Stratégie de repli des modèles : un playbook en 3 workflows

Le repli de modèle n’est pas un comportement unique. C’est un ensemble de décisions de récupération avec des limites de sécurité différentes.

Une stratégie de repli des modèles en production doit distinguer trois workflows :

1. Nouvelle tentative ou basculement équivalent lorsque la requête peut encore être rejouée sans risque.
2. Repli vers un autre modèle lorsqu’un autre modèle peut satisfaire le même contrat de capacité et de qualité.
3. Arrêter, réconcilier ou escalader lorsque la sortie a déjà été livrée à l’utilisateur ou qu’un effet de bord d’un outil a pu se produire.

Cette séparation est importante, car l’action de récupération la plus rapide n’est pas toujours la plus sûre. Rejouer une requête de classification en échec présente généralement un faible risque. En revanche, basculer silencieusement vers un autre modèle au milieu d’une réponse diffusée en streaming, ou après un appel incertain à un outil de paiement, ne l’est pas.

Ce playbook transforme la politique de repli en trois workflows opérationnels que votre équipe peut implémenter, tester, observer et déployer via un rollout de production contrôlé.

La décision de repli des modèles en un tableau

Commencez par l’état de la requête, pas par le nom du fournisseur.

La règle fondamentale est simple : la nouvelle tentative préserve la cible, le basculement équivalent préserve le contrat du modèle, et le repli vers un autre modèle modifie le risque du contrat. Chaque étape nécessite une vérification d’éligibilité plus stricte.

Pour une analyse plus approfondie des disjoncteurs, de la normalisation des erreurs et d’un contrôleur neutre vis-à-vis des fournisseurs, consultez le playbook de routage de repli pour les API LLM.

Avant les workflows : définir une seule enveloppe de repli

Chaque requête doit entrer dans la couche de routage avec une enveloppe bornée. L’enveloppe indique au système quelle quantité de récupération est autorisée avant que la requête doive s’arrêter.

type FallbackEnvelope = {
  requestId: string;
  deadlineMs: number;
  maxAttempts: number;
  maxAddedLatencyMs: number;
  maxCostUsd?: number;
  allowEquivalentFailover: boolean;
  allowCrossModelFallback: boolean;
  allowAfterPartialOutput: false;
  sideEffectMode: "none" | "read_only" | "write_possible";
  requiredCapabilities: string[];
  requiredSchemaVersion?: string;
};

Les valeurs doivent provenir du workflow produit, et non d’une valeur par défaut globale. Un job d’agrégation en arrière-plan peut tolérer davantage de latence qu’un assistant de codage interactif. Une réponse de chat sans outils peut tolérer un comportement de récupération différent de celui d’un agent capable de déployer du code ou d’envoyer des e-mails.

L’enveloppe empêche également les tentatives imbriquées. Si le SDK, l’application, la passerelle et l’adaptateur du fournisseur tentent chacun à nouveau indépendamment, un incident mineur peut se multiplier en une importante rafale de tentatives. Choisissez une seule couche pour prendre en charge le budget total de tentatives et exigez que chaque couche inférieure signale ce qu’elle a déjà consommé.

Transformez l’enveloppe de repli en politique sous forme de code

Une définition de type documente l’intention, mais l’acheminement en production a besoin d’une politique versionnée que les opérateurs peuvent examiner sans modifier le code de l’application. Gardez la politique suffisamment petite pour être auditée et suffisamment précise pour empêcher qu’une chaîne de repli générique ne s’infiltre dans des workflows à haut risque.

Cette configuration de départ sépare trois classes de routes courantes :

policy_version: 2026-08-02

routes:
  interactive_chat:
    deadline_ms: 12000
    max_attempts: 2
    max_added_latency_ms: 2500
    allow_equivalent_failover: true
    allow_cross_model_fallback: true
    allow_after_partial_output: false
    side_effect_mode: none
    required_capabilities: [streaming]

  structured_extraction:
    deadline_ms: 30000
    max_attempts: 3
    max_added_latency_ms: 8000
    allow_equivalent_failover: true
    allow_cross_model_fallback: true
    allow_after_partial_output: false
    side_effect_mode: none
    required_capabilities: [structured_output]
    required_schema_version: invoice-v4

  tool_agent_write:
    deadline_ms: 45000
    max_attempts: 2
    max_added_latency_ms: 5000
    allow_equivalent_failover: true
    allow_cross_model_fallback: false
    allow_after_partial_output: false
    side_effect_mode: write_possible
    required_capabilities: [tool_use]

Les valeurs ci-dessus sont des exemples, pas des seuils universels. Définissez-les à partir de votre objectif de latence orienté utilisateur, de l’économie de la tâche, des résultats d’évaluation et du risque lié aux effets de bord. Le choix de conception important est que l’agent capable d’écrire ne puisse pas basculer silencieusement vers un modèle au comportement différent.

Au moment de l’exécution, le routeur doit combiner la politique avec l’état de la requête et l’état d’échec observé. Une fonction de décision compacte peut rendre la frontière testable :

type RecoveryAction =
  | "retry_same_target"
  | "failover_equivalent"
  | "fallback_approved_model"
  | "reconcile_side_effect"
  | "restart_required"
  | "stop";

