ROI d’un cas d’usage IA : mesurer avant de généraliser

Le ROI d’un projet IA ne se mesure pas en multipliant des minutes théoriquement gagnées par un salaire horaire. Cette opération produit un chiffre rapide, mais elle ne dit ni si le travail a été accepté, ni si la qualité a tenu, ni si le temps libéré a réellement servi à autre chose. Elle oublie souvent la préparation des données, la vérification, les corrections, la formation, les changements de processus et les échecs.

Pour mesurer un ROI IA en entreprise, il faut partir d’un seul cas d’usage, décrire précisément la situation actuelle, observer une baseline sur des dossiers réels et comparables, puis faire passer un lot équivalent dans un pilote. La décision porte alors sur une valeur nette observée, une qualité maintenue et une capacité réellement utilisable, pas sur une promesse générale de productivité.

Si plusieurs problèmes sont encore en concurrence, commencez par prioriser les cas d’usage IA comme un portefeuille avant de construire la baseline du pilote retenu.

Réponse en bref

Un calcul défendable suit sept règles :

1. choisir une tâche et une sortie attendue, pas « l’IA dans l’entreprise » ;
2. enregistrer la situation habituelle avant le pilote sur 20 à 30 dossiers représentatifs ;
3. conserver le même périmètre, les mêmes critères de qualité et des cas de difficulté comparable pendant le pilote ;
4. compter tous les coûts directs, humains et organisationnels ;
5. distinguer temps économisé, capacité réaffectée et économie financière réalisée ;
6. mesurer les erreurs, les reprises, les pertes évitées et les écarts entre groupes de cas ;
7. décider à l’aide de seuils écrits avant le test : arrêter, continuer en corrigeant ou étendre progressivement.

Les trois formules centrales sont les suivantes :

Valeur nette du pilote = bénéfices financiers réalisés + valeur de la capacité effectivement réaffectée + pertes évitées prudemment estimées - coût complet du pilote

Valeur nette par tâche acceptée = valeur nette du pilote / nombre de tâches acceptées

ROI du pilote = valeur nette du pilote / coût complet du pilote × 100

Une tâche acceptée est une tâche dont le résultat satisfait les critères métier sans correction substantielle. Une sortie générée, envoyée dans une file ou marquée « terminée » par le système n’est pas encore une tâche acceptée.

La prochaine action utile consiste à sélectionner 20 à 30 dossiers représentatifs déjà traités, à mesurer leur durée, leurs reprises et leur qualité, puis à figer ce registre avant de lancer le pilote.

Mesurer une intervention, pas une technologie

La question « quel est le ROI de l’IA ? » est trop large pour produire une décision. Une même entreprise peut utiliser un assistant pour résumer des documents, classer des demandes, préparer un devis ou rechercher une information. Les sorties, les risques et les coûts de vérification ne sont pas comparables.

L’unité d’analyse doit tenir dans une phrase :

Pour ce type de dossier, une personne prépare cette sortie, selon ces critères, avant cette décision.

Par exemple : préparer une fiche de synthèse à partir d’un dossier complet, afin qu’un responsable puisse décider de la suite. Le cas d’usage n’inclut pas automatiquement la collecte initiale, la décision finale ou l’envoi à un tiers. Ces frontières empêchent d’attribuer à l’IA un gain produit par une autre amélioration simultanée.

Le guide britannique consacré à l’évaluation des interventions IA recommande d’expliciter la situation de référence, les mécanismes attendus, les risques et les effets non intentionnels. Cette logique est utile en entreprise : le pilote est une intervention dans un processus, pas un concours de réponses entre modèles.

Écrivez avant tout test :

• l’entrée admise et les cas exclus ;
• la sortie attendue ;
• la personne qui utilise ou valide cette sortie ;
• le résultat métier que la sortie doit permettre ;
• les erreurs inacceptables ;
• les changements menés en parallèle ;
• la version de l’outil, du modèle, des consignes et des données de référence.

Si le processus, l’équipe et l’outil changent tous pendant la mesure, le chiffre final ne permet plus de savoir ce qui a produit l’écart.

Décrire le fonctionnement habituel avant le pilote

Une baseline n’est pas une moyenne retrouvée de mémoire. C’est une observation datée du fonctionnement habituel, parfois appelé business as usual. Elle montre comment la tâche se déroule avant l’intervention : qui la reçoit, combien de temps elle attend, combien de temps elle mobilise, quelles reprises surviennent et quel résultat est finalement accepté.

