Graph Engineering : passer d'un simple prompt à 100 agents en production (Guide complet en 8 étapes)

Introduction

Un matin, à 9h00, une tâche de recherche est lancée. Votre agent lit le brief, effectue une recherche, analyse les résultats, relance une recherche, rédige un brouillon, s'auto-corrige et vous livre un rapport à 9h30.

Quatre-vingt-dix minutes de travail pour des étapes où presque rien ne dépendait du reste. Six de ces recherches n'avaient aucun lien entre elles. Quatre auraient pu tourner en même temps que la cinquième chargeait. Le système n'était pas lent : il était mis en file d'attente.

Ce problème n'est ni lié au prompt, ni au modèle. C'est un problème de structure du travail — une architecture que personne ne prend le temps de concevoir.

Voici la méthode en 8 étapes pour concevoir de véritables graphes d'agents performants.

Étape 1 : La plupart de vos liens (edges) sont faux

Le workflow par défaut d'un agent ressemble à une ligne droite, simplement parce que les instructions sont rédigées ainsi : « Fais ceci, puis cela, puis le reste ».

Mais la séquence n'est pas la dépendance. Un lien entre deux étapes ne devrait signifier qu'une seule chose : la seconde étape lit ce que la première a produit. Si ce n'est pas le cas, le lien est imaginaire, et vous le payez en temps de latence.

• Exemple : Pour un sujet de recherche (rapports d'entreprise, papiers académiques, prix des concurrents, avis d'experts), aucune de ces sources ne dépend des autres. Elles alimentent toutes la synthèse finale.
• Écrit sous forme de chaîne, cela fait 4 allers-retours consécutifs. Écrit sous forme de « ventilateur » (fan-out), cela fait un seul aller-retour global suivi d'une fusion.

La règle d'or : Posez une question à chaque flèche de votre système : « L'étape suivante lit-elle réellement la sortie précédente, ou se trouve-t-elle simplement écrite en dessous ? » Supprimez tout lien qui échoue à ce test.

Étape 2 : Un nœud descriptible est un nœud routable

Une fois que le travail est parallélisé, un élément doit décider où va chaque résultat. Cette décision implique de lire le résultat, qui doit donc posséder un format strict.

Un nœud qui renvoie du texte brut (prose) force le nœud suivant à l'interpréter, ce qui génère un appel de modèle supplémentaire et une source d'erreur inutile.

Un nœud dans un graphe fonctionnel possède quatre propriétés :

1. Un seul travail, simple au point de pouvoir le nommer en trois mots.
2. Une entrée explicite, pour savoir précisément de quoi il a besoin.
3. Une sortie structurée, pour que le graphe puisse faire des choix de branchement sans avoir à deviner ce que le texte signifie.
4. Un état d'échec nommé, où une erreur devient une donnée exploitable (ex: not_found) plutôt qu'une exception qui bloque tout le système.

Étape 3 : Quatre formes suffisent pour tout couvrir

Inutile de multiplier les modèles complexes. Les graphes en production combinent généralement quatre structures de base :

• La chaîne (Chain) : Chaque étape dépend strictement de la précédente (rare et plus courte qu'on ne le pense).
• Le ventilateur (Fan-out / Fan-in) : Une tâche se divise en branches indépendantes qui s'exécutent en parallèle puis fusionnent (idéal pour la recherche, l'audit, la comparaison). C'est ce modèle qui permet d'atteindre l'échelle des 100 agents.
• Le routeur (Router) : Le système analyse la requête et choisit le chemin optimal (court pour les tâches simples, long pour les tâches à haut risque).
• Le cycle contrôlé (Controlled Cycle) : Un nœud se répète jusqu'à ce que des critères objectifs prouvent que la tâche est terminée.

Étape 4 : La fusion (Join) est une décision, pas une formalité

Le piège classique consiste à placer une barrière bloquante après chaque étape, transformant discrètement votre structure parallèle en une simple ligne droite.

• Une fusion est nécessaire uniquement lorsque l'étape suivante a besoin de l'ensemble complet des données (pour dédupliquer, classer, comparer ou valider une couverture).
• Si chaque résultat individuel peut continuer sa route de façon autonome, laissez-le en streaming. En cas d'échec d'une branche, les 99 autres ne doivent pas s'effondrer.

Étape 5 : Laissez le modèle juger, laissez le graphe décider

Ne déléguez jamais le contrôle du système au modèle.

• Le classificateur (le modèle) : Il est probabiliste et renvoie une étiquette (label).
• La table de routage (le code) : Elle est déterministe et associe des étiquettes à des chemins précis (faible risque = chemin court, risque élevé = audit complet, inconnu = intervention humaine).

Cette séparation rend le système parfaitement explicable en cas de dysfonctionnement.

Étape 6 : Le nœud le plus précieux ne produit rien

Dans tout graphe qui survit à la production, le nœud au plus fort effet de levier est un vérificateur. Il n'ajoute aucun contenu : son unique rôle est d'empêcher un travail de mauvaise qualité de progresser en aval.

• Séparez toujours les rôles : ne demandez jamais au même agent (et au même contexte) de produire, d'approuver et de publier. Un agent générant du contenu aura toujours tendance à s'auto-valider.

Étape 7 : L'état (State) est la partie cachée des schémas

Un graphe doit maintenir un état persistant et robuste : quel est le nœud actuel, lesquels sont terminés, quels artéfacts existent, quel budget de tokens a été consommé, et combien de tentatives ont été effectuées.

Deux règles de survie :

1. Ne pas passer de transcriptions textuelles entre les nœuds, mais des références (identifiants).
2. Rendre les écritures idempotentes pour qu'une relance (retry) n'altère pas ou ne duplique pas les données.

Étape 8 : La structure est votre modèle de coût

L'architecture multi-agents n'est pas magique ni économique par défaut. Des rapports (comme ceux d'Anthropic) montrent qu'un système de recherche multi-agents surpasse un agent unique sur les tâches larges, mais consomme environ 15 fois plus de tokens.

Le compromis financier implique de combiner :

• Des modèles économiques pour l'extraction et le formatage.
• Des modèles puissants pour la décomposition et la vérification.
• Le graphe complet uniquement lorsque la valeur de la tâche justifie la dépense.

Conclusion : Quand faut-il utiliser un graphe ?

• Restez sur un agent unique (boucle simple) si la tâche est courte, que le contexte tient en une seule vue, qu'il n'y a pas de branches indépendantes et que l'échec ne coûte rien.
• Passez au graphe lorsque le travail s'exécute en parallèle, que différents nœuds requièrent des outils spécifiques, que les sorties exigent une vérification indépendante ou que le processus doit survivre à des interruptions.

Passer d'un prompt à 100 agents ne consiste pas à en invoquer davantage, mais à identifier et supprimer les faux liens de dépendance.

Par Aghilas AZZOUG