Pourquoi votre PoC IA n'est pas prêt à passer en production
Trois éléments séparent un PoC d'un agent IA fiable en production : jeux d'évaluation, garde-fous et observabilité.
La plupart des équipes mettent un PoC IA en production parce que la démonstration s’est bien passée. Ce n’est pas la même chose qu’être prêt pour la production.
Un agent IA prêt pour la production a besoin de trois choses qu’un PoC n’a presque jamais :
- Des jeux d’évaluation, pour que la qualité soit mesurée et non seulement ressentie.
- Des garde-fous, parce que les vrais utilisateurs, contrairement aux testeurs internes, cherchent activement les failles.
- De l’observabilité, pour repérer les défaillances sur l’ensemble des échanges, et non conversation par conversation.
L’agent qui a impressionné les décideurs et celui sur lequel votre activité 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 correctement à ces trois prompts. Tout le monde est satisfait, et la direction décide le lancement.
Or la démonstration n’a jamais vérifié :
- Ce que fait l’agent quand un utilisateur saisit un prompt ambigu, mal formulé ou conçu pour le piéger.
- 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 : “cela peut-il fonctionner ?”. La mise en production en pose une autre : “cela fonctionne-t-il en permanence, pour tous les utilisateurs, et le savons-nous ?“.
1. Les jeux d’évaluation : sortir du ressenti
Un PoC est validé par un humain qui regarde les sorties et dit “oui, c’est bon”. Ce jugement ne suffit plus en production.
Un jeu d’évaluation 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 fonctionnalité, et vous découvrez en production qu’un cas auquel personne n’avait pensé ne fonctionne plus.
Ce que contient un jeu d’évaluation :
- Les cas nominaux (les requêtes attendues les plus fréquentes).
- Les cas limites (formats inhabituels, données manquantes, ambiguïté).
- Les cas malveillants (tentatives de contournement, prompts piégés).
- Les cas de régression (tout bug rencontré en production rejoint le jeu d’évaluation).
C’est exactement la logique des tests automatisés en développement logiciel, appliquée à un système non déterministe.
2. Les garde-fous : protéger en sortie et en entrée
Au stade du PoC, l’utilisateur est de votre côté. Il souhaite que l’outil fonctionne et 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. Un agent qui répond à toute demande, quelle qu’elle soit, fait peser sur l’entreprise un risque juridique, un risque d’image, parfois un risque opérationnel.
Les garde-fous 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.
Pour un agent en contact avec des clients, ces garde-fous sont indispensables. Pour un agent interne, ils restent vivement recommandés : 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 sur l’ensemble des conversations
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 repose au minimum sur :
- 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 tableaux de bord qui permettent de répondre rapidement à la question “comment l’agent s’est-il comporté cette semaine ?” sans lancer d’analyse manuelle.
Quand un problème survient, il faut pouvoir remonter à la conversation exacte, voir ce que l’agent a reçu, 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 consiste à croire qu’il est possible de construire d’abord un PoC qui fonctionne, puis de lui ajouter après coup les exigences de la production. Cette démarche échoue presque toujours. L’architecture (circulation des données, appel des outils, emplacement de la logique métier) n’est pas la même selon que l’objectif est d’impressionner sur trois prompts ou de servir 10 000 utilisateurs avec une qualité garantie.
Un PoC ambitieux peut très bien servir à valider une idée. Mais le passer en production demande, dans 80% des cas, de refondre l’architecture. Non par incompétence, mais parce que l’objectif a changé.
Si vous savez dès le départ que la cible est la production, dites-le à l’équipe. La conception sera différente. Vous économiserez du temps et du budget, et vous éviterez le moment pénible où il faut expliquer au COMEX que la démonstration qui lui a été présentée il y a six mois n’est toujours pas en ligne, et ne le sera pas avant six mois encore.
Ce qu’il faut retenir
Un PoC réussi ne dit qu’une chose : la technologie peut faire ce qui lui est demandé 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, ce que vous avez en production n’est pas un agent, mais un PoC exposé à de vrais utilisateurs.
Sources
Votre PoC IA fonctionne et vous vous demandez ce qui lui manque pour être déployé à grande échelle ? Échangeons 30 minutes →. Pour outiller vos développeurs, voir la formation Claude Code en production.