5 patterns d’agents IA expliqués sur le même use case (scoring d’un lead B2B) : coût, taux de réussite, et celui qu’on choisit en prod

Pourquoi comparer les patterns d’agents IA sur un même use case

Tu lis des comparatifs de patterns d’agents IA depuis des mois. ReAct vs plan-and-execute vs reflection. Chaque article te dit quel pattern est « le meilleur » dans l’abstrait. Mais quand tu ouvres ton orchestrateur et que tu dois scorer un vrai lead B2B depuis un email, ces benchs abstraits ne t’aident pas à trancher.

Le problème, c’est que la plupart des guides cataloguent 10 ou 20 patterns sans jamais les confronter au même input. Tu te retrouves avec des définitions, pas des données. Alors que le choix d’un pattern en production se joue sur trois métriques : le coût, la latence et le taux de réussite.

J’ai donc pris 5 patterns d’agents IA (ReAct, plan-and-execute, reflection, tool use et multi-agent) et je les ai appliqués au même cas d’usage : le scoring d’un lead B2B à partir d’un email entrant. Même modèle de base, même CRM, mêmes outils. Et j’ai mesuré ce qui se passe vraiment.

Cet article te donne les résultats, le pattern que j’ai choisi en production, et pourquoi.

Le use case fil rouge : scorer un lead B2B depuis un email

Avant de comparer les architectures, il faut poser le besoin. Un commercial reçoit un email d’un prospect inconnu. L’email dit : « Bonjour, nous sommes une PME de 50 personnes dans le SaaS, nous cherchons un outil de scoring pour nos leads, budget 15 k€/an, objectif déploiement dans 3 mois. »

L’objectif du scoring est de qualifier ce lead avant l’appel : est-ce que le budget correspond, le timing est réaliste, le fit produit est bon ? Le flux de données en entrée comprend l’email brut, les données CRM du compte (quand il existe), les bases internes (docs produit, cas clients similaires) et un modèle de scoring maison hébergé via une API.

Les outils mobilisés sont une API de CRM (HubSpot ou Salesforce), une base vectorielle pour la RAG sur les docs internes, une API de scoring, et un format de sortie structuré (JSON avec un score « chaud/tiède/froid » et les raisons).

Ce cas d’usage est reproductible et exigeant : le email change de format, les données CRM varient, mais la structure du problème est stable. C’est exactement le type de tâche pour lequel tu vas industrialiser un agent en production. Et c’est un maillon clé avant la qualification en amont d’une CRM : si le scoring est bon, ton équipe commerciale gagne des heures sur des leads non qualifiés.

Les 5 patterns d’agents IA à l’épreuve

Un agent IA, c’est quoi ? C’est un LLM enveloppé dans une boucle continue d’observation, de raisonnement et d’action. Au lieu de répondre une fois, l’agent évalue un objectif, choisit des outils externes et ajuste son plan selon les résultats réels. C’est cette boucle qui le rend agentique.

Les 5 patterns que je compare sont :

• ReAct (Reason + Act) : le pattern historique qui alterne raisonnement et action à chaque étape
• Plan-and-execute : planification complète avant exécution
• Reflection : l’agent critique sa propre sortie avant de la rendre
• Tool use : brancher des outils via API et function calling
• Multi-agent : déléguer entre agents spécialisés coordonnés

Chacun a sa logique de raisonnement, son coût en tokens et son architecture de mémoire. Voyons-les en action sur le scoring du lead.

Le pattern ReAct : raisonner et agir en boucle

ReAct suit une logique Thought, Action, Observation. Le modèle réfléchit à chaque étape, agit, observe le résultat, et décide de la suite. Sur le scoring d’un email, ça donne : le modèle lit l’email (Thought), appelle l’API CRM pour vérifier si le compte existe (Action), reçoit la réponse (Observation), puis décide de chercher des cas similaires dans la base vectorielle (Thought suivant). Et ainsi de suite.

L’avantage de ReAct, c’est sa réactivité : il s’adapte au fil de l’eau. Si le CRM renvoie une erreur, il peut tenter un autre chemin. Mais le coût est massif : chaque étape déclenche un appel LLM avec tout le contexte précédent rechargé. Sur notre scoring de lead, ReAct peut consommer 8 à 12 appels LLM, un coût par lead qui explose vite à l’échelle.

Le deuxième risque, c’est la boucle infinie. Si l’API de scoring renvoie une réponse inattendue, l’agent peut boucler sur le même appel sans fin. Sans garde-fous stricts, limite d’itérations, monitoring des coûts et actions dangereuses bloquées, ReAct devient un piège financier.

Le pattern plan-and-execute : planifier puis exécuter

Le pattern plan-and-execute sépare la phase de plan du chemin d’exécution. L’agent établit d’abord un plan complet : extraction des infos du lead → enrichment via CRM → appel au modèle de scoring → décision → formatage du rapport. Puis il exécute chaque étape en séquence, avec des appels LLM plus légers que le cycle complet de ReAct.

