L'IA agentique n'est plus seulement une interface conversationnelle avec un peu de mémoire. Un agent peut lire un contexte, appeler des outils, interagir avec d'autres services, déclencher des actions et conserver des traces de travail. C'est précisément cette capacité à agir qui transforme la protection des données en sujet d'architecture.
La note publiée par la CNIL et le CIANum replace le débat au bon niveau. Les agents peuvent faire circuler des données personnelles entre plusieurs services, créer de nouveaux historiques, enrichir des profils et rendre la chaîne de responsabilité moins évidente. Dans un chatbot classique, l'utilisateur voit généralement ce qu'il transmet. Dans un système agentique, une demande peut devenir une suite d'opérations que l'utilisateur ne contrôle pas directement.
Pourquoi le changement d'échelle est réel
Un agent branché sur un système d'information ne travaille pas dans le vide. Il peut consulter un CRM, chercher dans des documents internes, ouvrir un ticket, relire un historique de conversation, appeler une API métier et proposer une action. Chacune de ces étapes a son propre niveau de sensibilité.
Le risque vient de la combinaison. Une information inoffensive dans un outil peut devenir sensible quand elle est croisée avec un autre contexte. Une donnée utile pour répondre à une question peut aussi être conservée trop longtemps, réutilisée dans un autre flux ou exposée dans un journal technique. La gouvernance ne peut donc pas se limiter à une case "données personnelles" cochée en fin de projet.
Le piège de la couche ajoutée trop tard
Beaucoup d'expérimentations commencent par ajouter un agent au-dessus d'outils existants. Le prototype fonctionne vite : l'agent trouve des documents, rédige des réponses, crée des tâches. Mais si les permissions, les journaux et les règles de validation ne sont pas pensés dès le départ, l'équipe découvre ensuite que le système peut accéder à trop de choses ou agir dans des zones mal définies.
Ce piège est courant parce que l'agent donne une impression d'interface unique. En réalité, il amplifie les droits des systèmes auxquels il est connecté. Si un connecteur donne accès à l'ensemble d'un espace documentaire, l'agent peut être tenté d'utiliser ce contexte même quand la demande ne le justifie pas. Si une action est disponible techniquement, il faut décider si elle est disponible fonctionnellement.
Mettre les permissions dans l'architecture
Le principe du moindre privilège doit devenir un réflexe agentique. Un agent qui classe des documents n'a pas besoin du même niveau d'accès qu'un agent qui modifie une fiche client ou déclenche un paiement. Les rôles doivent être séparés, les scopes limités et les actions sensibles placées derrière une validation explicite.
La conception doit aussi distinguer lecture, préparation et exécution. Laisser un agent proposer un message n'est pas la même chose que l'autoriser à l'envoyer. Lui permettre de détecter une anomalie n'est pas la même chose que lui permettre de modifier une donnée de production. Ces distinctions doivent apparaître dans les composants, pas seulement dans les consignes.
Mémoire, logs et droit à l'explication
La mémoire d'un agent peut améliorer l'expérience, mais elle ajoute une responsabilité. Que conserve-t-on ? Pendant combien de temps ? Qui peut relire l'historique ? Comment supprimer une donnée ? Comment expliquer une décision si l'agent a utilisé plusieurs sources et plusieurs outils ?
Les journaux doivent être assez complets pour auditer une action, mais assez sobres pour ne pas devenir eux-mêmes un réservoir de données sensibles. L'objectif est de reconstruire une chaîne : demande initiale, sources consultées, outils appelés, sortie proposée, validation éventuelle et action finale.
Une décision produit autant que juridique
La gouvernance des agents IA n'est pas seulement l'affaire du DPO ou de la sécurité. Elle touche directement l'expérience utilisateur. Un produit qui délègue trop sans expliquer crée de la défiance. Un produit qui demande une validation à chaque clic devient inutilisable. Le bon équilibre dépend du niveau de risque : assistance, recommandation, préparation d'action ou exécution autonome.
Les agents IA peuvent rendre les outils plus efficaces, mais ils obligent les équipes à rendre l'autonomie visible. Les données, les permissions et les validations doivent être traitées comme des fonctionnalités de base. C'est à cette condition que l'IA agentique peut passer du prototype impressionnant au service réellement exploitable.