function chooseRecovery(input: {
  errorClass: string;
  attemptsUsed: number;
  deadlineRemainingMs: number;
  partialOutput: boolean;
  sideEffectState: "none" | "safe" | "uncertain";
  equivalentAvailable: boolean;
  approvedAlternateAvailable: boolean;
  policy: FallbackEnvelope;
}): RecoveryAction {
  if (input.sideEffectState === "uncertain") return "reconcile_side_effect";
  if (input.partialOutput) return "restart_required";
  if (input.attemptsUsed >= input.policy.maxAttempts) return "stop";
  if (input.deadlineRemainingMs <= 0) return "stop";

  const transient = [
    "transport_transient",
    "rate_limited",
    "provider_overloaded",
    "provider_server_error",
  ].includes(input.errorClass);

  if (transient && input.attemptsUsed === 0) return "retry_same_target";
  if (transient && input.equivalentAvailable) return "failover_equivalent";

  if (
    input.policy.allowCrossModelFallback &&
    input.approvedAlternateAvailable
  ) {
    return "fallback_approved_model";
  }

  return "stop";
}

Gardez la sélection des candidats séparée de la décision de récupération. chooseRecovery décide quel workflow est autorisé ; un sélecteur de candidats filtre ensuite les cibles selon les capacités, le contexte, la région, le coût et la politique de qualité. Cette séparation facilite l’examen des incidents, car l’équipe peut distinguer « nous avons choisi le mauvais workflow de récupération » de « nous avons choisi le mauvais modèle alternatif ».

Versionnez la politique et associez cette version à chaque trace de tentative. Lorsqu’une régression de fallback apparaît, les opérateurs doivent pouvoir répondre à quelle politique a pris la décision, quels candidats étaient éligibles et quel budget restait à ce moment-là.

Workflow 1 : réessayer, puis basculer vers un équivalent

Utilisez ce workflow lorsque l’opération peut être rejouée et que le système n’a pas exposé de sortie partielle ni basculé dans un état d’effet secondaire incertain.

Une cible équivalente est une autre route qui préserve le contrat important : même classe de comportement du modèle, capacités requises, attentes de schéma, configuration de sécurité et limites de contexte compatibles. Il peut s’agir d’une région, d’un déploiement, d’un endpoint de fournisseur ou d’un pool de capacité différent.

Étape 1 : normaliser l’échec

Mappez les réponses spécifiques au fournisseur vers une petite taxonomie interne :

• transport_transient
• rate_limited
• provider_overloaded
• provider_server_error
• authentication_or_permission
• invalid_request
• deadline_exhausted
• contract_failure
• partial_output
• side_effect_uncertain

Seuls les quatre premiers sont normalement éligibles à une nouvelle exécution automatique. Les erreurs d’authentification, de permission et de requête invalide doivent arrêter le flux, car un endpoint différent a peu de chances de corriger la requête. Les échecs de contrat relèvent du Workflow 2. La sortie partielle et les effets secondaires incertains relèvent du Workflow 3.

Étape 2 : calculer le budget restant

Avant chaque tentative, vérifiez :

temps restant > latence estimée de la prochaine tentative + marge de sécurité de la réponse
tentatives restantes > 0
latence additionnelle restante > 0
budget de coût restant > coût estimé de la tentative, lorsqu’un plafond de coût existe

Si l’un des budgets requis est épuisé, quittez au lieu d’essayer un fournisseur de plus.

Étape 3 : réessayer avec backoff et jitter

Utilisez les recommandations de retry du fournisseur lorsqu’elles sont disponibles. Sinon, appliquez un backoff exponentiel avec jitter et maintenez le délai à l’intérieur du délai de la requête.

function retryDelayMs(attempt: number, retryAfterMs?: number): number {
  if (retryAfterMs !== undefined) return retryAfterMs;

  const base = Math.min(250 * 2 ** attempt, 4_000);
  const jitter = Math.random() * base * 0.3;
  return Math.round(base + jitter);
}

Le jitter est important car, sans cela, de nombreux clients simultanés peuvent réessayer selon le même calendrier et prolonger un événement de surcharge. Votre guide des limites de débit des LLM doit définir comment les RPM, les TPM, les files d’attente, la concurrence et les budgets de retry interagissent.

Étape 4 : basculer vers une capacité équivalente

Si la même cible reste en mauvaise santé, acheminez vers un point de terminaison équivalent uniquement après avoir vérifié :

• Le circuit est fermé ou semi-ouvert pour un probe.
• La cible prend en charge les modes d’entrée et de sortie requis.
• La cible peut accepter la requête dans sa limite de contexte.
• La cible utilise la configuration de sécurité et de traitement des données attendue.
• La tentative reste dans le délai et l’enveloppe de coût.

Le failover équivalent est normalement moins risqué qu’un changement de modèle, car il vise à préserver le contrat de réponse.

Étape 5 : consigner la raison de la récupération

Renvoyez un résultat de routage tel que :

{
  "workflow": "retry_equivalent_failover",
  "primary_attempts": 2,
  "equivalent_failover_attempts": 1,
  "recovered": true,
  "recovery_reason": "provider_overloaded",
  "added_latency_ms": 684
}

N’exposez pas les détails internes du fournisseur aux utilisateurs finaux, sauf si votre produit promet cette transparence. Conservez-les en revanche dans les traces et les journaux opérationnels.

Workflow 2 : repli contrôlé inter-modèles

Le repli inter-modèles n’est approprié que lorsque le modèle de remplacement a été préalablement approuvé pour la tâche. Le fait qu’un modèle renvoie du texte ne suffit pas ; il doit satisfaire le contrat du workflow.

Étape 1 : créer un contrat de capacité

Définissez les exigences non négociables pour chaque classe de route.

{
  "route_class": "support_ticket_triage_v3",
  "required": {
    "input": ["text"],
    "output": ["json_schema"],
    "tools": [],
    "minimum_context_tokens": 24000,
    "schema": "triage-result-v3",
    "languages": ["en", "es", "de"],
    "safety_profile": "customer-support-standard"
  },
  "fallback_models": [
    "approved-model-b",
    "approved-model-c"
  ]
}

