Les données que votre POC n'a jamais vues : pourquoi le prototype rate la production

---

title: "Les données que votre POC n'a jamais vues : pourquoi le prototype rate la production" seoTitle: "POC IA : l'échec vient des données réelles" description: "Un POC IA validé en démo s'effondre sur les données réelles de l'entreprise. Voici les cinq écarts entre l'échantillon de prototypage et la matière de production, le protocole de cinq jours qui les chiffre, et ce qu'il faut exiger avant de s'engager sur une industrialisation." seoDescription: "Un POC IA validé s'effondre sur les données réelles : les cinq écarts à mesurer et le protocole de cinq jours qui les chiffre avant de s'engager." date: "2026-10-07" author: "Équipe Raicode" tags: ["IA", "automatisation", "architecture", "qualité"] category: "IA & Automatisation" keywords: ["POC IA passage en production", "du POC à la production IA", "qualité des données IA", "industrialiser un POC IA", "échantillon de données LLM", "jeu de données production", "extraction documentaire LLM", "reprise projet IA", "silos de données"]

Le prototype traite les quarante documents de la démo sans une erreur. Six semaines plus tard, branché sur la vraie base, il en rate un sur trois. Entre les deux, personne n'a touché au modèle ni au prompt. Ce qui a changé, c'est la matière qui entre dans le système — et c'est la seule variable que le POC n'avait pas le droit de mesurer, puisqu'on lui avait soigneusement préparé son repas.

C'est le scénario le plus fréquent dans les projets IA que nous reprenons, et il est systématiquement diagnostiqué au mauvais endroit. L'équipe conclut que le modèle est insuffisant, lance un comparatif de fournisseurs, teste un modèle plus gros, envisage un fine-tuning. Trois mois passent, la justesse ne bouge pas de plus de deux points, et le projet s'arrête faute de budget. Le modèle n'était pas le problème : les documents qu'on lui donnait en production n'avaient presque rien à voir avec ceux de la démo.

Cet article s'adresse à une équipe qui a un POC validé, une pression pour l'industrialiser, et un doute sur ce qui se passera au contact du réel. Il décrit les cinq écarts qui séparent un échantillon de prototypage de la matière de production, le protocole de cinq jours qui les transforme en chiffres, et ce qu'il faut écrire dans un engagement de phase 2 pour ne pas acheter un échec à l'avance.

Le chiffre que tout le monde cite, et ce qu'il dit vraiment

Un chiffre circule dans tous les articles sur le sujet : un modèle à 92 % de justesse sur 500 lignes d'échantillon tombe à 64 % sur 50 000 lignes réelles. Il est répété sans source précise et il faut donc le traiter pour ce qu'il est — un ordre de grandeur, pas une loi. Les écarts que nous mesurons vont de six points à quarante selon les projets.

Mais l'ordre de grandeur est juste, et surtout sa direction est toujours la même. Nous n'avons jamais vu un système gagner en justesse en passant de l'échantillon au réel. Cela suffit à rendre absurde la pratique dominante : décider d'une industrialisation sur la foi d'un taux mesuré sur des données choisies.

Les deux autres statistiques du secteur — 88 % des POC qui n'atteignent jamais la production à l'échelle, 46 % des initiatives qui s'arrêtent entre le POC et la production — méritent la même prudence, et un commentaire. Elles mélangent deux échecs qui n'ont rien à voir : les projets qui meurent parce que l'organisation n'en voulait pas vraiment, et ceux qui meurent parce que la technique ne tient pas au contact des données. Seul le second est de votre ressort. L'intérêt de ce qui suit est précisément de savoir, en une semaine, dans quelle catégorie vous êtes — avant de dépenser le budget de la phase 2.

Les cinq écarts entre l'échantillon et le réel

Un jeu de démonstration n'est pas un petit jeu de production. C'est un jeu différent par construction, et la différence se décompose en cinq écarts qu'il faut mesurer séparément, parce qu'ils ne se corrigent pas avec les mêmes moyens.

1. La sélection — les documents de la démo ont été choisis

C'est l'écart le plus grossier et le plus universel. Quand on monte un POC, quelqu'un exporte des fichiers. Ce quelqu'un prend les plus récents, les plus propres, ceux dont il comprend le contenu, et il écarte sans y penser ceux qui l'embêtent — le scan de travers, le fichier de 400 pages, celui dont le format ne s'ouvre pas.

