Il y a un script que beaucoup d'organisations connaissent désormais. L'équipe monte un POC en quelques semaines : le bon modèle, les bonnes données de démo, le bon cas d'usage. La présentation se passe bien. Le système répond de façon impressionnante, les managers hochent la tête, quelqu'un dit "exactement ce qu'on cherchait". Un budget de développement est voté pour passer à l'étape suivante.
Six mois après, le projet n'est pas en production. Parfois il est officiellement "en cours d'industrialisation", ce qui signifie en pratique que personne n'a poussé de code depuis deux mois. Parfois il est "en attente de clarification des exigences", ce qui signifie que le dernier comité de pilotage a soulevé des questions sans les trancher. Parfois il existe dans un état intermédiaire : techniquement fonctionnel sur un serveur quelque part, utilisé par trois personnes, sans plan clair pour une mise en production réelle ni pour son arrêt.
Ce n'est pas un accident. Et ce n'est presque jamais un problème technique. Le modèle n'est pas en cause. Le framework non plus. Les trois vrais blocages sont organisationnels : une gouvernance qui n'a pas de processus décisionnel opérationnel, une évaluation qui n'existe pas au moment où elle compte, et une propriété du projet nominalement partagée entre plusieurs acteurs, ce qui revient à dire qu'elle n'appartient à personne. Ces trois blocages coexistent dans la grande majorité des projets IA qui stagnent. Et ils sont parfaitement évitables, si on les anticipe avant le premier sprint de code.
Des chiffres qui devraient changer les priorités
La situation n'est pas anecdotique. Les données disponibles sur les taux de passage en production des projets IA convergent vers le même constat, quelle que soit la source.
Gartner a publié en juillet 2024 une prévision selon laquelle au moins 30% des projets d'IA générative seraient abandonnés après la phase de POC d'ici fin 2025. Les raisons citées : mauvaise qualité des données, contrôles de risque insuffisants, coûts qui dérapent, et valeur métier jamais définie clairement. Le même rapport anticipe que plus de 40% des projets d'IA agentique seront annulés d'ici 2027 pour les mêmes raisons. Aucune de ces raisons n'est technique au sens strict.
Le rapport State of AI de McKinsey (novembre 2025) complète le tableau par le haut : 88% des organisations utilisent l'IA dans au moins une fonction. Mais seulement 5,5% sont classées "high performers", c'est-à-dire des organisations qui tirent un impact EBIT substantiel et mesurable de leurs déploiements IA. Les deux tiers restant sont bloqués entre le pilote et l'échelle, sans stratégie claire pour franchir le pas.
Ces chiffres révèlent une réalité que les organisations ont du mal à formuler : la difficulté n'est pas de faire un POC convaincant. La difficulté est de créer les conditions organisationnelles qui permettent de passer de la démo à la valeur réelle. Ces conditions ne se créent pas seules. Elles se construisent délibérément, et de préférence avant de commencer à coder.
Blocage 1 : la gouvernance qui n'a pas de visage
La gouvernance du projet existe, en général. Il y a un comité de pilotage, des réunions mensuelles, une feuille de route. Ce qui manque, c'est un processus décisionnel opérationnel : personne ne sait précisément qui peut dire "ce POC est prêt à passer en prod", ni selon quels critères, ni dans quel délai.
Ce vide se manifeste de façon très concrète. Le comité de pilotage valide les budgets et les grandes orientations, pas les décisions techniques de passage en production. L'équipe IT attend une validation fonctionnelle du métier, qui ne vient jamais sous une forme utilisable. Le métier attend que l'IT certifie que le système est "prêt à l'emploi", sans avoir défini ce que cela signifie. Chaque réunion repose la même question sans y répondre, parce que la gouvernance est organisée pour orienter, pas pour décider.
Les conséquences sont prévisibles. Les cycles de révision s'allongent au fil des comités. Les exigences changent entre deux réunions, pas parce que le besoin évolue vraiment, mais parce qu'aucune version des exigences n'a jamais été formellement validée. Le projet entre dans une zone grise où il n'est ni approuvé pour la production ni officiellement arrêté.
Selon les données collectées sur la gouvernance IA en entreprise, 44% des organisations déclarent que leur processus de gouvernance IA est trop lent, et 24% le trouvent trop lourd pour être applicable. Le problème structurel est bien identifié : les organisations développent l'IA à la vitesse du logiciel, mais gouvernent à la vitesse des comités. L'écart entre les deux crée exactement ce blocage.
Ce que "gouvernance opérationnelle" signifie en pratique
Une gouvernance opérationnelle pour un projet IA a trois composantes. Premièrement, des critères de passage en prod définis avant le démarrage du POC : performances minimales sur les cas d'usage prioritaires, seuils d'acceptabilité des erreurs, périmètre fonctionnel exact de la version 1. Deuxièmement, un décideur unique nommé pour chaque étape de validation, avec un délai de décision non renégociable. Troisièmement, une procédure d'escalade explicite quand la décision n'est pas prise dans le délai.
Ce n'est pas de la bureaucratie supplémentaire. C'est ce qui permet à un projet de progresser.
Blocage 2 : l'évaluation absente au moment où elle compte
Le deuxième blocage est plus technique dans sa forme, mais organisationnel dans sa cause.
Un POC "marche" quand la démo convainc les personnes dans la salle. Ce n'est pas la même chose qu'un système fiable sur l'ensemble des cas d'usage réels de l'organisation, y compris les cas limites, les entrées mal formées et les situations rares mais critiques. La démo montre les meilleurs cas. La production expose tous les cas. Et dans la quasi-totalité des POC qu'on voit, il n'existe aucun jeu d'évaluation formalisé au moment où la décision de passage en prod doit être prise.
Personne n'a constitué un ensemble de 100 à 300 questions représentatives des requêtes réelles, avec les réponses attendues, les seuils d'acceptabilité et les cas de refus légitimes. On ne peut donc pas mesurer si le POC "fonctionne" dans un sens précis et partagé entre le métier et l'IT. On sait qu'il a bien fonctionné en démo.
Ce point est documenté à grande échelle. Le rapport State of Agent Engineering de LangChain (décembre 2025), mené auprès de 1 340 équipes qui déploient des agents en production, révèle que 89% ont mis en place de l'observabilité sur leurs systèmes, mais seulement 52% font tourner des évaluations structurées sur des jeux de test documentés. L'écart entre "surveiller ce qui se passe" et "mesurer si les sorties sont bonnes" est de 37 points de pourcentage. Dans les projets encore en POC, ce chiffre est probablement plus bas.
Pourquoi l'absence d'éval bloque le passage en prod
Quand un système passe en production sans évaluation préalable, les premiers retours utilisateurs arrivent rapidement et sont mitigés, et personne ne sait comment les interpréter. Est-ce une régression par rapport au POC ? Le POC n'a-t-il jamais été aussi bon qu'on le pensait ? Les utilisateurs utilisent-ils le système de façon inattendue ? Sans baseline mesurée, toute discussion sur la qualité est subjective. Les équipes IT et métier débattent à partir d'impressions, les cycles de validation s'allongent, et les doutes sur la valeur du projet s'installent durablement.
La décision concrète à prendre : construire le jeu d'évaluation en parallèle du POC, pas après. Ce golden dataset n'est pas un livrable optionnel de fin de projet. C'est le contrat entre l'équipe de développement et le métier sur ce que "fonctionner" signifie. Il doit exister avant que le comité de pilotage soit convoqué pour décider du passage en prod.
Blocage 3 : l'ownership qui appartient à tout le monde
Le troisième blocage est le plus répandu et le moins nommé.
Le projet a un chef de projet technique. Il a une direction métier sponsor. Il a, parfois, un CAIO ou un CDO qui suit le portefeuille IA de l'organisation. Et pourtant, six mois après le déploiement technique, le système n'est pas réellement utilisé. La raison : personne n'a la responsabilité opérationnelle quotidienne du système après sa livraison.
Ce phénomène est bien documenté sous le nom de "AI without a home" : un projet techniquement livré, qui n'a pas de propriétaire au sein du business pour piloter l'adoption, résoudre les problèmes de terrain, ajuster les fonctionnalités quand les besoins évoluent, et défendre le budget de maintenance lors des revues budgétaires. Sans owner opérationnel, le système se dégrade progressivement. Les utilisateurs remontent des problèmes que personne n'est en charge de résoudre. La confiance baisse. Le taux d'utilisation décline, et finit par justifier la décision de couper le budget.
La confusion des rôles comme source directe du problème
L'origine de ce blocage est une confusion des responsabilités qui s'est installée par défaut. L'équipe IT considère son rôle terminé au déploiement. Le management pense que l'adoption va se faire naturellement si le système est de qualité. Le sponsor business considère que la responsabilité est partagée entre IT et un "responsable métier" qui n'a jamais été nommé nominalement.
Cette confusion remonte souvent à la direction, quand plusieurs fonctions revendiquent simultanément la légitimité sur l'IA de l'organisation : le DSI pour l'infrastructure, le CDO pour les données, le CAIO pour la stratégie, la direction métier pour les cas d'usage. Quand six responsables revendiquent la propriété d'un projet, personne ne prend les décisions difficiles d'adoption.
La solution : nommer un owner business avant le démarrage du POC. Non pas un "sponsor" de comité, mais une personne avec un budget de fonctionnement alloué, un mandat explicite sur les évolutions fonctionnelles, et un indicateur d'adoption dans ses objectifs. Ce rôle doit être occupé par quelqu'un du métier, pas de l'IT : c'est le métier qui sait si le système résout le problème qu'il était censé résoudre.
Quand les trois blocages se combinent
Ces trois problèmes ne se présentent presque jamais isolément. Ils se renforcent mutuellement, et c'est là que la situation devient difficile à débloquer.
Une gouvernance sans processus décisionnel produit une évaluation tardive, parce que personne n'a défini les critères de passage en prod qui auraient forcé à construire le jeu de test. L'absence d'évaluation rend la décision de passage en prod impossible à objectiver, ce qui allonge les cycles de comité et décourage l'owner potentiel de s'engager. L'absence d'owner signifie que personne ne pousse pour que les critères d'évaluation soient définis, ni que la gouvernance prenne une décision. Le cycle se répète.
Ce cercle vicieux a une caractéristique particulièrement pernicieuse : à chaque tour, le coût politique d'arrêter le projet augmente. L'organisation a investi des mois de développement, des budgets GPU, du temps de management. Admettre l'échec revient à déclarer que cet investissement n'a pas produit de valeur. Alors le projet continue, en consommant des ressources d'entretien minimal sans jamais créer d'impact mesurable. C'est ce que Gartner désigne sous le nom de projets "zombie" : des initiatives IA qui survivent par inertie mais ne seront jamais véritablement adoptées. Dans un contexte où les budgets IA sont sous pression croissante, ces projets finissent par être coupés lors du premier exercice sérieux de revue de portefeuille, souvent sans analyse des causes réelles.
Ce qu'on met en place concrètement pour débloquer
Quand un client nous sollicite sur un POC qui stagne, on ne commence jamais par regarder le modèle. On commence par trois questions, dans cet ordre.
Qui peut dire "c'est prêt" et selon quels critères ? Si la réponse désigne un comité sans préciser le décideur individuel ni les critères de validation, la gouvernance n'est pas opérationnelle. On la formalise avant tout travail technique supplémentaire.
Existe-t-il un jeu d'évaluation documenté ? Des cas de test représentatifs, des réponses attendues, des seuils de qualité acceptés formellement par le métier. Si ce jeu n'existe pas, on le construit avec les équipes métier en priorité absolue, avant de planifier quoi que ce soit sur le passage en prod.
Qui est l'owner opérationnel une fois le système déployé ? Un responsable métier nommé, avec un budget de fonctionnement et un mandat explicite sur les décisions fonctionnelles. Si ce rôle n'est pas encore désigné, le projet n'est pas prêt à passer en production, quelle que soit la qualité du code livré.
Sur les projets que l'on reprend en 2025-2026, cette vérification en trois points identifie le blocage principal dans plus de 80% des cas. Et dans la quasi-totalité des situations, la résolution ne passe pas par du travail technique supplémentaire. Elle passe par des décisions organisationnelles qui n'ont simplement pas encore été prises.
Ce qui est difficile n'est pas de poser ces questions. C'est de convaincre les organisations de les poser avant le premier sprint de développement, pas six mois après. Un POC qui démarre sans réponse à ces trois questions n'est pas un POC : c'est une démo avec un budget.
Vous voulez qu'on regarde votre cas ensemble ? Réservez un créneau, on bloque 30 minutes pour identifier ce qui bloque votre projet IA entre le POC et la production, et définir les trois décisions organisationnelles qui permettront de débloquer.