Architecture d’un agent IA : LLM, outils, mémoire, traces

Oubliez le “chat”. Un agent, c’est une boucle.

Un agent IA, ce n’est pas “un chatbot plus musclé”.

C’est un système qui agit.

Le plus simple pour le comprendre : imaginez une cuisine.

Un LLM, c’est le chef. Il sait improviser une recette. Mais sans frigo, sans couteaux, et sans inventaire, il va surtout… parler de cuisine.

Un agent, c’est le chef plus :

• des outils (le frigo, les couteaux, la caisse, le téléphone),
• une mémoire (la liste de courses, les allergies du client, les plats déjà servis),
• une politique (ce qui est autorisé / interdit),
• et un carnet de bord (tout ce qui a été fait, quand, pourquoi).

La littérature “agentic” a popularisé cette idée de boucle “raisonner + agir” : on alterne planification et actions concrètes (appels d’outils), au lieu de générer une réponse d’un seul bloc.¹

Les 6 briques d’un agent qui tient en production

En 2026, “faire un agent” peut se faire en 30 minutes. Faire un agent fiable est un autre sport.

Voici les briques que vous retrouvez (explicitement ou non) dans les SDK modernes comme l’OpenAI Agents SDK (Node/Python) qui met l’accent sur le tool-calling et la traçabilité.²

1) Le cerveau : un LLM (ou plusieurs)

Le LLM n’est pas toujours un monolithe.

En pratique, on voit souvent :

• un routeur (modèle plus léger) qui classifie la demande,
• un modèle principal qui raisonne et orchestre,
• parfois un vérificateur qui relit / recalcule / contrôle.

Pourquoi ? Parce que la robustesse vient rarement d’un “gros modèle unique”. Elle vient de la composition.

2) Les mains : tool calling (outils)

Un agent sans outils, c’est un copilote sans volant.

Les outils, ce sont :

• des APIs (CRM, ERP, ticketing, paiement, IAM…),
• des connecteurs (SFTP, SharePoint, Drive…),
• des actions (envoyer un e-mail, ouvrir un dossier, générer un PDF),
• et parfois des “outils internes” : calcul, recherche, validation, etc.

Les fournisseurs documentent tous un mécanisme de tool use / function calling (OpenAI, Anthropic, Google, Mistral).³⁴

Le piège classique : “On a des outils, donc l’agent agit”.

Non. Il peut agir.

Pour qu’il agisse bien, il faut trois choses :

1. des outils bien nommés (un agent n’a pas le temps de deviner),
2. des schémas stricts (sinon, votre runtime devient du parsing de poésie),
3. des permissions (sinon, vous créez un super-utilisateur… par accident).

Un outil, c’est un contrat (pas une incantation)

Le mot “tool” donne l’impression d’un truc léger. En production, un outil est un contrat d’API.

Un bon outil agent-friendly :

• a un nom qui décrit une action (“create_ticket”, pas “handleStuff”),
• a un schéma d’entrée minimal,
• renvoie des erreurs explicites (codes, messages),
• et, idéalement, est idempotent (vous pouvez relancer sans créer de doublons).

Pourquoi idempotent ?

Parce que les agents sont des systèmes de boucle. Donc ils retry. Donc ils rejouent. Et si rejouer crée un doublon, vous allez passer votre semaine à faire du ménage.

Exemple d’outil “propre” (simplifié) :

{
  "name": "create_ticket",
  "description": "Crée un ticket support dans l’outil interne.",
  "parameters": {
    "type": "object",
    "properties": {
      "client_request_id": { "type": "string", "description": "Clé idempotente" },
      "subject": { "type": "string" },
      "priority": { "type": "string", "enum": ["low", "normal", "high"] },
      "payload": { "type": "object" }
    },
    "required": ["client_request_id", "subject", "priority"]
  }
}

Vous remarquez la petite clé client_request_id ? Elle n’est pas glamour. Elle vous évite des doublons. Et les doublons, c’est du coût humain.

