Un script ne suffit pas
Chaque équipe de science des données a écrit quelque chose comme ça :
import re
def anonymize_email(text):
return re.sub(r'[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}', '[EMAIL]', text)
Cela remplace les adresses e-mail. C'est tout. L'ensemble contient toujours des noms, des numéros de téléphone et des identifiants médicaux. Il échouera à un audit RGPD.
L'écart entre « J'ai anonymisé les e-mails » et « Cet ensemble est conforme au RGPD » est grand. Les équipes le sous-estiment constamment.
Pourquoi le RGPD limite l'entraînement ML
L'article 5(1)(b) du RGPD est la règle clé. On l'appelle le principe de limitation des finalités. Les enregistrements personnels ne peuvent être utilisés qu'aux fins pour lesquelles ils ont été collectés.
Les commandes clients ont été collectées pour l'exécution des commandes. Pas pour entraîner un modèle de recommandation. Les dossiers médicaux ont été collectés pour le traitement. Pas pour entraîner un modèle de prédiction de réadmission. Les réponses aux sondages ont été collectées pour les retours produits. Pas pour entraîner un classifieur de sentiment.
Pour utiliser ces enregistrements pour l'entraînement ML, une équipe a besoin de l'une de trois choses :
- Le consentement explicite de chaque personne pour la finalité ML — difficile à obtenir, souvent impossible rétroactivement
- Une évaluation des intérêts légitimes montrant que l'utilisation ML est compatible — juridiquement incertain, dépend de l'autorité de protection
- L'anonymisation — remplacement ou suppression des détails personnels pour que l'ensemble ne soit plus personnel au sens du RGPD
L'anonymisation correcte offre la plus grande sécurité juridique. Le défi est de le faire correctement à chaque fois.
Le problème des scripts ponctuels
Les équipes qui écrivent un nouveau script Python pour chaque ensemble créent des problèmes qui s'accumulent.
Couverture incomplète. Un script construit pour un schéma manque les nouveaux champs. Une colonne de notes cliniques ajoutée il y a six mois ? Pas dans le regex. Un champ de deuxième prénom ? Le script ne gère que les patterns prénom et nom.
Pas de cohérence. L'ensemble A a été traité avec script_v1. L'ensemble B avec script_v3. L'ensemble C par un autre membre de l'équipe. L'ensemble d'entraînement fusionné a trois méthodes différentes. Un DPO ne peut pas le certifier.
Pas de piste d'audit. Le script a tourné. Qu'a-t-il changé ? Quelles entités ont été trouvées ? Sans enregistrements de traitement, la conformité est impossible. Quand un auditeur d'autorité demande « Comment savez-vous que cet ensemble est propre ? », la réponse « Nous avons exécuté un script Python » ne suffit pas.
Dérive du modèle. Les patterns regex qui fonctionnaient en 2023 manquent les nouveaux formats d'identifiants de 2024. Les scripts ne se mettent pas à jour.
Une démonstration de traitement par lots
Une équipe d'IA de santé doit anonymiser 8 000 dossiers patients. L'équipe américaine a besoin d'accès depuis un bureau européen. Schrems II s'applique — les enregistrements d'origine UE ne peuvent pas aller vers l'infrastructure américaine sans garanties appropriées.
Approche traditionnelle : Un ingénieur de données écrit un script personnalisé. Deux à trois jours de développement. Un à deux jours d'examen DPO. Un jour d'itération. Total : quatre à six jours. Le projet ML prend du retard.
Approche par traitement par lots :
- Exporter les 8 000 enregistrements en CSV
- Télécharger vers le traitement par lots
- Définir les types d'entités : PERSON, EMAIL_ADDRESS, PHONE_NUMBER, US_SSN, MEDICAL_RECORD, DATE_OF_BIRTH, LOCATION
- Choisir la méthode : Remplacer (substitue des valeurs synthétiques réalistes pour préserver la structure)
- Traitement : 45 minutes pour 8 000 enregistrements
- Télécharger le CSV propre
- Le DPO examine les métadonnées de traitement — entités trouvées par enregistrement, méthodes appliquées : 2 heures
- Le DPO approuve. Le transfert se fait.
Temps total : 45 minutes plus 2 heures d'examen DPO. Contre quatre à six jours.
Consultez le guide d'entraînement EU AI Act pour voir comment ces étapes satisfont les obligations de l'article 10.
Remplacer vs. Biffer pour l'usage ML
La méthode d'anonymisation influence la qualité du modèle.
Biffer remplace les PII par un token comme [BIFFÉ]. Cela fonctionne pour les modèles de détection de PII. Pour d'autres tâches — sentiment, classification, recommandation — c'est nuisible. Le modèle apprend que [BIFFÉ] est un token spécial. Il ne peut pas apprendre de la distribution naturelle des noms et des valeurs.
Remplacer échange « John Smith » par « David Chen ». Il échange « jsmith@company.com » par « dchen@synthetic.com ». La structure reste intacte. Placement des entités, patterns de co-occurrence, flux des phrases — tout préservé. Le modèle apprend à partir d'un contexte réaliste.
Pour les ensembles d'entraînement ML, Remplacer est le bon choix. Le modèle n'apprend pas les fausses valeurs. Il apprend les patterns autour d'elles. C'est ce qui compte.
Schrems II et les transferts transfrontaliers
L'arrêt Schrems II (CJUE, 2020) a invalidé le Privacy Shield EU-États-Unis. Les enregistrements d'origine UE ne peuvent pas aller vers l'infrastructure ML américaine — AWS US-East, GCP US-Central — sans garanties de transfert appropriées.
Les trois principales garanties sont :
- Clauses contractuelles types avec une évaluation d'impact sur les transferts
- Règles d'entreprise contraignantes pour les transferts au sein d'un groupe
- Dérogation pour les enregistrements anonymisés — les fichiers correctement anonymisés ne sont plus personnels au sens du RGPD et sont exemptés des règles de transfert
Pour les équipes utilisant une infrastructure américaine avec des ensembles d'origine européenne, l'anonymisation correcte supprime le problème Schrems II. L'ensemble propre n'est pas personnel. Il peut circuler librement.
C'est l'un des avantages pratiques les plus forts du traitement par lots. Il va au-delà de la conformité RGPD. Il supprime les frictions transfrontalières complètement.
Pour plus d'informations sur les restrictions de transfert, consultez le guide de minimisation RGPD.
Ce qu'il faut donner au DPO
Lors de la soumission d'un ensemble d'entraînement propre pour approbation DPO, inclure ces cinq éléments :
- Description de la source. Quel était l'ensemble original ? Quelle était la finalité de collecte ? Quelles catégories personnelles contenait-il ?
- Configuration d'anonymisation. Quels types d'entités ont été détectés et remplacés ? Quelle méthode a été appliquée ?
- Métadonnées de traitement. Nombre d'entités par enregistrement, scores de confiance, total d'enregistrements traités.
- Évaluation du risque résiduel. Quelle est la probabilité qu'une personne puisse être ré-identifiée ? Pour une anonymisation par méthode Remplacer avec 285+ types d'entités sur du texte structuré, cette probabilité est très faible.
- Usage prévu. Quel modèle sera entraîné ? Quelle est la finalité d'entraînement ?
Le traitement par lots fournit automatiquement les points 2 et 3. Les points 1, 4 et 5 viennent du data scientist.
Consultez l'API batch anonym.legal pour les détails.
Ce que vous gagnez
Les ensembles d'entraînement ML conformes au RGPD sont réalisables sans scripts personnalisés, sans délais de plusieurs jours et sans perte de qualité du modèle.
La méthode Remplacer conserve les propriétés de langage naturel importantes pour l'entraînement NLP. Elle supprime les détails personnels qui créent des risques RGPD.
45 minutes de traitement par lots font la différence entre un examen de conformité différé et une approbation DPO simple.