Orchestration d'agents IA à grande échelle — Ce qui fonctionne vraiment en production

Tout le monde construit des agents IA. Presque personne ne les construit d’une manière qui survit au contact du trafic de production. Je le sais parce que j’ai passé la dernière année à câbler des systèmes multi-agents chez Freelancer.com — serveurs MCP, workflows agentiques, routage LLM — servant une plateforme de 80+ millions d’utilisateurs. Ce qui suit, ce sont les patterns qui fonctionnent vraiment et les erreurs que j’ai vu des équipes (y compris la mienne) commettre en chemin.

Ce n’est pas un tutoriel. C’est un article d’architecture. Si vous évaluez si vous devriez construire des systèmes agentiques ou si vous essayez de comprendre pourquoi le vôtre casse constamment, c’est pour vous.

I. L’anti-pattern de l’agent omniscient

La première chose que chaque équipe construit est un agent unique avec un prompt système massif qui essaie de tout faire. Il peut interroger des bases de données, écrire du code, envoyer des emails, chercher dans des documents et mettre à jour les outils de gestion de projet. C’est magique en démo. Ça s’effondre en production en moins d’une semaine.

Le mode de défaillance est prévisible : quand le prompt système dépasse 4 000 tokens, le modèle commence à ignorer les instructions. Les appels d’outils deviennent peu fiables. L’agent choisit le mauvais outil 15% du temps, ce qui signifie qu’une interaction sur sept produit des résultats inutilisables. Et parce que tout passe par une seule fenêtre de contexte, un échec sur l’outil d’email corrompt l’état pour la requête de base de données qui suit.

La solution est la décomposition. Au lieu d’un agent omniscient, vous construisez des agents spécialisés avec des responsabilités restreintes et un routeur léger qui dispatche vers le bon agent. C’est le même pattern qui a fait fonctionner les microservices — non pas parce que les petites choses sont inhéremment meilleures, mais parce que les frontières de défaillance comptent.

II. La couche de routage

Le routage est la partie la plus sous-estimée d’un système agentique. Le routeur décide quel agent traite une requête, et s’il se trompe, rien en aval n’a d’importance. Nous en sommes à notre troisième génération de routage.

Génération 1 : correspondance par mots-clés. Si l’utilisateur mentionne « base de données » ou « requête », router vers l’agent SQL. Ça fonctionne pour environ 60% des requêtes. Les 40% restants sont ambigus (« montre-moi les derniers chiffres » — est-ce une requête de base de données ou une demande de tableau de bord ?).

Génération 2 : classification par LLM. Un modèle rapide (Haiku) lit la requête et produit une décision de routage. On atteint ~90% de précision, mais avec 200-400ms de latence supplémentaire sur chaque requête. Correct pour les workflows asynchrones, douloureux pour les interactions temps réel.

Génération 3 : hybride. Les règles déterministes gèrent les cas évidents (commandes structurées, mentions explicites d’outils). Le classifieur LLM gère le reste ambigu. Un seuil de confiance contrôle la décision — si le classifieur est en dessous de 70% de confiance, il demande à l’utilisateur de clarifier plutôt que de deviner. On atteint ~97% de précision de routage avec une latence p50 sous 100ms pour les cas courants.

III. La gestion du contexte est le vrai problème

Le contexte est le tueur silencieux des systèmes agentiques. Chaque appel d’agent consomme de la fenêtre de contexte, et les fenêtres de contexte sont finies. À 200K tokens, on pourrait croire qu’il y a largement assez de place. En pratique, un workflow multi-étapes avec des résultats d’outils peut brûler 50K tokens en quatre tours.

L’approche naïve consiste à tout déverser dans le contexte : historique complet de la conversation, tous les résultats d’outils, tout le raisonnement intermédiaire. Ça fonctionne pour les premières interactions, puis la qualité se dégrade quand le modèle perd le fil de ce qui est pertinent. Nous avons mesuré cela — la précision sur nos benchmarks internes chute de 12% quand le contexte dépasse 40K tokens, même quand toute l’information nécessaire est présente.

Ce qui fonctionne, c’est l’élagage agressif du contexte. Chaque agent ne reçoit que ce dont il a besoin : la tâche courante, les résultats d’outils pertinents et un résumé compressé des étapes précédentes. La couche d’orchestration maintient un objet d’état structuré qui suit ce qui a été fait et ce qui reste, et chaque agent reçoit une tranche ciblée. C’est l’équivalent agentique du passage de paramètres de fonction plutôt que de variables globales.

IV. MCP : la couche d’intégration des outils

Le Model Context Protocol (MCP) est ce qui rend l’orchestration d’agents praticable à grande échelle. Avant MCP, chaque intégration d’outil était un adaptateur custom : écrire une fonction, définir le schéma, gérer les erreurs, sérialiser les résultats. Pour cinq outils, c’est gérable. Pour cinquante, c’est un cauchemar de maintenance.

MCP standardise l’interface entre agents et outils. Un serveur MCP expose des outils typés avec des descriptions, des schémas de paramètres et des réponses structurées. L’agent n’a pas besoin de code custom pour chaque outil — il lit le schéma MCP et sait comment l’appeler. Nous faisons tourner des serveurs MCP pour Phabricator (revue de code et gestion de tâches), les bases de données internes, les pipelines de déploiement et les tableaux de bord de monitoring.

