# Comment concevoir un graphe d’agents d’IA?

Date: 2026-09-10 · Author: Robert Scales · https://guidetoartificialintelligence.com/fr/apprendre/concevoir-graphe-agents-ia/

**Answer:** Partez des unités de travail et des vérifications que chacune doit réussir, puis ajoutez les nœuds qui les relient, soit un découpeur qui divise la tâche en unités, des travailleurs qui roulent en parallèle quand les unités sont indépendantes, des étapes de code ordinaire et des barrières capables de faire échouer une unité. Renvoyez une unité en échec seule, avec la preuve de ce qui a échoué, transformez les échecs répétés en leçons pour la consigne, et gardez une personne à l’étape où une erreur ferait de vrais dégâts.

Une seule boucle d’IA rend une pièce de travail correcte : la produire, la vérifier, corriger ce qui a échoué, recommencer. Les vrais mandats contiennent en général plusieurs pièces. Trente articles d’aide à mettre à jour après un changement de prix, quarante sources à lire pour un rapport, une douzaine de fichiers à modifier dans une base de code. Un **graphe** est le plan qui organise ces pièces : quelles unités de travail existent, quelle étape s’occupe de chacune, ce qui peut rouler en même temps, où se trouvent les vérifications et où va le travail qui échoue.

Le mot vient des mathématiques, où un graphe est un ensemble de **nœuds** (des points) reliés par des **arêtes** (des liens). Dans un système d’agents, un nœud est une étape qui fait quelque chose, soit un appel au modèle, soit du code ordinaire, et une arête indique quelle étape roule ensuite. Des cadriciels comme LangGraph construisent explicitement les flux de travail de cette façon, et le guide d’Anthropic sur la construction d’agents décrit les formes courantes. Nul besoin d’un cadriciel pour en concevoir un, toutefois. Les questions de conception viennent d’abord.

## Les quatre types de nœuds

La plupart des graphes d’agents se construisent à partir de quatre rôles.

| Rôle | Ce qu’il fait | En général | Exemple |
|---|---|---|---|
| Découpeur | Divise la tâche en unités et rédige une consigne pour chacune | Un modèle, vérifié par du code | Dresse la liste des 30 articles qui mentionnent l’ancien prix |
| Travailleur | Traite une unité | Un modèle | Réécrit un article |
| Étape de code | Fait quelque chose d’exact et de reproductible | Du code ordinaire | Récupère une page, compte les mots, fusionne les résultats |
| Barrière | Décide si une unité passe | Du code d’abord, un modèle juge seulement là où le code ne peut pas trancher | Fait échouer tout article qui affiche encore l’ancien prix |

Anthropic appelle l’ensemble des deux premiers le schéma **orchestrateur-travailleurs** (*orchestrator-workers*) : un modèle central divise la tâche, confie les morceaux à des travailleurs et combine ce qui revient. Son système de recherche multi-agents fonctionne ainsi, avec un agent principal qui planifie la recherche et lance plusieurs sous-agents qui cherchent en même temps, chacun avec sa propre fenêtre de contexte.

Deux remarques sur le découpeur. Ce qu’il produit est une liste, alors vérifiez-la avec du code : couvre-t-elle tous les éléments voulus, sans doublons? Et la consigne de chaque unité doit se suffire à elle-même. Anthropic rapporte que des consignes vagues données à ses sous-agents de recherche les menaient à refaire le travail des autres ou à laisser des trous; chacun avait besoin d’un objectif, d’un format de sortie, d’indications sur les outils et les sources, et de limites claires.

Les barrières méritent le plus de soin, parce qu’un graphe n’est fiable que dans la mesure où ses vérifications le sont. Une barrière n’est réelle que si elle peut faire échouer une unité par elle-même, avec des preuves que le travailleur ne peut contester, comme un test qui échoue, une citation absente de la source ou un fichier modifié hors du plan. L’article qui accompagne celui-ci sur [ce qui rend une vérification réelle](/fr/apprendre/verification-reelle-boucle-ia/) traite la question en détail.

## Décider de ce qui roule en parallèle

