AWS Transform: ce que notre “trousse à outils agentique” automatise vraiment

Deuxième volet de notre série migration & modernisation augmentées par l'IA. Le premier article posait la méthode, celui-ci ouvre le capot moteur.

Dans l'article précédent, nous avons appelé AWS Transform « notre trousse à outils agentique » sans détailler ce qu'il y a dedans. C'est l'objet de celui-ci: d'abord la carte du service, puis une transformation exécutée de bout en bout sur un cas simple, avec la configuration réelle, ce que l'agent produit, ce que ça coûte, et le piège que nous avons rencontré en route. En conclusion, la question qui décide d'un chantier: ce qu'AWS propose directement, et ce qui reste du travail d’expert.

Une conviction structure cette lecture: Transform matérialise le passage d'une IA qui prédit (les modèles de TCO), puis génère (code, documentation, IaC), à une IA qui raisonne et agit sur plusieurs systèmes. La conséquence pratique rend par contre la chose moins confortable que le slogan: un outil s'invoque simplement, un agent doit lui être gouverné.

Un avertissement tout d’abord car il illustre le sujet mieux qu'un argument: entre ma première version de cet article et sa publication, un petit mois s'est écoulé, et le service a changé de forme. Tout ce qui suit est vérifié et testé au 8 octobre 2026 et c'est la première leçon de l'article: avec un service qui bouge à ce rythme, la veille technologique fait partie du delivery. Notre propre outillage de migration n’y échappe pas.

Un workbench, cinq familles d'agents

AWS Transform n'est pas une collection de produits: c'est un service unique, avec des agents spécialisés par domaine, une application web partagée et une CLI. Depuis fin 2025, il a absorbé les capacités de transformation d'Amazon Q Developer (fin de support des upgrades via plugins IDE le 30 avril 2027) et remplace fonctionnellement AWS Migration Hub et AWS Application Discovery Service, fermés aux nouveaux clients depuis novembre 2025. Si votre outillage de migration AWS date de 2024, il est déjà consolidé sous cette nouvelle étiquette. Le tableau résume moins ce que chaque agent fait (il faut toujours lire la doc!) que ce qu'il faut savoir pour choisir, et surtout ce qui reste à votre charge une fois que l’agent a réalisé son travail.

Un exemple de bout en bout: moderniser une API Python 3.8

Notre terrain d'essai est une application témoin imaginée pour l'exercice: une API Python née en 2017, figée en 2019, dont le code et les dettes sont réels même si l'histoire est un décor. Elle cumule sept dettes qu'on retrouve éparpillées dans n'importe quel parc: Python 3.8, boto2, une librairie interne en 1.x, une clé d'API en dur, setup.py, unittest, Flask 1.x. Premier lot, le plus simple en apparence: sortir le repo de Python 3.8 qui au passage est hors support depuis octobre 2024, avec la transformation fournie par AWS.

Trois choses à savoir avant de lancer quoi que ce soit, parce qu'elles changent la façon de travailler. atx, la CLI d’AWS Transform custom, s'exécute en local: les modifications sont faites sur une branche Git locale et rien n'est poussé sur le repo remote automatiquement. Le service facture le seul temps actif de l'agent: la compilation et les tests tournent chez vous, gratuitement. Et tout le pilotage passe par un fichier de configuration, dont le schéma yaml tient en cinq keys:

# 01-python-upgrade.yaml
transformationName: AWS/python-version-upgrade
codeRepositoryPath: /chemin/vers/le-repo        # un repo Git valide, en local
buildCommand: python -m compileall -q monapp
additionalPlanContext: >
  Cible Python 3.11, pas au-delà #(voir plus bas pourquoi)
  Les deux paquets stub du repo sont hors périmètre: ne pas les modifier.
validationCommands:
  - python -m unittest discover -s tests -q
  - python scripts/check-python-compat.py --max 3.11

Les deux dernières keys font tout le travail invisible. additionalPlanContext injecte dans le plan de l'agent ce que le modèle ne peut pas deviner: le plafond de version, les zones interdites. validationCommands définit ce que « réussi » veut dire, et l'agent boucle dessus: transformation, build, validation, correction, jusqu'à ce que ça passe ou que la limite soit atteinte. Puis on lance:

atx custom def exec -g file://01-python-upgrade.yaml -x -t --limit 400
# -x exécute sans interaction
#--limit 400 plafonne le budget de l'exécution à 400 agent-minutes. 

Ce que l'agent produit alors, et qu'on retrouve à chaque exécution: un plan (visible et modifiable en mode interactif), une série de commits de checkpoint signés ATX Bot sur une branche de résultat (atx-result-staging-<id>), et un dossier d'artefacts par conversation, dont un validation_summary.md qui rejoue la validation, commande par commande. La branche est le livrable; la revue du diff et le merge restent des gestes humains. Pour l'ordre de grandeur budgétaire, l’estimation n’est pas aisée car elle dépend de la taille de la codebase et surtout de sa complexité mais aussi des itérations qui deviennent de plus en plus efficaces grâce aux “lessons” que nous verrons plus loin. Pour une première estimation, 6 $ pour 10k lignes de code est une base mais rien ne remplacera une estimation réalisée après le passage sur plusieurs repos. Le suivi (coût, agent-minutes) remonte dans AWS Cost Explorer.

