Contexte technique
J'ai attentivement examiné le post-mortem d'Anthropic du 23 avril, et le plus intéressant n'est pas le bug lui-même, mais la façon dont une intégration IA d'apparence stable s'est effondrée à cause de plusieurs petites décisions simultanées. Si vous construisez une automatisation IA basée sur les LLM, c'est un scénario très familier : le modèle semble être le même, mais le produit devient soudainement plus bête, plus oublieux et moins pertinent.
Anthropic a décrit trois changements indépendants. Le premier a été effectué le 4 mars : l'effort de raisonnement par défaut de Claude Code a été abaissé de élevé à moyen pour accélérer les réponses. Lors des tests internes, la baisse de qualité semblait modérée, mais en utilisation réelle, les utilisateurs ont obtenu un assistant de code nettement moins performant. Ce changement n'a été annulé que le 7 avril.
Le deuxième changement est survenu le 26 mars. L'équipe voulait vider le cache de raisonnement après une heure d'inactivité, mais un bug a provoqué sa suppression à chaque tour de session suivant. Cela a donné l'impression que Claude oubliait le contexte, se répétait et agissait de manière désorientée. Ce bug a persisté jusqu'au 10 avril.
Le troisième changement est apparu le 16 avril, après la sortie d'Opus 4.7. Pour éliminer la verbosité et réduire la consommation de tokens, Anthropic a ajouté des contraintes au prompt système. C'est là que les choses ont particulièrement mal tourné : la nouvelle instruction, combinée à d'autres modifications du prompt, a dégradé la qualité du codage sur plusieurs versions, y compris Sonnet 4.6, Opus 4.6 et Opus 4.7. L'annulation a eu lieu le 20 avril.
Le point clé : selon Anthropic, le modèle de base et l'API principale n'étaient pas en cause. C'est la couche produit qui a échoué. Honnêtement, c'est mon type d'incident préféré et le plus frustrant, car le coupable n'est pas une version majeure, mais la somme de changements « sûrs » dans les paramètres, la couche de prompts et la gestion de session.
Ce que cela change pour les entreprises et l'automatisation
Pour les équipes, c'est un signal qui incite à la prudence : la dégradation d'un système LLM vient souvent non pas du modèle, mais de l'infrastructure qui l'entoure. Si le développement de votre solution d'IA repose sur des prompts système, du cache, du routage et de l'optimisation de la latence, vous devez tester l'ensemble de l'orchestre, pas seulement le modèle.
Qui sont les gagnants ? Ceux qui ont des déploiements progressifs, des métriques de cohorte appropriées et des restaurations rapides. Qui sont les perdants ? Les équipes qui considèrent les prompts comme n'étant « pas du code » et déploient de tels changements avec peu de discipline d'ingénierie.
Je traite depuis longtemps la couche de prompts comme une partie de l'architecture, et non comme un simple fichier texte improvisé. Chez Nahornyi AI Lab, nous résolvons précisément ces problèmes pour nos clients : nous décomposons l'architecture IA en couches, mettons en place l'observabilité et éliminons les points de fragilité qui peuvent soudainement nuire à la qualité.
Si vous remarquez déjà que votre assistant est brillant un instant et défaillant le suivant sans raison apparente, ce n'est généralement pas de la magie ou une « fatigue du modèle ». Nous pouvons analyser méthodiquement votre pipeline et construire une automatisation IA qui repose sur des garanties d'ingénierie, pas sur la chance. Si vous le souhaitez, chez Nahornyi AI Lab, je peux vous aider à trouver rapidement où se situe la fuite dans votre production.