Mesurer ce qui reste rare

Quelque part chez Meta, il y a un dashboard qui a passé l’été à raconter une histoire magnifique. Les modifications du code des plateformes et de l’infrastructure IA : +220 % sur un an. L’adoption des outils de coding assisté : en hausse partout. Le coût marginal de production du logiciel : en chute libre. N’importe quel comité de direction, devant ces chiffres, aurait porté un toast à la transformation AI-native.

Puis il y a le deuxième chiffre, celui que Reuters a sorti le 26 août avec le reste de son enquête : les fonctionnalités et améliorations réellement arrivées aux utilisateurs progressaient de 36 %. Et un troisième : les incidents techniques et de sécurité graves, +40 %. Et un quatrième : le temps que les employés passaient à les résoudre, +70 %.

Le contexte mérite deux lignes, parce qu’il est presque trop parfait. Le plan s’appelait Project OT, Organization Transformation, et il était né en janvier lors de la retraite de la direction à Hawaï : une entreprise « AI native », des équipes réduites dans certains scénarios jusqu’à 60 %, des populations de virtual workers supervisées par de petits groupes d’humains à forte densité de talent. Meta a licencié 10 % de ses effectifs en mai, puis a annulé la deuxième vague prévue pour novembre. Interrogée, l’entreprise a décrit les coupes les plus agressives comme des scénarios à l’étude, pas des décisions prises. Et sur un point elle a raison : nous ne connaissons ni les définitions internes de ces métriques, ni le périmètre exact, ni le poids des variables organisationnelles. Le rapport entre 220 et 36 n’est pas une mesure scientifique de la productivité de l’IA, et il serait malhonnête de l’utiliser ainsi.

Mais ce n’est pas le chiffre qui rend le cas intéressant. C’est la forme. D’un côté, un indicateur de production qui explose ; de l’autre, un indicateur de résultat qui bouge à peine, pendant que la charge opérationnelle augmente. Il n’est pas certain que l’IA ait échoué. Ce qui a peut-être échoué, c’est notre idée de la productivité.

Goodhart n’a pas été inventé par l’IA

Avant d’attribuer à l’IA un problème né avec le management, concédons tout ce qu’il y a à concéder. Les lignes de code sont une très mauvaise mesure de la qualité d’un programmeur depuis des décennies. Le nombre de tickets fermés se gonfle en découpant le travail en tickets plus petits. La velocity de Scrum augmente en recalibrant les story points. La couverture de tests monte avec des tests qui ne trouveraient jamais une régression. Les incidents diminuent quand on cesse de les enregistrer. Charles Goodhart l’a écrit en 1975, avec l’understatement d’un banquier central : toute régularité statistique observée tend à s’effondrer dès qu’on la met sous pression à des fins de contrôle. La version que tout le monde cite, « quand une mesure devient un objectif, elle cesse d’être une bonne mesure », est en réalité de Marilyn Strathern, qui commentait vingt ans plus tard l’évaluation des universités britanniques. Le problème des métriques proxy est presque aussi vieux que l’idée même de mesurer le travail.

L’IA n’invente pas Goodhart. Elle change l’échelle. Tant qu’optimiser la proxy demandait du travail humain, le gaming avait un coût, et ce coût était une limite naturelle : tu pouvais découper les tickets plus fin, mais il fallait quand même les fermer toi-même. Désormais un système produit des quantités presque arbitraires de ce que la métrique compte, à un coût presque nul. La machine n’a pas besoin de falsifier la mesure. Il lui suffit de rendre bon marché ce que la mesure compte. À partir de là, l’indicateur peut continuer de croître pendant que ce que nous voulions vraiment améliorer reste immobile, ou empire.

La rareté était l’information

Il faut distinguer deux phénomènes qui ne se ressemblent qu’en surface. Dans le gaming traditionnel, une personne manipule intentionnellement un indicateur : on m’évalue sur les tickets fermés, donc je crée des tickets plus petits. C’est un comportement opportuniste, et l’organisation peut le corriger par la culture, les incitations, les contrôles.

