Mener un privacy impact assessment avant le lancement

Un comté de Pennsylvanie a un jour construit un modèle de risque prédictif pour signaler les nouveau-nés les plus susceptibles de subir de la maltraitance. Il notait chaque naissance à partir des registres du comté, de l'historique d'aide sociale et des données carcérales, avant même qu'un travailleur social ne rencontre la famille. Ce modèle, l'Allegheny Family Screening Tool, n'a été mis en service qu'après des années d'examen externe, précisément parce que quelqu'un a posé les questions difficiles en amont : de qui viennent ces données, qui est signalé de façon disproportionnée, et que se passe-t-il en cas de fuite ou d'erreur ?

Ce processus de « questionnement préalable » a un nom : le Privacy Impact Assessment (PIA), un examen structuré des données personnelles qu'un système collecte, des raisons de cette collecte et de ce qui pourrait mal tourner, avant qu'il ne touche le dossier d'un seul habitant. Aux États-Unis, les PIA sont légalement obligatoires pour les systèmes fédéraux au titre de l'E-Government Act de 2002, dès lors qu'un nouveau système traite des données à caractère personnel identifiantes. Dans l'UE, l'équivalent est le Data Protection Impact Assessment (DPIA), imposé par l'article 35 du GDPR (General Data Protection RegulationGeneral Data Protection RegulationRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète →) pour tout traitement « susceptible d'engendrer un risque élevé » pour les personnes, ce qui inclut explicitement le profilage à grande échelle et les décisions automatisées concernant des groupes vulnérables comme les enfants.

Si vous êtes sur le point de déployer un outil de risque prédictif dans la protection de l'enfance, la police, l'éligibilité aux prestations sociales ou le logement, un PIA n'est pas de la paperasse. C'est le dernier point de contrôle avant que votre modèle ne commence à façonner de vraies interventions dans la vie de vraies familles.

Ce qu'un PIA vous oblige réellement à trancher

Un PIA rigoureux passe en revue cinq questions concrètes. Si vous en sautez une, vous avancez à l'aveugle.

1. Quelles données entrent ? Chaque champ source : actes de naissance, contacts antérieurs avec la protection de l'enfance, casier d'arrestations, demandes de remboursement Medicaid, données scolaires.
2. Pourquoi avez-vous besoin de chaque champ ? C'est le principe de minimisation des données du GDPR (article 5) : ne collecter que ce qui est nécessaire à la finalité annoncée. Le code postal peut prédire le risque, mais il est souvent un proxy de la race et de la pauvreté, et non un facteur de risque causal.
3. Qui peut ré-identifier une personne à partir de ces données ? Même les jeux de données « anonymisés » ne le sont souvent pas.
4. Que se passe-t-il si le modèle se trompe, et pour qui précisément ? Les faux positifs et les faux négatifs ne se répartissent pas uniformément entre les groupes.
5. Qui est responsable en cas d'échec ? Nommez une personne, pas un comité.

Passer directement à « construisons le modèle » sans traiter ces questions est le mode de défaillance le plus courant dans le secteur public.

Risque de ré-identification : la vérification que la plupart des équipes sautent

« Anonymisé » n'est pas une garantie technique, c'est une affirmation qu'il faut tester. Une étude de référence de Latanya Sweeney a montré que 87 % de la population américaine pouvait être identifiée de façon unique à partir du seul code postal, de la date de naissance et du sexe (Sweeney, 2000, Data Privacy Working Paper), estimation encore largement citée parce que la combinatoire sous-jacente n'a pas changé.

Pour un outil de protection de l'enfance, le test pratique est une vérification de k-anonymat : pour chaque combinaison de champs que vous prévoyez de publier ou de partager (âge, code postal, type de dossier, source du signalement), chaque combinaison correspond-elle à au moins *kkLe nombre moyen de nouveaux utilisateurs que chaque utilisateur existant génère par recommandation. Au-dessus de 1,0, la croissance s'auto-alimente et devient exponentielle.Voir la définition complète →* personnes (couramment k=5 ou k=10 comme seuil de travail, pas comme obligation légale) ? Si une requête renvoie un seul foyer, vous avez un problème de ré-identification, même si vous avez retiré le nom et le numéro de sécurité sociale.

Une vérification simple à lancer avant que des données ne sortent d'un environnement sécurisé :

import pandas as pd

# quasi-identifiants susceptibles de permettre la ré-identification
quasi_ids = ["zip_code", "age_bracket", "case_type"]

group_sizes = df.groupby(quasi_ids).size()
risky_groups = group_sizes[group_sizes < 5]  # seuil k=5

print(f"{len(risky_groups)} combinations have fewer than 5 people")
print(risky_groups.head(10))

