Vous aussi, vous trouvez que l'IA est devenue moins intelligente ?

Publié le 24 août 2026 — Par l'équipe DEV-AI

Le constat que beaucoup partagent

Claude Code semble moins performant ? ChatGPT paraît moins intelligent qu'avant ? Vous n'êtes pas les seuls à vous poser la question.

Vous l'avez remarqué vous aussi ? Il y a encore quelques semaines, votre assistant IA semblait comprendre votre projet immédiatement. Aujourd'hui, il oublie une instruction donnée trois messages plus tôt, modifie un fichier qu'on lui avait pourtant demandé de ne pas toucher, tourne en boucle sur un agent de code, ou produit en dix minutes ce qu'il réalisait auparavant en deux.

Pourtant, sur le papier, les modèles n'ont jamais été aussi performants : les scores aux benchmarks publics ne cessent de progresser, génération après génération. Alors que se passe-t-il vraiment ?

C'est le sujet de cette enquête. Pas pour trancher entre « vous avez raison » et « c'est dans votre tête », mais pour comprendre les mécanismes réels — souvent plus intéressants qu'un simple oui ou non.

Ce n'est probablement pas de l'overfitting

La première explication qui circule est celle de l'overfitting post-déploiement — l'idée qu'un modèle « s'adapterait mal » avec le temps. C'est techniquement peu probable : un modèle de langage déployé en production via une API ne se réentraîne pas en continu sur vos conversations. Les poids du modèle sont figés entre deux versions.

Ce qui change réellement entre deux sessions, en revanche, c'est tout ce qu'il y a autour du modèle : le system prompt, le budget de raisonnement alloué, la stratégie de compression du contexte, le routage vers telle ou telle variante interne, les outils disponibles. Et ça, contrairement au modèle lui-même, ça bouge en permanence — parfois plusieurs fois par semaine, sans annonce.

Un meilleur benchmark ne veut pas dire « meilleur partout »

C'est là que la littérature scientifique devient réellement utile. Le phénomène n'est pas nouveau : dès les premières générations de GPT, l'étude GPT-Fathom avait documenté ce que ses auteurs appellent le « seesaw phenomenon » — l'effet de balançoire. Un exemple frappant qu'ils rapportent : GPT-3.5-turbo-0613 progresse nettement en code par rapport à la version précédente, mais son score sur le benchmark de mathématiques MATH s'effondre de 32,0 à 15,0. Une même génération peut donc s'améliorer globalement tout en régressant fortement sur une catégorie précise de tâches.

Des travaux plus récents affinent cette idée. L'étude « Beyond the Mean: Within-Model Reliable Change Detection for LLM Evaluation » part d'un constat simple : la comparaison entre deux versions d'un modèle se fait presque toujours en moyenne globale sur un benchmark, alors que le comportement change souvent de façon substantielle au niveau de chaque item individuel. Autrement dit, deux versions peuvent afficher un score moyen quasi identique tout en répondant différemment — et parfois moins bien — à des familles de questions précises que vous, utilisateur, sollicitez justement beaucoup.

Concrètement : si votre usage quotidien tombe pile dans une catégorie de tâches qui a régressé pendant qu'une autre catégorie progressait, vous vivrez une vraie dégradation — même si le modèle est objectivement « meilleur » en moyenne.

Le modèle n'est plus vraiment le produit

C'est probablement la partie la plus sous-estimée du problème. Ce que vous appelez « Claude » ou « ChatGPT » n'est jamais le modèle brut. C'est une chaîne complète :

LLM → system prompt → budget de raisonnement → gestion du contexte → routage → outils → agent scaffold → réponse

Vous dites « Claude est moins bon », alors que le problème peut très bien se situer dans le scaffold — le harnais logiciel — construit autour de Claude, pas dans Claude lui-même.

Deux études publiées mi-2026 vont exactement dans ce sens. « The Scaffold Effect in Coding Agents » montre que le choix du harnais d'exécution constitue une variable cachée qui influence fortement l'évaluation des agents de code. Et « Stop Comparing LLM Agents Without Disclosing the Harness » va plus loin en avançant la « Binding Constraint Thesis » : le harnais d'exécution serait souvent un déterminant plus fort de la performance d'un agent que le modèle qu'il enveloppe. Les auteurs citent un cas concret où un harnais maison rapporte un taux de réussite SWE-bench Pro dans la fourchette basse des 50 %, alors qu'une exécution indépendante et standardisée du même modèle retombe autour de 45 %. Même modèle, harnais différent, dix points d'écart.

