Open Data et données internes : comment les articuler sans créer de confusion ?

Articuler open data et données internes suppose de fixer, pour chaque information partagée, quelle source fait foi, de rapprocher les deux par une clé commune à la même maille et au même millésime, de stocker la donnée ouverte sans la modifier et d'afficher l'origine de chaque chiffre jusqu'au tableau de bord.

Une entreprise intègre la base SIRENE pour compléter son fichier clients. Une collectivité croise ses données de fréquentation avec les populations légales de l'Insee. Une direction commerciale ajoute le revenu médian par commune dans son outil de ciblage. Chaque fois, le croisement paraît simple : deux fichiers, une colonne commune, une jointure.

Quelques mois plus tard, le même indicateur affiche deux valeurs selon le tableau de bord consulté. Une adresse saisie par un commercial a été remplacée par l'adresse administrative issue d'un import automatique. Deux calculs de taux de couverture reposent sur deux millésimes différents de la population communale. Dans l'entrepôt de données, plus personne ne sait quelles colonnes viennent de l'extérieur et lesquelles ont été produites en interne.

Une idée reçue alimente cette situation : publiée par un organisme public, la donnée ouverte serait plus fiable que la donnée interne et pourrait la corriger. Une donnée ouverte n'est pas plus juste qu'une donnée interne, elle répond à une autre définition, produite par un autre acteur, à une autre date. Remplacer l'une par l'autre ne supprime pas l'erreur, cela la déplace.

La confusion ne tient donc ni à la qualité de la source publique ni à celle des systèmes internes. Elle tient à l'absence de règles à l'endroit précis où les deux se rencontrent. Ces règles sont peu nombreuses, elles se décident avant la première intégration, et elles relèvent de la gouvernance des données bien plus que de la technique.

Open Data et données internes : pourquoi le croisement crée de la confusion

La confusion entre open data et données internes naît d'une asymétrie que le fichier ne montre pas. Une donnée ouverte et une donnée interne peuvent porter le même nom de colonne, le même format et parfois la même valeur, tout en décrivant deux réalités différentes.

Donnée ouverte et donnée interne ne suivent pas les mêmes règles

Une donnée interne est produite pour un usage de l'entreprise. Sa définition, son rythme de mise à jour et ses contrôles sont décidés en interne, et peuvent être modifiés quand le besoin évolue. Une donnée ouverte est produite par un tiers, pour ses propres missions ou pour répondre à une obligation légale, selon une définition que l'entreprise ne maîtrise pas.

Cinq différences expliquent la plupart des écarts constatés lorsque les deux sources sont croisées.

• Le producteur : la donnée interne a un responsable que l'on peut interroger et qui peut corriger une valeur. La donnée ouverte a un producteur externe, joignable au mieux par un espace de discussion public.
• La définition : l'adresse d'un établissement dans la base SIRENE est son adresse administrative déclarée. Ce n'est ni l'adresse de livraison, ni le lieu où travaille l'interlocuteur commercial.
• Le calendrier : une donnée ouverte est publiée au rythme de son producteur, souvent avec un décalage. Les populations légales entrées en vigueur au 1er janvier d'une année décrivent la situation de trois ans plus tôt.
• La maille : une donnée ouverte est souvent publiée à la commune, à l'IRIS ou au département, quand l'entreprise raisonne par client, par magasin ou par zone commerciale.
• La licence : la donnée interne appartient à l'entreprise. La donnée ouverte s'accompagne d'obligations de réutilisation, légères ou contraignantes selon la licence retenue par le producteur.

Tant que ces cinq différences ne sont écrites nulle part, elles se découvrent au moment où deux chiffres divergent en comité.

Trois symptômes d'une articulation mal définie

Les organisations qui croisent des données ouvertes sans règle préalable voient apparaître les mêmes signaux. Ils sont souvent attribués à un problème de qualité, alors qu'ils révèlent un problème d'organisation.

Trois symptômes reviennent d'une organisation à l'autre.

• Des chiffres contradictoires pour une même notion : le nombre de clients par commune diffère entre deux tableaux de bord, parce que l'un rattache les clients par code postal et l'autre par code commune.
• Une donnée interne écrasée sans trace : un import de la donnée ouverte remplace une valeur saisie par un commercial, sans conserver l'ancienne valeur ni indiquer d'où vient la nouvelle.
• Une origine devenue invisible : dans l'entrepôt de données, rien ne distingue plus une colonne issue d'un fichier public d'une colonne produite par les équipes, et personne ne sait laquelle mettre à jour.

