Programme IA : enquête sur une dynamique en panne

Un programme IA ne produit de ROI qu'une fois mis en cohérence et correctement séquencé : c'est à cette condition que la valeur s'accumule d'un cas d'usage au suivant, au lieu de repartir de zéro à chaque fois. Reste à comprendre pourquoi si peu d'organisations y parviennent.

Dix-huit mois plus tard, la question qui fâche

La scène se passe en comité de direction, dix-huit mois après le lancement du programme IA. Je la raconte de première main, j'y assistais en observateur, invité par la direction de la transformation d'une entreprise de services que je ne nommerai pas ; j'aurais pu être dans dix autres maisons ce trimestre-là, le procès-verbal aurait été le même. La question vient du directeur général et tient en une ligne : qu'est-ce que tout cela nous a rapporté ? Le budget a été voté deux fois, les recrutements sont faits, et il attend un chiffre plutôt qu'un exposé sur les modèles de langage.

La DSI répond avec ce qu'elle a, des capacités : les modèles sont accessibles, la plateforme tient la charge, les gardes-fous de conformité sont posés. Tout est vrai, et rien ne répond à la question, car une capacité n'a de ROI que le jour où un processus métier s'appuie dessus. Les directions métier prennent le relais avec ce qu'elles ont, des cas d'usage : une vingtaine d'identifiés en ateliers, sept qualifiés, deux pilotes qui plaisent aux utilisateurs. Mais en production, à l'échelle, avec un gain mesuré ? Presque rien.

Personne ne ment et personne n'a démérité. La tech a construit, le métier a cherché, et le ROI demandé n'existe nulle part, parce qu'il ne peut naître que de la rencontre des deux et que cette rencontre n'est organisée par personne. On promet un tableau de bord pour le trimestre suivant, et le comité passe au point suivant.

Les indices

Les déclarations des témoins ne se contredisent pas : chacune décrit la moitié d'un trajet en croyant décrire le trajet entier.

Le camp tech raconte un mouvement qui part de la capacité : on construit un socle, on regarde ce qu'il permet, on en tire des cas d'usage réalisables avec ce qui existe déjà. C'est le tech-push, qu'on a tort de caricaturer en gadgétisation, puisqu'il produit une cartographie réelle du possible, établie avec les données et les contraintes de la maison. Le camp métier raconte le mouvement inverse, qui part du besoin : on identifie où se joue la performance de l'entreprise, on en déduit des exigences pour la technologie. C'est le business-pull, tout aussi indispensable, faute de quoi l'IA reste une collection d'améliorations marginales posées sur des processus qu'il aurait fallu repenser.

Tech-push et business-pull ne sont pas deux stratégies concurrentes entre lesquelles il faudrait arbitrer, mais deux demi-arcs du même cercle. Or un demi-arc ne boucle pas, et cette évidence géométrique explique les deux pathologies les plus répandues des programmes IA. D'un côté l'usine à POC : une grande organisation dont le responsable data m'a déroulé l'historique avait aligné une trentaine de démonstrateurs en deux ans, le décompte variait selon mes interlocuteurs car personne ne tenait le registre, tous techniquement réussis, sans en industrialiser un seul. Après le POC, rien n'était prévu. De l'autre la cathédrale : un an de cadrage, une stratégie magnifique, puis la rencontre avec le terrain, où la moitié des cas priorisés supposent des données qui n'existent pas.

Les fausses pistes

Les pistes que j'ai suivies pour rien sont celles que tout le monde suit.

La première pointe vers les données, le suspect qu'on désigne dans tous les post-mortem : la donnée était sale, éparpillée, mal gouvernée. L'accusation est commode parce qu'elle est toujours un peu vraie, aucun patrimoine n'étant irréprochable, mais elle ne tient pas la confrontation avec les faits. J'ai vu une entreprise au patrimoine remarquable, référentiels propres, data office installé de longue date, présenter exactement les mêmes symptômes. La qualité des données détermine la vitesse à laquelle on peut avancer, pas la capacité à aboutir. La piste du sponsoring ne résiste pas davantage, le programme dont je parle étant porté personnellement par le directeur général, et celle des talents non plus, les équipes étant bonnes, ce qui rendait l'échec d'autant plus troublant.

