← Retour à tous les articles
DATEX II Architecture UE

Comment nous normalisons DATEX II sur 30 points d'accès nationaux européens

1er mai 2026 · 11 min de lecture

La directive UE 2010/40/UE impose à chaque État membre de gérer un point d'accès national (NAP) publiant en temps réel des données de trafic, de sécurité et de mobilité multimodale au format DATEX II. Sur le papier : un standard, 27 publieurs, une intégration.

En pratique, chaque NAP livre un profil DATEX II différent, sur un transport différent, derrière une authentification différente, à une cadence différente. « Conforme à DATEX II » est une case que chaque État membre coche à sa façon.

C'est ce que nous avons rencontré en construisant NAPSPAN, une API unifiée sur l'UE 27 + UK + AELE. Voici l'architecture qui nous permet de traiter 30 flux DATEX II incompatibles comme s'ils n'en faisaient qu'un.

La spec, puis la réalité

DATEX II est un standard européen mature, maintenu par datex2.eu et coordonné par NAPCORE. Chaque règlement délégué le désigne comme format d'échange obligatoire :

La spécification est donc claire. La mise en œuvre l'est beaucoup moins.

Là où les NAPs divergent vraiment

« Conforme à DATEX II » cache au moins cinq axes de divergence :

1. Profil

Chaque État membre publie un profil national — un sous-ensemble contraint du modèle DATEX II. Le profil allemand (German Traffic Data Profile) définit les incidents, chantiers et flux sur Autobahn et Bundesstraßen. transport.data.gouv.fr en France utilise d'autres sous-éléments. Le NDW néerlandais publie une taxonomie d'événements plus serrée. Le NAP TDT britannique enveloppe DATEX dans des conteneurs propres au TIH. Le répertoire des profils DATEX II les liste tous — même schéma racine, forme différente par pays.

2. Version

DATEX II v2.3 et v3.x cohabitent dans la nature. Certains NAPs publient les deux. Certains sont en pleine migration. Les espaces de noms XML diffèrent. Quelques éléments ont été renommés entre versions.

3. Transport

DATEX II est un format de payload, pas un transport. Les NAPs le diffusent via :

4. Authentification

La matrice est large :

5. Cadence et fraîcheur

