02 - Les 5 patterns d'agents IA qui marchent

Les 5 patterns d'agents IA qui marchent

Construire un agent IA, ce n'est pas juste connecter un LLM à des outils et espérer que tout fonctionne. Il existe des architectures éprouvées — des patterns — qui structurent la façon dont un agent raisonne, agit et s'améliore. Certains sont simples et robustes, d'autres sont sophistiqués et puissants.

Dans cet article, on passe en revue les 5 patterns d'agents IA qui fonctionnent réellement en production. Pour chacun : explication claire, schéma d'architecture, cas d'usage concrets, et analyse honnête des forces et faiblesses.

🔄 Pattern 1 : ReAct (Reasoning + Acting)

Principe

ReAct est le pattern le plus populaire et le plus intuitif. Publié par Yao et al. en 2022, il combine raisonnement (Reasoning) et action (Acting) dans une boucle itérative. À chaque étape, l'agent :

1. Pense (Thought) — Analyse la situation, planifie la prochaine étape
2. Agit (Action) — Appelle un outil ou effectue une opération
3. Observe (Observation) — Reçoit le résultat de l'action
4. Répète jusqu'à avoir assez d'informations pour répondre

Schéma d'architecture

Le flux démarre par la question de l'utilisateur. L'agent génère d'abord une pensée ("Je dois chercher la population de la France"), puis déclenche une action (par exemple, un appel à un outil de recherche). Le résultat de cette action (l'observation : "68,4 millions d'habitants") est injecté dans le contexte. L'agent génère une nouvelle pensée ("J'ai l'info, je peux répondre"), puis produit la réponse finale.

Exemple d'implémentation

L'implémentation d'un agent ReAct repose sur une classe principale initialisée avec un LLM et un dictionnaire d'outils disponibles. La méthode run construit un prompt structuré demandant au modèle de suivre le format Thought/Action/Observation, puis lance une boucle itérative. À chaque itération, la réponse du LLM est analysée : si elle contient "Final Answer", la boucle s'arrête et la réponse est extraite ; si elle contient "Action", le nom de l'outil et ses paramètres sont parsés, l'outil est exécuté, et le résultat est ajouté à l'historique sous forme d'observation. Un compteur limite le nombre maximal d'itérations pour éviter les boucles infinies.

Cas d'usage idéaux

• Recherche d'informations : Questions factuelles nécessitant plusieurs sources
• Assistants conversationnels : Chatbots avec accès à des APIs
• Tâches de diagnostic : Investigation étape par étape d'un problème
• Q&A sur documents : Recherche et synthèse d'informations

Forces et faiblesses

📋 Pattern 2 : Plan-and-Execute

Principe

Contrairement à ReAct qui raisonne étape par étape, Plan-and-Execute sépare la planification de l'exécution. L'agent commence par créer un plan complet, puis exécute chaque étape séquentiellement. Si une étape échoue, il peut re-planifier.

Ce pattern est inspiré des travaux sur BabyAGI et les planificateurs hiérarchiques. Il excelle sur les tâches complexes qui nécessitent une vision d'ensemble.

Schéma d'architecture

Le flux commence par un planificateur (un LLM puissant) qui analyse la tâche et génère un plan structuré en plusieurs étapes (par exemple : 1. Chercher X, 2. Analyser Y, 3. Calculer Z, 4. Synthétiser). Ce plan est ensuite transmis à un exécuteur (un LLM plus rapide couplé aux outils) qui traite chaque étape séquentiellement. Si l'étape 3 échoue, le flux revient au planificateur qui ajuste le plan (ajout d'une étape 3bis alternative) avant de relancer l'exécution.

Exemple d'implémentation

Ce pattern nécessite deux LLM distincts : un modèle puissant pour la planification et un modèle rapide pour l'exécution. La méthode run procède en trois phases. D'abord, la phase de planification génère une liste structurée d'étapes à partir de la tâche initiale et des outils disponibles. Ensuite, la phase d'exécution parcourt chaque étape séquentiellement : le résultat de chaque étape est injecté en contexte de la suivante. Si une étape échoue, un mécanisme de re-planification est déclenché pour générer des étapes alternatives à partir du point d'échec. Enfin, une phase de synthèse utilise le modèle puissant pour consolider tous les résultats intermédiaires en une réponse finale cohérente.

Cas d'usage idéaux

