Résumé
- L'incident majeur Haiku 4.5 a duré de 13:04:35 à 16:38:26 UTC le 21 juillet et est revenu à l'état « identifié » après une première surveillance.
- Une fiche critique multi-modèles situe les erreurs élevées entre 15:28 et 16:26, bien qu'elle n'ait été fermée qu'à 18:18.
- Un autre incident critique a touché la création de documents et plusieurs outils Claude de 17:40 à 18:03.
- Opus 4.1 a connu un incident mineur distinct sur l'API et Claude Code de 08:34 à 09:00 le 22 juillet.
- Anthropic n'a publié ni cause commune, ni taux d'erreur, ni nombre d'utilisateurs, ni répartition régionale.
Une page d'état raconte ce que le fournisseur croit savoir à un instant donné. Le 21 juillet, celle de Haiku 4.5 a montré la limite de cette croyance: Anthropic est passé en surveillance à 13:22, puis a dû revenir à un problème identifié à 14:44.
La rechute rend la journée plus importante qu'une simple addition de minutes. Elle oblige le client à vérifier sa propre reprise. Mais elle n'autorise pas à fusionner les trois autres fiches dans une panne unique.
Haiku a connu deux tentatives de stabilisation
La fiche Haiku, classée majeure, commence à 13:04:35. Elle couvre claude.ai, la Console, l'API, Claude Code et Cowork. Après identification et première surveillance, elle revient à l'état identifié, repasse en surveillance à 15:30 et se ferme à 16:38.
Anthropic ne dit pas si la première correction était incomplète, si un autre symptôme est apparu ou si le signal d'amélioration était trompeur. Le fait prouvé est plus sobre: le premier état de surveillance n'a pas tenu.
Pour une équipe cliente, un test synthétique réussi ne suffit pas non plus. Il faut observer plusieurs requêtes, vérifier les files en attente et distinguer un modèle disponible d'un flux de travail entièrement rétabli.
L'incident multi-modèles a une fenêtre d'impact précise
La fiche critique ouverte à 15:35 indique dans son bilan final que les utilisateurs ont subi des erreurs élevées de 15:28 à 16:26. Elle est pourtant restée ouverte jusqu'à 18:18.
La première durée mesure l'impact déclaré. La seconde mesure le cycle de gestion et de confirmation. Présenter tout l'intervalle comme une panne continue exagérerait les faits; ignorer le temps de surveillance masquerait l'incertitude opérationnelle.
Cette fiche concerne claude.ai, l'API, Claude Code et Cowork. Son chevauchement avec Haiku suggère une concentration de risque, pas une racine commune démontrée.
Les outils de production ont ensuite leur propre horloge
À 17:40, Anthropic ouvre un incident critique distinct affectant notamment la création de documents, Cowork Remote, Claude Code, sa version Web, Claude Tag et Claude Design. La surveillance débute à 17:51 et la résolution arrive à 18:03.
Cette séparation est utile. Une réponse de modèle peut fonctionner alors que l'environnement distant, le document ou l'orchestration échoue. Une entreprise doit tester l'inférence et les outils périphériques comme des dépendances différentes.
Le 22 juillet, Opus 4.1 ajoute un épisode mineur: identification à 08:34, surveillance à 08:45, résolution à 09:00 pour l'API et Claude Code.
Le client peut vivre une journée continue sans cause continue
Du point de vue d'une équipe qui passe d'un modèle à l'autre, ces événements peuvent former une longue journée instable. Du point de vue causal, ils restent quatre dossiers. Les étiquettes majeur, critique et mineur ne s'additionnent pas et ne mesurent pas un nombre universel d'utilisateurs touchés.
Anthropic ne fournit ni volume, ni région, ni perte de données, ni crédit contractuel. Le mécanisme économique certain est celui de la coordination: files suspendues, reprises prudentes, contrôles manuels et choix d'un modèle ou fournisseur de secours.
Un futur rapport pourra relier les dépendances et expliquer la rechute de Haiku. En attendant, la lecture rigoureuse tient en une phrase: plusieurs surfaces Claude ont échoué à des moments proches, mais les données publiques ne prouvent pas une panne technique unique.