Les architectures Agentics en 2026

Auteur : Philippe PRADOS

L’année 2025 a été riche en nouveautés et en normalisations lors de l’utilisation d’agents. Les différentes équipes ont proposé des solutions, des usages, des approches, que les concurrents se sont empressés de répliquer. Certaines méthodes ont abouti à des standards, ce qui a permis d'harmoniser les approches.

Le marché s’organise autour de fondations (Agentic AI foundation (AAIF) sous l'égide de la Linux Foundation), dont, n’en doutons pas, de nouvelles normes et spécifications vont être stabilisées en 2026.

Il est essentiel de maîtriser la combinaison de ces différentes spécifications, actuelles et futures, afin de pouvoir profiter rapidement des nouveautés que nous réserve 2026.

La courte histoire des LLM nous montre comment des idées initiales deviennent rapidement des normes, profondément intégrées dans l’écosystème, jusqu’au plus profond des modèles.

• L’approche “chain of thought” était une stratégie de prompt. Elle est intégrée dans les apprentissages.
• La génération stricte de JSON pour permettre l’invocation d’outils était une astuce de développement, combinée à un “stop-word” magique, permettant d’ajouter dynamiquement du savoir à un LLM. Les modèles ont appris à produire du JSON propre, aidée d’API pour le Structured Output et utilisent des tokens spécialisé pour l’invocation d’outils.
• L’invocation simultanée de plusieurs outils dans le même cycle est une stratégie d’optimisation, pour économiser des tokens et améliorer les performances. Des modèles ont été entrainé pour organiser les appels en batchs, en gérant les dépendances.

Ces astuces sont maintenant au cœur des apprentissages des dernières versions des modèles ou des API proposées (Prompt caching, Reflexions, Reference artifact, Parallel tools calling, etc.).

Parions que la génération dynamique d’interface (A2UI), la sélection des Skills ou d’autres nouveautés à venir, seront au cœur des prochaines générations. Sachant que tous les trois mois (le temps d’apprentissage), une nouvelle rafale de modèles est publiée, il ne faudra pas longtemps pour voir des idées transformées en features standard, au cœur des modèles.

Bien que les agents soient de simples logiciels, leurs caractéristiques rendent leur intégration difficile avec les API REST/GraphQL traditionnelles :

• Les agents s’exécutent en continu et traitent les tâches intermédiaires, souvent sur plusieurs sessions.
• Les agents présentent un comportement imprévisible et interagissent avec l'interface utilisateur de manière non déterministe.
• Les agents combinent simultanément des entrées/sorties structurées et non structurées (par exemple, texte et voix, ainsi que des appels d’outils et des mises à jour d’état).
• Les agents nécessitent une composition interactive : par exemple, ils peuvent appeler des sous-agents, souvent de manière récursive.
• Et bien plus encore…

Le temps de la simple application RAG est révolu. Elle est généralement plus ou moins performante suivant l’effort fait pour gérer correctement les spécificités de chaque corpus documentaire. Une approche agentique permet de gérer la complexité des scénarios comme la comparaison de documents, la prise en compte de la négation (“ce type de document, mais pas pour les mineurs”).

Dans les faits, les approches agentiques avancées sont principalement utilisées pour le “Vibe Coding”, le développement aidé d’IA générative. Les moteurs d'exécution de ces différents outils de codage sont de plus en plus similaires. S’ils respectent les quelques normes actuellement disponibles, les moteurs offrent pratiquement tout ce qui est nécessaire pour la plupart des scénarios nécessitant des agents IA. Utiliser ces normes pour tous les projets Agentics permet de bénéficier de l’expérience accumulée pour cet usage particulier, le codage. Récupérer un moteur IA Coding Agent aide à résoudre vos scénarios complexes métiers.

En ce début d’année 2026, regardons les normes qu’il nous semble indispensable d'implémenter dans toutes les solutions Agentic.

Intégrer les nouvelles spécifications au plus tôt permettra de ne pas être dépassé par des solutions et des approches nouvelles, que vos utilisateurs réclameront.

• Model Context Protocol (MCP) — Agents ↔ Tools
• Agent Skill — Agents ↔ Expertise
• Agent-2-Agent (A2A) — Agents ↔ Agent
• Agent Client Protocol (ACP) — Agents ↔ IDE
• Interface utilisateur
  • Agent–User Interaction Protocol (AG-UI) — Agents ↔ Users
  • MCP Apps Protocole (MCP Apps) — Agents ↔ Fixed Rich UI
  • Agent-Driven Interfaces (A2UI) — Agents ↔ Dynamic Rich UI
• Really Simple Licensing (RSL) — Agents ↔ Crawler
• AGENTS.md — Agents ↔ code base

Il nous semble important d’ajouter des user-stories pour migrer les solutions existantes vers ces nouvelles approches.

Model Context Protocol (MCP) — Agents ↔ Tools

Sous la fondation AAIF

Le 25 novembre 2024, le protocole MCP a été proposé par Anthropic. Il permet aux LLM d’utiliser des outils normalisés pour récupérer des informations ou agir dans le monde réel.

L’idée est simple:

• Indiquer dans quelle situation utiliser un outil
• Quel est le format des paramètres attendus (obligatoire, optionnel) et le rôle de chacun
• Quel est le format de la réponse

Ces informations sont injectées dans le prompt système ou via l’API du LLM. Puis, la boucle Agentic identifie la demande et invoque un outil. Elle utilise le protocole MCP pour formater les paramètres, invoquer la fonction et injecter la réponse dans le prompt, afin de permettre au LLM de continuer son raisonnement.

Le protocole offre également des fonctionnalités avancées complémentaires:

• Liste de ressources (url de ressources exposées par le composant)
• Liste de modèles d’URL de ressources (url avec paramètre)
• Liste de prompts (promptes pré-rédigées pouvant être invoquées directement)
• Liste d’outils (pouvant être invoqués par un LLM lorsqu’il le juge nécessaire)
• Les listes peuvent être mises à jour dynamiquement.
• Lecture de fichiers locaux à la demande d’un serveur MCP
• Invocation du LLM client par le serveur

Serveur MCP

Initialement un serveur MCP invoquait lui même un LLM, avec son propre token d’API, s’il en avait besoin. Les dernières spécifications permettent au composant MCP de déléguer cette invocation au client.

Carbon préconise d’utiliser systématiquement cette approche. En effet, un composant MCP doit être agnostique de son environnement d’exécution. Il doit pouvoir être utilisé par votre application, ou par n’importe quel client MCP. De même, l’accès aux fichiers par le composant doit être délégué au client MCP. Cela lui permet d’ajouter des contraintes de sécurité.

Afin qu'un composant MCP puisse être facilement réutilisé dans divers contextes, il est nécessaire qu'il puisse être installé et exécuté à partir d'une seule ligne de commande. Pour Python, il est nécessaire qu'il puisse être lancé via uvx mon-serveur-mcp. Pour JavaScript, à l'aide de npx -y. Il serait judicieux d'avoir un répertoire local à l'entreprise.

Client MCP

Tout projet Agentic doit être un client MCP. Idéalement, il doit s’appuyer pratiquement exclusivement sur une liste de composants MCP. Cela structure l’application en modules réutilisables, dans le respect des normes. C’est la meilleure stratégie pour pouvoir bénéficier des évolutions futures de cet écosystème, extrêmement riche en nouvelles technologies.

Ce n’est pas toujours très simple au niveau de l’organisation du code du projet (de nombreux sous-modules), mais nous pensons que c’est indispensable pour l’avenir.

Nous préconisons que chaque produit soit lui-même un composant MCP. Il doit pouvoir jouer les deux rôles: client et serveur.

Au cas où l’application est un composant MCP, il y a deux approches pour l’invocation des API LLM. Soit l’application, et donc le composant qu’elle représente, utilise ses propre tokens d’API, soit elle utilise, dans ce cas, le LLM du client MCP qui consomme votre application. Cette approche mixte nous semble la plus prometteuse.

Il existe de nombreux dépôts de serveur MCP, ajoutant éventuellement des validations de sécurité (Glama, MCPServer, PulseMCP, etc. )

Agent Skill — Agents ↔ Expertise

Sous la fondation AAIF

Le 18 décembre 2025, Anthropic propose à la communauté une nouvelle norme, pour ajouter de l’expertise à un LLM. L’idée consiste à guider l’agent à résoudre des problèmes spécifiques, en suivant une stratégie imposée qu’un développeur considère comme la plus efficace.

En effet, lorsqu’un LLM est confronté à une difficulté, la stratégie qu’il choisit dépend uniquement du choix aléatoire du premier token qu’il a produit pour proposer une solution. Confronté au même problème plusieurs fois, il va choisir une approche différente, sans bénéficier des retours d’expériences des développeurs ou des utilisateurs.

Le LLM est bien équipé d’outils (trop nombreux) pour lui permettre d’aller chercher une vue plus ou moins complète de la situation, mais au final, il va utiliser son “intuition” (un tirage aléatoire) pour choisir une stratégie.

Les Skills sont une collection de répertoires respectant une structure:

./.agents/skills/my-skill/
├── SKILL.md          # Required: instructions + metadata
├── scripts/          # Optional: executable code
├── references/       # Optional: documentation
└── assets/           # Optional: templates, resources

L’agent va parcourir l’ensemble de ces répertoires afin de récupérer la description de chaque compétence. Comme pour les outils, cette description va aider le LLM à identifier lorsqu’un problème peut être résolu, avec l'aide des directives décrites dans le répertoire. Il va alors dévier de sa trajectoire pour invoquer la compétence (voir plusieurs en parallèle s’il considère cela possible).

Les prompts métiers doivent utiliser l’approche Skill pour pouvoir les réutiliser dans différents outils actuels et à venir.

Prenons l'exemple de la lutte contre la fraude communautaire et les contrefaçons. L'utilisation de skills dédiés par scénario permet de détecter des signaux faibles, aussi bien dans les bases de donnoées douanières que dans les flux de transactions des plateformes, à la recherche de produits ne respectant pas les normes ou à des tarifs trop éloignés des produits originaux.

Les skills peuvent être ajoutés via un simple serveur MCP. Et bien entendu, des registres de Skill arrivent (MCPServer).

TODO: https://skills.sh/

Agent-2-Agent (A2A) — Agents ↔ Agent

Sous la fondation AAIF

Les entreprises proposent de plus en plus d'agents, en complément d’API. Pour résoudre des problèmes complexes, les agents doivent pouvoir communiquer entre eux de façon normalisée. Le protocole Agent2Agent (A2A) est une norme ouverte conçue pour faciliter la communication et l'interopérabilité entre des systèmes d'agents d'IA indépendants et potentiellement opaques. On peut voir cette approche comme le remplacement d’un utilisateur humain par un autre agent.

Tout processus métier nécessitant de pouvoir s’interrompre, car il manque une information, devrait utiliser ces spécifications. Et donc, dès qu’il y a une interaction humaine.

L’intégration entre agents doit être une stratégie d’entreprise. Permettre à différents agents métiers de communiquer entre eux. Cela va permettre de combiner des services métiers différents, dans une intégration stratégique.

Imaginons un processus complexe de gestion de sinistre pour une assurance. Ce dernier doit suivre de nombreuses étapes, contenant des interactions multiples avec des partenaires (expert, juriste, médecin, etc.). Ces interactions bloquent le processus tant que les réponses ne sont pas disponibles. Un agent de gestion de sinistre, peut signaler qu’il attend une réponse de l’expert, un devis du garagiste et une expertise médicale.

Un autre agent peut prendre en charge ces demandes pour les traduire en des échanges par mails, chat, SMS ou autre avec ces différents partenaires. Ils pourront répondre à plusieurs questions dans le même mail, signaler que l’information a été transmise à un autre service, indiquer qu’ils sont en congés pour une semaine, ou tout autre scénario complexe, présent dans la vie de tous les jours. Un agent spécialisé dans la remontée d'informations peut gérer ces situations, jusqu'à obtenir enfin l’information permettant de continuer le processus de métier de gestion de sinistre.

A2A est là pour proposer un cadre de communication entre agents, pour gérer des scénarios de ce type.

Les entreprises doivent réfléchir à des bus d'intégration et de communications entre les différents agents métiers, pour une intégration globale.

Agent Client Protocol (ACP) — Agents ↔ IDE

Sous la fondation AAIF

Pour éviter l’enfer d’une intégration n x m, entre les IA Agent coding et les IDE, ACP propose une spécification, proche de MCP, pour normaliser cette intégration. Les différents IDE ont intégré cette spécification, permettant aux développeurs d’utiliser l’agent qu’ils souhaitent.

Cette spécification peut également servir pour une intégration normalisée avec vos clients lourds par exemple. C’est une sorte d’implémentation concrète de A2A. L'ACP se concentre sur une session linéaire (Thread -> Message -> Run). Le A2A nécessite souvent des topologies de réseau plus complexes (Peer-to-Peer, Mesh) que le modèle Client-Serveur strict de l'ACP.

User Interfaces

Les canaux de communication avec une application agentic ne se limitent pas à un échange textuel. Des spécifications décrivent comment proposer des interfaces riches, alant jusqu’a créer une interface utilisateur sur mesure.

Agent User Interaction Protocol (AG-UI) — Agents ↔ Users

AG-UI est une proposition pour normaliser l’intégration des solutions d’agent IA avec une interface utilisateur généraliste. Des solutions comme CopilotKit implémentent ces spécifications pour proposer un client riche, indépendant de la technologie utilisé coté back.

Les agents intégrant AG-UI peuvent :

• Diffuser les réponses en continu : texte affiché en temps réel dès sa génération
• Appeler des outils côté client : votre agent peut utiliser des fonctions et des services définis par les clients
• Partager un état : la mémoire de votre agent est partagée de manière bidirectionnelle
• S’exécuter de manière universelle : intégration avec toute application cliente compatible AG-UI

Des connecteurs existent pour les frameworks majeurs.

L'intégration d'AG-UI permet à votre agent de communiquer via le protocole AG-UI. Il peut ainsi interagir avec n'importe quelle application cliente compatible AG-UI, comme les interfaces de chat, les copilotes ou les outils d'IA personnalisés.

Il est maintenant plus facile d'intégrer plusieurs agents dans la même interface.

MCP Apps Protocol — Agents ↔ Fixed Rich UI

Le protocole MCP seul ne permet au composant de ne retourner que du texte. Cela est une limitation que MCP Apps Protocole se propose de lever (Novembre 2025).

L’idée est d'autoriser à un composant de retourner un fragment d’interface utilisateur (un formulaire ; un graphique ; une animation, une mini-application ; etc.).

Par exemple, pour lui demander de choisir entre plusieurs options à l’aide d’un formulaire, pour saisir plusieurs informations sans devoir poser les questions les unes après les autres, pour avoir une vue de la météo sur une carte ; etc. C’est un outil indispensable pour une ergonomie de chat moderne.

Pour le moment, l’interface doit être au format HTML (mimeType:text/html;profile=mcp-app). Charge au client MCP ou à l’application hôte, de présenter celle-ci dans le flux de communication avec l’utilisateur dans un bac à sable IFrame. Cela réutilise le protocole de communication asynchrone JSON-RPC de MCP.

MCP Client

Pour le client MCP, cela entraine la prise en compte de ce protocole dans le flux de communication avec l’agent et une implémentation sécurisée pour limiter les possibilités accordées au composant MCP utilisé. Avec cette approche, vous pouvez facilement trouver des composants pour représenter vos chiffres avec des graphiques sous différents formats ; offrir des ergonomies aussi riches que le HTML peut en proposer.

Nous préconisons que l’hôte intègre cette technologie (et/ou A2UI) pour permettre une interaction plus fluide avec l’utilisateur.

MCP Server

Si vous proposez des composants MCP pour votre application, ils doivent, éventuellement, implémenter cette spécification pour proposer une ergonomie plus riche. À défaut, ils doivent proposer une stratégie de repli en texte simple.

Carbon préconise d’envisager cette approche avant toute autre solution propriétaire ou ergonomie non compatible.

Agent-Driven Interfaces (A2UI) — Agents ↔ Dynamic Rich UI

Sous la fondation AAIF

Comment les agents d'IA peuvent-ils envoyer en toute sécurité des interfaces utilisateur riches ? C’est à ce besoin que répond cette spécification.

L’approche MCP-Apps précédente est pragmatique mais reste limitée à des ergonomies conçues et proposées par les composants MCP.

Les spécifications A2UI proposent au LLM de concevoir dynamiquement une ergonomie spécifique pour répondre aux besoins du moment. L’interface utilisateur n’est pas rigide. Elle peut être différente pour chaque utilisateur et s’adapter à ses spécificités, à son contexte ou aux connaissances que possède le LLM sur l’utilisateur.

A2UI permet aux agents d'envoyer des descriptions de composants que les clients affichent à l'aide de leurs propres widgets natifs. C'est comme si les agents parlaient un langage d'interface utilisateur universel. De nombreux composants sont proposés.

Un composer permet de tester la génération d’interface via un prompt.

L’agent envoie une structure de données pour alimenter l’interface utilisateur proposée via un data model. Suivant les interactions de l’utilisateur, le data model évolue, et est renvoyé à l’agent lorsqu’il clique sur un bouton par exemple.

Pour cela, le prompt doit être ajusté pour générer la description de l’interface et le data model associé.

Comment créer un agent A2UI :

• Comprendre l'intention de l'utilisateur → Choisir l'interface utilisateur à afficher
• Faire générer du JSON A2UI respectant le schema → Utiliser une sortie structurée LLM ou des invites
• Valider et diffuser → Vérifier le schéma, envoyer au client
• Gérer les actions → Répondre aux interactions de l'utilisateur

Le style peut être adapté à votre marque.

Le client de l’agent doit être en capacité de convertir la description de l’interface en widget, de gérer les interactions de l’utilisateur, et de transmettre les évènements d’interaction à l’agent. Ce dernier peut demander des ajustements à chaud, de l’interface utilisateur (ajouter des composants, alimenter des listes, etc.)

Notez que les spécifications v0.9 remettent en cause certaines approches, pour être simples et conformes aux spécifications JSON.

C’est un protocole dont il faut être attentif aux évolutions, et prévoir une intégration prochaine dans vos solutions agentics. Mais il est préférable d’attendre une stabilisation des spécifications.

Clients normalisés

De nombreux clients génériques sont proposés, plus ou moins intégrés avec les dernières spécifications de l’AAIF. Gageons que les écarts seront vite comblés.

Les composants UI capables de gérer toutes les subtilités de ces spécifications sont très complexes. Il n’est pas pertinent de construire une solution “maison”. Il est préférable d’étudier les solutions disponibles, d’étudier leurs roadmaps, et d’en choisir une susceptible d'intégrer les nouveautés au fur et à mesure.

Voici quelques solutions à envisager.

CopilotKit

Grâce aux différentes normes, il est possible d'utiliser un composant générique, facilement intégrable dans votre SI, capable de se connecter à tous les backends agentic, directement ou via les protocoles (AG-UI, A2UI, MCP ou A2A).

La solution CopilotKit a cette ambition. En s'affranchissant de frameworks, de modèles ou de protocoles d'agents spécifiques, CopilotKit vous permet de faire évoluer votre pile d'IA sans que vous ayez à repenser l'expérience utilisateur de votre application. Contrairement aux chatbots traditionnels qui ne répondent que par du texte, les interfaces de chat agentiques peuvent exécuter des fonctions, afficher du contenu riche et créer des expériences collaboratives entre les utilisateurs et les agents IA.

Des fonctions avancées permettent d’utiliser différents médias dans la conversation, de proposer des interfaces créées sur mesure par le modèle de langage (A2UI), d’intégrer des actions côté client ou serveur, etc.

C’est une solution à envisager, pour limiter l’effort de développement à la valeur ajoutée pour l’entreprise, sans maintenir une stack propriétaire couteuse, et toujours en retard par rapport aux évolutions du marché. Attention à la licence.

Goose

Le client Goose est complètement générique, basé uniquement sur les différents standards de l’écosystème Agentic. Avec un peu de paramétrage, il est possible de tester tous les scénarios d’intégration de votre entreprise, sans trop d’effort. En développant quelques serveurs MCP d’intégration, des compétences Skills, vous pouvez valider toutes vos idées d’exploitation de ces technologies, en quelques jours.

Toujours valider vos idées avec une technologie similaire, en se limitant exclusivement aux normes, avant de lancer un POC long et complexe, dont le ROI est imprévisible.

AGENTS.md — Agents ↔ code base

Sous la fondation AAIF

C’est probablement la plus simple des spécifications: ajouter un fichier AGENTS.md à la racine du projet, pour expliquer au LLM comment est architecturé le code du projet. C’est le README pour l’agent (il aide également beaucoups les développeurs).

Dans le cadre d’un projet métier Agentic, ce dernier n’est pas nécessaire en production. Il peut être envisagé pour un projet métier ayant plusieurs instances. Chaque instance est ainsi spécialisée via ce fichier. Par exemple, une instance de votre projet de détection de fraude s’occupe des fraudes aux contrefaçons, une autre pour la fraude à la déclaration douanière, etc. Chaque instance peut posséder son fichier AGENTS.md pour ajuster le comportement de l’instance. Ce fichier est à injecter dans chaque prompt métier. C’est un peu le plugin du system prompt de votre instance.

Pour conclure

La convergence de toutes ces solutions et leur normalisation sous Agentic AI foundation est une excellente chose. L’année 2026 sera l’année de la maturité.

De nouveaux protocoles émergent, comme Universal Commerce Protocol (UCP), Agent Paiement Protocol (AP2) … Ils vont chercher à s’imposer courant 2026.

Il manque de nombreux chapitres :

• Normaliser les interactions longues avec les utilisateurs, via une “in-box” LLM (comme le propose GotoHuman) ;
• Normaliser l’intégration des couches de sécurité (détection GuardRail.AI ou Nemo GuardRail), d’authentification entre agents, de traçabilité, etc.;
• Normaliser les interactions voix full-duplex ;
• Normaliser les échanges de messages par bus entre agents, pour une intégration d’agents communiquant dans toutes les activités de l’entreprise ;
• Gérer les transactions entre agents ;
• Gestion des sous-agents ;
• etc.

Il est important de rapidement s’atteler à l’intégration de ces nouvelles spécifications. Oui, tout va trop vite, on ne peut pas tous connaître. Néanmoins, c'est essentiel si nous ne souhaitons pas avoir une marche trop grande dans un ou deux ans.