Les unités qui ne dépendent pas les unes des autres peuvent rouler en même temps. Anthropic appelle cela le **sectionnement** (*sectioning*), l’une de ses deux formes de travail parallèle (l’autre, le **vote**, exécute la même tâche plusieurs fois et compare les résultats). Dans LangGraph, un nœud peut se déployer vers le même travailleur une fois par élément avec `Send`, chaque copie recevant sa propre entrée, et un **réducteur** (*reducer*, une petite fonction qui indique comment combiner les résultats) recueille les sorties, par exemple en ajoutant chacune à une liste. La documentation de l’Agents SDK d’OpenAI montre la version en Python ordinaire : exécuter ensemble des agents indépendants avec `asyncio.gather`, et garder le déroulement dans votre propre code quand vous voulez une vitesse, un coût et un comportement prévisibles.

Le travail parallèle a deux coûts réels, et la conception doit tenir compte des deux.

**Les jetons.** Anthropic rapporte que sa configuration de recherche multi-agents consommait environ quinze fois plus de jetons qu’une conversation ordinaire. Cela rapporte pour de vastes questions de recherche, beaucoup moins pour de petits mandats.

**La cohérence.** Des travailleurs qui ne voient pas le travail des autres prennent leurs décisions chacun de leur côté, et ces décisions peuvent se contredire. Cognition, l’entreprise derrière l’agent de programmation Devin, a soutenu en 2025 que cela rend fragiles les sous-agents en parallèle pour des tâches comme l’écriture de code, où chaque partie dépend de choix faits dans les autres. Anthropic a fait une remarque voisine : les tâches où tous les agents ont besoin du même contexte, ce qui inclut la plupart des tâches de programmation, se prêtent mal pour l’instant à un partage entre agents.

La règle pratique : ne découpez que là où les unités sont vraiment indépendantes, et inscrivez toute décision commune (le nouveau prix, le ton, la convention de nommage) dans la consigne de chaque unité avant que les travailleurs commencent. Ajoutez ensuite, après la jonction, une étape de code qui vérifie les unités les unes par rapport aux autres, et pas seulement une à une.

## Deux chemins de retour : la correction et l’apprentissage

Un graphe a deux sortes de chemins de retour, et les confondre est une erreur de conception courante.

| | Arête de correction | Arête d’apprentissage |
|---|---|---|
| But | Réparer cette unité maintenant | Empêcher le même échec dans les unités futures |
| Transporte | L’unité, la preuve de ce qui a échoué, la portée de la correction | Une courte leçon |
| Va vers | Le travailleur, pour un essai de plus | La consigne que lit chaque travailleur |
| Exemple | « Le paragraphe 3 indique encore 10 $/mois; ne change que ce paragraphe » | « Écris les prix sous la forme 12 $/mois, jamais 12 dollars » |
| Limite | Un nombre fixe d’essais, puis une personne | Revue avant de devenir permanente |

L’**arête de correction** est la boucle courte. Elle doit être précise : ce qui a échoué (la sortie de la barrière, copiée au complet) et la part de l’unité qui peut changer. « Corrige le prix au paragraphe 3 » invite un petit changement vérifiable; « essaie encore » invite une réécriture qui peut briser ce qui avait déjà réussi.

L’**arête d’apprentissage** est la boucle longue. Quand plusieurs unités échouent de la même façon, la cause est en général la consigne, pas les travailleurs. L’article sur Reflexion (Shinn et ses collègues, 2023) en a montré une forme : un agent transforme la rétroaction d’un essai raté en une courte réflexion écrite, la garde en mémoire et la lit avant l’essai suivant. Les agents de programmation de longue durée d’Anthropic en utilisent une forme plus simple, un fichier de progression et un historique git que chaque nouvelle séance lit avant de se mettre au travail. Dans un graphe, la leçon entre dans la consigne commune, pour que les unités qui n’ont pas encore commencé en profitent aussi. Gardez les leçons courtes, et faites-les revoir par une personne avant qu’elles deviennent des consignes permanentes, parce qu’une mauvaise leçon se propage à toutes les unités.

## Renvoyer une unité en échec, pas tout le lot

Quand trois unités sur trente échouent à une barrière, renvoyez ces trois-là. Relancer les trente gaspille des jetons et, pire, donne à vingt-sept unités qui avaient déjà réussi l’occasion de revenir différentes et d’échouer. Pour que ce soit possible, conservez séparément le statut, la sortie, le nombre d’essais et le dernier échec de chaque unité, plutôt qu’un seul bloc de résultats partagé.

