Quels cas d’usage peuvent réellement tirer parti de l’Open Data ?

Un cas d’usage tire parti de l’open data lorsque la donnée ouverte y joue un rôle précis : servir de référentiel commun, enrichir une base incomplète, apporter une variable de contexte absente des systèmes internes, ou constituer la matière première du service lui-même. En dehors de ces quatre rôles, la donnée ouverte ajoute un flux à maintenir sans modifier la décision.

Le scénario se répète dans beaucoup d’organisations. Une équipe télécharge un fichier sur une plateforme publique, l’ouvre, en tire une carte ou un graphique, présente le résultat en comité. Tout le monde trouve la démarche intéressante. Six mois plus tard, personne ne sait si le fichier a été mis à jour, ni qui devrait s’en occuper, ni ce que la carte a changé dans les décisions prises depuis.

L’explication tient rarement à la qualité du jeu de données. Elle tient au point de départ. L’open data est presque toujours abordé par l’offre : on regarde ce qui est disponible, puis on cherche ce qu’on pourrait en faire. Cette logique produit des démonstrations, pas des usages. Une donnée externe ne crée pas un besoin, elle répond à un besoin déjà formulé.

L’idée reçue qui bloque le sujet est celle de la gratuité. Une donnée ouverte ne coûte rien à télécharger, donc l’essai paraît sans risque. En réalité, le coût ne se situe pas au téléchargement mais dans tout ce qui suit : le rapprochement avec les données internes, la reprise à chaque nouvelle version, la gestion des écarts de maille et de calendrier, la surveillance de la source. Ce coût est réel, récurrent, et il ne se justifie que si le cas d’usage en tire un bénéfice mesurable.

Reste donc à savoir quels cas d’usage passent ce test. La réponse ne dépend pas du jeu de données retenu, mais du rôle qu’on lui assigne dans la chaîne qui mène à une décision, et de la capacité de l’organisation à tenir ce rôle dans la durée.

Ce que l’open data apporte vraiment à un cas d’usage data

L’open data n’apporte jamais une valeur générique. Il joue un rôle identifiable dans la chaîne qui va de la donnée à la décision, et ce rôle détermine à la fois le bénéfice attendu et le niveau d’exigence sur la source. Nommer ce rôle avant d’ouvrir le fichier évite l’essentiel des impasses.

Les quatre rôles que peut jouer une donnée ouverte dans un cas d’usage

Une donnée ouverte intervient dans un cas d’usage selon quatre modalités distinctes, qui n’engagent ni le même travail d’intégration ni le même risque. Les distinguer permet de savoir dès le cadrage ce qui se passera le jour où la source change de format ou cesse d’être mise à jour.

• Le rôle de référentiel : la donnée ouverte sert de nomenclature partagée pour normaliser des données internes. Une adresse client est réécrite au format de la Base Adresse Nationale, un tiers est rattaché à son numéro SIREN. La donnée externe ne s’ajoute pas, elle remet de l’ordre dans ce qui existe déjà.
• Le rôle d’enrichissement : la donnée ouverte ajoute des attributs que l’organisation ne collecte pas. L’effectif, le secteur d’activité ou la forme juridique d’un client professionnel viennent compléter une fiche qui n’en contenait aucun.
• Le rôle de variable de contexte : la donnée ouverte explique une variation que les systèmes internes ne portent pas. Un pic de ventes s’explique par une vague de chaleur, une chute de fréquentation par un jour férié ou par un calendrier scolaire décalé selon les académies.
• Le rôle de source primaire : la donnée ouverte constitue la matière du service. Un outil d’estimation immobilière construit sur les demandes de valeurs foncières n’existe pas sans ce fichier. La dépendance est totale, et elle doit être traitée comme telle.

Ces quatre rôles forment une progression. Au premier, l’organisation garde la main : si la source disparaît, le référentiel interne continue de fonctionner, moins bien normalisé. Au dernier, la disparition de la source arrête le service. Le rôle joué par la donnée ouverte fixe le niveau de dépendance, et donc le niveau de vigilance à prévoir.

Pourquoi la gratuité d’un jeu de données ouvert ne dit rien de sa valeur d’usage ? 

