Rentabiliser l'IA en entreprise : le problème n'est pas le cas d'usage

Chaque semaine, j’échange avec des dirigeants qui essaient d’intégrer l’IA dans leur entreprise. Et avec d’autres praticiens du sujet : des indépendants, des gens en agence, des responsables IA salariés qui le montent de l’intérieur.

Ils n’ont ni les mêmes clients, ni les mêmes moyens, ni les mêmes contraintes. Sur beaucoup de choses, ils ne sont pas d’accord entre eux.

Il y a pourtant un point sur lequel je ne les ai jamais vus diverger. Et ce n’est pas ce point qui m’intéresse, parce qu’il est devenu un lieu commun. C’est l’explication qu’on en donne. Je crois qu’elle est fausse, et qu’elle coûte cher.

Ce que tout le monde constate

Le retour est toujours le même, et il ne vient pas que de mon entourage. Le CEO de Palantir le disait récemment : pour l’instant, personne n’a réussi à trouver le ROI, ni la manière d’intégrer l’IA efficacement dans les entreprises. Et les rares boîtes qui ont réussi ont commencé à voir un impact sur leur business après un an.

Les chiffres qui circulent racontent la même histoire : une petite minorité des projets IA arrive en production, et là-dessus, à peine un quart a un ROI positif.

Ce que je ne comprends pas, c’est comment il peut y avoir autant de projets qui partent au tapis. Parce qu’aujourd’hui, avec les outils qu’on a, c’est quand même assez facile de déployer des cas d’usage et de s’assurer qu’ils ont du ROI. En tout cas dans une PME. Dans les grands groupes, c’est une autre réalité.

Avec un peu de méthode, ça se fait super bien.

Donc si ce n’est pas difficile et que ça échoue malgré tout, c’est que la question est mal posée.

La question mal posée

La lecture dominante, c’est : personne n’a encore trouvé les bons cas d’usage. Il faudrait chercher mieux, chercher plus, regarder ce que font les autres, et un jour on tomberait sur celui qui débloque tout.

Je ne crois pas à ça. Non pas parce que ces cas d’usage n’existent pas, mais parce qu’on ne rentabilise pas l’IA avec un seul d’entre eux. On la rentabilise avec un ensemble, correctement intégré, qui finit par former un tout cohérent.

Et un tout cohérent, ça ne se trouve pas. Ça se cultive.

La bonne question n’est donc pas « lequel ». C’est « dans quel environnement ». Qu’est-ce que je mets en place pour que les bons cas d’usage apparaissent, qu’ils passent en production, et qu’à la fin ils forment un système et pas un tas.

D’abord, sortir de la vision Jarvis

Avant de parler d’environnement, il faut évacuer ce qui empêche de le construire.

La plupart des gens que je coache pensent encore en IA assistant. Un assistant de plus en plus capable, certes, mais un assistant. Ils imaginent l’agent qui va tout faire, qui va résoudre les choses de manière autonome. Ils ont la vision Jarvis, pas la vision workflow.

Et je suis mal placé pour leur en vouloir, parce que j’en suis revenu moi-même. Il y a encore quelques mois, je pensais plutôt qu’il y aurait des agents pour gérer des périmètres entiers. Plus j’avance, plus je dis non. À la fin, ça reste des workflows. Même s’il y a des agents dedans, ça reste des lignes de production, et il faut être capable de les gérer.

Le vrai changement de posture est là : passer de « comment je fais cette tâche pour résoudre ce problème » à « comment je design un système avec l’IA pour que l’IA résolve le problème ».

Tant que quelqu’un n’a pas fait cette bascule, il peut connaître tous les derniers modèles et tous les derniers outils, il produira des automatisations isolées qui ne s’additionnent jamais.

Le bon cadre : l’entreprise comme un ensemble de lignes de production

Je vois de plus en plus les entreprises comme un ensemble de lignes de production, vraiment au sens industriel du terme. Avec un point de départ, une arrivée, un livrable.

Le premier travail, c’est de les nommer, service par service. Quels sont les livrables de chacun, quels sont les process. Et ensuite seulement : comment je mets en place la ligne.

