Le 2 juin 2026, Anthropic a subi une panne mondiale généralisée. Les taux d'erreur ont explosé sur Opus 4.6, l'API Claude et le CLI Claude Code. Trois jours plus tard, le 5 juin, une nouvelle perturbation a frappé — touchant claude.ai, l'API, Claude Code et Cowork. L'équipe d'ingénierie de Notion a réagi en désactivant immédiatement tous les modèles Anthropic du sélecteur et en reroutant chaque requête vers des fournisseurs alternatifs. Les utilisateurs ont vécu un changement de modèle. Pas une panne.
Cet écart — entre les équipes qui se sont retrouvées paralysées et celles qui ont rebasculé sans accroc — tient à une seule décision architecturale prise des mois auparavant : traiter ou non l'IA comme une infrastructure.
L'IA est désormais une infrastructure
En 2024, une panne IA signifiait que votre chatbot était temporairement indisponible. En 2026, elle signifie que votre pipeline de développement, votre support client, votre traitement documentaire et vos flux d'onboarding s'arrêtent simultanément.
Thoughtworks a documenté les défaillances en cascade lors de l'incident de juin : les assistants de codage automatisés sont passés hors ligne, la recherche sémantique a régressé vers la recherche par mots-clés, et les pipelines de données alimentés par LLM ont silencieusement cessé de traiter. Les équipes les plus touchées étaient celles qui avaient remplacé la compétence humaine par la compétence IA plutôt que de l'amplifier.
La leçon n'est pas "utiliser moins l'IA". La leçon est de construire l'IA comme toute infrastructure critique : avec redondance, dégradation gracieuse et basculement automatique.
Le piège du fournisseur unique
La plupart des intégrations IA démarrent de la même façon : choisir un fournisseur, obtenir une clé API, livrer. Ça fonctionne jusqu'à ce que ça ne fonctionne plus. Les modes de défaillance sont prévisibles :
- Panne fournisseur — Claude, GPT-4o et Gemini ont tous connu des temps d'arrêt significatifs en 2026
- Limitation de débit — les pics de trafic vous poussent vers des erreurs 429 sans prévenir
- Dépréciation de modèle — les fournisseurs retirent les modèles avec un préavis de 90 jours
- Défaillances régionales — certaines pannes sont géographiquement limitées mais touchent quand même vos utilisateurs
- Pics de coûts — un fournisseur change sa tarification et vos marges s'effondrent du jour au lendemain
Coder en dur un seul endpoint API est un passif. La solution est d'acheminer vos requêtes via une couche qui traite les fournisseurs de modèles comme des ressources de calcul interchangeables.
Construire une chaîne de basculement
Une chaîne de basculement prête pour la production comporte au moins trois niveaux :
- Modèle principal — votre fournisseur préféré pour la qualité et le coût (ex. Claude Opus 4.7)
- Basculement même fournisseur — un modèle moins cher ou plus léger du même éditeur (ex. Claude Haiku 4.5)
- Basculement multi-fournisseur — un éditeur complètement différent (ex. GPT-4o ou Gemini 2.5 Flash)
- Option de dernier recours — un modèle auto-hébergé ou local sans dépendance externe
La chaîne se déclenche sur les codes d'erreur 429, 500, 502, 503 et 529. Chaque niveau dispose d'un budget de retry configurable avant escalade.
Implémentation avec LiteLLM
LiteLLM est la passerelle open source la plus adoptée pour le routage multi-modèles. Voici un exemple minimal en Python utilisant son Router :
from litellm import Router
router = Router(
model_list=[
{
"model_name": "claude-primary",
"litellm_params": {
"model": "anthropic/claude-opus-4-7",
"api_key": "YOUR_ANTHROPIC_KEY",
},
"order": 1,
},
{
"model_name": "claude-haiku-fallback",
"litellm_params": {
"model": "anthropic/claude-haiku-4-5",
"api_key": "YOUR_ANTHROPIC_KEY",
},
"order": 2,
},
{
"model_name": "openai-fallback",
"litellm_params": {
"model": "openai/gpt-4o",
"api_key": "YOUR_OPENAI_KEY",
},
"order": 3,
},
],
fallbacks=[
{"claude-primary": ["claude-haiku-fallback", "openai-fallback"]}
],
num_retries=3,
retry_after=60,
)
response = await router.acompletion(
model="claude-primary",
messages=[{"role": "user", "content": "Résume ce document."}],
)Le champ order contrôle la priorité. Quand un déploiement order=1 échoue, le routeur essaie automatiquement order=2 puis order=3. Le tableau fallbacks vous donne un contrôle explicite sur l'escalade inter-groupes.
OpenRouter comme alternative managée
Si vous préférez ne pas gérer votre propre infrastructure de passerelle, OpenRouter fournit un routage de basculement managé via un seul endpoint API :
const response = await fetch("https://openrouter.ai/api/v1/chat/completions", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.OPENROUTER_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
model: "anthropic/claude-opus-4-7",
models: [
"anthropic/claude-opus-4-7",
"anthropic/claude-haiku-4-5",
"openai/gpt-4o",
],
route: "fallback",
messages: [{ role: "user", content: "Résume ce document." }],
}),
});OpenRouter gère la logique de basculement côté serveur. Si Claude rencontre des problèmes, la requête est automatiquement routée vers le modèle suivant dans votre tableau models. Pour moins de 1 000 requêtes par seconde, cette approche managée supprime une charge opérationnelle significative.
Les circuit-breakers pour les APIs IA
Les retries seuls ne suffisent pas. Sans circuit-breaker, votre application continuera à marteler un fournisseur dégradé, ralentissant sa reprise et aggravant votre latence. Le consensus communautaire pour la configuration :
- Seuil de défaillance — 5 échecs consécutifs ouvrent le circuit
- Période de refroidissement — 60 secondes avant de tester la reprise avec une seule requête sonde
- État semi-ouvert — une sonde réussie ferme le circuit ; un échec le maintient ouvert
Exemple TypeScript avec la bibliothèque cockatiel :
import { CircuitBreakerPolicy, ExponentialBackoff } from "cockatiel";
const claudeCircuit = CircuitBreakerPolicy.circuitBreaker({
halfOpenAfter: 60_000,
breaker: {
threshold: 0.5,
duration: 30_000,
minimumRps: 5,
},
});
const response = await Policy.wrap(claudeCircuit, retryPolicy).execute(() =>
callClaude(prompt)
);Considérations UX lors du basculement
Le basculement entre modèles est invisible pour les utilisateurs seulement si vous le planifiez. Quand un fallback se déclenche, deux choses doivent être vraies :
Cohérence des sorties. Claude Opus retournant une analyse structurée de 2 000 mots suivi de GPT-4o retournant 400 mots de prose libre désorientera les utilisateurs. Normalisez vos prompts avec des instructions de format explicites que tout modèle capable respectera.
Messages de dégradation gracieuse. Pour les fonctionnalités explicitement liées à un modèle spécifique, affichez un signal discret : "L'analyse avancée fonctionne temporairement sur un fournisseur alternatif. Les résultats peuvent légèrement varier." Les utilisateurs tolèrent bien mieux une légère variation de qualité qu'une indisponibilité totale.
Observabilité : savoir avant vos utilisateurs
Le dernier élément est la surveillance sémantique — suivre non seulement si l'API répond, mais si les réponses atteignent votre seuil de qualité. Trois métriques à suivre par appel de modèle :
- Débit en tokens — tokens par seconde, par fournisseur
- Taux d'erreur par code — séparez les 429 (limite de débit) des 5xx (pannes) des 529 (surcharge)
- Latence P95 — pas la moyenne, mais le 95e percentile pour détecter la dégradation de la queue
Des outils comme Langfuse, Helicone et Portkey proposent des tableaux de bord prêts à l'emploi. Définir des seuils d'alerte à 15% de taux d'erreur déclenche le basculement automatique avant que les utilisateurs ne remarquent quoi que ce soit.
Recommandations pour les équipes MENA
Pour les équipes d'ingénierie en Afrique du Nord et au Moyen-Orient, la résilience multi-modèles comporte une dimension supplémentaire : la latence régionale. Plusieurs fournisseurs IA offrent une couverture inégale en Afrique du Nord et dans le Golfe. Benchmarker les fournisseurs — Claude, Gemini, GPT-4o et Mistral — depuis votre région serveur réelle identifie votre modèle principal le plus rapide et le meilleur fallback pour vos utilisateurs locaux, pas seulement les moyennes mondiales.
Les pannes de juin 2026 ont été un test de charge que l'industrie a collectivement échoué. Les équipes qui ont réussi ont construit leurs intégrations IA comme elles construisent leurs bases de données : avec réplication, basculement automatique, et la conviction que tout noeud unique finira par tomber.
Votre modèle principal n'est pas votre infrastructure. Votre couche de routage l'est.
Pour aller plus loin : Documentation OpenRouter Fallbacks · Documentation LiteLLM Router · Analyse Thoughtworks de la panne Claude