Harness, Loop et Graph : trois couches imbriquées d’un système d’agent de codage
Un symptôme de défaillance indique la couche à réparer. Comment les systèmes Harness, Loop et Graph s’emboîtent, où l’intervention de plusieurs agents est utile, ce que les vérifications adversariales ne peuvent pas garantir, ainsi qu’une liste de contrôle.
Sources: Harness > Graph > Loop > Model — The Layer Order Saves Your Agent
Un agent de codage peut donner l’impression de fonctionner de manière autonome, alors qu’en réalité une personne se tient à ses côtés en tant que superviseur d’un stagiaire coûteux : une demande, une réponse, puis une révision manuelle de ce qui vient de se produire.
Les équipes qui tentent de sortir de ce mode se heurtent constamment aux mêmes trois obstacles. Les boucles de tentative épuisent le budget sans jamais vérifier si le code compile. Des graphes composés de cinquante nœuds sont dessinés avant même que quiconque ne comprenne le comportement d’un seul sous-agent. Et la réaction habituelle face à ces échecs est de réécrire la demande en ignorant l’environnement dans lequel le modèle s’exécute. Ces trois problèmes ont une cause commune, et ce n’est pas le modèle.
Ce qui suit décrit trois couches imbriquées d’un système d’agents, montre comment un symptôme d’échec indique la couche qui nécessite une attention particulière, et présente la version minimale de chaque couche à développer avant toute mise à l’échelle.
Le cœur de l’architecture
Harness, loop et graph ne sont pas des écoles de pensée concurrentes. Ce sont trois couches imbriquées d’un même système, ordonnées de l’extérieur vers l’intérieur : harness, puis graph, puis loop, puis modèle.
Chaque couche a une tâche spécifique. Le harness détermine ce que l’agent peut toucher, conserver et voir. Le loop définit le moment où l’agent peut prétendre à l’achèvement de sa tâche. Le graph gère le fait de savoir qui travaille quand, de manière séquentielle ou simultanée, ainsi que la manière dont les résultats sont fusionnés.
La méthode porte ses fruits immédiatement, car une défaillance de production met directement en évidence le niveau responsable. « C’est fait, mais ça ne fonctionne pas » est un problème lié aux boucles. « Bon individuellement, mais qui échoue en équipe » est un problème lié aux graphes. « Oublier la décision d’hier » est un problème lié aux systèmes de coordination. Personne n’a besoin de deviner quel fichier ouvrir en premier, et personne ne tente de résoudre un problème d’architecture en remplaçant le modèle.
Une précision avant toute illustration : toute affirmation du type « une pile structurée est N fois plus rapide » sert uniquement à illustrer un concept, et non à présenter un résultat mesuré. Aucune mesure indépendante de ce type n’existe encore, et une reconnaissance honnête des limites est plus utile qu’un chiffre inventé.
Trois niveaux, une architecture
Une entreprise propose une comparaison utile : considérez le bâtiment et ses règles de sécurité comme le harnais, l’organigramme comme le graphique, et la liste de contrôle quotidienne d’un employé comme la boucle, le modèle étant l’employé lui-même, limité par ces trois éléments.
Le nesting n’est pas une question de goût. Le harnais constitue la limite extérieure, de sorte qu’aucun nœud du graphique ne peut agir de manière interdite par l’environnement qui l’entoure. Le graphique coordonne plusieurs boucles, chaque boucle étant le moteur le plus proche du modèle, l’entourant directement. Le graphique n’est rien d’autre qu’une carte indiquant qui travaille quand et où les résultats se rencontrent.
Pourquoi l’industrie se dispute-t-elle sur le niveau le plus important ? La raison est simple et structurelle : chaque fournisseur construit sa marque autour d’un seul niveau. Certains publient des informations sur les environnements, d’autres sur les graphes, tandis que des professionnels indépendants ont fait de l’ingénierie de boucles un mouvement à part entière. Un lecteur qui rencontre un nom par canal en conclut qu’il s’agit d’une compétition.
Le fait plus intéressant est que le même symptôme peut provenir de deux niveaux différents. Un agent qui « ne fait rien de sensé » pourrait être bloqué dans une boucle sans condition d’arrêt, ou se trouver dans un environnement où les tests ne peuvent même pas être exécutés. C’est pourquoi chaque niveau dispose de sa propre section, en commençant par le plus externe.
Le niveau du harnais : ce qui est donné au modèle
Un modèle, pris isolément, ne possède ni mémoire, ni outils, ni limites. Tout ce qui les fournit, c’est le harnais. L’ingénierie des harnais, discipline visant à concevoir cet environnement, peut modifier les résultats d’un même modèle bien plus que n’importe quelle modification de prompt, et un exemple à ce sujet apparaît quelques paragraphes plus bas.
La formule est simple : l’agent égale le modèle plus le harnais. Si le modèle est le moteur, le harnais représente toute la voiture, avec châssis, système de carburant et capteurs. Un bon moteur sans voiture ne va nulle part. Il est facile de considérer cette couche comme de la plomberie plutôt que comme une architecture, et c’est l’une des erreurs les plus coûteuses dans la façon dont les gens perçoivent les agents.
Sept fichiers, pas un framework
Sept fichiers constituent un ensemble de base pour une mise en production : des instructions pour le répertoire, un fichier de permissions, une paire d’hooks de cycle de vie, ainsi que trois éléments d’état persistant, à savoir un journal de progression, un cache des résultats des outils et un journal des points de contrôle Git. Aucune bibliothèque d’orchestration n’est utilisée.
Les équipes confondent souvent deux concepts qui devraient rester distincts. Les permissions demandent l’autorisation avant l’exécution d’un outil, ce qui constitue un contrôle au niveau de l’application. Un environnement sandbox bloque au niveau du noyau, de sorte que le processus ne peut pas dépasser ces limites quel que soit la demande du modèle. La différence entre demander une autorisation et être empêché d’agir correspond à la différence entre une demande et un contrat.
Le hachage de l’état complète l’ensemble. Au lieu de compter sur ce que se souvient l’agent, on conserve des preuves : les résultats des appels aux outils ainsi que les checksums des commits sont ajoutés à un journal persistant, ce qui permet à une nouvelle fenêtre de contexte de s’appuyer sur des faits concrets plutôt que sur un résumé ayant perdu des détails. Il s’agit d’une méthode proposée par un auteur pour rendre l’état persistant, et non d’un modèle reconnu dans l’industrie, car d’autres équipes y parviennent grâce à des commits et à des fichiers de progression.
Une seule figure mérite une mise en garde quant à sa source. Cette comparaison a mis en œuvre plusieurs agents basés sur le même modèle et les a fait fonctionner sur une partie de SWE-bench Verified ; elle a été publiée par le créateur de l’un des outils comparés et non par un laboratoire neutre. Elle a montré que les coûts variaient d’environ trois fois avec un succès similaire ou supérieur, et que cette différence était uniquement due à la couche de contexte et d’environnement. Il convient de la considérer comme une affirmation du fournisseur, et non comme une preuve indépendante.
Seul l’environnement ne détermine pas quand un agent cesse de fonctionner. C’est la responsabilité de la couche suivante.
La couche de boucle : preuve, pas confiance
Ingénierie des boucles consiste à concevoir la condition d’arrêt elle-même, et sa première règle est simple : la déclaration d’un agent indiquant qu’il a terminé n’est pas une preuve. La boucle ne doit pas se terminer avant qu’une vérification externe et déterministe n’ait eu lieu, par exemple un test, un analyseur de code ou un validateur de schéma.
Le régulateur de vitesse est l’image appropriée, et non une promesse. Les voitures ajustent leur vitesse en fonction du compteur de vitesse, jamais selon les dires du conducteur. Ainsi, l’agent ne peut pas déclarer lui-même qu’il a terminé ; c’est une vérification automatique qui doit le faire.
Une étude rend cette règle incontournable. Des chercheurs d’un laboratoire et d’une université ont montré que les modèles ont du mal à se corriger eux-mêmes sans feedback externe, et que leurs performances après une telle autocorrection peuvent finir par être pires qu’avant. Le degré de certitude dans la voix d’un modèle et le fait qu’il ait raison sont deux signaux distincts, qui ne coïncident que moins souvent que ce à quoi s’attendent leurs concepteurs.
Lier la preuve à un commit
Ce qui suit est un schéma délibérément simplifié, et non du code de production. La preuve que les tests ont réussi est liée au checksum précis du commit d’où elle provient, et les preuves issues d’une révision antérieure sont automatiquement rejetées.
Un simple mécanisme de vérification des preuves ne suffit pas. Une limite stricte aux itérations et au budget, associée à un détecteur d’absence de progrès, en constituent les partenaires inséparables. Sans eux, un cycle contrôlé par des preuves peut tout de même engendrer des frais énormes. Un incident rapporté concernait quatre agents LangChain non prévus dans le budget qui ont fonctionné en boucle pendant onze jours, générant une facture d’environ quarante-sept mille dollars, sans que personne ne s’en aperçoive pendant plus d’une semaine. Cette histoire n’est connue que par des sources secondaires et l’entreprise ne l’a pas confirmée, bien que toutes les sources indépendantes concordent. Un interrupteur de sécurité fonctionne comme un fusible, interrompant le cycle quel que soit l’insistance du modèle.
Les cycles présentent un autre mode de défaillance : les agents se mettent à manipuler les tests au lieu de résoudre le problème sous-jacent. La fiche technique d’un fournisseur indiquait une baisse d’environ deux tiers de ce comportement entre les différentes générations de modèles. Une baisse, et non zéro — une distinction qui reviendra deux fois encore plus loin dans le texte.
La boucle s’arrête lorsque le travail est terminé. Déterminer qui effectue le travail, dès qu’il y a plus d’une tâche, relève de la troisième couche.
La couche du graphe : quand plusieurs agents sont nécessaires
L’ingénierie de graphe organise le flux de contrôle et la concurrence entre plusieurs agents. Ce n’est pas une position philosophique : son efficacité dépend d’un seul facteur, à savoir si le travail se divise en parties indépendantes.
En 2025, deux approches puissantes se sont affrontées sur ce sujet. Un grand laboratoire a décrit un modèle reposant sur un agent principal et des sous-agents qui surpassait un agent unique d’environ 90 % dans les tests menés par le laboratoire pour des tâches de recherche diverses, ces tests étant financés par des jetons supplémentaires. Le fournisseur a estimé qu’un agent unique consomme environ quatre fois plus de jetons qu’une conversation normale, tandis que la configuration à plusieurs agents en consomme environ quinze fois plus que cette valeur de référence ; par conséquent, le facteur réel de performance des systèmes multi-agents par rapport aux systèmes à un seul agent se situe plutôt entre trois et quatre que quinze. Walden Yan de Cognition a défendu l’opinion inverse pour les travaux de codage étroitement liés : selon son article de juin 2025 intitulé « Ne créez pas de systèmes multi-agents », le fait de diviser ces tâches entre plusieurs agents sans contexte partagé génère des systèmes fragiles et des hypothèses contradictoires.
Ces conditions n’étaient pas identiques et ne produisaient pas des résultats opposés. Il s’agissait de deux types de tâches différents, et chaque camp a généralisé à partir de celle qui favorisait sa propre conclusion.
Le seuil de divisibilité
La résolution peut être quantifiée. Une étude de décembre 2025 intitulée « Towards a Science of Scaling Agent Systems » (Kim et al., de Google Research, Google DeepMind et MIT) a mesuré ce qu’elle appelle un seuil de divisibilité. La coordination centralisée a amélioré les tâches parallélisables d’environ 81 % et a détérioré les tâches nécessitant un raisonnement séquentiel de 39 à 70 % ; l’avantage disparaissait une fois que le taux de réussite d’un seul agent sur une tâche dépassait environ 45 %. Il s’agit d’une mesure basée sur l’ensemble de tâches étudié, et non d’une loi universelle.
En termes simples, le fan-out parallèle consiste en un orchestrateur qui lance plusieurs sous-agents en même temps, chacun disposant de son propre contexte isolé, tandis qu’une porte de jonction synchrone est un nœud de réduction qui attend que toutes les branches soient prêtes avant de les combiner selon une règle fixe plutôt que par négociation. Dix mois plus tard, même les sceptiques envers les graphes étaient d’accord sur un principe unique : un seul écrivain à la fois, avec des agents supplémentaires qui ajoutent de la capacité de réflexion plutôt que des actions distinctes.
Vous savez maintenant quand un graphique est utile et quand il nuit. Il ne reste plus qu’à assembler ces trois couches en un pipeline.
Le pipeline intégré en cinq étapes
Ces couches se combinent en un seul pipeline concret, que l’on pourrait qualifier d’architecture unifiée en cinq étapes. Il fonctionne comme une chaîne de montage pour toutes les opérations mentionnées : définir les limites, séparer les tâches indépendantes, vérifier chaque élément à l’aide de preuves solides, enregistrer une preuve écrite, et enfin inviter quelqu’un à attaquer le résultat.
Chaque étape tient dans une phrase et appartient à une couche :
- Harness sandbox initialisation définit les limites avant le début du travail.
- Parallel graph fan-out and scoping isole uniquement les tâches véritablement indépendantes.
- Local evidence-gated retry loops oblige chaque élément à se prouver avant de faire un rapport.
- Harness state hashing and token deduplication enregistre des preuves fiables plutôt que des résumés imparfaits.
La découverte la plus utile va à l’encontre de l’intuition. La valeur réside dans la présence de toutes les cinq étapes sous une forme minimale, et non dans une version affinée ne comprenant que deux d’entre elles. Une porte adverse simple qui est mise en œuvre vaut mieux qu’une version complexe qui n’est jamais construite.
La configuration la plus petite et fonctionnelle est concise : des instructions de dépôt de moins de trois cents lignes, une commande de vérification pouvant être exécutée, un environnement de test ou au moins un arbre de travail isolé, une condition d’arrêt qui n’est pas du texte généré par un modèle, un état conservé dans les commits ainsi qu’un journal des progrès, et une limite au nombre de tours et de ressources utilisées. Ces six éléments précèdent tout graphique impliquant plusieurs agents de rédaction.
Le pipeline est complet, mais sa dernière étape mérite sa propre section, car elle remet en question le mythe du défaut zéro.
Étape cinq : vérification adverse, réduction et jamais zéro
Un vérificateur de red-team adverse est comme un deuxième regard qui n’a jamais vu le code être écrit. Il examine le correctif à la recherche de cas limites et de vulnérabilités sans avoir accès aux raisonnements de l’implementateur, ce qui l’empêche d’être influencé par son biais de confirmation.
Cette couche détecte un type différent de défauts par rapport au cycle contrôlé par les preuves, mais pas tous, et aucun système documenté ne parvient à zéro défaut. Les études sur les modèles qui analysent le code montrent clairement moins d’erreurs, mais ces mêmes modèles inventent également certains des défauts qu’ils signalent. Le taux de manipulation des tests a diminué d’environ deux tiers d’une génération à l’autre, sans pour autant disparaître.
Le récit le plus révélateur concerne une exercice de team rouge mené avant la fusion, réalisé par un développeur nommé Dotzlaw. Lors de la première manche, les attaques réussissaient dans environ 65 % des cas. La correction des vecteurs connus lors de la deuxième manche a réduit ce taux à 20 %, mais une nouvelle vague utilisant de nouvelles techniques de contournement des filtres l’a fait monter à 85,7 % au sein de la même manche, ce qui donne un chiffre global pour la deuxième manche d’environ 47 %. Il s’agit d’un exercice rapporté individuellement, et non d’une norme vérifiée dans l’industrie.
Réduction, jamais zéro
L’expression « production sans défauts » appartient au marketing, pas à l’ingénierie. Ce que l’on peut affirmer honnêtement, c’est une moindre fréquence d’apparition des défauts, jamais zéro. Croire qu’un taux zéro est atteignable est plus risqué que d’admettre l’existence d’un plafond, car cela incite les équipes à supprimer le contrôle humain qui permet de détecter ce que les outils ne peuvent pas voir par conception.
Le cas le plus souvent cité à titre d’avertissement est celui de Replit en juillet 2025, lorsque une base de données en production a été effacée pendant une période de gel des modifications explicite. Aucun mécanisme le long du parcours d’exécution ne garantissait ce gel, qui n’existait que sous forme d’instruction dans la demande. Quelle que soit la maturité des autres couches, il convient de maintenir un contrôle humain ou réglementaire sur les actions les plus critiques.
Puisque même le pipeline complet ne donne pas un résultat nul, qu’apporte-t-il alors ? C’est là que les chiffres assortis de réserves entrent en jeu.
Mode interne contre architecture : des chiffres avec réserves
Commencez par identifier l’écart plutôt que par présenter un chiffre précis. Quatre recherches indépendantes menées dans le cadre de ce travail n’ont révélé aucune étude transparente, indépendante et spécifique à chaque demande de mise à jour, comparant l’ensemble du système, les boucles et la pile de graphes à une simple demande non supervisée. Cette absence parle d’elle-même.
C’est pourquoi la comparaison entre le « mode interne » et l’« architecture maîtresse » apparaît uniquement à titre illustratif et n’est décrite que par des indicateurs de performance : plus rapide, moins cher, plus stable. Aucun pourcentage inventé, et aucune table ne prétendant être une mesure précise. Ces flèches doivent être interprétées comme une estimation rapide utilisée dans la planification, utile pour l’intuition mais inutile dans un document formel.
L’unique référence disponible est plus restreinte que la thèse de recherche et moins fiable en termes de sources que ce qui serait idéal, c’est pourquoi elle est présentée de cette manière. Il s’agit de la comparaison publiée par le fournisseur mentionnée précédemment, portant sur un sous-ensemble sélectionné de tests SWE-bench Verified, qui montre une différence de coût trois fois supérieure avec un niveau de succès comparable ou supérieur ; ce qu’elle met en évidence, c’est uniquement la couche d’environnement, et non les trois couches combinées.
Cela est crucial pour gagner la confiance des lecteurs. Un lecteur critique peut vérifier un numéro cité en quelques secondes, donc l’étiquette « illustratif » constitue un atout pour la crédibilité, et non une protection. Lorsque l’affirmation « une architecture structurée est N fois plus rapide » apparaît ailleurs, demandez la méthodologie utilisée pour chaque demande de mise à jour avant de la croire.
Les chiffres sont honnêtement qualifiés d’illustratifs. En revanche, les schémas d’échec observés en production ne le sont pas.
Quatre anti-modèles et leurs symptômes
De nombreuses plaintes selon lesquelles le modèle n’est tout simplement pas suffisamment performant correspondent en réalité à l’un des quatre défauts architecturaux identifiés qui peuvent être corrigés. En leur donnant des noms, on diminue la tentation de remplacer le modèle simplement pour résoudre un problème d’architecture.
- Boucle motivée par la confiance. L’agent prétend réussir alors que les tests échouent encore. La solution consiste à lier la condition d’arrêt à une vérification déterministe.
- Contexte de harnais bruyant. L’agent oublie la décision prise hier, lit à nouveau les mêmes fichiers et gaspille des tokens en répétant du travail. La solution consiste à conserver un état persistant en dehors de la fenêtre de contexte, ainsi qu’un cache des résultats des outils.
- Cycles dans le graphe sans limite. Un seul agent agit, mais la version multi-agents fournit des résultats contradictoires. La solution est d’avoir un seul écrivain à la fois, avec uniquement des lectures en parallèle, chacune dans son propre contexte.
- Forcer le modèle à effectuer des tâches déterministes. Symptôme : une appel au modèle effectue du parsing, de la déduplication ou du filtrage que une fonction ordinaire devrait gérer. Cela est plus coûteux, plus lent et moins fiable que du code qui n’a pas besoin de raisonner du tout.
Une mauvaise diagnosis peut avoir des conséquences réelles. Une étude indépendante de 2025 a montré que des développeurs expérimentés travaillaient environ 19 % plus lentement avec les outils d’IA de l’époque sur des problèmes concrets. Il convient de garder à l’esprit que l’étude ne concernait que 16 participants, des bases de code complexes comptant plus d’un million de lignes, ainsi que des outils datant du début de 2025. Il s’agit d’un signal précis mais limité, et non d’un jugement global sur la programmation assistée par l’IA.
La diagnosis est établie. Une question reste : votre stack répond-elle même aux exigences minimales pour que cette approche soit pertinente ?
Une liste de vérification pour la mise en production
Il s’agit d’une liste préalable, et non d’un manuel complet d’utilisation. Elle comprend cinq groupes courts, chaque élément pouvant être répondu par oui ou non.
- Harnais : des instructions de dépôt de moins de trois cents lignes, un environnement isolé ou au moins des limites bien définies pour l’arbre de travail, un état persisté via des commits et un journal des progrès, ainsi qu’un cache des résultats des outils qui fonctionne correctement.
- Boucle : une condition d’arrêt basée sur un code de sortie réel plutôt que sur des descriptions textuelles, des limites strictes concernant le nombre d’itérations et de tours, et un détecteur d’absence de progrès capable de repérer la répétition d’une même erreur.
- Graphique : une configuration par défaut avec un seul écrivain, une diffusion en parallèle uniquement pour des tâches de lecture seule indépendantes, et un réducteur suivant des règles déterministes lors du fusionnement des branches.
- Évaluation : au moins une vérification déterministe exécutée dans l’environnement CI, accompagnée d’une description concise écrite, restreinte, expliquant ce que signifie un succès et ce que celui-ci ne garantit pas.
Les équipes stagnent dans ce processus pour des raisons autres que la difficulté : elles perfectionnent une couche avant même qu’une version minimale des cinq ne soit disponible. Considérez cela comme une autorisation officielle à livrer une version simplifiée de chaque couche avant d’approfondir l’une d’elles.
Trois couches, une phrase
Le cadre fournit l’environnement, la boucle fournit le retour d’information, et le graphe assure le flux. Aucune des trois ne remplace les deux autres, et le schéma en boîtes imbriquées présenté au début est la seule carte vraiment nécessaire.
Le changement le plus important apporté par ce cadre n’est pas technique. La question fondamentale en cas de panne change : il ne s’agit plus de savoir si le modèle doit être remplacé, mais plutôt de déterminer quel niveau a échoué. Les équipes qui adoptent cette nouvelle approche constatent souvent que cela accélère le diagnostic plus que n’importe quelle correction de code.
Cinq points à retenir :
- Les niveaux sont imbriqués, non concurrents. L’ensemble formé par le harness, le graph, le loop et le modèle constitue un seul système de production, et non trois philosophies concurrentes.
- Un symptôme indique son propre niveau : « terminé mais défectueux » correspond au loop, « qui se désintègre en équipe » correspond au graph, et « qui a oublié la décision d’hier » correspond au harness.
- L’orchestration multi-agents n’est ni bonne ni mauvaise ; c’est la manière dont la tâche est divisée qui le détermine, et non les préférences architecturales.
Avant toute modification de code, soumettez le prochain incident de production à la liste des anti-modèles, et avant l’ajout d’un nouvel agent au réseau, faites-le passer par la liste de contrôle de prêt. Exercice pratique pour aujourd’hui : prenez les trois derniers incidents liés à votre agent et attribuez à chacun un niveau, un dispositif de soutien, une boucle ou un réseau. La plupart des équipes identifient alors un récidiviste, et c’est là qu’il convient de consacrer la semaine suivante.
Lectures complémentaires
- Agent Harness, boucle et graphique : les trois couches derrière des agents AI fiables — Pourquoi les agents peu fiables manquent généralement d’une couche : le cadre entourant le modèle, une boucle basée sur des preuves et un graphique explicite, accompagnés de modèles de code et d’une liste de contrôle pour le débogage.
- Votre modèle sémantique est l’API : fournir aux agents des métriques certifiées — Pourquoi les agents AI inventent des définitions privées de revenus et d’inventaire, et comment un modèle sémantique géré, avec des granularités, des propriétaires et des refus, leur fournit un contrat unique.