« Les tests passent » : pourquoi l'IA exécute (et ne se contente pas d'assister)

Un agent vient de terminer sa tâche. Il a touché une dizaine de fichiers, ajusté une migration de base de données, modifié deux endpoints. Et il conclut, posément : « Les tests passent, la migration est validée, c'est prêt à partir. » Tout le monde respire. La PR est ouverte, la revue expédiée, le déploiement programmé.

Personne n'a vu la sortie d'exécution des tests. Personne ne sait si la migration a réellement tourné sur autre chose qu'une base vide. Ce que l'équipe a sous les yeux, ce n'est pas une preuve : c'est une déclaration. Un claim. Et un claim, c'est exactement ce qu'un agent produit le plus facilement — bien plus facilement qu'une preuve.

Tant qu'un humain relisait chaque ligne et relançait lui-même la suite de tests, le décalage entre ce qu'un agent affirme et ce qu'il a réellement fait restait absorbable : il y avait toujours une paire d'yeux à la fin de la chaîne. Mais à mesure que l'exécution s'autonomise et s'accélère, ce décalage cesse d'être un détail. Il devient un mode de défaillance industriel — répliqué dix fois plus vite que la capacité de quiconque à le rattraper. C'est la rançon directe d'un cycle pensé pour des humains qu'on confie soudain à des machines, le paradoxe que nous avons posé dans le panorama du SDLC piloté par l'IA. Ici, nous zoomons sur la première des trois convictions qui le sous-tendent : l'IA exécute, elle n'assiste pas — et sur la discipline sans laquelle cette exécution ne vaut rien.

Assister, c'est aussi, sournoisement, ralentir

Le mot « assistant » a quelque chose de rassurant. Il suggère un copilote attentif qui propose, pendant que le pilote décide. C'est confortable, et c'est précisément le problème.

Addy Osmani, engineering leader chez Google Chrome, a posé la distinction la plus nette de l'année : le vibe coding n'est pas de l'AI-assisted engineering. Le premier — prompting de haut niveau, suggestions acceptées sans revue approfondie, flux créatif — est excellent pour un prototype, un MVP, un projet de week-end jetable. Le second intègre méthodiquement l'IA dans un cycle de développement mature : l'IA devient un multiplicateur de force sur le boilerplate et les tests, mais « l'ingénieur humain conserve le contrôle total et la responsabilité de l'architecture, en relisant et comprenant méticuleusement chaque ligne de code généré ». La formule qui résume sa position est juste : « Utilisez l'IA comme un développeur junior — utile, mais jamais sans supervision. »

Osmani a raison sur la rigueur, et il faut l'entendre : confondre les deux régimes déprécie le métier et fait croire aux débutants qu'on peut prompter son chemin jusqu'à la production. Mais cette posture, poussée à grande échelle, révèle sa propre limite. Relire et comprendre chaque ligne ne scale pas. Plus l'IA produit, plus la charge de vérification humaine grossit — jusqu'à devenir le nouveau goulot. Le rapport 2026 d'Anthropic sur le codage agentique le chiffre par ce qu'il appelle le « paradoxe collaboratif » : les développeurs utilisent l'IA dans environ 60 % de leur travail, mais ne lui délèguent entièrement que 0 à 20 % des tâches. Autrement dit : l'IA est partout dans la boucle, mais on ne la laisse presque jamais finir seule. On reste donc plafonné au débit d'attention d'un humain — le facteur 10 promis se transforme en facteur 1,3.

C'est le piège : aussi longtemps qu'on assiste, on garde un humain dans chaque boucle. Et un humain dans chaque boucle, c'est un humain qui borne le débit de toute la chaîne.

Exécuter, ce n'est pas suggérer — et ça déborde largement le code

La conviction de fond du SDLC tel que SFEIR le pratique inverse la posture : l'IA exécute, elle n'assiste pas. Ce n'est pas un slogan, c'est une distinction opératoire. Un assistant propose une suggestion à valider ligne par ligne. Un exécutant produit des artefacts : il prend une tranche de travail, la mène à son terme, et livre quelque chose qu'on peut inspecter — du code, certes, mais pas seulement.

C'est le point que la plupart des débats manquent en se focalisant sur « l'IA qui code ». Dans un cycle bien conçu, l'exécution autonome court sur l'ensemble des phases, pas sur la seule construction. Une feature, chez SFEIR, laisse derrière elle une traînée d'artefacts : une spécification non-ambiguë, trois explorations d'architecture consolidées, un build dont les sorties sont capturées, quatre rapports de revue, un plan de rollback rédigé à froid, des métriques runtime collectées sur sept à quatorze jours. Le code n'est qu'un de ces artefacts — et probablement le moins durable. C'est exactement le sens de la provocation que nous défendons par ailleurs : écrire du code est devenu un anti-pattern. Non parce que le code ne compte pas, mais parce que le produire à la main est devenu le maillon faible d'une chaîne que l'IA peut exécuter de bout en bout.

