25 min de lecture

Le mirage de la productivité IA : et si on en faisait moins ?

L'IA t'a fait gagner trois heures aujourd'hui. T'en as fait quoi ? Probablement codé trois heures de plus. Pourquoi le temps gagné par l'IA n'est jamais à nous, et comment le reprendre.

L'IA t'a fait gagner trois heures aujourd'hui. T'en as fait quoi ? Probablement codé trois heures de plus. Pourquoi le temps gagné par l'IA n'est jamais à nous, et comment le reprendre.
Mode de lecture :

TL;DR

L’IA accélère le code. Elle n’allège pas la charge, elle la déplace. Plus on automatise, plus on travaille (paradoxe de Jevons). Plus on consomme de tokens, plus on s’épuise (Tokenmaxxing, AI Brain Fry, AI Coding Grief Syndrome). Le vrai problème n’est pas l’outil, c’est ce que le système fait du temps qu’il libère. Cet article est un appel à reprendre ce temps. À en faire autre chose que du code.

Introduction : Vendredi, 22h, ton terminal

Il est 22h. Tu fixes ton terminal.

Claude Code vient de refactorer ta couche d’API en douze minutes. Quatre heures de boulot annoncées dans le ticket. Tu as gagné trois heures et quarante-huit minutes sur ton estimation. Tu devrais te sentir libre. Tu devrais fermer ton laptop. Tu devrais sortir, voir quelqu’un, ouvrir un livre, dormir.

Tu ne le fais pas.

À la place, tu ouvres une nouvelle conversation. Tu lances un autre prompt. Tu refactores le module à côté. Tu génères des tests. Tu enchaînes. Pas par discipline. Pas par passion. Par réflexe.

Cette scène, elle est partout. Elle est dans ton équipe, dans la mienne, dans les threads Reddit, dans les couloirs des conférences. Elle est le symptôme d’un mirage que personne n’ose nommer.

J’ai écrit il y a quelques mois Les bons et les mauvais devs. J’y défendais une idée simple : l’IA n’est pas le problème. Le gatekeeping anti-IA, le purisme, le mépris pour celles et ceux qui utilisent ces outils, voilà ce qui est ridicule. Je le maintiens.

Et pourtant.

L’IA n’est pas mauvaise. Mais ce qu’on en fait collectivement, ce que le système économique et culturel en fait, ce que les organisations en font sans réfléchir, ça, ça l’est. Profondément. Et ça nous coûte cher : en santé mentale, en sommeil, en sens, en vie hors du clavier.

Cet article ne contredit pas le précédent. Il le complète. Il pose une question que j’avais laissée de côté : si l’IA nous fait vraiment gagner du temps, à qui appartient ce temps ?

Partie 1 : Le constat. Ce que personne n’ose dire

Oui, on gagne du temps. Et alors ?

Soyons clairs sur un point. Le gain est réel.

Quand on utilise l’IA correctement, on livre plus vite. Le formulaire à six champs avec validation, qui prenait une demi-journée, on l’a en quinze minutes. La couche d’API qui demandait deux jours, on l’a en une après-midi. Les tests qu’on aurait reportés à un sprint plus tard, on les écrit en parallèle. La doc qui restait éternellement à faire, on l’a quasi gratuitement. Ce n’est pas une illusion. C’est une réalité observable, mesurable, vérifiable dans n’importe quelle équipe qui s’est outillée correctement.

C’est précisément pour ça que cet article existe.

Parce que si l’IA nous fait gagner du temps, alors une question simple s’impose : où va ce temps ?

La réponse, telle qu’on l’observe à grande échelle, est presque comique. Il ne va nulle part. Plus exactement, il retourne immédiatement dans la boucle qui l’a libéré. Le ticket suivant arrive plus vite. Le sprint suivant attend plus de tickets. Le manager attend plus de features. Le board attend plus de releases. Et le dev qui aurait pu fermer son laptop à 18h continue à 22h, parce qu’il y a encore un module à automatiser, un prompt à raffiner, un agent à pousser.

