Pourquoi vos PoC font Plouf ! (Architecture de la non-décision)

En 2017, un développeur finlandais publie un billet LinkedIn qui ne fait pas de bruit ↗. Il s’appelle Sami Tähtinen, il est Chief Architect chez Youredi, et il pose un diagnostic qui aurait dû servir d’avertissement : le PoC est une drogue douce. Il démontre que la faisabilité prouvée en laboratoire ne préjuge en rien de la viabilité en production. Personne ne l’écoute vraiment (ou plutôt : tout le monde acquiesce et personne ne change rien).

Sept ans plus tard, MIT NANDA ↗, Gartner ↗ et BCG ↗ publient des chiffres qui disent la même chose avec des décimales.

Les chiffres que personne ne conteste plus

Gartner (juillet 2024) ↗ : au moins 30 % des projets GenAI abandonnés après PoC, pour mauvaise qualité des données, coûts escaladants ou valeur métier floue. La GenAI a officiellement rejoint le « trough of disillusionment » du Hype Cycle.

MIT NANDA – The GenAI Divide ↗ (juillet 2025) : 52 organisations interviewées, 153 leaders sondés, plus de 300 déploiements publics analysés – 95 % des pilotes enterprise ne produisent aucun impact P&L mesurable. Sur les entreprises ayant évalué des systèmes IA, 60 % ont atteint l’évaluation, 20 % le pilote, 5 % la production.

BCG – The Widening AI Value Gap ↗ (septembre 2025) : sur 1 250 entreprises dans 59 pays, 5 % seulement génèrent de la valeur IA à l’échelle. Ces « future-built companies » affichent une croissance de revenus 1,7 fois supérieure à la majorité. S&P Global ↗ précise que 42 % des entreprises ont abandonné la majorité de leurs initiatives IA en 2025 – contre 17 % en 2024.

La variation est frappante : +147 % d’abandons en un an. Ce n’est pas un problème de maturité technologique, plutôt un problème de système.

Ce que le PoC résout, et ce qu’il évite soigneusement

Un PoC répond à une question précise : cette technologie peut-elle résoudre ce problème dans des conditions contrôlées ? La réponse est presque toujours oui. Les données sont propres, le périmètre est défini, l’équipe est motivée, les parties prenantes assistent à la démo.

Ce que le PoC ne teste pas : la qualité des données en conditions réelles, avec leur variabilité et leurs biais de collecte ; l’infrastructure de déploiement (un modèle sur le laptop d’un data scientist (spécialiste des données) n’est pas un système servant des milliers de requêtes simultanées) ; l’alignement organisationnel entre l’équipe IA, les équipes métier, la DSI et la direction ; le coût de maintien en conditions opérationnelles.

La documentation Microsoft sur la maturité MLOps (gestion du cycle de vie des modèles en production) ↗ est explicite : le code produit dans un accélérateur PoC n’est pas conçu pour la production. Le passage PoC vers MVP implique une refonte de la stack (réseau, gestion des identités, CI/CD, observabilité). Ce sont deux projets différents.

Pourtant, on continue de lancer des PoC. Pourquoi ?

L’architecture de la non-décision

Max Weber ↗, dans Le Savant et le Politique, distingue deux éthiques que rien ne réconcilie. L’éthique de conviction répond du résultat conforme à ses principes : celle du sachant, du data scientist qui prouve que le modèle fonctionne, qui s’engage sur la précision et le rappel, et qui ne peut pas répondre d’autre chose que de son résultat technique. L’éthique de responsabilité répond des conséquences, y compris celles qu’on n’a pas voulues : celle du DSI qui doit arbitrer entre cette vérité technique et dix autres contraintes (budget, régulation, compatibilité, risque réputationnel, calendrier) et qui assumera l’incident si le modèle se trompe en production.

