Pourquoi l'adoption de l'IA échoue à l'étape de la formation

La plupart des programmes d’adoption de l’IA meurent dans la salle où tout le monde a adoré la démo. Quelqu’un montre l’outil en train de faire quelque chose de réellement impressionnant, la salle acquiesce, quelques personnes posent des questions pointues, et six semaines plus tard les chiffres d’usage sont plats. L’outil n’a pas échoué. Le plan autour de l’outil, si.

Ce schéma compterait moins si le coût de l’erreur se mesurait encore en une journée de formation gâchée. Ce n’est plus le cas. Le rythme auquel les modèles, les copilotes et les fonctions agentiques sortent en ce moment signifie qu’une organisation qui cale à l’étape de la formation ne perd pas seulement un trimestre — elle déploie la version un d’un outil face à des équipes encore peu compétentes dessus, alors que la version trois est déjà en service. La perturbation n’attend pas que le plateau se dégage.

J’ai vu une version antérieure de ce blocage en 2001, en enseignant SAP BusinessObjects à des salles entières à travers l’Europe qui n’avaient jamais touché un constructeur de requêtes. La partie démo était facile. La partie dure venait après, quand les gens retournaient à leur bureau et tendaient la main vers l’export Excel qu’ils connaissaient déjà, parce que la nouvelle interface n’avait pas encore gagné la friction qu’il leur coûtait de l’utiliser correctement. Compétence et enthousiasme ne sont pas la même monnaie, et une démo ne vous achète que la seconde.

La série Gestion du changement et habilitation à l’adoption nomme cela précisément : un pilote qui fonctionne et un pilote adopté sont deux projets différents, et la plupart des budgets IA sont dépensés comme si ce n’était pas le cas (playbook 1, « L’écart d’adoption »). La distance entre « c’est impressionnant » et « je m’en sers tous les jours » est un écart de pratique, pas de connaissance. Personne n’adopte un outil parce qu’il a compris une diapositive à son sujet. On l’adopte parce qu’on a été mauvais avec lui quelques fois, dans un cadre où être mauvais ne coûtait rien, et qu’ensuite on a été un peu moins mauvais.

Les programmes de formation construisent presque jamais ce cadre exprès. Un animateur déroule une démonstration bien huilée, appelle cela de l’habilitation, et se demande pourquoi la salle qui a applaudi ne rouvre jamais l’outil d’elle-même. La correction consiste à scinder la formation en deux métiers : une formation par rôle, rattachée à la tâche réelle qu’une personne précise fait déjà (playbook 3, « Habilitation par rôle »), et une couche de coaching ensuite qui comble l’écart entre savoir et faire par la répétition avec retour, pas par une deuxième session (playbook 4, « Construire la capacité »).

Il y a une version de cet échec que je vois maintenant, propre à 2026, et elle est pire que la version générique. Certaines petites entreprises qui me parlent d’IA locale, faisant tourner un modèle à poids ouverts sur leur propre matériel au lieu d’envoyer tout à un chatbot public, traitent la décision de déploiement comme la partie difficile et l’étape de formation comme un détail, exactement l’ordre contre lequel je mettais en garde avec les déploiements qui commencent par les licences. Mais un modèle local n’est pas un remplacement direct de l’onglet ChatGPT que les gens connaissent déjà. Il se cache généralement derrière une interface plus étroite, construite pour une tâche précise comme la classification de documents ou l’extraction de factures, et il n’offre rien du confort généraliste d’un chatbot public. Demandez à quelqu’un de passer d’un outil qui répond à tout à un outil qui ne fait bien qu’une chose, sans lui expliquer pourquoi, et vous le verrez rouvrir discrètement le chatbot gratuit sur son téléphone en une semaine, ce qui est précisément le retour en arrière que l’étape de formation existe pour empêcher — sauf que c’est aussi désormais un échec de gouvernance, parce que ce téléphone n’est pas couvert par la cartographie des données que vous venez de passer un mois à construire.

Les installations locales que j’ai vues échouer ont presque toujours échoué à cette étape précise, pas au matériel. L’installation tournait, le modèle classait correctement les documents en test, et puis personne n’a pris en charge la semaine où la personne à la facturation était plus lente et plus frustrée qu’avec l’outil qu’on lui avait dit d’arrêter. Ce sont les mêmes six semaines que décrites plus haut ; elles ont juste maintenant un serveur dans la pièce du fond au lieu d’une diapositive de formation.

Ce qui sépare les organisations où cela tient, ce n’est pas un meilleur logiciel ni un déploiement plus long — c’est de savoir si elles laissent les gens se tromper sur du vrai travail plutôt que sur un exemple synthétique, et si quelqu’un est explicitement responsable des semaines qui suivent. L’adoption régresse en une petite centaine de jours sans renforcement délibéré, parce que les vieilles habitudes sont la gravité par défaut (playbook 5, « Renforcement »). Le nombre de connexions en semaine deux ne dit rien de la semaine treize, et un bon résultat de benchmark tiré de la démo du fournisseur non plus.

Rien de tout cela n’est propre à l’IA, et ce n’était pas propre aux constructeurs de requêtes en 2001 non plus. C’est le même mécanisme que j’ai vu pendant dix ans en coaching individuel à travers les transitions personnelles des gens : comprendre qu’une nouvelle voie existe et l’adopter sont séparés par un milieu désordonné où l’on est moins bon avec le nouveau qu’avec l’ancien, publiquement, pendant un temps. Les organisations sont aussi allergiques à ce milieu que les individus — et quand l’outil lui-même continue de changer sous le support de formation, ce milieu s’allonge au lieu de raccourcir, à moins que quelque chose soit conçu pour tenir les gens à travers.

La vraie question de conception d’un déploiement d’IA, local ou cloud, n’est donc pas comment susciter l’enthousiasme. C’est qui prend en charge les six semaines où les gens sont visiblement, inconfortablement mauvais avec la nouvelle manière, mesurées contre quelque chose de plus solide que le ressenti, comme les quatre chiffres de la carte de score du changement — usage, non-retour en arrière, confiance et compétence observée (playbook 6). Et c’est la même personne qui devrait répondre à la question que je pose maintenant à tout dirigeant qui envisage l’IA locale : qui maintiendra encore cela, et formera les gens dessus, dans trois ans ?