Le mirage n’est pas dans le gain. Le mirage est dans la disparition silencieuse de ce gain. Dans ce moment, à peine perceptible, où le temps libéré est aussitôt réabsorbé par le système, sans qu’aucun de nous n’ait eu le temps de se demander à quoi ce temps aurait pu servir.

On a accéléré la production. On n’a pas appris à s’arrêter. Les deux phrases ne se contredisent pas. Elles décrivent la même réalité.

La fatigue qui n’avait pas encore de nom

Il y a deux ans, quand un dev rentrait épuisé après huit heures devant son IDE, on appelait ça le burnout. Un mot connu. Une réalité documentée. Aujourd’hui, on a un nouveau mot, plus précis, plus vicieux : l’AI Brain Fry. La surchauffe cérébrale par l’IA.

Le terme est entré dans la presse grand public via une étude relayée par CBS News en 2026, basée sur quinze cents travailleurs interrogés. Le constat tient en un chiffre.

1 travailleur sur 7 rapporte une fatigue mentale sévère liée au jonglage entre outils d’IA. C’est plus que les cas documentés de burnout traditionnel sur la même période. (Harvard Business Review, mars 2026)

Le mécanisme est connu, et il est cruel.

Superviser un agent demande quatorze pour cent d’effort mental supplémentaire par rapport à exécuter la tâche soi-même. Vérifier que le code généré est juste, débusquer les hallucinations, traquer les patterns inappropriés, tout ça mobilise une attention soutenue que la rédaction initiale ne demande pas. La même étude observe une chute de l’engagement critique chez les utilisateurs intensifs : capacité de détection d’erreurs qui s’érode, fatigue mentale qui grimpe, pour un volume de travail qui n’a pas diminué.

Au passage, la machine a tué les micro-pauses. Le mode conversationnel des outils d’IA pousse à travailler pendant les temps d’attente qu’on prenait avant pour respirer. La pause café devient une pause prompt. La fenêtre dans laquelle le cerveau récupère, elle s’est fermée.

Je vais être honnête : j’écris ça en parlant de moi.

Je bosse en full remote. La pause café, c’était mon dernier sas de décompression : descendre sur la terrasse, le café à la main, le soleil sur la figure, dix minutes sans écran. Mon vrai bouton off.

Le jour où Claude Code a sorti son mode remote, qui permet de continuer une session depuis le téléphone, je me suis retrouvé debout sur la terrasse, café d’une main, smartphone de l’autre, en train de prompter. Pour “profiter” des tokens pendant la pause. J’ai pensé exactement ce mot : « profiter ».

C’est ce jour-là que j’ai commencé à écrire cet article.

Le deuil que d’autres vivent

Il existe un syndrome plus discret, et plus controversé : l’AI Coding Grief Syndrome. Le syndrome du deuil du codage.

Erik Meijer, ingénieur reconnu, déclare que Claude Code a poussé l’état de l’art en génie logiciel “plus loin que soixante-quinze ans de recherche académique”. Gergely Orosz, lui, décrit ce que vivent beaucoup d’ingénieurs comme un deuil identitaire : la perte d’un rapport au métier construit pendant toute une carrière.

Disons-le sans détour : tout le monde ne se reconnaît pas dans ce deuil. Pour une partie significative des devs (et je m’inclus volontiers dedans), le code n’a jamais été un artisanat sacré, juste un moyen pour construire des produits utiles. Si l’IA libère du temps en supprimant la pénibilité de l’écriture, tant mieux. La nostalgie du caractère tapé à la main est une posture, pas une obligation. Le mythe de l’ingénieur-artisan qui souffre par amour du code ne dit rien d’universel sur le métier. Il dit quelque chose sur certaines personnes qui sont libres de le vivre comme elles l’entendent.

Mais pour une autre partie, parfois plus bruyante, parfois plus silencieuse, le deuil est réel. Pour ces collègues, écrire du code était plus qu’un job. C’était un rapport tactile à la matière logicielle. Refactorer une fonction qui demandait à devenir élégante. Passer une heure à comprendre pourquoi un test échoue. Cette part-là, ils la voient se rétrécir. Ils basculent vers la supervision passive, vers ce qu’on appelle le rôle de “concierge de code”. Certains le vivent mal, et leur ressenti est documenté, qu’on le partage ou pas.

