Architecture agentique : composants, modèles et méthode de conception

Un assistant qui explique comment modifier une commande et un agent qui effectue réellement cette modification peuvent s’appuyer sur le même modèle de langage. Pourtant, leurs responsabilités et leurs risques ne sont pas comparables. La différence tient à l’architecture qui organise leur fonctionnement. 

Pour intervenir sur la commande, le système doit identifier le client, retrouver le bon dossier, vérifier que l’expédition n’a pas commencé, recueillir une confirmation, appeler l’outil métier approprié puis contrôler que la modification a bien été enregistrée. Il doit également savoir quoi faire lorsqu’une information manque, qu’une règle bloque l’opération ou que la demande nécessite l’intervention d’un conseiller. 

Concevoir une architecture agentique, c’est structurer cette chaîne de décisions, d’actions et de contrôles. Cela implique de définir les données accessibles, les outils utilisables, la mémoire nécessaire, les limites de l’agent et les conditions de transfert vers un humain. Ces choix déterminent si le système restera une démonstration convaincante ou pourra fonctionner de manière fiable en entreprise.

Qu’est-ce qu’une architecture agentique ?

Lorsqu’un modèle reçoit un texte et produit une réponse, le parcours reste simple : entrée, génération, sortie. Une architecture agentique ajoute une boucle dans laquelle le système peut :

1. Observer la situation
2. Sélectionner une action
3. Utiliser un outil
4. Analyser le résultat
5. Décider de l’étape suivante.

Du modèle de langage au système capable d’agir

Un agent IA élémentaire repose sur trois composants : un modèle, des outils et des instructions qui définissent son comportement. Son moteur d’exécution le laisse ensuite travailler jusqu’à l’obtention d’un résultat ou jusqu’à l’activation d’une condition d’arrêt[1].

Prenons une demande adressée à un service client : « Je souhaite modifier l’adresse de livraison de ma commande. »

Un assistant génératif peut expliquer la procédure. Un agent peut aller plus loin :

1. identifier le client ;
2. retrouver la commande concernée ;
3. vérifier si elle a déjà été expédiée ;
4. demander une confirmation si la modification reste possible ;
5. appeler l’API de gestion des commandes ;
6. contrôler le résultat ;
7. informer le client ou transférer le dossier.

L’autonomie ne vient pas uniquement du modèle. Elle vient de la possibilité de choisir et d’enchaîner des actions dans un cadre défini.

Architecture agentique, RAG, workflow IA et système multi-agents : quelles différences ?

Ces notions interviennent souvent dans un même projet, mais elles ne désignent pas la même chose.

Le RAG peut alimenter un agent, mais il ne rend pas à lui seul une application agentique. De même, un workflow IA peut comporter plusieurs appels de modèles tout en conservant un chemin entièrement programmé.

Une distinction utile consiste à séparer les workflows, dont le parcours est défini dans le code, des agents, qui choisissent dynamiquement leur processus et l’usage de leurs outils[2]. Cette frontière n’est pas toujours absolue : les architectures les plus fiables combinent souvent des étapes déterministes avec quelques décisions confiées au modèle.

Enfin, une architecture agentique n’est pas nécessairement multi-agents. Un agent unique correctement équipé reste souvent plus simple à tester, à maintenir et à superviser.

Quels sont les composants d’une architecture agentique ?

Une demande de remboursement ne peut pas être traitée de façon fiable avec un modèle et un prompt isolés. Le système doit connaître la politique commerciale, retrouver la transaction, vérifier les droits de l’utilisateur, demander une validation et conserver la trace de chaque étape.

Une architecture d’entreprise peut ainsi être représentée par sept couches :

Canal → Agent et orchestrateur → Contexte → Modèle → Outils → Contrôles → Résultat

La sécurité, l’observabilité et la gouvernance traversent l’ensemble de ces couches. Les architectures de référence destinées aux entreprises les traitent d’ailleurs comme des préoccupations transversales plutôt que comme des modules ajoutés en fin de projet[3].

