Un modèle par tâche : le guide du routing multi-modèles

Une équipe de développement branche un agent de codage sur le modèle le plus capable du marché, celui qui trône en tête des classements, et lui confie tout : l'exploration de la base de code, la planification, la génération, la relecture, la correction. Le résultat impressionne. Puis arrive la facture. En instrumentant la consommation, la même équipe découvre qu'une seule tâche de codage agentique a englouti de l'ordre de quatre millions de tokens¹, et que l'essentiel de cette dépense a servi à relire du contexte plutôt qu'à produire du code : des fichiers, des logs, de la mémoire rechargée. Le modèle de raisonnement le plus cher du monde a passé le plus clair de son temps à faire ce qu'un modèle dix fois moins cher aurait fait aussi bien : ingérer.

C'est le point de départ de tout routage sérieux. Faire tourner une usine logicielle entière sur un modèle unique, c'est une absence de choix, et un gâchis mesurable. Cet article laisse de côté le plaidoyer économique : le pourquoi financier, le débat entre prix par token et coût par résultat, est traité ailleurs. Ici, on entre dans la salle des machines. Comment, concrètement, route-t-on un pipeline agentique entre plusieurs modèles ? Quelle mécanique, quels garde-fous, et à quel moment le luxe du multi-agents mérite qu'on le paie ?

Pourquoi router : le coût suit l'ingestion, pas la génération

La donnée qui change tout tient dans un ratio. Sur une tâche de codage agentique, le rapport entre ce que le modèle lit et ce qu'il écrit atteint 153 pour 1, contre à peine 1,33 pour 1 dans un simple chat de code¹. Dans une session type, les lectures de fichiers représentent à elles seules près de 96 % du contexte : l'agent relit sans cesse ce qu'il a déjà ingéré. La facture ne suit pas la livraison, elle suit l'ingestion.

Cette asymétrie a une conséquence directe sur le choix du modèle. Payer le tarif d'un modèle de raisonnement de pointe pour avaler des dizaines de milliers de tokens de logs bruts ou relire un diff, c'est acheter une Formule 1 pour faire ses courses. La capacité de raisonnement premium ne se justifie que là où il faut raisonner : décider d'une architecture, arbitrer un compromis, planifier une trajectoire. Sur les phases dominées par l'entrée (et elles sont nombreuses), un modèle intermédiaire, voire un petit modèle rapide, produit le même résultat pour une fraction du coût. Router, c'est aligner le prix du modèle sur la nature du travail de chaque phase, plutôt que de payer partout le prix de la phase la plus exigeante.

Encore faut-il savoir où part la facture. Nos mesures sur un cycle de développement à onze phases sont sans ambiguïté. Quatre phases concentrent 78 % de la consommation totale : BUILD (~30 %), REVIEW (~19 %), PLAN (~17 %) et VERIFY (~12 %)¹. Le reste du cycle (définition, mise en place, capitalisation, mise en production) se partage les miettes. Router avec méthode revient donc à traiter en priorité ces quatre phases plutôt qu'à micro-optimiser les onze, parce que c'est là que se joue quasiment toute la dépense.

Le pattern : un modèle par phase

Le bon design tient dans une formule : un modèle par phase. Concrètement, trois familles de modèles se répartissent le travail selon la nature cognitive de la tâche.