Certaines publications se rafraîchissent toutes les 30 secondes (flux d'autoroute). D'autres tous les soirs (calendriers de chantiers planifiés). Certaines sont derrière un CDN qui ment sur la fraîcheur via des en-têtes Last-Modified obsolètes. Le backoff adaptatif compte.

Le zoo des formats

Le résultat de ces cinq axes : le même incident — un accident sur autoroute, par exemple — arrive sous une forme totalement différente selon le NAP. L'un le livre en XML, l'autre en JSON-LD ; l'un en DATEX II v2.3, l'autre en v3.x ; chacun emballe la charge utile dans sa propre enveloppe et nous parvient via un transport différent, derrière une authentification différente. Même règlement, même standard — deux flux jamais identiques.

Le travail ne consiste donc pas à lire DATEX II une fois. Il consiste à lire 30 dialectes de DATEX II et à les faire concorder.

L'architecture

La solution est la même approche que côté nord-américain : chaque NAP est pris en charge par son propre adaptateur autonome, tous produisant la même sortie normalisée. Qu'un NAP soit récupéré en XML, interrogé en JSON-LD ou extrait d'un conteneur propre à un pays, l'adaptateur masque chacune de ces différences. Il prend une configuration de source (quel flux, quels identifiants, quel pays, quelle version de profil) et renvoie des événements et features normalisés.

Le scheduler ne sait ni ne se soucie de quel profil, version ou transport DATEX II chaque NAP utilise. Il demande à un adaptateur de récupérer les données et reçoit des événements et features normalisés — rien d'autre ne filtre.

Le modèle normalisé

Tout aboutit à un modèle cohérent, quelle que soit la provenance :

Événements — incidents bornés dans le temps (accidents, chantiers, fermetures, météo) avec gravité, localisation, routes affectées, horaires prévus vs réels et statut de cycle de vie. Les champs propres à chaque source que porte un NAP sont conservés aux côtés des champs normalisés — rien ne se perd à la traduction.

Features — tout le reste : caméras, panneaux VMS, stations météo, parkings, bornes de recharge, segments de route PL, hauteurs libres de ponts. Ils partagent tous une forme générique assortie d'un détail propre au type, si bien qu'ajouter un nouveau type de point d'intérêt est un changement de configuration, pas une migration de schéma.

Les parties difficiles

1. Mappage des champs de profil

Chaque profil national place la même information canonique — le nom de la route, la direction, la localisation — à un endroit différent, souvent imbriquée sur plusieurs niveaux et nommée autrement. Chaque adaptateur sait où son profil range chaque champ qui nous intéresse. Là où un profil ne porte tout simplement pas une donnée, le champ reste vide — nous ne synthétisons pas de données absentes.

2. Suivi du cycle de vie

Le même incident est republié à répétition à mesure qu'il évolue, et chaque NAP signale les mises à jour différemment — certains au moindre changement, d'autres seulement aux mises à jour substantielles. Nous suivons comment chaque enregistrement change au fil du temps, de sorte qu'une mise à jour soit reconnue comme le même événement qui mûrit, et non comme un nouveau. Cet historique est ce qui alimente les analytiques transfrontalières comme les percentiles de temps de dégagement et la fiabilité de corridor.

3. Systèmes de référence des coordonnées

La plupart des NAPs publient en WGS84 (EPSG:4326). Quelques flux d'États allemands publient en ETRS89 / zones UTM. Quelques flux urbains utilisent le système cadastral local. PostGIS gère la transformation, mais chaque adaptateur doit savoir ce qu'il reçoit.

4. Limitation de débit à grande échelle

30 NAPs, chacun avec plusieurs types de ressources (events, VMS, parkings, recharge, météo), polled toutes les 30 sec à 5 min. Le scheduler utilise des sémaphores par serveur avec des limites de concurrence et des intervalles minimum entre requêtes. Des disjoncteurs reculent en cas d'échecs répétés. Le backoff adaptatif augmente l'intervalle de poll quand un NAP est lent ou en erreur — sans cela, un seul NAP lent peut tirer la fraîcheur de toute une région vers le bas.

5. Un seul modèle pour chaque type de feature

Le modèle de feature générique paie à chaque fois qu'un nouveau type de données arrive. Quand les données AFIR de recharge sont arrivées côté UE, elles se sont insérées dans le même modèle que les caméras et les parkings sans remaniement structurel — simplement un type de feature de plus parmi les autres.

L'API

Une fois la normalisation faite, l'API est simple :

Incidents actifs en Allemagne :

curl "https://api.napspan.com/api/v1/events?country=DE&type=incident&status=active" \
  -H "X-API-Key: your_key"
{
  "data": [
    {
      "id": "de_mobilithek_4711",
      "country": "DE",
      "type": "incident",
      "severity": "major",
      "title": "Verkehrsunfall A7 Richtung Hamburg",
      "affected_roads": ["A7"],
      "direction": "Hamburg",
      "lanes_affected": "2 of 3 lanes closed",
      "latitude": 53.5511,
      "longitude": 9.9937,
      "start_time": "2026-05-01T08:15:00Z",
      "estimated_end_time": "2026-05-01T12:00:00Z"
    }
  ],
  "total": 142,
  "limit": 100,
  "offset": 0,
  "has_more": true
}

Caméras de trafic aux Pays-Bas en GeoJSON :

curl "https://api.napspan.com/api/v1/features/geojson?type=cameras&country=NL" \
  -H "X-API-Key: your_key"

La réponse s'injecte directement dans Leaflet, Mapbox ou tout outil compatible GeoJSON.

Requête de corridor transfrontalier (Berlin–Amsterdam) :

curl "https://api.napspan.com/api/v1/events/corridor?\
from_lat=52.52&from_lng=13.40&\
to_lat=52.37&to_lng=4.90&buffer_km=5" \
  -H "X-API-Key: your_key"

Un appel, deux NAPs (Mobilithek + NDW), une seule structure de réponse.

Ce que contiennent les données

Une fois normalisé, le jeu de données comprend :

Pile technique

Essayez

L'API est en ligne avec une formule gratuite (sans carte bancaire) :

Si vous construisez quoi que ce soit sur les données de mobilité européennes — logistique, routage de flotte, navigation, tableaux de bord urbains — nous serions ravis de savoir quels NAPs et quels profils DATEX II sont prioritaires pour vous. Le plus dur n'est pas le parsing ; c'est de savoir quel État membre publie quelles données sur quel transport derrière quelle authentification. Après 30 NAPs, nous avons une assez bonne carte de cela.

Prêt à essayer NAPSPAN ?

Essai gratuit de 14 jours. Sans carte bancaire. UE 27 + UK + AELE, normalisé.

Obtenir une clé API gratuite Explorer la carte