Agent IA en entreprise : comparer les garde-fous avant de lui ouvrir le SI

Un agent IA ne se contente pas de répondre à une question. Il peut interpréter une demande, consulter plusieurs sources, appeler une API et déclencher une action dans le système d’information. Cette capacité change la nature du risque : une erreur de réponse devient une erreur d’exécution, parfois propagée à plusieurs applications.

La CNIL décrit l’IA agentique comme un ensemble de systèmes capables d’agir sur un environnement défini, notamment des applications tierces, des bases de données ou des postes de travail, avec des niveaux variables d’autonomie. Elle souligne aussi les enjeux liés à la mémoire persistante, à la circulation des données entre services et au partage des responsabilités.

La définition de l’IA agentique publiée par la CNIL constitue un point de départ utile pour cadrer le sujet.

Pour une PME, la question n’est donc pas seulement de savoir quel modèle choisir. Il faut décider ce que l’agent peut voir, ce qu’il peut proposer, ce qu’il peut exécuter et quelles preuves doivent être conservées avant d’autoriser son usage.

Trois architectures possibles avant de parler d’autonomie

Le premier arbitrage porte sur le rôle confié à l’agent. Trois options permettent de comparer les risques sans partir d’un outil particulier.

Cette comparaison évite de confondre conversation et automatisation. Un agent qui consulte une base documentaire n’a pas le même périmètre qu’un agent capable de créer un compte, modifier une commande ou lancer un traitement. Le niveau d’autonomie doit suivre l’impact de l’action, pas l’effet de démonstration du modèle.

Option 1 : limiter l’agent à la lecture

La lecture seule est souvent le meilleur premier périmètre pour un usage interne : retrouver une procédure, qualifier un ticket, résumer une documentation ou préparer une réponse au support. Le système reste utile sans donner à l’agent la possibilité de changer l’état d’une application.

Cette option n’est pas sans risque. Les documents accessibles peuvent contenir des informations commerciales, personnelles ou techniques. La PME doit donc définir un corpus autorisé, un mécanisme d’authentification et une règle de filtrage des résultats. Le fait qu’un utilisateur puisse consulter une application ne signifie pas automatiquement que l’agent doit pouvoir agréger toutes les données auxquelles cet utilisateur a accès.

Le livrable attendu est une matrice simple : source consultable, type de donnée, rôle autorisé, durée de conservation des traces et propriétaire de la donnée. Il faut également prévoir des cas de refus, par exemple lorsqu’une demande vise une information hors périmètre ou lorsqu’une identité ne peut pas être vérifiée.

Option 2 : préparer l’action, sans l’exécuter

L’agent peut aussi produire une proposition : brouillon de réponse, requête de recherche, changement de statut ou plan d’intervention. Une personne conserve alors la décision finale. Cette architecture convient lorsque la tâche est répétitive mais que le coût d’une erreur reste significatif.

Le contrôle humain ne doit pas être une simple case « valider ». L’écran ou le processus de validation doit présenter l’objectif compris par l’agent, les données utilisées, l’action proposée, les conséquences possibles et les éléments qui justifient la proposition. Sans cette visibilité, l’humain risque de devenir un signataire automatique.

La recette doit couvrir les cas normaux, les données incomplètes, les demandes ambiguës et les tentatives de contournement. Pour organiser les scénarios, la validation de connecteur applicatif apporte une logique complémentaire : vérifier non seulement que l’appel technique fonctionne, mais aussi que l’effet produit, les droits et la reprise après erreur sont acceptables.

Option 3 : autoriser une exécution limitée

L’exécution directe peut se justifier pour une action bornée, réversible et facilement observable. Un agent peut par exemple classer un ticket dans une file dédiée ou déclencher une recherche sans modifier la donnée de référence. À l’inverse, la suppression, l’attribution de droits, la validation financière ou l’envoi externe doivent rester derrière un contrôle renforcé tant que le processus n’a pas démontré sa fiabilité.

Le principe de moindre privilège s’applique ici concrètement : l’agent ne reçoit que les droits nécessaires à une tâche, sur un périmètre identifié, avec une durée et une procédure de retrait. Les secrets utilisés pour appeler les outils ne doivent pas être placés dans une consigne, un historique conversationnel ou un fichier partagé.

Chaque outil exposé à l’agent doit avoir un propriétaire, un contrat d’appel, des limites de volume, des réponses d’erreur explicites et une procédure de coupure. L’équipe doit pouvoir désactiver l’intégration sans arrêter toute l’application métier.

Scénario synthétique : un agent de qualification des demandes

Le scénario suivant est fictif. Une PME souhaite utiliser un agent pour qualifier les demandes reçues par son support. L’agent lit le message, recherche la documentation interne, propose une catégorie et prépare une réponse. Il ne contacte pas le client et ne modifie pas directement la fiche ; un responsable valide la proposition.

Le périmètre initial peut être limité à trois catégories documentées. Les demandes contenant une donnée sensible, une demande de suppression ou une contestation sont orientées vers un humain. La recette vérifie alors quatre familles de cas : demande correctement classée, demande ambiguë, information absente de la documentation et tentative d’obtenir une donnée confidentielle.

La décision ne porte pas uniquement sur la qualité rédactionnelle. Elle porte sur la capacité à expliquer la source utilisée, à refuser une demande hors périmètre, à conserver une trace exploitable et à revenir à un traitement manuel. Pour les traces métier et les décisions différées, la journalisation des données consommées et des décisions produites fournit un complément utile.

Les critères de choix pour une PME

Le bon niveau d’autonomie dépend de l’effet produit par l’agent. Avant de demander un devis ou de choisir une plateforme, le décideur peut comparer les options sur six critères :

• Impact : que se passe-t-il si l’agent se trompe ou agit deux fois ?
• Réversibilité : l’action peut-elle être annulée rapidement sans restaurer toute l’application ?
• Données : quelles informations entrent dans le contexte, sont conservées ou ressortent vers un service tiers ?
• Droits : l’agent utilise-t-il une identité dédiée et limitée, plutôt qu’un compte humain trop puissant ?
• Observabilité : peut-on relier la demande, la décision, l’appel d’outil et le résultat ?
• Responsabilité : qui valide le périmètre, surveille les exceptions et décide de couper le service ?

Un prestataire doit rendre ces réponses vérifiables. Le dossier de cadrage peut demander une cartographie des flux, la liste des outils autorisés, les rôles et droits, les scénarios de recette, le format des journaux, le plan de retrait et les critères de passage à l’étape suivante.

Checklist avant le pilote

• Le cas d’usage est décrit par une tâche métier et non par une capacité générale du modèle.
• Le périmètre de données est documenté, avec les sources autorisées et les exclusions.
• Chaque outil appelé par l’agent possède un propriétaire et une procédure de coupure.
• Les actions irréversibles ou sensibles nécessitent une validation explicite.
• Les erreurs, refus, doublons et appels interrompus font partie des scénarios de recette.
• Les journaux permettent de reconstruire la demande, le contexte, l’action et le résultat sans exposer inutilement les données.
• Le pilote prévoit une décision de poursuite, de réduction du périmètre ou d’arrêt.

La sécurité d’un agent IA ne se résume donc pas au choix du modèle. Elle se construit autour de ses accès, de ses outils, de ses limites et de la preuve laissée par chaque décision. Pour une PME, commencer par une autonomie limitée et une recette concrète permet de vérifier la valeur du cas d’usage avant d’ouvrir davantage le système d’information.