Le dispatch cognitif — quel modèle pour quel agent

En bref

Quand on construit un pipeline d’agents, l’instinct pousse à utiliser le plus grand modèle pour les tâches difficiles. Nos tests sur 30 runs montrent que ce réflexe est partiellement faux : Opus n’apporte rien de mesurable sur les tâches analytiques par rapport à Sonnet, et Haiku reste exploitable bien au-delà de ce qu’on attendrait. Le vrai critère de dispatch n’est pas la taille du modèle — c’est le type d’opération cognitive demandée.

Contexte

Un pipeline d’agents, c’est typiquement un modèle orchestrateur qui envoie des sous-tâches à des agents spécialisés. Chaque agent reçoit une tâche précise : extraire un fait, comparer deux documents, synthétiser trois sources, concevoir un protocole. La question pratique est simple : quel modèle assigner à quel agent ?

L’intuition courante — et le discours commercial — pousse vers une règle de taille : tâche simple → Haiku, tâche intermédiaire → Sonnet, tâche complexe → Opus. C’est une heuristique lisible. Mais est-elle juste ?

Pour le tester, nous avons soumis dix tâches progressives aux trois modèles, en parallèle, sur 30 runs au total. Les tâches vont de l’extraction d’un fait précis dans un fichier unique (T1) jusqu’à la conception complète d’un protocole expérimental sur cinq fichiers simultanés (T10). Chaque run produit un livrable évalué sur quatre critères : couverture des points attendus, absence d’hallucinations, respect du format, exploitabilité directe.

Ce que les chiffres disent

Les durées

Haiku est 2,5 fois plus rapide que Sonnet. Opus est 5 % plus lent que Sonnet. Sur la tâche la plus lourde (T10, cinq fichiers, conception de protocole), l’écart devient plus marqué : Opus prend 195 s contre 138 s pour Sonnet, et 57 s pour Haiku.

Les tokens consommés

Haiku consomme environ 25 % plus de tokens que les deux autres pour le même prompt. Sonnet et Opus sont quasi identiques sur ce point. Sur un pipeline à fort volume, cet écart de tokens peut compenser l’écart de vitesse selon le pricing de l’API utilisée.

La qualité

Sur les dix tâches, Sonnet et Opus obtiennent 100 % de couverture, 0 hallucination, 10/10 formats respectés, 10/10 outputs exploitables. Haiku atteint 98 % de couverture moyenne avec le même score sur les autres critères.

La différence entre Haiku et les deux autres n’est pas dans les chiffres bruts — elle est dans la profondeur analytique. Sur T4 (comparer deux fichiers), Haiku produit exactement le minimum demandé : 3 points communs, 3 différences. Sonnet et Opus en produisent 5+5, avec plus d’argumentation. Sur T10, Haiku conçoit un protocole fonctionnel avec 7 sections sur 7. Sonnet produit un protocole plus rigoureux, avec des conditions de contrôle supplémentaires et des hypothèses alternatives. Opus produit… le même protocole que Sonnet.

Sonnet ≈ Opus : un résultat inattendu

Sur les tâches analytiques — lire des documents, croiser des sources, détecter des incohérences, rédiger une synthèse structurée — Sonnet et Opus produisent des résultats indistinguables. Opus prend plus de temps et ne produit pas de meilleure qualité.

Sur T10, Opus effectue 15 appels d’outils contre 5 pour Sonnet, et relit chaque fichier trois fois. Il travaille davantage. Il ne produit pas mieux. Les outputs Sonnet et Opus sont “remarquablement similaires” sur l’ensemble des tâches d’analyse documentaire.

Ce résultat tient également sur une série complémentaire portant sur la recherche documentaire (trois sujets, évaluation en aveugle) : Sonnet et Opus atteignent tous les deux 100 % de couverture des points factuels attendus, 0 hallucination, 3/3 formats respectés, 3/3 outputs exploitables.

La documentation Anthropic positionne Opus pour “les problèmes où obtenir le résultat juste est primordial” : refonte complète de codebases, coordination multi-agents complexe, sessions très longues. Ce positionnement est cohérent avec nos observations — la différence Sonnet/Opus, si elle existe sur ces cas, ne se manifeste pas sur l’analyse documentaire.

Le seuil réel : cognitif, pas quantitatif

L’expérience attendait un seuil lié au nombre de fichiers à traiter ou au nombre d’appels d’outils. Ce seuil n’existe pas dans les données.

Ce qui discrimine, c’est le type d’opération demandée.

Haiku suffit pour : extraire un fait, résumer un document, catégoriser un contenu, même sur des inputs volumineux. Ses outputs sont scolaires — complets mais sans surplus de nuance.

Sonnet est nécessaire pour : comparer des sources en cherchant des contradictions, produire une analyse critique avec contre-arguments, synthétiser avec rigueur méthodologique, concevoir un protocole qui anticipe les biais. Sur ces tâches, Haiku produit quelque chose d’exploitable, mais avec moins de profondeur — notamment sur la détection d’anomalies (80 % de couverture contre 100 % pour Sonnet/Opus).