Beaucoup de seniors ressentent une frustration face à cette transition. Beaucoup de juniors, eux, ressentent un syndrome de l’imposteur : ils n’auront jamais le temps de devenir vraiment bons à la main, parce que la main n’est plus le terrain où on les évalue. (J’ai exploré cet angle plus en détail dans Comment former les juniors quand l’IA écrit le code ?.)

Que tu te sentes concerné par ce deuil ou pas, le phénomène existe. Il ne se voit pas dans les sprint reviews. Il se voit ailleurs : dans le désengagement, dans la baisse de l’humour des standups, dans les démissions discrètes, dans les conversations Slack qui se vident de sens.

Le pivot : pourquoi l’IA ne te rend pas plus libre

Reprenons la scène d’ouverture. Vendredi 22h, Claude Code a fini ton refacto. Tu as gagné trois heures et quarante-huit minutes. Tu n’as pas fermé ton laptop. Tu as continué.

Pourquoi ?

Parce qu’on a confondu vélocité et liberté. Parce que le système a déjà mangé le temps que l’IA t’avait fait gagner avant même que tu te lèves de ta chaise. Parce que la productivité n’est pas devenue une option, elle est devenue un état permanent.

L’IA ne te rend pas plus libre. Elle te rend disponible plus longtemps.

Cette phrase, c’est le pivot de cet article. Garde-la. On va y revenir.

Partie 2 : Les mécanismes. Pourquoi le temps gagné disparaît

Le paradoxe de Jevons, version 2026

En 1865, l’économiste William Stanley Jevons fait une observation qui fâche les ingénieurs de son époque. Quand James Watt améliore le rendement de la machine à vapeur, on s’attend à ce que la consommation de charbon baisse. C’est l’inverse qui se produit. L’usage de la vapeur explose, parce qu’elle devient économiquement viable dans des contextes où elle ne l’était pas. La demande absorbe et dépasse les gains d’efficacité.

C’est le paradoxe de Jevons. Plus une ressource devient efficace, plus on en consomme.

Aujourd’hui, le code est cette ressource. L’IA en a fait baisser le coût marginal, drastiquement. Conséquence prévisible : on n’écrit pas moins de code, on en écrit infiniment plus. On ne résout pas moins de problèmes, on s’attaque à ceux qu’on ne se serait jamais permis d’aborder avant. On n’a pas plus de temps pour autre chose, on a plus de tickets dans le backlog.

Le rêve d’un dev qui finirait à 17h grâce à l’IA était un rêve linéaire. La réalité est circulaire. Le gain de productivité crée la demande qui absorbe le gain. La promesse de la semaine de quatre jours, on l’a faite à chaque révolution technique. Elle ne s’est jamais matérialisée. Pas parce que la technologie a échoué. Parce que le système qui l’utilise n’est pas conçu pour libérer du temps. Il est conçu pour consommer tout temps libéré.

L’effet cliquet : pourquoi les gains de productivité IA disparaissent

Concrètement, voilà comment le temps “gagné” disparaît.

Une équipe adopte un outil d’IA. Première semaine : les sprints accélèrent de quarante pour cent. Deuxième semaine : la direction recalibre les attentes. La nouvelle ligne de base est posée. Le sprint suivant doit livrer quarante pour cent de plus, pas quarante pour cent en moins de temps. Troisième semaine : on ajoute un projet qu’on n’aurait pas pris avant. Quatrième semaine : le rythme est devenu la norme. On a oublié l’ancien rythme.

Tout gain de productivité est immédiatement absorbé par une hausse des attentes. Le cliquet ne tourne que dans un sens.

Le mécanisme est documenté pour le génie logiciel par Azeem Azhar dans Jevons and the automated developer.

C’est l’effet cliquet. Les gains montent, ils ne redescendent jamais. Et chaque palier devient invisible une fois franchi.

À l’échelle individuelle, ça se traduit ainsi : tu acceptes des responsabilités que tu n’aurais pas acceptées avant, parce que “avec l’IA c’est faisable”. Tu prends en charge un domaine que tu ne maîtrises pas, parce que “Claude m’aidera”. Tu repousses la complexité en aval, parce que “on optimisera plus tard”. Ta sphère de responsabilité grossit. Ta charge cognitive aussi. Ta journée de huit heures, elle, ne grossit pas. Elle déborde.