Si ce décompte est non nul, vous devez soit supprimer ces lignes, soit généraliser le champ (âge exact vers tranche d'âge), soit ajouter du bruit avant que quiconque en aval ne puisse interroger le jeu de données.

Disparate impact : la vérification qui compte vraiment le plus

La ré-identification protège les individus. Le disparate impact protège les groupes, et dans la protection de l'enfance c'est le risque le plus lourd.

Le disparate impact est une notion juridique issue du droit américain des droits civiques (origine dans *Griggs v. Duke Power*, 1971, appliquée aux décisions algorithmiques par le Department of Justice et le HUD en matière de logement équitable) : une politique ou un modèle neutre en apparence qui produit des résultats significativement plus défavorables pour un groupe protégé, race, sexe, handicap, même sans intention de discriminer.

Le test pratique : calculez le taux de signalement et le taux d'erreur de votre modèle par sous-groupe démographique, et pas seulement la précision globale.

Un écart de 19 points dans les taux de signalement, s'il suit la race ou le revenu et n'est pas expliqué par des facteurs de risque légitimes, est un signal d'alerte assez sérieux pour arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êter le lancement. C'est exactement la critique que des chercheurs indépendants ont adressée à l'outil d'Allegheny : la pauvreté des familles et les contacts antérieurs avec le système (eux-mêmes façonnés par des signalements biaisés) étaient intégrés dans les scores de « risque », ce qui signifie que les familles pauvres étaient davantage surveillées, ce qui générait plus de données, ce qui justifiait plus de surveillance. Un PIA bien mené nomme explicitement cette boucle de rétroaction au lieu de la découvrir après le déploiement.

La Brookings Institution propose une explication claire et accessible sur la formation de ces boucles de rétroaction dans les outils de police prédictive et d'aide sociale : Brookings: Algorithmic bias detection.

Gouvernance : qui valide, et quand

Un PIA ne vaut que ce que vaut la structure de gouvernance derrière lui. Trois éléments doivent être en place avant le lancement, pas après :

• Un Data Protection Officer (DPO) nommé ou un responsable équivalent de la protection des données, exigé par l'article 37 du GDPR pour les autorités publiques, et de plus en plus courant dans les agences des États américains même sans obligation fédérale.
• Un comité d'examen indépendant ayant le pouvoir de retarder le lancement, pas seulement de commenter. Le comté d'Allegheny a fait réaliser un examen éthique externe (Eubanks, Dare et Chen, commandé par le comté) avant de déployer son outil à l'échelle de l'État, et cela a changé les variables utilisées.
• Un registre de décisions documenté : ce qui a été signalé, ce qui a été modifié, quel risque résiduel a été accepté et par qui. Si votre PIA ne laisse aucune trace écrite du type « nous savions X et avons décidé Y », c'est du théâtre, pas de la gouvernance.

Pour les agences des États et des collectivités locales aux États-Unis, le NIST AI Risk Management Framework (nist.gov/itl/ai-risk-management-framework) offre une structure gratuite, non réglementaire mais largement adoptée, faite exactement pour cela : cartographier les risques, les mesurer et attribuer la responsabilité de la gouvernance.

La checklist avant lancement

Avant que tout outil de risque prédictif ne touche le dossier d'un habitant, vérifiez :

• [ ] Chaque champ d'entrée a une finalité documentée et nécessaire (minimisation des données)
• [ ] Un test de k-anonymat ou équivalent de ré-identification a été effectué sur tout extrait partageable
• [ ] Les taux de signalement et les taux d'erreur sont ventilés par classe protégée et examinés au regard du disparate impact
• [ ] Une personne nommée porte la responsabilité du modèle, pas un service
• [ ] Il existe un processus défini permettant à un travailleur social de passer outre le score, et cette dérogation est journalisée
• [ ] Le document PIA/DPIA lui-même est publié ou disponible pour un audit indépendant

🎬 [VIDEO: "Algorithms in Child Welfare: Risk, Bias, and Accountability" - youtube.com - cherchez les tables rondes de Data & Society ou de l'AI Now Institute sur les outils prédictifs dans les systèmes de protection de l'enfance, qui détaillent le cas Allegheny]

Points clés

• Un PIA (États-Unis, au titre de l'E-Government Act) ou un DPIA (UE, article 35 du GDPR) est un examen obligatoire et structuré avant lancement, pas une documentation optionnelle, dès lors qu'un système profile des groupes vulnérables.
• Testez concrètement le risque de ré-identification avec une vérification de k-anonymat sur les quasi-identifiants (code postal, âge, type de dossier) ; « anonymisé » est une affirmation à vérifier, pas un état par défaut.
• Le disparate impact se mesure en comparant les taux de signalement et les taux d'erreur entre groupes protégés, pas via la précision globale du modèle ; un écart à deux chiffres est un signal bloquant pour le lancement.
• La gouvernance exige une personne responsable nommée, un comité d'examen indépendant doté d'un réel pouvoir de retarder le lancement et un registre de décisions documenté, avant le déploiement, pas en post-mortem.
• Les outils de risque prédictif construits sur des données de dossiers historiques risquent d'inscrire les biais de surveillance passés dans les décisions futures ; le PIA est le moment où vous attrapez cette boucle avant qu'elle ne s'amplifie.