Pour les parcours utilisant des outils, incluez le comportement de choix d’outil, la prise en charge des outils parallèles, la gestion du schéma des arguments et le fait que le modèle respecte de manière fiable les conditions de type « ne pas appeler ». Pour les sorties structurées, validez la réponse réelle par rapport au schéma après chaque tentative.

Étape 2 : séparer le succès du transport du succès de la tâche

Une réponse HTTP réussie peut tout de même faire échouer le workflow produit. Évaluez au moins trois niveaux :

1. Succès du transport : le fournisseur a renvoyé une réponse complète.
2. Succès du contrat : la réponse a été analysée, correspondait au schéma et utilisait correctement les outils pris en charge.
3. Succès de la tâche : la sortie a réellement permis à l’utilisateur d’achever son travail avec un niveau de qualité acceptable.

Cette distinction est essentielle lorsque vous comparez des candidats de repli. Un modèle avec un taux de réponse élevé mais des échecs fréquents de schéma ou d’outil n’est pas un repli fiable.

Étape 3 : classer les candidats approuvés selon la politique

Un routeur de production peut noter les cibles éligibles à l’aide de संकेतaux opérationnels sans prétendre qu’un modèle est universellement meilleur.

type Candidate = {
  id: string;
  capabilitiesPass: boolean;
  circuitOpen: boolean;
  estimatedLatencyMs: number;
  estimatedCostUsd: number;
  recentContractSuccess: number;
  recentTaskSuccess: number;
};

function eligible(candidate: Candidate, envelope: FallbackEnvelope): boolean {
  return (
    candidate.capabilitiesPass &&
    !candidate.circuitOpen &&
    candidate.estimatedLatencyMs <= envelope.maxAddedLatencyMs &&
    (envelope.maxCostUsd === undefined ||
      candidate.estimatedCostUsd <= envelope.maxCostUsd)
  );
}

Évitez une liste statique « principal, secours, secours » pour chaque tâche. Le meilleur ensemble de repli pour la génération de code peut différer du meilleur ensemble pour l’extraction, la traduction, la vision ou l’exécution d’outils.

Étape 4 : valider la sortie de repli

Appliquez d’abord des contrôles déterministes :

• Validation JSON ou du schéma
• Vérification des champs requis
• Validation des arguments d’outil
• Vérification du format des citations ou des URL
• Contraintes de longueur et de langue
• Motifs de sortie interdits

Ajoutez ensuite des contrôles de qualité spécifiques au workflow. Il peut s’agir de règles légères, d’un évaluateur de tâche, d’une revue humaine échantillonnée ou d’un modèle juge validé. Si le garde-fou qualité échoue, ne qualifiez pas le repli de récupéré.

Étape 5 : changements de stratégie en canari

Avant d’élargir un nouveau modèle de repli :

1. Relancez un ensemble d’évaluation hors ligne.
2. Exécutez un trafic en ombre lorsque la politique le permet.
3. Activez le candidat pour un petit pourcentage des échecs éligibles.
4. Comparez le succès du contrat, le succès de la tâche, la latence et le coût.
5. Élargissez uniquement si la valeur de récupération l’emporte sur le risque de régression.

Suivez ces mesures avec un schéma d’observabilité de l’API LLM qui enregistre une route et un span par tentative.

Workflow 3 : arrêter, réconcilier ou escalader

Certaines défaillances ne doivent pas déclencher un autre appel au modèle. Le bon repli est un arrêt contrôlé.

Cas 1 : sortie de streaming partielle

Une fois que des jetons de réponse ont atteint l’utilisateur, changer de modèle en silence peut créer des contradictions, du contenu en double, des blocs de code cassés ou un changement soudain de style. Cela rend aussi la réponse finale difficile à attribuer et à déboguer.

Utilisez plutôt l’un de ces résultats explicites :

• Terminer le flux avec une erreur récupérable et une action « réessayer ».
• Proposer de recommencer la réponse depuis le début.
• Continuer uniquement si l’application dispose d’un protocole de reprise conçu à cet effet et que le nouveau modèle reçoit exactement le préfixe accepté.

La valeur par défaut devrait être allowAfterPartialOutput: false.

Cas 2 : effets secondaires d’outil incertains

Supposons qu’un modèle ait sélectionné un outil de paiement, d’e-mail, de déploiement, de ticket ou d’écriture en base de données. L’outil a peut-être réussi même si la connexion a échoué avant que votre orchestrateur n’enregistre le résultat. Relancer l’ensemble du workflow peut dupliquer l’effet secondaire.

Protégez les outils d’écriture avec :

• Une clé d’idempotence basée sur l’opération utilisateur, et non sur la tentative du fournisseur.
• Un enregistrement d’exécution durable avec les états planned, started, succeeded, failed et unknown.
• Une déduplication à la frontière de l’outil.
• Une requête de réconciliation avant toute relance.
• Une revue humaine pour les actions à fort impact qui restent incertaines.

type ToolExecution = {
  operationId: string;
  toolName: string;
  state: "planned" | "started" | "succeeded" | "failed" | "unknown";
  externalReference?: string;
};

function nextAction(execution: ToolExecution): "continue" | "reconcile" | "stop" {
  if (execution.state === "succeeded") return "continue";
  if (execution.state === "failed") return "stop";
  return "reconcile";
}

Conservez séparément les identifiants du fournisseur et ceux de l’outil. Le guide de gestion sécurisée des clés API couvre le modèle de gestion des secrets et des contrôles d’accès associé.

