L'impossible mesure de la productivité de l'IA

Celui-ci est long, désolé. Je l’ai déjà écrit : j’écris surtout quand j’essaie de comprendre quelque chose. Cette question me travaille depuis un moment, et chaque fois que je croyais y avoir répondu, je trouvais un nouveau défaut dans ma réponse.

Chez Flowstate, on nous demande régulièrement comment mesurer le retour sur investissement de l’IA. Parfois, les gens veulent savoir si leurs équipes sont plus productives. Parfois, ils ont juste besoin de quelque chose de crédible à présenter au conseil d’administration quand il s’interroge sur la facture. Normal.

Mon intérêt ne s’arrête pas à une entreprise qui doit répondre à la question. Je crois que l’IA peut rendre les gens beaucoup plus capables, et j’aimerais que ce soit ce qu’on construit. Laisser les agents s’occuper des tâches répétitives de merde. Donner aux gens plus de temps pour le travail qu’ils veulent vraiment faire, y compris des choses qu’ils ne pouvaient pas se permettre de tenter avant.

C’est en grande partie ce qui sous-tend Flowstate. Mais je n’ai pas le droit de supposer que ça se produit sous prétexte que l’idée me plaît.

Je lis The Humanist Review, et putain, il y a de très bons textes là-dedans. Sérieusement, allez y jeter un œil. L’essai de Daron Acemoglu sur l’IA et le travail mérite d’être lu en entier, mais cette phrase sur le secteur privé m’est restée :¹

It will demand more pro-worker tools when it focuses on increasing productivity and innovation, rather than only labor cost-saving.

Je pense qu’il a raison. Si je défends l’IA uniquement en termes de salaires qu’elle pourrait remplacer, je ne peux pas m’étonner que la conversation tourne aux suppressions de postes. Je préférerais pouvoir expliquer ce que l’équipe sait faire maintenant et ne savait pas faire avant. Ou si la suppression d’un processus pénible a vraiment amélioré la journée de quelqu’un.

Le problème, c’est de le montrer. Quelqu’un qui dit gagner une heure par jour, c’est intéressant, mais je veux quand même savoir ce qui a changé. A-t-il fait plus de choses ? A-t-il enfin eu le temps de réfléchir sérieusement à un sujet ? Peut-être que l’outil lui a fait gagner une heure et a donné une heure de relecture à quelqu’un d’autre.

Alors j’ai cherché un moyen de comparer le travail d’une entreprise à ce qu’elle dépense pour le faire. Idéalement, quelque chose qui serve d’une équipe à l’autre, que le travail soit fait par des salariés, des prestataires, un fournisseur de services ou des agents. Je ne m’attendais pas à ce que chaque service ait la même idée de la réussite. J’espérais en revanche qu’on pourrait s’accorder sur une partie de la comptabilité.

Je suis arrivé à une approche qui mérite d’être testée, pas à une réponse que je recommanderais à tout le monde. Plusieurs de mes premières idées étaient fausses. J’ai laissé les erreurs utiles, parce qu’expliquer pourquoi elles ont échoué aide sans doute plus que de prétendre être arrivé à la version actuelle par un flair exceptionnel.

Le premier problème est facile à montrer : donnez à un agent les questions de support les plus simples, et les gens qui gèrent les difficiles peuvent soudain avoir l’air moins bons dans leur travail.

Apparemment, aider l’équipe l’a dégradée

Prenons une équipe de support qui traite 800 cas faciles et 200 cas difficiles par mois. Un cas facile demande six minutes de traitement humain. Un cas difficile en demande trente. Tous sont résolus avec le même niveau d’exigence.

Ces chiffres sont inventés.

Avant l’IA, cette équipe hypothétique avait besoin de 180 heures de traitement pour ses 1 000 cas. Ça fait 5,56 cas par heure.

Maintenant, un agent traite 600 des cas faciles. Il reste aux humains 200 cas faciles et 200 cas difficiles : 120 heures pour 400 cas, soit 3,33 par heure.

Le tableau de bord annonce une chute de 40 % du rythme de l’équipe humaine. Le temps de traitement moyen passe de 10,8 minutes à 18.

Personne n’est devenu plus lent. Les humains ont les cas les plus durs. Les cas faciles diluaient la moyenne, et ils ont disparu.

L’entreprise voit toujours ses 1 000 cas résolus et il lui faut soixante heures de traitement humain en moins. Je reviendrai sur ce que valent ces heures. Pour l’instant, demander à l’équipe de retrouver son ancienne moyenne serait une réaction assez stupide à un changement qu’on a voulu.

Confie les cas faciles à un agent

i

Faciles, humainsDifficiles, humainsFaciles, agent

Cas faciles résolus par l'agent chaque mois600 sur 800

Cas par heure humaine

5,56 → 3,33

Heures de traitement humain

180 → 120

Livraison reconnue

7 200 $ → 7 200 $

Coût affecté au traitement

7 200 $ → 5 280 $

Dépenses réelles, masse salariale inchangée

7 200 $ → 7 680 $

Les cas par heure humaine baissent de 40 %. Les mêmes 1 000 cas sont toujours résolus, et 60 heures de traitement se libèrent pour autre chose.

Ça existait avant les chatbots. Le Remote Encoding Center du service postal américain traite les images d’adresses que ses machines ne savent pas déchiffrer. Un récit de 2022 décrit des machines qui prennent les images les plus faciles et laissent aux humains celles qui demandent plus de temps à interpréter.² La vidéo de Tom Scott tournée dans ce centre reste l’un de mes exemples préférés d’un système automatisé qui transforme un processus métier, des années avant que quiconque parle d’IA. Intercom fait la même observation sur la charge de travail qui reste aux humains après l’automatisation du support.³

Il existe aussi de bonnes recherches qui utilisent justement le rythme que je viens de critiquer. Dans Generative AI at Work, Erik Brynjolfsson, Danielle Li et Lindsey Raymond mesurent en moyenne 15 % de tickets résolus en plus par heure. Leur assistant IA aidait les personnes qui répondaient aux clients. Il ne reprenait pas une file séparée de cas faciles. Ils ont aussi examiné la qualité et l’expérience du travail.⁴

Je ne conteste pas qu’on compte des cas dans ce contexte. Je conteste qu’on les juge encore comparables après avoir changé les cas que les gens reçoivent. « Cas par heure » peut servir. Il faut décrire les cas.

Et même dans mon exemple bien rangé, une journée avec moins de questions faciles peut être une journée plus exigeante. Rien dans le tableau ne dit si le travail s’est amélioré.

Qu’est-ce qu’on demande, au juste ?

A-t-on livré plus ? A-t-il fallu moins de ressources ? Le travail a-t-il produit quelque chose d’utile ? Ceux qui l’ont fait ont-ils passé une meilleure journée ?

Ce sont des questions différentes. J’ai moi-même traité la « productivité » comme si elle répondait aux quatre.

Les comptages renseignent sur le volume. Les coûts, sur ce qu’on a mis. Le délai, sur le temps d’attente de quelqu’un. Le chiffre d’affaires et la marge comptent, mais ils ne diront pas ce qui s’est passé dans chaque équipe. Un sondage qui demande aux gens s’ils se sentent plus rapides non plus.

L’expérience de METR début 2025 sur les développeurs illustre ce dernier point assez douloureusement. Des développeurs expérimentés, travaillant dans des dépôts open source qu’ils connaissaient, ont mis 19 % de temps en plus avec les outils d’IA disponibles. Après coup, ils estimaient quand même que les outils les avaient rendus 20 % plus rapides.⁵ C’est le résultat de ces développeurs et de ces outils, pas un verdict sur les agents de code en 2026. La mise à jour de février 2026 de METR dit que les outils plus récents aident probablement davantage, tout en expliquant pourquoi les effets de sélection rendent cette amélioration difficile à estimer.⁶