Une ligne de production, ce n’est jamais une seule technologie. C’est un mélange de trois choses :

• des workflows, des scripts, des choses qui tournent en back-office ;
• de l’IA, sous forme de skills ou d’agents ;
• des étapes humaines, de vérification ou de production.

Et le point important : ce n’est pas parce qu’il y a de l’IA et des agents impliqués que ce n’est plus une ligne. Un agent qui exécute un workflow, qui exécute des tâches précises, reste du process. Le suivi est un peu plus délicat, mais avec les outils d’observabilité d’aujourd’hui, on le fait de mieux en mieux.

Ce qui définit une ligne, ce n’est donc pas ce qui la compose. C’est qu’elle suit des étapes, qu’on sait quand elle se déclenche, dans quelles conditions, quel est son résultat, et qu’on est capable de la monitorer.

Les seules exceptions sont les assistants personnels et les agents de knowledge : ceux qu’on branche sur des documents ou une base de données, à qui on pose des questions, et qui répondent. Là il n’y a que de la lecture, pas d’action. On peut donc se permettre un cadre beaucoup plus léger.

Tout le reste, tout ce qui agit sur des sujets transverses dans la boîte, doit être une ligne.

Le mécanisme qui fait émerger : séparer le proto de la production

C’est ici que se joue, à mon avis, l’essentiel de l’écart entre les boîtes qui y arrivent et celles qui accumulent des projets morts.

Je différencie la phase de proto de la mise en production. Parce que si on fait passer un proto par la ligne classique et par toutes les contraintes qu’elle impose, ça ne va pas être très intéressant. On tue l’exploration avant d’avoir su si l’idée valait quelque chose.

Aujourd’hui, un proto se fait en une demi-journée. On valide ses hypothèses, on regarde avec les équipes métier si ça vaut le coup. Et une fois cette validation obtenue, alors seulement on se dit : d’accord, maintenant ça fonctionne, il y a du ROI, comment je transforme ça en ligne de production. Et là, c’est un autre sujet.

L’ordre compte. Beaucoup de gens construisent d’abord et regardent ensuite si ça tient. C’est l’inverse.

Une fois le proto validé et le ROI vérifié, on passe la main à l’équipe qui maîtrise la stack et qui s’assure que ça s’intègre au reste. C’est ce relais qui fait qu’à la fin on a un ensemble, et pas une collection.

Ouvrir les chakras avant de demander des idées

Il reste un problème : d’où viennent les idées.

J’ai intégré un process d’audit qui marche plutôt bien. Je passe deux fois deux heures avec chaque responsable, sur son quotidien réel. Je pars de ses responsabilités, puis de ses missions, puis assez vite de sa stack et des outils qu’il manipule, puis de ses livrables : ce qu’il doit produire chaque mois. Et je lui montre comment j’effectuerais ces tâches à sa place.

Deux choses m’ont frappé en procédant comme ça.

La première, c’est que même des gens qui pensent déjà bien utiliser l’IA ont encore un gap monstrueux sur ce qu’ils peuvent aller chercher. J’ai coaché des personnes dont c’est le métier et qui n’avaient pas poussé la réflexion jusque-là, simplement parce qu’elles sont dans la production et qu’elles n’ont jamais pris le temps d’aller plus loin. Ce n’est pas une question de compétence. C’est une question de temps et d’exposition.

La seconde, c’est que les interviews sur l’IA ne servent pas à grand-chose. Quand on interroge les gens dans l’abstrait, ils oublient plein de choses de base, et surtout ils n’imaginent pas ce que l’IA est capable de produire, donc ils ne donnent pas les bonnes informations. Là où s’asseoir et exécuter ensemble permet de se rendre compte de ce qui est réellement possible.

L’objectif de ces heures est triple : comprendre comment la boîte fonctionne, libérer du temps aux responsables parce que c’est avec eux que je vais travailler ensuite, et ouvrir leur vision de ce que l’IA peut faire pour qu’ils soient les plus moteurs possible.

