Architecture d'un agent IA : composants, mémoire et orchestration

L'architecture d'un agent IA est l'ensemble des composants qui entourent un modèle de langage et décident de ce qu'il voit, de ce qu'il peut faire et de ce qui se passe quand il se trompe. Une conception viable compte huit parties : un point d'entrée qui établit l'identité, une boucle de contrôle, un adaptateur de modèle, un constructeur de contexte, une couche d'outils, une barrière de contrôle (policy gate), un magasin d'état et une trace. La mémoire et les agents supplémentaires sont facultatifs, et chacun apporte des modes de défaillance qu'il faudra payer. La ligne de partage qui commande tout le reste : le modèle propose, et du code déterministe décide de ce qui s'exécute réellement.

Cet article est une référence sur cette structure, à lire composant par composant. Pour suivre une construction dans l'ordre, avec une boucle en Python qui tourne, voyez comment créer un agent IA. Les pratiques de production comme les règles de conception des outils, les garde-fous et l'évaluation figurent dans notre article sur le développement d'agents IA. L'état des produits et des protocoles est celui de novembre 2026.

Le schéma d'architecture

                 user or calling system
                           |
                           v
               +-----------------------+
               | ENTRY POINT           |   who is asking, on whose
               | identity, disclosure  |   permissions, with what budget
               +-----------+-----------+
                           |
                           v
 +-------------------------+----------------------------+
 | CONTROL LOOP (your code; owns the run)               |
 |                                                      |
 |   +-----------------+        +-------------------+   |      +--------------+
 |   | CONTEXT BUILDER |------->| MODEL ADAPTER     |---+----->| model        |
 |   | what the model  |        | one call, one     |<--+------| (hosted or   |
 |   | sees this step  |        | neutral format    |   |      | self-run)    |
 |   +--+-----------+--+        +---------+---------+   |      +--------------+
 |      ^           ^                     |             |
 |      |           |                     | proposal:   |
 |      |           |                     | text or     |
 |      |           |                     | tool call   |
 |      |           |                     v             |
 |      |           |           +-------------------+   |      +--------------+
 |      |           |           | POLICY GATE       |---+----->| person       |
 |      |           |           | allow, deny, or   |<--+------| (approval    |
 |      |           |           | ask a person      |   |      |  queue)      |
 |      |           |           +---------+---------+   |      +--------------+
 |      |           |                     | allowed     |
 |      |           |                     v             |
 |      |           |           +-------------------+   |      +--------------+
 |      |           +-----------| TOOL LAYER        |---+----->| your systems |
 |      |        tool results   | registry, schemas,|<--+------| and data     |
 |      |        (UNTRUSTED)    | scoped credentials|   |      | (UNTRUSTED   |
 |      |                       +-------------------+   |      |  content)    |
 +------+------------------+----------------------+-----+      +--------------+
        ^                  |                      |
        v                  v                      v
 +--------------+   +--------------+   +----------------------------+
 | MEMORY       |   | STATE STORE  |   | TRACE                      |
 | across runs  |   | this run,    |   | every proposal, decision,  |
 | (optional)   |   | checkpoints  |   | call; feeds evaluation     |
 +--------------+   +--------------+   +----------------------------+

Le même schéma en mots

Une requête arrive au point d'entrée (ENTRY POINT), qui lui associe une identité, un ensemble de permissions et un budget, puis lance une exécution. À partir de là, cette exécution appartient à la boucle de contrôle (CONTROL LOOP).

À chaque étape, le constructeur de contexte (CONTEXT BUILDER) assemble ce que le modèle verra : instructions, tâche, résultats d'outils récents, tout ce qui a été lu en mémoire. L'adaptateur de modèle (MODEL ADAPTER) l'envoie au modèle et renvoie l'une de deux choses, une réponse finale ou une proposition d'appel d'outil. Une proposition reste une proposition. Elle passe à la barrière de contrôle (POLICY GATE), qui l'autorise, la refuse avec une erreur lisible par le modèle, ou suspend l'exécution et interroge une personne. Un appel autorisé va à la couche d'outils (TOOL LAYER), qui l'exécute avec des identifiants limités à cet outil et renvoie le résultat au constructeur de contexte pour l'étape suivante.