Il y a, inévitablement, un sondage McKinsey. Dans ses résultats d’août 2026, 80 % des répondants disaient que l’IA avait amélioré leur propre productivité. Seuls 37 % lui attribuaient un impact sur les résultats de l’entreprise.⁷ Un écart bien utile pour un cabinet de conseil. Mais ce sont aussi deux questions déclaratives différentes, donc on ne peut pas soustraire un pourcentage à l’autre et déclarer que le bénéfice manquant a été volé.

Le cadre SPACE m’a aidé à tracer une frontière autour de la question. Nicole Forsgren, Margaret-Anne Storey et leurs coauteurs soutiennent que la productivité des développeurs ne se résume pas à une seule métrique ou à une seule dimension.⁸ Je suis d’accord. Une mesure de l’efficacité de livraison peut rester utile. Elle doit juste cesser de prétendre décrire tout le reste.

J’appellerai la proposition un indice de livraison standardisé. Il porte sur le travail livré et les ressources qui le sous-tendent. Le résultat pour l’entreprise et l’expérience du travail demandent leurs propres preuves.

J’ai essayé les chiffres qu’on avait déjà

Chacun semblait raisonnable jusqu’à ce que je lui donne un exemple tordu.

Ces tableaux ne sont pas une raison de jeter toutes les mesures existantes. J’avais besoin d’une partie de plusieurs. Ce qui échouait sans cesse, c’était l’hypothèse qu’une seule pouvait faire tout le travail.

J’ai éprouvé les candidats sur onze cas inventés, dont un agent qui prend le travail facile et une équipe qui se scinde en deux. Mes notes de travail contiennent les cas, les données factices et les calculs. Prends-les comme la trace de l’évolution de l’idée, pas comme onze tests prouvant que la version finale marche dans une entreprise.

Le travail n’est pas un ticket

Ma première définition était d’une netteté plaisante : compter le travail que quelqu’un a demandé et accepté.

Malheureusement, l’entreprise que j’avais décrite n’existait pas.

Chez Flowstate, notre propre Linear est presque toujours en retard sur le travail réellement fait. Pas besoin d’une étude historique des gestionnaires de tickets pour reconnaître ce problème.

Un ingénieur remarque quelque chose, en discute, le corrige et crée un ticket quelque part en chemin. Un client ouvre une conversation dans Intercom. Une facture arrive. Un avocat donne un conseil au téléphone. L’ingénieur d’astreinte enquête parce que garder le service en marche relève déjà de sa responsabilité.

Un bouton d’approbation ne rend pas le travail légitime. Et celui qui crée l’enregistrement n’est pas forcément celui qui avait besoin du travail.

Ce que j’essaie de compter, c’est un livrable ou un service avec un but, un périmètre et une condition d’achèvement qu’on sait expliquer. Une demande peut établir ces éléments. Un objectif convenu, un problème client ou une responsabilité permanente aussi. Un ingénieur ne devrait pas avoir besoin qu’un autre service commande un correctif de vulnérabilité pour qu’il compte.

Les définitions varieront selon la fonction. Je ne vois pas comment y échapper.

Ce ne sont pas d’autres noms pour des lignes de base de données. Un changement fusionné peut être incomplet. Une facture marquée payée peut être fausse. Un client silencieux peut être satisfait, ou franchement furieux.

Les preuves sont éparpillées. Un seul incident peut laisser une conversation de support, un ticket d’ingénierie, trois pull requests et un e-mail de suivi. Compter six enregistrements n’établit pas six livrables. Le process mining orienté objet est utile ici, parce qu’il représente des événements reliés à plusieurs objets métier.⁹ Il aide à relier les enregistrements. Il ne décide pas ce que l’incident doit compter pour.

Savoir si les entreprises partageront le contexte nécessaire, et si l’IA saura l’interpréter de façon fiable, ce sont d’autres problèmes. Je les laisse hors de ce billet. Pour la comptabilité, supposons qu’on arrive à établir un compte rendu assez bon du travail et de ses coûts, par relecture humaine, par automatisation ou par les deux.

Reste une question difficile : vu les preuves, qu’est-ce qu’on compte ? Des preuves manquantes doivent laisser le travail non résolu, pas le déclarer sans valeur. Sinon, je construis une mesure de celui qui écrit les notes de fin de mission les plus enthousiastes.

Les comptables sont déjà passés par là

L’exemple du support demande un moyen de distinguer six minutes de travail de trente. Cette partie-là, au moins, n’est pas nouvelle.

L’ACCA décrit les heures standard comme un moyen de combiner des produits différents en une seule mesure de production. Elle sépare la quantité produite, la part de capacité disponible utilisée et l’efficacité.¹⁰ L’ONS utilise des indices d’activité pondérés par les coûts pour une grande part de la production des services publics.¹¹

J’emprunte cette structure : compter les livrables par type, puis utiliser des pondérations de référence stables pour les additionner. Ça donne une échelle sans exiger que chaque service interne ait un prix de vente.

L’ONS offre aussi un bon rappel à la modestie. Environ un tiers de la production des services publics couverte par sa méthodologie repose encore sur la convention « entrées égales sorties », ce qui rend la productivité constante pour cette partie.¹¹ Le fait que la mesure pondérée par les coûts existe ne veut pas dire que quelqu’un a déjà trouvé comment mesurer chaque service.

Retour au support. Avec un taux horaire de référence de 40 $, une résolution facile porte un poids de 4 $ et une résolution difficile un poids de 20 $. Multiplie chaque comptage par son poids et additionne :

D = 800 × 4 + 200 × 20 = 7 200

(1)

On obtient 7 200 $ avant l’agent et 7 200 $ après. L’entreprise a reçu les mêmes 800 résolutions faciles et 200 difficiles. En rendre 600 moins chères ne les fait pas disparaître de la production.

Écrit de façon générale :

D_t = Σ_k n_k,t s_k,b

(2)

D est la production livrée en dollars de coût de référence. n est le nombre de chaque type et s son coût de référence de bout en bout. t désigne la période mesurée et b la période de référence. La somme porte sur les types de travail.

Ces dollars ne sont ni du chiffre d’affaires ni des économies. Ils permettent de comparer des quantités de travaux différents avec un seul jeu de pondérations déclaré.

J’ai d’abord essayé de justifier la pondération en disant que le coût historique était un plancher de la valeur. Une entreprise ne paierait quand même pas quatre heures pour un travail qui en vaut moins ?

Une vision extrêmement généreuse des décisions d’entreprise. Les entreprises achètent des choses qu’elles ne devraient pas, et des investissements raisonnables peuvent échouer. L’ancien coût nous renseigne sur la production. Il ne prouve pas ce que valait le résultat.

Pour une vraie entreprise, le standard couvrirait le mélange pertinent de personnes, d’outils, d’agents et de services achetés. Là où on dispose d’estimations d’effort crédibles par rôle, des taux de référence fixes évitent qu’un même travail reçoive un poids plus gros parce qu’une personne plus chère l’a fait. Un service acheté peut plutôt demander un prix de référence comparable.

Les salaires et les factures réels vont du côté coût. Le même livrable cadré doit avoir le même poids de production à Londres et à Lisbonne. Changer de fournisseur ne doit pas le changer non plus.

Les heures standard peuvent fonctionner là où elles ont un sens. Mais un indice qui couvre du travail automatisé a besoin de plus que les heures humaines restantes, sinon ses pondérations peuvent tendre vers zéro à mesure que l’automatisation réussit. Les coûts de ressources de référence fournissent une base plus large.

Et la période de référence n’a pas besoin d’être antérieure à l’IA. Elle a besoin de preuves exploitables. « Avant que quiconque utilise ChatGPT » ne restera pas éternellement une date utile.

Ce ne serait pas des story points en dollars ?

Si, peut-être. D’abord, une correction qui agace à juste titre les ingénieurs : les story points ne sont pas des heures. Ils servaient à dimensionner un travail par rapport à d’autres, selon la complexité et l’incertitude, c’est pourquoi tant d’équipes utilisent une échelle quasi Fibonacci. Les écarts grandissent quand la confiance baisse. Convertir les points en heures n’a jamais été le but.

Le risque ici est différent. Prendre les estimations de l’équipe, les transformer en dollars et appeler le résultat objectif, ce serait la même devinette avec un meilleur emballage financier.

