Un projet greenfield part de zéro ; un projet brownfield se construit sur un logiciel qui existe déjà, avec son historique et des règles métier que personne n'a jamais écrites. Les agents IA de code ne se comportent pas du tout pareil sur l'un et sur l'autre, et ça se voit jusque dans la façon de composer une équipe. On fait le point sur ce qui les distingue et sur ce que ça change pour l'organisation, chiffres à l'appui.
Tapez "greenfield vs brownfield" dans Google, et vous tomberez surtout sur des terrains à bâtir et des migrations SAP. Le développement logiciel arrive loin derrière, ce qui est un peu ironique pour deux mots que les équipes tech emploient tous les jours (rassurez-vous, ici, on parle bien de code). Et les agents IA les ont rendus beaucoup plus concrets : un agent qui arrive sur un dépôt vide et un agent qui arrive sur dix ans de code ne font pas du tout le même boulot.
Au sommaire
- Greenfield et brownfield : quelle différence en développement logiciel ?
- Pourquoi les agents IA vont-ils plus vite sur un projet greenfield ?
- En brownfield, que ne voit pas l'agent ?
- Pourquoi un projet greenfield devient-il vite un brownfield avec des agents ?
- Qu'est-ce que le terrain change à l'organisation de l'équipe ?
- FAQ
Greenfield et brownfield : quelle différence en développement logiciel ?
En développement logiciel, un projet greenfield démarre sur une page blanche, sans code existant ni utilisateurs à ménager : tous les choix techniques restent ouverts. Un projet brownfield fait évoluer un logiciel déjà en production, qu'il faut continuer à faire tourner pendant qu'on le transforme.
Les deux mots viennent de l'urbanisme. Un greenfield, c'est un terrain vierge, un champ où personne n'a encore construit. Un brownfield, c'est une friche industrielle sur laquelle on reconstruit avec ce qui reste (y compris, parfois, ce qui pollue le sol). L'image colle plutôt bien au logiciel : sur une friche comme dans un vieux dépôt, c'est en creusant qu'on découvre ce que les plans ne montraient pas.
Qu'est-ce qu'un projet greenfield ?
C'est un nouveau produit ou un outil interne qu'on construit de zéro. L'équipe choisit sa stack et ses conventions, et elle connaît forcément les contraintes du projet, puisqu'elle vient de les poser. C'est le terrain où un Product Builder, qui cadre le besoin et livre avec des agents, peut aller le plus loin seul. Le revers, c'est que tout reste à construire, y compris ce qu'un produit existant a déjà : des utilisateurs et des données.
Qu'est-ce qu'un projet brownfield ?
C'est le quotidien de la plupart des équipes : ajouter une fonctionnalité à un produit en production, ou migrer une vieille application vers une stack actuelle. Le code tourne déjà, sauf qu'une partie des règles qui le gouvernent n'est écrite nulle part. Pas besoin d'attendre dix ans, d'ailleurs : un produit lancé il y a deux ans est déjà un brownfield dès qu'on travaille dessus.
| Greenfield | Brownfield | |
|---|---|---|
| Point de départ | Un dépôt vide | Un logiciel en production |
| Contraintes | Celles que l'équipe pose | Celles de l'existant, écrites ou non |
| Ce que l'agent trouve dans le dépôt | L'essentiel du contexte | Une partie seulement des règles |
| Risque principal | Construire vite quelque chose qui ne tiendra pas | Casser ce qui marche sans le voir |
| Ce qui guide les décisions | La vision produit et les choix d'architecture | L'existant, ses utilisateurs et ses dépendances |
| Exemple | Un outil interne monté en quelques jours | La refonte du backoffice d'un produit de dix ans |
Pourquoi les agents IA vont-ils plus vite sur un projet greenfield ?
Sur un projet greenfield, presque tout ce qu'un agent doit savoir se trouve dans le dépôt qu'il lit, et il n'a aucune règle décidée avant lui à deviner. C'est ce qui le rend nettement plus efficace qu'en brownfield, surtout sur des tâches simples.
Les chiffres qui circulent le plus viennent de Yegor Denisov-Blanch, chercheur à Stanford, qui a présenté en conférence une étude sur près de 100 000 développeurs dans plus de 600 entreprises. Sa matrice simplifiée, construite sur 136 équipes de 27 entreprises, croise la maturité du code et la complexité des tâches. En greenfield, l'IA ferait gagner de 30 à 40 % de productivité sur les tâches simples, et de 10 à 15 % sur les complexes. En brownfield, on tombe à 15 à 20 % sur les tâches simples et à 0 à 10 % sur les complexes… avec, parfois, une productivité qui baisse carrément. Autant dire que sur le ticket costaud d'un produit qui a dix ans, celui qu'on repousse de sprint en sprint, l'agent ne fait pas de miracle.
On prend ces chiffres pour ce qu'ils sont, des ordres de grandeur : ils ont été présentés en conférence, sans que le modèle de mesure y soit détaillé. L'étude relève aussi que les gains baissent quand la codebase grossit, ce qui se comprend, puisque l'agent ne peut pas tout embrasser d'un coup.
Un écart qui pourrait se réduire
Chez nous, Olivier Bergeret, notre CTO IA, ne lit pas ces résultats comme une condamnation du brownfield. Dans son décryptage de l'AI-DLC d'AWS, il reconnaît qu'on aurait vite fait d'en conclure que les agents ne servent qu'en greenfield, avant d'expliquer qu'il voit autre chose chez ses clients. Avec les progrès des harnais et du spec-driven development, entre autres, il s'attend à un impact majeur sur le brownfield, au point que le legacy pourrait devenir le terrain des plus gros gains. Plutôt une bonne nouvelle, vu le temps que la plupart des équipes passent sur de l'existant !
En brownfield, que ne voit pas l'agent ?
En brownfield, l'agent ne voit que ce qui est écrit. Un comportement dont dépend un autre service, ou une exception que seule l'équipe historique connaît, n'apparaît nulle part dans le code, et l'agent peut livrer un changement parfaitement propre qui les casse sans le savoir.
Ces règles-là, c'est le genre qu'on découvre le lendemain d'une mise en prod. Tout le boulot, c'est de les rendre visibles avant de lancer l'agent, puis de vérifier qu'il ne les a pas cassées. On a détaillé la méthode (zones de risque, tests de caractérisation, migration par morceaux complets) dans notre guide pour faire travailler des agents sur du code legacy. C'est aussi pour ça que le brownfield démarre plus lentement : avant le premier gain, il faut passer du temps à écrire et à vérifier, ce que le greenfield vous épargne. Une fois ce cadre posé, un Product Builder peut tout à fait travailler sur un brownfield, et chez nous, on est convaincus que ça marche très bien.
Pourquoi un projet greenfield devient-il vite un brownfield avec des agents ?
Parce qu'un agent écrit du code beaucoup plus vite qu'une équipe ne le relit. Au bout d'un moment, une bonne partie du dépôt a été produite sans que personne prenne chaque décision, et l'équipe se retrouve à travailler sur un code qu'elle connaît mal : c'est déjà une forme de brownfield.
Vu la vitesse à laquelle les agents produisent, on comprend que certains aillent plus loin. Addy Osmani le relève dans son texte sur le brownfield agentic engineering, publié en septembre : pour certains, on est en brownfield dès qu'un agent livre du code qu'on n'a pas écrit décision par décision. D'autres font même du code généré dont on hérite un troisième cas, à part du greenfield comme du vrai legacy, avec sa propre façon de le reprendre.
Le terrain vierge ne le reste donc pas longtemps, surtout quand on y lâche plusieurs agents en parallèle. Son avantage dure tant que l'équipe garde la main sur ce qu'ils produisent, d'où l'intérêt de poser dès le premier jour le harnais des agents : des règles écrites pour l'agent et des tests qu'il doit passer avant qu'on relise son travail. Sans ce harnais, la vitesse du début se paie plus tard en dette technique, avec un code qui marche mais que personne n'a vraiment choisi… et qu'il faudra bien reprendre un jour.
Qu'est-ce que le terrain change à l'organisation de l'équipe ?
Le terrain décide en grande partie du dispositif. Sur un projet greenfield peu critique, un Product Builder seul avec des agents peut livrer. Sur un brownfield critique, il faut garder des développeurs et une relecture plus serrée, parce que le risque principal est de casser ce qui marche.
Pierre Sur, un de nos Product Builders, décrit les deux cas dans son retour de mission. Pour un outil interne qui génère des données de démo pour les équipes commerciales (greenfield, non critique), un Product Builder seul a livré en quelques jours une application montée avec Supabase et N8N. Le backoffice d'une scale-up de la MedTech, lui, c'est un code de dix ans où la fiabilité passe avant la vitesse, et le dispositif y réunissait un PM et deux développeurs qui travaillent avec des agents. Moins de développeurs qu'avant, donc… mais des développeurs quand même !
Pour trancher, deux questions aident bien. La première, c'est la criticité : qu'est-ce que ça coûte si l'agent casse quelque chose ? La seconde, c'est le contexte : qui connaît les règles que le code ne dit pas ? En brownfield, ces gens-là deviennent les plus précieux de l'équipe, parce que ce sont eux qui écrivent pour l'agent ce qu'il ne peut pas deviner, et eux qui repèrent ce qu'il a cassé. Plus le terrain est ancien et critique, plus il vaut mieux décider tôt qui relit quoi.
Votre organisation est-elle prête à travailler avec des agents ? Avec le Product Operating Model AI, Thiga vous aide à structurer vos équipes produit et tech autour des agents, de la composition des équipes à la gouvernance.
FAQ
Que signifie greenfield en français ?
Littéralement, « champ vert ». En urbanisme, le mot désigne un terrain vierge, jamais construit, et en logiciel, par extension, un projet qui démarre de zéro. Son pendant, brownfield, désigne une friche industrielle et, en logiciel, un projet qui part d'un système existant. En français, on garde le plus souvent les termes anglais.
Qu'est-ce que le bluefield ?
C'est une approche hybride entre greenfield et brownfield, surtout employée pour les migrations SAP. Au lieu de tout migrer ou de tout refaire, on choisit ce qu'on reprend de l'ancien système et ce qu'on reconstruit.
Les agents IA sont-ils réservés aux projets greenfield ?
Non. Les gains mesurés sont plus faibles en brownfield, surtout sur les tâches complexes, mais les agents y servent dès qu'on leur donne le contexte qui leur manque et des tests qui vérifient leur travail. Olivier Bergeret, notre CTO IA, s'attend même à ce que les plus gros gains viennent du legacy.
Faut-il réécrire un code legacy de zéro avec des agents ?
Rarement d'un seul coup. Pour limiter le risque, on fige le comportement actuel par des tests de caractérisation, puis on migre par morceaux complets, en vérifiant chaque étape avant de passer à la suivante.
Vos développeurs travaillent déjà avec des agents ? Avec la formation Product Builder for Engineers, Thiga Academy leur apprend à adopter un état d'esprit Produit, pour cadrer et prioriser avant de coder.