Le piège rencontré, et la règle qu'on en tire

Premier réflexe: viser directement Python 3.14. Échec, et pas où on l'attend: boto 2.49 (le SDK AWS d'ancienne génération, présent dans le repo) ne s'importe plus sur Python 3.12+, parce qu'il s'appuyait sur un mécanisme d'import qui a changé. Or la suite de tests importe un module qui importe boto: la validation devient impossible avant même que la transformation commence. L'agent ne peut pas « décider » de migrer boto2 au passage, et c'est heureux: ce serait un débordement de périmètre.

Une règle d'ingénierie refait surface: la cible d'un upgrade de langage est plafonnée par la dépendance la plus obsolète du repo. La montée se fait donc en deux temps, de part et d'autre d'un lot boto2 → boto3: 3.8 → 3.11, boto3, puis 3.11 → 3.14 en réutilisant la même transformation avec un autre additionalPlanContext. Une transformation se paramètre, elle ne sert pas une seule fois.

Un exemple du type de réécriture que fait le lot boto3, pour fixer les idées:

# avant (boto2)                          
import boto                              
s3 = boto.connect_s3()                  
bucket = s3.get_bucket("factures")
key = bucket.get_key(key_name)
key.get_contents_to_filename(dest)

# après (boto3)                      
import boto3                              
s3.download_file("factures", key, dest)                  

Multiplié par tous les appels du repo, avec la gestion d'erreurs et la pagination qui changent aussi: c'est exactement le travail répétitif, mécanique et risqué à la main, où un agent validé par une bonne suite de tests est on ne peut plus à sa place.

Ce que l'agent apprend, et pourquoi votre validation en décide

À chaque exécution, le service extrait des “lessons”: les patterns et correctifs rencontrés, réappliqués aux exécutions suivantes de la même transformation (consultables et désactivables via atx custom def learnings, opt-out par -d). C'est ce mécanisme qui rend la centième exécution meilleure que la première. Mais il y a une condition que la pratique nous apprend: la qualité de l'apprentissage dépend de la commande de validation. Une validation qui échoue franchement quand le code est faux produit des lessons utiles alors qu’une validation peu claire fait capturer du bruit, qui se réappliquera. Définir validationCommands est le plus important du fichier de config.

Anatomie d'une “Custom Transform Definition”

Les transformations AWS couvrent les modernisations génériques et la liste s'enrichit presque chaque semaine: versions de langage, SDK, frameworks publics.

Dans notre cas nous souhaitons convertir le packaging de notre application: setup.py et requirements.txt vers un pyproject.toml conforme PEP 621, avec uv comme gestionnaire de dépendances et hatchling comme backend de build. Pour ce genre de cas simple la définition entière tient dans un fichier SKILL.md.

Aperçu de son frontmatter:

---
name: ippon-setuppy-to-pyproject
description: Convertit le packaging d'un projet Python de setup.py et
 requirements.txt vers un pyproject.toml conforme à PEP 621, avec uv
 comme gestionnaire de dépendances et hatchling comme backend de build.
 [...] Déclencher sur tout repo contenant un setup.py, un setup.cfg ou
 un requirements.txt à la racine. Ne pas déclencher sur les repos déjà
 en pyproject.toml conforme PEP 621, ni sur les projets Poetry.
---

La description dit quand se déclencher et quand ne pas: c'est elle que l'agent lit pour décider si la transformation s'applique à un repo, avant toute modification. Le corps ordonne ensuite six étapes (extraire les métadonnées, séparer les groupes de dépendances, traduire les contraintes, poser le backend, nettoyer, verrouiller), et deux marqueurs y encadrent ce que l'agent a le droit de produire:

IMPORTANT: python_requires='>=3.8' ne doit pas être recopié tel quel.
La version cible de la campagne est >=3.14: vérifier que le code migré
la supporte réellement avant de l'écrire.
[...]
CRITICAL: ne jamais transposer un == d'une version obsolète vers la
nouvelle version en gardant le ==, cela réintroduit le problème qu'on
est en train de résoudre.

Deux idées tiennent cette définition. D'abord, enseigner par l'exemple: le SKILL.md se termine par un modèle de sortie, un pyproject.toml complet et conforme à nos standards, dont l'agent généralise comme on le ferait à partir d’une doc de référence. Ensuite, baliser le destructif: la suppression de setup.py et requirements.txt n'est autorisée qu'après un build ok, jamais avant. Quant au périmètre négatif, il tient en une ligne: un diff de cette transformation qui contient un .py du package est un échec, même si le build passe.