Cas 3 : incertitude de sécurité, d’autorisation ou de politique

La disponibilité ne doit pas affaiblir une décision de sécurité ou d’autorisation. Si le candidat de repli ne prend pas en charge les contrôles de politique requis, la route est inéligible. Si le système ne peut pas déterminer si une opération est autorisée, échouez en mode fermé ou escaladez selon le modèle de risque du produit.

Cas 4 : aucun candidat ne satisfait le contrat

Retournez un échec typé que l’application peut gérer :

{
  "status": "unavailable",
  "reason": "no_eligible_fallback",
  "retryable": true,
  "retry_after_ms": 30000,
  "request_id": "req_123"
}

Une réponse dégradée claire vaut mieux qu’une réponse qui semble réussie mais qui viole le schéma, utilise les mauvais outils ou produit le mauvais effet secondaire.

Intégrez les trois workflows dans une seule machine à états

La couche d’orchestration doit rendre la transition explicite.

DÉMARRER
  -> TENTATIVE_PRIMAIRE
     -> SUCCÈS : valider et retourner
     -> TRANSITOIRE + rejouable : WORKFLOW_1
     -> ÉCHEC_DE_CONTRAT + solution de repli approuvée : WORKFLOW_2
     -> SORTIE_PARTIELLE ou EFFET_DE_BORD_INCERTAIN : WORKFLOW_3

WORKFLOW_1
  -> réessayer dans la limite du budget
  -> basculement équivalent dans la limite du budget
  -> si un autre modèle compatible est autorisé : WORKFLOW_2
  -> sinon : ARRÊTER

WORKFLOW_2
  -> vérification des capacités
  -> tentative sur le modèle alternatif
  -> validation du contrat et de la tâche
  -> retour uniquement en cas de succès validé
  -> sinon : ARRÊTER

WORKFLOW_3
  -> marquer l’état partiel ou incertain
  -> réconcilier les effets de bord externes lorsque c’est possible
  -> proposer un redémarrage explicite ou une escalade humaine
  -> ne jamais rejouer silencieusement un travail non sûr

C’est aussi la bonne frontière pour une passerelle multi-modèles. Centraliser l’accès aux modèles derrière un point de terminaison compatible OpenAI peut réduire la duplication d’intégration, mais l’application doit toujours fournir l’intention du workflow : délais, mode d’effet de bord, outils requis, version du schéma et autorisation ou non d’un fallback intermodèles. Flatkey fournit une couche d’accès API unifiée pour les équipes qui veulent une seule clé et une seule surface d’intégration sur plusieurs fournisseurs de modèles ; la politique de routage la plus sûre commence toujours par des contrats applicatifs explicites.

Exécutez cinq exercices d’échec avant d’activer le fallback automatique

Un chemin de repli qui n’a jamais géré un échec contrôlé n’est qu’un schéma. Testez chaque classe de routage face à des défaillances qui sollicitent une frontière de sécurité différente.

Exécutez d’abord les exercices dans un environnement local ou de préproduction, puis lors d’une journée de jeu en production strictement limitée. L’objectif n’est pas de prouver que chaque requête survit. Il s’agit de prouver que le système échoue dans l’état prévu, expose suffisamment d’éléments pour diagnostiquer l’événement, et ne consomme pas plus de latence, d’argent ou de risque d’effet de bord que la politique ne l’autorise.

Pour chaque exercice, vérifiez indépendamment quatre couches :

1. Exactitude de la décision : le routeur a choisi le workflow prévu.
2. Exactitude du budget : toutes les tentatives sont restées dans l’enveloppe commune de délai, de tentatives et de coût.
3. Exactitude du résultat : le résultat final a passé la validation du contrat et de la tâche, ou a renvoyé un état dégradé explicite.
4. Exactitude de l’audit : les traces ont capturé la version de la politique, la classe d’échec, l’éligibilité du candidat, le motif du routage et le résultat visible par l’utilisateur.

Répétez l’exercice chaque fois que vous modifiez un adaptateur de fournisseur, le propriétaire des retries, un candidat de modèle, une version de schéma, un contrat d’outil ou une implémentation de streaming. Ces changements peuvent altérer la sécurité de la relecture même lorsque la forme de l’API publique semble inchangée.

Utilisez une grille d’évaluation de préparation au repli avant la production

Réussir quelques tests de parcours heureux ne suffit pas pour activer le repli automatique. Une route doit mériter l’automatisation en passant cinq contrôles de mise en production indépendants.

Considérez la grille comme un artefact de mise en production. Enregistrez la classe de route, la version de la politique, les candidats approuvés, la version de l’évaluateur, les résultats de l’exercice, le propriétaire et la date de revue. Un simple indicateur global « repli activé » masque trop de risques ; l’approbation doit se faire par classe de workflow.

Enregistrement de préparation copiable

fallback_readiness:
  route_class: support_ticket_extraction
  policy_version: fallback-v4
  owner: ai-platform
  primary_target: primary-model
  approved_candidates:
    - equivalent-deployment
    - alternate-model

  gates:
    replay_safety: pass
    contract_compatibility: pass
    task_quality: pass
    budget_control: pass
    operational_control: pass

  evidence:
    capability_matrix: contracts/support-ticket-v3.yaml
    evaluation_set: evals/support-ticket-2026-08.jsonl
    failure_drill_run: drills/2026-08-03.json
    dashboard: ai-routing/support-ticket
    runbook: runbooks/support-ticket-fallback.md

  release:
    mode: canary
    rollback_owner: oncall-ai-platform
    next_review_at: 2026-09-03