Les excuses de Ron Jeffries pour avoir peut-être inventé les story points sont drôles, mais elles ne répondent pas à cette objection.¹² Gergely Orosz décrit un développeur qui gonflait ses estimations dès que l’équipe a traité ses points de sprint comme un test de réussite.¹³ Un système de coûts de référence offre la même tentation. Mets un poids plus gros sur le travail et le score s’améliore.

Ce que je veux, c’est un standard pour une classe de travail livré, pas une estimation courante de la difficulté ressentie de cette tentative précise. Une estimation de planification peut monter quand on trouve un problème. Le poids de production ne devrait pas monter juste parce qu’on a passé plus de temps. Si le périmètre a changé, il faut dire ce qui a changé.

Je construirais le standard à partir d’exemples relus de travaux comparables et je le testerais sur d’autres exemples. Fige les pondérations pour la comparaison. Consigne les changements pour que ni l’équipe ni son manager ne puissent améliorer un résultat publié en les gonflant après coup.

Il reste du jugement là-dedans. Quels travaux vont ensemble ? Le cas coûteux est-il un autre type de travail, ou une tentative coûteuse de la même chose ? Un relecteur doit pouvoir contester à la fois la catégorie et le poids.

Même le choix de la moyenne compte. Une médiane décrit un cas typique. Multipliée par le volume, elle ne reproduira généralement pas la consommation totale de ressources d’une charge de travail à longue traîne. Pour un poids de coût de ressources attendu, je partirais normalement d’une moyenne pour une classe bien définie, en montrant la dispersion. Je ne choisirais pas la statistique qui donne le plus beau résultat à l’indice.

L’IA pourrait aider à proposer des pondérations. Les travaux d’Anthropic sur l’estimation de la durée des tâches ont trouvé une information de classement utile, mais Claude surestimait les courtes tâches logicielles et sous-estimait les longues.¹⁴ Ranger des travaux à peu près dans le bon ordre ne suffit pas quand leurs poids relatifs déterminent le résultat.

Un système de points pourrait adopter des contrôles similaires. Je ne peux pas crier victoire en changeant le nom. Le test, c’est de savoir si une autre équipe peut appliquer les définitions et si un désaccord raisonnable change la conclusion.

Si ça ne tient pas, alors oui, j’ai réinventé les story points en dollars.

Est-ce qu’on a fini, ou est-ce qu’on a juste arrêté d’en parler ?

Fin donne un exemple concret utile. Intercom compte les résolutions confirmées et les résolutions supposées, quand le client part après une réponse sans demander plus d’aide. Sa documentation précise aussi que la facturation est annulée si le client revient dans la même conversation pour demander de l’aide supplémentaire.¹⁵

C’est une règle de facturation claire. Elle laisse une question sur les clients silencieux, mais il serait injuste d’en discuter sans la règle d’annulation. Et les conversations closes par des humains méritent le même examen.

Pour cet indice, je préciserais ce qui compte comme achèvement pour chaque type de travail. Parfois il y a une acceptation explicite. Parfois un test, une preuve de paiement ou une preuve de livraison. Parfois on n’a que des signaux indirects et il faut montrer cette incertitude. « Clos » ne peut pas trancher tous les cas.

Les reprises ne sont pas simples non plus. Une conversation rouverte peut être une réponse ratée ou une nouvelle question. Un retour en arrière sur du code peut corriger un défaut ou refléter un changement de décision produit. Un litige ultérieur n’invalide pas automatiquement le conseil juridique qui l’a précédé.

Il faut une règle pour dire quelles corrections annulent une production antérieure, de combien, et lesquelles relèvent d’un nouveau périmètre. Utilise-la pour les humains comme pour les agents. Compare le travail qui a eu la même occasion de révéler ses défauts, et révise la période d’origine quand le crédit antérieur ne tient plus. Une file fraîchement vidée ne devrait pas paraître meilleure simplement parce que personne n’a eu le temps de se plaindre.

Le contrôle consomme aussi des ressources. Les scénarios de relecture et de reprise de GDPval montrent à quel point l’avantage de coût apparent peut changer une fois la relecture d’un expert incluse. Ce sont des scénarios modélisés, pas des économies observées en entreprise, et l’article note que les coûts équivalents de relecture et d’échec ne sont pas inclus pour sa référence humaine.¹⁶ Je voudrais que tout le flux de travail soit chiffré des deux côtés.

La planification a révélé une autre erreur de ma première version. Je proposais de ne donner aucun crédit à un cycle de prévision si les ajustements du planificateur le dégradaient. C’était confondre achever le travail et obtenir un résultat favorable.

La valeur ajoutée de la prévision est utile pour évaluer des ajustements sur des observations comparables.¹⁷ Ce n’est pas un interrupteur universel qui dit si la planification a eu lieu. Une prévision solide peut remplir son objectif et se révéler fausse quand même. Un bon conseil juridique peut faire capoter un contrat. Une expérience peut être utile justement parce qu’elle nous dit d’abandonner le projet.

Si la mesure ne reconnaît que les bonnes nouvelles, elle passera à côté de bon travail.

Quarante brouillons de quoi ?

Donnons maintenant à l’indice du travail de marketing.

Une équipe produisait quatre variantes de publicité par semaine. Chacune prenait deux heures, ce qui donne à chacune un poids de référence de 80 $ à notre taux illustratif. La production de la semaine était de 320 $.

Avec l’IA, elle en produit quarante. Applique le poids à chaque fichier généré et la production devient 3 200 $, alors que les résultats de la campagne bougent à peine.

J’y ai d’abord vu la preuve que la mesure était cassée. Elle l’est peut-être, mais pas pour la raison que je croyais. Quarante livrables distincts et comparables peuvent représenter dix fois la production sans être dix fois plus utiles. J’avais déjà dit que je ne mesurais pas la valeur, et j’attendais quand même du chiffre qu’il la mesure.

L’autre question, c’est de savoir si ces quarante fichiers étaient quarante livrables. Ce pourraient être des brouillons servant à choisir ce qui entre dans une seule expérience.

Pour cet exemple, supposons que le service est une expérience de campagne pour une audience précise, avec une question de test définie et des exigences de reporting. Je compterais cette expérience. Générer quatre brouillons ou quarante ne change pas l’unité. Leur production et leur sélection font partie de son coût.

Si l’équipe mène une autre expérience réellement distincte, de portée comparable, c’est plus de production. Appeler dix variations du même test dix expériences, non. Il faudrait la définition avant de voir le résultat, pas une explication inventive après coup.

Dans un autre flux de travail, produire des variantes prêtes à l’emploi peut être le service lui-même. Alors les variantes individuelles peuvent être la bonne unité. C’est une autre frontière de reporting, et je ne passerais pas de l’une à l’autre selon celle qui donne le plus gros chiffre.

Tom Cunningham et Parker Whitfill, de METR, m’ont aidé à comprendre pourquoi la question de la valeur reste à part. Ils distinguent l’effet de l’IA sur l’ancien mélange de tâches, sur le nouveau mélange et sur la valeur produite. Rendre quelque chose bon marché change ce que les gens choisissent de tenter, en plus de la vitesse à laquelle ils terminent la charge d’hier.¹⁸

Je suis d’accord pour séparer ces questions. Un comptage de production ne devient pas une mesure de valeur parce que le travail coûtait cher avant. L’approbation d’un manager ne rend pas non plus quarante variantes quarante fois plus utiles qu’une seule.

Que se passe-t-il quand une étape disparaît ?

Le logiciel casse le comptage dans l’autre sens.

Supposons qu’une fonctionnalité demandait trois heures de spécification, dix heures d’implémentation et deux heures de relecture. À 40 $ de l’heure, le coût de référence est de 600 $.

Maintenant, un agent peut construire la même fonctionnalité à partir du contexte déjà disponible. L’utilisation coûte 25 $. La relecture humaine prend trois heures, soit 120 $ d’effort à notre taux. Les ressources modélisées utilisées totalisent 145 $. Supposons que la fonctionnalité respecte les mêmes exigences et les mêmes contrôles de qualité.

