Pourquoi les POC d'IA générative ne passent pas en production

Le chiffre que tout le monde cite, et celui qui compte

Le chiffre le plus repris depuis 2025 vient du MIT : sur plus de 300 initiatives d'IA générative publiquement documentées, 52 entretiens structurés et 153 réponses de dirigeants, le rapport The GenAI Divide, State of AI in Business 2025 du programme NANDA (copie miroir, le MIT n'en héberge pas de version publique stable) conclut que 95 % des pilotes n'ont produit aucun effet mesurable sur le compte de résultat.

Il est souvent mal lu. Il ne dit pas que la technologie ne marche pas. Il dit que 95 % des pilotes n'ont jamais atteint le point où on aurait pu mesurer quoi que ce soit. Sa méthodologie a d'ailleurs été discutée, et l'échantillon invite à la prudence : 153 réponses de dirigeants ne font pas un recensement. Le chiffre vaut comme ordre de grandeur, pas comme mesure. Deux autres séries de chiffres cadrent mieux le problème.

D'abord l'abandon. Une enquête S&P Global Market Intelligence menée auprès de plus de 1 000 entreprises et relayée par CIO Dive montre que 42 % des organisations interrogées ont abandonné la majorité de leurs initiatives IA en 2025, contre 17 % l'année précédente, et que l'organisation moyenne abandonne 46 % de ses POC avant la production. Gartner avait annoncé la tendance dès juillet 2024 en prédisant qu'au moins 30 % des projets d'IA générative seraient abandonnés après le POC d'ici fin 2025, pour quatre raisons nommées : qualité des données insuffisante, contrôles de risque inadéquats, coûts qui dérapent, valeur métier floue.

Ensuite l'échelle. Le rapport State of AI de McKinsey publié en novembre 2025 indique que 39 % des répondants constatent un effet de l'IA sur l'EBIT, mais que dans la plupart des cas cet effet reste sous les 5 % de l'EBIT total. Environ un tiers seulement déclare avoir passé l'échelle de l'organisation.

Ces quatre causes Gartner ne sont pas des causes techniques. Ce sont des causes d'ingénierie de production. C'est là que se joue la partie, et c'est une partie qui se prépare avant la première ligne de code.

Le POC ment par construction

Un prototype se construit vite, et c'est exactement son problème. Il est évalué sur une dimension unique : est-ce que la réponse a l'air bonne ? En production, quatre autres dimensions apparaissent d'un coup, qui n'ont jamais été mesurées.

Le POC tourne sur un jeu de données choisi. La production tourne sur les données réelles, avec leurs doublons, leurs champs vides, leurs conventions de saisie contradictoires entre agences et leurs dix ans d'historique mal migré.

Le POC est regardé par son auteur. La production est utilisée par des gens qui n'ont pas écrit le prompt, ne connaissent pas ses limites, et prendront la réponse pour argent comptant.

Le POC n'a pas de coût marginal visible. La production a une facture mensuelle.

Le POC n'engage personne. La production engage l'entreprise, y compris juridiquement.

Le rapport State of Agent Engineering 2026 de LangChain, fondé sur plus de 1 300 praticiens interrogés entre novembre et décembre 2025, confirme le déséquilibre : 89 % des répondants ont mis en place un mécanisme d'observabilité, mais seuls 52,4 % pratiquent une évaluation hors ligne, et moins de la moitié font passer des tests formels à leur système. Tout le monde regarde ce qui se passe. Peu de monde sait dire si c'est bon.

La grille : six questions avant de parler production

Voici la grille. Chaque ligne a une réponse écrite, ou le projet n'est pas prêt. Ce n'est pas une checklist de conformité, c'est une liste de choses qui cassent.

1. Périmètre : qu'est-ce que le système ne fait pas ?

La question utile n'est pas ce que l'agent fait, c'est ce qu'il ne touche pas. Écrire la liste négative avant de coder force les arbitrages qui, sinon, arrivent en production sous forme d'incident. Quels systèmes en lecture seule, lesquels en écriture, quelles tables, quels montants plafonds, quels types de dossiers exclus par nature.

Gartner nomme le symptôme inverse : l'agent washing, la requalification en agent de ce qui n'est qu'un enchaînement de règles, ou à l'inverse la promesse d'autonomie totale sans périmètre écrit. Sur des milliers de fournisseurs revendiquant de l'agentique, Gartner estimait mi-2025 qu'environ 130 proposaient des capacités réellement agentiques.

2. Traçabilité : peut-on reconstituer une décision six mois plus tard ?

Un journal d'audit utile n'enregistre pas la réponse. Il enregistre l'entrée exacte, la version du prompt, l'identifiant du modèle et sa version, les documents ou lignes de base effectivement récupérés, les appels d'outils avec leurs paramètres, la sortie, et l'identité de qui a validé. Sans ces sept champs, un litige client ou un contrôle interne se solde par « on ne sait pas ».

Ce n'est plus seulement une bonne pratique. Depuis le 2 août 2026, les obligations de transparence de l'article 50 du règlement européen sur l'IA s'appliquent : l'utilisateur doit être informé clairement qu'il interagit avec un système d'IA et non avec un humain, et les contenus générés ou modifiés doivent être identifiables. Les manquements peuvent aller jusqu'à 15 millions d'euros ou 3 % du chiffre d'affaires mondial. Les obligations lourdes pesant sur les systèmes à haut risque de l'annexe III ont, elles, été décalées au 2 décembre 2027 par le Digital Omnibus, et au 2 août 2028 pour les composants d'IA intégrés à des produits réglementés. Ce report est un délai, pas une dispense : la traçabilité qu'il exigera se conçoit au moment de l'architecture, pas dix-huit mois après.

