Comment se préparer aux projets de modernisation du code basés sur l'IA

Dans notre série Notes from the Field, les ingénieurs d'Anthropic, déployés sur le terrain, partagent les bonnes pratiques inspirées par des déploiements réels chez des clients. Dans cet article, nous partageons notre expérience dans la gestion de projets de modernisation de code d'envergure.

Les modernisations de code, autrefois envisagées comme des efforts multiannuels, peuvent désormais être terminées en quelques mois (ou semaines), mais le travail organisationnel des deux côtés reste souvent le même.

Par exemple, chaque modification apportée à un système bancaire critique doit faire l'objet d'une gestion des changements, d'une révision et d'une approbation. Il s'agit d'un processus robuste car les autorités de réglementation, les auditeurs et l'entreprise l'exigent.

Ce sont ces processus qui rendent les systèmes critiques fiables, et ils ont été conçus en partant de l'hypothèse qu'un humain avait écrit chaque modification et qu'un humain examinerait chaque diff. Une fois que les agents accélèrent la rédaction des changements, le goulot d'étranglement passe de la production de ces changements à la mobilisation de l'organisation autour de ces derniers.

Cet article couvre le travail que les entreprises doivent accomplir avant que la modernisation n'ait lieu : définir ce que signifie « terminé », quelles preuves un changement doit comporter, comment les modifications certifiées atteindront la production et ce qui doit être mis en place pour que l'exécution puisse commencer.

Nous décomposons ce processus en six étapes :

1. Définissez l'objectif : la pile technologique et le comportement que doit avoir le code modernisé.
2. Créez le certificat: les conditions que les modifications doivent remplir pour être considérées comme correctes dans l'état cible.
3. Définissez la politique de mise en production : le chemin par lequel les modifications certifiées entrent en production au rythme où elles sont produites.
4. Mettez les prérequis en place : environnement, CI/CD, capacité de révision et approbations.
5. Créez et affinez le flux de travail agentique : le flux de travail dynamique personnalisé Claude Code qui répartit la modernisation sur de nombreux flux de travail de sous-agents parallèles plus petits qui produisent les modifications. Ceci est structuré autour de la cible, du certificat et de la politique de mise en production.
6. Exécutez la modernisation : validez le flux de travail de bout en bout sur une petite partition de la base de code, puis mettez-le à l'échelle.

Étape 1 : Définir la cible

La cible est l'état final de la modernisation. L'état final souhaité détermine lequel des trois types de modernisation vous effectuez, comme détaillé dans le tableau ci-dessous.

Déterminez le type de modernisation

La détermination du type de modernisation à réaliser est souvent débattue au sein d'une organisation. D'après notre expérience, les personnes les plus proches de la production souhaitent remplacer la pile technologique tout en conservant un comportement identique afin de limiter les risques (modernisation par transformation). De l'autre côté, on trouve souvent les ingénieurs qui ont vécu avec la base de code et qui souhaitent profiter de la modernisation pour rembourser la dette technique, ainsi que d'autres parties prenantes métiers qui veulent saisir l'occasion pour définir de nouvelles exigences (réimaginer la modernisation).

Les deux positions sont raisonnables, mais si la question n'est pas résolue, elle refait surface ultérieurement sous forme de débat pour savoir si un changement donné est « correct ». Trouver un consensus sur la voie à suivre ajoute des frictions initiales, mais rationalise le projet dans son ensemble.

Cartographier la base de code et créer la spécification comportementale

Comprendre le système actuel est souvent une bonne première étape pour définir la cible. En extrayant ce que fait réellement l'ancien code et en créant un inventaire du comportement actuel, il est facile de décider si certaines parties doivent être modifiées ou supprimées, et donc si la modernisation est une transformation ou une réinvention. Cela révèle également souvent une logique métier inconnue et des cas limites.

Claude peut contribuer en grande partie à cette découverte en cartographiant les dépendances et en documentant les flux de travail que personne ne se souvient d'avoir créés. Les commandes du plug-in de modernisation du code assess, map, et extract-rules extraient des règles métier accompagnées de références à la source que les ingénieurs peuvent ensuite examiner.

