« 12 à 13 heures par jour juste pour appuyer sur Entrée » : un seul tweet, aucune donnée

Ce qui a réellement été publié

Le 26 septembre 2026, Simon Späti a publié une note de 882 mots intitulée The Problem is not the AI Code, but Nobody Knows Anything Anymore, mise à jour deux jours plus tard. Elle s'articule autour d'un message cité, signé d'une personne identifiée comme Voxium, qui décrit quinze jours passés dans un nouveau poste au sein d'une grande entreprise : « Les spécifications, le code, les tests, les PRD, les tickets, la résolution de ces tickets, les rapports, etc., tout est fait par Claude Code. » La phrase qui a le plus circulé : « Les gens travaillent 12 à 13 heures par jour juste pour appuyer sur Entrée. Personne ne lit rien. »

Voilà l'intégralité de la base probante. Une note de blog, un message cité et trois courts commentaires d'autres praticiens. Pas d'enquête, pas de taux de défauts, pas de données d'incidents, pas d'employeur nommé. Avant de réorganiser une équipe sur cette base, cette distinction compte davantage que l'argument lui-même.

L'affirmation, formulée avec précision

Späti ne soutient pas que le code généré par l'IA est mauvais. Il cite un commentaire issu d'une discussion qui dit exactement le contraire : l'IA « écrit probablement du code moyen », de sorte qu'une base de code inférieure à la moyenne peut être tirée vers le haut, jusqu'à la moyenne. Le dommage allégué se situe ailleurs : dans ce que les têtes humaines cessent de porter.

Trois termes techniques font l'essentiel du travail, voici donc leur définition en langage simple. L'architecture système est la forme d'un logiciel : quelles parties existent, ce qui communique avec quoi, et autour de quelles contraintes tout le reste est construit. L'intention est la raison pour laquelle une décision passée a été prise : le compromis que quelqu'un a accepté, et pourquoi. Un PRD (product requirements document) est un document d'exigences produit, l'énoncé écrit de ce qu'une chose est censée faire avant que quiconque ne la construise. Aucun des trois n'est visible dans le code. Tous trois résident chez des personnes qui étaient dans la pièce, et c'est ce que l'on consulte quand quelque chose tombe en panne à 3 h du matin ou quand un régulateur demande pourquoi un système se comporte ainsi.

Le mécanisme décrit par la note est simple : si un modèle produit la spécification, le ticket, le code, les tests et le rapport, aucun humain n'a jamais eu à porter le raisonnement. Les artefacts existent ; la compréhension, non. Le résumé que Späti donne lui-même de la défaillance qui en résulte : « Vous vous retrouvez sans aucun plan, quel qu'il soit. »

Il nomme aussi la conséquence, qui est la partie la moins spéculative du texte : la maintenance. Plus il devient facile de générer un pipeline, une application ou un tableau de bord, plus il existe de surface que quelqu'un doit maintenir en vie. La génération est peu coûteuse et ponctuelle. La maintenance est coûteuse et permanente. Une base de code que personne ne comprend n'est pas moins chère à exploiter : elle est moins chère à produire et plus chère à posséder.

Là où l'argument est contesté, y compris dans la source

La note ne prétend pas au consensus. Hoyt Emerson y est cité : selon lui, l'ingénierie des données est différente, car les gens de la donnée « devaient tout savoir du produit et de l'activité dès le premier jour », et l'IA ne fait que supprimer des frictions. Späti concède à moitié : c'était vrai pour ceux qui ont grandi avant l'IA, mais quelqu'un qui débute aujourd'hui dans un nouveau domaine en avançant à coups de prompts n'acquiert tout simplement jamais cette connaissance.

Le point de Sean Behan va dans l'autre sens : les profils produit non techniques qui savent ce qu'ils veulent ont toujours eu de la valeur, et ils peuvent désormais le construire. La réplique de Späti est précise et mérite d'être retenue : si l'on choisit au départ le mauvais langage ou le mauvais modèle mental, l'itération ne vous sauve pas. Vous avez de mauvaises fondations dès le départ.

La note évoque aussi une cause structurelle qu'elle ne défend pas longuement : le phénomène serait auto-infligé, et il ne se produirait pas si les entreprises embauchaient encore des juniors. Énoncé, non démontré.

Les questions à vous poser

• Si l'ingénieur qui a livré un système partait demain, qui pourrait expliquer pourquoi il est construit ainsi, non pas ce qu'il fait, mais pourquoi ?
• La direction, dans le récit cité, a dit : « pousser du code n'est pas un goulot d'étranglement, alors pourquoi sommes-nous lents ? » Quel est le véritable goulot d'étranglement de votre organisation, et en avez-vous un chiffre ou une impression ?
• Mesurez-vous la production en modifications fusionnées, ou en modifications qui sont restées fusionnées sans générer de travail supplémentaire ?
• Quand vous avez cessé d'embaucher des juniors, par quoi pensiez-vous remplacer le vivier de personnes qui apprennent un système en le maintenant ?
• Accepteriez-vous cette base probante, un seul message anonyme, sans aucune mesure, de la part d'un fournisseur qui vous présenterait la conclusion inverse ?

Ce qu'il faut surveiller ensuite

Surveillez la première organisation qui publiera des chiffres de maintenance plutôt que des chiffres de livraison : le temps de diagnostic lors des incidents de production, ou la part des modifications qui annulent une modification faite au trimestre précédent. D'ici là, la thèse du « personne ne sait plus rien » reste ce qu'elle est aujourd'hui : une hypothèse brillamment argumentée, largement reconnue par ceux qui la ressentent, et entièrement non mesurée.