“Tool calling fiable” : ce que ça veut dire concrètement

Quand un fournisseur dit “tool calling”, vous voulez vérifier :

• le respect des schémas (JSON correct, champs attendus),
• la capacité à demander une précision plutôt que d’inventer,
• la stabilité (moins de “ça marche aujourd’hui, ça casse demain”),
• et la gestion des erreurs d’outils (timeout, 500, 429).

Un agent sans bonne gestion d’erreur, c’est un pilote automatique sans capteur de panne.

3) Les yeux : observation (input, état, contexte)

“Observer”, ce n’est pas juste lire le message utilisateur.

C’est aussi :

• récupérer l’état du dossier (dans votre SI),
• lire les pièces jointes,
• vérifier la dernière action,
• comprendre le canal (e-mail, chat, voix),
• et parfois détecter les signaux faibles : une incohérence, un manque, une alerte conformité.

Sans observation structurée, l’agent marche au feeling. Et le feeling ne passe pas en audit.

4) La mémoire : court terme, long terme, et RAG

Le mot “mémoire” est piégeux.

On met tout dedans : l’historique de chat, des notes, un vector store, un cache, un “profil”.

Une façon utile de penser :

• Mémoire court terme : contexte de session (ce qui se passe maintenant).
• Mémoire long terme : connaissances persistantes (politiques, docs, préférences).
• Mémoire de travail : variables et état du plan (todo, contraintes, résultats).

Le pattern le plus stable pour l’ancrage métier reste le RAG : récupérer des passages de documents puis demander au modèle de répondre “à partir” de ces sources.⁵

Mémoire : le triangle “utile / risqué / cher”

Quand on implémente une mémoire, il y a un triangle de contraintes :

• Utile : est-ce que ça améliore vraiment la qualité ?
• Risqué : est-ce que ça augmente l’exposition (PII, erreurs persistantes) ?
• Cher : est-ce que ça augmente latence et coûts (retrieval, contexte) ?

Trois patterns reviennent souvent :

1. Mémoire “profil” (stable) : préférences, contraintes, style.
2. Mémoire “dossier” (métier) : état, pièces, décisions précédentes.
3. Mémoire “recherche” (RAG) : passages de documents pertinents.

Le piège : transformer un agent en archiviste.

Plus vous injectez de mémoire, plus vous augmentez :

• la latence,
• le coût,
• et le risque de confusion (le modèle “moyenne” des versions).

La solution classique : séparer l’état du dossier (structuré) de la mémoire textuelle. L’état vit dans une base de données (ou un service). Le LLM n’en voit qu’un résumé strict.

5) La colonne vertébrale : l’orchestrateur (runtime)

Vous avez deux grandes familles :

1. Agents “LLM-first” : le modèle pilote la boucle et décide des outils.
2. Workflows “graph-first” : vous définissez des étapes (graph / DAG), le LLM intervient dans les nœuds.

Les deux sont utiles. Les deux échouent, mais pas de la même façon.

Quand vous voulez :

• de la flexibilité → agent LLM-first,
• de la prédictibilité → workflow graph-first,
• les deux → architecture hybride (graph + décisions LLM cadrées).

LangGraph, par exemple, formalise l’idée d’un agent comme un graphe d’états (state machine) plutôt qu’une boucle “magique”.⁶

6) Les freins : vérification, garde-fous, escalade

Ce qui sépare une démo d’un produit : la gestion de l’erreur.

Un agent sérieux a :

• des validations (formats, montants, cohérence),
• des garde-fous (policies, filtres, allowlists),
• des timeouts,
• un budget (tokens, outils, coûts),
• et un mécanisme d’escalade vers un humain.

Sur les risques applicatifs, l’OWASP a formalisé une liste utile (prompt injection, data exfiltration, etc.).⁷

Outils, permissions, sandbox : l’agent n’est pas “admin”

Le meilleur agent du monde devient un désastre s’il a trop de pouvoir.

Le principe simple : moindre privilège.

