Avant l'outil

Les six textes précédents de cette série ont regardé l’IA depuis l’intérieur d’une seule personne. La partie 1 demandait ce qui rend quelqu’un distinctif une fois la couche technique prise en charge. La partie 2 expliquait pourquoi les polymathes peinent dans les organisations bâties sur des étiquettes. La partie 3 proposait une méthode pour trouver les aptitudes que vous ne remarquez pas chez vous, et la partie 4 examinait comment une blessure devient une forme de perception. La partie 5 traitait du fait de suivre une trajectoire que personne n’a cartographiée, et la partie 6 de ce qu’on transmet à la génération suivante. Ce texte revient à l’entreprise, parce que c’est là que la plupart des gens rencontreront d’abord ces questions.

Le lien entre les deux niveaux est plus ancien que l’IA. La conduite du changement distingue depuis longtemps le changement lui-même, qui a lieu à une date, de la transition que les gens traversent, qui se passe en eux et prend plus de temps. L’IA rend cette transition plus difficile que d’habitude.

Dans la plupart des programmes de changement, les gens avancent vers un état final défini, comme un nouveau processus ou un nouveau système. Ici, l'état final pour la personne est ouvert, parce qu'elle doit déterminer à quoi elle sert une fois que l'outil prend en charge une partie de ce qu'elle faisait.

La plupart des déploiements d’IA ignorent cela et suivent l’ordre familier : choisir l’outil, former le personnel, mesurer l’adoption. J’ai vu où mène cet ordre. Pendant mes années de conseil en BI, les stagiaires cessaient d’utiliser le logiciel une fois la formation terminée, et des projets échouaient pour des raisons organisationnelles alors que la technologie fonctionnait comme spécifié.

Quand les tâches techniques d'une équipe sont automatisées, les personnes qui les faisaient perdent ce qui faisait leur valeur. Si personne ne les aide à trouver une nouvelle définition, elles protègent l'ancienne.

Elles gardent le travail manuel, ralentissent le déploiement, ou évitent discrètement l’outil. Ce genre de résistance porte rarement sur la technologie. C’est une réponse rationnelle à une menace que personne n’a nommée.

Pour un COO, ou quiconque pilote le changement, cela appelle une séquence différente, avec le travail sur les personnes placé avant le déploiement.

1. Cartographier ce que chaque rôle s’apprête à perdre. Pour chaque rôle concerné, listez les tâches que l’IA va absorber, puis posez la question plus difficile : sur quoi reposait la valeur de ce rôle ? Un analyste dont la réputation repose sur la production rapide de rapports perd plus qu’une tâche quand les rapports se produisent tout seuls. Écrivez la réponse, parce qu’elle vous dit d’où viendra la résistance.
2. Mener le travail de découverte en équipe. La méthode du troisième texte fonctionne au sein d’une équipe, et les collègues sont les meilleurs témoins extérieurs dont vous disposez. En une session, chaque personne liste ce que ses collègues lui demandent régulièrement. Les collègues ajoutent ensuite ce qu’ils voient cette personne faire qu’eux-mêmes trouveraient difficile. Attendez-vous à apprendre sur votre équipe des choses qu’aucun entretien d’évaluation n’a captées.
3. Reconstruire les rôles autour des personnes avant de redessiner l’organigramme. Une fois que vous savez ce qui est naturel à chacun, combinez-le avec ce que les outils prennent désormais en charge. Certains rôles fusionneront. Certaines personnes se révéleront être des polymathes que vos descriptions de poste n’avaient jamais prévus. Traitez les nouvelles descriptions de rôle comme provisoires la première année, parce que personne ne voit encore la forme finale.
4. Garder la friction pour les juniors. Si l’IA prend tout le travail d’entrée de gamme, les nouveaux n’acquièrent jamais le jugement sur lequel reposent vos seniors, et dans quelques années vous n’aurez personne à promouvoir. Décidez délibérément quelles tâches les juniors font encore à la main, et expliquez pourquoi.
5. Rendre la trajectoire visible. Demandez à chaque personne ou équipe de tenir un court journal hebdomadaire de ce qu’elle a tenté avec l’IA, ce qui a marché et ce qui n’a pas marché. Examinez-le pour les tentatives, pas pour la production. Le journal vous montre où une nouvelle valeur se forme dans l’entreprise. Il donne aussi aux gens une preuve de leur propre progrès à un moment où leurs anciens repères disparaissent.

Il y a deux choses à éviter. N’annoncez pas de gains d’efficacité en termes d’effectifs avant que le travail de redéfinition ait eu lieu. Les personnes qui s’attendent à être remplacées cachent ce qu’elles savent, ce qui est l’inverse de ce dont vous avez besoin d’elles. Et ne confiez pas ce travail au fournisseur de l’outil. La formation d’un fournisseur enseigne le produit. Elle ne peut pas dire à vos équipes à quoi elles servent maintenant, et le fournisseur est payé sur des indicateurs d’adoption, qui peuvent grimper pendant que l’organisation stagne.

Rien de tout cela n’est un playbook éprouvé, et je me méfierais de quiconque en vendrait un. C’est l’ordre que je suivrais, d’après les endroits où j’ai vu des déploiements casser.

La question à laquelle un dirigeant doit répondre se révèle être la même que celle que chaque personne affronte dans cette série : une fois le travail technique pris en charge, à quoi vos équipes servent-elles ?