900 K€ à 1,8 M€. C'est le coût moyen d'un projet IA en entreprise. 85% n'atteignent jamais la production (Gartner). 21% seulement génèrent une vraie valeur. Et seules 8% des organisations réussissent à déployer l'IA à l'échelle (McKinsey).
Ces chiffres ne sont pas une fatalité. Ce sont des symptômes. Sur le terrain — en PI Planning, en comité de pilotage, en rétrospective — j'ai appris à reconnaître quatre signaux qui annoncent le crash bien avant qu'il soit officiel.
Si vous en repérez ne serait-ce qu'un seul dans votre organisation, arrêtez tout. Corrigez avant d'investir un euro de plus.
Signal 1 — "On a les données"
La phrase la plus dangereuse d'un kick-off IA. Un sponsor confiant, un slide avec un schéma de base de données, tout le monde hoche la tête. Trois mois plus tard, l'équipe data découvre la réalité.
Les données existent. Mais elles sont réparties dans 14 systèmes différents, avec des formats incompatibles, des doublons partout, des champs vides à 40%, des règles métier non documentées qui font que la même colonne ne signifie pas la même chose selon l'entité.
Cas vécu : un industriel arrête un projet de maintenance prédictive après 4 mois et 300 K€. Motif : les capteurs enregistraient toutes les 5 minutes, le modèle avait besoin de données toutes les 10 secondes. Personne n'avait vérifié avant.
Comment je le détecte : je demande "qui a fait l'audit data ?" en kickoff. Silence ou "on verra ça en sprint 2" → on va dans le mur. Quand l'équipe data n'a pas été consultée pendant le cadrage, le projet est déjà en sursis.
Ce que je recommande : un sprint de découverte de 2 semaines, dédié exclusivement à l'audit des données. Pas de modèle, pas de code, pas de POC. Une seule question : est-ce qu'on a ce qu'il faut, dans l'état qu'il faut, à la fréquence qu'il faut ? Si non, vous venez d'économiser 6 mois.
Signal 2 — "L'IA va tout automatiser"
Quand un Comex annonce "automatisation de bout en bout", le projet est mort-né. Pas parce que c'est techniquement impossible. Parce que c'est rarement le bon point de départ.
Le réflexe naturel :
→ On identifie un processus coûteux
→ On imagine un monde où l'IA le fait à la place des humains
→ On calcule un ROI théorique
→ On lance le projet
C'est séduisant. C'est aussi le chemin le plus rapide vers l'échec.
Double problème. Premier : l'automatisation complète exige une maturité data et processus que très peu d'organisations possèdent. Second : elle déclenche une résistance maximale — les équipes se sentent menacées, les syndicats s'activent, le projet devient politique avant d'être technique.
Bascule conceptuelle : on ne déploie pas l'automatisation, on déploie l'augmentation. Optimiser avant de transformer. Copilote d'abord. Autopilote jamais en kickoff.
Concrètement : au lieu d'automatiser l'analyse des réclamations clients de A à Z, on commence par suggérer une catégorisation que l'agent humain valide ou corrige. L'humain reste dans la boucle. La confiance se construit. Les données d'entraînement s'améliorent grâce au feedback. Six mois plus tard, c'est l'équipe elle-même qui demande à automatiser les cas simples.
Les indices qui ne trompent pas : scope initial qui vise l'automatisation complète sans phase de decision-support. ROI calculé sur le remplacement de postes plutôt que l'augmentation de capacité. Sponsor qui dit "on va faire comme Amazon" sans jamais avoir mis les pieds dans un entrepôt logistique.
Signal 3 — "Les équipes sont prêtes"
Non, elles ne le sont pas. Et ce n'est pas un reproche, c'est une réalité structurelle.
Le schéma se répète dans chaque transformation que j'accompagne. La direction pense que les équipes sont enthousiastes parce qu'elles ont assisté à une démo impressionnante. En réalité, derrière la fascination initiale : peur, confusion, et un vide — personne n'a expliqué ce que ça change concrètement dans leur quotidien.
Les managers sont les premiers touchés. L'IA est un amplificateur : elle révèle et amplifie les forces comme les faiblesses du management en place.
Sans cadre de conduite du changement :
→ Les early adopters avancent seuls, se déconnectent du reste de l'équipe
→ Les sceptiques se retranchent
→ Les managers du milieu, ceux qui devraient porter le changement, ne savent pas quoi faire
→ Le projet se fragmente
C'est pour ça que le framework M3K existe : Mindset, Methods, Metrics, Knowledge. Quatre dimensions à travailler simultanément. Pas une formation ponctuelle — un parcours continu qui adresse la posture, les pratiques, la mesure du progrès et la montée en compétence.
Ce que je cherche : un plan d'adoption. Des indicateurs réels — pas le nombre de licences activées, ça ne veut rien dire. Des rituels d'équipe adaptés. Et surtout : est-ce que les managers ont eux-mêmes utilisé l'outil qu'ils déploient ? Dans 8 cas sur 10, la réponse est non.
Le test ultime : demandez à un manager intermédiaire de vous montrer comment il utilise l'IA dans son quotidien. S'il ne peut pas, l'adoption est une illusion.
Signal 4 — "Le POC a marché"
Le piège le plus sournois. Parce qu'il vient avec des preuves. Des métriques. Des graphiques qui montent. Le Comex est convaincu, le budget est débloqué, on passe en production.
Et là, tout s'effondre.
Un POC fonctionne parce qu'il est protégé. Données nettoyées à la main. Environnement contrôlé. Équipe dédiée. Cas d'usage sélectionnés pour réussir. C'est son rôle : prouver la faisabilité technique. Mais la faisabilité technique n'est que 20% du problème.
Les 80% restants, ceux qui tuent en production :
- Le data drift — les données en production ne ressemblent pas à celles du POC. Elles évoluent, se dégradent, changent de distribution. Le modèle perd en précision sans que personne ne s'en rende compte.
- Les edge cases — le POC traitait les cas standards. La production affronte les exceptions, les données aberrantes, les cas métier que personne n'avait anticipés.
- L'intégration — brancher un modèle sur un SI existant, avec ses API, ses latences, ses contraintes de sécurité, ses processus de validation, c'est un projet en soi.
- Les compétences — l'équipe POC était composée de data scientists seniors. L'équipe de run est composée de profils opérationnels qui n'ont jamais maintenu un modèle en production.
Les signaux d'alarme : un POC validé par le Comex sans plan de mise en production. Pas de MLOps. Pas de monitoring. Pas de stratégie de retraining. Pas de runbook pour les dégradations.
On a prouvé que ça marchait un mardi après-midi avec des données propres, et on en déduit que ça marchera tous les jours avec des données réelles. C'est tester un parapluie par beau temps.
Comme je l'ai écrit sur la FOMO IA, la pression pour aller vite pousse à confondre preuve de concept et preuve de valeur. Ce sont deux choses radicalement différentes.
Dérisquer en trois phases (et leurs checkpoints)
Ces quatre signaux ne sont pas des fatalités. Ce sont des points de contrôle. L'approche IAgile structure le dérisquage en trois phases — chacune avec un checkpoint Go/No-Go avant de passer à la suivante.
Phase Discovery (semaines 1-4)
- Audit qualité des données : complétude, fraîcheur, cohérence, accessibilité.
- Cartographie des parties prenantes et de leur posture face au changement.
- Scope minimal défini : aide à la décision, pas automatisation.
- Go/No-Go basé sur des faits, pas sur l'enthousiasme du sponsor.
Phase Build (semaines 5-16)
- Itérations courtes avec feedback utilisateur réel (pas juste les data scientists).
- Plan d'adoption activé dès le sprint 1, structuré par M3K.
- Monitoring de l'adoption réelle : qui utilise quoi, combien de fois, avec quel résultat.
- Intégration progressive dans le SI existant, pas un big bang.
Phase Scale (semaines 17+)
- MLOps en place : monitoring, alerting, retraining automatisé.
- Runbook de dégradation : que faire quand le modèle dérive.
- Transfert de compétences vers les équipes de run.
- Mesure de la valeur métier réelle, pas juste de la précision du modèle.
Les checkpoints qui décident vraiment
Pas une réunion de validation où tout le monde dit oui. Un point de décision avec des critères objectifs, et le pouvoir de tuer le projet.
Discovery → Build : les données sont-elles suffisantes ? Le scope est-il réaliste ? Les parties prenantes sont-elles alignées ? Le plan d'adoption existe-t-il ?
Build → Scale : l'adoption réelle dépasse-t-elle 60% ? Le modèle performe-t-il sur des données qu'il n'a jamais vues ? L'infra de production est-elle prête ? L'équipe de run est-elle formée ?
Si un seul critère est rouge, on ne passe pas. On corrige d'abord. C'est contre-intuitif dans une culture du "go fast", mais c'est exactement ce qui sépare les 8% qui réussissent des 85% qui échouent.
Ces signaux d'alerte, je ne les ai pas trouvés dans un livre. Je les ai appris en PI Planning, en voyant des trains SAFe entiers se mobiliser sur des projets IA mal cadrés. En comité de pilotage, en regardant des sponsors défendre des POC qu'ils confondaient avec des produits. En rétrospective, en écoutant des équipes raconter qu'elles avaient su dès le sprint 1 que ça n'allait pas marcher — mais personne ne les avait écoutées.
Le coût d'un projet IA qui échoue n'est pas que financier. C'est la confiance des équipes dans la prochaine initiative. La crédibilité du management. Le temps perdu qui ne reviendra pas.
Avant d'investir 900 K€ dans votre prochain projet IA, investissez 4 semaines dans un vrai diagnostic. Vous saurez exactement où vous en êtes. Et vous déciderez en connaissance de cause.
Pour approfondir : l'approche IAgile et le framework M3K.
Lequel de ces 4 signaux est en train de clignoter sur votre prochain projet IA ?