Architecture agentique : bâtir l'infrastructure de vos agents IA

Une architecture agentique est l'ensemble des couches techniques qui permettent à un agent IA d'agir dans le système d'information d'une entreprise : le modèle qui raisonne, les connecteurs qui donnent accès aux applications, l'orchestration, la mémoire, l'identité de l'agent, la supervision et les garde-fous de sécurité. Le choix du modèle d'IA n'en est qu'une partie. Ce qui décide si un agent peut passer en production, c'est tout ce qu'on construit autour.

Architecture agentique : définition

L'IA agentique, selon la CNIL, « désigne couramment un ensemble de systèmes qui reposent sur la coordination de plusieurs sous-systèmes appelés agents IA ». Un agent ne se contente pas de répondre : il lit des données, modifie des fiches, déclenche des actions dans des applications tierces, avec un niveau d'autonomie variable.

L'architecture agentique décrit comment ces agents sont reliés au reste du SI. Elle répond à des questions très concrètes pour une DSI : à quelles applications l'agent accède-t-il, avec quel compte, qui valide ses actions sensibles, où sont conservées ses traces, comment le couper sans toucher au reste ?

On parle aussi d'infrastructure agentique ou d'infrastructure IA agentique. Pour la définition de l'IA agentique elle-même et ses différences avec un chatbot ou une RPA, voir notre article sur l'IA agentique.

Les couches d'une architecture agentique en entreprise

Une architecture agentique se lit comme un empilement de sept couches. Chacune pose une question à laquelle il faut répondre avant la mise en production.

Les modèles d'IA (GPT, Claude, Mistral) : un composant remplaçable

Le modèle de langage fournit le raisonnement : il comprend la demande, choisit l'outil à appeler, rédige la réponse. C'est la couche la plus visible et, paradoxalement, celle qu'il faut rendre la plus facile à changer. Les modèles évoluent tous les quelques mois, leurs prix aussi. Une architecture saine isole le modèle derrière une interface commune, pour pouvoir en tester un autre ou en utiliser plusieurs selon la tâche sans réécrire les intégrations.

Question à se poser : si le modèle change demain, qu'est-ce qui doit être modifié ?

Les connecteurs : API et serveurs MCP (Model Context Protocol)

Un agent n'agit que sur ce à quoi il est connecté. Les connecteurs lui donnent accès aux applications (messagerie, CRM, outil de tickets, ERP) par leurs API. Le Model Context Protocol (MCP) est un protocole ouvert qui standardise ces échanges : un serveur MCP expose des ressources (des données), des prompts et des outils (des fonctions que le modèle peut exécuter), et l'application qui héberge l'agent s'y connecte.

La spécification MCP rappelle que les outils représentent une exécution de code arbitraire et doivent être traités avec prudence, et que l'utilisateur doit consentir explicitement à leur appel. Côté architecture, cela veut dire : un connecteur par besoin réel, des droits limités à ce besoin, et aucun serveur MCP d'origine inconnue branché sur un environnement de production.

Question à se poser : l'agent n'accède-t-il qu'aux sources dont il a besoin pour sa tâche ?

L'orchestration : un agent ou plusieurs, et qui passe la main à un humain