3. Validation humaine : sur quoi, et par qui ?

La validation humaine systématique tue la valeur. La validation humaine absente tue le projet. Ce qui marche est une validation proportionnelle au risque de l'action, pas au système entier.

Gartner a mis un nom sur l'erreur dans un communiqué du 26 mai 2026 : appliquer une gouvernance uniforme à tous les agents, quel que soit leur niveau d'autonomie, est la cause racine des échecs. Les entreprises traitent la gouvernance comme binaire, verrouillée ou pleinement confiante, ce qui produit deux modes de panne symétriques : sur-restriction des agents simples, qui ralentit la livraison, et sous-contrôle des agents qui agissent. La prédiction associée : d'ici 2027, 40 % des entreprises rétrograderont ou mettront hors service des agents autonomes à cause de manques de gouvernance identifiés seulement après un incident en production.

En pratique : lecture et synthèse en autonomie, écriture dans un système métier avec revue, mouvement financier ou communication externe avec validation nominative.

4. Retour arrière : combien de temps pour tout annuler ?

Deux mécanismes distincts, souvent confondus. L'arrêt d'urgence coupe le système et bascule sur le processus humain ; il doit être actionnable par une personne d'astreinte, sans déploiement. La réversibilité des effets annule ce que l'agent a écrit dans les systèmes métier ; elle suppose que chaque écriture porte un identifiant de corrélation et qu'une opération inverse existe.

Si personne ne sait répondre à « il a saisi 400 lignes fausses hier soir, comment on revient en arrière », le système n'est pas prêt, quelle que soit la qualité de ses réponses.

5. Évaluation : qu'est-ce qui sert de test de non-régression ?

Un jeu d'évaluation est un actif du projet, au même titre que le code. Il contient des cas réels, annotés par le métier, avec la réponse attendue, y compris les cas où la bonne réponse est « je ne sais pas ». Il tourne à chaque changement de prompt, de modèle, de version de modèle ou de source documentaire.

C'est ce qui permet de changer de modèle sans repartir de zéro, et de détecter une dérive silencieuse. C'est aussi ce qui manque le plus, comme le montre le chiffre LangChain cité plus haut.

6. Coût réel : quelle est la facture par unité de travail ?

Le coût du token baisse, le nombre de tokens explose. L'analyse d'EY sur le coût par interaction chiffre le passage d'un enchaînement linéaire simple en 2023, environ 0,04 dollar par interaction, à un système orchestré avec outils, raisonnement et boucles de reprise en 2026, environ 1,20 dollar, soit près de trente fois plus. EY note aussi les coûts qui n'apparaissent pas sur la facture du fournisseur de modèle : mise à jour des bases de connaissance, évaluation, conception de la collaboration humaine.

La bonne unité de mesure n'est pas le coût mensuel. C'est le coût par dossier traité, comparé au coût actuel du même dossier. Ce ratio décide de l'industrialisation, et il se mesure dès le prototype.

Le tableau de décision

Dimension	Le POC qui meurt	Le POC qui passe
Périmètre	« L'agent gère les commandes »	Liste écrite de ce qu'il ne touche pas, systèmes en lecture seule identifiés
Données	Extraction propre préparée à la main	Données de production, cas sales inclus dès la deuxième semaine
Traçabilité	Logs applicatifs	Entrée, version de prompt, version de modèle, sources, appels d'outils, validateur
Validation	Uniforme ou absente	Graduée par risque de l'action, nominative sur les opérations sensibles
Retour arrière	Non posé	Arrêt d'urgence sans déploiement, et opération inverse par écriture
Évaluation	Jugement de l'auteur	Jeu annoté par le métier, rejoué à chaque changement
Coût	Facture mensuelle observée	Coût par dossier, comparé au coût actuel
Décision d'arrêt	Implicite, par lassitude	Critère chiffré écrit avant de commencer

La dernière ligne est celle qu'on oublie. Décider à l'avance du seuil en dessous duquel on arrête, et l'écrire, est ce qui distingue un arrêt propre d'un enlisement. Conclure qu'un cas d'usage ne vaut pas le coup est un résultat, pas un échec, à condition d'avoir dépensé trois semaines et non neuf mois pour l'établir.

Ce qui se fait lundi matin

Trois actions, dans l'ordre, sur un projet déjà en cours.

Sortir le jeu d'évaluation du prototype. Prendre trente dossiers réels, dont dix difficiles et cinq où la bonne réponse est un refus, les faire annoter par le métier, et mesurer. Le chiffre obtenu est la première information honnête du projet.

Écrire la liste négative. Une page, validée par le responsable métier et par le RSSI, disant ce que le système ne touche pas. Elle réduit la surface de discussion de moitié.

Calculer le coût par dossier sur le prototype, et le poser à côté du coût actuel. Si l'écart n'est pas franc, le problème n'est pas la qualité du modèle, c'est le choix du cas d'usage.

Si le cadrage de ces trois points est le sujet, l'offre de cadrage est conçue exactement pour ça.