Deux faits comptent plus que les cases du schéma. Le contenu renvoyé par les outils n'est pas fiable (UNTRUSTED), car un e-mail de client ou une page web peut contenir des instructions, et il revient dans le contexte du modèle à l'étape suivante. Et la barrière de contrôle se trouve après le modèle sur le chemin de sortie, là où rien de ce que le modèle lit ou écrit ne peut la retirer. Le magasin d'état (STATE STORE), la mémoire (MEMORY) et la trace (TRACE) se situent sous la boucle : le magasin d'état contient cette exécution, la mémoire transporte des informations d'une exécution à l'autre, et la trace enregistre le tout.

Les composants, un par un

Point d'entrée

Le point d'entrée répond à trois questions avant tout appel au modèle : qui demande, avec les permissions de qui l'agent va agir et de quel budget dispose cette exécution. Si cette étape manque, l'agent se rabat sur un unique compte de service aux droits étendus, et chaque utilisateur peut atteindre tout ce que ce compte peut atteindre. Le Top 10 for Agentic Applications de l'OWASP (décembre 2025) range cette catégorie de problème sous ASI03, Identity & Privilege Abuse. Le CAISI du NIST a lancé en février 2026 une AI Agent Standards Initiative dont l'identité est l'un des axes de recherche, mais sa page ne mentionnait aucune recommandation finale sur les agents à sa mise à jour d'août 2026.

Pour les agents en contact avec des clients, l'obligation de transparence de l'article 50 du règlement européen sur l'IA (AI Act), applicable depuis le 2 août 2026, se traite aussi le plus facilement ici.

Boucle de contrôle

La boucle est du code ordinaire qui alterne appels au modèle et appels d'outils jusqu'à ce qu'une condition d'arrêt se déclenche. Elle détient le compteur d'étapes, l'échéance et la décision qu'une exécution est terminée. Elle ne doit contenir aucune logique métier. Ce qui va ailleurs : les règles dans la barrière de contrôle, les prompts dans le constructeur de contexte, les intégrations dans la couche d'outils.

Par défaut, un choix raisonnable consiste à intégrer la boucle comme un nœud d'un workflow plus large, avec des étapes fixes avant (classer, router) et après (valider la sortie). L'article sur la création d'un agent en donne une version exécutable, avec la liste de chaque condition d'arrêt.

Adaptateur de modèle

Une fonction, avec un format neutre unique pour les messages et les appels d'outils, qui traduit vers le fournisseur que vous utilisez. Elle porte le délai d'expiration, les nouvelles tentatives sur limite de débit, la version de modèle épinglée et le repli. Le routage de modèle par étape se trouve aussi ici, avec un modèle plus petit pour résumer les sorties d'outils si votre jeu d'évaluation ne montre aucune perte.

Constructeur de contexte

Le constructeur de contexte décide de ce que le modèle voit à cette étape. S'il n'existe pas comme module à part, les messages s'accumulent, simplement. Son travail : garder les instructions et la tâche à une position stable, tronquer ou résumer les anciennes sorties d'outils, ne charger que les outils utiles à la tâche et signaler quel contenu vient de l'extérieur.

La liste LLM 2026 de l'OWASP comporte une entrée appelée Hidden Context Exposure (LLM08). Notre règle pour ce composant : ne placez jamais un secret dans le contexte en supposant que le modèle le gardera.

Couche d'outils

La couche d'outils est un registre : pour chaque outil, un schéma, une classe de risque, ses identifiants, un délai d'expiration et une limite de débit. La classe de risque (lecture, écriture réversible, écriture irréversible) est le lien avec la barrière de contrôle. Les outils peuvent être des fonctions dans le processus ou des serveurs MCP distants.

Pour les outils distants, la révision de MCP du 28 juillet 2026 change les conditions de déploiement. Les sessions du protocole et la poignée de main initialize disparaissent, la version et les capacités accompagnent chaque requête, et server/discover devient obligatoire. Notre lecture : les serveurs MCP distants deviennent plus simples à exploiter derrière des répartiteurs de charge ordinaires, puisque le protocole ne maintient plus de session, mais tout état dont votre outil a besoin est désormais votre affaire. HTTP+SSE, Sampling, Roots et Logging figurent parmi les parties dépréciées, avec une période minimale de douze mois : vérifiez ce dont dépendent vos serveurs existants.

