IA agentique en entreprise : la checklist RGPD avant de connecter un agent à vos outils

Tu veux connecter un agent IA à ton CRM, ton ticketing, ton Drive ? Stop. Fais ça d’abord.

Brancher un agent IA sur tes outils internes, ce n’est pas “ajouter un chatbot”. C’est ouvrir des flux sur des données perso : clients, prospects, salariés, parfois des infos sensibles planquées dans des notes libres ou des pièces jointes.

Donc RGPD. Point.

Et avec l’IA agentique, tu ajoutes un risque spécifique : fuite ou mémorisation involontaire via prompts, logs, outputs, embeddings, caches. Sans parler des attaques d’extraction (on force le système à recracher des données). La CNIL a été très claire : les principes RGPD restent le socle, et “le fournisseur dit que c’est anonyme” ne vaut rien si tu ne peux pas le démontrer.

Objectif de cet article : une checklist RGPD terrain pour cadrer ton IA agentique RGPD avant le moindre branchement, savoir quand déclencher une DPIA (DPIA agent IA), et une méthode en 60 minutes pour classer tes cas d’usage : OK, OK sous conditions, Non.

Ce que “agentique connecté” change vraiment côté RGPD

Un agent IA connecté, c’est typiquement :

• Un LLM (ChatGPT, Claude, Gemini, Copilot, modèle open source) + des connecteurs (CRM, Drive, ticketing, SIRH…).
• Un moteur de recherche interne (RAG) avec index/embeddings.
• Des actions possibles : créer un ticket, envoyer un mail, modifier une fiche CRM, générer un document, lancer un remboursement, etc.

RGPD, ça veut dire : tu mets en place un traitement de données personnelles avec collecte, consultation, transformation, parfois prise de décision ou assistance à la décision. Donc tu dois cadrer :

• Finalité (pourquoi tu fais ça, en 1 phrase).
• Base légale (tu la choisis, tu ne la devines pas).
• Minimisation (l’agent ne voit que ce qui est utile).
• Sécurité (accès, secrets, intégrité).
• Traçabilité (qui a fait quoi, avec quelles sources, et quand).
• Droits des personnes (accès, rectification, opposition, etc.).

Si tu ne fais pas ça, tu ne “gagnes pas du temps”. Tu fabriques un risque : incident, perte de données, conflit social, ou demande CNIL ingérable.

La checklist RGPD “agent IA connecté” (avant de brancher quoi que ce soit)

1) Cartographie express des données (10 minutes)

Tu prends une feuille. Tu listes tout ce que l’agent peut lire et écrire.

• CRM (HubSpot, Salesforce, Pipedrive…)
• Ticketing (Zendesk, Freshdesk, Jira Service Management…)
• Drive (Google Drive, SharePoint, OneDrive…)
• Messagerie (Gmail, Outlook…)
• ERP, facturation
• SIRH
• Base de connaissances interne
• Enregistrements d’appels, visios

Pour chaque source, tu notes :

• Catégories de personnes : clients, prospects, salariés, candidats, fournisseurs.
• Types de données : identité, contact, historique d’achat, plaintes, notes libres.
• Données à risque : santé, mineurs, données financières (IBAN), données RH (sanctions, évaluations), “notes libres” (le cimetière RGPD).
• Échelle : petit volume ou grande échelle.
• Durées : combien de temps ça traîne.

Décision dirigeant : si tu touches RH, santé, vulnérables, ou des décisions qui impactent des personnes, tu bascules en “haut risque” et tu ralentis. Tu ne fais pas un POC sauvage.

2) Finalité, rôles et base légale (10 minutes)

Tu écris une finalité unique. Une phrase. Pas trois objectifs flous.

Exemple propre : “Aider l’équipe support à rédiger des réponses à partir des tickets et de la base de connaissances, avec validation humaine.”

Ensuite :

• Responsable de traitement : toi (ton entreprise), dans 95 % des cas.
• Sous-traitants : éditeur de l’agent, hébergeur, fournisseur LLM, plateforme d’automatisation.

Base légale : tu choisis et tu documentes. En pratique, on voit souvent :

• Contrat : exécution du support client, gestion d’un dossier.
• Intérêt légitime : amélioration du service, productivité, sous réserve de test de mise en balance.
• Obligation légale : cas plus rares mais possibles (conservation, conformité).

Piège classique : “on met consentement et c’est bon”. Non. Le consentement est fragile, difficile à prouver, difficile à retirer proprement dans un système connecté.

3) Minimisation “par design” (15 minutes)

La minimisation n’est pas un principe moral. C’est un levier concret : moins l’agent voit, moins tu risques la fuite, l’erreur, et la demande ingérable.

Checklist minimisation :

