Le chronomètre ne voit qu’une partie du travail
Quand il faut justifier une automatisation, le calcul vient presque tout seul. Une tâche prend dix minutes, on la fait vingt fois par semaine : ça fait deux cents minutes, soit environ trois heures vingt. On multiplie par le nombre de semaines, puis par un coût horaire, et la calculatrice rend son verdict.
C’est propre, facile à comprendre, et ça permet de glisser un chiffre dans une cellule, un geste dont les entreprises tirent depuis longtemps un réconfort difficile à expliquer.
Le problème, ce n’est pas que ce calcul soit faux. C’est qu’il ne mesure qu’une seule chose : le temps directement consacré à la tâche. Or le coût réel du travail se loge souvent juste à côté.
Une tâche de cinq minutes peut occuper beaucoup plus de place
Prenons un responsable commercial qui doit vérifier plusieurs fois par jour si certaines opportunités appellent une relance. La vérification en elle-même est rapide : ouvrir le CRM, filtrer, parcourir quelques lignes, relire au besoin le dernier échange. Cinq minutes, à peu près.
Sauf qu’elle tombe toujours au milieu d’autre chose. Il était en train de préparer une proposition, il s’interrompt, passe dans le CRM, repère deux dossiers intéressants, ouvre un email, répond à l’un des deux. Puis il revient à sa proposition et met un moment à retrouver où il s’était arrêté.
Le chronomètre a vu cinq minutes de CRM. Pour le cerveau, c’est une autre histoire.
Gloria Mark et ses collègues ont étudié les interruptions. Leurs résultats montrent qu’on peut parfois terminer une tâche plus vite après avoir été interrompu, mais en travaillant à un rythme plus soutenu, avec davantage de stress, de frustration et d’effort. L’étude The Cost of Interrupted Work: More Speed and Stress met précisément en évidence ce décalage.
Une minute n’est pas une unité de fatigue. C’est dommage : bien des tableaux de bord y gagneraient en simplicité.
L’automatisation intéressante évite parfois que la tâche existe
On peut aborder le sujet de deux façons. La première :
Cette vérification prend cinq minutes. Essayons de la faire en une.
La seconde :
Pourquoi quelqu’un doit-il penser à effectuer cette vérification ?
Dans notre exemple commercial, un système peut surveiller les échéances et ne remonter que les dossiers réellement concernés. La tâche n’est alors pas simplement accélérée. Elle cesse de réclamer l’attention de quelqu’un.
Le commercial n’a plus à se souvenir qu’il doit vérifier, à interrompre ce qu’il fait, à ouvrir l’outil et à passer en revue des opportunités qui ne demandent aucune action. Il reçoit trois situations utiles au lieu d’en examiner trente.
Si l’on ne compare que le temps passé dans le CRM avant et après, on sous-estime sans doute une bonne part du bénéfice. Ce qu’on a économisé, c’est aussi une rupture dans la journée.
Le temps de correction appartient au coût du processus
Passons à une opération administrative. Quelqu’un récupère des données dans un email, les copie dans un outil, puis transmet le dossier. Trois minutes, presque rien.
Seulement, une fois sur vingt, une information est mal recopiée. L’erreur est découverte deux jours plus tard. Une autre personne demande une correction, il faut retrouver le message d’origine, comprendre ce qui s’est passé, modifier le dossier, parfois prévenir quelqu’un d’autre.
Les trois minutes sont faciles à mesurer. Tout ce qui suit l’erreur l’est beaucoup moins, et c’est pourtant ce qui peut rendre le processus coûteux.
Le cadre de gestion des risques du NIST invite à considérer les conséquences directes et indirectes d’un système, ses limites et le coût de ses erreurs, dans le contexte réel où il est utilisé. Il rappelle aussi que des mesures faites en environnement contrôlé peuvent différer de ce qu’on observe en usage opérationnel.
Quand on évalue une automatisation, il faut donc regarder :
le temps passé à faire, mais aussi le temps passé à refaire.
Et parfois le temps passé à expliquer pourquoi il faut refaire, qui a le don de se multiplier tout seul.
Plus vite n’a de sens que si le résultat reste bon
On réduit souvent la productivité à une division :
quantité produite / temps passé.
Mais produire plus vite quelque chose qu’il faudra corriger ensuite, c’est une performance assez théorique.
Les expérimentations sur l’IA générative montrent bien qu’il faut regarder plusieurs dimensions à la fois. Shakked Noy et Whitney Zhang ont demandé à des professionnels de réaliser différentes tâches rédactionnelles. Ceux qui utilisaient ChatGPT ont fini en moyenne plus vite, et leurs productions ont obtenu de meilleures évaluations de qualité dans le cadre de l’expérience. L’étude, publiée dans Science, mesure à la fois la vitesse et la qualité.
Ces résultats portent sur des tâches précises, dans un contexte expérimental. Ce n’est pas une promesse universelle à afficher près de la machine à café. Mais ils soulignent un point important : la bonne question n’est pas seulement
Ont-ils terminé plus vite ?
mais plutôt
Ont-ils terminé plus vite sans détériorer le résultat ?
Une automatisation qui fait gagner vingt minutes en augmentant les erreurs peut valoir moins qu’une autre qui n’en fait gagner que cinq, mais rend le processus plus constant.
Le gain peut apparaître dans la montée en compétence
Il y a un autre endroit où le chronomètre habituel regarde rarement : l’apprentissage.
Quand un nouveau collaborateur arrive dans une entreprise, une partie de son intégration consiste à découvrir ce que les anciens ne pensent même plus à expliquer. Comment répondre à tel type de client. Où trouver telle information. Ce cas particulier qui ressemble au précédent mais qui, pour une raison évidente aux initiés, n’a strictement rien à voir.
Cette connaissance mobilise le nouvel arrivant, mais aussi tous ceux qu’il vient solliciter.
L’étude de Brynjolfsson, Li et Raymond sur plus de 5 000 agents de support est instructive à cet égard. L’assistance par IA augmentait en moyenne la productivité, avec des gains bien plus marqués chez les moins expérimentés. Les auteurs observent aussi une diffusion plus rapide de certaines pratiques des agents les plus performants. L’article Generative AI at Work documente cet effet sur l’apprentissage et l’expérience.
L’automatisation ou l’assistance ne fait donc pas seulement gagner quelques secondes à chaque interaction. Elle peut raccourcir une partie de la courbe d’apprentissage. Pour une entreprise qui recrute régulièrement, cela peut peser davantage que les secondes grappillées sur chaque dossier.
Parfois, on gagne surtout en homogénéité
Imaginons cinq personnes qui exécutent le même processus. La première est d’une rigueur extrême. La deuxième aussi, sauf le vendredi. La troisième a son propre système, qu’elle juge supérieur, et elle n’a peut-être pas tort. La quatrième vient d’arriver. La cinquième sait tout, mais sera en vacances trois semaines en août.
Le souci n’est pas forcément la durée de la tâche. C’est que le résultat dépend beaucoup de la personne qui la réalise.
Une automatisation peut apporter autre chose qu’un gain de vitesse : de la régularité. La même règle appliquée, la même donnée contrôlée, la même information enregistrée, la même procédure d’escalade.
Il ne s’agit pas de supprimer toute diversité humaine, ce qui serait un projet de société plutôt inquiétant, mais de retirer de la variabilité là où elle n’apporte rien. Le collaborateur peut alors garder sa liberté d’action pour les situations qui en ont vraiment besoin.
L’information disponible au bon moment a sa propre valeur
Certains processus ne sont pas spécialement longs. Ils sont simplement mal synchronisés.
Le responsable apprend trop tard qu’une situation exige son intervention. Le commercial retrouve un prospect oublié en ouvrant son CRM par hasard. Le dirigeant constate une dérive quand elle apparaît dans le reporting mensuel. Le support comprend qu’un client est en difficulté au troisième message seulement.
Dans ces cas-là, l’automatisation fait gagner peu de temps au sens strict. Elle fait autre chose :
elle rapproche l’information du moment où elle devient utile.
Une anomalie détectée aujourd’hui peut éviter une heure de travail demain. Un dossier signalé avant son échéance ne devient peut-être jamais urgent. Une alerte bien placée n’économise parfois aucune minute à celui qui la reçoit, mais épargne deux jours d’attente au processus dans son ensemble.
Il faut donc parfois mesurer le temps de traversée du processus, et pas seulement le temps pendant lequel quelqu’un travaille réellement dessus. Un dossier peut demander vingt minutes de travail humain et rester cinq jours dans l’entreprise. Automatiser quinze de ces vingt minutes est peut-être intéressant ; ramener les cinq jours à vingt-quatre heures l’est potentiellement davantage.
Le temps économisé peut revenir par la fenêtre
L’effet inverse existe aussi. Une automatisation semble libérer du temps, puis on s’aperçoit qu’elle demande :
- une vérification systématique ;
- la correction régulière de ses résultats ;
- une surveillance quotidienne ;
- des manipulations supplémentaires en cas d’erreur ;
- une série de validations ajoutées parce que personne ne lui fait vraiment confiance.
La tâche manuelle de dix minutes a disparu, remplacée par huit minutes passées à vérifier que l’automatisation a bien fait son travail. Une victoire en demi-teinte.
C’est l’une des raisons pour lesquelles il faut évaluer les outils une fois intégrés au fonctionnement réel. L’OCDE souligne que les bénéfices de l’IA au travail peuvent être importants, mais qu’ils dépendent de la manière dont les systèmes sont déployés, des risques organisationnels et des conditions d’usage. Son étude sur l’IA au travail met côte à côte les gains perçus et les inquiétudes des travailleurs.
Le gain doit donc être mesuré une fois le nouveau fonctionnement installé, et pas seulement pendant la démonstration, où tout le monde sait exactement ce qui doit se passer. La démonstration est docile. Le mardi matin l’est beaucoup moins.
Alors, que mesurer ?
Il n’existe pas de métrique universelle, et c’est probablement mieux ainsi. Avant d’automatiser, plusieurs dimensions méritent d’être observées.
Temps d’exécution humain
Combien de temps une personne travaille-t-elle réellement sur le dossier ?
Délai complet
Combien de temps s’écoule-t-il entre le début et la fin ?
Interruptions
Combien de fois le processus réclame-t-il une intervention ?
Erreurs et reprises
Combien d’opérations doivent être corrigées ou refaites ?
Attentes
Combien de temps le dossier reste-t-il bloqué entre deux étapes ?
Escalades
Combien de situations demandent-elles une compétence supérieure ?
Qualité et homogénéité
Le résultat dépend-il beaucoup de la personne qui intervient ?
Montée en compétence
Combien de temps faut-il pour qu’un nouveau collaborateur devienne autonome ?
Et seulement ensuite, le fameux :
Heures économisées
Ce chiffre reste important. Il cesse simplement d’être seul à table.
Le meilleur gain est parfois de ne plus avoir à y penser
Une automatisation réussie n’est pas forcément celle qui fait disparaître le plus d’heures dans un tableur. C’est parfois celle qui transforme :
Il faut que je pense à vérifier ça chaque matin.
en :
Le système me préviendra si quelque chose demande mon attention.
Le nombre de minutes économisées paraît modeste. Le changement dans la journée, beaucoup moins : moins d’interruptions, moins d’informations gardées en attente dans un coin de la tête, moins de petits contrôles « au cas où », moins de dossiers devenus urgents simplement parce qu’on les avait oubliés. Et davantage de temps continu consacré à ce que la personne était en train de faire.
Le calcul classique du retour sur investissement sait très bien compter le temps passé. Il mesure beaucoup moins bien l’attention rendue. Or, dans beaucoup d’entreprises, c’est précisément elle qui manque.
Sources
- Mark, Gudith & Klocke — The Cost of Interrupted Work: More Speed and Stress
- Noy & Zhang — Experimental Evidence on the Productivity Effects of Generative Artificial Intelligence, Science
- Brynjolfsson, Li & Raymond — Generative AI at Work, Quarterly Journal of Economics
- OCDE — Using AI in the workplace: Opportunities, risks and policy responses
- NIST — Artificial Intelligence Risk Management Framework 1.0