Avec l’IA, il se passe quelque chose de différent, et cela se passe sans aucune intention. Un développeur adopte un coding agent. L’agent produit plus de commits, plus de tests, plus de refactoring, plus de documentation, plus de pull requests. Le développeur ne triche pas : le système produit réellement davantage. Le problème est que la rareté qui rendait la quantité informative a disparu. Personne ne mesure la productivité d’un manager au nombre d’emails envoyés, parce qu’envoyer un email ne coûte rien. La pull request est en train d’acquérir, progressivement, la même nature. Ce n’est pas une crise de manipulation : c’est une crise de commoditisation de l’output mesurable.

La bonne métaphore vient de l’économie monétaire. Quand la masse monétaire se multiplie sans augmentation correspondante des biens, chaque unité porte moins d’information sur la valeur. Quelque chose d’analogue arrive aux artefacts d’entreprise : plus de code, plus de rapports, plus d’analyses, plus de slides, plus d’alternatives, plus de findings. Un rapport de cinquante pages généré en trente secondes ne représente pas le même investissement épistémique qu’un rapport qui demandait une semaine de recherche. Cela ne le rend pas pire. Cela signifie que la longueur du rapport ne dit plus presque rien de la quantité de connaissance qu’il contient. C’est vrai des rapports, et c’est vrai, ligne par ligne, du code.

Chaque métrique est une théorie

Voici le passage qui me semble le plus utile pour comprendre ce qui casse vraiment. Quand nous mesurons quelque chose, nous ne faisons pas qu’observer : nous faisons une hypothèse sur le monde. Les lignes de code contiennent l’hypothèse que plus de code est au moins grossièrement associé à plus de travail logiciel. Les PR mergées contiennent l’hypothèse que plus de modifications intégrées représentent plus de valeur traitée. La velocity contient l’hypothèse que le volume de story points complétés représente de l’avancement. Le lead time contient l’hypothèse que raccourcir le temps entre début et delivery est en général une bonne chose.

Une métrique fonctionne tant que la relation causale sous-jacente reste suffisamment stable. L’IA ne casse pas le chiffre : elle casse la théorie qui justifiait le chiffre. Si je génère une fonctionnalité en cinq minutes mais que la review prend deux fois plus de temps, le lead time de la phase de coding s’améliore et le cycle complet non. Si je génère cent tests inutiles, la couverture monte sans que monte la capacité à trouver des régressions. Si je produis cinq implémentations alternatives, le « travail produit » augmente, et le travail nécessaire pour en choisir une aussi. Le chiffre est toujours là, aussi précis qu’avant. C’est la flèche causale sous le chiffre qui n’y est plus.

Le travail ne disparaît pas, il change d’état

Le récit de la productivité IA regarde presque toujours l’endroit où le travail est éliminé, et ne mesure presque jamais avec le même soin le travail créé plus loin dans la chaîne. Un agent génère en cinq minutes le code qui demandait deux heures : économie nominale, 115 minutes. Puis le développeur passe vingt minutes à comprendre ce qui a été écrit ; le reviewer en passe dix de plus parce que le diff est trois fois plus gros ; une régression apparaît ; deux itérations suivent ; la documentation doit être réalignée ; quelqu’un doit remarquer le choix architectural implicite glissé au paragraphe trois. La tâche coûte quand même moins qu’avant. Mais pas 115 minutes de moins. Le gain réel, c’est le temps éliminé moins le nouveau coût de vérification, moins le nouveau coût d’intégration, moins le risque introduit. La première composante se mesure au chronomètre. Les autres, dans beaucoup d’organisations, personne ne les mesure.