Si je compte les anciennes étapes du processus, je perds la spécification. L’implémentation et la relecture qui survivent ont, avec les anciens poids, un total de 480 $. Pourtant l’entreprise a reçu la fonctionnalité entière.

Compter les étapes fait perdre 20 % de la production parce qu’un document est devenu inutile. Compter la fonctionnalité entière garde la comparaison intacte.

Ça ne marche que si l’étape était vraiment inutile. Supprimer un contrôle de sécurité ou abandonner une exigence changerait ce qui a été livré. « La même fonctionnalité, au même niveau d’exigence » porte une part importante de cette phrase.

« La fonctionnalité entière » aussi. Ça ne peut pas désigner tout ce qui s’appelle une demande. Découpe une fonctionnalité en trois tickets et elle ne devrait pas recevoir trois poids de fonctionnalité. Regroupe trois vraies fonctionnalités dans une epic et deux ne devraient pas disparaître.

Il y a aussi les parents et les enfants. Si la fonctionnalité de bout en bout inclut déjà la conception et la relecture, je ne peux pas ajouter son poids au même travail compté une deuxième fois par ces équipes. On peut répartir les contributions à l’intérieur du total. On ne peut pas créer de production supplémentaire pour l’entreprise en la déplaçant d’un service à l’autre.

Essaie de réorganiser le même travail sans changer ce qui est livré. Le total de l’entreprise doit rester en place. Essaie d’en externaliser une partie. Même test.

Les projets longs demandent aussi de l’attention au calendrier. J’utiliserais des comparaisons cumulées ou des jalons utiles en eux-mêmes, dont les poids s’additionnent au périmètre convenu. Sinon, des mois de coûts débouchent sur un énorme pic d’achèvement, et un tableau de bord mensuel passe la majeure partie de l’année à induire en erreur.

D’accord. Qu’est-ce qui compte comme la même fonctionnalité ?

J’ai été plutôt indulgent avec moi-même sur cette fonctionnalité de quinze heures. Une correction d’orthographe et un système de facturation peuvent tous deux s’appeler une fonctionnalité. Les ranger dans une seule catégorie nous ramènerait droit au problème du support.

Prenons quelque chose de plus précis : un export CSV de l’historique d’audit d’un client. Un administrateur de compte autorisé doit exporter huit champs précis sur une plage de dates choisie. Le cahier des charges définit les limites de volume et de temps de réponse, les exigences de précision et les contrôles d’accès. Il doit fonctionner dans le produit en production.

Je compterais une capacité d’export livrée de ce périmètre. Pas le bouton, le endpoint, les tests et la documentation séparément. Je ne la compterais pas non plus à chaque téléchargement du fichier. Ici, on mesure la livraison d’un changement, pas l’exploitation du produit ensuite.

Dans cette entreprise fictive, supposons qu’on trouve cinq changements antérieurs d’export de rapports, de portée de données, de comportement utilisateur, de limites d’exploitation et d’exigences d’assurance comparables. Sur la même base de prix de référence, leurs coûts de bout en bout étaient de 480 $, 560 $, 600 $, 640 $ et 720 $. La moyenne est de 600 $.

C’est comme ça qu’on pourrait construire le poids. Cinq chiffres commodes ne prouvent pas qu’il est bon. Le relecteur doit vérifier ce qui rendait ces travaux comparables, au lieu de chercher simplement le mot « export ». On testerait ensuite la classe et son poids sur d’autres travaux.

On a maintenant une définition à discuter :

Remarque que la classe ne dépend ni de l’implémentation choisie, ni du nombre de pull requests, ni du salaire de l’ingénieur. Ces éléments peuvent affecter le coût sans changer ce que l’entreprise a reçu.

Le flux d’événements, c’est autre chose. Il change le comportement exigé. Il faudrait une classe de référence adaptée ou un autre traitement explicite pour ce périmètre, appliqué de la même façon au travail antérieur et postérieur. On ne peut pas inventer une catégorie « export très complexe » après une construction coûteuse pour lui attribuer plus de production.

Et une nouvelle plateforme de reporting sans précédent crédible ? Je ne la forcerais pas dans cette classe. Je décrirais son périmètre, ses coûts et ses jalons utiles, et je la laisserais hors de cette série comparable tant qu’on n’a pas de base pour l’y inclure.

Son coût doit rester visible. Le rapport doit rapprocher le service mesuré, le travail non rattaché et le reste des dépenses. Sinon, je sélectionnerais les succès faciles à classer et je laisserais tout l’investissement délicat ailleurs.

C’est la partie la plus difficile de la proposition. Un autre relecteur pourrait rejeter la classe export ou son poids de 600 $. Au moins, on peut localiser le désaccord et voir si un autre choix raisonnable change la réponse.

Une partie du travail d’ingénierie peut se prêter à des classes comme celle-ci. Une autre non. Le découvrir serait un résultat utile, même si ça ruine mon espoir d’un total pour toute l’entreprise.

Les soixante heures n’ont pas quitté la paie

Retour au support, et à l’économie que j’étais tenté d’annoncer.

À l’origine, 180 heures de traitement à 40 $ donnaient 7 200 $. Après, 120 heures donnent 4 800 $. Ajoute une facturation illustrative de l’agent de 0,80 $ pour chacune de ses 600 résolutions et le coût de traitement affecté est de 5 280 $.

Ça fait 1 920 $ de moins. Sauf que les gens sont toujours employés aux mêmes conditions.

Supposons que la masse salariale de cet exemple simplifié reste à 7 200 $. Ajoute la facture de l’agent de 480 $ et l’entreprise dépense 7 680 $. Le besoin de traitement a baissé. La facture a monté.

Robert Kaplan et Steven Anderson font cette distinction dans leurs travaux sur le calcul des coûts par activité piloté par le temps : la capacité inutilisée offre des occasions d’économies ou de croissance.¹⁹ Je suis d’accord, et ça change la règle ici. Les heures libérées vont sur une ligne de capacité. Les économies demandent la preuve d’une baisse des dépenses ou un compte crédible des dépenses évitées.

Les soixante heures pourraient permettre de servir plus de clients sans embauche. Elles pourraient réduire les heures supplémentaires, absorber les pics ou rendre le travail moins frénétique. Elles pourraient aussi rester inutilisées. Je ne veux pas que la comptabilité choisisse un résultat avant que l’entreprise ait fait quoi que ce soit de ce temps.

Pour l’indice principal d’efficacité des coûts, j’utiliserais le coût de fourniture du service mesuré, y compris le travail raté et la capacité laissée inutilisée. Compare la croissance de la livraison à la croissance des coûts :

E_t = 100 × D_t / D_bC_t / C_b

(3)

D est le total livré. C est le coût dans la même frontière de reporting. E part de 100, donc 100 signifie aucun changement de l’efficacité des coûts.

Dans l’exemple du support, la livraison reste à 7 200 $ alors que les dépenses passent de 7 200 $ à 7 680 $. L’indice vaut 93,8 : l’efficacité des coûts a baissé de 6,25 % ce mois-là.

Avec le modèle séparé du coût de traitement affecté, le ratio est de 136,4. C’est l’amélioration des ressources nécessaires au flux de travail, pas un gain financier réalisé. Les deux chiffres sont utiles une fois étiquetés. Mettre « économies de l’IA » au-dessus de l’un ou de l’autre épargnerait beaucoup d’explications et créerait un problème bien plus gros.

Pour un vrai compte de coûts, inclus la masse salariale et les charges, les prestataires, les services achetés, les licences, l’usage des agents et l’infrastructure. La relecture, la maintenance et la mesure consomment aussi des ressources. N’ajoute pas deux fois la main-d’œuvre de relecture si elle est déjà dans le total de la paie.

La facture d’un fournisseur entre une fois dans le compte, à côté de notre propre supervision. On n’invente pas en plus sa masse salariale interne et ses coûts de tokens. L’externalisation ne doit pas faire disparaître le coût d’achat, ni le compter deux fois.