Tokenmaxxing : la métrique qui a cessé d’être bonne

Dans cette logique, une dérive culturelle s’installe : le Tokenmaxxing.

Le terme désigne la pratique consistant à mesurer la productivité d’un travailleur par sa consommation de tokens d’IA. Plus tu consommes, plus tu es “performant”. L’idée est entrée dans les discussions des grandes entreprises tech avec une rapidité confondante.

Quelques faits, glanés dans la presse spécialisée :

  • Sonya Huang, partenaire chez Sequoia Capital : “We all should be tokenmaxxing.” La firme tient son propre leaderboard interne de consommation.
  • Visa consommerait près de deux trillions de tokens par mois (environ 1,9 trillion en mars 2026).
  • Meta a intégré, à un moment, le nombre de lignes de code générées par IA comme indicateur de performance, avant de fermer son leaderboard interne Claudeonomics après deux jours, suite à des dérives manifestes.
  • Jensen Huang, PDG de Nvidia, se dit “deeply alarmed” si un ingénieur payé cinq cent mille dollars par an ne consomme pas au moins deux cent cinquante mille dollars de tokens.

Et puis il y a les corps qui lâchent.

Andrej Karpathy, ex-OpenAI et ex-Tesla, parle d’un “state of psychosis” : il dit ne plus avoir tapé de code depuis décembre, et passer ses journées à pousser des agents jusqu’à leurs limites. Quentin Rousseau, CTO de Rootly, raconte avoir dû recourir à des somnifères pendant des mois, le cerveau incapable de décrocher du flux de prompting. Il compare l’expérience à une machine à sous.

Il y a là une loi économique connue, qui s’applique avec une violence rare : la loi de Goodhart. Quand une métrique devient un objectif, elle cesse d’être une bonne métrique. Mesurer la productivité par la consommation de tokens crée mécaniquement une incitation à consommer plus de tokens. Pas à produire plus de valeur. Plus de tokens. Lancer plus d’agents. Écrire des prompts plus longs. Automatiser des tâches qui n’avaient pas besoin de l’être.

Joe Cotellese le résume mieux que personne : “C’est comme mesurer la productivité d’un écrivain par le nombre de mots tapés. Ou la valeur d’un développeur par les lignes de code.” On a déjà fait cette erreur. On la refait, à plus grande échelle, avec des ressources qui coûtent un ordre de grandeur plus cher.

Le résultat tient en un mot : workslop. Du travail produit en masse, instable, redondant, qui sature les files de revue, dégrade la qualité des codebases, et fatigue les seniors chargés de nettoyer derrière. La vélocité affichée est une fiction. Le coût caché est très réel.

Pourquoi ton cerveau souffre vraiment : ECN, DMN et fatigue cognitive

Une parenthèse plus technique, parce que ce n’est pas juste de la fatigue ordinaire.

Le cerveau humain dispose de deux grands réseaux antagonistes. Le Réseau de Contrôle Exécutif (ECN) s’active quand tu codes, quand tu analyses, quand tu te concentres intensément. Il est analytique, dirigé, coûteux en énergie. Le Réseau du Mode par Défaut (DMN) s’active quand tu marches, quand tu rêvasses, quand tu jardines, quand tu prends une douche. Il est associatif, errant, peu coûteux. Il est aussi, comme l’a documenté la recherche en psychologie cognitive depuis vingt ans, le réseau qui produit la majorité des intuitions créatives. C’est dans le DMN que naissent les “Aha!”, les solutions qui surgissent d’on ne sait où, les angles morts qu’on n’avait pas vus.

Le travail assisté par IA maintient le cerveau dans l’ECN en permanence. Pas de pause. Pas de bascule. Le DMN ne s’allume jamais. Et avec lui, c’est toute une partie de l’intelligence créative qui se met en sommeil.

