Tu veux “donner de la data” à l’IA. Tu veux surtout éviter l’accident.
Dans beaucoup de boîtes, le scénario est toujours le même. Un cas d’usage IA arrive (analyse, reporting, RAG, entraînement). Une équipe dit : “On anonymise.” Puis on masque deux colonnes, on remplace les noms par des ID… et on se raconte que c’est bon.
Problème : “anonyme” n’est pas un label marketing. C’est une évaluation de risque d’identification. Et depuis juillet 2026, le message du régulateur est encore plus clair.
L’EDPB a publié les “Guidelines 02/2026 on Anonymisation” (v1.0, 7 juillet 2026, consultation jusqu’au 30 octobre 2026). Le point clé pour un dirigeant : l’anonymisation, ça se teste, et ça se reteste si le contexte change. Nouvel outil, nouvelle donnée externe dispo, nouveau partenaire, nouvelle capacité technique… ton “anonyme” peut redevenir “personnel”.
Objectif de cet article : te donner un plan terrain en 6 étapes, une grille de décision selon ton cas d’usage IA, et un modèle de registre de traitement simplifié pour cadrer un RGPD projet IA entreprise sans t’enfermer dans une usine à gaz.
Avant le plan : anonymisation vs pseudonymisation (version dirigeant)
Pseudonymisation : tu réduis le risque, mais tu restes dans le RGPD
Pseudonymiser, c’est remplacer des identifiants directs (nom, email, téléphone) par un alias (ID, hash, token), et protéger la “clé” de rapprochement. C’est utile. Ça limite la casse en cas de fuite. Mais ça ne “dé-RGPD-ise” pas.
Si toi (ou quelqu’un d’autre “raisonnablement susceptible” d’avoir les moyens) peut ré-identifier via une table de correspondance, des données auxiliaires, ou du recoupement, alors ça reste une donnée personnelle. Donc obligations RGPD, base légale, droits, sécurité, etc. L’ICO insiste justement sur ce piège : ne confonds pas pseudo et anonymisation.
Anonymisation : tu sors du RGPD, mais c’est dur (et jamais “définitif”)
Anonymiser, c’est rendre la donnée non rattachable à une personne de façon réaliste. Si c’est réussi, ces données sortent du champ du RGPD. Et là, oui, ça change tout : partage plus simple, moins de contraintes, moins de risques juridiques.
Mais ça exige une logique de test. Et l’EDPB 2026 formalise une idée très opérationnelle : l’anonymat dépend du point de vue de l’entité. Un dataset peut être “anonyme” pour un partenaire externe, mais rester “personnel” pour toi si tu gardes des infos auxiliaires ou une clé de rapprochement.
Les 3 critères EDPB 2026 à retenir (et à utiliser)
Les EDPB guidelines anonymisation posent 3 critères concrets pour juger si un jeu peut être considéré comme anonyme :
- No Record Isolation : impossible d’isoler l’enregistrement d’un individu (ou un petit groupe unique) dans le dataset.
- No Linkage : impossible de relier ce dataset avec d’autres jeux/événements pour ré-identifier.
- No Inference : impossible d’inférer une identité ou un attribut sensible de façon exploitable.
Traduction terrain : ce n’est pas “j’ai supprimé le nom”. C’est “même en attaquant intelligemment, je n’arrive pas à retrouver quelqu’un ni à déduire un truc sensible”.
La grille de décision : anonymiser, pseudonymiser, ou traiter en données perso encadrées
Tu choisis ta stratégie selon 2 axes : valeur pour l’IA vs exposition RGPD. Et surtout : est-ce que tu dois pouvoir revenir à la personne ?
Règle simple (qui évite 80% des erreurs)
Si tu dois revenir à une personne (support, relance, personnalisation, enquête qualité, gestion d’un litige), tu es structurellement en pseudonymisation au mieux. Donc RGPD.
Tableau rapide par cas d’usage IA
- Reporting / pilotage (CA, délais, volumes, qualité) : vise agrégation + anonymisation si possible. Souvent, tu n’as pas besoin de ligne par ligne nominative.
- Analyse exploratoire (détection de tendances, segmentation) : souvent pseudonymisation + minimisation. L’anonymisation est possible mais plus coûteuse si tu gardes de la granularité.
- RAG (recherche dans des docs internes, réponses assistées) : si tu mets des emails, CR, tickets, RH, tu touches vite de la donnée perso. Stratégie fréquente : minimiser + pseudonymiser + contrôler les sorties. L’anonymisation complète est rare si tu veux des réponses précises.
- Entraînement / fine-tuning : c’est le plus risqué. Si tu pars sur des données perso, il faut une base solide et un cadre béton. Si tu peux faire autrement, privilégie données anonymisées ou synthétiques (avec prudence) et surtout minimisation.
Le plan en 6 étapes (applicable dès aujourd’hui)
Étape 1 : cartographie “source → champs → finalité IA → accès”
Livrable : un tableau simple. Pas un roman.
- Source : CRM, ERP, tickets, emails, Drive, RH, factures, call center…
- Champs : ce qui part vraiment (et pas “tout le dossier”).
- Finalité IA : analyse, RAG, reporting, entraînement, détection…
- Accès : qui voit quoi, et via quel outil (ChatGPT Business/Enterprise, Copilot, outil interne, prestataire).
Piège classique : ne regarder que “nom/prénom”. L’EDPB rappelle qu’une donnée “relate” à une personne par son contenu, sa finalité ou son effet. Un identifiant machine, un historique d’actions, une combinaison d’attributs peuvent redevenir identifiants.
Étape 2 : minimiser avant de transformer (tu supprimes d’abord)
Règle terrain : tu supprimes ou agrèges avant de pseudonymiser/anonymiser. Sinon tu “protèges” un volume inutile, et tu gardes des angles d’attaque (linkage, inference).
Checklist minimisation :
- Supprimer identifiants directs inutiles (email, tel, adresse, NIR, IBAN…).
- Réduire la résolution : date → mois, âge → tranche, localisation → département/région.
- Couper les variables “à haute dimension” (trop de colonnes fines qui rendent chaque ligne unique).
- Limiter l’historique : 24 mois au lieu de 10 ans si ça suffit.
- Pour du texte libre (emails, notes) : filtrer ou résumer avant ingestion.
Impact dirigeant : moins de données = moins de risque = moins de coûts de conformité = plus simple à industrialiser.
Étape 3 : choisir la technique selon l’usage (et accepter le compromis)
Tu as 3 options. Choisis explicitement, au lieu de bricoler “un peu de tout”.
- Option A : anonymisation réelle (objectif : sortir du RGPD)
- Agrégation, généralisation, suppression forte.
- k-anonymity / l-diversity / t-closeness (attention : pas magique, mais utile pour cadrer).
- Bruit statistique (différential privacy et approches proches) si tu publies/partages des stats.
- Option B : pseudonymisation (objectif : réduire le risque, rester RGPD)
- Tokenisation (ID interne), hash avec salt, chiffrement.
- Clé de correspondance isolée, accès ultra restreint.
- Séparation des environnements et des rôles.
- Option C : données perso encadrées (objectif : qualité max, risque assumé et maîtrisé)
- Base légale, information, mesures de sécurité, contrôle fournisseur, clauses, etc.
- Sorties contrôlées (éviter la fuite via prompts/logs/exports).
Décision simple : plus tu veux de précision individuelle, plus tu te rapproches de B ou C. Et plus tu dois investir dans sécurité, logs, contrôle des accès, et gouvernance.
Étape 4 : tester la ré-identification (mini “test d’attaque” interne)
C’est le cœur des EDPB guidelines anonymisation : l’anonymisation est un test de risque, pas un maquillage.
Tu fais un test interne, même basique, aligné sur les 3 critères EDPB :
- No Record Isolation : est-ce qu’une ligne est unique ?
- Test : cherche des combinaisons rares (poste + ville + date + montant) qui pointent vers une seule personne.
- Si tu trouves des “unicités”, tu n’es pas anonyme.
- No Linkage : est-ce que je peux recouper avec un autre fichier ?
- Test : prends un dataset “auxiliaire” réaliste (annuaire interne, LinkedIn, fichiers partenaires, logs) et tente un rapprochement.
- Si tu arrives à ré-identifier avec un effort raisonnable, tu n’es pas anonyme.
- No Inference : est-ce que je peux déduire un attribut sensible ?
- Test : même sans identifier “Jean Dupont”, est-ce que je peux inférer santé, syndicat, difficultés financières, etc. sur un individu ou micro-groupe ?
- Si oui, tu as un risque sérieux, même “sans nom”.
Deux approches possibles (EDPB) :
- Contextuelle : tu évalues les moyens réellement disponibles pour tes acteurs (toi, prestataires, partenaires, attaquants plausibles).
- Simplifiée : tu prends une position plus conservatrice (souvent plus simple à appliquer en PME/ETI), quitte à surprotéger.
Ce test, tu le refais si le contexte change. Nouveau partenaire. Nouveaux champs. Nouvelles données externes accessibles. Nouvel outil IA. Sinon tu joues au “ça passait avant”.
Étape 5 : documenter la décision (preuve, pas blabla)
Le but n’est pas de remplir du papier. Le but est de pouvoir répondre vite à 3 questions :
- Qu’est-ce que tu fais ? (finalité IA, périmètre exact)
- Pourquoi tu as choisi anonymisation ou pseudo ? (compromis valeur/risque)
- Comment tu prouves que tu as testé ? (résultats, limites, actions correctives)
Ça te sert en audit, en incident, ou quand un client te challenge sur la confidentialité.
Si tu montes des agents et des connexions, tu peux aussi cadrer le sujet global “privacy ops” IA. Si tu veux un cadre plus large côté organisation, tu peux t’appuyer sur cet article du site : https://jimmymanin.com/blog/ai-act-x-rgpd-organise-tes-privacy-ops-ia-en-30-jours-et-evite-la-sanction-cnil.
Étape 6 : gouverner l’accès et les sorties (là où les fuites arrivent)
Beaucoup d’incidents ne viennent pas de la technique d’anonymisation. Ils viennent de l’opérationnel : mauvais droit, mauvais export, prompt copié-collé, log trop bavard.
Mesures terrain :
- Séparer prod vs bac à sable IA.
- RBAC (rôles) strict : qui peut charger des données, qui peut exporter, qui peut voir les logs.
- Journalisation : uploads, exports, requêtes, accès datasets.
- Règles de sortie : ce qui peut sortir en CSV, PDF, email, prompt, pièce jointe.
- Contrôles sur prompts et pièces jointes si tu utilises des assistants conversationnels avec documents.
Le point EDPB à garder en tête : l’anonymat s’apprécie par “entité”. Donc un même dataset peut être anonyme pour A et pas pour B selon les accès et données auxiliaires. Tes contrôles d’accès font partie du raisonnement.
Grille de décision rapide (à copier dans ton doc projet)
- Question 1 : as-tu besoin de revenir à la personne ?
- Oui : pseudonymisation ou données perso encadrées.
- Non : vise anonymisation/agrégation.
- Question 2 : le cas d’usage tolère-t-il moins de granularité ?
- Oui : agrège, généralise, supprime fort.
- Non : accepte RGPD et renforce gouvernance.
- Question 3 : y a-t-il un risque de recoupement réaliste ?
- Fort : anonymisation difficile, privilégie pseudo + contrôle d’accès + limitation des exports.
- Faible : anonymisation possible si test OK.
- Question 4 : données à haute dimension/haute résolution (beaucoup de colonnes fines) ?
- Oui : risque de ré-identification en hausse, minimisation obligatoire.
- Non : anonymisation plus accessible.
Modèle de registre de traitement simplifié (projet IA)
Tu peux coller ça dans un tableur. Objectif : trace claire, courte, défendable.
- Nom du traitement : “RAG Support client sur base tickets”
- Responsable : entité + sponsor interne (toi ou un directeur)
- Finalité : ex. “Réduire le temps de réponse N1, homogénéiser les réponses”
- Cas d’usage IA : analyse / RAG / reporting / entraînement
- Sources : Zendesk, emails, base FAQ, CRM
- Catégories de données : identifiants, contenu tickets, logs, métadonnées
- Personnes concernées : clients, prospects, salariés
- Minimisation appliquée : champs supprimés, agrégation, réduction historique
- Stratégie : anonymisation / pseudonymisation / données perso encadrées
- Techniques : tokenisation, hash+salt, généralisation dates, masquage texte, etc.
- Test ré-identification : date, méthode (isolement/linkage/inférence), résultat, actions
- Base légale (si données perso) : à renseigner avec DPO/conseil
- Destinataires : interne, prestataire, éditeur IA (et lesquels)
- Transferts : UE/hors UE (si applicable)
- Durée de conservation : dataset IA + logs + exports
- Mesures sécurité : RBAC, chiffrement, journaux, séparation environnements
- Règles de sortie : exports autorisés, validation, seuils
- Prochaine réévaluation : date et déclencheurs (nouvelle source, nouveau modèle, etc.)
Ce que tu gagnes si tu fais ça proprement
- Temps : moins d’allers-retours “c’est bon / c’est pas bon” entre métier, IT, DPO.
- Moins de coût projet : minimisation = moins de data à traiter, moins de complexité.
- Moins de risque : tu réduis les fuites et tu sais justifier tes choix.
- Plus de vitesse : tu peux partager certains jeux réellement anonymes plus librement.
Plan d’action 48h (si tu veux avancer sans t’enliser)
- Jour 1 matin : fais la cartographie “source → champs → finalité IA → accès” sur 1 cas d’usage.
- Jour 1 après-midi : fais minimisation (suppression, agrégation, baisse de résolution).
- Jour 2 matin : choisis la stratégie (anonyme/pseudo/perso encadré) et écris-la noir sur blanc.
- Jour 2 après-midi : fais un mini test d’attaque interne (isolement, linkage, inférence) + note le résultat dans ton registre simplifié.
Si tu connectes des agents à tes outils, ajoute un contrôle “fuites” et “accès” avant de laisser faire. Tu peux t’appuyer sur la checklist déjà publiée ici : https://jimmymanin.com/blog/ia-agentique-en-entreprise-la-checklist-rgpd-avant-de-connecter-un-agent-a-vos-outils.
Tu veux partager des données utiles sans basculer en risque. La voie la plus solide est simple : minimise, choisis explicitement, teste la ré-identification, documente, verrouille les accès et les sorties. Le reste, c’est de la croyance.
