Conduire un projet IA en entreprise : de la preuve de concept à la production

Ces chiffres convergent avec un constat plus ancien de RAND Corporation : plus de 80 % des projets IA échouent, soit deux fois plus que les projets IT classiques. Autrement dit, la dérive POC-sans-suite est devenue le mode d’échec par défaut de l’IA en entreprise.

Chez Molia, nous avons une conviction qui structure toutes nos missions : un projet IA qui se termine en POC est un projet raté. Pas parce que l’IA ne marche pas, elle marche, et nous la déployons en production tous les jours, mais parce que les entreprises conduisent leurs projets IA comme des expérimentations alors qu’elles devraient les conduire comme des projets industriels. Cet article expose la méthodologie que nous appliquons, en six étapes, pour passer de l’idée à la production.

Pourquoi 80 % des projets IA échouent : ce n’est pas un problème de modèle

Avant de décrire la méthode, il faut démonter un malentendu. Les projets IA n’échouent pas parce que les modèles sont mauvais. Ils échouent en amont et en aval du modèle.

RAND a interviewé 65 data scientists et ingénieurs expérimentés pour identifier les cinq causes racines d’échec : une mauvaise formulation du problème à résoudre, des données absentes ou de mauvaise qualité, un focus sur la technologie plutôt que sur la valeur métier, une infrastructure inadaptée au passage en production, et une mauvaise adéquation entre le problème posé et la technique IA retenue.

L’enquête Informatica CDO Insights 2025 converge : les trois premiers obstacles sont la qualité des données (43 %), la maturité technique (43 %) et la pénurie de compétences (35 %). Aucun des trois n’a à voir avec le modèle lui-même.

Le constat est le même côté français. Selon McKinsey, deux tiers des entreprises qui ont lancé des projets IA restent bloquées en phase pilote. Et malgré un investissement moyen de 1,9 M€ dans l’IA générative, moins de 30 % des dirigeants français se déclarent satisfaits de leur retour sur investissement. L’INSEE mesure que seules 10 % des entreprises françaises utilisent une IA en 2024, 33 % pour celles de 250 salariés et plus, alors que 58 % des dirigeants de PME-ETI considèrent l’IA comme un enjeu de survie.

Ce décalage entre l’ambition affichée et la valeur livrée n’est pas une fatalité technologique. C’est un défaut de méthode. Et la méthode, nous la reproduisons mission après mission.

Les six étapes pour passer un projet IA en production

Étape 1: Cadrer le use case autour du problème métier, pas de la solution technique

La première erreur des équipes IA consiste à partir de la technologie : “on veut faire du RAG”, “on veut un agent”, “on veut entraîner un modèle”. C’est exactement la cause racine n°1 identifiée par RAND.

Le cadrage doit partir d’un problème métier formulable en une phrase, avec un propriétaire identifié (un directeur opérationnel, pas le DSI), un impact quantifié (gain de temps, réduction d’erreurs, augmentation de chiffre d’affaires, coût évité), et une mesure de succès préalable — ce qui suppose souvent d’instrumenter la baseline avant même de concevoir la solution.

Un exemple typique : “réduire de 40 % le temps de traitement d’une facture non conforme” est un cadrage exploitable. “Mettre de l’IA sur la compta fournisseurs” ne l’est pas.

Étape 2: Appliquer un go/no-go sur quatre critères objectifs

Toutes les idées IA ne méritent pas un POC. Nous filtrons chaque use case sur quatre critères, dans l’ordre.

Valeur métier — Est-ce que l’impact business est quantifiable, significatif et prioritaire ? Si la réponse est floue, on arrête là. Un use case qui économise 50 k€ par an n’amortira jamais 200 k€ de mise en production.

Faisabilité data — Les données existent-elles, sont-elles accessibles, sont-elles de qualité suffisante ? Gartner prédit que 60 % des projets IA seront abandonnés d’ici 2026 faute de données AI-ready. Si les données n’existent pas, le projet n’est pas un projet IA — c’est un projet data sur lequel on posera une brique IA dans six mois.

Faisabilité technique et souveraine — La solution technique est-elle mature ? Les contraintes réglementaires et de confidentialité permettent-elles le déploiement envisagé ? C’est à cette étape qu’on cadre le niveau de souveraineté nécessaire — une question traitée en détail dans notre guide sur la souveraineté IA (article pilier de cette série).

Faisabilité d’adoption — Les utilisateurs finaux vont-ils réellement intégrer l’outil dans leur quotidien ? C’est la cause d’échec la plus fréquente après les données : un système qui fonctionne techniquement mais que personne n’utilise.

Un projet qui ne passe pas les quatre critères ne doit pas être lancé. C’est contre-intuitif, mais c’est la condition pour que les projets qu’on lance aient une chance d’aboutir.

Étape 3: Choisir la première use case avec un calcul de portefeuille

La question n’est pas “quel est le meilleur use case”, mais “quel est le bon premier use case”. Ce n’est pas le même calcul.

Un bon premier use case combine trois attributs. D’abord, un ROI tangible à 6-9 mois — assez court pour créer de la conviction en interne, assez riche pour justifier l’investissement. Ensuite, un risque mesuré — données non critiques, impact d’erreur limité, réversibilité possible. Enfin, un effet d’entraînement — un use case qui crée les fondations (data, compétences, infrastructure) pour les suivants.