Aucun de ces symptômes ne disparaît avec un nettoyage des données. Chacun disparaît quand le rôle de chaque source a été décidé avant l'intégration.

Quelle source fait foi entre Open Data et données internes ?

La première règle à fixer entre open data et données internes ne porte pas sur la technique mais sur la responsabilité. Pour chaque information présente à la fois dans une source ouverte et dans un système interne, l'organisation doit décider laquelle fait référence, pour quel usage, et qui peut modifier ce choix.

Désigner la source de référence attribut par attribut

La source de référence se décide au niveau de l'attribut, pas du jeu de données entier. Un même fichier client peut prendre la raison sociale et le code d'activité dans la base SIRENE, tout en gardant l'adresse de livraison, le contact et le statut commercial dans le CRM.

Cette répartition se formalise dans une table simple : pour chaque attribut, la source retenue, la raison du choix et la personne qui l'a validé. Le Data Owner du domaine client est le mieux placé pour trancher, parce qu'il connaît l'usage métier de chaque information. Une table de quelques lignes, validée une fois, évite des dizaines d'arbitrages au cas par cas.

Trois questions suffisent à désigner la source de référence d'un attribut.

• Quelle définition l'usage exige-t-il ? Une facturation exige l'adresse du siège, une livraison exige l'adresse du site. La source qui porte la bonne définition l'emporte, quelle que soit sa réputation de fiabilité.
• Quelle source est la plus à jour pour cet attribut ? Une cessation d'activité apparaît souvent dans le répertoire public avant d'être connue du commercial. Un changement d'interlocuteur, lui, n'apparaîtra jamais dans une base publique.
• Qui peut corriger une erreur ? Une erreur dans la donnée interne se corrige en interne. Une erreur dans la donnée ouverte se signale au producteur et se corrige à son rythme, ce qui compte quand l'attribut alimente un processus quotidien.

La réputation d'une source ne décide pas du choix : c'est l'usage de l'information qui décide.

La donnée ouverte comme référentiel : aligner sans remplacer

Certaines données ouvertes jouent naturellement le rôle de référentiel : liste des communes, nomenclature des activités, répertoire des entreprises, base des adresses. Les utiliser comme tables de référence évite de maintenir en interne une liste qui existe déjà, tenue à jour par un producteur dont c'est la mission.

L'erreur consiste à confondre alignement et remplacement. Aligner, c'est rattacher chaque enregistrement interne à l'identifiant du référentiel public, en conservant la donnée interne à côté. Remplacer, c'est écraser la donnée interne par la donnée publique, et perdre ce que l'entreprise savait de plus que le registre.

Les démarches de Master Data Management reposent sur cette distinction. Un référentiel consolidé garde la trace de chaque source et de la règle qui a permis de retenir une valeur plutôt qu'une autre. Sans cette trace, la première contestation d'un chiffre oblige à reconstituer l'historique à la main.

La donnée ouverte comme contexte : enrichir sans écraser

Dans la plupart des cas, la donnée ouverte n'a pas vocation à devenir un référentiel. Elle apporte un contexte : revenu médian d'une commune, densité de population, relevés météorologiques, zonage réglementaire. Elle s'ajoute alors à côté de la donnée interne, dans des colonnes distinctes, sans jamais la modifier.

Cette séparation a une conséquence pratique immédiate. Une colonne de contexte peut être retirée, remplacée par un autre millésime ou par une autre source sans toucher aux données de l'entreprise. Une donnée ouverte ajoutée en colonne se remplace facilement, une donnée ouverte fusionnée dans une colonne interne ne se retire plus.

👉 À lire aussi : Quels cas d’usage peuvent réellement tirer parti de l’Open Data ?

Rapprocher données ouvertes et données internes : clé, maille et millésime

Une fois le rôle de chaque source décidé, le rapprochement entre données ouvertes et données internes repose sur trois conditions techniques. Si une seule manque, la jointure produit un résultat faux mais plausible. C'est la situation la plus coûteuse, parce que personne ne pense à la remettre en cause.

