Il manque une question aux programmes qui s’enlisent

Demandez pourquoi un programme d’IA s’est enlisé, et l’on vous répondra généralement par un argument technique. Les données n’étaient pas prêtes. L’intégration a été plus difficile que prévu. Le modèle n’était pas assez bon pour le cas d’usage.

Une partie de tout cela est vraie. L’essentiel découle d’un problème antérieur : personne n’avait formulé de question en bonne et due forme.

À quoi ressemble une question bien formulée

Elle comporte trois éléments, et l’absence d’un seul suffit à faire échouer le travail.

Un responsable. Une personne nommée qui voulait savoir, et qui agira différemment selon la réponse. « L’entreprise » n’est pas un responsable, un comité non plus.

Une décision qui en dépend. La réponse doit changer ce que quelqu’un fait. Si la même chose se produit quelle que soit la réponse, vous avez un rapport, et les rapports sont aussi faciles à produire qu’à ignorer.

Une échéance. À quelle date la réponse est-elle utile ? C’est l’élément que l’on oublie, et c’est celui qui indique la qualité de réponse réellement nécessaire. Une réponse livrée le trimestre prochain à une question qui comptait la semaine dernière est un échec complet, même si elle passe pour une réussite légèrement tardive dans un rapport d’avancement.

La plupart des demandes qui arrivent à une équipe IA n’ont aucun de ces trois éléments. Elles ont un sujet.

Ce que dit la recherche, et ce qu’elle ne dit pas

La prévision de Gartner selon laquelle plus de quatre projets d’IA agentique sur dix seront abandonnés d’ici fin 2027 est largement citée. La partie qui mérite d’être lue est la liste des causes : l’envolée des coûts, une valeur métier floue, des contrôles de risque insuffisants. Deux des trois sont d’ordre commercial et une relève de la gouvernance. Aucune ne tient aux capacités de la technologie.

Cela correspond à ce que nous observons. La technologie est rarement le point de blocage. Le blocage vient de ce que l’objet construit n’a jamais été rattaché à une décision que quelqu’un attendait de prendre.

Offre et demande se confondent

Voici le schéma, et nous en avons nous-mêmes été coupables.

Une équipe compétente se dote d’un outil performant. L’outil sait produire des analyses, des synthèses, des recommandations, des premiers jets. Alors il en produit. Les résultats apparaissent, ils sont réellement bons, et ils circulent.

Personne ne les avait demandés.

Ils sont lus, parfois. Ils changent rarement quoi que ce soit, parce que la personne qui aurait pu agir en conséquence ne les attendait pas et a sa propre liste de priorités. L’équipe qui les produit en conclut que l’entreprise tarde à adopter l’outil. L’entreprise en conclut que l’équipe produit des choses dont personne n’a besoin. Toutes deux décrivent le même échec, chacune depuis son extrémité.

Le signe révélateur est simple. Mesurez la part de ce que vous produisez qui remonte à une question que quelqu’un a réellement posée. Si la réponse est gênante, c’est cela, le constat.

Les deux changements qui ont fonctionné

Partir de la question, dans les mots du demandeur. Le sujet ne suffit pas : il faut la question, écrite, avec le nom de la personne qui en a besoin et la date à laquelle il la lui faut. Si elle ne tient pas en une phrase, elle n’est pas prête à recevoir une réponse.

Refuser le travail qui n’est rattaché à rien. C’est le plus difficile, car ce travail est généralement intéressant et toujours plus facile que de découvrir ce dont quelqu’un a réellement besoin. Le produire donne un sentiment de productivité. C’est ce qui occupe une équipe pendant que la valeur se trouve ailleurs.

Nous faisons évoluer le premier échange de nos missions clients vers ce modèle. L’objectif est écrit dans les mots du client, le but est de faire apparaître les lacunes de la conversation tant que le client est encore dans la salle, et le client signe les objectifs confirmés avant que quoi que ce soit ne soit construit. C’est plus lent le premier jour. C’est conçu pour détecter tôt les demandes de changement qui arrivaient autrefois au troisième mois. Le déroulement de ce premier échange est décrit sur la page Engagement et livraison assistés par l’IA.

La conséquence dérangeante

Si vous prenez cela au sérieux, la première phase d’un programme d’IA n’est pas une phase technologique. C’est une période consacrée à découvrir à quelles questions l’organisation cherche réellement à répondre, et lesquelles restent aujourd’hui sans réponse ou reçoivent une réponse trop tardive.

Ce travail n’a rien d’enthousiasmant et se prête mal aux démonstrations. C’est aussi la seule partie du programme qui détermine si quoi que ce soit sera utilisé.

Nous avons mené cet exercice sérieusement, chiffres à l’appui, et le résultat a été pire que prévu.

Avant d’y venir, le prochain article tourne la même discipline vers l’extérieur, vers un changement déjà en consultation qui touchera toutes les entreprises assujetties à la TVA en Afrique du Sud.