13 février 2026, 14h47 UTC. Anthropic Claude est en outage pendant 2h13. Sur les SaaS clients que je suis, 4 ont eu une indisponibilité produit complète. 2 ont continué à servir, en mode dégradé propre. La différence : le mode dégradé était documenté, testé, et activable en moins de 5 minutes.
Quand votre produit dépend d'un LLM tiers, le PCA n'est pas une option de luxe. C'est devenu une exigence client (questionnaires enterprise), une exigence régulatoire (DORA pour les fintechs, NIS2 pour beaucoup d'autres), et un différenciateur commercial concret.
Voici le plan qu'on déploie en mission. Pas une bibliothèque de patterns théoriques — ce qui marche en vrai chez 6 clients en 2025-2026.
La réalité chiffrée des outages provider
Les SLA marketing sont rassurants. Les chiffres observés en production sont plus humbles :
- Anthropic : ~99.5% en 2024-2025, soit ~43h d'indisponibilité cumulée par an, en plusieurs incidents.
- OpenAI : ~99.3%, soit ~60h/an.
- Mistral : ~99.4%, similar.
- Azure OpenAI : meilleur (99.9%+) grâce au backbone Azure, mais avec ses propres pannes corrélées.
Les incidents les plus visibles sont souvent les pannes courtes (1-2h). Les plus dangereuses sont les dégradations longues : latence × 10, taux d'erreur à 30%, throughput divisé par 5. Pas binaire, et plus difficile à détecter automatiquement.
Le cadre du PCA en 4 questions
Q1 — Quel est le RTO acceptable côté business ?
Pour chaque fonctionnalité qui utilise un LLM :
- Combien de temps peut-elle être indisponible sans perte client ?
- Combien de temps peut-elle être dégradée (qualité réduite) sans perte client ?
Réponses typiques observées :
- Chatbot support client : RTO 15-30 min acceptable, dégradation OK pendant 4h.
- Assistant IA générant des contrats : RTO 1h, dégradation OK pendant 24h.
- Modération automatique de contenu temps réel : RTO 0 (mode dégradé requis immédiatement).
- Pipeline data enrichment batch : RTO 4-8h, recovery 24h OK.
Ces réponses pilotent toute la suite du PCA.
Q2 — Quel niveau de continuité est rentable ?
Trois niveaux possibles, par fonctionnalité :
- Niveau 1 : dégradation acceptée (fonctionnalité OFF temporairement, message clair à l'utilisateur).
- Niveau 2 : modèle de secours dégradé (un modèle plus simple ou plus lent, mais qui répond).
- Niveau 3 : fail-over provider (basculement vers un autre provider, qualité similaire).
Niveau 1 coûte ~1-2 jours d'implémentation. Niveau 2 ~5-15 jours. Niveau 3 ~20-60 jours selon la complexité (prompts à reporter, formats outputs à harmoniser, observabilité multi-provider).
Pas tout en niveau 3. Choisir par fonctionnalité.
Q3 — Comment basculer vite ?
Trois patterns concrets qu'on déploie :
- Feature flag global :
LLM_DEGRADATION_MODEen variable d'env, lisible en temps réel par le code. Bascule manuelle en 30 secondes. - Circuit breaker automatique : sur taux d'erreur > X% ou latence > Y ms pendant Z secondes, bascule auto. Patterns connus (
pybreaker,resilience4j, équivalents Node). - Routage par AI gateway : Vercel AI Gateway, Portkey, Helicone, LiteLLM. Le routage et la fallback sont gérés en dehors du code applicatif.
Q4 — Comment on sait que ça marche le jour J ?
Sans test périodique, le PCA est théorique. Trois rituels qu'on impose :
- Test mensuel de bascule manuelle : activer le mode dégradé pendant 15 minutes, observer le comportement, restaurer. Documenter.
- Test trimestriel multi-provider : forcer le routage vers le provider de secours pour 1% du trafic pendant 24h, mesurer les écarts.
- Exercice annuel full disaster : simuler une panne provider de 4h en pré-prod, dérouler le runbook, mesurer le temps de bascule réel.
Sans ces tests, le PCA s'oxyde en 6 mois.
Les 5 patterns techniques qui marchent
Pattern 1 — Mode "dégradation explicite"
Quand le LLM principal est down, le produit continue de fonctionner mais affiche clairement : "L'assistant IA est temporairement indisponible. Vos données et fonctionnalités non-IA restent accessibles." Coût : faible. Impact : très bon en termes de perception client.
Le bricolage qui tue : afficher une roue qui tourne pendant 2h sans message. Les utilisateurs ne quittent pas votre produit parce qu'il a une panne, ils le quittent parce qu'ils ne savent pas si ça va revenir.
Pattern 2 — Bascule vers un modèle plus simple chez le même provider
Anthropic Opus down → bascule sur Sonnet ou Haiku. OpenAI GPT-5 down → bascule sur GPT-4o-mini. Pas idéal en qualité mais utilisable. Coût : très faible. Limites : ne protège pas des pannes globales du provider.
Pattern 3 — Multi-provider avec routage intelligent
Anthropic primary, OpenAI secondary, Mistral tertiary. Le code applicatif ne sait pas qui répond. Géré par un AI gateway. Coût d'implémentation : ~15-30 jours pour un produit avec 10-20 prompts. Coût récurrent : ~5-15% de surcoût (gateway + tests cross-provider).
C'est le pattern qui devient standard sur les SaaS IA mid-market à partir de 2026.
Pattern 4 — Self-host pour les cas critiques
Sur les fonctionnalités les plus critiques (modération temps réel, classification automatique), héberger un modèle plus petit en interne (Mistral Small, Llama 3, Qwen) sur GPU dédiés. Latence et coûts maîtrisés, indépendance du provider.
Coût : significatif (GPU, MLOps, monitoring). Justifié uniquement quand la fonctionnalité est critique et bien cadrée. Voir LLM self-hosted.
Pattern 5 — Cache agressif des outputs
Pour les fonctionnalités déterministes (génération à partir d'un template, traduction, classification stable), cacher les outputs 7-30 jours. En cas de panne, servir du cache vieux plutôt que rien.
Pattern oublié mais souvent le moins coûteux à mettre en place. ROI très bon sur les usages répétitifs.
Les artefacts du PCA
Quatre documents qu'un client enterprise (ou un auditeur DORA / NIS2) attendra :
1. Cartographie des dépendances LLM
Tableau qui croise fonctionnalité × provider × modèle × criticité × RTO/RPO acceptable. Maintenu à jour à chaque ajout/retrait.
2. Runbook de bascule
Procédure pas-à-pas, qui fait quoi, dans quel ordre, en combien de temps. Avec captures d'écran des consoles. Imprimable.
3. Plan de communication crise
Messages pré-rédigés pour : statut public (page status), notification clients enterprise (email), com interne (Slack), com presse si majeur. Préparés froid, validés juridiquement.
4. Registre des tests
Trace des tests mensuels et trimestriels avec : date, résultat, écart constaté, action corrective. C'est ce qu'un auditeur va regarder en premier.
Les pièges qu'on voit en mission
Penser que le SLA contractuel suffit
Le SLA de votre fournisseur LLM vous donne ~30 minutes de crédit par mois en cas de panne. Ça ne couvre pas l'impact réel sur votre business. Le PCA, c'est ce qui couvre l'impact.
Tout vouloir basculer
Tentation : faire un fail-over multi-provider partout. Coût explose, complexité aussi, surface de bugs aussi. Discriminer : niveau 1 (dégradation) suffit pour 60-70% des fonctionnalités.
Tester en prod sous pression
Le premier vrai test du runbook a lieu pendant la première panne. Forcément, ça ne se passe pas comme prévu. Tester en pré-prod, mensuellement, sans pression.
Ignorer la dégradation lente
Le pattern qui plante : pas une panne, une dégradation. Latence × 5, qualité de réponse qui dérive. Le circuit breaker classique ne le voit pas. Il faut un monitoring sémantique (échantillonner les outputs, mesurer la qualité par rapport à une baseline).
Le contre-exemple instructif
Un SaaS d'analyse de contrats juridiques en T1 2025. Un seul provider (Anthropic), aucun fail-over, aucun cache. Outage Anthropic d'une journée en mars. Produit complètement down. 38 clients enterprise ont reçu un email d'excuse, 3 ont demandé un avoir, 1 a remis en discussion son renouvellement à 280 k€/an.
Coût direct : ~50 k€ d'avoirs + heures internes. Coût indirect : le DG a passé l'été à expliquer à chaque renouvellement comment ça n'arriverait plus. Le PCA est rentré dans la roadmap dès avril. Implémentation niveau 2 + 3 sur 4 mois pour ~45 k€ d'investissement.
L'arbitrage classique : on paie 45 k€ une fois pour éviter de payer 50 k€ + risque de churn à chaque outage suivant. La rentabilité se compte en mois.
Pour DORA, voir DORA SaaS financiers roadmap. Pour les options self-hosted, voir LLM self-hosted opérationnel. Pour cadrer le fournisseur en amont, voir DPA fournisseur LLM.