Données, interopérabilité et données ouvertes du secteur public

Pourquoi cela compte pour la valeur publique

Chaque organisme public détient déjà plus de données qu'il n'en utilise bien. Une autorité fiscale, un réseau hospitalier, un organisme de transport, et un bureau de planification local collectent chacun de l'information comme sous-produit de faire fonctionner un service, et chacun découvre, habituellement trop tard, que le dossier dont il a besoin pour répondre à la question d'un citoyen ou régler un litige se trouve dans un système que personne d'autre dans l'organisation ne peut interroger. Le coût n'est pas abstrait : un citoyen qui a déjà dit son adresse à un organisme ne devrait pas avoir à la redire à un autre organisme à l'intérieur du même gouvernement.

Deux ambitions séparées se situent à l'intérieur du titre de ce thème, et les organismes publics les confondent régulièrement. La première est l'interopérabilité — faire bouger les données de façon fiable entre des systèmes que différentes équipes et époques de technologie ont bâtis indépendamment, afin qu'une partie du gouvernement puisse agir sur ce qu'une autre partie sait déjà. La seconde est l'ouverture — publier des données entièrement en dehors du gouvernement, afin que journalistes, chercheurs, et citoyens puissent les utiliser à des fins que l'organisme publiant n'a jamais anticipées. L'interopérabilité est principalement un problème d'ingénierie et de gouvernance ; l'ouverture est une valeur publique en soi, de la même famille que les biens publics décrits au thème 1.4 — Biens publics, biens de mérite et pluralisme des valeurs, parce que les données publiées sont non rivales et difficiles à exclure de quiconque une fois publiées, donc un marché seul les sous-fournirait.

