Model routing
Politique consistant à orienter chaque tâche vers un modèle IA différent selon son risque, sa complexité ou son coût, plutôt que d'utiliser un modèle unique pour tout.
Définition
Le model routing consiste à définir des règles explicites pour choisir quel modèle traite quelle tâche : un modèle économique pour les tâches mécaniques (génération de boilerplate, tests unitaires simples), un modèle plus coûteux pour l'architecture, le refactoring complexe ou le debugging de comportements subtils. Ce n'est pas une session = un modèle, mais un mapping tâche → modèle documenté, qu'il soit appliqué manuellement ou via un proxy/gateway qui route automatiquement selon des critères définis.
Point de vue postcursors
Le model routing est pertinent comme politique explicite, surtout à l'échelle d'un budget d'équipe — c'est un moyen concret de contrôler le coût sans sacrifier la qualité là où elle compte. Le piège : appeler "routing" ce qui n'est en réalité que du zapping d'outil individuel, changer de modèle sans règle écrite ni mesure, au gré des sorties ou de l'humeur du moment.
En pratique
Une équipe qui adopte Kilo Code sur OVH AI Gateway peut router par défaut vers Gemini pour le travail courant, et vers Claude Sonnet via l'API Anthropic directe pour l'architecture et le refactoring complexe. Le routing selon la nature de la tâche — documenté, pas improvisé session par session — est l'étape de maturité qui suit l'adoption d'un modèle unique.
Confusions fréquentes
- ✗ Appeler 'routing' le fait de changer de modèle au hasard selon la dernière release ou l'humeur, sans règle écrite ni mesure de résultat
- ✗ Router uniquement sur le prix du token sans tenir compte de la qualité produite pour le type de tâche concerné