1. Le canal et la perception de la demande

Le point d’entrée peut être un chat, un appel téléphonique, un e-mail, une application interne ou un événement produit par un logiciel métier.

Cette couche transforme le signal reçu en informations exploitables : transcription d’un appel, identification de la langue, pièces jointes, identité de l’utilisateur ou métadonnées d’un événement. Elle doit aussi rejeter les formats invalides et détecter les entrées qui nécessitent un traitement particulier.

Dans un agent vocal, par exemple, une erreur de transcription sur un numéro de commande peut contaminer tout le processus. L’architecture doit donc prévoir une confirmation explicite avant toute action fondée sur une donnée critique.

2. Le modèle, les objectifs et les instructions

Le modèle interprète la situation et choisit la prochaine étape. Ses instructions précisent son rôle, son objectif, ses limites, les règles métier et les circonstances dans lesquelles il doit solliciter un humain.

Un bon objectif doit être vérifiable. « Aider le client » est trop vague. « Identifier la commande, déterminer si son adresse peut encore être modifiée et exécuter la modification après confirmation » offre une condition de réussite plus exploitable.

Le modèle le plus puissant n’est pas nécessairement requis à chaque étape (n’oublions pas la question des coûts). Une architecture peut réserver un modèle avancé à la planification ou aux cas ambigus et employer un modèle plus léger pour classer une intention, extraire une référence ou formater une réponse.

3. Le contexte, le RAG, la mémoire et leur importance

Le contexte immédiat regroupe les informations nécessaires à l’étape en cours : demande du client, résultats d’outils, règles applicables et état du dossier.

Le RAG apporte des connaissances issues de documents externes au modèle : catalogue, procédures internes, conditions contractuelles ou base d’aide. La mémoire conserve quant à elle certains éléments au-delà d’un appel unique.

Trois niveaux doivent être distingués :

• la mémoire de travail, limitée à l’exécution actuelle ;
• la mémoire conversationnelle, utilisée pendant plusieurs échanges ;
• la mémoire persistante, enregistrée pour une utilisation future.

Tout conserver augmente les coûts, le bruit contextuel et le risque d’exposer des données inutiles. Une architecture robuste définit ce qui peut être mémorisé, pendant combien de temps et pour quelle finalité. La mémoire n’équivaut pas non plus à un apprentissage automatique : enregistrer une préférence client ne signifie pas que le modèle s’est amélioré.

4. Les outils, API et connecteurs

Un modèle de langage ne peut pas, à lui seul, consulter un CRM, modifier un rendez-vous ou envoyer un e-mail. Pour intervenir dans un logiciel, l’agent doit utiliser un outil mis à sa disposition par l’architecture.

Dans ce contexte, trois notions peuvent être distinguées :

• L’outil correspond à une action que l’agent peut demander, par exemple rechercher un client, consulter une commande ou créer un ticket.
• L’API est l’interface technique qui transmet cette demande au logiciel concerné.
• Le connecteur facilite l’intégration entre les deux systèmes en prenant notamment en charge les formats de données et l’authentification.

Pour une demande de modification de rendez-vous, l’agent pourrait ainsi disposer de trois outils : consulter le dossier du client, rechercher les créneaux disponibles et enregistrer le nouveau rendez-vous. Il ne devrait pas recevoir un accès général au logiciel de planification si ces trois fonctions suffisent.

Chaque outil doit donc être encadré par des règles précises :

• quelles informations l’agent doit fournir ;
• quelles données il peut consulter ou modifier ;
• quelle identité et quels droits sont utilisés ;
• dans quels cas une confirmation humaine est obligatoire ;
• comment l’outil signale une réussite ou une erreur.

L’architecture doit également éviter qu’une même action soit exécutée deux fois. Si l’agent relance une requête après un délai de réponse, le système doit vérifier que le rendez-vous ou le remboursement n’a pas déjà été enregistré avant de recommencer l’opération.