Ajoute à ça : la surveillance de l’IA mobilise quatorze pour cent d’effort mental supplémentaire par rapport à l’exécution manuelle, selon l’étude HBR de 2026 sur le Brain Fry. Chaque sortie d’IA déclenche une micro-décision (accepter, refuser, raffiner) qui accélère la fatigue décisionnelle. Et plus on multiplie les outils, plus l’impression d’efficacité grimpe alors que la productivité réelle s’érode.

Il faut en moyenne 23 minutes pour retrouver une concentration profonde après chaque interruption. Avec des suggestions d’IA toutes les minutes, ce délai n’est jamais atteint. (Gloria Mark, The Cost of Interrupted Work, CHI 2008)

L’exercice physique, la marche, le sommeil de qualité, la lumière naturelle, ne sont pas des bonus. Ce sont les conditions nécessaires pour que le DMN puisse refaire son boulot. Quand tu t’en prives, tu ne te prives pas seulement de bien-être. Tu te prives de la moitié de ton intelligence.

Partie 3 : Sortir du mirage. Faire moins, faire autre chose

C’est ici que beaucoup d’articles dérapent dans le wellness-washing. Fais du yoga, médite, supprime tes notifications, tout ira bien. Non. Ce n’est pas vrai. Le problème n’est pas une mauvaise hygiène individuelle. Le problème est systémique, économique, culturel. Aucune appli de méditation ne corrigera l’effet cliquet ou le Tokenmaxxing.

Mais il y a quelque chose qu’on peut faire, individuellement et collectivement. Reprendre.

Reprendre le temps, la métrique, le rythme, l’attention, le silence, et surtout, reprendre la légitimité de faire autre chose que coder.

Le silence te fait peur : la privation de solitude des devs

Cal Newport, professeur d’informatique à Georgetown, a popularisé l’idée de Digital Minimalism. L’idée tient en une phrase : la technologie doit servir tes valeurs profondes, pas les coloniser.

Il propose trois principes simples. Premier principe : l’usage intentionnel, pas la consommation passive. Deuxième principe : le décluttering numérique régulier (Newport recommande un reset de trente jours pendant lequel tu supprimes les outils optionnels, puis tu les réintroduis seulement s’ils servent vraiment quelque chose). Troisième principe : sanctuariser la solitude et les loisirs profonds, ces activités tactiles ou intellectuelles qui procurent une satisfaction qu’aucun écran ne peut imiter.

Newport décrit un phénomène qu’il appelle la solitude deprivation. La privation de solitude. Beaucoup de devs aujourd’hui n’ont littéralement plus jamais de moment seuls avec eux-mêmes : il y a toujours un Slack, un mail, un prompt, un agent, une IA conversationnelle prête à combler le silence. Le résultat, c’est que le silence devient anxiogène. On l’évite. On le remplit. On clique.

Le silence n’est pas un bug du métier. C’est sa condition de possibilité.

L’incubation : ce que ton cerveau fait quand tu ne fais “rien”

Le mathématicien Henri Poincaré racontait que ses idées les plus importantes lui venaient quand il ne travaillait pas. En montant dans un omnibus. En se promenant sur la plage. En somnolant. Il appelait ça l’incubation.

La recherche moderne lui a donné raison. Les percées créatives ne surviennent presque jamais dans le mode “concentration intense”. Elles surviennent dans la phase d’incubation, ce moment où le cerveau, libéré de la tâche, continue de la traiter en arrière-plan. C’est exactement à ce moment-là que le DMN entre en jeu. C’est exactement à ce moment-là que les idées s’assemblent.

Quand tu enchaînes les prompts pendant huit heures sans pause, tu ne donnes jamais à ton cerveau le temps d’incuber. Tu produis du code, tu valides du code, tu génères du code. Mais tu n’as plus le temps de penser au sens du code, à son architecture profonde, à ses alternatives, à ce qu’il faudrait construire à la place. Tu deviens efficace dans la fabrication, et indigent dans la conception.

Le temps “perdu” à marcher sans téléphone, à jardiner, à cuisiner, à lire un livre qui n’a aucun rapport avec le boulot, ce temps-là n’est pas perdu. C’est le temps où tu redeviens capable de penser.

Faire autre chose que coder : marche, sport, hobbies, contemplation

Voici la partie qui me tient à cœur. Et qui résume pourquoi cet article existe.

