Pourquoi la remédiation ne passe pas à l'échelle

Voici une scène qui se joue en ce moment dans beaucoup d’entreprises. Une équipe lance un pilote agentique. Ça se passe bien, le volume est réel, la démo convainc, la note de synthèse s’écrit toute seule. Puis quelqu’un pointe l’outillage d’analyse statique et d’architecture existant sur la production, et il remonte trois cent quarante constats.

Ce qui se passe ensuite est tout l’argument. Pas les constats. Ce qui se passe ensuite.

IL’ancienne boucle était chirurgicale

Pendant cinquante ans, la correction logicielle a fonctionné d’une seule façon. Quelqu’un écrivait du code. Quelqu’un d’autre, ou un outil, trouvait un problème. Une personne qui comprenait le code faisait une modification petite et ciblée, et le reste du système restait exactement où il était.

Cette dernière partie est celle qui porte, et elle était si fiable que personne ne l’a nommée. La correction était locale. Corriger une chose ne déplaçait pas les autres. Vous pouviez donc dérouler la boucle autant de fois que nécessaire en étant certain que chaque passe vous rapprochait du correct. Le nombre de défauts baissait et restait bas. Tout l’appareil de revue de code, de QA et de backlogs de remédiation présuppose cette propriété.

Il présuppose, autrement dit, que corriger converge.

IILa nouvelle boucle n’est pas une boucle

Quand un agent produit un bloc de quarante mille lignes, la personne qui le relit ne l’a pas écrit. Souvent personne ne l’a écrit, en aucun sens significatif, il n’y a pas d’auteur à consulter sur l’intention, parce que l’intention vivait dans un prompt et une fenêtre de contexte qui n’existent plus.

La correction naturelle n’est donc pas d’éditer. C’est de relancer. Ajuster l’instruction, régénérer, revérifier. Toutes les équipes qui font cela arrivent au même réflexe en deux semaines environ, et cela paraît efficace, parce que c’est bien plus rapide que de lire quarante mille lignes.

La correction a cessé d’être une édition pour devenir une refabrication. Ce seul changement casse l’hypothèse dont tout le reste dépend.

La régénération n’est pas idempotente. Même spécification, même modèle, même température, sortie différente. Pas radicalement différente, en général. Suffisamment différente. Les structures bougent. Les noms changent. Une fonction utilitaire dont trois autres blocs dépendaient se retrouve inlinée. Le correctif atterrit, et le voisinage autour se déplace.

IIIPourquoi cela cesse de converger

Voyez-le comme une propriété simple plutôt que comme une métaphore. Chaque cycle de régénération a une certaine probabilité de résoudre la violation ciblée, et une certaine probabilité d’introduire des violations que vous n’aviez pas. Tant que le second nombre est significativement supérieur à zéro, et tant que le volume de code régénéré croît avec le volume produit, la boucle ne descend pas la pente. Elle oscille.

Vous pouvez la dérouler indéfiniment et rester à peu près là où vous avez commencé, une population stable de violations dont la composition ne cesse de changer. Chaque cycle produit un rapport montrant des progrès sur les constats précis que vous aviez ciblés, et chaque cycle réensemence discrètement le vivier.

C’est pourquoi les équipes décrivent toutes la même expérience : le tableau de bord s’améliore, le patrimoine non. Les outils de détection sont excellents pour vous dire où vous êtes. Ils sont structurellement incapables de vous dire si vous vous rapprochez, parce qu’ils mesurent l’artefact, pas la trajectoire.

IVLe symptôme est déjà mesurable

Il existe une signature empirique précoce de ce phénomène. Dans une étude portant sur trois cents projets open source, dont cinquante partiellement ou entièrement générés par IA, l’anti-pattern le plus constant n’était ni une faille de sécurité ni un problème de performance. C’était l’évitement des refactorisations, présent dans la grande majorité des bases de code générées par IA.

Les machines ajoutent. Elles restructurent très rarement. Quand on lui demande de corriger quelque chose, un modèle produira de façon fiable du code neuf qui traite le cas, plutôt que de réorganiser le code existant pour que le cas ne puisse pas survenir. Chaque correction est additive. Ce qui signifie que sous un régime de correction-par-régénération, le patrimoine ne devient pas plus simple à mesure qu’il devient plus correct. Il devient plus vaste et d’apparence plus correcte, ce qui est une situation considérablement pire.

La même étude a relevé des taux élevés de sur-spécification, logique défensive et dupliquée écrite pour satisfaire une instruction plutôt qu’une architecture, et de défauts récurrents, la même classe de bug réapparaissant de génération en génération parce que rien dans le système ne se souvient qu’elle avait déjà été résolue.

VLe « shift left » n’est pas la réponse qu’on croit

La réponse habituelle à tout cela est de déplacer la détection plus tôt. Lancer le scanner dans l’IDE. Le lancer à chaque commit. Le lancer dans la boucle interne de l’agent lui-même.