Toutefois, la seule découverte de Claude peut ne pas rendre pleinement compte du comportement d'un système existant. Des entretiens avec des utilisateurs métiers et des développeurs, ainsi que de la documentation interne, peuvent combler ces lacunes. La collecte du contexte peut prendre un certain temps au départ, mais la qualité de ce contexte façonne chaque décision que prendra ensuite le flux de travail.

Pour une refonte, définir la cible nécessite un travail supplémentaire : une spécification comportementale détaillée doit être rédigée et validée par les groupes d'utilisateurs.

Établir la justification et les objectifs du projet

Outre la définition de la cible, l'organisation doit examiner les raisons pour lesquelles la modernisation vaut la peine d'être entreprise. La modernisation des systèmes existants peut réduire les coûts récurrents de maintenance et d'exploitation. Toutefois, d'après notre expérience, la réduction des coûts n'a pas été l'objectif principal de la plupart des projets de modernisation.

Par exemple, un système présentant des vulnérabilités non corrigées peut entraîner une violation de données ou une panne suffisamment grave pour mettre l'entreprise elle-même en danger. Un runtime non pris en charge ou un bassin d'ingénieurs de plus en plus restreint maîtrisant le système exacerbent le risque.

Les outils de codage agentique comme Claude Code ont raccourci les délais de modernisation, mais les budgets restent difficiles à estimer, ce qui entraîne une certaine inertie. Nous avons publié les coûts de certaines de nos modernisations d'envergure, comme d'autres l'ont fait. Ces éléments peuvent servir de base approximative, et nous fournissons des indications supplémentaires sur les projections budgétaires à la fin de ce guide.

Le principal défi pour lancer ces projets est généralement de parvenir à un consensus interne et d'obtenir l'engagement des équipes propriétaires du système et des équipes qui en dépendent. L'élaboration de l'analyse de rentabilité et la définition des objectifs du projet, souvent au niveau de la direction, facilitent cette partie du processus. Cela permet également de mieux situer les compromis dans le certificat et la politique de mise en production qui suivent. Lorsque les parties prenantes sont en désaccord sur le niveau de risque qu'un changement peut comporter, le risque de ne pas se moderniser constitue le contrepoids.

Étape 2 : Définir le certificat

Le certificat est l'ensemble des conditions ou des tests que chaque changement de modernisation doit remplir. Choisissez les conditions qui fournissent les preuves cumulatives les plus solides que le changement est valide par rapport à la cible.

Chaque condition doit être vérifiable sans intervention humaine, afin que le flux de travail agentique puisse itérer sur une modification jusqu'à ce qu'elle réponde au certificat, ou la signaler pour examen humain si ce n'est pas possible.

Le contenu du certificat dépend de la cible, mais sera généralement tiré de cette liste :

• La suite de tests initiale passe
• Les tests rédigés par Claude lors de la modernisation passent tous
• La couverture des tests atteint un seuil convenu
• Les indicateurs de performance restent dans les limites convenues
• Les examens indépendants et contradictoires par Claude, chacun dans une nouvelle fenêtre de contexte, ne permettent d'identifier aucun problème bloquant
• Pour les interfaces utilisateur, l'utilisation de l'ordinateur pilotée par Claude ne détecte aucune régression
• Les versions actuelle et cible produisent le même résultat à partir de la même entrée, qui peut être en direct, enregistrée ou générée par Claude
• L'état persistant et les formats de transmission effectuent des allers-retours entre les versions actuelle et cible
• Les modifications sont déployées dans l'environnement de staging pendant une période convenue sans aucune régression des taux d'erreur, de la latence ou des alertes
• L'analyse statique et les analyses de sécurité n'ont pas révélé de nouveaux résultats
• Pour les cibles compilées, le build est propre et les vérifications de type sont réussies

Leur expertise façonne ce que mesure le certificat, et leur implication précoce est ce qui garantit leur adhésion lorsque les changements sont examinés. Un bon moyen de vérifier le certificat final est de déterminer s'ils se sentiraient en confiance pour effectuer une fusion sur la base des seules preuves fournies par le certificat. S'ils y retrouvent leur propre standard, la politique de mise en production de l'étape 3 peut être allégée.

