Dans presque toutes les organisations qui expérimentent avec l'IA, le même groupe finit par se former : deux, peut-être trois personnes qui comprennent, qui se sont mises à tester elles-mêmes, qui racontent avec enthousiasme ce qui est possible. Elles construisent un prototype, testent un outil, partagent des résultats dans un chat interne. Le reste de l'organisation regarde, hoche la tête, et continue le travail comme avant.
Après quelques mois, il y a une liste d'expériences intéressantes et aucun changement dans la façon dont le travail est réellement effectué. Les deux enthousiastes sont toujours enthousiastes. Tout le monde autour d'eux n'a pas bougé.
Le raisonnement derrière cette approche paraît sensé : commencer petit, avec des personnes motivées, et laisser le succès se répandre naturellement. Cela fonctionne effectivement pour certains changements. Une nouvelle façon de travailler qui fait visiblement gagner du temps se propage parfois de manière organique, les collègues l'adoptant d'eux-mêmes.
Avec l'IA, ce mécanisme ne fonctionne généralement pas, et la raison ne réside pas dans les personnes mais dans l'organisation qui les entoure. Les enthousiastes ont souvent accès à des systèmes, du temps et un mandat que les autres n'ont pas. Ce qui représente pour eux une simple après-midi de test demande, pour un collègue sans cet accès, une demande, une approbation, un ticket informatique. L'enthousiasme n'est pas le problème. L'absence d'un chemin permettant aux autres de suivre, voilà le problème.
L'ordre dans lequel se construit la maturité en matière d'IA ne commence pas par les personnes qui le veulent. Il commence par la structure qui le rend possible : comment l'organisation est organisée, quelle infrastructure informatique est en place, comment les données sont gérées. Deux enthousiastes peuvent contourner cette structure, avec leur propre accès, leurs propres astuces, leurs propres détours. Le reste de l'organisation ne le peut pas, et ne devrait pas non plus le vouloir — les détours ne constituent pas une base pour quelque chose qui doit continuer à fonctionner.
Cela explique pourquoi ce schéma se répète souvent aux côtés d'autres pièges bien connus. Qui lit sur ce qui doit être démontré avant qu'un pilote ne mène à quelque chose reconnaît un mécanisme similaire : une activité sans accord sur ce que signifie le succès reste une activité. Chez deux enthousiastes, l'accord fait également défaut — ni sur ce qui doit être démontré, ni sur qui prend la suite après eux.
Il existe quelques signaux reconnaissables. Le premier est que les mêmes deux ou trois noms reviennent sans cesse dès qu'on parle d'IA, dans chaque réunion, dans chaque mise à jour. Le deuxième est que les questions des autres services commencent par « comment ont-ils fait » plutôt que par une démarche propre. Le troisième, et le plus sous-estimé, est que personne ne peut expliquer ce qui devrait se passer si l'une de ces deux personnes partait demain.
Un quatrième signal est plus subtil : l'expérience continue de fonctionner dans son propre coin, déconnectée du reste du processus. Cela rejoint ce qui se produit lorsque un pilote qui ne trouve aucun écho hors de son propre service — l'enthousiasme sans connexion avec le reste de l'organisation reste une île, aussi bien que cette île fonctionne.
Un cinquième signal, enfin, est que la mise à l'échelle est proposée comme étape suivante, alors que personne n'a vérifié si la base est déjà en place. Ce risque est décrit dans ce qui se passe lorsqu'on tente une mise à l'échelle avant que la base ne soit en place : deux enthousiastes qui veulent multiplier leur propre succès vers dix équipes se heurtent précisément à la structure qu'ils avaient eux-mêmes contournée.
Il est tentant de conclure qu'il faut plus d'enthousiastes, ou une meilleure formation, ou un programme de culture d'entreprise. Cela passe à côté de l'essentiel. La question n'est pas de savoir s'il y a suffisamment de personnes motivées — il y en a souvent déjà deux, et c'est précisément le problème, car deux ne constituent pas une structure. La question est de savoir si l'organisation dans son ensemble — dans sa conception, dans la façon dont les systèmes communiquent entre eux, dans la disponibilité et la fiabilité des données — peut supporter une situation où non pas deux mais beaucoup plus de personnes peuvent travailler avec l'IA. C'est une question différente de celle de savoir qui est enthousiaste, et c'est la question qui doit d'abord recevoir une réponse.
Pour ceux qui, dans un rôle de direction, se heurtent à ce schéma, il est utile de savoir à quoi une personne dans une position similaire serait attentive : à quoi un CEO serait attentif en évaluant la maturité en matière d'IA décrit certains de ces points d'attention, tout comme le regard qu'un COO porterait sur la maturité en matière d'IA depuis une autre perspective sur la même organisation.
Si deux enthousiastes démontrent qu'une chose est possible, la question reste sans réponse de savoir quelle part du travail peut réellement être reprise, et par qui. Cette question ne relève pas de la maturité mais du travail lui-même : quelles tâches se prêtent à une reprise par l'IA et quelle part cela représente. C'est précisément à cela que sert le scan de travail de FTE TO AI — il calcule, tâche par tâche, quelle part du travail peut être reprise, indépendamment de qui expérimente déjà avec enthousiasme.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.