Le 22 juin 2026, la page d’accueil de Hacker News affichait simultanément trois articles, provenant de trois utilisateurs différents, pointant vers trois produits distincts, mais s’emboîtant comme les pièces d’un puzzle.
La première pièce : le journal SQLite de Codex écrivait en arrière-plan vers le SSD local à un rythme de 640 To par an, alors que les données effectivement conservées ne dépassaient pas 0,5 million de lignes — le compteur AUTOINCREMENT avait pourtant déjà dépassé les 5,5 milliards. Une amplification d’écriture de 10 000 fois. Un SSD grand public de 1 To a une durée de vie d’écriture nominale de 600 TBW ; Codex le consumerait en dix mois. Le correctif PR a été fusionné le jour même, affirmant réduire le volume de journalisation de 85 %. La deuxième pièce : Patrick McCanna a découvert que la sortie « Extended Thinking » de Claude Code est un résumé généré a posteriori, et non le véritable processus de raisonnement du modèle. Le vrai raisonnement est chiffré en un bloc de signature de 600 caractères, dont la clé est détenue par Anthropic, inaccessible localement à l’utilisateur. Patrick compare cette transformation à « enregistrer un JPEG en BMP, puis éditer le BMP en prétendant que c’est un JPEG — la perte de données se produit dans la conversion. » La troisième pièce : Tech Stackups a publié un test comparatif entre GLM-5.2 et Claude Opus 4.8, construisant à partir de zéro un jeu de plateforme 3D WebGL avec le même prompt unique. GLM-5.2 a mis 1 h 10 et coûté 5,39 $ ; Opus 4.8 a mis 33 minutes pour environ 21,92 $. La conclusion : « Nous ne migrerons pas notre主力 d’Opus », mais GLM-5.2, avec ses poids ouverts sous licence MIT, a gagné une « utilisabilité inaliénable ».
Les trois articles ont obtenu respectivement 456, 253 et 474 points. Les scores ne veulent rien dire en soi — les votes HN ne sont jamais un baromètre de la vérité. Mais la résonance du même jour pointe vers le même problème : les développeurs ne se demandent plus seulement « quel modèle est le plus fort », ils commencent à se demander « à quel outil peut-on faire confiance ».
Ce virage est étayé par des données. L’enquête Stack Overflow 2025 auprès des développeurs montre que 84 % des développeurs utilisent ou prévoient d’utiliser des outils de codage IA, mais seulement 29 % font confiance à leurs résultats — une baisse de 11 points par rapport à 40 % l’année précédente. L’évaluation de Veracode a révélé que 45 % du code généré par IA échoue aux tests de sécurité. L’enquête de Sonar met en lumière une fracture encore plus dangereuse : 96 % des développeurs ne font pas entièrement confiance à l’exactitude fonctionnelle du code généré par IA, mais seulement 48 % déclarent vérifier systématiquement avant de valider. Un essai contrôlé randomisé de METR a montré que les développeurs utilisant des outils IA sont en réalité 19 % plus lents que leurs collègues n’utilisant pas l’IA, bien qu’ils se perçoivent comme 20 % plus rapides. Pour l’auteur, il s’agit d’un problème d’ingénierie du mécanisme de confiance — lorsque la sortie d’un outil n’est pas vérifiable, le gain de productivité est absorbé par le coût de la vérification.
Revenons aux trois articles. Chacun touche une dimension différente de la confiance.
Le bug de logging de Codex touche à la fiabilité. Un système qui a enregistré 5,5 milliards de lignes de logs pour n’en conserver que 500 000 n’est pas malveillant, mais négligent. Cependant, le signal de cette négligence est fort : si ce code d’infrastructure de base — la journalisation locale — a fonctionné six mois avec un défaut de cette ampleur (sans compter un bug où un spinner occupait 100 % du GPU Mac, lui aussi resté non corrigé), comment un développeur peut-il croire que le code métier généré par cet outil ne cache pas un gaspillage équivalent ? Un utilisateur de HN a utilisé un mot dur : « slopware ». Le terme est brutal, mais il frappe juste au cœur de l’émotion de la communauté — ce qui est critiqué, ce n’est pas que le résultat de Codex soit entièrement médiocre, c’est que sa discipline d’ingénierie l’est. Il y a une distance entre ces deux jugements, mais elle se réduit.
Le résumé de la pensée de Claude Code touche à la transparence. Les raisons techniques d’Anthropic sont compréhensibles — cacher la chaîne de raisonnement empêche les concurrents de distiller le modèle et empêche les utilisateurs d’utiliser le contenu du raisonnement pour des attaques de sécurité. Mais compréhension n’empêche pas le problème concret soulevé par la découverte de Patrick : lorsque vous auditez le comportement d’un agent IA, avez-vous accès à sa véritable pensée ou à un résumé embelli ? Ce n’est pas qu’une question philosophique. Si les agents IA doivent à l’avenir manipuler des bases de données, envoyer des requêtes API, modifier le système de fichiers, leur processus de décision doit être auditable — « accessible » ne suffit pas, il faut « précis ». Un utilisateur de HN a déclaré sans détour : « Je n’utiliserai ni ne recommanderai aucun modèle qui cache son raisonnement. » C’est catégorique, mais cela reflète un instinct d’ingénierie valable : si l’état interne d’un système n’est pas observable, vous ne pouvez pas construire un modèle de confiance fiable.
La controverse du benchmark GLM-5.2 touche à l’honnêteté même de la méthode d’évaluation. Le test comparatif de Tech Stackups était sérieux — même prompt, même tâche, code source ouvert, jeu jouable. Mais les critiques de la communauté HN ne portaient pas sur l’exécution du test, mais sur sa conception. Un commentaire très voté racontait l’histoire d’un ivrogne cherchant ses clés sous un lampadaire : un policier lui demande ce qu’il fait, il dit qu’il cherche ses clés ; le policier demande si c’est là qu’il les a perdues, il répond que non, mais « c’est là qu’il y a de la lumière ». Le benchmark one-shot est ce lampadaire — facile à mesurer, facile à reproduire, facile à transformer en graphique, mais il ne reflète pas le véritable flux de travail du génie logiciel. La programmation réelle implique des itérations multiples, la compréhension de code existant, la correction de bugs, la refactorisation d’architecture — pas une génération d’application complète en un seul prompt. Si une méthode de test ne couvre que 5 % des capacités de codage IA, que sont les 95 % restants ? Nous ne le savons pas. Et c’est ce « ne pas savoir » qui est crucial.
Les trois événements pointent vers la même conclusion : la dimension des capacités des outils de codage IA a été surdéveloppée, tandis que la dimension de la confiance accuse un grave retard.
Il ne s’agit pas de dire que « les outils de codage IA sont inutiles ». Ils sont utiles. 84 % des développeurs les utilisent pour une raison. Mais « utile » et « digne de confiance » sont deux variables indépendantes. Un outil peut être à la fois utile et non fiable — c’est précisément la situation actuelle. Et cette combinaison est plus difficile à gérer que « inutile et non fiable », car elle incite les gens à accumuler une dette de vérification à long terme pour un gain d’efficacité à court terme. Werner Vogels appelle cela la « verification debt », dont les intérêts sont composés — des résultats d’IA non vérifiés sont référencés, copiés, et deviennent des dépendances dans le code en aval, les erreurs s’amplifiant de niveau en niveau dans la chaîne de dépendance.
GLM-5.2 a reçu le moins de critiques. Les résultats des tests montraient clairement qu’il était inférieur à Opus, mais le ressentiment de la communauté ne portait pas sur les performances — il portait sur les poids ouverts eux-mêmes. L’open source ne rend pas automatiquement digne de confiance, mais il fournit quelque chose qu’un modèle fermé ne peut pas offrir : vous pouvez au moins essayer de le comprendre. Codex est fermé, vous ne pouvez pas corriger le bug du spinner. Le raisonnement de Claude Code est chiffré, vous ne pouvez même pas voir comment il pense. GLM-5.2 met au moins ses poids à disposition ; même si la plupart des gens ne les regarderont jamais, l’option même de « pouvoir regarder » fait partie de l’infrastructure de confiance.
L’auteur ne croit pas que tout cela signifie que « l’hiver du codage IA arrive ». Une crise de confiance n’est pas la mort de la confiance. C’est une réévaluation de la confiance — les développeurs recalculent le coût qu’ils sont prêts à payer pour du « rapide mais imprécis ». Ce processus de réévaluation mérite peut-être plus d’attention que les changements de classement dans les benchmarks. Il y a 28 jours, CVE-2026-35603 a été divulguée — une vulnérabilité d’élévation de privilèges dans un outil de codage IA. Il y a 16 jours, Cymulate a publié une analyse détaillée. Aujourd’hui, trois articles HN convergent sur une même page. Ce ne sont pas des événements isolés, ce sont les impulsions successives d’un même signal.
Cette observation est basée sur les informations publiques de cette seule journée du 22 juin 2026. L’auteur ne dispose pas de données d’utilisation à long terme de ces outils et ne prétend pas prédire leur évolution. La confiance en ingénierie est une variable cumulative — les découvertes de demain pourraient confirmer le jugement d’aujourd’hui, ou le renverser. La seule certitude est que lorsque les développeurs cessent de courir après les scores SOTA et commencent à courir après « est-ce que ce truc est vraiment fiable ? », les règles du jeu ont déjà changé.