Cinq problèmes de données routières que rencontre toute flotte transfrontalière européenne

Si vous développez des logiciels de routage, de répartition ou de télématique pour le transport routier européen, ce n'est que rarement l'algorithme de routage qui freine la feuille de route. Ce sont les données routières. Un plan de tournée de Rotterdam à Bucarest traverse une douzaine de juridictions, et chacune publie ce qui se passe sur ses routes — incidents, péages, restrictions, recharge — à sa façon, selon son calendrier, sous ses propres règles. Voici les cinq problèmes qui reviennent dans presque toutes nos conversations avec les équipes logicielles européennes de flotte et de logistique. Aucun n'est exotique. Tous brûlent discrètement du temps d'ingénierie.

1. Vingt-sept pays, vingt-sept points d'accès

La directive STI de l'UE a bel et bien amené chaque État membre à mettre en place un point d'accès national (NAP) publiant des données routières, le plus souvent en DATEX II. Cela ressemble à un problème résolu — jusqu'à ce que vous vous connectiez réellement à un deuxième pays. La norme laisse de la marge, et les NAP l'utilisent pleinement : profils et versions DATEX différents, authentification différente, cadences de mise à jour différentes, idées différentes de ce que signifie un champ donné. Et bien des données utiles à l'exploitation ne voyagent jamais en DATEX II : elles vivent sur des portails open data municipaux ou dans des flux nationaux antérieurs à cette plomberie.

Une équipe qui veut une couverture continentale réelle finit donc par écrire et maintenir une intégration distincte par pays, puis à les surveiller toutes pendant que les flux changent silencieusement de forme. C'est le problème qui dévore le plus de temps, parce qu'il ne finit jamais. Nous avons décrit comment nous normalisons DATEX II sur les NAP européens et comment les sources non-DATEX s'intègrent au même schéma — en bref, le fouillis pays par pays devient un contrat events et features cohérent, et maintenir les adaptateurs en vie devient notre problème plutôt que le vôtre.

2. La facture de péage change à chaque frontière

Il n'existe pas de péage européen unique. Il y a des vignettes, des systèmes au kilomètre, des redevances poids lourds à l'essieu, des péages urbains de congestion, des péages de tunnels et de ponts — chaque pays avec son propre modèle, ses propres classes de véhicules et ses propres surcoûts par classe d'émission. Un itinéraire qui paraît le moins cher en distance peut être le plus coûteux une fois les péages comptés, et l'écart entre un 5 essieux Euro VI et un fourgon plus petit représente de l'argent réel sur chaque tronçon.

Pour un planificateur, une estimation qui ignore la classe de véhicule est une estimation fausse au moment de la facture. Pour une équipe logicielle, tarifer à la main un itinéraire transfrontalier signifie modéliser une douzaine de systèmes de péage nationaux et les tenir à jour à mesure que les tarifs changent. Nous avons rassemblé tout cela pour qu'un itinéraire revienne avec une ventilation des péages par pays tenant compte de la classe de véhicule — voir coûts de péage par classe de véhicule à travers l'Europe.

3. Là où le temps s'épuise — et s'il y a une place de stationnement

Les règles de temps de conduite du règlement UE 561/2006 et la pénurie chronique de stationnements poids lourds sécurisés sont en réalité un seul problème à deux visages. Savoir qu'un conducteur atteindra la limite de conduite journalière à 18 h 40 n'en est que la moitié. La moitié qui immobilise un camion — ou force un arrêt dangereux sur le bas-côté — c'est de savoir s'il existe un endroit légal et atteignable pour la pause lorsque le temps s'épuise, et cette réponse exige à la fois la projection du temps de conduite et des données de stationnement en direct sur le même corridor.

La plupart des équipes résolvent la première moitié et découvrent la seconde à l'aire de repos. Nous avons relié les deux : envoyez l'horloge du conducteur avec l'itinéraire et recevez chaque pause requise, chacune associée au stationnement atteignable avant l'échéance et à un indicateur feasible lorsqu'il n'y en a aucun. C'est le sujet de la planification des pauses au titre du règlement UE 561/2006.

4. L'interdiction que vous ignoriez jusqu'à la frontière

Le transport transfrontalier repose sur une mosaïque de restrictions nationales qu'aucune carte grand public ne connaît : interdictions de circuler le week-end et la nuit, interdictions sectorielles sur les corridors alpins, zones à faibles émissions au cœur des villes, limites de poids et de gabarit pays par pays, et restrictions saisonnières. Un plan légal dans un pays peut être illégal de l'autre côté de la ligne à la même heure — et la sanction, quand on l'apprend à la dure, est une amende, une attente forcée ou un chargement refusé.

Le besoin opérationnel n'est pas « une liste de chaque règle en Europe ». C'est « dis-moi les restrictions et les panneaux à message variable sur ce corridor, avant que le conducteur n'y arrive » — restrictions et signalisation issues des flux nationaux officiels, normalisées dans les mêmes features interrogeables que parle le reste de l'API, filtrables par pays et par cadre géographique. Un seul schéma pour une interdiction de nuit allemande et une interdiction sectorielle autrichienne, c'est vérifier un seul endroit au lieu de vingt-sept.

5. Recharger une flotte qui s'électrifie, par-delà les lacunes

À mesure que les flottes s'électrifient, « où ce véhicule peut-il réellement recharger sur le corridor » devient une donnée d'entrée du routage, pas un simple bonus. Le règlement AFIR de l'UE oblige désormais les opérateurs de points de recharge à publier l'état en direct par connecteur via les NAP — c'est la référence, et là où un pays le porte, nous le servons. Mais la couverture AFIR n'est aussi complète que le déploiement de chaque NAP, et plusieurs pays n'exposent pas encore de flux VE mature.

La réponse honnête tient donc en deux couches, signalées pour que vous puissiez les distinguer : l'état en direct là où AFIR le porte, et un registre de recharge sous licence ouverte — coordonnées, standards de connecteurs, puissances — là où il ne le porte pas. Chaque borne indique quelle garantie elle vous donne. Nous avons traité le volet temps réel dans la télémétrie de recharge VE de l'article 20 d'AFIR et le volet couverture dans intégrer l'open data dans une seule API européenne.

Le fil conducteur

Chacun de ces problèmes a la même forme : les données existent, mais elles sont fragmentées entre les autorités nationales, publiées dans des formats incompatibles, régies par des licences différentes, et utiles seulement une fois reliées à un itinéraire et tenues à jour. Chacun est soluble en interne — et chacun, résolu en interne, devient un engagement de maintenance permanent qui concurrence le produit que vous vendez réellement.

C'est toute la prémisse de NAPSPAN : faire cette agrégation une fois, pour tout le monde, et vous remettre une API normalisée — événements, features, péages, restrictions, recharge, routage avec dangers de corridor — au lieu de vingt-sept intégrations à maintenir en vie. Les données sont servies depuis l'Europe, chaque source est classée par licence avant sa mise en service, et vous consacrez votre temps d'ingénierie à la partie qui rend votre produit unique.

Essayer

• Documentation API — events, features, routage et les filtres ?country= / ?type= dans une seule référence
• Carte en direct — voir les données normalisées sur les NAP européens
• Clé API gratuite — sans carte, essai de 14 jours