Comment réussir un projet Agentic AI en production ?

Un projet Agentic AI réussit quand l’agent sait agir, garder le bon contexte, décider proprement, coopérer et se mesurer en production. Le vrai sujet n’est pas le modèle. C’est l’architecture autour. Je vous montre les 5 concepts à verrouiller avant de confier des actions réelles à une IA.

Pourquoi un agent doit-il utiliser des outils ?

Un agent doit utiliser des outils parce qu’un LLM seul produit du texte, alors qu’un agent doit déclencher des actions vérifiables dans des systèmes réels.

Un chatbot répond. Il génère une réponse, reformule, explique, conseille. C’est déjà utile, mais ça reste du langage. Un agent Agentic AI va plus loin : il agit pour l’utilisateur. Il peut interroger une API, lire une base de données, créer un ticket, mettre à jour un CRM, lancer un workflow n8n ou appeler un service interne.

Le point important, c’est que le modèle ne fait pas ça nativement. Un LLM ne “met pas à jour Salesforce” tout seul. Il prédit du texte. Pour agir, il lui faut un pont d’exécution. Ce pont, c’est le tool use : une façon contrôlée de dire au modèle quels outils existent, quand les appeler, avec quels paramètres, puis comment exploiter le résultat.

J’ai vu ça chez un client support client. Le chatbot disait “Votre commande semble éligible à un remboursement”. Sympa, mais insuffisant. L’agent, lui, devait vérifier la commande dans l’ERP, lire les règles business, contrôler le délai de retour, puis ouvrir un remboursement si tout était conforme. Là, on n’est plus dans une conversation. On est dans une chaîne d’actions traçables.

Découvrez égalementComment passer à la maturité IA avec l'orchestration ?

Le Model Context Protocol, ou MCP, introduit par Anthropic en novembre 2024, essaie justement de standardiser cette relation entre agent et outils. L’idée est simple : éviter de refaire une intégration ad hoc pour chaque outil. Un serveur MCP expose un manifest de capacités, c’est-à-dire une description des actions disponibles, et les échanges passent par un modèle basé sur JSON-RPC, un format léger pour appeler des fonctions à distance.

Ce que j’aime dans MCP, c’est la séparation plus propre des rôles :

• Le modèle raisonne et choisit l’action.
• L’agent orchestre, contrôle et garde le contexte.
• Les outils exécutent dans les vrais systèmes.
• Les connecteurs peuvent être réutilisés au lieu d’être recodés partout.
• Les autorisations, comme OAuth, et les contextes multi-tenant sont mieux structurés.

Mais MCP n’est pas magique. Il peut ajouter du contexte, donc du coût en tokens. Pour des systèmes très haut débit, ou quand chaque milliseconde compte, un appel direct à une API, une CLI ou un connecteur maison reste parfois plus pertinent. Comme souvent en prod, le bon choix dépend moins de la mode que de la latence, du coût, de la sécurité et de la maintenabilité.

Comment gérer la mémoire d’un agent ?

La mémoire d’un agent se gère comme un composant d’architecture séparé, pas comme un simple historique de conversation qu’on empile dans le prompt. Un appel LLM est stateless par défaut. Ça veut dire que le modèle ne garde rien tout seul entre deux appels. Si je ne lui redonne pas les bonnes infos, il oublie.

C’est supportable pour un chatbot simple. Ça devient vite fragile dès qu’on parle d’un agent qui travaille en plusieurs étapes, sur plusieurs sessions, avec plusieurs utilisateurs. L’agent doit savoir où il en est, ce qu’il a déjà tenté, ce qu’il ne doit pas refaire, et ce qui compte vraiment pour la prochaine décision.

Découvrez égalementComment démarrer avec ML Intern sans perdre de temps ?

La mémoire, ce n’est pas un gros sac où je mets tout. Je sépare plusieurs choses.

• La mémoire de conversation courte garde les derniers échanges utiles.
• La mémoire long terme conserve des informations stables, validées, qui survivront à la session.
• Les préférences utilisateur stockent les habitudes, contraintes ou choix récurrents.
• L’état de tâche dit où l’agent en est dans son workflow.
• Les traces d’actions réalisées évitent de refaire deux fois la même chose.
• Les documents récupérés via RAG apportent une connaissance externe au bon moment. RAG veut dire Retrieval Augmented Generation, en gros on va chercher les bons documents avant de demander au modèle de répondre.

Le contexte n’est pas juste la mémoire. Le contexte, c’est ce que je choisis de remettre devant le modèle à un instant précis. C’est là que l’ingénierie du contexte devient critique. Chez les clients, je vois souvent les deux extrêmes. Trop de contexte rend l’agent confus, coûte cher, et augmente les réponses contradictoires. Pas assez de contexte le rend inutile. Le bon compromis, c’est de sélectionner, résumer, classer, puis rappeler uniquement ce qui sert à la prochaine décision.

