Diagramme d'architecture d'un agent IA : modèle, outils, mémoire et garde-fous

La plupart des diagrammes d'agents IA montrent une icône de robot à côté d'un logo de LLM, avec une flèche étiquetée « outils ». Cette image cache les questions qui décident si un agent peut tourner en sécurité : qui choisit l'étape suivante, à quoi l'agent a le droit de toucher, par où entre le texte non fiable, et qu'est-ce qui arrête une exécution qui ne mène nulle part.

Cet article décompose un agent en ses parties, parcourt la boucle qui le pilote, couvre les outils et le Model Context Protocol, la mémoire, les garde-fous, les limites et le traçage, et dessine un agent de support client capable de consulter des commandes et d'émettre des remboursements.

Workflow ou agent ?

Le guide d'Anthropic pour construire des agents efficaces trace une frontière utile. Dans un workflow, les LLM et les outils sont orchestrés par des chemins de code écrits à l'avance. Dans un agent, le modèle dirige son propre processus et décide, étape par étape, quels outils utiliser jusqu'à ce que la tâche soit terminée.

Le même guide recommande la solution la plus simple qui fonctionne. Si une tâche suit toujours les trois mêmes étapes, écrivez ces étapes en code et appelez le modèle à l'intérieur. Tournez-vous vers un agent quand le chemin dépend de ce que l'agent découvre en route : un dossier de support où la recherche suivante dépend de la dernière réponse, ou une tâche de développement qui demande plusieurs tours de modification et de test.

Les parties d'un agent

Le modèle n'est qu'une boîte. L'essentiel de l'ingénierie, et l'essentiel du contrôle des risques, se trouve dans le code autour.

La boucle

Réduit à l'essentiel, le runtime est une boucle :

def run(task, user):
    messages = [system_prompt(user), task]
    for step in range(MAX_STEPS):
        reply = llm.generate(messages, tools=allowed_tools(user))
        if not reply.tool_calls:
            return check_output(reply.text)
        for call in reply.tool_calls:
            result = execute(call, user)   # permission check, approval, timeout
            messages.append(tool_result(call, result))
    return stop("step limit reached", messages)

Le modèle n'exécute jamais rien lui-même. Il renvoie soit une réponse, soit une demande d'appel d'outil avec certains arguments, et c'est le runtime qui décide s'il l'exécute et comment. C'est là que se trouve le contrôle : vérifications de permissions, validations, timeouts et limites se situent tous dans execute et dans la boucle, pas dans le prompt.

Les outils, et la place de MCP

Un outil est une fonction que le modèle peut demander : un nom, une description et un schéma JSON pour ses arguments. Les descriptions comptent autant que le code, car c'est tout ce que le modèle sait du moment où utiliser un outil.

Le Model Context Protocol est un standard ouvert pour connecter des applications d'IA à des systèmes externes. Un serveur MCP expose des outils, des données et des prompts ; le runtime de l'agent joue le rôle de client. Au lieu de câbler chaque intégration dans le code de l'agent, chaque système fournit un serveur, et n'importe quel runtime compatible MCP peut l'utiliser.

Les bons outils ont quelques traits en commun :

• Peu nombreux et précis. refund_order(order_id, amount, reason) vaut mieux qu'un call_api(url, body) générique.
• Lecture et écriture séparées, pour qu'un rôle puisse obtenir les outils de lecture sans ceux d'écriture.
• Des erreurs claires sur lesquelles le modèle peut agir, comme « montant supérieur au total de la commande ».
• Des clés d'idempotence sur les écritures, pour qu'une étape relancée ne rembourse pas deux fois.

La mémoire

Les agents ont deux sortes de mémoire, et les diagrammes les confondent souvent :

