Les APIs LLM ont des incidents, des maintenances, des pics de latence et des 429. Si ton produit dépend d'un seul provider sans repli, sa disponibilité est plafonnée par la sienne. Le fallback multi-modèle n'est pas du luxe au-delà d'un certain enjeu.
La chaîne de repli
Les règles qui comptent
- Provider différent, pas juste modèle différent : si Anthropic est down, basculer sur un autre modèle Anthropic ne sert à rien. Le repli doit être chez un autre fournisseur.
- Prompt portable : tester que ton prompt fonctionne acceptablement sur le modèle de secours avant l'incident, pas pendant.
- Échouer honnêtement : si tout tombe, un message clair (« service IA indisponible, réessayez ») vaut mieux qu'un timeout de 30 s ou une réponse inventée.
- Circuit breaker : après N échecs consécutifs sur le primaire, basculer d'office quelques minutes au lieu de retenter à chaque requête.
Le coût caché
Maintenir un repli, c'est maintenir deux intégrations et deux jeux de prompts. Ce coût n'est justifié que si l'indisponibilité a un vrai impact business. Pour un outil interne, un message d'erreur suffit. Pour un produit payant en façade client, le fallback est une exigence, pas une option.