Fixez une limite d’essais par unité (deux ou trois, c’est courant) et dirigez tout ce qui l’atteint vers une personne, avec l’historique complet des échecs. Ajoutez aussi une limite pour toute l’exécution. LangGraph, par exemple, arrête une exécution qui dépasse sa limite de récursion, un plafond du nombre d’étapes, et lève une erreur. Anthropic note que les limites du nombre d’itérations sont une façon courante de garder les agents sous contrôle.

Le déroulement tient sur une page de Python ordinaire. Dans cette ébauche, `split`, `work`, les barrières et `lesson_from` sont des fonctions que vous fournissez; chaque barrière renvoie une liste de messages d’échec, vide quand l’unité réussit.

```python
from concurrent.futures import ThreadPoolExecutor

MAX_ATTEMPTS = 3

def run_graph(job, split, work, gates, lesson_from):
    units = split(job)                      # découpeur : liste de {"id", "task"}
    lessons = []                            # arête d'apprentissage : partagée par les unités futures
    results, attempts, evidence = {}, {}, {}
    pending = [u["id"] for u in units]
    by_id = {u["id"]: u for u in units}

    while pending:
        with ThreadPoolExecutor() as pool:  # les travailleurs roulent en parallèle
            outs = pool.map(lambda uid: work(by_id[uid], lessons, evidence.get(uid)), pending)
            outputs = dict(zip(pending, outs))
        retry = []
        for uid, out in outputs.items():
            attempts[uid] = attempts.get(uid, 0) + 1
            failed = [msg for gate in gates for msg in gate(by_id[uid], out)]
            if not failed:
                results[uid] = out
            elif attempts[uid] < MAX_ATTEMPTS:
                evidence[uid] = failed      # arête de correction : cette unité seulement
                retry.append(uid)
            else:
                results[uid] = {"escalate": failed}
        new = lesson_from([evidence[u] for u in retry])
        if new and new not in lessons:
            lessons.append(new)
        pending = retry
    return results                          # ensuite : une seule revue humaine du résultat assemblé
```

Seules les unités de `retry` refont un tour, chacune avec sa propre preuve. Les unités qui atteignent `MAX_ATTEMPTS` ressortent marquées pour être remises à une personne au lieu de tourner sans fin.

## Un exemple concret : mettre à jour trente articles d’aide

Une entreprise de logiciels fait passer son forfait de base de 10 $ à 12 $ par mois. Son centre d’aide compte des centaines d’articles; certains mentionnent le prix.

1. **Découpeur (code, puis modèle).** Une recherche trouve chaque article qui contient « 10 $ » ou « 10 dollars ». Un modèle lit chaque résultat et ne garde que ceux qui portent sur le prix du forfait de base, en rédigeant une consigne d’une ligne par article. Une vérification en code confirme que chaque résultat de recherche a été soit gardé, soit écarté avec une raison. Résultat : 30 unités.
2. **Travailleurs (modèle, en parallèle).** Chaque travailleur reçoit un article, sa consigne et les décisions communes : le nouveau prix, la date d’entrée en vigueur, la formulation pour la clientèle existante.
3. **Barrières en code.** Chaque article réécrit ne doit plus contenir l’ancien prix, doit contenir « 12 $/mois » là où figurait l’ancien prix, ne doit différer de l’original que dans les paragraphes qui mentionnaient le prix, et doit garder tous ses liens fonctionnels.
4. **Barrière de jugement (modèle).** Un modèle distinct vérifie une seule question par article, réussi ou échoué : l’article dit-il encore quelque chose qui contredit le nouveau prix, comme un total annuel calculé à partir de l’ancien?
5. **Arête de correction.** Disons que quatre articles échouent : trois affichent encore un total annuel de 120 $, un a modifié un paragraphe qu’il ne devait pas toucher. Chacun repart seul, avec le message de la barrière et le paragraphe qu’il peut changer.
6. **Arête d’apprentissage.** Trois échecs ont la même cause, le total annuel. La leçon « mets aussi à jour les totaux annuels : 144 $/an » est ajoutée à la consigne, après un coup d’œil d’une personne, pour que les articles encore en cours en profitent.
7. **Jonction et barrière humaine.** Une étape de code rassemble les trente changements dans une seule page de revue, avec un diff par article, les résultats des barrières et les quatre articles qui ont dû être corrigés. Une personne revoit cette page une fois et approuve la publication. La publication est la seule étape qui atteint la clientèle, c’est donc la seule qu’une personne doit approuver.

