Claude et ChatGPT semblent moins intelligents après chaque mise à jour ou lors de pics d’affluence : simple biais ou réalité ?

Hier soir, j’ai demandé à Claude de reprendre un tableau qu’il avait bouclé sans broncher le matin même. Réponse tronquée, une colonne oubliée, et ce « voulez-vous que je continue ? ». J’ai juste eu envie de fermer la session et de passer à autre chose.

J’ai eu ce sentiment plusieurs fois, comme s’ils avaient bridé le truc parce que tout le monde se connecte à cette heure-là. Ou que Claude Code sous Opus 5 était devenu stupide depuis la sortie d’Opus 5.5, le 22 septembre. On a tous formulé cette théorie au moins une fois. J’ai essayé de comprendre ce qui est vrai et ce qui est faux.

Pour aller plus loin
Claude Opus 5.5 vs GPT 6-Sol : une bataille entre la puissance et le prix

La question n’est plus anecdotique. Claude Code, Codex et leurs concurrents sont devenus des outils de travail quotidiens, facturés de 20 à 200 euros par mois, et une partie des gens qui les paient dépendent d’eux pour livrer. Un PC portble qui ralentit, on le voit. Un modèle qui change sous nos pieds, on ne le voit pas, et personne ne nous prévient. D’où le soupçon permanent, et d’où l’intérêt de regarder ce qui a été réellement mesuré.

Le phénomène a un nom, la dérive des modèles, et il a été mesuré dès 2023. Cet été-là, des chercheurs de Stanford et Berkeley avaient constaté que GPT-4 reconnaissait un nombre premier dans 97,6 % des cas en mars, puis 2,4 % en juin.

L’étude a été critiquée, notamment par Arvind Narayanan, informaticien à l’université de Princeton. Il y voyait un changement de comportement plutôt qu’une perte de capacité : le modèle ne répondait plus de la même façon, sans être forcément moins bon. Le doute était tout de même installé, et il n’a jamais quitté les forums depuis. Il aura fallu attendre septembre 2025 pour qu’un laboratoire pose lui-même des chiffres sur la table.

Le 17 septembre 2025, Anthropic a publié un premier post-mortem détaillé et reconnu trois bugs d’infrastructure entre août et début septembre. Le plus parlant : une erreur de routage envoyait des requêtes Sonnet 4 vers des serveurs configurés pour la fenêtre de 1 million de tokens, d’abord 0,8 % des requêtes Sonnet 4 à partir du 5 août, puis 16 % à la pire heure du 31 août. Environ 30 % des utilisateurs de Claude Code actifs pendant cette période ont eu au moins un message dégradé. Comme le routage était « collant », une requête tombée sur le mauvais serveur y restait souvent pour la suite de la conversation. Autrement dit, deux personnes assises côte à côte pouvaient vivre deux Claude différents pendant des jours.

Ce premier post-mortem répondait à une question, pas à toutes. La théorie la plus tenace, celle qui ressort à chaque baisse de forme, ne parle pas de routage. Elle parle de compression.

Quantification, les réglages silencieux

Le principe de la quantification tient en quelques lignes. Un modèle est fait de milliards de nombres, généralement stockés en 16 bits. Les compresser en 8 ou 4 bits divise la mémoire nécessaire par deux ou quatre, donc le nombre de GPU par utilisateur, et donc la facture. Pour un labo qui sert des millions de requêtes par jour, la tentation est évidente.

À 8 bits, la perte est quasi invisible. À 4 bits, les erreurs apparaissent sur le code et les raisonnements longs, sauf pour les modèles entraînés pour ça dès le départ, comme Kimi K3 de Moonshot, livré nativement en MXFP4 depuis juillet.

Les laboratoires d’IA fermés ne disent jamais en quelle précision ils servent leurs modèles. Anthropic affirme noir sur blanc ne jamais réduire la qualité selon la demande, l’heure ou la charge, et attribue ses baisses de qualité à des bugs ou à des réglages de ses outils. Rien ne permet de prouver le contraire chez OpenAI ou Google non plus, ce qui est à la fois rassurant et un peu frustrant.

La pratique est en revanche documentée chez les hébergeurs tiers de modèles ouverts : OpenRouter a dû créer un mode de routage « Exacto » après avoir constaté que deux fournisseurs servant le même modèle n’obtiennent pas toujours la même fiabilité en appel d’outils. Même poids, même nom, résultats différents. Le soupçon vient de là, et il n’est pas absurde.

Pour Anthropic, la piste de la compression reste donc une hypothèse sans preuve. Le second post-mortem, publié le 23 avril 2026, est bien plus intéressant parce qu’il liste ce que l’entreprise a réellement modifié. Le 4 mars, Anthropic a baissé l’effort de raisonnement par défaut de Claude Code de « élevé » à « moyen » pour corriger une latence qui figeait l’interface.

