Un comité d’investissement valide 400 000 € pour un projet d’IA. Sur le slide de décision, une ligne : « +30 % de productivité ». Personne ne demande sur quelle tâche, mesurée comment, à partir de quel point de départ. Dix-huit mois plus tard, personne ne saura dire s’il a rapporté quoi que ce soit : on n’a jamais défini ce qu’on regardait. Ce scénario, nous le voyons presque à chaque audit.
Disons-le franchement : la plupart des ROI d’IA présentés en comité sont des fictions. Pas des mensonges. Des fictions. Un chiffre rond, tiré d’un cas d’usage idéal, jamais confronté à la production. Un calcul qui tient debout demande l’inverse : une métrique reliée à de l’argent réel, une mesure prise avant, et l’honnêteté de compter tous les coûts.
« +30 % de productivité » ne veut rien dire
Un gain de productivité n’est pas une valeur tant qu’il n’est pas converti en coût évité ou en revenu gagné. Trente pour cent de temps économisé sur une tâche que personne ne facture, et qui n’est pas le goulot de l’équipe, c’est zéro euro au compte de résultat. Le temps « gagné » qui se dilue en réunions n’a jamais réduit une facture.
Première décision, donc : la métrique. Elle doit relier le projet à un coût ou un revenu que la direction financière reconnaît déjà. Quelques candidates solides :
- Heures économisées valorisées : seulement si elles deviennent des postes non remplacés, des intérimaires en moins, ou une capacité réaffectée à un travail facturable.
- Taux de traitement automatique (la part des cas qui vont de bout en bout sans intervention humaine) : directement lié au coût par dossier.
- Taux d’erreur : quand une erreur a un prix connu (avoir, retard de paiement, pénalité, reprise).
- Délai de traitement : s’il débloque du chiffre d’affaires ou réduit un besoin en fonds de roulement.
- Churn : si vous savez chiffrer la valeur d’un client retenu.
Une métrique, pas cinq. Reliée à l’argent, pas au confort. Si vous ne savez pas écrire « 1 point de cette métrique = X euros », vous n’avez pas un calcul de ROI. Vous avez une intention.
Pas de baseline avant, pas de ROI après
C’est l’erreur la plus coûteuse, et la plus banale. On déploie, puis on cherche à prouver le gain. Sans mesure prise avant, le « après » n’a rien à quoi se comparer, et l’estimation rétrospective penche toujours du côté de celui qui a porté le projet.
La baseline se mesure sur le terrain, pas dans une procédure. Combien de factures par mois, vraiment ? Combien passent en exception ? Combien de temps un comptable y consacre-t-il en réalité, reprises et relances comprises ? Prenez-la sur plusieurs semaines pour absorber la saisonnalité, avant la première ligne de code. Une baseline prise après le démarrage est un souvenir reconstitué.
La check-list des coûts que tout le monde sous-estime
Le dénominateur du ROI, c’est le coût total. Et c’est là que les calculs se dégonflent. Le build n’est presque jamais le poste principal sur la durée. Ce qu’un calcul honnête doit inclure :
- Build : conception, développement, intégration au SI. Le seul poste que tout le monde compte.
- Tokens et inférence : le coût par appel, multiplié par le volume réel. Négligeable en démo, significatif à l’échelle.
- Données : collecte, nettoyage, étiquetage, mise en qualité. Souvent le poste le plus lourd, et le plus oublié.
- MLOps / LLMOps : hébergement, supervision, jeux d’évaluation, pipelines de déploiement.
- Maintenance : un modèle dérive, un fournisseur change d’API, un prompt casse. Comptez une charge récurrente, pas un coût ponctuel.
- Conduite du changement : formation, accompagnement, refonte des processus. Sans elle, l’adoption stagne et le gain reste théorique.
- Coût caché des corrections humaines : le temps passé à relire, corriger, rattraper les sorties du système. Un système qui automatise 80 % des cas mais dont chaque sortie doit être vérifiée ne fait pas économiser 80 % du travail — souvent de quoi diviser le gain affiché par deux.
Attention aussi au coût unitaire à l’échelle. Un pilote sur 200 dossiers ne dit presque rien du coût à 50 000 : les coûts variables (inférence, vérification humaine, support) montent linéairement, parfois plus vite quand les cas limites se multiplient. Raisonnez en coût par unité traitée, à volume cible. C’est là aussi que se jouent les arbitrages : un modèle plus petit, une mise en cache ou un traitement par lots divisent le coût d’inférence sans toucher à la valeur. Invisibles en POC, ils décident de la rentabilité.
Gain théorique contre gain réalisé
Entre le gain calculé sur tableur et le gain qui arrive au compte de résultat, deux filtres s’intercalent. L’adoption : un outil utilisé par 40 % de l’équipe ne livre pas 100 % du bénéfice, et c’est presque toujours le cas la première année. La reprise humaine : la part des cas que le système renvoie à un humain, par prudence ou par incapacité. Un taux d’automatisation de 70 % qui tombe à 55 % une fois les garde-fous activés, c’est un quart de la valeur attendue qui disparaît.
Un calcul honnête présente donc une fourchette, pas un point : gain théorique en haut, gain réalisé attendu en bas, après des hypothèses d’adoption et de reprise que vous assumez. Puis on le met à jour avec les chiffres réels, une fois le système en service. Le ROI n’est pas une promesse faite au lancement. C’est une mesure qu’on suit dans le temps.
Un exemple chiffré : l’automatisation des factures fournisseurs
Des ordres de grandeur pour illustrer la mécanique, pas une étude de cas. Une entreprise traite environ 30 000 factures fournisseurs par an. Baseline mesurée : 8 minutes de travail humain par facture en moyenne, soit à peu près 4 000 heures annuelles, valorisées disons 35 € l’heure chargée, autour de 140 000 € de coût de traitement par an.
Objectif : automatiser l’extraction et le rapprochement, viser un taux de traitement automatique de 70 %. Sur le papier, 70 % de 140 000 €, c’est près de 100 000 € de gain annuel. Le gain théorique. Reste à le passer dans les filtres du réel.
- Le taux réel se stabilise plutôt à 55 % les premiers mois (cas limites, fournisseurs aux formats exotiques).
- Les 45 % restants demandent une intervention, et 10 % environ des cas « automatisés » sont relus par sécurité.
- Gain réalisé estimé : plutôt 60 000 à 70 000 € par an, pas 100 000 €.
En face, les coûts. Build et intégration : disons 120 000 € la première année. Récurrent annuel (inférence, hébergement, supervision, maintenance, conduite du changement) : de l’ordre de 30 000 €. Première année : 65 000 € de gain pour 150 000 € de coût, donc négative, c’est normal. Sur 3 ans : environ 195 000 € de gains cumulés pour 210 000 € de coûts. Le projet est à l’équilibre, pas le triomphe annoncé — l’information utile pour décider, bien plus que le « +30 % » du slide.
Horizon, seuil de décision, et quand tuer un projet
Fixez l’horizon avant de lancer, pas après avoir vu les chiffres. Pour la plupart des cas d’usage IA en entreprise, 2 à 3 ans est raisonnable : assez long pour absorber le build, assez court pour qu’un fournisseur ou un modèle ne rende pas la solution obsolète. Au-delà de 4 ou 5 ans, vos hypothèses de coût d’inférence ne valent plus rien.
Définissez aussi le seuil de décision en amont : quel niveau de gain réalisé, à quelle date, justifie de continuer, d’étendre ou d’arrêter. Et donnez-vous le droit de tuer. Un projet qui plafonne loin sous son objectif, dont l’adoption ne décolle pas ou dont le coût de correction annule le gain, doit être arrêté. L’arrêter tôt n’est pas un échec : c’est de la discipline. Le vrai gâchis, c’est le projet qu’on garde sous perfusion budgétaire parce que personne n’ose dire tout haut qu’il ne rapporte rien.
Un ROI défendable n’est jamais un chiffre rond annoncé au comité. C’est une métrique reliée à l’argent, une baseline prise avant, tous les coûts comptés, et une fourchette qu’on ajuste avec le réel. Si vous cadrez un projet sur ces bases, notre offre diagnostic & cadrage pose l’état des lieux et le calcul en quelques jours, et le guide Feuille de route IA & ROI détaille la méthode de priorisation.