Comprendre les agents d’IA : conception, comportement et définition des limites

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Certaines personnes semblent confondre les LLM avec les agents d’IA. Mettons les choses au clair une bonne fois pour toutes, voulez-vous ? Certes, certains « étendent » les chatbots pour leur permettre d’exécuter des outils et les qualifient d’agents d’IA, mais cette approche manque de maturité si vous souhaitez exploiter les agents à des fins d’automatisation avancée. Ce qui est bien sûr votre cas, car vous savez qu’il s’agit de l’un des cas d’usage les plus précieux pour remédier à la fatigue opérationnelle croissante engendrée par la complexité des environnements hybrides et multicloud.

Un agent d’IA doit être une unité logicielle (une application), c’est-à-dire un système délimité qui interprète des objectifs, conserve le contexte et effectue des actions en faisant appel à des outils. Il peut utiliser un grand modèle de langage (LLM) pour déterminer ce qui doit se passer, mais le LLM n’est qu’un rouage du mécanisme. L’agent constitue le système.

Concrètement, un agent d’IA reçoit une tâche (explicite ou déduite), l’évalue dans un contexte donné et décide de la marche à suivre. Il peut notamment faire appel à des outils, interroger des systèmes ou déclencher des workflows.

Cela dit, nul besoin d’une multitude d’agents pour tirer parti d’un seul. Un agent unique, doté d’un périmètre bien défini et associé à une chaîne d’outils ciblée, peut dès aujourd’hui accomplir des tâches utiles. Il peut automatiser la création de synthèses, générer des rapports, classer des tickets ou même acheminer les alertes vers les files appropriées. Tant qu’il respecte son périmètre et les règles établies, il apporte déjà une réelle valeur ajoutée.

Vous pouvez utiliser des agents d’IA sans faire d’IA agentique… Mais dès que des agents collaborent, vous faites bel et bien de l’IA agentique, même si votre architecture n’est pas prête pour cela.

D’après notre étude la plus récente, je suppose que vous êtes soit déjà confronté à des comportements agentiques (9 % des personnes interrogées), soit en passe de l’être (79 % des personnes interrogées). L’IA agentique nécessite un cadre fondé sur une exécution contrôlée, dans lequel plusieurs agents (oui, des « minions », car cela permet de mieux les distinguer de l’IA agentique) interagissent avec des outils partagés, des objectifs contextuels et des couches de contrôle telles que MCP.

Qu’est-ce qu’un agent ?

Un agent est une entité logicielle qui fonctionne de manière autonome ou semi-autonome dans le cadre de contraintes clairement définies. Il interprète les tâches, gère le contexte, fait appel à des outils et prend des décisions pour le compte d’un utilisateur ou d’un système plus vaste. Dans les architectures conformes au MCP, les agents suivent un protocole structuré qui régit les interactions entre les tâches, l’état et les règles.

Les agents peuvent raisonner, déléguer et agir, mais uniquement dans les limites de l’environnement isolé qui leur a été attribué. Ils n’improvisent pas d’appels système et ne s’octroient pas eux-mêmes l’accès à des outils. Chaque action doit passer par une interface déclarée, qui peut être sécurisée, surveillée et révoquée.

Au minimum, un agent dispose des éléments suivants :

1. Gestionnaire de contexte – Assure le suivi de l’état, des objectifs et de la mémoire (à court terme ou persistante)
2. Moteur de raisonnement – Généralement un LLM ou un planificateur symbolique qui interprète les tâches et planifie leur exécution
3. Interface d’outils – Traduit les intentions en actions et contrôle les opérations que l’agent peut exécuter
4. Périmètre de sécurité – Définit ce que l’agent est autorisé à faire et dans quel cadre
5. Couche de transport – Transmet les messages et le contexte, généralement via MCP, HTTP ou un bus d’événements

Un LLM « réfléchit ». Un agent « agit ». La plateforme « gouverne ».

Modèles de conception d’agents

Deux modèles prédominent, et l’un d’eux est un piège.

