Mesurer honnêtement le retour sur investissement de l’IA : un cadre pour décider quoi garder et quoi couper

La question du DAF n’est pas de savoir si l’entreprise utilise l’IA. C’est de savoir si chaque cas d’usage mérite de continuer à consommer de l’argent, de l’attention, des données et une capacité de risque.

L’adoption et le retour ne sont pas la même chose. L’étude State of AI 2025 de McKinsey indiquait que 88 % des répondants utilisaient régulièrement l’IA dans au moins une fonction, alors que 39 % seulement déclaraient un impact sur l’EBIT à l’échelle de l’entreprise. L’étude IBM menée auprès de dirigeants indiquait que 25 % seulement des initiatives IA avaient produit le retour attendu et 16 % avaient été déployées à l’échelle de l’entreprise. Ces enquêtes ne portent pas sur les mêmes échantillons, mais elles décrivent le même problème financier : l’activité est plus facile à compter que la valeur.

Une enquête WRITER de 2026 rapportait également que 75 % des dirigeants interrogés reconnaissaient que leur stratégie IA était « surtout pour l’image » plutôt qu’un véritable guide d’action. Traitez ce chiffre comme un résultat d’enquête, pas comme une vérité universelle. La leçon pratique est plus solide : une ligne budgétaire intitulée IA n’est pas un business case.

Commencez par la décision, pas par le modèle

Avant de demander un pourcentage de retour, écrivez une phrase qui nomme ce que le cas d’usage doit changer. « Utiliser l’IA pour améliorer la productivité » est trop général. « Réduire de huit à trois minutes le temps moyen de classement d’une facture fournisseur sans augmenter les erreurs d’exception » peut être mesuré.

Attribuez quatre responsabilités à chaque cas d’usage :

• Responsable métier : redevable du résultat et de l’adoption.
• Responsable finance : redevable de la base, du modèle de coût et du traitement des bénéfices.
• Responsable du processus : redevable du flux réel et de la revue humaine.
• Responsable du risque : redevable des garde-fous de confidentialité, sécurité, qualité et conformité.

Dans une petite équipe, une même personne peut porter plusieurs rôles. Notez-le. Un responsable non nommé est un risque, quelle que soit la taille de l’organisation.

Construisez le coût complet de l’IA

Les business cases faibles utilisent le prix de la licence comme coût. La finance doit mesurer le coût nécessaire pour produire le résultat de façon répétée et sûre.

1. Coût fixe de plateforme

Incluez les abonnements, engagements minimums, accès aux modèles, bases de données, services de recherche, outils d’observabilité et infrastructure réservée. Un essai gratuit n’est pas une hypothèse de régime permanent.

2. Coût d’usage

Comptez les événements déclencheurs : appels au modèle, tokens, documents, pages, images, minutes audio, requêtes de recherche, exécutions de flux et reprises. La fréquence compte. Une automatisation peu coûteuse par appel peut devenir une charge importante si elle s’exécute sur chaque message client, facture, mouvement de stock ou demande interne.

3. Coût du personnel

Incluez la mise en œuvre, la conception des prompts et du flux, la préparation des données, la revue, les exceptions, la formation, le support, l’analyse financière et la conduite du changement. La file de revue humaine fait partie du modèle opérationnel ; elle ne prouve pas que l’IA est gratuite.

4. Coût des intégrations et des données

Prévoyez les API, connecteurs, nettoyages, indexations, exports, sauvegardes et maintenances des droits. Si la fonction exige un nouveau processus de données de référence, chiffrez ce travail au lieu de le traiter comme une condition invisible.

5. Coût des contrôles

Les revues de confidentialité, les tests de sécurité, les journaux, l’évaluation du modèle, les tests adversariaux, les contrats, les règles de conservation et la réponse aux incidents protègent la valeur. Un cas d’usage incapable de passer le seuil de contrôle n’est pas une bonne affaire.

6. Coût des défaillances

Estimez les reprises, erreurs, escalades, remédiations client, indisponibilités et occasions perdues lorsque l’équipe cesse de faire confiance à la fonction. Vous ne connaîtrez pas parfaitement ce chiffre au lancement. Suivez-le et améliorez l’estimation avec les incidents.

Séparez quatre types de valeur

La « valeur » n’est pas un seul chiffre. Séparez les bénéfices afin qu’un gain de capacité ne devienne pas silencieusement une économie de trésorerie puis une promesse de croissance.

1. Trésorerie réalisée : coût fournisseur supprimé, heures supplémentaires évitées, contrat non renouvelé ou encaissement accéléré. Montrez le mécanisme et la période.
2. Capacité libérée : heures rendues à l’équipe. Montrez ce que l’équipe en a fait : plus de dossiers, clôture plus rapide, meilleur suivi ou pression réduite. Ne l’appelez pas économie salariale si la masse salariale ne change pas.
3. Qualité et risque : erreurs réduites, détection accélérée, exceptions de conformité diminuées, décisions plus sûres ou piste d’audit plus complète. Convertissez en argent uniquement lorsque la conversion est défendable.
4. Option stratégique : données, apprentissage ou capacité réutilisable qui facilitera une décision future. Cela peut compter, mais ne doit pas masquer un retour actuel négatif.

