L'IA s'installe ou non. La culture tranche.

Trois conditions culturelles qui décident de l'adoption.

Quand nous regardons les déploiements IA qui se sont installés et ceux qui ne se sont pas installés, dans le travail mené à travers nos quatre bureaux, trois conditions culturelles sous-tendent presque chaque cas réussi. La première est la sécurité psychologique pour signaler une mauvaise sortie. La deuxième est la volonté de partager le travail dont le modèle peut apprendre. La troisième est le confort avec le jugement mesuré plutôt qu'avec l'intuition du héros.

La sécurité psychologique pour signaler une mauvaise sortie semble évidente jusqu'à ce qu'on observe une équipe en pratique. L'opérateur qui accepte la première réponse de l'agent sans la challenger est soit celui qui a décidé que l'agent est suffisamment juste, soit celui qui a décidé que la signaler ne valait pas la friction. Les deux signaux sont mauvais pour l'adoption. Les équipes qui capitalisent sont celles où signaler la sortie est normal, attendu, et reconnu.

La volonté de partager le travail dont le modèle peut apprendre est la deuxième condition. Les agents s'améliorent quand ils ont accès aux schémas que les opérateurs expérimentés ont construits. Si les opérateurs voient l'agent comme un concurrent pour leur rôle, ils gardent leurs schémas, l'agent ne s'améliore pas, et la boucle confirme leur peur. S'ils le voient comme un outil qu'ils peuvent façonner, ils partagent les schémas et la boucle renforce l'adoption.

Le confort avec le jugement mesuré plutôt qu'avec l'intuition du héros est la troisième. L'IA introduit le jugement mesuré dans des processus où l'intuition a été le signal dominant. Les équipes qui peinent à adopter sont généralement celles où l'opérateur le plus expérimenté a bâti sa réputation sur l'intuition et à qui on demande maintenant de s'en remettre à une sortie mesurée. Les équipes qui adoptent bien sont généralement celles où intuition et mesure sont vues comme une paire, pas comme une hiérarchie.

La conduite du changement doit avoir lieu en parallèle de la construction.

L'erreur la plus fréquente que nous voyons, et nous l'avons vue à travers les industries et les bureaux, est de séquencer la conduite du changement après la construction. L'équipe construit l'agent en isolation, le livre à l'équipe opérationnelle avec une session de formation, et suppose que l'adoption suivra. L'adoption ne suit pas. L'équipe opérationnelle vit l'agent comme quelque chose qu'on lui impose, trouve les coutures qui ne correspondent pas à son processus, et le contourne silencieusement.

Le travail qui produit l'adoption commence avant la première ligne de code. L'équipe opérationnelle est dans la conversation de conception. Elle définit le processus que l'agent doit soutenir, nomme les points où son jugement garde la décision, et identifie les cas où la sortie de l'agent doit être challengée par défaut. L'agent qui sort est alors un outil que les opérateurs ont façonné, pas un outil qu'on leur impose.

Le coût de mener la conduite du changement en parallèle de la construction est réel. La construction prend plus de temps. Les conversations sont plus chahutées. Elles produisent aussi un agent d'une autre nature, qui s'installe au lancement plutôt qu'après un trimestre de rattrapage.

Comment repérer le rejet tôt.

Le signal de rejet le plus fréquent est le non-usage silencieux, et c'est le signal que les équipes ratent le plus souvent. L'agent sort, l'usage est élevé la première semaine parce que tout le monde est curieux, baisse la deuxième parce que la curiosité s'estompe, et s'aplatit dès la troisième à un niveau de base bien en dessous de la cible de conception. L'équipe opérationnelle ne se plaint pas. Elle a simplement absorbé l'agent dans sa boîte à outils à un niveau qui ne change pas son processus.

Nous surveillons quatre métriques dans les six premières semaines de tout déploiement pour attraper le motif de non-usage silencieux. Le nombre d'utilisateurs actifs par semaine. Le nombre moyen de sessions par utilisateur actif. Le taux d'acceptation des suggestions de l'agent. Le temps entre le lancement et la première correction signalée par un utilisateur. Chacune raconte une histoire différente, et la combinaison nous dit tôt si le déploiement s'installe.

Quand le motif de non-usage silencieux apparaît, la première réponse que nous recommandons est la conversation plutôt que le travail produit. Nous nous asseyons avec trois ou quatre opérateurs et leur demandons ce qu'ils font à la place d'utiliser l'agent pour les cas qu'il est censé traiter. Les réponses sont presque toujours opérationnelles plutôt que techniques. La sortie de l'agent est bonne. Les opérateurs ne lui font pas encore assez confiance, ou l'intégration au processus exige un clic de trop, ou l'affichage de confiance de l'agent ne correspond pas à leur propre sens de la confiance.

L'opérateur conduit l'adoption. Pas l'exécutif.

Le parrainage exécutif compte. Il pose les conditions du travail, alloue le budget, et signale que le déploiement est sérieux. Il ne produit pas l'adoption. L'adoption se passe au poste de l'opérateur, au moment où il choisit d'utiliser l'agent ou de le contourner. Ce choix est influencé par le ton du sponsor exécutif, mais il est tranché par l'expérience que l'opérateur fait de l'outil.

Les équipes que nous avons vues atteindre une adoption durable ont investi lourdement dans l'identification des opérateurs qui peuvent porter le déploiement auprès de leurs pairs. Ils sont généralement assez jeunes dans leur carrière pour s'engager avec le nouvel outil sans ego, assez expérimentés pour que leurs pairs les respectent, et assez curieux pour pousser l'agent dans ses cas limites. Deux ou trois opérateurs de ce profil, embarqués dans la conversation de conception et visibles dans le déploiement, font davantage pour l'adoption que n'importe quel town hall que le dirigeant puisse animer.

Identifier ces opérateurs est le travail que la fonction conduite du changement devrait faire dès le premier mois, pas au troisième. Les équipes qui retardent cette étape trouvent généralement que le déploiement avance dans la communication exécutive mais n'avance jamais dans l'équipe opérationnelle.

La culture est la fonctionnalité que l'on ne peut pas licencier.

Le fournisseur d'agent ne peut pas vous livrer une culture. Le cabinet de conseil ne peut pas l'installer. La décision de plateforme ne peut pas la corriger. La culture est le lent travail de conversations, de rituels, de choix de recrutement et de conception des incitations qui construit les conditions pour que de nouveaux outils soient adoptés, et il doit être fait avec l'équipe qui possédera le processus.

Dans les missions que nous menons, la part d'effort consacrée aux conditions culturelles de l'adoption surprend généralement les clients qui s'attendaient à un programme dominé par la construction. La part qui va à la construction elle-même est plus petite que la part qui va aux conversations avec l'équipe opérationnelle, au travail de littératie, à la refonte du processus et à l'identification des opérateurs qui porteront le changement.

Si votre organisation prépare un déploiement IA et que le travail culturel attend dans une phase ultérieure, le mouvement que nous recommandons est de l'avancer. Les équipes qui le font en amont livrent des déploiements qui s'installent au lancement. Celles qui ne le font pas livrent des déploiements qui nécessitent un programme de remédiation trois trimestres plus tard. Les équipes Consulting et Tech Factory de nos bureaux de Paris, Dubaï, Singapour et Bali sont joignables depuis le formulaire ci-dessous.