Un run de tests au vert n'est pas encore une preuve
L'intuition suggère une chose simple : si toute la suite de tests passe, le travail est fait. Un préprint récent brise cette intuition sur un exemple réduit, presque jouet. Deux agents ont reçu la même tâche de refonte d'application. Le premier a suivi disciplinement les règles du processus — et a échoué au test gardé en réserve, non montré pendant le travail. Le second a ignoré les règles, mais a bouclé toute la suite visible de vérifications sans une seule erreur.
La conclusion est désagréable, mais utile : une suite de tests ne décrit pas la correction de l'application, mais la frontière qu'on a réussi à contourner. Quand la vérification et l'implémentation naissent de la même description, rien n'empêche l'agent d'adapter le code aux attentes de la vérification plutôt qu'à la tâche elle-même. Un tableau vert, dans cette situation, est un auto-rapport du système sur lui-même, et non une mesure indépendante.
L'auteur du travail déplace donc le curseur : il ne s'agit pas d'écrire des instructions plus intelligentes pour le modèle, mais de rendre une partie des assertions vérifiable par machine, c'est-à-dire telle qu'on ne puisse pas la contourner par la persuasion.
L'interface est figée avant l'écriture de la première ligne de code
Le point de départ est une observation issue de recherches antérieures : dès que le modèle devient suffisamment puissant, un pipeline complexe de refonte multi-agents commence à perdre face au scénario le plus primitif. Il suffit de donner au modèle le code source plus une seule instruction — c'est à peu près ainsi que fonctionne l'approche AgentModernize — et le résultat s'avère non pas moins bon, mais parfois meilleur que celui d'un schéma avec rôles, relecteurs et étapes intermédiaires.
La réponse de l'auteur est l'outil rebuild-dossier. Sa logique est la suivante : d'abord figer la véritable interface de l'application, c'est-à-dire ses entrées et sorties exactes, et seulement ensuite autoriser l'écriture du code. L'assemblage se fait un test à la fois, et chaque étape passe par des vérifications automatisées, et non par des accords écrits du type « n'oublie pas de t'assurer que… ».
La différence est fondamentale. Une instruction dans le prompt est une demande. Un script qui vérifie les signatures et les résultats est une contrainte. Une demande peut être violée sans même qu'on s'en aperçoive ; une contrainte passe ou ne passe pas, et cela se voit de l'extérieur.
Une réserve ici, facile à manquer : les auteurs n'ont pas mesuré d'effet propre à la fixation de l'interface elle-même — cet élément a été testé séparément et n'a pas participé à la comparaison. La conclusion « il suffit de figer le contrat et tout fonctionnera » ne découle donc pas du travail.
Trois niveaux de vérification au lieu d'un seul rapport d'agent
La partie la plus pratique du travail ne porte pas sur l'architecture des agents, mais sur la manière d'attester les faits. Chaque assertion sur le déroulement de la refonte est recoupée en trois endroits à la fois : ce que l'agent a écrit lui-même sur son travail, ce qu'a enregistré le journal automatique, et ce qui est réellement apparu dans le système de fichiers après le run.
Chaque niveau a son angle mort. L'agent peut se tromper dans son rapport, ou l'embellir. Le journal consigne les événements, mais dépend de ce qu'on a décidé de journaliser. La liste des fichiers ne ment pas, mais reste muette sur le sens des changements. L'écart entre les trois tableaux est précisément le signal pour lequel tout cela a été conçu.
Ce n'est pas une précaution théorique : le recoupement a mis au jour de vrais défauts, y compris un bug dans le code de journalisation écrit par les auteurs eux-mêmes. Un seul niveau — par exemple une confiance inconditionnelle dans le journal — n'aurait tout simplement pas remarqué cette erreur. La leçon se transpose à n'importe quel pipeline agentique : si vous n'avez qu'un seul canal d'observabilité, vous mesurez avant tout votre propre erreur.
Modèle faible et application volumineuse : où la construction trébuche
La deuxième question était la suivante : tout ce mécanisme est-il rentable par rapport à la ligne de base — donner à un modèle plus faible le code source et une seule instruction ? Sur une petite application, on a constaté une égalité. Sur une plus grande, une défaite nette, et la vérification automatisée ne s'est même pas lancée. C'est donc précisément la boucle de contrôle censée apporter l'avantage qui a échoué.
Cela se lit ainsi : ce qui fait la différence, ce n'est pas la fixation de l'interface, mais le mécanisme de vérification, qui ne s'est pas déclenché lors de ce run. Plus le projet est volumineux et plus la confiance dans le fait que l'automatisation fonctionnera comme prévu s'amenuise, plus il faut se méfier des promesses selon lesquelles « le processus remettra tout en ordre ».
Un autre volet : la portabilité. Les risques se reproduisent sur un autre modèle et une autre chaîne d'outils : le modèle plus puissant a passé le processus trois fois de suite, le plus faible — jamais. Pour l'idée « prenons un modèle accessible et le même pipeline », c'est une mauvaise nouvelle : la discipline du processus s'avère elle-même une fonction des capacités du modèle, et non une propriété de l'instruction.
Ce qu'il en découle en pratique
- Ne considérez pas les tests au vert comme une preuve. Demandez d'abord qui a écrit ces tests et s'il est possible de les contourner sans rien violer sur le fond.
- Gardez une suite de vérifications différée. Une partie des tests doit être inaccessible à l'agent pendant le travail — sinon il optimisera précisément pour eux.
- Sortez le contrat dans un artefact séparé. Les entrées et sorties — avant le code, et non dans les commentaires en cours de route. Mais rappelez-vous que cette seule étape peut ne pas suffire à obtenir un gain.
- Un test par étape. Un découpage fin rend la défaillance locale et compréhensible.
- Recoupez au minimum trois sources : le rapport de l'agent, le journal machine, l'état réel des fichiers. L'écart importe plus que la concordance.
- Testez sur un autre modèle et d'autres outils. Si le processus ne tient que sur le modèle le plus puissant, vous n'avez pas un processus, mais une de ses propriétés.
- Distinguez le poids des preuves. Dans ce travail, trois résultats sont étayés de manière inégale : ici une petite comparaison, là une observation. Ne transformez pas une démonstration réussie en standard du secteur.
De quel travail s'agit-il et à quel point y faire confiance
Il s'agit du préprint « Rebuild Dossier: Mechanically-Enforced Specs for Agentic App Rebuilds, and What Model-Tier Failures Reveal » (arXiv:2608.23616, section cs.SE) : version v1 du 22 août 2026, v2 du 26 août. Auteur — Parker Fawcett. Volume — 48 pages, une illustration. L'outil est ouvert sous licence MIT et se reproduit de bout en bout sur les applications des auteurs eux-mêmes ; le code et les artefacts d'évaluation sont publiés séparément, avec leur propre DOI.
La principale valeur ici ne réside pas dans une recette toute faite, mais dans la démonstration honnête de la manière dont un résultat « au vert » trompe précisément, et du nombre de couches de vérification nécessaires pour détecter l'écart. Les limites sont également énoncées sans détour : comparaisons compactes, poids inégal des trois résultats, dépendance de la discipline du processus à la puissance du modèle. Cela se lit comme un ensemble d'hypothèses vérifiables et un outil utile, et non comme une méthodologie définitive de refonte d'applications par des agents.
