En data space mobilité, la donnée n’est plus un problème de capteurs ou d’algorithmes. Le vrai problème commence quand on veut la partager : contrôle, responsabilité, souveraineté, traçabilité. C’est précisément là que le concept de Data Space devient nécessaire — non pas comme une “plateforme”, mais comme un cadre de partage gouverné.

Nature de ce billet (position paper)

Ce billet ne présente pas un résultat expérimental ni une revue systématique de la littérature.

Il s’agit d’un position paper au sens académique du terme : une prise de position argumentée, fondée sur des travaux antérieurs (RS3, Telemachus), des retours terrain et une analyse critique des limites des modèles actuels de partage de données.

L’objectif est de poser un cadre d’interprétation — non de proposer une implémentation complète ni une solution clé en main.

Quand la donnée de mobilité sort de l’organisation

Pourquoi le Data Space devient nécessaire

Dans cet article, je propose une lecture data space mobilité issue d’un retour d’expérience “du signal au standard” : qualité GNSS/IMU, enrichissement (pente, contexte), puis interopérabilité. Pour le contexte technique, voir mes billets sur le 10 Hz (RS3) : https://roadsimulator3.fr/ et sur la pente/altitude : https://roadsimulator3.fr/service-robuste-pente-altitude-10hz/. Côté standardisation, voir Telemachus : https://github.com/telemachus3/telemachus-spec.

La donnée de mobilité n’est plus une promesse.

Les signaux existent (GNSS, IMU, événements). Les pipelines existent (correction, enrichissement, contextualisation). Et des efforts de standardisation existent.

Et pourtant, la valeur reste difficile à produire durablement.

Pourquoi ? Parce que le vrai problème commence au moment où la donnée sort de l’organisation qui l’a produite.

Ressources associées (internes) :

• RS3 — signaux 10 Hz & télématique (blog) : https://roadsimulator3.fr/
• RS3 — service robuste de pente/altitude 10 Hz : https://roadsimulator3.fr/service-robuste-pente-altitude-10hz/

Ressources associées (externes) :

• International Data Spaces Association (IDSA) : https://internationaldataspaces.org/
• Data Spaces Support Centre (DSSC) : https://dssc.eu/
• Telemachus Spec (interopérabilité mobilité) : https://github.com/telemachus3/telemachus-spec

1) La donnée de mobilité existe déjà (ce point est acquis)

Aujourd’hui, un véhicule (ou un smartphone) produit en continu :

• des positions GNSS,
• des vitesses et capteurs inertiels (IMU),
• des signaux dérivés (accélérations, yaw rate…),
• des événements (freinage, virage, stop, congestion),
• du contexte (route, pente, météo, densité urbaine…).

Ces données peuvent être :

• corrigées (qualité du GNSS, synchronisation),
• enrichies (pente, géométrie, carte),
• structurées (schémas, champs normalisés),
• qualifiées (métadonnées, qualité, provenance).

👉 Autrement dit : on sait transformer un signal brut en information exploitable.

Le sujet n’est donc plus “peut-on produire de la donnée ?” ni même “peut-on l’analyser ?”.

Le sujet devient : peut-on la partager correctement, dans la durée, entre acteurs différents ?

2) Le moment de rupture : quand la donnée circule

Data space mobilité : les questions qui deviennent non-négociables

La donnée de mobilité ne reste jamais longtemps “chez elle”. Elle circule, tôt ou tard, entre :

• flottes et donneurs d’ordre,
• opérateurs et territoires,
• assureurs et gestionnaires de risque,
• industriels, chercheurs, autorités.

C’est à ce moment-là que les questions deviennent difficiles :

• Qui garde la maîtrise de la donnée ?
• Qui décide des usages autorisés ?
• Que devient la responsabilité si la donnée est réutilisée, agrégée, ou “dérivée” ?
• Comment éviter la captation de valeur par un acteur central (plateforme, intégrateur, marketplace) ?
• Comment garantir la traçabilité (qui a eu quoi, quand, pour quel usage) ?

👉 Ce ne sont pas des questions “data engineering”. Ce sont des questions de gouvernance.

3) Pourquoi les modèles classiques montrent leurs limites

Quand on arrive à ce point, les réponses habituelles reviennent souvent :

• “On va exposer une API.”
• “On va créer une plateforme.”
• “On va passer par une marketplace.”

Ces approches peuvent fonctionner… jusqu’à un certain point.

• Une API permet d’accéder à une donnée, mais ne définit pas les règles d’usage.
• Une plateforme centralise, mais déplace le pouvoir (et souvent la valeur).
• Une marketplace facilite la transaction, mais ne garantit ni souveraineté ni traçabilité sur la durée.

En mobilité, où les acteurs sont multiples et les données sensibles (personnes, lieux, habitudes, risques), ces modèles atteignent rapidement leurs limites.

4) Ce que le Data Space apporte réellement (sans jargon)

Un Data Space n’est pas :

• une “plateforme de plus”,
• un produit clé en main,
• une technologie miracle.

Un Data Space est un cadre de partage de données gouverné, où :

• les données peuvent rester chez leurs producteurs,
• les règles d’accès et d’usage sont explicites,
• la traçabilité est native,
• la souveraineté est préservée,
• la valeur peut être partagée sans confiscation.

👉 Le Data Space ne remplace pas les briques techniques existantes. Il les encadre.

La question à laquelle il répond est simple :

Comment partager des données entre organisations sans perdre le contrôle ?

5) Pourquoi la mobilité est un cas d’école

La mobilité concentre pratiquement toutes les difficultés du partage de données :

• production distribuée (chaque véhicule est une source),
• valeur construite progressivement (du brut au contexte, puis aux indicateurs),
• usages multiples et parfois concurrents,
• forte dépendance territoriale,
• enjeux réglementaires, assurantiels, sociaux.

Si un cadre de partage gouverné fonctionne pour la mobilité, il devient transposable à de nombreux autres secteurs.

👉 La mobilité n’est pas un cas particulier : c’est un révélateur.

6) Conclusion : la suite logique

Après :

• la donnée brute,
• l’ingénierie des signaux,
• la structuration et la standardisation,

le prochain défi est clair :

organiser le partage de la donnée de mobilité dans la durée.

Le Data Space n’est pas une rupture. C’est la suite logique d’un travail déjà engagé sur la qualité, la structure et la gouvernance des données.

Limites et non-objectifs de ce billet

Dans une démarche volontairement rigoureuse, il est important de préciser ce que ce billet ne cherche pas à faire :

• il ne propose pas une implémentation technique complète d’un Data Space,
• il ne compare pas formellement les initiatives institutionnelles existantes,
• il ne définit pas un modèle économique ou contractuel,
• il ne prétend pas couvrir l’ensemble de la littérature académique sur les Data Spaces.

Son rôle est plus modeste — et plus fondamental : identifier le point de rupture conceptuel à partir duquel la donnée de mobilité cesse d’être un simple objet technique pour devenir un objet de gouvernance.

À suivre

Dans les prochains billets, je traiterai :

• les faux amis du Data Space (API, marketplace, DDS, data mesh…),
• une architecture cible Data Space appliquée à la mobilité (sans marque, sans produit),
• et les erreurs classiques à éviter quand on confond plateforme et gouvernance.