Comprendre les agents d'IA : Conception, comportement et fixation des limites

Certaines personnes confondent les LLM avec les agents IA. Mettons cela au clair, d'accord ? Même si certains « étendent » les chatbots pour utiliser des outils et les appellent agents IA, cette approche reste immature si vous voulez exploiter pleinement les agents pour une automatisation avancée. Ce que vous voulez, bien sûr, car vous savez que c’est l’un des cas d’usage les plus précieux pour alléger la fatigue opérationnelle croissante due à la complexité du cloud hybride et multicloud.

Un agent d’IA doit être une unité logicielle (une application) autonome capable d’interpréter des objectifs, de garder le contexte et d’exécuter des actions en utilisant des outils. Il peut s’appuyer sur un grand modèle de langage (LLM) pour déterminer les actions à mener, mais le LLM n’est qu’un élément du système. L’agent constitue le système.

Concrètement, un agent IA reçoit une tâche (exprimée ou déduite), l’analyse dans un contexte donné et choisit la façon d’agir. Il peut ainsi appeler des outils, interroger des systèmes ou lancer des flux de travail.

Vous n'avez plus besoin d'une armée d'agents pour en tirer profit. Un agent unique et bien ciblé, intégré à une chaîne d’outils précise, accomplit déjà un travail efficace. Il automatise les résumés, génère des rapports, classe les tickets ou oriente les alertes vers les bonnes files. En respectant son champ d’action et les politiques, il apporte déjà une vraie valeur.

Vous pouvez utiliser des agents IA sans pratiquer l'IA agentique. Mais dès que les agents collaborent, vous pratiquez l'IA agentique, même si votre architecture n'est pas prête.

Selon nos recherches les plus récentes, vous faites déjà face à un comportement agentique (9 % des répondants) ou vous vous y orientez (79 % des répondants). L'IA agentique exige un cadre encadrant une exécution contrôlée, où plusieurs agents (oui, des « petits soldats » pour mieux les différencier de l'IA agentique) collaborent avec des outils communs, des objectifs contextuels et des niveaux d’application tels que MCP.

Un agent est une entité logicielle qui agit de façon autonome ou semi-autonome dans des limites bien définies. Il interprète les tâches, gère le contexte, utilise des outils et prend des décisions pour vous ou au sein d’un système plus vaste. Dans les architectures alignées MCP, les agents respectent un protocole structuré qui organise l’interaction entre les tâches, l’état et les politiques.

Vous pouvez raisonnablement déléguer et agir, mais toujours dans les limites du sandbox qui vous est alloué. Vous ne devez pas improviser les appels système. Vous ne créez pas dʼaccès aux outils de façon arbitraire. Chaque action doit transiter par une interface déclarée, que vous pouvez sécuriser, surveiller et révoquer.

Un agent dispose au minimum de :

1. Gestionnaire de contexte – Assure le suivi de l'état, des objectifs et de la mémoire (à court terme ou permanente)
2. Moteur de raisonnement – Souvent un LLM ou un planificateur symbolique qui analyse les tâches et organise leur exécution
3. Interface de l’outil – Relie l’intention aux actions ; détermine quelles opérations l’agent peut déclencher
4. Périmètre de sécurité – Nous définissons clairement les actions que l’agent peut effectuer et leur étendue
5. Couche de transport – Transmet messages et contexte, en utilisant généralement MCP, HTTP ou un bus d’événements

Un LLM réfléchit. Un agent passe à l’action. La plateforme régule.

Il existe deux modèles principaux, dont l’un constitue un piège.

C’est le modèle par défaut pour la plupart des frameworks aujourd’hui : LangChain, AutoGen, CrewAI, etc. L’agent se présente essentiellement comme une invite de chat intégrant des outils et une mémoire optionnelle, le tout structuré autour d’une seule session LLM.

• Prototypez rapidement
• Simple à présenter
• Difficult à mettre à l'échelle en toute sécurité

Limites:

• Pas d’architecture persistante
• Absence d’application native des politiques
• Le modèle génère facilement des appels d’outils fictifs ou omet les contraintes
• Aucune visibilité hors des journaux de jetons, sauf extension

En résumé : c’est un stagiaire compétent avec un accès root, mais sans surveillance. Ça marche parfaitement, jusqu’au jour où ça ne marche plus.

C’est le modèle à privilégier en production.

Ici, l’agent constitue un service logiciel complet fondé sur un cadre qui utilise un LLM sans que ce dernier ne soit indispensable à l’exécution.

• L'état se trouve à l'extérieur (Redis, bases de données vectorielles, moteurs de gestion des politiques)
• Vous contrôlez explicitement l’usage des outils via une couche de contrôle (serveur MCP, proxy passerelle)
• La sécurité et l'observabilité sont une priorité, pas un simple ajout
• L'agent est un service en place, et non une invite

Cette méthode vous offre un contrôle de version, des journaux dʼaccès, une gouvernance au niveau des outils et une isolation à lʼexécution. C’est ainsi que vous faites des agents bien plus que de simples gadgets, mais une véritable infrastructure.

Lorsqu’on conçoit des agents comme s’ils étaient des entités intelligentes, on adopte instinctivement des modèles d’accès axés sur l’humain : contrôle d’accès basé sur les rôles (RBAC), jetons d’authentification, attributs utilisateur, périmètres d’identité. Cela se comprend lorsqu’on gère une identité humaine constante tout au long d’une session. Mais les agents ne fonctionnent pas ainsi. Ils ne sont pas des utilisateurs. Ils exécutent des actions. Et cela change tout.

Les agents changent de rôle au fur et à mesure de leur action. Un même agent peut tour à tour collecter des données, élaborer un plan, puis déclencher une automatisation, souvent dans la même session et sous un même ensemble de tâches. Il ne se contente ni de se connecter, ni de récupérer un jeton statique, ni de rester cantonné à une seule fonction.

C’est là que le contrôle d’accès traditionnel montre ses limites. RBAC fonctionne avec des rôles statiques. Le contrôle d’accès basé sur les attributs (ABAC) s’appuie sur des attributs fixes. Les jetons de session requièrent une portée constante. Rien de cela ne tient quand les agents sont dynamiques. Dans les systèmes à agents, l’identité est fonctionnelle, pas personnelle.

C’est pourquoi nous devons passer d’une politique fondée sur l’identité à une politique fondée sur l’exécution pour gouverner les agents. Vous devez valider chaque appel d’outil en temps réel selon le rôle actuel de la tâche, l’état du contexte et la portée autorisée de l’agent. Nous appliquons les politiques au niveau de la couche outil, pas au niveau de l’authentification. Ce sont les blocs de contexte, et non les sessions de connexion, qui contiennent les métadonnées nécessaires à l’application de ces politiques. C’est pourquoi nous qualifions ce changement de paradigme de « Politique dans la charge utile », car la politique est littéralement dans la charge utile.

Considérez les agents comme des agents. Contrôlez-les comme un logiciel. Souvenez-vous toujours : le LLM réfléchit, l’agent agit, la plateforme supervise. Mélangez ces rôles, et vous créez une personnalité avec les droits d’admin, mais sans mémoire de ses erreurs passées.

Le LLM analyse. L'agent intervient. La plateforme contrôle.

En suivant cette approche, vous développerez une infrastructure d'agents capable de s'adapter, de garantir la sécurité et de résister aux imprévus.