Il faut aussi une base cohérente dans le temps. Les charges d’une période ne sont pas des décaissements. Un développement payé ce trimestre peut servir plusieurs années. Choisis le traitement et déclare-le. Ne passe pas le développement en charges dans une comparaison pour l’étaler sur plusieurs années dans une autre. L’exemple du support suppose que charges et décaissements coïncident.

Les prix comptent aussi. Des tokens moins chers améliorent l’économie même si rien ne change dans le flux de travail. Une augmentation de salaire fait l’inverse. Quand on peut comparer les quantités d’intrants et la qualité, une vue à prix constants aide à séparer les variations de prix de l’utilisation des ressources. Sans ces preuves, montre le résultat de coût nominal et explique ses limites.

Enfin, soixante heures de traitement en moins ne prouvent pas qu’un poste entier peut disparaître. Les effectifs doivent toujours couvrir le travail quand il arrive. La question suivante porte sur la demande et les engagements de service, pas sur une division par un nombre d’heures qui arrange.

L’erreur que je croyais voir s’annuler

J’avais écrit qu’un mauvais poids s’annulerait quand on compare une équipe à elle-même. La même erreur apparaît des deux côtés, donc ça va, non ?

Non. Pas quand le mélange bouge.

Prenons deux types de travail. Pour cet exemple, posons que leurs poids de référence corrects sont de 1 $ pour le travail simple et de 10 $ pour le travail complexe. Au premier trimestre, l’équipe termine quatre-vingt-dix unités simples et une unité complexe. Au second, dix simples et neuf complexes. La production correctement pondérée est de 100 $ aux deux trimestres. Gardons aussi les ressources totales inchangées.

Donnons maintenant au travail complexe un poids erroné de 20 $.

On annonce 72,7 % de croissance là où il n’y en avait aucune dans la mesure correctement pondérée. L’erreur est restée fixe. On a fait plus du travail qu’on surévaluait.

Un mauvais poids peut fabriquer de la croissance

i

Croissance réelle 0,0 %. L'index annonce +72,7 %. Même travail, autre mélange.

À quel point le poids du travail complexe est-il faux ?+100 %

Unités complexes au trimestre 29

Se tromper aussi du même montant sur le poids du travail simple

La relation est la suivante :

ĜG = 1 + ē_t1 + ē_b,ē_t = Σ_k w_k,t e_k

(4)

G est le ratio de croissance avec les poids corrects de l’exemple. Ĝ utilise nos poids estimés. e est l’erreur de poids proportionnelle de chaque type et w sa part de la production correctement pondérée. ē est l’erreur moyenne une fois pondérée par ces parts.

Les erreurs s’annulent quand cette moyenne est la même aux deux périodes. Un mélange de travail inchangé suffirait. Se tromper du même pourcentage sur tous les poids aussi. D’autres combinaisons peuvent aussi s’annuler. Ces deux-là ne sont pas les seules possibilités.

Le contrôle pratique consiste à regarder ce qui a gagné des parts. Si l’amélioration apparente vient d’une catégorie dont on se fie à peine au poids, essaie des alternatives plausibles. Le gain survit-il ? Les résultats par type devraient figurer à côté du total, sans qu’il faille une demande spéciale de celui qui doute.

Les catégories peuvent cacher un autre glissement. Si l’agent prend les plus faciles des « cas faciles », même mon modèle de support à deux catégories peut s’ajuster trop peu. Il faut aussi vérifier ce qui a changé à l’intérieur de chaque catégorie.

On peut aussi mieux voir le travail

Même avec des poids parfaits, les enregistrements peuvent nous tromper.

Supposons que la production réelle croisse de 10 %. On capte 80 % de la production correctement pondérée à la première période et 84 % à la seconde. La comparaison observée devient :

D̂_tD̂_b = 1,10 × 0,840,80 = 1,155

(5)

Le tableau de bord annonce 15,5 % de croissance. Quatre points de pourcentage de meilleure couverture ont ajouté 5,5 points à la croissance apparente. Sans croissance réelle, ce même changement de couverture en fabriquerait 5 %.

Un agent peut laisser un journal exhaustif d’un travail qu’une personne aurait fini au fil d’une conversation. De meilleurs enregistrements seraient les bienvenus. Ils ne seraient pas, à eux seuls, plus de production.

« Couverture » dans cette équation désigne la part de la production captée, pondérée sur la même base de référence. Elle ne désigne pas le pourcentage de la masse salariale rattaché à une intégration, les sièges connectés ou les dépenses visibles.

Savoir où est passé 80 % de l’argent ne nous dit pas qu’on a trouvé 80 % du travail. Il faut pour ça d’autres hypothèses sur le travail observé et le travail manquant. Garde la couverture des dépenses comme contrôle financier utile. Ne la mets pas dans l’équation de production sous prétexte qu’elle est plus facile à obtenir.

C’est pourquoi j’ai gardé l’exemple de la couverture, même si je laisse le système de collecte des preuves hors de ce billet. Un changement dans ce qu’on peut voir change la mesure, quelle que soit la façon dont on collecte les enregistrements.

Plus d’enregistrements ne règleront pas ça automatiquement. Le volume peut réduire le bruit aléatoire. Un biais constant peut rester. Quatre trimestres de données ne divisent pas non plus automatiquement l’incertitude par deux. Des erreurs partagées d’un trimestre à l’autre ne se comportent pas comme des erreurs indépendantes.

Je préfère publier une série plus étroite qu’on observe de façon cohérente plutôt que d’affirmer quelque chose sur toute l’entreprise avec une couverture qu’on ne peut pas défendre. Il faut une frontière claire, les mêmes fenêtres de suivi et des contrôles des changements d’enregistrement. Le travail hors de cette frontière reste visible comme du travail non mesuré.

Des simulations antérieures m’ont aidé à explorer ces erreurs. Je n’ai pas conservé leurs fourchettes numériques comme preuve de la précision de la méthode. Il faudrait publier l’implémentation et les hypothèses, puis les vérifier sur du travail réel. Les exemples d’ici établissent les modes de défaillance sans prétendre savoir à quelle fréquence chacun se produira.

À terme, même la base de référence pose problème

On ne peut pas figer un seul jeu de pondérations pour toujours en supposant que l’entreprise restera obligeamment comparable. Les services changent. Certains disparaissent, et les nouveaux ne viennent pas avec un ancien prix.

Une option consiste à mettre à jour les pondérations périodiquement, en comparant chaque paire de périodes adjacentes avec les mêmes poids. Un chaînage annuel avec les poids de l’année précédente s’écrit :

L_t = Σ_k n_k,t s_k,t−1Σ_k n_k,t−1 s_k,t−1

(6)

Le numérateur compte la production de cette année avec les poids de l’an dernier. Le dénominateur compte la production de l’an dernier avec ces mêmes poids. Multiplie les maillons pour un indice qui court plus longtemps.

Ça évite d’appeler un changement de pondérations un changement de production. Il y a aussi un revers : des composantes chaînées séparément ne s’additionnent généralement pas au total chaîné. Le BEA met explicitement en garde contre le fait de traiter les composantes en dollars chaînés comme additives.²⁰

Construis donc la série de l’entreprise à partir de son propre ensemble de livrables sans recouvrement. N’additionne pas des tableaux de bord d’équipes conçus indépendamment en espérant qu’ils mesurent des choses compatibles. Certains travaux internes peuvent être utiles dans une vue par fonction tout en étant déjà inclus dans le livrable de bout en bout de l’entreprise.

Une classification modifiée demande aussi un pont : une période de recouvrement, une reconstruction crédible de la série antérieure ou une rupture déclarée. Le chaînage ne réparera ni une mauvaise définition de service ni du travail manquant qu’on vient seulement de trouver.

On peut en sortir avec des comparaisons utiles par fonction et aucun total défendable pour l’entreprise. Je l’accepterais. Ce serait mieux que d’inventer un total parce que la commande de départ en demandait un.

Parfois, le bon travail réduit le compteur

Supposons que l’ingénierie corrige le défaut à l’origine de mille conversations de support. Notre indice de cas de support annonce moins de cas traités.

