Faut-il un failover multi-LLM, ou un seul bon fournisseur suffit-il ?

La plupart des produits n'ont pas besoin de failover multi-LLM dès le premier jour. Construisez sur un seul fournisseur, encapsulez l'appel au modèle derrière une interface légère pour que le changement de fournisseur ne soit plus tard qu'une modification de configuration, et n'ajoutez un second fournisseur qu'une fois qu'une panne, une limite de débit ou un changement tarifaire vous a réellement coûté quelque chose de mesurable.

C'est la réponse sans surprise — et c'est la bonne pour peut-être 90 % des fondateurs qui nous posent cette question. Pourtant, elle revient régulièrement, d'autant plus maintenant que des outils promettant « une seule clé API pour tous les modèles » (GPT, Claude, Gemini, Grok, DeepSeek, Kimi) attirent l'attention. L'argument est séduisant : ne plus être prisonnier d'un seul fournisseur, contourner les pannes, arbitrer les prix. La réalité est plus nuancée, et se tromper dans un sens comme dans l'autre a un coût.

Pourquoi la question semble urgente en ce moment

Tous les fournisseurs ont connu des mauvaises journées. Les pages de statut d'OpenAI et d'Anthropic font toutes deux état d'incidents de dégradation périodiques, généralement de l'ordre de quelques minutes à quelques heures. Si votre produit envoie une requête côté client directement vers un seul modèle sans mécanisme de secours, une panne de 45 minutes se traduit par 45 minutes d'indisponibilité de votre produit — alors même que le reste de votre infrastructure fonctionne parfaitement.

Les limites de débit constituent le mode de défaillance le plus courant. La documentation sur les rate limits d'OpenAI et celle d'Anthropic font toutes deux évoluer ces limites avec le palier d'utilisation — ce qui signifie que le moment où vous subissez un pic de trafic (lancement produit, mention dans la presse, fonctionnalité virale) est précisément celui où vous risquez le plus d'atteindre un plafond que vous n'avez jamais rencontré auparavant.

La dépréciation des modèles est le problème silencieux. Les fournisseurs retirent les versions de modèles selon un calendrier établi, et si vos prompts ont été ajustés en fonction des particularités d'un modèle spécifique, son remplaçant peut faire évoluer la qualité des sorties de façon que vos utilisateurs remarquent avant vous.

L'argument contre une construction immédiate

Nous voyons des équipes se lancer dans une abstraction multi-fournisseurs complète avant même d'avoir livré une seule fonctionnalité qui l'exploite réellement. C'est de l'infrastructure prématurée, et elle a un coût bien réel : chaque couche d'indirection entre votre logique métier et l'appel au modèle est un endroit où un bug peut se cacher, et c'est du code à maintenir même si vous ne basculez jamais vers un autre fournisseur.

Nous avons tiré cette leçon en construisant nos propres outils de prospection. Nous scrapons le site de chaque prospect et rédigeons un e-mail personnalisé avec un seul appel LLM qui extrait les informations pertinentes et rédige le message — sans chaîne multi-étapes, sans couche d'orchestration. Nous avons d'abord essayé le pipeline multi-appels, supposé plus « robuste ». Il ne l'était pas : il était plus lent, plus coûteux par e-mail, et présentait davantage de points de défaillance. L'appel unique était moins cher, plus rapide et plus facile à déboguer. La leçon est généralisable : n'ajoutez pas de complexité architecturale pour vous prémunir contre un mode de défaillance que vous n'avez pas encore réellement rencontré. La même logique s'applique à la redondance de fournisseurs. Si aucune panne ne vous a encore coûté un client, vous optimisez probablement pour un problème que vous n'avez pas. C'est le même raisonnement qui explique pourquoi une conception simple à appel unique l'emporte généralement sur les chaînes d'agents pour des tâches bien délimitées.

Quand cela vaut vraiment la peine

