OCPI et itinérance : ce que l'exploitant doit vérifier

OCPP et OCPI : deux interfaces, deux rôles

OCPP relie la borne à son système central de supervision. OCPI relie ce système central aux partenaires commerciaux de l'exploitant : opérateurs de mobilité qui délivrent badges et applications, plateformes d'itinérance, services de navigation. La spécification le montre bien : quand un opérateur de mobilité demande un démarrage à distance, l'exploitant reçoit la commande en OCPI puis la transmet à la borne par un autre protocole, par exemple OCPP (module Commands d'OCPI 2.2.1).

OCPI est un protocole libre, maintenu par l'EVRoaming Foundation. Il fonctionne en liaison bilatérale ou à travers une plateforme d'itinérance. Côté borne, voir notre article sur OCPP 1.6 et 2.0.1 ; pour les rôles d'opérateur de recharge et d'opérateur de mobilité, voir CPO et EMSP.

En France, l'itinérance n'est pas une option pour une infrastructure ouverte au public et supervisée. L'article R353-4-3 du code de l'énergie impose à l'aménageur de garantir l'accès à la recharge en itinérance, et au paiement associé, à tout opérateur de mobilité qui le demande. L'obligation peut être satisfaite par une connexion à une plateforme d'interopérabilité. Une exception vise l'aménageur d'une seule station, d'une puissance maximale de 36 kVA au plus, de cinq points de recharge au plus et non intégrée à un réseau. Le manquement est passible d'une amende administrative de 300 euros au plus par point de recharge.

OCPI 2.2.1 : les modules à connaître

Selon la présentation des versions de l'EVRoaming Foundation, la version 2.2.1 a été publiée en octobre 2021 et sa documentation mise à jour en septembre 2023. La fondation indique que la version courante est désormais la 2.3.0 et que la 2.1.1 n'est plus maintenue. La 2.2 avait ajouté le support des plateformes d'itinérance (hubs) et les profils de recharge. Le dépôt officiel ocpi sur GitHub publie le texte de la 2.2.1.

L'EVRoaming Foundation considère qu'un exploitant n'a réellement implémenté OCPI que s'il couvre au minimum Versions, Credentials, Locations, Sessions, CDRs, Tariffs et Tokens. Commands est optionnel mais fortement recommandé dès qu'une application permet un démarrage à distance (même présentation).

Locations, EVSE et Connector

OCPI connaît trois niveaux : le site (Location), le point de recharge (EVSE) et le connecteur. La spécification recommande de regrouper sous une seule Location les bornes d'un même site : le conducteur cherche un nombre de points libres, pas un nombre de bornes. Trois règles du module Locations pèsent sur l'exploitation :

• un EVSE ne se supprime jamais : on le passe au statut REMOVED, car les sessions passées y font référence ;
• le champ uid est l'identifiant technique, qui ne change jamais ; l'evse_id est l'identifiant lisible, au format eMI3 ;
• en OCPP 1.x, une borne qui a plusieurs connecteurs sur un même EVSE est publiée avec un EVSE virtuel par connecteur ; quand l'un devient indisponible, tous les EVSE virtuels du point physique passent indisponibles.

La même spécification interdit de publier en OCPI une Location privée, qui n'est pas destinée à la recharge publique.

Identifiants : EVSE ID et code opérateur

Chaque objet OCPI porte le code pays (ISO 3166 alpha-2) et le party_id, code à trois caractères de l'opérateur. L'EVSE ID suit le format décrit par le document IDRR sur le format des identifiants : deux lettres de pays, trois caractères alphanumériques d'opérateur, la lettre E, puis jusqu'à trente caractères alphanumériques choisis par l'exploitant. Le séparateur * est facultatif ; le document déconseille de l'utiliser entre systèmes informatiques.

Les cinq premiers caractères sont délivrés par un organisme d'enregistrement (IDRO), que l'article 20 du règlement (UE) 2023/1804 demande à chaque État membre de désigner. Les règles générales des IDRO précisent qu'un code n'est valable que s'il est publié sur le site de l'organisme, qu'il ne peut être ni vendu ni cédé, et qu'une société à la fois opérateur de recharge et opérateur de mobilité a besoin de deux codes. En France, le schéma IRVE statique du point d'accès national demande pour id_pdc_itinerance un identifiant commençant par FR, suivi des trois caractères délivrés par l'AFIREV, puis de la lettre E, sans séparateur.

