POC IA réussi, production ratée : les 7 différences à maîtriser

Une démo réussie ne prouve pas qu’un système IA est prêt pour la production

Une démonstration prouve la faisabilité sur des cas choisis. La production ajoute sept exigences qu’un POC n’a jamais eu à traiter : évaluation reproductible, cas non passants, maîtrise des coûts, observabilité, contrôle des accès, comportement de repli et adoption.

Un POC répond à une seule question : est-ce techniquement possible ? On y parvient avec un modèle, quelques prompts, un jeu d’exemples choisis et une personne qui sait exactement quoi taper. Rien de tout cela ne disparaît en production, mais rien de tout cela ne suffit plus. Le système rencontre alors des utilisateurs qui ignorent ses limites, des données qu’il n’a jamais vues, des volumes qui transforment un coût anecdotique en ligne budgétaire, et des incidents qu’il faudra expliquer à quelqu’un.

L’écart se lit dans les plateformes elles-mêmes. Googlene présente pas Vertex AI Agent Engine comme un simple hébergeur d’agents : sa documentation place au même niveau le déploiement, l’évaluation de la qualité, le traçage via Cloud Trace, la journalisation et les métriques de supervision. Ce qu’un prototype traite comme des sujets à voir « plus tard » constitue, dans un environnement industriel, une partie du produit.

Les sept différences qui suivent ne forment pas sept chantiers indépendants. Les deux premières portent sur ce que le système produit, les deux suivantes sur ce qu’il consomme et sur la trace qu’il laisse, les deux d’après sur ce qu’il a le droit de faire et sur son comportement lorsqu’il n’y arrive pas. La septième décide si l’ensemble sert à quelque chose. Surtout, elles se conditionnent : l’évaluation a besoin des traces, le repli a besoin des budgets, la sécurité a besoin des journaux, et l’adoption a besoin des six autres.

1. Mesurer la qualité au lieu de la constater

En POC, la qualité s’apprécie à la main sur quelques exemples, et c’est rationnel à ce stade : l’objectif est de savoir si la piste tient, pas de la garantir. Cette méthode a pourtant un défaut qui devient rédhibitoire en production : elle ne détecte pas les régressions. Un système génératif peut changer de comportement pour des raisons qui n’apparaissent nulle part dans le code applicatif : une version de modèle qui évolue, un prompt ajusté, un outil ajouté, une base documentaire mise à jour, une API dont le format change. Sans jeu d’évaluation reproductible, personne ne peut dire si une modification a amélioré ou dégradé le système. Il ne reste que des impressions.

Les critères utiles dépendent du cas d’usage, mais ils répondent en général à trois questions distinctes. La réponse est-elle correcte ? On mesure alors l’exactitude, l’ancrage dans les sources fournies et le taux d’hallucination. Le système s’est-il comporté comme prévu ? On regarde le respect des consignes, la sélection des outils et les refus attendus. L’utilisateur a-t-il obtenu ce qu’il venait chercher ? Ce sont le taux de résolution, les escalades et la satisfaction. Ces trois questions ne se substituent pas les unes aux autres : un système peut être exact et inutilisable, ou apprécié et faux.

Google documente les deux moments où cette mesure compte. Avant le déploiement, la suite d’évaluation doit fonctionner comme une porte de qualité exécutée automatiquement à chaque changement, la livraison échouant si les scores passent sous les seuils définis. Après la mise en production, l’évaluation doit être rejouée périodiquement sur les données réelles, précisément pour détecter une dégradation progressive. La construction d’un tel jeu d’évaluation fait l’objet d’un décryptage à part entière.

2. Sortir du scénario qui fonctionne

Une démonstration montre le chemin qui aboutit, et il n’y a rien de malhonnête à cela : c’est son objet. La production, elle, est largement faite du reste. Les difficultés réelles se répartissent en trois familles. L’entrée peut être insuffisante : donnée manquante, demande ambiguë, question hors périmètre. Une dépendance peut céder : API indisponible, outil en erreur, délai dépassé. Enfin, le système peut produire lui-même le problème : résultat incohérent, contenu inattendu, boucle qui ne converge pas.

