Comment faire survivre votre app IA quand un modèle disparaît soudainement

Tout développeur qui construit sur l'IA finit par apprendre la même leçon à ses dépens : le modèle dont vous dépendez n'est pas garanti d'être là. Il peut être limité en débit aux heures de pointe, renvoyer un refus, atteindre une erreur de surcharge, ou — comme c'est arrivé à Claude Fable 5 en juin 2026 — être complètement coupé pour des raisons qui n'ont rien à voir avec votre code. Les applications qui survivent à ces moments ne sont pas celles qui ont le meilleur prompt. Ce sont celles qui ont anticipé l'absence du modèle.

Ce guide parcourt une approche pratique et à plusieurs niveaux de la résilience, qui fonctionne que vous appeliez un fournisseur directement ou que vous passiez par une passerelle.

Étape 1 : ne codez jamais en dur un modèle unique

La fragilité la plus courante est un nom de modèle figé directement dans une requête. Dès l'instant où cette chaîne cesse de fonctionner, tous les appels échouent. Définissez plutôt vos modèles sous forme de configuration — une petite liste de priorités, pas une constante :

MODEL_CHAIN = [
    "claude-opus-4-8",      # primary
    "claude-sonnet-4-6",    # same provider, cheaper/faster
    "gpt-5.5",              # different provider entirely
]

Ce seul changement fait que changer de fournisseur pendant un incident devient une modification de configuration, pas un déploiement de code. Remarquez que la troisième entrée est un fournisseur différent. Les replis chez le même fournisseur vous protègent de la panne d'un seul modèle ; les replis multi-fournisseurs vous protègent de la panne de tout le fournisseur — ou de sa mise hors ligne sur ordre.

Étape 2 : utilisez une chaîne de repli, pas un essai unique

Le schéma est simple : essayer chaque modèle dans l'ordre, passer au suivant en cas d'échec, et ne faire remonter une erreur que si toute la chaîne est épuisée.

def call_with_fallback(messages):
    last_error = None
    for model in MODEL_CHAIN:
        try:
            return client.complete(model=model, messages=messages)
        except (RateLimitError, OverloadError, RefusalError) as e:
            last_error = e
            continue  # try the next model
    raise AllModelsFailedError(last_error)

Ce sur quoi vous repliez compte. Réessayer le même modèle sur une erreur transitoire overloaded (HTTP 529) a du sens après un court délai. Mais une erreur d'authentification ou une requête malformée échouera de façon identique sur chaque modèle — celles-ci devraient remonter immédiatement plutôt que de consumer toute votre chaîne.

Étape 3 : appuyez-vous sur la plateforme quand elle propose des replis nativement

Vous n'avez pas toujours à tout coder à la main. Plusieurs plateformes le font désormais côté serveur :

• L'API d'Anthropic a ajouté un paramètre bêta fallbacks qui réessaie une requête refusée sur un autre modèle en un seul aller-retour — Fable 5, par exemple, était configuré pour se replier sur Opus 4.8 lorsque ses classifieurs refusaient une requête. La facturation suit le modèle qui a réellement servi la réponse.
• OpenRouter vous laisse passer un tableau models par ordre de priorité ; il bascule automatiquement en cas d'erreurs de longueur de contexte, de signalements de modération, de limites de débit et d'indisponibilité, en vous facturant au tarif du modèle qui a répondu.
• LiteLLM livre un Router avec des relances intégrées, des replis et de la répartition de charge entre déploiements et fournisseurs, que vous auto-hébergez pour un contrôle maximal.

Une passerelle comme OpenRouter ou LiteLLM vous offre un point d'accès unifié sur de nombreux fournisseurs, de sorte qu'un repli multi-fournisseurs n'est qu'une entrée de plus dans une liste plutôt qu'un second SDK à intégrer.

Étape 4 : ajoutez un disjoncteur pour échouer vite

Si un modèle est clairement hors service, vous ne voulez pas que chaque requête attende son expiration avant de basculer. Un disjoncteur suit les échecs récents et, une fois un seuil franchi, contourne entièrement le modèle défaillant pendant une période de refroidissement. Les équipes en production en 2026 se situent couramment autour de cinq échecs consécutifs pour déclencher le disjoncteur et un refroidissement d'environ 60 secondes avant de tester la reprise. Tant que le disjoncteur est ouvert, le trafic va directement au modèle suivant de la chaîne — aucune latence gaspillée.

Étape 5 : décidez de ce que « dégradé » signifie pour votre produit

Se replier sur un modèle moins cher n'est pas gratuit — la qualité baisse, et vos prompts peuvent se comporter différemment. Anticipez :

• Testez vos prompts sur chaque modèle de la chaîne. Un prompt ajusté pour un modèle peut produire un résultat nettement moins bon sur son repli.
• Prévenez l'utilisateur quand vous êtes en mode dégradé si cela compte (p. ex. « fonctionnement en mode rapide »), plutôt que de livrer silencieusement des résultats de moindre qualité.
• Journalisez quel modèle a réellement servi chaque requête pour pouvoir voir, après un incident, quelle part du trafic les replis ont absorbée.

À retenir

La résilience n'est pas une fonctionnalité que l'on boulonne après le lancement — c'est une petite dose de structure que l'on ajoute tôt : de la configuration au lieu de constantes, une chaîne de priorités au lieu d'un appel unique, un disjoncteur pour échouer vite, et des prompts testés à chaque niveau. Les équipes dont les apps sont restées debout pendant la coupure de Fable 5 en juin n'ont pas eu de chance. Elles avaient simplement déjà répondu à la question que tout bâtisseur d'IA devrait se poser dès le premier jour : que se passe-t-il si ce modèle n'est plus là demain ?