L'orchestration enchaîne les étapes : un agent qui planifie, un autre qui exécute, un troisième qui vérifie, ou un seul agent qui fait tout. Plus il y a d'agents, plus les échanges entre eux doivent être tracés. La règle la plus importante de cette couche est ailleurs : définir à quel moment l'agent s'arrête et transmet à un humain (montant, type d'action, doute sur la demande).

Question à se poser : dans quels cas l'agent doit-il demander une validation humaine ?

La mémoire et les données : ce que l'agent a le droit de lire et de garder

Un agent utile se souvient du contexte : l'historique d'un ticket, les préférences d'un utilisateur, les documents internes qu'il consulte. Cette mémoire est aussi un stockage de données, parfois personnelles, qui relève du RGPD. Il faut décider ce que l'agent peut lire, ce qu'il conserve, combien de temps, et qui peut y accéder.

Question à se poser : les données que l'agent garde en mémoire sont-elles inscrites au registre des traitements ?

Les identités et les droits : un compte par agent (Microsoft Entra Agent ID)

Un agent qui agit dans le SI a besoin d'une identité, distincte de celle des utilisateurs et des applications classiques. Dans un environnement Microsoft, c'est le rôle de Microsoft Entra Agent ID : il crée des identités d'agents dans Microsoft Entra ID, qui permettent de distinguer les opérations d'un agent de celles d'un humain, de lui donner des droits au plus juste et de l'empêcher d'accéder aux rôles de sécurité critiques. L'accès conditionnel s'applique aussi aux identités d'agents (avec les licences requises par Microsoft, dont Microsoft Agent 365).

Un compte par agent permet surtout de révoquer un agent sans toucher aux comptes des collaborateurs.

Question à se poser : peut-on couper un agent en une action, sans effet sur le reste ?

La supervision et les journaux : savoir ce que fait l'agent, et pourquoi

Un agent en production se supervise comme un serveur : disponibilité, erreurs, temps de réponse, volume d'actions, coût de consommation du modèle. Il faut aussi journaliser ses décisions : quelle demande il a reçue, quels outils il a appelés, avec quelles données, et ce qu'il a fait. Ces journaux servent à corriger l'agent, à répondre à un audit et à reconstituer un incident.

Question à se poser : peut-on reconstituer après coup chaque action de l'agent ?

Les garde-fous de sécurité : injection de consignes, actions sensibles, SOC

Un agent lit des contenus qu'il ne maîtrise pas (courriels, pages web, pièces jointes). Une consigne cachée dans ces contenus peut détourner son comportement : c'est l'injection de consignes (prompt injection). Les garde-fous limitent les dégâts possibles : liste fermée d'actions autorisées, validation humaine des actions sensibles, filtrage des entrées, et envoi des journaux de l'agent vers la supervision de sécurité (SIEM, SOC) pour détecter un comportement anormal. L'ANSSI, dans ses recommandations de sécurité pour un système d'IA générative, demande de maîtriser les interactions du système d'IA avec les applications métier et de limiter les actions automatiques.

Question à se poser : si l'agent est détourné, jusqu'où peut-il aller ?

Schéma : comment les couches s'assemblent (exemple Microsoft 365)

Prenons un agent qui traite les demandes d'accès des collaborateurs dans Microsoft 365 : un salarié demande l'accès à un site SharePoint, l'agent vérifie la demande, l'exécute ou la transmet. Voici ce que chaque couche contient dans ce cas.

L'ordre de lecture compte : la demande entre par un canal connu, l'agent ne voit que ce que ses connecteurs lui ouvrent, et tout ce qu'il fait laisse une trace exploitable par l'équipe de sécurité. C'est le même exemple que dans notre article sur l'opérateur d'infrastructure agentique, vu cette fois sous l'angle de la construction.

Par où commencer : l'ordre de mise en place pour une PME ou une ETI

L'erreur classique consiste à partir du modèle et à ajouter la sécurité à la fin. L'ordre inverse fonctionne mieux.

1. Choisir un cas d'usage borné. Une tâche répétitive, avec des règles claires et un faible risque en cas d'erreur : traitement de demandes d'accès, tri de tickets de support, préparation de réponses à valider.
2. Définir ce que l'agent a le droit de faire. La liste des actions autorisées, celles qui demandent une validation humaine, et celles qui lui sont interdites.
3. Créer son identité et ses droits. Un compte dédié, des droits au plus juste, sans rôle d'administration.
4. Brancher les connecteurs strictement nécessaires. Un connecteur par besoin, testé en dehors de la production.
5. Mettre en place les journaux et la supervision avant l'ouverture aux utilisateurs. Si l'on ne peut pas voir ce que fait l'agent, il n'est pas prêt.
6. Ouvrir progressivement. Un service pilote, puis l'ensemble de l'entreprise, en ajustant les seuils de validation au vu des journaux.

Le choix du modèle intervient au milieu de ce parcours, pas au début. Pour l'intégration aux applications existantes, notre guide pour intégrer un agent IA dans un SI existant détaille les points techniques.

Les erreurs d'architecture les plus fréquentes

• Un agent qui utilise le compte d'un administrateur. C'est rapide pour un prototype, mais toutes ses actions se confondent avec celles d'un humain, et le couper revient à bloquer ce collaborateur.
• Des connecteurs ouverts « au cas où ». Chaque accès inutile agrandit ce qu'un agent détourné peut atteindre.
• Aucune règle de passage à un humain. L'agent décide seul d'actions qui auraient dû être validées, et personne ne sait à partir de quand il aurait dû s'arrêter.
• Des journaux incomplets. On sait que l'agent a agi, pas pourquoi ni avec quelles données. Impossible alors de corriger un comportement ou de répondre à un audit.
• Un modèle soudé au reste. Le jour où il faut changer de modèle, tout est à reprendre.
• Une mémoire sans règle de conservation. L'agent accumule des données personnelles qui ne figurent dans aucun registre.

Pour la sécurité d'un projet d'agent de bout en bout, voir aussi comment sécuriser un projet d'agent IA en entreprise.

Architecture agentique et AI Act : ce qui change pour la conception

Le règlement européen sur l'intelligence artificielle (règlement (UE) 2024/1689, dit AI Act) impose déjà plusieurs obligations qui se traduisent dans l'architecture :

• Former les personnes qui utilisent l'IA, obligation en vigueur depuis le 2 février 2025.
• Informer l'utilisateur qu'il échange avec une IA (obligations de transparence de l'article 50), applicables depuis le 2 août 2026. Un agent qui répond à des collaborateurs ou à des clients doit donc se présenter comme tel.
• Les usages à haut risque de l'annexe III (par exemple en recrutement) ont des exigences propres, reportées au 2 décembre 2027 par le règlement (UE) 2026/1744. Un agent qui intervient dans ces domaines doit être conçu dès maintenant pour les respecter : contrôle humain, journalisation, documentation.

Côté architecture, la journalisation et les règles de passage à un humain décrites plus haut sont les deux couches qui répondent le plus directement à ces exigences. Le RGPD s'applique en parallèle à la mémoire de l'agent et aux données qu'il traite.

Qui conçoit et exploite cette architecture ?

Construire une architecture agentique relève de plusieurs métiers : l'éditeur fournit le modèle ou la plateforme, l'intégrateur branche l'agent sur les applications, et quelqu'un doit ensuite faire tourner l'ensemble en production, jour après jour : superviser, corriger, faire évoluer les droits, répondre aux incidents. C'est le rôle d'un opérateur d'infrastructure agentique.

Chez IT Systèmes, nous exploitons déjà notre propre agent, Helpy, en production pour le support informatique de 55 clients sous contrat d'hypergérance. C'est cette expérience que nous mettons à disposition des PME et ETI qui veulent faire agir des agents dans leur SI, Microsoft 365 en tête : voir notre offre d'opérateur d'infrastructure IA agentique, et nos agents IA pour les entreprises.

Questions fréquentes

Qu'est-ce qu'une architecture agentique ?

C'est l'ensemble des couches techniques qui permettent à un agent IA d'agir dans le système d'information : modèle, connecteurs, orchestration, mémoire, identité, supervision et garde-fous de sécurité. Le modèle d'IA n'en est qu'un composant.

Quelle différence entre architecture agentique et plateforme agentique ?

Une plateforme agentique est un produit qui aide à créer et à héberger des agents (par exemple Microsoft Copilot Studio). L'architecture agentique est la façon dont ces agents sont reliés au SI de l'entreprise : leurs accès, leurs identités, leur supervision. Une plateforme ne suffit pas à définir une architecture.

Faut-il un système multi-agents ?

Pas pour commencer. Un seul agent sur une tâche bornée est plus simple à superviser et à sécuriser. Plusieurs agents se justifient quand la tâche se découpe en étapes distinctes (planifier, exécuter, vérifier), à condition de tracer les échanges entre eux.

Qu'est-ce que MCP et faut-il l'utiliser ?

Le Model Context Protocol est un protocole ouvert qui standardise la connexion entre une application d'IA et des sources de données ou des outils. Il simplifie l'intégration, mais chaque serveur MCP donne à l'agent la capacité d'exécuter des actions : il faut n'utiliser que des serveurs de confiance, limiter leurs droits et journaliser leurs appels.

Peut-on construire une architecture agentique sur Microsoft 365 ?

Oui. Microsoft 365 fournit les briques principales : Microsoft Graph pour accéder aux données, Microsoft Entra Agent ID pour donner une identité à chaque agent, l'accès conditionnel pour encadrer ses connexions, et les outils de sécurité Microsoft pour superviser ses actions. Il reste à définir les règles d'usage, les seuils de validation humaine et l'exploitation au quotidien.