Les huit étapes de Kotter, et les trois qu'on saute toujours sur un projet IA

Avant d'entrer dans le modèle, une mise au point s'impose sur le chiffre qui accompagne toujours son évocation.

Le chiffre que tout le monde cite et que personne n'a vérifié

« 70 % des transformations échouent, comme l'a montré Kotter. » Cette phrase ouvre un nombre considérable de présentations sur la conduite du changement. Elle est fausse sur la source, et probablement sur le fond.

Dans son article de 1995 pour la Harvard Business Review, intitulé « Leading Change: Why Transformation Efforts Fail », Kotter s'appuie sur l'observation d'une centaine d'entreprises sur dix ans. Il y décrit des degrés de réussite variables et reste prudent sur les proportions. Le chiffre de 70 % n'y figure pas.

Son origine réelle est ailleurs. Michael Hammer et James Champy avancent en 1993 que 50 à 70 % des projets de reengineering « n'obtiennent pas de résultats spectaculaires », ce qui ne veut pas dire qu'ils échouent. Deux ans plus tard, Hammer désavoue lui-même l'usage qui en est fait, en écrivant que son observation a été déformée en affirmation normative et qu'il n'existe pas de taux d'échec intrinsèque au reengineering. Kotter, lui, n'emploie cette formulation qu'en 2008, dans un autre ouvrage.

La revue de la littérature académique sur ce point aboutit à un constat simple : aucune base empirique solide ne soutient ce taux. Je le signale parce qu'un modèle utile mérite mieux qu'une statistique inventée en guise d'introduction, et parce que la même paresse se retrouve dans les chiffres qui circulent aujourd'hui sur l'IA.

Les huit étapes, rapidement

Le modèle publié en 1995, développé dans l'ouvrage « Leading Change » l'année suivante, se déroule ainsi : créer un sentiment d'urgence, constituer une coalition dirigeante, développer une vision et une stratégie, communiquer cette vision, lever les obstacles qui empêchent d'agir, générer des victoires à court terme, consolider les acquis pour produire davantage de changement, et ancrer les nouvelles pratiques dans la culture.

L'avertissement central de Kotter porte moins sur le contenu des étapes que sur leur enchaînement : sauter une étape crée une illusion de vitesse et ne produit jamais un résultat satisfaisant. Sur les projets IA que j'observe, trois étapes sautent presque systématiquement.

Première étape sautée : une urgence fabriquée plutôt que constatée

L'urgence au sens de Kotter naît d'un constat partagé, quelque chose que les équipes voient elles-mêmes et qui rend l'inaction inconfortable. Sur les projets IA, l'urgence est généralement importée de l'extérieur : un concurrent qui communique, un article lu par un dirigeant, une peur de retard.

La différence se mesure facilement. Une urgence réelle se formule par une phrase que les équipes reprennent spontanément. Une urgence fabriquée ne survit pas à la réunion où elle a été annoncée. Dans le second cas, ce qui est produit n'est pas de l'urgence mais de l'anxiété, et l'anxiété ne fait pas adopter un outil, elle fait attendre que ça passe.

Deuxième étape sautée : une coalition réduite à un sponsor unique

Kotter insiste sur une coalition, au pluriel, réunissant assez d'autorité et de crédibilité opérationnelle pour porter le sujet (j'ai détaillé le rôle des relais et des réfractaires dans l'adoption). Sur un projet IA, le montage habituel est un sponsor unique côté DSI, parfois accompagné d'un chef de projet.

Le problème n'est pas le niveau hiérarchique, il est la composition. Une coalition sans représentant métier reconnu par ses pairs ne peut pas répondre à la seule question qui compte pour les équipes : est-ce que ça change mon travail en bien. La DSI n'a pas la légitimité pour répondre à cette question, et ce n'est pas un défaut de sa part, c'est un fait d'organisation.

Sixième étape sautée : la victoire rapide mise en scène

C'est l'étape la plus trahie. Une victoire à court terme, chez Kotter, est un résultat sans ambiguïté, visible, et attribuable au changement engagé. Sur les projets IA, elle est presque toujours remplacée par une démonstration, alors que la plus crédible s'obtient souvent en amont, en choisissant de prototyper avec les futurs utilisateurs.

La démonstration impressionne et ne prouve rien, parce qu'elle a été préparée et parce que personne ne sait ce qu'elle a coûté à produire. Une vraie victoire rapide sur un projet IA ressemble à autre chose : un indicateur qui bouge sur une tâche identifiée, mesuré avant et après, sur un périmètre restreint, avec un ordre de grandeur que l'équipe reconnaît comme sien.

Cette confusion entre démonstration et résultat est exactement le mécanisme que je décris à propos des comités de pilotage qui ne servent à rien : produire un livrable de réunion n'est pas produire un effet.

Kotter ou ADKAR, et pour quoi faire

Les deux modèles ne traitent pas le même objet et se complètent plutôt qu'ils ne s'opposent. Kotter décrit la conduite d'un changement à l'échelle d'une organisation, du côté de ceux qui le pilotent. ADKAR décrit la transition d'un individu, et c'est lui que j'utilise pour diagnostiquer où bloque l'adoption d'un outil IA.

En pratique, je me sers de Kotter pour cadrer la séquence au démarrage et d'ADKAR pour comprendre pourquoi l'usage ne décolle pas trois mois plus tard. Utiliser l'un à la place de l'autre donne soit un plan de communication sans effet individuel, soit un diagnostic individuel sans mandat pour agir.

Rien de tout cela n'est propre à l'IA, et c'est précisément le point. La cause dominante d'échec reste un cadrage insuffisant en amont plutôt qu'une limite technique, ce que je traite comme un sujet de delivery management et de conduite du changement avant d'être un sujet d'outillage.

Sources : John P. Kotter, « Leading Change: Why Transformation Efforts Fail », Harvard Business Review, mai-juin 1995 ; Michael Hammer et James Champy, « Reengineering the Corporation », 1993 ; Michael Hammer, « The Reengineering Revolution », 1995 ; John P. Kotter, « A Sense of Urgency », 2008.