Mesurer le ROI de l'IA : au-delà du battage médiatique

La question du retour sur investissement de l'IA met la plupart des organisations dans une position inconfortable. Non parce que les gains seraient inexistants, mais parce que les méthodes de mesure héritées des projets informatiques classiques s'appliquent mal, et que l'alternative — renoncer à mesurer au nom du caractère « stratégique » de l'investissement — n'est pas tenable devant un comité d'audit.

Le premier obstacle est que la valeur d'un projet IA se manifeste rarement là où on l'attend.

Un assistant de rédaction déployé pour faire gagner du temps aux équipes commerciales produit souvent son effet ailleurs : non pas dans le temps de rédaction, marginal, mais dans le fait que des propositions qui n'étaient jamais envoyées faute de temps le sont désormais. Le gain n'est pas de la productivité, c'est du volume d'activité. Mesurer le temps de rédaction ne montrera rien.

Le deuxième obstacle tient à l'attribution. Quand un indicateur métier s'améliore après un déploiement IA, la part revenant au modèle est rarement isolable. D'autres choses ont changé : les équipes ont été formées, les processus revus, l'attention de la direction s'est portée sur le sujet. Cette difficulté n'est pas propre à l'IA, mais elle y est aiguë parce que les projets IA s'accompagnent presque toujours d'une transformation du travail.

Le troisième obstacle, et le plus coûteux, est de raisonner projet par projet alors que l'essentiel de la valeur est cumulatif. Le premier cas d'usage d'une organisation porte tout le poids de la mise en place : la plateforme, les compétences, les règles de gouvernance, l'apprentissage des équipes. Son ROI isolé est presque toujours médiocre. Le troisième cas d'usage, qui réutilise cette fondation, affiche des chiffres flatteurs sans avoir rien payé. Évaluer chaque projet séparément conduit donc à deux erreurs symétriques : arrêter un programme après un premier cas d'usage jugé décevant, ou surestimer la rentabilité d'un portefeuille à partir de ses derniers ajouts.

L'exemple qui suit est une composition : il réunit des observations faites dans des contextes différents, sans reproduire un cas réel. Une direction déploie un outil d'aide au traitement de dossiers et calcule un gain de vingt pour cent du temps de traitement, soit l'équivalent de plusieurs postes. Le chiffre est exact. Il ne se traduit pourtant par aucune économie, pour une raison simple : le temps libéré est réparti sur quarante personnes, à raison de quelques dizaines de minutes par jour chacune. Ce temps n'est ni mesurable, ni transférable, ni supprimable. Il s'est dilué. La même organisation obtient en revanche un gain parfaitement tangible sur un autre cas d'usage, plus modeste en pourcentage, mais concentré sur une équipe de trois personnes traitant un goulot d'étranglement : là, le temps libéré permet d'absorber une hausse d'activité sans recrutement.

La leçon est structurante : un gain de temps ne devient une valeur que s'il est concentré quelque part. C'est le principe que nous appliquons dès le cadrage chez KAIROS Impulse. Avant d'estimer les gains d'un cas d'usage, nous posons une question désagréable mais nécessaire : si ce projet réussit parfaitement, qu'est-ce qui change concrètement dans les comptes ou dans la capacité de l'organisation ? Si la réponse est « les équipes seront plus à l'aise », le projet peut avoir du sens, mais il ne faut pas lui promettre un ROI qu'il ne produira pas.

Trois familles de valeur méritent d'être distinguées, parce qu'elles ne se mesurent pas de la même manière. La valeur d'efficience — faire la même chose avec moins — est la plus facile à calculer et la plus souvent illusoire, pour la raison de dilution évoquée plus haut. La valeur de capacité — faire ce qu'on ne pouvait pas faire, traiter un volume inaccessible, répondre dans un délai impossible — est plus difficile à chiffrer et beaucoup plus réelle. La valeur de risque — éviter une erreur, détecter une anomalie, documenter une décision — ne se mesure qu'en fréquence d'incidents évités, ce qui suppose de connaître la fréquence antérieure.

Une objection récurrente mérite réponse : certains dirigeants soutiennent que l'IA relève de l'investissement stratégique et échappe par nature au calcul de rentabilité. C'est une position dangereuse. Non parce qu'elle serait toujours fausse, mais parce qu'elle rend le programme indéfendable au premier arbitrage budgétaire difficile. Une initiative dont personne ne sait dire ce qu'elle a produit sera coupée, quelle que soit sa valeur réelle. Mesurer imparfaitement vaut mieux que ne pas mesurer.

Un dernier point, souvent oublié : le coût. Le coût d'un système d'IA n'est pas celui de son développement. Il inclut l'inférence, qui se paie à l'usage et croît avec l'adoption — un succès coûte plus cher qu'un échec —, la surveillance, le réentraînement périodique, et le temps humain de supervision. Les organisations qui budgètent le projet sans budgéter les trois années d'exploitation qui suivent découvrent le vrai coût au pire moment.

Trois questions pour clore. Pour chaque cas d'usage en cours, sommes-nous capables de nommer la ligne du compte de résultat ou l'indicateur de capacité qu'il doit déplacer ? Le gain attendu est-il concentré sur une équipe ou dilué sur un grand nombre de personnes ? Et avons-nous chiffré le coût d'exploitation sur trois ans, ou seulement celui de la construction ?