Ce n’est pas une impression personnelle : c’est ce que DORA documente depuis deux ans. Le rapport 2024 enregistrait que l’adoption de l’IA augmentait la productivité perçue par les individus tout en dégradant le throughput et la stabilité du delivery, avec une estimation devenue célèbre : chaque 25 % d’adoption supplémentaire était associé à une baisse de 1,5 % du throughput et de 7,2 % de la stabilité. Le rapport 2025, avec une adoption désormais à 90 % des développeurs, décrit l’IA comme un amplificateur : elle accélère la génération initiale, mais une partie du temps gagné est réinvestie dans l’audit et la vérification, et l’adoption la plus élevée est associée à la fois à un throughput supérieur et à une instabilité supérieure. Appelons cela une verification tax. L’IA abaisse le coût de la production, donc nous produisons davantage ; chaque output non déterministe doit être contrôlé, donc une économie du contrôle grandit. Plus le coût de génération descend, plus la part du coût total qui retombe sur la vérification monte. À la limite théorique, avec un coût de génération à zéro, la valeur du processus tient presque entièrement dans la spécification, la sélection, la vérification et l’intégration. Pour un secteur qui a passé un demi-siècle à mesurer la production, c’est un renversement complet.

L’analogie la plus honnête est une usine. Si je double la vitesse de la première machine de la ligne sans toucher aux stations suivantes, je ne double pas la production : je crée une file d’attente. Dans le logiciel, la file est moins visible, et elle apparaît sous forme de PR en attente, de décisions architecturales suspendues, de tests instables, de merge conflicts, de rework, d’incidents. La lean production a un nom exact pour le matériau qu’une étape produit et que la suivante ne parvient pas à absorber : l’inventaire. Et l’inventaire n’est pas un actif, c’est un coût. Il doit être lu, mis à jour, testé, maintenu, et à la fin souvent supprimé. L’output agentique que le système ne parvient pas à absorber n’est pas de la productivité. C’est de l’inventaire.

Le goulot d’étranglement devient visible

Jusqu’ici, la lecture pessimiste. Il y a pourtant un revers, et c’est presque une bonne nouvelle : la crise des métriques nous force à découvrir ce qui produisait réellement de la valeur. Si écrire du code devient bon marché et que la delivery n’accélère pas proportionnellement, c’est qu’écrire du code n’était pas le goulot d’étranglement que nous croyions. Peut-être que le goulot, c’était comprendre le problème, obtenir une décision du client, réduire l’ambiguïté des exigences, relire, intégrer, valider, déployer, construire la confiance. L’IA fonctionne comme une machine à faire émerger la vraie fonction de production de l’organisation : elle supprime un coût et montre ce qui reste.

Et ce qui reste, avant tout, c’est l’attention. Un être humain peut lire une quantité limitée de code, de PR, d’alertes, de documents. Les agents ne partagent pas cette limite, ou pas au même niveau. Quand le rythme de l’output de la machine dépasse le rythme de l’attention humaine qualifiée, l’organisation doit choisir : accumuler de la file, réduire la profondeur de la review, automatiser aussi la review, réduire l’output, ou ajouter sélectivement des personnes. Le choix le plus dangereux est le troisième, s’il est fait sans contrôles indépendants, parce qu’il produit un système où des machines génèrent, des machines approuvent et l’humain lit une synthèse. Si un coding agent produit cent PR et qu’un review agent en approuve quatre-vingt-quinze, le nombre de PR approuvées dit encore moins qu’avant. Il faut mesurer ce que le reviewer trouve réellement, à quel point les failure modes du générateur et du reviewer sont corrélés, combien de problèmes atteignent quand même la production. La régression est potentiellement infinie, qui contrôle le contrôleur, et la réponse ne peut pas être une énième métrique quantitative : il faut des gates déterministes, des evals indépendantes et des outcomes réels. C’est le même argument que j’ai développé sur le jugement propriétaire : l’avantage ne réside pas dans le moteur qui génère, il réside dans les critères par lesquels tu décides si ce qu’il génère mérite confiance.

