# Modèles de secours pour agents IA : comment garder votre agent opérationnel en cas de défaillance d’un modèle

> Découvrez le fonctionnement des modèles de secours pour agents IA, les erreurs qui doivent déclencher une solution de repli, les raisons pour lesquelles le modèle de secours se comporte différemment et comment le tester avant une panne.

Last updated: 2026-09-28T14:00:00

Canonical URL: https://crevio.co/fr/blog/ai-agent-backup-models

*Dernière mise à jour : septembre 2026. Pages d’état, rapports d’incident et documentation vérifiés le 28 septembre 2026.*

**Le modèle de votre agent finira par tomber en panne, et le modèle de secours prévu pour prendre le relais ne se comportera pas comme celui que vous avez testé.** Le 28 septembre 2026, la page d’état de l’API Claude affichait une disponibilité de 99,52 % sur les 90 jours précédents. Cela semble presque parfait, jusqu’à ce que l’on fasse le calcul : 0,48 % de 90 jours, c’est l’équivalent d’environ 10 heures de service dégradé ou indisponible sur un trimestre. Un modèle de secours pour agent IA permet à votre agent de continuer à fonctionner pendant ces heures. Mais s’il est configuré à la hâte, il peut aussi permettre à une tâche de s’achever discrètement à moitié avec un modèle que personne n’a jamais essayé.

Ce guide s’adresse aux dirigeants et aux équipes opérationnelles qui exécutent des agents selon un planning ou les mettent à la disposition de leurs clients. Vous y découvrirez ce qui peut tomber en panne, les erreurs qui doivent déclencher un basculement, la manière dont les principaux outils de routage gèrent ces situations et comment vérifier que votre solution de repli fonctionne avant d’en avoir besoin.

- **Trois pannes différentes peuvent sembler identiques de l’extérieur :** indisponibilité, limites de débit et modèles retirés. Seules certaines nécessitent un modèle de secours
- **Réessayez d’abord, basculez ensuite.** De nombreuses erreurs disparaissent après une nouvelle tentative ou en passant par un autre hôte qui exécute le même modèle
- **Un modèle de secours n’est pas une copie interchangeable.** Les modèles récents refusent des paramètres acceptés par les anciens, l’appel d’outils diffère et le cache de prompts est vide
- **Les solutions de repli coûtent plus cher par étape que prévu,** car le modèle de secours démarre avec un cache froid
- **Une solution de repli non testée n’est qu’une hypothèse.** Provoquez volontairement une panne, exécutez de vraies tâches avec le modèle de secours et consignez le modèle qui a répondu

## Qu’est-ce qu’un modèle de secours pour agent IA ?

Un modèle de secours pour agent IA, souvent appelé solution de repli LLM, est un second modèle configuré à l’avance pour prendre le relais lorsque le modèle principal de l’agent ne peut pas répondre. Le basculement est généralement automatique : un routeur ou une passerelle détecte l’erreur, envoie la même requête au modèle suivant d’une liste et renvoie la réponse comme si de rien n’était.

Il s’agit de l’une des quatre couches de protection. C’est la troisième à utiliser, et non la première :

| Couche | Fonctionnement | Corrige | Change de modèle ? |
|---|---|---|---|
| **Nouvelle tentative** | Renvoie la même requête après une courte attente | Brèves pointes de charge, dépassements de délai ponctuels | Non |
| **Basculement d’hôte** | Envoie la requête à un autre fournisseur qui exécute le même modèle | Défaillance d’un centre de données ou d’un hôte | Non |
| **Repli du modèle** | Envoie la requête à un autre modèle | Pannes complètes, quotas épuisés | Oui |
| **Migration planifiée** | Transfère volontairement l’agent vers un nouveau modèle | Retraits et abandons de modèles | Oui, définitivement |

L’ordre compte, car chaque étape du tableau modifie davantage le comportement de votre agent. Une nouvelle tentative ne change rien. Un autre modèle change presque tout, comme le montrent les sections suivantes.

## Les trois façons dont votre modèle principal peut tomber en panne

### Les pannes

