Architecture des systèmes IA — Maîtrise2 / 9
Agent unique vs. multi-agent — Choisir une topologie
Le multi-agent est à la mode et généralement prématuré. Voici comment décider honnêtement — et pourquoi la plupart des produits doivent commencer avec un seul agent bien équipé.
« Multi-agent » sonne avancé, donc les équipes s'y lancent tôt. Généralement c'est une erreur. Un agent unique avec de bons outils est plus simple, moins cher, et plus facile à déboguer — commencez là et gagnez votre chemin vers plus.
Quand un agent gagne
Si la tâche est surtout séquentielle et rentre dans un contexte, un agent unique avec les bons outils surpasse un essaim. Moins de pièces mobiles, une seule trace à déboguer, pas de surcharge de coordination. La plupart des produits y restent plus longtemps qu'ils le pensent.
Les vraies raisons de passer au multi-agent
- Parallélisme — des sous-tâches véritablement indépendantes (N fichiers, N sources) s'exécutent concurremment pour des gains de temps réel.
- Isolation du contexte — une sous-tâche lourde et intensive en lecture ne doit pas polluer le contexte de l'agent principal.
- Spécialisation — un reviewer ou un chercheur bien mis en prompt se comporte plus régulièrement qu'un généraliste jonglant avec plusieurs rôles.
Si aucune de ces raisons n'existe, le multi-agent n'est que de la surcharge qui porte un habit tendance.
Le coût de coordination
Vous avez décidé que vous aviez besoin de coordination ? Ensuite : les motifs d'orchestration — pipelines, routeurs, et essaims.
Série — Architecture des systèmes IA — Maîtrise
- Partie 01Architecting AI Products — First PrinciplesAI systems fail differently from normal software: they're non-deterministic, costly per call, and hard to test. The architecture has to account for all three.
- Partie 02Agent unique vs. multi-agent — Choisir une topologie — vous êtes iciLe multi-agent est à la mode et généralement prématuré. Voici comment décider honnêtement — et pourquoi la plupart des produits doivent commencer avec un seul agent bien équipé.
- Partie 03Modèles d'orchestration — Pipelines, Routeurs, EssaimsUne fois que vous avez plusieurs étapes ou agents, leur interconnexion détermine le coût, la latence et la fiabilité. Quatre modèles couvrent presque tout.
- Partie 04Architecture du contexte et de la mémoireLa fenêtre de contexte est votre ressource la plus chère et la plus convoitée. Ce que vous y mettez — et ce que vous mémorisez entre les appels — est une décision architecturale.
- Partie 05Les pipelines d'évaluation comme infrastructureDans les systèmes d'IA, l'évaluation n'est pas un QA qu'on fait à la fin — c'est une infrastructure qu'on construit d'abord. Sans elle, chaque changement est une prière.
- Partie 06Cost Engineering — Token Budgets That HoldAn AI feature that delights at 100 users can bankrupt you at 100,000. Cost is an architectural constraint, designed in — not discovered on the invoice.
- Partie 07Latence et débit à l'échelleL'inférence est lente et imprévisible. Le streaming, le parallélisme et la limite asynchrone sont ce qui maintient un produit IA réactif sous charge réelle.
- Partie 08Fiabilité — Retries, Fallbacks, GuardrailsLes modèles retournent des résultats mal formés, les fournisseurs s'arrêtent, et la qualité des outputs dérive. Un système d'IA fiable s'attend aux trois et continue de fonctionner malgré tout.
- Partie 09The Reference Architecture in ProductionTopology, orchestration, memory, eval, cost, latency and reliability — composed into one blueprint for an AI system that survives real users.