Ces deux éthiques ne fusionnent pas. Aucune réorganisation, aucun comité, aucun workflow ne les articule sans heurt – parce que ce qu’elles demandent est structurellement opposé : ici, prouver versus assumer. C’est précisément pour ça que l’institution doit construire le moment où l’une cède la place à l’autre. Pas une étape d’un processus. Un seuil – politique avant d’être technique.

Le pilot purgatory (terme forgé par Gartner pour désigner le purgatoire des pilotes IA qui ne passent jamais en production), c’est l’absence de ce seuil. Le sachant livre. Le décideur acquiesce. Personne ne fait passer la décision d’un régime à l’autre, parce que personne n’a été désigné pour porter le poids de l’éthique de responsabilité dans ce dossier précis.

Henry Mintzberg ↗ l’a décrit d’une autre manière : le faux consensus, la décision collective qui n’appartient à personne. En France particulièrement, ne pas s’opposer n’est pas approuver. C’est une posture qui protège.

« Personne n’a jamais perdu son poste après un PoC raté. »

Personne n’a jamais perdu son poste après un PoC raté. Warren Buffett avait évoqué cet inconfort en décrivant pourquoi il avait préféré s’abstenir plutôt que voter contre le plan de rémunération de Coca-Cola en 2014 ↗ : on ne « rote pas en société ». Le PoC IA est, entre autres choses, une version institutionnalisée de ce réflexe.

Trois postures, que je retrouve d’un dossier à l’autre, sans qu’elles soient jamais nommées comme telles. Il y a ceux pour qui ce n’est pas leur combat : le PoC répond à une injonction venue d’en haut, ils l’exécutent sans conviction ni opposition franche. Il y a ceux qui s’achètent du temps : conscients que le brouillard technologique est réel, ils parient que la situation se clarifiera une fois la démo livrée. Ce n’est pas de l’immobilisme, c’est de la prudence rationnelle mal outillée. Et il y a ceux qui utilisent le PoC comme alibi : la case cochée, le signal envoyé à la direction, sans jamais avoir eu l’intention de déployer si ce n’est sur un malentendu parce que ce n’est pas la fonction première du PoC.

Ce qui consolide le tout, c’est le risque asymétrique. Un pilote qui ne passe pas en production disparaît dans les archives. Un déploiement raté laisse des traces dans les systèmes, dans les budgets, dans les relations avec les équipes métier.

BCG nomme ce phénomène le « GenAI burden » ↗ : des PoC en silos, non scalables, non réutilisables, qui s’accumulent sans jamais constituer une capacité durable.

Certains PoC sont rationnels. Quand le brouillard technologique est réel, maintenir un portfolio d’expérimentations à faible coût est une stratégie défendable. Le problème n’est pas le PoC en lui-même. C’est l’absence de critère qui transformerait un PoC réussi en décision de déployer. Sans ce critère, même les PoC raisonnables alimentent l’architecture de la non-décision.

Ce que font les 5 % qui passent en prod

Trois gestes les distinguent – politiques autant que techniques.

Le critère de sortie est fixé avant le premier sprint. La MIT Survivability Matrix ↗ pose la question en deux axes : spécificité du domaine et profondeur d’intégration dans le workflow réel.

Seul le quadrant haute spécificité et haute intégration produit un ROI mesurable. Ce n’est pas un outil technique. C’est un outil de décision politique, parce qu’il force à nommer – avant que le premier euro soit engagé – ce qui constitue un succès. Et ce qui, s’il n’est pas atteint, justifie l’arrêt.

La répartition budgétaire est inversée. BCG ↗ documente une règle de répartition : 10 % sur la technologie, 20 % sur les données et l’architecture, 70 % sur les personnes, les processus et la conduite du changement. C’est l’inverse de ce que font la plupart des entreprises. Quand le budget parle, la décision est prise – pas avant. Une organisation qui alloue 80 % de son budget IA à la technologie a déjà dit quelque chose sur ses priorités réelles, même si personne ne l’a formulé explicitement.

