Panne Claude : runbook 429, 529 et repli dans l'UE

TL;DR

Une panne Claude se manifeste par des erreurs 529 (surcharge), 500 ou 504. Un 429 vient le plus souvent de vos propres limites. Relancez avec backoff et jitter, sauf un 429 de plafond de dépenses. Pour des données personnelles, basculez entre le profil UE de Bedrock et la multirégion eu de Vertex. L’API Anthropic n’offre pas d’inférence dans l’UE.

Quelle erreur Claude signifie quoi ?

Trois familles. 529, 500 et 504 signalent un problème chez le fournisseur : on relance, puis on bascule. 429 signifie que vous avez atteint une limite, soit une limite de débit qui se lève après retry-after, soit un plafond de dépenses qu’aucune relance ne débloque. 400, 401, 403 et 413 sont vos propres erreurs, qu’un repli ne ferait que masquer.

La page des erreurs de l’API Claude décrit le 529 overloaded_error comme une surcharge temporaire, possible lorsque le trafic est élevé pour l’ensemble des utilisateurs. Elle précise aussi qu’une hausse brutale de votre propre usage peut déclencher des 429 liés aux limites d’accélération. Bedrock et Vertex habillent les mêmes modèles avec leur propre vocabulaire d’erreurs. L’ingénieur d’astreinte a donc besoin d’un seul tableau, pas de trois onglets de documentation.

Code	Où	Signification	Action
429 rate_limit_error	API Claude	Limite RPM, ITPM ou OTPM atteinte	Attendre retry-after, puis relancer
429 avec enforced_spend_limit_reached	API Claude	Plafond mensuel du niveau atteint	Ne pas relancer. Changer de niveau ou basculer
400 invalid_request_error	API Claude	Requête invalide ou limite de dépenses fixée par vous	Corriger la requête ou relever la limite
500 api_error / 504 timeout_error	API Claude	Erreur interne ou délai dépassé	Relancer avec backoff, streamer les longs traitements
529 overloaded_error	API Claude, Bedrock	Capacité du fournisseur, pas votre quota	Relancer avec jitter, puis basculer
429 ThrottlingException	Bedrock	Quota du compte AWS dépassé	Backoff, hausse de quota ou seconde route
503 ServiceUnavailable	Bedrock	Forte demande dans la région	Backoff, inférence interrégionale
429 “Resource exhausted, please try again later.”	Vertex	Capacité partagée en paiement à l’usage épuisée	Backoff exponentiel, puis basculer

Deux détails changent le runbook. La page des limites de débit indique que le 429 de plafond n’a pas d’en-tête retry-after et échoue jusqu’au premier jour du mois suivant à 00:00 UTC. Les plafonds sont de 500 USD (Start), 1 000 USD (Build) et 200 000 USD (Scale). Et la référence des erreurs Bedrock précise qu’un 503 n’a rien à voir avec vos quotas, qui renvoient un 429. Lisez le code avant d’ouvrir un ticket.

Comment relancer correctement les erreurs 429 et 529 ?

Confiez les relances au SDK, pas à une boucle maison. Les SDK Anthropic relancent déjà deux fois les erreurs de connexion, 408, 409, 429 et tous les 5xx (donc le 529), avec un backoff exponentiel court, en respectant retry-after. Augmentez max_retries avec mesure pour les traitements par lots, restez bas pour les appels interactifs.

La documentation du SDK Python donne les valeurs par défaut : 2 relances et 10 minutes de délai par requête. Les relances ne corrigent pas une limite trop basse. Les limites suivent un seau à jetons, et Anthropic précise que 60 RPM peuvent être appliqués comme 1 requête par seconde : 20 appels parallèles peuvent être bridés même si le total à la minute semble correct. Au niveau Start, Sonnet 5 et Opus 5.5 autorisent chacun 1 000 RPM, 2 000 000 de tokens en entrée et 400 000 en sortie par minute. Les lectures en cache ne comptent pas dans l’ITPM pour la plupart des modèles : le prompt caching est la hausse de capacité la moins chère.