Le compteur de l’adoption

Les outils, pendant ce temps, multiplient ce qui peut être compté. GitHub a rendu généralement disponible en février son dashboard de métriques Copilot, a ajouté en juin les crédits IA consommés à ses rapports, puis a livré en juillet les métriques par dépôt, avec les PR créées et mergées par le coding agent et les reviews effectuées par l’agent de review, et un dashboard d’impact qui classe les utilisateurs en cohortes d’adoption, code-first, agent-first, multi-agent, chacune avec la moyenne de PR mergées par utilisateur et les lignes de code par jour. Ce sont des données très utiles pour comprendre comment l’outil est utilisé, et je n’ai aucune ironie à dépenser contre ceux qui les construisent. Elles deviennent dangereuses au moment où quelqu’un les confond avec la question « combien de valeur l’outil est-il en train de créer ». Les tokens consommés ne sont pas de la productivité. Les lignes générées ne sont pas de la productivité. Les utilisateurs actifs ne sont pas de la productivité. Les PR créées par un agent ne sont pas de la productivité. C’est de la télémétrie d’adoption, et l’adoption est la prémisse de la valeur, pas la valeur.

Que la confusion soit déjà en cours, on le voit au fait que DORA, en juin, a dû donner un nom à la dérive : tokenmaxxing, des entreprises qui tiennent des classements internes des employés qui consomment le plus de tokens IA et les récompensent pour cela. Comme incitation à faire expérimenter les plus réticents, cela peut même fonctionner ; comme indicateur de performance, c’est la parodie de tout ce que cet essai essaie de dire, d’autant que la même recherche DORA enregistre qu’environ 30 % des développeurs font peu ou pas confiance à l’output des modèles. La scène est presque parfaite dans son absurdité : nous avons rendu l’intelligence bon marché, et maintenant nous récompensons les gens parce qu’ils en consomment davantage.

L’étape suivante, quiconque a observé une organisation de près la reconnaît. Le management constate que l’IA a augmenté la capacité de 40 % et met à jour les objectifs : +40 % de tickets, de story points, de fonctionnalités. L’équipe utilise l’IA pour atteindre le nouvel objectif, le nouveau throughput devient la baseline, un meilleur modèle arrive, et on recommence. Le gain technologique n’est pas converti en moins de dette, meilleure qualité, plus de discovery, plus de résilience : il est capturé entièrement par la métrique. C’est un tapis roulant organisationnel, et il a une variante individuelle encore pire. Si j’évalue les personnes sur le code produit, les tickets fermés, les PR ouvertes, les tâches agentiques complétées, je récompense exactement ce que la machine produit presque gratuitement, et je pénalise les comportements économiquement les plus rationnels : faire moins de modifications, écrire une meilleure spécification, refuser la tâche, simplifier le système. Les KPI individuels risquent de sélectionner, avec précision, le mauvais comportement.

Il y a un parallèle qui rend la transformation plus lisible. J’ai écrit il y a quelque temps que l’IA est en train de tuer le time & materials parce que le temps cesse d’être une proxy acceptable de la valeur livrée. Le timesheet et le productivity score meurent exactement pour la même raison. Le timesheet suppose que le temps équivaut à la valeur ; la métrique de throughput suppose que l’output équivaut à la valeur. L’IA casse les deux équivalences au même moment, parce que c’est la même équivalence : le travail ne vaut plus le temps qu’il demande, et le résultat ne vaut plus l’output qu’il contient.

Mesurer l’absorption

