ADKAR est-il adapté à un déploiement d'outil IA, ou est-ce un modèle trop ancien ?

Le modèle date de 1996 et il n'a pas été conçu pour l'IA, mais il porte sur la transition individuelle face à un changement, pas sur la technologie elle-même. C'est justement ce qui le rend applicable : sur un déploiement d'IA, ce qui bloque relève de l'envie, du droit d'usage et de l'ancrage, pas du modèle de langage utilisé.

Par quelle étape commencer si le déploiement est déjà lancé et que l'usage retombe ?

Par Desire, systématiquement, même si l'instinct pousse à refaire une session de formation. Reprendre la formation d'une équipe qui n'a pas envie produit un deuxième pic d'usage suivi de la même retombée, à un coût doublé.

Faut-il un budget de conduite du changement séparé du budget outil ?

Oui, et le dimensionner avant de signer les licences plutôt qu'après. Un budget d'adoption arbitré en fin de projet finit toujours en sessions de formation, c'est-à-dire sur la seule étape qui se commande facilement, pas sur celles qui bloquent réellement.

ADKAR et IA : pourquoi la formation ne fait pas l'adoption

Une équipe équipée de licences IA en janvier, formée en février, et dont l'usage réel est retombé à trois personnes en avril. C'est le scénario que je rencontre le plus souvent. La conclusion tirée en interne est presque toujours la même : l'outil n'était pas mûr. C'est rarement le bon diagnostic.

Le symptôme : des licences payées, un usage qui s'effondre

Le nombre de sièges ne bouge pas, il est engagé pour l'année. L'usage, lui, suit une courbe très reconnaissable : un pic à l'ouverture des accès, un plateau pendant les sessions de formation, puis une décroissance qui se stabilise autour d'un petit noyau.

Ce noyau, regardez-le de près. Ce sont presque toujours les mêmes profils, ceux qui utilisaient déjà l'outil à titre personnel avant le déploiement officiel. Autrement dit, ils auraient adopté sans aucun accompagnement. Le budget de déploiement a produit l'adoption qui serait arrivée toute seule, et rien d'autre.

Ce que le modèle ADKAR permet de voir

ADKAR est un modèle de conduite du changement formalisé par Jeff Hiatt en 1996, diffusé dans un livre blanc en 1999 puis dans un ouvrage en 2006, à partir de travaux menés sur plus d'un millier d'organisations. Il est aujourd'hui porté par le cabinet Prosci.

Son intérêt n'est pas théorique, il tient à une seule propriété : les cinq étapes sont séquentielles. Awareness (la conscience du besoin), Desire (l'envie d'y participer), Knowledge (le savoir-faire), Ability (la capacité réelle à faire), Reinforcement (ce qui ancre l'usage dans la durée). Une étape bloquée rend inutile tout ce qu'on investit dans les suivantes.

C'est précisément ce qui se joue sur un déploiement d'IA, et c'est pour ça que le modèle est utile ici plutôt que décoratif.

Les cinq étapes appliquées à un déploiement d'IA

Awareness : comprendre pourquoi, pas apprendre que

Annoncer le déploiement dans une réunion générale crée de l'information, pas de la conscience. La différence se mesure à une question : un collaborateur sait-il expliquer quel problème concret de son quotidien cet outil est censé traiter ? S'il répond par la stratégie de l'entreprise, l'étape n'est pas franchie.

Desire : l'étape que presque personne ne traite

C'est le trou noir des déploiements d'IA. Personne ne demande aux équipes si elles ont envie de cet outil, parce que la réponse fait peur. Or la question de fond est rarement l'ergonomie, elle est plus brutale : est-ce que cet outil rend mon travail plus intéressant, ou est-ce qu'il prépare ma disparition ?

Tant que cette question reste sans réponse explicite, le collaborateur teste l'outil une fois, poliment, puis retourne à ses habitudes. Aucune formation ne compense ça.

Knowledge : là où part l'essentiel du budget

Sessions de prise en main, bibliothèques de prompts, webinaires internes. C'est la partie visible, mesurable, facile à commander, et c'est là que va presque tout l'investissement. Le problème n'est pas qu'elle soit inutile, c'est qu'elle arrive en troisième position et qu'on la traite comme si elle était la première.

Former quelqu'un qui n'a pas envie revient à remplir un seau percé.

Ability : savoir faire ne veut pas dire pouvoir faire

Un collaborateur peut avoir parfaitement compris la formation et rester incapable d'appliquer quoi que ce soit. Les raisons sont concrètes : l'outil n'est pas branché sur ses données réelles, il n'a pas le droit d'y déposer les documents sur lesquels il travaille, sa charge ne laisse aucune marge pour expérimenter, ou il attend une validation que personne ne sait donner.

C'est l'étape la plus souvent confondue avec la précédente, et elle explique une grande partie des usages fantômes. Quand une capacité existe sans cadre autorisé pour l'exercer, elle ne disparaît pas, elle se déplace : c'est le mécanisme du shadow AI que j'ai détaillé ailleurs.

Reinforcement : ce qui manque quand l'usage retombe

Sans rien pour ancrer l'usage, la courbe redescend à son niveau naturel au bout de quelques semaines. L'ancrage n'a pas besoin d'être spectaculaire : rendre visible un gain obtenu par un collègue identifiable, intégrer l'outil dans un rituel existant, ou simplement ne pas maintenir l'ancien processus en parallèle.

Le diagnostic, une question par étape

C'est la partie que j'utilise réellement en atelier. Cinq questions, posées à des collaborateurs et pas à leur direction, et la première réponse floue indique l'étape bloquée.

Awareness : quel problème de ton quotidien cet outil est-il censé régler ? Desire : qu'est-ce que tu y gagnes personnellement ? Knowledge : saurais-tu me montrer comment tu t'en sers sur un cas réel, maintenant ? Ability : qu'est-ce qui t'empêche de l'utiliser sur ton vrai dossier aujourd'hui ? Reinforcement : quand as-tu vu quelqu'un d'autre de ton équipe l'utiliser pour de bon ?

La valeur de cette grille tient à son ordre. Inutile de traiter une réponse floue sur Knowledge si la réponse sur Desire l'était déjà : le blocage se traite toujours à l'étape la plus amont.

Ce que je regarde en priorité sur un déploiement IA

Je commence par les deux questions les moins confortables, celles de Desire et d'Ability, avant de regarder le plan de formation. Dans la quasi-totalité des situations que j'ai vues, le budget formation était correct et le blocage se situait ailleurs.

Ce réflexe rejoint directement ce que j'ai documenté sur les raisons pour lesquelles la plupart des pilotes d'agents IA échouent en entreprise : la cause dominante n'est presque jamais technique, c'est un cadrage insuffisant en amont. ADKAR ne contredit pas ce constat, il le rend actionnable en nommant quelle partie du cadrage a lâché.

L'autre réflexe, c'est de traiter ces cinq étapes au cadrage et pas à la livraison, exactement comme les deux premières semaines d'un projet en déterminent la suite. Un plan d'adoption écrit après le déploiement est un plan de rattrapage.

C'est ce diagnostic que je pose dans mes missions d'intégration IA, avant de parler d'outil ou de licence. Pour chiffrer ce qu'un usage réellement adopté ferait gagner, mon calculateur de ROI d'automatisation donne une base de discussion honnête plutôt qu'une promesse.