Cueillir le fruit avant que le terreau ait pris

Pourquoi l'IA transformante naît dans l'IA pour tous, et nulle part ailleurs

Lors d'une récente avant-vente avec une ETI, l'un des participants a formulé le constat qui revient dès qu'on parle stratégie IA. « Les COMEX veulent du ROI. Sur l'adoption, on peut bien sûr trafiquer les chiffres pour le démontrer, mais ce sera juste artificiel. » Cette mise en garde était d'autant plus juste qu'elle exprimait à voix haute ce que la plupart des sponsors pensent tout bas.

J'ai répondu ce que je crois profondément. Sur l'IA pour tous, le seul KPI honnête est l'adoption. Pas le ROI, pas le temps gagné par utilisateur, pas la productivité estimée — l'adoption. C'est en assumant cette pauvreté apparente du tableau de bord du premier temps qu'on prépare la richesse réelle du second. Parce que l'usage né de l'IA pour tous est ce qui donne naissance, mois après mois, aux cas d'usage d'IA transformante de l'année suivante.

La conviction que je porte ici est qu'on ne peut pas couper ce circuit sans casser le programme entier.

Deux mouvements, pas deux options

Je travaille depuis trois ans au déploiement de l'IA générative dans des grands groupes et des ETI, et je vois revenir la même hésitation à chaque cadrage. D'un côté, une IA pour tous, qui consiste à donner à chaque collaborateur un assistant sécurisé, à créer le réflexe quotidien, à lutter contre le Shadow AI qui prolifère. De l'autre, une IA transformante, qui vise à réinventer un processus métier, à déployer des agents autonomes, à démontrer un ROI mesurable.

Présentées ainsi, les deux semblent s'opposer. L'une serait l'horizontale, l'autre la verticale. L'une viserait l'adhésion, l'autre la performance. L'une coûterait sans rapporter, l'autre prouverait sa valeur. C'est précisément cette opposition que je veux contester.

L'IA pour tous et l'IA transformante ne sont pas deux options stratégiques entre lesquelles arbitrer, ni même deux étapes successives qu'il suffirait de séquencer. Ce sont les deux faces d'une même réalité, celle d'une organisation qui apprend à vivre avec une nouvelle technologie dont elle ignore encore tout du potentiel. Les opposer, c'est essentialiser ce qui est, par nature, en mouvement et pluriel. C'est forcer le programme à choisir entre deux appartenances qu'il a vocation à tenir ensemble.

Le piège du choix prématuré

Sur le terrain, deux dérives symétriques reviennent.

D'un côté, le COMEX qui veut commencer par l'IA transformante, sans passer par l'IA pour tous. La raison est presque toujours la même : la peur du retard, la pression du board, l'impatience d'un sponsor qui veut « ne pas être spectateur de la révolution ». Trois mois plus tard, on se retrouve face à une équipe en train de chercher des cas d'usage artificiels, des automatisations qui ne servent personne, des agents qui tournent à vide, des prouesses techniques que les métiers regardent avec une politesse distante. La bibliothèque des promesses se remplit, l'usage réel reste vide.

De l'autre, l'organisation qui s'installe confortablement dans l'IA pour tous, sans préparer la suite. La plateforme tourne, quelques milliers d'utilisateurs sont actifs, on génère des comptes-rendus de réunion, on rédige des posts LinkedIn, on synthétise des notes, et puis plus rien. Le programme atteint un palier qu'il prend pour un sommet. Les champions s'éteignent doucement, faute d'horizon pour leur effort — un constat qui m'a conduite, plus récemment, à interroger la pertinence des programmes champions à l'échelle.

Les deux dérives se ressemblent plus qu'on ne croit. L'une et l'autre supposent qu'on peut traiter les deux registres séparément. C'est exactement l'erreur. J'ai longtemps cru moi-même qu'une séquence linéaire suffisait, l'IA pour tous d'abord, l'IA transformante ensuite, dans un enchaînement ordonné. Le terrain m'a appris autre chose.

La double maturation qu'on néglige presque toujours

Quand un programme IA fonctionne vraiment, on découvre un mouvement à deux temps que personne ne décrit jamais. Et ce mouvement n'est pas seulement celui des utilisateurs. C'est celui, simultané, des bâtisseurs.