La prise en charge multi-fournisseurs justifie sa complexité dans quelques situations précises :

• Vous dépassez plusieurs milliers de requêtes par jour et les limites de débit sont un point récurrent dans votre journal d'incidents, pas une hypothèse.
• Votre produit est orienté utilisateur et synchrone (un widget de chat, un agent vocal), où même quelques minutes d'indisponibilité fournisseur sont immédiatement visibles par vos utilisateurs en temps réel — contrairement à un job en arrière-plan qui peut simplement relancer dans une heure.
• Vous avez une charge de travail spécifique sensible aux coûts, où router les requêtes moins complexes (classification, extraction) vers un modèle plus petit et réserver un modèle frontier au raisonnement complexe modifie significativement vos économies unitaires. Cela recoupe largement le travail général d'optimisation des coûts LLM que vous devriez mener de toute façon.
• Vous êtes soumis à une obligation contractuelle ou réglementaire d'éviter la dépendance à un seul fournisseur — ce qui apparaît plus fréquemment dans les secteurs de la santé et des marchés publics que la plupart des fondateurs ne l'anticipent.

Si aucun de ces cas ne s'applique, vous construisez une assurance contre un risque que vous n'avez pas évalué.

Comment procéder sans sur-construire

Si vous avez décidé que vous en avez réellement besoin, ne développez pas un routeur from scratch. Des projets comme OpenRouter et LiteLLM résolvent déjà le problème de l'API unifiée : une interface, plusieurs backends, une gestion cohérente des erreurs. Le travail d'ingénierie sur lequel vous devriez vous concentrer est plutôt le suivant :

1. Isolez l'appel au modèle. Une seule fonction ou un seul module responsable de « envoyer ce prompt, obtenir cette réponse ». Tout le reste de votre codebase passe par lui, jamais directement par le SDK du fournisseur.
2. Normalisez vos prompts, pas seulement vos appels API. Des modèles différents réagissent différemment aux mêmes instructions. Un routeur qui change de fournisseur tout en envoyant exactement le même prompt dégradera silencieusement la qualité des sorties sur le modèle de secours si vous ne l'avez pas testé.
3. Ajoutez des evals avant d'ajouter le failover. Vous ne pouvez pas basculer en toute sécurité vers un second modèle si vous n'avez pas de moyen de mesurer si ses sorties sont suffisamment bonnes. C'est la même rigueur que nous recommandons lorsqu'il s'agit d'intégrer les evals dans les contrats avec des fournisseurs d'IA : savoir ce que « bon » signifie avant d'avoir à le prouver sous pression.
4. Définissez explicitement votre politique de bascule. Réessayer le même fournisseur, changer de fournisseur, ou dégrader gracieusement (réponse en cache, fonctionnalité simplifiée, transfert vers un humain) ? Chacune a un coût différent et un mode de défaillance différent — et « basculer sur GPT » n'est pas une politique.

Le cadre de décision concret

Posez-vous trois questions avant d'écrire une seule ligne de code de routage : combien de fois au cours du dernier trimestre une panne fournisseur ou une limite de débit vous a-t-elle réellement coûté un client ou une fonctionnalité défaillante ? Quel serait le coût, en temps d'ingénierie, de construire et maintenir un second chemin d'intégration ? Et le risque contre lequel vous vous assurez s'aggrave-t-il ou s'atténue-t-il au fur et à mesure que l'infrastructure de votre fournisseur mature ? Si la réponse à la première question est « jamais, mais j'y pense », livrez sur un seul fournisseur et revenez sur ce sujet dans trois mois. Si c'est « deux fois le mois dernier », vous avez déjà votre justification métier.

Le risque fournisseur est réel, mais le risque de livrer un système plus complexe que votre usage ne le justifie l'est tout autant. Si vous évaluez ce compromis pour un produit spécifique, parlons-en de vos modes de défaillance réels avant de construire autour de scénarios hypothétiques.