Le biais n'est pas malveillant, il est mécanique. Mais il déplace le niveau de difficulté du jeu entier. Nous avons repris une extraction de factures fournisseurs dont le POC affichait 94 % de champs corrects. L'export de départ venait d'un seul ERP, sur douze mois, sur des fournisseurs récurrents. La production, elle, voyait aussi les factures reçues par e-mail en photo, celles d'un second ERP hérité d'une acquisition, et les notes de frais que le service comptable range au même endroit. Sur un tirage réellement aléatoire, le même système tombait à 71 %.

2. La forme — le réel est sale, et il l'est de façons précises

Les champs vides, les doublons, les encodages mélangés, les dates au format américain dans une base française, les montants avec des espaces insécables, les noms de société écrits de six manières différentes. Chacun de ces défauts est trivial pris isolément ; pris ensemble, ils forment la moitié du taux d'échec.

Ce qui compte ici n'est pas de constater que « les données sont sales » — tout le monde le sait et personne n'en fait rien. C'est d'en sortir une liste chiffrée : quel pourcentage de lignes est concerné par quel défaut. Un défaut qui touche 0,3 % du volume se traite par une exception manuelle. Un défaut qui touche 14 % est un chantier d'ingénierie de données à budgéter dans la phase 2, et il doit apparaître dans le devis.

3. La distribution — la queue longue n'était pas dans l'échantillon

Quarante documents de démo couvrent les cas fréquents. Ils ne contiennent, par construction, aucun cas rare. Or en production les cas rares ne sont pas rares collectivement : ils représentent souvent 15 à 25 % du volume, et ce sont eux qui produisent les erreurs les plus coûteuses, parce que ce sont eux que personne ne sait vérifier.

C'est le point où se décide la viabilité économique du projet, et il se formule simplement : quelle proportion du volume le système doit-il traiter pour que l'automatisation ait un sens ? Si le gain métier suppose 90 % de traitement automatique et que la queue longue en représente 20 %, le projet est condamné avant d'avoir commencé, quel que soit le modèle. Si 70 % suffisent avec une file de reprise humaine pour le reste, il est jouable immédiatement.

4. Le temps — les données bougent, le POC est figé

Un POC est une photographie. La production est un flux. Entre les deux s'intercale tout ce qui change : un formulaire de saisie modifié, une nouvelle gamme de produits, un client qui change de nomenclature, une migration d'outil qui réécrit les libellés. Un système d'extraction ou de classification calibré sur un trimestre donné perd mécaniquement en justesse à mesure que la matière s'éloigne de ce trimestre.

Cet écart ne se mesure pas sur un instantané. Il se mesure en rejouant le même jeu d'évaluation sur des tranches temporelles différentes — un échantillon par trimestre sur deux ans. Si la justesse décroche de huit points entre le plus ancien et le plus récent, vous ne tenez pas un système qu'on livre et qu'on oublie : vous tenez un système à ré-évaluer périodiquement, et ce coût de surveillance doit entrer dans le budget de run dès maintenant.

5. L'accès — la donnée dont vous avez besoin n'est pas accessible

Le POC a tourné sur un export CSV posé sur le bureau de quelqu'un. La production suppose une connexion à l'outil source, avec des droits, un rythme de rafraîchissement, une gestion des suppressions et un responsable qui réponde quand le flux casse. Dans les cas que nous reprenons, c'est l'écart qui coûte le plus de semaines, et c'est le seul qui soit entièrement organisationnel.

Il se révèle par trois questions, à poser avant toute estimation. Qui est propriétaire de la source ? Existe-t-il une interface d'accès, ou faut-il la construire ? Et le volume complet est-il seulement autorisé à sortir de son système — question qui croise souvent une contrainte de confidentialité et renvoie à un arbitrage d'architecture sur l'endroit où tourne le modèle.

Le protocole de cinq jours qui transforme le doute en chiffre

Ces cinq écarts se mesurent en une semaine, sans rien construire de neuf. Le principe est de rejouer le POC existant, tel quel, sur un échantillon qu'il n'a pas choisi.

Jour 1 — inventorier les sources réelles. Pas celles du POC : toutes celles que la production verra. Pour chacune, le volume, l'ancienneté, le format, le propriétaire, et le mode d'accès. Cet inventaire tient sur une page et il surprend presque toujours quelqu'un dans la salle. C'est souvent ici qu'apparaît la troisième source dont l'équipe technique ignorait l'existence.

Jour 2 — tirer un échantillon vraiment aléatoire. 300 à 500 unités, tirées au hasard sur la totalité de la période et de toutes les sources, sans aucun filtre de qualité, sans écarter ce qui ne s'ouvre pas. Ce qui ne s'ouvre pas est une donnée du problème, pas un incident à exclure. Si vous ne devez retenir qu'une seule chose de cet article, c'est ce tirage : il coûte deux heures et il dit à lui seul si le projet tient.

