Le rôle du coach dans la transformation IA

Les organisations dépensent de l’argent sérieux pour rater l’adoption de l’IA dans un ordre très précis : licences d’abord, revue de sécurité ensuite, infrastructure en troisième, puis, presque en dernier recours, une journée de formation. Le chiffre le plus souvent cité pour où cela finit est un plateau d’adoption à 15 % — je l’ai vu répété assez souvent pour le tenir comme directionnellement vrai, même si je n’ai jamais vu nommer l’étude qui le sous-tend ; prenez-le comme une forme, pas comme un chiffre établi. Ce qui est plus fiable, c’est le schéma en dessous : le déploiement cale non pas parce que les gens ne comprennent pas l’outil, mais parce que personne dans le projet ne possède la partie du travail qui n’a rien à voir avec l’outil.

Cet écart était encore survivable sur une horloge plus lente. Ce n’est plus le cas, et cela est devenu plus compliqué, pas moins. Une entreprise qui a fait correctement le travail de gouvernance ne remet plus un seul outil à tout le monde ; elle remet un menu : un chatbot grand public pour l’information publique, une offre cloud d’entreprise pour le travail interne, une option hébergée dans l’UE pour les fichiers confidentiels, peut-être un modèle local pour les tâches étroites et sensibles qui ne devraient pas sortir du bâtiment du tout. C’est la bonne politique. C’est aussi, du siège de la personne qui fait réellement le travail, quatre outils au lieu d’un, chacun avec une règle sur le document qui a le droit de le toucher. Personne n’adopte cela volontairement à partir d’une diapositive expliquant les niveaux de sensibilité. On l’adopte parce que quelqu’un s’assoit avec vous pendant que vous vérifiez, pour la dixième fois, dans laquelle des quatre cases tombe un contrat client, jusqu’à ce que vérifier devienne un réflexe au lieu d’un moment d’arrêt et de question.

Savoir comment quelque chose fonctionne et l’utiliser par habitude sont deux états différents, et la distance entre les deux est exactement là où opère un coach, pas un ingénieur, et pas un document de politique non plus. Dix ans à tenir une pratique de coaching individuel, à accompagner des gens à travers des changements de carrière et les transitions pour lesquelles personne ne planifie de journée de formation, m’ont appris quelque chose qui se transfère directement ici : les gens résistent rarement au changement parce que sa logique leur échappe. Ils résistent parce qu’utiliser la nouvelle manière, devant leurs collègues, expose exactement tout ce qu’ils ne savent pas encore faire — et cela menace quelque chose de plus précis que la productivité. Cela menace le sentiment d’être la personne compétente dans la salle. Les gens résistent rarement à l’outil lui-même ; ils résistent à la raison qu’on ne leur a pas dite à voix haute (playbook 2, « Prise de conscience et désir »), et « la conformité nous l’a demandé » n’est pas une raison, c’est un ordre.

Un ingénieur résout pour que l’outil fonctionne. Un coach résout pour qu’une personne précise accepte de paraître incompétente devant son équipe assez longtemps pour cesser de l’être — l’écart entre savoir et faire, qui se comble par la répétition avec retour plutôt que par une session unique (playbook 4, « Construire la capacité »). La plupart des déploiements d’IA ne pourvoient que le premier poste, parce que c’est celui qui a une ligne budgétaire et un livrable. Le coaching ne produit pas un système que vous pouvez montrer quand le budget est revu, alors il est traité comme facultatif, même dans les déploiements qui vous diront sur le papier que les personnes sont la priorité.

Ce que ce travail représente réellement s’est élargi depuis la dernière fois que j’en ai écrit. C’est toujours travailler avec la résistance au lieu de la vaincre à force d’arguments, car argumenter déplace rarement quelqu’un dont l’objection n’a jamais vraiment porté sur la logique. C’est toujours construire assez de sécurité psychologique pour qu’essayer l’outil maladroitement, sous les yeux d’un manager, ne se lise pas comme une donnée pour un entretien d’évaluation. Mais cela inclut désormais aussi de traduire une cartographie de sensibilité des données en quelque chose qui ne ressemble pas à une cage de conformité : pas « vous ne pouvez pas utiliser ChatGPT », qui sonne comme une punition pour quelque chose que tout le monde faisait déjà, mais « voici exactement quel outil couvre ce fichier, et voici pourquoi il est vraiment acceptable de l’utiliser », rattaché à la tâche que cette personne précise déteste déjà faire (playbook 3, « Habilitation par rôle »). Mal traduite, la gouvernance se lit comme un mur de nouvelles règles posées sur un outil que les gens trouvaient déjà déroutant. Bien traduite, par quelqu’un dont le métier est la traduction, elle se lit comme la permission, enfin, d’arrêter de deviner.

Et puis rester présent pendant la période où la personne est visiblement moins bonne dans son travail qu’il y a un mois, la fenêtre exacte où l’adoption régresse discrètement sans maintien délibéré (playbook 5, « Renforcement »). Cette fenêtre s’est allongée, pas raccourcie, le jour où « l’outil d’IA » a cessé de désigner une seule chose.

La question ouverte n’est pas de savoir si ce rôle est utile, mais qui est censé le tenir quand la plupart des entreprises n’ont ni AI Officer, ni DPO, ni comité d’éthique, et encore moins un coach. Nommez le rôle explicitement même sans département où le loger, plutôt que de le laisser revenir par défaut à celui qui est déjà surchargé (playbook 5 Gouvernance, « Des rôles sans département »). Savoir si le coaching devient une pratique standard, ou si la transformation IA continue d’échouer discrètement à la même étape humaine sur laquelle chaque perturbation technologique précédente a aussi échoué, est la question que personne parmi ceux qui financent ces déploiements ne semble encore poser — et il coûte de plus en plus cher de continuer à ne pas la poser.