L’étude IBM de 2025 indiquait que 52 % des dirigeants interrogés voyaient une valeur de l’IA au-delà de la réduction des coûts, notamment dans la croissance, l’expérience client, l’innovation et la durabilité. La réduction des coûts n’est donc pas toute l’histoire. C’est précisément pour cela qu’il faut nommer le type de valeur avant de la compter.

Établissez une base et un scénario de comparaison

Une comparaison avant-après est un début, pas une preuve. Le volume, les effectifs, la saisonnalité, les prix, le profil client et d’autres changements de processus peuvent avoir évolué en même temps que le lancement de l’IA.

Pour chaque cas d’usage, consignez :

• la période de référence et la définition exacte de l’indicateur ;
• le volume, le mix et les conditions normales de service ;
• le groupe, l’ancien processus ou la période de comparaison ;
• les changements intervenus en dehors de l’IA ;
• les seuils de qualité et de sécurité qui ne peuvent pas être sacrifiés ;
• la personne qui valide le résultat.

Utilisez la comparaison la plus solide que le contexte permet. Un test aléatoire peut convenir à un message ou à un flux peu risqué. Une agence, équipe, file ou période comparable peut être plus réaliste. Pour la finance, la santé, le crédit, l’emploi ou les décisions concernant des clients, conservez l’approbation humaine et présentez le contrôle à côté du gain de productivité.

Attribuez le résultat honnêtement

Donnez à chaque bénéfice un niveau de confiance d’attribution :

• Élevé : le changement IA est isolé, la base est stable et l’effet de trésorerie est visible dans les comptes ou dans un relevé opérationnel convenu.
• Moyen : la direction du résultat est claire, mais plusieurs changements ont eu lieu ensemble. Présentez une fourchette et les hypothèses.
• Faible : la promesse est plausible mais aucune base, comparaison ou preuve d’adoption n’est fiable. Traitez-la comme un apprentissage, pas comme un ROI.

Cette méthode évite deux erreurs opposées. La première consiste à approuver de mauvais outils en attribuant 100 % des bénéfices à l’IA. La seconde consiste à couper une capacité utile parce que la finance refuse de reconnaître ce qui ne se réduit pas à une facture. Une bonne mesure dit ce qui est connu, estimé ou encore hypothétique.

Décidez quoi garder, corriger ou couper

Examinez chaque fonction à une cadence fixée avec la même fiche. La question n’est pas « La démonstration est-elle impressionnante ? », mais « Cette version du processus mérite-t-elle une nouvelle période de dépense ? »

« Corriger » ne doit pas devenir une salle d’attente permanente. Fixez une limite de temps à l’expérience suivante. Si le cas d’usage ne présente toujours pas de chemin crédible après traitement des données, du flux et de l’adoption, prenez la décision de couper.

Une revue financière de 30 jours

1. Jours 1 à 5 : nommer le résultat, les responsables, la base, le volume, les garde-fous et la date de décision.
2. Jours 6 à 10 : lister les coûts fixes, variables, humains, d’intégration, de contrôle et de défaillance. Confirmer comment la fréquence sera comptée.
3. Jours 11 à 20 : mesurer le travail réel contre la comparaison prévue. Enregistrer les exceptions et l’usage du temps libéré.
4. Jours 21 à 25 : vérifier l’attribution, le traitement comptable, la capacité, la qualité et le risque.
5. Jours 26 à 30 : décider garder, corriger ou couper. Inscrire la décision dans le registre d’investissement et fixer la prochaine revue.

L’objectif n’est pas de transformer chaque expérimentation en comité trimestriel. Le niveau d’examen doit correspondre au risque et à la dépense. Un assistant interne peu risqué exige moins qu’un système qui approuve un crédit, modifie les prix ou manipule des données personnelles. La discipline reste la même : résultat nommé, coût complet, comparaison crédible et décision responsable.

L’IA n’est pas exemptée de la discipline d’investissement

L’IA peut créer une valeur réelle. Elle peut aussi créer une facture récurrente d’appels, de revues, d’intégrations et de contrôles avant que quiconque ait démontré ce qui a changé. Les travaux d’IBM montrent que beaucoup de dirigeants investissent avant d’avoir une valeur claire, alors que la plupart disent que des indicateurs plus précis les aideraient. C’est une invitation à mesurer, pas une raison d’arrêter toute expérimentation.

Gardez les fonctions qui améliorent un résultat important à un coût complet acceptable. Corrigez celles qui ont un problème nommé et un test limité dans le temps. Coupez celles qui ne franchissent pas le seuil de valeur, de sécurité, d’adoption ou de mesure. La contribution d’un DAF n’est pas le scepticisme pour lui-même : c’est la preuve qui permet de faire davantage du bon travail et d’arrêter de payer le reste.

Pour commencer, associez ce cadre à notre guide sur la gouvernance responsable de l’IA et à l’article sur l’IA agentique pour les dirigeants. Pour transformer un cas d’usage en business case mesuré, contactez Peter.