Choisir une clé de rapprochement stable et partagée

Un rapprochement fiable passe par un identifiant pivot présent des deux côtés. Les données publiques françaises en proposent plusieurs : le numéro SIREN ou SIRET pour les entreprises et leurs établissements, le code officiel géographique de l'Insee pour les communes, l'identifiant de la Base Adresse Nationale pour les adresses.

Le rapprochement par libellé (nom d'entreprise, nom de commune, adresse saisie en texte libre) reste possible, mais il produit une part d'erreurs qu'il faut mesurer avant de s'y fier. Un profilage des données des deux sources, mené avant la première jointure, révèle le taux de correspondance réel, les doublons et les formats incompatibles.

Trois pièges reviennent dans le choix de la clé.

• Le code postal utilisé comme code commune : un code postal peut couvrir plusieurs communes, et une commune peut avoir plusieurs codes postaux. Toute agrégation par code postal d'une donnée publiée par commune produit un résultat faux.
• Le SIREN utilisé à la place du SIRET : le SIREN identifie l'entreprise, le SIRET identifie chacun de ses établissements. Rattacher un site client au SIREN revient à lui attribuer les caractéristiques du siège.
• La clé ressaisie à la main : un identifiant public recopié dans le CRM sans contrôle de format contient des erreurs de frappe. La jointure transforme ces erreurs en absences silencieuses, que personne ne remarque dans un total.

Le taux de correspondance obtenu doit être connu et affiché avant que le moindre indicateur soit calculé sur la jointure.

Travailler à la même maille des deux côtés

Deux données se comparent à la même maille ou ne se comparent pas. Un taux de pénétration obtenu en divisant le nombre de clients d'un magasin par la population de sa commune suppose que la zone de chalandise du magasin coïncide avec la commune, ce qui est rarement le cas.

Deux solutions existent, et le choix entre elles est un choix de méthode.

• Agréger la donnée interne à la maille de la donnée ouverte : le calcul perd en précision mais reste juste. C'est la solution à retenir quand l'indicateur sert à comparer des territoires entre eux.
• Reconstruire la maille interne à partir de mailles publiques plus fines : une zone de chalandise peut être décrite comme un ensemble d'IRIS ou de communes. La méthode de passage doit alors être documentée, car elle conditionne tous les résultats.

Quelle que soit l'option retenue, la méthode de passage d'une maille à l'autre s'écrit à côté de l'indicateur, pas dans la mémoire de l'analyste qui l'a construit.

Dater chaque donnée ouverte par son millésime

Les référentiels publics évoluent en permanence. Le code officiel géographique change chaque 1er janvier au gré des fusions de communes, les nomenclatures d'activités sont révisées, les établissements naissent et ferment en continu dans le répertoire des entreprises. Une jointure entre le millésime 2024 d'un référentiel et des données internes de 2026 laisse des enregistrements sans correspondance.

Trois pratiques évitent que le millésime devienne une source d'écart invisible.

• Stocker le millésime dans la donnée elle-même : une colonne indique la date de référence de chaque valeur issue d'une source ouverte, en plus de la date d'import.
• Conserver les millésimes successifs : remplacer l'ancien fichier par le nouveau empêche de recalculer un indicateur passé et d'expliquer une variation d'une année sur l'autre.
• Aligner les millésimes avant de croiser : deux données ouvertes croisées entre elles doivent décrire la même date. Si ce n'est pas possible, l'écart de date est signalé dans l'indicateur.

Tracer l'origine des données ouvertes dans le système d'information

La troisième famille de règles porte sur la visibilité de l'origine des données. Une donnée ouverte correctement rapprochée redevient source de confusion dès que son origine se perd, quelque part entre le fichier téléchargé et le chiffre présenté en comité.

Isoler les données ouvertes dans une zone dédiée

Dans la plateforme de données, les jeux ouverts gagnent à être stockés dans une zone qui leur est propre, séparée des données produites par l'entreprise. Le fichier y est conservé tel qu'il a été publié, avec son millésime, sans aucune correction. Les transformations (sélection de colonnes, harmonisation des codes, agrégation) interviennent ensuite dans le pipeline de données, ce qui les rend rejouables à chaque nouvelle version.

Cette séparation produit deux effets utiles.

• Un nouveau millésime se charge sans risque : il remplace ou complète le précédent dans sa zone, sans toucher aux traitements des données internes.
• La dépendance aux sources publiques devient mesurable : l'organisation peut enfin répondre à une question que beaucoup ne savent pas traiter, à savoir quels indicateurs dépendent aujourd'hui d'une source publique.

Documenter source, licence et millésime dans le catalogue

Chaque jeu ouvert intégré mérite une fiche dans le catalogue de données, au même titre qu'une table interne. Un Data Catalog mis en place tôt offre l'emplacement naturel pour ces informations. Le suivi du lignage des données permet ensuite de relier la donnée ouverte à chacun des indicateurs qui l'utilisent.

La fiche d'un jeu ouvert intégré comporte au minimum six informations.

• Le producteur et l'adresse de publication : pour savoir où vérifier une valeur et où signaler une erreur.
• Le millésime et la fréquence de publication : pour savoir quelle version est en place et quand attendre la suivante.
• La licence : Licence Ouverte, ODbL ou autre, avec les obligations qu'elle entraîne en cas de diffusion externe.
• La définition des attributs utilisés : reprise de la documentation du producteur, sans reformulation interne qui en modifierait le sens.
• Le rôle attribué dans l'entreprise : référentiel, contexte ou matière d'analyse, avec la liste des attributs pour lesquels la source fait foi.
• Le responsable interne : la personne qui surveille les nouvelles versions et répond aux questions des utilisateurs.

Afficher l'origine jusqu'au tableau de bord

L'origine d'une donnée doit rester lisible à l'endroit où la décision se prend. Un indicateur qui combine des données internes et une donnée ouverte mentionne la source externe et son millésime, dans la légende du graphique ou dans une info-bulle. Un utilisateur qui lit « population Insee, millésime 2023 » sous un graphique ne confond plus ce chiffre avec un comptage interne.

Cette mention protège aussi l'équipe data. Quand un utilisateur signale un écart, la source affichée oriente immédiatement la vérification vers le bon jeu de données, au lieu de déclencher une recherche dans l'ensemble des traitements.

Le parcours complet d'une donnée ouverte, depuis sa publication jusqu'à l'indicateur, repose sur une séparation maintenue jusqu'au dernier moment : les deux sources restent dans des zones distinctes, se croisent selon des règles écrites, et le résultat garde la trace de son origine.

Gérer les écarts entre Open Data et données internes

Même avec des règles claires, open data et données internes divergeront. Le répertoire public indiquera fermée une entreprise que le CRM considère active, un effectif différent de celui connu du commercial, une adresse qui ne correspond plus. La manière de traiter ces écarts décide de la confiance accordée à l'ensemble du dispositif.

Un écart entre sources est une information, pas une anomalie à masquer

Un écart entre une donnée ouverte et une donnée interne signale l'une de trois situations. La donnée interne est périmée, la donnée ouverte est en retard ou erronée, ou les deux sources décrivent des notions différentes sous le même nom. Chacune appelle une réponse différente, et aucune ne se règle en retenant arbitrairement l'une des deux valeurs.

Les écarts méritent donc d'être mesurés et suivis comme un indicateur de qualité. Un taux d'écart qui augmente sur un attribut révèle souvent un problème de saisie interne, ou un changement de définition chez le producteur, avant que les utilisateurs ne s'en aperçoivent.

Qui arbitre un écart entre une donnée ouverte et une donnée interne ?

L'arbitrage revient au Data Steward du domaine concerné, qui connaît les règles de gestion et peut qualifier l'écart. Il s'appuie sur la table des sources de référence validée par le Data Owner : quand la source qui fait foi est définie, l'arbitrage se limite à appliquer la règle et à corriger la source fautive.

Le traitement d'un écart suit un ordre constant, qui évite de le rouvrir à chaque import.

• Qualifier l'écart : donnée interne périmée, donnée ouverte en retard ou erronée, ou définition différente sous un même libellé.
• Appliquer la règle de référence : la source qui fait foi pour cet attribut l'emporte, sans nouveau débat au cas par cas.
• Corriger à la source : mettre à jour le système interne, ou signaler l'erreur au producteur de la donnée ouverte.
• Tracer la décision : conserver l'écart, la décision prise et sa date, pour que le prochain import ne relance pas la même discussion.

Signaler une erreur au producteur de la donnée ouverte

Une donnée ouverte erronée ne se corrige pas en interne. Une correction locale crée une version propre à l'entreprise, qui divergera de nouveau au prochain millésime et que personne ne saura expliquer dans deux ans. La plupart des producteurs publics disposent d'un canal de signalement : espace de discussion sur la plateforme de publication, formulaire dédié ou adresse de contact.

Signaler une erreur prend quelques minutes et bénéficie à tous les réutilisateurs du jeu de données. En attendant la correction, la valeur interne est conservée et l'écart reste documenté, avec la référence du signalement effectué.

👉 À lire aussi : Data Owner, Data Steward, Data Custodian : le triptyque pour réussir sa gouvernance des données

Licences Open Data : ce qu'elles imposent aux données internes enrichies

La réutilisation d'une donnée ouverte est libre, mais elle n'est pas sans condition. Tant que le résultat reste à usage interne, les obligations sont légères. Elles deviennent significatives dès qu'une donnée interne enrichie sort de l'organisation : rapport remis à un client, application accessible au public, jeu de données transmis à un partenaire.

Licence Ouverte : mentionner la source et la date de mise à jour

La Licence Ouverte d'Etalab, utilisée par la plupart des administrations françaises, autorise toute réutilisation, y compris commerciale. Elle pose une condition : mentionner la paternité de l'information, c'est-à-dire sa source et la date de sa dernière mise à jour.

Cette obligation rejoint une pratique de gouvernance déjà utile en interne : afficher l'origine de chaque chiffre là où il est consulté. Une organisation qui affiche déjà la source et le millésime dans ses tableaux de bord remplit l'obligation de la Licence Ouverte sans effort supplémentaire.

ODbL : le partage à l'identique des bases dérivées

L'Open Database License, utilisée notamment par OpenStreetMap et par plusieurs collectivités, ajoute une clause de partage à l'identique. Lorsqu'une base de données dérivée d'une base sous ODbL est utilisée publiquement, cette base dérivée doit à son tour être mise à disposition sous la même licence.

Cette clause pèse sur les choix d'architecture. Une base client fusionnée avec une donnée sous ODbL, puis exposée dans un service accessible au public, peut entrer dans le champ de cette obligation. Garder la donnée ouverte dans des tables et des colonnes distinctes est une précaution de qualité, et c'est aussi une précaution juridique. Le service juridique doit être consulté avant toute diffusion externe d'une base enrichie de cette manière.

Publier une donnée interne enrichie : une décision à part entière

L'articulation fonctionne aussi dans l'autre sens. Une organisation qui a enrichi ses données avec des sources ouvertes est parfois sollicitée pour publier le résultat. Cette décision relève de la même analyse que toute décision d'ouverture des données : obligations légales, réutilisateurs identifiés, capacité de maintenance. S'y ajoutent ici les conditions de licence de chaque source ouverte utilisée.

Un point mérite une vigilance particulière. Le croisement d'une donnée interne agrégée avec des données ouvertes fines peut rendre des personnes réidentifiables, alors que chaque source prise isolément ne le permettait pas. L'analyse de risque porte donc sur le jeu croisé, jamais sur ses composants pris un par un.

Articuler Open Data et données internes : les règles à écrire avant le premier croisement

L'articulation entre open data et données internes ne demande ni outil spécifique ni projet de grande ampleur. Elle demande que six décisions soient prises et écrites avant que le premier fichier public entre dans la plateforme, plutôt que découvertes au moment où deux chiffres divergent.

Chacune de ces décisions a un porteur identifié, et chacune expose à un risque précis si elle reste implicite.

Une organisation qui a écrit ces six règles intègre une nouvelle source ouverte en quelques jours, parce que chaque question a déjà sa réponse. Une organisation qui ne les a pas écrites les redécouvre à chaque intégration, sous la forme d'un écart à expliquer.

Le coût d'une donnée ouverte ne tient pas au fichier téléchargé, il tient aux règles qui encadrent sa rencontre avec les données de l'entreprise. Ces règles se décident une fois, se révisent quand une source change, et donnent à chaque chiffre publié une origine que tout utilisateur peut vérifier.