La gratuité de l’open data porte sur l’accès, pas sur l’exploitation. Un jeu de données publié sous licence ouverte se télécharge sans contrepartie, mais son intégration dans un système d’information suit exactement le même chemin qu’une donnée achetée à un fournisseur, avec les mêmes étapes et les mêmes coûts.

Trois postes reviennent systématiquement, et ils sont rarement chiffrés au moment de la décision d’intégrer une source ouverte dans un cas d’usage.

• Le rapprochement avec les données internes : aucun jeu de données ouvert ne s’aligne spontanément sur un référentiel d’entreprise. Il faut définir la clé de rapprochement, mesurer le taux d’appariement obtenu, et décider quoi faire des lignes qui ne s’apparient pas. C’est le poste le plus souvent sous-estimé.
• La reprise à chaque version : les producteurs publics font évoluer leurs formats, leurs nomenclatures et leurs périmètres. Une colonne renommée, une commune fusionnée ou un millésime restructuré suffisent à casser un traitement qui fonctionnait depuis deux ans.
• La surveillance de la source : une donnée ouverte peut cesser d’être mise à jour sans annonce. Sans contrôle automatique de la fraîcheur, l’anomalie se découvre au moment où quelqu’un s’étonne d’un chiffre, souvent plusieurs mois après.

Ces coûts ne disqualifient pas l’open data. Ils fixent simplement le seuil à partir duquel il devient intéressant : le bénéfice attendu doit dépasser la charge d’intégration et de maintien, sur la durée de vie du cas d’usage, pas sur la durée du test. Cette arithmétique est la même que pour un projet de données de référence, où le coût réel se joue dans la reprise et la maintenance, pas dans l’acquisition.

👉 À lire aussi : Open Data : quand l’ouverture des données a du sens (et quand elle n’en a pas)

Quels cas d’usage métier tirent le meilleur parti des données ouvertes ?

Les cas d’usage qui fonctionnent avec de l’open data partagent une caractéristique : la donnée externe y comble un manque identifié, dont l’absence bloquait ou dégradait une décision. Six familles reviennent régulièrement dans les organisations françaises, publiques comme privées.

Fiabiliser un référentiel client ou fournisseur avec des données ouvertes d’identité

La fiabilisation d’un référentiel de tiers est le cas d’usage open data le plus rentable, et le moins spectaculaire. Une base client contient des adresses saisies à la main, des raisons sociales approximatives, des doublons créés par des orthographes concurrentes. Les référentiels publics d’identité permettent de reprendre cette matière et de la ramener à une écriture unique.

Deux sources structurent ce travail en France. La Base Adresse Nationale normalise les adresses postales et leur associe des coordonnées géographiques. Le répertoire SIRENE identifie les entreprises et leurs établissements par un numéro unique, avec leur activité déclarée et leur état administratif.

Le bénéfice se mesure immédiatement sur des indicateurs concrets, ce qui rend ce cas d’usage facile à défendre.

• La réduction des doublons : deux fiches qui portaient des orthographes différentes se rattachent au même identifiant et deviennent réconciliables.
• La qualité des envois : une adresse normalisée réduit les retours courrier et les livraisons échouées, avec un coût évité directement chiffrable.
• La fiabilité des analyses géographiques : un chiffre d’affaires réparti par commune ne veut rien dire tant que les adresses ne sont pas rattachées à un code officiel.
• Le suivi de l’état des tiers : un établissement fermé administrativement reste actif dans beaucoup de bases internes pendant des mois.

Ce cas d’usage suppose une décision préalable, souvent éludée : que fait-on des lignes qui ne s’apparient pas ? Un taux d’appariement de 92 % laisse 8 % de la base dans un état intermédiaire, et ces 8 % concentrent en général les cas les plus problématiques. Sans règle de traitement pour le reliquat, la normalisation crée deux référentiels au lieu d’un.

Enrichir une base commerciale avec des données ouvertes d’entreprise et de territoire

L’enrichissement d’une base commerciale consiste à ajouter, sur des clients ou des prospects déjà connus, des attributs que l’organisation ne collecte pas elle-même. Les données publiques d’entreprise et les statistiques territoriales couvrent une partie de ce besoin sans passer par un fournisseur payant.

Les usages concrets sont directement liés à des décisions commerciales, ce qui distingue cette famille des exercices d’analyse sans suite.