Les deux ambitions entrent en collision avec un troisième fait que ce thème traite comme une véritable tension non résolue plutôt qu'un problème avec une réponse propre : des données assez détaillées pour être utiles sont souvent assez détaillées pour identifier l'individu qu'elles décrivent, même après que les noms et identifiants évidents aient été retirés. Un gouvernement qui publie richement et un gouvernement qui protège bien les gens dans ses dossiers tirent dans des directions différentes sur le même levier, et l'appétit croissant pour des données afin d'entraîner et d'évaluer des systèmes algorithmiques (voir thème 5.2 — IA et prise de décision algorithmique dans l'administration publique) a élevé les enjeux, parce que plus d'acteurs que jamais veulent des données publiques exactement à la granularité qui les rend les plus risquées à publier. Un dirigeant qui traite la gouvernance, l'interopérabilité, et l'ouverture comme un seul problème, avec la vie privée comme sa contrainte permanente, est mieux placé pour capturer la valeur de ce thème que celui qui traite chacun isolément.

Concepts fondamentaux

La gouvernance des données est l'ensemble des droits de décision, normes, et redevabilités qui déterminent qui peut créer, changer, accéder, et retirer les données d'une organisation, et à quel standard de qualité elles doivent être tenues (voir gouvernance des données). Elle est distincte de la gestion des données, qui est le travail opérationnel de déplacer et stocker les données au quotidien ; la gouvernance décide les règles, la gestion les exécute. Un organisme public sans gouvernance des données a encore des données, mais personne ne peut dire avec confiance quelle copie du dossier d'un citoyen est celle faisant autorité, ni qui est redevable quand ce dossier s'avère erroné.

Un intendant de données (data steward) est l'individu ou le rôle nommé redevable de la qualité, de la définition, et de l'usage approprié d'un ensemble de données spécifique, distinct du personnel technique qui fait fonctionner les systèmes où il réside (voir intendant de données). L'intendance compte parce que la qualité des données se dégrade par défaut : un champ dont personne n'est redevable accumule des entrées incohérentes, des dossiers dupliqués, et une dérive silencieuse entre ce qu'un champ est censé signifier et ce que le personnel y met réellement. Assigner un intendant à un ensemble de données convertit la qualité des données d'un exercice de nettoyage occasionnel en une responsabilité continue et nommée.

L'interopérabilité est la capacité de systèmes bâtis indépendamment à échanger des données et à les utiliser correctement sans ingénierie spéciale et ponctuelle pour chaque paire de systèmes impliqués (voir interopérabilité). Elle opère à trois niveaux faciles à confondre : l'interopérabilité technique (les systèmes peuvent-ils se connecter et déplacer des octets du tout, typiquement à travers une interface de programmation d'application, ou API, une façon définie pour un logiciel de demander des données ou une action à un autre — voir interface de programmation d'application) ; l'interopérabilité sémantique (les deux systèmes signifient-ils la même chose par un champ partagé, tel que « ménage » ou « cas actif ») ; et l'interopérabilité organisationnelle (les deux organisations conviennent-elles de pourquoi les données sont partagées et qui est redevable de ce qui se passe ensuite). La plupart des échecs d'interopérabilité les plus coûteux se produisent au niveau sémantique ou organisationnel même quand la connexion technique fonctionne parfaitement.

Un schéma commun, ou norme de données, est une structure convenue et publiée pour comment une catégorie de données est représentée — noms de champs, formats, unités, et valeurs permises — adoptée par plus d'un système ou organisation afin que les données produites par l'un puissent être consommées par un autre sans traduction manuelle. Les organismes gouvernementaux qui adoptent un schéma partagé pour quelque chose d'aussi basique qu'une adresse ou un statut de cas convertissent des dizaines de problèmes de traduction bilatérale potentiels en une seule norme que chaque nouveau système peut simplement implémenter. Un identifiant unique qui persiste à travers les systèmes et dans le temps — un numéro de cas, un numéro d'enregistrement d'entreprise, une référence citoyenne — est le mécanisme spécifique qui permet aux dossiers sur la même personne ou entité d'être liés correctement, et mal concevoir l'identifiant (réutiliser des numéros, changer les formats, ou n'en avoir aucun du tout) est l'une des causes les plus courantes et évitables d'échec d'interopérabilité.

Les métadonnées sont des données sur les données — la description de la structure, de la provenance, de la fréquence de mise à jour, et de la signification d'un ensemble de données, publiée aux côtés des données elles-mêmes afin qu'un utilisateur qui ne l'a pas créé puisse le comprendre et lui faire confiance (voir métadonnées). Un ensemble de données publié sans métadonnées adéquates est à peine utilisable par quiconque en dehors de l'équipe qui l'a produit, aussi ouverte que soit sa licence ; les métadonnées sont ce qui transforme un déversement de fichiers en quelque chose qu'un tiers peut réellement réutiliser.

Un accord de partage de données est un arrangement formel entre organismes, ou entre un organisme public et un partenaire externe, qui spécifie le but pour lequel les données peuvent être utilisées, la base légale de leur partage, combien de temps elles peuvent être retenues, et ce qui se passe si le but change. La limitation du but — restreindre l'usage des données partagées au but pour lequel elles ont été collectées ou partagées — est la discipline qui empêche un accord de partage de données de devenir une licence illimitée pour réaffecter l'information personnelle, et son absence est un thème récurrent dans les échecs de confiance publique impliquant des données inter-organismes.

Les données ouvertes sont des données rendues librement disponibles pour que quiconque y accède, les utilise, et les redistribue, à toute fin, typiquement lisibles par machine et publiées sous une licence qui permet la réutilisation plutôt que simplement la visualisation (voir données ouvertes). Leur dossier de valeur publique suit la logique des biens publics exposée au thème 1.4 — Biens publics, biens de mérite et pluralisme des valeurs : une fois qu'un ensemble de données est publié, l'usage d'une personne ne diminue pas celui d'une autre, et le gouvernement est souvent le seul acteur avec à la fois le statut légal et l'échelle pour les collecter et les publier en premier lieu, donc les marchés privés seuls sous-fournissent chroniquement ce genre d'information. Les données ouvertes permettent la redevabilité (journalistes et citoyens vérifiant les propres revendications du gouvernement contre ses propres dossiers), l'innovation tierce (entreprises et technologues civiques bâtissant des services par-dessus des données publiques que le gouvernement lui-même ne bâtira jamais), et de meilleures décisions publiques ailleurs dans l'économie, tout cela sans que l'organisme publiant n'ait à anticiper chaque usage à l'avance.

La réidentification est le processus consistant à faire correspondre des données supposément anonymisées contre d'autres informations disponibles pour déterminer quelle personne réelle un dossier décrit, et c'est le fait technique central qui rend la tension de vie privée de ce thème inévitable plutôt que simplement gênante (voir réidentification des données). Retirer un nom, ou un identifiant évident tel qu'un numéro d'assurance sociale, ne retire pas le risque : une combinaison de quasi-identifiants tels que l'âge, le code postal, et une condition médicale rare peut identifier de façon unique quelqu'un même dans un ensemble de données qui ne l'a jamais nommé, particulièrement une fois recoupé contre un autre ensemble de données séparément public. La k-anonymité est une façon formelle de raisonner sur ce risque : un ensemble de données satisfait la k-anonymité si chaque combinaison de champs quasi-identifiants qu'il contient est partagée par au moins un nombre défini, k, de dossiers, afin qu'aucune ligne unique ne puisse être isolée à moins de k personnes possibles (voir k-anonymité). La confidentialité différentielle est une approche plus récente et mathématiquement rigoureuse qui ajoute un bruit statistique soigneusement calibré à un ensemble de données ou aux résultats de requêtes contre lui, afin que la présence ou l'absence du dossier de tout individu unique ne change la sortie publiée que d'un montant borné et démontrable, indépendamment de ce qu'un attaquant sait déjà (voir confidentialité différentielle). La protection de la vie privée dès la conception (privacy by design) est le principe plus large selon lequel la protection de la vie privée devrait être intégrée dans l'architecture d'un système dès le départ, comme un paramètre par défaut, plutôt que boulonnée comme une étape de caviardage juste avant publication (voir protection de la vie privée dès la conception) ; caviarder des identifiants évidents après coup est la forme la plus faible de cette discipline, non un substitut à celle-ci.

Pratiques exemplaires

1. Nommez un intendant redevable pour chaque ensemble de données qui compte, non seulement un bureau de données central. Un bureau de données peut fixer des normes, mais il ne peut pas savoir si un champ spécifique dans un système spécifique signifie encore ce qu'il était censé signifier ; ce jugement appartient à quelqu'un proche de l'usage réel des données.
2. Publiez ouvert par défaut, et documentez la raison spécifique chaque fois que vous ne le faites pas. Inverser le défaut — exiger une justification pour retenir plutôt qu'une justification pour publier — fait surgir les véritables sensibilités pour une révision individuelle au lieu de laisser la prudence s'appliquer indistinctement à tout.
3. Adoptez un schéma existant et partagé avant d'en concevoir un nouveau. Une structure de données sur mesure qui convient parfaitement à un projet et ne correspond à rien d'autre au gouvernement garantit un coût d'intégration futur ; vérifiez ce que votre secteur, juridiction, ou un organisme de normalisation international a déjà publié avant de bâtir le vôtre.
4. Concevez des identifiants uniques persistants et bien gouvernés avant qu'un système ne soit mis en service, non après. Rétro-adapter un schéma d'identifiant sur des dossiers qui s'accumulent depuis des années sous des clés incohérentes est dramatiquement plus coûteux que bien concevoir dès le départ.
5. Bâtissez l'échange de données à travers des API gouvernées plutôt que des transferts de fichiers ponctuels. Une API qui applique un schéma, journalise l'accès, et peut être versionnée vous donne un point d'interopérabilité contrôlable et auditable ; une feuille de calcul envoyée par courriel entre départements ne vous donne rien de tout cela et personne ne remarque quand elle devient périmée.
6. Écrivez des accords de partage de données qui énoncent le but, la base légale, et l'expiration, non seulement le mécanisme technique. Un accord qui spécifie comment les données se déplacent mais non pourquoi, ou pour combien de temps, tend à survivre au but qui le justifiait et à devenir discrètement la permission pour quelque chose que personne n'a explicitement autorisé.
7. Traitez la désidentification comme une évaluation de risque avec un résultat résiduel, non une tâche de caviardage ponctuelle. Demandez quels autres ensembles de données publics ou achetables pourraient être liés contre celui que vous êtes sur le point de publier, et calibrez le risque de réidentification contre ce modèle de menace réaliste, non contre un attaquant idéalisé sans information extérieure.
8. Appliquez la confidentialité différentielle ou une technique formelle équivalente à toute publication impliquant de petites populations ou des caractéristiques rares. La simple suppression ou généralisation d'identifiants évidents est insuffisante une fois qu'un ensemble de données inclut quelque chose d'assez inhabituel pour être identifiant en soi, tel qu'une condition rare, une petite population locale, ou une transaction de haute valeur.
9. Maintenez un catalogue de données public et actuel avec de véritables métadonnées, non seulement une liste de noms de fichiers. Un ensemble de données qu'un utilisateur potentiel ne peut pas comprendre assez bien pour lui faire confiance est fonctionnellement non publié, quelle que soit la permissivité de sa licence ; les entrées de catalogue devraient dire ce qu'un champ signifie, à quelle fréquence il se met à jour, et quelles sont ses limites connues.
10. Mesurez la qualité des données contre des normes définies selon un calendrier récurrent, et rapportez les résultats à quiconque possède l'ensemble de données. Une qualité vérifiée seulement quand quelque chose se casse se dégrade invisiblement pendant de longues périodes entre-temps ; une mesure routinière transforme la dégradation en une tendance visible et gérable.
11. Révisez périodiquement chaque ensemble de données publié pour la valeur publique continue et le risque continu. Les populations changent, les techniques de réidentification s'améliorent, et une publication qui était sûre il y a cinq ans peut ne pas l'être aujourd'hui contre des données devenues depuis nouvellement disponibles ailleurs.
12. Séparez la décision de partager ou publier des données de l'équipe technique qui les déplace. Les gens les mieux placés pour juger le but, la proportionnalité, et le risque de vie privée sont rarement les mêmes gens les mieux placés pour bâtir le pipeline, et fusionner les deux rôles en un seul laisse le jugement le plus difficile sous-examiné.

Questions à discuter avec votre équipe

Savons-nous quel système détient le dossier faisant autorité pour chacune de nos entités de données centrales, et tout le monde le traite-t-il réellement ainsi ? De nombreuses organisations ont, en pratique, plusieurs copies « vraies » de la même information — l'adresse d'un citoyen dans le système de facturation, le système de gestion de cas, et le journal de correspondance, toutes légèrement différentes et toutes sur lesquelles quelqu'un agit. Utilisez cette question pour lister les entités centrales de votre organisation (citoyen, cas, propriété, entreprise) et identifiez, honnêtement, si une source faisant autorité unique existe pour chacune ou si le personnel a discrètement appris quel système faire confiance pour quel but. Discutez de ce qu'il faudrait pour désigner et appliquer une source faisant autorité par entité, et ce qui se casserait dans la transition. C'est habituellement moins cher à corriger tôt qu'après qu'une décision sérieuse ait été prise sur la mauvaise copie.

Si une personne nous demandait pourquoi elle a dû donner la même information à deux parties de notre propre organisation, quelle serait notre réponse honnête ? La réponse honnête est souvent « parce que nos systèmes ne peuvent pas l'échanger », ce qui est un échec d'interopérabilité déguisé en exigence de processus. Utilisez cette question pour choisir un parcours de service qui s'étend sur plus d'une équipe ou système et retracez, étape par étape, où le même fait est capturé plus d'une fois. Discutez de si la demande répétée protège quelque chose d'authentique — un consentement frais, une étape de vérification — ou si c'est simplement l'absence d'un accord de partage de données ou d'un schéma commun. Considérez ce que cela coûterait, en confiance citoyenne autant qu'en temps de personnel, de le laisser non corrigé pour une autre année.

Où un journaliste ou chercheur déterminé pourrait-il le plus plausiblement réidentifier quelqu'un dans un ensemble de données que nous appelons actuellement anonymisé ? La plupart des organisations qui publient des données désidentifiées ne les ont pas testées à l'épreuve contre une combinaison réaliste de quasi-identifiants et d'autres ensembles de données publics. Utilisez cette question pour choisir votre ensemble de données publié ou bientôt publié à plus haut risque et parcourez quelle autre information — un reportage local, un ensemble de données ouvert d'un autre organisme, un registre public — pourrait plausiblement y être lié. Discutez de si votre approche actuelle de désidentification (suppression, généralisation, ou une technique formelle telle que la k-anonymité ou la confidentialité différentielle) résisterait réellement à cette combinaison, et qui est responsable de la retester à mesure que de nouvelles données externes deviennent disponibles.

Qui a actuellement l'autorité de dire qu'un ensemble de données ne devrait pas être publié, et sommes-nous confiants que cette autorité est utilisée pour les bonnes raisons ? Une politique ouverte par défaut a encore besoin d'un processus d'exception crédible et bien raisonné, et la personne qui l'exerce devrait être identifiable et redevable. Utilisez cette question pour vérifier si les décisions de rétention dans votre organisation sont prises par un rôle nommé contre des critères documentés, ou informellement, par quiconque se trouve être interrogé et pèche par excès de prudence. Discutez de si votre taux de rétention ressemble davantage à un jugement soigneux au cas par cas ou à un réflexe institutionnel permanent, et ce qu'une révision externe périodique des ensembles de données retenus pourrait révéler.

Nos accords de partage de données entre organismes sont-ils encore utilisés pour le but pour lequel ils ont été écrits ? La limitation du but est facile à énoncer dans un accord et facile à éroder discrètement en pratique, particulièrement une fois qu'un ensemble de données s'avère utile pour quelque chose que ses signataires originaux n'ont jamais anticipé. Utilisez cette question pour choisir deux ou trois arrangements de partage de données inter-organismes vivants et vérifiez l'usage réel actuel contre le but écrit et la date d'expiration. Discutez de quelle étape de gouvernance manque si un décalage apparaît, et qui devrait être redevable d'attraper ce genre de dérive avant qu'un audit externe ou un journaliste ne le fasse.

Si nos normes d'interopérabilité ou de données devenaient une barrière à un nouvel usage légitime de nos données, le découvririons-nous avant ou après qu'elles aient causé un véritable préjudice ? Les normes qui étaient sensées quand elles ont été adoptées peuvent s'ossifier en obstacles à mesure que les besoins et la technologie changent, et les organisations bâtissent rarement un mécanisme pour remarquer que cela arrive à leurs propres règles. Utilisez cette question pour discuter de comment votre organisation révise actuellement si ses normes de données, schémas d'identifiant, ou processus de partage servent encore leur but, plutôt que d'être simplement hérités et non questionnés. Considérez si les gens qui remarqueraient qu'une norme est devenue un obstacle — personnel de première ligne, organisations partenaires, développeurs externes utilisant vos données ouvertes — ont un véritable canal pour le soulever, et si ce canal a déjà réellement changé une norme.

En pratique : un exemple de valeur publique

Un organisme régional de protection sociale et une autorité de santé régionale distincte — fictifs, illustratifs d'un schéma plutôt qu'un compte rendu d'un organisme réel — avaient passé une décennie à faire fonctionner des systèmes de gestion de cas incompatibles, donc une famille connue des deux pouvait être enregistrée sous des numéros de référence différents, sans moyen fiable de dire au personnel de l'organisme que le ménage apparaissant dans une charge de cas de soutien au logement était le même ménage apparaissant dans une charge de cas de sensibilisation pédiatrique. Un programme conjoint pour identifier les enfants à risque de tomber dans l'écart entre les deux services calait répétitivement, non par manque de volonté politique, mais parce que personne ne pouvait produire une vue combinée unique et digne de confiance de quelles familles avaient besoin des deux types de soutien.

Les deux organismes ont éventuellement adopté un identifiant de ménage partagé et un schéma commun pour les champs que les deux systèmes avaient besoin d'échanger, bâti à travers une API gouvernée plutôt que les exports de feuille de calcul périodiques sur lesquels chacun s'était appuyé précédemment, sous un accord de partage de données qui nommait le but spécifique — coordonner le soutien pour les ménages à risque — et exigeait une révision annuelle. En un an, les agents de dossiers des deux côtés pouvaient voir, pour la première fois, quelles familles étaient connues de l'autre service, et les conférences de cas conjointes qui s'étaient précédemment appuyées sur une vérification croisée manuelle sont devenues routinières. Les organismes sont ensuite allés plus loin, publiant un ensemble de données ouvert agrégé au niveau de la zone montrant le nombre de ménages recevant un soutien combiné par district, destiné à aider les organismes de bienfaisance locaux à cibler leur propre sensibilisation et à permettre aux conseillers élus de voir si le programme conjoint atteignait les zones pour lesquelles il était conçu.

Un défenseur local des droits de données, travaillant avec un chercheur universitaire, a découvert que les chiffres publiés au niveau du district pouvaient être recoupés contre un ensemble de données ouvert séparément publié et également bien intentionné de l'autorité locale de transport — montrant les demandes de tarif subventionné par petite zone — pour réduire certains districts à des comptes de ménage assez petits pour que des familles spécifiques puissent plausiblement être identifiées, particulièrement dans les districts ruraux peu peuplés où les deux ensembles de données comptaient des nombres de ménages à un seul chiffre. Aucun ensemble de données seul n'était divulgatoire ; combinés, dans les zones les moins peuplées, ils l'étaient. Le premier instinct des organismes, de retirer entièrement l'ensemble de données ouvert, aurait détruit la valeur de redevabilité et de ciblage de bienfaisance qu'il avait déjà commencé à livrer. Au lieu de cela, travaillant avec le même défenseur, ils ont republié l'ensemble de données en utilisant une approche de confidentialité différentielle qui ajoutait du bruit calibré aux petits comptes, préservant son utilité pour repérer de larges schémas régionaux tout en rendant le compte réel de tout district à faible population assez incertain pour défaire l'attaque de recoupement qui avait exposé la publication originale. L'épisode est devenu l'étude de cas que les organismes ont utilisée dans leur propre formation subséquente du personnel, pour pourquoi la désidentification doit être évaluée contre ce qui est autrement publiquement disponible, non contre l'ensemble de données isolément.

Quatre angles sectoriels

Collectivités locales

Une collectivité locale fait typiquement fonctionner plus de systèmes distincts, plus anciens, et moins intégrés par résident servi qu'un organisme national, parce que des décennies de systèmes départementaux individuellement approvisionnés — logement, urbanisme, déchets, soins sociaux — ont rarement été bâtis pour partager des données entre eux. Cela rend l'interopérabilité une véritable bataille interne avant d'en être jamais une externe : un résident interagissant avec trois départements du conseil en une semaine peut trouver qu'aucun d'eux ne peut voir ce que les autres savent déjà. Les données ouvertes locales, pendant ce temps, tendent à avoir une valeur civique inhabituellement directe — calendriers de collecte des poubelles, demandes d'urbanisme, dépense locale — parce que les résidents et journalistes locaux s'y engagent à un niveau de spécificité que les ensembles de données nationaux offrent rarement, ce qui élève les enjeux pour bien faire les métadonnées et la fréquence de mise à jour même pour des ensembles de données modestes et quotidiens.

Gouvernement national

Les gouvernements nationaux font typiquement fonctionner la gamme la plus complète d'instruments de gouvernance des données et d'interopérabilité — une stratégie nationale de données, des schémas d'identifiant à travers le gouvernement, des portails de données ouvertes mandatés, et des régulateurs dédiés de protection des données — mais le pur nombre de systèmes hérités accumulés à travers des décennies et administrations rend l'interopérabilité technique une tâche de fond persistante et coûteuse plutôt qu'un projet ponctuel. Les programmes de données ouvertes nationaux portent un risque de réidentification disproportionné précisément parce que les ensembles de données nationaux sont assez grands pour être authentiquement précieux et assez détaillés, une fois liés contre d'autres registres nationaux, pour identifier des individus ; les documents de stratégie nationale de données que plusieurs gouvernements publient désormais nomment de plus en plus explicitement les techniques de divulgation préservant la vie privée, plutôt que de traiter la désidentification comme un détail d'implémentation sous l'attention politique.

Secteur social et organismes à but non lucratif

Un organisme à but non lucratif ou une organisation non gouvernementale (ONG) est rarement soumis à un mandat de données ouvertes, mais il fait face de plus en plus à une attente parallèle des bailleurs de fonds, régulateurs, et du public que les données de programme soient partagées de façon transparente, et il travaille souvent avec des populations — survivants de violence, personnes en pauvreté aiguë, résidents sans papiers — pour qui le risque de réidentification porte un coût personnel bien plus élevé qu'il ne le fait typiquement pour la population générale dans un ensemble de données gouvernemental. Les accords de partage de données comptent de façon disproportionnée ici parce qu'un organisme à but non lucratif partage fréquemment des données de client avec des bailleurs de fonds gouvernementaux ou organisations partenaires sous des contrats qu'il n'a pas écrits, et il a besoin de la capacité de négocier la limitation du but plutôt que simplement accepter quels que soient les termes de partage de données attachés au financement. Les normes d'interopérabilité adoptées par de plus grands bailleurs de fonds gouvernementaux ou philanthropiques peuvent être un véritable fardeau sur la capacité technique limitée d'une petite organisation, ce qui est un véritable coût valant la peine d'être nommé plutôt que de traiter l'adoption de normes comme sans coût.

Organismes multilatéraux et internationaux

Les organismes multilatéraux agrègent des données à travers des États membres avec une maturité de gouvernance, une capacité statistique, et des régimes légaux de vie privée vastement différents, ce qui rend l'interopérabilité sémantique — convenir de ce qu'un champ partagé signifie réellement — un problème diplomatique autant que technique persistant ; un terme aussi basique que « ménage » ou « chômeur » est défini assez différemment à travers les pays pour que les organismes statistiques internationaux maintiennent des normes entières, telles que le format Statistical Data and Metadata Exchange (SDMX), purement pour rendre les données transnationales authentiquement comparables. Les données ouvertes à ce niveau fonctionnent comme un bien public particulièrement clair au sens exposé au thème 1.4 — Biens publics, biens de mérite et pluralisme des valeurs, parce qu'aucun État membre unique n'a d'incitation à financer un ensemble de données comparatif mondial seul, pourtant chaque État et chercheur en bénéficie une fois qu'un organisme multilatéral en publie un. Les préoccupations de souveraineté des données courent plus profondément ici que dans un contexte d'un seul pays : un État membre peut résister à partager des données qu'il a légalement le droit de retenir, ou peut contester comment un organisme multilatéral a classifié ou agrégé ses propres chiffres nationaux, ce qui rend la question de gouvernance de qui contrôle une statistique partagée aussi conséquente que la question technique de comment elle est échangée.

Modes de défaillance courants

Les silos de données silencieux. Les systèmes s'accumulent indépendamment à travers une organisation sans identifiant ou schéma partagé, et le coût reste caché jusqu'à ce qu'un cas spécifique — un échec de protection, un audit, une panne de service — exige une vue combinée qui s'avère impossible à produire rapidement, moment auquel le coût du silo devient visible d'un coup et coûteux à corriger sous pression.

Le théâtre de l'anonymisation. Un ensemble de données a des noms et identifiants évidents retirés et est ensuite traité comme sûr à publier sans aucune évaluation des quasi-identifiants ou du risque de liaison contre d'autres données disponibles. Le coût fait surface, souvent publiquement et de façon embarrassante, quand un chercheur, journaliste, ou défenseur démontre que la réidentification est possible, moment auquel la crédibilité de l'organisation sur la vie privée est endommagée bien au-delà de l'ensemble de données spécifique impliqué.

La gouvernance sans propriétaire. La politique de gouvernance des données existe sur papier, mais aucune personne spécifique n'est redevable de la qualité ou de l'actualité d'un ensemble de données spécifique, donc les normes se dégradent discrètement et personne ne le remarque jusqu'à ce que les données soient invoquées pour une décision qu'elles ne peuvent réellement pas soutenir. C'est un échec particulièrement courant parce que le document de politique lui-même semble complet, masquant l'absence de quiconque réellement redevable en dessous.

L'interopérabilité par mandat, sans dotation en ressources. Un schéma partagé ou un schéma d'identifiant est mandaté centralement mais jamais financé pour les équipes censées l'adopter, donc la conformité devient un exercice de case à cocher — un champ techniquement présent mais non correctement rempli — plutôt qu'une véritable interopérabilité utilisable. Le coût est un faux sentiment qu'une norme partagée existe, découvert seulement quand quelqu'un essaie réellement de s'appuyer sur les données qu'elle était censée normaliser.

Le blanchiment d'ouverture. Une organisation publie des tableaux de bord et des visualisations sommaires et appelle cela des données ouvertes, tandis que l'ensemble de données lisible par machine sous-jacent dont un tiers aurait besoin pour bâtir quelque chose de nouveau reste non publié ou publié dans un format que personne ne peut pratiquement réutiliser. Cela capture l'apparence de transparence et d'ouverture décrite au thème 3.4 — Redevabilité, transparence et légitimité sans sa substance, et c'est souvent confondu avec un véritable programme de données ouvertes parce que le tableau de bord semble impressionnant.

Modèle de maturité

Liste de vérification

• Identifiez le système source faisant autorité pour chacune des entités de données centrales de votre organisation.
• Confirmez que chaque ensemble de données qui compte matériellement a un intendant nommé et redevable.
• Vérifiez si un schéma ou une norme partagée existe déjà pour un nouveau projet de données avant d'en concevoir un sur mesure.
• Révisez la conception de votre identifiant unique pour la persistance et la cohérence à travers les systèmes qui l'utilisent.
• Remplacez au moins un échange de données manuel ou basé sur feuille de calcul récurrent par une API gouvernée.
• Confirmez que chaque accord de partage de données inter-organismes actif énonce son but, sa base légale, et son expiration, et correspond à l'usage réel actuel.
• Menez une évaluation de risque de réidentification, incluant la liaison plausible contre d'autres ensembles de données publics, avant de publier tout ensemble de données impliquant de l'information personnelle.
• Appliquez une technique formelle préservant la vie privée, telle que la k-anonymité ou la confidentialité différentielle, à toute publication impliquant de petites populations ou des caractéristiques rares.
• Confirmez que votre catalogue de données ouvertes inclut de véritables métadonnées actuelles, non seulement des noms de fichiers.
• Révisez les ensembles de données précédemment publiés contre des données externes nouvellement disponibles pour un risque de réidentification émergent.
• Confirmez que les décisions de rétention sont prises par un rôle nommé et redevable contre des critères documentés.
• Posez à votre équipe les six questions de discussion ci-dessus et enregistrez où la réponse honnête diffère de l'officielle.

Sources principales

• International Open Data Charter, ses six principes, et son orientation sur la publication ouverte par défaut.
• Recommandation du Conseil de l'OCDE sur l'amélioration de l'accès aux données et de leur partage (2021).
• US National Institute of Standards and Technology, Special Publication 800-226, Guidelines for Evaluating Differential Privacy Guarantees.
• Documents du US Census Bureau sur l'évitement de divulgation et son application de la confidentialité différentielle aux données du recensement décennal.
• Le travail fondateur de Cynthia Dwork formalisant la confidentialité différentielle, et la littérature académique plus large sur le contrôle de divulgation statistique.
• Le triangle stratégique de Mark H. Moore et la logique des biens publics exposée au thème 1.4 — Biens publics, biens de mérite et pluralisme des valeurs, comme le cadrage sur lequel ce thème s'appuie.

Références

1. Data governance — Wikipedia — https://en.wikipedia.org/wiki/Data_governance
2. Data steward — Wikipedia — https://en.wikipedia.org/wiki/Data_steward
3. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
4. Application programming interface — Wikipedia — https://en.wikipedia.org/wiki/Application_programming_interface
5. Metadata — Wikipedia — https://en.wikipedia.org/wiki/Metadata
6. Open data — Wikipedia — https://en.wikipedia.org/wiki/Open_data
7. Data re-identification — Wikipedia — https://en.wikipedia.org/wiki/Data_re-identification
8. K-anonymity — Wikipedia — https://en.wikipedia.org/wiki/K-anonymity
9. Differential privacy — Wikipedia — https://en.wikipedia.org/wiki/Differential_privacy
10. Privacy by design — Wikipedia — https://en.wikipedia.org/wiki/Privacy_by_design
11. Open Data Charter principles — International Open Data Charter — https://opendatacharter.org/principles/
12. Recommendation of the Council on Enhancing Access to and Sharing of Data (2021) — OECD Legal Instruments — https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0463
13. Guidelines for Evaluating Differential Privacy Guarantees, SP 800-226 (Initial Public Draft) — US National Institute of Standards and Technology — https://csrc.nist.gov/pubs/sp/800/226/ipd
14. Disclosure avoidance and data stewardship — US Census Bureau — https://www.census.gov/about/policies/privacy/statistical_safeguards/disclosure-avoidance.html
15. Data.gov — US federal open data portal, General Services Administration — https://www.data.gov/