Résultat : la latence par lead est 2 à 3 fois plus faible qu’avec ReAct. Le coût aussi, parce que chaque étape d’exécution utilise un prompt plus simple, sans le surcoût de la boucle de raisonnement ReAct. Pour le scoring de lead, on découpe en étapes claires : extraction du nom de l’entreprise, du budget annoncé, du besoin exprimé ; enrichment CRM (taille, secteur, techno) ; passage dans le modèle de scoring.

Cette architecture est idéale quand tu connais les étapes à l’avance. C’est le cas du scoring B2B : le flux est toujours le même, seuls les paramètres changent. Le trade-off, c’est la rigidité : si une API renvoie un format inattendu, l’agent plan-and-execute a moins de flexibilité pour s’adapter que ReAct.

Reflection : s’auto-corriger avant de conclure

Le pattern reflection ajoute une boucle de critique interne. L’agent génère d’abord une sortie, puis la relit et l’évalue avant de la rendre. Concrètement, sur le scoring du lead : l’agent produit un premier score avec ses justifications, puis un deuxième appel LLM critique cette production en vérifiant la cohérence, la présence de tous les champs requis, l’absence d’affirmations non étayées.

L’impact sur la fiabilité du scoring est net : moins de faux positifs (leads qualifiés à tort) et moins de faux négatifs (leads intéressants écartés par erreur). Le coût, en revanche, inclut un appel LLM supplémentaire par cycle. Pour un scoring qui décide de passer des leads à l’équipe commerciale, ce surcoût est justifié : une erreur de qualification coûte bien plus cher qu’un appel LLM de plus.

Je recommande la reflection pour les décisions critiques, celles où le coût d’une erreur dépasse largement le coût de la vérification. Dans une pipeline de scoring, c’est un filtre que tu places avant l’envoi du lead vers le CRM.

Tool use : brancher les bons outils

Le tool use est le pattern qui connecte l’agent aux systèmes réels via le function calling et les API. Sans lui, l’agent est limité à ce que le modèle connaît déjà, ce qui ne sert à rien pour un scoring qui a besoin de données fraîches.

Sur notre cas, l’agent tool use branche une API CRM (vérification du compte, historique, interactions passées), une API de modèle de scoring (appel à un modèle entraîné sur les closes historiques), une API d’enrichissement (taille d’entreprise, secteur, technos détectées), et une API d’export vers le CRM (création ou mise à jour du lead avec le score).

Le standard MCP (Model Context Protocol) uniformise tout ça : un client découvre les outils disponibles via un manifeste de capacités et les invoque avec le même schéma JSON-RPC. Chaque intégration est une brique indépendante. La qualité des descriptions d’outils détermine la performance de l’agent autant que le modèle lui-même.

La différence avec un agent totalement autonome, c’est le contrôle du périmètre d’action : tu décides quels outils sont accessibles, en lecture seule ou en écriture, avec ou sans validation humaine. Le tool use n’est pas un agent qui fait tout tout seul — c’est une couche habilitante pour les autres patterns.

Multi-agent : déléguer entre agents spécialisés

Le pattern multi-agent distribue le travail entre plusieurs agents spécialisés, coordonnés par un agent superviseur. Sur le scoring d’un lead B2B, ça donne : un agent d’extraction (parse l’email et sort les champs clés), un agent d’enrichissement (interroge le CRM et les bases), un agent de décision (applique le modèle de scoring et produit le résultat), et un agent de rapport (rédige le résumé pour le commercial).

Chaque agent a son propre prompt, ses propres outils, parfois son propre modèle. L’agent superviseur orchestre les flux : il reçoit le résultat de l’extraction, le passe à l’enrichissement, puis à la décision, puis au rapport. Si un agent échoue, l’échec reste isolé, l’agent extraction peut planter sans impacter l’agent décision.

Le coût d’orchestration est réel : chaque agent consomme des tokens pour son prompt système, son historique et ses descriptions d’outils. Un orchestrateur qui appelle 4 spécialistes peut consommer 10 à 20 fois plus de tokens qu’un agent unique. La complexité de gouvernance aussi s’accroît : qui valide les changements de prompt ? Comment tracer une décision dans la chaîne ?

Le multi-agent surperforme un agent unique quand les sous-tâches demandent des expertises vraiment différentes. Sur un scoring simple, c’est rarement le cas. Le pattern devient pertinent quand tu ajoutes des dimensions comme la vérification de conformité, la recherche de données externes ou la personnalisation avancée.

Comparatif chiffré : coût, latence et taux de réussite

Voici le tableau de synthèse des 5 patterns sur le scoring du lead B2B. Les chiffres sont des ordres de grandeur basés sur des runs avec le même modèle (Claude Sonnet), le même email d’entrée et les mêmes outils.

Quelques enseignements. Le pattern tool use seul est le moins cher et le plus rapide, mais son taux de réussite pâtit de l’absence de boucle de raisonnement : il exécute des requêtes API sans vérifier la cohérence d’ensemble. ReAct et multi-agent offrent les meilleurs taux de réussite mais avec un coût et une latence qui les rendent difficiles à industrialiser à plus de quelques centaines de leads par jour. Plan-and-execute + reflection donne un excellent rapport qualité-coût pour un volume de milliers de leads mensuels.