import anthropic

# Appels interactifs : échouer vite pour laisser la route de secours prendre le relais
interactive = anthropic.Anthropic(max_retries=2, timeout=60.0)

# Traitements par lots : plus de patience
batch = anthropic.Anthropic(max_retries=6)

try:
    msg = interactive.messages.create(
        model="claude-sonnet-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": "Résume ce ticket."}],
    )
    print(msg._request_id)
except anthropic.RateLimitError as e:
    # Plafond de dépenses : pas de retry-after, inutile de relancer
    print(e.status_code, e.response.headers.get("retry-after"))

AWS recommande sur Bedrock un backoff exponentiel avec jitter aléatoire pour les 429, 500, 503 et 529, et met en garde contre les relances synchronisées de nombreux clients, qui retardent le rétablissement. La page Google sur l’erreur 429 dit la même chose pour Vertex. Un piège côté AWS : les passerelles NAT, les endpoints d’interface VPC et les Network Load Balancers coupent les connexions TCP inactives après 350 secondes, alors que le keep-alive Linux part par défaut après 7 200 secondes. Les longs appels en streaming meurent en silence et ressemblent à une panne. Le remède : tcp_keepalive=True dans la configuration boto3 et un keep-alive noyau sous 350 secondes.

Quel repli garde Claude dans l’UE ?

Bedrock avec le profil d’inférence géographique eu. et Vertex avec la multirégion eu. Les deux servent les modèles Claude actuels, traitent les requêtes dans des régions de l’UE et coûtent 10 % de plus que leurs routes globales. L’API Anthropic ne convient pas : inference_geo n’accepte que us et global, et le workspace geo est uniquement américain.

Beaucoup d’équipes l’ignorent. La page sur la résidence des données liste exactement deux zones d’inférence. Un repli vers api.anthropic.com fait donc sortir des données personnelles de l’UE pendant l’incident, au moment précis où personne ne pense au RGPD. Les routes globales de Bedrock et de Vertex produisent le même effet. Le premier conseil de Google contre les 429 est d’utiliser l’endpoint global. Pour des données soumises au RGPD, ignorez ce conseil.

Route	Identifiant du modèle	Hébergement des données	Capacité documentée
Profil géographique UE de Bedrock	eu.anthropic.claude-opus-5-5, eu.anthropic.claude-sonnet-5	Régions UE	2 M TPM en entrée par défaut, jusqu’à 5 M en entrée et 500 000 en sortie sur demande
Multirégion eu de Vertex	claude-opus-5-5, claude-sonnet-5	Multirégion UE	Opus 5.5 : 1 000 QPM, 10 M TPM en entrée. Sonnet 5 : 1 250 QPM, 12,5 M TPM en entrée
Bedrock global, Vertex global	préfixe global., region="global"	Monde entier	Vertex Opus 5.5 global : 2 000 QPM
API Claude	claude-opus-5-5	global ou us uniquement	Limites du niveau, voir plus haut

Les deux routes UE tombent indépendamment l’une de l’autre, car elles tournent sur deux clouds avec deux systèmes de quotas. Deux points tirés de la documentation AWS sur l’inférence interrégionale : vos SCP doivent autoriser toutes les régions de destination du profil, sinon le profil lui-même casse, et CloudTrail journalise chaque requête dans la région source, avec le champ additionalEventData.inferenceRegion qui indique où elle a été traitée. Conservez ce champ comme preuve pour votre DPO. La mise en place des deux routes est détaillée dans nos guides Claude sur AWS Bedrock en Europe et Claude sur Vertex AI en Europe.

Ne confondez pas avec le paramètre fallbacks d’Anthropic. La page sur les refus et le fallback indique que seul un refus d’un classifieur de sécurité le déclenche : limite de débit, surcharge ou erreur serveur sont renvoyées telles quelles. Il n’existe pas non plus sur Bedrock ni sur Google Cloud. C’est un outil contre les refus, pas contre les pannes.

