Mesurer le ROI d'un projet IA

Le ROI d’un projet IA n’a rien de mystérieux. C’est une soustraction : ce que vous gagnez moins ce que vous dépensez. La difficulté n’est pas dans le calcul, elle est dans l’honnêteté des chiffres qu’on y met.

Trois statuts à ne jamais confondre

Tout chiffre présenté doit porter son origine.

DÉCLARÉ — le client l’a fourni. « Ça nous prend environ dix minutes. » C’est une information de première main, mais c’est une impression, rarement chronométrée.

ESTIMÉ — dérivé d’hypothèses. « Si on réduit de moitié, cela représente huit heures par mois. » Le chiffre est calculé, mais il repose sur une hypothèse de réduction qui n’a encore rien prouvé.

MESURÉ — observé après implémentation. C’est le seul qui vaut quelque chose pour décider de continuer ou d’arrêter.

Un rapport qui affiche « 9 600 € économisés par an » sans préciser lequel des trois statuts s’applique n’est pas un rapport. La plupart du temps, il s’agit d’un chiffre estimé présenté avec l’assurance d’un chiffre mesuré.

La situation de départ

Sans point de départ chiffré, il n’existe aucun progrès démontrable. Quatre données suffisent le plus souvent :

volume mensuel
minutes par occurrence
coût horaire chargé
coût mensuel actuel = volume × minutes ÷ 60 × coût horaire

Un exemple concret. Cent dossiers par mois, dix minutes chacun, trente-cinq euros de l’heure :

100 × 10 ÷ 60 = 16,7 heures par mois
16,7 × 35 = 583 € par mois

Voilà ce que coûte cette tâche aujourd’hui. Tout le reste s’apprécie par rapport à ce nombre.

Le coût horaire ne s’invente pas. Ce n’est pas le salaire brut : c’est le coût chargé, charges patronales comprises. Si vous ne le connaissez pas, posez une hypothèse explicite et affichez-la comme telle — ne la dissimulez pas dans le résultat.

Selon les cas, deux données supplémentaires comptent autant : le taux d’erreur et le taux de reprise. Une tâche rapide qu’il faut refaire une fois sur cinq coûte bien plus que son temps unitaire.

Les coûts que tout le monde oublie

Le coût d’un projet IA n’est jamais le seul abonnement mensuel à l’outil. Il faut compter :

la mise en œuvre — temps de conception, de paramétrage, de tests ;
les abonnements logiciels et la consommation d’API, qui croît avec le volume ;
la validation humaine — si un humain relit chaque sortie, ce temps ne disparaît pas du calcul ;
la formation des personnes concernées ;
la maintenance — un système qui n’est plus entretenu se dégrade ;
la migration des données existantes ;
le coût de sortie, si vous décidez un jour de changer d’outil.

C’est souvent la validation humaine qui fait basculer un business case. Un système qui produit un brouillon en trois secondes mais demande quatre minutes de relecture n’économise pas dix minutes : il en économise six.

Valeur nette et délai de rentabilité

La valeur nette est le gain brut moins le coût récurrent :

heures économisées = heures actuelles × taux de réduction
valeur brute = heures économisées × coût horaire
valeur nette = valeur brute − coût récurrent mensuel

Puis :

délai de rentabilité = coût de mise en œuvre ÷ valeur nette mensuelle

Reprenons l’exemple. Réduction estimée entre 40 % et 70 %, coût de mise en œuvre 1 200 €, outil à 60 € par mois :

	Hypothèse basse	Hypothèse haute
Heures économisées / mois	6,7	11,7
Valeur brute	233 €	408 €
Valeur nette	173 €	348 €
Rentabilisé en	6,9 mois	3,4 mois

Toujours présenter une fourchette. Un chiffre unique masque une incertitude qui est bien réelle, et il se retournera contre vous le jour où le résultat tombera dans la partie basse.

Et si la valeur nette est négative ou nulle, le projet ne se rembourse jamais dans ces hypothèses. Ce n’est pas un échec du calcul, c’est son utilité : il vient de vous éviter une dépense.

Le calcul appartient au logiciel, pas au modèle

Un modèle de langage est mauvais en arithmétique et excellent pour formuler des hypothèses plausibles. La bonne répartition est donc :

le modèle propose les hypothèses de volume, de temps unitaire, de taux de réduction, et explique son raisonnement ;
le code calcule, de façon déterministe et vérifiable.

Un chiffre produit par un modèle de langage n’est pas reproductible. Sur un business case que vous allez présenter à un associé ou à un banquier, c’est rédhibitoire.

Déployé n’est pas validé

C’est le point que la plupart des projets manquent. Un système mis en production n’est pas un système qui a fonctionné. Il l’a fait quand les mesures le montrent.

Après implémentation, collectez :

le temps réel passé, maintenant ;
le coût réel, abonnements et API compris ;
l’adoption — combien de personnes l’utilisent vraiment, et à quelle fréquence ;
les erreurs et les corrections humaines nécessaires ;
le résultat business visé au départ ;
les incidents et les surprises.

L’adoption est la mesure la plus révélatrice. Un outil parfait que personne n’ouvre a une valeur strictement nulle, quel que soit le calcul initial.

Trois issues sont possibles, et les trois sont valides : étendre, ajuster, ou arrêter. Un projet arrêté après mesure n’est pas de l’argent perdu — c’est de l’argent qu’on cesse de perdre.

Ce qui ne se chiffre pas toujours

Certaines valeurs sont réelles sans être monétisables proprement : qualité de décision, réduction du risque, capacité à absorber un pic sans embaucher, pénibilité en moins.

Il est parfaitement légitime de les faire entrer dans une décision. Il ne l’est pas de leur attribuer un montant inventé pour faire tenir un business case. Nommez-les, expliquez pourquoi elles comptent, et laissez-les hors du calcul.

Metriva calcule le ROI en code, pas avec un modèle de langage, et distingue toujours ce qui est estimé, déclaré et mesuré. Faire mon audit gratuit.