La chaîne d'approvisionnement est ici le risque structurel, puisque chaque serveur distant est du code qui détient des identifiants et dont les descriptions entrent dans le contexte du modèle. Les entrées LLM04 et ASI04 de l'OWASP la couvrent, et MITRE ATLAS y consacre une technique, AI Agent Tool Poisoning (AML.T0110).

Barrière de contrôle

La barrière est du code déterministe qui examine chaque appel proposé au regard des permissions de l'utilisateur, des listes d'autorisation, des budgets et de la classe de risque de l'outil, puis répond : autoriser, refuser ou demander. Le modèle ne peut pas la modifier, et elle ne dépend pas de sa coopération. De tous les composants, c'est celui qui limite le plus les dégâts quand autre chose lâche. Le guide pratique d'OpenAI cite deux déclencheurs d'intervention humaine : le dépassement de seuils d'échec et les actions « sensibles, irréversibles ou à forts enjeux ». Les deux s'implémentent ici.

Une architecture sans barrière confie la sécurité au prompt, et c'est un mauvais pari. « The Attacker Moves Second » (Nasr, Carlini et al., octobre 2025) rapporte que des attaques adaptatives ont contourné 12 défenses publiées contre l'injection de prompt, la plupart avec plus de 90 % de réussite, alors que la plupart de ces défenses annonçaient des taux d'attaque proches de zéro. Notre article sur la sécurité des agents IA couvre le modèle de menace et les contrôles.

Magasin d'état

L'état d'exécution est tout ce qu'il faut pour reprendre ou auditer une exécution : numéro d'étape, messages ou pointeur vers ceux-ci, appels effectués, validations en attente, budget consommé. Il a sa place dans une base de données. Gardez-le hors du prompt. Le besoin saute aux yeux avec les validations, car une exécution suspendue deux jours sur le bureau de quelqu'un ne peut pas vivre dans la mémoire du processus. La documentation de LangGraph appelle cela mémoire à court terme, un état limité au fil et conservé par des points de reprise, et l'OpenAI Agents SDK parle de sessions. Quel que soit le mot, écrivez un point de reprise après chaque étape et traitez les outils en écriture comme pouvant être relancés après un crash, ce qui suppose de leur donner des clés d'idempotence.

Trace et points d'accroche de l'évaluation

Chaque exécution doit laisser une trace de chaque contexte envoyé, proposition renvoyée, décision de la barrière et résultat d'outil, sous un même identifiant d'exécution. Le harnais d'évaluation lit ce même enregistrement : ce que « Demystifying evals for AI agents » d'Anthropic (janvier 2026) appelle la transcription (transcript) est, dans un système en production, cette trace. Les conventions sémantiques GenAI d'OpenTelemetry répertorient des spans d'agent mais restent au statut Development : adoptez-les derrière votre propre fine enveloppe, et un renommage ne touchera qu'un fichier.

Les traces contiennent des prompts et des sorties d'outils, souvent des données personnelles. En Allemagne, les traces qui montrent qui a utilisé l'agent et comment constituent aussi un sujet probable pour le comité d'entreprise allemand (Betriebsrat), comme l'explique notre article sur le processus.

Mémoire des agents IA

