Quand deux agences ne parlent pas le même langage de données, c'est le citoyen qui paie le prix

En 2023, l'État de Californie a découvert que ses systèmes d'aide au logement et ses bases de données sur les bénéficiaires Medicaid utilisaient deux définitions différentes du mot "ménage". Résultat : des milliers de dossiers croisés ne pouvaient pas être réconciliés sans travail manuel, ralentissant l'attributionattributionUn framework qui attribue le crédit d'une conversion aux différents touchpoints y ayant contribué, afin de mesurer quels canaux et quelles interactions génèrent réellement des résultats.Voir la définition complète → des aides de plusieurs semaines. Ce n'est pas une anomalie. C'est le quotidien de la plupart des gouvernements qui n'ont pas mis en place de standards d'interopérabilité formels.

L'interopérabilité entre agences publiques désigne la capacité de systèmes distincts, gérés par des entités juridiquement séparées, à échanger et interpréter des données de façon cohérente sans transformation ad hoc à chaque échange. La confusion autour de ce concept tient souvent à une méprise : on la confond avec l'intégration technique (connecter des systèmes), alors qu'elle relève d'abord de la sémantique et de la gouvernance.

Pourquoi l'interopérabilité est l'affaire du CDO public, pas du DSI

Dans une entreprise privée, la valeur des données se mesure à leur contribution à la marge. Dans le secteur public, la mission remplace ce repère : une agence de santé publique ne maximise pas un taux de rendement, elle tente de réduire la mortalité infantile ou le taux de réhospitalisation. Cela change radicalement le rapport aux données partagées.

Quand le Department of Veterans Affairs ne peut pas récupérer automatiquement les données de santé d'un vétéran depuis les systèmes du Department of Defense, ce n'est pas un problème d'efficacité opérationnelle au sens commercial du terme : c'est un écart de mission. Et cet écart a des conséquences mesurables. Un rapport du Government Accountability Office de 2022 estimait que les doublons et incohérences de données entre agences fédérales américaines généraient plusieurs milliards de dollars de paiements incorrects chaque année dans les programmes de protection sociale.

Pour un CDO du secteur public, l'interopérabilité est aussi une question de conformité. Les accords de partage de données entre agences sont soumis aux exigences du Privacy Act, du FISMA, et dans certains cas du HIPAAHIPAAHealth Insurance Portability and Accountability Act, loi américaine imposant la protection des données de santé (PHI). Violations : amendes jusqu'à 1,9M$ par catégorie de violation.. Un data-sharing agreement mal rédigé ou un standard de données non documenté peut bloquer un audit, voire exposer l'agence à des recours. Les équipes juridiques et les auditeurs de l'inspector general ne vérifient pas seulement que les données circulent : ils vérifient que leur circulation est autorisée, traçable et conforme. Comprendrecomment les données circulent effectivement entre registres administratifs, enquêtes et bases opérationnelles est le préalable à tout projet d'interopérabilité sérieux.

Comment fonctionne un standard d'interopérabilité entre agences publiques ?

Un standard d'interopérabilité repose sur trois couches qui doivent être alignées simultanément : le format technique, le modèle sémantique et le protocole de gouvernance.

Prenons un exemple concret : le programme Homeless Management Information System (HMIS) aux États-Unis. Le Department of Housing and Urban Development impose à toutes les agences financées fédéralement d'utiliser un data dictionary commun, un ensemble d'éléments de données définis précisément (nom, date de naissance, type de logement, épisode de sans-abrisme). Chaque agence locale collecte ses données dans son propre logiciel, mais selon ce dictionnaire. HUD peut alors agréger les données de plus de 400 Continuums of Care à l'échelle nationale, produire des statistiques cohérentes et piloter les financements.

Ce qui rend le modèle HMIS instructif, ce n'est pas sa sophistication technique : c'est l'architecture de gouvernance derrière lui. HUD publie chaque année une version mise à jour du dictionnaire, avec un cycle de consultation. Les éditeurs de logiciels certifiés doivent implémenter chaque version dans un délai fixé. Les agences locales doivent se conformer sous peine de perdre leur financement. La contrainte n'est pas technique mais budgétaire et contractuelle.

C'est là que réside la mécanique réelle. Les standards d'interopérabilité dans le secteur public tiennent rarement grâce à leur qualité intrinsèque : ils tiennent parce qu'ils sont adossés à des conditions de financement, à des clauses dans les contrats fédéraux, ou à des exigences légales. Le Federal Data Strategy américain, lancé en 2019 et dont l'exécution s'est poursuivie sous plusieurs administrations, repose sur ce même principe : des "data standards" publiés par le Office of Management and Budget, dont l'adoption est liée aux conditions d'obtention de certaines dotations fédérales.

En Europe, le Data Act entré en vigueur en 2024 impose des obligations similaires aux entités publiques sur le partage de données avec d'autres administrations et, dans certains cas, avec des acteurs privés. La norme n'est pas optionnelle : elle est juridiquement exigible.

Quand les standards partagés sont contre-productifs : les arbitrages que personne ne mentionne

L'interopérabilité a un coût réel, et certaines situations ne la justifient pas.

Premièrement, un standard trop centralisé peut figer des pratiques locales utiles. Une agence de santé d'un État rural qui collecte des données sur des indicateurs propres à sa population risque de perdre cette granularité si elle doit se conformer à un modèle fédéral conçu pour des contextes urbains. La standardisation nivelle parfois ce qu'elle devrait préserver.

Deuxièmement, les cycles de mise à jour des standards sont lents par nature : ils impliquent des consultations interagences, des validations juridiques, des migrations dans des systèmes souvent vieux de dix à quinze ans. Une agence qui a besoin de partager des données rapidement avec un partenaire peut légitimement préférer un accord bilatéral avec une table de correspondance, plutôt qu'attendre trois ans qu'un groupe de travail interministériel finalise un référentiel commun.

Troisièmement, la question des systèmes hérités. La majorité des agences publiques font tourner des applications sur des architectures des années 1990 ou 2000. Imposer un standard moderne d'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 → REST ou 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 → JSON-LD à un système COBOL en production sans budget de migration, c'est crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éererLe rapport entre les interactions (likes, commentaires, partages) et le reach d'un contenu, utilisé pour mesurer la réaction de l'audience au regard du nombre de personnes touchées.Voir la définition complète → un problème de conformité sur papier qui n'existe pas en pratique.Rédiger des accords de partage de données qui résistent à un audit suppose de documenter honnêtement ces écarts plutôt que de les masquer derrière une conformité fictive.

Quatrièmement, le risque d'équité. Un standard qui n'a pas été testé avec des données issues de populations minoritaires peut systématiquement mal classer ces populations lors des croisements entre agences. Ce n'est pas un risque hypothétique : plusieurs études ont documenté comment des identifiants fédéraux standardisés généraient des taux d'erreur plus élevés pour les noms composés ou les orthographes non anglophones.

Le CDO public qui pilote un projet d'interopérabilité doit donc poser deux questions avant d'adopter ou d'imposer un standard : à qui ce standard a-t-il été conçu, et qui finance son maintien dans le temps ? Un standard sans gouvernance durable est un projet pilote qui s'ignore.

L'interopérabilité entre agences publiques produit de la valeur réelle quand elle est adossée à une contrainte réelle : financement conditionné, obligation légale, ou pénalité d'audit. Sans ce levier, les groupes de travail interagences produisent des référentiels que personne n'implémente. Le travail du CDO public n'est pas de convaincre les collègues que le standard est bon ; c'est de trouver le mécanisme qui rend son adoption inévitable.

Le parcours complet sur ce secteur :Data dans Secteur public & associatif.