Le Model Context Protocol, ou MCP, standardise la manière dont une application présente des ressources et des outils à un système d’IA. Son architecture permet notamment de séparer les différents serveurs et de limiter le contexte transmis à chacun[4].

MCP facilite donc la connexion entre un agent et des services externes. En revanche, il ne décide pas des actions autorisées ni des règles métier à appliquer.

Ces contrôles restent à la charge de l’entreprise : un agent autorisé à consulter une fiche client ne doit pas pouvoir la modifier automatiquement, et un outil de remboursement ne doit être accessible que dans les situations prévues.

5. L’orchestrateur et la gestion de l’état

L’orchestrateur pilote la boucle d’exécution. Il transmet les messages, appelle les modèles, exécute les outils et vérifie si le travail doit continuer.

L’état permet de savoir où en est la tâche : informations déjà collectées, décisions prises, validations obtenues, erreurs rencontrées et prochaine étape attendue. Pour un processus long, cet état doit être conservé dans un stockage durable plutôt que dans le seul historique de conversation.

Les conditions d’arrêt sont indispensables. Le système peut s’arrêter lorsqu’il :

• obtient un résultat conforme à un schéma attendu ;
• atteint un nombre maximal d’étapes ;
• rencontre une erreur non récupérable ;
• manque d’informations ;
• nécessite une autorisation ;
• détecte que l’objectif est déjà atteint.

Sans ces limites, un agent peut répéter une recherche, multiplier les appels d’API ou transférer indéfiniment la tâche entre plusieurs composants.

6. Les garde-fous et la supervision humaine

Les garde-fous combinent règles déterministes et contrôles sémantiques. Ils peuvent vérifier les entrées, les paramètres transmis aux outils, les résultats obtenus et la réponse finale.

Une demande de consultation d’un dossier peut être exécutée automatiquement. Une modification d’adresse peut nécessiter une confirmation. Un remboursement élevé peut imposer l’accord d’un responsable. L’intervention humaine doit ainsi dépendre du risque, et non être ajoutée uniformément à toutes les étapes.

Le mécanisme de transfert doit fournir au conseiller le motif du contact, les informations vérifiées, les actions déjà tentées et la cause de l’escalade. Autrement, l’agent automatise le début du parcours tout en obligeant le client à recommencer son explication.

7. L’observabilité et les évaluations

Les journaux techniques ne suffisent pas. Il faut pouvoir reconstituer le chemin suivi : modèle utilisé, outil sélectionné, paramètres envoyés, résultat retourné, contrôle activé et décision finale.

Les évaluations doivent porter sur plusieurs niveaux :

• exactitude de la réponse ;
• choix du bon outil ;
• validité des paramètres ;
• respect des règles métier ;
• succès réel de l’action ;
• pertinence du transfert humain ;
• coût et durée de l’exécution.

Un agent peut produire un message convaincant tout en ayant échoué à modifier le dossier. Le KPI décisif reste alors l’état observé dans le système métier, pas la qualité apparente du texte.

Agent unique, workflow ou système multi-agents : que choisir ?

Pour traiter une demande de facturation, trois architectures sont envisageables. Un agent unique peut consulter la facture et expliquer l’écart. Un workflow peut imposer une succession fixe de contrôles. Un système multi-agents peut répartir l’analyse entre un agent documentaire, un agent comptable et un agent chargé de la réponse.

La solution la plus complexe n’est justifiée que si elle améliore un résultat mesurable.

L’agent unique équipé de plusieurs outils

Un agent unique convient lorsque le périmètre reste cohérent, que les outils partagent des règles communes et que le nombre de décisions demeure maîtrisable.

Ses avantages sont concrets : moins de transferts de contexte, un parcours plus facile à tracer et moins d’appels de modèles. Il peut évoluer progressivement par l’ajout d’outils ou de modèles d’instructions spécialisés.

Il atteint toutefois ses limites lorsque ses instructions deviennent contradictoires, que ses outils exigent des niveaux d’autorisation incompatibles ou que plusieurs domaines métier doivent travailler indépendamment.

