L'ingénierie de graphes : le nouveau nom d'un travail que nous menons déjà.

Tous les quelques mois, le monde de l'outillage IA converge vers un nom pour quelque chose que les praticiens faisaient déjà. L'« ingénierie de prompt » a reçu son nom des années après que les gens ont commencé à la pratiquer. L'« ingénierie de contexte » a reçu le sien en 2025. Celle qui se consolide en ce moment, c'est l'ingénierie de graphes, et cette fois, l'étiquette est arrivée pour un travail que notre propre pile exécute quotidiennement.

Six chaînes, deux semaines, une étiquette.

La définition sur laquelle la vague s'est arrêtée : plutôt que de confier un objectif à un seul agent qui le traite en série, on décompose la tâche en un graphe. Chaque nœud est un agent qui travaille dans sa propre fenêtre de contexte isolée. Chaque arête est une décision sur ce qui avance.

Les vidéos présentent les graphes comme le successeur de l'« ingénierie de boucle », un agent unique qui itère jusqu'à la fin. Nous le formulerions avec moins de drame : le fan-out complète l'itération, il ne la remplace pas. Une boucle reste le bon outil quand chaque étape dépend de la précédente. Un graphe mérite sa place quand le travail contient des sous-tâches véritablement indépendantes, parce que des sous-tâches indépendantes peuvent tourner en parallèle, dans des contextes propres, sans se contaminer mutuellement.

Si votre équipe utilise un outil de codage agentique qui déploie des sous-agents, vous avez déjà exécuté un graphe sans le nommer ainsi. Ce que la nouvelle étiquette ajoute, c'est une façon de parler des formes de manière délibérée, et c'est dans les formes que vivent les décisions utiles.

Les nœuds sont des fenêtres de contexte. Les arêtes sont des décisions.

Deux formes couvrent l'essentiel de ce que nous exécutons en production.

Le diamant : déployer en éventail, puis fusionner. Un brief se divise en plusieurs nœuds spécialistes qui travaillent en parallèle, et un nœud final synthétise ce qui revient. Notre pipeline interne de révision de code est un diamant. Le brief se déploie vers des agents repéreurs, un par dimension de révision (exactitude, performance, sécurité). Chaque constat passe ensuite à un agent vérificateur distinct dont la seule instruction est de tenter de le réfuter. Seuls les constats qui survivent à la réfutation atteignent le synthétiseur qui rédige le rapport fusionné.

La barrière : même problème, plusieurs angles, attendre que tous rapportent. La seconde forme envoie la même entrée à plusieurs agents qui l'examinent sous des angles différents, et rien n'avance tant que chaque angle n'a pas rapporté. Nous l'utilisons quand un livrable peut échouer de plus d'une façon : une page française passe par une passe linguistique, une passe de parité technique et une passe de conformité, et la fusion ne se déclenche qu'une fois les trois complétées. La barrière coûte du temps d'attente, elle est donc réservée aux cas où un angle manquant coûte plus cher qu'une réponse lente.

Pourquoi les contextes isolés comptent mérite un paragraphe clair, parce que c'est le mécanisme réel. Un agent qui a passé une heure à construire quelque chose porte cette heure dans son contexte : ses suppositions, ses raccourcis, ses raisons. Demandez au même agent de réviser son propre travail, et il relit ses raisons et les trouve convaincantes. Un nœud frais révise l'artefact, pas le parcours. C'est la structure en graphe qui vous procure cette séparation.

Ne jamais dégrader le juge.

Une fois que chaque nœud est son propre agent, chaque nœud peut faire tourner son propre modèle, et la tentation s'écrit d'elle-même : mettre un modèle bon marché sur les nœuds de révision, puisque « vérifier est plus facile que construire ». La vidéo d'AI LABS contient le meilleur témoignage de praticien que nous ayons vu sur pourquoi ça échoue, et c'est la raison d'être de cette note.

La chaîne a fait tourner la même compétence de révision d'interface deux fois contre sa propre réalisation : une fois sur un modèle rapide bon marché, une fois sur leur modèle le plus puissant.[1] L'exécution bon marché a retourné une longue liste de constats. L'exécution puissante en a retourné une courte. La longue liste semblait plus exhaustive jusqu'à ce qu'ils la lisent : la plupart des constats signalaient des choix délibérés que le code environnant expliquait, un contexte que le modèle puissant avait saisi et que le modèle bon marché avait manqué. Leur conclusion, dans leurs mots : « la révision bon marché ne nous avait rien fait économiser, parce que maintenant la révision elle-même devait être révisée » (notre traduction).

À l'intérieur d'un graphe, cet échec se démultiplie. Plusieurs nœuds s'auto-vérifient avec la même compétence de révision. Un juge faible n'échoue pas discrètement; il inonde le graphe de faux positifs plausibles, les agents en aval brûlent des jetons à corriger ce qui n'a jamais été brisé, et au moment où la sortie fusionnée paraît fautive, impossible de dire quel nœud en est à l'origine. Une anecdote, une chaîne, aucun chiffre. Mais elle atterrit sur un terrain que la recherche mesurée a déjà préparé : notre note sur le biais du juge couvrait une étude menée par Cambridge qui a chiffré à quel point les juges échouent sans grâce, et la conclusion partagée est que la qualité du juge est une propriété structurelle du pipeline, pas un luxe.