Ce sont eux qui connaissent leur métier. Mon travail, c’est de les mettre dans le bon état d’esprit pour qu’ils proposent les meilleures idées.

La thèse : vision, cadre, autonomie, convergence

Je suis un peu revenu de la cartographie exhaustive de tous les process. C’est long, c’est cher, et le résultat est périmé avant d’être fini.

Ce qui compte, dans l’ordre :

Une vision de la façon dont la boîte va opérer demain. Pas une liste de projets. Une image de la cible.

Un cadre en termes de gouvernance et de stack. Voilà comment fonctionne notre gouvernance, voilà nos outils.

Et ensuite, l’autonomie. On laisse les équipes construire leurs cas d’usage au fur et à mesure.

Si le cadre et la vision sont bien posés, ce sont plein de petites briques qui se rajoutent, et qui sont censées converger vers ce mode de fonctionnement. Je ne dis pas que c’est facile à faire. Mais c’est ça, le mécanisme.

C’est l’inverse d’un plan. Un plan désigne les cas d’usage à l’avance et se trompe. Un environnement bien posé en produit qu’on n’avait pas prévus, et qui tiennent ensemble.

Mais l’émergence ne veut pas dire le laisser-faire

C’est le point où beaucoup vont mal m’interpréter, alors je le pose net : les bons cas d’usage n’apparaissent pas tout seuls. Ils apparaissent parce que quelqu’un cultive le terrain.

Dans une équipe de huit ou neuf personnes dédiées à l’IA, il peut très bien y en avoir deux dont le seul travail est de passer du temps avec les autres, de repérer les bons cas d’usage et d’identifier ceux qui méritent d’être promus en production.

Ce n’est pas une fonction de contrôle, c’est une fonction de récolte. Parce qu’on ne peut pas suivre chaque initiative : le rôle d’un responsable IA est d’outiller les équipes, pas de piloter chacun de leurs projets.

Et il y a une raison de fond à ça. Un des grands changements culturels qui arrive, c’est que le nombre d’initiatives, de projets et d’itérations dans les boîtes va juste exploser. Que ce soit au marketing, aux ventes, partout. Les meilleures équipes commerciales des grosses startups ont aujourd’hui des playbooks quasiment à la semaine, avec des indicateurs à la semaine, là où avant ça se pilotait au trimestre.

Dans ce régime-là, un comité qui valide les cas d’usage un par un devient le goulot. Ce qui est utile n’est plus de décider, c’est de rendre possible et de récolter.

L’infrastructure minimale

Trois briques, et elles sont moins coûteuses qu’on ne le croit.

Un second cerveau d’entreprise, qui est un index et non un entrepôt

C’est la partie que je vois le plus souvent mal comprise, et la plus rentable.

Dans le second cerveau d’une boîte, on ne range ni les documents ni les informations elles-mêmes. On y range une seule chose : où chaque information se trouve.

Concrètement, on y met :

• les process par département, avec les skills associés. Les process, c’est ce que font les gens. Les skills, c’est ce que fait l’IA. Et dans un process, il peut y avoir des skills.
• le contexte général de la boîte : qui sont les clients, quelles sont les offres, quelle est l’histoire.
• la cartographie de la stack, avec une fiche par outil. Une fiche pour le Drive, qui explique comment il est organisé, quel dossier contient quoi, quelles conventions s’appliquent. Une fiche pour le CRM, avec les siennes. Et ainsi de suite.

Ce qu’il ne faut surtout pas faire, c’est venir y emmagasiner du contexte. On veut qu’il reste léger. C’est le réseau de neurones qui connecte tout l’écosystème, et la porte d’entrée vers le reste de la boîte, pour que chaque personne qui utilise l’IA parte du même contexte.

C’est aussi comme ça qu’on mutualise plus de process, plus de standards dans l’usage de l’IA, et plus de structure au final. C’est un multiplicateur de productivité pour tout le monde, quel que soit le niveau de chacun en IA. Et une version 1 se met en place assez vite, avec les outils que la boîte a déjà.

J’ai consacré un webinaire entier à ce sujet, et le guide complet est en ligne : le second cerveau d’entreprise.

