Le sujet le plus brûlant en architecture IT actuellement est l'architecture AI-native : des systèmes conçus autour de l'IA agentique, de l'orchestration multi-agents et de l'interopérabilité standardisée outils/agents (MCP, A2A) plutôt que de traiter les LLMs comme une fonctionnalité ajoutée après coup.
La question centrale : quelles sont les vraies configurations d'architecture AI-native pour les agents, et quand utiliser chacune ?
À haut niveau, tout système d'IA agentique a trois composantes mobiles : (1) les agents (LLMs avec des objectifs), (2) la coordination (orchestration vs chorégraphie), et (3) la connectivité (appels d'outils + protocoles agent-à-agent).
Option 1 : Agent Unique (Le Monolithe)
Un agent fait tout : analyser la requête, raisonner, appeler les outils (MCP), et répondre. C'est l'architecture par défaut pour les prototypes et les automatisations "un prompt", mais elle atteint rapidement les limites de fenêtre de contexte et est difficile à paralléliser.
Pour qui : MVPs, automatisations simples, développeurs solo qui livrent vite.
Comment ça marche : Utilisateur → Agent → Outils (MCP) → Boucle Agent → Réponse.
| Dimension | Note | Remarques |
|---|---|---|
| Simplicité | ★★★★★ | Un agent, une boucle de contrôle |
| Scalabilité | ★☆☆☆☆ | Difficile à paralléliser ; le contexte croît vite |
| Débogage | ★★★★★ | Une trace ; facile à suivre |
FlowZap Code :
User { # Utilisateur
n1: circle label:"Début"
n2: rectangle label:"Envoyer requête"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Agent.n3.handle(top) [label="Requête"]
}
Agent { # Agent IA Unique
n3: rectangle label:"Recevoir entrée"
n4: rectangle label:"Raisonner et planifier"
n5: rectangle label:"Décider appel outil"
n6: rectangle label:"Traiter résultat outil"
n7: rectangle label:"Générer réponse"
n8: circle label:"Terminé"
n3.handle(right) -> n4.handle(left)
n4.handle(right) -> n5.handle(left)
n5.handle(bottom) -> Tools.n9.handle(top) [label="Requête MCP"]
n6.handle(right) -> n7.handle(left)
n7.handle(right) -> n8.handle(left)
n7.handle(top) -> User.n2.handle(bottom) [label="Réponse"]
loop [réessayer jusqu'à objectif atteint] n4 n5 n6 n7
}
Tools { # Serveur d'Outils (MCP)
n9: rectangle label:"Recevoir appel MCP"
n10: rectangle label:"Exécuter outil"
n11: rectangle label:"Retourner résultat"
n9.handle(right) -> n10.handle(left)
n10.handle(right) -> n11.handle(left)
n11.handle(top) -> Agent.n6.handle(bottom) [label="Résultat outil"]
}
Option 2 : Pipeline Séquentiel (La Chaîne de Montage)
Un pipeline séquentiel enchaîne plusieurs agents dans un ordre fixe (analyser → enrichir → analyser → formater), ce qui est une configuration "microservices LLM" courante quand chaque étape peut être isolée. Cette structure est souvent utilisée dans le traitement de documents et les workflows de type ETL car chaque étape est testable et prévisible.
Pour qui : Workflows de contenu et documents, tâches multi-étapes déterministes.
| Dimension | Note | Remarques |
|---|---|---|
| Simplicité | ★★★★☆ | Linéaire et explicite |
| Scalabilité | ★★☆☆☆ | Goulot d'étranglement sur l'étape la plus lente |
| Débogage | ★★★★★ | Inspection étape par étape |
FlowZap Code :
Trigger { # Déclencheur
n1: circle label:"Début"
n2: rectangle label:"Requête entrante"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Pipeline.n3.handle(top) [label="Entrée"]
}
Pipeline { # Pipeline Séquentiel
n3: rectangle label:"Agent A: Analyser entrée"
n4: rectangle label:"Agent B: Enrichir données"
n5: rectangle label:"Agent C: Analyser"
n6: rectangle label:"Agent D: Formater sortie"
n7: circle label:"Terminé"
n3.handle(right) -> n4.handle(left)
n4.handle(right) -> n5.handle(left)
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left)
n6.handle(top) -> Trigger.n2.handle(bottom) [label="Sortie finale"]
}
Option 3 : Orchestrateur–Travailleur (Le Chef d'Orchestre)
C'est l'architecture "orchestration d'agents" la plus courante : un agent orchestrateur décompose un objectif en sous-tâches, les distribue à des travailleurs spécialisés, puis synthétise une réponse finale. C'est puissant, mais l'orchestrateur peut devenir un goulot d'étranglement à mesure que le nombre de travailleurs augmente, c'est pourquoi des frameworks comme LangGraph se concentrent sur le routage/état explicite pour garder cela gérable.
Pour qui : Produits d'IA agentique généralistes (support, recherche, ops) où un "cerveau" délègue aux spécialistes.
| Dimension | Note | Remarques |
|---|---|---|
| Simplicité | ★★★☆☆ | La logique de routage croît avec le temps |
| Scalabilité | ★★★☆☆ | Risque de goulot d'étranglement orchestrateur |
| Débogage | ★★★★☆ | Les décisions centralisées facilitent le traçage |
FlowZap Code :
User { # Utilisateur
n1: circle label:"Début"
n2: rectangle label:"Soumettre tâche complexe"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Orchestrator.n3.handle(top) [label="Tâche"]
}
Orchestrator { # Agent Orchestrateur
n3: rectangle label:"Recevoir tâche"
n4: rectangle label:"Décomposer en sous-tâches"
n5: rectangle label:"Distribuer sous-tâches"
n6: rectangle label:"Collecter résultats"
n7: rectangle label:"Synthétiser réponse finale"
n8: circle label:"Terminé"
n3.handle(right) -> n4.handle(left)
n4.handle(right) -> n5.handle(left)
n5.handle(bottom) -> Research.n9.handle(top) [label="Sous-tâche recherche"]
n5.handle(bottom) -> Code.n11.handle(top) [label="Sous-tâche code"]
n5.handle(bottom) -> Review.n13.handle(top) [label="Sous-tâche revue"]
n6.handle(right) -> n7.handle(left)
n7.handle(right) -> n8.handle(left)
n7.handle(top) -> User.n2.handle(bottom) [label="Réponse"]
}
Research { # Agent Recherche
n9: rectangle label:"Chercher sources"
n10: rectangle label:"Résumer trouvailles"
n9.handle(right) -> n10.handle(left)
n10.handle(top) -> Orchestrator.n6.handle(bottom) [label="Résultat recherche"]
}
Code { # Agent Code
n11: rectangle label:"Générer code"
n12: rectangle label:"Exécuter tests"
n11.handle(right) -> n12.handle(left)
n12.handle(top) -> Orchestrator.n6.handle(bottom) [label="Résultat code"]
}
Review { # Agent Revue
n13: rectangle label:"Évaluer qualité"
n14: rectangle label:"Signaler problèmes"
n13.handle(right) -> n14.handle(left)
n14.handle(top) -> Orchestrator.n6.handle(bottom) [label="Résultat revue"]
}
Option 4 : Hiérarchique (L'Organigramme)
Les systèmes multi-agents hiérarchiques scalent l'orchestration en empilant superviseurs et chefs d'équipe (un arbre), ce qui reflète les structures organisationnelles d'entreprise et aide à partitionner le contexte. C'est communément discuté comme l'"architecture d'IA agentique de niveau entreprise" quand un seul orchestrateur ne peut pas gérer tous les travailleurs directement.
Pour qui : Grandes entreprises, workflows multi-domaines, configurations "main-d'œuvre IA" où les tâches se divisent naturellement en départements (finance/juridique/ingénierie).
| Dimension | Note | Remarques |
|---|---|---|
| Simplicité | ★★☆☆☆ | Plus de couches = plus de coordination |
| Scalabilité | ★★★★★ | Les équipes scalent indépendamment |
| Débogage | ★★★☆☆ | Le traçage traverse plusieurs sauts |
FlowZap Code :
User { # Utilisateur
n1: circle label:"Début"
n2: rectangle label:"Soumettre requête entreprise"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Supervisor.n3.handle(top) [label="Objectif"]
}
Supervisor { # Superviseur Principal
n3: rectangle label:"Décomposer objectif"
n4: rectangle label:"Déléguer aux chefs d'équipe"
n5: rectangle label:"Agréger sortie finale"
n6: circle label:"Terminé"
n3.handle(right) -> n4.handle(left)
n4.handle(bottom) -> LeadA.n7.handle(top) [label="Sous-objectif A"]
n4.handle(bottom) -> LeadB.n10.handle(top) [label="Sous-objectif B"]
n5.handle(right) -> n6.handle(left)
n5.handle(top) -> User.n2.handle(bottom) [label="Rapport final"]
}
LeadA { # Chef d'Équipe A
n7: rectangle label:"Planifier sous-tâches pour A"
n8: rectangle label:"Distribuer aux travailleurs"
n9: rectangle label:"Consolider résultats A"
n7.handle(right) -> n8.handle(left)
n8.handle(bottom) -> Workers.n13.handle(top) [label="Tâche A1"]
n8.handle(bottom) -> Workers.n14.handle(top) [label="Tâche A2"]
n9.handle(top) -> Supervisor.n5.handle(bottom) [label="Résultat A"]
}
LeadB { # Chef d'Équipe B
n10: rectangle label:"Planifier sous-tâches pour B"
n11: rectangle label:"Distribuer aux travailleurs"
n12: rectangle label:"Consolider résultats B"
n10.handle(right) -> n11.handle(left)
n11.handle(bottom) -> Workers.n15.handle(top) [label="Tâche B1"]
n11.handle(bottom) -> Workers.n16.handle(top) [label="Tâche B2"]
n12.handle(top) -> Supervisor.n5.handle(bottom) [label="Résultat B"]
}
Workers { # Agents Travailleurs
n13: rectangle label:"Travailleur A1 exécute"
n14: rectangle label:"Travailleur A2 exécute"
n15: rectangle label:"Travailleur B1 exécute"
n16: rectangle label:"Travailleur B2 exécute"
n13.handle(top) -> LeadA.n9.handle(bottom) [label="A1 terminé"]
n14.handle(top) -> LeadA.n9.handle(bottom) [label="A2 terminé"]
n15.handle(top) -> LeadB.n12.handle(bottom) [label="B1 terminé"]
n16.handle(top) -> LeadB.n12.handle(bottom) [label="B2 terminé"]
}
Option 5 : Fan-Out Parallèle (Le Map-Reduce)
Le fan-out parallèle exécute plusieurs agents simultanément sur des vérifications indépendantes (style, sécurité, performance) puis fusionne les résultats, ce qui est une approche standard de conception multi-agents pour le débit. Cela s'applique bien au CI/CD, à la réponse aux incidents et à la recherche, mais la réconciliation (fan-in) devient la partie subtile.
Pour qui : Bots de revue de code, recherche parallèle, pipelines d'évaluation multi-signaux.
| Dimension | Note | Remarques |
|---|---|---|
| Simplicité | ★★★☆☆ | La logique fan-in est la partie délicate |
| Scalabilité | ★★★★★ | Parallélisme embarrassant |
| Débogage | ★★★★☆ | Comparer chaque sortie d'agent |
FlowZap Code :
Trigger { # Déclencheur
n1: circle label:"Début"
n2: rectangle label:"PR soumise pour revue"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Coordinator.n3.handle(top) [label="Payload PR"]
}
Coordinator { # Agent Coordinateur
n3: rectangle label:"Fan out vers réviseurs"
n4: rectangle label:"Collecter toutes les revues"
n5: diamond label:"Tout validé?"
n6: rectangle label:"Approuver PR"
n7: rectangle label:"Demander modifications"
n8: circle label:"Terminé"
n3.handle(bottom) -> Reviewers.n9.handle(top) [label="Vérif style"]
n3.handle(bottom) -> Reviewers.n10.handle(top) [label="Audit sécurité"]
n3.handle(bottom) -> Reviewers.n11.handle(top) [label="Analyse perf"]
n4.handle(right) -> n5.handle(left)
n5.handle(right) -> n6.handle(left) [label="Oui"]
n5.handle(bottom) -> n7.handle(top) [label="Non"]
n6.handle(right) -> n8.handle(left)
}
Reviewers { # Agents de Revue Parallèles
n9: rectangle label:"Agent Style"
n10: rectangle label:"Agent Sécurité"
n11: rectangle label:"Agent Performance"
n9.handle(top) -> Coordinator.n4.handle(bottom) [label="Rapport style"]
n10.handle(top) -> Coordinator.n4.handle(bottom) [label="Rapport sécurité"]
n11.handle(top) -> Coordinator.n4.handle(bottom) [label="Rapport perf"]
}
Option 6 : Event-Driven (Maillage d'Agents Kafka-First)
L'IA agentique event-driven remplace l'orchestrateur central par des topics Kafka/PubSub : les agents s'abonnent, réagissent et publient de nouveaux événements, ce qui aligne les systèmes multi-agents avec la chorégraphie microservices éprouvée. Confluent décrit les architectures multi-agents event-driven comme un moyen pratique de scaler la collaboration d'agents en utilisant les concepts pub/sub et event streaming.
Pour qui : Systèmes temps réel, haut débit, configurations "maillage d'agents", organisations déjà standardisées sur Kafka.
| Dimension | Note | Remarques |
|---|---|---|
| Simplicité | ★★☆☆☆ | Le comportement global émerge des événements |
| Scalabilité | ★★★★★ | Scaler agents + partitions indépendamment |
| Débogage | ★★☆☆☆ | Nécessite traçage distribué + forte observabilité |
FlowZap Code :
Source { # Sources d'Événements
n1: circle label:"Début"
n2: rectangle label:"Événement action utilisateur"
n3: rectangle label:"Événement alerte système"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Broker.n4.handle(top) [label="Publier événement"]
n3.handle(bottom) -> Broker.n4.handle(top) [label="Publier événement"]
}
Broker { # Broker d'Événements (Kafka / Pub-Sub)
n4: rectangle label:"Bus d'événements reçoit"
n5: rectangle label:"Router vers abonnés"
n4.handle(right) -> n5.handle(left)
n5.handle(bottom) -> Orders.n6.handle(top) [label="topic: commandes"]
n5.handle(bottom) -> Alerts.n8.handle(top) [label="topic: alertes"]
n5.handle(bottom) -> Analytics.n10.handle(top) [label="topic: analytics"]
}
Orders { # Agent Traitement Commandes
n6: rectangle label:"Parser événement commande"
n7: rectangle label:"Exécuter fulfillment"
n6.handle(right) -> n7.handle(left)
n7.handle(bottom) -> Broker.n4.handle(top) [label="Publier: commande.terminée"]
}
Alerts { # Agent Triage Alertes
n8: rectangle label:"Classifier sévérité"
n9: rectangle label:"Router vers astreinte ou auto-résoudre"
n8.handle(right) -> n9.handle(left)
n9.handle(bottom) -> Broker.n4.handle(top) [label="Publier: alerte.résolue"]
}
Analytics { # Agent Analytics
n10: rectangle label:"Agréger métriques"
n11: rectangle label:"Mettre à jour dashboard"
n12: circle label:"Stocké"
n10.handle(right) -> n11.handle(left)
n11.handle(right) -> n12.handle(left)
}
Option 7 : Compétitif / Générateur-Critique (Mode Tournoi)
Plusieurs générateurs produisent des réponses indépendantes, puis un agent évaluateur note et sélectionne la meilleure sortie ; c'est une approche courante pour améliorer la qualité et réduire la fragilité d'un modèle unique. C'est plus coûteux (plusieurs appels LLM), mais souvent rentable quand la correction ou la créativité est plus importante que la latence.
Pour qui : Génération de contenu, raisonnement à enjeux élevés, flux de revue politique/sécurité, configurations style "débat IA".
| Dimension | Note | Remarques |
|---|---|---|
| Simplicité | ★★★☆☆ | La logique d'évaluation n'est pas triviale |
| Scalabilité | ★★★★☆ | Les générateurs se parallélisent |
| Débogage | ★★★★★ | Comparaison côte à côte |
FlowZap Code :
Input { # Entrée
n1: circle label:"Début"
n2: rectangle label:"Brief créatif soumis"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Generators.n3.handle(top) [label="Brief"]
n2.handle(bottom) -> Generators.n4.handle(top) [label="Brief"]
n2.handle(bottom) -> Generators.n5.handle(top) [label="Brief"]
}
Generators { # Agents Générateurs
n3: rectangle label:"Agent A: Brouillon option 1"
n4: rectangle label:"Agent B: Brouillon option 2"
n5: rectangle label:"Agent C: Brouillon option 3"
n3.handle(bottom) -> Evaluator.n6.handle(top) [label="Option 1"]
n4.handle(bottom) -> Evaluator.n6.handle(top) [label="Option 2"]
n5.handle(bottom) -> Evaluator.n6.handle(top) [label="Option 3"]
}
Evaluator { # Agent Évaluateur
n6: rectangle label:"Noter toutes les options"
n7: diamond label:"Seuil qualité atteint?"
n8: rectangle label:"Sélectionner meilleure sortie"
n9: circle label:"Terminé"
n6.handle(right) -> n7.handle(left)
n7.handle(right) -> n8.handle(left) [label="Oui"]
n7.handle(top) -> Generators.n3.handle(bottom) [label="Non - Affiner"]
n8.handle(right) -> n9.handle(left)
loop [affiner jusqu'au seuil qualité] n3 n4 n5 n6 n7
}
Comment les Agents se Connectent : MCP vs A2A (La Couche d'Interopérabilité)
En architecture AI-native, la couche protocole compte car elle détermine si les agents sont des "jardins clos" ou des composants interopérables.
- MCP (Model Context Protocol) : standardise comment les agents se connectent aux outils et sources de données (agent → outils). C'est largement présenté comme un connecteur type USB-C pour les intégrations IA.
- A2A (Agent-to-Agent Protocol) : standardise comment les agents découvrent et délèguent à d'autres agents (agent → agent), y compris les configurations cross-vendor.
Beaucoup de systèmes réels utilisent les deux : MCP pour les appels d'outils, et A2A pour la délégation inter-agents (surtout dans les environnements entreprise).
Frameworks et Marques à Mentionner
Une grande partie de la conversation "architecture AI-native" est actuellement médiée par des frameworks et vendors.
| Framework / Vendor | Connu Pour | Où Ça S'Applique |
|---|---|---|
| LangGraph / LangChain | Orchestration d'agents basée graphe/état | Options 3–5 ; workflows hybrides |
| CrewAI | Équipes multi-agents basées sur les rôles | Option 3 (orchestrateur-travailleur) |
| AutoGen | Collaboration multi-agents par conversation | Option 7 et collaboration pair |
| Google ADK | Blocs de construction d'agents structurés | Option 4 (hiérarchique) |
| Kafka / Confluent | Event streaming & pub/sub | Option 6 (maillage event-driven) |
Choisir Votre Architecture AI-Native (Règle Rapide)
- Livrer vite : Option 1
- Étapes déterministes : Option 2
- Choix production par défaut : Option 3
- "Main-d'œuvre IA" entreprise : Option 4
- Débit maximum : Option 5
- Organisations Kafka-first : Option 6
- Qualité maximale : Option 7