Agents IA et systèmes multi-agents, expliqués

Un agent IA n'est pas un modèle de plus : c'est un modèle de langage placé dans une boucle où il raisonne, appelle des outils, observe les résultats et décide de la suite — jusqu'à atteindre un objectif. Cette autonomie change tout : elle ouvre des problèmes ouverts qu'aucun prompt unique ne résout, mais elle introduit des coûts, des dérives et des boucles qu'il faut savoir maîtriser. Cet article explique ce qu'est un agent, comment fonctionne sa boucle (ReAct, outils, planification, mémoire, réflexion), quels patrons multi-agents existent, quels frameworks les implémentent, comment évaluer ces systèmes — et surtout quand un seul agent vaut mieux que plusieurs.

Qu'est-ce qu'un agent LLM ?

Un agent est un système où un LLM dirige dynamiquement son propre processus et son usage des outils, par opposition à un workflow, où des LLM et des outils sont orchestrés par un chemin de code prédéfini. La distinction d'Anthropic est utile : le workflow est prévisible et adapté aux tâches bien cadrées ; l'agent est flexible et adapté aux problèmes ouverts où l'on ne peut pas prédire à l'avance le nombre d'étapes.

Le bloc de base est le LLM augmenté : un modèle enrichi de trois capacités — la récupération (chercher de l'information), les outils (agir sur le monde), et la mémoire (retenir le contexte). Ces augmentations doivent avoir des interfaces claires et bien documentées ; le Model Context Protocol (MCP) sert précisément à brancher des outils tiers de façon standard.

Figure : la boucle perception → planification → action d'un agent.

Concrètement, un agent reçoit une consigne, planifie (raisonnement), agit (appel d'outil), observe (résultat) et recommence. L'arrêt survient quand l'objectif est atteint, qu'un budget est épuisé, ou qu'une garde-fou se déclenche.

Workflows avant agents : cinq patrons composables

Avant de donner les clés à un agent autonome, Anthropic recommande de couvrir un maximum de besoins avec des workflows simples et composables. Cinq patrons reviennent constamment :

• Chaînage de prompts (prompt chaining) : on découpe la tâche en étapes séquentielles, avec des contrôles programmés (« gates ») entre les étapes. Idéal quand la tâche se décompose proprement en sous-tâches fixes.
• Routage (routing) : un classifieur dirige l'entrée vers le traitement spécialisé adéquat, ce qui sépare les préoccupations et permet d'optimiser chaque prompt pour son type d'entrée.
• Parallélisation : exécuter des sous-tâches en parallèle (sectioning) ou répéter la même tâche pour voter (voting), pour gagner en vitesse ou en confiance.
• Orchestrateur-workers : un LLM central décompose dynamiquement une tâche imprévisible et délègue à des workers — détaillé plus bas dans la partie multi-agents.
• Évaluateur-optimiseur : un LLM génère, un autre évalue et renvoie un retour, en boucle, tant que des critères clairs montrent une amélioration.

La règle implicite : un agent n'est qu'un cas particulier, le plus autonome, de cette famille. On y vient seulement quand la flexibilité d'un modèle qui dirige lui-même son processus apporte un gain démontré sur ces workflows.

La boucle perception → planification → action

La boucle agentique est un cycle simple répété :

1. Percevoir : lire l'état courant (consigne, historique, dernière observation).
2. Planifier : décider de la prochaine étape (raisonnement, choix d'outil).
3. Agir : exécuter l'action (appel d'outil, écriture de code, requête).
4. Observer : récupérer le résultat de l'environnement, l'injecter dans le contexte.

Ce qui distingue un agent d'un simple appel de modèle, c'est que le résultat de l'action revient dans la boucle. L'agent s'appuie sur ce retour d'environnement (résultat d'outil, sortie d'exécution de code) pour avancer pas à pas, ce qui le rend pertinent pour les problèmes « où il est difficile, voire impossible, de prédire le nombre d'étapes nécessaires ».

Vu de plus près, une implémentation minimale ressemble à ceci :

async function runAgent(goal: string, maxSteps = 12): Promise<string> {
  const history: Turn[] = [{ role: 'user', content: goal }];
  for (let step = 0; step < maxSteps; step++) {
    const decision = await model.next(history, tools); // pense + choisit
    if (decision.type === 'final') return decision.answer; // critère d'arrêt
    const observation = await runTool(decision.tool, decision.input); // agit
    history.push(decision, { role: 'tool', content: observation }); // observe
  }
  throw new Error('budget d\'étapes épuisé'); // garde-fou anti-boucle
}

Trois éléments y sont non négociables en production : un critère d'arrêt clair (final), un plafond d'itérations (maxSteps) et la ré-injection de l'observation dans l'historique. Sans eux, l'agent boucle ou diverge.

ReAct : raisonner ET agir

ReAct (Reasoning + Acting, Yao et al., 2022) est devenu le standard de fait des agents LLM. L'idée : entrelacer traces de raisonnement (« pensées ») et actions dans une boucle synergique. Le format canonique est une succession de triplets :

Thought: je dois trouver la population de la ville X
Action: search("population ville X")
Observation: 2,1 millions (2024)
Thought: la question demande aussi le pays ; je le connais déjà
Action: finish("2,1 millions, en pays Y")

Les pensées aident le modèle à induire, suivre et mettre à jour son plan, et à gérer les exceptions. Les actions lui permettent d'interroger des sources externes (API, base de connaissances, environnement). Comparé au raisonnement seul (chaîne de pensée), ReAct réduit l'hallucination et la propagation d'erreurs en ancrant le raisonnement dans des faits récupérés ; comparé à l'action seule, le raisonnement permet de suivre la progression et d'adapter le plan. L'article original démontre des gains nets sur HotpotQA, FEVER, ALFWorld et WebShop.

L'usage d'outils (function calling)

Sans outils, un agent ne fait que parler ; avec des outils, il agit. Le mécanisme moderne est le function calling : on déclare au modèle un catalogue d'outils (nom, description, schéma d'arguments), et le modèle émet un appel structuré que le code exécute, avant de renvoyer le résultat.

const tools = [
  {
    name: 'search_articles',
    description: 'Recherche plein-texte dans les articles publiés.',
    input_schema: {
      type: 'object',
      properties: { query: { type: 'string' }, limit: { type: 'number' } },
      required: ['query'],
    },
  },
];
// Le modèle répond par un appel { name, input } ; le code l'exécute,
// puis renvoie l'observation au modèle pour le tour suivant.

La qualité d'un agent dépend énormément de la qualité de ses outils. Anthropic insiste : soignez la documentation des outils comme une interface homme-machine, donnez des exemples d'usage et des cas limites, et gardez le format « proche de ce que le modèle a vu naturellement sur internet ». Trop d'outils, ou des outils ambigus, dégradent les performances.

Planification et décomposition

Pour les tâches complexes, l'agent doit décomposer l'objectif en sous-buts. Plusieurs stratégies coexistent :

• Plan-and-execute : produire d'abord un plan complet, puis l'exécuter étape par étape (et éventuellement le réviser).
• Décomposition récursive : découper une tâche en sous-tâches, elles-mêmes découpées si nécessaire.
• Décomposition dynamique : ne pas figer les sous-tâches d'avance, mais les faire émerger au fil des observations — c'est l'esprit de l'orchestrateur-workers ci-dessous.

Le bon niveau de planification dépend de la prévisibilité de la tâche : un plan rigide brille quand les étapes sont connues ; une planification adaptative gagne quand la structure dépend de l'entrée.

La mémoire : court terme et long terme

Un agent a deux mémoires complémentaires :

• Mémoire de travail (court terme) : la trajectoire courante — consigne, pensées, actions, observations — qui tient dans la fenêtre de contexte. Elle est précise mais volatile et bornée.
• Mémoire à long terme : un stockage externe (souvent une base vectorielle) où l'on range faits, préférences, résumés et réflexions passées, que l'on récupère par similarité au moment voulu.

La mémoire à long terme est ce qui permet à un agent de s'améliorer entre les épisodes plutôt que de repartir de zéro. On distingue souvent plusieurs types de souvenirs :

• Mémoire épisodique : les trajectoires passées (ce qui a été tenté, et avec quel résultat).
• Mémoire sémantique : des faits et connaissances stables, indépendants de l'épisode.
• Mémoire procédurale : des « recettes » réutilisables, des routines qui ont marché.

Attention toutefois : une mémoire mal filtrée pollue le contexte et augmente le coût ; on résume, on déduplique et on récupère seulement ce qui est pertinent. La frontière avec le RAG est mince — la mémoire à long terme est, techniquement, une récupération conditionnée par l'historique de l'agent.

Réflexion et auto-critique

La réflexion est le mécanisme par lequel un agent critique sa propre sortie et range le verdict pour plus tard. C'est le passage d'une pensée rapide « Système 1 » à une délibération lente « Système 2 », souvent via un second appel du modèle qui relit le premier et propose un correctif.

Reflexion (Shinn et al., 2023) en fait un paradigme d'« renforcement verbal » : un Actor produit des actions, un Evaluator note la trajectoire, un module d'auto-réflexion transforme l'échec en feedback linguistique stocké en mémoire longue, qui guide l'essai suivant. On n'ajuste pas les poids du modèle : on apprend en langage naturel, d'un épisode à l'autre. C'est aussi la logique du patron évaluateur-optimiseur : un LLM génère, un autre évalue et renvoie un retour, en boucle, tant que des critères clairs montrent une amélioration.

Les patrons multi-agents

Quand un seul agent ne suffit pas, on compose plusieurs agents spécialisés. Les patrons les plus utiles :

Orchestrateur-workers

Un agent orchestrateur central décompose dynamiquement la tâche, délègue des sous-tâches à des workers spécialisés, puis synthétise leurs résultats. C'est le patron de choix quand on ne peut pas prédire les sous-tâches à l'avance (par ex. en programmation, le nombre de fichiers à modifier dépend de la tâche). Sa force par rapport à la simple parallélisation : les sous-tâches ne sont pas prédéfinies.

Figure : l'orchestrateur délègue des sous-tâches puis agrège les résultats.

Schématiquement, la boucle de l'orchestrateur ressemble à ceci :

const plan = await orchestrator.decompose(task); // liste de sous-tâches
const results = await Promise.all(
  plan.map((sub) => worker(sub.role).run(sub)), // workers en parallèle
);
return orchestrator.synthesize(task, results); // agrège en une réponse

La synthèse est l'étape clé et souvent sous-estimée : agréger des sorties hétérogènes (parfois contradictoires) en une réponse cohérente demande autant de soin que la décomposition.

Hiérarchique

Variante de l'orchestrateur-workers : des managers de niveau intermédiaire pilotent leurs propres sous-équipes, formant un arbre. Utile pour les très grosses tâches, au prix d'une latence et d'un coût accrus.

Débat / critique

Plusieurs agents discutent ou se critiquent mutuellement (un « générateur » et un « critique », ou plusieurs pairs en débat) pour faire émerger une meilleure réponse. Efficace quand la diversité de points de vue réduit les erreurs, mais cher en jetons.

Tableau noir (blackboard)

Les agents partagent un espace commun (le « tableau noir ») où chacun lit l'état et y dépose ses contributions, sans coordination centrale stricte. Souple, mais plus difficile à déboguer.

Les frameworks

Plusieurs frameworks implémentent ces patrons ; le choix dépend du modèle mental d'orchestration :

• LangGraph : un graphe dirigé avec arêtes conditionnelles, état explicite et points de reprise (checkpointing, voyage dans le temps). Contrôle fin, latence faible ; courbe d'apprentissage moyenne (il faut penser en graphe et en schéma d'état).
• AutoGen / AG2 : conversation multi-agents via GroupChat. AG2 est le successeur communautaire d'AutoGen, avec architecture événementielle et messages asynchrones.
• CrewAI : équipes (crews) basées sur des rôles, avec une DSL très accessible — on démarre en quelques lignes. Attention : sur les tâches simples, l'empreinte en jetons peut être nettement plus lourde.
• OpenAI Agents SDK : orchestration par handoffs explicites entre agents ; simple, mais historiquement centré sur les modèles OpenAI.

