La diapo existe dans toutes les entreprises et elle dit toujours la même chose : « on libère 1 200 heures par an ». Page quatre, juste avant le budget, et personne ne la discute parce qu’elle ressemble à de l’arithmétique. Douze mois plus tard, le département coûte pareil, l’effectif est le même, et personne ne sait expliquer où sont passées ces 1 200 heures. Ce n’est pas que l’IA n’a pas marché. C’est que l’heure a été libérée et n’est allée nulle part.
La thèse en une ligne : une heure libérée n’est pas un euro économisé. C’est une heure disponible, ce qui est autre chose. Pour devenir de l’argent, elle doit atteindre l’une des trois destinations — plus de volume à effectif constant, du travail qu’on ne faisait pas avant, ou un coût qui baisse vraiment — et chacune exige une décision explicite que presque personne ne prend. Par défaut, l’heure se réabsorbe dans du travail de remplissage et personne ne le voit, parce que personne ne regardait. Si ce n’est pas écrit où va l’heure, l’heure ne va nulle part.
Pourquoi les heures libérées par l’IA ne sont pas des économies réelles au compte de résultat
Le malentendu tient au verbe. « Économiser » sur un tableur veut dire qu’un coût disparaît. « Économiser » sur une journée veut dire qu’un créneau se libère. Deux choses différentes qui s’écrivent pareil, et le business case les traite comme une seule. Le coût d’une personne ne baisse pas parce qu’elle a moins de travail : il baisse quand il y a moins de personnes, ou quand les mêmes personnes produisent davantage de quelque chose qui se vend. Tout le reste, c’est de la capacité oisive déguisée en économie.
Et la capacité oisive ne se voit pas. Personne ne reste à fixer le mur : le trou se remplit tout seul, avec des réunions qui ne tenaient pas avant, des relectures plus soignées, la version longue du rapport qu’on faisait court. Une partie est très bien — c’est du travail mieux fait. Mais ce ne sont pas des économies, et six mois plus tard personne ne peut dire quelle part du trou était amélioration et quelle part était remplissage, parce que le trou n’a jamais été mesuré.
Le calcul de la BCE : de 7,7 % de la journée à 0,35 point de productivité
Il existe un chiffre récent qui permet de voir toute la fuite, et il ne vient pas d’un vendeur. Le 26 août 2026, la Banque centrale européenne a publié une analyse sur l’adoption de l’IA et la productivité — signée António Dias da Silva, Laura Lebastard et David Sondermann — construite sur sa Consumer Expectations Survey : environ 20 000 personnes par mois dans onze pays de la zone euro. L’utilisateur médian déclare économiser trois heures par semaine, soit environ 7,7 % de son temps de travail. La BCE précise elle-même que la distribution est très asymétrique : la plupart économisent peu, quelques-uns économisent beaucoup.
Ce qui compte, c’est ce que la BCE fait ensuite de ces 7,7 %, parce que c’est exactement la soustraction qui n’apparaît jamais dans une présentation. Seule la moitié des actifs — 48,8 % — déclare utiliser l’IA et gagner du temps, donc le gain d’efficacité pour l’économie entière tombe autour de 3,8 %. Traduit en croissance de la productivité, l’estimation de la BCE elle-même pour la zone euro tourne autour de 0,35 point de pourcentage par an. De 7,7 % d’une journée au bureau à trois dixièmes de point dans l’économie. En route, ce qui se perd n’est pas de la technologie : c’est une décision. Le chiffre concerne la zone euro ; il dimensionne le problème, il ne promet aucun résultat.
Les trois destinations d’une heure libérée (et ce que chacune exige)
Une heure qui cesse d’être consommée par une tâche ne peut finir qu’à trois endroits si tu veux qu’elle se voie dans le résultat. Aucune des trois n’est automatique, et les trois demandent quelque chose que l’outil ne te donne pas.
| Destination de l’heure | Ce qu’il faut pour qu’elle se matérialise | Comment on vérifie à six mois |
|---|---|---|
| Plus de volume à effectif constant | Une demande réelle pour absorber cette capacité : plus de commandes, plus de dossiers, plus de clients. Sans demande, l’heure est en trop. | Le volume traité par personne monte et le coût unitaire baisse |
| Du travail qu’on ne faisait pas | Une décision de direction qui nomme ce travail et le priorise. S’il n’est pas nommé, il n’apparaît pas tout seul. | Une tâche nouvelle existe, avec un responsable et une date, que quelqu’un peut désigner |
| Un coût qui baisse vraiment | Une conversation sur l’effectif, un contrat prestataire ou des heures sup que presque personne ne veut avoir. | Une ligne précise du budget baisse : un poste, un contrat externe ou une équipe de renfort |
Il faut être honnête sur la troisième, parce que c’est la seule qui soit une « économie » au sens où l’entend un directeur financier, et c’est celle qu’on n’écrit presque jamais. Les deux autres sont de la croissance et de la qualité : ça vaut de l’argent, mais ça ne fait pas baisser un coût, ça le déplace. Un business case qui promet des économies et livre du volume n’a pas raté son exécution. Il a raté son étiquette.
La destination par défaut : l’heure se réabsorbe et personne ne le remarque
Quand aucune des trois n’est choisie, c’est la quatrième qui arrive — celle qui n’est pas dans le business case parce que personne ne l’écrirait : l’heure se répartit toute seule. Et elle fuit toujours par les quatre mêmes trous.
- La supervision de l’IA elle-même. Relire, corriger et relancer ce que le système renvoie est un travail nouveau qui n’existait pas avant, et il se sert directement dans le trou qu’il vient de créer.
- Ce qui attendait dans la file. Ce qui était reporté depuis des mois entre dans le trou. C’est utile, mais c’est de la substitution, pas de l’économie : le coût est toujours là et l’embouteillage a juste changé de place.
- L’extension du standard. Ce qui se réglait en une demi-page en prend trois maintenant, parce que c’est possible. La qualité monte un peu, le temps retourne à sa place et le coût ne bouge pas.
- L’éparpillement invisible. Dix minutes ici et quinze là, réparties sur quatorze personnes et trente jours. Personne ne ressent de marge, donc personne ne la réclame, et ça n’apparaît jamais en comptabilité.
La première mérite son propre chiffre, parce que c’est la plus sous-estimée. L’Automation and AI Pathfinder Survey de Bain & Company, publiée le 1er juin 2026 sur 951 entreprises dans le monde, trouve que seulement 7 % ont des agents pleinement autonomes en production : le modèle dominant, à 38 %, exige une approbation humaine, et 32 % de plus fonctionnent avec garde-fous et exceptions. Dans neuf cas sur dix il y a une personne dans la boucle, et ce temps de personne était hors du business case. La même enquête résume la conséquence en une ligne : 37 % des entreprises visaient une réduction de coûts de 11 % à 20 %, et près de 40 % de celles qui ont mesuré ont atterri dans la tranche 0 % à 10 %. Ce sont de grandes entreprises à l’échelle mondiale ; le chiffre dimensionne le problème, il ne décrit pas notre travail.
Comment écrire la destination dans le business case, avant de démarrer
La bonne nouvelle, c’est que ça se règle avec du texte, pas avec de la technologie, et ça se règle avant de signer quoi que ce soit. Quatre lignes dans le business case évitent la discussion dans six mois :
- Destination nommée. Laquelle des trois. Pas « ça améliorera l’efficacité », mais « on absorbe les 20 % de commandes en plus prévus au second semestre sans agrandir l’équipe » ou « on arrête le contrat de renfort ». Une, pas trois.
- Responsable nommé. Qui décide de ce qu’on fait de la capacité quand elle apparaît. Pas le comité : la personne qui peut changer la charge de cette équipe et s’asseoir pour l’expliquer.
- Base de référence mesurée avant. Combien d’heures coûte le processus aujourd’hui, chronométrées sur des cas réels avant de toucher à quoi que ce soit. Sans ce chiffre, dans six mois n’importe quel nombre est défendable et aucun n’est vérifiable.
- Date de conversion. Quand la capacité devient la destination choisie. Si au sixième mois ce n’est pas arrivé, l’hypothèse était fausse et il faut le dire, pas renégocier la métrique.
C’est la couche du dessus. L’arithmétique — combien d’heures, combien vaut chacune, ce que coûte le système — est déjà réglée et je ne la refais pas ici : elle est dans le guide sur comment calculer le ROI de l’automatisation avec l’IA, avec les trois blocs de coût et la formule de payback. Ce calcul te dit si tu entres. Cet article parle de ce qui arrive au numérateur une fois entré, là où il s’évapore.
Quoi regarder à six mois pour savoir si l’heure est arrivée
Quatre vérifications. Si tu ne peux pas y répondre, tu n’as pas d’économies : tu as une croyance libellée en euros.
- La base de référence, à nouveau. Le même processus, mesuré comme la première fois. Pas l’estimation de celui qui l’a monté : le chronomètre sur des cas réels.
- Le temps de supervision. Combien d’heures par mois quelqu’un passe à relire, corriger ou refaire ce que renvoie le système. Ce chiffre se soustrait, il ne s’ignore pas.
- L’indicateur de la destination. Si la destination était le volume, le volume par personne ; si c’était le coût, la ligne budgétaire ; si c’était du travail nouveau, que ce travail existe et ait un responsable. Un seul : celui qui a été écrit.
- Ce que dit l’équipe. Demander à ceux qui font le travail où est passé le trou. C’est la réponse la moins rigoureuse et la plus informative, et presque personne ne la demande.
La mécanique pour monter cette mesure — base de référence, instrumentation, ce qu’on revoit chaque mois — est dans mesurer la performance de tes automatisations. La seule chose que j’ajoute : monte-la avant d’allumer le système, parce que la base de référence ne se prend que tant qu’il n’y a encore rien à mesurer.
Quand la réponse honnête est qu’il n’y aura pas d’économies
Il y a des processus où il vaut mieux le dire d’avance : ici, tu ne vas pas économiser d’argent. Ce sont ceux qui répartissent une marge fine sur beaucoup de monde — deux heures par mois et par personne sur quarante personnes —, ceux qui marchaient déjà bien et vont marcher un peu mieux, et ceux qui dépendent d’une demande qui ne croît pas. Les automatiser peut rester justifié pour l’erreur évitée, pour le délai, pour la traçabilité, ou parce que le travail est pénible et que les gens partent. Tout cela vaut de l’argent, mais ce n’est pas une ligne de coût qui baisse, et le vendre comme telle est ce qui fait juger comme un échec un projet qui a marché.
Le motif de fond est toujours le même, développé dans pourquoi les projets d’automatisation par l’IA échouent : ce n’est presque jamais le modèle qui échoue, c’est ce qu’il y avait autour. Ici, ce qui échoue autour, c’est une phrase que personne n’a écrite.
Par où commencer
Par l’ordre, pas par l’outil. Avant de décider ce qu’on automatise, il faut savoir quels processus sont éligibles, ce qu’ils coûtent vraiment et dans quel ordre ils entrent : c’est auditer tes processus pour l’IA, et c’est de là que sort la base de référence qui te permettra ensuite de discuter avec des chiffres. Et si, en regardant les trois destinations, tu vois que le goulot n’est pas la capacité mais que personne ne changera la façon de travailler de l’équipe quand le trou apparaîtra, alors le travail c’est l’adoption de l’IA dans les équipes — playbooks par département, un responsable par processus, un dashboard d’adoption — avant une automatisation de plus.
La phrase à retenir est celle du début : si ce n’est pas écrit où va l’heure, l’heure ne va nulle part. À six mois, il n’y aura pas de discussion pour savoir si l’IA a marché — elle a marché —, mais sur le pourquoi le budget est toujours le même. Et cette discussion se gagne ou se perd le jour où on écrit le business case, pas le jour où on allume le système.