Exemple simple. Un agent commercial qui reprend une négociation après trois semaines doit retrouver les contraintes du client, les prix déjà proposés et les objections. Il n’a pas besoin de tout l’historique mot à mot. Sinon il va noyer l’info importante dans du bruit.

Comment un agent décide-t-il quoi faire ?

Un agent décide quoi faire en enchaînant observation, raisonnement, choix d’action, exécution et vérification, jusqu’à atteindre un objectif ou demander de l’aide.

La différence avec un simple chatbot, elle est là. Un chatbot répond. Un agent doit choisir la prochaine action utile. Il peut chercher une information, appeler un outil, attendre une validation humaine, reformuler une demande, arrêter la tâche ou escalader à quelqu’un. Et ce choix se fait rarement en une seule fois.

En production, cette boucle devient vite fragile. J’ai vu des agents très convaincants appeler le mauvais outil parce que deux API avaient des noms proches. J’en ai vu répéter trois fois la même recherche, modifier une donnée trop tôt, ou décider avec un contexte incomplet. Le modèle “raisonne”, oui, mais il ne comprend pas vos risques métier comme un humain responsable du processus.

Découvrez égalementMCP server security comment réduire les risques ?

Les patterns comme ReAct, au sens observation puis action, la planification simple, la séparation planner-executor ou une étape de critique avant action aident à organiser le raisonnement. Mais ce ne sont pas des garanties. Ce sont des cadres. La fiabilité vient surtout des limites que vous imposez autour de l’agent.

Les garde-fous de base sont assez simples à formuler, mais il faut les appliquer sérieusement :

• Objectifs explicites : L’agent doit savoir ce qu’il cherche à obtenir, et ce qu’il ne doit pas faire.
• Permissions limitées : Il ne doit accéder qu’aux outils nécessaires, avec les droits minimums.
• Validation humaine : Toute action sensible doit être approuvée avant exécution.
• Règles d’arrêt : L’agent doit savoir quand abandonner, demander de l’aide ou escalader.
• Contraintes business : Les seuils, exceptions, priorités et règles internes doivent être codés clairement.
• Logs d’actions : Chaque décision doit être traçable. Sinon, impossible de comprendre un incident.
• Tests réels : Les scénarios propres ne suffisent pas. Il faut tester les cas tordus, incomplets, ambigus.

Prenons un agent finance qui classe des factures. Il lit le document, extrait le fournisseur, vérifie que ce fournisseur existe, compare le montant avec le bon de commande, contrôle le seuil d’approbation, demande une validation si le montant dépasse la limite, puis transmet la facture à l’outil comptable. À chaque étape, il ne “répond” pas. Il décide quoi faire ensuite.

Avant la production, je veux vérifier que l’agent sait prendre ces décisions :

• Choisir le bon outil.
• Ne rien faire quand le contexte est insuffisant.
• Demander une validation humaine au bon moment.
• Refuser une action hors périmètre.
• Détecter une boucle ou une répétition inutile.
• Tracer ce qu’il a fait et pourquoi.
• S’arrêter proprement quand l’objectif est atteint.

Quand faut-il plusieurs agents ?

Plusieurs agents deviennent utiles quand une tâche demande des rôles spécialisés, mais ils compliquent vite la coordination, les coûts et le contrôle.

Je ne vois pas le multi-agent comme une mode. Je le vois comme une façon de rendre un système plus lisible quand un seul agent commence à porter trop de responsabilités. Un agent qui cherche l’information, analyse les résultats, prend une décision, exécute une action et se relit lui-même, ça marche en démo. En production, ça devient vite flou.

La séparation peut aider. Un agent recherche les données. Un autre analyse. Un autre exécute dans un outil métier. Un dernier vérifie avant validation. C’est souvent plus simple à auditer, surtout quand chaque agent a un rôle précis, des droits limités et une sortie attendue dans un format stable.

Les modèles de coordination les plus propres restent assez simples :

• Un orchestrateur central décide quel agent appeler, dans quel ordre, et garde la trace des décisions.
• Des agents spécialisés sont appelés uniquement quand on en a besoin, par exemple pour vérifier un stock ou lire une politique commerciale.
• Un agent critique relit la réponse ou la décision avant exécution, un peu comme un contrôle qualité.
• Un pipeline déterministe impose un ordre fixe, ce qui réduit la créativité mais améliore le contrôle.

La limite, elle est très concrète. Plus il y a d’agents, plus il y a de messages, de latence, de coûts, de contradictions possibles et de responsabilités floues. J’ai déjà vu des prototypes très impressionnants devenir impossibles à maintenir parce que personne ne savait quel agent avait décidé quoi. Et quand un client demande pourquoi une remise a été proposée, “C’est l’agent analyse qui a influencé l’agent réponse” ne suffit pas.

Prenons un agent e-commerce. Un agent vérifie le stock. Un autre contrôle la politique commerciale, par exemple les remises autorisées ou les conditions de retour. Un troisième rédige la réponse client. Un dernier relit avant envoi pour vérifier le ton, la conformité et l’absence de promesse impossible. Là, le multi-agent a du sens, parce que chaque rôle est clair.