Un modèle de raisonnement coûteux (un Opus, dans la nomenclature d'Anthropic) pour la planification et les décisions d'architecture. C'est la phase PLAN : explorer les options, peser les compromis, arrêter une trajectoire. On y consomme relativement peu de tokens rapportés au reste, mais chaque décision engage tout le reste du cycle. C'est le seul endroit où l'on veut, sans discuter, la meilleure tête disponible.

Un modèle intermédiaire (un Sonnet) pour la génération de masse, c'est-à-dire BUILD, la phase la plus lourde du cycle. Implémenter, valider, capturer les sorties réelles : un travail volumineux mais cadré, où un modèle de milieu de gamme tient parfaitement la charge à un coût très inférieur. C'est là que le routage rapporte le plus, tout simplement parce que c'est là que passe le plus de volume.

Un petit modèle rapide et bon marché (un Haiku) pour les scouts d'exploration : les agents qu'on lance en reconnaissance pour lire la documentation, scanner la base de code, trier des résultats de recherche. Ces tâches sont dominées par l'entrée et ne demandent aucune finesse de raisonnement ; y affecter un modèle premium reviendrait à payer le prix fort pour de la lecture rapide.

Ce triptyque a un nom dans l'outillage : le pattern « opusplan », un modèle de raisonnement pour planifier, un modèle intermédiaire pour exécuter, un petit modèle pour explorer¹. La logique tient là : composer une équipe où chacun opère à son niveau de coût pertinent, au lieu de chercher « le » bon modèle. Bien appliqué, ce routage par phase peut réduire la facture d'un ordre de grandeur sans dégrader la qualité perçue du résultat¹.

La mécanique : une passerelle, l'isolation, le cache

Le routage n'a de valeur que s'il est facile à mettre en œuvre et à faire évoluer. Les briques techniques nécessaires n'ont rien d'exotique.

Une passerelle compatible OpenAI. La quasi-totalité des laboratoires exposent aujourd'hui une API alignée sur le format OpenAI. Placer une passerelle unique (un routeur de modèles) devant tous vos appels transforme le choix du modèle en une simple variable, décidée à l'exécution en fonction de la phase. La conséquence pratique est frappante : brancher un cinquième modèle derrière cette passerelle devient une affaire d'heures, pas de trimestres. Le jour où un nouvel entrant casse les prix (la banalisation de la couche frontier en fournit un exemple par mois), on l'ajoute au portefeuille sans réécrire la moindre ligne métier. Cette abstraction est aussi la première pierre d'une architecture multi-LLM réversible : router par tâche et pouvoir sortir d'un fournisseur relèvent de la même couche.

L'isolation des sous-agents. Dès qu'on parallélise (plusieurs scouts, plusieurs relecteurs), la règle d'or est de donner à chaque sous-tâche sa propre fenêtre de contexte, et de ne faire remonter à l'orchestrateur qu'un résumé compact. Le détail d'une exploration ne doit jamais polluer le contexte principal. Sans cette discipline, chaque agent injecte ses milliers de tokens dans une fenêtre commune qui enfle jusqu'à l'absurde ; avec elle, l'orchestrateur reste léger, focalisé, et son coût par tour ne dérive pas. L'isolation fait plus que réduire le coût : elle garde le raisonnement de l'agent principal net. C'est du context engineering appliqué : composer délibérément ce que chaque agent voit, et ce qu'il ne voit pas.

Le prompt caching. Puisque la dépense est dominée par la relecture d'un contexte largement stable (la base de code, les instructions, la mémoire), mettre ce contexte en cache est le levier unique le plus puissant. Les relectures en cache reviennent à environ 10 % du tarif d'entrée normal, soit jusqu'à −90 % sur le tout premier poste de coût¹. Aucun changement de modèle n'offre un tel retour. Avant même de router finement, activer le cache est souvent le geste qui divise la facture par le facteur le plus visible.

Quand le multi-agents paie son multiplicateur

Le routage ne se limite pas à choisir un modèle par phase ; il inclut la décision de paralléliser : lancer plusieurs agents de front. Et cette décision a un prix élevé, qu'il faut regarder en face. Un système multi-agents de recherche consomme de l'ordre de quinze fois les tokens d'un simple chat ; une équipe d'agents de codage en mode plan, environ sept fois ceux d'une session unique¹. Le parallélisme n'est pas gratuit : chaque sous-agent entretient sa propre fenêtre, et les fenêtres s'additionnent.

Ce n'est pourtant pas un gaspillage, à une condition. Les sous-agents réduisent le temps réel de 50 à 80 % et améliorent la qualité du résultat : en évaluation interne, une équipe de sous-agents Sonnet a dépassé un agent Opus unique de +90,2 %¹. Le multiplicateur de tokens achète du temps et de la fiabilité. La question n'est donc jamais « le multi-agents coûte-t-il cher ? » (il coûte cher) mais « la tâche vaut-elle ce coût ? ».

D'où une règle de décision simple : quand la valeur de la tâche dépasse son coût en tokens, le multi-agents gagne ; sinon, on reste en agent unique. Deux phases paient ce multiplicateur par choix délibéré, parce que la parallélisation y rapporte plus qu'elle ne coûte. PLAN, d'abord : trois scouts partent en parallèle explorer la base de code, les bonnes pratiques et les versions de frameworks, avant qu'une synthèse ne remonte au décideur humain : un coût payé une seule fois par cycle, en amont d'un choix qui engage tout le reste. REVIEW, ensuite : quatre sous-agents auditent le même diff sous quatre angles (qualité, sécurité, tests, performance), chacun ré-ingérant le contexte dans sa propre fenêtre. Une telle revue multi-agents coûte de l'ordre de 15 à 25 dollars par pull request, pour environ trois millions de tokens¹. Rapporté au coût d'un défaut de sécurité passé en production, l'arbitrage est vite tranché. Ailleurs (pour une exploration secondaire, un enrichissement de confort), le même multiplicateur ne se justifie pas, et un agent unique suffit.

Les garde-fous : mesurer par phase, cadrer l'entrée

Un routage se pilote, il ne se décrète pas. Le premier garde-fou est la mesure par phase. Tant qu'on raisonne sur des moyennes globales, on optimise à l'aveugle. En instrumentant la consommation phase par phase (les outils de suivi de coût des agents le permettent nativement), on remplace les estimations par des chiffres maison et l'on voit tout de suite où le routage dérape : un modèle premium resté branché sur une phase d'ingestion, un cache mal configuré, une parallélisation qui ne rapporte rien.

Le second garde-fou est la maîtrise de la variance. Deux exécutions de la même tâche de débogage peuvent différer d'un facteur trente en tokens consommés¹. Autrement dit, un routage qui semble optimal en moyenne peut exploser sur un cas particulier. Il faut donc borner les boucles (limiter le nombre d'itérations de correction, cadrer strictement le périmètre en amont pour restreindre l'ingestion) et surveiller les queues de distribution, pas seulement la médiane. Plus de tokens n'égale d'ailleurs pas plus de réussite : sur les tâches de vérification, la précision plafonne à coût intermédiaire¹. Dépenser davantage au-delà de ce plateau, c'est brûler des tokens pour rien.

Le troisième garde-fou est de traiter le routage comme une composante du harnais, pas comme un réglage figé. La table de routage (quel modèle pour quelle phase, quand paralléliser, quand couper une boucle) est un artefact vivant, à ajuster au fil des mesures. C'est l'objet du harness engineering : l'équation Agent = Modèle + Harnais rappelle qu'à modèle égal, la qualité de l'attelage décide du résultat. Le routage est l'une des pièces maîtresses de ce harnais.

Le point de vue SFEIR : le routage est une compétence, pas un réglage

Notre conviction, en tant qu'acteur « AI Only », tient en une observation de terrain : les équipes qui maîtrisent leur facture agentique sont celles qui ont fait du routage une discipline d'ingénierie, pas celles qui ont trouvé le modèle le moins cher. Elles ont une passerelle, une table de routage documentée, une mesure par phase, et une règle explicite pour décider quand paralléliser. Le choix du modèle est devenu chez elles une variable d'exécution, pas un pari stratégique. Ce qui, au passage, les rend indifférentes au prochain lancement fracassant d'un laboratoire.

C'est la traduction opérationnelle d'un déplacement plus large, que nous documentons dans notre panorama des modèles frontier : la valeur ne réside plus dans le modèle, mais dans le système qui l'orchestre. Router est la première brique d'une usine logicielle qui traite les modèles comme des composants interchangeables : chacun à sa place, chacun à son coût.

Router, c'est cesser de parier

Revenons à l'équipe du début, celle qui faisait tout tourner sur un modèle unique et découvrait sa facture. Le remède consistait à cesser de poser la question en ces termes, pas à migrer vers un modèle moins cher. En affectant un modèle de raisonnement à la planification, un modèle intermédiaire à la génération, un petit modèle aux scouts ; en plaçant le tout derrière une passerelle unique ; en isolant les sous-agents et en mettant le contexte en cache ; en ne parallélisant que là où la valeur dépasse le coût, et en mesurant chaque phase, elle a repris la main sur sa dépense sans rien concéder sur la qualité.

Le routage multi-modèles est une posture, pas une astuce ponctuelle. Dans un marché où un cinquième, bientôt un sixième modèle frontier débarque au tarif du gros de la troupe, la bonne réponse n'est jamais « lequel choisir ? », mais « comment les faire travailler ensemble, chacun à sa juste place ». Router, au fond, c'est cesser de parier sur un modèle et commencer à construire le système qui n'en a plus besoin.

---

Sources

1. Bai et al., « How Do AI Agents Spend Your Money? », arXiv 2604.22750 (2026) — mesures sur 8 modèles frontier (SWE-bench Verified). Analyse first-party SFEIR de la consommation d'un cycle de développement piloté par agents (matière interne « Tokens & SDLC v3 ») : ratio entrée/sortie 153:1, ~4,17 M tokens par tâche, variance ×30 entre deux exécutions, concentration de 78 % de la facture sur BUILD·REVIEW·PLAN·VERIFY (~30/19/17/12 %), routage « un modèle par phase » (pattern « opusplan »), prompt caching jusqu'à −90 %, surcoût multi-agents ×15 (recherche) et ×7 (équipe de codage en plan), sous-agents Sonnet +90,2 % vs un Opus unique en évaluation interne, ~15-25 $ par pull request pour une revue multi-agents (~3 M tokens). arXiv 2604.22750