Les workflows agentiques

Un workflow conserve une ossature déterministe tout en confiant certaines décisions à un modèle. Cette approche convient bien aux processus dont les grandes étapes sont connues.

Quatre patterns reviennent fréquemment :

• Séquentiel : chaque étape transforme la sortie de la précédente.
• Routage : une demande est dirigée vers une branche spécialisée.
• Parallélisation : plusieurs analyses indépendantes sont lancées simultanément.
• Évaluateur-optimiseur : un composant produit un résultat, un autre le contrôle, puis une nouvelle version est générée si nécessaire.

Pour une réclamation, le parcours peut imposer l’identification, la collecte des faits et le contrôle d’éligibilité, tout en laissant le modèle choisir les documents à consulter. La structure reste prévisible sans figer chaque micro-décision.

Les architectures multi-agents

Le multi-agent devient pertinent lorsque les responsabilités doivent réellement être séparées. Un agent superviseur peut déléguer des tâches à des spécialistes, ou chaque agent peut transférer le contrôle au suivant.

Les documentations d’architecture distinguent notamment les modèles séquentiels, concurrents, avec conversation de groupe, avec handoff et avec planification centrale[5][6].

Le bon réflexe consiste à commencer par un agent unique ou un workflow encadré. Le multi-agent intervient lorsque la spécialisation, l’isolation des droits ou l’exécution parallèle compensent réellement sa complexité.

Comment concevoir une architecture agentique en six étapes ?

Une entreprise qui souhaite « mettre un agent dans son service client » part d’une technologie. Une démarche plus solide part d’un processus précis, par exemple réduire les demandes manuelles de report de rendez-vous.

1. Définir un objectif opérationnel

Le cas d’usage doit comporter un résultat observable : rendez-vous modifié, ticket qualifié, fiche CRM enrichie ou demande transférée au bon service.

Il faut ensuite recenser les entrées, les exceptions et les motifs d’échec. Si le parcours peut être décrit intégralement avec quelques règles stables, une automatisation classique sera souvent plus fiable et moins coûteuse.

2. Fixer le niveau d’autonomie

Chaque action peut être classée selon son impact et sa réversibilité.

La consultation d’un statut peut être automatique. La suppression d’un compte ou l’engagement d’une dépense ne devrait pas dépendre d’une simple décision probabiliste.

3. Cartographier les données et les outils

Pour chaque outil, documentez les données lues, les données modifiées, l’identité utilisée et les dépendances externes. Séparez autant que possible les fonctions de lecture et d’écriture.

Cette cartographie révèle souvent les véritables obstacles : référentiels incohérents, API incomplètes, droits trop larges ou absence de source faisant autorité.

4. Choisir le pattern le plus simple

Commencez par un parcours nominal. Ajoutez du routage si plusieurs intentions exigent des traitements distincts, puis des agents spécialisés uniquement si les rôles ou permissions doivent être isolés.

La complexité doit répondre à une contrainte identifiée. « Un agent par service » n’est pas un principe d’architecture suffisant.

5. Prévoir les échecs

Définissez les timeouts, reprises, limites d’appels, réponses dégradées et transferts humains. Une erreur d’outil doit être visible par l’orchestrateur et ne pas être reformulée comme un succès.

Pour les actions sensibles, une clé d’idempotence évite qu’un nouvel essai crée deux remboursements, deux rendez-vous ou deux tickets.

6. Évaluer avant d’étendre

Le jeu de test doit inclure les demandes courantes, les formulations ambiguës, les informations manquantes, les attaques et les exceptions métier.

Un pilote peut d’abord fonctionner en mode recommandation : l’agent prépare l’action, mais un collaborateur l’exécute. Une fois les résultats mesurés, certaines catégories à faible risque peuvent passer en exécution automatique.

Comment rendre le système fiable, sécurisé et gouvernable ?

Un chatbot qui consulte une FAQ expose principalement un risque de mauvaise réponse. Un agent autorisé à écrire dans un CRM, envoyer un message ou modifier un contrat possède une surface d’attaque bien plus large.

