Agent IA en entreprise : définition, exemples et limites

Un agent IA est un système qui poursuit un objectif en enchaînant des décisions et des actions sur des outils, avec un modèle de langage qui choisit l’étape suivante. Il ne se contente pas de répondre : il consulte une base, appelle une API, rédige un document, vérifie le résultat, puis décide de continuer, de corriger ou de s’arrêter.

Cette définition tient en une phrase, mais elle sépare nettement l’agent du chatbot, de l’assistant et du workflow automatisé. Elle permet aussi de poser la seule question qui compte avant un projet : qui décide de l’étape suivante, sur quels outils, et avec quel contrôle. Les exemples, les briques techniques et les limites décrites ici en découlent.

Concrètement, un agent IA est une boucle : le modèle lit l’objectif et le contexte, choisit un outil, observe le résultat de l’appel, puis décide de l’action suivante jusqu’à atteindre l’objectif ou une condition d’arrêt. C’est cette boucle, pilotée par le modèle, qui fait l’agent.

La documentation d’Anthropic Building effective agents pose une distinction utile. Dans un workflow, le modèle et les outils sont orchestrés par des chemins de code définis à l’avance. Dans un agent, le modèle dirige lui-même son processus et l’usage de ses outils. La même entreprise peut donc utiliser un modèle de langage dans les deux cas, avec des niveaux de risque très différents.

Le même texte recommande de commencer par la solution la plus simple et de n’ajouter de l’autonomie que lorsqu’elle améliore réellement le résultat. Un agent se justifie quand le nombre d’étapes ne peut pas être prévu ni codé à l’avance. Pour une tâche bien définie, un workflow est plus prévisible et moins coûteux, ce que développe l’article agent ou simple appel au modèle.

Un chatbot répond à un message, un assistant aide un humain qui reste aux commandes, un workflow automatisé exécute des étapes fixées par le code, et un agent choisit lui-même ses étapes et agit sur des outils. La différence tient à qui décide de l’étape suivante.

Le tableau montre pourquoi le mot « agent » est souvent mal employé. Un chatbot branché sur une base documentaire reste un chatbot, même s’il cite ses sources ; le sujet est traité dans l’article sur le chatbot RAG et ses garde-fous. Une chaîne d’appels écrite à la main reste un workflow. On parle d’agent dès que le modèle choisit l’outil et l’ordre des opérations.

Les exemples d’agents IA en entreprise les plus solides automatisent la collecte, le tri et la préparation d’une décision, tout en laissant à un humain la validation de ce qui engage l’entreprise. Les six cas ci-dessous sont génériques et décrivent un découpage type, pas un retour d’expérience.

La colonne de droite est le cœur du projet. Elle se décide avant la technique, comme le détaille l’article sur le périmètre avant l’autonomie. Un agent qui prépare une décision apporte déjà un gain de temps. Un agent qui l’exécute seul exige un niveau de preuve beaucoup plus élevé.

Un agent IA repose sur six briques : un modèle de langage, des outils, une mémoire, une orchestration, des contrôles d’autorisation et une journalisation, et sa fiabilité dépend autant des deux dernières que du modèle.

• Le modèle interprète l’objectif, choisit l’outil et rédige les paramètres de l’appel.
• Les outils sont les fonctions qu’il peut appeler : recherche, lecture d’un dossier, création d’un ticket, envoi d’un message. Anthropic recommande peu d’outils, chacun avec un rôle net, des noms explicites et des messages d’erreur qui disent comment corriger l’appel.
• La mémoire conserve ce qui doit survivre d’une étape à l’autre : l’état de la tâche, les résultats intermédiaires, parfois des préférences.
• L’orchestration gère la boucle : nombre maximal d’étapes, conditions d’arrêt, reprise après erreur, passage de relais à un humain.
• Les contrôles d’autorisation vérifient, hors du modèle, que l’action demandée est permise pour cet utilisateur et ce dossier.
• La journalisation enregistre chaque appel, ses paramètres et son résultat, pour rejouer et expliquer une décision.

Le Model Context Protocol standardise la façon de brancher ces outils : des hôtes, des clients et des serveurs qui exposent ressources, prompts et outils. Sa spécification rappelle que les outils représentent une exécution de code arbitraire, que leurs descriptions doivent être tenues pour non fiables si le serveur ne l’est pas, et que l’hôte doit obtenir le consentement explicite de l’utilisateur avant d’invoquer un outil.

