Comment mettre l’agentic AI en production ?

En traitant le LLM comme un agent contrôlé, pas comme un générateur de texte magique. Le vrai sujet, c’est la boucle observation, raisonnement, action, puis les garde-fous autour. Validation, contexte, erreurs, gouvernance, coûts. C’est là que le prototype devient utilisable.

Qu’est-ce que l’agentic AI change vraiment ?

L’agentic AI change surtout la façon dont j’utilise un LLM : je ne lui demande plus juste une réponse, je l’intègre dans une boucle qui observe, raisonne, agit, puis corrige sa trajectoire.

Avec un LLM classique, on envoie un prompt, le modèle répond, fin de l’histoire. C’est souvent stateless, c’est-à-dire sans mémoire réelle de ce qui vient de se passer, sauf ce qu’on remet explicitement dans le contexte. Avec une approche agentique, le modèle devient une pièce dans un système plus large.

La boucle ressemble à ça dans la vraie vie :

• L’agent observe une situation, par exemple un ticket client ouvert depuis 3 jours.
• Il raisonne sur ce qu’il manque, par exemple l’historique CRM ou la dernière facture.
• Il choisit une action, comme appeler une API interne ou chercher dans une base documentaire.
• Il lit le résultat de l’outil, puis ajuste son plan si l’information ne suffit pas.
• Il peut continuer jusqu’à produire une action utile, pas seulement un texte joli.

C’est là que ça devient intéressant. Pas quand on demande à un modèle de “faire un résumé”. Mais quand il doit interagir avec des systèmes réels : un CRM, une base documentaire, une API métier, un outil de ticketing, un workflow Make ou n8n, parfois même plusieurs à la fois.

Découvrez égalementQuels OpenCode plugins choisir pour coder avec l’IA ?

J’ai vu ce déclic chez un client assez récemment. Au début, tout le monde accusait le modèle. “Il hallucine”, “il n’est pas fiable”, “il ne comprend pas notre métier”. En creusant, le vrai problème n’était pas le LLM. C’était l’orchestration autour : mauvais contexte, outils mal décrits, aucune validation de sortie, aucune stratégie si l’API répondait mal.

C’est pour ça que l’agentic AI demande une vraie architecture de production. Il faut penser validation des sorties, récupération d’erreur, gestion du contexte, gouvernance, droits d’accès, traces d’exécution et contrôle des coûts. Sinon, on ne met pas un agent en production. On met une démo fragile avec un joli nom.

Comment éviter les mauvaises sorties ?

Les mauvaises sorties se limitent surtout avec un pattern de validation placé avant toute action en aval. Dans un système agentic AI, je ne considère jamais la sortie du modèle comme fiable par défaut. Encore moins si elle déclenche une mise à jour dans un CRM, la création d’un ticket, un remboursement, ou une décision automatisée.

Le modèle propose. Le workflow vérifie. Puis seulement après, le système agit. C’est vraiment cette séparation qui évite les dégâts.

En production, j’utilise plusieurs contrôles assez simples, mais très efficaces :

• Sorties structurées : Le modèle doit répondre dans un format précis, souvent en JSON, pas en texte libre.
• Validation par schéma : JSON Schema sert de contrat. Il dit quels champs sont attendus, quels types sont acceptés, et quelles valeurs sont autorisées.
• Contrôle de types : Un montant doit être un nombre, une date doit être une date, un email doit ressembler à un email.
• Champs obligatoires : Si le client, la priorité ou le sujet manque, on bloque.
• Function calling : Quand le modèle appelle un outil, il doit fournir des paramètres précis. Pas une intention vague.

Découvrez égalementComment mesurer la maturité IA de votre business ?

Les structured outputs vont dans le même sens. Le modèle est contraint de produire une réponse exploitable par une machine. Ça ne rend pas le modèle parfait, mais ça rend ses erreurs détectables. Et ça, c’est déjà énorme.

J’ajoute parfois une étape d’auto-vérification. Le modèle relit sa propre réponse et cherche des incohérences. C’est utile, surtout pour repérer un oubli évident ou une contradiction. Mais je ne lui fais pas confiance comme garde-fou principal. Une validation déterministe reste obligatoire. Déterministe, ça veut dire que le résultat est vérifié par une règle claire, toujours de la même façon.

Exemple simple pour une création de ticket support :

<ticket-support>
  <email>client@example.com</email>
  <sujet>Connexion impossible</sujet>
  <priorite>haute</priorite>
  <description>Le client ne peut plus accéder à son compte.</description>
</ticket-support>

Et côté workflow, je garde une logique très bête, mais robuste :

reponse = appeler_modele(demande)

si valider_schema(reponse) == vrai:
    creer_ticket(reponse)
sinon:
    reponse_corrigee = appeler_modele_pour_corriger(reponse)

    si valider_schema(reponse_corrigee) == vrai:
        creer_ticket(reponse_corrigee)
    sinon:
        envoyer_en_revue_humaine(demande, reponse_corrigee)

