La plupart des initiatives d’IA s’arrêtent au pilote. En général, le modèle n’y est pour rien : c’est que rien ne relie un résultat produit par l’IA à une décision dont quelqu’un accepte de répondre.
Toutes les organisations parlent d’IA. La plupart des initiatives d’IA ne dépassent jamais l’atelier, la preuve de concept et le pilote isolé.
On attribue généralement cet échec à la technique. D’après notre expérience, la technique n’est pas en cause. La capacité existe. Ce qui manque, c’est un mécanisme qui transforme un résultat produit par l’IA en une décision que quelqu’un est prêt à signer de son nom.
Voilà l’écart, et il est d’ordre organisationnel.
Quatre mots, à prendre au pied de la lettre.
L’IA recommande. L’humain décide.
Cela ressemble à une déclaration de prudence ; c’est en réalité une contrainte de conception. Si une personne doit assumer la décision, la recommandation doit lui parvenir dans un état qui rend cette responsabilité possible. Elle doit voir d’où vient la recommandation, sur quoi elle repose, ce qui a été écarté et ce qui se passe si elle est fausse. Une recommandation que l’on ne peut pas interroger ne peut pas être assumée : elle sera donc ignorée, et une recommandation ignorée n’a aucune valeur, si bonne soit-elle.
Concevoir dans cette optique change ce que l’on construit. Le système doit montrer son raisonnement, et il doit pouvoir dire quand il n’est pas sûr. L’aisance de la formulation vient en dernier.
En pratique, ce sont les parties ingrates qui se révèlent les plus coûteuses. L’essentiel du développement n’a pas porté sur l’appel au modèle. Il a consisté à faire en sorte que chaque réponse porte les identifiants des documents dont elle s’inspire, pour qu’un relecteur puisse les ouvrir en un clic, et à faire en sorte que la réponse ne renvoie rien quand l’ancrage documentaire fait défaut. C’est ce second comportement qui fait débat chez les ingénieurs, car un système qui refuse parfois de répondre est plus difficile à démontrer, et auquel on fait bien plus facilement confiance.
Un savoir institutionnel que l’IA peut réellement lire. Un référentiel de ce que l’organisation a livré, décidé et appris, suffisamment à jour et structuré pour qu’une réponse s’appuie sur lui, et non sur des connaissances générales tirées de l’internet ouvert. Nous avons expliqué pourquoi ce chantier devait passer en premier, et c’est toujours celui que la plupart des organisations sautent.
Un circuit gouverné de l’exigence au travail. Des exigences approuvées qui deviennent un travail structuré et actionnable sans que le contrôle se perde en route. Ici, la valeur de l’automatisation ne tient pas à la vitesse de génération. Elle tient au fait que le même chemin est suivi à chaque fois, si bien que l’on peut reconstituer ensuite ce qui s’est passé.
Un socle d’ingénierie cohérent. Des schémas communs pour la qualité, la sécurité, la gestion multilocataire et la reproductibilité, afin que ce qui est construit soit reconnaissable pour l’ingénieur suivant et se comporte comme ce qu’a construit le précédent. La cohérence n’a rien de spectaculaire, et c’est elle qui rend la réutilisation possible.
Chacun de ces éléments a une valeur propre. S’il faut les trois, c’est qu’ensemble ils forment un chemin qui va d’une idée à un livrable, avec une personne responsable à chaque passage de relais.
Sur nos propres missions, ces trois éléments portent un nom. Le savoir institutionnel, c’est notre Intelligence Hub ; le circuit gouverné de l’exigence au travail, c’est the Hive ; le socle d’ingénierie, c’est nVisionIT.Framework. Ce que chacun a le droit de faire dans une mission client, et l’endroit où une personne signe, sont décrits à la page Engagement et livraison assistés par l’IA. Les organisations qui construisent le même chemin en interne commencent généralement par une plateforme d’agents IA d’entreprise ancrée dans leurs propres documents.
C’est à ce stade qu’un article de ce genre promet généralement trop, aussi le paragraphe suivant est-il volontairement restreint.
Le cadre est conçu pour qu’une proposition s’appuie sur le travail de réalisation que l’organisation a déjà accompli, et non sur les souvenirs de quelqu’un. Pour qu’une décision soit prise sur la base d’informations qu’un relecteur peut ouvrir et vérifier. Et pour que ce qui est construit suive des standards qui ont déjà fait leurs preuves en production. Ce sont des intentions de conception, et elles sont raisonnables.
Savoir si elles ont produit une différence mesurable est une autre question, qui appelle une autre réponse, et cette réponse exige des chiffres. Des adjectifs n’y suffisent pas. Nous le mesurons, les résultats ont remis en cause certaines de nos hypothèses, et les derniers articles de cette série exposent ce que nous avons constaté. D’ici là, nous préférons décrire ce que le dispositif est conçu pour faire et ne pas revendiquer des résultats que nous n’avons pas encore formulés avec précision.
Cette distinction mérite d’être reprise. Un fournisseur qui décrit un cadre vous parle de conception. Un fournisseur qui décrit un résultat doit pouvoir vous dire ce qui a été mesuré, sur quelle période et par rapport à quelle référence.
Le succès ne dépend pas du modèle que vous choisissez. Les modèles changent tous les deux ou trois mois, et ce choix vieillit plus vite que presque toutes les autres décisions que vous prendrez.
Il dépend de la possibilité, pour quelqu’un, de vérifier d’où vient une recommandation, puis de sa volonté d’agir sur cette base. C’est une question qui porte sur la façon dont l’organisation est construite. Savoir quel fournisseur a pris l’avantage ce trimestre n’y change rien.
Ce qui fonctionne, c’est une répartition claire entre ce que fait la machine et ce que fait la personne, sans que personne ne confonde les deux. Il n’a jamais été question de remplacer la personne. L’objectif a toujours été d’élargir le champ dont une seule personne peut raisonnablement répondre.
Le prochain article de cette série sort de notre propre expérience pour examiner ce que disent les travaux publiés : tout cela se traduit-il dans les résultats des entreprises ?
Fait partie de la série Insights. Recevez les nouvelles analyses par e-mail ou suivez le flux RSS.
Deuxième volet sur trois. Nous avons comparé ce que nous avions produit à ce qui nous avait réellement été demandé. Une grande part ne correspondait à aucune question, et cela a changé notre façon de choisir sur quoi travailler.
Premier volet d’une série de trois. Nous pensions que produire davantage créerait davantage de valeur. Mesurer les résultats et non l’activité a changé ce que nous pensions, et la principale leçon s’est révélée ne pas concerner l’IA.
La première correction de notre démarche IA n’avait rien à voir avec l’IA. Le savoir d’une organisation est généralement dispersé, non daté et contradictoire, et un modèle qui s’en nourrit répondra avec assurance, et à tort.
