Comment fonctionnent vraiment les agents IA: architecture, mémoire, outils, et boucle d'agent

Introduction

On résume souvent les agents IA à "un LLM avec des outils". C'est globalement vrai, mais incomplet.

Pour comprendre comment fonctionnent les AI agents, il faut une vision système: un agent est une boucle de contrôle qui (1) lit un état, (2) décide, (3) agit, et (4) mesure ce qui s'est passé. Le LLM est souvent le module de décision, mais l'agent est l'ensemble du runtime autour.

Cet article est un guide technique sur l'AI agent architecture: composants, flux de données, et patterns qui rendent des LLM agents fiables en production.

Pourquoi les agents IA sont importants maintenant

Les agents IA comptent aujourd'hui parce que trois choses sont devenues praticables en meme temps:

1. Les modèles savent planifier et choisir des outils pour beaucoup de tâches bien bornées.
2. Le tool calling est devenu une interface de première classe (function calls structurés, JSON schemas, sorties contraintes).
3. Le coût/la latence ont baissé au point de permettre des boucles multi-étapes plutôt que du one-shot.

Où ils sont utilisés aujourd'hui

On trouve déjà des agents IA en production pour:

• Outillage dev: recherche dans le code, refactors, génération de tests, triage CI, revues de PR.
• Support et opérations: tri de tickets, exécution de runbooks, résumé d'incidents.
• Data: génération de SQL avec validation, explication de dashboards, suivi d'anomalies.
• Sécurité et IT: workflows d'accès, enrichissement d'alertes, remédiations (souvent avec approbations).
• Recherche: collecte de sources, résumé et synthèse (avec checkpoints humains).

Qu'est-ce qu'un agent IA?

Définition (simple et utile): un agent IA est un système logiciel qui utilise un LLM (ou une autre "policy") dans une boucle pour choisir des actions qui changent l'état d'un environnement afin d'atteindre un objectif.

Cette définition a trois éléments non négociables:

1. Boucle: l'agent exécute plusieurs étapes, pas un seul prompt.
2. Actions: il déclenche des effets (API calls, écritures DB, éditions de fichiers, transactions).
3. État: il lit et met à jour une représentation du monde (observations + mémoire).

LLM vs chatbot vs AI agent

Voici le modele mental le plus utile:

