LLM Router vs API directe : ce que les fondateurs doivent peser

Utilisez un LLM router tant que vous testez encore quel modèle correspond à votre produit, que vous avez besoin de flexibilité multi-modèles, ou que vous souhaitez un basculement automatique sans avoir à le construire vous-même. Passez à l'API directe du fournisseur une fois que vous avez arrêté votre choix sur un modèle principal, que votre volume est suffisant pour négocier la tarification, et que vous voulez supprimer un intermédiaire entre votre produit et vos données.

Cette décision est devenue plus intéressante cette année. Les informations faisant état d'une acquisition d'OpenRouter par Stripe pour plus de 7 milliards de dollars rappellent que les services d'« agrégation » sont des entreprises financées par du capital-risque, avec leurs propres logiques de sortie — pas une infrastructure neutre. Si vous faites transiter un trafic significatif par un tiers, une acquisition, un changement de tarification ou une fermeture est désormais quelque chose que vous anticipez, pas quelque chose que vous ignorez.

Ce qu'un router vous apporte concrètement

Un LLM router (OpenRouter et services similaires) s'intercale entre votre application et plusieurs fournisseurs de modèles. Vous envoyez une requête dans un format commun, et le router prend en charge :

• La sélection du modèle : remplacer claude-sonnet-5 par un modèle moins cher avec un changement de configuration, pas de code.
• Le basculement automatique : en cas de panne d'un fournisseur, le router peut relancer automatiquement la requête sur un modèle de secours.
• La facturation unifiée : une seule facture au lieu de comptes séparés chez Anthropic, OpenAI et tous les autres fournisseurs que vous testez.
• Une forme d'API unique : utile quand vous évaluez des modèles et ne souhaitez pas réécrire le parsing requête/réponse pour le SDK de chaque éditeur.

C'est une valeur réelle, surtout en phase initiale. C'est aussi exactement le type de logique de coordination abordé dans multi-llm-provider-failover si vous préférez construire la partie basculement vous-même plutôt que de la sous-traiter.

Ce à quoi vous renoncez

Chaque couche que vous ajoutez entre votre produit et le modèle est une couche que vous ne contrôlez pas :

• La tarification : vous êtes soumis à la marge du router — ou à l'absence de remises sur engagement — plutôt que de négocier directement avec le fournisseur dès que votre niveau de dépense le justifie.
• La latence : un saut réseau supplémentaire, généralement faible, mais qui s'accumule pour les agents vocaux ou temps réel où chaque centaine de millisecondes compte.
• Le traitement des données : vos prompts et complétions transitent par l'infrastructure d'un tiers avant d'atteindre le fournisseur de modèles. Dans la santé ou le govtech, cela signifie un BAA ou un DPA supplémentaire à négocier, pas un raccourci pour s'en affranchir.
• Le risque de continuité fournisseur : le router lui-même peut être racheté, modifier ses conditions ou déprécier un modèle dont vous dépendez. Vous suivez désormais la roadmap de deux entreprises au lieu d'une.

Rien de tout cela ne disqualifie les routers. Cela signifie que la commodité a un prix, et que ce prix évolue à mesure que vous montez en charge.

Pourquoi l'actualité d'OpenRouter est un signal utile

Que l'accord Stripe se concrétise ou non tel que rapporté, le schéma vaut la peine d'être intériorisé : les agrégateurs existent parce que basculer entre OpenAI, Anthropic et d'autres fournisseurs est contraignant, et quelqu'un vous vendra toujours une abstraction sur cette contrainte. Mais une couche d'abstraction rachetée peut modifier son modèle tarifaire, être intégrée dans le produit d'une plateforme plus large, ou réorienter entièrement son positionnement — sans que vous ayez votre mot à dire.

Si une part significative du coût ou de la latence de votre produit transite par un agrégateur, traitez cela comme n'importe quel point de défaillance unique : sachez ce qu'il faudrait pour basculer vers une intégration directe en une semaine, pas en un trimestre. Cela ne signifie pas le pré-construire — cela signifie maintenir votre logique de prompt découplée du SDK d'un éditeur particulier, afin que la bascule soit un changement de configuration et de client, pas une réécriture.

Quand utiliser l'un ou l'autre

Utilisez un router quand :

• Vous n'avez pas encore atteint le product-market fit et comparez encore qualité des modèles et coût.
• Vous avez besoin d'un basculement automatique entre fournisseurs et ne souhaitez pas construire vous-même la logique de retry/fallback.
• Votre volume est trop faible pour que les remises en direct auprès des fournisseurs fassent une différence significative.

Passez en direct quand :

• Vous avez choisi un modèle principal et votre dépense mensuelle est suffisamment élevée pour qu'un accord entreprise direct batte la tarification agrégateur.
• La latence fait partie de la proposition de valeur de votre produit (voix, chat temps réel, tout ce qui est interactif).
• Vous évoluez dans un secteur réglementé et avez besoin d'un accord de traitement des données directement avec l'éditeur du modèle, pas via un intermédiaire.
• Vous avez déjà construit votre propre logique de basculement et n'avez pas besoin de celle du router.

La plupart des équipes qui dépassent le stade du MVP aboutissent à une approche hybride : intégration directe avec leur modèle principal pour le trafic de production, router ou fallback direct pour la fiabilité en mode dégradé. C'est une bonne valeur par défaut, pas un compromis.

Ce que nous avons appris en travaillant avec les deux approches

Dans notre propre outillage, nous faisons tourner un moteur d'outreach qui scrape le site de chaque prospect avec une instance Firecrawl auto-hébergée et un LLM local, puis rédige un email personnalisé par entreprise. Nous avons comparé cette approche à un pipeline chaîné multi-étapes (extraction des faits, puis rédaction séparée) et avons constaté qu'un seul appel bien prompté donnait de meilleurs résultats, tant sur le coût que sur la qualité, que le découpage en étapes — voir single-call-vs-agent-chains pour le schéma général. La leçon qui s'applique ici : moins il y a de sauts entre vos données et le modèle, mieux c'est en termes de coût et de qualité, que ce saut soit une étape de chaîne superflue ou une couche de routage inutile. Ce n'est pas une raison d'éviter les routers systématiquement — c'est une raison d'être délibéré sur les sauts qui justifient leur existence.

Le cadre de décision concret

Posez-vous trois questions avant de choisir l'une ou l'autre voie :

1. Avez-vous déjà identifié votre modèle principal ? Si non, la flexibilité d'un router vaut son faible surcoût.
2. Quel est votre niveau de dépense LLM mensuelle ? En deçà de quelques milliers de dollars par mois, les remises en direct auprès des fournisseurs sont négligeables ; au-delà, elles s'accumulent. Faites le calcul comme vous le feriez pour l'optimisation des coûts LLM en général.
3. Quelle est la sensibilité de vos données ? Les données réglementées (dossiers médicaux, données financières, tout ce qui relève d'une obligation de conformité) orientent généralement vers une intégration directe avec un accord signé, pas vers un service intermédiaire.

Ces réponses ne sont pas définitives. De nombreuses équipes démarrent avec un router et basculent en direct une fois que le volume et le choix du modèle se stabilisent. L'erreur n'est pas de faire le « mauvais » choix au départ — c'est de coupler si étroitement votre logique de prompt et de requête au format d'un seul éditeur que changer de cap implique une réécriture plutôt qu'un changement de configuration.

Si vous êtes en train de peser ce compromis pour un produit que vous construisez en ce moment, parlons-en.