La différence avec un POC ne tient pas au nombre de cas couverts, mais à l’existence d’un comportement attendu lorsqu’aucune bonne réponse n’existe. Dans un prototype, un échec est un défaut à corriger ; en production, c’est une situation à spécifier. Un agent industrialisé doit savoir échouer correctement, et l’échec dangereux n’est pas le message d’erreur : c’est la réponse plausible produite sans fondement, que l’utilisateur n’a aucun moyen de distinguer d’une bonne réponse.

Ces cas non passants ont vocation à rejoindre le jeu d’évaluation décrit au point précédent. Un incident compris qui ne devient pas un cas de test se reproduira.

3. Faire du coût une variable pilotée

Cinquante exécutions coûteuses passent inaperçues pendant un POC. À cent mille exécutions mensuelles, la même architecture devient un sujet de direction financière. Le volume n’est pourtant pas la vraie difficulté : c’est la dispersion. Une étude publiée en avril 2026 par Bai et al., portant sur huit LLM frontier évalués sur SWE-bench Verified, mesure jusqu’à 1 000 fois plus de tokens pour des tâches agentiques que pour des tâches de code reasoning ou de conversation, et surtout jusqu’à 30 fois d’écart entre deux exécutions d’une même tâche. Les auteurs constatent également que les tokens d’entrée dominent la facture et que les modèles sous-estiment systématiquement leur propre consommation.

La conséquence est directe : un coût moyen calculé sur une démonstration ne dit rien de la facture. Trois mesures deviennent nécessaires. Le coût moyen par exécution donne la tendance. Le coût au 95e centile (p95) montre ce que produisent les exécutions qui dérapent, c’est-à-dire celles qui font réellement l’addition. Le coût par tâche réussie, enfin, est le seul qui permette de comparer deux architectures : un modèle moins cher au token mais qui s’y reprend à trois fois n’est pas un modèle moins cher. Mesurer la consommation étape par étape complète le dispositif, puisque c’est la seule façon de savoir quoi optimiser. Nous détaillons cette économie dans notre décryptage sur le coût réel d’un agent IA.

4. Rendre le comportement du système explicable

Un journal qui indique « erreur LLM » ne permet pas de corriger grand-chose. La raison est structurelle : dans une application classique, une pile d’appels désigne l’endroit du problème, alors que dans un système agentique la défaillance est le plus souvent une décision, et une décision ne produit aucune exception à inspecter. Il faut donc pouvoir reconstruire l’enchaînement complet : demande → contexte fourni → modèle appelé → décision prise → outil utilisé → résultat obtenu → réponse rendue.

C’est exactement ce que les plateformes ont commencé à outiller. Agent Engine s’appuie sur Cloud Trace pour visualiser la séquence d’actions d’un agent et sur Cloud Logging pour ses journaux, et propose un tableau de bord qui suit dans le temps la consommation de tokens, la latence, le taux d’erreur et les appels d’outils.

L’observabilité n’est pas une exigence parmi d’autres : c’est celle qui rend les autres possibles. Les traces alimentent le jeu d’évaluation, fournissent le coût par étape et constituent la piste d’audit attendue côté sécurité. Elle ne consiste pas pour autant à tout journaliser, question que nous traitons dans notre décryptage sur l’observabilité des agents IA.

5. Traiter les accès comme une propriété de l’architecture

En prototype, un compte technique très permissif simplifie le développement, et ce n’est pas de la négligence : cela supprime une variable pendant l’exploration. Le raccourci devient structurel pour une raison simple : une fois le système en place, réduire des permissions revient à risquer de casser quelque chose qui fonctionne. Personne ne s’en charge spontanément.