Il existe aujourd’hui deux approches dominantes pour concevoir des agents d’IA : l’approche centrée sur les LLM et l’approche limitée à une application. L’approche centrée sur les LLM convient aux chatbots, mais pas aux cas d’usage plus avancés en matière d’automatisation.

1. Agents centrés sur les LLM (monolithiques)

C’est aujourd’hui le modèle par défaut de la plupart des frameworks : LangChain, AutoGen, CrewAI, etc. L’agent est essentiellement une invite de chat à laquelle sont intégrés des outils et, éventuellement, une mémoire, le tout reposant sur une seule session de LLM.

• Rapide à prototyper
• Facile à présenter en démonstration
• Dangereux à déployer à grande échelle

Limites :

• Aucune architecture persistante
• Aucune application native des politiques
• Le modèle peut facilement halluciner des appels d’outils ou oublier des contraintes
• Aucune observabilité en dehors des journaux de jetons, sauf extension

En bref : c’est un stagiaire intelligent avec un accès root et sans aucune supervision. Ça fonctionne très bien, jusqu’au jour où ça ne fonctionne plus.

2. Agents liés à une application (modulaires)

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

Ici, l’agent est un service logiciel complet reposant sur un framework qui utilise un LLM, mais ne dépend pas de celui-ci pour gérer l’exécution.

• L’état est externalisé (Redis, bases de données vectorielles, moteurs de règles)
• L’utilisation des outils est explicite et gérée par une couche de contrôle (serveur MCP, proxy de passerelle)
• La sécurité et l’observabilité sont des priorités de premier ordre, et non des considérations secondaires
• L’agent est un service déployé, pas un prompt

Cette approche vous offre le contrôle des versions, des journaux d’accès, une gouvernance au niveau des outils et une isolation de l’environnement d’exécution. C’est ainsi que vous faites passer les agents du statut de gadgets à celui d’infrastructure.

Les agents ne sont pas des personas

Lorsque l’on conçoit des agents comme s’il s’agissait de personnages intelligents, on se tourne instinctivement vers des modèles d’accès centrés sur l’humain : contrôle d’accès basé sur les rôles (RBAC), jetons de connexion, attributs utilisateur, périmètres d’identité. Ces modèles sont pertinents lorsqu’on a affaire à une identité humaine cohérente tout au long d’une session. Mais les agents ne fonctionnent pas ainsi. Ce ne sont pas des utilisateurs. Ce sont des exécutants. Et cela change tout.

Les agents changent de rôle au fil de leurs opérations. Un même agent peut servir à récupérer des données, puis à planifier des actions et enfin à déclencher une automatisation, souvent au cours d’une même session et dans le cadre d’une même tâche. Il ne se connecte pas pour obtenir un jeton statique et s’en tenir à un seul rôle.

C’est là que le contrôle d’accès traditionnel montre ses limites. Le RBAC repose sur des rôles statiques. Le contrôle d’accès basé sur les attributs (ABAC) suppose des attributs fixes. Les jetons de session supposent un périmètre constant. Or, rien de tout cela ne tient lorsque les agents sont dynamiques. Dans les systèmes agentiques, l’identité est fonctionnelle, et non personnelle.

C’est pourquoi la gouvernance des agents exige de passer d’une politique fondée sur l’identité à une politique fondée sur l’exécution. Chaque appel d’outil doit être validé en temps réel en fonction du rôle actuel de l’agent dans la tâche, de l’état du contexte et du périmètre autorisé. Les politiques s’appliquent au niveau des outils, et non 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 appelons ce changement de paradigme « Politique dans la charge utile », car la politique se trouve littéralement dans la charge utile.

Traitez les agents comme des agents. Encadrez-les comme des logiciels. Et n’oubliez jamais : le LLM réfléchit, l’agent agit et la plateforme gouverne. Si vous confondez ces rôles, vous créez une personnalité dotée de droits d’administrateur et qui ne garde aucun souvenir de sa dernière erreur.

Le LLM réfléchit. L’agent agit. La plateforme gouverne.

Tenez-vous-en à ces principes, et vous bâtirez une infrastructure d’agents capable de monter en charge, de rester sécurisée et de résister à l’épreuve du réel.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie