Routage LLM : passerelle et juge de complexité

Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 21 octobre 2026.

En bref

Dans la réalisation TW3 Partners, une passerelle multi-modèles reçoit les requêtes, un juge les classe par complexité, puis chaque niveau utilise un modèle sélectionné sur banc. Les requêtes sont classées simples, moyennes ou complexes. Les bancs comparent la justesse, la latence et le coût, sur une plateforme d’API de modèles ouverts hébergée en France. L’organisation peut changer de modèle sans refaire l’intégration des applications. Selon l’Insee, 21 juillet 2026, 33 % des entreprises utilisant l’IA en 2025 évoquent des coûts trop élevés comme frein à leurs usages. L’enquête couvre les entreprises implantées en France hors Mayotte, comptant au moins 10 personnes occupées, dans les secteurs principalement marchands hors agriculture, finance et assurance.

1. Qu’est-ce qu’une passerelle multi-modèles ?

Une passerelle multi-modèles désigne un point d’entrée commun entre les applications et plusieurs modèles de langage. Selon la documentation LiteLLM de BerriAI, les applications transmettent leurs requêtes à la passerelle, qui les adresse au fournisseur du modèle puis retourne la réponse dans le format d’OpenAI. Ce service peut être hébergé par l’organisation et expose une interface compatible avec l’API d’OpenAI.

La documentation prévoit des clés virtuelles attribuables aux utilisateurs, équipes et projets. Chaque clé possède sa liste de modèles, son budget et ses limites de débit. Dans la réalisation TW3 Partners, le dispositif comprend un proxy LiteLLM commun à tous les modèles et des clés par application.

Pour cadrer un déploiement, nous recommandons d’établir la correspondance entre chaque application, sa clé et son responsable. Ce registre doit permettre de retrouver qui peut modifier les modèles accessibles et qui valide les changements de configuration. Il devient ainsi un document de travail partagé entre l’équipe qui exploite la passerelle et les responsables des applications.

2. Pourquoi ne pas envoyer chaque requête au même modèle ?

Le routage répond au besoin d’ajuster le modèle au traitement demandé tout en conservant une intégration commune. Dans sa fiche de réalisation, TW3 Partners décrit une organisation souhaitant utiliser des modèles du marché et des modèles ouverts sans multiplier les intégrations ni les coûts. Le problème exposé associe le coût et le ralentissement liés au recours systématique à un modèle haut de gamme, ainsi que la dépendance créée par un modèle unique.

Pour évaluer ce choix dans une autre organisation, nous recommandons de partir des tâches réellement attendues. Définir pour chacune une réponse acceptable, puis comparer les modèles sur ces mêmes demandes, donne un cadre à l’arbitrage. Le responsable métier précise le niveau de justesse requis ; l’équipe de plateforme examine le délai de réponse et le coût correspondant.

Nous conseillons également de conserver une configuration de référence utilisant un modèle unique pendant l’évaluation. La comparaison doit porter sur les mêmes requêtes et inclure le passage par le juge. Elle permet de décider si le routage présente un intérêt pour le périmètre étudié, avant d’en généraliser l’usage.

3. Comment le juge de complexité classe-t-il une requête ?

Le juge intervient en amont de chaque requête et l’affecte à un niveau simple, moyen ou complexe. C’est le fonctionnement décrit par la fiche TW3 Partners, qui associe ce classement au choix des modèles par niveau.

Pour la recette, nous recommandons de consigner le modèle employé comme juge et son réglage, puis d’examiner ensemble le classement et la réponse obtenue. Une requête mal orientée pourrait parvenir à un modèle insuffisamment adapté : nous proposons donc de traiter ce risque dans les essais. Conserver la requête testée, le niveau attribué, le modèle appelé et le verdict de vérification permettrait d’examiner l’origine d’un échec.

Nous conseillons de faire relire les demandes dont la difficulté est discutée par les équipes métier et techniques. Cette revue doit servir à préciser les frontières entre niveaux. Il faut ensuite rejouer ces demandes dans le parcours complet, afin de vérifier la réponse après routage et le temps total nécessaire pour l’obtenir.

4. Comment choisir le modèle de chaque niveau ?

Le choix repose sur des bancs de mesure comparant la justesse, la latence et le coût, avec une décision documentée par niveau. La réalisation TW3 Partners précise que les critères sont vérifiables par programme et que les bancs ont été réalisés sur Scaleway Generative APIs, une plateforme d’API de modèles ouverts hébergée en France.

Vérifier par programme consiste à appliquer un contrôle automatique à la réponse produite. Pour construire ce banc, nous recommandons de définir en amont la réponse attendue et la règle qui décidera si elle est acceptable. Le responsable métier doit valider que cette règle correspond bien au besoin. L’équipe technique peut ensuite exécuter le contrôle de façon identique pour chaque candidat.

Le tableau suivant propose un contenu de dossier de sélection, à partir des critères publiés dans la fiche.

Critère du banc	Ce que nous recommandons de consigner	Décision à préparer
Justesse	Réponses attendues, règles de vérification et résultats par demande	Accepter le modèle sur le périmètre testé
Latence	Temps de réponse dans les conditions du test et délai du parcours avec juge	Vérifier la compatibilité avec l’usage
Coût	Consommation mesurée pour le même ensemble de demandes, juge compris	Comparer les configurations acceptables