• La segmentation par taille et par secteur : l’effectif et le code d’activité permettent de construire des segments cohérents à partir d’une base qui n’en contenait pas.
• Le ciblage géographique : les statistiques de population, de revenus et de composition des ménages aident à prioriser des zones de prospection.
• La qualification d’un potentiel : le nombre d’établissements d’un secteur sur un territoire donne un ordre de grandeur du marché adressable local.
• La détection de changements : une création, une cessation ou un déménagement d’établissement constituent des signaux commerciaux exploitables.

La limite de cet enrichissement est connue et doit être posée dès le cadrage. Les données publiques décrivent une situation déclarée et parfois ancienne : un effectif peut dater de l’exercice précédent, une activité déclarée peut ne pas correspondre à l’activité réelle. Ces données servent à prioriser, pas à décider seules.

Ajouter une variable de contexte à un modèle de prévision

L’ajout d’une variable de contexte est le cas d’usage où l’open data apporte le plus à un travail d’analyse prédictive. Un modèle entraîné uniquement sur des données internes ne voit que ce que l’entreprise enregistre. Il ignore la température, les jours fériés, les vacances scolaires ou les événements locaux, alors que ces facteurs expliquent souvent une part importante de la variation observée.

Les variables externes les plus utilisées sont peu nombreuses et faciles à récupérer.

• Les observations et prévisions météorologiques : température, précipitations et ensoleillement pèsent sur la fréquentation, la consommation d’énergie et certaines catégories de produits.
• Le calendrier : jours fériés, ponts et vacances scolaires par zone académique expliquent des variations qu’un modèle interprète autrement comme du bruit.
• Les données de mobilité : les horaires de transport publiés en données ouvertes éclairent les flux dans le commerce de proximité et les services.

Cette famille impose une exigence particulière, qui la rend plus difficile qu’elle n’en a l’air. Un modèle a besoin d’un historique aussi profond que la période d’entraînement, et d’un accès à la même variable en prévision. Une variable disponible en historique mais indisponible en projection ne sert à rien pour un modèle destiné à tourner en production.

Cadrer une décision d’implantation ou de tarification avec des données ouvertes territoriales

Le cadrage d’une décision d’implantation repose sur des informations que l’entreprise ne détient jamais en interne : ce qui se passe autour du point qu’elle envisage. Les données foncières, cadastrales et statistiques publiques couvrent précisément ce périmètre.

Les demandes de valeurs foncières, publiées par l’administration fiscale, recensent les transactions immobilières avec leur prix, leur date et leur localisation. Croisées avec le plan cadastral et les statistiques de population, elles permettent de situer un prix, d’observer une dynamique de marché et de comparer plusieurs zones sur une base homogène.

Ce cas d’usage réussit ou échoue sur un critère unique, la maille géographique. Une donnée disponible à la commune ne répond pas à une question posée à l’échelle d’un quartier, et une moyenne calculée sur trop peu de transactions ne veut rien dire. La maille de la donnée doit correspondre à la maille de la décision, sinon l’analyse produit une précision apparente sans fondement.

Objectiver un risque sur un site, un actif ou un fournisseur

L’objectivation d’un risque est une famille de cas d’usage en croissance, portée par les obligations de reporting et par les exigences des assureurs. Les données publiques d’exposition aux risques naturels et technologiques, les caractéristiques des bâtiments et les diagnostics de performance énergétique permettent de qualifier un parc immobilier ou une liste de sites sans lancer de campagne de collecte.

Trois applications reviennent régulièrement, avec un même point commun : elles remplacent une information absente par une information publique vérifiable.

• L’exposition d’un site : inondation, retrait-gonflement des argiles, proximité d’installations classées, ces informations conditionnent des décisions d’assurance et d’investissement.
• La caractérisation d’un parc : année de construction, surface et performance énergétique alimentent les trajectoires de rénovation et les obligations de publication extra-financière.
• La vérification d’un tiers : l’état administratif d’une entreprise et ses données légales publiques constituent un premier niveau de contrôle avant contractualisation.

Construire un produit ou un service dont la donnée publique est la matière première

La construction d’un produit sur une donnée publique est le cas d’usage le plus visible, et le plus exigeant. Les comparateurs de prix immobiliers, les applications de mobilité et les outils de vérification d’entreprise reposent entièrement sur des jeux de données ouverts. Sans eux, il n’y a pas de produit.

