Résumé
- L’incident Opus 4.8 et Haiku 4.5 a duré de 13:37:28Z à 15:23:37Z le 22 juillet.
- Haiku 4.5 a récupéré avant Opus 4.8 et avant la clôture complète de cette première fiche.
- Un incident Sonnet 5 distinct a commencé à 15:24:05Z, soit 28 secondes plus tard, et s’est terminé à 16:12:32Z.
- Les deux fiches citaient claude.ai, Console, API, Claude Code et Cowork.
- Anthropic n’a publié ni cause commune, ni nombre d’utilisateurs touchés, ni taux d’erreur, ni constat de perte de données.
La récupération anticipée de Haiku montre pourquoi «Claude est en panne» et «Claude est rétabli» sont des abstractions trop larges pour un système de production. Un client qui pouvait choisir son modèle aurait pu remettre certaines tâches en circulation avant la fermeture de la première fiche. Un autre, dépendant d’Opus 4.8, devait continuer à attendre ou à appliquer son plan de repli.
Cette différence précède une frontière temporelle exceptionnellement courte. La première fiche s’est fermée, puis la seconde s’est ouverte presque immédiatement. Du point de vue d’une file de travail automatisée, il n’existe pas assez de temps pour observer une récupération stable. Du point de vue de l’analyse des incidents, les identités restent toutefois séparées.
Une récupération par étapes change le choix de repli
Anthropic a ouvert la fiche Opus/Haiku à 13:37:28Z avec un impact qualifié de mineur. Le fournisseur a ensuite indiqué que Haiku 4.5 avait récupéré tandis qu’Opus 4.8 subissait toujours des erreurs élevées. La situation est passée en surveillance à 15:06:53Z, puis a été résolue à 15:23:37Z.
Ces transitions donnent plus d’information qu’un indicateur unique. Une application capable de remplacer un modèle par un autre pouvait tester Haiku et reprendre une catégorie de tâches compatible. Elle ne devait pas supposer que la même décision convenait aux requêtes nécessitant Opus, à des contextes longs ou à des outils dont le comportement diffère selon le modèle.
Les cinq surfaces listées étaient claude.ai, Console, API, Claude Code et Cowork. La présence d’un nom dans cette liste ne signifie pas que chaque requête a échoué. De même, le mot «mineur» n’indique pas un nombre de clients. La fiche fournit des états, des modèles et des composants, mais ni taux d’échec, ni répartition géographique, ni volume de files bloquées.
Sonnet a créé un nouveau risque de reprise
À 15:24:05Z, Anthropic a ouvert une autre fiche pour Sonnet 5. Le problème a été déclaré identifié à 15:36:57Z et résolu à 16:12:32Z. L’impact était à nouveau classé mineur et la fiche reprenait les mêmes cinq surfaces.
L’intervalle de 28 secondes vient des horodatages milliseconde de l’API de statut. Sa précision ne doit pas servir à inventer un mécanisme. Rien ne montre que la récupération d’Opus a déclenché les erreurs de Sonnet, ni qu’une réparation a déplacé la panne. Anthropic n’a pas publié une telle relation.
Fusionner les deux fiches en une panne technique unique produirait donc une cause commune sans preuve et effacerait la différence entre modèles. La formulation justifiée est plus étroite: des clients utilisant plusieurs modèles Claude ont rencontré deux séquences d’erreurs adjacentes, avec pratiquement aucun intervalle pour reconstruire leur confiance opérationnelle.
Une relance sûre exige plus qu’une page verte
Une équipe peut imposer une période de succès sur des requêtes synthétiques visant exactement le modèle et l’interface utilisés. Elle peut rouvrir le trafic progressivement, conserver les clés d’idempotence, plafonner les nouvelles tentatives et garder un modèle ou un fournisseur de secours pour les tâches dont les contraintes permettent une substitution.
Le contrôle de santé devrait au minimum distinguer modèle et surface. Un état global aurait masqué le fait que Haiku avait récupéré avant Opus, puis que Sonnet possédait sa propre fiche. Pour certains usages, le contrôle doit aller jusqu’au type de charge: appels d’outils, gros contextes et tâches interactives ne prouvent pas leur santé de la même manière.
Les deux événements arrivent après les quatre fiches déjà couvertes par la précédente limite temporelle de BTW. Ils constituent donc une nouvelle récurrence. Cette répétition peut justifier davantage de prudence, mais elle ne transforme pas les épisodes antérieurs et actuels en une seule défaillance prolongée.
Les inconnues empêchent de calculer la disponibilité
Anthropic n’a communiqué aucune cause commune, aucun nombre d’utilisateurs affectés, aucun pourcentage d’erreurs, aucune distribution régionale, aucune perte de données et aucune décision de crédit de service. Il n’est donc pas possible d’en déduire une estimation de disponibilité, une saturation de capacité ou un impact financier global.
La chronologie, elle, est vérifiable: environ une heure et 46 minutes pour la première fiche, 28 secondes d’intervalle, puis environ 48 minutes pour la seconde. La leçon se trouve dans l’écart entre ces deux mesures. La page de statut décrit l’identité choisie par le fournisseur; le client doit décider, avec ses propres sondes, quand son travail peut réellement reprendre.