• Rédaction de rapports : Recherche → Analyse → Rédaction → Relecture
• Projets de code : Analyse → Design → Implémentation → Tests
• Workflows business : Étude de marché → Recommandations → Plan d'action
• Tâches multi-étapes prévisibles : Pipelines de données, ETL

Forces et faiblesses

🪞 Pattern 3 : Reflexion

Principe

Reflexion ajoute une couche d'auto-évaluation à l'agent. Après avoir produit un résultat, l'agent critique son propre travail et itère pour l'améliorer. C'est l'équivalent IA de relire sa copie avant de la rendre.

Publié par Shinn et al. en 2023, ce pattern a montré des améliorations significatives sur les benchmarks de code (HumanEval) et de raisonnement.

Schéma d'architecture

L'acteur produit une première réponse ou solution à la tâche. Cette réponse passe par un évaluateur qui analyse sa qualité via des tests, des critères prédéfinis ou un score. Si le score est suffisant, la réponse est validée. Sinon, une phase de réflexion produit un retour détaillé ("La réponse manque X, l'erreur est Y"), qui est injecté en contexte pour une nouvelle tentative de l'acteur. La boucle se répète jusqu'à validation.

Exemple d'implémentation

L'agent Reflexion s'articule autour de trois méthodes principales bouclant sur un nombre maximal de tentatives. La méthode act génère une réponse en injectant le contexte des réflexions précédentes dans le prompt pour éviter de reproduire les mêmes erreurs. La méthode evaluate analyse la qualité de la réponse produite : elle peut s'appuyer sur un LLM qui note la réponse sur une échelle de 1 à 10 et identifie les problèmes spécifiques, ou sur des tests automatisés pour du code. Si l'évaluation est négative, la méthode reflect produit un retour détaillé expliquant pourquoi la réponse est insuffisante et donnant des instructions précises d'amélioration. Ce retour est stocké et servi à la tentative suivante.

Cas d'usage idéaux

• Génération de code : Écrire → Tester → Corriger
• Rédaction de contenu : Écrire → Évaluer qualité → Réécrire
• Résolution de problèmes mathématiques : Calculer → Vérifier → Corriger
• Traduction : Traduire → Évaluer fidélité → Affiner

Forces et faiblesses

🤝 Pattern 4 : Multi-Agent

Principe

Au lieu d'un seul agent qui fait tout, le pattern multi-agent distribue le travail entre plusieurs agents spécialisés. Chaque agent a un rôle précis, des outils dédiés, et potentiellement un LLM différent.

Ce pattern est popularisé par des frameworks comme CrewAI, AutoGen et LangGraph, ou encore des plateformes comme ruflo : la plateforme d'orchestration multi-agent qui explose sur GitHub. Il s'inspire de la façon dont les équipes humaines fonctionnent : spécialisation et collaboration.

Schéma d'architecture

La tâche est d'abord transmise à un orchestrateur (coordinateur). Celui-ci distribue le travail entre plusieurs agents spécialisés — par exemple un agent Recherche (outils : web, news API), un agent Analyse (outils : Python, charts) et un agent Rédaction (outils : Markdown, CMS). Chaque agent travaille sur sa partie, puis les résultats sont consolidés pour produire le résultat final.

Topologies courantes

Il existe plusieurs façons d'organiser les agents entre eux :

Exemple d'implémentation

L'implémentation repose sur deux classes. La classe Agent encapsule un nom, un rôle, un LLM et une liste d'outils. Sa méthode execute construit un prompt intégrant le rôle de l'agent et le contexte des étapes précédentes, puis appelle le LLM avec ses outils. La classe MultiAgentOrchestrator gère la coordination. Elle propose au minimum deux topologies : l'exécution séquentielle, où chaque agent reçoit le résultat cumulé des agents précédents et le passe au suivant ; et l'exécution hiérarchique, où un agent manager reçoit la description de son équipe et décide dynamiquement à quel worker déléguer chaque sous-tâche, jusqu'à ce qu'il considère le travail terminé et produise une synthèse finale.

Cas d'usage idéaux

• Production de contenu : Recherche → Rédaction → Relecture → SEO
• Développement logiciel : Architecte → Développeur → Testeur → Reviewer
• Analyse business : Collecte données → Analyse → Recommandations → Rapport
• Support client : Triage → Spécialiste → Validation → Réponse

Forces et faiblesses

📚 Pattern 5 : Tool-Augmented RAG

Principe