Ce que ça change pour vous : le classement entre modèles n'est pas fixe. Il dépend du framework agentique utilisé pour les faire tourner — Claude Code, Cursor, OpenCode, Codex CLI, etc. Comparer « les modèles » sans préciser le harnais n'a, à la limite, pas beaucoup de sens.

Claude Code est-il devenu moins performant ?

Contexte compressé de façon plus agressive, modifications silencieuses du harnais, budget de raisonnement réduit sous forte charge, saturation des serveurs, changements de configuration côté produit : tout cela peut faire varier l'expérience d'un jour à l'autre, sans que le modèle sous-jacent n'ait changé d'un bit.

Et il y a aussi, plus simplement, les pannes. Le 24 août 2026 — le jour même où nous écrivons cet article — Anthropic a confirmé une panne majeure touchant Claude Chat, l'API et Claude Code, avec des erreurs élevées sur plusieurs modèles de la gamme. L'incident a été détecté à 05:06 UTC, la cause identifiée une vingtaine de minutes plus tard, pour une résolution complète après environ 3h26 de perturbations. Selon les signalements Downdetector rapportés dans la presse spécialisée, 41 % des problèmes remontés concernaient spécifiquement Claude Code. De quoi expliquer, ce jour précis, une bonne partie des « Claude Code est cassé aujourd'hui » qui circulaient — sans qu'il s'agisse d'une régression du modèle.

Le piège, c'est que ces incidents techniques, les changements de scaffold et les vraies régressions de modèle produisent exactement le même symptôme côté utilisateur : « ça marche moins bien qu'avant ». Impossible de les distinguer sans creuser.

Des agents de code fragiles face à des changements pourtant anodins

Un autre travail, publié le 18 août 2026, éclaire un angle mort spécifique aux agents de code : « A Jagged Frontier: Evaluating Robustness of Code Agents to Semantics-Preserving Transformations » (Colorado State University, Microsoft, UIUC, Carnegie Mellon). Les chercheurs appliquent à des dépôts de code des transformations qui ne changent strictement rien au comportement du programme — réécriture du flux de contrôle, injection de code mort, renommage d'identifiants — puis mesurent si des agents de réparation de bugs (mini-SWE agent et OpenCode, avec Claude Opus 4.5, Kimi K2.5, MiniMax M2.5 et Qwen 3.6-27B en moteur) restent aussi fiables sur ces variantes que sur le code original, via SWE-bench Verified et SWE-bench Pro.

Le principe même de l'étude est révélateur : si un agent obtient un taux de résolution mesurablement différent sur deux versions strictement équivalentes du même code, c'est que sa performance dépend de détails de surface plutôt que d'une compréhension robuste du problème. Et le classement entre modèles change selon le scaffold agentique utilisé — encore une fois, le harnais compte.

Pour vous, en pratique : un simple renommage de variables, un refactor cosmétique ou l'ajout de code mort dans votre base peut, à lui seul, faire varier la fiabilité de votre agent de code — sans que rien de « réel » n'ait changé dans le projet.

ChatGPT est-il devenu moins intelligent lui aussi ?

Les témoignages autour de ChatGPT suivent une trame similaire à ceux sur Claude : sensation de mémoire plus courte, instructions system moins bien suivies, réponses plus génériques après une mise à jour silencieuse. La difficulté reste la même qu'ailleurs : distinguer un incident technique ponctuel (indisponibilité, dégradation de latence, erreurs API) d'une véritable régression du modèle sur les tâches qui comptent pour vous. Le premier se résout en quelques heures ; le second nécessite un vrai changement de version — ou de modèle.

La vraie question : pourquoi les devs diversifient vers Z.ai, Codex et Kimi

C'est là que le sujet devient franchement intéressant. On voit de plus en plus de développeurs expliquer qu'ils quittent progressivement Claude Code — ou du moins qu'ils ne l'utilisent plus seul — au profit de Z.ai (GLM), Codex ou Kimi, précisément à cause d'une perception de baisse d'efficacité. Le déclencheur documenté remonte à juin 2026, quand Zhipu AI a sorti GLM 5.2 : la sortie a suffi à convaincre une partie non négligeable d'utilisateurs d'arrêter, au moins partiellement, les services Anthropic. Z.ai a ensuite lancé ZCode, un environnement de développement agentique dédié aux modèles GLM, donnant enfin aux développeurs un terrain de comparaison direct avec Claude Code.

