Valeur de l’IA : mesurer les gains et les coûts réels

Selon Gartner, 13 % des DSI déclarent une valeur importante de l’IA. Gains de temps, reprises et dépenses : comment lire ce résultat sans confondre activité et bénéfice.

Imaginons un assistant qui termine une réponse en quelques secondes. Le dossier, lui, reste ouvert : il faut contrôler les chiffres, retrouver une pièce manquante et corriger une conclusion trop assurée. Entre la rapidité de l’outil et le travail réellement terminé, c’est tout le calcul de la valeur de l’IA qui se joue.

L’enquête Gartner publiée le 19 octobre 2026 donne un repère : 13 % des directeurs des systèmes d’information interrogés déclarent que leur entreprise a déjà obtenu une valeur significative ou transformationnelle de l’IA. Elle porte sur 2 002 DSI et responsables technologiques, interrogés de mai à juillet 2026. Son intitulé « 2027 » désigne l’agenda étudié, pas une collecte de réponses dans le futur.

Ce résultat mérite mieux qu’un verdict général sur une technologie. Pour une entreprise, la question utile est plus précise : quelle tâche accomplit-elle mieux, à quel coût et avec quelles conséquences pour les personnes qui doivent reprendre la main ?

Ce que le chiffre de 13 % ne permet pas de conclure

Il s’agit d’une appréciation déclarée par les répondants, pas d’un audit comptable de chaque entreprise. Les autres réponses ne peuvent donc pas être transformées automatiquement en 87 % de projets sans aucun bénéfice. Le communiqué public ne fournit pas le détail des réponses nécessaire pour établir ce raccourci.

Gartner relève aussi une association entre des règles d’arrêt explicites et les organisations de son groupe le plus performant : 31 % des répondants disposent de critères pour refuser le passage d’un pilote en production, 17 % pour arrêter une initiative déjà déployée. Une association statistique ne démontre cependant pas, à elle seule, qu’une règle d’arrêt provoque la performance.

Mesurer le dossier terminé, pas seulement la réponse générée

Imaginons un service qui utilise l’IA pour préparer des réponses à des demandes clients. Compter les textes produits donne une mesure d’activité. Compter les demandes correctement résolues donne une mesure du service rendu. Les deux peuvent diverger si une réponse bien rédigée contient une erreur de contrat ou appelle plusieurs échanges supplémentaires.

Une grille utile sépare donc au moins trois résultats : le temps nécessaire pour traiter la demande, la justesse de la réponse et les reprises demandées par le client. La référence de départ doit être connue. Comparer une semaine calme sans IA à une semaine chargée avec IA ne permettrait pas d’attribuer proprement un écart au nouvel outil.

Le NIST, l’institut américain de normalisation, propose dans son guide de gestion des risques de l’IA de choisir les mesures selon l’usage, de fixer des limites de performance acceptables et de documenter ce qui ne peut pas être mesuré. Il recommande aussi de comparer les performances avant et après déploiement, puis de réexaminer les indicateurs lorsque les conditions changent. Ce cadre aide à organiser une évaluation ; il ne certifie pas la rentabilité d’un produit.

Sur le terrain, cela revient à écrire une question que l’on peut vraiment trancher. Par exemple : « Sur des demandes de même nature, le délai baisse-t-il sans hausse des erreurs graves ni des réclamations ? » Une telle question permet de savoir quelles observations recueillir avant de choisir un fournisseur ou d’étendre l’usage.

Un calcul fictif pour voir où part le gain

Prenons un exemple entièrement hypothétique, qui ne décrit aucune entreprise de l’enquête. Un service traite 1 000 dossiers par mois. Sans assistant, chaque dossier demande 12 minutes. Avec l’outil, la préparation et la vérification ordinaires prennent ensemble 8 minutes. Le gain brut est de 4 000 minutes, soit environ 66,7 heures.

