Des agents qui agissent, pas juste des chatbots : le RGPD ne se gère plus pareil
À Lyon comme ailleurs, beaucoup d’entreprises ont déjà un “assistant IA” qui résume des mails, aide à rédiger, ou répond sur une base documentaire. La marche d’après, c’est l’IA agentique : un système qui ne se contente pas de produire du texte, mais déclenche des actions dans tes outils. Et c’est là que la conformité RGPD se complique.
La “note CNIL en préparation” dont on entend parler est en réalité déjà là. La CNIL et le Conseil de l’IA et du Numérique (CIANum) ont publié une note exploratoire sur “IA agentique et données personnelles” (été 2026). Leur message est simple : on passe de l’IA générative à un modèle qui “change d’échelle”, car ces systèmes agissent sur leur environnement, se connectent à plusieurs services, et font circuler des données personnelles entre briques. Source : CNIL, note exploratoire “IA agentique et données personnelles” (CNIL x CIANum) https://cnil.fr/fr/ia-agentique-cnil-cianum-note?trk=public_post_comment-text
Si tu déploies des agents IA entreprise (copilotes, assistants, agents multi-outils), ce papier change surtout une chose : tu dois arrêter de penser “conversation”. Tu dois penser chaîne d’opérations, traces, connecteurs, sous-traitants, et effacement dans un environnement où les données se dupliquent.
IA agentique : une définition utile côté conformité
La définition “marketing” d’un agent varie selon les éditeurs. La définition utile pour le RGPD est plus nette.
Dans l’approche CNIL, une IA agentique se distingue parce qu’elle :
- ne fait pas que produire une réponse : elle peut déclencher des actions (exécuter une tâche, appeler un outil, écrire dans un SI, contacter un tiers),
- orchestré des flux entre services connectés (messagerie, drive, CRM, ticketing, RH, calendrier, etc.).
Source : note exploratoire CNIL x CIANum https://cnil.fr/fr/ia-agentique-cnil-cianum-note?trk=public_post_comment-text
Exemples concrets (les cas qu’on voit déjà en PME lyonnaise)
- Agent “Sales” qui lit le CRM, rédige un mail, puis crée une tâche et planifie un rendez-vous.
- Agent “Support” qui résume un ticket, classe la demande, met à jour la fiche client, et déclenche un remboursement selon des règles.
- Agent “RH” qui récupère des CV, pré-remplit une fiche dans un ATS et notifie un manager.
À chaque fois, tu ne gères plus un texte. Tu gères des opérations sur des données, parfois dans 5 outils différents, avec des copies, des logs, des erreurs possibles, et des accès à cadrer.
Pourquoi l’IA agentique complique le RGPD
1) Finalités : “assistant” ne suffit plus
La CNIL martèle, sur l’IA générative, l’importance de clarifier les finalités dès la conception et d’identifier base légale et usages techniquement envisageables, même pour des systèmes généralistes. Source : liste de vérification CNIL IA (PDF) https://cnil.fr/sites/default/files/2025-07/ia_liste_de_verification.pdf
Avec l’agentique, la finalité “assistance” explose en sous-finalités. Exemple : “assister le service client” devient :
- lire une demande entrante,
- identifier le client,
- consulter l’historique,
- proposer une réponse,
- mettre à jour une fiche,
- déclencher une action (geste commercial, expédition, escalade).
Pour le RGPD, tu dois pouvoir dire : pour quoi l’agent traite quelles données, et jusqu’où il a le droit d’aller. Sinon, tu documentes du flou. Et le flou finit mal en audit.
2) Minimisation : les connecteurs aspirent tout si tu ne les brides pas
La note exploratoire insiste sur l’accès à plusieurs sources et la circulation des données personnelles entre services. Source : note exploratoire CNIL x CIANum https://cnil.fr/fr/ia-agentique-cnil-cianum-note?trk=public_post_comment-text
Erreur classique en déploiement : “on branche la boîte mail, le drive, le CRM et l’ERP pour que l’agent soit performant”. Sauf que tu viens de créer :
- un accès transverse à des données non nécessaires,
- des risques de consultation hors périmètre (ex : pièces RH dans un drive),
- des copies de données dans prompts, caches, mémoires et logs.
La minimisation, en agentique, n’est pas une ligne dans un document. C’est une configuration d’autorisations (rôles, scopes, contextes) et une conception de flux (quelles données entrent et ressortent).
3) Mémoires persistantes : le point chaud CNIL
Un point de vigilance mis en avant par la CNIL : les mémoires persistantes et la conservation de l’historique d’interactions. Ça augmente la quantité de données stockées, facilite des profils hyper-personnalisés et crée un risque de perte de maîtrise pour l’utilisateur. Source : note exploratoire CNIL x CIANum https://cnil.fr/fr/ia-agentique-cnil-cianum-note?trk=public_post_comment-text
Traduction opérationnelle : si ton agent “se souvient” de tout pour “mieux aider”, tu dois être capable de répondre à ces questions :
- où la mémoire est stockée (éditeur ? base interne ? outil tiers ?),
- ce qui y entre (PII ? données sensibles ? secrets ?),
- combien de temps tu gardes,
- comment tu purges et comment tu prouves que tu as purgé.
4) Sous-traitants : la chaîne de valeur s’allonge
La CNIL rappelle, pour l’IA générative, qu’en tant qu’utilisateur/intégrateur tu dois interroger le fournisseur sur la conformité, et que les responsabilités varient selon l’intégration (fine-tuning, RAG, etc.). Source : FAQ CNIL IA générative (18 juillet 2024) https://www.cnil.fr/fr/les-questions-reponses-de-la-cnil-sur-lutilisation-dun-systeme-dia-generative
En agentique, tu empiles souvent :
- un fournisseur de modèle (ou plusieurs),
- une plateforme d’agent,
- un hébergeur,
- des outils tiers appelés par l’agent (API),
- des SaaS connectés (CRM, support, storage).
Côté RGPD, ça veut dire : qualification des rôles (responsable de traitement, sous-traitant, sous-traitant ultérieur), clauses, et maîtrise des transferts si des données sortent de l’UE.
5) Droits des personnes : effacer devient un sport
La note exploratoire insiste sur la conservation des historiques et mémoires persistantes sur des supports variés. Résultat : une demande d’effacement peut devenir compliquée si les données sont dupliquées dans des mémoires, logs, caches ou services. Source : note exploratoire CNIL x CIANum https://cnil.fr/fr/ia-agentique-cnil-cianum-note?trk=public_post_comment-text
Si tu ne sais pas où l’agent a copié la donnée, tu ne sais pas l’effacer. Et si tu ne peux pas l’effacer, tu ne sais pas répondre proprement à une demande RGPD.
6) Logs et traçabilité : c’est un sujet SI, pas un sujet “IA”
La conformité devient dépendante de ta capacité à journaliser ce que fait l’agent. La CNIL a une recommandation dédiée à la journalisation : enregistrer les opérations (création, consultation, modification, suppression), avec auteur identifié, horodatage, nature de l’opération et référence des données concernées. Source : recommandation CNIL “journalisation” (PDF) https://www.cnil.fr/sites/cnil/files/atoms/files/recommandation_-_journalisation.pdf
La CNIL rappelle aussi que les logs doivent pouvoir être analysés, y compris via des mécanismes automatiques pour détecter des usages indus. Source : article CNIL sur les mesures de journalisation https://www.cnil.fr/fr/la-cnil-publie-une-recommandation-relative-aux-mesures-de-journalisation
Pièges classiques :
- pas de logs, ou logs inutilisables (pas de corrélation requête → action),
- logs trop verbeux (tu stockes des données personnelles “en traces”),
- réutilisation des logs à une autre finalité (détournement). Sur la sécurité et la finalité, voir aussi le guide CNIL “sécurité des données personnelles” (2024) https://cnil.fr/sites/default/files/2024-03/cnil_guide_securite_personnelle_2024.pdf?utm_source=openai
Check-list opérationnelle : cadrer un agent IA entreprise à Lyon (sans paperasse inutile)
Objectif : être capable de répondre à deux questions en audit. 1) Qu’est-ce que l’agent peut faire exactement ? 2) Comment tu l’empêches de faire le reste ?
Étape 1 : cartographier les actions possibles (pas seulement les données)
Fais une fiche par agent (ou par “capacité” si tu as un agent multi-modes) :
- Déclencheurs : chat, email entrant, webhook, action utilisateur, planification.
- Actions : lire, rechercher, exporter, créer, modifier, supprimer, envoyer, payer, clôturer, approuver.
- Systèmes touchés : M365/Google Workspace, CRM, ERP, ticketing, drive, RH, messagerie, outils métier.
- Catégories de données : clients, prospects, salariés, fournisseurs, logs, identifiants, données sensibles éventuelles.
- Sorties : emails, documents, tickets, écritures CRM, notifications, exports.
Tu obtiens une carte des opérations. C’est la base pour borner les finalités et la minimisation.
Étape 2 : borner les finalités et les sous-finalités
- Finalité principale (ex : “traiter les demandes SAV”).
- Sous-finalités (ex : “classer”, “répondre”, “créer un ticket”, “mettre à jour le dossier”).
- Hors-périmètre explicite : ce que l’agent n’a pas le droit de faire (ex : “consulter des dossiers RH”, “exporter une liste de clients”, “envoyer à un tiers”).
Sans hors-périmètre, tu ne protèges rien. Tu espères.
Étape 3 : minimisation par design (scopes, rôles, contexte)
- Accès par rôle : l’agent support n’a pas à voir la paie.
- Scopes d’API minimaux : lecture seule si possible, écriture seulement là où nécessaire.
- Filtrage par contexte : accès au dossier client uniquement si un identifiant client est fourni et validé.
- Débranchement par défaut : aucun connecteur “full drive” sans justification.
Règle simple : si tu ne peux pas expliquer pourquoi l’agent a accès à une source, il ne doit pas y accéder.
Étape 4 : garde-fous sur les actions à impact
Classe les actions en trois niveaux, et traite-les différemment.
- Niveau 1 (faible impact) : rédiger un brouillon, proposer une réponse, résumer. OK sans validation, mais avec supervision et limites.
- Niveau 2 (impact opérationnel) : créer un ticket, modifier une fiche CRM, envoyer un email à un client. Exige une validation humaine ou un mode “brouillon + confirmation”.
- Niveau 3 (impact fort) : suppression de données, export massif, changement de coordonnées bancaires, paiement, décision RH. Là, tu veux du double contrôle, des restrictions fortes, voire pas d’automatisation.
Étape 5 : encadrer la mémoire et l’historique
- Mémoire désactivée par défaut, sauf besoin réel documenté.
- Mémoire séparée par utilisateur si tu dois personnaliser, pour limiter la contamination croisée.
- Durées de conservation courtes et appliquées techniquement (purge automatisée).
- Interdits : pas de stockage de pièces d’identité, données de santé, secrets, mots de passe dans une mémoire “agent”.
Étape 6 : journaux exploitables, mais pas intrusifs
Tu veux pouvoir reconstituer “qui a fait quoi” sans te créer une base de données de surveillance.
- Identifiant de corrélation par requête et par action.
- Horodatage et identité (utilisateur, agent, service account).
- Nature de l’action (lecture, écriture, suppression, envoi).
- Références (ID d’objet CRM, ID ticket) plutôt que contenu complet, quand c’est possible.
- Rétention des logs alignée sur ta politique (ni éternelle, ni insuffisante).
Pour cadrer la journalisation, base-toi sur la recommandation CNIL : https://www.cnil.fr/sites/cnil/files/atoms/files/recommandation_-_journalisation.pdf
Étape 7 : sous-traitants, sous-traitants ultérieurs et “où part la donnée”
- Liste de tous les prestataires impliqués (modèle, plateforme, hébergement, connecteurs).
- Contrats : clauses de sous-traitance, audit, sécurité, confidentialité.
- Transferts : vérifier si données hors UE, et sur quelle base.
- Réutilisation : clarifier si les données servent ou non à entraîner/améliorer un modèle côté fournisseur (et à quelles conditions).
Pour une base CNIL côté IA générative, voir la FAQ : https://www.cnil.fr/fr/les-questions-reponses-de-la-cnil-sur-lutilisation-dun-systeme-dia-generative
Étape 8 : droits des personnes, version agentique
- Accès : savoir retrouver ce qui a été utilisé et produit (traces, actions, documents générés).
- Effacement : cartographier où la donnée peut se retrouver (mémoire, logs, caches, systèmes tiers).
- Opposition : prévoir un mode “opt-out” quand c’est pertinent (ex : pas d’usage d’un historique pour personnaliser).
Ton test pratique : “on reçoit une demande d’effacement d’un client. On fait quoi, étape par étape, et qui exécute ?”. Si tu n’as pas de réponse, tu n’es pas prêt.
Cas à risque : comment mettre à jour ton registre et ton DPIA
Quand un agent IA touche des données personnelles de manière large, persistante, ou avec des actions à impact, tu bascules vite dans un niveau de risque qui exige plus de preuves. Deux objets sont à bétonner : le registre des traitements et, pour les cas les plus sensibles, la DPIA (analyse d’impact).
Mettre à jour le registre : ce qui change avec l’IA agentique
Pour chaque traitement lié à un agent :
- Finalités et sous-finalités (liste concrète d’actions permises).
- Catégories de personnes (clients, prospects, salariés) et catégories de données.
- Sources (outils connectés) et destinataires (outils ciblés, services tiers).
- Durées de conservation séparées : contenu conversationnel, mémoire, documents produits, logs.
- Mesures de sécurité : contrôle d’accès, séparation des rôles, journalisation, alertes, chiffrement, revue des permissions.
- Sous-traitants et sous-traitants ultérieurs, avec localisation et transferts éventuels.
Point clé agentique : documenter les actions et pas seulement “usage d’un LLM”.
Quand une DPIA devient difficile à éviter
Sans faire de surpromesse, retiens une règle prudente : une DPIA devient très pertinente (souvent nécessaire) si ton agent :
- agit sur des données à grande échelle (support, CRM, RH),
- utilise une mémoire persistante riche,
- automatise des actions à fort impact (suppression, décisions, paiements, RH),
- croise plusieurs sources (profilage implicite),
- ou crée une perte de maîtrise possible pour les personnes.
Mettre à jour la DPIA : les ajouts spécifiques agentiques
- Description détaillée des flux : déclencheur → outils appelés → données lues → données écrites → destinataires.
- Nécessité et proportionnalité : pour chaque connecteur, pourquoi il est indispensable, et quel filtrage existe.
- Évaluation des risques centrée sur l’agentique : action non voulue, action irréversible, fuite via logs, dérive de mémoire.
- Mesures : validation humaine (N2/N3), limitations de scopes, sandbox, monitoring, alertes, purge mémoire, politique de logs.
- Tests : scénarios d’abus (ex : “exporte tous les clients”, “trouve le salaire de X”), et preuve que l’agent échoue.
- Plan de réponse : quoi faire si l’agent agit mal (rollback, gel, enquête via logs, notification).
Plan d’action en 10 jours pour une entreprise lyonnaise qui veut déployer propre
- J1 : inventaire des agents et assistants, même “en test”.
- J2 : cartographie des actions possibles par agent (pas juste les données).
- J3 : liste des connecteurs, scopes, comptes techniques, et suppression des accès “trop larges”.
- J4 : classification des actions N1/N2/N3 et ajout des validations humaines.
- J5 : cadrage mémoire persistante (off par défaut, rétention, purge).
- J6 : mise à niveau logs (corrélation, rétention, minimisation des traces).
- J7 : revue sous-traitants (qui fait quoi, où va la donnée).
- J8 : procédure droits des personnes version agentique (accès/effacement).
- J9 : mise à jour registre, et déclenchement DPIA si besoin.
- J10 : exercice à blanc “incident agentique” (erreur d’action, fuite via connecteur, etc.).
Ce que tu dois retenir (et faire dès maintenant)
La note exploratoire CNIL x CIANum ne dit pas “n’y allez pas”. Elle dit : l’IA agentique change la nature du risque parce qu’elle agit et connecte. Donc le RGPD ne se gère pas en mode “outil IA”. Il se gère en mode système d’information : finalités bornées, minimisation par design, chaîne de sous-traitance claire, droits opérables, et traçabilité propre.
Si tu dois choisir une première action simple à Lyon, demain matin : liste les actions exactes que ton agent peut déclencher, et mets une validation humaine sur tout ce qui modifie, envoie, supprime ou paie. C’est la différence entre un assistant et une bombe à retardement.
À lire aussi sur Lyon IA : si tu veux compléter l’angle conformité et garde-fous, tu peux croiser avec ces contenus déjà publiés :
Laisser un commentaire