ROI de l’IA en entreprise : pourquoi vos meilleurs cas d’usage n’arrivent jamais en production

En 2024 puis en 2025, la direction a obtenu son enveloppe IA. Elle l’a répartie pour que le sujet avance sur plusieurs fronts à la fois : des licences Copilot déployées largement, trois ou quatre POC portés par des équipes différentes, un chatbot interne pour montrer que l’IA générative n’était pas restée un sujet de conférence. Le mot d’ordre était clair : bouger vite, montrer de l’activité sur tous les fronts.

Le COMEX demande maintenant un bilan, pour décider de l’enveloppe 2027. Et le bilan qui se dessine tient en une phrase que personne n’a envie de prononcer en réunion : des expérimentations, zéro production.

Le problème n’est pas l’absence de résultats. Un des POC a convaincu les métiers, au point qu’ils l’utilisent déjà dans leur quotidien. Le problème, c’est que l’enveloppe est consommée, et qu’aucun critère objectif ne permet de dire pourquoi celui-là méritait de continuer plutôt qu’un autre. Le ROI de l’IA en entreprise se juge sur ce genre d’arbitrage, pas sur le nombre de POC lancés dans l’année.

Cette situation touche autant les ETI que les grands comptes. Le contexte change, l’enveloppe change de taille, mais l’arbitrage à faire devant le COMEX reste le même : décider quoi arrêter, quoi poursuivre, et sur quelle base l’affirmer.

ROI IA en entreprise

ROI de l'IA en entreprise : le POC n'est pas encore la preuve

Ce n’est pas un problème isolé. Selon Gartner, au moins 30 % des projets d’IA générative lancés en entreprise seraient abandonnés après la phase de POC d’ici fin 2025, pour quatre raisons principales : une valeur métier mal démontrée, des coûts qui grimpent plus vite que prévu, des contrôles de risque insuffisants, et une qualité de données insuffisante (Gartner, juillet 2024). Le POC prouve qu’une technologie fonctionne dans un cadre contrôlé. Il ne prouve presque jamais qu’elle vaut la dépense nécessaire pour l’industrialiser.

C’est là que le mode de répartition de l’enveloppe IA pose problème. Financer trois ou quatre POC portés par des équipes différentes, en même temps qu’un déploiement de licences et un chatbot interne, donne l’impression de couvrir le sujet sur tous les fronts. Mais chaque POC a été cadré séparément, avec ses propres critères de succès, souvent définis par l’équipe qui le portait. Comparer leur valeur respective devient un exercice presque impossible : l’un a été jugé sur l’adoption, l’autre sur le temps gagné, un troisième sur la simple faisabilité technique.

Résultat : quand l’un des cas d’usage convainc réellement les métiers, au point qu’ils s’en servent sans qu’on les y pousse, personne ne peut dire objectivement s’il mérite plus de budget que les autres, ni combien il en faudrait pour passer en production. L’enveloppe suivante se décide alors sur l’intuition ou sur qui défend le mieux son dossier en COMEX, pas sur des critères partagés.

Ce vide de méthode ne se voit pas au moment où l’on lance les POC. Il se voit au moment du bilan, quand il faut choisir ce qu’on arrête et ce qu’on industrialise, avec une enveloppe qui ne grossit pas au même rythme que les ambitions.

Répartir le budget sur plusieurs équipes répond souvent à une pression réelle : montrer que l’IA avance partout dans l’organisation, pas seulement dans un service pilote. Cette pression n’est pas illégitime. Mais elle a un coût caché, qui n’apparaît que le jour où il faut choisir : plus de cas d’usage lancés en parallèle, moins de méthode commune pour les comparer entre eux.

Cadrer un cas d'usage IA avant de le financer, pas après

Traiter cette situation ne consiste pas à choisir un vainqueur parmi les POC existants. Le vrai chantier commence avant le lancement d’un cas d’usage, pas après.

Un cadrage rigoureux pose les mêmes questions à chaque cas d’usage candidat, quelle que soit l’équipe qui le porte :

  • Quel processus métier change réellement si l’outil fonctionne.
  • Quelles données existent déjà, et sous quelle qualité.
  • Quelles exceptions et quels contrôles s’appliquent aujourd’hui dans ce processus.
  • Quel est le coût estimé pour passer du prototype à un usage quotidien.

 

Posées avant le POC, ces questions permettent de comparer les cas d’usage entre eux sur une base commune, plutôt que sur l’enthousiasme de l’équipe qui les défend.

Sans cadrage commun

Avec cadrage commun

Critères de succès définis par chaque équipe

Critères communs à tous les cas d’usage

Trajectoire de production pensée après le POC

Trajectoire de production pensée dès le cadrage

Cas d’usage impossibles à comparer entre eux

Cas d’usage comparables sur une base partagée

Décision COMEX fondée sur l’enthousiasme

Décision COMEX fondée sur des critères documentés

Le cadrage ne s’arrête pas à la sélection. Il doit aussi documenter, dès le départ, ce que suppose la mise en production : qui doit valider la sortie du prototype, quelles données changent d’échelle, quels contrôles doivent exister pour que la DSI ou la conformité l’acceptent. Sans cette anticipation, le cas d’usage qui a le plus convaincu les métiers reste bloqué exactement au même endroit que les autres, entre le POC et l’usage réel.

Cette comparaison suppose aussi qu’une seule instance porte le cadrage, plutôt que chaque équipe séparément. Un comité resserré, associant la DSI, la direction data et un ou deux sponsors métier, permet d’appliquer la même grille à chaque candidat et d’arbitrer sans revivre le débat à chaque nouveau POC.

Poser ces questions avant de financer le prochain cas d’usage change tout l’exercice du bilan suivant : le COMEX n’arbitre plus entre des impressions, mais entre des dossiers comparables.

Le point de vue JEMS

Chez JEMS, ce cadrage s’appuie sur la méthodologie que nous avons construite au fil des missions d’Architecture Cognitive. Elle interroge cinq composantes clés du cas d’usage, chacune passée au crible de sept champs d’analyse, avant de croiser deux modalités complémentaires pour capter ce qui ne figure dans aucune documentation : les règles que les équipes appliquent sans les écrire, les exceptions qu’elles gèrent de mémoire, les contrôles qu’elles font sans même s’en rendre compte.

Cette rigueur, appliquée avant le lancement plutôt qu’au moment du bilan, change la nature de la question posée au COMEX. On ne demande plus un arbitrage entre des expérimentations disparates. On présente des cas d’usage dont la valeur, les risques et le coût d’industrialisation ont été documentés dès le départ, sur les mêmes bases. Le bilan devient alors un exercice de pilotage, pas un exercice de justification a posteriori.

Le prochain bilan se prépare avant le prochain POC

Le cas d’usage que vos métiers ont adopté sans qu’on les y oblige a déjà fait la preuve la plus difficile à obtenir. Le perdre faute de méthode de cadrage ferait perdre plus qu’un budget : la confiance que les métiers ont commencé à accorder à l’IA.

Le sujet, pour l’enveloppe 2027, n’est pas de trouver plus de budget. C’est de cadrer les prochains cas d’usage avec la rigueur qui a manqué sur ceux d’aujourd’hui.

Si vous préparez ce bilan pour votre COMEX, les équipes JEMS peuvent échanger avec vous sur la méthode de cadrage à mettre en place avant le prochain cycle budgétaire.

PLUS DE RESSOURCES