Architecture agentique en 2026 :
la vue d'ensemble

01 — Qu'est-ce qu'« agentique »

Le mot « agent » est utilisé depuis trois décennies en intelligence artificielle. Ce qu'il désigne en 2026 dans le monde des LLM n'a presque rien à voir avec ce qu'il désignait en 1995. Définissons proprement.

Un système agentique, dans le sens où nous l'employons aujourd'hui, est un système logiciel construit autour d'un modèle de langage qui possède trois caractéristiques :

• Autonomie de décision. Le modèle ne se contente pas de répondre à une question : il décide, à chaque étape, de l'action suivante — appeler un outil, demander une clarification, vérifier sa réponse, terminer.
• Boucle de raisonnement. Le système peut s'exécuter sur plusieurs tours, en observant le résultat de ses actions précédentes pour ajuster les suivantes. Il n'est pas one-shot.
• État persistant. Le système maintient un état (mémoire de travail, historique, résultats intermédiaires) qui circule entre les tours. Cet état est explicite et inspectable.

Cette définition est structurelle, pas capacitaire. Elle ne dit pas « un agent est un système IA très intelligent ». Elle dit « un agent est un système IA construit autour d'une boucle d'état explicite ». La différence est fondamentale : la première est une promesse marketing, la seconde est une propriété d'ingénierie.

Pourquoi maintenant ?

Trois conditions se sont réunies entre fin 2023 et début 2026 pour rendre l'agentique viable en production :

(1) Les modèles savent appeler des outils proprement. Function calling natif, structured outputs (JSON garanti), tool use multi-étape avec retours d'erreur — tout cela est devenu mature avec Claude 3.5, GPT-4, Mistral Large 2 puis stabilisé en 2025-2026 avec Claude 4.x, GPT-5 et Mistral Large 3.

(2) Les frameworks de modélisation d'état ont mûri. LangGraph (2024-2026) a apporté le bon niveau d'abstraction : graphes d'état explicites, checkpointing, human-in-the-loop. Les SDK des éditeurs (Anthropic Agent SDK, OpenAI Agents SDK successor de Swarm) ont rejoint la fête.

(3) L'observabilité LLM est devenue praticable. MLflow Tracing v3, Langfuse, Arize Phoenix, LangSmith — chacun permet désormais de tracer chaque pas d'un agent avec ses tokens, sa latence, son coût. Sans cette base, l'agentique en production était un suicide opérationnel.

02 — Du LLM stateless à l'agent stateful

La transition 2024 → 2026 peut se résumer à un seul changement d'architecture, qu'il faut bien comprendre. Avant : un appel API au LLM, une réponse, fin. Maintenant : une boucle d'état qui orchestre planification, appels d'outils, observation, réflexion, jusqu'à atteindre une condition de terminaison.

Ce n'est pas qu'un changement de degré : c'est un changement de nature. Concevoir un système agentique ne ressemble pas à concevoir un chatbot. Cela ressemble à concevoir un workflow métier — sauf que chaque transition est une décision LLM, donc non déterministe par défaut.

Tout l'enjeu de l'ingénierie agentique 2026 consiste à encadrer cette non-détermination : graphes d'état explicites, garde-fous d'entrée et de sortie, budgets stricts (tokens, étapes, coût), checkpoints persistés, replay forensique. Sans ce cadre, vous avez une démo qui marche le mardi et qui hallucine le mercredi.

03 — Les six patterns canoniques

Si vous lisez la littérature et les implémentations de référence, vous retrouverez systématiquement six patterns d'architecture agentique. Tout le reste est dérivé. Comprendre ces six patterns, c'est comprendre 95 % du domaine.

① ReAct (Reason + Act)

Le pattern fondateur, formalisé par Yao et al. en 2022. À chaque tour, l'agent produit une pensée (« je dois chercher X dans la base »), choisit une action (appel d'outil), et observe le résultat. Il itère jusqu'à pouvoir formuler une réponse.

C'est le pattern le plus simple, donc souvent le plus efficace. Idéal pour les tâches Q&A avec accès à 1 à 5 outils, raisonnement court (5-10 étapes max). Implémentation native dans LangGraph via create_react_agent.

Quand ReAct échoue : quand l'objectif est vague, quand les outils sont mal nommés ou mal documentés, quand la tâche demande une planification longue. L'agent tourne en rond — d'où la nécessité d'un budget strict (max_iterations).

② Plan-and-Execute

Quand la tâche est longue et prévisible, on sépare la planification de l'exécution. Un premier appel LLM (idéalement un modèle de reasoning : Claude Opus, GPT-5, o-series) produit un plan explicite : « étape 1, étape 2, étape 3 ». Un second LLM (plus rapide : Sonnet, Haiku, Mistral Medium) exécute chaque étape en boucle.