Les données confirment cette approche portefeuille. Les entreprises qui déploient trois use cases ou plus en production obtiennent 160 % de ROI moyen, contre 40 % pour celles qui n’en ont qu’un. Le premier use case doit préparer le second, pas l’épuiser. Nous recommandons donc de cartographier 5 à 10 use cases candidats et de séquencer, pas de choisir le plus beau isolément.

Étape 4: Industrialiser dès le POC, pas après

C’est le pivot méthodologique le plus important, et celui que la majorité des équipes ratent. Le POC n’est pas un prototype jetable — c’est le premier incrément d’un système de production.

Concrètement, cela veut dire qu’on impose dès le départ des contraintes de production : versioning du code et des données, CI/CD automatisée, infrastructure as code, observabilité intégrée, et architecture pensée pour le passage à l’échelle. Les pratiques MLOps 2025 ne sont pas un luxe qu’on ajoute à la fin : elles structurent le POC dès le jour 1.

L’argument pragmatique : un POC industrialisable coûte 20 à 30 % plus cher qu’un POC jetable. Refaire un POC jetable pour le mettre en production coûte entre 200 et 400 % de plus — et c’est précisément ce qui fait mourir les projets entre POC et prod.

L’approche “build vs buy” joue aussi à cette étape. MIT NANDA observe que les entreprises qui achètent auprès de vendeurs spécialisés ou construisent en partenariat réussissent 67 % du temps, contre environ 33 % pour celles qui construisent tout en interne. Le build interne complet reste pertinent sur des cas très différenciants ; pour tout le reste, l’intégration de briques existantes accélère le passage en production.

Étape 5: Mettre en place un monitoring continu, pas un tableau de bord

Une fois en production, un système IA dérive. Les données d’entrée évoluent, les comportements utilisateurs changent, les coûts explosent silencieusement. Selon Gartner, moins de 40 % des projets IA qui atteignent la production maintiennent leur valeur business au-delà de 12 mois.

Le monitoring efficace couvre quatre dimensions : la qualité des sorties (évaluation continue, pas ponctuelle), la dérive des données (détection statistique automatisée), les coûts (coût par requête, consommation GPU, API externes), et l’usage réel (qui utilise le système, pour quoi, avec quelle satisfaction). Des outils comme Evidently, Langfuse ou Giskard permettent d’instrumenter ces dimensions. Nous traitons ce sujet en détail dans notre article sur l’observabilité IA.

L’absence de monitoring explique pourquoi tant de projets passent en production puis s’éteignent en silence, sans jamais être formellement arrêtés.

Étape 6: Transférer les compétences : l’indépendance est la vraie métrique de succès

Un projet IA réussi qui laisse le client dépendant d’un prestataire n’est pas un projet réussi — c’est une dette technique et stratégique qui mûrit. Le transfert de compétences n’est pas un livrable en fin de mission ; c’est un fil rouge qui court sur toutes les étapes.

Dans nos missions, cela prend trois formes. Un co-développement systématique : les équipes internes travaillent en pair avec nos consultants, pas en réception. Une documentation vivante, maintenue dans les outils du client (Notion, Confluence, Git), pas dans un rapport PDF de fin de mission. Une trajectoire de compétence explicite : qui saura faire quoi dans 6 mois, 12 mois, et avec quel plan de formation.

L’argument économique est simple. BCG mesure que les entreprises qui extraient le plus de valeur de l’IA sont aussi celles qui ont les programmes d’upskilling les plus ambitieux. La compétence interne, pas l’infrastructure, est le vrai facteur discriminant.

Ce que Molia recommande

Les 80 % d’échec ne sont pas une fatalité. Ils sont le symptôme d’une industrie qui traite les projets IA comme des expérimentations et qui s’étonne ensuite qu’ils n’atteignent jamais la production.

Notre conviction, que nous appliquons sur chaque mission : le POC et la production sont le même projet, pas deux projets distincts. La question à se poser au lancement n’est pas “est-ce que ça va marcher”, c’est “comment on l’opère dans 18 mois”. Si vous n’avez pas de réponse crédible à cette question, ne lancez pas le POC.

Cette méthode transverse s’incarne dans nos quatre expertises : automatisation de processus métier, knowledge management IA, traitement documentaire intelligent et data engineering au service de l’IA. Chaque mission Molia applique les six étapes ci-dessus, et chaque mission Molia se termine en production — avec un transfert de compétences qui rend le client autonome.

Concrètement, si vous êtes DG, DSI, CDO ou responsable innovation et que vous vous apprêtez à lancer un projet IA : commencez par cartographier vos 5-10 use cases candidats, appliquez le filtre go/no-go sur les quatre critères, choisissez votre premier use case sur la logique de portefeuille, et imposez dès le POC les contraintes de production. Le reste suivra.

Conclusion

BCG mesure que 5 % des entreprises (“future-built”) captent 1,7× la croissance du chiffre d’affaires et 3,6× le TSR par rapport aux autres. L’écart entre ces 5 % et les 60 % qui ne captent aucune valeur matérielle ne tient ni au budget, ni à la technologie — il tient à la méthode. Le rattrapage reste possible, à condition de cesser de lancer des POC et de commencer à lancer des projets.

Cet article fait partie de la série Souveraineté IA par Molia. Une question sur le passage en production d’un projet IA ? Contactez-nous.