Le mot « mémoire » recouvre plusieurs choses, et les questions de conception diffèrent pour chacune. La documentation LangGraph de LangChain la divise en mémoire à court terme (le magasin d'état ci-dessus) et mémoire à long terme entre sessions, cette dernière répartie en trois types : sémantique, épisodique et procédurale. C'est le vocabulaire d'un éditeur, appliqué ici à des décisions de stockage.

Nous avons une opinion tranchée sur ce tableau : commencez sans aucune mémoire à long terme. La plupart des premiers agents peuvent lire ce dont ils ont besoin dans le système source au moyen d'un outil, et le système source reste juste et a un responsable. La mémoire ajoute une seconde copie qui peut se périmer ou être empoisonnée. Une seule instruction injectée et écrite en mémoire atteint des exécutions ultérieures qui n'ont jamais vu le contenu de l'attaquant. L'OWASP classe Memory & Context Poisoning en ASI06, et MITRE ATLAS a une sous-technique Memory sous AI Agent Context Poisoning (AML.T0080.001).

Les index vectoriels ont leur propre entrée dans la liste OWASP 2026, LLM09, Vector and Embedding Weaknesses. Si la mémoire contient des documents, la recherche doit filtrer selon les permissions de l'utilisateur servi, comme dans notre conception d'un chatbot RAG pour documents internes.

La mémoire portant sur des personnes identifiables constitue des données personnelles au sens du RGPD : chaque stockage à long terme a donc besoin d'une durée de conservation et d'un moyen d'effacer les entrées d'une personne. C'est bien plus facile si les entrées sont structurées et étiquetées par personne concernée dès le départ, et pénible à ajouter plus tard à des résumés en texte libre.

Types d'agents IA

La classification de référence vient de Artificial Intelligence: A Modern Approach, de Stuart Russell et Peter Norvig. Elle est antérieure aux LLM et classe les agents selon leur façon de décider :

Ces types décrivent une logique de décision et disent donc peu de choses sur ce qu'il faut construire autour d'un agent LLM. La plupart des agents LLM se comportent comme des agents fondés sur un but, quoi qu'ils fassent par ailleurs. Le mot « agent » varie lui aussi selon les fournisseurs : la présentation de Google Cloud retient une définition lâche, des applications qui répondent à des requêtes en langage naturel, alors qu'OpenAI et Anthropic exigent que le modèle contrôle l'exécution. Notre article agents IA vs IA agentique compare ces définitions. Pour l'architecture, trois propriétés vérifiables en disent davantage, car chacune change ce que vous devez construire.

Un agent en lecture seule, à requête unique et choisissant parmi des routes fixes n'a guère besoin de plus que la boucle et la couche d'outils. Un agent qui tourne plusieurs jours avec des écritures irréversibles a besoin des huit composants, quelle que soit sa catégorie marketing. L'ADK de Google, par exemple, sépare agents LLM, agents de workflow et agents personnalisés, ce qui correspond à peu près au premier axe.

Patrons d'orchestration des agents IA

L'orchestration décide de la façon dont le travail circule quand plusieurs instances de modèle interviennent. « AI Agent Orchestration Patterns » de Microsoft (février 2026) en nomme cinq : séquentiel, concurrent, discussion de groupe, transfert (handoff) et magentic. Le guide d'OpenAI en nomme deux : un patron manager, où un LLM central orchestre, et un patron décentralisé, où les agents se transmettent le travail. Le conseil de Microsoft, en substance, est d'employer le niveau de complexité le plus bas qui satisfait vos exigences de façon fiable. Nous sommes d'accord : chaque pas vers la droite du tableau ci-dessous ajoute de nouvelles façons d'échouer.

Agent seul

Restez-en là jusqu'à ce qu'un problème mesuré impose de changer. Trop d'outils et un contexte trop chargé sont les pressions habituelles, et une tâche plus étroite ou un chargement des outils par type de tâche règle souvent les deux. La faiblesse structurelle : l'agent corrige sa propre copie et détient toutes les permissions au même endroit. Une étape de vérification déterministe règle le premier point sans aucune machinerie multi-agent.

Orchestrateur-workers

Ce patron est le patron manager d'OpenAI sous un autre nom. Deux raisons le justifient. Des parties indépendantes peuvent s'exécuter en même temps, par exemple pour interroger plusieurs sources sans rapport entre elles. Ou bien des parties distinctes demandent des permissions différentes, si bien qu'un worker de recherche en lecture seule qui traite du contenu non fiable ne détient jamais les identifiants d'écriture.

Le point faible est la frontière. Un worker ne voit que ce que l'orchestrateur a choisi de lui dire, et l'orchestrateur ne voit que ce que le worker a choisi de rendre. L'injection de prompt la franchit aussi : un worker qui lit un document empoisonné peut faire remonter l'instruction de l'attaquant dans son résultat. Les entrées concernées de la liste agentique de l'OWASP sont Agent Goal Hijack (ASI01) et Insecure Inter-Agent Communication (ASI07). Traitez la sortie d'un worker comme une sortie d'outil, non fiable et validée par un schéma. Un contrat de passation pourrait ressembler à ceci :

{
  "run_id": "r-20261105-0412",
  "parent_step": 3,
  "worker": "invoice_research",
  "permissions": ["erp.invoices.read"],
  "budget": {"steps": 8, "seconds": 120},
  "goal": "Find the purchase order that matches invoice INV-1001.",
  "must_return": {
    "status": "found | not_found | gave_up",
    "purchase_order_id": "string or null",
    "evidence": ["source record ids"]
  }
}

Notez ce que le contrat n'inclut pas : la conversation complète de l'orchestrateur et tout identifiant. Le worker reçoit un budget prélevé sur le total de l'exécution, si bien que le fan-out ne peut pas dépasser le plafond fixé au point d'entrée. Les permissions ne peuvent que se réduire en descendant.

Project Nemo d'Allianz en Australie est un exemple public attribuable. Allianz a fait état de sept agents traitant les sinistres d'avaries alimentaires de moins de 500 AUD, en service depuis juillet 2025, avec une réduction de 80 % du temps de traitement et de règlement et une personne qui prend chaque décision de paiement. Ce sont les chiffres d'Allianz, et nous n'avons trouvé aucun audit indépendant. L'article d'Allianz ne permet pas de dire de quel patron il s'agit : nous n'en tirons donc qu'un point structurel, à savoir de nombreux agents, une tâche étroite et l'étape irréversible laissée à une personne.

Hiérarchique

Une hiérarchie est le patron orchestrateur-workers appliqué de façon récursive, et il nous faudrait un argument solide pour l'employer dans les premiers systèmes d'une entreprise. Chaque niveau résume pour le niveau supérieur : l'objectif dérive en descendant et le détail se perd en remontant. Un résultat faux peut être repris par des branches voisines avant que quiconque ne s'en aperçoive, ce qui correspond à ASI08, Cascading Failures, de l'OWASP. La délégation tend aussi à blanchir l'autorité : à moins que les permissions ne se réduisent à chaque niveau, un agent de bas niveau peut demander à un agent supérieur de faire ce qui lui est interdit, et cela relève là encore d'ASI03. Les boucles de délégation exigent une limite de profondeur dans le code.

Si des équipes séparées possèdent des domaines séparés, envisagez plutôt un orchestrateur à plat qui appelle l'agent de chaque équipe par une interface stable. A2A est le protocole conçu pour les appels d'agent à agent. Sa v1.0 est sa première spécification stable, et la Linux Foundation fait état de plus de 150 organisations qui le soutiennent, sans toutefois définir ce « soutien » ni nommer de client en production. Nous n'avons trouvé aucune donnée indépendante comparant son adoption à celle de MCP.

Transferts (handoffs)

Dans un transfert, le contrôle passe d'un agent à l'autre sans planificateur central, le patron qu'OpenAI appelle décentralisé. Il convient au triage, où un agent oriente vers un spécialiste et se retire. Les modes de défaillance sont les agents qui se renvoient un cas et une responsabilité floue du résultat final : désignez un responsable par exécution et plafonnez le nombre de transferts.

Construire ou reprendre d'un framework

Les frameworks diffèrent surtout par les composants qu'ils fournissent. Les descriptions ci-dessous sont celles des éditeurs.

Quoi que vous adoptiez, gardez la barrière de contrôle et le registre d'outils dans votre propre code. Ils encodent vos règles, et ce sont les éléments que vous aurez le moins envie de réécrire quand un framework change ou, comme AutoGen, est archivé. Le magasin d'état peut très bien venir d'un framework, la boucle aussi.

Où s'exécute chaque composant, vu du droit de l'UE

Le schéma sert aussi de cartographie des données pour une revue de protection des données. L'adaptateur de modèle décide si les prompts quittent votre région : si la résidence compte, c'est un point de terminaison hébergé dans l'UE ou un modèle auto-exploité qui va dans cette case. Le contexte, le magasin d'état, la mémoire et la trace contiennent tous des copies de ce que lit l'agent, et chaque copie a besoin de son propre contrôle d'accès et de sa propre règle de conservation.

L'AI Act classe selon l'usage : aucun choix d'architecture ne sort donc un agent de la catégorie à haut risque. Un agent qui évalue la solvabilité de personnes physiques relève de l'annexe III, point 5 b), quelle que soit sa construction, les obligations des systèmes de l'annexe III s'appliquant à partir du 2 décembre 2027 après le Digital Omnibus, comme l'indique la page de la Commission européenne. L'architecture peut rendre ces obligations plus praticables : la trace vous donne des enregistrements, et la barrière de contrôle un point documenté de contrôle humain.