Le fichier n’a pas besoin d’exister dans ce format exact. Ce qui importe, c’est que la décision de mise en production soit révisable et liée à la même version de politique enregistrée dans les traces de production.

Déployez une stratégie de repli des modèles en quatre étapes

Le repli automatique ne doit pas passer d’un test hors ligne à chaque requête de production d’un seul coup. Utilisez quatre étapes qui exposent les erreurs de décision avant qu’elles ne deviennent visibles pour l’utilisateur.

Étape 1 : mettez la décision en shadow

Exécutez le contrôleur de repli en mode observation seule. Le chemin principal détermine toujours la réponse utilisateur, tandis que le contrôleur enregistre ce qu’il aurait fait.

Examinez :

• À quelle fréquence la politique classe une défaillance comme réessayable.
• À quelle fréquence un candidat est éligible.
• Quel budget aurait arrêté la récupération.
• Si la politique propose un repli après une sortie partielle ou des effets secondaires incertains.
• Si les erreurs normalisées par le fournisseur conservent suffisamment de détails pour le diagnostic d’incident.

Le mode shadow est particulièrement utile pour détecter des règles trop larges, comme « repli sur chaque 429 » ou « essayer un autre modèle après toute erreur de schéma ». Ces règles peuvent sembler raisonnables lors de la revue de code, mais se comporter mal face à des états de requête réels.

Étape 2 : utilisez le canary sur des workflows à faible risque

Activez le repli pour une faible part de trafic sûr à rejouer, comme la classification en lecture seule, l’extraction ou la synthèse en arrière-plan. Excluez les outils côté écriture, les décisions sensibles à la sécurité et les routes avec streaming visible pour l’utilisateur.

Comparez le canary au chemin uniquement principal à l’aide de résultats au niveau de la route :

• Taux de tâches acceptées, pas seulement le succès HTTP.
• Latence ajoutée par la récupération.
• Écart de coût par tâche acceptée.
• Échecs de validation de contrat par candidat.
• Épuisement des délais et taux d’absence de repli éligible.
• Annulation par l’utilisateur ou taux de redémarrage explicite.

N’élargissez pas le canary simplement parce que le taux d’erreur du fournisseur a baissé. Élargissez-le uniquement lorsque le résultat final côté utilisateur reste acceptable et que le chemin de récupération demeure dans son enveloppe.

Étape 3 : contraignez la récupération automatique par classe de risque

Étendez uniquement les classes de workflows qui ont passé la grille de préparation. Conservez des différences de politique explicites :

C’est à cette étape que se rencontrent une passerelle et un contrat applicatif. La passerelle peut normaliser les erreurs, appliquer les budgets et sélectionner la capacité éligible. L’application doit toujours indiquer si la sortie a été exposée, si un effet de bord est possible, et quels contrôles de qualité ou de politique sont obligatoires.

Étape 4 : élargir progressivement et re-certifier les changements

Augmentez le trafic par paliers bornés. À chaque étape, conservez la capacité de désactiver une version de politique, une classe de route, un adaptateur de fournisseur ou un candidat sans couper l’ensemble de la couche de routage.

Relancez les gates pertinentes du scorecard lorsque l’un de ces éléments change :

• Modèle ou version du modèle.
• Adaptateur de fournisseur ou point de terminaison.
• Modèle de prompt ou instruction système.
• Définition d’outil ou périmètre d’autorisation.
• Schéma de sortie structurée.
• Propriété des nouvelles tentatives ou configuration du délai d’attente.
• Transport de streaming ou comportement du client.
• Politique de sécurité ou évaluateur de qualité.

La préparation au repli expire lorsque ses hypothèses changent. Un candidat approuvé pour un prompt, un schéma ou un ensemble d’outils précédent ne doit pas rester automatiquement éligible par inertie.

Définissez les déclencheurs de rollback avant d’activer le canary

Un canary n’est sûr que si l’équipe s’accorde à l’avance sur ce qui l’arrête. Utilisez des déclencheurs spécifiques à la route plutôt que d’attendre un incident large.

Faites revenir en arrière ou désactivez la politique affectée lorsque vous observez :

• Des effets de bord d’écriture dupliqués ou incertains.
• Un succès du contrat inter-modèles sans succès de tâche acceptable.
• Une hausse des échecs de flux partiels ou du splicing invisible des réponses.
• Des épuisements répétés du délai imposé par les tentatives de récupération.
• Des plafonds budgétaires dépassés ou ignorés.
• Une sélection de candidat qui viole une capacité requise ou une politique de sécurité.
• Un changement inexpliqué de la distribution des raisons de repli après un déploiement.
• Des données de trace manquantes au niveau de la version de politique ou de la tentative pendant un incident.

L’action de rollback doit être aussi ciblée que la défaillance. Selon l’événement, cela peut vouloir dire désactiver un seul candidat, forcer une route à utiliser uniquement le repli équivalent, définir allowCrossModelFallback sur false, ouvrir un circuit pour un fournisseur, ou ramener le workflow en mode primaire uniquement.

Évitez un mécanisme de retour arrière qui nécessite de reconstruire l’application. Les changements de politique de récupération sont fréquents pendant les incidents, et la réponse la plus sûre est souvent une modification de configuration avec une version auditables plutôt qu’un correctif de code d’urgence.

Utilisez une feuille de travail unique pour chaque événement de repli

Les incidents de repli deviennent difficiles à diagnostiquer lorsque chaque fournisseur expose une forme d’erreur différente et que chaque application consigne un état de requête différent. Capturez une feuille de travail neutre vis-à-vis du fournisseur.

