Routage sémantique LLM : notre plan B IA tient dans un proxy
Ce que six semaines de routage sémantique vers des modèles open-weight nous ont appris — sur les coûts, sur la qualité, et sur ce que « souveraineté » veut vraiment dire pour une agence qui utilise l'IA tous les jours, sur des projets clients.
Votre stack IA a-t-elle un plan B ? Parlons-en
Le déclencheur n'était pas technique
Fin 2025, nos factures IA grimpent. La question qui se pose alors est simple : est-ce qu'on paie le prix fort pour des tâches qui ne le méritent pas ? Un git commit bien formulé et une refonte d'architecture n'ont pas besoin du même modèle. D'où l'idée du routage sémantique : analyser l'intention de chaque requête et l'envoyer vers le modèle le moins cher capable de la traiter correctement.
Nous montons une première version. Verdict : décevant. Les modèles open-weight ne sont pas assez bons, et surtout pas assez peu chers pour que l'arbitrage tienne. L'expérience est mise de côté.
Six mois plus tard, le contexte a changé sur trois axes à la fois.
Les prix des modèles open-weight se sont effondrés. Leurs performances ont fait un bond que nous n'avions pas anticipé. Et surtout, l'épisode de censure de Fable a relancé très fort le débat sur la souveraineté de l'IA en Europe.
Ce troisième point n'est pas anecdotique pour nous. Nous utilisons l'IA intensivement, sur des projets clients, tous les jours. Une agence qui construit sa productivité sur des outils qu'elle ne contrôle pas doit se poser une question inconfortable : qu'est-ce qu'on fait si l'accès est coupé demain matin ?
L'expérience est relancée en juillet. Cette fois avec un objectif différent : ce n'est plus seulement un exercice d'optimisation de coûts, c'est un test de plan B.
Ce qu'est le routage sémantique
Le principe tient en une phrase : au lieu d'envoyer toutes les requêtes au même modèle, on analyse l'intention de chaque demande et on l'aiguille vers une route configurée pour ce type de tâche.
Concrètement, entre le prompt et la réponse, il y a une étape supplémentaire.
Le classifieur lit la requête et détermine sa nature : correction de bug, génération de code, planification de feature, design d'interface, analyse profonde. D'autres signaux entrent dans la décision : la langue, la taille du contexte, l'activation du mode raisonnement.
Nous avons testé trois approches pour ce classifieur : un modèle BERT local, de la détection de mots-clés, et un LLM rapide. C'est le LLM rapide qui s'est révélé le plus efficace. La latence ajoutée existe, mais elle n'est pas significative à l'échelle d'une boucle d'agent — et le classifieur tourne sans raisonnement, ce qui est une garantie architecturale autant qu'une optimisation.
Les cinq modèles
La configuration repose sur cinq modèles, chacun avec un rôle assumé.
| rôle | modèle | prix in / cache / out ($/M) | contexte |
|---|---|---|---|
| Classifieur | qwen3-235b-a22b-2507 | 0,120 / 0,098 / 0,590 | 262 K |
| Défaut + code | deepseek-v4-pro-0813 | 1,134 / 0,063 / 3,320 | 1 M |
| Volume + repli 1 | deepseek-v4-flash-0731 | 0,293 / 0,021 / 0,880 | 262 K |
| Design (repli) | moonshotai/kimi-k2.6 | 0,950 / 0,160 / 4,000 | 262 K |
| Qualité + repli 2 | z-ai/glm-5.2 | 1,190 / 0,221 / 3,740 | 1 M |
Trois familles se dégagent : un tier qualité (GLM 5.2, contexte long, pour tout ce qui demande de la hauteur de vue), un tier code (DeepSeek V4 Pro, notre cheval de trait), et un tier volume (DeepSeek V4 Flash, quatre fois moins cher, pour tout ce qui ne mérite pas mieux).
La route design est un ajout tardif. Dès les premiers essais, il était évident que DeepSeek n'avait pas le niveau sur les interfaces. Kimi a été branché en repli spécifiquement sur ce point.
La carte des routes
Douze routes, ordonnées par priorité décroissante. La première qui correspond à l'intention détectée l'emporte.
| prio | route | modèle primaire | repli | curseur |
|---|---|---|---|---|
| 200 | deep_analysis | GLM 5.2 (high) | DeepSeek V4 Pro (high) | 0,1 |
| 190 | architecture | GLM 5.2 | DeepSeek V4 Pro | 0,2 |
| 180 | feature_planning | GLM 5.2 | DeepSeek V4 Pro | 0,2 |
| 170 | ux_ui_design | GLM 5.2 | Kimi K2.6 | 0,2 |
| 160 | complex_review | GLM 5.2 | DeepSeek V4 Pro | 0,2 |
| 150 | code_review | DeepSeek V4 Pro | GLM 5.2 | 0,3 |
| 140 | bug_fixing | DeepSeek V4 Pro | DeepSeek V4 Flash | 0,3 |
| 130 | refactoring | DeepSeek V4 Pro | DeepSeek V4 Flash | 0,4 |
| 120 | code_generation | DeepSeek V4 Pro | DeepSeek V4 Flash | 0,4 |
| 110 | testing | DeepSeek V4 Flash (low) | DeepSeek V4 Pro | 0,6 |
| 100 | simple_task | DeepSeek V4 Flash (low) | DeepSeek V4 Pro | 0,8 |
| 10 | other (catch-all) | DeepSeek V4 Flash (low) | DeepSeek V4 Pro | 0,6 |
| — | default (dégradé) | DeepSeek V4 Flash | GLM 5.2 | — |
Le curseur est l'arbitrage coût/qualité paramétré pour chaque route : plus il est bas, plus on accepte de payer pour la qualité. deep_analysis à 0,1 tire vers le meilleur modèle disponible en raisonnement élevé ; simple_task à 0,8 tire vers le moins cher en raisonnement minimal.
La structure se lit en trois étages.
Chaque route a un repli, et les replis sont choisis pour dégrader dans la bonne direction. Une route qualité qui échoue retombe sur le tier code, pas sur le tier volume. Une route code qui échoue retombe sur le tier volume. Et ux_ui_design est la seule à basculer vers Kimi, parce que c'est le seul modèle du lot qui tient la route sur l'interface.
Enfin, la route default en mode dégradé sert de filet quand le classifieur lui-même est indisponible. C'est le cas qu'on espère ne jamais voir, et qui représente tout de même 12 % du trafic mesuré — un chiffre sur lequel nous avons encore du travail.
Un audit de votre dépendance aux modèles IA ?
Le bug qui coûtait cher
Première mesure sérieuse, sur 1 265 requêtes : 64,3 % du trafic partait dans la route catch-all. Deux tiers des requêtes n'étaient pas classées et finissaient sur le modèle flash en raisonnement minimal. Dans le même temps, les routes architecture et complex_review affichaient zéro requête. La route refactoring : une seule.
Autrement dit, nous avions construit douze routes et nous en utilisions vraiment quatre.
Le problème ne venait ni des routes ni du modèle. Il venait du format de sortie du classifieur, dont les réponses n'étaient pas exploitables de façon fiable.
La correction : un changement de classifieur, avec une sortie JSON structurée forcée.
Le catch-all est passé de 64 % à 45 %, et les routes spécialisées ont récupéré le trafic.
| route | avant (1 265 req.) | après (3 208 req.) |
|---|---|---|
| other (catch-all) | 64,3 % | 45 % |
| code_generation | 3,8 % | 16 % |
| bug_fixing | 11,6 % | 9 % |
| feature_planning | 4,7 % | 4 % |
| ux_ui_design | 7,7 % | 3 % |
| testing | 0,9 % | 3 % |
| deep_analysis | 1,3 % | 1 % |
C'est la leçon la plus concrète de tout ce chantier : dans un système de routage, le maillon faible n'est pas le modèle qui répond, c'est celui qui décide. Et un problème de format de sortie ressemble à s'y méprendre à un problème de qualité de modèle. Pendant plusieurs jours, nous avons cru que nos modèles sous-performaient, alors que nous leur envoyions simplement les mauvaises tâches.
Les 45 % restants ne sont d'ailleurs pas tous des échecs de classification : une part correspond à des demandes qui ne rentrent légitimement dans aucune de nos douze catégories. Reste que le chantier n'est pas terminé.
Les chiffres
Sur la durée des tests : 3 208 requêtes, 412,8 millions de tokens en entrée, 2,4 millions en sortie, pour 39,23 $.
La répartition par modèle montre bien l'effet du routage : le tier volume traite une part importante des requêtes pour une fraction du budget.
| modèle | coût | part du budget | latence moy. |
|---|---|---|---|
| DeepSeek V4 Pro (0813) | 16,97 $ | 43 % | 17,8 s |
| GLM 5.2 | 8,34 $ | 21 % | 15,7 s |
| DeepSeek V4 Pro | 7,23 $ | 18 % | 16,5 s |
| Qwen3 Coder Next | 3,39 $ | 8 % | 7,6 s |
| DeepSeek V4 Flash | 1,69 $ | 4 % | 17,2 s |
| Kimi K2.6 | 1,61 $ | 4 % | 31,8 s |
Le taux de cache est monté entre 80 % et 95 %, ce qui change tout dans la comparaison. En appliquant les tarifs publics aux mêmes volumes et au même taux de cache :
| scénario | coût estimé | facteur |
|---|---|---|
| Notre configuration | 39,23 $ | — |
| Sonnet 5 (80 % de cache) | ~255 $ | 6,5× |
| Opus 5 (80 % de cache) | ~638 $ | 16× |
Une précision d'honnêteté : ces 39 $ couvrent une période de tests, pas un usage intensif en production. Il serait malhonnête de les extrapoler en coût mensuel. Ce qui tient, en revanche, c'est le rapport à volume égal.
Ce que ça coûte vraiment
La facture n'est pas le seul prix à payer.
Les modèles open-weight arrivent au résultat. Mais ils y arrivent plus lentement — et pas seulement à cause de la latence brute. La boucle d'agent est plus longue parce que le modèle tâtonne davantage. Il explore, se trompe, revient. Le résultat final est là, le chemin est moins direct.
Un membre de l'équipe l'a formulé sans détour au début des tests : « j'ai l'impression de régresser d'un an ». C'était avant l'amélioration de la configuration, et le jugement serait plus nuancé aujourd'hui. Mais il pointe une réalité qui ne disparaît pas : l'open-weight a quelques mois de retard sur les modèles frontière.
Quelques mois. Pas quelques années. C'est précisément ce qui rend l'exercice intéressant.
Une chaîne complète, pas seulement un proxy
Un plan B qui ne couvre que l'accès aux modèles n'est pas un plan B. Si le proxy tient mais que l'outil qui l'utilise dépend, lui, d'un fournisseur unique, on a déplacé le problème d'un cran sans le résoudre.
Nous avons donc testé l'écosystème autour :
- Harness de développement : OpenCode, Pi, le harness DeepSeek — l'équivalent open des outils que nous utilisons au quotidien, comme Claude Code, Cursor ou Codex
- Design : OpenDesign
- Agent bureautique : OpenWork
L'objectif était de vérifier qu'aucun maillon de la chaîne ne constituait un point de rupture. La bascule, aujourd'hui, peut être immédiate.
Souveraineté avec des modèles chinois ?
C'est l'objection qui vient toujours, et elle est légitime. Le déclencheur du projet est un débat sur la souveraineté européenne, et la réponse repose sur DeepSeek, GLM et Kimi.
Est-ce qu'on remplace une dépendance par une autre ?
Non, et la distinction est précise : ce qui compte n'est pas l'origine du modèle, c'est le fait que les poids soient ouverts. Un modèle open-weight peut être hébergé n'importe où — y compris en Europe, y compris, à terme, sur nos propres machines. C'est la même logique que celle que nous explorons côté device avec les LLM en local sur mobile : rapprocher le modèle de l'endroit où l'on contrôle vraiment l'exécution.
Nous passons aujourd'hui par un agrégateur, mais c'est un choix de commodité : il permet de tester plusieurs modèles avec un seul compte, ce qui est exactement ce dont on a besoin dans une phase d'exploration. Rien n'empêche demain de prendre des comptes chez des hébergeurs européens. C'est cette portabilité qui constitue la garantie, pas le drapeau du laboratoire qui a entraîné le modèle.
Où nous en sommes
Le proxy reste en veille. Tous les quinze jours, nous testons une nouvelle configuration en fonction des modèles qui sortent et de l'évolution des prix. Ce n'est pas un projet terminé, c'est une veille active avec un livrable opérationnel.
Ce qui nous a le plus surpris, ce n'est ni les coûts ni l'architecture. C'est le rythme des progrès depuis décembre dernier. Des tâches entières, menées de bout en bout sans accroc, sur des modèles qui étaient inutilisables six mois plus tôt. C'est ce qui rend la solution de plus en plus viable au fil du temps, sans que nous ayons grand-chose à faire d'autre que remettre à jour la configuration.
Le conseil, si vous vous posez la question
Oui, il faut préparer un plan B. Pas nécessairement celui-ci : à chacun de le mettre en place en fonction de son contexte, de ses contraintes de confidentialité et de son niveau de dépendance.
Mais la question mérite d'être posée avant d'y être forcé.
C'est exactement le type d'arbitrages que nous accompagnons, du cadrage à la mise en production, via nos audits, notre agence IA et notre coaching IA en 24h.
Discutons de votre stratégie IA
llmsoup est accessible en ligne pour qui veut l'essayer : llmsoup.insideapp.fr. Il n'y a aucune volonté de le commercialiser à ce stade.
FAQ
Qu'est-ce que le routage sémantique appliqué aux LLM ?
Le routage sémantique consiste à analyser l'intention de chaque requête avant de l'envoyer à un modèle, puis à l'aiguiller vers une route configurée pour ce type de tâche. Une correction de bug, une refonte d'architecture et un message de commit ne mobilisent pas le même niveau de modèle : le routage permet d'envoyer chaque demande vers le modèle le moins cher capable de la traiter correctement.
Comment fonctionne le classifieur dans un proxy de routage sémantique ?
Le classifieur lit la requête et détermine sa nature : correction de bug, génération de code, planification de feature, design d'interface, analyse profonde. D'autres signaux entrent dans la décision, comme la langue, la taille du contexte et l'activation du mode raisonnement. Nous avons testé un modèle BERT local, de la détection de mots-clés et un LLM rapide : c'est le LLM rapide, contraint à une sortie JSON structurée, qui s'est révélé le plus efficace.
Quel gain de coût peut-on attendre de modèles open-weight routés ?
Sur nos tests, 3 208 requêtes et 412,8 millions de tokens en entrée ont coûté 39,23 $. En appliquant les tarifs publics aux mêmes volumes et au même taux de cache, la même charge revenait à environ 255 $ sur Sonnet 5 et 638 $ sur Opus 5, soit un facteur 6,5 et un facteur 16. Ce rapport tient à volume égal, mais il ne faut pas extrapoler ces 39 $ en coût mensuel de production.
Les modèles open-weight sont-ils au niveau des modèles frontière ?
Ils arrivent au résultat, mais plus lentement. La boucle d'agent est plus longue parce que le modèle tâtonne davantage : il explore, se trompe, revient. L'écart avec les modèles frontière se compte en mois, pas en années, et il se réduit vite.
Peut-on parler de souveraineté avec des modèles chinois ?
Ce qui compte n'est pas l'origine du modèle mais le fait que les poids soient ouverts. Un modèle open-weight peut être hébergé n'importe où, y compris en Europe et à terme sur ses propres machines. C'est cette portabilité qui constitue la garantie, pas le drapeau du laboratoire qui a entraîné le modèle.
Quel est le principal piège d'un système de routage sémantique ?
Le maillon faible n'est pas le modèle qui répond, c'est celui qui décide. Un problème de format de sortie du classifieur ressemble à s'y méprendre à un problème de qualité de modèle : pendant plusieurs jours nous avons cru que nos modèles sous-performaient alors que nous leur envoyions simplement les mauvaises tâches.
Faut-il préparer un plan B sur ses outils IA ?
Oui, mais pas nécessairement celui-ci. Chaque équipe doit le construire en fonction de son contexte, de ses contraintes de confidentialité et de son niveau de dépendance. La question mérite surtout d'être posée avant d'y être forcé.
Qu'est-ce que llmsoup ?
llmsoup est le proxy de routage sémantique que nous avons développé et testé en interne. Il est accessible en ligne sur llmsoup.insideapp.fr pour qui veut l'essayer. Il n'y a aucune volonté de le commercialiser à ce stade.