1. Pourquoi parler de "patterns" ?
Dans le développement logiciel, un pattern est une solution éprouvée à un problème récurrent. Le mot vient des architectes (Christopher Alexander dans les années 1970), repris par les développeurs en 1994 avec le célèbre Design Patterns du Gang of Four.
Pour les agents IA, c'est exactement la même logique. Plutôt que de réinventer la roue, on utilise des architectures qui ont fait leurs preuves. Comprendre ces patterns vous évite des semaines de tâtonnement.
Les 4 patterns qu'on couvre dans ce chapitre :
- ReAct (Reason + Act) : le pattern réactif. L'agent décide étape par étape.
- Plan-and-Execute : l'agent planifie d'abord, exécute ensuite.
- Reflection : l'agent évalue ses propres résultats et se corrige.
- Multi-agents (orchestrateur) : plusieurs agents spécialisés coordonnés par un chef d'orchestre.
2. Pattern 1 : ReAct (le plus simple)
ReAct est le pattern de base, introduit par Yao et al. dans un papier de 2022. L'idée est très simple : l'agent alterne entre raisonner (Reason) et agir (Act). Pas de planification globale, pas de réflexion sur ses résultats. Juste une boucle continue.
Comment ça marche
À chaque tour, le LLM produit deux choses :
- Une pensée ("Je dois récupérer le statut du client X dans le CRM")
- Une action (appel à l'outil
search_crm("client X"))
Le résultat de l'action revient dans le contexte. Le LLM produit alors une nouvelle pensée et une nouvelle action. La boucle continue jusqu'à ce que le LLM décide que la tâche est terminée et produit une réponse finale.
Quand utiliser ReAct
- Tâches courtes à moyennes (jusqu'à 5-10 étapes)
- Pas besoin de planification globale (l'agent peut découvrir le chemin au fur et à mesure)
- Vous démarrez en agents IA : c'est le pattern le plus facile à mettre en place
- Cas d'usage : Q&R, recherche, classification, actions simples
Limites de ReAct
- Pour les tâches complexes (15+ étapes), l'agent perd le fil
- Pas de "vue d'ensemble" : difficile de vérifier qu'on est dans la bonne direction
- Coûteux si on tourne longtemps (chaque tour = appel LLM)
3. Pattern 2 : Plan-and-Execute (le pragmatique)
Plan-and-Execute répond aux limites de ReAct. L'agent commence par établir un plan de toutes les étapes, puis exécute le plan une étape à la fois.
Comment ça marche
Deux phases distinctes :
- Phase Plan : le LLM reçoit la tâche et produit un plan structuré (par exemple, une liste de 5 à 8 étapes). Pas d'action exécutée à ce stade.
- Phase Execute : on exécute chaque étape du plan séquentiellement. Pour chaque étape, on peut utiliser un mini-ReAct si nécessaire.
Bonus : on peut présenter le plan à l'humain pour validation avant exécution. C'est la Plan Mode qu'on retrouve dans Claude Code.
Quand utiliser Plan-and-Execute
- Tâches complexes à étapes multiples (5-20 étapes)
- Vous voulez pouvoir valider le plan avant exécution (Human-in-the-Loop sur la stratégie, pas juste sur les actions)
- Vous voulez économiser : un seul appel LLM pour planifier, puis exécution efficace
- Cas d'usage : workflows métier, génération de rapports, processus de validation
Limites de Plan-and-Execute
- Si la situation change pendant l'exécution, le plan peut devenir obsolète
- Plus complexe à mettre en place que ReAct
- Risque de plan trop ambitieux ou irréalisable
4. Pattern 3 : Reflection (l'auto-critique)
Reflection ajoute une boucle d'auto-évaluation après chaque action ou après le résultat final. L'agent critique son propre travail et le corrige si nécessaire.
Comment ça marche
Trois étapes :
- Génération initiale : l'agent produit un premier résultat (peut être avec ReAct ou Plan-and-Execute en interne).
- Réflexion : un second appel au LLM (ou le même avec un prompt différent) évalue le résultat. "Cette réponse est-elle complète ? précise ? bien sourcée ? Y a-t-il des erreurs ?"
- Révision : si la réflexion détecte des problèmes, on génère une nouvelle version corrigée. On peut boucler 2 à 5 fois.
Quand utiliser Reflection
- Tâches où la qualité du résultat compte vraiment (rédaction stratégique, analyses complexes)
- Vous voulez réduire les hallucinations (la réflexion les détecte souvent)
- Génération de contenu qui sera publié ou présenté
- Cas d'usage : analyses, rapports, contenu éditorial, audits
Limites de Reflection
- Coût multiplié par 2 ou 3 (chaque réflexion = nouvel appel LLM)
- Plus lent
- Si la réflexion est mal calibrée, elle peut générer des oscillations (corriger en cassant)
- Inutile pour les tâches simples ou très standardisées
5. Pattern 4 : Multi-agents (l'orchestre)
Multi-agents est le pattern le plus puissant et le plus complexe. Au lieu d'un seul agent qui fait tout, on a plusieurs agents spécialisés, coordonnés par un agent orchestrateur.
Comment ça marche : l'analogie de l'agence
Imaginez une agence de communication. Vous, le client, parlez au directeur de clientèle (l'orchestrateur). Il comprend votre besoin global, puis distribue le travail :
- Le concepteur-rédacteur écrit les textes
- La directrice artistique fait les visuels
- Le chef de projet gère le planning
- Le responsable qualité relit tout
Chaque spécialiste fait son métier. Le directeur de clientèle coordonne, fait remonter les blocages, vous tient informé.
C'est exactement ça, le multi-agents :
- 1 agent orchestrateur : reçoit la mission, comprend le contexte, distribue le travail
- N agents spécialisés : chacun excellent dans son domaine restreint
- Communication : l'orchestrateur récupère les résultats, les compose, les valide
Pourquoi c'est plus puissant
Trois bénéfices majeurs :
- Spécialisation : chaque agent peut avoir son propre prompt système (1-3 pages dédiées à son rôle), ses outils spécifiques (3-7 par agent), son modèle adapté (haut de gamme pour les rédacteurs, économique pour les classifieurs).
- Parallélisation : plusieurs spécialistes peuvent travailler en même temps. Une tâche qui prend 10 minutes en séquentiel peut prendre 2 minutes en parallèle.
- Maintenabilité : ajouter une nouvelle capacité = ajouter un nouvel agent. Pas besoin de toucher aux autres.
Quand utiliser multi-agents
- Tâches complexes nécessitant plusieurs expertises (analyse + rédaction + design + validation)
- Vous avez besoin de parallélisation (gain de temps important)
- Vous prévoyez d'évoluer : ajouter de nouveaux agents au fil des besoins
- Cas d'usage : rapports complexes, recrutement, support multi-niveaux, gestion de campagnes
Limites de multi-agents
- Complexité de mise en place beaucoup plus élevée que les patterns précédents
- Coût plus élevé (plusieurs LLMs en parallèle)
- Debugging plus difficile : si quelque chose foire, qui a foiré ?
- Risque d'over-engineering : pour 80 % des cas TPE/PME, un seul agent bien conçu suffit
6. Matrice de choix : quel pattern pour quel cas
| Pattern | Complexité tâche | Coût | Mise en place | Cas typique |
|---|---|---|---|---|
| ReAct | Faible-moyenne | $$ | Facile (1 jour) | FAQ, recherche, classification |
| Plan-and-Execute | Moyenne-haute | $ | Moyenne (3-5 jours) | Workflows métier, rapports |
| Reflection | Variable | $$$ | Moyenne (2-3 jours) | Analyses stratégiques, contenu publié |
| Multi-agents | Haute | $$$$ | Difficile (1-3 semaines) | Rapports complets, multi-expertises |
Recommandation pour démarrer : commencez toujours par ReAct. C'est le plus simple, le plus économique, et il couvre 70 % des cas. Évoluez vers Plan-and-Execute si la complexité l'exige, puis vers Reflection si la qualité doit être impeccable, puis vers multi-agents en dernier recours.
7. Combinaisons hybrides
Dans la vraie vie, on combine souvent les patterns. Quelques exemples courants :
- ReAct + Reflection : agent réactif qui critique son résultat final avant de le rendre. Bon compromis qualité/coût.
- Plan-and-Execute + Multi-agents : un orchestrateur planifie, distribue à plusieurs agents spécialisés, chacun en mode ReAct dans son périmètre. C'est l'architecture des grands systèmes.
- Multi-agents + Reflection : chaque agent spécialisé termine par une auto-critique. Garantit la qualité de chaque pièce avant assemblage.
Ne vous laissez pas piéger par le besoin de "tout combiner" pour faire bien. La simplicité gagne presque toujours. Ajoutez de la complexité seulement quand vous mesurez qu'elle apporte un vrai bénéfice.
8. Anti-patterns à éviter
Anti-pattern 1 : Le "God Agent"
Symptôme : un seul agent avec 30 outils, censé tout faire dans l'entreprise. Conséquences : erreurs fréquentes (mauvais outil choisi), latence élevée (contexte énorme), coût élevé, debugging cauchemardesque. Solution : décomposer en plusieurs agents spécialisés (multi-agents).
Anti-pattern 2 : Le "Reflection Infini"
Symptôme : l'agent critique sans fin, modifie sans converger, dépense des dizaines d'euros pour ne rien produire. Solution : limite stricte du nombre de réflexions (3 maximum), seuils de qualité absolus.
Anti-pattern 3 : Le "Plan Mort"
Symptôme : l'agent fait un plan parfait au début, mais quand l'exécution rencontre un obstacle imprévu, il continue aveuglément le plan inadapté. Solution : introduire un mini-Reflection après chaque étape majeure pour vérifier la pertinence du plan, le révisant si nécessaire.
Anti-pattern 4 : Le "Multi-agents pour le multi-agents"
Symptôme : on découpe en 5 agents là où 1 suffirait, parce que "c'est plus moderne". Conséquences : coût x5, debugging multiplié, sans bénéfice. Solution : ne passer en multi-agents que quand on a au moins 3 expertises clairement distinctes ou un besoin de parallélisation mesuré.
9. À retenir avant le chapitre suivant
- 4 patterns couvrent 95 % des cas : ReAct, Plan-and-Execute, Reflection, Multi-agents
- ReAct : le plus simple, à utiliser par défaut. Tâches courtes-moyennes
- Plan-and-Execute : quand la tâche a 5+ étapes claires. Permet la validation du plan
- Reflection : quand la qualité est critique (publications, analyses stratégiques)
- Multi-agents : pour les tâches multi-expertises ou nécessitant de la parallélisation
- Combinaisons hybrides possibles, mais la simplicité gagne presque toujours
- 4 anti-patterns à éviter : God Agent, Reflection Infini, Plan Mort, Multi-agents pour le multi-agents
Au chapitre 4, on plonge dans les outils (tools) : comment connecter votre agent au monde réel via API, MCP, webhooks, et fonctions custom. C'est ce qui transforme un LLM "qui parle" en agent "qui fait".