Comment mesurer un agent en production ?

Un agent se mesure en production avec des traces complètes, des métriques métier, des évaluations automatisées et des revues humaines sur les cas sensibles.

L’observabilité, c’est souvent le grand oublié des projets Agentic AI. Je le vois souvent chez des clients : on teste le prompt, on regarde si la réponse “sonne bien”, puis on découvre trop tard que l’agent a pris une mauvaise décision. Un chatbot peut donner une mauvaise réponse. Un agent, lui, peut faire une mauvaise action.

Il faut donc garder une trace exploitable de tout le raisonnement opérationnel. Ce qu’il a vu. Ce qu’il a décidé. Quel outil il a appelé. Avec quels paramètres. Quel résultat il a obtenu. Pourquoi il s’est arrêté. Sans ça, impossible de débugger, d’auditer ou de faire confiance au système.

L’évaluation ne doit pas se limiter à la qualité du texte. Il faut tester le comportement complet. Un agent qui écrit bien mais applique la mauvaise règle, c’est un problème de production, pas un détail.

Les pratiques crédibles sont assez simples à poser, mais il faut les tenir dans le temps :

• Construire des jeux de scénarios représentatifs, avec des cas simples, limites et franchement pénibles.
• Lancer des tests de non-régression à chaque nouvelle version.
• Rejouer des traces réelles pour comparer les décisions.
• Comparer deux versions de l’agent sur les mêmes cas.
• Analyser les échecs, pas seulement les scores moyens.
• Faire un échantillonnage humain régulier sur les cas sensibles.

La sécurité doit être intégrée dès le départ. Permissions minimales, sandbox pour isoler les tests, dry run avant une action réelle, alertes sur comportement anormal. Un dry run, c’est une simulation : l’agent prépare l’action, mais ne l’exécute pas encore.

Prenez un agent qui traite des demandes de remboursement. Je ne mesure pas seulement si sa réponse est bien écrite. Je mesure s’il applique la bonne règle, s’il demande une validation quand le montant dépasse un seuil, s’il ne rembourse pas deux fois la même commande, et s’il laisse une trace exploitable pour l’audit.

Avant de passer en production, je vérifie au minimum :

• Les traces couvrent les décisions, les outils, les paramètres et les résultats.
• Les métriques métier sont suivies chaque jour.
• Les actions risquées passent par validation ou dry run.
• Les tests de non-régression tournent à chaque changement.
• Les échecs sont revus par une personne responsable.

Alors, qu’est-ce qui bloque vraiment votre agent ?

L’Agentic AI ne se résume pas à brancher un modèle plus puissant sur quelques outils. Pour que ça tienne en production, il faut penser système : outils bien exposés, mémoire propre, contexte maîtrisé, décisions encadrées, coordination claire et observabilité solide. C’est souvent là que les projets passent du prototype sympa au vrai levier business. Mon conseil est simple : commencez petit, mesurez tout, donnez peu de droits au départ, puis élargissez quand les traces prouvent que l’agent travaille correctement. Le bénéfice pour vous, c’est un agent utile, contrôlable, et beaucoup moins fragile.

FAQ

• Quelle est la différence entre un chatbot et un agent Agentic AI ?
  Un chatbot répond surtout avec du texte. Un agent Agentic AI peut aussi agir : appeler une API, chercher une donnée, mettre à jour un outil, lancer un workflow ou demander une validation. La différence importante, c’est l’exécution d’actions dans un cadre contrôlé.
• Pourquoi le tool use est-il central dans l’Agentic AI ?
  Parce qu’un LLM seul ne sait pas manipuler vos systèmes. Le tool use lui donne un moyen structuré d’utiliser des outils externes. Sans ça, l’agent reste bloqué dans la génération de texte et ne peut pas produire de résultat opérationnel.
• À quoi sert le Model Context Protocol ?
  Le Model Context Protocol, ou MCP, sert à standardiser la façon dont un agent découvre et appelle des outils. L’idée est d’éviter des intégrations spécifiques partout, avec un modèle plus réutilisable entre agents, services et environnements.
• Pourquoi la mémoire d’un agent est-elle difficile à gérer ?
  Parce qu’il ne suffit pas de remettre tout l’historique dans le prompt. Il faut choisir les informations utiles, les résumer, les structurer et les rappeler au bon moment. Trop de contexte coûte cher et peut brouiller l’agent. Pas assez de contexte le rend inefficace.
• Quelles métriques suivre pour un agent en production ?
  Je regarderais d’abord le taux de réussite des tâches, les erreurs d’outils, les escalades humaines, la latence, le coût par tâche, les actions annulées et le respect des règles business. La qualité du texte compte, mais ce n’est pas suffisant pour juger un agent.

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Avec mon agence webAnalyste et mon organisme Formations Analytics, j’accompagne des équipes qui veulent passer de la démo IA au système fiable, mesurable et utile. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer un projet Agentic AI ou automatiser vos process business sans perdre le contrôle, contactez-moi.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.