À contrôler : le même EVSE ID dans la supervision, sur l'étiquette de la borne, dans le flux OCPI et dans le fichier publié sur transport.data.gouv.fr. Un écart, c'est une borne introuvable ou une session rattachée à rien.

Statuts OCPP et statuts OCPI publiés

Le statut publié en OCPI est celui que voient les applications des opérateurs de mobilité. Il doit découler des statuts que la borne remonte en OCPP par StatusNotification (spécifications OCPP de l'Open Charge Alliance). La spécification OCPI ne fixe pas de table de correspondance : la table ci-dessous est une correspondance d'usage, à valider avec votre éditeur de supervision.

Deux erreurs reviennent souvent : une borne déconnectée qui reste AVAILABLE parce que son dernier statut n'est jamais remis en cause, et une borne en maintenance publiée OUTOFORDER au lieu d'INOPERATIVE. Les mêmes statuts alimentent le fichier dynamique publié au point d'accès national et le calcul de disponibilité : une seule source pour les trois, comme le détaille notre article sur la publication des données des bornes.

Tarifs et CDR : les erreurs à surveiller

Tarifs

Le module Tariffs appartient à l'exploitant, qui pousse chaque tarif aux opérateurs de mobilité. Points à surveiller :

• les dates de début et de fin de validité sont exprimées en UTC, le fuseau de la Location servant à la conversion : une erreur de fuseau décale un tarif heures creuses ;
• quand plusieurs éléments tarifaires couvrent la même dimension (énergie, temps, stationnement, forfait), c'est le premier élément dont les restrictions correspondent qui s'applique : l'ordre compte ;
• la spécification ne fixe aucune règle d'arrondi, laissée à la loi et aux contrats : écrivez-la dans l'accord avec chaque partenaire ;
• un connecteur doit pointer vers des tarifs effectivement transmis ; une recharge gratuite se décrit par un tarif explicite à prix nul, pas par l'absence de tarif.

L'article 5 du règlement AFIR interdit en outre toute discrimination, à travers les prix, entre utilisateurs finals et opérateurs de mobilité, sauf différenciation proportionnée et objectivement justifiée. L'EVRoaming Foundation publie aussi des lignes directrices de simplification des tarifs, avec un outil de test, pour réduire les erreurs d'implémentation de ce module.

CDR

Le CDR est le seul objet OCPI qui sert à la facturation (module CDRs). Une fois envoyé, il ne se modifie plus : pour corriger, l'exploitant envoie un CDR de crédit (champ credit à true, référence au CDR d'origine, montants négatifs), puis un nouveau CDR. Renvoyer un CDR corrigé sous le même identifiant est l'erreur classique. Les autres causes de rejet à suivre :

• un CDR qui cite un site ou un EVSE inconnu du partenaire, souvent après un renommage ;
• un jeton inconnu de l'opérateur de mobilité, ou une référence d'autorisation différente de celle qu'il avait donnée ;
• un coût total que le partenaire ne peut pas recalculer, faute de détail par période de recharge ;
• des CDR manqués pendant une coupure de la liaison, à récupérer par une requête GET de rattrapage.

Côté autorisation, le module Tokens fixe le mode de chaque badge : liste blanche, autorisation en temps réel, ou temps réel avec repli hors ligne. Une liste de badges périmée produit des refus que la borne ne signale pas comme une panne. Le livre blanc de l'Open Charge Alliance sur la disponibilité recommande de surveiller la santé des interfaces d'itinérance et de les vérifier dès que les refus d'autorisation se multiplient. La méthode de tri est dans notre article sur les sessions de recharge échouées.

Pair à pair ou plateforme d'itinérance

OCPI permet de se connecter directement à chaque opérateur de mobilité, ou de passer par une plateforme qui relaie les échanges. L'EVRoaming Foundation cite GIREVE et e-clearing.net parmi les plateformes qui utilisent OCPI, souvent en complément de liaisons directes. Le module HubClientInfo informe chaque partie de l'état de connexion des autres membres de la plateforme.

Quelle que soit l'option, quatre questions : quelle version d'OCPI est supportée de bout en bout ; quels modules sont réellement implémentés ; qui surveille la liaison et qui est prévenu en cas de rejet ; comment les écarts de CDR sont réconciliés.

Ce que JCSM prend en charge

JCSM n'édite pas de plateforme d'itinérance. Nous intervenons sur ce que l'itinérance révèle : supervision OCPP du parc, cohérence entre statuts remontés et statuts publiés, diagnostic des sessions refusées, et intervention sur la borne quand le défaut est matériel. Le détail est sur la page exploitation et supervision.

Questions fréquentes