Opus n’apporte rien de mesurable sur ces tâches. Son avantage s’exprime dans les contextes très longs, où les modèles plus légers perdent en cohérence, et pour les rôles d’orchestration dans des pipelines complexes.

Appliquer le dispatch dans un pipeline

Le dispatch cognitif ne s’improvise pas tâche par tâche. Il se structure en amont, lors de la décomposition du pipeline.

Classer avant de choisir. La séquence utile : lister toutes les sous-tâches, les classer selon la grille (extraction / analyse / coordination), puis affecter un modèle par classe. Ce n’est qu’après cette classification que les modèles sont choisis.

Une heuristique rapide : si la tâche peut être décrite par un verbe simple (lire, lister, extraire, compter, trier, catégoriser), c’est de l’extraction. Si elle nécessite deux verbes avec un lien logique (lire et déduire, comparer et recommander, détecter et expliquer), c’est de l’analyse.

Les agents de consolidation sont analytiques. Quand un agent agrège les outputs de dix agents Haiku et produit une synthèse cohérente, il fait de l’analyse — pas de l’extraction. Il doit détecter des incohérences entre sources, arbitrer des contradictions, maintenir la cohérence d’ensemble. Dispatcher un agent de consolidation sur Haiku revient à confier le raisonnement le plus complexe du pipeline au modèle le moins capable.

L’erreur fréquente : dispatcher selon l’importance, pas la nature. Une extraction de données critiques reste une extraction — elle n’a pas besoin de Sonnet parce que les données sont importantes. Choisir le modèle selon l’importance stratégique de la tâche plutôt que sa nature cognitive est le biais le plus courant dans la conception de pipelines.

Ce que la littérature dit

Ces observations rejoignent deux papiers récents.

Rabanser et al., “Towards a Science of AI Agent Reliability” (Princeton/Berkeley, arXiv 2602.16666, février 2026) : évaluation de 14 modèles sur 12 métriques de fiabilité en conditions opérationnelles réelles. Conclusion : “les gains de capacité récents n’ont produit que de petites améliorations de fiabilité.” Un modèle plus grand n’est pas mécaniquement plus fiable en production. Le papier documente aussi que les métriques de succès uniques “masquent des défaillances opérationnelles critiques”.

Ma et al., “MAESTRO” (arXiv 2601.00481, janvier 2026) : benchmark couvrant 12 architectures multi-agents différentes. Résultat principal : “l’architecture prime sur les choix de modèle et les paramètres d’outils.” Ce qui fait la différence dans un pipeline d’agents, c’est comment les agents sont organisés — pas quel modèle spécifique tourne dans chaque agent.

Trois sources, méthodes distinctes, même direction : le choix du modèle est moins déterminant qu’on ne le croit. Ce qui compte, c’est l’adéquation entre chaque tâche et le modèle qui la traite.

Limites

Nos observations portent sur des tâches d’analyse documentaire. Elles ne sont pas généralisables à : l’écriture de code complexe, la recherche web multi-étapes, la coordination multi-agents longue durée, le raisonnement mathématique.

Nos 30 runs fonctionnent avec N=1 par combinaison modèle/tâche. Il n’y a pas de réplication permettant de mesurer la variance intra-modèle. Ce sont des résultats exploratoires, pas des résultats confirmatoires. L’évaluation en aveugle par un humain reste le seul ground truth non biaisé ici.

Ce qu’il faut retenir

• La règle “grand modèle pour tâche difficile” ne se vérifie pas sur les tâches analytiques documentaires.
• La frontière utile est entre Haiku et Sonnet. Elle est déterminée par la profondeur analytique demandée, pas par le volume de données.
• Sonnet et Opus produisent des résultats indistinguables sur les tâches d’analyse documentaire — Opus est plus lent sans être meilleur.
• Dispatcher par type d’opération cognitive plutôt que par importance de la tâche réduit les temps d’exécution sans sacrifier la qualité.
• Les agents de consolidation sont des agents analytiques — les dispatcher sur Haiku est une erreur fréquente aux conséquences visibles dans la synthèse finale.

Sources

1. Rabanser, S. et al. — “Towards a Science of AI Agent Reliability”, arXiv 2602.16666, Princeton/Berkeley, février 2026. https://arxiv.org/abs/2602.16666

2. Ma, T. et al. — “MAESTRO: Multi-Agent Evaluation Suite for Testing, Reliability, and Observability”, arXiv 2601.00481, janvier 2026. https://arxiv.org/abs/2601.00481

3. Anthropic — Documentation Claude : positionnement Haiku, Sonnet, Opus. https://www.anthropic.com/claude

4. Wang et al. — “A Survey on Large Language Model based Autonomous Agents”, arXiv 2308.11432, 2023. https://arxiv.org/abs/2308.11432

5. Nos observations — 30 runs sur 10 tâches progressives (extraction simple → conception de protocole sur 5 fichiers) et 3 sujets de recherche documentaire, trois modèles en parallèle, évaluation sur couverture, hallucinations, format et exploitabilité.