Cette dépendance impose des précautions que les autres familles n’exigent pas.

• La licence doit être compatible avec l’usage : une licence ouverte permissive et une licence à obligation de partage ne créent pas les mêmes contraintes pour un produit commercial.
• Les versions doivent être suivies : un service en production ne peut pas dépendre du dernier fichier téléchargé sans historique ni possibilité de revenir en arrière.
• La continuité doit être anticipée : un scénario de repli est nécessaire si la source cesse d’être publiée ou change de conditions d’accès.

Le tableau ci-dessous reprend ces six familles avec le rôle joué par la donnée ouverte, les sources typiquement mobilisées et la condition qui décide de la réussite.

Quels cas d’usage ne tirent pas parti de l’open data ?

Certains cas d’usage résistent à l’open data quelles que soient les sources mobilisées, et il vaut mieux le savoir avant d’engager un chantier d’intégration. Trois situations reviennent, chacune pour une raison différente.

Les décisions qui dépendent d’une donnée propre à l’entreprise

Une décision qui repose sur un comportement observé en interne ne trouvera pas sa réponse dans une donnée publique. Le parcours d’un client sur un site, la marge réalisée sur une référence, le taux de rebut d’une ligne de production, la charge d’une équipe : ces informations n’existent nulle part ailleurs que dans les systèmes de l’organisation.

L’erreur consiste à chercher un substitut public à une donnée interne manquante. Une statistique sectorielle ne remplace pas une mesure sur son propre périmètre. Elle donne un point de comparaison, ce qui est utile, mais elle ne dit rien de la situation particulière de l’entreprise. Quand la donnée interne manque, le chantier à ouvrir est celui de sa collecte, pas celui de son remplacement par une source externe.

Le principe est le même que pour les causes de mauvaise qualité des données : ajouter une source externe ne corrige jamais un défaut de collecte interne.

Les usages qui exigent une fraîcheur que la donnée ouverte ne garantit pas

Un cas d’usage qui a besoin d’une donnée récente se heurte au rythme de publication des producteurs publics. Les fréquences varient fortement d’une source à l’autre, et elles ne sont pas toujours tenues.

Trois décalages posent problème en pratique, et ils se combinent souvent.

• Le délai de publication : une donnée décrit une situation antérieure de plusieurs mois, parfois davantage pour les statistiques structurelles.
• L’irrégularité : un jeu de données annoncé comme mensuel peut rester inchangé plusieurs trimestres sans que rien ne le signale.
• La rétroactivité : certaines sources corrigent des millésimes passés, ce qui modifie des analyses déjà diffusées et rend les comparaisons instables.

Un pilotage opérationnel quotidien, une détection de fraude ou une alerte en temps réel ne peuvent pas s’appuyer sur ce type de source. En revanche, un cadrage stratégique, une étude de marché ou un modèle entraîné sur plusieurs années s’en accommodent parfaitement. La question n’est pas la qualité de la donnée ouverte, mais la compatibilité entre son rythme et celui de la décision.

Les explorations lancées sans question métier formulée

Une exploration lancée sans question précise produit des visualisations, rarement des décisions. Le mécanisme est toujours le même : un jeu de données paraît intéressant, quelqu’un le charge dans un outil, en sort des graphiques, les présente. La discussion porte sur la qualité du rendu, jamais sur ce qu’il faudrait décider.

Ces travaux ne sont pas inutiles en soi, mais ils ne constituent pas des cas d’usage. Ils deviennent coûteux lorsqu’ils occupent des ressources rares et qu’ils créent l’illusion d’une démarche en cours. Les critères qui permettent de savoir quand arrêter ou réorienter un cas d’usage s’appliquent ici sans adaptation : sans décision associée, sans propriétaire et sans suite prévue, l’exercice s’arrête après la présentation.

Comment tester si un cas d’usage peut réellement tirer parti de l’open data ?

Le test se fait avant l’intégration, en quelques questions, et il ne demande ni outil ni budget. Il consiste à vérifier que la donnée ouverte a bien un rôle, que ce rôle est tenable dans la durée, et que le résultat sera exploitable par quelqu’un.

Quatre questions à passer avant d’intégrer un jeu de données ouvert