Quand une étape échoue ou que de l'information nouvelle apparaît, l'agent re-planifie : il retourne au planner pour amender le plan.

Avantages : économique (le modèle de reasoning n'est appelé qu'une fois par re-planif), auditable (le plan est explicite et validable), traçable. Inconvénient : ne fonctionne que quand le plan peut être anticipé — donc inapplicable aux tâches d'exploration libre.

③ Reflexion / Self-correction

Après chaque tentative, un nœud séparé critique le résultat. La critique est typiquement un llm-as-judge : un autre LLM (souvent plus puissant que le producteur) évalue la réponse selon des critères explicites (justesse, complétude, traçabilité, format). Si la critique est négative, l'agent retravaille — jusqu'à max_iterations.

Pattern très efficace pour réduire les hallucinations sur les tâches critiques (juridique, financier, médical). Coût : 2× à 5× plus de tokens vs ReAct, mais qualité finale beaucoup plus haute.

Variante intéressante : combiner Reflexion avec un panel de juges (Claude Opus + GPT-5 + Gemini Pro), vote majoritaire. Coût élevé, qualité maximale.

④ Multi-agent supervisor-worker

On sépare les rôles. Un agent superviseur reçoit la requête, l'aiguille vers l'agent spécialisé approprié (chercheur, codeur, rédacteur, vérificateur), puis synthétise les contributions.

Chaque worker a son propre prompt, ses propres outils, son propre modèle. C'est l'occasion d'utiliser le bon modèle au bon rôle — Claude Opus en chercheur, Mistral Codestral en codeur, Claude Sonnet en rédacteur, GPT-5 en vérificateur.

Excellente séparation des préoccupations. Implémentable nativement avec LangGraph via le Command pattern. Limite : le superviseur peut devenir un goulot d'étranglement — au-delà de 5-7 workers, fragmenter en plusieurs équipes.

⑤ Swarm (handoffs pair-à-pair)

Pas de superviseur central. Chaque agent peut passer la main (handoff) à n'importe quel autre agent du swarm en fonction du contexte. Modélisé par OpenAI dans Swarm puis intégré aux Agents SDK ; LangGraph propose langgraph-swarm en équivalent.

Plus fluide pour les workflows émergents (support client multi-domaines, par exemple), où la séquence d'expertises à mobiliser ne peut pas être anticipée. Plus difficile à observer et à déboguer qu'un supervisor — chaque agent doit pouvoir savoir à qui passer la main, ce qui se traduit par des prompts plus longs.

Souvent combiné à une mémoire partagée (Letta, Mem0) pour que le contexte voyage avec le client à travers le swarm.

⑥ Hierarchical teams

Un superviseur top-level dirige plusieurs équipes, chacune ayant son propre sous-superviseur et ses workers. C'est la composition de sous-graphes LangGraph indépendants.

Idéal pour les problèmes très larges qui se décomposent naturellement en domaines (recherche / synthèse / vérification, ou métier A / métier B / métier C). S'apparente à une organisation d'entreprise classique.

Coût de coordination élevé. À n'utiliser que quand la décomposition est structurellement nécessaire — pas pour le plaisir architectural.

04 — Mémoire : trois couches

Un agent sans mémoire est un poisson rouge. Trois couches de mémoire sont à concevoir séparément.

Mémoire de travail (working memory)

L'état du graphe LangGraph pendant une invocation : messages, scratchpad, plan en cours, résultats d'outils. Vit le temps d'une session. Stockée dans le checkpointer (Postgres, SQLite, Redis). Permet pause/reprise, time-travel queries, replay forensique.

Cette mémoire est structurelle. Elle ne contient pas de connaissance métier — uniquement le contexte courant.

Mémoire épisodique

« Qu'as-tu dit à cet utilisateur la semaine dernière ? » — historique des conversations passées, indexées par user_id, récupérées par similarité ou récence. Stockée typiquement dans un vector store dédié, avec summarization périodique pour éviter l'explosion.

Outils dédiés en 2026 : Mem0 (extraction automatique de facts), Letta (anciennement MemGPT, gestion hiérarchique de la mémoire), LangMem (intégré LangChain).

Mémoire sémantique

Les faits stables et préférences : « l'utilisateur préfère le tutoiement », « il travaille en pharma », « ne jamais lui suggérer X ». Extraite des conversations par un LLM dédié, validée, persistée dans une base structurée (KG, JSON typé).

C'est la couche la plus difficile à bien concevoir. Mal faite : vous générez des hallucinations persistantes (« l'agent croit que l'utilisateur travaille en chimie »). Bien faite : votre agent devient vraiment utile dans la durée.