Ce que le certificat vérifie, et la façon dont il le fait, dépend du type de modernisation.

• Pour une modernisation de type uplift, la parité est établie par rapport à la base de code d'origine, et la suite de tests d'origine peut constituer le noyau du certificat.
• Pour une modernisation par transformation, la parité est également établie par rapport à la base de code d'origine, mais la suite de tests d'origine s'exécute rarement sur la nouvelle pile. Le rejeu du trafic de production, les tests différentiels entre l'ancien et le nouveau et un déploiement parallèle en production assurent l'essentiel du travail à la place.
• Pour une modernisation repensée, le certificat est ancré dans la spécification comportementale. C'est le cas le plus difficile. Une spécification est moins objective qu'un système existant pour effectuer un diff, ce qui implique une plus grande part de jugement de la part du modèle, pouvant conduire à des résultats plus variables. Ici, le certificat s'appuie sur des tests rédigés à partir de la spécification, des examens contradictoires indépendants effectués par Claude qui vérifient chaque changement par rapport à la spécification, et des contrôles différentiels où le nouveau système conserve le comportement de l'ancien. Prévoyez de réviser le certificat à mesure que la spécification sera clarifiée : les lacunes dans la spécification apparaissent ici en premier.

Les systèmes plus anciens ont souvent une faible couverture de tests, des tests instables et une télémétrie limitée. Une partie de la définition du certificat consiste à identifier ces lacunes. S'il est difficile de prendre en charge un certificat solide, l'une des choses les plus utiles à faire à cette étape est d'utiliser Claude pour générer les preuves manquantes, qu'il s'agisse de mettre en place une configuration parallèle à la production, de créer un système de rejeu ou de rédiger davantage de tests.

Étape 3 : définir la politique de mise en production

Les agents apporteront des changements beaucoup plus rapidement qu'une équipe humaine ne peut les examiner diff-by-diff. La politique de mise en production est un parcours d'examen à plusieurs niveaux – consigné par écrit et convenu à l'avance – qui définit le degré d'examen humain d'un changement, afin que la modernisation puisse s'achever dans un délai acceptable.

Comme pour le certificat, travaillez cette étape avec les évaluateurs et intégrez-la dans le processus de gestion du changement existant de votre organisation dans la mesure du possible. Les détails varieront selon l'organisation et les arbitrages en matière de risques auxquels elle est confrontée, mais quelques règles s'appliquent partout :

• Changements de niveau par rayon d'impact et confiance de l'agent. Utilisez la classification des changements ou des risques propre à votre organisation, si elle en dispose. Maintenez une revue humaine complète des chemins critiques.
• Corrigez les indicateurs récurrents à la source. Regroupez et analysez les modifications signalées au fil du temps. Lorsque le même type d'alerte se répète, corrigez la cause dans le flux de travail agentique ou le certificat plutôt que de réviser chacune d'entre elles.
• Concevez le format de sortie avec les réviseurs. Mettez-vous d'accord sur les informations et le format qui permettent d'accélérer l'examen, et sur les signaux qui inspirent davantage confiance que d'autres. Demandez-leur d'examiner les premiers échantillons de résultats à l'étape 5.
• Allouez efficacement le temps des SME. Les SME ne liront pas chaque diff final, mais leur jugement reste la ressource rare. Permettez-leur d'accéder directement aux modifications apportées aux niveaux les plus à risque et aux décisions signalées par les agents dans chacun d'eux, sans avoir à parcourir de longs diffs. Un petit nombre d'heures d'expertise couvre ensuite les modifications qui comportent le plus de risques.

Nombre de ces règles concentrent les heures des SME en les impliquant dès le début du projet. Leurs retours permettent d'affiner le certificat et le flux de travail agentique avant le début de la modernisation complète.

Leur approbation des échantillons constitue également une justification supplémentaire pour un parcours d'examen plus léger où le niveau de confiance est élevé. C'est le contraire du schéma traditionnel non agentique, où la révision intervient à la fin.