• Scopes minimum sur chaque connecteur : un pipeline CRM, un projet ticketing, un dossier Drive. Pas “tout”.
• Champs autorisés : tu whitelist. Tu masques téléphone, IBAN, date de naissance, notes libres si inutile.
• Fenêtre temporelle : 30 à 90 jours de tickets au départ. Pas 5 ans.
• Pièces jointes : off par défaut. Une PJ, c’est souvent passeport, RIB, arrêt maladie, contrat…
• Sorties : l’agent ne doit pas “réafficher” des données complètes si ce n’est pas nécessaire (ex. afficher un identifiant de ticket plutôt que le contenu).

Cas particulier : RAG / embeddings. Si tu indexe des documents internes, tu crées un stockage dérivé (index vectoriel). Traite-le comme un actif RGPD :

• finalité claire,
• accès restreint,
• durée de conservation,
• purge,
• traçabilité des documents indexés.

4) Traçabilité et journalisation “audit” (10 minutes)

Tu veux pouvoir répondre à ces questions en 2 minutes :

• Qui a lancé l’agent ?
• Quand ?
• Avec quel connecteur ?
• Quelles sources ont été consultées (au minimum : dépôt/dossier/projet ; idéalement : liste de documents) ?
• Quelles actions l’agent a tenté (lecture, écriture, suppression, envoi mail) ?
• Résultat : succès, échec, et surtout validation humaine ou non.

Important : des logs “techniques” ne suffisent pas. Il te faut des logs exploitables en cas d’incident, d’audit, ou de demande d’une personne concernée.

Autre point dur : tes logs peuvent contenir des données personnelles (prompts, extraits). Donc : minimisation des logs, rétention courte, accès limité.

5) Accès, séparation des pouvoirs, validation humaine (10 minutes)

Règle simple : l’agent ne doit jamais avoir plus de droits que l’utilisateur.

• Moindre privilège : comptes de service dédiés, droits minimaux, revues régulières.
• Sépare lecture et écriture : tu démarres en lecture seule, ou lecture + brouillons. L’écriture en prod vient plus tard.
• Validation humaine significative dès qu’il y a impact possible sur une personne : support, RH, finance, recouvrement.
• Stop conditions : si l’agent sort du cadre (ex. tente d’accéder à un dossier hors scope), il s’arrête.

6) Confidentialité fournisseur : ce que tu dois vérifier sans te faire endormir

Tu poses noir sur blanc :

• Où sont traitées les données (UE, hors UE) ?
• Qui y a accès (support, sous-traitants en chaîne) ?
• Les données sont-elles réutilisées pour entraîner des modèles ?
• Quels paramètres pour désactiver la réutilisation et réduire la conservation ?
• Quid des caches, journaux, “amélioration produit” ?

Tu ne te contentes pas d’une phrase marketing “vos données sont sécurisées”. Tu veux des engagements, et un paramétrage compatible avec ton niveau de risque.

Quand déclencher une DPIA pour un agent IA (DPIA agent IA)

La DPIA (analyse d’impact) n’est pas un document pour faire plaisir. C’est ton assurance “je sais ce que je fais”.

Déclenche une DPIA dès que tu coches une ou plusieurs cases ci-dessous (règle pratique, dirigeant-friendly) :

• Grande échelle : beaucoup de personnes, beaucoup de données, ou surveillance continue.
• Données sensibles ou très intimes : santé, RH, mineurs, vulnérables.
• Décision ou quasi-décision : scoring, priorisation, refus, recouvrement, sanctions, recrutement.
• Croisement de sources : CRM + mails + Drive + support, tu reconstruis une vue très complète d’une personne.
• Agent qui agit (écrit, envoie, supprime) et pas juste “assiste”.
• Tech nouvelle + incertitude : RAG, embeddings, outils agentiques, accès multi-systèmes.

À retenir : plus tu passes d’un assistant à un agent qui exécute, plus tu te rapproches du besoin DPIA.

Et si tu industrialises des agents, tu as intérêt à standardiser tes DPIA : l’EDPB a adopté un modèle de DPIA en avril 2026 pour harmoniser la preuve.

Méthode en 60 minutes : trier “OK”, “OK sous conditions”, “Non” avant connexion

Tu peux faire ce tri en comité très court : toi + DPO si tu en as un (ou conseil), + responsable SI, + owner métier (support, sales, RH…).

Minute 0 à 10 : score “données”

Tu prends la cartographie express et tu coches :

• Données clients/prospects simples (nom, mail pro) : 1 point
• Données salariés / candidats : 3 points
• Notes libres non maîtrisées : 3 points
• Pièces jointes : 4 points
• Données sensibles (santé, etc.) : 6 points

