Playbook 1 — Le fossé de l'adoption
Pourquoi un pilote qui fonctionne et un pilote adopté sont deux projets différents
Un outil qui passe les tests et une équipe qui s’en sert tous les jours ne sont pas le même résultat. L’essentiel des budgets IA est dépensé comme si c’était le cas.
Voici comment le fossé s’ouvre. Un pilote est cadré pour répondre à une question technique : le modèle produit-il un bon résultat, s’intègre-t-il, tient-il face à de vraies données. Il réussit sur ces critères, il est validé, et tout le monde passe à autre chose. La mesure qui comptait — les gens ont-ils changé leur façon de travailler — n’a jamais été celle sur laquelle le projet rendait compte. Un feu vert sur l’outil se lit donc comme un feu vert sur l’adoption, et rien dans l’outil ne vous dit si quelqu’un l’a ouvert le lundi.
Le cabinet de recherche en gestion du changement Prosci publie un chiffre selon lequel la plupart des échecs de l’IA tiennent à des facteurs humains plutôt qu’à la technologie elle-même. À lire comme un ordre de grandeur, pas comme un chiffre précis : Prosci vend des prestations de gestion du changement, son cadrage n’est donc pas neutre. Mais cela correspond à ce qu’on observe sans étude. L’outil échoue rarement. C’est le plan autour de l’outil qui échoue.
Le fossé a deux bords, et ils échouent différemment. Le premier sépare l’approuvé de l’utilisé : la direction valide, les licences sont achetées, l’usage stagne. Le second sépare l’utilisé du correctement utilisé — quelqu’un ouvre l’outil, obtient un mauvais premier résultat, et revient discrètement à l’ancienne méthode pendant que la licence reste active. Un seul des deux ressemble à un problème sur la facture.
Les décomptes de licences masquent les deux. Un siège payé et un siège utilisé sont des lignes identiques. Le signal honnête se situe au niveau de la tâche : ce travail a-t-il été fait dans l’outil, ou à côté.
Ce qu’il faut trancher avant de déclarer un pilote réussi :
- L’indicateur de réussite inclut un comportement, pas seulement un résultat.
- Vous savez qui est censé l’utiliser, sur quelle tâche, à quelle fréquence.
- Quelqu’un est responsable de l’adoption, distinct de celui qui possède l’outil.
- Vous avez une base de référence sur la façon dont la tâche était faite avant.
- Il existe un point défini où « personne ne l’utilise » compte comme un résultat.
Rien de tout cela ne relève de l’enthousiasme. C’est décider, avant le début du pilote, qu’un outil que personne n’utilise a échoué — même s’il fonctionne parfaitement.
Suite : le playbook 2 nomme les deux questions auxquelles un déploiement doit répondre avant le premier jour.