La politique de mise en production doit également refléter la position de la modernisation sur le spectre entre rapidité et profondeur de l'examen. Une modernisation soumise à un délai strict, comme lorsqu'un runtime cesse d'être pris en charge, nécessite une politique plus rapide avec une révision humaine allégée et un accord explicite pour accepter un risque plus élevé par changement.

Une modernisation sur une période plus longue peut permettre une révision humaine plus approfondie et une transition plus lente. Les parties prenantes se situeront à différents points de ce spectre en fonction de leur appétit pour le risque et de leurs contraintes ; il est donc utile de se mettre d'accord avant le début des travaux.

Dans un environnement réglementé, opter pour un processus de révision humaine plus léger pour tout changement peut susciter une réelle inquiétude. Les personnes chargées de l'approbation hésitent à donner leur accord, car elles portent la responsabilité d'un changement néfaste, tandis que les dirigeants assument le risque plus important d'un système vieillissant.

D'après notre expérience, il est préférable que la directive concernant la politique de mise en production émane du plus haut niveau de l'organisation. Il est également préférable de s'entendre à l'avance pour que la responsabilité d'un bug qui atteint la production soit partagée et non attribuée à la personne qui a approuvé le changement.

Étape 4 : Mettre en place des prérequis

Une grande partie de cette étape est confiée à des équipes extérieures à la modernisation : plateforme ou infrastructure pour l'hôte, assurance qualité ou ingénierie des versions pour la capacité de test, sécurité et conformité pour les approbations. Chacune de ces équipes a souvent son propre backlog ou son propre processus d'approbation, alors entamez les conversations tôt, dès que vous avez identifié les exigences, souvent pendant que les étapes 1 à 3 sont encore en cours.

Environnement

• Un hôte distant dédié pour exécuter le flux de travail avec la base de code et d'autres sources pertinentes accessibles par Claude
• Capacité d'essai telle que requise par le certificat
• Tout ce qui renforce le certificat : télémétrie de production, configuration parallèle à la production ou données de production pour la relecture

Base de code et CI/CD

• Une carte des dépendances de la base de code fondée sur les journaux de build et de compilation, l'analyse des importations ou les traces d'exécution. Remarque : la commande map du plug-in est un bon point de départ, mais en fonction de la taille et de l'âge de la base de code, un travail préalable plus important peut être nécessaire
• Traitement planifié des éventuelles dépendances ou packages, dans le cadre de la définition de la cible
• Un contrôle de compatibilité prêt à être ajouté à CI/CD, si nécessaire
• Une politique convenue de gel du code, si vous modernisez sur place
• Un plan de communication pour les développeurs actifs couvrant les gels de code et les nouvelles exigences de compatibilité

Équipes et révision

• Accord des autres équipes qui dépendent de la base de code pour leur participation, par exemple en approuvant le certificat ou en effectuant des revues conformément à la politique de mise en production, avec un temps réservé aux réviseurs

Sécurité et conformité

• Un chemin d'accès au modèle pour Claude Code approuvé pour le code source
• Accès au moindre privilège pour le flux de travail agentique : écriture autorisée uniquement sur les branches de modernisation et aucun identifiant de production
• Secrets et informations personnelles supprimés ou masqués de la branche de modernisation
• Chaque changement est traçable et chaque PR est liée à une transcription d'agent et à une preuve de certificat
• Vérifications des licences et des vulnérabilités sur les nouvelles dépendances

Étape 5 : Créer et affiner le flux de travail agentique

Utilisez Claude Code pour développer un flux de travail dynamique personnalisé pour moderniser la base de code.

Nous recommandons de commencer par le plug-in de modernisation du code et de placer tout ce dont le flux de travail peut avoir besoin sur le système de fichiers ou sur MCP, où Claude peut l'atteindre. Cela inclut la cible, le certificat, la politique de mise en production, la base de code et la documentation ainsi que les sources de données ou les outils nécessaires pour le certificat. Vous pouvez également donner cet article à Claude pour le contexte. Cela constitue la base de connaissances centrale du projet.

Une fois cela établi, construire le flux de travail de modernisation est la partie facile. Demandez aux SME de réviser le travail de Claude selon les besoins, y compris toute skill spécifique à la base de code ou toute règle extraite, avant toute utilisation en aval.