Côté client, le repli tient en une courte boucle sur deux clients :

import anthropic
from anthropic import AnthropicBedrock, AnthropicVertex

ROUTES = [
    (AnthropicBedrock(aws_region="eu-west-3", max_retries=2), "eu.anthropic.claude-sonnet-5"),
    (AnthropicVertex(project_id="mon-projet-ue", region="eu", max_retries=2), "claude-sonnet-5"),
]
FAILOVER = (anthropic.RateLimitError, anthropic.InternalServerError, anthropic.APIConnectionError)

def ask(messages, max_tokens=1024):
    last = None
    for client, model in ROUTES:
        try:
            return client.messages.create(model=model, max_tokens=max_tokens, messages=messages)
        except FAILOVER as e:  # 429, 5xx dont 529, réseau
            last = e
    raise last

Les erreurs 400, 401 et 403 ne figurent pas dans FAILOVER, volontairement. Une requête invalide échoue sur les deux clouds, et une erreur d’authentification sur l’un d’eux est un problème de configuration que vous voulez voir.

Avec une passerelle, la même logique passe dans la configuration. LiteLLM bascule vers le groupe de modèles suivant une fois num_retries épuisé, et sa documentation des fallbacks indique que les erreurs 429 et 500 sont couvertes. LiteLLM traduit la location eu en aiplatform.eu.rep.googleapis.com. L’installation de base est décrite dans notre article sur la passerelle LiteLLM dans l’UE.

model_list:
  - model_name: claude-eu
    litellm_params:
      model: bedrock/eu.anthropic.claude-sonnet-5
      aws_region_name: eu-west-3
  - model_name: claude-eu-vertex
    litellm_params:
      model: vertex_ai/claude-sonnet-5
      vertex_ai_project: mon-projet-ue
      vertex_ai_location: eu

litellm_settings:
  num_retries: 2
  allowed_fails: 3
  cooldown_time: 30
  fallbacks: [{"claude-eu": ["claude-eu-vertex"]}]

allowed_fails et cooldown_time reprennent les valeurs d’exemple de la documentation, un bon point de départ. Chaque ligne des spend logs enregistre attempted_fallbacks et original_model_group : vous saurez combien de requêtes la route de secours a servies. Depuis LiteLLM v1.85.0, le drapeau mock_testing_fallbacks est retiré des requêtes Proxy. Testez le repli en cassant volontairement la route principale en préproduction, par exemple avec une mauvaise région ou une permission IAM retirée.

Quel est le runbook d’incident, étape par étape ?

Détectez la panne avec votre propre taux d’erreurs, confirmez-la sur la bonne page de statut, basculez délibérément et notez les identifiants de requête dès le début. En cas de panne Claude, l’essentiel du temps se perd sur la mauvaise page de statut ou en relances contre un plafond de dépenses. Le runbook ci-dessous tient sur un écran.

status.claude.com liste claude.ai, Claude Console, Claude API, Claude Code, Claude Cowork et Claude for Government. Bedrock et Vertex n’y figurent pas. En septembre 2026, la page a recensé 13 incidents, dont 8 touchant le composant Claude API, le plus souvent des taux d’erreur élevés sur certains modèles. Un incident affiché là ne prouve pas que Bedrock est en panne, et un problème Bedrock n’y apparaîtra pas. Abonnez l’astreinte aux trois sources : la page de statut Claude (e-mail, SMS, Slack, Teams, webhook ou Atom), l’AWS Health Dashboard et Google Cloud Service Health.