En cas d’échec, il y a plusieurs réactions possibles. Retry, correction automatique, demande de clarification à l’utilisateur, blocage pur et simple, ou revue humaine. J’ai vu chez un client un agent créer des tickets avec des priorités fantaisistes. Le correctif n’a pas été un meilleur prompt. C’était une liste de valeurs autorisées.

Comment gérer les pannes sans casser le workflow ?

Découvrez égalementDatabricks Data + AI Summit 2026 change quoi ?

Les pannes se gèrent dans le design, pas en espérant que les API répondent toujours. Un agent en production dépend rarement d’un seul cerveau magique. Il appelle un modèle LLM, une API métier, une base de données, un outil tiers, parfois tout ça dans le même workflow. Et dans la vraie vie, ça casse. Les timeouts arrivent. Les limites de débit tombent. Les réponses sont incomplètes. Les services renvoient des erreurs 502, ou répondent trop tard.

Le bon réflexe, c’est de prévoir le comportement de l’agent quand ça arrive. Pas juste quand tout va bien.

Le pattern classique, c’est une récupération d’erreur contrôlée. L’agent tente une action, vérifie le résultat, puis choisit quoi faire si ça échoue :

• Retry contrôlé. L’agent réessaie, mais pas en boucle infinie.
• Backoff progressif. Il attend 2 secondes, puis 10, puis 30. Ça évite d’aggraver une panne.
• Circuit breaker. Si un service échoue trop souvent, on arrête temporairement de l’appeler.
• Fallback provider. On bascule vers un autre modèle, une autre API, ou une version dégradée du service.
• File d’attente. On garde la tâche pour la reprendre plus tard.
• Dead-letter queue. Les cas vraiment bloqués vont dans une file spéciale pour analyse.
• Escalade humaine. Quand l’automatisation n’a plus assez de certitude, quelqu’un reprend la main.

C’est directement lié à la validation. Une sortie invalide, ce n’est pas juste “un mauvais résultat”. C’est une erreur à traiter proprement. Si l’agent demande un JSON avec un email et reçoit un texte flou, il ne doit pas continuer comme si de rien n’était. Il peut redemander une sortie correcte, utiliser un modèle de secours, ou envoyer le cas à un opérateur.

J’ai vu ça chez un client avec un agent qui enrichissait des fiches clients via une API externe. Tout le monde avait bossé le prompt. Personne n’avait vraiment prévu le cas où l’API répondait en retard. Résultat, des fiches restaient à moitié remplies sans alerte claire. La bonne version garde l’état de la fiche, réessaie plus tard, puis notifie un opérateur si le problème persiste.

Quel contexte donner à l’agent ?

Le bon contexte, c’est celui qui aide l’agent à décider maintenant. Pas tout ce que l’entreprise possède. C’est un réflexe assez courant de vouloir tout donner au modèle, la doc complète, l’historique client, les procédures, les tickets, les emails. Sur le papier, ça rassure. En production, ça coûte cher et ça dégrade souvent les réponses.

Trop de contexte augmente les tokens, donc les coûts et la latence. Les tokens, c’est simplement les morceaux de texte que le modèle lit et génère. Plus on lui en donne, plus il travaille. Et surtout, plus on risque de le distraire avec des infos secondaires. À l’inverse, trop peu de contexte donne un agent qui répond “à côté”, parce qu’il n’a pas les éléments utiles pour choisir la bonne action.

Le pattern que j’utilise le plus, c’est une gestion du contexte en couches. Une mémoire courte pour la conversation en cours. Une mémoire long terme pour les faits stables. Du retrieval, donc une recherche intelligente dans les documents. Des résumés pour compresser l’historique. Une sélection dynamique pour ne garder que ce qui sert vraiment. L’objectif est simple : apporter la bonne information au bon moment.

En pratique, ça passe souvent par une base vectorielle. Elle stocke des morceaux de documents sous forme d’embeddings, c’est-à-dire une représentation numérique du sens du texte. Quand l’agent reçoit une demande, il cherche les passages les plus proches du besoin. C’est le principe du RAG, pour Retrieval Augmented Generation. Le modèle ne “sait” pas tout. Il récupère ce qu’il faut, puis il raisonne avec.

Une architecture type ressemble à ça : l’agent reçoit une demande, identifie l’intention, récupère les documents pertinents dans une base vectorielle, résume l’historique utile, injecte seulement les éléments nécessaires dans le prompt, puis agit. Ça paraît simple, mais c’est souvent là que la différence se fait entre une démo sympa et un système stable. Et oui, ça sert aussi à garder les coûts sous contrôle.

Exemple concret. Un agent de support interne reçoit : “Je n’arrive pas à accéder à Notion depuis ce matin”. Il ne charge pas toute la documentation IT. Il récupère seulement les procédures liées aux accès SaaS, les incidents récents sur Notion, le profil de l’utilisateur et les derniers messages du ticket. Si la demande était RH, il irait chercher la politique congés ou télétravail, pas les procédures VPN. C’est bête, mais c’est exactement ce tri qui rend l’agent fiable.