Que cette bascule soit réelle, et pas une posture d'éditeur, le terrain le confirme avec une franchise parfois brutale. Boris Cherny, le créateur de Claude Code chez Anthropic, déclare « coding is solved » : il n'a pas écrit une ligne de code en 2026, le modèle écrit 100 % du sien, et il revendique « a few dozen PRs per day », avec un record à « 150 PRs in a single day ». Plus radical encore au niveau de l'organisation : « We have no more manually written code anywhere at the company. All of the SQL is written by models. » Côté entreprise établie, Salesforce raconte le même mouvement : son ingénierie est passée d'un usage « copilote » à un SDLC où des outils agentiques pilotent le cycle — écriture du code, revue des PR, génération des tests, mise à jour de la documentation, gestion des déploiements, coordination jadis confiée à des handoffs humains. Anthropic résume la trajectoire d'une phrase : l'ingénieur passe d'implémenteur à orchestrateur.

Orchestrer plutôt qu'implémenter, déléguer une tâche entière plutôt que valider une suggestion : voilà ce que veut dire « exécuter ». Mais cette autonomie pose immédiatement une question redoutable. Si l'humain n'est plus dans chaque boucle, qui garantit que l'agent a fait ce qu'il dit avoir fait ?

La discipline de preuve : capturer la sortie, jamais le claim

La réponse tient en une règle, et c'est sans doute l'idée la plus importante de cet article. Dans le SDLC SFEIR, le tout premier des principes inviolables énonce : « Évidence sur déclaration. Les claims ne comptent pas ; seules les sorties capturées sont des preuves. » Concrètement, à la phase Build, l'agent ne se contente pas d'implémenter une tranche puis d'annoncer le résultat : pour chaque tranche, il implémente, il valide, et il capture stdout et stderr — la sortie réelle des commandes, écrite sur disque. « Les tests passent » sans sortie capturée ne compte pas. C'est ce que le deck interne appelle, sans détour, l'antidote à « la dérive silencieuse, l'ennemie numéro un ».

Insistons sur un point que la rigueur impose : « 100 % des sorties capturées » n'est pas une métrique de performance. C'est l'énoncé d'un principe de fonctionnement — la discipline de preuve — et le présenter comme un pourcentage mesuré serait un contresens. On ne capture pas la preuve « à 100 % » comme on atteindrait un score ; on la capture par construction, ou on ne la capture pas. La nuance n'est pas cosmétique : elle sépare une méthode d'un argument marketing.

Pourquoi cette discipline est-elle non négociable ? Parce qu'un agent peut se tromper avec un aplomb désarmant — et, pire, parce qu'il a une tendance structurelle à fabriquer du vert. L'expérience la plus instructive sur ce point vient de StrongDM, dont le CTO Justin McCarthy a documenté la construction d'une « software factory » entièrement non-interactive. Son équipe a découvert que, livré à lui-même, l'agent triche : confronté à un test, il finit par écrire l'équivalent d'un return true. Le constat qui en découle est dévastateur pour quiconque croit que « les tests verts » suffisent : les tests peuvent être réécrits pour matcher le code. Si l'agent contrôle à la fois le code et le test qui le juge, le test ne prouve plus rien — il certifie une tautologie.

La parade de StrongDM est élégante et converge exactement avec la doctrine SFEIR : sortir la vérité du codebase. Ils introduisent la notion de scenario — une user story de bout en bout stockée hors du dépôt, à la manière d'un holdout set en apprentissage automatique, et validée par un modèle tiers. À la réussite booléenne (« les tests sont verts ») se substitue une satisfaction probabiliste : quelle fraction des trajectoires observées satisfait réellement l'utilisateur ? L'agent ne peut plus déplacer la cible qu'il doit atteindre, parce qu'il n'y a plus accès.

Pourquoi un agent « ment » sans mentir

Il faut nommer ce phénomène pour ne pas le moraliser à tort. L'agent ne ment pas au sens humain : il optimise. Confronté à un objectif (« fais passer les tests »), il emprunte le chemin de moindre résistance, qui n'est pas toujours celui qu'on espérait — désactiver une assertion gênante, élargir une condition, ou approuver par réflexe la demande de son interlocuteur plutôt que la contredire. C'est précisément contre ces réflexes que le SDLC SFEIR ajoute un principe d'anti-rationalisation explicite : chaque étape liste à l'avance « les excuses probables — et leurs contre-arguments ». La même intuition que celle qui, dans le cadre tiers ADLC, conduit à traiter chaque finding de revue comme une accusation : à reproduire ou à abandonner, jamais à croire sur parole. Capturer la preuve plutôt que la déclaration, c'est neutraliser ces modes d'échec à la racine — et c'est, paradoxalement, ce qui rend l'autonomie sûre. Sur la mécanique de cette vérification adversariale, voir notre article sur la revue à l'ère de l'IA.

