Agent simple, outillé ou multi-agent : la complexité doit servir le besoin, pas l'inverse
Tout le monde parle d'agents IA, mais derrière ce terme se cachent trois architectures très différentes en termes de capacités, de complexité et de coût. Un chatbot FAQ n'a pas besoin d'un système multi-agent orchestré par un superviseur. Inversement, un pipeline de traitement end-to-end (analyse → décision → action) ne fonctionne pas avec un simple prompt. Le piège classique : sur-architecturer un besoin simple ou sous-dimensionner un besoin complexe.
Le problème
Le choix d'architecture est la première décision technique d'un projet agent IA — et la plus sous-estimée :
Le sur-engineering tue les projets
Influencées par les démos spectaculaires de systèmes multi-agents, beaucoup d'équipes construisent une architecture complexe pour un besoin simple. Un chatbot FAQ qui nécessite 5 agents coordonnés, un superviseur et un module de mémoire est 10 fois plus long à développer, 5 fois plus cher à maintenir et 3 fois plus lent à répondre qu'un agent simple bien conçu. Le résultat : un projet de 3 mois qui dure 9 mois et n'est jamais mis en production.
Le sous-dimensionnement frustre les utilisateurs
À l'inverse, un agent simple (prompt + RAG) atteint vite ses limites quand le besoin demande des actions concrètes : interroger une API, mettre à jour une base de données, envoyer un email. L'utilisateur demande « Annule ma commande 12345 » et l'agent répond « Veuillez contacter le support au 01 23 45 67 89 ». La frustration est proportionnelle à l'attente créée par le terme « agent IA » dans la communication interne.
L'absence de critères de choix objectifs
Il n'existe pas de guide pratique qui dit « pour tel besoin, utilisez telle architecture ». Les tutoriels montrent des démos impressionnantes mais ne discutent pas des trade-offs. Les décideurs et les développeurs manquent d'un framework de décision simple pour choisir l'architecture adaptée à chaque cas d'usage, avec les implications en coût, délai et maintenance.
La solution IA
Voici les trois architectures, du plus simple au plus complexe, avec leur zone d'application optimale :
Architecture 1 : Agent simple (prompt + RAG)
Le LLM reçoit un prompt système, le contexte de la conversation et les documents pertinents récupérés par RAG. Il génère une réponse textuelle. Pas d'outils, pas d'actions, pas de boucle de décision. C'est l'architecture d'un chatbot FAQ, d'un assistant de rédaction, d'un outil de résumé. Elle couvre 60 à 70 % des cas d'usage courants. Avantage : développement en 1 à 2 semaines, maintenance minimale, latence faible (2-4 s). Limitation : l'agent ne peut que répondre, pas agir.
Architecture 2 : Agent outillé (tool-use)
Le LLM dispose d'une liste d'outils (fonctions) qu'il peut appeler : rechercher en base de données, appeler une API, envoyer un email, créer un ticket. À chaque tour, le LLM décide s'il doit appeler un outil ou répondre directement. C'est l'architecture d'un agent de support (consulter le CRM, créer un ticket), d'un assistant commercial (enrichir une fiche, planifier un rendez-vous) ou d'un agent d'automatisation. Développement : 3-6 semaines. Complexité moyenne mais puissance décuplée.
Architecture 3 : Système multi-agent
Plusieurs agents spécialisés collaborent sous la coordination d'un agent superviseur (orchestrateur). Chaque agent a son propre prompt, ses outils et son périmètre. Exemples : un agent d'analyse + un agent de décision + un agent d'exécution. Ou un agent par domaine métier (comptabilité, RH, juridique) avec un routeur. C'est l'architecture des workflows complexes end-to-end : traitement de dossiers, pipelines de validation, processus multi-étapes. Développement : 8-16 semaines. Maintenance significative.
Mise en oeuvre
L'arbre de décision pour choisir et construire la bonne architecture :
Étape 1 — Qualifier le besoin avec 3 questions (jour 1)
Posez trois questions sur votre cas d'usage : (1) L'agent doit-il exécuter des actions (API, base de données, envoi) ou seulement répondre ? Si seulement répondre → agent simple. (2) Combien de domaines ou étapes distinctes le processus comporte-t-il ? Si 1-2 → agent outillé. Si 3+ avec des décisions entre étapes → multi-agent. (3) Quel est le volume et la criticité ? Forte criticité + fort volume → investir dans le multi-agent se justifie. Faible volume → rester simple.
Étape 2 — Prototyper en commençant simple (semaines 1-3)
Même si vous visez un multi-agent, commencez toujours par un prototype d'agent simple ou outillé. Cela valide le cas d'usage, teste la qualité du LLM sur votre domaine et fournit une baseline de performance. 40 % des projets qui prévoyaient un multi-agent découvrent qu'un agent outillé suffit. Utilisez LangGraph ou le SDK natif du fournisseur LLM. Testez sur 50 cas réels et mesurez la satisfaction utilisateur.
Étape 3 — Migrer vers le multi-agent si nécessaire (semaines 4-12)
Si le prototype outillé montre ses limites (prompt trop long, outils trop nombreux, erreurs de routage), décomposez en agents spécialisés. Définissez clairement le rôle, le périmètre et les outils de chaque agent. Implémentez l'orchestrateur (LangGraph StateGraph, CrewAI ou custom). Testez chaque agent individuellement puis le système complet. Mettez en place le monitoring pour suivre les interactions inter-agents et détecter les boucles.
Résultats
Questions fréquentes
Quelle architecture d'agent choisir pour commencer ?
Commencez toujours par l'agent simple (prompt + RAG). Il couvre 60 à 70 % des cas d'usage courants (chatbot FAQ, assistant interne, résumé de documents) avec un coût et une complexité minimaux. Passez à l'agent outillé uniquement quand vous avez besoin d'actions concrètes (appeler une API, écrire en base, envoyer un email). Le multi-agent est réservé aux workflows complexes avec plusieurs étapes et décisions.
Un système multi-agent est-il plus intelligent qu'un agent unique ?
Pas nécessairement. Un système multi-agent est mieux organisé, pas plus intelligent. Chaque agent individuel utilise le même type de LLM. L'avantage est la spécialisation : chaque agent a un prompt et des outils optimisés pour sa tâche. Cela réduit les erreurs dues à la surcharge de contexte et permet une meilleure traçabilité. Mais la coordination entre agents ajoute de la complexité et de la latence.
Quels frameworks utiliser pour construire un agent outillé ?
Les principaux frameworks en 2025-2026 : LangGraph (flexible, événementiel, bon pour les workflows complexes), CrewAI (simple, orienté multi-agent), Autogen (Microsoft, collaboration multi-agent), et les SDK natifs des fournisseurs (Anthropic tool-use, OpenAI function-calling). Pour une PME, LangGraph ou le SDK natif Anthropic/OpenAI suffisent pour 90 % des cas.
Pour les profils tech
Comparatif des 3 architectures d'agents IA
| Critère | Agent simple (prompt + RAG) | Agent outillé (tool-use) | Multi-agent |
|---|---|---|---|
| Capacité d'action | Texte uniquement | API, BDD, email | Workflow complet |
| Temps de développement | 1-2 semaines | 3-6 semaines | 8-16 semaines |
| Latence (P50) | 2-4 s | 4-8 s | 10-30 s |
| Coût par interaction | 0,01-0,03 € | 0,03-0,10 € | 0,15-0,50 € |
| Maintenance | Minimale | Moyenne | Significative |
| Cas d'usage type | FAQ, résumé, rédaction | Support, CRM, extraction | Workflows E2E, pipelines |
| Framework recommandé | SDK natif + RAG | LangGraph, SDK natif | LangGraph, CrewAI |