Ouvre n’importe quelle démo d’assistant de code. Le type tape une phrase, et une appli de todo apparaît, scaffold compris, base de données incluse, endpoint de santé offert. Tout propre, tout neuf, zéro fichier hérité, zéro client à ne pas casser.
Maintenant regarde ton dépôt réel. Huit ans de commits, un module de facturation que deux clients paient encore, trois contournements que plus personne n’ose toucher, et une convention de nommage absurde que toute l’équipe respecte religieusement parce qu’elle porte du poids.
Le texte publié ce mardi sur le sujet donne un nom à ce décalage : le biais greenfield. L’hypothèse silencieuse, planquée sous presque tous les outils de code IA, que tu pars d’une page blanche. Sauf que la page blanche n’est pas un détail du décor, c’est l’environnement pour lequel ces outils sont implicitement dessinés, parce que c’est là qu’ils ont l’air bons.
Le décalage apparaît dès qu’on passe au travail réel. Construire du neuf et modifier de l’existant sont deux activités parentes, mais différentes, et la différence est précisément la partie qui rend le travail réel difficile.
La contrainte change de camp
Sur un projet neuf, tu définis les contraintes. Pas d’héritage à respecter, pas de contrat existant à honorer, pas d’utilisateur qui compte sur le comportement actuel. L’agent choisit l’approche la plus propre possible puisque rien ne gêne. C’est le terrain de jeu de la génération, et c’est aussi celui de la démo, ce qui explique pourquoi la falaise démo-vers-prod et le biais greenfield sont les deux faces de la même pièce.
Sur un système existant, ce sont les contraintes qui te définissent. L’approche la plus élégante dans l’absolu est souvent indisponible, parce que quelque chose dépend de la forme actuelle. Il faut coller à l’architecture en place, pas à celle que tu dessinerais à main levée, préserver des comportements dont les utilisateurs dépendent, éviter de péter des contrats que d’autres bouts de code supposent, et respecter des conventions qui tiennent debout même quand elles ont l’air fausses.
Un outil calibré pour la page blanche et lâché sur une base existante ne sous-performe pas gentiment. Il produit une catégorie d’erreurs confiantes, toutes issues de la même liberté qu’il s’autorise et que le dépôt ne lui donne pas.
Il propose de réécrire là où il faudrait éditer. Face à du code qui n’est pas écrit comme lui l’aurait fait, l’agent formaté greenfield sort le bulldozer : « on remplace par un truc propre ». Le geste sûr, c’est la modification minimale qui s’insère dans l’existant. La réécriture est plus jolie et beaucoup plus risquée, parce qu’elle jette des contraintes encodées dans le vieux code que personne n’a jamais pris la peine d’écrire noir sur blanc.
Il ignore la portée d’un changement. Sur une page blanche, rien ne dépend encore de rien, donc le rayon d’impact n’existe pas comme concept. Sur un système vivant, chaque modification a une portée, et un outil qui ne raisonne pas sur ce qu’elle va toucher casse tranquillement des choses qu’il n’a jamais regardées.
Il impose ses conventions au lieu d’apprendre celles du dépôt. La cohérence avec le système existant vaut presque toujours mieux que la conformité à un idéal générique. Un agent qui se bat contre le style de la maison génère de la friction à chaque commit.
Il traite les trous comme un problème à contourner, pas comme un problème à combler. L’absence de tests, l’absence de structure, ça arrive partout dans le vrai code. La réponse honnête consiste parfois à consolider le sol avant de construire dessus, plutôt qu’à générer avec aplomb sur du sable.
Des modèles plus gros n’y changeront rien
Le réflexe évident, c’est de se dire que ce biais va s’estomper à mesure que les modèles progressent. Il ne s’estompera pas tout seul, parce que ce n’est pas d’abord une question de capacité. C’est une orientation de conception. Un outil fabriqué pour impressionner sur une page blanche optimise la génération fluide. Un outil fabriqué pour les produits réels optimise le respect des contraintes, la compréhension de la portée, l’insertion dans l’existant. Ce sont deux choses à construire, pas deux niveaux du même réglage.
La partie qui gratte, c’est que le marché récompense l’inverse. La démo clean slate sert un marché qui existe à peine : les équipes qui ont du budget et de vraies factures au bout bossent sur des systèmes qui tournent déjà. Le produit parfait pour changer de l’existant, c’est celui qui sert le boulot réel. Et c’est aussi le plus dur, donc le moins démonstratif. Un agent qui refuse une approche, qui propose une modif timide et qui avance lentement fera toujours moins de vues qu’un qui sort une appli de zéro en trente secondes. Le vibe coding a beau avoir tenu sa première appli payante, il reste un sport de terrain vague.
La source du texte mérite d’être lue avec un œil plissé : elle renvoie vers un guide pour rendre son dépôt « prêt pour un agent », donc elle vend quelque chose dans la foulée de son diagnostic. Ça n’invalide pas le constat, ça en précise juste l’émetteur.
Reste l’aveu le plus intéressant du billet, celui qui évite de se poser en solution miracle. Être pensé pour l’existant ne rend pas un dépôt facile, ça empêche juste l’outil de faire comme si le dépôt n’était pas là. Et surtout, aucune orientation ne comble le trou des contraintes implicites : les hypothèses jamais documentées restent un risque sur les vrais systèmes, précisément là où les enjeux sont les plus gros. D’où la présence humaine là où ça coûte cher, pas par principe moral mais par lucidité technique.
Pendant ce temps, l’autre moitié du marché continue de vendre la page blanche à la découpe : une page produit propose 80 retouches d’images par IA pour 9,90 dollars, crédits qui n’expirent jamais. Personne n’a jamais eu besoin de comprendre un dépôt de huit ans pour faire ça, c’est bien pour ça que ça se vend tout seul.
Le code propre qui fait la mauvaise chose, c’est juste un bug bien indenté.
Sources :
Comments are closed