Première maturation, du côté des métiers. Un collaborateur qui n'a jamais touché à l'IA reçoit une plateforme générique. Il s'en empare timidement, l'utilise pour des tâches simples, gagne en aisance. Trois mois plus tard, ses questions changent de nature. Il ne demande plus comment résumer un document, il demande si l'outil pourrait croiser deux référentiels qu'il consulte chaque semaine, l'un juridique l'autre fournisseurs. Cette question, il était incapable de la formuler avant. Il n'avait pas le langage pour. C'est l'usage qui le lui a donné. Et c'est de cette question qu'émergera, plus tard, un cas d'usage d'IA transformante.

Mais il existe une seconde maturation, parallèle et presque inaperçue, du côté des équipes techniques. Pendant que les métiers développent leur réflexe, les équipes tech multiplient les assistants, structurent des bases de connaissances, affinent leur pratique du RAG, expérimentent l'orchestration de premières chaînes simples. Elles montent en compétence sur ce qui paraît modeste avant de pouvoir traiter ce qui est complexe. Quand la demande métier émerge enfin (« ce serait bien si l'outil pouvait, en plus, déclencher cette action »), elles sont en mesure de répondre par un agent, parce qu'elles ont passé six mois à apprendre comment on conçoit, supervise et industrialise un assistant. Sans cette maturation silencieuse, la même demande métier serait restée sans réponse. La technologie aurait existé, mais l'expertise pour la mobiliser, non.

Le programme avance donc sur deux jambes en même temps. Les métiers acquièrent le langage du besoin avancé. Les équipes tech acquièrent la capacité de la réponse avancée. Les deux maturations dépendent du même phénomène, l'usage massif d'une plateforme générique pendant la première moitié du programme. Couper ce phénomène, c'est tuer simultanément les deux jambes.

C'est pourquoi je dis qu'on ne peut pas commencer par l'IA transformante. Ni le besoin ni la capacité ne sont alors disponibles, et aucun raccourci ne les fabrique.

L'architecture en deux temps

Concrètement, qu'est-ce que cela change à la manière de cadrer un programme IA ?

D'abord, dans la priorisation du premier temps. La majorité des efforts, environ soixante-dix pour cent du budget et de l'attention, doit aller à l'IA pour tous : acculturer largement, déployer la plateforme, former les managers, animer une communauté. Mais trente pour cent vont déjà à la préparation de l'IA transformante, et c'est ce qu'on oublie le plus souvent. Ces trente pour cent servent à conduire des interviews terrain, à écouter attentivement les questions qui changent, à cadrer les premiers quick wins, à construire une roadmap pour le temps qui vient. Cette part minoritaire est invisible mais déterminante. C'est elle qui empêche le plateau de confort.

Ensuite, dans le retournement du second temps. On ne passe pas de l'IA pour tous à l'IA transformante en abandonnant la première. On inverse le ratio. Soixante-dix pour cent désormais sur l'IA transformante, sur les agents, les intégrations SI, le pilotage de la valeur. Trente pour cent maintenus sur l'animation de l'IA pour tous, qui continue de produire les remontées et de soutenir l'adhésion.

Enfin, dans la mesure. Un programme IA ne peut pas avoir le même tableau de bord d'un temps à l'autre. Au premier, les bons KPIs sont l'adoption, la couverture, la profondeur d'usage, la diversité des cas remontés. Au second seulement, ils deviennent le ROI, les gains processus, la valeur captée. Confondre les deux phases, c'est demander au premier temps de prouver ce qu'il prépare encore, et au second de continuer à mesurer ce qu'il aurait dû ancrer depuis longtemps.

Refuser le faux choix

Je reviens à la question de mon interlocuteur du début. Il avait raison de craindre les chiffres trafiqués. Personne n'aime un tableau de bord ROI qui sonne creux. Mais sa solution implicite, qui consistait à chercher un ROI coûte que coûte sur l'IA pour tous, ou à s'en passer pour aller directement à l'IA transformante, était le piège dont je voulais le sortir.

Ce qui me frappe, à mesure que j'accompagne ces programmes, c'est que la simplification est toujours en embuscade. Réduire une organisation à des « users » et des « non-users ». Opposer le terrain au COMEX. Choisir entre l'humain et la machine. Et, dans le cas qui nous occupe, séparer en deux ce qui n'est qu'un seul mouvement. Cette tentation de réduire le multiple à un binaire est probablement la plus grande menace qui pèse sur ces programmes. Pas la technologie, pas la résistance au changement, pas même les enjeux juridiques. C'est la tentation de simplifier, par confort intellectuel, ce qui demande à être tenu ensemble.

Et si la première décision stratégique d'un programme IA n'était pas le choix d'une plateforme, mais le refus d'opposer ce qui doit dialoguer ?