Maintenance applicative : tester Claude Code et Codex sur un projet legacy

L'IA en maintenance applicative doit d'abord aider à comprendre et vérifier un changement limité. Sur un projet legacy, Claude Code ou Codex peuvent être évalués sur la lecture d'un module, l'ajout de tests et la correction d'un défaut reproductible. Commencer par une refonte générale rend les risques et les résultats plus difficiles à maîtriser.

Le terme legacy ne signifie pas nécessairement que l'application est mauvaise. Elle peut porter des règles métier essentielles, peu documentées et connues de quelques personnes. Le premier objectif est de préserver ces règles tout en rendant le problème visible.

Scénario pédagogique conçu le 17 septembre 2026 avec assistance IA. Il ne décrit pas une intervention client réalisée. Les exemples doivent être adaptés à un dépôt autorisé. Illustration générée par IA.

Choisir un module dont le comportement peut être observé

Retenez un traitement limité : validation d'un formulaire, export, calcul local ou transformation de données. Il doit être possible de fournir une entrée et de vérifier une sortie. Une anomalie déjà signalée avec un cas reproductible constitue un bon point de départ.

Évitez d'abord les migrations de base, l'authentification globale et les traitements irréversibles en production. Ces périmètres peuvent être abordés ensuite, avec un dispositif de validation adapté, mais ils compliquent inutilement un premier essai.

Avant de partager le dépôt, validez les conditions de sécurité du code source client. Remplacez les données de production par des exemples synthétiques qui conservent la structure nécessaire au test.

Un scénario : un export traite mal les valeurs manquantes

Imaginons une application qui exporte des lignes de commande. Lorsque la quantité manque, le module produit une ligne incohérente au lieu de signaler une erreur. Le responsable métier confirme que l'export doit rejeter cette ligne et conserver le comportement des autres cas.

Le ticket de pilote précise les entrées concernées, le message attendu, les sorties à préserver et les fichiers exclus. L'agent n'a pas à décider seul si une quantité absente vaut zéro ou un. Cette décision relève du contrat métier.

Le périmètre s'arrête à une correction et à ses tests. Une modernisation de la syntaxe, un changement de bibliothèque ou une réorganisation de tout le module doit être proposée séparément, même si l'agent estime que ce serait plus élégant.

Étape 1 : demander une carte du comportement existant

Demandez à l'agent de retrouver le point d'entrée, les appels et les tests liés à l'export. Il doit citer les fichiers et distinguer ce qu'il a lu de ce qu'il a réellement exécuté. Le mainteneur confirme ensuite les relations importantes.

Examiner le module d'export sans modifier les fichiers.
Identifier le chemin suivi par une ligne avec quantité absente.
Citer les fonctions et tests concernés.
Distinguer observations, hypothèses et informations manquantes.
Proposer le plus petit test qui permet de confirmer la cause.

Cette phase peut révéler que le défaut vient de la préparation des données plutôt que de l'export lui-même. La correction doit suivre les preuves, pas l'emplacement supposé au départ.

Étape 2 : créer des tests de caractérisation

Un test de caractérisation décrit le comportement existant. Il aide à éviter qu'un correctif modifie involontairement d'autres cas. Il ne signifie pas que tous les comportements actuels sont souhaitables : le défaut identifié doit rester distingué des règles à préserver.

Construisez une liste d'entrées avec le responsable métier : valeur normale, valeur absente, zéro, chaîne vide et valeur hors domaine. Pour chacune, écrivez la sortie attendue ou indiquez qu'une décision est nécessaire. N'inventez pas une règle pour remplir le tableau.

La documentation des bonnes pratiques Claude Code recommande de fournir des critères vérifiables. Ici, le critère est un test qui met en évidence le défaut avant la correction.

Étape 3 : produire un correctif minimal

Confiez une seule modification à l'agent et demandez un diff réduit. Le correctif doit traiter la cause confirmée sans changer la politique d'erreur d'autres modules. Si une refonte devient nécessaire, interrompez l'exercice pour requalifier le périmètre.