Il le doit. Il y avait moins de cas. L’erreur serait de décider que l’entreprise est devenue moins productive.

À une frontière plus large, on essaie d’aider les clients à utiliser le produit avec succès. Maintenir ou améliorer ce service avec moins de contacts évitables peut être un gain substantiel. Le comptage étroit des cas a besoin de la définition de service plus large ou des mesures de résultat à côté.

La fiabilité et la prévention ont le même problème. Une semaine d’astreinte tranquille peut être une bonne semaine. Une intervention de conformité utile peut empêcher un dossier d’exister.

Pour ces fonctions, je testerais des unités fondées sur le service maintenu sur une période : ce qu’on a gardé en marche, pour qui, sous quelle charge et quel risque, selon quel standard. Une ligne dans le planning d’astreinte ne suffit pas. Je ne ramènerais pas non plus la production d’un mois à zéro parce qu’un seuil a été manqué. L’ajustement de qualité doit refléter la défaillance plutôt que de tout faire dépendre d’un seul interrupteur.

Ces unités sont plus difficiles à définir. Ça fait partie du problème que j’essaie de comprendre, pas de quelque chose qu’un compteur de tickets nous permet d’éviter.

Et le travail qu’on ne pouvait pas faire avant ?

Une équipe d’audit qui échantillonnait les transactions peut maintenant toutes les examiner. Mets l’ancien coût humain hypothétique en face de chaque contrôle supplémentaire et la production revendiquée devient énorme.

Mais personne n’allait forcément acheter ce processus manuel. Plus de contrôles ne signifient pas non plus une hausse proportionnelle de l’assurance.

Si le nouveau service est comparable à quelque chose qu’on mesure déjà, on peut tenir compte du changement de périmètre ou de qualité sur cette base. Sinon, je rapporterais séparément la capacité, son coût et ce qu’on attend d’elle, le temps d’établir une définition utile.

J’appelle ça un registre de capacités. Ça ne veut pas dire que la dépense peut être immobilisée. Ça ne veut pas dire qu’on peut cacher du travail coûteux sous « innovation » chaque fois que le ratio d’efficacité déçoit. Le compte doit toujours se rapprocher des finances.

Une fois le service répétable et définissable, il peut rejoindre l’indice de livraison selon une règle d’introduction explicite. Être rendu possible par l’IA ne devrait pas le maintenir dehors pour toujours.

C’est là que revient l’argument d’Acemoglu sur la demande des entreprises. Si les entreprises ne récompensent que les économies de main-d’œuvre, elles n’achèteront que des outils qui remplacent des gens.¹ Un registre de capacités est une façon de récompenser l’autre sorte.

Ma contribution ici est plus modeste. Donner à l’entreprise un endroit pour expliquer ce que l’investissement rend possible, plutôt que d’exiger que chaque projet se justifie comme du vieux travail moins cher. Un responsable, des preuves et une date de revue seraient un bon début. « C’est de l’IA » n’est pas un dossier d’investissement.

Acemoglu s’oppose aussi aux distorsions fiscales qui favorisent le capital par rapport au travail, en s’appuyant sur des travaux avec Andrea Manera et Pascual Restrepo.¹²¹ Je suis d’accord pour supprimer une préférence artificielle pour le remplacement. Pour ce billet, pourtant, la décision se prend à l’intérieur du budget : combien coûte maintenant le service existant, et que peut-on faire qu’on ne pouvait pas faire avant ?

Le registre ne prendra pas cette décision à notre place. Il devrait rendre plus difficile de l’éviter.

Est-ce que je mettrais ça sous les yeux d’un directeur financier ?

Oui, mais avec le reste du compte, pas comme une note pour l’entreprise.

Kent Beck et Gergely Orosz plaident fortement contre les objectifs d’effort et de production dans leur réponse à McKinsey. À propos de ses métriques sur mesure, ils écrivent : « Customers don’t care. Executives don’t care. Investors don’t care. » (Les clients s’en fichent. Les dirigeants s’en fichent. Les investisseurs s’en fichent.)²²

Je pense que ce rejet va trop loin. Un directeur financier peut raisonnablement demander si on peut fournir le même service de paie, au même niveau d’exigence, avec moins de ressources. On ne devrait pas avoir à attendre un mouvement du bénéfice de l’entreprise pour chercher pourquoi il est devenu plus cher.

Leur argument est plus nuancé que cette phrase. Ils reconnaissent aussi l’usage de l’effort et de la production pour diagnostiquer des problèmes, et les dangers de juger les gens uniquement sur les résultats.¹³ Dans sa section finale, Orosz recommande d’utiliser l’effort et la production pour enquêter sur les problèmes plutôt que d’en faire les mesures publiques de la réussite.

C’est le désaccord plus étroit qui vaut la peine d’être eu. Je pense qu’une comparaison régulière de la production et du coût d’un service défini peut aider, à côté des résultats. Elle doit justifier son coût et son effet sur les comportements. Un beau tableau de bord qui transforme l’équipe en améliorateurs de tableau de bord à plein temps a échoué.

Voilà à peu près ce que je voudrais voir :

Les mesures de résultat doivent différer selon la fonction. Les commandes ont leur place dans une discussion commerciale. Elles ne forment pas un test d’acceptation sensé pour un conseil juridique. Je préfère montrer ces différences plutôt que les cacher dans un « multiplicateur d’impact ».

Au niveau de l’entreprise, le compte financier doit aussi refléter la manière dont on a acheté le travail. Le chiffre d’affaires par salarié peut monter après une externalisation même si le coût total de livraison augmente. Ajoute les services achetés et les coûts d’IA pertinents avant de décider que l’entreprise est devenue plus efficace. Le chiffre d’affaires a d’autres moteurs, donc ce ratio n’attribuera pas le changement à l’IA.

Je n’utiliserais pas l’indice de livraison pour classer des individus. Ses pondérations décrivent des classes de travail, pas la contribution complète d’une personne. Le mentorat, les interruptions et l’aide apportée à quelqu’un pour finir un travail n’entrent pas dans le comptage de production d’un individu. Lie la rémunération à l’indice et on donne aux gens une raison de plaider pour des poids plus gros et plus de travail comptable.

Même comparer le travail assisté par l’IA et le travail uniquement humain demande le même soin que l’exemple d’ouverture. Les affectations peuvent différer à l’intérieur d’une catégorie. Savoir qu’un agent est intervenu ne prouve pas qu’il a causé l’amélioration.

Et un artefact terminé ne prouve pas que la personne responsable l’a compris. C’est un autre problème, surtout si on prétend que le but est de rendre les gens plus capables.

Le test que je n’ai pas encore fait

J’ai montré comment se comportent quelques calculs avec des entrées que j’ai choisies. J’ai emprunté des méthodes comptables et appris des objections des autres. Rien de tout ça ne me dit si deux équipes peuvent utiliser cette proposition sur du vrai travail et arriver à un résultat utile.

C’est le prochain test.

Je commencerais par trois contextes : un flux répétable de cas ou de transactions, un flux de projet et un service continu. Pour chacun, écris l’unité, le périmètre et la frontière de reporting avant de voir les résultats. Ajoute la règle d’achèvement, le traitement de la qualité, les pondérations de référence et la base de coûts. Dis ce qui arrive au travail non rattaché et aux corrections ultérieures.

Donne ensuite les mêmes preuves à une autre équipe compétente. Peut-elle reproduire le calcul ? Sur quoi est-elle en désaccord quant à ce qui doit y figurer ?

L’arithmétique devrait être facile à accorder. L’exemple de l’export montre où se jouera la vraie dispute. Si deux choix raisonnables de catégorie inversent le résultat principal, le rapport doit le montrer plutôt que de trancher le désaccord avec une décimale.

Choisis les classes de référence et estime leurs poids sur un jeu de travaux, puis teste-les sur un autre. Inclus dans la relecture les enregistrements exclus et le travail hors du système de suivi principal. Ne redessine pas les catégories jusqu’à ce que l’historique soit convaincant.

