La version courte
Le graph engineering, c'est le nom de la semaine pour relier plusieurs boucles d'agents en un système orchestré : branches parallèles, vérificateurs, transferts et conditions d'arrêt. La structure n'a rien de neuf; les moteurs de workflows dessinent ces graphes depuis dix ans. Ce qui a changé, c'est que les nœuds interprètent leurs tâches au lieu de suivre des règles fixes, alors l'état, les vetos et les budgets doivent être explicites.
- Le loop engineering n'est pas mort. Un graphe, c'est ce qu'on obtient quand une seule boucle ne suffit plus, et les graphes contiennent des boucles.
- La structure est ancienne : les moteurs de workflows et les ordonnanceurs de DAG dessinent ces graphes depuis dix ans. Ce qui change, c'est que les nœuds interprètent maintenant leurs tâches.
- Des agents qui vérifient des agents peuvent produire du non-sens organisé à grande échelle. Une partie des preuves doit venir de l'extérieur : vrais tests, vrai argent, vrais humains.
Si vous passez le moindre temps dans la bulle IA de Twitter, vous l’avez vu passer. Neuf mots de Peter Steinberger, le créateur d’OpenClaw, qui avaient attiré 2,6 millions de vues au moment d’enregistrer ma vidéo. Probablement plus maintenant. Puis Hamel Husain, connu pour son travail sur les évaluations d’IA, en a rajouté : « Le loop engineering est mort. Place au graph engineering. » Et voilà, tout mon fil a décidé que nous avions une nouvelle discipline.
Honnêtement, les deux tweets étaient des blagues. Steinberger se moquait de la vitesse à laquelle on renomme les choses. Le prompt engineering est devenu le context engineering, puis le harness engineering, puis le loop engineering. Ce qui veut essentiellement dire la même chose. Mais une blague devient virale quand elle pointe quelque chose de vrai et de partagé, et c’est le cas ici. Même pour nous, sans le budget d’un employé d’OpenAI.
J’ai fait une vidéo sur le loop engineering il y a quelques semaines, et apparemment il est mort avant même que certains d’entre vous aient eu le temps de la regarder. Alors couvrons ce qu’est vraiment le graph engineering et la partie qui mérite votre attention. Une chose a bel et bien changé, discrètement, et il y a des éléments intéressants dans tout ce battage largement exagéré. Ce n’est pas la partie « graphe ».
Un rappel rapide sur les boucles
Comparée au simple prompt d’un modèle, comme dans ChatGPT, une boucle comprend un agent qui travaille vers un objectif, un vérificateur externe qui contrôle le résultat, le travail raté qui repart dans la boucle et une condition d’arrêt qui y met fin. Une boucle, une tâche. Tout l’intérêt était de retirer l’humain de cette boucle, ou au moins de réduire notre charge de révision. Une version de base tient dans le prompt lui-même : demandez au modèle de réviser son travail jusqu’à une condition vérifiable, comme des tests de code qui passent.
Là où les graphes commencent vraiment
La conversation sur les graphes commence quand une seule boucle ne suffit plus, ce qui arrive vite dans les systèmes de revue de code ou les tâches réellement complexes. Disons que Codex travaille sur un changement et ouvre une pull request. Avec la bonne configuration, des analyses automatiques déploient plusieurs agents d’audit en parallèle pour chaque nouvelle PR. Leurs constats convergent vers un vérificateur. Les problèmes confirmés vont à un correcteur, puis à la suite de tests. Les tests échouent, le travail reboucle. Les tests passent, la revue est livrée.
Vous simulez plusieurs employés qui collaborent, se transfèrent le travail, le révisent, font des allers-retours. Cette structure de travail, celle qu’on connaît déjà comme humains, c’est un graphe. Voilà pourquoi « boucles contre graphes » n’est même pas une comparaison pertinente. Les graphes contiennent des boucles. Un graphe, c’est simplement la couche supplémentaire où l’on fait encore plus confiance aux agents pour nous remplacer.
Le concept n’a rien de neuf
C’est mon problème avec la bulle, parfois : le concept lui-même n’est pas nouveau. Le billet Building Effective Agents d’Anthropic, publié en 2024, dessinait déjà chacun de ces patrons : chaînage, routage, parallélisation, orchestrateur-travailleurs, évaluateur-optimiseur. Mettez n’importe lequel sur un tableau blanc et vous obtenez un graphe. Prenez du recul et ce sont des moteurs de workflows, des ordonnanceurs de DAG et des machines à états. Airflow est un graphe de tâches depuis dix ans, avec un outillage plus éprouvé que la plupart des frameworks d’agents actuels.
Ce qui a vraiment changé
Alors pourquoi tout le monde en parle maintenant? À cause de ce qui vit dans les nœuds. Une étape d’un pipeline normal suit des règles fixes. Un agent interprète sa tâche : il peut mal lire l’instruction ou choisir autrement à la prochaine exécution. Et jusqu’à récemment, on cachait tout ça dans un seul contexte de conversation géant, où le modèle était à la fois l’ordonnanceur, la base de données, le journal et le chef de projet.
Ça fonctionne pour les petites tâches. Ça s’effondre dès que le travail s’étale sur des heures, plusieurs dépôts et plusieurs agents. Dessiner le graphe vous force à penser le processus et à le définir une fois pour toutes : ce qui tourne en parallèle, l’état qui circule entre les nœuds, qui peut opposer un veto à un résultat et ce que tout ça coûte avant de s’arrêter. Ces questions ont toujours été là. Les fenêtres de conversation permettaient juste de les remettre à plus tard.
Pour le ressentir concrètement, les workflows dynamiques de Claude Code sont exactement cette idée en vrai : le plan devient un programme qui lance des sous-agents, les exécute en parallèle et reprend les échecs sans que vous surveilliez la conversation. Vous pouvez faire la même chose avec Codex dans un simple prompt avec 5.6 Sol Ultra, en lui demandant de déployer des sous-agents pour telle ou telle tâche et d’exploiter d’autres fils. Vous pouvez même lancer un sous-agent Codex depuis Claude Code avec le MCP Codex, ma façon préférée en ce moment de faire collaborer les modèles sans gaspiller de tokens.
Du non-sens organisé à l’échelle industrielle
La meilleure analyse vient de Carlos Perez, et elle vaut la peine d’être retenue : un graphe d’agents qui vérifient des agents peut produire du non-sens extrêmement organisé. Vingt agents sur le même modèle, lisant le même contexte défaillant, s’entendent entre eux à l’échelle industrielle. Comme on le sait, surtout si vous suivez mes vidéos depuis un moment, les modèles ont tendance à préférer leurs propres réponses, ce qui veut dire qu’ils ont aussi tendance à être d’accord entre eux. Si vous travaillez avec plusieurs agents dans un graphe, il vous faut un système de jugement réfléchi, avec plusieurs réviseurs venant de modèles différents et un contexte frais. Et idéalement, une vérification humaine pour les livraisons importantes.
Carlos proposait un correctif, et je suis d’accord avec lui : une partie des preuves doit venir de l’extérieur du système d’agents. Des tests qui ont réellement tourné. De l’argent qui s’est rendu à la banque. Des clients qui sont restés. Ou un réviseur humain expert qui approuve ou non le résultat final. Il faut quelque chose de déterministe, ou au moins d’extérieur à ce « graphe ». On ne peut pas tout automatiser.
Commencez simple, grandissez quand le travail l’exige
Alors s’il vous plaît, ne répondez pas à un mème en construisant un graphe de quarante agents qui tourne toute la nuit. C’est la meilleure façon d’épuiser votre limite de tokens pour à peu près aucun progrès réel. Même position que d’habitude, celle derrière livrer des agents plutôt que des démos : commencez simple. Une tâche récurrente, un vrai vérificateur, un état que vous pouvez inspecter, une interface avec des métriques rapides à consulter, un arrêt ferme. Faites-la tourner jusqu’à comprendre comment elle échoue. Puis, seulement quand le travail vous y force, faites grandir cette boucle : un réviseur, une branche parallèle, une vérification de sécurité avec droit de veto. À ce moment-là, vous avez un graphe. Vous en aviez toujours un, honnêtement. Vous ne l’aviez juste pas dessiné.
Le loop engineering n’est pas mort. Le graph engineering, c’est le nom de la semaine pour prendre l’orchestration un peu plus au sérieux maintenant qu’on a accès à des modèles comme 5.6 et Fable. La compétence durable, c’est de décider quelles parties de votre système méritent un agent probabiliste et lesquelles doivent rester du code ennuyeux et déterministe. Celle-là ne se fera pas renommer.
Pensez-vous que ce battage autour du graph engineering est du pur hype, ou qu’il y a de vrais nouveaux paradigmes pour travailler avec les LLMs? Dites-moi ce que vous en pensez. Merci d’avoir passé ce temps ici, et on se retrouve dans la prochaine avec un très bon exemple de projet tiré de ma configuration actuelle pour travailler avec des agents.
FAQ
Qu'est-ce que le graph engineering?
Le graph engineering consiste à relier plusieurs boucles d'agents en un système orchestré avec des branches parallèles, des vérificateurs, des transferts, un état partagé et des conditions d'arrêt, plutôt que de tout faire tenir dans un seul contexte de conversation.
Le loop engineering est-il mort?
Non. Un graphe, c'est ce qu'on construit quand une seule boucle ne suffit plus, et tout graphe d'agents utile contient encore des boucles. Les tweets viraux étaient des blagues sur la vitesse à laquelle le domaine renomme les choses.
Quelle est la différence entre une boucle et un graphe d'agents?
Une boucle, c'est un agent qui travaille vers un objectif avec un vérificateur et une condition d'arrêt. Un graphe coordonne plusieurs de ces boucles : ce qui tourne en parallèle, l'état qui circule entre les nœuds, qui peut opposer un veto et quand tout s'arrête.
Faut-il un framework pour construire un graphe d'agents?
Non. Commencez avec une tâche récurrente, un vrai vérificateur, un état que vous pouvez inspecter et un arrêt ferme. Les moteurs de workflows et les ordonnanceurs existants modélisent déjà des graphes, et des outils comme les workflows de Claude Code ou le MCP Codex couvrent l'essentiel des besoins avant qu'un framework dédié devienne nécessaire.
Pourquoi plusieurs agents s'entendent-ils sur de mauvaises réponses?
Les modèles ont tendance à préférer leurs propres réponses, alors des agents bâtis sur le même modèle et lisant le même contexte défaillant se valident entre eux. Mélanger les modèles réviseurs, leur donner un contexte frais et exiger des preuves extérieures au système sont les défenses pratiques.