Si l’IA te fait gagner trois heures aujourd’hui, le piège est de remplir ces trois heures avec d’autres prompts. Le piège est de chercher un side project. Le piège est de se former à un nouveau framework. Le piège est de “rentabiliser” le temps gagné, comme si le temps n’avait de valeur que monétisé en sortie de code.

Il y a une autre option. Tu peux fermer ton laptop.

Tu peux marcher. Une étude après l’autre montre que la marche, sans téléphone, est l’un des outils les plus puissants pour générer des idées originales et pour clarifier sa pensée. C’est gratuit. Ça ne demande aucun équipement. C’est l’opposé absolu de la posture courbée devant un écran.

Tu peux faire du sport. L’exercice physique régulier augmente le volume des régions cérébrales liées à la mémoire et à l’apprentissage. L’OMS recommande deux heures et demie d’activité aérobie modérée par semaine. C’est très peu. Et ça change tout. Comme le résume joliment un article de Gorilla Logic : Running for better runtime. Courir pour optimiser ton runtime biologique. C’est moins ridicule qu’il n’y paraît.

Tu peux pratiquer un hobby physique, tactile, lent. Travailler le bois. Cuisiner sérieusement. Jardiner. Apprendre un instrument. Pratiquer la photo argentique. Peu importe l’activité, ce qui compte c’est qu’elle te sorte du virtuel et qu’elle te remette en contact avec une matière qui résiste, qui demande du temps, qui ne se laisse pas refactorer en douze minutes.

Tu peux ne rien faire.

C’est probablement l’option la plus radicale. Ne rien faire. S’asseoir. Regarder par la fenêtre. Penser à rien. Laisser le DMN faire son boulot. Aristote, dans l’Éthique à Nicomaque, plaçait la contemplation au sommet des activités humaines. Il avait peut-être raison.

Et puis il y a tout le reste. Tout ce qu’on n’a même plus le réflexe de mentionner.

Voir des gens qui ne sont pas des collègues. Des amis. Des inconnus dans un café. Des enfants. Des vieux. La connexion humaine non médiée par un outil est un nutriment dont on est sevré sans s’en rendre compte. Cal Newport parle de deep satisfactions, ces satisfactions profondes qu’aucune activité numérique ne peut fournir. Elles existent. On les a juste désapprises.

Lire un livre. Pas un blog tech. Pas une doc d’API. Un roman. Un essai. Quelque chose qui demande de la patience, qui n’a pas d’utilité immédiate, qui ne sera jamais “monétisé” sous forme de code.

Aucune de ces activités n’est obligatoire. Aucune n’est meilleure qu’une autre. Tu es libre. C’est tout l’enjeu de cet article : te rappeler que tu es libre. Que les trois heures que l’IA te fait gagner ne doivent pas, par défaut, retomber dans la machine à coder. Elles peuvent retomber n’importe où. Elles peuvent retomber là où ta vie a vraiment lieu.

Partie 4 : Manifeste

Il est temps de monter d’un cran.

Tout ce qu’on vient de décrire, le Brain Fry, le Tokenmaxxing, l’effet cliquet, le deuil du codage, le mirage de la productivité, ce n’est pas un accident. C’est la conséquence prévisible d’un système économique qui mesure tout en flux et qui n’a aucune catégorie pour la lenteur, le repos, l’incubation, le sens.

Le capitalisme numérique a une logique simple : tout gain de productivité est immédiatement réinvesti pour produire plus. Toute heure libérée est aussitôt réoccupée. Toute amélioration technique devient une nouvelle ligne de base. Le cliquet ne tourne que dans un sens. Dans ce système, l’IA ne pouvait que devenir ce qu’elle est en train de devenir : un accélérateur sans frein.

L’IA en elle-même n’est pas le problème. Bien utilisée, c’est un outil extraordinaire. Je continue à l’utiliser tous les jours, et je le revendique, comme je l’ai écrit dans Les bons et les mauvais devs. Le problème, c’est que le système qui l’absorbe n’a aucun garde-fou intégré, aucun mécanisme de retenue, aucune notion de “assez”.