Contrôler les accès et les actions

Les risques propres aux architectures agentiques comprennent notamment le détournement d’objectif, le mauvais usage des outils, l’abus d’identité, l’empoisonnement de la mémoire et la propagation d’erreurs entre agents[7].

Quelques règles structurantes permettent de réduire cette exposition :

• appliquer le principe du moindre privilège ;
• séparer lecture, proposition et exécution ;
• valider les paramètres côté serveur ;
• isoler les données de chaque utilisateur ;
• ne jamais traiter le contenu récupéré comme une instruction de confiance ;
• demander une confirmation explicite pour les actions sensibles ;
• prévoir un mécanisme d’arrêt immédiat.

La spécification MCP publiée en juillet 2026 recommande elle aussi de limiter les autorisations aux scopes nécessaires et de vérifier que chaque jeton a bien été émis pour le serveur auquel il est présenté[8].

Protéger les données et assurer la traçabilité

L’Autorité de protection des données (APD) rappelle que les systèmes d’IA peuvent traiter des données à caractère personnel à plusieurs étapes de leur cycle de vie. Ces traitements doivent notamment respecter les principes de finalité, de minimisation, d’exactitude, de limitation de la conservation et de sécurité prévus par le RGPD[9].

Dans une architecture agentique, cette vigilance concerne les informations ajoutées au contexte, les données consultées ou produites par les outils, ainsi que les éléments conservés dans la mémoire de l’agent. L’entreprise doit déterminer quelles données sont nécessaires à chaque étape, qui peut y accéder et combien de temps elles doivent être conservées.

Il faut notamment pouvoir répondre à cinq questions :

1. Quelle personne ou quel système a demandé l’action ?
2. Quel agent a pris la décision ?
3. Quelles informations ont fondé cette décision ?
4. Quel outil a exécuté l’action ?
5. Quel résultat a réellement été enregistré dans le système métier ?

Cette traçabilité facilite l’audit et l’amélioration continue. Elle permet de déterminer si une erreur provient du modèle, du contexte transmis, d’un outil, des droits accordés ou d’une règle métier mal définie.

Arbitrer entre qualité, coût et latence

Une architecture multi-agents multiplie les instructions, les transferts de contexte et les appels aux modèles. Elle peut améliorer la spécialisation, mais aussi allonger le délai de réponse.

Le coût doit donc être suivi par exécution complète : tokens consommés, appels d’outils, reprises et interventions humaines. Une résolution plus chère peut rester rentable si elle évite un traitement manuel important ; à l’inverse, trois agents chargés de vérifier une réponse simple créent surtout de la dépense et de la latence.

Quelle architecture agentique pour la relation client ?

Imaginons un client qui appelle pour déplacer une intervention technique. L’objectif n’est pas seulement de répondre à sa question, mais d’aboutir à un rendez-vous valide ou à un transfert correctement documenté.

Le parcours peut être organisé ainsi :

Imaginons un client qui appelle pour déplacer une intervention technique. L’objectif n’est pas seulement de lui indiquer la marche à suivre, mais d’enregistrer un nouveau rendez-vous ou, en cas d’exception, de transmettre un dossier complet à un conseiller.

Le parcours peut être organisé ainsi :

1. Agent vocal : accueille le client, transcrit sa demande et identifie son intention.
2. Service d’identité : vérifie les informations nécessaires pour accéder au dossier.
3. Orchestrateur : conserve l’état de la demande, charge les règles applicables et détermine l’action suivante.
4. Client MCP : identifie les outils autorisés pour cette tâche et transmet les demandes de l’agent aux serveurs concernés.
5. Serveur MCP du CRM : expose des fonctions limitées, comme consulter le contrat, l’adresse ou l’historique des interventions.
6. Serveur MCP de planification : permet de rechercher les créneaux disponibles et, après confirmation, de modifier le rendez-vous.
7. Agent : compare les possibilités, propose plusieurs créneaux au client et recueille son choix.
8. Garde-fou : vérifie l’identité, l’adresse, le créneau choisi et la présence d’une confirmation explicite.
9. Outil métier : enregistre le nouveau rendez-vous par l’intermédiaire de l’API du logiciel de planification.
10. Contrôle final : relit l’état réellement enregistré avant d’annoncer la réussite de l’opération.
11. Transfert humain : intervient lorsqu’aucun créneau ne convient, qu’une information reste incertaine ou que la situation sort du périmètre autorisé.