La revue recherche notamment les conversions implicites, les valeurs par défaut non justifiées et les exceptions absorbées. Remplacer une erreur par une valeur arbitraire peut faire disparaître le symptôme tout en détériorant les données.

Ne mélangez pas reformatage massif et correction fonctionnelle. Un petit diff permet de comprendre la causalité et de revenir sur la modification si les tests d'intégration révèlent un effet inattendu.

Étape 4 : vérifier à plusieurs niveaux

Exécutez le test ciblé, les tests du module et les vérifications d'intégration pertinentes. Si une commande échoue pour une raison d'environnement, signalez-le explicitement. Le résultat ne doit pas être présenté comme prêt à livrer tant que les preuves essentielles manquent.

Demandez ensuite une revue indépendante de la modification. Pour un export, contrôlez un fichier produit avec les données d'essai, son format et sa lecture par le système destinataire de test. Une fonction correcte en isolation peut encore être mal utilisée par son appelant.

Le guide de tests unitaires avec Claude Code et Codex détaille la différence entre génération de tests et validation d'une règle. Une couverture élevée ne suffit pas si les assertions ne contrôlent pas le comportement utile.

Comparer Claude Code et Codex sur le même legacy

Préparez deux copies du même commit et une consigne identique. Donnez les mêmes décisions métier et les mêmes commandes. Empêchez le second outil de consulter le correctif du premier pendant l'essai.

Mesurez le temps nécessaire pour localiser la cause, le nombre de modifications hors périmètre, la qualité des tests et l'effort de revue. Le résultat intéressant peut être une meilleure investigation, même si le code final tient en quelques lignes.

Notez le modèle, le mode d'exécution et les droits accordés. Vous comparez des configurations datées sur un module précis, pas une supériorité générale d'un produit. Le comparatif pour ESN fournit une grille commune.

Refactoring et modernisation : une décision séparée

Un correctif réussi peut révéler une dette technique, mais ne justifie pas automatiquement sa réécriture. Distinguez la correction du bug, l'amélioration de testabilité et la modernisation de l'architecture. Chacune nécessite son objectif et ses critères.

Pour évaluer un refactoring OpenAI Codex ou Claude Code, commencez par une transformation sans changement fonctionnel attendu. Les tests de caractérisation deviennent alors une référence, complétée par une revue métier si le code couvre des cas mal documentés.

La modernisation complète d'une application demande une analyse des dépendances, du support des versions et des exigences de migration. Un pilote de maintenance ne démontre pas sa faisabilité ni son budget.

Le livrable attendu en fin de démonstration

Conservez le ticket, le commit de départ, l'explication de la cause, le test qui reproduit le défaut, le correctif et les résultats de validation. Ajoutez les limites et les décisions métier prises pendant l'exercice.

Ce dossier permet à un autre développeur de vérifier la démarche. Il sert également à calculer le ROI du pilote en incluant les reprises et la revue, pas seulement la génération du patch.

Questions fréquentes

Peut-on commencer sur une application sans tests ?

Oui pour une investigation et la préparation d'un premier test de caractérisation. Mais l'absence de tests augmente le travail de validation ; elle ne justifie pas une fusion sur la seule confiance dans l'agent.

Faut-il donner tout le dépôt au modèle ?

Fournissez le contexte nécessaire, dans le périmètre autorisé. Une exploration ciblée aide à réduire le bruit et les données exposées. L'agent doit pouvoir demander les éléments manquants sans élargir seul ses droits.

Le legacy doit-il être modernisé avant d'utiliser un agent ?

Pas nécessairement. Un pilote limité peut aider à comprendre et tester l'existant. Les contraintes d'environnement et de versions doivent cependant permettre une vérification fiable.

Demander une démonstration sur un périmètre autorisé

Hunter BI propose de préparer une démonstration à partir d'un module, d'une anomalie reproductible et de critères validés. Le travail commence par les accès et la compréhension du comportement, puis se limite au périmètre convenu.

Demander une démonstration IA pour la maintenance applicative ou découvrir notre approche d'ingénierie IA.