Ces quatre questions se posent dans l’ordre, et une réponse négative à l’une d’elles suffit à interrompre le cadrage. Elles portent sur le besoin, sur la donnée, sur son intégration et sur son exploitation.

• Quelle décision change si cette donnée est disponible ? Si la réponse tient en une phrase concrète, avec un décideur identifié, le cas d’usage existe. Si la réponse commence par « on pourrait voir si », il s’agit d’une exploration.
• Le jeu de données couvre-t-il le périmètre réel ? Une couverture nationale ne signifie pas une couverture complète. Les taux de remplissage varient selon les territoires, les tailles d’organisation et les millésimes, et il faut le vérifier sur son propre périmètre, pas sur la documentation.
• Le rapprochement avec les données internes est-il possible ? Une clé commune doit exister, et son taux d’appariement doit être mesuré sur un échantillon avant tout engagement. C’est le point qui fait échouer le plus grand nombre de projets.
• Qui exploitera le résultat, et à quelle fréquence ? Un enrichissement consulté une fois par an ne justifie pas une chaîne d’intégration automatisée. Un export manuel documenté suffit, et coûte infiniment moins cher à maintenir.

Ce test ne remplace pas l’évaluation de la valeur métier d’un cas d’usage. Il la complète sur un point précis : la source envisagée est-elle capable de soutenir cette valeur dans la durée ?

👉 À lire aussi : Piloter des cas d’usage Data & IA : comment décider, prioriser et arrêter ?

Ce qu’il faut mettre en place pour tenir un cas d’usage open data dans la durée

Un cas d’usage open data qui passe en production change de nature : il devient une dépendance externe, avec les mêmes exigences qu’une intégration fournisseur. Quatre dispositions suffisent à le rendre durable, et leur absence explique la plupart des abandons observés au bout de quelques mois.

• Un propriétaire désigné : un Data Owner répond de la source ouverte comme de n’importe quelle donnée du périmètre. Sans nom sur la source, personne ne réagit quand elle change.
• Un contrôle de fraîcheur automatique : la date de dernière mise à jour est vérifiée à chaque exécution, et un écart déclenche une alerte plutôt qu’un constat tardif. Cette vérification s’intègre naturellement dans les indicateurs de qualité des données déjà suivis.
• Une trace de la licence et de la version : la licence applicable et le millésime utilisé sont documentés au même endroit que le traitement, pour que la question ne se repose pas à chaque audit.
• Une date de revue : le cas d’usage est réexaminé à échéance fixe, pour vérifier que le bénéfice attendu est toujours là et que la source n’a pas dérivé.

Ces dispositions relèvent du cadre de gouvernance existant, pas d’un dispositif spécifique. Une organisation qui sait déjà à quoi sert sa gouvernance des données n’a rien de nouveau à inventer pour les sources ouvertes. Elle a seulement à les traiter comme des données de plein exercice, avec un propriétaire, des contrôles et une revue.

Ce qu’il faut retenir avant de lancer un cas d’usage open data

Un cas d’usage open data se juge sur trois éléments, et aucun ne concerne le jeu de données lui-même. Le premier est le rôle joué par la donnée ouverte : référentiel, enrichissement, contexte ou source primaire. Le deuxième est la décision que ce rôle permet de prendre, formulée avec un décideur identifié. Le troisième est la capacité de l’organisation à maintenir la source dans le temps, avec un propriétaire et des contrôles.

Six familles de cas d’usage couvrent l’essentiel de ce qui fonctionne aujourd’hui dans les organisations françaises. Elles ont en commun de partir d’un manque précis, pas d’un catalogue. À l’inverse, les cas d’usage qui échouent partagent une origine unique : ils ont commencé par le fichier disponible et cherché ensuite à quoi il pourrait servir.

Une dernière vérification mérite d’être faite avant d’engager le chantier. La plupart des difficultés rencontrées avec l’open data ne viennent pas de la donnée externe, mais de l’état des données internes auxquelles on veut la rattacher. Un référentiel interne instable rend tout rapprochement hasardeux, quelle que soit la qualité de la source publique. Cette dépendance se vérifie aussi sur ce qu’une plateforme data doit réellement supporter : les sources externes n’y tiennent que si le socle interne tient déjà.