ROI d'un projet IA : du POC au passage à l'échelle

Le moment qu'on voit le plus souvent en CAC40 et ETI : un DSI prépare un POC IA convaincant, va le présenter pour passer à l'échelle, et se fait renvoyer sur « quel est le ROI précis ? ». La réponse est généralement un chiffre fragile, basé sur des hypothèses optimistes, qui ne survit pas aux questions croisées du DAF, du sponsor métier et de la direction juridique.

Le problème n'est pas la culture financière des DSI — c'est que les projets IA ne se calculent pas comme des projets logiciels classiques. La structure des coûts, la nature des bénéfices, et surtout la temporalité du retour sont fondamentalement différents. Cet article propose une méthode pour construire un business case qui tient devant un comité d'arbitrage exigeant et multi-acteurs.

Le parcours réel : convaincre plusieurs parties prenantes, puis prouver

En grande entreprise, un projet IA n'est jamais arbitré par une seule personne ni en un seul comité. Le parcours typique implique au moins six interlocuteurs aux logiques différentes — et le business case doit pouvoir tenir face à chacun d'eux, sur des critères différents.

Aucun de ces acteurs ne validera un investissement à six chiffres sur la seule base d'une présentation théorique. C'est pourquoi le parcours réel passe quasi-systématiquement par un POC ciblé avant la décision d'investir à grande échelle.

Le POC remplit deux fonctions distinctes que le business case écrit ne peut pas remplir : il prouve la faisabilité technique et la valeur réelle sur votre métier (les benchmarks publics ne suffisent pas), et il aligne les parties prenantes sur une réalité partagée (un sponsor qui a vu un POC fonctionner devient un ambassadeur, pas un sceptique). Les projets qui sautent cette étape pour passer directement au déploiement ont structurellement plus de chances d'être abandonnés ou recadrés en cours de route.

L'ordre rationnel devient donc : cadrage business case léger (pour obtenir le budget POC) → POC sur 6 à 12 semaines avec un périmètre restreint → business case complet basé sur les mesures du POC → décision d'investissement à grande échelle. C'est le seul circuit qui survit à un comité multi-acteurs exigeant.

Que mesurer pendant le POC pour alimenter le business case

Le POC ne sert pas seulement à valider la faisabilité technique : c'est l'instrument qui produit les chiffres réels du business case complet. Pour qu'il joue ce rôle, trois familles de métriques doivent être instrumentées dès le jour 1 du POC, pas a posteriori :

Sans cette instrumentation, le POC se termine sur des sentiments — « ça marche bien », « les utilisateurs sont contents » — qui ne tiennent pas dans une discussion d'arbitrage budgétaire. Avec elle, le POC produit la matière brute du business case, et la conversation au moment de la décision de scale change radicalement de nature : on ne défend plus une projection, on rapporte une mesure.

Pourquoi les méthodes classiques ne marchent pas pour l'IA

Un DAF — ou plus largement un comité d'arbitrage — qui regarde un projet IA avec les outils habituels (TCO + actualisation à 5 ans) va systématiquement sous-estimer le ROI ou conclure à un investissement non rentable. Trois raisons.

