Comment calculer l'effet d'un cas d'usage IA avant son lancement, pas après
Voici à quoi ressemble un cas d'usage IA typique : un collaborateur consacre deux heures à une tâche, l'outil la réalise en vingt minutes, l'économie s'élève à cent minutes, que l'on multiplie par le nombre de tâches et par le taux horaire. Le chiffre obtenu est impressionnant — et presque toujours faux.
Il n'est pas faux à cause du calcul, mais à cause de l'unité de mesure. Une heure économisée n'est pas une ressource libérée qui reste disponible : elle se remplit d'un autre travail, une partie part dans la vérification et la correction du résultat, et parfois elle disparaît tout simplement dans des attentes de rendement plus élevées que personne n'a chiffrées. Ce qui doit entrer dans l'analyse de rentabilité, c'est ce qui ne se reconstitue pas — les opérations supprimées et les défaillances évitées.
L'analyse de rentabilité d'un cas d'usage IA repose sur trois grandeurs : combien d'opérations disparaissent du processus, quelle part des résultats comporte aujourd'hui une défaillance, et combien coûte une défaillance. Le gain de temps n'entre dans le calcul qu'avec une décote pour la charge de vérification et la reprise — selon des enquêtes indépendantes, cette part atteint environ quarante pour cent. Un cas d'usage sans opérations supprimées et sans baisse du taux de défaillance ne se rentabilise pas, aussi impressionnante que soit l'accélération en démonstration.
Pourquoi une heure économisée n'est pas un gain financier
Cette affirmation repose sur deux raisons indépendantes, et les deux se vérifient dans votre propre entreprise en une semaine d'observation — sans pilote fournisseur.
L'heure retourne dans le processus. Le temps libéré ne se transforme pas de lui-même en réduction de coûts : il se remplit de tâches qui étaient jusque-là reportées. Cela peut être une bonne chose — vos équipes traitent enfin ce qu'elles n'avaient jamais le temps de traiter. Mais ce n'est pas une ligne du compte de résultat, et on ne peut pas la promettre comme telle à un comité de direction.
Une partie de l'heure part en vérification. Un résultat produit rapidement doit être lu, recoupé, et souvent réécrit. Ce travail est nouveau : il n'existait pas avant, parce que l'auteur du résultat en était aussi le vérificateur. Il est invisible en démonstration et apparaît précisément à la deuxième semaine d'exploitation réelle, quand quelqu'un doit engager sa signature sur le résultat.
Environ 40 % du temps économisé grâce à l'IA repart sous forme de reprise : correction d'erreurs, réécriture et vérification du résultat obtenu. Autrement dit, sur dix heures « économisées », environ quatre servent à rendre le résultat exploitable.
Je signale moi-même la limite : l'étude a été commandée par un éditeur de logiciels d'entreprise qui vend ses propres fonctionnalités d'IA intégrées et a tout intérêt à montrer les limites des outils « génériques ». La méthodologie complète n'est accessible que derrière un formulaire de contact, pas en accès libre. J'utilise ce chiffre comme un ordre de grandeur pour la décote, pas comme une norme à appliquer telle quelle dans un tableur.
Environ une tâche sur six réalisée avec l'IA prend désormais plus de temps qu'auparavant. Les auteurs indiquent clairement ne pas en avoir établi la cause : cela peut tenir à un volume de travail accru comme au temps de vérification.
Il s'agit d'une déclaration de temps par les intéressés eux-mêmes, non d'un chronométrage, et le lien de causalité n'est pas établi par les auteurs — ils l'écrivent honnêtement. Pour l'analyse de rentabilité, c'est le constat qui compte : la distribution de l'effet présente une queue négative significative, et si l'on calcule à partir de la promesse moyenne d'un éditeur, cette queue n'entre jamais dans le calcul.
Les trois grandeurs sur lesquelles bâtir le calcul
Tout ce qu'exige une analyse de rentabilité honnête se recueille sur le processus en un ou deux jours, sans aucun pilote ni éditeur présent.
Le nombre d'opérations qui disparaissent. Pas « ce sera plus rapide », mais « cette étape n'existera plus ». Une opération disparaît quand son résultat se calcule par une règle, s'insère automatiquement, ou cesse tout simplement d'être nécessaire. Chaque opération supprimée apporte deux choses à la fois : du temps, et un point de défaillance en moins.
La part des résultats en défaillance aujourd'hui. Une défaillance n'est pas une faute dans un texte, mais un événement où le travail ne franchit pas l'étape suivante : le document est parti incomplet, la demande n'est pas arrivée jusqu'au bon interlocuteur, le paiement est parti au mauvais endroit. Cette part se calcule manuellement sur les vingt à cinquante derniers résultats.
Le coût d'une défaillance. Il se compose du coût de la correction et de la probabilité de perte. La seconde partie est inconfortable, car elle exige une estimation plutôt qu'un justificatif — mais c'est généralement elle qui constitue la plus grande part du coût.
| Grandeur | Comment la recueillir | Ce qu'elle apporte au calcul |
|---|---|---|
| Opérations supprimées | Parcourir le processus étape par étape et repérer celles qui disparaissent | La part durable de l'économie |
| Part des résultats en défaillance | Examiner les 20 à 50 derniers résultats | La base du calcul du gain |
| Coût d'une défaillance | Coût de la correction plus probabilité de perte | Un multiplicateur qui dépasse généralement le gain de temps |
| Gain de temps | Mesure avant/après | Intégré avec une décote |
| Nouvelle charge de vérification | Estimer la part des résultats nécessitant une correction | Déduite du gain |
Portez une attention particulière à la dernière ligne. La charge de vérification du résultat est un nouveau poste de coût qui n'existait pas dans le processus avant le déploiement, et elle n'est presque jamais intégrée au calcul initial. C'est précisément elle qui transforme les pourcentages promis en déception au troisième mois.
Ce que disent ceux qui mesurent déjà
72 % des dirigeants interrogés déclarent suivre le retour de l'IA générative à l'aide d'un indicateur, quel qu'il soit, et trois sur quatre parmi eux déclarent un retour positif. L'un des auteurs de l'étude demande explicitement de considérer ce résultat avec prudence : il s'agit d'une déclaration des intéressés, pas de données financières auditées.
La réserve vient des auteurs eux-mêmes, ce qui reste assez rare pour être souligné : ils proposent de considérer leurs propres chiffres « avec un certain scepticisme », les données n'étant pas vérifiées par les comptes des entreprises. La conclusion pratique de ce travail ne tient pas au pourcentage, mais au fait que près d'un tiers des entreprises ne suit aucun indicateur de retour — elles n'ont donc pas non plus de base pour chiffrer leur prochain cas d'usage.
Quand la bonne décision est d'attendre
Le critère standard « la valeur actuelle nette est positive, donc on lance » fonctionne mal dans les projets à forte incertitude. Pour les investissements informatiques, la littérature académique l'a démontré, et la conclusion est contre-intuitive.
Pour un investissement informatique à forte incertitude et avec possibilité de différer l'entrée, le critère traditionnel de la valeur actuelle nette positive peut conduire à une décision erronée. Dans le cas étudié par les auteurs, différer l'entrée de trois ans procurait une valeur plus élevée que l'investissement immédiat : 152 955 $ de plus que l'option « démarrer maintenant ».
Ce travail a plus d'un quart de siècle, et le cas étudié — une infrastructure bancaire de la fin des années 1980 — en constitue une limite que je nomme sans détour plutôt que de la passer sous silence. Le cadre méthodologique, lui, se transpose exactement : lorsque le coût d'un outil chute rapidement et que l'incertitude est forte, le droit d'attendre a une valeur de l'attente mesurable. C'est particulièrement vrai pour les cas d'usage IA, car le prix du calcul et les capacités des modèles évoluent plus vite que le temps nécessaire pour rentabiliser une intégration.
L'ordre du calcul
Le cinquième nœud contient une option généralement écartée d'emblée : traiter la tâche par des règles. Si l'analyse montre que les opérations supprimées sont univoques et calculables, un modèle de langage n'est pas nécessaire — je traite ce choix séparément. Un calcul mené selon ce schéma conduit à cette conclusion plus souvent que ne l'anticipe le commanditaire.
Quatre questions avant de valider le budget
Quelles étapes disparaîtront complètement
Pas « deviendront plus rapides », mais cesseront d'exister. En l'absence de telles étapes, le gain ne portera que sur le temps — qui, lui, retourne dans le processus.
Quelle part des résultats comporte aujourd'hui une défaillance
L'examen des vingt derniers résultats. C'est le seul chiffre qu'on ne peut pas obtenir d'une présentation d'éditeur.
Qui vérifiera, et combien
La nouvelle charge de vérification du résultat s'intègre au calcul dès le départ, plutôt que d'être découverte au troisième mois.
Que perdons-nous si nous attendons six mois
Si la réponse est « rien, sinon le gain différé », attendre peut coûter moins cher qu'une intégration qu'il faudra ensuite refaire.
Une analyse de rentabilité dont tout le gain repose sur des heures économisées n'est pas un calcul, c'est une promesse que personne ne pourra plus faire valoir dans un an.
Questions fréquentes
Comment calculer le ROI d'un déploiement d'IA avant son lancement ?
Par trois grandeurs : le nombre d'opérations qui disparaissent du processus, la part actuelle des résultats en défaillance et le coût d'une défaillance. Le gain de temps s'ajoute en ligne distincte, avec une décote pour la charge de vérification et la reprise — selon des enquêtes indépendantes, cette part atteint environ quarante pour cent. Les coûts intègrent non seulement les licences, mais aussi l'intégration, le coût d'exploitation et la charge de vérification du résultat.
Qu'appelle-t-on une défaillance dans un processus ?
Un événement où le travail est formellement accompli, mais où le résultat ne franchit pas l'étape suivante : le document est parti incomplet, la demande n'est pas arrivée jusqu'au bon interlocuteur, la réponse n'a pas été enregistrée dans le système. Une défaillance se distingue d'une erreur en ce que ses conséquences surviennent en dehors de l'endroit où elle s'est produite, ce qui explique qu'elle apparaisse rarement dans les indicateurs du service où elle a eu lieu.
Un pilote est-il nécessaire pour calculer l'effet ?
Pas pour le calcul lui-même. Les trois grandeurs se recueillent sur le processus actuel sans aucun outil : les étapes sont recensées, les défaillances sont comptées sur les derniers résultats, le coût d'une défaillance est estimé avec la direction financière. Le pilote sert une autre question — quelle part des résultats nécessitera une correction —, et c'est sur cette question précise qu'il faut le concentrer, pas sur une démonstration de capacités.
Pourquoi le gain promis n'apparaît-il pas dans le compte de résultat ?
Parce que le temps économisé ne quitte pas l'entreprise de lui-même. Il ne se transforme en argent qu'à travers trois décisions : réduire le volume de prestations achetées, renoncer à un recrutement, ou augmenter la production avec le même effectif. Si aucune de ces trois décisions n'est prise, le gain reste une grandeur descriptive — réelle pour les collaborateurs, invisible dans les comptes.
L'ordre du calcul (opérations supprimées, taux de défaillance, coût de la défaillance, gain de temps avec décote) est une méthode propre, issue de la pratique d'estimation de la charge de travail chez Alego.Digital et de l'évaluation de projets d'investissement dans le portefeuille du Fonds d'investissement Chine-Russie. Il n'existe pas de description formalisée de cette méthode dans les documents de ces entreprises ; elle est exposée ici pour la première fois. Aucune métrique interne chiffrée n'est présentée dans cet article : tous les chiffres proviennent de sources externes dont la méthode est indiquée.
- Workday, Hanover Research. Beyond Productivity: Measuring the Real Value of AI, janvier 2026 (enquête auprès de 3 200 répondants, novembre 2025). newsroom.workday.com
- Epoch AI, Ipsos. One in Five Workers Delegate Work to AI, août 2026 (enquête auprès de 1 106 actifs, juillet 2026). epoch.ai
- Wharton, GBK Collective. 2025 AI Adoption Report, novembre 2025 (enquête auprès de plus de 800 dirigeants). knowledge.wharton.upenn.edu
- Benaroch M., Kauffman R. J. A Case for Using Real Options Pricing Analysis to Evaluate Information Technology Project Investments. Information Systems Research, 1999. steveambler.uqam.ca