La gouvernance est traitée comme une feature, pas comme un audit. Dans les secteurs régulés – banque, assurance – la contrainte réglementaire est souvent invoquée pour justifier l’attente (« on ne peut pas encore, le cadre n’est pas clair ») tout en continuant d’empiler des pilotes. C’est une posture qui se retourne. L’European Union AI Act (EU AI Act), applicable à partir d’août 2026, ne crée pas l’exigence de gouvernance – il oblige à la nommer. Les 5 % n’ont pas attendu : ils ont compris qu’un modèle déployé sans gouvernance est un incident qui n’a pas encore eu lieu, et que désigner avant la régulation qui en répond coûte moins cher que désigner après.

Les entreprises qui s’en sortent ne font pas mieux techniquement. Elles ont décidé – et elles ont construit l’organisation autour de cette décision.

Ce que ça réclame : « un chef, c’est fait pour cheffer ! »

Weber revient ici, et il revient pour clore – autrement.

On lit souvent Weber comme une succession : le sachant prouve, le politique prend le relais. C’est inexact. Chez Weber, le décideur authentique ne remplace pas l’éthique de conviction par l’éthique de responsabilité : il tient les deux à la fois, sous tension. Il écoute le sachant sans s’effacer derrière lui. Il assume les conséquences sans renier la rigueur technique. Cheffer, c’est ça : porter simultanément deux exigences que rien ne réconcilie, et arbitrer en connaissance de cause.

« Cheffer, c’est porter simultanément deux exigences que rien ne réconcilie, et arbitrer en connaissance de cause. »

L’éthique de responsabilité n’est donc pas qu’une qualité personnelle. C’est aussi une fonction que l’institution doit créer – sans quoi l’individu qui voudrait l’assumer n’en a pas les moyens. “Cheffer”, ce n’est pas valider une démo. C’est désigner quelqu’un qui répond de l’échec en production – et lui donner ce qu’il faut pour répondre. C’est fixer le critère qui autorise le passage en production – et celui qui l’interdit. C’est construire l’organisation autour de cette décision avant que le modèle soit entraîné, pas après que le PoC ait été jugé concluant.

Trois signaux indiquent qu’une organisation a perdu ce moment :

1. Le nombre de PoC actifs dépasse le nombre de déploiements en production d’un facteur supérieur à 5.

2. Il n’existe pas de plateforme IA transverse : chaque cas d’usage reconstruit sa propre stack.

3. La question « qui est responsable si ce modèle se trompe en production ? » n’a pas de réponse claire dans l’organigramme.

Ce ne sont pas des problèmes techniques. Un modèle plus précis, un framework MLOps plus robuste, un prompt mieux rédigé n’y changeront rien. Ces signaux indiquent une carence de gouvernance politique, pas une carence d’ingénierie.

Les organisations qui sortent du pilot purgatory ne le font pas par un grand programme de transformation. Elles ont arrêté de traiter l’IA comme une expérimentation permanente et ont commencé à la traiter comme une infrastructure critique – avec les exigences de décision que ça suppose sur l’architecture, le budget et la responsabilité.

D’ici 24 mois, les chiffres BCG seront actualisés. Les 5 % auront creusé l’écart sur les autres – pas par un progrès technique décisif, mais par accumulation : deux ans de décisions assumées d’un côté, deux ans de pilotes de l’autre. La question pour qui lit ces lignes n’est pas de savoir si l’écart existe. C’est de savoir de quel côté son organisation sera.

P.S. : Merci à Florian C. de m’avoir donné l’idée de cet article au détour d’une conversation.

Pour prolonger

• 88 % des entreprises utilisent l’IA. 94 % n’en tirent pas de valeur – les chiffres derrière l’écart entre adoption et valeur réelle.
• Shadow AI : le contournement vous dit ce que votre DSI ne vous dira pas – quand le PoC reste en silo, le contournement commence.