Gouverner la privacy et l'équité sur des systèmes legacy

# Gouverner la privacy et l'équité sur des systèmes legacy

Un travailleur social d'un bureau d'aide sociale de comté tape le nom d'un bénéficiaire dans un dashboard moderne de gestion de dossiers. Derrière l'écran, ce dashboard interroge discrètement un mainframe installé quand Reagan était président. Le mainframe contient 40 ans d'historique d'éligibilité dans un format que presque plus personne dans l'équipe ne sait lire. Pour aider ce seul bénéficiaire, le comté doit relier ces deux systèmes. Cet acte de liaison, à lui seul, est le point où risque privacy, risque d'équité et dette technique se percutent.

Cette leçon déroule cette décision de liaison. Elle est courante dans les administrations, et elle est rarement aussi simple que « il suffit de connecter les bases ».

Pourquoi les systèmes legacy sont la norme, pas l'exception

La plupart des gens supposent que l'administration tourne sur de vieilles technologies parce que les agences sont paresseuses ou sous-financées. Les vraies raisons sont structurelles.

Les systèmes de prestations (assurance chômage, éligibilité Medicaid, SNAP) tournent souvent sur COBOL, un langage de programmation de 1959 qui traite encore une large part des transactions publiques. Pendant la vague de chômage de 2020, plusieurs États ont publiquement cherché des programmeurs COBOL parce que leurs systèmes ne pouvaient pas monter en charge.

Vous ne pouvez pas simplement remplacer ces systèmes. Ils fonctionnent. Ils sont porteurs. Une modernisation ratée peut couper les prestations de vraies personnes pendant des semaines. La réalité pratique est donc : vous gouvernez des données sur des systèmes que vous n'avez pas choisis et que vous ne pouvez pas changer entièrement.

Le problème de liaison, concrètement

Admettons que vous vouliez relier deux enregistrements :

• Mainframe (1985) : stocke un bénéficiaire par numéro de sécurité sociale (SSN), nom et historique d'éligibilité codé.
• Outil de gestion de dossiers (moderne) : stocke un bénéficiaire par un identifiant de dossier interne, un nom et les services en cours.

Pour les connecter, il vous faut une join key, un champ commun qui fait correspondre un enregistrement d'un système à la même personne dans l'autre. La clé évidente est le SSN. C'est aussi le champ le plus dangereux que vous puissiez faire circuler.

Voici la tension en une ligne :

The field that makes linkage EASY (SSN)
is the same field that makes RE-IDENTIFICATION easy.

La ré-identification, c'est quand des données supposées anonymes sont retracées jusqu'à une personne précise. Des travaux de recherche classiques ont montré qu'une large part de la population américaine peut être identifiée de façon unique avec seulement le code postal, la date de naissance et le sexe. Retirer les noms ne suffit donc pas.

Une façon plus sûre de relier

Plutôt que de copier des SSN entre systèmes, les équipes utilisent de plus en plus un identifiant hashé ou un master person index séparé.

Le hashing fait passer le SSN dans une fonction à sens unique qui produit une chaîne brouillée. Le même SSN produit toujours le même hash, vous pouvez donc encore faire correspondre les enregistrements, mais le SSN brut ne quitte jamais le mainframe.

import hashlib

def link_key(ssn: str, secret_salt: str) -> str:
    # le salt empêche un attaquant de précalculer les hashs de tous les SSN
    return hashlib.sha256((secret_salt + ssn).encode()).hexdigest()

# Même personne, même clé, dans les deux systèmes. Le SSN brut reste chez lui.
link_key("123-45-6789", secret_salt="agency-only-value")