Notre propre règle de routage, en place depuis des mois et renforcée chaque fois que nous la testons : les modèles bon marché vont sur les étapes mécaniques, et le nœud juge fait tourner le modèle le plus puissant, au réglage de raisonnement le plus élevé que nous pouvons nous permettre. Un vérificateur est aussi prompté pour réfuter, pas pour confirmer, et instruit de pencher par défaut vers « réfuté » en cas d'incertitude. Un juge qui veut dire oui n'est presque plus un juge.

Coût unitaire en baisse. Coût total en hausse.

Le choix de modèle par nœud fait baisser le prix de chaque appel, et chaque vidéo d'ingénierie de graphes présente ça comme le gain. Le chiffre qui compte pointe dans l'autre direction : un graphe existe pour dépenser plus de calcul sur un seul livrable. Cinq nœuds relisent du matériel qui se chevauche dans cinq contextes distincts, les vérificateurs réexaminent ce que les repéreurs ont produit, et la fusion relit tout de nouveau. La facture de jetons atterrit à un multiple de ce qu'un seul agent aurait brûlé sur la même tâche.

Reconnaissons le mérite là où il est dû : la vidéo d'AI LABS est franche là-dessus, plus franche encore dans sa description qu'à l'écran : « Côté tarification API, ne faites tourner aucun graphe. Côté abonnement, attendez-vous à atteindre vos limites beaucoup plus tôt. »[1] C'est juste dans l'orientation, et dit honnêtement par une chaîne qui profite du fait que les gens en fassent tourner davantage.

Notre version du même conseil : budgétez le livrable, pas l'appel API. Un graphe se justifie quand le coût d'échec du livrable justifie le multiple : un changement de code en production, un contrat, une page qui sort sous le nom de votre client. Il ne se justifie pas pour un travail qu'un seul agent réussit neuf fois sur dix, et il ne remplace jamais la question de savoir si la tâche se décompose du tout. Les études contrôlées que nous avons couvertes en juin montraient que la coordination ne paie que sous des conditions structurelles étroites, et que c'est la décomposabilité, pas la complexité de la tâche, qui prédit le rendement. L'ingénierie de graphes, faite honnêtement, c'est la discipline de trouver ces conditions étroites délibérément.

Quatre règles avant de déployer en éventail.

1. Ne déployez en éventail que ce qui est indépendant.

   Si l'étape B a besoin de la sortie de l'étape A, les dessiner comme des nœuds parallèles n'apporte que du surcoût de coordination. La forme du graphe doit découler de la structure de dépendance réelle de la tâche, jamais l'inverse.

   cible · la forme suit les dépendances, pas l'ambition
2. Mettez votre modèle le plus puissant sur le nœud juge.

   Acheminez les modèles bon marché vers les étapes mécaniques : extraction, mise en forme, génération de premier brouillon. Le seul endroit où économiser vous coûte tout, c'est le nœud dont la sortie décide de la valeur de la sortie des autres nœuds.

   cible · juge = modèle le plus puissant, effort maximal, prompté pour réfuter
3. Budgétez le livrable, pas l'appel.

   Attendez-vous à ce que le graphe coûte un multiple d'un seul agent sur la même tâche. Décidez que le livrable vaut le multiple avant de dessiner le graphe, et gardez une simple boucle comme option par défaut pour tout ce qui ne le vaut pas.

   cible · coût d'échec du livrable > multiple de jetons du graphe
4. Journalisez la sortie de chaque nœud.

   Quand un résultat fusionné est fautif, vous devez pouvoir retracer quel nœud en est à l'origine. Conservez la sortie brute de chaque nœud à côté de la fusion. Et sachez où en est honnêtement l'état de l'art : attribuer une mauvaise fusion à son nœud source est le maillon le plus faible de cette pratique partout, y compris ici.

   cible · chaque fusion traçable jusqu'à ses entrées

Ce que nous n'affirmons pas.

L'histoire du nœud juge est l'anecdote d'une seule chaîne, sans chiffres derrière. Nous la répétons parce qu'elle correspond à ce que prédit la recherche mesurée sur le biais des juges et à ce que notre propre pratique continue de confirmer, pas parce qu'elle prouve quoi que ce soit à elle seule. Nos exemples de production relèvent de notre pratique, pas d'un banc d'essai contrôlé : nous n'avons pas fait tourner le contrefactuel où le graphe de révision tourne sur des juges bon marché pour compter les dégâts, et nous n'allons pas prétendre le contraire.

L'étiquette elle-même ne tiendra peut-être pas. L'« ingénierie de graphes » est une vague dans un coin d'Internet qui produit une nouvelle vague chaque mois. Les formes qu'elle recouvre sont plus anciennes que le nom et lui survivront de toute façon, ce qui est précisément pourquoi le nom vaut la peine d'être appris maintenant : le vocabulaire se consolide pendant que les pratiques restent inégalement comprises, et c'est dans cet écart que se vendent les mauvais fan-outs.

Si vous êtes en train de décider si un workflow de votre boîte mérite un graphe ou une boucle, le formulaire de contact est le chemin le plus rapide. Nous faisons des revues de 30 minutes des piles d'agents en production, gratuitement.