Prenez 20 à 30 dossiers pour un premier diagnostic opérationnel. Ce volume ne transforme pas le test en étude statistique universelle. Il suffit souvent à révéler des écarts masqués par une moyenne : dossier court ou long, donnée complète ou manquante, utilisateur expérimenté ou débutant, cas standard ou exception. Si la décision engage fortement des personnes, de l’argent ou un service critique, un échantillon plus large et une méthode d’évaluation spécialisée peuvent être nécessaires.

Le lot doit représenter le travail réel. Ne choisissez pas uniquement les dossiers propres qui rendent la démonstration facile. Constituez des strates avant de mesurer, par exemple :

• 12 cas standards ;
• 6 cas incomplets ;
• 4 cas ambigus ;
• 4 cas comportant une exception connue ;
• 4 cas qui doivent être refusés ou escaladés.

La composition dépend du processus. L’important est de conserver des familles comparables entre la baseline et le pilote.

Le registre avant-après

Le registre relie chaque observation à un dossier opaque, sans recopier son contenu sensible. Une ligne correspond à une tentative complète dans le processus habituel ou dans le pilote.

Champ	Ce qu’il faut enregistrer
identifiant	référence opaque du dossier, jamais son contenu brut
période	baseline ou pilote, avec date
famille de cas	standard, incomplet, ambigu, exception ou refus attendu
version	outil, modèle, consigne, workflow et base utilisés
temps actif	minutes réellement travaillées par les personnes
temps d’attente	délai entre réception et résultat disponible
contrôle	durée et rôle de la personne qui vérifie
correction	aucune, mineure, substantielle ou reprise complète
statut final	accepté, corrigé puis accepté, refusé ou abandonné
qualité	critères métier observables, identiques avant et après
incident	erreur critique, donnée exposée, action indue ou autre événement défini
effet suivant	décision accélérée, demande évitée, travail reporté ou aucune suite observable

Mesurez le temps actif séparément du délai. Un système peut produire un brouillon en trente secondes tout en laissant le dossier trois heures dans une file de validation. À l’inverse, un contrôle de huit minutes peut être acceptable s’il remplace une préparation manuelle plus longue et améliore la traçabilité.

Définissez aussi les corrections. Une retouche de ponctuation ne doit pas être confondue avec la reprise d’un raisonnement, la recherche d’une source manquante ou la reconstruction du document. La catégorie « substantielle » doit être reconnaissable par deux évaluateurs.

Construire un pilote comparable

Un pilote utile compare le nouveau processus à une référence, pas à une impression. L’idéal méthodologique dépend du contexte : répartition aléatoire, déploiement progressif, comparaison avant-après ou approche fondée sur une théorie du changement. Pour un premier cas métier borné, la priorité est plus simple : éviter que le pilote reçoive uniquement les meilleurs dossiers et les utilisateurs les plus motivés.

Utilisez le même format d’entrée, la même définition du résultat accepté et la même grille de qualité. Si possible, faites traiter des cas comparables sur la même période. Sinon, documentez les différences : saison, charge, expérience, changement réglementaire, nouvel outil source ou réorganisation.

Le pilote doit inclure le processus complet : préparation de l’entrée, génération, contrôle, correction, enregistrement et reprise après erreur. Une évaluation limitée à la qualité brute du modèle ne mesure pas le ROI du cas d’usage. Le rapport ARIA du NIST distingue notamment tests du modèle, red teaming et tests de terrain. Cette séparation rappelle qu’une application peut réussir un test isolé tout en créant des difficultés dans son contexte réel.

Pour mesurer la qualité avant déploiement, le protocole sur 50 cas représentatifs complète cette approche. Le présent calcul pose une question différente : une fois la qualité acceptable, le processus produit-il une valeur nette dans les conditions d’usage prévues ?

Compter le coût complet sans le gonfler

Le coût du pilote comprend ce qui a été nécessaire pour obtenir et maintenir le résultat observé. Il ne doit ni se limiter au prix du modèle, ni absorber tous les frais généraux de l’entreprise.

Séparez six blocs :

1. outil et infrastructure : abonnements, API, hébergement, stockage et services directement utilisés ;
2. construction : cadrage, préparation des données, intégration, tests et documentation ;
3. contrôle humain : lecture, approbation, escalade et vérification par échantillon ;
4. correction et échec : reprises, dossiers rejetés, incidents et travail devenu inutilisable ;
5. formation et adoption : temps de formation, accompagnement initial et animation nécessaire au cas ;
6. processus et maintenance : nouvelle procédure, suivi des versions, support et revue périodique.

Distinguez les coûts de lancement des coûts récurrents. Le premier pilote supporte souvent un cadrage et une préparation qui ne se répéteront pas intégralement. À l’inverse, une maintenance oubliée rend le coût futur artificiellement faible.

