IA
Un agent IA ne doit accéder qu'aux données nécessaires à la tâche qu'on lui confie, avec des droits qui ne dépassent jamais ceux de la personne pour qui il agit. La lecture s'ouvre en premier, l'écriture ensuite et sur un périmètre borné. Les données personnelles sensibles, les flux financiers et les secrets d'accès restent sous validation humaine.
Les agents IA ne sont plus des démonstrations de salon. Ils trient des boîtes de réception, mettent à jour des fiches dans le CRM, rédigent des réponses fournisseurs, lancent des requêtes sur l'entrepôt de données. Pour y parvenir, ils ont besoin d'une chose que les assistants conversationnels n'avaient pas : un accès direct aux systèmes de l'entreprise.
Cet accès change la nature du risque. Un agent qui poursuit correctement la tâche qu'on lui a confiée peut, en chemin, ouvrir un dossier qu'il n'aurait jamais dû voir ou modifier un enregistrement qu'il n'aurait jamais dû toucher. Le danger ne vient pas d'une intention malveillante, il vient de ce que l'agent peut atteindre.
Le débat public se concentre pourtant sur le modèle : sa fiabilité, ses hallucinations, son alignement. Ces questions comptent, mais elles ne sont pas celles que l'entreprise peut régler seule. Ce qu'elle maîtrise entièrement, ce sont les droits qu'elle accorde. Un agent mal configuré sur un périmètre étroit fait peu de dégâts. Un agent excellent branché sur un compte qui voit tout peut en faire beaucoup.
La décision d'ouvrir des données à un agent relève donc de la gouvernance des données bien avant de relever de la technique. Quelles données, pour quelle tâche, avec quel droit, sous le contrôle de qui : ce sont les quatre réponses à obtenir avant la première connexion.
Le risque d'un agent IA se mesure à ce qu'il peut faire sans demander. Tant qu'un outil d'IA se contentait de répondre dans une fenêtre de discussion, l'erreur restait à l'écran et un humain décidait de la suite. Un agent, lui, exécute.
Un assistant conversationnel produit un texte que l'utilisateur relit, copie, corrige ou jette. Un agent enchaîne des actions : il lit un document, en tire une conclusion, appelle un outil, écrit dans un système, puis passe à l'étape suivante. Chaque étape ajoutée entre la demande et le résultat est une étape où personne ne regarde.
Cette différence change la nature du risque. Une hallucination dans un assistant produit une phrase fausse. La même hallucination dans un agent peut produire un e-mail envoyé au mauvais client, une fiche fournisseur écrasée ou une requête qui extrait un fichier entier au lieu d'une ligne.
Un agent qui sort de son périmètre ne le fait pas forcément parce qu'il se trompe. Il le fait souvent parce que rien ne l'en empêche : une connexion laissée ouverte, un identifiant accessible, une barrière qu'il peut franchir pour atteindre son objectif.
Trois failles méritent une attention particulière pour une entreprise qui déploie ses propres agents. Chacune renvoie à une décision d'accès, pas à une propriété du modèle.
Lorsqu'un agent se connecte avec le compte de la personne qui l'a configuré, ou avec un compte technique doté de droits larges « pour que ça marche », il hérite d'accès pensés pour un humain qui sait ce qu'il ne doit pas ouvrir.
Un collaborateur du service achats voit les contrats de tous les fournisseurs, mais il ne les consulte pas tous. Un agent disposant des mêmes droits n'a pas cette retenue implicite : s'il juge qu'un document peut l'aider, il l'ouvre. Les droits d'accès d'un humain reposent sur son jugement, ceux d'un agent doivent reposer sur une règle.
C'est aussi pour cette raison que copier la gouvernance des données pour l'IA ne suffit pas : les règles existantes supposent un utilisateur humain, identifiable et responsable de ses consultations.
La question « à quelles données l'agent a-t-il accès ? » arrive souvent après la mise en service, quand quelqu'un s'étonne d'une réponse trop bien informée. Elle doit arriver avant. Le point de départ n'est pas l'outil, c'est le classement des données que l'agent va toucher.
Un classement simple suffit pour démarrer, à condition qu'il soit appliqué à chaque source avant de la connecter. Les quatre familles suivantes couvrent l'essentiel des situations rencontrées dans une organisation.
Ce classement n'a de valeur que s'il est porté par quelqu'un qui connaît les données. C'est le rôle du Data Owner de chaque domaine : il sait ce que contient réellement un dossier partagé, bien mieux que l'équipe qui déploie l'agent.
Le classement porte sur le contenu réel des sources, pas sur leur intitulé. Un espace partagé nommé « Documentation projet » peut contenir des exports de fichiers clients, une messagerie d'équipe peut contenir des bulletins de salaire transmis en pièce jointe. Tant que l'inventaire des sources n'a pas été fait, une source mixte se classe au niveau de sa donnée la plus sensible.
La sensibilité d'une donnée ne suffit pas à décider. Un agent qui lit des fiches clients pour préparer un rendez-vous commercial présente un risque limité si rien ne sort de l'entreprise. Le même agent qui peut modifier ces fiches ou envoyer un message au client présente un risque d'une autre nature, parce que l'action ne se rattrape pas.
La bonne question n'est pas seulement « que peut-il voir ? », c'est aussi « que peut-il changer, et peut-on revenir en arrière ? ». Une action réversible (un brouillon, une proposition, une note interne) peut être confiée plus largement. Une action irréversible (un envoi, un paiement, une suppression, une écriture dans un système de référence) exige une validation humaine, quelle que soit la qualité de l'agent.
Le tableau suivant croise ces deux dimensions pour les accès les plus fréquemment demandés. Il sert de base de discussion entre les métiers qui veulent un agent et les équipes qui en répondent.
| Accès demandé par l'agent | Décision | Condition à poser |
|---|---|---|
| Lire la documentation interne et les procédures | Ouvrir | Sources à jour, avec un responsable identifié et une date de révision connue. |
| Lire les dossiers et tickets d'une équipe | Ouvrir | Périmètre limité à l'équipe qui utilise l'agent, jamais à toute la direction. |
| Rédiger des brouillons et des propositions | Ouvrir | Écriture dans un espace dédié, relu par un humain avant tout usage. |
| Lire des fiches clients, contrats ou données RH | Encadrer | Finalité écrite, accord du Data Owner, traitement inscrit au registre RGPD. |
| Envoyer des messages à l'extérieur de l'entreprise | Encadrer | Validation humaine avant chaque envoi, mention de l'usage de l'IA si la loi l'exige. |
| Modifier un référentiel (clients, fournisseurs, produits) | Encadrer | Modifications proposées dans une file de validation, jamais écrites directement. |
| Déclencher un paiement ou modifier des coordonnées bancaires | Exclure | Action réservée à un humain habilité, l'agent peut au mieux préparer le dossier. |
| Lire des identifiants, clés d'accès ou mots de passe | Exclure | Secrets retirés des sources connectées et stockés dans un coffre dédié. |
Ouvrir une source à un agent, c'est aussi lui confier ses défauts. Une procédure obsolète, un référentiel fournisseur en double, un tableau de suivi abandonné depuis deux ans : un humain les repère au premier coup d'œil, un agent les traite comme des faits. Plus l'agent agit, plus une donnée fausse se transforme en action fausse.
Ce lien direct entre la mauvaise qualité des données et le risque IA plaide pour une règle simple : ne connecter que des sources qui ont un responsable, une date de mise à jour connue et un périmètre clair. Les autres attendent.
Une fois les données classées, il reste à fixer les règles qui encadrent l'accès. Aucune n'est nouvelle en sécurité informatique. Ce qui change, c'est leur application à un utilisateur qui n'est pas humain et qui travaille sans pause.
Un agent doit disposer de son propre compte, distinct de celui de la personne qui l'a configuré. Sans cette séparation, il devient impossible de savoir, dans les journaux, si une action a été faite par un collaborateur ou par l'agent qui agissait en son nom.
Cette identité propre permet trois choses que le partage de compte interdit.
Le principe du moindre privilège consiste à n'accorder que les droits strictement nécessaires. Pour un agent, il se calcule à partir de la tâche. Un agent qui prépare les synthèses hebdomadaires d'un projet a besoin de lire les dossiers de ce projet, pas ceux de tous les projets de la direction.
Un agent qui reçoit les droits de son utilisateur « par commodité » en reçoit presque toujours trop. La règle pratique consiste à partir de zéro et à ajouter les accès un par un, en justifiant chacun par une étape de la tâche.
La lecture seule couvre une grande part des usages utiles : rechercher, synthétiser, comparer, préparer. Elle n'est pas sans risque (une fuite reste possible si l'agent restitue une information à la mauvaise personne), mais elle ne modifie rien dans les systèmes.
L'écriture ne s'ouvre qu'une fois l'agent éprouvé en lecture, et sur un périmètre plus étroit encore. Écrire dans un espace de brouillons ou dans une file de propositions à valider n'a pas les mêmes conséquences qu'écrire directement dans le système de référence.
La validation humaine systématique rend l'agent inutile : si chaque action attend un clic, autant la faire soi-même. La validation doit donc être placée là où elle compte, sur les actions qui ne se rattrapent pas.
Ces actions sont identifiables à l'avance, et la liste suivante couvre la plupart des cas.
Le schéma suivant présente cette progression sous forme de paliers. Chaque palier n'est franchi que lorsque le précédent a fait ses preuves sur le périmètre concerné.
Un agent qui dispose d'un accès en lecture à des dossiers partagés, à une messagerie ou à des dépôts de code lit aussi tout ce qui s'y trouve par erreur : mots de passe notés dans un document, clés d'accès collées dans un ticket, identifiants transmis par e-mail. Pour l'agent, un identifiant lisible devient un accès utilisable.
Avant de connecter une source, une recherche des secrets qu'elle contient doit être menée, puis répétée à intervalle régulier. Les secrets découverts sont révoqués, remplacés et stockés dans un coffre dédié, auquel l'agent n'a pas accès. Un secret lisible par un agent doit être considéré comme déjà utilisé.
Journaliser les actions d'un agent n'a d'intérêt que si quelqu'un peut lire ces journaux. Une trace exploitable indique quelle donnée a été lue ou modifiée, à quel moment, pour quelle demande et avec quel résultat.
Ces journaux servent à trois moments : pendant la phase d'essai, pour décider d'élargir ou non les accès ; en cas d'incident, pour reconstituer ce qui s'est passé ; lors d'un contrôle, pour démontrer que l'agent a respecté son périmètre. Sans ces journaux, un accès hors périmètre peut passer inaperçu pendant des mois.
Un agent qui touche aux données de plusieurs services pose une question d'organisation autant que de technique. Sans répartition claire, chacun considère que la décision appartient à un autre, et l'agent se retrouve configuré par la seule équipe qui l'a installé.
Le Data Owner d'un domaine (clients, fournisseurs, ressources humaines, finance) décide si ses données peuvent être ouvertes à un agent, pour quelle finalité et avec quel droit. Il s'appuie sur le Data Steward pour identifier précisément les sources concernées et leur niveau de qualité.
Ce rôle n'est pas une formalité. Le Data Owner est le seul à pouvoir dire qu'un dossier nommé « Clients » contient aussi des données de prospects qui n'ont jamais donné leur accord, ou qu'un tableau partagé sert de référence à la facturation.
L'équipe sécurité définit comment un agent obtient une identité, comment ses droits sont attribués, comment ses actions sont tracées et comment un accès est révoqué. Elle ne décide pas si un agent commercial peut lire les fiches clients : c'est une décision métier, prise avec le Data Owner.
Cette séparation évite deux dérives opposées. Une sécurité qui décide seule tend à tout interdire, et les métiers contournent le dispositif avec des outils non validés. Des métiers qui décident seuls tendent à tout ouvrir, et la sécurité découvre l'agent lors du premier incident.
Chaque agent en production doit avoir un responsable nommé, côté métier. Il connaît la tâche, valide les évolutions du périmètre et répond des actions de l'agent comme il répondrait du travail de son équipe. La question de savoir qui est responsable de l'IA en entreprise, et de quoi exactement se pose ici de façon très concrète : un agent sans responsable identifié n'a pas sa place en production.
Les agents ne bénéficient d'aucun régime d'exception. Les règles qui s'appliquent au traitement de données personnelles et aux systèmes d'IA s'appliquent à eux, avec une difficulté supplémentaire : un agent peut créer de nouveaux traitements sans que personne ne l'ait décidé explicitement.
Le principe de minimisation impose de ne traiter que les données nécessaires à une finalité déterminée. Un agent qui a accès à l'ensemble d'une messagerie pour trier les demandes de devis traite bien plus de données personnelles que sa finalité ne le justifie.
Trois points méritent une vérification avant la mise en service, avec le délégué à la protection des données.
La protection des données personnelles n'est pas un frein à l'usage des agents. Elle fournit au contraire un cadre de décision déjà connu des équipes juridiques, ce qui accélère les arbitrages.
L'AI Act prévoit des obligations de transparence : une personne qui interagit avec un système d'IA doit en être informée, et les contenus générés doivent être signalés. Un agent qui répond à des clients ou à des candidats est directement concerné.
Si l'agent intervient dans un domaine classé à haut risque (recrutement, évaluation de crédit, accès à des services essentiels), il relève des obligations renforcées prévues par l'AI Act pour les systèmes à haut risque. Documentation, supervision humaine effective et conservation des journaux en font partie. Ce que l'IA Act change concrètement pour les projets IA mérite d'être examiné dès la conception de l'agent, pas au moment de l'échéance.
Un agent se déploie par étapes. Chaque étape élargit le périmètre sur la base de ce que l'étape précédente a montré, et non sur la base de ce que l'éditeur promet.
La première version d'un agent doit tourner en lecture seule, sur une seule source et pour une seule équipe. Cette phase dure le temps nécessaire pour observer des cas réels, y compris les demandes ambiguës ou mal formulées que les tests ne couvrent jamais.
Comme pour un POC IA dont il faut décider de la suite, les critères de passage à l'étape suivante sont fixés avant de commencer : taux de réponses exactes sur un échantillon relu, absence d'accès hors périmètre dans les journaux, retours des utilisateurs.
Chaque élargissement (nouvelle source, droit d'écriture, nouvelle équipe) fait l'objet d'une revue courte : que montrent les journaux de la période précédente, quelles erreurs ont été constatées, quelles actions auraient dû être bloquées ? Un accès ajouté sans relecture des journaux précédents est un accès ajouté à l'aveugle.
Cette revue n'a pas besoin d'être lourde. Une réunion de trente minutes entre le responsable métier, le Data Owner concerné et un représentant de la sécurité suffit, si les journaux sont lisibles.
Certains constats doivent entraîner la réduction immédiate des droits d'un agent, sans attendre la revue suivante. Les définir à l'avance évite de débattre au moment où il faut agir.
L'ouverture des données à un agent se prépare en quelques décisions, prises dans cet ordre. Chacune a un responsable et laisse une trace écrite.
Aucune de ces décisions ne dépend du modèle choisi. Toutes dépendent de l'organisation, ce qui fait de la gouvernance des accès le levier le plus direct pour déployer des agents sans exposer l'entreprise.
👉 À lire aussi : Gouverner l'IA en entreprise : rôles, règles et pilotage
Un assistant conversationnel produit une réponse qu'un humain relit avant d'agir. Un agent IA enchaîne lui-même des actions dans les systèmes de l'entreprise pour atteindre un objectif, sans validation à chaque étape. Cette différence change la nature du risque :
Aucune donnée n'est ouverte sans risque, mais certaines présentent un risque faible. La documentation interne à jour et les dossiers d'une équipe restreinte peuvent être ouverts en lecture en premier. Le classement se fait avant la connexion :
Non. Un agent doit disposer de sa propre identité, avec des droits plus restreints que ceux de la personne qu'il assiste. Le partage de compte rend les actions de l'agent indiscernables de celles du collaborateur. Une identité propre apporte plusieurs garanties :
La validation humaine se place sur les actions irréversibles. Les actions réversibles, comme un brouillon ou une proposition, peuvent être confiées à l'agent sans validation systématique. Les actions à valider sont connues à l'avance :
La décision est partagée. Le Data Owner autorise l'ouverture des données de son domaine, l'équipe sécurité fixe les mécanismes techniques et un responsable métier répond des actions de l'agent. Chaque rôle a un périmètre distinct :
Oui. Les agents ne bénéficient d'aucun régime particulier : le RGPD s'applique dès qu'ils traitent des données personnelles, et l'AI Act s'applique selon l'usage qui en est fait. Plusieurs obligations sont à prendre en compte :
Un agent démarre en lecture seule, sur une source et pour une équipe. Chaque élargissement se décide après relecture des journaux de la période précédente, selon des critères fixés au départ. La progression suit quelques règles simples :
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
%20copie.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)