Tout le monde construit des routeurs LLM, nous avons déprécié le nôtre.

Imaginez construire un système qui choisit automatiquement le modèle d’IA le plus économique pour chaque requête. Cela semble parfait sur le papier : pourquoi payer pour GPT-4 quand Claude 3 Haiku pourrait suffire ? C’est exactement ce que de nombreuses entreprises font en ce moment, en lançant des routeurs LLM sophistiqués qui promettent de réduire drastiquement les coûts d’inférence. Mais il y a un problème : Manifest, une plateforme qui a construit et lancé son routeur en mars 2026, a décidé de le déprécier complètement après seulement quatre mois. Leur conclusion est surprenante et contre-intuitive : pour la plupart des cas d’usage, le routage intelligent n’est pas la solution qu’il semble être. Ce changement de cap offre une leçon importante à quiconque envisage d’implémenter cette technologie.

De Quoi S’agit-il
#

L’article de Bruno Perez raconte les coulisses d’une décision difficile : pourquoi Manifest a supprimé une fonctionnalité qui avait été présentée comme centrale dans leur passerelle LLM. Leur routeur classait chaque requête en quatre niveaux de complexité (simple, standard, complexe et reasoning) pour la diriger vers le modèle approprié. Cela semble logique, mais après quatre mois d’utilisation parmi des milliers d’utilisateurs cloud, l’équipe a découvert que les bénéfices promis ne se concrétisaient pas comme prévu. Au lieu de réduire les coûts globaux, le routage créait des problèmes cachés qui compensaient les économies apparentes.

Pourquoi C’est Pertinent
#

La pertinence de cette histoire va bien au-delà de Manifest. Alors que le marché des routeurs LLM explose avec de nouveaux acteurs qui promettent des économies significatives, cette expérience réelle montre que la réalité est beaucoup plus complexe qu’il n’y paraît.

Le premier problème est fondamental : la complexité d’une tâche ne peut pas être déduite du seul prompt. Quand vous demandez à un modèle d’« évaluer et améliorer les tests d’un référentiel », le niveau de difficulté réel dépend de facteurs qui n’émergent que pendant l’exécution : si le repo est un simple site HTML ou le kernel Linux. Le routeur prend la décision dans le noir, en se basant sur des informations incomplètes.

Le deuxième aspect est économique mais contre-intuitif : le caching est beaucoup plus efficace que le routage pour réduire les coûts. Les lectures depuis le cache coûtent entre 90 % et 95 % moins cher que les entrées non cachées. Quand un routeur maintient une « stickiness » avec le même modèle pour exploiter le caching du prompt système et de l’historique conversationnel, il finit par ne pas faire de routage. En d’autres termes, le routeur atteint l’efficacité économique en cessant de faire son travail principal.

Le troisième problème est qualitatif : le routage casse la cohérence comportementale. Passer d’un modèle à l’autre pendant une session de travail dégrade la qualité globale et éloigne les ingénieurs de la maîtrise de leurs outils. C’est comme demander à un peintre de changer de pinceau au milieu d’une œuvre parce qu’un autre coûte moins cher.

Applications Pratiques
#

Cette leçon est particulièrement pertinente si vous construisez des systèmes agentic ou des workflows automatisés. Quand vous ajoutez une couche d’incertitude dans le routage, tout devient plus difficile à maintenir : les évaluations, les prompts système, l’observabilité. Chaque fois que vous ne savez pas quel modèle a traité une requête, il devient plus complexe de déboguer les comportements anormaux ou d’optimiser les performances.

Pour la plupart des équipes, la meilleure stratégie est de choisir consciemment un modèle éprouvé et de construire autour de celui-ci. Cela signifie investir du temps pour comprendre les compromis entre les modèles disponibles, tout comme un artisan sait exactement quel outil utiliser. Si le coût est un problème, l’accent devrait être mis sur des stratégies de caching intelligentes et l’optimisation des prompts, pas sur le routage dynamique.

Réflexions Finales
#

L’expérience de Manifest représente un moment de maturité dans le secteur des LLM. Tout ce qui semble efficace sur le papier ne l’est pas dans la pratique. Le routage des LLM aura probablement des cas d’usage légitimes, mais ce n’est pas la solution universelle que le marketing du secteur suggère. La vraie leçon est que simplifier bat souvent l’automatisation sophistiquée quand le coût caché de l’automatisation est plus élevé que le bénéfice apparent. Dans un écosystème où les modèles évoluent rapidement et les coûts changent constamment, avoir le contrôle et la prévisibilité pourrait valoir beaucoup plus que quelques pourcentages d’économies économiques.

Cas d’Usage
#

Private AI Stack: Intégration dans des pipelines propriétaires
Client Solutions: Implémentation pour des projets clients

Ressources
#

Liens Originaux
#

Everyone is building LLM routers, we deprecated ours - Lien original

Article signalé et sélectionné par l’équipe Human Technology eXcellence traité via intelligence artificielle (dans ce cas avec LLM HTX-EU-Claude-Haiku-4.5) le 2026-08-18 08:11 Source originale : https://manifest.build/blog/why-we-deprecated-our-llm-router/

Résumé #

Introduction #

De Quoi S’agit-il #

Pourquoi C’est Pertinent #

Applications Pratiques #

Réflexions Finales #

Cas d’Usage #

Ressources #

Liens Originaux #

Articles Connexes #

Résumé
#

Introduction
#