Questions fréquentes

Quelle est la différence entre la mémoire et l'état d'un agent IA ?

L'état appartient à une exécution et existe pour qu'elle puisse reprendre et être auditée. La mémoire à long terme transporte des informations d'une exécution à l'autre. La documentation de LangGraph appelle le premier mémoire à court terme et divise la seconde en sémantique, épisodique et procédurale.

Que doit contenir un schéma d'architecture d'agent IA ?

Au minimum, le chemin qui va de la proposition du modèle aux outils en passant par une barrière de contrôle, le chemin de retour des résultats d'outils non fiables, l'endroit où une personne valide et celui où l'état et les traces sont stockés. Un schéma qui ne montre que « LLM, outils, mémoire » laisse de côté les parties qui limitent les dégâts.

Quand le patron orchestrateur-workers vaut-il mieux qu'un agent seul ?

Quand des parties d'une tâche peuvent s'exécuter en parallèle avec peu de contexte partagé, ou demandent des permissions différentes. Pour l'angle des coûts, voyez notre article sur le coût de développement d'un système multi-agent. Sinon, un agent seul est plus facile à tester et à déboguer.

Une architecture d'agent a-t-elle besoin de MCP ou d'A2A ?

Ni l'un ni l'autre n'est requis. MCP est utile quand plusieurs agents ou clients partagent des outils, et A2A quand des agents appartenant à des équipes ou à des entreprises différentes s'appellent entre eux. Des fonctions dans le processus et de simples appels de fonction conviennent à l'intérieur d'un même système.