Affinez ce que vous avez construit en l'appliquant à de petites parties de la base de code, avec les SME passant en revue les modifications produites, le processus des agents et les preuves que les exigences du certificat ont été satisfaites.

Étape 6 : exécuter la modernisation

Premièrement, terminez la modernisation de bout en bout sur une petite partie de la base de code, notamment en examinant et en validant les modifications dans le cadre de la politique de mise en production. Corrigez tout ce qui ne fonctionne pas tant que cela reste peu coûteux, répétez le processus jusqu'à ce que vous soyez en confiance, puis étendez votre solution à l'ensemble de la base de code.

Alors que les modernisations de transformation et de réimagination impliquent de construire la cible aux côtés du système existant et de procéder au basculement une fois terminé, une mise à niveau offre une deuxième option : la modernisation en place sur la base de code active pendant que le développement se poursuit.

C'est le choix habituel lorsque le système ne peut pas être interrompu ou lorsque la base de code évolue si rapidement qu'il est difficile de maintenir à jour une copie modernisée distincte. Ce que nous avons vu fonctionner dans ce cas, c'est le découpage de la base de code en partitions logiques des feuilles vers l'intérieur ; le gel et la modernisation d'une partition à la fois ; et le contrôle du CI/CD afin que les nouvelles validations ne puissent pas annuler une partition une fois qu'elle a été modernisée.

Une note sur les coûts

On nous demande souvent combien une modernisation comme celle-ci coûtera en jetons. Chaque effort de modernisation est différent, mais les principaux facteurs de coûts incluent :

• Quelle part de la base de code doit être lue par rapport à celle à modifier ;
• Le degré d'implication du certificat (la vérification, et non la rédaction des modifications, représente généralement la part la plus importante dans un environnement réglementé) ;
• La quantité de rédaction de nouveaux tests et de réparation de tests que le certificat exige ; et
• Quelle part du travail de réconciliation provient du fait que d'autres équipes s'intègrent à votre projet pendant que l'exécution est en cours.

Les mesures issues du projet pilote montrent également où optimiser votre flux de travail agentique en termes de coûts. Trouvez les parties du flux de travail qui ont consommé le plus de jetons et réfléchissez aux moyens de les rendre plus efficaces. Déplacez les signaux de vérification gourmands en ressources informatiques derrière des filtres moins coûteux afin qu'ils ne s'exécutent qu'une fois les contrôles plus simples validés.

Envisagez d'utiliser des modèles comme Sonnet qui équilibrent les coûts et les capacités pour les travaux mécaniques à fort volume que le certificat vérifie entièrement. Conservez des modèles plus intelligents pour les transformations difficiles et les évaluations contradictoires qui en vérifient l'exactitude.

Vous pouvez également passer à un modèle plus coûteux lorsqu'un modèle moins coûteux ne répond pas aux critères requis, mais analysez soigneusement les taux de réessai lors du pilotage, car plusieurs tentatives peu coûteuses peuvent coûter plus cher qu'une seule tentative coûteuse. Si vous donnez à Claude un accès à la fois au flux de travail et aux données pilote, il peut effectuer une grande partie de ces analyses avec vous.

Au-delà de la modernisation

La base de code modernisée est l'un des résultats. Les autres sont le flux de travail qui l'a produit, un certificat écrit de ce qui est considéré comme correct, une politique de mise en production déjà acceptée par votre processus de gestion du changement et une piste d'audit pour chaque changement apporté. Codifiez le playbook comme un actif réutilisable, afin que le modèle soit déjà en place pour la prochaine mise à niveau ou réécriture.

Nos ingénieurs déployés sur le terrain travaillent selon ces étapes avec les clients sur leurs systèmes les plus critiques. Si vous préparez une modernisation, adressez-vous à notre équipe.

Ressources supplémentaires

• Le plug-in public codemod pour Claude Code
• Le manuel SDLC fondé sur l'IA
• Manuel de modernisation du code
• Modernisation de COBOL avec l'IA : surmonter l'obstacle des coûts