Alors voilà ce qu’on peut revendiquer, en tant que collectif d’humains qui codent.

On peut refuser le Tokenmaxxing comme métrique de performance. Sans détour. Le nombre de tokens consommés ne dit rien de la valeur produite. Toute organisation qui s’engage dans cette direction est en train de fabriquer du workslop à grande échelle, et de griller ses talents. Il faut le dire clairement, en interne, en public, dans les appels d’offres, dans les recrutements.

On peut refuser que les gains de l’IA se traduisent automatiquement en hausse des attentes. Si l’IA accélère ton travail, ça n’oblige pas ton équipe à livrer plus vite. Ça peut tout aussi bien obliger ton équipe à livrer mieux. À faire moins de bugs. À écrire plus de tests. À investir dans la documentation. À former les juniors correctement. À soigner l’architecture. C’est une question politique, au sens premier : quelle valeur on choisit d’optimiser ?

On peut réhabiliter les métriques de qualité, de stabilité, de bien-être. Pas seulement pour faire plaisir aux RH. Parce que ce sont les seules métriques qui prédisent réellement la performance à long terme. Le rapport DORA le dit. Les données BCG sur la valeur réelle de l’IA le disent. Harvard sur le Brain Fry le dit. Les chiffres de turnover des équipes en surchauffe le hurlent.

On peut refuser la culpabilité de la non-productivité. Personne, jamais, n’a le devoir d’utiliser ses heures gagnées pour produire plus de code. Le temps libre est un droit, pas un budget à dépenser. Lire un roman est aussi noble que pousser une PR. Marcher sans téléphone est une activité d’ingénieur. Dormir huit heures est un acte d’hygiène cognitive professionnelle.

On peut s’organiser collectivement, en équipe, pour qu’aucun de ces choix individuels ne soit sanctionné. C’est probablement la partie la plus dure. Tant qu’un seul dev de l’équipe joue le jeu du Tokenmaxxing pour se faire bien voir, les autres seront comparés à lui. La sortie individuelle du mirage est fragile. La sortie collective est une vraie sortie.

Et on peut, surtout, se rappeler à quoi on a dit oui le jour où on a choisi ce métier. Pour la plupart d’entre nous, ce n’était pas pour superviser des machines à sous. C’était pour construire. Pour comprendre. Pour résoudre. Pour bricoler. Cette envie-là, l’IA ne peut pas nous la voler. À condition qu’on la défende.

Et toi ? Que vas-tu faire des heures gagnées grâce à l’IA ?

L’IA t’a fait gagner trois heures aujourd’hui.

Tu vas en faire quoi ?

Tu vas relancer un prompt ? Tu vas commencer un side project ? Tu vas regarder un cours ? Tu vas répondre aux Slack en retard ?

Ou tu vas faire ce qui ne se voit pas, ce qui ne se mesure pas, ce qui n’a pas de ROI ? Tu vas marcher sans téléphone ? Tu vas appeler un ami que tu n’as pas vu depuis trois mois ? Tu vas lire un livre qui ne t’apprendra rien d’utile ? Tu vas ne rien faire, vraiment rien, pendant une heure, et accepter que ce soit le meilleur usage possible de ce temps ?

Je ne te dirai pas quoi faire. Personne n’a le droit de te le dire. Tu es libre.

Mais souviens-toi de la phrase. Elle est presque la seule chose à retenir de tout cet article.

L’IA ne te rend pas plus libre. Elle te rend disponible plus longtemps.

Sauf si tu décides, toi, que cette fois, ce sera différent.

Sources

Sources citées dans l’article

Brain Fry, fatigue cognitive et IA

  1. When Using AI Leads to “Brain Fry” (Harvard Business Review, mars 2026) https://hbr.org/2026/03/when-using-ai-leads-to-brain-fry

  2. Is AI productivity prompting burnout? (CBS News) https://www.cbsnews.com/news/is-ai-productivity-prompting-burnout-study-finds-new-pattern-of-ai-brain-fry/

  3. AI Brain Fry: Why Using More AI Tools Makes You Work Harder (MindStudio) https://www.mindstudio.ai/blog/ai-brain-fry-cognitive-fatigue-ai-tools

  4. AI brain fry is real / Erik Meijer “75 ans de recherche académique” (Fortune, 10 mars 2026) https://fortune.com/2026/03/10/ai-brain-fry-workplace-productivity-bcg-study/

  5. The Cost of Interrupted Work: More Speed and Stress (Gloria Mark, CHI 2008) https://ics.uci.edu/~gmark/chi08-mark.pdf