Anthropic est revenu sur ce choix le 7 avril, en reconnaissant un mauvais compromis. Le niveau d’effort reste réglable à la main dans Claude Code avec la commande /effort : c’est le premier réflexe à avoir quand les réponses paraissent bâclées, bien avant d’accuser le modèle.

Deux autres changements se sont empilés par-dessus. Le 26 mars, Anthropic a déployé une optimisation censée effacer une seule fois l’historique de réflexion des sessions restées inactives plus d’une heure. À cause d’un bug, l’effacement se répétait ensuite à chaque échange : Claude oubliait pourquoi il avait fait ses choix, se répétait, et les quotas fondaient plus vite. Le bug a été corrigé le 10 avril. Enfin, une consigne ajoutée au prompt système le 16 avril pour raccourcir les réponses a fait perdre 3 % sur l’une des évaluations internes d’Anthropic, avant d’être retirée le 20 avril.

Les problèmes ont duré près de sept semaines, du 4 mars au 20 avril, et venaient de trois causes distinctes. Aucune ne touchait au modèle lui-même, dont les poids n’avaient pas bougé. Anthropic avait modifié les réglages autour (l’effort de raisonnement, le cache et le prompt système), chacun sur une partie différente des utilisateurs de Claude Code, ce qui explique pourquoi les plaintes semblaient incohérentes d’une personne à l’autre. Seul le passage à l’effort « moyen » était expliqué, par une fenêtre dans l’outil. Pour ce réglage-là, au moins, ça ressemblait beaucoup à un bridage volontaire. Anthropic ne l’appelle juste pas comme ça.

Seuls Claude Code, le Claude Agent SDK et Claude Cowork étaient touchés : l’API d’Anthropic n’a pas bougé pendant cette période. Le 23 avril, l’entreprise a réinitialisé les limites d’usage de tous ses abonnés. Aucun de ces trois bugs n’avait de lien avec l’heure de la journée, et cette partie de la théorie mérite donc un traitement à part.

Pourquoi ça semble pire à 18 h

De ce que l’on sait, l’heure ne change rien au modèle, mais elle pèse sur tout ce qui l’entoure. Cette impression de « flemmardise » en fin de journée a plusieurs explications, et aucune ne nécessite un complot.

À 18 h à Paris, il est 9 h en Californie : les Américains commencent leur journée alors que les Européens n’ont pas fini la leur. La latence grimpe, et une réponse lente paraît paresseuse même quand elle est identique. Au lancement de GPT-5 en août 2025, le trafic de l’API a doublé en 24 heures et le routeur automatique est tombé en panne. Sam Altman, CEO d’OpenAI, a lui-même admis que le modèle semblait « bien plus bête » ce jour-là.

Aux heures chargées, on tape aussi plus vite dans ses limites d’usage, et certaines offres basculent alors vers un modèle plus petit sans forcément le crier sur les toits.

Il y a aussi nous. En fin de journée, on écrit des prompts plus courts, dans des conversations plus longues, où un contexte saturé dégrade les réponses. Et on est moins patient, ce qui n’aide pas. En décembre 2023, le développeur Rob Lynch a même lancé sur X la « théorie des vacances d’hiver » : GPT-4 Turbo répondait plus court quand on lui faisait croire qu’on était en décembre plutôt qu’en mai, comme s’il imitait la baisse de régime des humains avant Noël.

OpenAI a répondu ne pas avoir touché au modèle depuis le 11 novembre. Le chercheur Ian Arawjo n’a pas réussi à reproduire le test avec un résultat statistiquement significatif. Le bridage aux heures de pointe, en tant que réglage délibéré du modèle, ne tient donc pas. En revanche, la file d’attente, les quotas et la fatigue de l’utilisateur, eux, sont bien réels à 18 h.

Si on met tout bout à bout, le tableau est plus simple que les théories. Le modèle lui-même, ses poids, ne change pas entre deux versions annoncées. Ce qui bouge en permanence, c’est tout ce qu’il y a autour : le prompt système, le niveau d’effort par défaut, la gestion du cache, le routage des requêtes, la charge des serveurs. Chacune de ces couches peut être modifiée un mardi sans annonce, et chacune des dégradations documentées à ce jour venait de là. Quand Claude « devient nul », ce n’est pas le cerveau qui rétrécit, c’est la plomberie autour qui a été retouchée.

Ça change deux choses pour celui qui paie. D’abord, les réflexes utiles ne sont pas ceux qu’on croit : vérifier /effort, relancer une session quand le contexte est saturé, regarder la version de l’outil et la page de statut avant de changer de crémerie. Ensuite, la distinction entre un bug et un bridage est plus mince que les labos ne le disent. Anthropic répète ne jamais dégrader ses modèles volontairement. Pourtant, passer tout le monde à l’effort « moyen » pour économiser du calcul était un choix assumé, présenté comme un compromis.