Supposons maintenant que 100 dossiers nécessitent chacun 15 minutes de reprise supplémentaires. Il faut retirer 1 500 minutes, soit 25 heures. Le gain net de temps descend à environ 41,7 heures. Ignorer ces reprises ferait apparaître un résultat nettement plus favorable que le travail effectivement accompli.

Si l’on valorise, pour cet exemple seulement, une heure de travail à 30 euros, ces heures représentent 1 250 euros de capacité dégagée. Si les dépenses mensuelles supplémentaires atteignent 900 euros, l’écart théorique est de 350 euros. Il reste encore à considérer les frais initiaux, les incidents éventuels et les limites de cette valorisation.

Surtout, 1 250 euros de temps disponible ne sont pas automatiquement 1 250 euros économisés sur un compte bancaire. Si les salaires et les horaires restent identiques, l’entreprise a surtout gagné une possibilité de faire autre chose. Réduire un retard, mieux répondre aux clients ou absorber davantage de demandes peut avoir une valeur réelle. Encore faut-il constater que cette capacité est effectivement utilisée.

Regarder les coûts qui entourent l’outil

Le prix d’un abonnement ou d’une requête est facile à voir. Pour comparer deux solutions, le périmètre proposé doit aussi inclure l’intégration, la préparation des données, la formation, les contrôles et le traitement des erreurs. Il faut préciser quels coûts sont ponctuels et lesquels reviennent chaque mois, sans compter deux fois le même travail.

Un essai peut être peu coûteux parce qu’un salarié prépare manuellement tous les documents avant chaque démonstration. Ce résultat reste intéressant, mais il ne démontre pas que le service fonctionnerait au même prix à grande échelle. La question à poser est alors concrète : cette préparation disparaît-elle dans la version déployée, ou devient-elle une charge permanente ?

Il faut également regarder les cas difficiles. Une moyenne acceptable peut masquer quelques dossiers très longs à corriger. Pour une tâche exposant un client à une erreur importante, le temps moyen ne suffit pas : la gravité des erreurs et la possibilité de les détecter avant qu’elles produisent un effet doivent entrer dans la décision.

Prévoir une sortie sans perdre le service

Fixer une règle d’arrêt ne signifie pas abandonner l’IA au premier résultat décevant. Une décision utile peut être de réduire le périmètre : conserver l’aide à la rédaction, mais empêcher l’envoi automatique ; autoriser le classement de documents, mais maintenir une validation pour les pièces ambiguës. Le choix doit correspondre au défaut observé.

Pour notre service fictif, un pilote pourrait ainsi rester limité tant que les erreurs portant sur les engagements contractuels ne sont pas repérées de façon fiable. Une correction ciblée serait ensuite évaluée sur de nouveaux dossiers comparables. Réussir sur les seuls exemples déjà corrigés ne suffirait pas à démontrer que le problème est résolu.

La continuité mérite elle aussi une réponse avant le lancement. Qui reprend les dossiers si l’outil est suspendu ? Où se trouvent les demandes en attente ? Comment éviter qu’une action déjà effectuée soit répétée après une interruption ? Ces questions permettent de juger un service complet, au-delà de la qualité visible d’une réponse.

Ce qu’un bilan devrait permettre de décider

Un bilan lisible peut tenir sur quelques lignes, à condition qu’elles portent sur le bon périmètre : tâche évaluée, période observée, comparaison de départ, volume traité, erreurs et reprises, temps net gagné, dépenses supplémentaires et limites connues. Chaque décision de poursuivre, corriger ou arrêter peut alors être rattachée à une observation.

La discussion devient également plus honnête avec les équipes. Si l’objectif est d’améliorer la qualité du service, il faut le mesurer comme tel. Si l’objectif est une économie, il faut montrer où la dépense disparaît réellement. Changer d’objectif après un résultat décevant rendrait toute comparaison peu instructive.

Le prochain dossier traité avec l’IA peut ainsi poser une question simple : a-t-il été terminé plus vite, correctement, et sans déplacer une charge invisible vers quelqu’un d’autre ? C’est à cette échelle que la promesse technologique commence à devenir vérifiable.