Note de méthode : publier un jeu de données de veille sans exposer de personnes
Retirer les noms ne suffit pas à protéger les personnes. Agrégation, seuil de publication, décalage temporel : les techniques qui rendent un jeu de données diffusable.
À retenir
- Un jeu de données reste réidentifiable après retrait des noms dès qu'une combinaison de date, de lieu et de fonction isole un cas unique.
- Agrégation, seuil minimal par croisement, décalage temporel et généralisation des catégories constituent le socle des protections praticables.
- Toute protection coûte de la finesse analytique : l'arbitrage se documente au lieu de se cacher.
- Le contrôle avant publication porte sur les croisements réellement possibles, pas sur les colonnes prises une à une.
Publier les données qui sous-tendent une étude de veille est une exigence de méthode : sans jeu de données diffusé, un résultat reste invérifiable et non reproductible. Cette exigence entre pourtant en tension directe avec une autre, tout aussi impérative : ne pas exposer les personnes qui apparaissent, souvent sans le savoir, dans un corpus constitué à partir de sources ouvertes.
La réponse spontanée consiste à retirer les noms puis à considérer le problème réglé. Cette croyance est l'erreur la plus répandue en matière de diffusion de données. Un jeu de données dépourvu de tout patronyme reste fréquemment réidentifiable, parce que l'identité d'une personne ne tient pas seulement à son nom : elle tient à la combinaison de ce qui la décrit.
Cette note expose la démarche que nous suivons avant de diffuser un jeu de données extrait d'un corpus de veille : ce qui rend une donnée réidentifiable, les techniques de protection réellement praticables, l'arbitrage entre utilité analytique et protection, le cadre de licence à poser et le contrôle final à effectuer. Elle prolonge nos principes de constitution de corpus et d'évaluation des sources : la publication est la dernière étape de la chaîne méthodologique, celle où une négligence devient irréversible.
Ce qui rend une donnée réidentifiable après le retrait des noms
La réidentification ne procède presque jamais d'une colonne isolée. Elle procède d'un croisement. Une date d'événement, une localisation et une fonction professionnelle, prises séparément, ne désignent personne ; réunies sur une même ligne, elles décrivent souvent une seule personne au monde. Un incident survenu tel mois, dans telle ville moyenne, concernant la direction financière d'une entreprise du secteur de l'énergie : le nom retiré n'a rien protégé du tout.
Ces variables descriptives, indirectement identifiantes, sont d'autant plus dangereuses qu'elles paraissent anodines et qu'elles constituent précisément l'intérêt analytique du jeu de données. Personne ne publie une base de veille pour ses noms propres ; on la publie pour ses dates, ses secteurs, ses territoires et ses typologies. Le matériau utile et le matériau risqué sont le même matériau.
S'y ajoute une difficulté propre aux données issues de sources ouvertes : elles coexistent avec un environnement informationnel abondant. Une ligne de notre jeu de données rapprochée d'un article de presse, d'un registre public ou d'une publication professionnelle redevient nominative sans effort particulier. L'évaluation du risque porte donc sur le jeu de données augmenté de ce qui est accessible autour de lui, jamais sur le fichier considéré seul.
L'unicité d'un cas, principal facteur d'exposition
Le critère opératoire le plus fiable est l'unicité. Une ligne dont la combinaison de caractéristiques n'est partagée par aucune autre ligne du jeu de données est une ligne exposée : il suffit de connaître deux ou trois de ses attributs pour la retrouver, puis pour lui attacher toutes les autres colonnes, y compris les plus sensibles. À l'inverse, une ligne noyée dans un groupe de cas semblables résiste au rapprochement.
Les cas uniques ne sont pas des anomalies marginales du fichier : ce sont souvent les cas les plus intéressants. Le secteur rare, l'événement atypique, le territoire peu représenté constituent le sel de l'analyse et, simultanément, ses points de fragilité. Toute démarche de protection commence par un dénombrement des combinaisons présentes une seule fois, puis par une décision explicite sur leur sort : regroupement, généralisation ou retrait.
Les techniques praticables : agréger, seuiller, décaler, généraliser
Quatre techniques couvrent la majorité des situations rencontrées sur un corpus de veille. Elles se combinent plutôt qu'elles ne se substituent, et chacune se choisit en fonction de la variable qui porte le risque. Le tableau ci-dessous en résume la logique, ainsi que le prix analytique à payer pour chacune.
| Technique | Ce qu'elle protège | Ce qu'elle coûte à l'analyse |
|---|---|---|
| Agrégation | Supprime la ligne individuelle au profit d'un effectif ou d'une moyenne | Interdit l'étude des cas particuliers et des distributions fines |
| Seuil minimal par croisement | Masque toute case comptant moins de cas que le seuil retenu | Crée des trous dans les catégories rares, celles qui intéressent le plus |
| Décalage temporel | Casse le rapprochement avec l'actualité datée du même jour | Rend inexploitable la mesure des délais courts et des séquences |
| Généralisation des catégories | Remplace une valeur précise par une classe plus large | Efface les distinctions internes à la classe ainsi créée |
L'agrégation est la protection la plus robuste : ce qui n'est jamais publié à la ligne ne se réidentifie pas. Le seuil minimal par croisement en est le complément indispensable, car une table agrégée dont une case compte un seul cas désigne aussi sûrement une personne qu'un fichier nominatif. Nous appliquons un seuil de cinq cas par case publiée, et nous masquons également une case voisine lorsque le total de la ligne permettrait de reconstituer par soustraction la valeur masquée.
Le décalage temporel consiste à publier une période plutôt qu'une date, ou à différer la diffusion. Il vise les jeux de données dont la datation fine constitue le vecteur principal de rapprochement avec la presse. La généralisation des catégories, enfin, remplace une fonction précise par une famille de fonctions, une commune par un département, un secteur pointu par une branche. Elle est souvent la moins coûteuse des quatre, à condition que les classes obtenues restent analytiquement signifiantes.
Un jeu de données ne devient pas anonyme parce qu'on en a retiré les noms. Il le devient quand aucune combinaison de ses colonnes n'isole plus une personne.
L'arbitrage entre utilité analytique et protection
Il n'existe pas de réglage qui préserve à la fois la totalité de la finesse analytique et la totalité de la protection. Toute technique qui réduit le risque de réidentification réduit aussi, mécaniquement, la précision de ce que le jeu de données autorise à mesurer. Un fichier parfaitement protégé et un fichier parfaitement informatif sont les deux extrémités d'un même axe, et la publication consiste à choisir un point sur cet axe.
Ce choix se fait au regard de l'usage attendu. Un jeu de données destiné à vérifier un ordre de grandeur supporte une agrégation forte sans rien perdre de son utilité. Un jeu de données destiné à répliquer une analyse de séquences temporelles supporte mal le décalage des dates, et sa protection passera plutôt par la généralisation des catégories descriptives. Nous déterminons donc d'abord ce que le fichier doit permettre de refaire, puis nous protégeons tout le reste sans réserve.
Licence de réutilisation et mention des limites
Un jeu de données publié sans licence explicite laisse le réutilisateur dans l'incertitude et prive l'auteur de tout cadre. Nous attachons à chaque fichier une licence nommée, autorisant la réutilisation et l'adaptation sous condition d'attribution, et nous y adjoignons une clause de non-réidentification : la tentative de retrouver l'identité des personnes concernées, ou de croiser le fichier à cette fin, sort du périmètre autorisé. Cette clause n'a pas de force technique, elle a une valeur de cadrage et de responsabilité.
La mention des limites accompagne obligatoirement le fichier. Elle indique quelles transformations ont été appliquées, à quelles colonnes, avec quel seuil, et quelles analyses deviennent de ce fait impraticables. Un utilisateur averti des masquages appliqués ne conclura pas à une absence de cas là où il n'y a qu'une case supprimée. Documenter les protections fait partie du résultat au même titre que documenter les biais du corpus : dans les deux cas, ce qui n'est pas dit sera mal interprété.
Le contrôle à faire avant publication
Le contrôle final ne se fait pas colonne par colonne, mais croisement par croisement. Nous dénombrons les combinaisons uniques et quasi uniques sur l'ensemble des variables descriptives conservées, puis nous vérifions qu'aucune case publiée ne descend sous le seuil retenu, y compris par recomposition à partir des marges d'un tableau. Un fichier propre colonne par colonne échoue régulièrement à ce test.
Vient ensuite un contrôle de rapprochement externe : nous prenons quelques lignes parmi les plus atypiques et nous tentons de les réidentifier avec les moyens ordinaires d'un analyste, à partir des sources publiques disponibles. Si l'exercice aboutit en quelques minutes, la protection est insuffisante et la ligne concernée retourne en généralisation. Ce test adverse, mené sur son propre fichier, vaut mieux que toute déclaration de conformité.
Ce contrôle suppose de savoir de quel document chaque ligne provient. Le corpus dont sont extraits nos jeux de données s'appuie sur la collecte multi-sources de NewsCore (www.newscore.fr), qui couvre en continu des millions de sources et relie chaque élément traité à son document d'origine. Cette traçabilité vers la source rend le contrôle de réidentification praticable à grande échelle : on remonte du fichier publié aux documents qui l'ont nourri, et on mesure ce qu'un tiers reconstituerait en faisant le chemin inverse.
Questions fréquentes
Retirer les noms et les identifiants suffit-il à anonymiser un jeu de données de veille ? Non. La réidentification passe par le croisement de variables descriptives conservées, comme la date, le lieu et la fonction. Un fichier sans aucun nom reste exposé dès qu'une de ses lignes présente une combinaison de caractéristiques unique.
Quel seuil minimal retenir pour publier une case d'un tableau agrégé ? Nous retenons cinq cas par case publiée, et nous masquons en complément les cases voisines lorsque les totaux de ligne ou de colonne permettent de reconstituer par soustraction une valeur masquée. Le seuil n'a de valeur que si les marges du tableau ne le contournent pas.
Faut-il renoncer à publier les cas rares, qui sont les plus intéressants ? Pas nécessairement. La généralisation des catégories regroupe le cas rare dans une classe plus large et le rend diffusable sous une forme moins précise. Le choix se fait cas par cas, entre publication généralisée et retrait pur et simple.
Comment vérifier concrètement qu'un jeu de données est diffusable ? En tentant soi-même la réidentification. On sélectionne les lignes les plus atypiques et on cherche à retrouver les personnes concernées avec les sources publiques disponibles. Un échec de cette tentative constitue une garantie plus solide qu'une inspection formelle des colonnes.