Tokenmaxxing

  1. Token maxxing (Wikipedia) https://en.wikipedia.org/wiki/Token_maxxing

  2. What Is Tokenmaxxing? The AI Workplace Trend Explained (Built In) https://builtin.com/articles/ai-tokenmaxxing

  3. Meta killed employee AI token dashboard / “Claudeonomics” (Fortune, 9 avril 2026) https://fortune.com/2026/04/09/meta-killed-employee-ai-token-dashboard/

  4. Jensen Huang says Nvidia engineers should use AI tokens worth half their annual salary (Tom’s Hardware) https://www.tomshardware.com/tech-industry/artificial-intelligence/jensen-huang-says-nvidia-engineers-should-use-ai-tokens-worth-half-their-annual-salary-every-year-to-be-fully-productive-compares-not-using-ai-to-using-paper-and-pencil-for-designing-chips

  5. Karpathy says developers have ‘AI Psychosis.’ Everyone else is next. (The New Stack) https://thenewstack.io/karpathy-says-developers-have-ai-psychosis-everyone-else-is-next/

  6. One More Prompt: The Dopamine Trap of Agentic Coding (Quentin Rousseau) https://blog.quent.in/blog/2026/03/09/one-more-prompt-the-dopamine-trap-of-agentic-coding/

  7. Measuring AI Token Consumption Is the New Lines of Code (Joe Cotellese) https://joecotellese.com/posts/measuring-ai-token-consumption-is-the-new-lines-of-code/

Deuil du codage

  1. The grief when AI writes most of the code (The Pragmatic Engineer / Gergely Orosz) https://blog.pragmaticengineer.com/the-grief-when-ai-writes-most-of-the-code/

Paradoxe de Jevons

  1. Paradoxe de Jevons (Wikipedia) https://en.wikipedia.org/wiki/Jevons_paradox

  2. Jevons and the automated developer (Azeem Azhar, Exponential View) https://www.exponentialview.co/p/jevons-and-the-automated-developer

Productivité IA, métriques

  1. The Fast and Spurious: Developer Productivity with GenAI (arXiv) https://arxiv.org/html/2510.24265v2

  2. Making AI Productivity Deliver Real Value (BCG) https://www.bcg.com/publications/2026/making-ai-productivity-deliver-real-value

Cerveau, créativité, repos

  1. Incubation and Intuition in Creative Problem Solving (Frontiers in Psychology) https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2016.01076/full

  2. Creativity, the unconscious foundations of the incubation period (PMC) https://pmc.ncbi.nlm.nih.gov/articles/PMC3990058/

  3. The science of creativity: how to train your brain for innovative thinking (Penn LPS) https://lpsonline.sas.upenn.edu/features/science-creativity-how-train-your-brain-innovative-thinking

  4. Running for Better Runtime: why regular exercise matters for developers (Gorilla Logic) https://gorillalogic.com/running-for-better-runtime-why-regular-exercise-is-important-for-software-developers/

  5. Why Every Programmer Needs a Non-Computer Hobby (DEV) https://dev.to/mahdijazini/why-every-programmer-needs-a-non-computer-hobby-fgf

Digital Minimalism

  1. Digital Minimalism and the Radical Power of Unplugging (Cal Newport via Todoist) https://www.todoist.com/inspiration/cal-newport-digital-minimalism

Pour aller plus loin

Études et rapports institutionnels

Brain Fry, santé mentale, fatigue cognitive (suite)

Burnout et prévention

Paradoxe de Jevons (suite)

Digital Minimalism (suite)

Hobbies et créativité (suite)

Cet article qui dénonce le mirage de la productivité IA a été relu et amélioré avec l’assistance de Claude Opus 4.7. Oui, je sais.

Back to Blog

Comments (0)

Loading comments...

Leave a Comment