Mais l'observation la plus intéressante n'est pas le mouvement vers un concurrent — c'est ce qu'il implique. Si la perception de régression touchait uniquement Claude, l'explication la plus simple serait un problème propre à Anthropic. Or le motif qui domine réellement en 2026 n'est pas l'abandon en bloc, mais la diversification : de nombreuses équipes combinent désormais plusieurs modèles dans le même workflow — Claude pour la planification architecturale, Codex pour l'implémentation et l'édition itérative, GLM pour les charges sensibles au coût ou multilingues. Ce n'est pas le signe d'un vainqueur qui change de camp ; c'est le signe qu'aucun modèle ne domine plus uniformément toutes les tâches — exactement ce que prédisent les études sur le « seesaw phenomenon » et l'effet de scaffold citées plus haut.

Et cette hypothèse ouvre une piste supplémentaire, plus prosaïque : la complexité progressive de vos propres projets. Un dépôt qui grossit, un historique de conversation qui s'allonge, un contexte de plus en plus chargé — tout cela sollicite davantage n'importe quel modèle, quel que soit le fournisseur, sans qu'aucune régression n'ait eu lieu côté modèle.

GLM-5.3 : le cas qui brouille tout

Si un lecteur venait à observer que Z.ai lui-même semble « moins bon » ces derniers jours, cela renforcerait justement l'hypothèse d'une cause plus générale que le seul cas Anthropic. Or les données disponibles sur GLM-5.3 racontent une histoire nuancée, pas un simple sacre. Sur le benchmark indépendant KingBench 3, GLM-5.3 obtient le meilleur score enregistré (91,25 %), devant Opus 5, Kimi K3 et Qwen3.8 Max, à peu près au niveau de Fable 5. Il prend également la tête sur Humanity's Last Exam avec outils et sur GDPval-AA v2. Mais sur DeepSWE 1.1, c'est Kimi K3 qui garde l'avantage.

Autrement dit, même le modèle qui progresse le plus vite en ce moment ne domine pas partout. C'est un « jagged frontier » de plus, cette fois entre concurrents open-weight — pas un signe que tout le monde régresse en même temps, mais la confirmation qu'aucun classement de modèles n'est stable d'un benchmark à l'autre, ni d'un mois à l'autre.

Notre protocole : on va tester ça nous-mêmes

Les benchmarks publics ont un défaut : ils ne reproduisent jamais exactement vos conditions d'usage réelles — votre codebase, votre style de tâches, votre scaffold. La méthode la plus honnête reste de comparer plusieurs outils sur des tâches identiques et de mesurer ce qui compte vraiment pour un développeur au quotidien.

C'est ce que nous allons mettre en place chez DEV-AI : un protocole comparatif entre Claude Code, Codex/GPT-5.6 et Z.ai GLM-5.3, sur un jeu de tâches de développement identiques (correction de bug, ajout de fonctionnalité, refactor, écriture de tests, revue de code). Nous mesurerons pour chaque outil : le taux de réussite, le nombre d'itérations nécessaires, le respect des instructions données, la consommation de tokens, le temps d'exécution et, si possible, le coût réel. L'idée est de reconduire ce protocole chaque mois pour suivre l'évolution dans le temps — plutôt que de se fier à une photo unique.

Les résultats de ce premier passage feront l'objet d'un article dédié, publié dès que le protocole aura tourné sur l'ensemble des tâches.

Alors, l'IA régresse-t-elle ?

La réponse honnête est « pas globalement, mais parfois localement — et souvent pour de mauvaises raisons ». Les benchmarks agrégés progressent presque partout, génération après génération. Ce qui se dégrade, ce n'est pas nécessairement l'intelligence du modèle, mais :

• des catégories de tâches précises qui régressent pendant que d'autres progressent (effet de balançoire) ;
• le scaffold — system prompt, gestion du contexte, outils — qui change plus vite et plus souvent que le modèle lui-même ;
• des incidents techniques ponctuels, comme celui qu'Anthropic a connu le jour même de la rédaction de cet article ;
• la fragilité de certains agents face à des changements de code pourtant sans impact sémantique ;
• et, tout simplement, des projets qui grossissent et sollicitent davantage n'importe quel modèle.

Le bon réflexe en 2026 n'est donc plus de chercher le meilleur modèle une fois pour toutes, mais de suivre en continu lequel est le plus fiable pour vos tâches, avec votre scaffold, à un instant donné — et de ne pas hésiter à en combiner plusieurs. C'est exactement l'esprit de notre comparatif GPT vs Claude vs Gemini et de notre Top 25 des LLM open source — et ce sera bientôt celui de notre benchmark maison.