1. Alerter. Déclencher l’astreinte quand le taux de 5xx et de 429 sur les appels Claude dépasse votre seuil pendant 5 minutes, ventilé par fournisseur et par modèle.
2. Qualifier. Lire le code et le corps de la réponse. Plafond de dépenses (enforced_spend_limit_reached) ou 4xx : arrêter les relances, escalader au responsable du budget. 429 de bridage, 503, 529 : fournisseur ou capacité.
3. Localiser. Consulter status.claude.com, AWS Health et Google Cloud Service Health. Noter si un modèle, une route ou tout est touché.
4. Basculer. Si la passerelle ne l’a pas déjà fait, envoyer le trafic sur l’autre route UE. Jamais vers une route globale ni vers api.anthropic.com pour des données personnelles.
5. Délester. Suspendre les traitements par lots, réduire la concurrence, passer les fonctions non critiques sur un modèle plus petit de la même route UE.
6. Communiquer. Premier point interne sous 15 minutes : impact, route active, heure du prochain point. Puis toutes les 30 minutes. Les clients ne sont informés que si la bascule a échoué.
7. Conserver les preuves. Garder les request-id des appels API Claude en échec, les identifiants de requête AWS et les horodatages. Pour un ticket 529, AWS demande l’identifiant de requête, l’identifiant du modèle, la région et l’heure.
8. Revenir. Rebasculer seulement après 30 minutes sans erreur sur la route principale, pour éviter les allers-retours.
9. Post-mortem. Sous 5 jours ouvrés : chronologie, nombre de requêtes servies par la route de secours, écart de coût et une modification concrète des quotas, des alertes ou de la configuration.

Les intervalles de 15 et 30 minutes sont notre recommandation, pas une exigence des fournisseurs.

Exploiter en interne ou externaliser ?

Exploitez en interne si vous avez déjà une astreinte 24 h/24 et des comptes AWS et Google Cloud. Construire le repli prend quelques jours. Le coût réel est dans l’exploitation : revues de quotas, exercices, changements d’identifiants de modèles et post-mortems. Externalisez si Claude est critique pour l’activité mais que personne n’est joignable la nuit.

Ce que recouvre l’exploitation en interne :

Tâche	Qui	Fréquence
Astreinte sur les routes Claude	Équipe plateforme ou SRE	24 h/24 si Claude est exposé aux clients
Revue des quotas, demandes de hausse chez AWS et Google	Responsable plateforme	À chaque lancement de modèle, au moins chaque trimestre
Exercice de bascule en préproduction	Ingénieur plateforme	Chaque trimestre (notre recommandation)
Alignement des identifiants de modèles sur les deux clouds	Ingénieur plateforme	À chaque version (Opus 5.5 est arrivé sur Vertex le 22 septembre 2026)
Post-mortem et communication de statut	Responsable d’incident	À chaque incident

Notre estimation, et non un chiffre sourcé : 2 à 4 jours-homme pour construire et tester la double route, puis environ une demi-journée par mois pour les exercices, les quotas et les mises à jour de modèles, plus le coût de l’astreinte. Sans astreinte de nuit, le vrai coût est l’astreinte, pas le code.

Confier ce périmètre à un prestataire de services managés a du sens quand Claude se trouve dans un parcours client et que la couverture de nuit manque, ou quand il faudrait ouvrir un second cloud uniquement pour le repli. Cela en a peu pour des outils internes, où deux heures de panne sont gênantes sans être coûteuses, ou si le prestataire ferait transiter le trafic par ses propres comptes, ce qui change l’identité du sous-traitant.

Ce qu’il faut exiger d’un prestataire sur ce sujet :

• Un SLA au périmètre réaliste. Des délais de réaction par niveau de gravité pour la détection et la bascule. Un prestataire ne peut pas garantir une capacité qu’AWS ou Google ne garantissent pas, et Google exclut les 429 en paiement à l’usage de son taux d’erreur SLA.
• Contrat de sous-traitance et sous-traitants ultérieurs. Un contrat conforme à l’article 28 du RGPD et une liste des sous-traitants ultérieurs qui nomme AWS et Google avec les régions exactes. Vérifiez qu’aucune route globale ni aucun repli vers l’API Anthropic ne figure dans leur configuration.
• Modèle d’accès. Exploitation dans vos propres comptes AWS et Google Cloud via des rôles à privilèges minimaux, lecture des journaux, aucune copie des prompts dans les systèmes du prestataire.
• Réversibilité. Configuration de la passerelle, règles d’alerte et runbook dans votre dépôt. Clés et quotas restent dans vos comptes, pour reprendre la main en une journée.

