La plupart des équipes basculent un PoC IA en production parce que la démo a bien tourné. Ce n’est pas la même chose qu’être prêt pour la production.
Un agent IA de niveau production a besoin de trois choses qu’un PoC n’a presque jamais :
- Des datasets d’évaluation, pour que la qualité soit mesurable et pas juste ressentie.
- Des guardrails, parce que les vrais utilisateurs, contrairement aux testeurs internes, cherchent activement les failles.
- De l’observabilité, pour détecter les défaillances à l’échelle, pas une conversation à la fois.
L’agent qui a impressionné les décideurs et l’agent sur lequel votre business peut s’appuyer ne se construisent pas de la même façon.
Le piège de la démo réussie
Une démo, c’est trois prompts soigneusement choisis, un cas d’usage cadré, et un public bienveillant. Le PoC répond bien sur ces trois prompts. Tout le monde sourit. La direction arbitre : on lance.
Le problème, c’est que la démo n’a jamais testé :
- Ce que l’agent fait quand un utilisateur entre un prompt ambigu, mal formulé, ou volontairement piégeant.
- Ce qu’il fait quand 200 personnes l’utilisent en parallèle au lieu d’un seul démonstrateur.
- Ce qu’il fait quand un cas inattendu sort du périmètre prévu.
- Ce qu’il fait au bout de trois mois, quand le modèle sous-jacent a été mis à jour ou que vos données ont changé.
Un PoC répond à la question “est-ce que ça peut marcher ?”. La production répond à “est-ce que ça marche, tout le temps, pour tout le monde, et est-ce qu’on le sait ?“.
1. Les datasets d’évaluation : sortir du ressenti
Un PoC est validé par un humain qui regarde les sorties et dit “oui, c’est bon”. Ce signal ne tient pas en production.
Un dataset d’évaluation, c’est un ensemble de cas de test représentatifs (50 à 500 selon le périmètre) avec, pour chacun, le résultat attendu ou les critères de qualité à respecter. Vous le faites tourner avant chaque déploiement. Vous obtenez un score chiffré. Vous savez si la nouvelle version est meilleure que l’ancienne, ou pire.
Sans cela, chaque modification devient un pari. Vous changez un prompt, vous mettez à jour le modèle, vous ajoutez une nouvelle fonctionnalité, et vous découvrez en production que vous avez régressé sur un cas que personne n’avait pensé à tester.
Ce qu’on met dans un dataset d’évaluation :
- Les cas nominaux (les requêtes les plus fréquentes attendues).
- Les cas limites (formats inhabituels, données manquantes, ambiguïté).
- Les cas adversariaux (tentatives de contournement, prompts piégés).
- Les cas de régression (tout bug rencontré en production rejoint le dataset).
C’est exactement la logique des tests automatisés en développement logiciel, appliquée à un système non déterministe.
2. Les guardrails : protéger en sortie et en entrée
En PoC, l’utilisateur est de votre côté. Il veut que ça marche. Il pose des questions raisonnables.
En production, vous n’avez plus aucun contrôle sur qui interagit avec l’agent. Certains utilisateurs vont essayer de le faire dévier, par jeu, par curiosité, ou par mauvaise intention. Et un agent qui répond à n’importe quoi est un risque, juridique, réputationnel, parfois opérationnel.
Les guardrails se mettent en place sur deux axes :
En entrée : filtrer ou reformuler les requêtes hors périmètre, détecter les tentatives d’injection de prompt, refuser de traiter des données qui ne devraient pas être là.
En sortie : vérifier que la réponse de l’agent ne contient pas d’informations sensibles, ne produit pas de contenu toxique, et reste dans le cadre fonctionnel prévu. Si l’agent doit appeler une API externe ou exécuter une action, valider que cette action est bien dans la liste autorisée pour cet utilisateur.
Sur un agent qui parle à un client final, c’est non négociable. Sur un agent interne, ça reste fortement recommandé : un collaborateur peut, sans intention malveillante, formuler une requête qui pousse l’agent à divulguer des données qu’il ne devrait pas voir.
3. L’observabilité : voir ce qui se passe à l’échelle
En PoC, vous regardez les conversations une par une. Vous voyez immédiatement si l’agent dérape.
En production, vous avez 1 000, 10 000 ou 100 000 conversations par mois. Vous ne pouvez pas les lire toutes. Sans observabilité, vous découvrez les problèmes uniquement quand quelqu’un se plaint, et bien souvent, le problème existait depuis des semaines.
L’observabilité d’un agent IA, ce sont au minimum :
- Des logs structurés de chaque requête, réponse, et appel d’outil.
- Des métriques agrégées (taux de réussite, latence, coût par requête, taux de refus).
- Des alertes sur les anomalies (chute du taux de réussite, explosion des coûts, hausse des refus).
- Un mécanisme de feedback utilisateur (pouce levé/baissé, note, commentaire) pour identifier les conversations problématiques sans tout relire.
- Des dashboards qui permettent de répondre rapidement à “comment l’agent se comporte cette semaine ?” sans devoir lancer une analyse manuelle.
Quand un problème survient, vous voulez pouvoir remonter à la conversation exacte, voir ce que l’agent a vu, ce qu’il a renvoyé, et pourquoi. Sans cela, vous débuguez à l’aveugle.
La différence d’intention dès le départ
Le piège, c’est de croire qu’on construit d’abord un PoC qui marche, puis qu’on rajoute “les trucs de production” par-dessus. Ça ne fonctionne presque jamais. Les bonnes architectures (où passe la donnée, comment les outils sont appelés, où s’attache la logique métier) ne sont pas les mêmes selon qu’on cherche à impressionner sur trois prompts ou à servir 10 000 utilisateurs avec une garantie de qualité.
Un PoC ambitieux peut être très bon pour valider une idée. Mais le passer en production demande, dans 80% des cas, de refondre l’architecture. Pas par incompétence, par changement d’objectif.
Si vous savez dès le départ que la cible est la production, dites-le à l’équipe. La conception sera différente. Vous gagnerez du temps, du budget, et vous éviterez le moment pénible où il faut expliquer au COMEX que la démo qu’on leur a montrée il y a six mois n’est toujours pas en ligne, et qu’elle ne le sera pas avant six mois de plus.
Ce qu’il faut retenir
Un PoC réussi ne dit qu’une chose : la technologie peut faire ce qu’on lui demande sur un cas cadré. C’est utile, c’est même indispensable. Mais ne confondez jamais cette validation avec une décision de mise en production.
Avant d’ouvrir l’agent à de vrais utilisateurs, posez trois questions à votre équipe :
- Comment mesurez-vous la qualité, et sur quels cas ?
- Que se passe-t-il quand un utilisateur sort du cadre prévu ?
- Comment savez-vous, demain matin, si l’agent a bien fonctionné cette nuit ?
Si les réponses sont vagues, vous n’avez pas un agent en production. Vous avez un PoC déguisé.
Sources
Vous avez un PoC IA qui tourne et vous vous demandez ce qui manque pour le passer à l’échelle ? Échangeons 30 minutes →