Stratégie brownfield
Comment faire la transition d'une base de code existante vers le développement IA-natif : quand remédier sur place, quand utiliser la migration strangler-fig, quand reconstruire, quand isoler, et la méthodologie qui rend chacune faisable.
Votre base de code est-elle réellement brownfield ?
Les quatre modes de cette page s'appliquent aux bases de code brownfield : du code existant avec des décisions accumulées, des utilisateurs en production et une équipe qui travaille à l'intérieur. Avant de choisir un mode, vérifiez l'état de la base de code. Trois cas se présentent en pratique :
| État | Ce que ça signifie | Quoi faire |
|---|---|---|
| Greenfield (en développement, pré-lancement) | Nouvelle base de code, pas encore en production, ou en production mais assez jeune pour que tout le code soit encore activement conçu. Les faibles scores de maturité ici sont des décisions de planification, pas de la dette. | Continuez le développement. Comblez les écarts de maturité selon le calendrier. Relancez l'évaluation de maturité au lancement et traitez les écarts non comblés comme brownfield à ce moment-là. |
| Brownfield (production, accumulé) | Le code existe, tourne en production, a de vrais utilisateurs, porte des années de décisions. Les écarts de maturité sont de la dette. | Choisissez un mode parmi les quatre ci-dessous. |
| Hybride | Un nouveau service prêt pour le Niveau 5 à l'intérieur d'une organisation dont les autres systèmes sont brownfield. Le nouveau service est greenfield; la frontière d'intégration avec le legacy est brownfield. | Évaluez le nouveau service comme greenfield. Pour chaque frontière legacy, choisissez un mode séparément. Version la plus courante : une nouvelle application IA-native qui lit ou écrit des données via une API legacy. |
Les quatre modes
Chaque mode est un chemin vers le Niveau 5 différent. La question n'est pas « quel mode l'équipe a la capacité d'assumer » : c'est une décision d'allocation de ressources en aval. La question est « quel mode est le chemin le plus court vers le Niveau 5 pour cette base de code, selon les données disponibles ». La taille de l'équipe, les priorités stratégiques et le coût d'opportunité sont des intrants qu'un humain pèse après avoir lu la recommandation; ils ne sont pas des intrants à la recommandation elle-même.
| Mode | Ce que « chemin vers le Niveau 5 » signifie |
|---|---|
| Remédier sur place | Le Niveau 5 arrive dans cette base de code via la construction progressive du harnais. |
| Strangler-fig | Le Niveau 5 arrive progressivement : les nouvelles parties sont construites Niveau 5-prêtes pendant que les anciennes se retirent. |
| Reconstruction complète | Le Niveau 5 arrive dans une nouvelle version de cette base de code; l'ancienne se retire à la bascule. |
| Isoler et contourner | Le Niveau 5 n'arrive pas dans cette base de code. Il arrive dans de nouvelles bases de code Niveau 5-prêtes à côté; celle-ci reste gelée. |
Mode 1 : remédier sur place
Gardez le code existant. Investissez dans le harnais : tests, types, conventions, intention documentée. Utilisez l'IA pour accélérer la remédiation elle-même via la méthodologie Recherche-Revue-Reconstruction décrite ci-dessous.
Quand c'est le bon choix : l'architecture est fondamentalement saine (le problème est le harnais, pas la structure); l'équipe a une expertise du domaine liée à la base de code actuelle; la continuité métier ne peut pas tolérer des systèmes parallèles.
Le risque : vous remédiez le harnais et le code reste fondamentalement au Niveau 3 parce que la structure vous combat. Vous avez dépensé six mois et vous ne pouvez toujours pas atteindre l'Échelon 5.
Mode 2 : migration strangler-fig
Construisez les nouvelles fonctionnalités Niveau 5-prêtes à côté de l'ancien système. Routez le trafic via une façade. Tuez les morceaux de l'ancien système un par un à mesure que les nouveaux font leurs preuves. Le Strangler Fig Pattern de Martin Fowler est la référence canonique.
Quand c'est le bon choix : le système existant a des coutures propres pour l'extraction; la continuité métier compte; le temps de reconstruction du système entier dépasserait la tolérance métier.
Le risque : l'identification des coutures est difficile. Si les coutures ne sont pas propres, vous vous retrouvez avec deux systèmes couplés au lieu d'un : deux fois la complexité, aucun des bénéfices.
Mode 3 : reconstruction complète
Repartez de zéro avec une base de code Niveau 5-prête. Faites tourner les deux systèmes en parallèle, migrez les données, basculez quand le nouveau système s'avère équivalent ou meilleur.
Quand c'est le bon choix : la structure existante empêche activement le travail dont vous avez besoin; le coût de la remédiation continue dépasse le coût de la reconstruction; l'économie de la reconstruction assistée par IA rend la reconstruction faisable dans un délai qui n'était pas viable avant; le domaine est bien compris (vous remplacez le comment, pas en train de redécouvrir le quoi).
Le risque : l'effet second système. Les reconstructions collectent chaque demande de fonctionnalité différée de l'ancien système et s'effondrent sous leur propre poids. Maintenez la discipline sur la portée.
Mode 4 : isoler et contourner
Gelez le legacy. Maintenez-le par des mains humaines au niveau que le métier exige encore. Construisez la nouvelle valeur sous forme de nouvelles applications Niveau 5-prêtes à côté, en routant via l'API ou la couche de données qui fonctionne déjà. N'essayez pas de moderniser le legacy lui-même.
Quand c'est le bon choix : le coût de remédiation dépasse la valeur résiduelle dans le legacy; la nouvelle valeur peut être livrée en parallèle sans intégration profonde; le legacy a une couture d'intégration viable (API, base de données, file) que les nouvelles applications peuvent utiliser; le métier tolère le mode maintenance pour une période prolongée.
Le risque : le legacy isolé accumule plus de dette avec le temps. Quelque chose force finalement la décision : un correctif de sécurité qui ne peut pas être appliqué, une fin de vie de plateforme, un modèle de données qui ne peut pas tenir les nouvelles exigences. Isoler et contourner achète du temps; ça ne résout pas le problème.
« Ne pas investir » est une issue légitime ici. Tous les systèmes legacy ne valent pas la peine d'être réparés. Le signal : vous êtes en train d'écrire votre troisième plan de remédiation pour le même module, les tests ajoutés le trimestre dernier ne sont plus verts, et le métier livre encore de la valeur via ce code. Ce n'est pas une base de code qui attend d'être modernisée. C'est une base de code qui attend d'être remplacée.
Critères de décision
| Question | Remédier | Strangler | Reconstruire | Isoler |
|---|---|---|---|---|
| L'architecture est-elle fondamentalement saine ? | Oui | Surtout | Non | Peu importe |
| Y a-t-il des coutures propres pour l'extraction ? | Sans objet | Oui | Sans objet | Au moins un point d'intégration utilisable |
| L'équipe peut-elle décrire l'intention du système ? | Oui | Oui | Oui (ou utiliser Boîte noire à plan) | Pas requis pour le legacy |
| Le métier tolère-t-il des systèmes parallèles ? | Sans objet | Oui | Oui | Oui |
| Continuer à payer la dette est-il moins cher que la remplacement ? | Oui | Partiellement | Non | Oui, pendant que la nouvelle valeur se livre à côté |
| Le legacy a-t-il une valeur résiduelle à préserver ? | Oui | Oui | Oui | Oui, mais ne vaut pas la peine d'être réparé |
| Avez-vous la capacité d'équipe pour l'option plus difficile ? | La plus faible | Moyenne | La plus élevée | Faible (le legacy reste gelé) |
Pas de oui clair sur la ligne reconstruire ? Ne reconstruisez pas. L'effet second système punit les équipes qui ont choisi la reconstruction pour des raisons autres que la pertinence.
Plusieurs « non » sur Remédier/Strangler/Reconstruire, mais le legacy a encore de la valeur métier ? Isoler et contourner est probablement le bon mode.
Le Quadrant de la dette technique affine la décision de reconstruction :
| Type de dette | Cause | Remédiation |
|---|---|---|
| Prudente, délibérée | On a livré en sachant le raccourci. | Généralement remédiable. |
| Prudente, involontaire | On a appris mieux plus tard. | Remédiable, mais vérifiez si l'apprentissage a invalidé des décisions structurelles. |
| Imprudente, délibérée | On savait mieux, on l'a fait quand même. | Souvent remédiable avec de la discipline, mais signale des problèmes de processus qui survivent à la base de code. |
| Imprudente, involontaire | On ne savait pas ce qu'on faisait. | Candidate à la reconstruction. La structure reflète une ignorance que la connaissance ultérieure ne peut pas défaire sur place. |
Besoin d'aide pour choisir le bon mode ? La compétence Claude Code codebase-readiness évalue une base de code selon le modèle de maturité à neuf dimensions et recommande un chemin vers le Niveau 5, y compris lequel des quatre modes s'applique.
La méthodologie : recherche, revue, reconstruction
Publiée par Fowler et EPAM sous le nom Research, Review, Rebuild, c'est la méthodologie brownfield la plus concrète disponible. Elle s'applique directement aux Modes 1 à 3; dans le Mode 4, elle s'applique à la couture d'intégration même si le legacy reste gelé. Le déploiement direct d'agents dans une base de code legacy opaque produit de façon fiable des sorties confidemment erronées. La structure à phases permet d'éviter cela.
Phase 1 : recherche. L'IA analyse le code existant : reconstruit l'intention, extrait les contrats comportementaux, identifie les patrons, documente le graphe de dépendances. Des outils comme les connecteurs MCP permettent aux agents de traverser systématiquement la base de code. Sortie : une carte d'intention : ce que le système fait, indépendamment de la façon dont il est structuré.
Phase 2 : revue. Les experts du domaine valident la carte d'intention. L'IA peut extraire ce que le code fait. Seuls les humains peuvent distinguer le comportement intentionnel de l'accident historique. C'est le goulot d'étranglement du débit : dans l'étude de cas Bahmni (AngularJS vers React), la revue humaine prenait environ 20 minutes par composant. Planifiez la capacité pour la revue, pas seulement pour la génération.
Phase 3 : reconstruction. Avec une intention validée, l'IA génère le code de remplacement avec une ambiguïté minimale. Sur Bahmni : environ 2 $ par composant en moins d'une heure, contre 3 à 6 jours manuellement. L'économie est convaincante quand les Phases 1 et 2 sont disciplinées, et pire que le traditionnel quand elles sont sautées.
L'ordre est structurant. Les équipes qui sautent la recherche et la revue pour atteindre la reconstruction plus vite ne gagnent pas de temps; elles produisent des sorties erronées plus vite et dépensent le temps économisé à déboguer un comportement halluciné.
L'économie : ce que les chiffres impliquent
Le point de données Bahmni réorganise le calcul : ce qui était une migration de 18 mois devient une migration de 6 mois, où la contrainte est la capacité des réviseurs, pas les heures d'ingénierie. Vos résultats varieront selon l'architecture, la couverture de tests et la complexité du domaine, et l'économie ne fonctionne que quand Recherche et Revue sont disciplinées. Les sauter effondre l'accélération.
Boîte noire à plan : rétro-ingénierie de l'intention
Quand l'équipe originale est partie, la documentation est fausse, et le code est la seule source de vérité, la Phase 1 devient un problème de rétro-ingénierie. La Boîte noire à plan de Fowler décrit cinq techniques :
- Reconstruction par la couche UI : déduire le comportement depuis l'interface utilisateur et ses transitions d'état.
- Capture des données de changement : observer comment le système modifie les données en production pour déduire la logique métier.
- Inférence de la logique serveur : analyser les frontières API et les patrons requête/réponse pour reconstruire la logique derrière.
- Archéologie binaire : reconstruire depuis les binaires, les logs et les interfaces externes quand le code source est perdu.
- Enrichissement multi-passes progressif : décomposer les artefacts en morceaux gérables, extraire des connaissances partielles par passe, construire le contexte de façon incrémentale. L'analyse globale en un seul passage échoue à l'échelle.
Deux disciplines sont non négociables : la triangulation (chaque hypothèse sur l'intention confirmée par deux sources indépendantes : UI + logs, API + base de données, code + comportement observé) et le suivi de la lignée (pour chaque affirmation, consignez l'évidence sur laquelle elle repose, pour que les évidences peu fiables soient identifiables plus tard).
Spec-depuis-le-code : l'inversion brownfield
Les Standards d'exécution IA et le Guide de spécification supposent que les spécifications précèdent le code. Le brownfield inverse cela : le code existe déjà, et la spécification doit être rétro-ingéniérée à partir de lui. C'est un flux de travail différent.
Les outils de développement piloté par spécification comme spec-kit, Kiro et Tessl sont principalement orientés greenfield. Le « Brownfield Bootstrap » de spec-kit est l'exception : découvrir automatiquement l'architecture existante pour établir une Constitution (principes directeurs persistants), puis appliquer le développement piloté par spécification aux nouvelles fonctionnalités seulement pendant que Recherche et Revue rattrapent la surface legacy.
Le patron qui fonctionne :
- Extrayez la spécification implicite. Que fait réellement le système ? Voir la séquence brownfield du Lab IA pour la version disciplinée.
- Écrivez des scénarios de bout en bout qui décrivent le comportement actuel attendu à partir de la spec extraite.
- Vérifiez que les scénarios passent sur le code existant. Ça devient votre harnais de régression.
- Appliquez la spécification-d'abord à tout nouveau travail. Sans exception.
- Migrez par migration strangler, composant par composant, en utilisant les scénarios comme protection pendant la migration.
La première étape est le travail humain le plus difficile de la transition. Les agents peuvent documenter ce que le système fait; seuls les humains peuvent répondre si c'est ce qu'il devrait faire.
Pièges courants
Sous-estimer le goulot d'étranglement de la revue humaine. Les coûts de génération IA ont chuté de plusieurs ordres de grandeur. Les coûts de revue humaine, non. Planifiez la capacité des réviseurs comme une contrainte de premier plan, pas une réflexion après coup.
Lab brownfield à moitié. Faire tourner une partie du projet en mode IA-natif et l'autre en mode traditionnel parce que « cette partie-là va plus vite à l'ancienne » ne produit aucun des bénéfices. La liste des pièges du Lab IA nomme cela spécifiquement.
Traiter les coutures comme acquises quand elles sont implicites. La migration strangler-fig se lit bien sur les tableaux blancs. En pratique, des « coutures propres » désignent des endroits où les responsabilités peuvent être extraites sans couplage à huit autres modules. Si ce n'est pas vrai de votre base de code, la migration strangler-fig devient une reconstruction complète avec des étapes supplémentaires.
Confondre coût de modernisation et coût de remplacement. La décision « remédier vs reconstruire » ne porte pas sur le fait que la réparation coûte de l'argent : les deux coûtent de l'argent. Elle porte sur le fait que la structure peut tenir ce dont vous avez besoin. La dette imprudente-involontaire ne peut pas être défaite sur place, peu importe le budget.
Panorama des outils (instantané)
Le cadre ne recommande pas d'outils spécifiques; le paysage évolue trop vite. Mais il vaut la peine de connaître : le développement piloté par spécification (spec-kit, Kiro, Tessl; voir la comparaison de Fowler); les connecteurs MCP pour la traversée systématique de bases de code; les plateformes d'agents (Claude Code, Cursor, Aider, Devin) avec différents compromis autonomie/humain-dans-la-boucle; les benchmarks (SWE-bench, IDE-Bench), mais les scores sur des problèmes sélectionnés ne prédisent pas les performances brownfield sur votre code.
Miroir : stratégie et non-fiabilité
L'ingénierie de la fiabilité traite de la construction de systèmes fiables à partir de sorties IA non fiables. La stratégie brownfield traite de rendre les agents IA efficaces sur des bases de code non fiables. Les deux convergent vers le harnais : capteurs rapides, intention documentée, validation au niveau des scénarios. Une migration brownfield qui ne se termine pas avec la base de code au Niveau 5 et qui ne correspond pas à la discipline de non-fiabilité a réussi en forme mais pas en substance.
En lien
- Maturité du code : le diagnostic dont cette page dépend
- Le Lab IA : le mode de travail de l'Échelon 5 une fois que vous y arrivez
- L'ingénierie de la fiabilité : le problème miroir
- Standards d'exécution IA et Guide de spécification : l'ingénierie de spécification
- Pratiques héritées : les patrons humains qui accompagnent souvent le code legacy
Sources
- Fowler, M. (2026). « Harness Engineering for Coding Agent Users. » martinfowler.com
- Fowler, M. (2026). « From Black Box to Blueprint: Reverse-Engineering Legacy Systems with AI. » martinfowler.com
- Fowler, M. & EPAM. (2026). « Research, Review, Rebuild: AI-Assisted Legacy Modernization. » martinfowler.com
- Fowler, M. (2024). « Rewriting the Strangler Fig Application. » martinfowler.com
- Fowler, M. « Strangler Fig Application. » martinfowler.com
- Fowler, M. « Technical Debt Quadrant. » martinfowler.com
- Fowler, M. (2026). « Spec-Driven Development: The Three Tools. » martinfowler.com
- GitHub. « Spec Kit. » github.com/github/spec-kit
- Duvall, P. (2026). « AI Development Patterns. » github.com/PaulDuvall/ai-development-patterns
- Feathers, M. (2004). Working Effectively with Legacy Code. Addison-Wesley.
- « Artificial Intelligence for Software Architecture: A Literature Review. » (2025). arXiv. arxiv.org/abs/2504.04334
- « IDE-Bench: Evaluating LLM Agents on Real Codebases. » (2026). arXiv. arxiv.org/abs/2601.20886
- SWE-bench. swebench.com
← Retour à l'accueil · Maturité du code · Le Lab IA · L'ingénierie de la fiabilité · Glossaire