fallback_incident:
  incident_id: inc-2026-08-03-001
  route_class: support_ticket_extraction
  request_id: req_123
  policy_version: fallback-v4

  request_state:
    output_started: false
    side_effect_mode: none
    tool_execution_state: not_started
    deadline_remaining_ms: 1820
    attempts_remaining: 1

  primary_failure:
    normalized_class: overloaded
    provider_status: 529
    retry_guidance_present: true

  recovery_decision:
    workflow: cross_model_fallback
    candidate: alternate-model
    reason: equivalent_capacity_unavailable

  validation:
    transport_success: true
    contract_success: true
    task_success: false
    failure_reason: required_field_omitted

  user_outcome:
    state: explicit_failure
    partial_output: false
    duplicate_side_effect: false

  containment:
    action: disable_candidate_for_route
    owner: oncall-ai-platform

La distinction la plus importante est entre succès de récupération et succès utilisateur. Une requête de repli peut renvoyer une réponse HTTP valide tout en échouant au schéma, en choisissant le mauvais outil, en omettant un fait requis ou en violant le seuil de qualité de la route. La revue d’incident doit suivre le résultat jusqu’à la tâche visible par l’utilisateur.

Exécutez un game day de repli des modèles de 60 minutes

Les tests unitaires prouvent que des branches individuelles s’exécutent. Un game day de repli prouve que l’ensemble du système de récupération se comporte correctement pendant que les délais, les nouvelles tentatives, les flux, la validation, les outils, la télémétrie et les contrôles opérateur interagissent.

Exécutez l’exercice pour une seule classe de workflow à la fois. Ne commencez pas par une simulation globale de panne de fournisseur. Une route étroite comme l’extraction en lecture seule ou la synthèse interne produit des preuves plus claires et limite le rayon d’impact si la politique est erronée.

Définissez la charte du game day

Rédigez une charte d’une page avant que quiconque n’injecte une panne. La charte empêche l’exercice de se transformer en panne improvisée.

game_day:
  id: fallback-gd-2026-08-04-extraction
  route_class: structured_extraction
  policy_version: fallback-v4
  environment: staging
  exercise_owner: ai-platform
  incident_commander: reliability

  primary_target: primary-model
  approved_fallbacks:
    - equivalent-deployment
    - alternate-schema-capable-model

  traffic_scope:
    synthetic_requests: 100
    production_percentage: 0

  safety_limits:
    stop_after_minutes: 60
    max_error_rate_percent: 5
    max_duplicate_side_effects: 0
    max_unexplained_route_decisions: 0

  success_definition:
    - every request ends accepted, explicitly degraded, or safely stopped
    - no request exceeds the shared attempt budget
    - no partial stream is silently continued by another model
    - every fallback decision includes a policy version and route reason

Utilisez d’abord du trafic synthétique ou compatible avec le replay. Si la route peut déclencher des écritures, remplacez l’outil par un double de test contrôlé ou un sandbox qui prend en charge la recherche d’idempotence. Un game day doit tester les contrôles de reprise, pas miser sur l’état client.

Attribuez quatre rôles

Gardez l’équipe suffisamment petite pour prendre des décisions rapidement, mais séparez l’observation de l’exécution.

Pour une très petite équipe, une personne peut couvrir deux rôles, mais la personne qui injecte la panne ne doit pas être la seule à évaluer si le système a répondu correctement.

Construisez une échelle de scénarios

Commencez par la défaillance la moins ambiguë et n’ajoutez du risque qu’après que la route a franchi l’échelon précédent.

Ne passez pas directement à un scénario complexe intermodèles. Si le basculement équivalent ne peut pas préserver le budget et le contrat de trace, l’ajout d’un modèle au comportement différent rendra le diagnostic plus difficile, pas plus réaliste.

Injectez les pannes à des limites explicites

Étiquetez la limite exacte où la panne entre dans le cycle de vie de la requête. « Le fournisseur a échoué » est trop vague pour constituer un enregistrement de test utile.

type InjectionPoint =
  | "before_connect"
  | "after_connect_before_headers"
  | "after_headers_before_body"
  | "after_partial_stream"
  | "after_tool_dispatch_before_ack"
  | "after_tool_ack_before_model_response"
  | "after_transport_success_before_validation";

La frontière détermine quelles actions de récupération sont sûres. Un timeout avant la connexion peut souvent être retenté. Une déconnexion après qu’un utilisateur a vu une sortie nécessite un redémarrage explicite. Un accusé de réception perdu après un appel d’outil en écriture nécessite une réconciliation. Traiter ces trois cas comme une seule classe de timeout est la manière dont des actions en double et des réponses incohérentes arrivent en production.

Si votre couche d’injection de fautes ne peut pas cibler ces frontières, ajoutez le marqueur de frontière à l’adaptateur du fournisseur ou à la couche d’orchestration avant l’exercice. Les bascules de panne grossières sont utiles pour les tests de disponibilité, mais insuffisantes pour les tests de sécurité du replay.

Capturez une ligne de preuve par requête

La journée de simulation devrait produire un registre au niveau de la requête, et pas seulement des captures d’écran du tableau de bord. Une ligne compacte rend visibles les décisions inexpliquées.

Stockez le registre à côté de l’instantané de la politique, de la version du validateur, de la configuration des fautes et de l’export du tableau de bord. Sans ces versions, un exercice réussi ne peut pas être reproduit après le prochain changement d’adaptateur ou de modèle.

Évaluez l’exercice avec des règles de promotion

Utilisez trois décisions possibles : promouvoir, corriger et relancer, ou arrêter l’automatisation. Évitez un résultat flou du type « en grande partie réussi ».

