Quand tout le monde a l'IA mais que l'entreprise n'apprend toujours rien : le bourbier de l'adoption de l'IA en entreprise

L'article aborde la phase douloureuse de l'adoption de l'IA où les licences pour Copilot, ChatGPT Enterprise, Claude, Gemini ou Cursor sont provisionnées, mais l'entreprise dans son ensemble n'apprend presque rien. Le modèle Leadership, Lab et Crowd d'Ethan Mollick est cité : le Leadership définit la direction, la Foule découvre des cas d'usage, et le Lab devrait transformer ces découvertes en pratiques partagées — mais l'apprentissage voyage rarement.

Problèmes clés de l'adoption actuelle de l'IA

• La première phase ressemble aux déploiements d'entreprise standard : acheter des sièges, définir une utilisation acceptable, organiser des formations, créer un réseau de champions, demander aux gens de partager des cas d'usage dans un canal Teams (qui devient un grenier mort).
• La deuxième phase est plus désordonnée : une équipe utilise Copilot comme autocomplétion, une autre utilise Claude Code avec des boucles et des révisions serrées, un propriétaire de produit prototypise un logiciel réel au lieu de maquettes Figma, un ingénieur senior délègue l'analyse des causes racines à un agent et obtient une solution valide en moins d'une heure (auparavant deux semaines), un junior produit du code soigné sans comprendre les implications architecturales, une équipe de support transforme tranquillement des tickets récurrents en automatisation de workflow parce que personne au Centre d'Excellence n'a jamais posé la bonne question.
• L'unité d'adoption n'est plus l'organisation ni même l'équipe — c'est la boucle à l'intérieur du travail.

Pourquoi la machinerie traditionnelle du changement échoue

Les communautés de pratique, les sessions brown-bag, les réseaux de champions, les présentations d'habilitation, les démos mensuelles, les enquêtes — tout cela est trop lent. Le travail intéressant de l'IA apparaît à l'intérieur d'une revue de code, d'une proposition commerciale, d'une tâche de recherche, d'un prototype de produit, d'un incident de production, d'une stratégie de test, ou d'une question de conformité. Au moment où l'histoire devient une diapositive de meilleure pratique, l'apprentissage a perdu son tranchant. Ce qui le rendait utile était la friction : le contexte manquant, le test qui a échoué, le comportement étrange de l'API, le moment où l'agent s'est éparpillé dans le non-sens et où quelqu'un a dû le ramener.

Le cadre de la boucle élastique

L'auteur suggère de réfléchir à travers la boucle élastique : la collaboration avec l'IA n'est pas un mode unique. Elle s'étend de la co-conduite serrée et synchrone à la délégation plus lâche et asynchrone. La véritable question d'adoption n'est pas « les gens utilisent-ils l'IA ? » mais : les équipes savent-elles quelle taille de boucle utiliser ? Où ont-elles besoin de résistance ? Quels artéfacts devraient survivre à la boucle ? Comment ces artéfacts deviennent-ils quelque chose dont l'organisation peut apprendre ? C'est bien plus difficile que l'utilisation d'outils ou le comptage de tokens.