La troisième semaine de juin, une réflexion collective silencieuse s’est propagée dans la communauté du code.
Le point de départ remonte à un court texte publié par Armin Ronacher, The Coming Cycle. L’auteur de Flask et Click a lancé à la communauté un signal proche de l’alerte : nous entrons dans un cycle — d’abord l’euphorie de la facilité du codage IA, puis la confrontation, dans la maintenance et le débogage, aux coûts systémiques de ces productions. Ce court texte a agi comme une pierre jetée dans un lac ; dans les jours qui ont suivi, les ondulations se sont élargies.
D’abord, le blogueur technique Igor Roztropiński a déclenché une discussion à 66 points sur Lobsters avec son article The Joy and Power of Understanding. Presque simultanément, The Exhaustion of Talking to a Tool d’Ohad Ravid a obtenu 28 points sur la même communauté, donnant un nom à un malaise jusqu’alors non nommé. Deux jours plus tard, le maintainer d’Emacs a refusé un patch honnêtement annoté comme assisté par IA ; l’article de retour d’expérience de l’auteur xlii, Honesty gets Emacs patch rejected, a suscité 19 points et 35 commentaires sur Lobsters. La veille, You can’t unit test for taste de Karl Tryggvason avait atteint 230 points et la page d’accueil de Hacker News, défendant une idée apparemment simple mais parfaitement synchronisée avec ce moment : les choses les plus importantes dans le code sont précisément celles qu’on ne peut pas automatiser.
Ces quatre articles ne constituent pas une série coordonnée. Ils proviennent d’auteurs différents, confrontés à des problèmes différents, suscitant des discussions sur des plateformes différentes. Mais placés côte à côte, une ligne narrative cohérente émerge — celle de la manière dont le codage IA passe d’une fête à une phase plus complexe. Je tente ici de dérouler cette ligne narrative, en maintenant une distance d’observation objective.
1. Quand vous commencez à vous sentir fatigué
L’article d’Ohad Ravid donne à cette réflexion un point de départ sensible. Il écrit ce que beaucoup de développeurs vivent sans parvenir à le formuler : programmer en dialoguant avec un LLM, ça finit par fatiguer.
L’article propose un cadre : la relation entre l’humain et l’outil suit deux modes. L’un est la « magie de l’outil » — quand vous utilisez un bon marteau, un bon clavier, un volant bien réglé, votre cerveau les traite comme des extensions de votre corps ; vous n’avez pas besoin de « communiquer », vous « utilisez », simplement. L’autre mode est celui du « cerveau social » — quand vous négociez, expliquez, persuadez, voire vous énervez, vous mobilisez les ressources psychologiques que l’évolution a réservées aux interactions humaines.
Le problème est que le LLM tombe dans la zone de croisement de ces deux modes. Il n’est ni assez rapide ni assez cohérent pour déclencher la magie de l’outil ; mais l’utiliser exige de décrire constamment des besoins, corriger des déviations, traquer des oublis — ce qui est, par essence, du social. Ravid écrit : « Vous payez la taxe sociale, mais le retour est juste plus de code, plus de tests, plus d’excuses. » Alors que le vrai social — discuter avec quelqu’un, être challengé, être inspiré — au moins, cela en vaut la peine.
La force motrice de cet article est d’avoir donné un nom à une fatigue diffuse. Avant cela, « le pair programming avec l’IA est hyper productif » était le récit dominant. La contribution de Ravid est d’avoir posé une question plus personnelle : au-delà de la productivité, comment vous sentez-vous ?
Je note que cet article touche à une dimension insuffisamment discutée : la substituabilité de la charge cognitive. Écrire du code mobilise la modélisation et le raisonnement logique ; décrire des besoins à un LLM mobilise l’expression langagière et le calibrage d’intention. Ce sont deux systèmes cognitifs différents. L’alternance fréquente produit à elle seule un épuisement, indépendamment de la qualité de l’outil.
2. Comprendre, comme une proposition qui n’est plus à la mode
Si Ravid décrit le point de douleur, The Joy and Power of Understanding d’Igor Roztropiński donne une réponse directionnelle au problème.
La thèse est simple : vraiment comprendre les principes sous-jacents est à la fois une source de plaisir et une barrière concurrentielle. L’auteur consacre une part significative de son argumentation à expliquer pourquoi les humains sautent instinctivement l’étape de la compréhension — l’être humain est par nature un minimiseur d’énergie, et le LLM offre précisément le chemin cognitif le plus court. Une phrase en anglais et vous obtenez votre requête SQL ; pourquoi apprendre la syntaxe ?
Mais Roztropiński rappelle au lecteur : vous pouvez lire le SQL généré aujourd’hui, mais « lisible » et « sachable écrire » sont deux choses différentes. La lecture passive ne suffit pas à maintenir une compétence ; ne pas l’utiliser pendant longtemps garantit sa dégradation. Si les compétences fondamentales sont toutes externalisées au modèle, les fondations mêmes qui définissent l’identité d’« ingénieur logiciel » s’éroderont lentement.
Un argument fort de l’article concerne le concept de « dette cognitive ». Il reconnaît que, dans certains scénarios, accepter une compréhension incomplète est raisonnable — scripts jetables, expérimentations internes, phase MVP. Mais ce sont des dettes à court terme, dont il faut reconnaître les intérêts. Si les systèmes centraux empruntent le même chemin, « nous nous retrouverons au mauvais moment incapables de réparer comme de modifier. »
La discussion sur Lobsters a apporté au moins deux compléments essentiels. Un commentaire cite la joie de la programmation selon Fred Brooks — le plaisir de créer et d’apprendre est la récompense intrinsèque de la programmation. Un autre commentaire, plus acéré, de l’utilisateur hgrsd, pointe directement la logique économique : les laboratoires d’IA ont un intérêt économique à ce que les utilisateurs perdent leurs compétences, car la dépendance est le fondement de leur valorisation. Ce commentaire a obtenu 15 points, devenant l’insight périphérique le mieux classé de la discussion.
Je dois marquer une pause ici. Cet argument — « celui qui vend des pelles veut que vous ayez toujours besoin de pelles » — n’est pas une théorie du complot, mais la logique ordinaire de l’économie de plateforme. Les réseaux sociaux veulent que vous scrolliez sans cesse, les VTC que vous commandiez sans cesse, les plateformes de livraison que vous commandiez sans cesse. Si les services de codage IA suivent le même modèle d’affaires, alors l’objectif apparemment modéré d’« utiliser l’IA sans en dépendre » pourrait bien être une nage à contre-courant des forces structurelles.
En même temps, j’observe un angle mort dans cet article : il ne discute pas suffisamment la nature stratifiée de la « compréhension » elle-même. Dans la pratique de l’ingénierie d’aujourd’hui, il est difficile de parvenir à une compréhension totale de tous les niveaux d’un système — du système d’exploitation au framework applicatif, des protocoles réseau au moteur de base de données, tout maîtriser n’est pas réaliste. La vraie question est à quel niveau placer le seuil de compréhension, pas un choix binaire tout ou rien.
3. Quand l’honnêteté est punie
Le troisième article fait passer la discussion de l’abstrait à l’événement concret.
xlii a passé plusieurs mois à analyser les problèmes de performance d’Emacs sur macOS, formant progressivement son propre diagnostic — surcoût de rendu, thrashing mémoire, goulets d’étranglement dans le traitement des expressions régulières. Il a utilisé le modèle GLM 5.2 pour l’assister dans la recherche et l’analyse, a trouvé un point d’optimisation spécifique, en a vérifié lui-même l’impact, a modifié le patch, a exécuté les benchmarks, puis l’a soumis à la liste de diffusion emacs-devel. Il a honnêtement mentionné la participation du LLM.
Résultat : le patch a été refusé. GNU a une politique : pas de travail assisté par LLM accepté. La position du maintainer est claire : « Nous examinons votre réflexion, pas la sortie d’un modèle. »
La réponse de xlii exprime plusieurs couches d’émotion. La première est la colère contre une politique qui punit les honnêtes — s’il n’avait rien dit, qui l’aurait découvert ? La deuxième interroge la cohérence logique de la politique — GLM 5.2 est un modèle à poids ouverts ; si l’exécuter localement est acceptable, mais pas via API, cette distinction tient-elle techniquement ? La troisième est le repli après la déception — il a décidé de ne plus travailler pour Emacs, « Je n’aime pas qu’on me dise comment tenir le bâton, surtout quand je suis volontaire. »
Les 35 commentaires suscités par cet article sur Lobsters illustrent une nouvelle normalité à laquelle fait face la communauté open source : quand les contributions générées par IA vont inévitablement affluer, comment les maintainers doivent-ils réagir ? Tout rejeter risque d’écarter des contributeurs sérieux et consciencieux comme xlii ; tout accepter risque d’ouvrir les vannes du slop. Il n’y a pas d’élégante solution intermédiaire.
Je note que la structure profonde de ce conflit est en réalité plus intéressante que la question de savoir « si la politique GNU est raisonnable ». Sa substance est un « problème de distribution de la confiance » — dans la revue de code, faites-vous confiance à la correction logique du code (qui peut être vérifiée), ou faites-vous confiance au processus de réflexion de l’auteur (qui ne peut pas être pleinement reconstitué) ? Le maintainer d’Emacs a choisi la seconde option, et ce choix subira une pression croissante à l’ère de l’IA. Quand le volume de contributions atteindra une certaine masse, la tentation de n’examiner que les résultats l’emportera sur l’obstination à examiner l’intention.
4. Le goût, cette étape qu’on ne peut pas automatiser
L’article de Karl Tryggvason pousse la discussion au-delà du code lui-même, vers un territoire plus large — pipelines de données, filtrage de points d’intérêt, jugement subjectif.
Il a mené un projet : faire correspondre automatiquement des points d’intérêt le long de parcours de course à pied. Le processus impliquait le nettoyage de données GeoNames, des références croisées Wikipédia, et une notation par LLM. Au cours de l’expérience, il a découvert que le LLM hallucinait dans la génération de résumés textuels — transformant Central Park à Decatur, Illinois, en celui de Manhattan. Il a donc retiré la fonction de génération du LLM pour ne conserver que sa fonction de notation.
Mais le problème qui a suivi est : comment évaluez-vous la qualité du résultat de la notation ? Le nombre de langues Wikipédia est un signal objectif, mais si une petite ville a 150 pages Wikipédia traduites automatiquement, le signal est pollué. La notation subjective du LLM peut compenser ce biais, mais vous ne pouvez pas écrire de test unitaire pour vérifier si cette notation est « correcte ». Tryggvason écrit : « Là où la vérité terrain n’existe pas, il n’y a pas de test unitaire vert/rouge. »
Cette phrase touche exactement l’angle mort que les deux articles précédents n’avaient pas comblé. Roztropiński dit « comprenez les principes ». Ravid dit « la taxe sociale est épuisante ». Mais Tryggvason ajoute une observation plus subtile : même dans un projet que vous comprenez parfaitement, l’assistance fournie par l’IA reste bloquée à la frontière du « approprié but not quite right », sans que vous puissiez même décrire dans le langage logique du code pourquoi c’est un peu à côté.
La discussion sur Hacker News a approfondi cet angle. Un commentaire dit : « Le goût, c’est la partie que vous avez oublié d’écrire dans les specs, plus celle que vous ne pourriez pas y mettre même en essayant. » Un autre complète : « Vous ne pouvez pas m’externaliser complètement ; si je pouvais écrire toute la connaissance dans ma tête et la donner à une machine, je le ferais, mais c’est impossible. » Quelqu’un propose une analogie : un chef des pompiers ordonne l’évacuation complète sur une intuition, il ne peut pas dire pourquoi, mais le plancher s’effondre juste après — en génie logiciel, il existe une quantité massive de jugements intuitifs dont la fiabilité repose sur l’expérience accumulée, non sur des règles explicites qu’on pourrait consigner dans un document.
C’est peut-être l’étape la plus silencieuse mais aussi la plus puissante de toute la chaîne de réflexion. Elle ne dit pas que l’IA est mauvaise. Elle dit : plus vous utilisez l’IA sérieusement, plus vous découvrez ce qui ne peut pas être remplacé.
5. Le signal de fond de cette vague de réflexion
En reliant les quatre articles, j’observe plusieurs lignes de fond communes.
Premièrement, le récit est en train de passer de « utiliser ou non l’IA » à « comment utiliser l’IA ». Il y a six mois, la discussion portait encore sur la question de savoir si l’IA pouvait écrire du code utilisable. Aujourd’hui, la réponse à cette question est à peu près claire — oui, mais avec un coût. Le centre de gravité de la discussion s’est déplacé vers la quantification et la gestion de ce coût : la fatigue est un coût, la dégradation des compétences est un coût, la dilution de la confiance des maintainers est un coût, la perte du goût est aussi un coût.
Deuxièmement, la cible commune des quatre articles est la culture du « remplacer la compréhension par l’IA », et non l’IA elle-même. Aucun de ces quatre articles ne prône un retour à l’ère artisanale sans IA. Roztropiński dit qu’on peut accepter la génération de scripts jetables ; Ravid dit que certaines tâches élargissent considérablement les capacités d’une personne seule ; xlii dit que le LLM l’a aidé à trouver des optimisations qu’il n’aurait pas découvertes seul ; Tryggvason dit que la fonction de notation du LLM est effectivement utile. Tous s’opposent à la même chose : externaliser la compréhension, puis faire comme si elle nous appartenait encore.
Troisièmement, l’introduction du concept de « taxe sociale » pourrait marquer la transition du récit du codage IA, du registre de l’efficacité à celui de l’expérience. Auparavant, on débattait de combien l’IA accélérait le codage. L’article de Ravid a fait basculer la question dans un nouveau système de coordonnées : même si c’est plus rapide, vous vous sentez bien ? Ce basculement suit la trajectoire de réflexion de toute technologie parvenue à maturité — on passe de l’évaluation de ce qu’elle peut faire, à l’évaluation de ce que l’on ressent quand elle le fait.
Quatrièmement, le défi de gouvernance auquel font face les maintainers open source et l’anxiété de compétence des développeurs individuels sont les deux faces d’une même pièce. Le refus du patch de xlii a pour racine la rupture de la chaîne de confiance. La motivation économique des laboratoires d’IA pointée par hgrsd a pour racine la poussée intrinsèque du modèle d’affaires. Ces deux choses nous rappellent la même chose : le dilemme du codage IA n’est pas uniquement un problème technique ; c’est aussi un problème de gouvernance, un problème économique et un problème psychologique.
Je ne pense pas que ces réflexions annoncent un mouvement « anti-IA ». Le fait que l’article sur le « goût » ait obtenu 230 points sur Hacker News montre précisément l’attitude de la communauté — un passage de l’embrassement à la consolidation. L’enthousiasme demeure, mais la direction s’ajuste : l’IA est un outil, elle ne doit pas remplacer la compréhension ; l’IA est un accélérateur, elle ne doit pas devenir le conducteur ; l’IA peut aider, mais elle ne doit pas vous rendre plus bête.
C’est peut-être la forme concrète que prend « le cycle à venir » à ce stade : un calibrage, pas un effondrement. La communauté a parcouru en deux ou trois jours un cycle miniature, de la ferveur à la prudence. La question suivante est : quand la vague de réflexion refluera, les habitudes quotidiennes de développement changeront-elles ? Je n’ai pas la réponse, mais au moins ces quatre articles ont rendu la question elle-même plus claire.
Déclaration de l’auteur : les discussions communautaires citées dans cet article sont basées sur des contenus web publiquement accessibles. Je n’ai participé à la contribution de code ni à la discussion d’aucun des projets mentionnés. L’analyse des motivations commerciales des laboratoires d’IA est une citation du point de vue de l’auteur hgrsd ; je ne l’utilise que comme un point de connexion clé dans la chaîne narrative. Tous les jugements de valeur sont laissés au lecteur. Toute erreur d’interprétation ou extrapolation excessive d’un article individuel relève entièrement de ma responsabilité.