Deux cents licences, six semaines, rien n'a bougé
Une entreprise avec qui j'ai échangé l'an dernier a acheté GitHub Copilot pour deux cents ingénieurs, soigné son lancement, puis attendu que la courbe de productivité s'infléchisse. Six semaines plus tard, l'usage quotidien s'était effondré à une poignée d'irréductibles. L'outil marchait très bien. Le déploiement, non. Personne n'avait décidé quelles tâches devaient changer, quelles revues de code devaient accélérer, ni à qui le travail était censé devenir plus simple. La licence s'est renouvelée à la date prévue. La façon de travailler, elle, est restée identique.
Cet écart, c'est toute l'histoire de la transformation IA. BCG a posé un chiffre dessus qui colle à ce que la plupart des dirigeants pressentent : dans leur grille, environ 70% de la valeur vient des personnes et des processus, près de 20% des données et de la technique, et seulement 10% des algorithmes eux-mêmes. Le plus gênant, c'est que ces 70% sont précisément la part qu'on ne peut pas acheter. Signer un contrat pour un modèle prend un après-midi. Repenser la façon dont mille personnes travaillent prend des trimestres, et oblige quelqu'un à assumer la perturbation.
Alors la chose prévisible arrive. Les budgets filent vers les outils, parce qu'un outil est lisible et que les achats savent le valider, pendant que la refonte organisationnelle qui rendrait ces outils utiles ne reçoit qu'une fraction de l'attention.
Pourquoi le pilote éblouit et le déploiement s'éteint
Les pilotes sont taillés pour réussir, et c'est bien le problème. Vous confiez une nouvelle capacité à dix volontaires qui l'ont réclamée, vous leur offrez la couverture de la direction, et vous les invitez à tout casser. Évidemment que ça marche. Puis vous poussez le même outil vers mille personnes qu'on n'a jamais consultées, dont la prime récompense encore l'ancien savoir-faire, et dont les managers ont reçu une annonce Slack en guise de formation. Même logiciel, résultat inverse.
La lecture honnête, c'est qu'un pilote mesure si la technologie fonctionne, tandis qu'un déploiement mesure si l'organisation accepte de se réorganiser autour. Réussir le premier ne dit presque rien du second. C'est le fond du propos de réinventer les organisations : un modèle ne vaut jamais mieux que le système d'exploitation dans lequel il se branche.
L'alignement est plus rare que ne le laisse croire le deck de lancement
Demandez à trois dirigeants quel problème votre programme IA résout, et vous obtiendrez souvent trois réponses. Les sondages retrouvent toujours la même chose : une faible part d'entreprises ont vraiment aligné le business, la DSI et le comex sur l'endroit où l'IA doit créer de la valeur, et celles qui l'ont fait ont plusieurs fois plus de chances de constater des retours réels. L'alignement n'est pas une diapositive qu'on présente une fois. C'est une discussion qui dure, sur le travail qui change et sur qui en sort gagnant.
Les travaux de McKinsey sur la conduite du changement à l'ère de l'IA générative(lien externe, nouvel onglet) aboutissent à traiter les employés en co-créateurs plutôt qu'en utilisateurs finaux, et ce cadrage compte parce que l'inverse, c'est exactement la fragmentation sur le terrain. Le marketing achète Jasper, l'engineering standardise sur Copilot, le support teste un assistant Intercom, et aucun des trois ne partage de définition du succès. Six mois plus tard, l'entreprise a une douzaine d'expériences déconnectées, une facture logicielle plus lourde, et aucune histoire cohérente à raconter au conseil. Les outils se sont multipliés. Le modèle opérationnel, jamais, et la valeur est restée prisonnière de démos isolées.
Les gens font ce que leur rôle récompense
L'adoption suit les incitations, pas l'enthousiasme. Si un outil accélère une tâche mais que la reconnaissance va toujours à l'ancienne manière de faire, les gens l'utilisent pour la forme et reviennent discrètement en arrière dès que la pression monte. J'ai vu des analystes continuer à monter leurs tableaux à la main parce que c'était l'artefact que leur manager savait évaluer, alors qu'un chemin plus rapide était posé juste devant eux.
C'est le même échec que derrière la mort silencieuse de la fiche de poste : le travail se déplace, la définition du rôle reste figée, et les gens devinent ce qu'est un bon résultat. Une vraie transformation, c'est redéfinir les rôles, retirer ouvertement les tâches qui n'ont plus de sens, et récompenser le nouveau comportement là où ça compte vraiment, dans les évaluations. L'analyse de BCG sur comment les leaders tech doivent se réinventer pour l'ère de l'IA(lien externe, nouvel onglet) le dit sans détour : les entreprises en tête financent l'IA en simplifiant les opérations et en réduisant la complexité, pas en l'empilant sur des structures qu'elles refusent de toucher.
Conduire le changement, pas seulement livrer l'outil
Le travail de leadership ici, c'est de redessiner le travail, et c'est plus dur que de distribuer des licences. Cela veut dire décider à voix haute ce qui s'arrête, dégager du temps protégé pour apprendre au lieu de faire comme si les gains étaient gratuits, et rendre possible le fait de dire que ça ne marche pas encore. Cela veut dire aussi piloter directement la collaboration entre humains et agents, l'exigence déjà posée aux leaders d'équipes hybrides, désormais étendue à des coéquipiers en partie logiciels. Les managers qui portent cette charge y ont rarement été préparés ; ils ont besoin de soutien, pas seulement d'un objectif à atteindre.
Le takeaway
Avant d'acheter le prochain outil IA, écrivez les trois rôles qu'il va changer et la façon dont vous récompenserez les gens qui travailleront autrement. Si vous ne pouvez pas remplir cette page, vous ne tenez pas un plan de transformation. Vous tenez un bon de commande mieux habillé.