Ces résultats sont à transposer à ton contexte. Le modèle utilisé, le volume de leads, la complexité de ton CRM et la tolérance à l’erreur de ton équipe commerciale changent la balance. Le tableau n’est pas une vérité absolue, c’est un cadre pour trancher.

Quel pattern choisir en production ?

La règle d’or en production : commence simple, complexifie si nécessité. Ne déploie pas un multi-agent pour un scoring à 300 leads/mois. Ne lance pas du reflection sur chaque email si ton taux d’erreur acceptable est de 10 %.

Pour un scoring de lead B2B, le pattern que je choisis en production est une combinaison de plan-and-execute + tool use, avec un human-in-the-loop. Concrètement :

• Un agent plan-and-execute décompose le lead en étapes (extraction, enrichment, décision)
• Chaque étape appelle les outils via MCP (CRM, base interne, API de scoring)
• Un point de validation humaine avant l’envoi du résultat final au commercial
• Un compteur d’itérations limite les boucles à 3 max

Ce choix tient à plusieurs raisons. La latence de 4-7 s est acceptable pour un usage synchrone (le commercial attend le score). Le coût de 0,03-0,05 $ par lead passe à l’échelle (300 $ pour 10 000 leads). Et le human-in-the-loop sur le dernier cran (avant l’export CRM) évite les faux positifs sans ajouter de latence à chaque étape.

Anticiper le coût tokens et l’observabilité, c’est les deux piliers qui font tenir ce choix en production. Sans monitoring de la consommation de tokens par lead, tu découvres le surcoût sur ta facture du mois. Sans traces d’exécution (quel outil a été appelé, quelle réponse est revenue) tu ne peux pas debugger un score erroné.

Quand mettre du multi-agent ou de la reflection ? Le multi-agent devient utile quand tu ajoutes des étapes qui nécessitent des modèles ou des jeux d’outils différents (ex. : vérification de conformité RGPD, scoring sentiment sur l’email). La reflection, je l’active sur les leads à fort ticket (>50 k€) où le coût d’une erreur de qualification justifie un appel LLM supplémentaire.

Les pièges qui font échouer un agent IA en production

J’ai vu des projets d’agents IA se casser la figure sur des erreurs qui n’ont rien à voir avec le modèle. Les voici pour que tu les évites.

1. Croire qu’un LLM seul suffit sans workflow. Un LLM tout seul, c’est un générateur de texte stateless. Pour scorer un lead, il faut une orchestration : appeler le CRM, lire la base, formater la sortie. Le LLM sans workflow, c’est un moteur sans volant.
2. Penser qu’autonomie totale = fiabilité. Un agent totalement autonome qui décide tout seul d’envoyer le résultat au CRM sans validation, c’est une bombe à retardement. Le human-in-the-loop sur le dernier cran de décision n’est pas un signe de faiblesse, c’est le signe d’une architecture de production mature.
3. Négliger le monitoring et l’évaluation en production. Un agent qui marche en démo peut produire des résultats différents en production sans qu’une ligne de code ait changé, parce que les données en entrée ont bougé. Sans monitoring des coûts, de la latence et du taux de réussite, tu ne vois pas la dérive arriver.
4. Ignorer la maîtrise des coûts et du prompt système. J’ai vu des équipes lancer un pattern multi-agent sur 50 000 leads par mois sans avoir budgété les tokens. Résultat : une facture LLM 10 fois supérieure au prévisionnel. Le prompt système, versionné et optimisé, fait la différence entre un agent qui coûte 0,02 $ par tâche et un qui coûte 0,20 $.

Conclusion : ta grille de choix des patterns d’agents

Récapitulons les 5 patterns en une phrase chacun.

• ReAct : flexible et adaptatif, mais coûteux et risqué sans garde-fous
• Plan-and-execute : efficace et prévisible, idéal pour les flux connus à l’avance
• Reflection : renforce la fiabilité des décisions critiques, au prix d’un appel LLM supplémentaire
• Tool use : la couche habilitante qui connecte l’agent aux systèmes réels, indispensable en production
• Multi-agent : puissant sur les workflows complexes, mais lourdeur de gouvernance et coût x10 à x20

Ma décision finale pour le scoring d’un lead B2B en production : plan-and-execute + tool use, avec human-in-the-loop sur l’étape d’export et reflection activée sur les leads à fort ticket. C’est le pattern qui offre le meilleur ratio coût / latence / fiabilité pour un volume de plusieurs milliers de leads par mois.

Le déploiement d’un agent IA en production ne se joue pas sur le choix du modèle. Il se joue sur le choix du pattern, les garde-fous que tu mets autour et l’observabilité que tu installes dès le jour 1. La règle est simple : commence simple, mesure tout, complexifie là où le besoin est avéré.

Si tu veux suivre l’aventure, abonne-toi !