Une commande la publie dans la registry transform du compte, versionnée (atx custom def publish -n ippon-setuppy-to-pyproject, un mode brouillon permet également d'itérer sans la rendre visible). Ensuite elle s'invoque comme n'importe quelle transformation AWS, par son nom dans la config du lot, la même config qui apporte ce qui reste propre au repo:

# 06-setuppy-to-pyproject.yaml
transformationName: ippon-setuppy-to-pyproject
codeRepositoryPath: /chemin/vers/le-repo
buildCommand: uv sync --all-groups
validationCommands:
 - uv run python -m compileall -q monapp
 - uv build
additionalPlanContext: >
 Target requires-python is >=3.14. Dev dependencies go into a PEP 735
 group named dev. Delete setup.py and requirements.txt only after
 uv build succeeds. Do not modify any file under monapp/ or tests/.

La définition porte la règle générale, comment on migre un packaging chez nous; la config porte le cas particulier, la cible et les dossiers intouchables de ce repo. L'agent lit les deux, déroule, et les lessons extraites de chaque exécution s'attachent à la définition: chaque passage améliore les suivants. Écrite une fois, la transformation sert ensuite sur tous les repos du parc encore en setup.py.

La TD (Transform Definition) la plus simple du registre est aussi la plus parlante: un fichier, six étapes. Et l'essentiel est dans ce qu'elle interdit: le == recopié, le .py touché, la suppression avant un build en success.

Ce que l’expérience nous a appris

Les limites qui comptent ne sont pas celles du produit: ce sont celles qu'on rencontre. En voici quatre tirées de nos premières campagnes. Chacune a coûté un échec, ou pire, un faux résultat.

Une commande de validation doit évoluer. Notre script de contrôle du dernier lot avait été écrit pour l'état initial du repo: interpréteur 3.8, librairie interne en v1, requirements.txt. Trois lots plus tard, plus rien de tout ça n'existait, et la validation échouait par construction: l'agent aurait conclu, à tort, que sa transformation était fausse. Le repo avait juste avancé. Une validation s'écrit pour l'état du repo au moment du lot, pas une fois pour toute la campagne.

Les transitives cassent avant la transformation. Notre Flask 1.1.2 tombait en panne dès que pip installait Werkzeug 3: le requirements.txt d'origine n'épinglait que les dépendances directes. La validation échouait pour une raison étrangère à la transformation en cours, le pire des signaux à donner à un agent qui apprend. D'où un prérequis qu'on applique désormais systématiquement: une baseline clean, dépendances gelées, avant la première agent-minute.

-x désactive plus que les questions. En mode autonome, le flag -t fait confiance à tous les outils, et notre fichier de commandes de confiance, pensé pour les sessions interactives, n'a plus aucun effet. Les garde-fous qui comptent ne peuvent donc pas vivre dans la configuration de session ni dans un prompt: nous les avons déplacés dans AWS Identity and Access Management (IAM), avec un refus explicite des actions de publication et de gestion des lessons sur le rôle d'exécution. Le prompt reste une intention, la policy IAM est une garantie.

L'outillage doit suivre le produit. Entre deux versions du CLI, le mécanisme des « knowledge items » que nos scripts géraient est par exemple devenu celui des lessons. Rejouer un lot de référence à chaque montée de version est vivement recommandé.

Conclusion: la partie AWS et le reste…

AWS livre le moteur, le format et une partie des transformations mais tout ce qui fait qu'une campagne réussit plutôt qu'une simple démo reste du travail d'expertise. La répartition, étape par étape:

La colonne de droite ne se dégarnit jamais: c'est là que nous travaillons. Notre valeur n'est pas de faire tourner l'outil, elle est dans ce que cette colonne exige: décider l'ordre des lots en lisant votre repo, écrire la transformation de votre librairie interne, poser les témoins qui détectent l'agent trop zélé, définir la validation qui rend l'apprentissage utile, et tenir la gate qui décide de merger. Les agents exécutent, nos experts décident, et l'objectif reste celui de l'article précédent: que vos équipes tiennent ces gates elles-mêmes après la mission. Le tout s'inscrit dans l'AWS Migration Acceleration Program (MAP), financement compris, dès la phase d’Assessment.

La ligne « passage à l’échelle » du tableau mérite son propre article: orchestrer des cohortes de repos, piloter les agents depuis Kiro ou Claude Code maintenant qu'ils parlent tous à Transform via MCP, tenir les seuils de stop des lots et la traçabilité quand on passe de un repo à trois cents. C'est le sujet du mois prochain.

D'ici là, si votre parc contient ces fameuses applications avec des librairies métiers internes et de vieux frameworks que personne n'ose plus monter de version et encore moins moderniser à la faveur d’une migration: c'est précisément les cas qu'on préfère.

Tristan Miche - AWS Ambassador, Ippon Technologies