Objet	Ce que c'est	Ce que ça produit	Échec typique
LLM	Une fonction probabiliste texte -> texte	Tokens (texte / JSON)	"Hallucinations" convinquantes
Chatbot	Un LLM dans une UI conversationnelle	Messages	Utile mais passif (pas d'action)
AI agent	Une boucle + etat + outils + policies avec un LLM planificateur	Actions et resultats	Actions a risque, mauvais appels d'outils, boucles

Callout: un LLM est stateless, un agent est stateful. Cette difference explique la plupart des choix d'architecture.

Architecture de base d'un agent IA

Vous pouvez construire des agents de plusieurs facons, mais la plupart des designs "production" contiennent les memes composants.

(inputs) User/Env
      |
      v
  +---------------------------+
  | Perception / I-O          |
  +-------------+-------------+
                |
                v
  +---------------------------+      +---------------------------+
  | Context Builder           | <--> | Memory                    |
  | (rules + RAG + schemas)   |      | (state + vector DB)       |
  +-------------+-------------+      +---------------------------+
                |
                v
  +---------------------------+
  | LLM Reasoner              |
  | (plan + choose next step) |
  +-------------+-------------+
                |
                v
  +---------------------------+
  | Tool Router + Guardrails  |
  | (validate + approve +     |
  |  retry + limits)          |
  +-------------+-------------+
                |
                v
  +---------------------------+      +---------------------------+
  | Tool Execution            | ---->| External systems / tools  |
  | (APIs, DBs, code, web)    |<---- | (APIs, DBs, services...)  |
  +-------------+-------------+      +---------------------------+
                |
                v
  +---------------------------+
  | Observations              |
  | (results + errors + state)|
  +-------------+-------------+
                |
                v
  +---------------------------+
  | Eval + Telemetry          |
  | (score + trace + alerts)  |
  +-------------+-------------+
                |
                +----> loop to Context Builder

(outputs) response / tool calls / state updates

Entrées

Les entrées ne sont pas uniquement "le message utilisateur". Un agent ingère typiquement:

• un objectif (définition du succès)
• des contraintes (ne pas envoyer d'email, demander avant toute dépense, etc.)
• l'état environnement (ticket, repo, lignes DB, métriques)
• des observations (résultats d'outils, erreurs)
• des policies (sécurité, compliance, isolation tenant)

Raisonnement

Le "raisonnement" est souvent un appel LLM, mais la decision cle est:

• traiter le LLM comme un planificateur non fiable
• garder l'orchestrateur deterministe et strict

Implémentation: ne laissez pas le LLM exécuter directement des outils. Placez un routeur d'outils entre le LLM et les effets (ReAct, plan-and-execute, etc.).

Mémoire

Les agents ont besoin de mémoire car les appels LLM sont (pratiquement) stateless.

Deux choses différentes sont appelées "mémoire": l'état court terme pendant un run, et la connaissance long terme entre les runs (faits, préférences, décisions).

Outils

Les outils sont la facon dont l'agent agit sur le monde. Un outil est une fonction avec un contrat:

• nom + description
• schéma d'entrée
• implémentation déterministe
• classification de risque (read-only vs write, réversible vs irréversible)

Actions

Les actions sont les effets produits par les outils:

• lecture: fetch un record, lister des fichiers, requeter des metriques
• ecriture: modifier un ticket, ouvrir une PR, envoyer un email
• communication: demander une info, demander une approbation

En production, les actions doivent etre idempotentes et auditables.

Boucle de feedback

Sans feedback, un agent devient un "demo loop": il fait des choses sans savoir si ca a aide.

Le feedback inclut souvent: métriques de résultat (success rate, corrections), signaux de sécurité, évaluation (rubriques, régression), et traces par étape.

La boucle d'agent expliquée (Perceive, Think, Act, Evaluate, Repeat)

La plupart des LLM agents se comprennent via cinq phases:

1. Percevoir: collecter les observations.
2. Penser: choisir la prochaine étape.
3. Agir: exécuter une action (outil ou réponse).
4. Évaluer: vérifier impact, sécurité, erreurs.
5. Répéter: mettre à jour l'état et continuer jusqu'à un stop.

Pseudo-code minimal

type Observation = { kind: "user" | "tool"; payload: unknown };
type ToolCall = { tool: string; args: unknown };

type StepDecision =
  | { kind: "tool_call"; call: ToolCall }
  | { kind: "final"; output: string };

const MAX_STEPS = 12;

export async function runAgent(goal: string, userMessage: string) {
  const state = { goal, history: [] as Observation[] };

  for (let step = 0; step < MAX_STEPS; step++) {
    // 1) Perceive
    const observation: Observation = step === 0
      ? { kind: "user", payload: userMessage }
      : state.history[state.history.length - 1];

    // 2) Think
    const context = buildContext({ state, observation });
    const decision: StepDecision = await llmDecide({ context, toolSchemas });

    // 3) Act
    if (decision.kind === "final") return decision.output;

    const validated = validateToolCall(decision.call); // schema + policy checks
    const result = await executeTool(validated);

    // 4) Evaluate + 5) Repeat
    recordTrace({ step, validated, result });
    state.history.push({ kind: "tool", payload: result });

    if (isGoalSatisfied({ goal, result })) break;
  }

  return "Stopped: max steps reached (needs human review).";
}

Détails importants: la boucle est un programme normal avec des conditions d'arrêt (max steps/temps, succès, erreur non récupérable, risque élevé -> approbation).

La mémoire dans les agents IA

La mémoire est l'endroit où beaucoup de prototypes cassent en production. Le problème est rarement "le modèle". C'est le produit mémoire.

Mémoire court terme vs long terme

Pensez en couches:

Court terme (par run)
- objectif courant, plan courant
- resultats intermediaires
- scratchpad (souvent non stocke)

Long terme (entre les runs)
- profil/preferences
- faits projet (APIs, endpoints, repos)
- decisions et outcomes (ce qui a marche/echoue)
- knowledge domain qui doit rester coherent

Le court terme, c'est ce que vous mettez dans le prompt suivant. Le long terme, c'est ce que vous stockez hors prompt.

Vector databases, embeddings, et retrieval (RAG)

Les bases de données vectorielles permettent un rappel "fuzzy":

• stockage de chunks + embedding vector
• embedding de la query + similarity search
• injection des top-k dans le prompt

RAG (retrieval-augmented generation) est souvent la difference entre "plausible" et "correct".

Détails pratiques qui comptent: chunking, filtres metadata, re-ranking, et compression de contexte.

Pipeline de retrieval (sketch)

async function retrieveContext(input: { userId: string; query: string }) {
  const rewritten = await llmRewriteQuery(input.query);
  const q = await embed(rewritten);

  const candidates = await vectorDb.search(q, {
    topK: 12,
    filter: { userId: input.userId, docType: ["policy", "decision", "runbook"] },
  });

  const reranked = await rerank(candidates, { query: rewritten });
  const top = reranked.slice(0, 6);

  return compressForPrompt(top, { maxTokens: 900 });
}

Callout: la mémoire long terme doit stocker des faits, pas des transcripts. Stockez "refund denied le 2026-01-10 car policy v4", pas 200 lignes de chat.

Outils et actions externes

Les outils sont la frontière entre langage et réalité, et la principale surface de risque.

APIs

Pour les APIs, faites du backend engineering classique: inputs types, timeouts/retries, idempotency pour les writes.

Exemple de schéma d'outil:

{
  "name": "search_tickets",
  "description": "Search support tickets (read-only).",
  "parameters": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "limit": { "type": "integer", "minimum": 1, "maximum": 20 }
    },
    "required": ["query"]
  }
}

Bases de données

Pour l'accès DB, séparez read et write:

• read: SELECT safe, guards, limites
• write: operations explicites, diffs valides, approbations si risque

Execution de code

Si l'agent exécute du code: sandbox, limites ressources, filesystem read-only par défaut, et jamais de secrets.

Navigation (browsing)

Le web est un input non fiable. Les sorties d'outils peuvent contenir des instructions ("ignore previous rules") qui tentent de detourner l'agent.

Mitigations: traiter les pages comme de la donnée, isoler la navigation des outils privilégiés, exiger des citations pour les affirmations factuelles.

Mono-agent vs multi-agent

Les architectures multi-agent peuvent aider, mais elles multiplient aussi la complexite.

Différences

• Mono-agent: une boucle, un etat, un set d'outils. Plus simple a debugger et moins cher.
• Multi-agent: plusieurs boucles spécialisées (planner, researcher, executor, critic). Plus de parallèle, plus de failure modes.

Use cases

Mono-agent:

• workflows bornes (triage, resume, formulaires)
• taches orientees outils avec contraintes claires
• assistants interactifs avec approvals/checkpoints

Multi-agent:

• recherche/analyse large (sources en parallele + synthese)
• software engineering (design/implement/review separes)
• ops avec roles monitor/remediate

Quand choisir?

Commencez mono-agent. Passez multi-agent uniquement si la spécialisation prouve un meilleur outcome.

             +------------------+
User/Task -->|  Orchestrator    |
             |  (policy + plan) |
             +---+----------+---+
                 |          |
        +--------+--+   +---+---------+
        | Researcher |   | Executor   |
        | (read-only)|   | (tool run) |
        +--------+---+   +---+--------+
                 |           |
                 +-----+-----+
                       v
                   Critic/Eval

Points de rupture courants

Hallucinations

Souvent, c'est un problème de retrieval ou de stop conditions.

Mitigations: RAG + facts dans le prompt, outputs structures (schemas), citations (IDs d'outils/documents).

Mauvais usage d'outils

Symptômes: mauvais arguments, write tool inutile, répétition d'appels à cause d'erreurs mal gérées.

Mitigations: validation stricte, risk levels + approvals, fallbacks deterministes (retry/backoff).

Boucles infinies

Mitigations: max steps/durée, heuristiques de progrès, détection de répétition.

Mauvaise mémoire

Symptômes: contexte stale, fuites de données, retrieval bruit.

Mitigations: faits structures + metadata, TTL/recence, filtres, redaction.

Architecture de référence (style production)

Client/UI
  |
  v
API (auth, rate limits)
  |
  v
Agent Orchestrator
- builds context (policy + retrieval + tool schemas)
- calls LLM (planner)
- routes tools with guardrails
  |
  +--> Tool Registry (read / write risk-gated)
  +--> Memory Stores (relational + vector DB)
  +--> Evaluation + Telemetry (traces, metrics, regression)

Flux de données (end-to-end)

Request
  -> Authenticate + authorize
  -> Retrieve memory (RAG + structured facts)
  -> Build prompt/context (constraints + tool schemas)
  -> LLM decides next step (tool call or final answer)
  -> Validate + risk gate
  -> Execute tool (idempotent, traced)
  -> Store observation + update memory
  -> Evaluate outcome
  -> Respond (or continue loop)

Règle d'ingénierie pragmatique

Gardez le probabiliste à la marge:

• LLM: planning, classification, summarization
• Code deterministe: validation, authZ, effets, persistence, metriques

C'est l'essence de "comment fonctionne vraiment un agent IA" en production.

Conclusion

Points clés

• Un agent est une boucle, pas un prompt.
• Les LLM agents ont besoin d'architecture: mémoire, outils, validation, évaluation, traces.
• La mémoire est un système (RAG dépend du chunking, filtres et compression).
• Les outils sont des APIs: schema-validated, risk-gated, idempotent, auditable.
• Le multi-agent est optionnel. Commencez simple.

Où va le domaine

La prochaine vague sera moins "modeles plus gros" et plus:

• runtimes d'agents standardises + tool contracts
• évaluation automatique (regression suites)
• navigation/outils plus safe (prompt injection-aware)
• produits mémoire plus fiables (rappel long terme)

Lecture associée

• Pourquoi les agents IA echouent (et comment les corriger)
• Comment construire des agents IA (tutoriel LangChain)

Construire avec l IA et livrer proprement

Besoin d un developpeur capable de transformer une idee en livrable ?

J aide les equipes a livrer du React, Next.js, Node.js, de l IA et de l automatisation avec un cadrage clair, des garde-fous utiles et une execution rapide.

Voir le profilVoir l offre freelanceMe contacter