Skip to content

Ralentir, Putain : Le Burnout Tech n'est Pas un Échec Individuel

Ralentir, Putain : Le Burnout Tech n'est Pas un Échec Individuel

Le 25 mars 2026, Mario Zechner a publié un billet de blog dont le titre dit tout : "Thoughts on Slowing the Fuck Down". En 24 heures, le post a explosé sur HackerNews avec 783 points et 371 commentaires. Parce que Zechner ne dit pas quelque chose de nouveau. Il dit quelque chose que tout le monde dans la tech ressent mais n'ose pas formuler : on va trop vite, et la qualité s'effondre.

Zechner n'est pas un obscur blogueur en mal de clics. C'est un développeur respecté, créateur de libGDX, avec des années d'expérience dans le développement de logiciels sérieux. Son observation de départ est simple : depuis que les agents de coding IA sont apparus, il y a un an environ, le logiciel est devenu un champ de mines. Les services qui tournaient à 99,9% tombent à 98% de uptime, les UI ont des bugs absurdes, et personne ne semble s'en soucier parce que la quantité de code produite est astronomique.

Les exemples qu'il cite sont édifiants. AWS a subi une panne causée par un bot IA, officiellement démentie puis suivie d'un reset interne de 90 jours sur les pratiques de code. Microsoft reconnaît publiquement que la qualité de Windows se dégrade. Des entreprises qui revendiquent 100% de code généré par IA sortent des produits avec des fuites de mémoire en gigaoctets et des fonctionnalités cassées. Le CEO de Microsoft, Satya Nadella, se vante que jusqu'à 30% du code de l'entreprise est écrit par IA. Le résultat se voit.

L'argument central de Zechner porte sur la différence fondamentale entre les erreurs humaines et les erreurs d'agents. Un humain fait des erreurs, oui. Mais un humain apprend. Il fait la même erreur quelques fois, puis quelqu'un lui hurle dessus ou il comprend par lui-même, et il arrête. Un agent n'a pas cette capacité d'apprentissage. Il refait la même erreur indéfiniment, avec des variations créatives qui en génèrent de nouvelles. Et surtout, un humain est un goulot d'étranglement. Il ne peut produire que tant de code par jour. Les erreurs s'accumulent lentement. Quand la douleur devient trop forte, l'humain s'arrête et corrige.

Un orchestrateur d'agents n'a pas de goulot d'étranglement. Il peut cracher 20 000 lignes de code en quelques heures, chacune avec ses petites erreurs inoffensives qui, mises bout à bout, forment un monstre d'architecture. Et puisque l'humain s'est retiré de la boucle, il ne sent la douleur que quand il est trop tard. Quand il veut ajouter une fonctionnalité et que l'architecture, composée presque entièrement d'erreurs compounding, ne le permet plus.

Zechner appelle ça la disparition du code review et de la discipline. On a délégué les décisions de design aux agents, ajouté des fonctionnalités que personne ne demandait, et supprimé les filets de sécurité qui existaient précisément pour empêcher cette accumulation de dette technique. Le résultat est ce qu'il décrit comme une addiction à la production de code pour elle-même, où l'objectif est de produire le plus grand nombre de lignes dans le plus court temps, peu importe la qualité.

La discussion sur HackerNews confirme que Zechner a touché une corde sensible. Des développeurs de startups et de grandes entreprises racontent la même histoire : on s'est codé dans un coin avec des agents, sans code review, sans architecture réfléchie, et maintenant on paie la facture. Certains disent que ça marche pour les side projects. Zechner est d'accord, mais souligne que votre side project personne ne l'utilise, y compris vous. Appliquer la même approche à un produit utilisé par des humains réels, c'est de la négligence.

Ce qui rend ce post particulièrement pertinent en 2026, c'est le timing. Les agents de coding sont passés du stade de curiosité à celui d'outil de production en moins de 18 mois. L'industrie n'a pas eu le temps de développer les garde-fous nécessaires. Pas de bonnes pratiques établies, pas de frameworks de review adaptés, pas de consensus sur le niveau d'autonomie acceptable. On a plongé tête la première, et Zechner est celui qui crie qu'il n'y a pas d'eau.

Le message n'est pas anti-IA. Zechner reconnaît que les agents sont utiles et que l'expérience de les utiliser est agréable. Son point est plus subtil : la discipline de développement existe pour de bonnes raisons. Le code review, l'architecture réfléchie, les tests de régression, tout ça existe parce que des générations de développeurs ont appris, à leurs dépens, ce qui arrive quand on les saute. Les agents ne changent pas cette réalité. Ils l'accélèrent.

Ralentir n'est pas un signe de faiblesse. C'est un acte de résistance contre une culture qui valorise la vitesse au détriment de la qualité, la quantité au détriment du sens, et l'automatisation au détriment de la responsabilité. Comme le dit Zechner, la douleur finit toujours par arriver. La question est de choisir si on la ressent au fur et à mesure et on la corrige, ou si on attend que le monstre soit trop gros pour être tué.


Podcast: 🎙️ Episode MP3 (~11 min)