L’idée séduit : faire collaborer plusieurs agents IA spécialisés (un chercheur, un rédacteur, un vérificateur, un correcteur). Sur le papier, on gagne en qualité. Dans la réalité, on se retrouve avec une facture API multipliée par 5 sans gain proportionnel. Quatre patterns d’orchestration qui marchent.
Pattern 1 : Router + spécialistes
Un petit modèle (Haiku ou GPT-mini) classifie la requête, puis route vers le spécialiste pertinent. Le routing coûte ~1% du coût total mais évite d’envoyer une question simple à un Opus. Gain typique : 40 à 60% du budget.
Pattern 2 : Chaîne en cascade avec early exit
L’agent 1 produit, l’agent 2 vérifie. Si l’agent 2 valide, on s’arrête. Sinon, on enchaîne avec un troisième. La majorité des cas s’arrêtent après 2 agents, le coût moyen reste maîtrisé.
Pattern 3 : Map-reduce
Pour traiter un gros corpus (100 documents), on lance N agents en parallèle (un par doc) avec un modèle compact, puis on agrège avec un agent plus puissant. C’est 5 à 10× moins cher qu’envoyer le corpus complet à un seul gros modèle.
Pattern 4 : Caching agressif des prompts
Les prompts systèmes longs et les contextes répétés se cachent. Une fois mis en place, le caching divise par 2 à 4 la facture sans aucun changement applicatif. C’est le levier le plus sous-utilisé.
Le réflexe « monitoring » avant tout
Avant d’optimiser, mesurez. Sur nos missions, on installe systématiquement un dashboard simple (coût par tenant, par feature, par jour). 80% des optimisations viennent du repérage d’anomalies (un agent qui boucle, un prompt mal compressé), pas d’une refonte d’architecture.