Pour détailler modèles, outils, données, infrastructure, contrôle et retries, utilisez le registre de coût par tâche acceptée. Ici, ces coûts deviennent le dénominateur d’une décision de valeur, mais ils ne suffisent pas à prouver le bénéfice.

Ne pas transformer automatiquement le temps gagné en euros

Le temps économisé peut produire trois situations différentes.

Temps théorique

La tâche prend moins longtemps, mais la différence est absorbée par des interruptions, de l’attente ou une charge variable. Le gain existe dans le registre, sans effet financier ou opérationnel encore démontré.

Capacité réaffectée

Le temps libéré sert à traiter davantage de dossiers, réduire un retard, améliorer un contrôle ou accomplir une tâche précédemment abandonnée. Cette capacité a une valeur opérationnelle, à condition de montrer son usage. Elle ne correspond pas automatiquement à une baisse de dépense.

Économie financière réalisée

Un achat est évité, une prestation diminue, des heures supplémentaires disparaissent ou une dépense variable baisse effectivement. Le gain peut alors entrer dans le calcul monétaire, avec une pièce comptable ou une règle de valorisation validée.

Cette distinction évite le raisonnement suivant : neuf minutes gagnées sur 10 000 tâches équivalent forcément à 1 500 heures de salaire économisées. Si les effectifs, les horaires et les dépenses restent identiques, aucune économie de trésorerie n’a encore eu lieu. L’entreprise dispose peut-être d’une capacité supplémentaire, ce qui peut être utile, mais ce bénéfice doit être nommé correctement.

Les indicateurs agrégés de productivité publiés par l’OCDE décrivent des économies, des secteurs ou des groupes d’entreprises. Ils montrent aussi que les moyennes masquent une forte hétérogénéité et que compétences, management et infrastructure comptent dans la diffusion des gains. Une statistique macroéconomique, même récente, ne peut donc pas devenir le ROI de votre pilote.

Ajouter la qualité et le risque au tableau

Un processus plus rapide peut détruire de la valeur s’il augmente les erreurs difficiles à détecter. Mesurez au minimum :

• le taux d’acceptation sans correction substantielle ;
• le taux de reprise complète ;
• les erreurs critiques ;
• les omissions importantes ;
• les escalades correctement déclenchées ;
• les écarts de qualité entre familles de cas ;
• le temps de contrôle nécessaire pour maintenir le niveau attendu.

Une perte évitée peut entrer dans la valeur lorsque trois éléments existent : une fréquence de référence, un coût ou impact documenté et un mécanisme crédible par lequel le pilote réduit cette perte. « L’IA diminue les risques » ne suffit pas. Il faut par exemple montrer que le nouveau contrôle détecte une catégorie d’erreur auparavant observée, sans créer une autre erreur plus grave.

Les validations humaines doivent être placées avant l’effet qu’elles contrôlent. L’article sur le human in the loop explique comment définir les états, l’expiration et la reprise. Dans le calcul du ROI, ce contrôle est à la fois un coût et un mécanisme de protection. Le supprimer pour embellir le résultat change le système évalué.

Calculer la valeur nette par tâche acceptée

Commencez par compter les tâches acceptées, pas les générations. Puis additionnez uniquement les bénéfices observés sans double compte.

Prenons une illustration entièrement synthétique. Une équipe observe 24 dossiers avant le pilote, puis 24 dossiers de difficulté comparable. Le temps actif médian passe de 32 à 23 minutes, contrôle compris. Dix-huit sorties du pilote sont acceptées sans correction, quatre reçoivent une correction mineure puis sont acceptées et deux sont refusées comme prévu. Le registre établit un gain de temps, mais ce gain reste une capacité tant que l’équipe ne montre pas ce qu’elle en fait.

Si, pendant la même période, la capacité libérée permet de résorber un stock documenté sans heures supplémentaires, la dépense évitée correspondante peut être valorisée. Si l’équipe traite simplement les mêmes volumes avec les mêmes coûts, elle conserve un bénéfice de délai ou de confort, pas encore une économie financière.

Calculez ensuite :

Coût complet = lancement amorti sur le périmètre + coûts récurrents + contrôle + corrections + formation + maintenance

Bénéfices retenus = économies réalisées + capacité valorisée selon une règle validée + pertes évitées documentées

Valeur nette par tâche acceptée = (bénéfices retenus - coût complet) / tâches acceptées

Présentez aussi les indicateurs non monétaires à côté du ROI : délai médian, taux d’acceptation, erreurs critiques, satisfaction du rôle utilisateur et variation selon les familles. Un pourcentage financier ne résume pas une dégradation de qualité ou un risque sur une personne.

Tester la solidité de la conclusion