Quand les suspects habituels ont tous un alibi, il faut chercher dans les liaisons entre des composants qui, pris un à un, étaient tous correctement tenus.

La panne est dans les liaisons

Ce n'est dans aucun des quatre quadrants que j'ai fini par trouver la panne. Le socle, les cas d'usage, la transformation, la stratégie : chacun avait son équipe, son budget, ses livrables, et chacun les produisait. Ça se grippe dans les liaisons, ces moments où le mouvement doit passer d'un quadrant au suivant et où, le plus souvent, personne n'est aux commandes. La capacité livrée que le métier ignore, le pilote réussi que personne n'installe dans le quotidien, l'usage réel dont rien ne remonte vers la stratégie : autant de transmissions désertées, précisément parce qu'elles n'appartiennent à aucun des quatre propriétaires.

Un test suffit à établir le constat chez vous : demandez à vos responsables métier ce que votre plateforme sait faire. Le silence qui suit en dit long. Chaque quadrant tournait, et rien ne circulait entre eux ; c'est de cette circulation qu'il faut maintenant parler, car c'est elle, la solution.

La roue

Imaginez maintenant les mêmes quadrants avec quelqu'un aux commandes de chaque transmission. Ce qui apparaît est une roue, et elle change tout.

Premier mouvement, le socle descend vers les cas d'usage : c'est le geste même du tech-push. La plateforme dessine la frontière du faisable, et quelqu'un traduit cette frontière en langage métier. Bien faite, cette traduction révèle des quick wins, des cas à portée de main que le socle existant permet de livrer en quelques semaines, et le métier cesse de demander l'impossible ou de demander ce qu'il demandait il y a deux ans.

Deuxième mouvement, le cas d'usage devient de la valeur, et c'est le plus coûteux à négliger. Un cas d'usage produit un outil ; le transformer en valeur suppose qu'il soit réellement utilisé, ancré dans le quotidien des équipes. Parfois cela passe par une refonte du processus, quand on peut supprimer trois étapes au lieu d'accélérer la quatrième ; le plus souvent, il s'agit de modifier ce qu'on a toujours fait, des gestes professionnels installés depuis des années, avec des craintes légitimes à accompagner. C'est le dernier kilomètre du programme : entre la capacité mappée au besoin réel et l'usage effectif, celui que les collaborateurs pratiquent vraiment, il faut conduire l'adoption et le changement, un chantier que les programmes budgètent rarement à la hauteur de la plateforme. La frontière entre la démo qui impressionne et le quotidien qui change se franchit ici ou jamais.

Troisième mouvement, le terrain remonte vers la stratégie. Un usage qui tourne pour de vrai produit une information que ni la tech ni le métier ne possédaient : des adjacences que personne n'avait vues, des irritants jugés secondaires qui pèsent le double, des cas déclarés prioritaires que les utilisateurs abandonnent au bout de trois semaines. Il renvoie aussi de la demande, puisque des utilisateurs dont le quotidien a changé formulent des besoins qu'ils n'auraient pas su exprimer six mois plus tôt. La stratégie de l'année suivante s'écrit alors avec les hypothèses du terrain, pas avec celles d'il y a deux ans.

Quatrième mouvement, ces besoins redescendent en exigences sur le socle : une capacité à construire, ou un coût unitaire à faire baisser pour rendre éligible ce qui ne l'était pas. C'est là que le prix d'une requête cesse d'être un sujet d'ingénieur. Et la boucle est bouclée : ces capacités nouvelles redessinent la frontière du faisable, le tech-push relancé a de nouveaux quick wins à proposer, la roue entame son tour suivant.