• La mémoire de travail est le contexte envoyé au modèle à chaque étape : instructions, conversation et résultats d'outils jusque-là. Elle est limitée par la fenêtre de contexte du modèle et par le coût : les longues exécutions résument donc les anciennes étapes ou abandonnent la sortie brute des outils une fois utilisée.
• Les connaissances à long terme vivent hors du modèle : documents, règles, anciens tickets. L'agent récupère les morceaux pertinents, souvent dans un index vectoriel, et les ajoute à la mémoire de travail. Le diagramme d'architecture RAG détaille le pipeline de récupération.

L'état de la tâche qui doit survivre à un crash, comme les étapes déjà exécutées ou la validation en attente, a sa place dans une base de données classique, pas dans le contexte du modèle.

Garde-fous et permissions

Le Top 10 OWASP pour les applications LLM place l'injection de prompt en premier. Une autre entrée, l'agentivité excessive, couvre les actions dommageables qu'un système LLM peut mener parce qu'il dispose de plus de fonctionnalités, de permissions ou d'autonomie que nécessaire. Les agents sont exposés aux deux : ils lisent du texte non fiable (saisies utilisateur, pages web, documents récupérés, résultats d'outils) et ils peuvent agir.

Des règles qui tiennent en pratique :

• Traitez chaque résultat d'outil et chaque document récupéré comme des données. Le texte d'une page web ne peut pas accorder de permissions ni changer la tâche.
• Agissez avec les permissions de l'utilisateur, pas avec un compte de service qui voit tous les clients.
• Filtrez les écritures. Les lectures s'exécutent librement ; les écritures au-delà d'un seuil, ou toute action irréversible, attendent une personne.
• Isolez l'exécution de code : sans identifiants et sans réseau par défaut.
• Vérifiez les sorties avant qu'elles n'atteignent les utilisateurs ou d'autres systèmes, pour repérer des fuites de données internes ou du contenu dangereux.

Le diagramme de flux de données pour la modélisation des menaces est un bon moyen de trouver où du texte non fiable entre dans un composant capable d'agir.

Limites et coûts

Un agent qui tourne en rond sans progresser brûle de l'argent et de la patience. Placez les limites dans le runtime, pas dans le prompt :

• Étapes : un nombre maximal d'appels au modèle par tâche.
• Temps : une limite de durée par tâche et un timeout par appel d'outil.
• Argent : un budget en tokens ou en dollars par tâche, et par utilisateur et par jour.
• Débit : des limites de requêtes par utilisateur au niveau de l'API, comme dans la conception d'un rate limiter.

Quand une limite est atteinte, arrêtez proprement : renvoyez ce qui a été trouvé, indiquez quelle limite a stoppé l'exécution et conservez la trace pour la revue.

Traçage et évaluations

Enregistrez chaque étape : le contexte envoyé, le modèle et ses réglages, chaque appel d'outil avec ses arguments et ses résultats, les tokens, la latence et le coût. OpenTelemetry définit des conventions sémantiques pour l'IA générative, si bien que ces traces peuvent rejoindre les mêmes backends que le reste de votre système ; le diagramme d'architecture d'observabilité montre ce pipeline.

Les traces répondent à « que s'est-il passé dans cette exécution ? ». Les évaluations répondent à « l'agent s'améliore-t-il ou se dégrade-t-il ? » : un ensemble fixe de tâches réalistes, notées automatiquement, lancées à chaque changement de prompts, d'outils ou de modèles.

Le diagramme d'architecture

Comment le lire :

• À gauche : l'utilisateur envoie une tâche via l'application de chat, qui gère la connexion et les sessions et transmet la tâche, avec l'identité de l'utilisateur, aux garde-fous.
• Au centre : la boucle d'agent envoie le contexte et la liste d'outils au LLM (trait plein) et reçoit une réponse ou un appel d'outil (tirets). Elle lit et écrit la mémoire de travail ; le bloc Markdown liste les limites.
• À droite : les appels d'outils vont à la recherche web, à une sandbox de code et à l'API des commandes. Un remboursement attend la validation (tirets).
• En bas : l'index de connaissances alimente la mémoire de travail en documents récupérés, et chaque étape est enregistrée dans les traces et les évaluations (pointillés).