Les prix, y compris la majoration de 10 % sur les deux routes UE, figurent dans notre comparatif des prix de l’API Claude.

FAQ

Une erreur Claude 529 est-elle de ma faute ?

Non. Un 529 overloaded_error signifie que le fournisseur manque temporairement de capacité. Votre quota, lui, renvoie un 429. Relancez avec backoff et jitter, et basculez sur la seconde route UE si les 529 durent plus de quelques minutes.

Quelle différence entre un 429 et un 529 chez Claude ?

Un 429 indique une limite atteinte : limite de débit, limite d’accélération ou plafond de dépenses. Un 529 indique qu’Anthropic ou le fournisseur cloud est surchargé pour tout le monde. Un 429 de débit se lève après retry-after. Un 429 de plafond attend le mois suivant ou un niveau supérieur.

Le repli dans l’UE coûte-t-il plus cher qu’une route globale ?

Oui. Les endpoints régionaux et multirégionaux de Bedrock et Vertex coûtent 10 % de plus que les endpoints globaux pour les modèles actuels. L’inférence limitée aux États-Unis sur l’API Claude coûte 1,1 fois le tarif standard. Pendant une panne, la route de secours facture à ses propres prix : budgétez les deux.

Peut-on se replier sur l’API Anthropic tout en restant dans l’UE ?

Non. L’API Claude n’accepte que us et global pour inference_geo, et le workspace geo est uniquement américain. Pour l’hébergement des données dans l’UE, la paire de repli est Bedrock avec un profil eu. et Vertex avec la multirégion eu.

Le paramètre fallbacks d’Anthropic aide-t-il pendant une panne ?

Non. Il ne relance une requête que lorsqu’un classifieur de sécurité la refuse. Limites de débit, surcharge et erreurs serveur sont renvoyées sans changement, et le paramètre n’existe pas sur Bedrock ni sur Google Cloud.

Où vérifier si Claude est en panne ?

Sur status.claude.com pour l’API Claude, claude.ai et Claude Code. Bedrock et Vertex n’y figurent pas : consultez aussi l’AWS Health Dashboard et Google Cloud Service Health. Vos propres métriques d’erreurs réagissent plus vite que n’importe quelle page de statut.

Combien de relances configurer ?

Gardez la valeur par défaut du SDK, 2, pour les appels interactifs afin que la route de secours prenne vite le relais. Augmentez max_retries pour les traitements par lots qui peuvent attendre. Ne relancez jamais un 429 de plafond de dépenses, ni les 400, 401 ou 403.

Sources

1. Documentation Anthropic : erreurs de l'API (1 octobre 2026)
2. Documentation Anthropic : limites de débit (1 octobre 2026)
3. Documentation Anthropic : SDK Python (1 octobre 2026)
4. Documentation Anthropic : résidence des données (1 octobre 2026)
5. Documentation Anthropic : refus et fallback (1 octobre 2026)
6. Documentation Anthropic : Claude dans Amazon Bedrock (1 octobre 2026)
7. Documentation Anthropic : Claude sur Google Cloud (1 octobre 2026)
8. AWS : codes d'erreur de l'API Bedrock (1 octobre 2026)
9. AWS : inférence interrégionale (1 octobre 2026)
10. AWS : inférence interrégionale géographique (1 octobre 2026)
11. AWS : fiche modèle Claude Opus 5.5 (1 octobre 2026)
12. Google Cloud : code d'erreur 429 (1 octobre 2026)
13. Google Cloud : Claude Opus 5.5 (1 octobre 2026)
14. Google Cloud : Claude Sonnet 5 (1 octobre 2026)
15. Documentation LiteLLM : fallbacks (1 octobre 2026)
16. Page de statut Claude (1 octobre 2026)