AFIR article 20 — télémétrie de recharge VE, une API à l'échelle européenne

Le règlement sur le déploiement d'une infrastructure pour carburants alternatifs (AFIR) — (UE) 2023/1804 — est l'un des textes européens les plus lourds de conséquences pour la mobilité depuis des années. Il impose une couverture minimale de bornes le long du RTE-T, encadre les modes de paiement et — crucial pour tout développeur travaillant sur logiciel orienté VE — oblige avec son article 20 chaque État membre à exposer la télémétrie en direct des bornes via son point d'accès national, en DATEX II.

Si vous construisez une appli de routage, un tableau de bord d'électrification de flotte, une plateforme de roaming/paiement ou un outil d'analytique de réseau de recharge, l'article 20 de l'AFIR est le règlement le plus utile jamais écrit pour vous. Le piège : chaque État membre l'implémente à son rythme, dans son profil, derrière son NAP. Voici la vue d'ensemble telle que nous la voyons depuis NAPSPAN, où nous agrégeons les données AFIR à l'échelle du continent dans une seule API.

Ce que l'article 20 exige réellement

Le texte impose aux opérateurs de bornes (CPOs) de mettre à disposition, gratuitement et au format machine via le NAP, les données statiques et dynamiques suivantes :

Statiques (en une fois, évolution lente) :

• Coordonnées géographiques de la station et de chaque borne
• Nombre de connecteurs par station
• Types de connecteurs (CCS, CHAdeMO, Type 2, Tesla, etc.)
• Puissance maximale (kW) par connecteur
• Identité et contact de l'opérateur
• Accessibilité (24/7 ? restreinte ?)
• Méthodes d'authentification et de paiement acceptées
• Tarif ad hoc — ce que paie réellement un utilisateur sans contrat

Dynamiques (temps réel) :

• État opérationnel (disponible, occupé, hors service, réservé)
• État par connecteur
• Horodatage de la dernière mise à jour

Le format doit être DATEX II. La cadence proche du temps réel. L'accès gratuit. Voilà pour le règlement. C'est dans la mise en œuvre que ça devient intéressant.

Le profil AFIR de Mobilithek (Allemagne)

L'Allemagne a démarré tôt. Le profil AFIR de recharge de Mobilithek est entré en service en août 2025 et embarque les CPOs depuis. Il roule sur le même broker Mobilithek que nous avons couvert dans notre guide mTLS — même authentification par certificat client, même motif d'URL https://mobilithek.info:8443/..., une Publikations-ID distincte par CPO.

Le profil utilise l'extension DATEX II EnergyInfrastructure. Un enregistrement typique ressemble à ceci :

<d2:payloadPublication
    xsi:type="ei:EnergyInfrastructureStatusPublication"
    xmlns:d2="http://datex2.eu/schema/3/common"
    xmlns:ei="http://datex2.eu/schema/3/energyInfrastructure">
  <ei:energyInfrastructureSiteStatus id="DE_CPO_NW_1234">
    <ei:refuelPointStatus id="CP1">
      <ei:status>available</ei:status>
      <ei:lastUpdated>2026-05-01T08:14:05Z</ei:lastUpdated>
    </ei:refuelPointStatus>
    <ei:refuelPointStatus id="CP2">
      <ei:status>occupied</ei:status>
      <ei:lastUpdated>2026-05-01T08:13:50Z</ei:lastUpdated>
    </ei:refuelPointStatus>
  </ei:energyInfrastructureSiteStatus>
</d2:payloadPublication>

Les données statiques arrivent dans une EnergyInfrastructureTablePublication séparée. On joint les deux sur energyInfrastructureSiteStatus.id — statique une fois par jour, statut toutes les 30 à 60 secondes.

Là où les États membres divergent

L'AFIR fixe le modèle de données. Chaque NAP choisit le reste :

Même en ignorant les écarts de profils DATEX II, on obtient au moins quatre flux d'authentification distincts et trois variantes de transport. Et ce n'est que pour les sept premiers États membres. Le détail des profils varie aussi : certains NAPs n'exposent que le statut dynamique ; d'autres seulement le catalogue statique ; le couple obligatoire AFIR statique-plus-dynamique se met en place de façon échelonnée sur 2026 et 2027.

Le modèle normalisé

Dans NAPSPAN, les données AFIR vivent dans notre table générique features avec feature_type = 'ev_charging'. Les champs spécifiques au type vont dans une colonne JSONB properties. Aucun nouveau schéma pour un nouveau pays — juste un nouvel adaptateur et un nouvel appel à Register().

{
  "id": "de_mobilithek_de_cpo_nw_1234",
  "type": "ev_charging",
  "country": "DE",
  "operator": "EnBW mobility+",
  "name": "EnBW HPC Köln-Nord",
  "latitude": 50.9851,
  "longitude": 6.9550,
  "properties": {
    "connectors": [
      {
        "id": "CP1",
        "standard": "CCS_COMBO_2",
        "max_power_kw": 300,
        "status": "available",
        "last_updated": "2026-05-01T08:14:05Z"
      },
      {
        "id": "CP2",
        "standard": "CCS_COMBO_2",
        "max_power_kw": 300,
        "status": "occupied",
        "last_updated": "2026-05-01T08:13:50Z"
      }
    ],
    "access_24_7": true,
    "payment_methods": ["contactless_card", "ad_hoc_qr", "roaming"],
    "ad_hoc_price_per_kwh_eur": 0.65
  }
}