Un exemple complet : un remboursement

Un client écrit : « La commande 4411 est arrivée cassée, je veux être remboursé. »

1. Les garde-fous vérifient le message et y joignent l'identité du client.
2. Le modèle demande get_order(4411). Le runtime vérifie que la commande appartient à ce client et renvoie : livrée il y a trois jours, 180 dollars.
3. Le runtime récupère la politique de remboursement dans l'index de connaissances et l'ajoute à la mémoire de travail : les articles endommagés sont remboursables sous 30 jours.
4. Le modèle demande refund_order(4411, 180, "damaged"). Le montant dépasse le seuil de 100 dollars : le runtime met l'exécution en pause et envoie une demande de validation à un responsable du support.
5. Le responsable valide. Le runtime exécute le remboursement avec une clé d'idempotence et renvoie la confirmation.
6. Le modèle rédige la réponse, les vérifications de sortie passent, et le client obtient sa réponse.

Trois appels au modèle, deux appels d'outils, une récupération, une validation, et une trace qui montre chaque étape.

Ce qu'il faut mettre sur un diagramme d'agent

• Qui décide de l'étape suivante : le modèle, ou le code que vous avez écrit.
• Chaque outil, avec son accès en lecture ou en écriture et les permissions qu'il utilise.
• Les points de validation pour les actions risquées.
• Les limites : étapes, temps et budget.
• Les points d'entrée du texte non fiable : saisies utilisateur, pages web, documents, résultats d'outils.
• Le traçage, pour qu'un relecteur sache que les exécutions peuvent être inspectées.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez deux nœuds Personne du pack Modèle C4 pour l'utilisateur et le valideur, et un Conteneur pour l'application de chat.
3. Ajoutez un Cadre du pack Base pour le runtime de l'agent, avec un Conteneur pour la boucle d'agent et deux nœuds Composant pour les garde-fous et la mémoire de travail.
4. Ajoutez un Modèle et un Index vectoriel du pack ML, un second Cadre avec trois nœuds Carte de service du pack Stack pour les outils, et du Traçage du pack DevOps.
5. Dessinez les réponses du modèle en tirets et l'arête de traçage en pointillés, et ajoutez un bloc Markdown du pack Base avec les limites. Pour qu'un agent le dessine à votre place, voyez créer des diagrammes avec des agents IA via MCP.

L'exemple utilise 15 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Quelle est la différence entre un agent IA et un workflow ? Dans un workflow, votre code décide de l'enchaînement des étapes et appelle le modèle à l'intérieur. Dans un agent, le modèle décide de l'étape suivante et des outils à utiliser, dans une boucle que votre code contrôle.

Qu'est-ce que MCP dans une architecture d'agent ? Le Model Context Protocol est un standard ouvert pour connecter des applications d'IA à des outils et à des données. Les systèmes exposent des serveurs MCP, et le runtime de l'agent s'y connecte en tant que client.

Comment empêcher un agent de mener des actions dommageables ? Donnez-lui uniquement les outils dont il a besoin, exécutez-les avec les permissions de l'utilisateur, exigez une validation humaine pour les écritures au-delà d'un seuil et traitez tous les résultats d'outils et documents comme des données non fiables.

Comment les agents se souviennent-ils des choses ? Au sein d'une exécution, grâce au contexte envoyé au modèle à chaque étape. D'une exécution à l'autre, grâce à des connaissances stockées récupérées au besoin et à un état de tâche conservé dans une base de données.

Comment maîtriser les coûts d'un agent ? Fixez dans le runtime des limites d'étapes, de temps et de tokens par tâche, ajoutez des budgets par utilisateur et tracez chaque exécution pour que les schémas coûteux apparaissent lors des revues.

Commencez gratuitement — un siège, sans carte bancaire.