Jour 3 — constituer la vérité terrain. Quelqu'un qui connaît le métier annote le résultat attendu sur cet échantillon. C'est la seule étape réellement coûteuse — comptez une à deux journées-homme pour 300 unités — et c'est celle que tout le monde essaie d'éviter. Sans elle, vous n'avez pas de mesure, vous avez une impression. C'est le même investissement que celui décrit dans notre article sur l'évaluation d'un agent avant la mise en production, et il se réutilise ensuite à chaque changement de prompt ou de modèle.

Jour 4 — rejouer et classer les échecs. Lancez le POC sur l'échantillon annoté, puis classez chaque échec dans l'un des cinq écarts ci-dessus, plus une catégorie « le modèle s'est trompé alors que la donnée était bonne ». Cette dernière catégorie est celle qui justifie de travailler le modèle. Dans les diagnostics que nous menons, elle dépasse rarement un quart des échecs.

Jour 5 — produire le verdict. Trois chiffres suffisent : le taux de justesse sur données réelles, la part du volume traitable automatiquement au seuil de qualité exigé par le métier, et la répartition des échecs par cause. Avec ces trois chiffres, la décision d'industrialiser devient défendable devant une direction financière. Sans eux, c'est un pari.

Ce que le verdict change dans la décision

Le résultat oriente vers l'une de trois branches, et aucune n'est l'échec du projet.

La justesse tient sur le réel, les échecs sont concentrés sur une cause identifiée. C'est le meilleur cas et il est plus fréquent qu'on ne croit. On industrialise en traitant d'abord cette cause — souvent un format source ou une catégorie de documents — plutôt qu'en touchant au modèle.

La justesse décroche mais une sous-population tient. On restreint le périmètre de la version 1 à ce sous-ensemble mesurable, avec une règle d'aiguillage explicite et une file humaine pour le reste. Un système qui traite 60 % du volume de façon fiable et le reconnaît crée de la valeur ; un système qui prétend tout traiter à 85 % en détruit, parce qu'il oblige à tout revérifier.

La justesse décroche partout et les causes sont dispersées. Alors le chantier n'est pas un chantier d'IA, c'est un chantier de données, et il faut le dire avant de dépenser la phase 2. C'est le constat le plus difficile à porter et le plus utile. Il nous arrive de le rendre à l'issue d'une reprise de projet IA : la bonne recommandation est parfois d'arrêter le modèle pendant un trimestre et de nettoyer la source, parce qu'aucun prompt ne rattrape une donnée absente.

À ce stade, un POC bloqué dont les causes sont ailleurs que dans la matière — latence, coût, exploitation, intégration — relève d'un autre diagnostic, que nous avons décrit dans les six murs qui empêchent un POC IA de passer en production.

Ce qu'il faut exiger avant de signer une phase 2

Si vous achetez une industrialisation à un prestataire, ou si vous la faites financer en interne, une seule clause change tout : le critère d'acceptation se mesure sur un échantillon aléatoire de données de production, tiré par le client, après la signature.

Cette phrase déplace le risque au bon endroit. Elle interdit la démonstration sur dossier choisi, elle oblige à qualifier la matière avant de chiffrer, et elle rend explicite ce qui reste à la charge de qui : si le prestataire découvre que 14 % des documents sont illisibles, c'est un avenant de préparation de données, pas une faute de l'un ou de l'autre.

Ajoutez-y trois éléments : le seuil de justesse attendu exprimé par catégorie de document et non en moyenne, le taux de couverture minimal du volume, et le comportement attendu en cas de doute — un système qui refuse de répondre quand il n'est pas sûr vaut beaucoup mieux qu'un système qui invente, et cela se spécifie dès le devis.

Ce que vous pouvez faire cette semaine

Si vous avez un POC validé qui attend un feu vert, ne commandez pas un comparatif de modèles. Faites le tirage du jour 2 : 300 unités au hasard sur toute la période et toutes les sources, sans filtre, et passez-les dans le prototype existant. Même sans annotation complète, le simple taux de documents que le système refuse de traiter ou traite visiblement de travers vous donnera, en une demi-journée, une idée plus juste de la faisabilité que six semaines de réunions.

Le POC a répondu à la question « est-ce que cette idée peut marcher ». Il n'a jamais répondu à « est-ce que cela marche sur ce que nous avons ». C'est une autre question, elle se mesure, et elle coûte une semaine — contre un trimestre de budget mal engagé.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.