Un tour, pris isolément, n'a rien de spectaculaire. C'est la répétition qui change la nature du système, parce qu'elle laisse des dépôts : des données structurées et des règles métier explicitées, qui font que le troisième cas d'usage d'un domaine coûte une fraction du premier ; des coûts unitaires qui baissent et rouvrent l'ensemble des possibles, puisque des cas écartés hier pour non-rentabilité redeviennent éligibles sans qu'une ligne de leur business case ait changé ; une organisation, enfin, qui a transformé trois métiers autour de l'IA et sait désormais le faire, avec des repères, des relais et des utilisateurs qui ont constaté que ça marchait.

Ce prétendu cercle est donc une spirale : on repasse par les mêmes quadrants sans jamais repasser au même niveau. Ce qui décide de la trajectoire, dès lors, c'est la cadence bien plus que la perfection d'un tour donné. Une organisation qui boucle chaque trimestre avec des ambitions modestes finira loin devant celle qui tente un tour parfait tous les dix-huit mois, parce que ces dépôts se composent dans le temps, comme des intérêts.

La meilleure objection

Tout cela plaide pour des tours modestes et rapides plutôt que pour un grand cadrage préalable. C'est cette conclusion qu'un directeur de la stratégie a contestée devant moi, avec le meilleur plaidoyer pour la cathédrale que j'aie entendu. Démarrer par un cas d'usage étroit, m'a-t-il dit, c'est prendre le risque de construire en silo, un patchwork de solutions locales qu'aucune vision ne relie ; on referait avec l'IA ce qu'on a mis vingt ans à défaire dans les systèmes d'information.

Le risque est réel et je l'ai constaté ailleurs : quand chaque cas se construit dans son coin, avec son stack et ses raccourcis, les premiers tours produisent du jetable. Sur ce point, il a raison, et la conséquence est structurante : le premier cas doit se bâtir sur un socle mutualisé, celui qui portera de tour en tour le cumul des capacités, et toute la spirale dépend de cette discipline du premier tour. Sur le cadre stratégique global, en revanche, l'histoire récente plaide contre lui, chaque cadre que j'ai vu écrire avant tout contact avec le réel ayant vieilli en quelques mois. La vision d'ensemble reste indispensable ; elle s'écrit simplement mieux au deuxième tour qu'avant le premier.

Retour au comité

Revenons au comité du début : tous les ingrédients du ROI étaient sur la table, il manquait la roue qui les transforme en euros.

Alors amorcer par un besoin métier étroit dont la valeur est mesurable avant la première ligne de code, plutôt que par une stratégie complète ou un socle générique. Ne jamais juger un tour sur le POC, car tant que l'usage n'est pas installé dans le quotidien des équipes on tient une démonstration technique et non un cas d'usage. Et admettre l'inconfortable : chaque quadrant a un propriétaire, la DSI, le métier, la transformation, la stratégie, mais les transmissions n'appartiennent à personne, et c'est exactement là que les programmes meurent. Il faut nommer un responsable de la rotation, comptable des tours complets plutôt que d'un quadrant.

La question du ROI reviendra au prochain comité, et c'est une bonne question. Mais ni la liste des capacités livrées ni le portefeuille de cas identifiés n'y répondront. Ce qui y répond, c'est le mouvement. Dans une organisation mûre, on ne compte d'ailleurs plus les tours : les cas d'usage s'engagent en continu, chacun à un stade différent du cycle, et la roue devient un flux où les rotations se superposent et se lissent. Mais avant d'en arriver là, il y a un premier tour complet à boucler, un seul, de bout en bout. Alors le chiffre que le directeur général attendait finira par apparaître, et il se constatera très bien en comité de direction. Il aura simplement été fabriqué ailleurs, dans ces liaisons dont personne ne s'occupe.