Comment garder le contrôle en production ?

Le contrôle se garde avec de la gouvernance et une vraie logique de coûts dès la conception. Pas après. Pas quand l’agent est déjà branché au CRM, à l’ERP ou à votre outil de ticketing. Dès qu’un agentic AI peut agir dans des systèmes métier, il faut décider ce qu’il a le droit de faire, quand il doit demander une approbation, et comment on audite ses actions.

Je vois souvent le même piège chez les clients. On teste un agent en démo, il marche bien, tout le monde est content. Puis quelqu’un demande : “Et s’il annule une commande à 80 000 euros par erreur ?” Là, on revient aux bases.

Le governance pattern, c’est simplement mettre des garde-fous autour de l’agent. Rien de magique. On retrouve les mêmes pratiques que dans les environnements logiciels sérieux : audit logs, RBAC, traçabilité des appels outils. Le RBAC, c’est le contrôle d’accès basé sur les rôles. Un agent support n’a pas les mêmes droits qu’un agent finance, et c’est très bien comme ça.

Concrètement, je mets en place ce genre de règles :

• Des gates d’approbation avant les actions sensibles.
• Du human-in-the-loop, donc une validation humaine quand le risque dépasse un seuil.
• Une journalisation d’audit complète : qui a demandé quoi, quel outil a été appelé, avec quel résultat.
• Une séparation des permissions entre lecture, recommandation et action réelle.
• Des seuils de risque clairs, par montant, type de client, impact légal ou impact opérationnel.

Ce n’est pas de la bureaucratie. C’est ce qui permet de déployer sans perdre la responsabilité. Si l’agent agit, l’entreprise reste responsable. Donc il faut pouvoir expliquer, bloquer, rejouer et corriger.

Le cost control pattern est tout aussi important. Les coûts explosent vite avec de grandes fenêtres de contexte, des appels modèle inutiles, des retries mal maîtrisés, ou des modèles de raisonnement utilisés pour des tâches simples. Un agent qui réfléchit trop longtemps sur une classification basique, c’est juste de l’argent brûlé.

Les leviers sont assez simples :

• Router les tâches simples vers des modèles moins chers.
• Limiter le nombre d’appels modèle par workflow.
• Mettre en cache certaines réponses quand elles sont stables.
• Résumer le contexte au lieu de tout renvoyer à chaque étape.
• Suivre les tokens consommés, donc les morceaux de texte envoyés et générés par le modèle.
• Définir des budgets par agent, par workflow, ou par action business.

Un exemple simple : un agent utilise un modèle rapide pour classifier une demande client. Si la demande est complexe ou risquée, il passe à un modèle plus puissant. Et si l’action touche une facture, un remboursement ou une donnée sensible, il demande une validation humaine avant d’agir.

Alors, votre agent peut-il vraiment passer en production ?

Un agentic AI fiable, ce n’est pas juste un bon prompt branché sur un LLM. C’est une boucle d’exécution avec des outils, du contexte bien dosé, des validations, des retries, des garde-fous et une mesure claire des coûts. C’est moins spectaculaire sur le papier, mais c’est exactement ce qui fait la différence entre une démo sympa et un système qui tient dans le temps. Mon conseil simple, c’est de concevoir l’agent comme un workflow critique. Vous gardez la vitesse de l’IA, mais avec plus de maîtrise, moins de surprises et un vrai bénéfice business.

FAQ

• Qu’est-ce que l’agentic AI ?
  L’agentic AI consiste à intégrer un LLM dans une boucle d’exécution. L’agent observe une situation, raisonne, choisit une action, appelle éventuellement un outil externe, puis ajuste son comportement selon le résultat obtenu.
• Pourquoi un prototype LLM ne suffit pas pour la production ?
  Un prototype répond souvent à une demande isolée. En production, il faut gérer les sorties invalides, les pannes d’API, le contexte, les droits d’accès, les validations humaines et les coûts. Sans ces patterns, le système devient fragile.
• Comment valider les réponses d’un agent IA ?
  Je valide d’abord le format attendu avec des sorties structurées, un schéma, des champs obligatoires et des règles métiers simples. Si la réponse échoue, le workflow peut relancer, demander une correction ou passer par une revue humaine.
• Comment gérer le contexte dans un agentic AI ?
  Le bon réflexe, c’est de donner uniquement l’information utile à la décision. On peut utiliser du retrieval, une base vectorielle, des résumés, une mémoire courte et une mémoire long terme. Trop de contexte coûte cher et peut brouiller la réponse.
• Comment éviter que les coûts IA explosent ?
  Il faut suivre les appels modèles, limiter les grandes fenêtres de contexte, router les tâches simples vers des modèles moins chers, mettre en cache quand c’est pertinent et définir des budgets par workflow. Le coût doit être piloté comme une métrique produit.

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 webAnalyste et Formations Analytics, j’accompagne des équipes qui veulent passer des prototypes IA aux workflows réellement exploitables. 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, automatiser ou industrialiser vos cas d’usage IA, 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.