L'architecture agentique ou comment concevoir l’autonomie par paliers

Une architecture agentique réussie ne cherche pas à tout automatiser, notamment lorsqu’il est question de contrôle. Elle attribue à l’agent une autonomie proportionnée au risque et à la capacité de vérifier ses résultats.

Le point de départ le plus solide reste un cas d’usage circonscrit, un agent ou un workflow simple, des outils aux droits limités et un jeu d’évaluation représentatif. L’architecture peut ensuite évoluer vers davantage d’autonomie ou plusieurs agents lorsque les résultats justifient cette complexité.

Pour appliquer cette démarche à la relation client, commencez par cartographier un parcours précis : informations nécessaires, décisions attendues, outils sollicités, exceptions et transfert humain.

Les équipes Ringover peuvent ensuite vous aider à identifier les briques conversationnelles et téléphoniques adaptées à ce parcours. Vous avez des questions ? Posez-les à nos experts ou testez directement nos solutions IA.

FAQ sur l’architecture agentique

Une architecture agentique est-elle forcément multi-agents ?

Non. Un seul agent équipé de plusieurs outils peut suffire. Une architecture multi-agents devient pertinente lorsque le processus exige des compétences spécialisées, des permissions différentes ou des traitements parallèles.

Quelle différence entre une architecture RAG et une architecture agentique ?

Le RAG récupère des connaissances pour enrichir la réponse d’un modèle. Une architecture agentique organise en plus la prise de décision, l’utilisation d’outils, la gestion de l’état et l’exécution d’actions.

À quoi sert un orchestrateur d’agents IA ?

Il pilote les appels de modèles et d’outils, transmet le contexte, conserve l’état de la tâche et applique les conditions d’arrêt. Dans un système multi-agents, il peut aussi attribuer les tâches et gérer les transferts.

Quel rôle joue MCP dans une architecture agentique ?

MCP standardise la manière dont une application expose des ressources, des prompts et des outils à un système d’IA. Il facilite leur découverte et leur utilisation, mais ne remplace ni l’orchestration, ni les règles métier, ni les contrôles de sécurité.

Comment choisir entre un workflow et un agent IA ?

Choisissez un workflow lorsque les étapes et exceptions peuvent être prévues. Un agent devient utile lorsque le système doit interpréter des informations non structurées, adapter son parcours ou choisir parmi plusieurs outils selon le contexte.

Comment tester une architecture agentique ?

Il faut tester la réponse finale, mais aussi les décisions intermédiaires : choix des outils, paramètres, permissions, gestion des erreurs et état créé dans les logiciels métiers. Les tests doivent inclure des situations ambiguës, incomplètes et malveillantes.

Mentions

• [1] https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
• [2] https://www.anthropic.com/engineering/building-effective-agents
• [3] https://docs.aws.amazon.com/prescriptive-guidance/latest/govern-architect-agentic-ai/enterprise-architecture.html
• [4] https://modelcontextprotocol.io/specification/2026-07-28/architecture
• [5] https://docs.cloud.google.com/architecture/choose-design-pattern-agentic-ai-system
• [6] https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns
• [7] https://genai.owasp.org/initiatives/agentic-security-initiative/
• [8] https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
• [9] https://www.autoriteprotectiondonnees.be/publications/l-impact-de-l-intelligence-artificielle-sur-la-vie-privee.pdf
• [10] https://dicodunumerique.com/definitions/handoff

Publié le 3 septembre 2026.