Transformations digitales : le coût qu'on ne mesure jamais et pourquoi l'IA risque de l'aggraver

Chaque transformation ratée brûle la crédibilité interne. L'IA arrive dans des organisations déjà fatiguées. Sans diagnostic réel avant de lancer, la promesse s'use plus vite que le modèle ne produit.

Il y a quelques années, un grand groupe européen lançait une transformation SAFe ambitieuse : cartographie des flux de valeur, identification des ARTs, formation des équipes, PI Plannings. Six mois après, les trains roulaient. Dix-huit mois plus tard, lors d'un PI Planning, 40 % des features étaient bloquées par des dépendances sur trois équipes transverses extérieures au train. SAFe prévoit des mécanismes pour ça : Shared Services, élargissement du périmètre de l'ART. Aucun n'a été activé : personne dans la salle n'avait le mandat de rattacher au train des équipes relevant d'autres directions.

Tout le monde le savait. Les équipes, les managers de proximité, les architectes. Le programme s'est poursuivi.

Ce cas se reproduit depuis vingt ans. ERP dans les années 2000, cloud dans les années 2010, agile à l'échelle à partir de 2015. Chaque vague produit des résultats en deçà des promesses. Le diagnostic habituel invoque le manque de sponsorship, la résistance au changement, le défaut d'implémentation. Des lectures commodes qui suggèrent que le problème aurait pu être évité avec plus de rigueur. Le bilan réel de ces vagues pointe vers un coût d'une autre nature, rarement mesuré car absent des business cases : le coût en crédibilité interne.

La dette de crédibilité

Les collaborateurs qui ont traversé deux ou trois cycles de transformation ont appris à attendre que ça passe. Ils adoptent le vocabulaire du moment, participent aux cérémonies, remplissent les artefacts, et continuent de fonctionner comme avant. Cette conformité de façade est une adaptation rationnelle : l'environnement a démontré, sur la durée, que les transformations annoncées ne tenaient pas leurs promesses.

Un dirigeant qui lance un nouveau programme dans ce contexte ne part pas de zéro. Il part d'en dessous de zéro. Il doit rembourser la dette de crédibilité accumulée par les programmes précédents avant de construire quoi que ce soit. Ce coût n'apparaît dans aucun business case. Il est pourtant l'un des facteurs les plus prédictifs de ce qui va se passer ensuite, et le plus systématiquement ignoré.

L'IA compresse le cycle de déception

L'IA générative entre dans ce terrain déjà fatigué avec un facteur aggravant. On parle ici des programmes IA formels, ceux qui passent en COMEX avec un budget et une promesse de résultats, pas de l'adoption diffuse via ChatGPT ou des POC en shadow IT.

Un ERP se déployait sur plusieurs années. Une migration cloud sur dix-huit à trente-six mois. L'IA compresse ces délais. Un COMEX qui a vu une démo attend des résultats en semaines. La déception arrive plus vite, devant un public plus large : l'IA touche la relation client, la production documentaire, l'aide à la décision, des sujets que les directions métier mesurent directement.

Déployer un LLM suppose une donnée accessible, gouvernée, de qualité suffisante. Ce prérequis est rarement réuni. Mais le problème principal est ailleurs : quand un programme IA demande aux équipes de structurer des données, de valider des outputs, de revoir leurs processus, il s'adresse à des collaborateurs qui ont déjà vu passer les programmes agiles, les migrations cloud, les réorganisations produit. La puissance du modèle ne compense pas la fatigue accumulée.

Pourquoi le diagnostic n'a pas lieu

Pourquoi les organisations n'évaluent-elles pas leur état réel avant de lancer ? La réponse tient à la conception du processus de décision lui-même.

La salle où se décide l'adoption d'un programme de transformation réunit typiquement quatre acteurs dont les incitations convergent vers le même résultat. L'éditeur ou l'intégrateur, dont le modèle économique repose sur l'adoption. Le champion interne, qui a besoin d'un programme visible pour obtenir un budget et une légitimité. Le COMEX, qui achète une promesse d'outcomes et n'a ni les moyens ni l'intérêt de s'engager dans un audit de dette technique. La DSI, qui connaît l'état réel du SI mais sait qu'une opposition frontale la positionne comme un frein.