Promouvez la route uniquement lorsque toutes les conditions suivantes sont remplies :

• Chaque requête a un état terminal expliqué.
• Aucune chaîne de tentatives ne dépasse le délai partagé, le nombre de tentatives ou le plafond de coût configuré.
• Chaque sortie acceptée passe le validateur ou la règle d’évaluation de la route.
• La sortie partielle et les effets secondaires incertains entrent dans des états explicites d’arrêt ou de réconciliation.
• Les opérateurs peuvent désactiver un candidat ou l’ensemble de la politique sans déployer de code applicatif.
• L’alerting identifie à la fois les échecs de récupération et les récupérations nuisibles, comme une réussite de repli avec une qualité de tâche inacceptable.

Choisissez corriger et relancer lorsque le modèle de sécurité est correct mais que les preuves ou l’implémentation sont incomplètes. Exemples : une raison de route manquante, une alerte qui se déclenche trop tard, ou un candidat qui passe le contrat mais n’atteint pas l’objectif de latence.

Choisissez arrêter l’automatisation lorsque l’exercice révèle une ambiguïté de replay, des effets secondaires en double, un splicing silencieux du flux, un routage inexpliqué, un contournement de politique, ou un mode de défaillance que la machine à états actuelle ne peut pas représenter. Ce sont des lacunes de conception, pas des problèmes de réglage.

Utilisez un tableau de bord de game day réutilisable

game_day_result:
  game_day_id: fallback-gd-2026-08-04-extraction
  route_class: structured_extraction
  policy_version: fallback-v4
  evaluator_version: extraction-eval-v7
  started_at: 2026-08-04T09:00:00Z
  completed_at: 2026-08-04T10:00:00Z

  scenarios:
    equivalent_failover: pass
    retry_pressure: pass
    semantic_contract_failure: pass
    partial_stream: pass
    uncertain_tool_completion: not_applicable
    fallback_degradation: fix

  totals:
    requests: 100
    accepted: 94
    explicitly_degraded: 6
    unsafe_or_unexplained: 0
    duplicate_side_effects: 0
    deadline_violations: 0

  decision: fix_and_rerun
  blockers:
    - alternate p95 latency exceeded the route objective during degradation
  owner: ai-platform
  rerun_due: 2026-08-11

Les valeurs de l’exemple sont données à titre illustratif. Utilisez vos propres objectifs de route et seuils d’évaluation. Ce qui compte, c’est que la décision finale renvoie à des preuves conservées et à un responsable nommé.

Transformez les constats en contrôles de mise en production

Terminez le game day en convertissant chaque constat en l’un des quatre contrôles durables suivants :

1. Changement de politique : éligibilité du candidat, budget de tentatives, délai, ou règle de classe de route.
2. Test de contrat : vérification de compatibilité de capacité, de schéma, d’outil, de streaming ou de sécurité.
3. Contrôle opérationnel : alerte, tableau de bord, kill switch, mise en quarantaine d’un candidat ou procédure d’incident.
4. Comportement produit : redémarrage explicite, message d’état dégradé, confirmation manuelle ou écran de réconciliation.

Ne terminez pas l’exercice avec une simple liste d’observations. Un constat sans responsable, sans type de contrôle et sans condition de relance réapparaîtra pendant un incident réel.

Pour la couche de télémétrie derrière ces exercices, utilisez le guide d’observabilité des API LLM. Pour la responsabilité des retries et le comportement des limites de débit, associez la journée de simulation au guide des limites de débit et de la stratégie de retry des LLM. Si votre équipe définit encore le périmètre du gateway, commencez par le guide d’initiation au gateway LLM.

Une séquence de mise en œuvre sur sept jours

Les équipes peuvent utiliser cet ordre pour passer d’une liste de modèles ad hoc à un playbook de workflow contrôlé :

1. Jour 1 — Inventorier les routes : classer le mode de sortie, le risque d’effets de bord, les outils, les schémas, les délais et les propriétaires actuels des retries.
2. Jour 2 — Définir les enveloppes : définir les limites d’essais, de latence, de coût, de capacité et de rejouabilité par classe de route.
3. Jour 3 — Construire les contrats : documenter les candidats approuvés et tester la compatibilité des outils, des schémas, du contexte, de la modalité et des politiques.
4. Jour 4 — Instrumenter les décisions : consigner l’échec normalisé, l’état de la requête, la version de la politique, l’éligibilité du candidat, le budget, la validation et le résultat utilisateur.
5. Jour 5 — Exécuter des drills de défaillance : injecter un timeout, une rafale de limites de débit, une sortie invalide, une déconnexion en cours de flux et une exécution d’outil ambiguë.
6. Jour 6 — Shadow et canary : observer d’abord les décisions, puis activer une route étroite à faible risque avec des déclencheurs de rollback prédéfinis.
7. Jour 7 — Réviser et élargir : examiner le taux de tâches acceptées, la latence ajoutée, l’écart de coût, les signaux de rejouabilité non sûre et les événements sans fallback éligible avant d’élargir.

La séquence est volontairement d’abord orientée workflow. Choisir une liste classée de modèles n’est qu’une petite étape. Le travail de production consiste à prouver quand le système peut continuer, quand il doit valider et quand il doit s’arrêter.

Checklist de déploiement de la stratégie de repli des modèles

Politique

• Chaque classe de route dispose d’une enveloppe de fallback.
• La politique de fallback est versionnée et consultable en tant que configuration.
• Les erreurs récupérables sont normalisées entre les fournisseurs.
• Le budget total de retries a un seul responsable.
• Les endpoints équivalents sont distingués des modèles alternatifs.
• Les candidats inter-modèles ont des contrats de capacité versionnés.
• La sortie partielle désactive par défaut le fallback transparent.
• Les outils en écriture utilisent des enregistrements d’idempotence durables.

