Structurer les agents IA avec des graphes pour fiabiliser les workflows

Le débat « boucles ou graphes » ne porte pas sur un effet de mode, mais sur qui contrôle le flux de travail. Un graphe définit à l’avance les étapes, la logique de routage et les contrôles, et réserve le jugement du modèle aux moments utiles. De la théorie aux précautions de production, voici comment structurer des agents opérables en pratique.

Points de contrôle, interruptions et effets de bord : les garde-fous

Passer en production exige de capturer l’état du système et de pouvoir reprendre sans tout relancer. Un point de contrôle conserve l’état du graphe à un instant donné et permet de poursuivre après un plantage d’un flux de quarante minutes. Les réducteurs d’état deviennent essentiels lorsque des branches parallèles convergent pour mettre à jour un même champ : ils définissent comment combiner des résultats, par exemple en fusionnant des listes ou en combinant des dictionnaires, sans écraser des mises à jour concurrentes. Certains cadres associent naturellement points de contrôle et interruptions : le flux est mis en pause en attente d’une approbation humaine et reprend ensuite avec le même identifiant de fil, ce qui rend praticables des enchaînements longs avec intervention humaine. Une arête contrôlée par un humain interrompt explicitement l’exécution jusqu’au feu vert. Dernier impératif : surveiller les effets de bord lors des réessais et des reprises. Dès qu’un nœud envoie un email, facture une carte ou déclenche une action externe, cette action doit être idempotente, faute de quoi une reprise peut la rejouer deux fois.

Nœuds, arêtes et état : le triptyque d’un graphe d’agent

Un graphe d’agent repose sur trois éléments : des nœuds, des arêtes et un état partagé. Un nœud est une unité de travail autonome : appel LLM, approbation humaine ou calcul déterministe. Tous n’ont pas besoin d’un modèle : vérifier un seuil d’approbation de facture se code de façon déterministe, tandis que qualifier un email comme demande de remboursement requiert probablement un jugement du modèle. Les arêtes décident de la suite : passage direct sans bifurcation, routage conditionnel (par exemple sceptique vers fusion, puis vers humain), exécution en parallèle, bouclage en cas d’échec avec la raison jointe, capture d’erreur et redirection vers une logique de récupération, ou mise en pause contrôlée par un humain. L’état transporte la tâche initiale, les recherches, les brouillons, les sorties intermédiaires et les verdicts de vérifications : chaque étape lit et écrit dans cette structure plutôt que d’empiler un historique de chat. Ainsi, les nœuds effectuent le travail, les arêtes tracent le chemin, et l’état porte l’information.

Du cas Shopify au flux de travail structuré

Appliqué à la question « faut-il créer un outil de comptabilité IA pour des commerçants Shopify ? », un nœud planificateur découpe la demande en trois piliers : douleur client, concurrents et distribution. Le graphe se scinde en trois nœuds de recherche parallèles dont les résultats alimentent l’état. Un nœud sceptique vérifie ensuite la solidité des affirmations produites. À partir des preuves restantes, un autre nœud rédige une recommandation. La recommandation, avec les recherches et les vérifications sous-jacentes, est présentée à un humain qui décide des suites.

Un modèle unique sans cadre produit des résultats inégaux

Dans une boucle à agent unique, un modèle reçoit une grande question, renvoie une réponse confiante et l’utilisateur valide sans cadre fixe, d’où une qualité variable. L’exemple Shopify illustre qu’un modèle peut décider seul des pistes, collecter et interpréter des preuves, recommander et s’auto-évaluer en une seule exécution, sans contrôle intermédiaire. En pratique, ces boucles se coincent à répéter des étapes improductives, omettent des règles métiers ou manquent de contexte. La réponse proposée n’est pas d’écrire une invite plus fine, mais de réduire la taille des travaux et de coder directement les règles connues. Le modèle ne sert que là où un jugement est requis, par exemple pour interpréter l’ambiguïté ou arbitrer entre des étapes ; il ne contrôle pas l’ensemble du flux. L’ingénierie des graphes fournit alors un flux qui décide de la suite, tandis que le modèle apporte son jugement aux moments utiles.

Ce qui change face aux invites et au contexte

L’ingénierie des invites ajuste le contenu adressé au modèle, tandis que l’ingénierie du contexte ajuste ce que le modèle peut voir, et ces approches restent en un seul tour. Les boucles outillent le modèle, lui donnent mémoire et itération, mais laissent le contrôle dans une exécution continue où il choisit la prochaine étape. Les graphes déplacent ce contrôle vers une structure explicite : nœuds, routage et points de contrôle sont définis à l’avance, et le modèle n’intervient qu’aux points nécessitant un jugement. Le mouvement conseillé consiste à confier la gestion du processus à la structure et à réserver le jugement au modèle là où il est réellement requis.

Public concerné et origine de la controverse

L’approche vise des équipes qui emploient déjà l’IA pour des tâches récurrentes comme la recherche, le support, la revue de code, la rédaction ou la décision sur données désordonnées, et qui constatent les limites des boucles ad hoc. Sans construire d’agent ni adopter un cadre d’orchestration, l’enjeu est de rendre la transition vers un graphe assez concrète pour juger si la structure apporte un gain. La discussion publique a pris de l’ampleur à la mi‑2026, quand Peter Steinberger a opposé boucles et graphes dans une question sur X, suivie quelques heures plus tard par un billet de Hamel Husain proclamant la mort des boucles au profit des graphes. Dans les jours suivants, des contre-arguments, des fils et des vidéos ont soutenu que les boucles n’étaient pas mortes et ont tenté d’expliciter les termes du débat, ramenant la question à ce que recouvre exactement l’ingénierie des graphes et son intérêt pratique.