Pourquoi 80 % des POC IA ne passent jamais en production (et comment l'éviter)

Le chiffre circule depuis 2023 dans toutes les études de marché : entre 70 et 90 % des POC IA n'atteignent jamais la production. Selon les sources et les périmètres, on retient 80 % comme ordre de grandeur honnête. Ce qui change rarement, c'est la manière de présenter le problème : on parle de pilot purgatory, on regrette le gâchis, on appelle à plus de gouvernance ou plus de méthode. Rarement on nomme précisément les trois mécanismes qui produisent l'échec.

Chez BUMPSLAB, on les nomme : l'effet vitrine, l'effet catalogue, l'effet techno-push. Ce ne sont pas des typologies anecdotiques. Ce sont les trois pièges méthodologiques qui condamnent la majorité des candidats IA, et chacun produit son propre type de POC échoué.

L'effet vitrine : l'IA pour montrer qu'on fait de l'IA

L'effet vitrine apparaît quand le POC IA est commandé pour répondre à un signal externe, pas à un besoin métier. Un conseil d'administration qui demande « où en est-on sur l'IA », un concurrent qui communique sur son agent maison, un client qui interroge sur la maturité IA. Le sponsor débloque un budget, la DSI ou un cabinet propose un cas d'usage présentable, et le POC démarre.

Le candidat est généralement un chatbot interne, un assistant documentaire générique, ou une démo de génération de contenu. La démo est belle. Le métier acquiesce poliment en réunion finale. L'outil n'est plus utilisé trois mois après. Le sponsor le défend dans les comités mais sait, intérieurement, que personne ne s'en sert.

Le signal de l'effet vitrine est facile à repérer : à la question « qui utilise cet outil cinq jours par semaine », personne ne peut citer un nom. Pas un service. Un nom. Si la réponse est floue, le POC était une vitrine, pas un pilote.

La sortie de l'effet vitrine passe par la double écoute. On refuse d'instruire un candidat IA dont les utilisateurs finaux n'ont pas été interviewés individuellement avant le scoping. Pas en groupe. Pas en validation finale. Au cadrage initial, en entretien d'une heure chacun. C'est la première discipline qu'un sponsor sérieux doit imposer à son équipe IA, qu'elle soit interne ou externe.

L'effet catalogue : la prolifération qui paralyse

L'effet catalogue apparaît dans les structures qui ont fait l'effort de cartographier. Workshops, ateliers transverses, formulaires de remontée. Au bout de quelques mois, l'organisation dispose d'un catalogue de quarante à cent cas d'usage IA candidats, scorés, classés, parfois colorés. Le sponsor a un Excel impressionnant. Et aucun pilote n'a démarré.

Pourquoi ? Parce que la priorisation par scoring multi-critères, lorsqu'elle est étendue à un catalogue large, produit toujours une douzaine de candidats à scores comparables. Aucune dimension ne tranche. Aucun candidat ne fait consensus. L'organisation reporte la décision au prochain comité, qui reporte au prochain.

L'effet catalogue tue par paralysie. Il n'échoue pas spectaculairement, il enkyste. Les budgets IA sont consommés en ateliers de priorisation au lieu de pilotes. La DSI s'épuise à maintenir le catalogue. Les sponsors métier finissent par lancer leur propre POC en marge, en SaaS, sans gouvernance, créant le scénario inverse, la dispersion non maîtrisée.

La sortie de l'effet catalogue n'est pas un meilleur scoring. C'est l'introduction de disqualifiants binaires. Un candidat IA, dans la méthode BUMPSLAB, ne se sélectionne pas seulement par addition de points sur cinq axes. Il se filtre par des disqualifiants qui éliminent purement et simplement : pas de sponsor exécutif nommé, pas d'actif data disponible à court terme, valeur de l'erreur incompatible avec un humain dans la boucle. Un disqualifiant coupe le débat. Le scoring 5 axes ne sert qu'à comparer les candidats survivants, et le seuil 18/25 force l'arbitrage.

Si vous avez un catalogue de plus de vingt candidats sans pilote engagé depuis six mois, le problème n'est pas dans le scoring. Il est dans l'absence de disqualifiants. Sujet qu'on traite plus en détail dans Catalogue d'idées IA qui dort.

L'effet techno-push : la solution qui cherche son problème

L'effet techno-push est le plus séduisant des trois, et le plus coûteux. Il apparaît quand l'équipe IA, interne ou externe, choisit le candidat en fonction de la techno qu'elle veut tester, pas en fonction du besoin métier. RAG sur base documentaire parce que c'est mature. Agent autonome parce que c'est tendance. Fine-tuning de modèle interne parce que ça impressionne le COMEX.

Le candidat est défendable techniquement. La démo est convaincante. Mais quand on remonte à la source, le besoin métier n'a pas été instruit indépendamment de la solution. Le process visé n'est pas un point de douleur réel, c'est un terrain de jeu qui matche la techno.

Le résultat se voit en production : l'outil fonctionne, mais la valeur produite est marginale. Le métier utilise sporadiquement, sans changement de processus. Le ROI ne se matérialise pas. Le sponsor finit par couper le budget, sans pouvoir dire si c'est l'IA qui n'a pas tenu ou le choix qui était mauvais.

Le signal du techno-push est révélateur : quand on demande au sponsor « combien d'heures par semaine ce candidat libère sur le poste de l'opérationnel concerné », il n'a pas le chiffre, et personne autour de la table ne l'a calculé. Si on n'a pas mesuré la baseline avant de coder, on ne mesurera pas le gain après.

La sortie du techno-push passe par la séquence rigoureuse : besoin avant solution, mesure avant code, métriques business signées avant POC. Le sponsor signe une page : valeur de baseline, valeur cible, mode de mesure, fenêtre de mesure. Pas une slide. Une page signée. Si cette page n'existe pas, le candidat est en techno-push, qu'on l'admette ou non.

Le cas client : un POC documentaire repris

Un acteur de la finance helvétique, 180 personnes, avait engagé un POC de chatbot documentaire en 2024 avec un grand cabinet. Six mois, 220 000 CHF, technologie maîtrisée. Le POC fonctionnait, à la démo. Trois mois après le déploiement, le chatbot était utilisé en moyenne quatre fois par semaine sur l'ensemble de l'entreprise.

On l'a repris en 2026 avec un AI Use Case Audit. La double écoute J1 a révélé que les opérationnels n'avaient jamais demandé un chatbot. Ils avaient demandé une recherche dans les contrats clients, avec citation de la clause exacte et numéro de page. Pas une conversation. Une recherche.

Le candidat n'avait pas été instruit, il avait été déduit de la techno disponible. Effet techno-push manifeste. On a redéployé en quatre semaines un outil de recherche structuré avec citation systématique, sans interface conversationnelle. Adoption à six semaines : 87 % des opérationnels concernés, deux à trois requêtes par jour.

L'IA sous-jacente était presque la même. Le candidat était différent.

Le contrepoint utile

Tous les POC qui n'atteignent pas la production ne sont pas des échecs. Certains sont des décisions de cadrage saines, on a instruit, on a mesuré, on a constaté que le ROI n'était pas au rendez-vous, on a coupé. C'est le bon comportement. Un sponsor qui couperait moins serait un sponsor qui n'instruit pas.

Le problème statistique des 80 % n'est pas que beaucoup de pilotes meurent. C'est qu'ils meurent pour les mauvaises raisons, vitrine, catalogue, techno-push, et qu'ils auraient pu être disqualifiés avant le code. Le travail d'instruction préalable, fait sérieusement, fait basculer la statistique. Sur les pilotes qu'on engage après un AI Use Case Audit, on tend vers un ratio inverse, la majorité passe en production, parce qu'on a refusé d'engager ceux qui ne le pouvaient pas.

C'est moins glorieux que de lancer dix POC et d'en sauver deux. C'est plus rentable.

Ce qu'il faut imposer avant le prochain POC

Trois disciplines, à imposer indépendamment de qui exécute le pilote, équipe interne, BUMPSLAB, ou autre.

D'abord, exiger la double écoute documentée. Trois à cinq utilisateurs finaux interviewés individuellement, comptes rendus partagés, friction réelle identifiée. Sans ça, vous êtes en effet vitrine en attente.

Ensuite, exiger les disqualifiants explicites avant le scoring. Pas la peine de scorer un candidat si son sponsor n'est pas nommé ou si son actif data n'est pas vérifié. Ces filtres coupent la moitié des catalogues en quinze minutes.

Enfin, exiger les métriques business signées sur une page. Baseline mesurée, cible chiffrée, mode de mesure défini, fenêtre fixée. Si l'équipe IA refuse de s'engager sur cette page, vous êtes en techno-push qui ne dit pas son nom.

Ces trois disciplines ne demandent pas de budget supplémentaire. Elles demandent une exigence sponsor.

---

Si vous avez un POC qui n'a pas atteint la production, ou un sponsor IA qui hésite à relancer après une déception, l'AI Use Case Audit en cinq jours est conçu pour identifier dans laquelle des trois mécaniques le projet précédent s'est fracassé, et instruire un candidat qui n'y retombera pas.