Les standards de connecteur se normalisent dans un enum fixe (CCS_COMBO_2, CHADEMO, TYPE_2, TESLA, NACS, CCS_COMBO_1). Le statut se normalise sur cinq valeurs (available, occupied, reserved, out_of_service, unknown). La puissance en entier kW. Le JSONB properties conserve tout ce que le profil source apportait en plus, pour ne rien perdre.

Requêtes transfrontalières

Tout l'intérêt de la normalisation : un seul appel d'API donne le statut des bornes dans tous les États membres à la fois.

Bornes CCS disponibles sur le corridor Berlin–Amsterdam, ≥ 150 kW :

curl "https://api.napspan.com/api/v1/features/corridor?\
type=ev_charging&\
from_lat=52.52&from_lng=13.40&\
to_lat=52.37&to_lng=4.90&\
buffer_km=15&\
connector=CCS_COMBO_2&\
min_power_kw=150&\
status=available" \
  -H "X-API-Key: your_key"

Un appel. Deux NAPs (Mobilithek + NDW). Une seule structure de réponse. La requête de corridor utilise PostGIS — nous tamponnons le grand cercle de 15 km et intersectons avec chaque feature ev_charging dont les propriétés correspondent au filtre.

Requête par bounding box en GeoJSON, prête pour Leaflet :

curl "https://api.napspan.com/api/v1/features/geojson?\
type=ev_charging&\
bbox=2.0,49.5,7.5,51.5" \
  -H "X-API-Key: your_key"

Ce que cela débloque

Trois catégories de produits gagnent matériellement en qualité quand les données AFIR sont normalisées et requêtables à l'échelle du continent :

Routage VE et planification de trajet

Aujourd'hui, la plupart des moteurs de routage VE se rabattent sur des jeux de données communautaires (OpenChargeMap) ou des API par réseau. Ils manquent de disponibilité temps réel hors du périmètre de l'opérateur. Les données de statut adossées à AFIR corrigent les deux : c'est en direct et c'est continental. Les moteurs peuvent privilégier les bornes disponibles maintenant avec le bon connecteur.

Tableaux de bord d'électrification de flotte

Pour un logisticien à flotte mixte traversant les frontières, disposer d'une seule API pour la disponibilité, la puissance et le tarif des bornes par pays élimine la matrice d'intégrations par réseau. Combiné aux aires de stationnement PL SSTP (également via le NAP), on obtient une surface de planification intégrée recharge + repos.

Plateformes de roaming et d'agrégation

OCPI est le protocole de roaming dominant ; AFIR est la couche de divulgation réglementaire. Les deux se chevauchent mais ne sont pas identiques. Les données AFIR sont la référence canonique pour tout ce qu'un CPO doit divulguer ; OCPI transporte des métadonnées opérationnelles et commerciales entre partenaires de roaming. Les agrégateurs ont besoin des deux. NAPSPAN traite l'AFIR comme source de vérité pour la divulgation statique-plus-statut, et expose les références opérateur pour que les intégrations OCPI s'y branchent proprement.

Avertissements utiles

• La couverture est inégale. Les obligations AFIR s'étalent sur 2026/2027. Tous les CPOs ne publient pas encore ; tous les États membres n'ont pas finalisé leur profil. Attendez-vous à une montée en puissance dans l'année.
• Le tarif est le champ délicat. Le « tarif ad hoc » est obligatoire, mais les opérateurs le publient différemment — au kWh, à la minute, à la session, en paliers horaires. Nous exposons ce que la source publie ; nous ne synthétisons pas.
• La fraîcheur du statut varie. Certains CPOs poussent toutes les 30 sec ; d'autres toutes les 5 min. Nous transmettons le last_updated de la source par connecteur, le consommateur décide ce qui est trop ancien.
• OCPI reste pertinent. AFIR est de la divulgation réglementaire ; OCPI est de l'interconnexion opérationnelle. Si vous êtes un hub de roaming, OCPI reste indispensable — les données AFIR le complètent, ne le remplacent pas.

Essayez

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

• Carte en direct — activer la couche bornes de recharge
• Documentation API — référence complète des endpoints
• Portail développeur — s'inscrire et obtenir une clé API

Si vous construisez du routage VE, de l'électrification de flotte ou de l'analytique de réseau de recharge sur des données européennes, nous serions ravis de savoir quels pays et quels réseaux CPO comptent le plus pour vous. La couverture AFIR monte en charge sur les 18 prochains mois ; l'ordre d'intégration des CPOs dépend en partie de ceux qu'utilisent réellement nos clients.