Cinq propriétés doivent donc être posées avant la mise en production : une identité propre à l’agent, un périmètre limité au strict nécessaire, des permissions explicites plutôt qu’héritées, une journalisation exploitable en cas d’incident, et une révocation déjà testée. Les deux références du domaine convergent sur ce point. Le NIST, via son centre NCCoE, a publié le 5 février 2026 un document de cadrage consacré à l’identité et à l’autorisation des agents logiciels et IA, en vue d’un projet de démonstration appuyé sur les standards d’identité existants. Microsofta publié en juillet 2026 des recommandations de moindre privilège pour les agents : identité dédiée avec propriétaire identifié, rôles conçus autour de tâches plutôt que d’organigrammes, ensemble d’outils explicitement autorisés, élévations de privilèges temporaires et journal d’audit permettant de reconstituer l’action réalisée.

Le principe sous-jacent mérite d’être rappelé : un prompt n’est pas un système d’autorisation. Les contrôles correspondants sont détaillés dans notre décryptage sur la sécurité des agents IA.

6. Décider à l’avance ce qui se passe quand ça échoue

La bonne question n’est pas « que se passe-t-il en cas d’échec ? » mais « qui a décidé de ce qui se passe ? ». En POC, personne ne tranche, parce qu’un échec signifie simplement relancer la démonstration. En production, une absence de décision reste un comportement : le système attend, réessaie indéfiniment, ou répond quand même.

Cinq situations méritent une réponse écrite : le modèle est indisponible ou dégradé, un outil renvoie une erreur, le niveau de confiance est insuffisant, le budget de l’exécution est dépassé, le délai maximal est atteint. Les réponses possibles forment une échelle de repli, le fallback, de la plus légère à la plus radicale : reprise contrôlée → modèle alternatif → réponse dégradée annoncée comme telle → transfert vers un humain → arrêt explicite. Choisir le cran adapté à chaque situation est une décision d’architecture, pas un détail d’implémentation.

Deux erreurs coûtent particulièrement cher. Réessayer sans limite transforme un incident en facture, ce qui ramène au troisième point. Répondre malgré tout produit exactement l’échec silencieux décrit au deuxième. Ces comportements doivent donc être écrits, testés et observables avant la mise en production, au même titre que le chemin nominal.

7. Concevoir l’adoption en même temps que le système

Un agent techniquement excellent mais ignoré par ses utilisateurs n’est pas industrialisé : il est seulement disponible. L’adoption est souvent traitée comme un sujet de conduite du changement, alors qu’elle dépend d’abord de propriétés du produit. La confiance se construit sur la capacité du système à montrer ce qu’il a fait et à dire quand il ne sait pas, ce qui renvoie aux deuxième et quatrième points. L’intégration pèse davantage que l’interface : un assistant qui vit dans les outils déjà utilisés rencontre moins de résistance qu’un outil supplémentaire à ouvrir. Enfin, un canal de retour n’a d’intérêt que s’il alimente réellement le jeu d’évaluation : sans cela, il enregistre des mécontentements sans rien corriger.

L’adoption n’est donc pas une étape postérieure au développement : elle fait partie du produit. Les leviers qui la font progresser, et ceux qui n’y changent rien, sont analysés dans notre décryptage sur l’adoption de l’IA en entreprise.

La grille Slash Tech : POC contre production

Les indicateurs à instrumenter avant de passer à l’échelle

Un système de ce type peut échouer de cinq manières indépendantes : mal répondre, répondre trop lentement, coûter plus qu’il ne rapporte, n’être utilisé par personne, ou agir au-delà de son périmètre. Un tableau de bord utile couvre donc ces cinq familles, sans quoi une défaillance restera invisible jusqu’à ce qu’un utilisateur la signale.

Conclusion

Le passage du POC à la production n’est pas un problème de prompt engineering : c’est un problème de système. Modèle, données, sécurité, observabilité, coûts, repli et adoption ne s’additionnent pas, ils se conditionnent. C’est la raison pour laquelle un projet peut rester bloqué au stade de la démonstration alors que le modèle, lui, fonctionne très bien.

La question à se poser en fin de POC n’est donc pas « est-ce que ça marche ? », mais « saurions-nous dire, demain, que ça ne marche plus ? ».