Dans un SDK d’agents, ça se traduit par :

• des scopes par outil,
• des secrets isolés (pas dans les prompts),
• un sandbox d’exécution (si l’agent exécute du code),
• une revue humaine pour les actions critiques.

Certains environnements “agentic coding” rendent ces sujets explicites, avec des notions de permissions et d’exécution contrôlée (ex. Claude Agent SDK / Claude Code SDK, qui documente permissions, hooks, subagents et MCP).⁸

Traçabilité : un agent sans trace est un agent sans responsabilité

Quand un agent fait une action, une question revient toujours :

“Pourquoi ?”

En production, la traçabilité n’est pas un bonus. C’est ce qui vous permet :

• d’auditer,
• de débugger,
• de prouver la conformité,
• et d’améliorer (sans casser).

L’OpenAI Agents SDK insiste sur la conservation d’une trace complète (“full trace”) de ce qui s’est passé.²

OpenAI documente aussi des mécanismes d’évaluation et de “trace grading” (noter des traces d’agents), ce qui est une approche pragmatique pour industrialiser la qualité.⁹

Ce qu’on trace, concrètement

Voici un format mental (simple, mais efficace) :

1. Input : demande + contexte + sources injectées
2. Décisions : plan, étapes, raisons (si possible)
3. Actions : outils appelés, paramètres, résultats
4. Vérifications : checks, règles appliquées, anomalies
5. Sortie : réponse, action finalisée, escalade

Traces distribuées : relier l’agent à vos systèmes (sans perdre le fil)

Dans une entreprise, l’agent ne vit pas seul.

Il appelle :

• un CRM,
• un ERP,
• un service de doc,
• un système de paiement,
• un moteur de recherche,
• un data warehouse.

Donc votre “trace agent” doit pouvoir se corréler avec la trace applicative classique.

Le langage standard de cette corrélation, en pratique, c’est souvent OpenTelemetry : une trace est un ensemble de spans (unités de travail) reliés par un trace_id.¹¹

Et pour propager ce contexte entre services, le web s’est largement standardisé autour de W3C Trace Context (headers traceparent, tracestate).¹²

Traduction : vous ne voulez pas seulement “un log d’agent”. Vous voulez un fil rouge qui traverse toute votre stack.

Sémantique GenAI : parler la même langue dans vos dashboards

Le deuxième piège : tracer, mais tracer n’importe comment.

Si chaque équipe invente ses tags (“modelName”, “llm_model”, “model”), vous perdez l’exploitabilité.

OpenTelemetry publie des conventions sémantiques GenAI (attributs standardisés pour les appels LLM, agents, frameworks).¹³

Ça ne remplace pas votre modèle de données métier. Mais ça évite le chaos.

Traces “produit” : debugging, audit, et évaluation

Certaines stacks proposent des produits d’observabilité orientés LLM.

LangSmith, par exemple, décrit une approche où chaque requête génère une trace qui “capture le record complet de ce qui s’est passé”.¹⁴

Et l’OpenAI Agents SDK a une page dédiée au tracing (avec un point important : sous certaines politiques type Zero Data Retention, le tracing peut ne pas être disponible).¹⁵

Le bon objectif n’est pas “avoir un outil”. C’est : pouvoir diagnostiquer et améliorer sans deviner.

Mémoire et vérité : quand garder du contexte devient risqué

Une mémoire mal gouvernée est une source de bugs “fantômes”.

Exemples :

• Un agent retient une préférence utilisateur qui n’est plus vraie.
• Un agent stocke une PII sans base légale.
• Un agent réutilise un vieux prompt et casse un workflow.

En Europe, les recommandations des autorités (ex. CNIL) rappellent les exigences de conformité et de minimisation des données lorsqu’on manipule des données personnelles avec des systèmes d’IA.¹⁰

La règle qui tient sur un post-it :

La mémoire d’un agent doit être nécessaire, explicable et supprimable.

De zéro à hero : construire votre premier agent (sans vous piéger)

FAQ