Le POC IA qui finit en production se cadre avant de commencer

Une PME de services teste une IA qui qualifie ses demandes entrantes (cas illustratif, sans nom de client). En démonstration, sur 40 demandes choisies, 85 % sont bien classées. Sur un mois réel, 62 %. Le POC reste « prometteur » pendant deux trimestres, puis plus personne n’en parle.

Le baromètre France Num 2026, publié le 28 septembre 2026, relève que 40 % des TPE et PME utilisent au moins une solution d’IA, soit 14 points de plus en un an, et 53 % des PME. Seules 19 % utilisent une solution payante (32 % chez les PME), alors que 68 % jugent l’impact positif sur leur activité. L’usage progresse vite et reste surtout gratuit et individuel, loin d’un système que l’entreprise fait tourner.

Pourquoi les POC IA meurent, chiffres en main

Gartner, dans un communiqué de juillet 2024, prévoyait qu’au moins 30 % des projets d’IA générative seraient abandonnés après la preuve de concept d’ici la fin 2025. Ses causes : qualité des données insuffisante, contrôles des risques inadéquats, coûts qui dérapent, valeur métier floue.

Le rapport « The GenAI Divide: State of AI in Business » du MIT Media Lab (Project NANDA), de juillet 2025, relève que 95 % des pilotes d’IA générative n’ont produit aucun effet mesurable sur le compte de résultat en six mois. Sa méthode : 52 entretiens, une enquête auprès de 153 dirigeants, 300 déploiements publics analysés.

Sur le terrain, ces causes prennent quatre formes. Personne n’a dit ce que « réussi » veut dire. Le POC a tourné sur un échantillon propre. Son résultat vit dans un écran à part. Personne chez le client n’a la charge de le relire ni de le signer. Ces quatre causes se découvrent au moment de la mise en production, et elles s’écrivent toutes les quatre avant de lancer.

Écrire le critère de réussite avant la première ligne de code

Un critère de réussite tient en quatre éléments : une mesure, un seuil, une date, un juge. Exemple (illustration) : « 80 % des demandes classées comme le ferait la personne qui les traite, mesurés sur un mois de demandes réelles, au 15 novembre, jugés par la responsable du service ». Le seuil vient du calcul de gain : sous quel taux la personne qui relit perd-elle plus de temps qu’elle n’en gagne ? Choisissez d’abord la bonne tâche avec la grille de l’audit IA en PME, puis tirez le seuil du business case.

Sans critère écrit, la phrase qu’on entend en réunion de verdict est « c’est plutôt bien, non ? ». Un POC qui plaît sans réussir ni échouer ne se décide jamais : chacun garde son impression et le sujet glisse au trimestre suivant. Un POC sans date de verdict ressemble à un invité qui ne repart jamais.

Faire tourner le POC sur les données réelles

Retour au cas illustratif, sans nom de client. L’écart tient à l’échantillon : les 40 demandes de départ avaient été choisies par l’équipe, propres, lisibles, en texte. Une demande sur quatre arrive en pièce jointe PDF ou en message vocal, et l’échantillon n’en contenait aucune.

Le réel, ce sont des PDF qui sont des scans sans texte lisible, des messages vocaux de trente secondes avec le bruit d’un couloir ou d’un chantier, des champs vides, des doublons quand le même client écrit par mail puis rappelle. Un échantillon trié à la main écarte tout cela sans que personne s’en aperçoive. Prenez le dernier mois complet, en vrac. Demandez l’export brut avant de lancer. Les exemples qu’on vous envoie volontiers ont déjà été triés.

Brancher le POC là où le travail vit déjà

Un POC qui rend ses résultats dans un tableur ou sur une page à part meurt à la démonstration : personne n’ouvre l’écran en plus. Le travail vit dans le logiciel métier, le CRM ou la boîte partagée. Branchez le POC dessus au moins en lecture, dès le départ : il lit les demandes là où elles arrivent et propose son classement à côté.

C’est l’accès qu’on oublie de demander. Demandez à l’éditeur du logiciel métier un accès en lecture seule, un compte technique ouvert au nom de l’entreprise (le compte d’un salarié disparaît le jour de son départ) et la limite d’appels autorisée par minute. Ces autorisations prennent des semaines, et un POC qui les découvre le jour du verdict a perdu son délai. Le coût réel des branchements surprend presque toujours, et certaines API répondent « tout va bien » alors qu’elles ont avalé l’erreur. L’écriture dans l’outil peut attendre la mise en production ; ce qui casse ensuite en service se lit dans les leçons d’un agent IA en production.

Désigner qui relit, qui corrige, qui signe

Un POC sans propriétaire côté client ne survit pas à la fin de la démonstration. Trois rôles, trois noms : qui relit les sorties, qui corrige les erreurs et les signale, qui signe le verdict et la décision de passer en production. Ces trois rôles reviennent au client.

Sans propriétaire, le POC attend une décision que personne n’a le mandat de prendre. La relecture a un coût : dans le cas illustratif, relire les classements d’une semaine de demandes réelles occupe la responsable du service plusieurs heures (illustration). Bloquez ce temps dans son agenda dès la première semaine, et retirez-lui une tâche en échange. Sans cela, la relecture passe en dernier, et le POC avec elle.

La fiche de POC tient sur une page

Les quatre conditions se rangent sur une page, écrite avant le lancement et signée par la personne qui juge. Voici celle du cas illustratif, sans nom de client :

1. La tâche visée : qualifier les demandes entrantes du service commercial.
2. Le critère et son seuil : 80 % des demandes classées comme le ferait la personne qui les traite (illustration).
3. L’échantillon réel : le dernier mois complet, en vrac, avec ses PDF et ses messages vocaux.
4. L’accès demandé : lecture de la boîte partagée et du CRM, compte technique ouvert avant le premier jour.
5. La personne qui juge : la responsable du service, son nom écrit sur la fiche.
6. La date de verdict : fixée avant le lancement.
7. Si le verdict est non : on arrête, on écrit la raison, on choisit la tâche suivante.

Dans l’illustration, le POC à 62 % échoue au seuil de 80 %, et la fiche dit déjà quoi faire : traiter les PDF et les messages vocaux comme un lot à part, puis mesurer de nouveau sur le même mois. À 62 %, le non est utile : il nomme ce qui manque et la mesure à refaire.

Quand le POC est une perte de temps

Le POC est inutile dans trois cas. La tâche est déjà cadrée et varie peu : une règle fixe suffit, et le POC teste une incertitude qui n’existe pas. Le volume est trop faible : le gain ne paiera jamais la mise en production. Les données sont introuvables : elles vivent dans des têtes ou sur des téléphones, et il faut d’abord les faire exister. Dans ces trois cas, un non écrit avec sa raison vaut mieux qu’un POC de plus. La grille en trois questions tranche en quelques minutes, avant même de rédiger la fiche.

Si une tâche vous occupe l’esprit, la fiche s’écrit à deux : le point de départ sert à ça, trente minutes, et je vous dis franchement si le POC vaut le coup chez vous.