Une boucle cache une décision dans une boîte noire : ce qui s'exécute ensuite.
Chaque fois qu'une boucle d'agent décide de réessayer, d'escalader ou de passer à autre chose, cette décision a lieu dans le raisonnement interne du modèle, invisible pour vous, non vérifiable après coup, et impossible à inspecter sans relire la sortie brute du modèle en espérant qu'il se soit expliqué honnêtement. Un graphe rend cette même décision explicite. Écrite. Inspectable avant même que l'exécution ne commence.
Ce n'est pas une distinction mineure. C'est l'argument réel derrière un véritable article arXiv publié en avril 2026 qui a reconfiguré la manière dont les systèmes agentiques devraient être construits, et il vaut la peine d'être franc sur quelque chose avant que ce cours n'aille plus loin. L'auteur de l'article inclut lui-même un avertissement d'équité indiquant clairement qu'il s'agit d'une conception non implémentée, et que le fait qu'elle tienne ses promesses en pratique reste une question empirique ouverte. Ce cours enseigne le cadre honnêtement, y compris cette réserve, car comprendre une proposition réelle et rigoureusement argumentée qui n'a pas encore été prouvée à grande échelle est plus utile que de faire comme s'il s'agissait d'un fait acquis.
À la fin de ce cours, vous comprendrez ce qu'est réellement l'ingénierie des graphes, pourquoi elle existe en tant que couche au-dessus des boucles, les trois engagements sur lesquels repose chaque graphe dans ce cadre, et comment construire votre premier graphe, ainsi qu'un compte rendu honnête de l'état actuel des preuves et de ce qu'elles ne prouvent pas.
Pourquoi les boucles ont un plafond
Pour comprendre pourquoi les graphes existent, vous devez comprendre précisément où les boucles cessent d'être suffisantes.
Une boucle, au sens agentique qui importe ici, est un cycle où un agent tente une tâche, observe le résultat, et décide de la suite, répété jusqu'à ce qu'une condition soit remplie. Cela fonctionne remarquablement bien pour une vaste gamme de tâches. C'est aussi, structurellement, une boîte noire au moment précis qui compte le plus : la décision de ce qui se passe ensuite.
Lorsque l'agent d'une boucle décide de réessayer une étape échouée, cette décision provient du modèle qui raisonne sur son propre contexte et produit un choix. Vous ne pouvez pas inspecter la décision avant qu'elle ne se produise. Vous ne pouvez observer le résultat qu'après coup. Si l'agent réessaie la même approche défaillante cinq fois de suite, en brûlant des coûts à chaque fois, rien dans la structure de la boucle ne l'a empêché, car la décision de réessayer vivait entièrement dans le jugement du modèle, et non dans une règle externe vérifiable.
C'est acceptable pour des tâches à faible enjeu et peu coûteuses où une nouvelle tentative occasionnelle gaspillée ne coûte rien de significatif. Cela devient un véritable handicap pour les travaux à long horizon, coûteux ou à enjeux élevés, exactement la catégorie de tâches à laquelle les systèmes agentiques sont de plus en plus confiés. L'argument central de l'article est qu'à mesure que les systèmes agentiques assument des travaux plus conséquents, l'opacité de « ce qui s'exécute ensuite » cesse d'être une boîte noire acceptable et commence à être le véritable point de défaillance qu'il vaut la peine d'ingénier directement.
Ce qu'est réellement un graphe
Un graphe, dans ce cadre, remplace la décision implicite du modèle sur l'étape suivante par une structure explicite définie avant le début de l'exécution.
Au lieu qu'un agent raisonne pour aboutir à « je devrais réessayer » ou « je devrais escalader » à l'intérieur d'une fenêtre de contexte opaque, le graphe définit, à l'avance, exactement quels états existent, quelles transitions entre états sont valides, et quelles conditions spécifiques déclenchent chaque transition. L'agent effectue toujours un travail réel dans chaque état. Ce qu'il ne fait plus, c'est décider invisiblement de la forme du processus global en cours de route.
La structure en cinq mouvements qui décrit tout passage unique à travers un graphe comme celui-ci : Planifier, Exécuter, Récupérer, Escalader, Répéter. Planifier est l'étape où la tâche est décomposée en une séquence définie. Exécuter est l'étape où l'agent effectue réellement le travail pour l'étape courante. Récupérer est ce qui se produit lorsque l'exécution échoue, suivant un protocole défini plutôt qu'une nouvelle tentative improvisée. Escalader est le point explicite et défini où le graphe confie le contrôle à un humain plutôt que de continuer à tenter une récupération automatique. Répéter ferme le cycle, passant à l'étape suivante du plan.
Remarquez ce qui a changé par rapport à une boucle. Chacun de ces cinq mouvements est désormais un état nommé et inspectable dans un graphe, avec des transitions définies entre eux, plutôt qu'une décision se produisant en silence à l'intérieur d'un seul appel de modèle.
Les trois engagements
Chaque graphe dans ce cadre repose sur trois engagements spécifiques. Comprendre ces trois engagements en profondeur est le véritable cœur de l'ingénierie des graphes en tant que discipline, plus que tout détail d'implémentation spécifique.
Engagement un : Plan immuable
Le plan d'exécution ne peut pas changer en cours de route. Une fois qu'un plan est généré et verrouillé, il existe comme une version fixe pour la durée de cette exécution. L'agent ne peut pas réviser silencieusement son propre plan à mi-parcours en fonction de quelque chose qu'il a remarqué, contrairement à ce qu'un agent à l'intérieur d'une boucle fait souvent sans aucun enregistrement externe de la révision.
Cela semble restrictif, et c'est voulu. La restriction est tout l'intérêt. Un agent qui peut librement réviser son propre plan en cours de route est exactement l'agent dont le comportement devient impossible à auditer après coup, car le plan que vous examinerez ensuite n'est pas le plan qui a été réellement suivi, c'est ce que le plan est devenu à la fin. Verrouiller le plan échange une flexibilité réelle contre une inspectabilité réelle. Ce compromis n'est pas gratuit, et il mérite d'être examiné honnêtement plutôt que d'être traité comme une amélioration stricte dans tous les cas. Une situation véritablement nouvelle que le plan original n'avait pas anticipée est moins bien gérée par un plan immuable que par une boucle qui peut s'adapter librement. L'engagement est un pari délibéré que, pour la catégorie de tâches que ce cadre cible, la prévisibilité et l'auditabilité l'emportent sur l'adaptabilité maximale.
Engagement deux : Couches séparées
La planification, l'exécution et la récupération vivent dans trois couches indépendantes au lieu d'une seule boucle emmêlée où les trois se produisent dans le même processus de raisonnement continu.
La couche de planification produit le plan immuable de l'engagement un et ne fait rien d'autre : elle n'exécute pas d'étapes et ne gère pas les échecs. La couche d'exécution exécute les étapes définies et rapporte les résultats : elle ne décide pas de ce qui se passe en cas d'échec, seulement de ce qui s'est passé. La couche de récupération reçoit les rapports d'échec et applique un protocole défini : elle n'exécute pas directement de nouveau travail, seulement décide comment répondre à ce qui s'est déjà produit.
Cette séparation reflète, délibérément, le même principe que la séparation d'un Constructeur d'un Juge dans une boucle de vérification : un rôle qui produit du travail ne devrait pas être le même rôle qui évalue ou décide de ce travail, car fusionner les deux érode l'indépendance qui rend la vérification significative en premier lieu. Ici, la séparation est triple au lieu de double, mais le raisonnement sous-jacent est identique : un système qui planifie, exécute et récupère tout à l'intérieur d'un seul processus indifférencié ne peut pas auditer de manière significative une seule de ces fonctions de manière indépendante, car elles ne sont jamais réellement distinctes dans la trace que vous examineriez ensuite.
Engagement trois : Escalade stricte
La récupération suit un protocole fixe au lieu de réessayer indéfiniment en espérant que quelque chose finira par fonctionner.
C'est l'engagement qui répond le plus directement au mode de défaillance par explosion de jetons qui afflige les boucles sans véritables conditions d'arrêt. Un protocole d'escalade stricte définit, à l'avance, exactement combien de tentatives de récupération sont autorisées, exactement ce qui compte comme une tentative de récupération réussie ou échouée, et exactement ce qui se produit une fois la limite définie atteinte : confier le contrôle à un humain, et non tenter une variation créative de plus sur la même approche défaillante.
L'analyse de l'article sur 70 systèmes réels a révélé qu'une grande partie des implémentations de boucles d'agents n'avaient aucune limite formelle aux tentatives de récupération, ce qui signifie que le comportement réel en cas de problème était déterminé par ce que le modèle décidait sur le moment, et non par une règle qu'un humain avait réellement examinée et approuvée à l'avance. L'escalade stricte comble directement cette lacune spécifique.
Construire votre premier graphe
Voici le chemin pratique pour en construire un réellement, en traduisant les trois engagements en quelque chose que vous pouvez implémenter plutôt que simplement comprendre conceptuellement.
Commencez par définir vos états explicitement, sur papier, avant d'écrire du code ou des instructions. Pour une tâche typique, cela ressemble généralement au minimum à : Planification, Exécution de l'étape N, Récupération après échec, Escalade, Terminé. Écrivez, pour chaque état, exactement ce qui se produit pendant que le système est dans cet état et exactement quelles conditions provoquent une transition hors de cet état.
Écrivez l'étape de génération du plan de sorte que sa sortie soit un artefact fixe et versionné, et non un document vivant que le reste du système peut modifier silencieusement. Une version simple et pratique consiste à générer le plan sous forme de liste numérotée d'étapes discrètes, chacune avec un critère de succès explicite, et à traiter cette liste comme en lecture seule pour le reste de l'exécution. Tout besoin réel de s'en écarter doit déclencher une escalade explicite vers un humain, et non une révision interne silencieuse.
Construisez la couche d'exécution de manière à ce qu'elle ne rapporte jamais que des résultats, réussite ou échec, avec des détails spécifiques, et ne prenne jamais elle-même de décision sur la suite. Cela reflète exactement le rôle du Constructeur dans une boucle de vérification : produire du travail et en rendre compte honnêtement, sans être aussi le rôle qui décide de réessayer.
Construisez la couche de récupération avec un protocole explicite et numéroté. Essayez une première approche alternative spécifique. Si cela échoue, essayez une deuxième approche différente spécifique. Si cela échoue, escaladez. Le protocole doit être suffisamment concret pour qu'un humain le lisant à l'avance puisse prédire exactement ce que le système fera à chaque étape, plutôt qu'une instruction vague comme « essayez de le réparer un nombre raisonnable de fois ».
Câblez l'état d'escalade de sorte que l'atteindre soit un événement réel et visible, et non quelque chose de silencieusement journalisé et oublié. Un humain doit être notifié, avec l'historique complet de ce qui a été tenté et pourquoi chaque tentative a échoué, la même discipline recommandée pour les conditions d'arrêt dans les boucles de vérification en général.
Où ce cadre aide réellement, et où il ne le fait pas
Être honnête sur les limites de l'ingénierie des graphes est plus utile que de la traiter comme une amélioration universelle par rapport aux boucles dans toutes les situations, et l'article lui-même soutient cette approche plus mesurée.
Les graphes aident réellement pour les tâches où l'espace des choses qui peuvent mal tourner est raisonnablement bien compris à l'avance, où l'auditabilité importe plus que l'adaptabilité maximale, et où le coût d'un cycle de nouvelles tentatives incontrôlé et sans limite serait vraiment élevé, que ce soit en coût de calcul ou en conséquence d'un mauvais résultat atteignant un utilisateur ou un système réel.
Les graphes sont moins adaptés pour les tâches véritablement ouvertes et exploratoires où vous ne pouvez pas prévoir de manière significative la forme de l'échec à l'avance, et où la valeur du système provient précisément de sa capacité à improviser une réponse à quelque chose que personne n'avait anticipé. Verrouiller un plan immuable, pour une tâche qui nécessite fondamentalement une replanification adaptative à mesure que de nouvelles informations émergent, échange exactement la capacité qui rendait la tâche digne d'être automatisée avec un agent en premier lieu.
La position honnête et défendable, et celle que l'auteur de l'article adopte lui-même, est qu'il s'agit d'un véritable compromis qui mérite d'être compris en profondeur, et non d'un remplacement strictement supérieur aux boucles dans tous les cas. Utilisez une boucle là où l'adaptabilité importe plus que l'auditabilité. Utilisez un graphe là où l'inverse est vrai. La plupart des systèmes réels bénéficient de la disponibilité des deux modèles et d'un choix délibéré entre eux par tâche, plutôt que d'adopter l'un ou l'autre comme valeur par défaut permanente.
Un exemple concret : migration de code structurée en graphe
Pour rendre concrète la structure en cinq mouvements et les trois engagements, voici comment ils s'appliquent à une tâche réelle et courante : migrer un module existant vers une nouvelle version de framework dans une base de code.
L'état Planification s'exécute une fois, au début. Il analyse le module, identifie chaque fichier qui doit changer, et produit une liste fixe et numérotée d'étapes de migration, chacune avec un critère de succès explicite. Par exemple, l'étape 4 réussit lorsque le fichier mis à jour compile et que la suite de tests existante pour ce fichier passe sans modification. Ce plan est verrouillé. C'est l'engagement un, immuable, en pratique.
L'état Exécution parcourt les étapes du plan dans l'ordre. Pour chaque étape, il applique la modification spécifique définie dans le plan et rapporte le résultat, réussite ou échec, avec la sortie réelle du compilateur ou le résultat du test en pièce jointe comme preuve, jamais une auto-évaluation « semble correct ». C'est la couche d'exécution de l'engagement deux, strictement séparée de la décision sur ce qui se produit en cas d'échec.
Lorsqu'une étape échoue, le graphe passe à Récupération, qui suit un protocole défini plutôt qu'une nouvelle tentative improvisée. Tentative une : réappliquer la même modification avec une portée plus restreinte, en isolant exactement quelle partie du fichier a causé l'échec de compilation. Tentative deux, si la première échoue : revenir à un modèle de migration alternatif documenté pour ce type spécifique d'échec, tiré d'une petite bibliothèque de correctifs connus plutôt qu'inventé à chaque fois. Si les deux tentatives définies échouent, le graphe passe à Escalade, c'est l'engagement trois, escalade stricte, pas une troisième tentative improvisée.
L'état Escalade notifie directement un humain, avec l'historique complet joint : quelle étape a échoué, ce que les deux tentatives de récupération ont essayé, et la sortie d'erreur spécifique de chacune. Un humain examine cet échec spécifique avec tout le contexte, plutôt que de découvrir des jours plus tard qu'un agent avait silencieusement réessayé la même approche défaillante en boucle tout ce temps, brûlant des coûts sans enregistrement de la raison.
Répéter ferme le cycle pour les étapes réussies, déplaçant le graphe vers l'élément suivant du plan verrouillé jusqu'à ce que la liste soit épuisée, moment auquel l'exécution atteint Terminé.
Remarquez ce que cela vous apporte par rapport à la même tâche exécutée comme une boucle non structurée. Chaque décision, que ce soit de réessayer, comment, et quand abandonner, est visible dans la structure définie du graphe avant même que l'exécution ne commence, et non découvrable seulement en lisant une transcription après coup et en déduisant ce que le modèle devait penser. Un relecteur de code, ou un auditeur de conformité, peut regarder la seule définition du graphe et savoir exactement ce que le système est capable de faire dans chaque scénario d'échec, sans jamais l'avoir vu s'exécuter.
Ingénierie des graphes versus ingénierie des boucles : quand utiliser quoi
Étant donné que les deux modèles sont réels, documentés, et ont chacun de véritables forces, voici un cadre de décision pratique pour choisir entre eux pour une tâche spécifique, plutôt que de traiter l'un ou l'autre comme valeur par défaut permanente.
Utilisez une boucle lorsque la tâche est véritablement exploratoire, lorsque vous ne pouvez pas prévoir à l'avance la forme de ce qui pourrait mal tourner, et lorsque la capacité du modèle à improviser une réponse à quelque chose d'inattendu est exactement la capacité sur laquelle vous comptez. Les tâches de recherche, le débogage ouvert où la cause profonde est véritablement inconnue au départ, et le travail créatif où une structure rigide nuirait activement au résultat, favorisent tous l'adaptabilité d'une boucle plutôt que l'auditabilité d'un graphe.
Utilisez un graphe lorsque la tâche est suffisamment bien comprise à l'avance pour que vous puissiez réellement énumérer les modes de défaillance probables, lorsque le coût d'un cycle de nouvelles tentatives sans limite et non audité serait vraiment élevé, et lorsqu'un relecteur humain, que ce soit une équipe de conformité, un auditeur de sécurité, ou simplement votre futur vous-même en train de déboguer un incident de production, aura besoin d'inspecter exactement ce que le système était capable de faire sans relire une transcription complète d'exécution. Les migrations, les transactions financières, tout ce qui touche aux données réglementées, et le travail d'agent non supervisé de longue durée où un échec silencieux pourrait s'aggraver pendant des heures avant que quiconque ne le remarque, favorisent tous la structure d'un graphe plutôt que la flexibilité d'une boucle.
Les deux modèles ne sont pas non plus mutuellement exclusifs au sein d'un même système plus vaste. Une conception pragmatique courante utilise un graphe au niveau externe, pour la structure globale de la tâche et ses conditions d'arrêt, tout en permettant à une boucle de s'exécuter à l'intérieur d'un seul état Exécution pour la sous-tâche véritablement exploratoire consistant à déterminer comment implémenter une étape spécifique. Cela vous donne l'auditabilité d'un graphe au niveau où elle compte le plus, la forme globale de ce que le système peut faire, tout en préservant l'adaptabilité d'une boucle au niveau où l'improvisation réelle est réellement précieuse, les détails d'un morceau de travail délimité.
Tester un graphe avant de lui faire confiance
Avant de vous fier à un système structuré en graphe pour quoi que ce soit de réel, soumettez-le à des tests de résistance spécifiquement conçus autour des trois engagements, car chaque engagement a sa propre façon de tomber silencieusement en panne s'il est implémenté de manière bâclée.
Pour tester l'engagement de plan immuable, construisez délibérément un scénario à mi-parcours d'une exécution où l'étape suivante « évidemment correcte », si le système raisonnait librement, s'écarterait du plan verrouillé. Confirmez que le système escalade réellement vers un humain plutôt que d'adapter silencieusement le plan par lui-même. S'il s'adapte silencieusement, le plan n'a jamais été réellement immuable en pratique, quelle que soit la manière dont le code est structuré.
Pour tester l'engagement de couches séparées, vérifiez si les rapports d'échec de la couche d'exécution contiennent une trace d'une décision sur ce qui devrait se passer ensuite, des phrases comme « cela nécessite probablement une approche différente » intégrées dans ce qui devrait être un rapport de réussite ou d'échec neutre. Si la couche d'exécution forme déjà des opinions sur la récupération, la séparation d'avec la couche de récupération n'est pas réelle, elle a simplement été renommée.
Pour tester l'escalade stricte, alimentez délibérément le système avec un échec qu'aucune des deux tentatives de récupération définies ne peut résoudre, et confirmez qu'il escalade proprement à la limite définie plutôt que de tenter une troisième approche non définie. C'est l'équivalent en ingénierie des graphes du test d'une condition d'arrêt de boucle contre une tâche véritablement insoluble, et cela détecte exactement la même classe de défaillance silencieusement coûteuse.
Au-delà de ces trois tests ciblés, suivez une métrique spécifique lors de l'utilisation réelle que l'alternative basée sur une boucle ne peut généralement pas vous donner proprement : le taux auquel les exécutions atteignent l'état Escalade, ventilé par quelle tentative de récupération spécifique a échoué à chaque fois. Un graphe qui escalade constamment à la même étape de récupération spécifique vous indique que le protocole défini de cette étape est mal calibré, et non que la tâche sous-jacente est uniformément difficile, la même valeur diagnostique que le suivi des déclencheurs de conditions d'arrêt pour les boucles, mais disponible ici avec plus de granularité car le point de défaillance est un état nommé et inspectable plutôt qu'un moment inféré à l'intérieur d'une transcription opaque.
Erreurs courantes lors de la construction d'un premier graphe
Quelques erreurs spécifiques reviennent fréquemment chez les personnes qui construisent leur premier système structuré en graphe, et les connaître à l'avance permet d'économiser un temps de débogage réel plus tard.
Traiter le plan comme immuable uniquement en théorie. Verrouiller le plan sur papier tout en permettant à la couche d'exécution de s'en écarter silencieusement en pratique produit le pire des deux mondes : pas d'adaptabilité réelle et pas d'auditabilité réelle non plus, puisque la trace ne correspond plus au plan verrouillé que vous examineriez.
Fusionner les trois couches en une seule parce que cela semble plus rapide à construire. La tentation de laisser la couche d'exécution également décider de la récupération, en sautant la séparation de l'engagement deux, va à l'encontre du but réel du cadre. Si la planification, l'exécution et la récupération ne sont pas véritablement indépendantes, vous avez construit une boucle qui porte le vocabulaire d'un graphe, pas un véritable graphe.
Rédiger un protocole de récupération suffisamment vague pour que ce ne soit pas vraiment un protocole. « Essayez un nombre raisonnable d'approches alternatives » n'est pas un protocole d'escalade stricte, c'est une instruction molle avec le même mode de défaillance qu'une boucle sans limite, simplement décrite en utilisant le langage de l'ingénierie des graphes. Un véritable protocole nomme le nombre spécifique de tentatives et les conditions spécifiques pour chacune.
Sauter l'évaluation honnête de l'adéquation. Construire un graphe pour une tâche véritablement ouverte et exploratoire parce que l'ingénierie des graphes est le cadre le plus récent et le plus rigoureux en apparence, plutôt que parce que la tâche bénéficie réellement du compromis, produit un système plus difficile à construire qu'une boucle et moins bon pour le travail réel qu'une boucle ne l'aurait été.
L'état honnête des preuves
Pour conclure sur la réserve avec laquelle ce cours a commencé, car elle importe plus ici que dans la plupart des écrits techniques. Les trois engagements décrits ci-dessus sont une proposition réelle et soigneusement raisonnée, analysée sur 70 systèmes réels pour identifier exactement où les boucles échouent silencieusement. Ils n'ont pas encore été validés comme offrant leurs avantages promis à grande échelle en production, de l'aveu même de l'auteur.
Cela ne rend pas le cadre inutile. Cela en fait une conception véritablement prometteuse qui mérite d'être comprise et expérimentée délibérément, en suivant vos propres résultats honnêtement plutôt qu'en supposant que l'argument théorique se traduit automatiquement en pratique. Si vous construisez un système structuré en graphe en utilisant ce cours, la chose la plus précieuse que vous puissiez faire est de mesurer s'il réduit réellement les modes de défaillance spécifiques qu'il cible, les nouvelles tentatives sans limite, la dérive de plan non détectée en cours d'exécution, les décisions de récupération non auditées, par rapport à votre propre utilisation réelle, plutôt que de supposer l'amélioration parce que l'argument est convaincant sur le papier.
Cette discipline, traiter un cadre bien raisonné comme une hypothèse à tester plutôt qu'un fait acquis à adopter sans esprit critique, est en soi la véritable méta-compétence sous-jacente à tout dans ce cours. L'ingénierie des graphes, l'ingénierie des boucles, toute pratique nommée dans ce domaine en évolution rapide, mérite d'être apprise correctement et testée honnêtement par rapport à vos propres résultats, plutôt qu'adoptée uniquement parce qu'elle a un nom et un article derrière elle.
Suivez @cyrilXBT pour les mises à jour sur ce cadre à mesure que des implémentations et des résultats concrets commencent réellement à apparaître.