Concevoir une architecture d'agent avec AI Superior

AI Superior est une entreprise d'ingénierie IA basée à Darmstadt, en Allemagne, fondée en 2019 par des scientifiques de l'IA, et nous développons des applications LLM, des systèmes RAG et des agents IA pour des clients B2B. Nos services de développement d'agents IA couvrent la conception et la réalisation. Lorsque l'identité, l'audit et les systèmes existants orientent la conception, voyez le développement d'agents IA pour les grandes entreprises.

Sources et lectures complémentaires

• OpenAI, « A practical guide to building agents », 2025.
• Anthropic, « Building effective agents », décembre 2024.
• Russell, S. et Norvig, P., Artificial Intelligence: A Modern Approach.
• Grace, Hadfield, Olivares, De Jonghe (Anthropic), « Demystifying evals for AI agents », janvier 2026.
• Google Cloud, AI Agent Ecosystem overview, non daté.
• Microsoft, « AI Agent Orchestration Patterns », février 2026.
• LangChain, documentation LangGraph sur la mémoire, consultée en novembre 2026.
• Documentation des projets : OpenAI Agents SDK, Claude Agent SDK, Microsoft Agent Framework, Google ADK, CrewAI, consultée en novembre 2026.
• Model Context Protocol, « Key Changes » de la révision 2026-07-28.
• Linux Foundation, communiqué de presse sur A2A, avril 2026.
• OWASP, GenAI LLM Top 10 2026 ; Top 10 for Agentic Applications for 2026, décembre 2025.
• MITRE ATLAS, version de contenu 2026.10, octobre 2026.
• NIST CAISI, AI Agent Standards Initiative, février 2026, page mise à jour en août 2026.
• OpenTelemetry, conventions sémantiques pour l'IA générative.
• Nasr, Carlini et al., « The Attacker Moves Second », octobre 2025.
• Allianz, article sur Project Nemo, novembre 2025.
• Commission européenne, page sur le cadre réglementaire de l'AI Act ; annexe III de l'AI Act.