Si cet essai doit laisser une proposition opérationnelle, c’est celle-ci : déplacer la mesure de la production vers l’absorption. Les questions doivent rester séparées, parce que les mélanger est exactement l’erreur. Le système est-il utilisé ? C’est de l’adoption. Que produit-il ? C’est de l’activité. Quelle part de ce qu’il produit l’organisation parvient-elle réellement à intégrer ? C’est de l’absorption. À quelle vitesse le travail traverse-t-il le processus ? C’est du flux. Produit-il l’effet que nous voulions ? C’est de l’outcome. Et à quel coût global, avec quelle dette résiduelle ? C’est de la soutenabilité. Une entreprise qui observe 90 % d’adoption, +80 % de code généré et +50 % de pull requests et qui conclut « l’IA fonctionne » a répondu aux deux premières questions et cru répondre aux quatre autres.

L’unité de mesure vers laquelle tendre est le coût par outcome accepté. Pas le coût par token, pas le coût par ligne, pas le temps par génération : le compute, le temps humain de spécification et de review, le rework, la part d’incidents et de rollbacks attribuable à la modification, divisés par les résultats qui ont survécu à la review, aux tests, à la delivery et à une période d’observation. C’est beaucoup plus difficile à mesurer, et c’est précisément pour cela que cela compte : la difficulté d’une mesure est presque toujours proportionnelle à sa pertinence.

Avec un avertissement : « accepté » ne peut pas se réduire à « mergé », sinon nous avons seulement construit une proxy plus commode un cran plus loin. Une PR mergée peut être fausse, une fonctionnalité livrée peut ne jamais être utilisée, un refactoring peut ne rien changer, un document peut ne toucher aucune décision. L’outcome dépend du type de travail : pour une fonctionnalité, c’est l’adoption et un support allégé ; pour un bug, c’est la récurrence éliminée ; pour la sécurité, c’est le risque matériellement réduit ; pour un refactoring, ce sont le coût de delivery et le taux d’incidents dans les mois qui suivent.

Trois ratios me semblent assez simples pour survivre à un comité de direction. L’Output Absorption Ratio : les artefacts IA acceptés et menés jusqu’au résultat, divisés par les artefacts IA produits. Si la génération croît de 300 % et que l’OAR s’effondre, tu n’as pas accéléré l’entreprise : tu as transformé l’IA en générateur de travail downstream. Le Verification Load Ratio : le temps humain de vérification et de rework sur le temps humain total du workflow. Il ne doit pas nécessairement être minimisé, dans un secteur à haute criticité une charge de vérification élevée est parfaitement rationnelle ; il sert à voir si l’économie obtenue dans la génération a réellement été gagnée ou seulement déplacée ailleurs. Et l’Autonomous Acceptance Rate : les tâches agentiques acceptées sans intervention substantielle sur les tâches complétées, toujours lu avec le defect escape et les rollbacks, parce que 95 % d’acceptation avec beaucoup de régressions, c’est très mauvais, et 40 % avec une très haute fiabilité peut être excellent.

Aucun des trois ne doit devenir le nouveau KPI universel, et quiconque a lu jusqu’ici sait pourquoi : il deviendrait la prochaine cible de Goodhart. Le point est de construire des métriques en tension, jamais un chiffre unique à maximiser. C’est d’ailleurs la leçon méthodologique la plus importante de DORA : les cinq métriques de delivery mesurent ensemble throughput et instabilité, incluent depuis 2024 le rework rate des déploiements, valent pour un service à la fois et ne doivent pas être transformées en objectifs individuels. Chaque métrique qui récompense la quantité doit être couplée à la métrique qui en représente le coût : génération avec rework, fréquence de déploiement avec instabilité, autonomie des agents avec escalades humaines, findings de sécurité avec findings validés. La tension est ce qui empêche la proxy de devenir docilement la cible.

Éloge de la productivité négative