Le vrai gain n’est pas le protocole en soi — c’est la composabilité. Quand vous ajoutez un nouveau serveur MCP, chaque agent du système peut immédiatement l’utiliser. Quand vous corrigez un bug dans la gestion d’erreurs d’un outil, chaque agent en bénéficie. C’est le même levier que les API REST ont donné aux applications web : une interface standard qui rend l’intégration bon marché.

V. Chaînes de fallback et gestion des pannes

Les API LLM tombent en panne. Ça arrive plus souvent qu’on ne le souhaiterait — limites de débit, timeouts, erreurs 500 transitoires, dégradation du modèle lors d’incidents chez le fournisseur. Si votre système d’agents a un point de défaillance unique à la couche LLM, votre disponibilité est plafonnée à celle du fournisseur, qui n’est pas de 100%.

Nous utilisons une chaîne de fallback : modèle principal → modèle secondaire → prompt simplifié avec un modèle plus petit → message de dégradation gracieuse. Chaque étape de la chaîne a son propre timeout et circuit breaker. Si le modèle principal (Opus) timeout après 30 secondes, on bascule sur Sonnet avec un prompt simplifié. Si Sonnet échoue aussi, on essaie Haiku avec un prompt minimisé. Si tout est en panne, l’utilisateur reçoit un message d’erreur clair, pas une requête suspendue.

Le constat clé est qu’

. La plupart des utilisateurs préfèrent une réponse de qualité Haiku immédiate plutôt qu’attendre 45 secondes une réponse Opus qui pourrait ne jamais arriver. La chaîne de fallback encode cette préférence explicitement.

VI. Observabilité : on ne peut pas corriger ce qu’on ne voit pas

Déboguer un système agentique sans observabilité, c’est comme déboguer un système distribué sans logs — théoriquement possible, pratiquement impossible. Chaque appel d’agent, chaque invocation d’outil, chaque décision de routage doit être tracé.

Nous instrumentons trois choses : les traces (le cycle de vie complet de la requête, de l’entrée utilisateur à la réponse finale, incluant chaque saut d’agent et appel d’outil), les évaluations (vérifications automatisées de la qualité des sorties d’agents, comparant avec des exemples de référence), et le suivi des coûts (utilisation de tokens par agent, par workflow, par utilisateur — car une boucle d’agent incontrôlée peut brûler 100$ de tokens avant que quiconque ne s’en aperçoive).

La métrique la plus utile que nous suivons est le taux de succès des appels d’outils par agent. Quand il passe sous 95% pour un agent, c’est généralement le signe que le prompt système a dérivé ou que l’outil sous-jacent a changé de comportement. Cette seule métrique a détecté plus de problèmes que tout le reste de notre monitoring combiné.

VII. L’architecture qui a survécu à la production

Après un an d’itérations, voici l’architecture sur laquelle nous avons convergé. Elle n’est pas élégante. Elle n’est pas innovante. Elle fonctionne.

Couche 1 : Routeur. Classifieur hybride déterministe + LLM. Reçoit l’entrée utilisateur, décide quel agent la traite. Sans état. Rapide. En cas de doute, demande une clarification.

Couche 2 : Agents spécialisés. Chaque agent a un prompt système ciblé (moins de 2 000 tokens), 3-5 outils MCP et un format de sortie spécifique. Les agents ne communiquent pas directement entre eux — ils retournent des résultats structurés à l’orchestrateur.

Couche 3 : Orchestrateur. Maintient l’état du workflow, gère les fenêtres de contexte, gère les tâches multi-étapes en chaînant les appels d’agents. Implémente la logique de retry et les chaînes de fallback. C’est le seul composant avec état.

Couche 4 : Serveurs MCP. Interfaces d’outils typées pour tous les systèmes externes. Chaque serveur est indépendamment déployable et testable. Ajouter un nouvel outil signifie déployer un nouveau serveur MCP — aucun changement sur aucun agent.

VIII. Ce que je ferais différemment

Si je repartais de zéro, trois choses changeraient :

Commencer par les évaluations, pas les fonctionnalités. Nous avons construit les agents d’abord et les évaluations ensuite. Ce qui signifie qu’on ne pouvait pas mesurer si les changements amélioraient la qualité avant des semaines après le déploiement. Construisez votre suite d’évaluation avant votre premier agent.

Versionner les prompts système comme du code. Les prompts système sont du code. Ils devraient être sous contrôle de version, revus en PR, testés contre des suites d’évaluation et déployés avec une capacité de rollback. Nous avons appris cela après qu’un « petit changement de formulation » dans un prompt système ait causé une chute de 30% de la précision d’un agent.

Budgéter les tokens comme le compute. Chaque appel d’agent a un coût. Sans budgets explicites, les workflows deviennent silencieusement coûteux. Définissez des budgets de tokens par workflow, alertez quand ils sont dépassés, et traitez le coût en tokens comme une métrique de première classe aux côtés de la latence et de la précision.

IX. En résumé

L’orchestration d’agents IA à grande échelle est fondamentalement un problème d’infrastructure, pas un problème d’IA. Les LLM sont assez puissants. Les outils existent. Ce qui manque à la plupart des équipes, c’est la discipline de traiter les systèmes agentiques avec la même rigueur qu’elles appliqueraient à n’importe quel système distribué : interfaces claires, gestion des pannes, observabilité et déploiement incrémental.

Les équipes qui réussissent ne sont pas celles avec les prompts les plus sophistiqués. Ce sont celles qui construisent l’infrastructure la plus ennuyeuse et fiable autour du modèle — puis itèrent sans relâche sur ce que le modèle fait à l’intérieur de ces garde-fous.