Les limites d’un agent IA tiennent à quatre facteurs : les erreurs qui se composent sur les longues chaînes, l’injection indirecte de prompt, le coût de chaque boucle et la question de la responsabilité quand une action part mal.

Les erreurs composées. Chaque étape d’un agent peut se tromper, et l’erreur d’une étape devient l’entrée de la suivante. À titre illustratif, si chaque étape réussissait 95 fois sur 100 de façon indépendante, une chaîne de dix étapes n’aboutirait entièrement qu’environ six fois sur dix. Anthropic cite explicitement ce risque d’erreurs composées et recommande des tests étendus en environnement isolé. Le phénomène est développé dans l’article sur le risque qui croît avec la durée.

L’injection indirecte. L’OWASP distingue l’injection directe, tapée par l’utilisateur, de l’injection indirecte, cachée dans un contenu que le modèle lit : page web, document, courriel, commentaire de code. Un agent qui lit des contenus externes et dispose d’outils en écriture est exposé par construction. La méthode de test est décrite dans tester un agent contre l’injection indirecte.

Le coût. Une boucle d’agent consomme des appels au modèle à chaque étape, et le nombre d’étapes varie d’une exécution à l’autre. Anthropic note que les systèmes agentiques échangent latence et coût contre la performance : le budget se mesure par tâche réussie, pas par appel.

La responsabilité. Le modèle n’est pas responsable d’une décision. L’entreprise l’est. Il faut donc savoir sous quelle identité l’agent agit, avec quels droits, et qui répond de l’action, sujet traité dans l’article sur l’identité, les droits et le contrôle des agents Copilot.

On sécurise un agent IA en réduisant ses outils au strict nécessaire, en lui donnant les droits de l’utilisateur qu’il sert, et en faisant vérifier les actions à fort impact hors du modèle, par le système cible ou par un humain.

Le référentiel OWASP pour les applications à base de modèles de langage classe ce risque sous le nom d’Excessive Agency, avec trois causes : trop de fonctionnalités, trop de permissions, trop d’autonomie. Les mesures qu’il propose sont concrètes : supprimer les extensions inutiles, préférer des outils granulaires à un accès shell ou à une récupération d’URL ouverte, accorder des droits minimaux, exécuter les actions dans le contexte de l’utilisateur, exiger une approbation humaine pour les actions à fort impact et faire appliquer l’autorisation par le système aval plutôt que par le modèle.

Ce dernier point est décisif. Une consigne dans le prompt système n’est pas un contrôle d’accès. Si l’agent ne doit pas lire un dossier, c’est l’outil qui doit refuser la lecture, comme pour le filtrage des droits dans un RAG. La journalisation et la limitation de débit n’empêchent pas l’abus, mais elles en réduisent l’ampleur et permettent de le reconstituer.

On met un agent IA en production par paliers : d’abord un workflow borné et des outils en lecture seule, puis des actions soumises à validation humaine, et l’autonomie seulement sur les cas où les mesures le justifient. La méthode que j’applique suit cet ordre.

1. Nommer la décision et le coût d’une erreur. Quelle tâche, pour quel métier, avec quelle conséquence si l’agent se trompe.
2. Construire d’abord le workflow le plus simple. Si un enchaînement fixe suffit, il n’y a pas besoin d’agent.
3. Écrire le jeu de tests avant l’agent. Des tâches réelles avec un résultat vérifiable, des cas limites et des contenus piégés pour l’injection indirecte.
4. Brancher les outils en lecture seule. L’agent propose, il n’écrit nulle part.
5. Ouvrir l’écriture avec validation humaine. Chaque action passe par une approbation, et chaque refus est journalisé comme une donnée d’évaluation.
6. Accorder l’autonomie par catégorie d’action. Seulement là où les taux d’erreur mesurés sont acceptables et où l’action est réversible.
7. Surveiller en continu. Les modèles, les outils et les données changent ; l’évaluation continue rejoue le jeu de tests à chaque modification.

Un projet peut rester bloqué entre les étapes 4 et 6 lorsque le jeu de tests ou le propriétaire métier manque ; ces causes sont analysées dans l’article sur là où s’arrêtent les projets d’agents. Pour un agent déjà en service, un audit IA du système existant vérifie droits, journalisation et résistance à l’injection, et livre un jeu de tests et un plan de correction. Les équipes qui conçoivent leurs propres agents peuvent s’appuyer sur une formation IA centrée sur ces contrôles.

Analyse et méthode proposées par Anand Candassamy au 13 octobre 2026.