Un seul calcul donne une précision trompeuse. Faites varier les hypothèses contestables : taux d’usage, temps de contrôle, prix du service, fréquence des reprises et part de capacité réellement réaffectée.

Préparez trois scénarios :

• prudent : adoption plus faible, contrôle plus long, aucun temps non matérialisé converti en argent ;
• central : valeurs observées pendant le pilote, sans extrapolation supplémentaire ;
• haut borné : adoption et volume supérieurs, uniquement si le processus peut absorber cette charge.

Si le ROI devient négatif dès qu’une hypothèse bouge légèrement, la généralisation est fragile. Si le scénario prudent reste acceptable et que la qualité tient, la décision dispose d’une meilleure marge.

Vérifiez aussi la sensibilité aux versions. Un changement de modèle, de consigne, de base ou d’interface peut modifier coût, qualité et temps de contrôle. La version évaluée doit être enregistrée, et toute modification significative doit rejouer un échantillon du registre.

Décider : arrêter, continuer ou étendre

Les seuils doivent être définis avant de voir les résultats.

Arrêter

Arrêtez si une erreur critique apparaît, si la qualité devient inférieure à la baseline, si le contrôle annule le gain, si les données nécessaires ne peuvent pas être utilisées légitimement ou si les personnes contournent le processus pour terminer leur travail.

Un ROI financier apparemment positif ne compense pas un risque non maîtrisé. L’arrêt peut aussi signifier que la tâche était mal choisie, pas que toute utilisation de l’IA est inutile.

Continuer en corrigeant

Continuez sur le même périmètre lorsque le signal est utile mais encore incertain : trop peu de cas, variation forte entre utilisateurs, un type de dossier mal traité ou coût initial encore mal séparé du coût récurrent. Corrigez un élément à la fois et rejouez des cas comparables.

Étendre progressivement

Étendez lorsque la qualité est au moins maintenue, les erreurs critiques absentes, le taux d’acceptation suffisant, les coûts observables et la capacité libérée effectivement utilisée. Ouvrez alors un nouveau groupe ou une nouvelle famille de cas, sans multiplier simultanément les outils et les permissions.

L’adoption conditionne la réalisation de la valeur. Des rituels d’équipe après la formation peuvent vérifier que la méthode reste utilisée, corrigée et transférée. Le registre ROI ne remplace pas ce travail : il montre si l’usage produit une valeur lorsqu’il est réellement appliqué.

La fiche de décision à présenter

Une direction métier ou financière n’a pas besoin d’un diaporama rempli de captures. Elle doit recevoir une fiche courte :

Question	Réponse attendue
quel cas ?	entrée, sortie, utilisateur et décision concernée
comparé à quoi ?	baseline datée et fonctionnement habituel documenté
sur quels cas ?	volume, familles, exclusions et différences connues
quelle qualité ?	acceptation, reprises, erreurs critiques et écarts
quel coût ?	lancement, récurrent, contrôle, correction, formation et maintenance
quel bénéfice ?	économie réalisée, capacité réaffectée et perte évitée séparées
quelle robustesse ?	scénarios prudent, central et haut borné
quelle décision ?	arrêter, corriger ou étendre, avec propriétaire et date de revue

Cette fiche rend les désaccords utiles. La finance peut contester une valorisation, le métier un critère d’acceptation, l’équipe technique un coût de maintenance et les utilisateurs une hypothèse d’adoption. Le calcul s’améliore parce que ses hypothèses deviennent visibles.

Si vous devez choisir le cas, construire la baseline et organiser le pilote avec plusieurs fonctions, une mission de conseil IA peut servir à cadrer la décision sans imposer un outil avant la mesure.

Limites

Un lot de 20 à 30 dossiers fournit un diagnostic de pilote, pas une preuve universelle. Les volumes faibles rendent la moyenne sensible à quelques cas, les tâches subjectives demandent une grille de qualité plus robuste et les impacts sur différents groupes peuvent exiger une évaluation dédiée.

Le ROI monétaire ne capture pas tout. Une réduction du délai, une meilleure traçabilité, une charge mentale moindre ou une capacité d’apprentissage peuvent compter sans être converties proprement en euros. À l’inverse, un gain déclaré par les utilisateurs ne prouve pas à lui seul une économie ou une amélioration de qualité.

Les effets à long terme restent incertains lorsque les modèles, les prix, les usages et les processus évoluent. Une généralisation doit donc conserver un registre de versions, des tests de régression, une revue des coûts et un point d’arrêt. Enfin, aucune méthode de calcul ne remplace une analyse juridique, sociale, de sécurité ou d’impact lorsque le cas concerne des décisions sensibles ou des personnes.