Tous les grands fournisseurs en ont connu, et les rapports d’incident sont publics. Le 11 décembre 2024, [tous les services OpenAI ont été fortement dégradés ou indisponibles](https://status.openai.com/incidents/ctrsv3lwd797) de 15 h 16 à 19 h 38, heure du Pacifique : 4 heures et 22 minutes pour ChatGPT, l’API et Sora. La cause était un nouveau service de télémétrie qui avait surchargé le plan de contrôle Kubernetes d’OpenAI. Le bug ne se manifestait que dans les grands clusters, et les tests ne l’avaient donc pas détecté.

![Incident sur la page d’état d’OpenAI le 11 décembre 2024, marqué comme résolu et correspondant à une panne complète, avec 9 composants d’API et 5 composants ChatGPT affectés, signalés par des barres rouges et orange](https://crevio.co/vite/assets/openai-status-december-2024-incident-gqiohlkd.png)

Les incidents plus courts sont beaucoup plus fréquents. Le 4 mars 2026, OpenAI a signalé [30 minutes d’erreurs élevées sur l’API](https://status.openai.com/incidents/01KJXQDJ6P1CG5YNXKZRY2H6RX/write-up) après l’exécution simultanée d’un ensemble de modifications de capacité retardées, qui a retiré des moteurs d’inférence du service. La page d’état d’Anthropic montre le même schéma : de longues périodes au vert, entrecoupées de courtes journées rouges et orange.

![Page d’état de Claude indiquant que tous les systèmes sont opérationnels, avec les barres de disponibilité sur 90 jours pour claude.ai à 99,43 %, Claude Console à 99,95 % et l’API Claude à 99,52 %](https://crevio.co/vite/assets/claude-status-page-eal06oie.png)

Une panne de 30 minutes passe presque inaperçue lorsque vous discutez avec un chatbot. Elle compte beaucoup lorsqu’une tâche planifiée se déclenche pendant ce laps de temps, car personne n’est là pour cliquer sur « Réessayer ».

### Limites de débit et erreurs 429

Une erreur 429 signifie que le fournisseur est opérationnel, mais qu’il ne vous servira pas pour le moment. La plupart du temps, il s’agit d’une limite par minute : l’API d’Anthropic utilise un [token bucket qui se recharge en continu](https://platform.claude.com/docs/en/api/rate-limits) et envoie un en-tête `retry-after` indiquant le nombre de secondes à attendre. Attendre ce délai puis réessayer avec le même modèle est la bonne approche.

Mais les erreurs 429 ne sont pas toujours temporaires. Lorsqu’une organisation Anthropic atteint son plafond de dépenses mensuel, l’API renvoie une erreur 429 **sans** en-tête `retry-after`, et la documentation est catégorique : « Les nouvelles tentatives, y compris celles effectuées automatiquement par les SDK, échouent jusqu’au rétablissement de l’accès. » L’accès revient au début du mois suivant. Un agent qui traite chaque erreur 429 comme une invitation à « attendre et réessayer » peut donc réessayer toute la nuit face à une limite qui ne sera peut-être pas réinitialisée avant plusieurs semaines.

### Abandons et retraits de modèles

Les modèles sont retirés selon un calendrier, et un modèle retiré ne se dégrade pas progressivement. La [politique d’abandon d’Anthropic](https://platform.claude.com/docs/en/about-claude/model-deprecations) garantit un préavis d’au moins 60 jours pour les modèles accessibles au public et précise que « les requêtes adressées à des modèles après leur date de retrait échoueront ». Claude Opus 4.1 en est un exemple récent : les développeurs ont été informés le 5 juin 2026 et le modèle a été retiré le 5 août 2026.

![Page de documentation de Claude Platform consacrée aux abandons de modèles, présentant les étapes Actif, Hérité, Abandonné et Retiré, ainsi qu’un avertissement indiquant que les modèles abandonnés sont probablement moins fiables que les modèles actifs](https://crevio.co/vite/assets/claude-model-deprecations-gt44ujck.png)

La [page d’abandon des modèles d’OpenAI](https://developers.openai.com/api/docs/deprecations) accorde au moins six mois de préavis aux modèles généralement disponibles, mais les modèles en préversion « peuvent être retirés avec un préavis beaucoup plus court, par exemple deux semaines ». En juin 2026, OpenAI a annoncé l’arrêt des snapshots GPT-5 et o3 le 11 décembre 2026. Un modèle de secours ne résout pas un retrait. Il ne fait que le repousser jusqu’à la propre date de retrait du modèle de secours.

### La panne qu’aucune solution de repli ne détecte

La panne la plus coûteuse ne renvoie jamais d’erreur. En 2025, Anthropic a publié [une analyse rétrospective de trois bugs d’infrastructure](https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues) qui ont dégradé les réponses de Claude pendant plusieurs semaines. Lors de l’heure la plus critique, l’un de ces bugs affectait 16 % des requêtes adressées à Sonnet 4. Si le problème a mis si longtemps à être détecté, c’est notamment parce que « Claude se remet souvent très bien d’erreurs isolées », ce qui l’a masqué.

Aucune chaîne de repli ne se déclenche face à une réponse moins bonne, puisqu’une réponse moins bonne renvoie tout de même un code 200. C’est le rôle des [contrôles ponctuels de ce que produit l’agent](/fr/blog/human-in-the-loop-ai-agents), pas du routage.

## Quelles pannes doivent déclencher un basculement vers un modèle de secours ?

Lisez l’erreur avant de réagir. Le même message « le modèle a échoué » peut signifier qu’il faut attendre cinq secondes, basculer immédiatement ou corriger votre propre requête.

![Cinq pannes de fournisseurs et la réponse adaptée à chacune : attendre et réessayer en cas d’erreur 429 avec retry-after, basculer vers le modèle de secours en cas d’erreur 429 sans retry-after, réessayer puis changer d’hôte avant de basculer en cas d’erreur 5xx ou de dépassement de délai, corriger la requête en cas d’erreur 400 et promouvoir le modèle de remplacement avant la date de retrait](https://crevio.co/vite/assets/which-failures-need-a-backup-model-mvzdhotu.svg)

Deux lignes méritent un examen plus attentif :

- **Erreurs 5xx, surcharge et dépassements de délai.** La [référence des erreurs d’Anthropic](https://platform.claude.com/docs/en/api/errors) répertorie une erreur 529 `overloaded_error` en cas de trafic élevé pour tous les utilisateurs, et ses SDK réessaient déjà deux fois les erreurs temporaires avec une temporisation exponentielle. Une tentative supplémentaire est raisonnable. Cinq tentatives transforment une interruption de 30 secondes en blocage de 10 minutes
- **Erreurs 400.** Un paramètre incorrect ou une requête mal formée échouera également avec le modèle de secours, souvent pour la même raison. Exception : un prompt trop long. Certains routeurs l’envoient plutôt vers un modèle doté d’une fenêtre de contexte plus grande ; dans ce cas, le repli est utile

## Fonctionnement des chaînes de repli et du routage

Vous construisez rarement vous-même la logique de repli. Une couche de routage entre votre agent et les fournisseurs s’en charge. Quatre solutions sont courantes :

| Outil | Configuration du modèle de secours | Déclencheurs | Identification du modèle ayant répondu |
|---|---|---|---|
| **OpenRouter** | Tableau `models` classé par ordre de priorité | Indisponibilité, limites de débit, erreurs de longueur de contexte, signalements de modération | Champ `model` dans la réponse |
| **LiteLLM** | `fallbacks`, avec des solutions de repli distinctes pour la fenêtre de contexte et la politique de contenu | Limites de débit et erreurs de serveur, avec périodes de refroidissement après plusieurs échecs | Journaux du proxy et callbacks |
| **Vercel AI Gateway** | Tableau `models` associé à un `order` du fournisseur | Toute défaillance de l’ensemble des fournisseurs d’un modèle | Liste `modelAttempts` dans les métadonnées du fournisseur |
| **Cloudflare AI Gateway** | Liste d’étapes sur le point de terminaison Universal | Erreurs et dépassements de délai des requêtes | En-tête `cf-aig-step` de la réponse |

Les [solutions de repli des modèles OpenRouter](https://openrouter.ai/docs/guides/routing/model-fallbacks) sont les plus simples à visualiser : vous transmettez une liste d’identifiants de modèles et « si le premier modèle renvoie une erreur, OpenRouter essaie automatiquement le modèle suivant de la liste ». Les requêtes sont facturées au tarif du modèle qui a finalement répondu. Par ailleurs, son [routage des fournisseurs](https://openrouter.ai/docs/guides/routing/provider-selection) assure le basculement d’hôte pour un même modèle. Par défaut, il privilégie les fournisseurs qui « n’ont pas connu d’interruptions importantes au cours des 30 dernières secondes » et `allow_fallbacks` reste activé tant que vous ne le désactivez pas.

![Page de documentation OpenRouter consacrée aux solutions de repli des modèles, expliquant que le paramètre models essaie automatiquement d’autres modèles si les fournisseurs du modèle principal sont indisponibles, soumis à une limite de débit ou refusent de répondre](https://crevio.co/vite/assets/openrouter-model-fallbacks-docs-k3qy0sqx.png)

Les [paramètres de fiabilité de LiteLLM](https://docs.litellm.ai/docs/proxy/reliability) décomposent plus finement le problème. Les `fallbacks` classiques couvrent les limites de débit et les erreurs de serveur, `context_window_fallbacks` redirige un prompt trop volumineux vers un modèle plus grand et `content_policy_fallbacks` intercepte les erreurs liées à la politique de contenu. `allowed_fails` et `cooldown_time` retirent temporairement de la rotation un modèle défaillant, afin qu’un fournisseur en difficulté ne soit pas sollicité à chaque requête.

Les [solutions de repli de modèle de Vercel AI Gateway](https://vercel.com/docs/ai-gateway/models-and-providers/model-fallbacks) combinent les deux couches : le service essaie chaque fournisseur autorisé pour le modèle principal, puis passe au modèle suivant du tableau `models` et consigne chaque tentative. Les [solutions de repli de Cloudflare AI Gateway](https://developers.cloudflare.com/ai-gateway/configuration/fallbacks/) fonctionnent sur son point de terminaison Universal et indiquent dans un en-tête l’origine de la réponse : `cf-aig-step: 0` signifie que le modèle principal a répondu, tandis que `1` signifie que le premier modèle de secours l’a fait.

Une précaution s’applique aux quatre solutions. **La passerelle est elle aussi une dépendance.** Le réseau de Cloudflare a connu une panne majeure le [18 novembre 2025](https://blog.cloudflare.com/18-november-2025-outage/), de 11 h 20 à 17 h 06 UTC, après la propagation d’un fichier de configuration incorrect. Une chaîne de repli vous protège contre la défaillance d’un fournisseur de modèles. Elle ne peut pas vous protéger contre la couche qui exécute cette chaîne.

## Pourquoi un modèle de secours pour agent IA se comporte différemment

Un modèle de secours qui renvoie une réponse n’a pas nécessairement accompli sa mission. Les agents sont plus fragiles que les chatbots dans ce contexte, car ils se trouvent au milieu d’une tâche en plusieurs étapes lorsque le basculement se produit, avec un long historique d’appels d’outils que le nouveau modèle doit reprendre.

![Ce qui change lorsqu’un agent change de modèle : passer au même modèle sur un autre hôte conserve le comportement du prompt, le format des appels d’outils, les paramètres et la fenêtre de contexte, tandis qu’un modèle plus récent du même fournisseur ou un modèle d’un autre fournisseur modifie la plupart de ces éléments ; chaque basculement fait également perdre le cache de prompts actif](https://crevio.co/vite/assets/what-changes-when-an-agent-switches-models-nxjdqm6x.svg)

### Les paramètres acceptés par un modèle mais refusés par un autre

Le problème peut survenir même chez un même fournisseur. D’après les [notes d’abandon d’Anthropic](https://platform.claude.com/docs/en/about-claude/model-deprecations) et sa [référence des erreurs](https://platform.claude.com/docs/en/api/errors) :

- Définir `temperature`, `top_p` ou `top_k` sur une valeur autre que celle par défaut renvoie une erreur 400 avec Claude Opus 4.7 et les versions ultérieures
- Forcer un outil précis avec `tool_choice` renvoie une erreur 400 avec Claude Opus 5.5, Sonnet 5.5 et Fable 5.1
- Préremplir le début de la réponse de l’assistant renvoie une erreur 400 avec Claude 4.6 et les modèles ultérieurs

Ainsi, une chaîne qui bascule d’un ancien modèle vers un modèle plus récent et « meilleur » peut échouer instantanément avec une erreur que le modèle principal n’a jamais produite. L’option [`require_parameters` d’OpenRouter](https://openrouter.ai/docs/guides/routing/provider-selection) existe notamment pour cette raison : elle ne route les requêtes que vers les fournisseurs compatibles avec tous les paramètres envoyés.

### Appels d’outils et prompts

Les différents fournisseurs attendent des outils, des résultats et des raisonnements présentés sous des formes différentes. Un repli entre fournisseurs dépend donc de la capacité de la passerelle à traduire correctement la conversation. Même lorsque le format est conservé, le modèle de secours n’est pas celui sur lequel vous avez réglé vos instructions. Il peut appeler les outils dans un ordre différent, s’arrêter plus tôt ou interpréter « soyez bref » comme « ignorez la vérification ». Certaines données de raisonnement ne sont pas transférées du tout : Anthropic précise qu’un bloc de réflexion « provenant d’un modèle que le modèle cible ne peut pas lire est supprimé ».

### Fenêtres de contexte

Si le modèle de secours lit moins de contexte que le modèle principal, une longue exécution de l’agent peut dépasser sa capacité dès qu’il prend le relais. C’est pourquoi OpenRouter indique les erreurs de longueur de contexte parmi les déclencheurs de repli et que LiteLLM leur consacre une liste distincte. Ajoutez à la chaîne un modèle de secours doté d’une fenêtre de contexte au moins aussi grande que celle du modèle principal, ou demandez à l’agent de condenser l’historique ancien avant le basculement.

## Le coût des solutions de repli

Un modèle de secours modifie votre facture de trois façons, dont aucune n’apparaît dans un tableau comparatif des prix.

**Le cache actif disparaît.** La mise en cache des prompts contribue largement à rendre les agents abordables : les instructions, les définitions d’outils et l’historique sont renvoyés à chaque étape et facturés pour l’essentiel au tarif du cache. Les caches sont liés à un modèle précis chez un fournisseur précis. C’est pourquoi OpenRouter utilise le [routage persistant](https://openrouter.ai/docs/guides/best-practices/prompt-caching) « pour router vos requêtes suivantes vers le même point de terminaison fournisseur après une requête mise en cache ». Basculez vers un autre modèle et l’étape suivante est facturée au tarif normal. Au tarif catalogue de [Claude Sonnet 5.5](https://platform.claude.com/docs/en/about-claude/pricing), soit 2,00 $ par million de tokens d’entrée et 0,20 $ pour les tokens mis en cache, un historique d’agent de 50 000 tokens coûte environ 0,01 $ lorsqu’il est renvoyé depuis le cache, contre environ 0,10 $ sans cache. Soit dix fois plus par étape, jusqu’à ce que le cache du modèle de secours soit à son tour alimenté.

**Vous payez pour le modèle qui a répondu, avec ses propres tokens.** OpenRouter facture le modèle qui a finalement répondu. Un repli vers un modèle plus cher augmente donc la facture, mais un modèle de secours moins cher qui nécessite davantage d’étapes pour terminer peut aussi coûter plus cher. Les volumes de tokens ne sont pas non plus directement comparables : la [page tarifaire d’Anthropic](https://platform.claude.com/docs/en/about-claude/pricing) précise que ses modèles Claude 4.7 et ultérieurs utilisent un nouveau tokenizer qui produit environ 30 % de tokens supplémentaires pour un même texte.

**Les nouvelles tentatives sont également facturées.** Une requête qui échoue au milieu d’un flux a souvent déjà produit des tokens payants, et chaque nouvelle tentative renvoie l’intégralité du contexte. Nous avons expliqué comment ces coûts s’additionnent dans notre article sur le [coût d’exécution des agents IA](/fr/blog/ai-agent-running-costs) : les exécutions échouées et les boucles peuvent constituer une longue traîne qui dépasse la moyenne.

Rien de tout cela ne remet en cause l’intérêt des modèles de secours. Cela signifie simplement qu’il faut les conserver pour les situations de repli, les nouvelles tentatives et le basculement d’hôte absorbant les erreurs courantes afin que le basculement coûteux ne se produise qu’en cas de véritable panne.

## Testez votre solution de repli avant d’en avoir besoin

La plupart des chaînes de repli sont utilisées pour la première fois pendant un incident, précisément au pire moment pour découvrir que le modèle de secours ne peut pas appeler vos outils. Un court exercice une fois par trimestre, puis après chaque changement de modèle, permet de détecter l’essentiel :

1. **Provoquez la panne.** Dirigez le modèle principal vers un identifiant de modèle inexistant ou utilisez le commutateur de test de votre routeur. LiteLLM propose `mock_testing_fallbacks=True` dans son SDK et recommande de déclencher une véritable erreur fournisseur dans un environnement hors production pour son proxy
2. **Exécutez de vraies tâches, pas un prompt « Bonjour tout le monde ».** Prenez trois ou quatre tâches réelles de votre agent, dont une exécution longue faisant largement appel aux outils, et laissez-les se terminer entièrement avec le modèle de secours
3. **Comparez les résultats.** A-t-il appelé les mêmes outils, s’est-il arrêté au même endroit et a-t-il respecté vos règles de mise en forme ? Lisez les transcriptions, pas uniquement la réponse finale
4. **Vérifiez quel modèle a répondu.** Consultez le champ `model` de la réponse, `modelAttempts` ou l’en-tête `cf-aig-step`. Un exercice au cours duquel le modèle principal a répondu discrètement ne prouve rien
5. **Configurez des alertes sur les replis.** Un modèle de secours qui se déclenche tous les jours n’en est plus un. Il s’agit de votre véritable modèle, non testé à ce volume, et vous devez le savoir
6. **Inscrivez les dates de retrait dans votre calendrier.** Consultez les pages d’abandon du modèle principal et du modèle de secours, puis passez au remplacement bien avant l’une ou l’autre date

Pour les tâches planifiées, prévoyez également une stratégie pour les exécutions qui échoueront malgré tout. Notre guide consacré à la [planification de tâches récurrentes pour les agents IA](/fr/blog/schedule-recurring-ai-agent-tasks) explique à quoi ressemble un échec bien géré : un résultat partiel, un message clair et une tâche qui s’arrête d’elle-même au lieu de réessayer indéfiniment.

## Comment l’agent de Crevio gère les défaillances de modèles

[Crevio](https://crevio.co/) est un outil de création d’entreprise basé sur l’IA : vous décrivez ce que vous souhaitez vendre, et son agent construit, lance et exécute les opérations nécessaires. Crevio choisit et exécute les modèles utilisés par cet agent. Vous n’avez donc pas à gérer les comptes fournisseurs, les clés ni les versions de modèles. Voici ce qui se passe lorsqu’un modèle se comporte mal, expliqué clairement, y compris ce que l’agent ne fait pas.

**Ce qu’il fait aujourd’hui :**

- **Il réessaie automatiquement avec le même modèle.** Lorsqu’un appel de modèle échoue en raison d’une surcharge, d’une limite de débit, d’une erreur serveur, d’un dépassement de délai ou d’une réponse interrompue au milieu du flux, l’agent réessaie jusqu’à trois fois, en attendant un peu plus longtemps à chaque fois (environ 2, 4 puis 8 secondes). Les erreurs qu’une nouvelle tentative ne peut pas corriger, comme une requête mal formée, ne sont pas réessayées
- **Il évite l’hôte qui vient d’échouer.** Pour les modèles disponibles sur plusieurs hôtes, une nouvelle tentative après une erreur d’hôte ignore celui qui vient de produire l’erreur
- **Il condense les longues conversations.** Lorsqu’une conversation dépasse ce que le modèle peut lire, l’agent résume l’historique ancien et réessaie une fois au lieu de s’arrêter
- **Il vérifie la liste des modèles à chaque nouvelle version.** À chaque mise à jour de Crevio, il confirme que tous les modèles dont dépend l’agent sont toujours proposés. La version est signalée comme ayant échoué si l’un d’eux a disparu

![Formulaire de nouvelle tâche de Crevio pour un récapitulatif quotidien des ventes du matin, avec des instructions indiquant la source de données inaccessible, une répétition quotidienne et l’option Notify via configurée pour envoyer une notification dans l’application et un e-mail](https://crevio.co/vite/assets/crevio-task-failure-notifications-cq6okyoe.png)

**Ce qui se passe lorsqu’il échoue malgré tout :** l’échec d’une exécution de tâche planifiée est signalé via les canaux définis dans le paramètre **Notify via**, avec le détail de ce qui a été accompli et de ce qui a échoué. Par défaut, une tâche récurrente se désactive après trois échecs consécutifs et vous en informe, au lieu d’échouer chaque matin sans que personne ne s’en aperçoive. Dans une conversation en direct, une réponse qui a épuisé ses nouvelles tentatives s’arrête simplement ; vous devez alors renvoyer le message.

**Ce qu’il ne fait pas encore :** l’agent de Crevio ne bascule pas automatiquement vers un autre modèle en cours de tâche lorsque son modèle principal est indisponible. Aujourd’hui, la protection repose sur les nouvelles tentatives et le basculement d’hôte pour un même modèle. Vous ne pouvez pas non plus choisir le modèle de l’agent ni utiliser votre propre clé fournisseur. Si vous avez besoin d’une chaîne de repli personnalisée entre plusieurs fournisseurs, un outil de routage de la liste ci-dessus, intégré à votre propre stack, vous donnera ce contrôle.

[Crevio](https://crevio.co/) est disponible gratuitement au démarrage, et la formule Starter inclut 20 crédits IA par mois.

## FAQ

### Ai-je besoin d’un modèle de secours si j’utilise déjà une passerelle IA ?

La passerelle est l’endroit où vous configurez le modèle de secours ; elle ne constitue pas un modèle de secours en elle-même. Certaines solutions réessaient ou basculent automatiquement entre les hôtes d’un même modèle, mais un repli vers un autre modèle ne se produit que si vous en indiquez un. Elles ajoutent également leur propre dépendance : vérifiez donc le comportement de votre passerelle lors d’incidents passés.

### Le modèle de secours d’un agent IA doit-il provenir d’un autre fournisseur ?

En cas de panne, oui : un modèle de secours du même fournisseur risque de tomber en panne lors du même incident. En cas de limite de débit, un second modèle du même fournisseur peut suffire, car les limites sont généralement définies par modèle. Le compromis concerne la compatibilité : plus le modèle de secours s’éloigne du modèle principal, plus vous devez tester les prompts, les appels d’outils et les paramètres.

### À quelle fréquence dois-je tester ma solution de repli LLM ?

Effectuez un exercice après chaque modification du modèle principal, du modèle de secours ou des instructions et outils de l’agent, et au moins une fois par trimestre dans les autres cas. Vérifiez également les dates d’abandon des deux modèles à chaque exercice : un modèle de secours déjà retiré échouera précisément au moment où vous en aurez besoin.

## Un modèle de secours que vous n’avez jamais exécuté n’est qu’une hypothèse

Les pannes, les limites de débit et les retraits sont désormais courants. Un bon modèle de secours pour agent IA les transforme en rapport matinal légèrement retardé plutôt qu’en rapport manqué. Mais sa valeur dépend de l’ordre dans lequel vous l’utilisez : réessayer, passer à un autre hôte, puis à un autre modèle, et uniquement avec un modèle de secours dont vous avez déjà observé l’exécution de tâches réelles. Si vous ne l’avez pas testé, vous n’avez pas de solution de repli. Vous avez simplement une deuxième source de panne potentielle.

## Articles associés

- [Coût d’exécution des agents IA : combien coûte réellement un agent par mois ?](/fr/blog/ai-agent-running-costs)
- [Comment planifier des tâches récurrentes pour un agent IA qui fonctionne sans vous](/fr/blog/schedule-recurring-ai-agent-tasks)
- [Agents IA avec supervision humaine : quoi approuver et quoi laisser s’exécuter](/fr/blog/human-in-the-loop-ai-agents)
- [Les agents IA pour les entreprises : que déployer en premier, service par service](/fr/blog/ai-agents-for-business)