Répète les tests de ticket scindé, de ticket fusionné, de réorganisation et d’externalisation. Vérifie les changements d’enregistrement. Le total de l’entreprise ne devrait pas bouger quand on n’a changé que la façon de décrire ou d’acheter le même travail.

Teste d’abord cette comptabilité avec un compte rendu du travail établi de façon indépendante. Savoir si une machine peut retrouver ce compte rendu à partir des systèmes disponibles est un test d’implémentation ultérieur. Si des humains disposant de preuves suffisantes ne s’accordent pas sur les unités, un meilleur classifieur ne sauvera pas la définition.

Tester si l’IA a causé une amélioration est un autre travail. L’accès aléatoire peut aider quand il est faisable, comme un déploiement échelonné soigneusement conçu avec un groupe de comparaison crédible. L’apprentissage, les effets de débordement, la sélection des tâches et un suivi de qualité équivalent comptent tous. Les adopteurs enthousiastes et les réticents ne sont pas automatiquement comparables parce qu’ils ont le même intitulé de poste.

Quelle précision faut-il à la mesure ? Ça dépend de la décision. Un signal approximatif pour savoir où enquêter n’a pas la même exigence que des preuves servant à réduire les effectifs ou à déclarer des économies. L’erreur acceptable devrait suivre cette décision, pas une taille d’échantillon d’audit universelle.

Publie les définitions, le calcul et la politique de révision avec le résultat. Mon critère, c’est qu’une autre équipe puisse appliquer la méthode, contester ses choix et voir si la conclusion tient. La reconnaissance d’un comptable ou une équation impressionnante ne suffirait pas.

J’ai maintenant une meilleure question

J’ai commencé par « l’IA nous a-t-elle rendus plus productifs ? ». Je veux maintenant savoir quel service a changé, si on compte la même chose et où est allée la capacité libérée. Ces questions sont moins pratiques sur une diapo. Elles sont bien plus utiles quand quelqu’un demande ce qu’on devrait faire ensuite.

Ça compte pour Flowstate parce que relier le travail aux ressources qui le soutiennent est justement le problème qu’on essaie de résoudre. Je ne veux pas que le produit dépende de la défense d’une formule à laquelle je me suis attaché en écrivant un billet de blog. Si le vrai travail casse le modèle, le modèle doit changer.

Je veux toujours que les agents retirent le travail répétitif de la journée des gens. Je veux qu’une entreprise reconnaisse le bénéfice quand quelqu’un a le temps de réfléchir, aide un collègue ou tente quelque chose de nouveau, plutôt que d’exiger plus de tickets pour prouver que l’achat du logiciel a marché.

Je ne sais pas combien de tout ça tient dans un seul indice. Peut-être moins que je l’espérais. Un résultat utile pourrait être un ensemble de comparaisons auxquelles on se fie, avec les trous laissés bien visibles.

Quand l’agent prend les cas faciles, les gens qui restent ne devraient pas avoir à fabriquer de l’activité pour se défendre. Quand quelqu’un revendique une économie, on devrait pouvoir demander où elle est passée. Et quand le chiffre proposé ne répond pas à la question, on devrait le dire avant qu’il devienne l’objectif de quelqu’un.

Je suis parti chercher une mesure. J’ai fini avec une méthode que je testerais et une assez longue liste de raisons d’être prudent. Vu mon point de départ, je crois que c’est un progrès.

Notes techniques

Voici les calculs derrière les exemples. Les hypothèses comptent : une identité peut être exacte sans nous dire avec quelle précision on peut estimer ses entrées dans une entreprise. Les ratios ci-dessous supposent des poids de référence positifs et des dénominateurs non nuls.

L’identité de l’erreur de pondération

Soit s le poids de référence correct, posé comme tel, du type k, et le poids estimé :

ŝ_k = s_k(1 + e_k)

(7)

Pour une production comptée avec exactitude, on définit le total correctement pondéré et la part de chaque type ainsi :

D_t = Σ_k n_k,t s_k,w_k,t = n_k,t s_kD_t

(8)

Alors :

D̂_t = Σ_k n_k,t s_k(1 + e_k) = D_t(1 + ē_t)

(9)

Le ratio entre deux périodes donne l’identité utilisée plus haut. Elle suppose des erreurs de poids proportionnelles fixes par type, des quantités exactes et une définition commune de la production. Elle ne modélise ni le travail omis, ni les classifications qui changent, ni les frontières incertaines des livrables.

Pour de petites erreurs, l’erreur relative du ratio de croissance vaut approximativement :

ĜG − 1 ≈ Σ_k (w_k,t − w_k,b) e_k

(10)

Si, de plus, les erreurs par type sont des variables aléatoires indépendantes, de moyenne nulle et d’écart type commun, l’écart type au premier ordre de cette erreur du ratio de croissance vaut :

σ_G ≈ σ_e √Σ_k (w_k,t − w_k,b)²

(11)

Sous ces hypothèses précises, transférer vingt points de pourcentage de part de production entre deux types, avec un écart type d’erreur de 20 %, donne environ 5,66 % d’erreur relative sur le ratio de croissance, à un écart type. Ce n’est pas une fourchette d’erreur établie empiriquement, et ce n’est pas en général le même nombre de points de pourcentage de croissance publiée. Des standards corrélés ou systématiquement biaisés demandent un autre calcul.

La couverture est un concept de production dans l’identité

Dans l’exemple de la seule couverture, soit c la part de la production correctement pondérée visible dans les enregistrements, sans faux positifs ni autre erreur. La production observée vaut alors c fois la production complète, donc :

D̂_t / D̂_bD_t / D_b = c_tc_b

(12)

L’équation est exacte avec ces définitions. L’estimation de c est la partie difficile. Un ratio entre dépenses connectées et dépenses totales est une autre statistique et ne peut pas s’y substituer sans un modèle explicite reliant la couverture des ressources à la couverture de la production.

La frontière comptable compte aussi ici. Observer une partie de la production tout en utilisant toute la base de coûts n’estime pas le même objet que mesurer la production et le coût d’un service volontairement restreint et observé de façon cohérente. Aucun des deux ne devrait être rebaptisé efficacité de toute l’entreprise sans justification.

Pourquoi la précision globale d’un classifieur ne suffit pas

Pour un problème simple de reconnaissance binaire avec des poids fixes correctement attribués, définis les totaux de vrais positifs, de faux positifs et de faux négatifs avec ces poids plutôt qu’avec le nombre d’éléments. La précision pondérée est le poids des vrais positifs divisé par tout le poids reconnu. Le rappel pondéré est le poids des vrais positifs divisé par tout le poids éligible. Quand les dénominateurs sont non nuls :

poids reconnupoids éligible = rappel pondéréprécision pondérée

(13)

La précision et le rappel ordinaires, fondés sur les comptages, ne donnent pas cette identité pour un indice pondéré par les coûts. Une mauvaise classification qui change le poids d’un élément reconnu demande un traitement supplémentaire. C’est aussi le cas des candidats jamais trouvés et des relations incertaines entre enregistrements parents et enfants. Combiner ces erreurs en une seule équation multiplicative exige des définitions compatibles. Ce n’est pas justifié simplement parce que chaque terme porte un nom plausible.

La reconnaissance probabiliste est possible, mais un estimateur proposé doit garder des classifications mutuellement exclusives et éviter de compter des livrables qui se recoupent. Un ensemble de tickets notés indépendamment ne remplit pas ces conditions automatiquement. Des probabilités calibrées traitent l’incertitude sur les candidats observés, pas le travail totalement absent de l’ensemble de candidats.

Ce qu’un échantillon d’audit peut établir

L’estimation familière de 385 observations vient d’un calcul particulier : un échantillon aléatoire simple d’une proportion binaire indépendante, un intervalle de 95 % par approximation normale, une proportion du pire cas égale à un demi et une marge de cinq points de pourcentage. La taille d’échantillon non arrondie est :

n ≈ 1,96² × 0,5 × 0,50,05² = 384,16

(14)