Cela vaut la peine d’être fait et ne résout pas le problème, parce que cela change quand vous détectez sans changer ce qui se passe après la détection. Si la réponse à un constat reste la régénération, un constat plus précoce ne fait qu’avancer un cycle non convergent. Vous avez augmenté la fréquence de l’oscillation. La population reste stable.

Le shift left est un changement d’ordonnancement. Ce qu’il faut est un changement de catégorie.

VILes contraintes doivent être des entrées, pas des critères

L’alternative n’est pas une détection plus sophistiquée. C’est de faire de l’architecture une entrée de production, quelque chose à l’intérieur de quoi la machine est maintenue pendant qu’elle travaille, plutôt que quelque chose à quoi un vérificateur compare la sortie après coup.

Concrètement, cela signifie que l’unité de production est bornée avant que quoi que ce soit ne soit généré : quel module, quelles interfaces, quels patterns, quelles décisions antérieures s’appliquent et lesquelles sont explicitement hors périmètre. Le générateur n’a pas la possibilité d’atteindre au-delà de cette frontière, donc la classe de violation que vous seriez sinon en train de remédier ne peut pas être exprimée. Vous ne l’attrapez pas. Vous la rendez inexprimable.

On ne peut pas inspecter son chemin jusqu’à une architecture. On ne peut que produire à l’intérieur d’une architecture.

Ce n’est pas une idée neuve dans l’industrie manufacturière, d’où vient le vocabulaire. Aucune ligne de production sérieuse n’atteint sa tolérance en mesurant les pièces finies et en refaisant celles qui la manquent. Elle l’atteint en contraignant la machine, puis mesure pour confirmer que la contrainte a tenu et pour détecter quand elle cesse de tenir. L’inspection est la façon dont on apprend que le procédé a dérivé. Elle n’a jamais été le mécanisme de la qualité.

VIICe qui en découle

Il existe un effet de second ordre qui mérite d’être nommé, parce que c’est la partie que la plupart des équipes n’anticipent pas.

Si vous contraignez au point de production, vous savez nécessairement, à cet instant, sans travail supplémentaire, quelle exigence a causé ce bloc, quelle décision l’a façonné, à quelles contraintes il a été tenu, ce qui a été vérifié et qui l’a accepté. La traçabilité est un sous-produit de cette façon de produire. Elle ne coûte rien de plus.

Si vous inspectez à la place, rien de tout cela n’existe. Il faut le reconstituer plus tard, à la main, généralement par la personne la moins heureuse de l’organisation, généralement dans les quatre semaines qui précèdent un audit, et généralement à un niveau dont tout le monde sait en privé qu’il relève du récit de bonne foi plutôt que du dossier.

C’est pourquoi les équipes qui réussissent le contrôle de production cessent de traiter la conformité comme un projet. La réponse existe déjà avant que quiconque ne pose la question.

VIIICe que nous ne disons pas

Ceci n’est pas un argument contre l’analyse statique, les scanners, les outils de politique ou la revue de code. Tous restent nécessaires. Les contraintes échouent. Les enveloppes sont mal spécifiées. Les modèles trouvent des cas limites que personne n’avait anticipés. Vous avez besoin de la détection précisément parce que la prévention n’est jamais totale, c’est à cela que sert la détection.

L’argument est plus étroit et, nous le pensons, plus difficile à écarter : la détection ne peut pas être le contrôle principal au volume machine. C’était un contrôle principal adéquat quand la correction était chirurgicale, parce que la boucle convergeait. Cela cesse de l’être au moment où la correction devient une régénération. Gardez les scanners. Cessez de leur demander un travail dont l’économie ne fonctionne plus.

IXLa question qui mérite d’être posée

Si vous évaluez en ce moment une capacité de livraison agentique, celle d’un fournisseur, ou celle de votre propre équipe, la question habituelle porte sur les taux de réussite. Quel pourcentage du code généré passe la revue, franchit le référentiel, ou part en production sans intervention.

C’est la mauvaise question, parce qu’elle mesure le bon cas. Interrogez plutôt le mauvais :

• Quand une violation est trouvée, que se passe-t-il réellement, une édition, ou une régénération ?
• Si c’est une régénération, qu’est-ce qui empêche la deuxième tentative de casser ce que la première avait réussi ?
• Combien de cycles faut-il pour clore un constat typique, et ce nombre baisse-t-il ?
• Dans six mois, le patrimoine sera-t-il plus petit et mieux compris, ou plus vaste et mieux documenté ?

Une capacité qui sait répondre à cela fait du contrôle de production. Une capacité qui ne sait que citer un taux de réussite fait de l’inspection, et découvrira la différence vers le dix-huitième mois, c’est-à-dire, d’après les organisations qui y sont déjà passées, à peu près au moment où l’on cesse de dire que l’IA accélère le développement pour commencer à dire qu’on ne peut plus livrer de fonctionnalités parce qu’on ne comprend plus ses propres systèmes.