L’activité n’est pas le progrès
Dernier de trois articles. Un processus peut devenir spectaculairement plus rapide sans que l’entreprise avance vraiment. Le chiffre le plus modeste impressionnait beaucoup moins et servait beaucoup plus.
En début d’année, nous pouvions décrire tout ce que nous avions construit avec l’IA, et presque rien de ce que cela avait changé. Voici le premier article d’une série sur ce que nous avons fait pour y remédier.
Il existe, dans un programme d’IA, une phase confortable où tout ressemble à un progrès. De nouvelles capacités arrivent à quelques semaines d’intervalle. Les gens leur trouvent des usages que personne n’avait prévus. Les démonstrations se passent bien. Rien ne cloche de façon évidente.
Nous sommes restés un moment dans cette phase.
Nous avions intégré l’IA au conseil, à l’ingénierie logicielle, à la gestion de ce que l’entreprise sait, et à la livraison. Nous pouvions tout décrire. Quand on nous demandait ce que cela avait changé pour l’entreprise, nous avions des anecdotes et un fort sentiment collectif que les choses allaient mieux.
Ce n’est pas une réponse. C’est l’absence de réponse, énoncée avec assurance.
Les modèles fonctionnaient. Les outils fonctionnaient. Personne n’attendait une décision de plateforme. Ce qui manquait se situait plus en amont, et c’était plus terne que tout cela : personne ne s’était accordé sur ce qui compterait comme un succès.
Sans cet accord, chaque discussion sur la valeur de l’IA se transforme en discussion sur l’activité de l’IA, parce que l’activité est ce que l’on voit réellement. Combien de personnes l’utilisent. Combien elle a produit. À quelle vitesse. Tout cela se mesure, et rien de cela ne prouve que quoi que ce soit ait bougé en aval.
On peut aller très loin ainsi sans savoir si l’on est en avance.
Pour deux raisons.
La première est que nos clients sont dans la même situation et ne le diront pas. Dans les conseils d’administration, la discussion sur l’IA est passée de ce qu’elle peut faire à ce qu’elle a fait, et il est bien plus difficile de répondre à la seconde question qu’à la première. Faire semblant n’aide personne.
La seconde est que les enseignements utiles sont les moins flatteurs. Une étude de cas décrit une réussite. Ce que nous voulions consigner, c’est la suite des corrections : les hypothèses qui se sont révélées fausses, et ce que nous avons changé en conséquence. C’est plus utile à quelqu’un qui fait face aux mêmes décisions, et plus difficile à simuler.
Nous les passerons en revue dans l’ordre où nous les avons rencontrées, car cet ordre s’est révélé important.
La première correction portait sur ce que lit le modèle. Avant que l’IA puisse faire quoi que ce soit qui vaille la peine d’être mesuré, les connaissances sur lesquelles elle s’appuyait devaient être accessibles et à jour. Les nôtres n’étaient ni l’un ni l’autre là où cela comptait.
Venait ensuite la question de l’emplacement physique de ces connaissances et de leur traitement. Dans cette région, les juristes s’y intéressent avant les architectes.
La troisième concernait la livraison : ce que la réutilisation apporte réellement une fois que l’assistance de l’IA entre en jeu, pourquoi l’alternative « construire ou acheter » met les gens sur une mauvaise piste, et ce qui change en matière de responsabilité quand un outil rédige le travail.
La mesure elle-même a pris le plus de temps. Quand nous avons enfin mesuré ce que le travail changeait en aval, plusieurs de nos convictions se sont révélées fausses.
Nous avons appliqué chaque correction d’abord à notre propre entreprise. Chacune fait depuis partie de notre façon de conduire les projets clients, et chaque article de cette série aboutit à quelque chose qu’un client peut constater au cours d’une mission. Le Sprint 0 est conçu pour se terminer par un prototype fonctionnel que le client a utilisé et approuvé, et rien de ce qu’un outil d’IA a rédigé ne parvient à un client sans avoir été revu par un ingénieur nommément désigné.
Le déroulement de cette mission, et les points où une personne signe, sont décrits sur la page Engagement et livraison assistés par l’IA.
La position de départ, en toute honnêteté, était la suivante en juin. Nous avions beaucoup construit. Nous avions beaucoup déployé. Nous ne pouvions pas dire ce que cela valait, et nous ne nous l’étions pas encore avoué assez clairement pour y remédier.
Tout ce qui suit est venu d’une seule question, posée en refusant d’accepter un indicateur d’activité pour réponse : qu’est-ce qui a changé dans l’entreprise parce que nous avons fait cela ?
Le prochain article examine ce que nous avons trouvé en remontant cette question jusqu’à sa source, qui s’est révélée être l’état de nos propres connaissances.
Fait partie de la série Insights. Recevez les nouvelles analyses par e-mail ou suivez le flux RSS.
Dernier de trois articles. Un processus peut devenir spectaculairement plus rapide sans que l’entreprise avance vraiment. Le chiffre le plus modeste impressionnait beaucoup moins et servait beaucoup plus.
Demandez pourquoi un programme d’IA s’est enlisé, et la réponse sera technique. En dessous, il y a généralement une question que personne n’avait correctement formulée, et dont personne n’attendait la réponse.
Il y a un an, les conseils d’administration parlaient de cas d’usage et de preuves de concept. La question posée aujourd’hui est plus difficile, et les études montrent que la plupart des organisations n’y ont pas encore répondu.