Ça n’établit pas que 385 enregistrements calibreront les coûts de référence, valideront chaque type de travail ou détecteront un petit changement entre périodes. La stratification, la mise en grappes, les poids inégaux, les cas rares très coûteux et les désaccords entre relecteurs changent le plan nécessaire. La planification d’audit devrait partir de l’erreur qui pourrait changer la décision de l’entreprise, pas d’un chiffre rond familier.

Reproductibilité et interprétation

Les exemples travaillés utilisent les entrées indiquées. Ce ne sont pas des estimations de la performance d’une entreprise typique. Des fourchettes d’erreur numériques par Monte Carlo demanderaient aussi la publication de l’implémentation, des distributions des paramètres, des hypothèses de dépendance et des graines aléatoires. Il faudrait ensuite établir quelles hypothèses correspondent au travail observé avant d’interpréter les fourchettes comme une précision attendue.

La somme de livraison a pour unité la devise de coût de référence. Un indice de présentation peut normaliser cette somme à 100 sur la période de base. L’indice d’efficacité des coûts utilise déjà cette normalisation. Aucun des deux ne mesure la valeur économique, l’impact causal de l’IA ou la valeur d’un salarié.

Will Hackett est cofondateur et CTO de Flowstate.

Footnotes

1. Daron Acemoglu, Will AI Replace Workers? Not If We Build It Right., The Humanist Review of AI, 15 juillet 2026. Plaide pour des outils qui complètent les travailleurs et pour une demande des entreprises centrée sur la productivité et l’innovation plutôt que sur les seules économies de main-d’œuvre. Le lien avec la conception du reporting ici est de mon cru, pas une méthode proposée dans cet essai. Source. ↩ ↩² ↩³

2. National Association of Letter Carriers, The Remote Encoding Center: Where bad addresses go to get better, The Postal Record, juillet 2022, p. 34 et 35. Le récit décrit des machines qui prennent les images d’adresses les plus faciles et laissent les plus difficiles aux opérateurs humains. Source. ↩

3. Intercom, How Fin AI Agent and Copilot Cut Handle Time and Boost Agent Productivity. Le passage sur la charge de travail humaine restante est un commentaire de fournisseur qui appuie le mécanisme du mélange de travail. Ce n’est pas une preuve indépendante de l’ampleur d’un gain de productivité. Source. ↩

4. Erik Brynjolfsson, Danielle Li et Lindsey Raymond, Generative AI at Work, The Quarterly Journal of Economics 140(2), 2025, p. 889 à 942. L’étude publiée rapporte une hausse moyenne de 15 % des tickets résolus par heure dans son contexte de support client, avec des effets de vitesse et de qualité qui varient selon les personnes. Article publié. Résumé des auteurs. ↩

5. Joel Becker, Nate Rush, Beth Barnes et David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, 10 juillet 2025. Le résultat concerne les développeurs expérimentés participants, leurs dépôts et les outils disponibles dans cette expérience. Source. ↩

6. Joel Becker et ses collègues, We are Changing our Developer Productivity Experiment Design, METR, 24 février 2026. Le suivi aborde la sélection des participants, la sélection des tâches et les difficultés à mesurer le temps avec des agents concurrents. Source. ↩

7. McKinsey, The state of AI in 2026: On the road to ROI, 25 août 2026. Les réponses au sondage ont été recueillies auprès de 1 719 participants entre le 4 mai et le 8 juin 2026. Les chiffres rapportés de 80 % pour la productivité individuelle et de 37 % pour l’impact sur l’EBIT répondent à des questions différentes. Source. ↩

8. Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck et Jenna Butler, The SPACE of Developer Productivity: There’s more to it than you think, ACM Queue 19(1), 2021. Soutient que la productivité des développeurs ne se résume pas à une seule métrique ou dimension. L’indice de livraison borné proposé ici n’est pas présenté comme un remplacement de ce cadre. Source. ↩

9. Alessandro Berti et ses collègues, OCEL (Object-Centric Event Log) 2.0 Specification, arXiv:2403.01975, soumis le 4 mars 2024. La spécification prend en charge des événements et des relations impliquant plusieurs objets métier. C’est un standard de représentation, pas une métrique de productivité. Source. ↩

10. ACCA, The standard hour in performance measurement. Les heures standard fournissent une mesure d’activité commune pour des produits hétérogènes et permettent des ratios distincts de volume, d’utilisation et d’efficacité. Source. ↩

11. Office for National Statistics, Public service productivity estimates: sources and methods, révisé le 1er mai 2026, en particulier la section 1 sur la production, les intrants et les indices. La méthodologie utilise des mesures d’activité pondérées par les coûts pour une grande part, mais pas la totalité, de la production des services publics. Source. ↩ ↩²

12. Ron Jeffries, Story Points Revisited, 23 mai 2019. Ses excuses nuancées pour avoir peut-être inventé les story points sont la référence ici, pas une preuve contre toute forme d’estimation relative. Source. ↩

13. Gergely Orosz et Kent Beck, Measuring developer productivity? A response to McKinsey, Part 2, The Pragmatic Engineer, 31 août 2023. Leur discussion commune traite des incitations fondées uniquement sur les résultats. La section finale, identifiée à part, est d’Orosz et comprend l’exemple de gonflement des estimations et la recommandation d’utiliser l’effort et la production pour diagnostiquer des problèmes plutôt que comme mesures publiques de réussite. Source. ↩ ↩²

14. Alex Tamkin et Peter McCrory, Estimating AI productivity gains from Claude conversations, Anthropic, 25 novembre 2025. Le contrôle sur les tâches logicielles rapporte des corrélations de Spearman de 0,44 pour Claude et de 0,50 pour les développeurs, avec des estimations du modèle comprimées. Une bonne performance de classement n’établit pas la calibration en heures. Source. ↩

15. Intercom, Fin AI Agent outcomes, documentation consultée le 7 octobre 2026. Voir « Resolution definition » et l’explication selon laquelle les demandes ultérieures d’aide supplémentaire dans la même conversation annulent la facturation de la résolution. Les exemples de ce billet n’utilisent pas les vrais prix de Fin. Source. ↩

16. Tejal Patwardhan et ses collègues, GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks, 2025, annexe A.2.1 et tableau 2. Les scénarios de relecture et de reprise reposent sur des hypothèses précisées et omettent un traitement comparable de la relecture et de l’échec pour la référence humaine. Il ne faut pas les lire comme des estimations générales d’économies sur le lieu de travail. Source. ↩

17. Ralf Seifert, Richard Markoff et Matthew Spooner, How a new approach to demand planning can redefine success, I by IMD, 5 août 2024. Traite de la valeur ajoutée de la prévision et de la possibilité qu’une meilleure base de référence réduise la contribution marginale des ajustements humains. Source. ↩

18. Tom Cunningham et Parker Whitfill, Task Substitution and Uplift, METR, 8 mai 2026. Distingue le gain sur les anciennes tâches, sur les nouvelles tâches et sur la valeur, avec des relations dérivées sous des hypothèses explicites. Source. ↩

19. Robert S. Kaplan et Steven R. Anderson, Rethinking Activity-Based Costing, Harvard Business School Working Knowledge, 24 janvier 2005. Distingue la capacité fournie de la capacité consommée et traite des occasions que crée la capacité inutilisée. Source. ↩

20. US Bureau of Economic Analysis, Chained-dollar estimates. Note la non-additivité en dehors de l’année de référence et déconseille d’utiliser les composantes comme de simples valeurs en dollars additives. Source. ↩

21. Daron Acemoglu, Andrea Manera et Pascual Restrepo, Does the U.S. Tax Code Favor Automation?, Brookings Papers on Economic Activity, printemps 2020. Analyse un traitement fiscal qui favorise l’investissement en équipement et en logiciels par rapport au travail. Les estimations historiques de cet article ne sont pas un calcul du traitement fiscal actuel d’une entreprise particulière. Source. ↩

22. Gergely Orosz et Kent Beck, Measuring developer productivity? A response to McKinsey, The Pragmatic Engineer, 29 août 2023, en particulier la section 4. Le rejet cité concerne les métriques personnalisées d’effort et de production de McKinsey, pas toutes les formes possibles de mesure opérationnelle. Source. ↩