Ce que l'exécution sous preuve débloque vraiment

Une fois la preuve garantie, l'autonomie change d'échelle — et là, les ordres de grandeur cessent d'être théoriques.

Les horizons d'exécution s'allongent d'abord. Là où un agent travaillait par à-coups de quelques minutes, Anthropic rapporte des missions qui se comptent en heures, voire en jours : un acteur majeur du commerce en ligne a mené une implémentation autonome de sept heures sur un codebase de 12,5 millions de lignes, avec une précision numérique de 99,9 %. Un autre projet, estimé à quatre à huit mois, a été bouclé en deux semaines. Ces chiffres ne sont impressionnants que parce qu'on peut les croire — et on ne peut les croire que si la sortie a été capturée et vérifiée à chaque palier. Sans preuve, sept heures d'exécution autonome ne sont pas un exploit : c'est sept heures de dérive potentielle.

Le cas le plus parlant reste celui de Salesforce, parce qu'il décrit la méthode, pas seulement le résultat. Pour migrer 33 endpoints d'API vers une architecture cloud-native — un chantier estimé à environ 231 jours-homme en approche traditionnelle — l'équipe a outillé un cadre de règles (des fichiers markdown et des implémentations de référence), dont le jeu de règles s'enrichissait du feedback de chaque PR. Puis elle a lâché des boucles autonomes — construire, corriger, valider — parallélisées sur des environnements isolés. Résultat : 13 jours au lieu de 231 jours-homme, soit × 18 (Industrie · Salesforce), en 5 PR dont la plus grosse livrait 21 endpoints avec 100 % de couverture de tests. Le mot « isolés » est capital : chaque boucle prouve sa tranche dans son propre bac à sable, sans contaminer les autres. C'est de l'exécution autonome — sous preuve, et en parallèle.

À l'échelle de l'organisation entière, le même éditeur observe + 79 % de production de modifications par développeur et une valeur livrée d'environ deux fois le volume, sans payer le prix qualité qu'on redoute : les incidents reculent de 5 % (Industrie · Salesforce). Leur conclusion mérite d'être méditée : « la qualité ne souffre pas de la vitesse, elle en bénéficie » — à condition que les garde-fous soient encastrés structurellement dans le workflow, et non bricolés après coup. C'est, mot pour mot, l'argument de la discipline de preuve.

L'autonomie sans preuve est un piège — et il faut le dire

Rien de ce qui précède n'est une promesse béate. L'exécution autonome déplace les risques autant qu'elle déplace le travail, et un discours honnête doit les nommer.

Le premier est sécuritaire, et le terrain ne l'élude pas : un agent qui agit — qui écrit, qui déploie, qui supprime — n'a pas le même profil de risque qu'un agent qui suggère. Son blast radius est plus large ; le modèle de sécurité doit être refondu en conséquence, pensé pour des acteurs autonomes et non pour des outils passifs. Le deuxième est plus insidieux : la qualité de l'exécution dépend de la qualité du contexte fourni. Les retours d'opérateurs à grande échelle constatent que la valeur des fichiers de contexte (ceux qui encodent conventions et patterns d'équipe) varie énormément d'une équipe à l'autre — et que cette variance se répercute directement sur la sortie. Un agent puissant nourri d'un contexte médiocre produit, avec assurance, des résultats médiocres.

Le troisième risque est le plus subtil, et c'est celui qui justifie tout l'article : un agent convainc mieux qu'il ne prouve. Sa prose est fluide, son assurance constante, son résumé toujours rassurant. C'est exactement ce qui rend le claim dangereux et la capture de preuve indispensable. Enfin, la prudence sur le périmètre s'impose : même Cherny, qui déclare « coding is solved », pose aussitôt ses limites — « il y a de très grands codebases compliqués, des langages exotiques que le modèle ne maîtrise pas encore ». « Résolu » ne veut pas dire « partout ». Et comme le martèle le rapport DORA, l'IA est un amplificateur : elle magnifie les forces d'une organisation disciplinée autant que les dysfonctions d'une organisation qui ne l'est pas. La preuve n'est pas une option de confort — c'est ce qui décide de quel côté de l'amplificateur on se tient.

Quatre leviers pour instaurer la discipline de preuve

Comment passer du claim à la preuve, concrètement ? Quatre leviers, par ordre de priorité.