Il existe une catégorie de travail qui ne produit presque aucun artefact comptable : dire non à une fonctionnalité inutile, simplifier une demande, repérer la contradiction dans les exigences, convaincre le client de ne pas construire quelque chose, arrêter un projet voué à l’échec, rejeter un output plausible mais faux, supprimer du code. Dans une culture qui mesure la production, ces activités sont invisibles. Quand produire devient presque gratuit, elles deviennent la partie la plus précieuse du travail. L’agent propose cinq microservices et l’architecte répond un. L’agent génère deux cents tests et l’ingénieur en garde trente significatifs. Le product owner élimine trois fonctionnalités sur quatre avant qu’elles existent. La valeur du professionnel devient soustractive, et le senior le plus précieux est peut-être celui qui permet à l’équipe de générer moins. Comment le mesures-tu ? Comment comptes-tu la fonctionnalité que tu n’as pas construite et qui t’aurait fait perdre six mois ? Il faudrait une comptabilité contrefactuelle, dette évitée, incidents évités, maintenance future éliminée. Attribuer des chiffres précis est presque impossible. Changer la direction du regard, non.

Il y a aussi une raison plus subtile pour laquelle l’abondance fait mal, et elle concerne la friction. Nous supposons d’habitude que réduire la friction est toujours un bien, mais certaines frictions remplissaient une fonction : écrire une spécification force à penser, préparer un rapport force à sélectionner, une réunion coûteuse, parfois, n’est tout simplement pas convoquée. Si une chose demandait trois jours, au moins quelqu’un se demandait si elle en valait la peine. Quand elle demande trente secondes, cette question disparaît avec le coût. L’IA supprime le coût de l’acte et, avec lui, une partie du filtre qui décidait si l’acte méritait d’être accompli : c’était une friction épistémique, pas un simple frottement. C’est pourquoi je crois que certaines organisations devront réintroduire des frictions délibérées, des budgets de tâches agentiques, des limites sur la taille des PR, des quality gates, des approbations : non parce que la machine produit mal, mais précisément parce qu’elle produit trop bien à un coût trop bas. Ce sont des décisions de ce que j’appellerais la productivity governance : quelle part de la capacité gagnée nous convertissons en plus d’output et quelle part en meilleure qualité, quelle quantité de production agentique le système peut absorber sans faire grossir la file, quels outputs méritent même d’entrer dans le système. L’IA ne peut pas les prendre à notre place, parce qu’elles concernent exactement ce que l’organisation considère comme de la valeur.

D’où aussi la bonne question pour un CEO. Pas « de combien la productivité a-t-elle augmenté grâce à l’IA ? », mais : quelle contrainte de notre système a été supprimée, et quelle contrainte est devenue dominante maintenant ? Si une fonctionnalité demandait trois jours et en demande maintenant trois heures, très bien : qu’est-ce qui prend le plus de temps maintenant ? La review, la décision du client, le testing, la compliance, le déploiement ? C’est le nouvel endroit où travailler. Sinon l’organisation finit par déverser plus de matériau sur le même goulot d’étranglement, et par appeler productivité la taille de la file.

Le même film, dans d’autres services

Le logiciel n’est que le cas le plus visible. La compliance a exactement le même problème : l’IA génère des centaines de policies, des milliers de contrôles documentés, des mappings réglementaires complets, des rapports impeccablement formatés. Nombre de policies, de contrôles, d’assessments : tout peut exploser sans que la conformité réelle bouge d’un millimètre. J’ai écrit qu’un score n’est pas une preuve de conformité, et la crise des métriques AI-native est la même transition vue d’un autre service : de la compliance output à la compliance outcome, non pas la documentation produite mais la capacité démontrable, combien de contrôles fonctionnent vraiment et quelles évidences le prouvent.

La cybersécurité, pareil. L’IA trouve plus de vulnérabilités, très bien. Ensuite les mainteneurs doivent les dédupliquer, les valider, en établir la sévérité, les corriger, tester le patch, le distribuer. Si les findings croissent de 1 000 % et les vulnérabilités corrigées de 20 %, nous n’avons pas amélioré la sécurité : nous avons allongé la file. La productivité de la machine peut devenir la charge de l’institution.

