Refactorisation par agents : quelles preuves demander avant de confier son code à une IA ?

Une étude de cas publiée par CodeScene rapporte la refactorisation de 300 000 lignes de C en trois semaines avec l’aide d’agents de codage, pour environ 4 000 dollars de jetons. Le résultat aurait été vérifié par un harnais de rejeu image par image, tandis que les agents construisaient progressivement un guide de recettes propres au code étudié.

Le chiffre attire l’attention, mais il ne constitue pas à lui seul une décision exploitable pour une PME. La vraie question est plus exigeante : que prouve exactement cette démonstration, quelles hypothèses restent ouvertes et quelles preuves faudrait-il réunir avant de laisser un agent modifier une application métier ?

Le chiffre impressionne, mais le périmètre décide

« 300 000 lignes » décrit un volume de code, pas une valeur métier ni une garantie de maintenabilité. Deux bases de code de même taille peuvent présenter des risques très différents selon la qualité des tests, la stabilité des interfaces, la présence de dépendances externes ou le nombre d’utilisateurs concernés.

Le cas rapporté concerne du C et une période de trois semaines. Ces éléments sont importants, car ils empêchent de transformer l’observation en promesse générale. On ne peut pas en déduire qu’un agent refactorisera une application web, un progiciel métier ou une API avec la même efficacité. On ne peut pas non plus conclure qu’un coût de jetons comparable couvrirait la préparation, la revue humaine, l’intégration et la reprise des anomalies.

Pour un décideur, le premier livrable à demander est donc une fiche de périmètre : langage, modules concernés, types de transformations, dépendances touchées, exclusions et conditions d’exécution. Sans cette fiche, le volume annoncé reste difficile à comparer à son propre patrimoine applicatif.

Ce que le harnais de rejeu change dans l’évaluation

Le point le plus instructif du cas n’est peut-être pas la vitesse de production du code, mais l’existence d’un mécanisme de vérification. Un harnais de rejeu image par image cherche à rejouer un comportement de référence et à comparer les étapes observées. Dans ce contexte, il fournit un cadre de contrôle plus précis qu’un simple « les tests passent ».

Cette méthode ne supprime pas le risque. Elle déplace la question vers la qualité du scénario de référence. Si le rejeu couvre seulement certains parcours, l’agent peut préserver les comportements observés tout en modifiant un cas absent. Si la comparaison mesure une sortie visible mais pas un effet secondaire, une régression peut rester invisible. Si l’environnement de référence est incomplet, la vérification reproduit une confiance limitée.

Avant un projet réel, une PME devrait donc distinguer trois niveaux de preuve :

• la preuve que le code modifié compile et respecte les contrôles techniques prévus ;
• la preuve que les parcours métier représentatifs conservent leur comportement attendu ;
• la preuve que les effets opérationnels, comme les journaux, les traitements différés ou les échanges avec d’autres systèmes, restent compréhensibles et maîtrisables.

Cette séparation rejoint les principes d’une chaîne d’outils de développement proportionnée : chaque outil doit répondre à un risque et produire une preuve lisible, plutôt que simplement ajouter une étape automatisée.

Le guide de recettes est une sortie aussi importante que le code

Le dossier indique que les agents ont construit un playbook de recettes propres au code étudié. C’est une information intéressante pour une entreprise qui envisage ce type d’approche. Un agent n’apprend pas seulement à appliquer une transformation générique ; il peut aussi exploiter des règles spécifiques au dépôt, à ses conventions et à ses contraintes de validation.

Mais ce guide ne doit pas rester implicite dans les conversations de l’agent. Il devrait devenir un livrable relu par l’équipe : règles de transformation autorisées, fichiers exclus, commandes de vérification, conditions d’arrêt, cas connus d’échec et procédure de retour arrière. Sans cette formalisation, une partie de la connaissance acquise pendant le chantier risque de disparaître avec la session de travail.

Une entreprise qui reprend une application doit également vérifier que le playbook est compréhensible par une personne qui n’a pas participé à l’expérience. C’est le même principe que pour un audit de maintenabilité : la valeur ne réside pas uniquement dans l’analyse, mais dans les preuves qui permettent à une autre équipe de reprendre la décision et le logiciel.

Trois questions à trancher avant de lancer un pilote

1. Quelle transformation veut-on réellement obtenir ? Une modernisation de syntaxe, une réduction de duplication, une séparation de modules et une correction de conception ne présentent ni le même risque ni les mêmes critères d’acceptation.
2. Quel comportement doit rester inchangé ? Il faut identifier les parcours critiques, les interfaces, les traitements planifiés et les données qui servent de référence avant de demander à l’agent de modifier le code.
3. Qui peut arrêter le chantier ? Un pilote doit prévoir un responsable capable de suspendre la génération, de refuser une série de changements ou de revenir à l’état précédent sans négociation improvisée.

Le bon point de départ n’est donc pas nécessairement le plus gros dépôt. Un périmètre réduit mais représentatif permet de vérifier si les scénarios sont assez couvrants, si les résultats sont relisibles et si le coût de revue reste compatible avec les compétences disponibles.

Les métriques à ne pas confondre

Le cas met en avant un volume de lignes et un coût de jetons. Ces mesures peuvent aider à documenter une expérience, mais elles ne suffisent pas à évaluer sa réussite. Une ligne réécrite n’est pas une anomalie supprimée. Un jeton consommé n’est pas le coût complet d’une transformation. Une exécution rapide ne signifie pas que la reprise sera simple.

Pour préparer une comparaison honnête, il vaut mieux suivre des indicateurs reliés à la décision :

• part du périmètre réellement couverte par les scénarios de vérification ;
• nombre et nature des changements refusés lors de la revue ;
• temps humain consacré à comprendre, corriger et accepter les propositions ;
• capacité à expliquer chaque modification importante ;
• existence d’un retour arrière praticable et documenté.

Ces indicateurs ne promettent aucun gain avant que le pilote ne les ait mesurés. Ils évitent surtout de confondre productivité de génération et maîtrise du changement.

Checklist de cadrage pour une PME

• Décrire le périmètre de code et les modules exclus.
• Nommer les comportements qui ne doivent pas changer.
• Rassembler les tests, jeux de données et scénarios réellement représentatifs.
• Définir les transformations autorisées et celles qui nécessitent une validation humaine renforcée.
• Conserver une trace de la proposition de l’agent, de la modification retenue et de la décision de revue.
• Prévoir une procédure de retour arrière avant la première exécution.
• Mesurer séparément le temps de génération, le temps de vérification et le temps de correction.
• Faire relire le playbook par une personne extérieure au pilote.

Cette checklist ne transforme pas un agent en prestataire autonome. Elle donne au contraire au décideur les éléments nécessaires pour conserver une responsabilité claire sur le code, les données et la continuité de l’application.

Ce que l’étude de cas permet réellement de conclure

Le cas rapporté constitue un signal intéressant sur la possibilité d’organiser une refactorisation assistée par agents autour d’un harnais de vérification et de recettes spécifiques au code. Il ne suffit pas à prouver qu’une telle approche convient à toutes les applications, ni que le coût annoncé représente un budget complet, ni que le résultat est transposable sans adaptation.

La décision raisonnable consiste à traiter cette approche comme une hypothèse à vérifier sur un périmètre limité. Le pilote devra rendre visibles ses entrées, ses transformations, ses contrôles, ses limites et la part de revue humaine nécessaire. Si ces éléments sont documentés, l’entreprise pourra décider de poursuivre, de réduire l’ambition ou d’abandonner l’automatisation sans avoir engagé tout son patrimoine applicatif.