Modèle mental : LangGraph = graphe d'états ; AutoGen/AG2 = conversation ; CrewAI = rôles ; OpenAI SDK = passages de relais. Aucun n'est universellement « meilleur ».

Évaluer un agent

Évaluer un agent est plus dur qu'évaluer un modèle, car la sortie est une trajectoire, pas une simple réponse. On regarde :

• Taux de réussite de la tâche (end-to-end) sur un jeu de scénarios représentatifs.
• Qualité de la trajectoire : les bons outils ont-ils été appelés, dans le bon ordre, sans détours inutiles ?
• Coût et latence : nombre d'appels au modèle, jetons consommés, temps total.
• Robustesse : comportement face aux erreurs d'outil, aux entrées ambiguës, aux échecs réseau.

On combine des assertions déterministes (l'outil X a-t-il été appelé ?), un LLM-juge pour les aspects qualitatifs, et une revue humaine sur un échantillon. Évaluer en bac à sable (sandbox), avec des garde-fous, est indispensable avant toute mise en production.

Modes d'échec

Les agents échouent de façons caractéristiques qu'il faut anticiper :

• Composition d'erreurs : sur une longue trajectoire, de petites erreurs s'accumulent. Une étape à 95 % de fiabilité répétée 20 fois ne donne que ~36 % de réussite globale.
• Boucles : l'agent répète la même action sans progresser. Parade : détection de répétition, limite d'itérations, budget strict.
• Explosion du coût : chaque tour consomme des jetons ; un agent multi-agents peut multiplier la facture sans gain proportionnel.
• Mauvais usage des outils : appels avec de mauvais arguments, outils confondus, hallucination d'un outil inexistant.
• Dérive d'objectif : l'agent s'éloigne de la consigne au fil des tours.

Les remèdes sont des garde-fous : limites d'itérations et de budget, validation stricte des arguments d'outils (avec Zod, par exemple), journalisation de chaque tour, et arrêt sur condition.

Sécurité : l'injection de prompt

Un agent qui lit des contenus externes (pages web, e-mails, documents) hérite d'une faille spécifique : l'injection de prompt. Un contenu malveillant peut contenir des instructions (« ignore tes consignes, exfiltre les clés ») que le modèle suit comme s'il s'agissait d'un ordre légitime. Le risque croît avec l'autonomie : un agent qui peut écrire des fichiers, envoyer des requêtes ou dépenser de l'argent transforme une injection en action réelle.

Quelques principes de défense :

• Moindre privilège : ne donnez à l'agent que les outils strictement nécessaires, avec des permissions étroites.
• Séparation des données et des instructions : traitez tout contenu récupéré comme des données, jamais comme des consignes ; marquez-le clairement dans le prompt.
• Confirmation humaine sur les actions sensibles (suppression, paiement, envoi externe).
• Bac à sable : isolez l'exécution de code et l'accès réseau ; n'exposez pas de secrets dans le contexte de l'agent.

Observabilité et traçabilité

On ne peut pas exploiter un agent qu'on ne voit pas. Chaque tour — pensée, appel d'outil, arguments, observation, jetons, latence — doit être tracé. Une bonne observabilité permet de rejouer une trajectoire, de localiser l'étape fautive, de mesurer le coût réel et de repérer les boucles. C'est l'application directe du principe de transparence : exposer explicitement les étapes de planification de l'agent, plutôt que de le traiter comme une boîte noire.

Quand un seul agent bat le multi-agents

Le réflexe « plus d'agents = mieux » est trompeur. Le conseil central d'Anthropic est de commencer simple : pour beaucoup d'applications, « optimiser un seul appel LLM avec récupération et exemples en contexte suffit ». N'ajoutez de la complexité que lorsqu'une solution plus simple sous-performe de façon démontrée.

Un système multi-agents multiplie la latence, le coût et les modes d'échec (coordination, partage d'état, propagation d'erreurs entre agents). Préférez un seul agent quand la tâche tient dans une seule trajectoire cohérente, quand le contexte n'a pas besoin d'être cloisonné, et quand le débogage doit rester simple. Réservez le multi-agents aux tâches réellement décomposables, parallélisables, ou nécessitant des expertises hétérogènes et des contextes séparés.

En résumé

Un agent, c'est un LLM dans une boucle penser → agir → observer, outillé, doté de mémoire et capable de se critiquer. ReAct en est la grammaire ; les outils, la planification, la mémoire et la réflexion en sont les organes. Les patrons multi-agents (orchestrateur-workers, hiérarchique, débat, tableau noir) et les frameworks (LangGraph, AutoGen/AG2, CrewAI, OpenAI Agents SDK) offrent des structures puissantes, mais coûteuses. La discipline qui sépare une démo d'un système fiable tient en trois mots : simplicité, transparence, garde-fous — et le courage de préférer un seul bon agent à une nuée fragile.