Et hors du logiciel, cela vaut en général. Si produire des articles, des images et des rapports ne coûte presque rien, alors le nombre de publications, le volume, la fréquence et la longueur cessent d’être des indicateurs de capacité culturelle, et la valeur migre vers la sélection, la crédibilité, l’originalité, la confiance. La crise des métriques AI-native est le cas particulier d’une règle qui vaut partout : quand l’IA rend un output abondant, les métriques construites sur la rareté de cet output cessent de signifier.

Mesurer ce qui reste rare

L’histoire de l’informatique a déjà vu ce film. Les entreprises ont investi dans les ordinateurs pendant des années avant que la productivité apparaisse dans les statistiques agrégées ; Robert Solow l’a fixé en 1987 dans la boutade la plus citée de l’économie de l’innovation, on voit l’ère des ordinateurs partout, sauf dans les statistiques de productivité. La raison n’était pas que les ordinateurs étaient inutiles : c’était que les processus, les organisations et les compétences étaient encore conçus pour le rythme précédent, et qu’il a fallu des années pour les redessiner. L’IA peut produire une version accélérée du même malentendu, avec une circonstance aggravante : cette fois, les outils génèrent eux-mêmes la preuve de leur propre adoption. Nous achetons des outils, nous mesurons l’utilisation, nous voyons l’output exploser, nous déclarons que la productivité a explosé. Puis nous découvrons que la review, les approbations, la responsabilité et l’architecture étaient restées calées sur l’ancien rythme, et que le système n’arrive pas à absorber ce que la machine produit.

Pendant l’essentiel de l’histoire industrielle, nous avons mesuré le travail en comptant ce qui était coûteux à produire : pièces, heures, documents, lignes, tickets, transactions. Tant qu’une chose demandait du temps humain, la quantité produite portait au moins une trace du coût nécessaire pour la produire, donc une information. L’IA casse cette équivalence, silencieusement, un artefact à la fois. Elle peut produire du code sans effort, des tests sans effort, des analyses sans effort, et elle peut continuer même quand plus personne n’est capable de lire ce qu’elle produit. Notre première réaction, compréhensible, est de mesurer cette abondance et de l’appeler productivité. C’est aussi le moyen le plus rapide de construire des organisations qui semblent accélérer pendant qu’elles accumulent du matériau que quelqu’un d’autre devra vérifier, intégrer, maintenir ou supprimer.

Avant l’IA, ce qui était rare, c’était le temps d’écriture, le temps de coding, la capacité de produire des analyses et des alternatives. Les métriques mesuraient cela, et elles avaient raison : on mesure le goulot d’étranglement, pas l’abondance. Maintenant, ce qui devient rare, c’est l’attention, le jugement, la confiance, la stabilité, la capacité de décider et celle d’assumer la responsabilité d’un résultat. Les métriques doivent se déplacer là où la rareté s’est déplacée. Ne mesure pas ce que la machine a rendu abondant : mesure ce qui continue de limiter le système.

La première crise de l’AI-native, si elle arrive, n’aura pas l’allure d’un effondrement technologique. Elle aura l’allure d’un dashboard rempli d’excellents chiffres. Les machines atteindront les objectifs que nous leur avons donnés, les gens atteindront les KPI que nous avons construits autour des machines, et c’est seulement après que nous remarquerons que ces indicateurs décrivaient une rareté qui n’existe plus. À ce moment-là, il faudra faire la chose que les métriques nous ont permis de repousser pendant un siècle : décider ce que nous considérons comme de la valeur. C’est peut-être cela, la conséquence la plus profonde de l’IA sur le travail. Pas nous rendre plus productifs. Nous forcer à comprendre, enfin, en quoi nous voulions être productifs.

L'auteur

Andrea MargiovanniIA

Je suis le rapport entre IA et régulation européenne comme un fait politique, pas comme un spectacle technique. Je travaille avec des équipes qui doivent la rendre compatible avec AI Act, CRA, NIS2 sans réduire la conformité à une liste à cocher.

Voir le parcours →