Nous recommandons de conserver les versions des modèles et les paramètres employés avec les résultats. Toute nouvelle sélection doit pouvoir être comparée à la précédente sur un ensemble de demandes commun. Les résultats détaillés, les candidats écartés et la raison du choix constituent le dossier de décision proposé au responsable de la plateforme.

5. Pourquoi prévoir des variantes par profil d’utilisateur ?

Les variantes permettent de prévoir plusieurs configurations selon le profil de l’utilisateur, comme le décrit la fiche de réalisation. Pour préparer leur définition, la documentation LiteLLM de BerriAI apporte un point d’appui : les clés virtuelles peuvent disposer de modèles autorisés, de budgets et de limites de débit propres.

Nous recommandons de commencer par décrire les usages de chaque profil et les contraintes qui justifieraient une configuration distincte. Il faut ensuite décider quels paramètres peuvent varier et qui les administre. Ce cadrage devrait précéder la configuration de la passerelle.

Pour la recette, nous conseillons de tester chaque configuration retenue avec ses propres demandes représentatives. Le dossier devrait indiquer le profil, les modèles accessibles et le responsable de la validation. Lors d’un changement de modèle, reprendre cette liste aiderait à identifier les usages à vérifier avant la bascule.

6. Que gagne l’organisation à passer par une passerelle unique ?

L’organisation peut changer de modèle sans refaire l’intégration de ses applications : c’est le bénéfice annoncé dans la fiche TW3 Partners. Le proxy LiteLLM est hébergé sur le cloud du client et les modèles Gemini et Claude sont appelés via Vertex AI. L’hébergement français mentionné pour les bancs concerne la plateforme Scaleway utilisée pour ces mesures.

Une autre fiche TW3 Partners, consacrée à un assistant interne, décrit également l’appel à Gemini et Claude par un proxy LiteLLM pour éviter la dépendance à un fournisseur unique.

Pour préparer un remplacement, nous recommandons de conserver les demandes de recette et les règles de vérification avec la configuration en service. L’équipe pourra alors soumettre le candidat au même banc et faire valider les écarts par le responsable métier. Nous conseillons de prévoir également les conditions d’un retour au modèle précédent, avec un responsable désigné pour décider de la bascule.

7. Quels points de contrôle prévoir avant la mise en service ?

Nous recommandons de demander les résultats des bancs par niveau, le choix documenté des modèles et la répartition des clés par application. Ces documents prolongent les étapes publiées par TW3 Partners et donnent à la DSI un support pour prononcer la recette.

Le dossier de recette proposé devrait répondre aux questions suivantes :

Quelles demandes et quelles règles de justesse fondent le choix de chaque modèle ?
Le parcours mesuré comprend-il le juge et l’application utilisatrice ?
Qui autorise un changement de modèle ou de configuration ?
À quelle application et à quel responsable chaque clé est-elle rattachée ?

Le suivi financier peut s’appuyer sur les coûts par clé. La fiche TW3 Partners sur le suivi des coûts IA par projet décrit un tableau de bord qui collecte ces coûts auprès de la passerelle et les rattache aux projets. Nous recommandons donc de préparer cette correspondance dès l’attribution des clés.

Les articles du même dossier prolongent ce cadrage : « Suivre les coûts de l’IA générative par projet : tableau de bord FinOps et budgets bloquants » et « Filtrer les messages envoyés à un assistant IA interne : conception d’un garde-fou d’entrée qui tient sur un seul GPU ».

FAQ

Qu’est-ce que LiteLLM ?
La documentation de BerriAI présente LiteLLM AI Gateway comme un serveur auto-hébergé donnant accès à plusieurs fournisseurs de modèles par une interface compatible avec l’API d’OpenAI. La passerelle transmet les demandes et retourne les réponses aux applications.

Le routage réduit-il la facture ?
La fiche TW3 Partners vise à adapter le modèle à la requête, mais ne publie aucune économie, latence mesurée ni performance du juge. Nous recommandons de comparer le coût du parcours complet, juge compris, à celui de la configuration de référence, sur des réponses jugées acceptables.

Peut-on mêler modèles du marché et modèles ouverts ?
Oui, c’est le contexte décrit dans la fiche TW3 Partners. Les bancs de sélection y sont effectués sur une plateforme de modèles ouverts hébergée en France, Scaleway Generative APIs.

Que se passe-t-il si un fournisseur change ou retire un modèle ?
Dans la réalisation décrite par TW3 Partners, l’organisation peut changer de modèle sans refaire l’intégration. Nous recommandons de repasser le banc de sélection et la recette applicative avant de valider le remplacement.

Qui décide du modèle de chaque niveau ?
La réalisation TW3 Partners prévoit un choix documenté appuyé sur les bancs. Pour organiser cette décision, nous recommandons que le responsable métier valide les exigences de réponse et que le responsable de plateforme formalise la sélection technique.

Faut-il un juge pour chaque requête ?
Dans la réalisation TW3 Partners, le juge intervient en amont de chaque requête. Nous recommandons d’inclure son exécution dans les mesures de délai et de consommation réalisées pendant la recette.

Routage LLM : passerelle multi-modèles et juge de complexité