Agents IA en entreprise : cas d'usage réalistes, limites et garde-fous

Un assistant conversationnel répond à une question. Un agent IA reçoit un objectif, planifie des étapes, utilise des outils (recherche dans une base documentaire, appel d'API, lecture d'un ticket, écriture dans un CRM) et boucle jusqu'à atteindre le résultat ou s'arrêter. La différence tient à l'autonomie et à l'accès aux systèmes.

Techniquement, un agent combine un grand modèle de langage, un ensemble d'outils décrits au modèle, une mémoire de travail et une boucle de contrôle. Des standards comme le Model Context Protocol (MCP) normalisent la façon dont un modèle découvre et appelle des outils, ce qui facilite l'intégration avec les systèmes existants.

Il faut distinguer l'agent de l'automatisation classique. Un flux d'automatisation suit des règles déterministes ; un agent interprète, décide et peut se tromper. Cette capacité d'interprétation est précisément ce qui le rend utile sur les tâches non structurées, et ce qui impose des garde-fous.

Le support client de premier niveau est le cas le plus mature : l'agent lit la demande, consulte la documentation et l'historique du client, répond aux questions courantes, et transfère à un humain avec un résumé lorsque la situation dépasse son périmètre. Le gain vient autant du triage que de la réponse.

Le traitement documentaire est le second : extraire des données de factures, contrats ou formulaires, les vérifier par rapport à des règles métier, et les saisir dans le système cible. L'agent gère la variabilité des formats bien mieux qu'un script fixe, mais chaque saisie doit rester vérifiable par un humain.

L'assistance interne sur la connaissance de l'entreprise (procédures, politique RH, documentation technique), avec une recherche fondée sur vos documents, et l'assistance au développement logiciel (revue de code, génération de tests, analyse d'incidents) sont également déployées avec succès, à condition de bien cadrer les sources et les permissions.

Un agent n'est pas fiable pour des décisions à fort enjeu sans validation humaine : engagement contractuel, versement, décision médicale ou juridique, action irréversible sur un système de production. Les modèles produisent des réponses plausibles, pas des réponses garanties exactes, et cette nuance change tout.

Il est également peu adapté aux processus où la règle est parfaitement définie et stable : un calcul de TVA ou un rapprochement bancaire simple sont mieux servis par du code déterministe, moins cher, plus rapide et testable. L'agent apporte de la valeur là où l'interprétation est nécessaire.

Enfin, les tâches longues avec de nombreuses étapes dépendantes accumulent les erreurs. Un agent qui réussit chaque étape dans la grande majorité des cas échouera fréquemment sur une chaîne de vingt étapes. Découpez les processus et validez les résultats intermédiaires.

L'injection de requête (prompt injection) est le risque principal : un contenu malveillant lu par l'agent (courriel, page web, document) peut lui donner des instructions détournées. Un agent qui lit des données externes et dispose d'outils d'action doit être considéré comme exposé, au même titre qu'une application web recevant des entrées utilisateur.

La fuite de données est le second risque : l'agent peut révéler des informations auxquelles l'utilisateur n'aurait pas dû accéder, si les permissions ne sont pas appliquées au niveau des sources de données et non seulement dans les instructions du modèle, qui ne sont pas un mécanisme de sécurité.

S'ajoutent les coûts non maîtrisés (boucles, contextes volumineux), la latence, la dépendance à un fournisseur et les obligations réglementaires, notamment le règlement européen sur l'IA, dont les obligations s'appliquent progressivement selon le niveau de risque de l'usage.

Limitez les outils au strict nécessaire et distinguez les outils de lecture des outils d'action. Toute action irréversible ou à impact (envoi, paiement, suppression, modification en production) doit passer par une validation humaine ou une file d'approbation, au moins tant que la fiabilité n'est pas démontrée sur des cas réels.

Appliquez les permissions à la source : l'agent agit avec l'identité et les droits de l'utilisateur qui l'a sollicité, jamais avec un compte de service omnipotent. Journalisez chaque appel d'outil, chaque décision et chaque réponse, pour l'audit et pour l'amélioration continue.

Construisez un jeu d'évaluation représentatif de cas réels, y compris des cas piégeux et des tentatives d'injection, et faites-le tourner à chaque changement de modèle, d'instructions ou d'outil. Sans évaluation, il est impossible de savoir si une modification améliore ou dégrade le système.

Commencez par un processus à volume élevé, à faible enjeu unitaire et facilement vérifiable, comme le triage de demandes. Mesurez la situation de départ (temps de traitement, taux de transfert) pour pouvoir démontrer le gain avec des chiffres qui vous appartiennent.

Déployez d'abord en mode assisté : l'agent propose, l'humain valide. Cette phase construit la confiance, alimente le jeu d'évaluation et révèle les cas non anticipés. L'autonomie s'accorde ensuite, périmètre par périmètre, sur la base de résultats mesurés et non d'impressions.

Enfin, traitez l'agent comme un logiciel : versionnement des instructions, environnements de test, surveillance en production, procédure d'arrêt d'urgence. La technologie évolue vite ; l'architecture doit permettre de changer de modèle sans tout réécrire.