La consigne que reçoit chaque travailleur peut suivre un gabarit fixe :

```prompt
Tu mets à jour un article du centre d’aide.
Unité : {article_id} — {title}
Objectif : {consigne d’une ligne du découpeur}
Décisions communes (applique-les exactement) : {nouveau prix, date, formulation}
Leçons tirées des unités précédentes : {leçons, ou « aucune pour l’instant »}
Portée : ne modifie que les paragraphes qui mentionnent le prix. Laisse toutes les autres phrases telles quelles.
Vérifications que ta sortie devra réussir : ancien prix absent, « 12 $/mois » présent, aucun changement hors des paragraphes sur le prix, liens inchangés.
{S’il s’agit d’un nouvel essai : « Ton dernier essai a échoué à ces vérifications : » suivi de la sortie de la barrière, mot pour mot.}
Rends le texte complet de l’article et rien d’autre.
```

> **À essayer :** prenez un mandat que vous confieriez à plusieurs agents et remplissez quatre colonnes avant d’écrire la moindre ligne de code : les unités, la vérification que chaque unité doit réussir, la preuve que renvoie une vérification en échec, et la seule étape qu’une personne doit approuver. Si une colonne est difficile à remplir, le graphe n’est pas prêt à être construit.

## Quand une seule boucle d’agent vaut-elle mieux qu’un graphe?

Souvent. Le conseil d’Anthropic est de commencer par la conception la plus simple qui fonctionne et de n’ajouter de la structure que si elle améliore clairement les résultats, et le graphe ci-dessus comporte plus de structure que bien des mandats n’en demandent. Si le travail est petit, ou si chaque partie dépend de décisions prises dans les autres, un seul agent qui avance dans la tâche dans l’ordre, avec de vraies vérifications en chemin, coûte en général moins cher et donne un résultat plus cohérent. L’argument de Cognition contre les sous-agents en parallèle est le plus fort justement dans ces cas : quand le contexte est partagé entre plusieurs agents, les décisions divergent.

Un graphe vaut son coût quand les unités sont vraiment indépendantes, qu’elles sont assez nombreuses pour que le travail parallèle fasse gagner du temps réel, et que chaque unité a une vérification capable de la faire échouer par elle-même. La recherche dans de nombreuses sources correspond à cette description; bien des tâches de programmation, non.

Il existe aussi une voie mitoyenne. Un seul agent principal peut confier des questions étroites, en lecture seule, à des assistants (trouver tous les fichiers qui utilisent cette fonction, résumer ce document) tout en gardant toutes les décisions et toutes les modifications dans son propre fil. On conserve ainsi une seule ligne de décisions cohérente tout en se faisant aider pour le travail qui se découpe proprement. Le [guide sur les flux de travail multi-agents](/fr/apprendre/construire-flux-de-travail-multi-agents/) de ce site présente les éléments de base si vous décidez qu’un graphe convient.

## Sources

- Building effective agents: https://www.anthropic.com/engineering/building-effective-agents
- How we built our multi-agent research system: https://www.anthropic.com/engineering/multi-agent-research-system
- Graph API overview (LangGraph docs source): https://github.com/langchain-ai/docs/blob/7aee47ad2fe0f18f297fa8f3d96598dc5d27dfa3/src/oss/langgraph/graph-api.mdx
- Agent orchestration (OpenAI Agents SDK documentation): https://github.com/openai/openai-agents-python/blob/fc6afebc48d5526bdfa0aea9315cb039c61d58b5/docs/multi_agent.md
- Reflexion: Language Agents with Verbal Reinforcement Learning: https://arxiv.org/abs/2303.11366v4
- Don't Build Multi-Agents: https://cognition.ai/blog/dont-build-multi-agents
- Effective harnesses for long-running agents: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

---

Tiré du Guide de l’intelligence artificielle, par Robert Scales, publié par Holistic Hybrid inc. Partage et adaptation permis selon la licence CC BY-NC-SA 4.0 (https://creativecommons.org/licenses/by-nc-sa/4.0/) : citez le guide, mettez un lien vers https://guidetoartificialintelligence.com/fr/apprendre/concevoir-graphe-agents-ia/, pas d’usage commercial sans permission, et gardez la même licence.