La courbe de bénéfices est en J. Sur les 6 à 12 premiers mois, l'IA coûte plus qu'elle ne rapporte : il y a l'investissement initial, le temps d'apprentissage des équipes, les ajustements sur les premiers cas d'usage. Les bénéfices arrivent par paliers, et l'effet réseau (un cas d'usage qui en débloque trois autres) ne se manifeste qu'à partir de l'année 2.

Les bénéfices sont distribués. Une réduction de 30 minutes par jour pour 500 collaborateurs ne se voit nulle part dans la P&L au mois 1. Pourtant à l'échelle annuelle, ça représente environ 55 000 heures à 100% d'adoption ; en appliquant un taux d'adoption réaliste de 40%, il reste ~22 000 heures effectivement libérées, soit l'équivalent de 14 ETP — sous réserve d'une réorganisation effective qui transforme ce temps en capacité supplémentaire ou en suppression de coûts. Les méthodes classiques ne capturent pas bien cette valeur diffuse.

L'option stratégique compte. Construire une capacité IA aujourd'hui n'a pas seulement une valeur opérationnelle ; elle confère une option (au sens financier) sur des cas d'usage futurs qui ne sont pas encore identifiés. Cette valeur est rarement comptabilisée — alors qu'elle peut peser lourd dans le ROI cumulé sur 3 à 5 ans, en particulier sur les briques techniques réutilisables (vector store, pipeline RAG, gouvernance LLM).

Les quatre leviers de valeur d'un projet IA

Avant de calculer, il faut savoir ce qu'on calcule. La valeur d'un projet IA en grande entreprise se décompose presque toujours en quatre leviers, dont les profils de ROI sont différents :

Cadre de valeur d'un projet IA — décomposition utilisée sur les missions de cadrage LityLabs

La formule qui tient sous le feu des questions

La formule que nous utilisons sur les business cases est volontairement simple — l'effort doit être mis dans le sourcing des hypothèses, pas dans la complexité du calcul. Une formule simple est aussi plus défendable face à un comité multi-acteurs : chaque partie prenante peut challenger les hypothèses sur son périmètre sans avoir à décrypter la mécanique.

Le taux d'adoption réel est le poste qu'on oublie le plus. Un POC qui fonctionne à 95% de qualité ne déploie pas à 95% d'adoption. Sur les outils internes en grande entreprise, l'adoption réelle après 12 mois est typiquement de 40 à 70% du périmètre cible. Sous-estimer ce facteur fait gonfler artificiellement le business case et fragilise sa crédibilité face aux parties prenantes financières.

Trois cas concrets avec chiffres réels

Pour ancrer la méthode, voici trois exemples anonymisés tirés de nos missions récentes en grande entreprise :

Cas anonymisés — chiffres arrondis pour préserver la confidentialité client

Ce qu'il faut noter : les payback les plus courts (5 à 6 mois) sont sur les cas d'automatisation et de productivité, pas sur les revenus. Les cas « augmentation revenus » (cas 3) ont un ROI absolu comparable mais un payback plus long et plus incertain — la conversion uplift dépend de variables marché qu'on ne contrôle pas. C'est un arbitrage important pour la priorisation.

Les cinq pièges qui torpillent un business case IA

La méthode complète en six étapes : du cadrage au passage à l'échelle

La séquence à appliquer sur un projet IA, du cadrage au passage à l'échelle. L'ordre compte — chaque étape produit la matière première de la suivante :

• Définir un cas d'usage suffisamment précis — pas « assistant IA pour les RH », mais « assistant qui répond aux 50 questions FAQ les plus posées par les managers, sur la base de 12 procédures internes ». Plus le périmètre est étroit, plus le ROI est mesurable.
• Quantifier le baseline actuel — combien de questions par mois, traitées comment, par qui, avec quel délai et quel coût ? Sans ce point de départ, aucun bénéfice ne peut être objectivé après le déploiement.
• Cadrer le POC — périmètre restreint (un sous-ensemble représentatif), durée 6 à 12 semaines. Surtout : instrumenter dès le jour 1 les trois familles de métriques (qualité, usage, économique) qui alimenteront le business case complet.
• Modéliser les coûts en trois postes distincts — build (one-shot), data (one-shot puis run léger), run récurrent (API, MLOps, gouvernance, supervision humaine). Compter chacun avec une marge d'erreur explicite, et inclure 25 à 40% du build en run annuel.
• Calculer les bénéfices avec le taux d'adoption mesuré pendant le POC — pas estimé, mesuré. C'est ce qui sépare un BC défendable d'une projection optimiste. Appliquer ce taux à la valeur théorique pour obtenir le bénéfice réaliste.
• Construire trois scénarios + jalons de revue partagés — pessimiste (adoption 30%, durée 18 mois pour atteindre le run nominal), central, optimiste. Définir avec les parties prenantes (DAF, sponsor métier, COMEX) les KPIs intermédiaires à 3 et 6 mois qui valideront ou infirmeront la trajectoire. Un BC IA est une promesse à 12-24 mois, pas un contrat figé.

Format type d'une mission de cadrage et déploiement

Pour donner un repère concret de ce que produit un accompagnement externe sur ce sujet :

• Atelier de cadrage — identification des cas d'usage, qualification de la donnée disponible, première estimation des leviers de valeur, design d'un POC ciblé.
• POC de validation — déploiement sur un périmètre restreint, mesure réelle des bénéfices, alignement des parties prenantes autour d'une preuve concrète plutôt qu'une projection.
• Modélisation du business case complet — construction du BC avec les trois scénarios sur la base des mesures POC, défense devant les comités d'arbitrage, ajustements.
• Pilotage post-déploiement — mise en place des KPIs de mesure, revues trimestrielles, re-baselining annuel.

Le sujet recoupe nos expertises GenAI, data engineering et product management — la combinaison nécessaire pour construire un BC qui couvre les volets technique, données et adoption.

Ce qui transforme un BC en succès

Les business cases IA qui passent en COMEX et qui tiennent leurs promesses ont presque toujours trois caractéristiques communes : ils sont calculés sur un périmètre étroit et précis (pas un cas d'usage englobant), ils intègrent un facteur d'adoption réaliste, et ils prévoient des jalons de revue trimestriels. À l'inverse, les BC qui dérapent partagent généralement un défaut : ils ont été calculés sur le scénario optimiste, sans plan de mesure ni scénario de repli.

La bonne nouvelle, c'est que ces écarts sont parfaitement maîtrisables. La méthode existe ; ce qu'il manque souvent, c'est le temps de la déployer rigoureusement. C'est précisément ce sur quoi un cabinet externe peut faire la différence : apporter le cadre méthodologique, pas réinventer ce que vos équipes savent déjà faire.