Chaque acteur y trouve son compte individuellement : un contrat signé, un programme budgété, un narratif présentable en conseil, une DSI qui n'est pas perçue comme un obstacle. Le résultat collectif, un lancement sans diagnostic, n'est la décision de personne. Personne dans la salle n'a le mandat de dire non.

Deux dimensions à croiser et un cadre pour le faire

Dans un précédent article publié ici, j'explorais la façon dont les organisations optimisent localement chaque domaine sans diagnostiquer la contrainte qui limite le système dans son ensemble. Le problème des prérequis non vérifiés procède de la même logique : on évalue chaque composant séparément sans croiser les deux dimensions qui déterminent ce qu'un programme peut réellement produire.

La première est technique : état du SI, niveau de couplage applicatif, qualité et gouvernance des données, capacité de découplage réaliste à trois-cinq ans.

La seconde est de gouvernance : niveau de délégation effectif sur les décisions de priorité, capacité à arbitrer entre domaines quand les flux de valeur se contredisent, tolérance réelle au conflit de priorisation, niveau de crédibilité résiduelle des programmes de transformation auprès des équipes (rarement mesuré). SAFe aborde cette dimension à travers plusieurs mécanismes : Lean-Agile Leadership, Lean Portfolio Management, Participatory Budgeting. Le modèle Team Topologies suppose une plateforme consommable en self-service qui ne peut exister sans des arbitrages d'investissement clairs. L'IA exige une gouvernance de la donnée qui touche aux prérogatives des directions métier. Chaque approche documente l'importance de cette dimension. Aucune, en pratique, n'en fait un critère de go/no-go.

Un programme peut progresser avec un SI partiellement couplé si la gouvernance permet de traiter les dépendances en temps réel. Un SI bien architecturé ne produit rien si les décisions de priorité restent centralisées par silo. Les deux dimensions interagissent. Les évaluer séparément revient à ne pas les évaluer.

Ce qui est actionnable

Les orientations qui suivent s'adressent aux organisations qui ont déjà traversé un ou plusieurs cycles. Celles où la dette de crédibilité existe et où au moins un décideur en a mesuré le coût.

Changer le livrable du diagnostic : le Value Stream Mapping identifie déjà les dépendances, les handoffs, les goulots. Le problème tient à l'usage qui en est fait : dans le processus SAFe, ces constats servent d'inputs au design des ARTs, pas de carte des contraintes à traiter avant de découper. Utiliser le VSM comme livrable de diagnostic plutôt que comme étape vers le découpage changerait la nature du programme. La même logique s'applique à l'IA : état des lieux croisé de la qualité des données et de la gouvernance, avant le catalogue de cas d'usage.

Condition minimale : un commanditaire prêt à recevoir un livrable moins séduisant que celui qu'il avait prévu de présenter en comité.

Rendre les fondations visibles budgétairement : dans presque tous les programmes observés, les prérequis sont censés se construire dans la foulée. Ils ne se construisent jamais, systématiquement arbitrés au profit du delivery. Sans ligne distincte, sans ownership claire, sans roadmap indépendante, les fondations ne survivent pas à la première revue de priorisation. Ce qui n'apparaît pas dans le budget disparaît des arbitrages.

Condition minimale : un sponsor qui accepte de sanctuariser une ligne sans livrable métier immédiat.

Introduire un acteur dont le mandat ne dépend pas du lancement : si les quatre acteurs convergent structurellement vers "on lance", la seule façon de produire un diagnostic fiable est de mandater quelqu'un dont l'intérêt n'est pas aligné avec l'adoption. Un évaluateur avant la décision de go, avec un livrable simple : voici où vous en êtes sur les deux dimensions, voici ce que ce positionnement permet d'attendre, voici ce qu'il ne permet pas de promettre.

Ce qui se joue maintenant

La prochaine vague IA va prod…uire ses résultats dans des organisations qui portent encore les traces des vagues précédentes. Le modèle sera puissant. Les cas d'usage seront réels. Et les équipes à qui l'on demandera de s'engager auront déjà appris, programme après programme, que les promesses de transformation ont une durée de vie limitée.

La question qui déterminera la suite n'est pas technique. Elle tient en une phrase : cette organisation a-t-elle encore le crédit nécessaire pour que les gens y croient une fois de plus ?