Toutes les équipes qui construisent des agents IA se heurtent au même obstacle.
On commence avec un seul prompt et quelques outils.
Ça marche.
Puis les besoins grandissent. Plus de cas particuliers. Plus d'équipes. Plus de risques.
Soudainement, votre « agent » devient un prompt système de 3 000 mots qui essaie de faire cinq choses à la fois.
La solution n'est pas plus d'ingénierie de prompt.
C'est de choisir le bon pattern.
Voici les 15 patterns sur lesquels tous les systèmes agentiques en production sont construits — et quand utiliser chacun.
Avant de choisir un pattern
Toutes les tâches ne nécessitent pas un agent.
Une tâche justifie un agent quand :
→ Un seul appel de modèle ne peut pas produire un résultat fiable
→ Le modèle doit choisir entre des outils ou des sources de données à l'exécution
→ La tâche nécessite de la planification, de la validation ou un raffinement itératif
→ Le workflow comporte une réelle incertitude qui ne peut pas être codée en dur
Une tâche n'a généralement PAS besoin d'un agent lorsque le chemin de l'entrée à la sortie est prévisible.
Résumé. Classification. Extraction simple. Génération basée sur un template.
Ce sont des appels de modèles directs, plus rapides, moins chers et plus fiables.
Les envelopper dans un agent ajoute juste de la latence et des points de défaillance sans aucun bénéfice.
PATTERN 1 — Agent Unique
Le point de départ le plus simple et le plus courant.
Un modèle. Un prompt système. Un ensemble d'outils limité.
Le modèle décide quel outil appeler, observe le résultat et continue jusqu'à ce qu'il en ait assez pour répondre.
Exemple réel : Un agent de support client qui vérifie le statut d'une commande, le suivi d'expédition et crée un ticket s'il ne peut pas résoudre le problème — le tout avec 2-3 outils et une mission claire.
À utiliser quand : la tâche est bien définie, l'ensemble d'outils est petit, et un seul agent peut gérer l'intégralité du contexte sans se tromper.
Ça échoue quand : vous continuez à ajouter des outils et le prompt système dépasse une page. C'est le signal qu'il vous faut un pattern différent — pas un prompt plus long.
PATTERN 2 — Multi-Agent Séquentiel
Des agents spécialisés fonctionnent dans un ordre fixe. La sortie de chacun alimente l'entrée du suivant.
Exemple réel : Un pipeline de révision de contrat — un agent extrait les obligations, le suivant identifie les risques, un troisième rédige le résumé pour les achats. La séquence ne change jamais.
À utiliser quand : le workflow a des étapes claires et reproductibles, et chaque étape produit exactement ce dont la suivante a besoin.
Ça échoue quand : l'ordre doit en fait varier en fonction de ce qui est découvert en cours de route. Les pipelines séquentiels supposent que le chemin est fixe — s'il ne l'est pas, vous avez besoin de quelque chose de plus dynamique.
PATTERN 3 — Multi-Agent Parallèle
Des sous-tâches indépendantes sont exécutées simultanément, puis combinées en une seule vue.
Exemple réel : Un incident de production à 2h du matin. Trois agents enquêtent sur les logs, les métriques et les déploiements récents en même temps — pas l'un après l'autre — car chaque minute compte lors d'une panne.
À utiliser quand : les sous-tâches sont véritablement indépendantes et la vitesse compte.
Ça échoue quand : les tâches dépendent en fait des résultats les unes des autres. Forcer un travail dépendant dans une exécution parallèle crée simplement des conditions de course et un contexte incomplet.
PATTERN 4 — Boucle
Répéter une séquence d'étapes jusqu'à ce qu'une condition de sortie soit remplie.
Exemple réel : Un agent de nettoyage de données qui profile un fichier CSV désordonné, propose un plan de nettoyage, vérifie s'il répond aux normes de qualité, et réessaie si ce n'est pas le cas — jusqu'à un nombre d'itérations maximum.
À utiliser quand : la tâche nécessite plusieurs tentatives et vous pouvez définir une condition d'arrêt claire et vérifiable.
Ça échoue quand : il n'y a pas de condition de sortie fiable. Sans cela, vous obtenez des coûts incontrôlés et un système qui pourrait ne jamais se terminer.
PATTERN 5 — Révision et Critique
Un agent juge examine la sortie d'un autre agent, la critique et donne des retours d'information spécifiques et exploitables.
Exemple réel : Un rapport généré est examiné par un agent « critique » distinct qui signale les affirmations faibles, les preuves manquantes ou les sections peu claires avant même qu'il n'atteigne un humain.
À utiliser quand : la qualité prime sur la rapidité et vous voulez qu'un second avis soit intégré au système, pas ajouté après coup.
Ça échoue quand : l'agent critique a les mêmes angles morts que le générateur. Un réviseur formé sur des hypothèses similaires ne détectera pas les mêmes erreurs.
PATTERN 6 — Raffinement Itératif
Une boucle de rétroaction avec un seuil de score de qualité. Le générateur continue à affiner jusqu'à ce qu'il franchisse la barre.
Exemple réel : Un générateur de texte marketing qui évalue son propre brouillon par rapport aux directives de la marque, et continue à réécrire jusqu'à atteindre un score de qualité minimum — pas seulement une vérification binaire, mais une amélioration graduelle.
À utiliser quand : la qualité de la sortie est véritablement variable et « assez bon » a un seuil mesurable.
Ça échoue quand : la fonction de notation est vague ou manipulable. Si le modèle peut gonfler son propre score sans réelle amélioration, la boucle ne fait que brûler des tokens.
PATTERN 7 — Coordinateur
Un agent de routage central dirige les requêtes vers des agents spécialisés en fonction de ce qui est demandé.
Exemple réel : Les tickets de support sont acheminés vers les spécialistes de la facturation, du technique, du compte, de l'expédition ou de la fraude — chacun avec un contexte restreint au lieu d'un seul agent essayant de tout savoir.
À utiliser quand : vous avez des types de demandes vraiment différents qui nécessitent un contexte, des outils ou une logique de décision différents.
Ça échoue quand : le routage lui-même devient ambigu. Si les demandes ne rentrent pas clairement dans une catégorie, le coordinateur devient un nouveau goulot d'étranglement et une source de mauvais routage.
PATTERN 8 — Décomposition Hiérarchique des Tâches
Un agent racine décompose un objectif complexe en sous-objectifs plus petits, les délègue à des agents spécialisés, puis synthétise le tout en une seule réponse.
Exemple réel : « Dans quels 3 pays devrions-nous nous développer l'année prochaine ? » est décomposé en analyse concurrentielle, recherche réglementaire, faisabilité logistique et dimensionnement du marché — chacun traité par un spécialiste différent, puis combiné.
À utiliser quand : le problème est trop vaste pour un seul passage de raisonnement mais se décompose clairement en domaines d'expertise indépendants.
Ça échoue quand : les sous-objectifs ne sont pas réellement indépendants. Si les flux de travail doivent s'informer mutuellement en temps réel, les décomposer en amont perd cette interaction.
PATTERN 9 — Essaim
Plusieurs agents spécialisés contribuent à une discussion partagée, remettent en question les hypothèses des autres, et un facilitateur synthétise une recommandation finale.
Exemple réel : L'entreprise devrait-elle lancer un abonnement ? Les agents de la recherche, de l'ingénierie, des finances et du support argumentent chacun leur point de vue sur plusieurs tours avant qu'un facilitateur ne pèse les compromis.
À utiliser quand : il n'y a pas de réponse unique « correcte » — vous avez besoin d'une décision bien motivée façonnée par des points de vue véritablement concurrents.
Ça échoue quand : vous avez besoin d'une réponse rapide et déterministe. Les essaims sont délibérément lents et exploratoires — mauvais outil si vous avez besoin de vitesse.
PATTERN 10 — ReAct (Raisonner et Agir)
L'agent alterne entre raisonnement et action : décider quoi investiguer, appeler un outil, observer le résultat, décider s'il y a assez de preuves.
Exemple réel : « Le processeur de file d'attente semble bloqué » — l'agent cherche dans la documentation, vérifie l'état du service, corrèle les résultats, et ne suggère un correctif qu'ensuite. Le chemin d'investigation n'est pas prédéfini ; il dépend de ce qu'il trouve en cours de route.
À utiliser quand : le chemin vers la réponse ne peut vraiment pas être planifié à l'avance — il dépend de ce que chaque étape révèle.
Ça échoue quand : les investigations s'éternisent sans converger. Limitez toujours le nombre de cycles raisonnement-action, ou vous risquez une exploration infinie.
PATTERN 11 — Humain dans la Boucle
L'agent enquête et recommande, mais un humain prend la décision finale sur tout ce qui est risqué ou ambigu.
Exemple réel : Approbations de remboursement — les cas simples et à faible risque sont automatisés. Les montants élevés, les signaux de fraude ou les exceptions de politique sont mis en attente pour un examen humain avant que quoi que ce soit ne soit finalisé.
À utiliser quand : la décision comporte un risque financier, juridique ou de réputation réel et une automatisation complète n'est pas encore acceptable.
Ça échoue quand : vous traitez cela comme une simple fonctionnalité d'interface utilisateur au lieu d'une fonctionnalité architecturale. Vous avez besoin d'un état persistant, d'une attribution de réviseur, d'une gestion des timeouts et de chemins d'escalade — pas seulement d'un bouton « pause ».
PATTERN 12 — Planifier et Exécuter
Un agent planificateur crée un plan structuré complet en amont — révisable et modifiable — avant qu'une action ne soit entreprise. Un exécuteur parcourt ensuite les étapes.
Exemple réel : « Redimensionner la flotte de workers de 10 à 20 instances, vérifier que la file d'attente se vide, mettre à jour le runbook. » Le plan complet est visible avant le début de l'exécution, contrairement à ReAct où le chemin émerge étape par étape.
À utiliser quand : vous voulez que le plan soit révisable ou approuvable avant toute action — important pour les opérations ayant des conséquences réelles.
Ça échoue quand : l'environnement change plus vite que le plan ne peut s'exécuter. Un plan obsolète exécuté aveuglément est pire que pas de plan du tout.
PATTERN 13 — Réflexion
L'agent évalue ses propres échecs, réfléchit à ce qui n'a pas fonctionné et conserve cette mémoire pour la tentative suivante.
Exemple réel : Un agent de génération de code écrit un script, il échoue à l'exécution, l'agent analyse l'erreur réelle, enregistre ce qui doit être corrigé et réessaye — devenant plus intelligent à chaque tentative au lieu de répéter la même erreur.
À utiliser quand : les échecs sont informatifs et l'auto-correction améliore réellement la tentative suivante.
Ça échoue quand : les modes de défaillance sont aléatoires ou sans lien entre eux. La réflexion n'aide que lorsqu'il y a un vrai modèle à apprendre.
PATTERN 14 — Logique Personnalisée
Un hybride : le code déterministe gère les règles qui ne doivent jamais être erronées, tandis que le modèle gère le jugement, la rédaction et la gestion des exceptions.
Exemple réel : Un workflow de remboursement où la vérification d'achat et les contrôles anti-fraude s'exécutent sous forme de règles déterministes strictes — jamais déléguées au modèle — tandis que la rédaction de la réponse client et les recommandations de routage restent agentiques.
À utiliser quand : le workflow a une réelle logique de branchement avec des conséquences juridiques ou financières, et vous devez être précis sur ce qui est déterministe par rapport à ce qui est flexible.
Ça échoue quand : les équipes brouillent la frontière et laissent le modèle prendre des décisions qui devraient être des règles codées en dur. L'éligibilité, les autorisations et les mouvements d'argent ne devraient jamais être la seule décision du modèle.
PATTERN 15 — Agent Piloté par les Événements
L'agent n'attend pas qu'on lui demande. Il s'abonne à un flux d'événements et agit dès qu'une condition est déclenchée.
Exemple réel : Un agent de détection de fraude qui réagit instantanément lorsqu'un événement de transaction suspecte se déclenche — pas quand un ticket de support le signale finalement, moment où les dégâts sont déjà faits.
À utiliser quand : le timing compte plus que tout, et attendre une demande humaine signifie rater la fenêtre d'action.
Ça échoue quand : les conditions de déclenchement sont mal définies. Un flux d'événements bruyant avec des déclencheurs vagues se transforme en un système qui crie constamment au loup — ou pire, qui rate le vrai signal.
Sélection du pattern — adaptez-vous à l'incertitude, pas au battage médiatique
Le bon pattern correspond à la forme de l'incertitude dans votre travail :
→ Incertain de l'outil à utiliser → Agent Unique ou ReAct
→ Incertain de l'endroit où router → Coordinateur
→ Incertain de la qualité → Révision & Critique ou Raffinement Itératif
→ Incertain du chemin d'exécution → Planifier et Exécuter ou ReAct
→ Incertain de l'auto-correction → Réflexion ou Boucle
→ Incertain du risque commercial → Humain dans la Boucle ou Logique Personnalisée
→ Incertain de la structure du problème → Décomposition Hiérarchique ou Essaim
→ Impossible d'attendre une demande → Agent Piloté par les Événements
Un essaim n'est pas plus avancé qu'un agent unique si la tâche n'a besoin que d'un seul appel d'outil fiable.
Planifier et Exécuter n'est pas une amélioration de ReAct si votre plan est obsolète à la troisième étape.
Les systèmes de production les plus fiables ne sont pas les plus autonomes.
Ils placent l'autonomie exactement là où elle crée de la valeur — et la contraignent partout ailleurs.
10 règles pour les systèmes agentiques en production
- Commencez par le plus petit pattern qui fonctionne. Un agent unique avec des contrats d'outils propres bat un système multi-agent avec des contrats faibles.
- Rédigez les descriptions d'outils comme des contrats. Le modèle ne sait ce que fait l'outil que par la description — pas par votre intention.
- Limitez les itérations, les appels d'outils et les dépenses par requête. Un agent sans limites de budget est un passif qui attend de se manifester sur une facture.
- Consignez la trace d'action complète. Appels d'outils, arguments, sorties, décision finale. Sans cela, l'investigation d'incident est une devinette.
- Gardez les actions irréversibles derrière des vérifications déterministes ou une approbation humaine. Ne laissez jamais un modèle être le seul garde-fou avant un mouvement d'argent ou un changement de production.
- Évaluez avec des cas d'échec réels, pas seulement des chemins heureux. La correction du chemin heureux est un prototype. La correction des cas limites est un produit.
- Séparez les prompts par responsabilité avant que le prompt système ne devienne illisible. « Mais ne fais pas X quand Y » qui s'immisce dans votre prompt signifie que l'agent fait deux travaux.
- Traitez les systèmes multi-agents comme des systèmes distribués. Les défaillances partielles, les timeouts, les tentatives et l'observabilité ne sont pas optionnels.
- La révision par modèle ne remplace pas la validation déterministe. Utilisez des juges pour améliorer la qualité. Utilisez des tests et des vérifications d'autorisation pour appliquer la conformité.
- Préférez le pattern le plus simple — pas parce que simple est toujours mieux, mais parce que le budget de complexité que vous économisez peut être dépensé pour de meilleurs outils, de meilleurs prompts, une meilleure évaluation.
Voilà les 15.
La plupart des équipes n'échouent pas parce qu'elles ont choisi le mauvais pattern.
Elles échouent parce qu'elles ne se sont jamais demandé quelle incertitude elles résolvaient réellement.
Choisissez le pattern. Adaptez-vous à la forme du problème. N'ajoutez pas d'autonomie là où elle ne mérite pas sa place.
Si cela vous a été utile :
→ Republiez pour le partager avec chaque ingénieur qui construit des agents dans votre équipe
→ Suivez @sairahul1 pour plus d'analyses comme celle-ci
→ Mettez-le en favori — vous y reviendrez chaque fois que vous commencerez un nouveau projet d'agent
J'écris sur l'IA, la construction de produits et les systèmes qui fonctionnent sans vous.