Le RAG (Retrieval-Augmented Generation) classique cherche des documents pertinents et les injecte dans le contexte du LLM. Le Tool-Augmented RAG va plus loin : l'agent peut choisir dynamiquement ses sources de données et ses méthodes de recherche via des outils.

Au lieu d'un pipeline RAG figé (query → vector search → LLM), l'agent décide :
- Où chercher (base vectorielle, SQL, API, web)
- Comment chercher (recherche sémantique, filtres, agrégations)
- Quand chercher (itérativement, jusqu'à avoir assez d'infos)

Si vous n'êtes pas encore familier avec les bases du RAG, notre article RAG pour les nuls : donner de la mémoire à son IA couvre les fondamentaux.

Schéma d'architecture

La question de l'utilisateur est transmise à un agent RAG (un LLM). Celui-ci choisit dynamiquement la source de données la plus appropriée parmi plusieurs options : une recherche vectorielle (Pinecone, Chroma), une requête SQL sur une base relationnelle, un appel à une API externe, ou une recherche web (Brave, Google). Les résultats de ces différentes sources sont consolidés, puis l'agent synthétise une réponse en citant ses sources.

Exemple d'implémentation

L'implémentation d'un RAG augmenté repose sur un dictionnaire d'outils de recherche hétérogènes. Chaque outil est une méthode dédiée : vector_search effectue une recherche sémantique dans une base vectorielle en retournant les textes et leurs scores de pertinence ; sql_query exécute des requêtes en lecture seule (avec validation du préfixe SELECT) ; web_search interroge un moteur de recherche externe ; et api_fetch effectue des appels HTTP. La méthode run lance une boucle itérative : à chaque tour, le LLM reçoit la question, les sources déjà trouvées et la liste des outils disponibles. Il décide soit d'appeler un outil (les résultats sont stockés), soit de produire une réponse finale si les informations sont suffisantes.

Cas d'usage idéaux

• Support client avancé : Chercher dans la doc, les tickets, le CRM
• Analyse juridique : Recherche dans les textes de loi + jurisprudence
• Intelligence économique : Croiser données internes + sources ouvertes
• Assistants techniques : Documentation + logs + monitoring

Forces et faiblesses

📊 Comparaison globale des 5 patterns

(⭐ = faible, ⭐⭐⭐ = élevé)

🔀 Comment choisir le bon pattern ?

Pour choisir le bon pattern, posez-vous ces questions dans l'ordre :

1. La tâche est-elle simple (1-3 étapes) ? → Oui : ReAct
2. La qualité doit-elle être maximale ? → Oui : Reflexion
3. La tâche a-t-elle des étapes prévisibles ? → Oui : Plan-and-Execute
4. Faut-il des compétences variées ? → Oui : Multi-Agent
5. La tâche est-elle centrée sur la recherche d'info ? → Oui : Tool-Augmented RAG
6. Par défaut → ReAct

Combiner les patterns

En pratique, les meilleurs agents combinent plusieurs patterns :

• ReAct + Reflexion : L'agent agit étape par étape, puis évalue et corrige
• Plan-and-Execute + Multi-Agent : Le planificateur délègue à des agents spécialisés
• Multi-Agent + Tool-Augmented RAG : Un agent researcher avec du RAG augmenté

OpenClaw, par exemple, utilise un mélange de ReAct (boucle think-act-observe) et de Tool-Augmented RAG (accès dynamique à de multiples outils et sources via MCP). Pour comprendre les mécanismes sous-jacents, consultez notre guide MCP, Function Calling, Tool Use : le guide complet.

🚀 Conseils pour implémenter votre premier agent

1. Commencez par ReAct — C'est le plus simple et ça couvre 80% des cas
2. Ajoutez Reflexion si la qualité n'est pas suffisante — Un évaluateur automatique peut transformer un agent moyen en agent excellent
3. Passez au Multi-Agent uniquement si le problème est réellement complexe — La coordination a un coût
4. Mesurez tout — Tokens consommés, latence, taux de succès, qualité des réponses
5. Limitez les itérations — Un agent qui boucle coûte cher et ne produit rien

L'avenir des agents IA est dans la composition intelligente de ces patterns, adaptée à chaque cas d'usage. Maîtrisez-les un par un, puis combinez-les pour construire des systèmes véritablement puissants. Pour aller plus loin, Sécuriser son agent IA : les garde-fous essentiels détaille les bonnes pratiques pour éviter les dérives en production.