05 — Outils, sandboxing, garde-fous

Un agent sans outils n'agit sur rien. Mais un agent avec tous les outils est un risque opérationnel majeur. La discipline est : allow-list explicite, jamais d'allow-all.

Anatomie d'un outil

Un outil bien défini a quatre propriétés :

• Schéma d'arguments typé (Pydantic, JSON Schema). Le LLM ne peut pas inventer un argument hors schéma.
• Description précise en langage naturel (50-200 tokens). Décrit quand appeler l'outil, pas comment.
• Idempotence ou versioning. Si l'outil a un effet de bord (envoyer un email), une réexécution doit être sûre.
• Erreur structurée. En cas d'échec, l'outil retourne une erreur typée que l'agent peut interpréter et corriger.

Sandboxing

Tout outil avec effet de bord important (exécution de code, requête SQL, appel API tiers, action OS) doit s'exécuter dans un sandbox : container isolé, allow-list de domaines réseau, budget mémoire/CPU, timeout strict.

Standards 2026 : E2B et Modal sandboxes pour le code Python, conteneurs gVisor / Firecracker pour les workloads critiques, Anthropic Computer Use avec son isolation native pour l'interaction OS.

Garde-fous

Au-delà du sandboxing technique, on filtre sémantiquement. NeMo Guardrails (NVIDIA) permet d'écrire des règles déclaratives sur ce que l'agent peut et ne peut pas faire. Llama Guard 3 et Lakera Guard détectent les prompts hostiles et les tentatives d'injection.

Tout cela est cumulatif : garde-fou sémantique + allow-list d'outils + sandboxing + traçabilité MLflow/Langfuse. Pas l'un OU l'autre.

06 — Évaluer un agent

Évaluer un agent, ce n'est pas évaluer une réponse : c'est évaluer une trajectoire — la séquence d'étapes prise pour atteindre l'objectif. Trois familles de métriques.

La règle d'or : la métrique précède le code. Avant d'écrire le premier nœud, construisez un jeu d'évaluation de 100 à 500 trajectoires de référence, idéalement annotées par vos experts métier. Sans ce jeu, vous codez en aveugle et la régression est invisible.

07 — Frameworks 2026

Le paysage s'est largement consolidé. Voici notre lecture, basée sur les missions que nous menons en 2026.

LangGraph s'est imposé comme le standard de production. Sa victoire tient à un seul choix d'ingénierie : rendre l'état explicite et inspectable. C'est ce qui permet l'observabilité, le replay et le human-in-the-loop sans hacks. Les autres frameworks restent pertinents dans leurs niches.

Quand passer au harness in-house

Quatre cas justifient de construire votre propre harness sur-mesure plutôt que d'utiliser un framework générique :

1. Audit forensique exigé. Signature cryptographique des transitions, time-travel queries, immutabilité — au-delà de ce qu'offrent les frameworks.
2. Latence sub-second. Python introduit 50-200 ms d'overhead par nœud ; pour les usages temps-réel (trading, voix), un harness optimisé devient nécessaire.
3. Air-gap strict. Pas de packages PyPI tiers, audit de chaque dépendance, contraintes ANSSI.
4. Intégration profonde au SI. Bus d'événements existant (Kafka, NATS), workflow engine maison — le framework générique combat votre architecture.

Dans tous les autres cas, LangGraph fait le travail. Le harness in-house est une option, pas une obligation.

08 — Conclusion & arbitrage

En 2026, concevoir un système agentique n'est plus expérimental. C'est une discipline d'ingénierie avec des patterns canoniques, des frameworks matures, des outils d'observabilité et d'évaluation. Tout le savoir-faire existe — il faut savoir le mobiliser.

Notre conviction, validée par les missions que nous menons chez nos clients :

• Commencez simple. ReAct avec 3-5 outils bien définis résout déjà beaucoup de problèmes. N'introduisez du multi-agent que quand vous avez vraiment des spécialités hétérogènes.
• L'observabilité d'abord. Avant d'écrire le premier nœud, installez MLflow Tracing + Langfuse. Sans cela, vous serez aveugle.
• La métrique précède le code. Construisez un jeu d'évaluation représentatif avant tout. Mettez-le en CI/CD dès le jour 1.
• Sandboxez les outils, allow-listez tout. Un agent autonome est un risque autonome. Le sandboxing technique et les garde-fous sémantiques sont cumulatifs, pas alternatifs.
• Restez framework-pivot, code-souverain. LangGraph par défaut. Mais votre code, votre état, vos prompts vous appartiennent.

C'est aussi ce qui rend ces systèmes opérables dans la durée. Sans cette discipline, vous avez une démo. Avec elle, vous avez un produit.