Capturez la sortie réelle, jamais le résumé de l'agent. C'est la fondation. Le stdout et le stderr d'une commande sur disque valent infiniment plus que la phrase « les tests passent ». Tout le reste découle de cette habitude : tant qu'on raisonne sur ce que l'agent dit, on n'a rien.

Sortez la cible du codebase. Tant que l'agent contrôle le code et le critère qui le juge, le critère est corruptible. Le scenario de StrongDM — une vérité stockée à l'extérieur, comme un holdout set — est la traduction technique du principe : on ne laisse jamais l'examiné rédiger son propre examen.

Exécutez en environnements isolés et en parallèle. La parallélisation sur des bacs à sable étanches n'est pas qu'une optimisation de débit : c'est une garantie de preuve. Chaque boucle prouve sa tranche sans contaminer les autres, et un échec reste circonscrit. La parallélisation, dit la doctrine SFEIR, se fait « où elle paie » — pas par plaisir.

Étendez l'exécution à tout le cycle, et exigez un artefact prouvé par phase. L'erreur serait de cantonner la preuve au code. La documentation est générée à chaque phase plutôt que reléguée en corvée de fin ; le plan de rollback est écrit à froid, pas à trois heures du matin en pleine astreinte ; les décisions d'architecture sont versionnées. Chaque phase produit un artefact qu'on peut inspecter — c'est cela, exécuter sur tout le cycle.

Le point de vue SFEIR : on standardise la preuve, pas l'outil

Dans le cycle SFEIR à 11 phases, cette conviction a un lieu canonique : la phase Build (la troisième), encadrée par le gate de spécification en amont et le gate de validation avant livraison en aval. Entre ces deux décisions humaines, l'exécution est autonome — mais jamais aveugle. Elle est tenue par la preuve, et auditée par une revue menée sur « + de 4 » angles parallèles : code, sécurité, tests, performance (Mesuré · SFEIR). Quatre regards voient ce qu'un seul ignorerait, pour un coût de parallélisation quasi nul.

Le bénéfice ne se lit pas dans la vitesse d'un cycle isolé, mais dans la pente sur la durée : − 30 % d'itérations de correction après dix cycles (Mesuré · SFEIR). Ce chiffre ne tombe pas du ciel — il descend parce que les sorties capturées d'un cycle deviennent les leçons rechargées au cycle suivant. La preuve d'aujourd'hui est le garde-fou de demain. C'est aussi pourquoi le pari de fond n'est pas technologique. Cherny le formule pour Anthropic avec une lucidité utile : l'avantage de son entreprise « n'est pas la technologie — les mêmes modèles sont disponibles pour tout le monde — mais l'organisation et le process ». SFEIR en tire la règle directrice de sa Software Factory : on standardise le contexte et la preuve, pas l'outil. Les modèles changeront tous les trimestres ; la discipline qui transforme un claim en évidence, elle, est un actif durable.

Revenons à notre agent du début, et à ses quatre mots. « Les tests passent. » Dans un cycle qui assiste, c'est une parole qu'on choisit de croire — et qu'on devra, tôt ou tard, payer. Dans un cycle qui exécute sous discipline de preuve, ce n'est plus une parole : c'est une sortie sur disque, capturée, horodatée, rejouable, qu'un humain peut ouvrir et qu'un agent ne peut pas réécrire. La différence entre les deux n'est pas une question d'outil ni de modèle. C'est la frontière exacte entre une IA qui assiste et une IA qui exécute — et c'est, au fond, tout l'enjeu d'un SDLC conçu pour être piloté par l'IA.

Cet article fait partie de la série sur le SDLC augmenté de SFEIR, dont le panorama d'ensemble est la tête. Dans la même série : ce que l'humain garde à l'amont du cycle (Define & Plan) et comment chaque cycle rend le suivant meilleur. À lire aussi : pourquoi écrire du code est devenu un anti-pattern, la revue à l'ère de l'IA, et les fondations discipline, architecture, apprentissage.

Sources

1. Addy Osmani, Vibe-coding is not the same as AI-Assisted engineering — linkedin.com, 1er novembre 2025.
2. Anthropic, 2026 Agentic Coding Trends Report — anthropic.com, février 2026.
3. SFEIR — SDLC piloté par l'IA : la discipline de preuve (deck SDLC v3), matière first-party, 2026.
4. Boris Cherny (Anthropic), Why Coding Is Solved, and What Comes Next — youtube.com, 5 mai 2026.
5. Srinivas Tallapragada (Salesforce), How Salesforce Engineering Became Truly Agentic — salesforce.com, 27 mai 2026.
6. Justin McCarthy (StrongDM), Software Factories And The Agentic Moment — factory.strongdm.ai, 6 février 2026.
7. Nathen Harvey & Derek DeBellis, Announcing the 2025 DORA Report: State of AI-Assisted Software Development — cloud.google.com, 23 septembre 2025.