💡 L'essentiel

• ReAct est le pattern de base : pense, agis, observe, répète. À adopter par défaut.
• Plan-and-Execute sépare la réflexion de l'action et excelle sur les tâches longues à étapes prévisibles.
• Reflexion ajoute une boucle d'auto-évaluation pour maximiser la qualité, au prix de plus de tokens.
• Multi-Agent distribue le travail entre spécialistes, idéal pour les projets complexes nécessitant des compétences variées.
• Tool-Augmented RAG dépasse le RAG classique en laissant l'agent choisir dynamiquement où et comment chercher l'information.
• En pratique, les agents les plus performants combinent plusieurs patterns selon le besoin.

❌ Erreurs courantes

• Utiliser Multi-Agent pour une tâche simple : la coordination ajoute de la latence et de la complexité inutiles. Commencez par ReAct.
• Oublier de limiter les itérations : un agent ReAct ou Reflexion sans guardrail peut boucler indéfiniment et exploser votre facture.
• Utiliser le même LLM pour tout : dans un pattern Plan-and-Execute ou Multi-Agent, utiliser un modèle puissant pour la planification et un modèle rapide pour l'exécution réduit les coûts sans perte de qualité.
• Mal décrire les outils : si le LLM ne comprend pas quand et comment utiliser un outil, il fera des appels inutiles ou passera à côté de la bonne source.
• Ignorer la re-planification : un plan initial n'est jamais parfait. Sans mécanisme d'ajustement, une seule étape qui échoue casse tout le pipeline.

🛠️ Outils recommandés

• LangGraph : framework de référence pour implémenter des workflows d'agents complexes avec gestion d'état.
• CrewAI : dédié au pattern Multi-Agent, il permet de définir des agents avec des rôles, des objectifs et des outils spécifiques.
• AutoGen (Microsoft) : framework multi-agent supportant les topologies séquentielles, hiérarchiques et en débat.
• Pinecone / Chroma : bases vectorielles pour implémenter la couche de recherche dans un Tool-Augmented RAG.
• MCP (Model Context Protocol) : standard pour connecter des agents à des outils et sources de données externes de manière unifiée.

❓ FAQ

Quel pattern choisir pour mon premier agent ?
Commencez par ReAct. Il couvre la majorité des cas d'usage, est simple à implémenter et à debugger. Ajoutez Reflexion si la qualité de sortie n'est pas suffisante.

Est-ce que je peux combiner plusieurs patterns ?
Oui, c'est même recommandé en production. Par exemple, un planificateur qui délègue à des agents spécialisés (Plan-and-Execute + Multi-Agent), ou un agent ReAct avec une étape d'auto-évaluation finale (ReAct + Reflexion).

Le pattern Multi-Agent est-il toujours supérieur au mono-agent ?
Non. Le Multi-Agent introduit un overhead de coordination (communication, latence, coût). Il ne se justifie que si la tâche nécessite des compétences véritablement différentes ou si la parallélisation apporte un gain réel.

Comment éviter qu'un agent boucle indéfiniment ?
Implémentez toujours des guardrails : un nombre maximal d'itérations, un timeout, et un mécanisme de fallback qui retourne la meilleure réponse trouvée même si elle est incomplète.

Le Tool-Augmented RAG est-il vraiment meilleur qu'un RAG classique ?
Sur des questions simples, non — le RAG classique suffit. Mais dès que la réponse nécessite de croiser plusieurs sources (SQL + vectoriel + web), le RAG augmenté est nettement supérieur car il décide dynamiquement de la meilleure stratégie de recherche.

Conclusion

Il n'existe pas de pattern d'agent IA "meilleur" dans l'absolu — seulement un pattern adapté à votre problème. ReAct pour la simplicité, Plan-and-Execute pour les workflows structurés, Reflexion pour la qualité critique, Multi-Agent pour les projets complexes, et Tool-Augmented RAG pour la recherche d'information avancée.

La clé est de maîtriser chaque pattern individuellement, puis d'apprendre à les composer. C'est exactement cette approche qui permet de passer d'un prototype qui "marche parfois" à un agent fiable en production. Pour mettre ces concepts en pratique, suivez notre guide Créer son premier agent IA autonome. Des exemples concrets d'agents en production sont également disponibles avec Dexter : un agent IA autonome qui fait de la recherche financière profonde ou encore notre article sur Automatiser un pipeline complet avec un agent.
```