Une gouvernance qui est un cadre, pas une étape

La gouvernance relève du cadre, pas du process. Ce que je veux dire, c’est que ce n’est pas une étape numéro 5 dans un pipeline, à laquelle les équipes doivent penser. Elle est intégrée dès la conception dans la manière dont elles opèrent.

Si quelqu’un monte un flux d’automatisation, il existe une façon de le faire, une organisation des dossiers, des règles d’accès. C’est présent à toutes les étapes, et pas seulement à une.

On m’a demandé si les gens allaient vraiment respecter ça. Justement : l’intérêt, c’est qu’ils n’aient pas le choix. Une gouvernance qu’on peut oublier n’en est pas une, c’est une case à cocher.

Quelqu’un dont le travail est de maintenir

Je me renseigne pas mal sur le fonctionnement de l’industrie. On y trouve des postes dédiés à la maintenance, et même à l’amélioration continue : les lignes qui tournent, comment on peut les rendre meilleures.

Dès qu’une équipe atteint une certaine taille, il est beaucoup plus simple de confier l’entretien à une ou deux personnes plutôt que de renvoyer chacun vers ce qu’il a construit. Ce n’est pas seulement une question de charge : ça force une passation, et donc la documentation reste à jour.

Et plus il y a de lignes en service, plus le monitoring compte. Il devient un sujet à part entière, sur lequel il faut construire des choses.

C’est le point que presque personne n’anticipe. On pense au build, jamais au run. Or chaque ligne mise en service ajoute une charge permanente. Une équipe qui ne prévoit personne pour ça voit sa capacité à en produire de nouvelles se dégrader toute seule, sans que rien n’ait changé.

Ce qu’on mesure vraiment : de la capacité, pas des économies

Reste la question qui a lancé tout ça : comment on sait que c’est rentable.

Ce dont je suis de plus en plus clair avec mes clients, c’est que je leur redonne de la capacité, plus que je ne leur fais faire des économies.

C’est tentant de prendre un taux horaire, de le multiplier par le temps gagné et d’annoncer une économie. Sauf que dans 80 % des cas, personne ne va licencier la personne. Elle va faire autre chose.

Le cadrage en capacité récupérée est plus proche de la réalité. Et surtout, il oblige à poser la vraie question : dans quoi est-ce qu’on réinvestit ce temps.

Ce n’est pas la responsabilité de l’équipe IA. C’est celle de la direction, ou de chaque service. Mais c’est un sujet sur lequel l’équipe IA peut éduquer : nous, on va vous faire gagner du temps, il faut que vous ayez des initiatives pour exploiter cette nouvelle capacité.

C’est là que la boucle se ferme. Une boîte qui libère du temps sans savoir quoi en faire ne rentabilise rien : ce temps se dissout. Une boîte qui sait comment elle veut fonctionner demain sait exactement où le remettre. C’est la même vision qui fait converger les cas d’usage et qui rend le temps gagné mesurable.

Ce que je retiens

Chercher le bon cas d’usage, c’est chercher la bonne pièce sans avoir d’atelier.

Ce qui manque aux entreprises pour rentabiliser l’IA, ce n’est pas une idée. C’est un environnement : une vision de la façon dont on va opérer, un cadre de gouvernance et d’outils, de l’autonomie donnée aux équipes, deux ou trois personnes qui récoltent et promeuvent, un second cerveau qui indexe, et quelqu’un qui entretient.

Posez ça, et les cas d’usage arrivent. Ils viennent des gens dont c’est le métier, ils passent en production parce qu’il existe un chemin pour ça, et ils finissent par former un système.

Ne le posez pas, et vous aurez ce que le marché a aujourd’hui : beaucoup de projets, très peu en production, et presque aucun rentable.

---

On en parle deux heures ?

Si vous êtes dirigeant, ou responsable dans une entreprise de 5 à 200 salariés, je vous offre deux heures de travail sur votre quotidien réel. Pas une présentation : on s’assoit, on prend vos sujets, et on construit ensemble. Focus total sur vous, zéro pitch.

Prendre rendez-vous