Le salt (une valeur secrète ajoutée avant le hashing) compte. Sans lui, un attaquant peut hasher tous les SSN possibles (il y en a moins d'un milliard) et inverser vos clés « anonymes » en quelques minutes. Ce n'est pas théorique : le hashing sans salt a provoqué de vraies fuites.

Pour une base accessible sur les méthodes de dé-identification, le guide du US Department of Health and Human Services sur la dé-identification des informations de santé protégées est une référence gratuite solide, même en dehors de la santé.

La gouvernance privacy que vous devez réellement satisfaire

La liaison de données dans le secteur public déclenche en général des règles formelles. À définir dès la première utilisation :

• PII (Personally Identifiable Information) : toute donnée qui identifie une personne. Le SSN est la catégorie la plus à risque.
• Data-sharing agreement (DSA) : un document signé entre programmes ou agences précisant exactement quelles données circulent, pourquoi et pendant combien de temps.
• Limitation de finalité : le principe selon lequel des données collectées pour une raison (l'éligibilité, par exemple) ne peuvent pas être librement réutilisées pour une autre (la répression pénale, par exemple) sans habilitation.

La limitation de finalité est le terrain où la confiance publique se gagne ou se perd. Si les bénéficiaires croient que leurs données de prestations peuvent être transmises aux services de l'immigration, ils cessent de déposer des demandes, même pour des prestations auxquelles leurs enfants ont légalement droit. Cet effet dissuasif est un préjudice d'équité documenté, pas une simple note de bas de page sur la privacy.

🎬 [VIDEO: "The Privacy Paradox in Government Data" - youtube.com - un panorama accessible de la manière dont les agences arbitrent entre utilité des données et risque de ré-identification]

Où l'équité entre en jeu : l'audit

Une fois les systèmes reliés, les agences construisent souvent des outils par-dessus : un score de risque pour signaler les fraudes probables, ou un modèle pour prioriser les actions de proximité. C'est là qu'intervient l'audit d'équité algorithmique.

Un audit d'équité vérifie si une décision pilotée par les données produit des résultats différents selon les groupes (origine, situation de handicap, langue, géographie) d'une manière qui n'est pas justifiée.

La dimension legacy rend l'exercice plus difficile. Les vieilles données de mainframe encodent de vieilles hypothèses.

Exemple concret : le piège des « données manquantes »

Supposons que le système de 1985 n'enregistrait que certaines catégories de prestations courantes dans les banlieues aisées, tandis que les demandeurs ruraux et immigrés étaient plus souvent traités sur papier et jamais complètement numérisés. Des décennies plus tard, un modèle entraîné sur cet historique mainframe « voit » moins de données pour ces groupes.

Moins d'enregistrements peut ressembler à un besoin plus faible, ou gonfler un score de fraude parce que l'historique de la personne paraît « mince » ou « incohérent ». Le biais n'est pas dans le code. Il est inscrit dans ce qui a été enregistré il y a 40 ans.

Un audit d'équité honnête doit donc poser deux questions :

1. Équité des résultats : les taux d'erreur sont-ils comparables entre groupes ? (Par exemple, le taux de faux positifs de fraude est-il plus élevé pour un groupe linguistique ?)

2. Provenance des données : qui est systématiquement absent ou faiblement représenté dans les données sources, et pourquoi ?

Sauter la deuxième question est l'erreur la plus fréquente. Les équipes auditent le modèle et le déclarent équitable, sans remarquer que les données sous-jacentes n'ont jamais été neutres.

Un tableau d'audit simple

Un premier passage utile est la comparaison par sous-groupe. Pas besoin de mathématiques avancées pour démarrer :

| Groupe | Taux de signalement | Taux de confirmation correcte | Taux de faux positifs |

|-------|-------------|------------------------|---------------------|

| Groupe A | 8 % | 90 % | 10 % |

| Groupe B | 8 % | 62 % | 38 % |

Des taux de signalement égaux (8 % chacun) peuvent masquer des taux d'erreur très inégaux. Le groupe B est ici signalé à tort bien plus souvent. C'est exactement le type de schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → qu'un audit sert à faire remonter.

Travailler dans des contraintes que vous ne pouvez pas lever

Vous avez trois forces : le risque privacy, le risque d'équité et un mainframe que vous ne pouvez pas remplacer. Voici comment les équipes expérimentées s'y prennent.

1. Minimiser ce qui circule

Ne transférez pas tout le mainframe dans l'outil moderne. Déplacez la plus petite tranche possible nécessaire à la tâche, avec des clés hashées, pas des SSN bruts. Moins de données en transit, c'est moins de matière à fuiter et moins de ré-identification possible.

2. Ajouter une couche de traduction, pas un remplacement

Souvent, vous ne pouvez pas toucher au mainframe sans risque. Les équipes construisent plutôt une couche middleware (parfois une APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète →) qui s'intercale entre l'ancien système et le nouveau. Le mainframe reste intact. Le middleware contrôle exactement quelles données passent et logue chaque accès.

Le logging compte aussi pour l'équité : vous ne pouvez pas auditer ce que vous n'avez pas enregistré.

3. Documenter l'histoire des données

Rédigez une courte note de provenance pour chaque champ : d'où il vient, de quelle époque, quelles lacunes connues. Quand quelqu'un construira plus tard un modèle de risque, cette note l'avertira qu'un « historique mince » peut vouloir dire « traité sur papier en 1990 », pas « besoin faible ».

4. Associer les communautés concernées à la revue

Les audits d'équité fonctionnent mieux quand les personnes représentées dans les données aident à les interpréter. Un schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → de données manquantes qui ressemble à de la fraude pour un analyste peut être évident pour un représentant associatif qui se souvient du processus d'accueil sur papier.

5. Décider à l'avance de ce que signifie « assez injuste 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 »

Fixez des seuils avant le lancement. Si les taux de faux positifs diffèrent entre groupes au-delà d'un écart convenu, l'outil est mis en pause. Décider cela en amont supprime la tentation de rationaliser un résultat biaisé une fois que l'argent et la réputation sont en jeu.

Points clés

• La join key est tout l'enjeu. Utilisez des identifiants hashés avec salt ou un master person index pour que les SSN bruts ne quittent jamais le mainframe. Retirer les noms ne suffit pas à empêcher la ré-identification.
• Les données legacy ne sont pas neutres. Ce qui a été enregistré il y a des décennies (et ce qui ne l'a pas été) façonne les algorithmes d'aujourd'hui. Auditez la provenance des données, pas seulement les sorties du modèle.
• La limitation de finalité protège l'accès. Si les bénéficiaires craignent que leurs données de prestations soient réutilisées contre eux, ils se désengagent, ce qui constitue en soi un préjudice d'équité.
• Encapsulez, n'arrachez pas. Une couche middleware avec logs vous permet de gouverner les accès sans prendre le risque de remplacer un mainframe porteur.
• Fixez les seuils d'équité avant le lancement, pour qu'un résultat biaisé déclenche une pause plutôt qu'une justification a posteriori.