Si tu dépasses 6 points : tu es en zone rouge. Tu ne connectes pas “comme ça”.

Minute 10 à 20 : score “actions”

• Lecture seule : 1 point
• Rédaction de brouillons (mail/ticket) : 2 points
• Écriture dans CRM / création ticket : 4 points
• Suppression / envoi externe / paiement : 6 points

Si tu as 6 points ici : validation humaine obligatoire + garde-fous serrés, sinon c’est non.

Minute 20 à 35 : score “contrôle”

Tu coches ce que tu as déjà, maintenant :

• Scopes minimaux par connecteur : -2
• Champs whitelistés / masqués : -2
• Fenêtre temporelle limitée : -1
• Pièces jointes désactivées : -2
• Logs audit exploitables : -2
• Validation humaine en place : -2

Si tu n’arrives pas à descendre ton risque avec ces contrôles, c’est que le cas est mal choisi ou trop ambitieux.

Minute 35 à 50 : décision “OK / OK sous conditions / Non”

Règle simple :

• OK si : données basiques, lecture ou brouillons, scopes serrés, logs, validation humaine si besoin.
• OK sous conditions si : données mixtes ou notes libres, RAG/embeddings, écriture limitée. Tu listes les conditions obligatoires avant prod (masquage, rétention, DPIA, etc.).
• Non si : données sensibles ou RH + agent qui agit sans contrôle + pas de logs audit + périmètre trop large.

Minute 50 à 60 : tu remplis la fiche de décision dirigeant

Une page. Pas un roman. Le but : décider, cadrer, et pouvoir prouver.

Modèle : fiche de décision dirigeant (copier-coller)

Nom du cas d’usage :
Ex. “Agent support: brouillons de réponse Zendesk + base de connaissances”

Owner métier : …
Owner SI : …
DPO / référent RGPD : …

Finalité (1 phrase) :
…

Sources connectées :

• Lecture : …
• Écriture : …

Catégories de données personnelles :

• Clients : oui/non, types : …
• Prospects : oui/non, types : …
• Salariés : oui/non, types : …
• Sensibles : oui/non, lesquelles : …

Base légale : contrat / intérêt légitime / obligation légale / autre (préciser)
Test de mise en balance (si intérêt légitime) : fait / à faire

Minimisation appliquée :

• Scopes : …
• Champs autorisés : …
• Fenêtre temporelle : …
• Pièces jointes : off/on (si on, pourquoi) …
• RAG/embeddings : oui/non, où est l’index, qui y accède, purge : …

Traçabilité :

• Logs “audit” activés : oui/non
• Contenu des logs : qui/quand/sources/actions/résultat : oui/non
• Rétention logs : … jours

Accès et sécurité :

• Moindre privilège : oui/non
• Compte de service dédié : oui/non
• Lecture seule au départ : oui/non
• Validation humaine : obligatoire / non requise (justifier)

DPIA : requise / non requise (justification en 3 lignes)
Date décision DPIA : …

Décision : OK / OK sous conditions / NON
Conditions (si OK sous conditions) :

• …
• …

Date de revue (obligatoire) : … (ex. dans 30 jours après pilote)

Deux rappels qui t’évitent 80 % des problèmes

1) Commence “petit et traçable”, pas “grand et flou”

Le meilleur pattern : lecture seule + brouillons + validation humaine + logs. Tu récupères déjà une grosse partie du gain de temps, sans jouer au poker avec tes données.

Pour cadrer le déploiement sans ouvrir les vannes, tu peux t’appuyer sur ce plan : https://jimmymanin.com/blog/agents-ia-en-entreprise-le-plan-pilote-controle-en-21-jours-sans-ouvrir-les-vannes

2) Sécurité et RGPD sont collés

Un agent connecté augmente ta surface d’attaque. Ce n’est pas théorique. Donc tu poses aussi tes contrôles anti-fuite avant prod. Checklist sécurité complémentaire ici : https://jimmymanin.com/blog/agents-ia-en-entreprise-checklist-securite-en-12-points-anti-fuite-avant-deploiement

Plan d’action direct : fais le tri aujourd’hui, et connecte demain (si c’est OK)

Si tu dois le faire en une heure chrono :

• 10 min : cartographie sources + données à risque.
• 10 min : finalité unique + base légale + qui est sous-traitant.
• 15 min : minimisation (scopes, champs, temps, PJ, RAG).
• 10 min : logs audit + rétention.
• 10 min : accès (moindre privilège) + validation humaine.
• 5 min : décision OK / OK sous conditions / Non + date de revue.

Tu obtiens deux choses utiles : un agent cadré, et une preuve de pilotage. C’est ça qui te fait gagner du temps sans te fabriquer un risque RGPD.