Validation

• Le transport, le contrat et la réussite de la tâche sont mesurés séparément.
• Les sorties structurées sont validées après le fallback.
• Les arguments d’outil et le comportement de sélection d’outil sont testés par modèle.
• Les ensembles d’évaluation du fallback représentent de vraies classes de route.
• Les nouveaux candidats passent une évaluation hors ligne et un canary en production.
• Les cinq drills de défaillance réussissent pour chaque classe de route applicable.

Opérations

• Chaque tentative enregistre le motif de routage, la cible, la latence et le résultat.
• Les tableaux de bord affichent séparément le primaire, la nouvelle tentative, le basculement vers une capacité équivalente et la récupération inter-modèles.
• Les alertes incluent l’épuisement des délais et les taux d’absence de repli éligible.
• Les coupe-circuits utilisent des sondes demi-ouvertes contrôlées.
• La revue d’incident inclut la qualité visible pour l’utilisateur et le risque d’effet secondaire en double.
• Chaque trace de tentative enregistre la version active de la politique de repli.
• Chaque route dispose d’une fiche de préparation achevée et d’un responsable nommé.
• Les déclencheurs de rollback canari et les coupe-circuits ciblés sont testés.
• Les fiches d’incident capturent l’état de la requête, la validation et le résultat pour l’utilisateur.

Métriques qui prouvent que le repli est utile

N’optimisez pas uniquement le taux d’erreur du fournisseur. Suivez le résultat pour l’utilisateur.

Segmentez ces métriques par classe de route. Un taux de récupération agrégé peut masquer le fait que le repli fonctionne bien pour l’extraction mais mal pour la génération de code ou l’utilisation d’outils.

Lors du déploiement, comparez ces métriques par version de politique et par étape de publication. Cela permet de distinguer un incident fournisseur d’un changement du contrôleur, d’un changement de candidat ou d’un élargissement du canari.

Foire aux questions

Qu’est-ce qu’une stratégie de repli des modèles ?

Une stratégie de repli des modèles est une politique qui détermine quand une requête IA doit retenter la même cible, basculer vers une capacité équivalente, passer à un modèle alternatif approuvé ou s’arrêter parce qu’une relecture serait risquée.

Quelle est la différence entre nouvelle tentative et repli ?

Une nouvelle tentative répète la requête vers la même cible ou le même déploiement. Le basculement vers une capacité équivalente déplace la requête vers une capacité destinée à préserver le même contrat de modèle. Le repli inter-modèles change le modèle et nécessite donc une validation des capacités et de la qualité.

Chaque erreur 429 doit-elle déclencher un autre modèle ?

Non. Commencez par classer la limite, respecter les indications de nouvelle tentative, vérifier le délai restant et utiliser une nouvelle tentative bornée ou une file d’attente. Le changement de modèle peut aider lorsqu’une capacité alternative approuvée existe, mais il peut aussi modifier la qualité de sortie, le comportement des outils ou le coût.

Une réponse diffusée en flux peut-elle basculer au milieu de la réponse ?

Il est généralement plus sûr de ne pas basculer de manière transparente une fois que les jetons ont atteint l’utilisateur. Arrêtez le flux et proposez un redémarrage explicite, sauf si l’application dispose d’un protocole de reprise testé.

Combien de modèles de repli une route devrait-elle avoir ?

Utilisez le plus petit ensemble approuvé qui offre une récupération significative. Chaque candidat ajoute du travail d’évaluation, de surveillance et de réponse aux incidents. Une longue liste non testée n’est pas de la résilience.

Où la logique de repli devrait-elle résider ?

Centralisez la normalisation des fournisseurs, le routage, les budgets de tentatives et l’observabilité dans une passerelle ou une couche d’orchestration. Conservez l’intention propre au workflow — risque d’effets de bord, exigences de schéma, politique de sécurité et seuils de qualité — au plus près de l’application.

Comment une équipe devrait-elle déployer un repli automatique des modèles ?

Commencez en mode shadow, ne faites du canary que pour les workflows sûrs à rejouer, définissez les déclencheurs de rollback avant d’élargir le trafic, et revalidez la politique de repli chaque fois que les modèles, prompts, outils, schémas, la responsabilité des retries ou les exigences de sécurité changent.

Construire le repli autour du risque du workflow

La meilleure stratégie de repli des modèles n’est pas « essayer le modèle suivant ». C’est un système de décision borné :

• Workflow 1 récupère les requêtes rejouables avec des retries et une capacité équivalente.
• Workflow 2 bascule les modèles uniquement après des vérifications de capacité et de qualité.
• Workflow 3 arrête la relecture automatique lorsque la sortie ou les effets de bord rendent la récupération dangereuse.

Cette conception améliore la disponibilité sans masquer les échecs de contrat ni dupliquer les actions de l’utilisateur. Si votre équipe standardise l’accès entre plusieurs fournisseurs de modèles, utilisez la couche d’API unifiée compatible OpenAI de Flatkey comme surface d’intégration, puis associez ces enveloppes propres à chaque workflow à chaque route de production.

Sources et lectures complémentaires

• Codes d’erreur de l’API OpenAI
• Sorties structurées d’OpenAI
• Erreurs de l’API Anthropic
• Messages en streaming d’Anthropic
• Modèle de retry avec backoff d’AWS
• Modèle de disjoncteur d’AWS
• Stratégie de retry de Google Cloud