Création d'agents IA de niveau production : guide complet et introduction à l'évaluation des agents
Eliott Ardisson
Founder & CEO - Basalt Studio
Comment créer des agents IA fiables pour votre PME : architecture, évaluation continue, gestion des erreurs et bonnes pratiques de déploiement en production.
Points clés
- Un agent IA de niveau production n’est pas un prototype amélioré : c’est un système conçu dès le départ pour gérer les cas réels, les erreurs inattendues et l’évolution des besoins métier.
- L’architecture modulaire est la condition sine qua non d’un agent maintenable : elle permet de mettre à jour des composants sans tout reconstruire.
- L’évaluation des agents n’est pas optionnelle. Sans monitoring continu, une dérive de performance peut passer inaperçue pendant des semaines et dégrader l’expérience utilisateur en silence.
- Les métriques qui comptent sont celles alignées sur des objectifs business concrets : taux de complétion des tâches, temps économisé par processus, qualité des résultats mesurée par les utilisateurs finaux.
- Le plus grand écueil n’est pas technique : c’est de déployer sans plan d’évaluation ni critères de succès définis à l’avance.
Ce qui distingue un agent de production d’un prototype
Un prototype d’agent IA peut impressionner en démonstration. Il répond bien aux cas nominaux, il est rapide à monter, et il suffit souvent de quelques centaines de lignes de code pour convaincre un dirigeant de la viabilité du concept.
Mais en production, le contexte change. Les utilisateurs ne posent pas des questions propres et prévisibles. Les APIs externes tombent. Les données d’entrée sont malformées. Un collaborateur utilise l’agent d’une façon que personne n’avait anticipée, et le système plante sans message d’erreur utile.
Un agent de niveau production est conçu pour absorber cette réalité. Sa robustesse ne repose pas sur la qualité du modèle de langage seul, mais sur l’ensemble de l’architecture qui l’entoure : gestion des erreurs, mécanismes de récupération, monitoring, logs exploitables, et frontières claires entre les composants.
La distinction pratique : un prototype réussit dans 80 % des cas en conditions contrôlées. Un agent de production doit rester opérationnel et utile dans 95 % des cas en conditions réelles, y compris quand les 5 % restants se produisent.
Les composants fondamentaux d’une architecture solide
Couche d’interface
C’est le point d’entrée des requêtes, qu’elles viennent d’un chat intégré dans un CRM, d’un webhook déclenché par un formulaire, ou d’une API appelée par un outil tiers. Cette couche doit valider les entrées avant de les transmettre au reste du système, filtrer les requêtes malformées, et retourner des messages d’erreur clairs plutôt que des crashes silencieux.
Couche de traitement (l’orchestrateur)
C’est ici que réside la logique de l’agent : interprétation de la requête, choix de la stratégie, planification des étapes, appels aux outils. Dans les implémentations que nous réalisons chez Basalt Studio avec des outils comme n8n et l’API Claude via l’Anthropic SDK, cette couche est la plus délicate à concevoir, car elle doit être à la fois flexible (pour s’adapter au contexte) et prévisible (pour être testable et auditable).
Couche d’outils
L’ensemble des fonctions que l’agent peut invoquer : requêtes vers un CRM, envoi d’emails, extraction de données depuis une base, création de documents, appels à des APIs métier. Chaque outil doit avoir une interface claire, une gestion d’erreur propre, et des logs structurés. Un outil qui échoue silencieusement est une source de bugs impossibles à diagnostiquer.
Couche de données et mémoire
Contexte des conversations, historique des interactions, métriques de performance, logs d’erreur. Cette couche détermine ce que l’agent “sait” d’une session à l’autre et ce que vous pouvez analyser après coup. Sur des projets TypeScript et Next.js avec Convex comme backend temps réel, la persistance du contexte est un choix architectural à faire tôt, pas à rattraper en cours de route.
Gestion des erreurs : les trois niveaux à implémenter
La gestion des erreurs dans un agent de production n’est pas un filet de sécurité qu’on ajoute à la fin. C’est une décision de conception qui traverse toutes les couches.
Niveau 1 : Retry intelligent. Quand une API externe ne répond pas dans les délais, l’agent doit réessayer avec une logique de backoff exponentiel, pas en boucle infinie. Un timeout non géré qui bloque l’agent pendant 30 secondes est une mauvaise expérience utilisateur autant qu’un bug.
Niveau 2 : Fallback gracieux. Si une fonctionnalité échoue, l’agent doit proposer une alternative ou expliquer clairement ce qu’il ne peut pas faire, plutôt que de retourner un message vide ou une erreur technique brute. Dans un contexte de cabinet juridique, par exemple, si la recherche dans la base documentaire échoue, l’agent doit dire “je n’ai pas pu accéder aux documents, mais voici ce que je peux faire à partir des informations disponibles” plutôt que de s’arrêter.
Niveau 3 : Escalade vers l’humain. Il existe des situations où l’agent ne doit pas essayer de gérer seul : requêtes hors périmètre, données sensibles sans contexte suffisant, situations ambiguës à fort enjeu. Un agent bien conçu sait reconnaître ses propres limites et transférer proprement.
Pourquoi l’évaluation continue est non négociable
L’évaluation d’un agent IA est fondamentalement différente de celle d’un modèle de machine learning classique. On ne peut pas simplement calculer une précision sur un dataset figé et conclure que le système est bon.
Les agents opèrent dans des environnements dynamiques. Les requêtes évoluent. Les processus métier changent. Un modèle de langage peut être mis à jour par son fournisseur et modifier subtilement ses comportements. Sans système d’évaluation continu, ces dérives passent inaperçues.
Ce que révèle le monitoring en conditions réelles
- Des patterns de requêtes auxquels personne n’avait pensé lors de la conception
- Des cas limites où l’agent prend des décisions correctes sur le plan technique mais inappropriées sur le plan métier
- Des goulots d’étranglement dans l’exécution qui n’apparaissent pas sous charge modérée
- Des taux d’abandon qui signalent une mauvaise expérience utilisateur avant même que quelqu’un le signale
McKinsey a noté dans plusieurs de ses publications sur l’IA en entreprise que l’une des causes les plus fréquentes d’échec des déploiements est l’absence de mécanismes de feedback opérationnel après le lancement. Le système est livré, puis laissé seul. Six mois plus tard, personne ne l’utilise plus ou il génère des résultats incorrects sans que l’équipe l’ait remarqué.
Les métriques qui comptent vraiment
Métriques techniques
Taux de complétion autonome : quelle proportion des requêtes l’agent traite-t-il de bout en bout sans intervention humaine ? Pour un agent de qualification de leads dans une agence immobilière, par exemple, un taux en dessous de 80 % signale un problème de conception ou de couverture des cas d’usage.
Temps de réponse perçu : pas simplement le temps de traitement interne, mais le délai entre la requête utilisateur et le premier retour utile. Au-delà de quelques secondes, l’utilisateur suppose que le système est bloqué.
Taux d’erreur technique : fréquence des échecs non gérés (timeouts, exceptions non catchées, appels d’API qui retournent des erreurs 5xx). Un agent robuste maintient ce taux faible, mais surtout il ne laisse jamais une erreur technique se propager sans réponse propre à l’utilisateur.
Métriques business
Temps économisé par processus : combien de minutes ou d’heures par semaine le processus automatisé représente-t-il versus le traitement manuel antérieur ? Cette métrique est la plus simple à expliquer à un dirigeant.
Qualité des résultats : taux de satisfaction des utilisateurs finaux, nombre de corrections manuelles nécessaires après une action de l’agent, taux de réponses jugées pertinentes lors des évaluations périodiques.
Coût par transaction traitée : en intégrant les coûts d’API (modèle de langage, outils tiers), d’infrastructure et de maintenance, combien coûte le traitement d’une requête comparé au traitement humain équivalent ?
Construire un système d’évaluation : approche pratique
Un système d’évaluation efficace comporte trois niveaux complémentaires.
Tests automatisés en continu
Des jeux de tests représentatifs du périmètre réel de l’agent, exécutés à chaque déploiement. Ces tests ne vérifient pas uniquement que le système “fonctionne” au sens technique, mais que les réponses restent dans les paramètres attendus pour les cas d’usage définis. Sur des agents basés sur des LLMs, cela inclut des évaluations de cohérence, de pertinence et de respect des contraintes métier.
Les tests de régression sont particulièrement importants : quand on améliore l’agent sur un cas d’usage, il faut s’assurer qu’on n’a pas dégradé ses performances sur des cas précédemment couverts.
Monitoring temps réel
Des logs structurés sur chaque interaction, des alertes automatiques en cas d’anomalie (pic d’erreurs, temps de réponse anormal, taux de complétion qui chute), et des tableaux de bord accessibles aux responsables opérationnels sans avoir à interroger un développeur.
L’objectif n’est pas d’avoir des logs exhaustifs sur tout, mais des métriques actionnables : celles qui permettent de détecter un problème avant qu’il affecte les utilisateurs, et d’en identifier rapidement la cause.
Évaluation humaine périodique
L’automatisation ne remplace pas le jugement humain sur la pertinence contextuelle. Une revue mensuelle d’un échantillon d’interactions réelles par quelqu’un qui connaît le métier reste irremplaçable pour détecter des problèmes que les métriques quantitatives ne capturent pas : une réponse techniquement correcte mais maladroite, un ton inapproprié, une recommandation juridiquement acceptable mais commercialement contre-productive.
Les erreurs les plus fréquentes lors du passage en production
Déployer sans critères de succès définis. Si personne n’a défini ce que “ça marche” signifie concrètement avant le déploiement, il est impossible d’évaluer si l’agent est une réussite ou non après coup.
Ignorer les cas limites lors de la phase de test. Les cas nominaux représentent souvent 70 à 80 % du volume, mais les cas limites représentent 80 % des problèmes en production. Un agent de traitement de demandes RH qui fonctionne bien pour les contrats CDI standard mais qui plante sur les contrats atypiques est un problème réel, pas un détail.
Sous-estimer l’importance de la couche de sécurité. Dans des secteurs comme la comptabilité, le droit ou la santé, l’accès aux données sensibles doit être strictement contrôlé. Ce n’est pas un chantier à traiter après le déploiement. Les réglementations comme le RGPD ou des exigences sectorielles spécifiques doivent être intégrées dès la conception.
Négliger l’adoption utilisateur. Un agent techniquement parfait mais que personne n’utilise est un échec. La formation des équipes, la documentation des workflows, et la communication sur les capacités réelles de l’agent (ce qu’il fait, ce qu’il ne fait pas) sont des facteurs de succès au même titre que la qualité technique.
Confondre vitesse de déploiement et qualité. Livrer vite un agent instable coûte plus cher à corriger qu’un déploiement progressif bien préparé. Le déploiement pilote sur un périmètre restreint, suivi d’un monitoring renforcé avant généralisation, reste la méthode la plus fiable.
Ce que l’architecture technique détermine sur le long terme
Le choix des outils et des frameworks au moment du développement détermine la facilité de maintenance et d’évolution sur 12 à 36 mois. Quelques principes qui résistent à l’épreuve du temps :
- La modularité avant l’optimisation prématurée. Un système composé de modules bien délimités est plus facile à faire évoluer qu’un monolithe optimisé pour un cas d’usage spécifique.
- Les logs doivent être conçus pour être lus, pas juste générés. Un log inexploitable est inutile. La structure des logs doit être pensée en fonction des questions qu’on voudra poser après un incident.
- Les intégrations avec les systèmes externes doivent être isolées. Si l’API d’un outil tiers change ou tombe, l’impact doit rester circonscrit à un seul composant, pas se propager dans tout le système.
Vers des agents qui tiennent dans la durée
Les agents IA de niveau production ne sont pas un projet qu’on livre et qu’on oublie. Ce sont des systèmes vivants qui évoluent avec les processus métier, les outils, les équipes et les modèles de langage sous-jacents.
Les entreprises qui obtiennent les meilleurs résultats sur le long terme sont celles qui ont traité l’évaluation et le monitoring comme des composantes du projet dès le départ, et non comme des ajouts après coup. Elles ont aussi défini des critères de succès clairs avant de déployer, et elles ont prévu une boucle de feedback entre les utilisateurs opérationnels et les équipes qui maintiennent l’agent.
Gartner a observé que la majorité des projets IA qui échouent en entreprise ne le font pas pour des raisons techniques, mais faute de gouvernance claire et de mécanismes de suivi de la performance dans le temps. Ce constat s’applique directement aux agents IA déployés en contexte PME.
Si vous envisagez de déployer un premier agent en production ou d’évaluer la robustesse d’un agent existant, une discussion de 30 minutes sur vos processus et votre stack actuel permet souvent d’identifier les points de vigilance les plus importants avant de commencer.
Réservez un appel stratégie IA pour échanger avec l’équipe Basalt sur votre contexte spécifique.