C omprendre le protocole OCPI est devenu indispensable pour tout responsable technique qui pilote un parc de bornes IRVE en entreprise. Derrière l’apparente simplicité d’un badge qui s’authentifie sur une borne étrangère se cache une architecture d’échanges de données sophistiquée, standardisée par le protocole OCPI et opérée par des hubs de roaming comme Gireve. En 2026, OCPI 2.2 s’est imposé comme le standard de facto du marché français, et sa maîtrise conditionne la capacité d’une entreprise à intégrer ses bornes dans l’écosystème national de la recharge ouverte.

Ce guide s’adresse aux DSI, responsables techniques et chefs de projet IRVE qui doivent choisir ou configurer un CSMS compatible OCPI pour leur parc de bornes. Nous décryptons les modules fonctionnels du protocole, les flux d’autorisation et de facturation, les différences entre OCPI 2.2 et la future version 3.0, et les critères d’évaluation d’un CSMS pour une intégration réussie dans l’écosystème de roaming français.

Origine et gouvernance du protocole OCPI

OCPI est né d’une initiative portée par les opérateurs de recharge néerlandais en 2014, dans le cadre du consortium EV Roaming Foundation. Face à la multiplication des solutions propriétaires incompatibles, plusieurs CPO et eMSP européens ont décidé de définir un protocole open source commun pour standardiser leurs échanges de données. La spécification est maintenue par la communauté sous licence libre et hébergée sur GitHub, ce qui permet à tout développeur ou opérateur de l’implémenter sans frais de licence. La gouvernance est assurée par un comité technique ouvert, avec des contributions de fabricants de bornes, d’opérateurs, d’agrégateurs et de hubs de roaming. Cette gouvernance ouverte est une force : le protocole évolue en réponse aux besoins réels du marché plutôt qu’aux intérêts d’un acteur dominant. En France, l’AVERE-France soutient l’adoption d’OCPI et l’a intégré dans ses recommandations pour les appels d’offres publics IRVE. La Commission Européenne, dans le cadre du règlement AFIR, recommande explicitement l’interopérabilité via des protocoles standards comme OCPI. Cette validation réglementaire accélère son adoption par les opérateurs qui devaient encore hésiter entre OCPI et des solutions propriétaires.

Architecture technique : comment OCPI s’intègre dans la chaîne IRVE

La chaîne technique d’une infrastructure IRVE interopérable comprend trois couches distinctes. La première couche est la borne physique, qui communique avec son CSMS via OCPP (généralement OCPP 1.6 JSON ou 2.0.1). La deuxième couche est le CSMS, qui gère la flotte de bornes et implémente OCPI pour dialoguer avec les acteurs externes. La troisième couche est l’écosystème eMSP/hub, qui agrège les données de plusieurs CPO pour offrir des services de roaming aux utilisateurs finaux. OCPI opère entre la deuxième et la troisième couche. Techniquement, OCPI est une API REST, ce qui signifie que les échanges sont des requêtes HTTP(S) avec des payloads JSON. Chaque module OCPI correspond à un ensemble de routes REST (endpoints) qui exposent ou consomment des ressources spécifiques. L’authentification entre plateformes se fait via des tokens API statiques (OCPI 2.2) ou OAuth 2.0 (prévu OCPI 3.0). La communication est initiée dans les deux sens : le CPO pousse les données de session et de disponibilité, l’eMSP pousse les tokens et les commandes. La topologie peut être directe (CPO-eMSP) ou indirecte via un hub (CPO-hub-eMSP), ce dernier modèle étant dominant pour les grandes flottes.

Les modules OCPI essentiels : fonctionnement détaillé

Le module Tokens gère les identifiants d’authentification. L’eMSP transmet au CPO la liste de ses tokens actifs (whitelist), qui peut être synchronisée périodiquement (pull) ou mise à jour en temps réel (push). Chaque token contient l’identifiant RFID, le type (badge, application), l’état (actif/inactif) et des métadonnées optionnelles. Le module Locations permet au CPO de publier en temps réel la liste de ses stations (adresse, coordonnées GPS, nombre de points de charge, connecteurs disponibles, tarif applicable). Ces données sont exploitées par les applications de navigation et de planification de recharge. Le module Sessions envoie les données de sessions en cours à l’eMSP (consommation instantanée, durée, état), permettant un suivi en temps réel. Le module CDR (Charge Detail Record) transfère l’enregistrement complet de chaque session terminée pour facturation. Le module Tariffs permet la publication et la mise à jour des grilles tarifaires, avec prise en charge des tarifs complexes (tranches horaires, prix au kWh et à la minute). Le module Commands permet à l’eMSP d’envoyer des commandes à la borne via le CPO : démarrage ou arrêt de session, déverrouillage du connecteur. Ces modules peuvent être implémentés progressivement selon les besoins.

Implémentation OCPI dans un CSMS : étapes et contraintes techniques

L’implémentation d’OCPI dans un CSMS suit un processus structuré. La première étape est la phase de design : définir quels modules implémenter (minimum Tokens, Sessions, CDR pour le roaming), choisir la version cible (2.2.1 recommandée en 2026), et identifier les partenaires de connexion (hub Gireve, eMSP directs). La deuxième étape est le développement : créer les endpoints REST, gérer l’authentification par token API, implémenter la logique de synchronisation des whitelists et la génération des CDR. La troisième étape est le testing : utiliser les environnements de test mis à disposition par Gireve (sandbox Gireve Connect) ou Hubject (Intercharge Network) pour valider les échanges avant mise en production. La quatrième étape est la certification : Gireve réalise un audit technique des implémentations avant toute connexion à son hub de production. Cet audit vérifie la conformité des payloads JSON, les délais de réponse, et la gestion des erreurs. La cinquième étape est la mise en production progressive, avec monitoring des erreurs OCPI et alertes en cas de délai de réponse anormal. Un point d’attention critique : les timezones. OCPI impose que toutes les dates soient en UTC, mais les bornes peuvent envoyer des heures locales. Une mauvaise gestion des conversions peut générer des CDR avec des horodatages erronés, source de litiges de facturation.

OCPI en pratique : cas d’usage pour les entreprises gestionnaires de bornes

Pour une entreprise qui gère son propre parc IRVE via un CSMS, OCPI ouvre plusieurs cas d’usage à haute valeur opérationnelle. Le premier est l’ouverture du parc aux visiteurs via roaming : en se connectant à Gireve comme CPO, l’entreprise permet à tout utilisateur d’un eMSP partenaire de recharger sur ses bornes, sans gestion manuelle de badges. Le CPO reçoit une rémunération par kWh délivré selon le tarif affiché. Le deuxième cas d’usage est la centralisation du reporting multi-réseaux : en implémentant OCPI côté eMSP interne, l’entreprise peut agréger les données de sessions issues de différents réseaux publics utilisés par ses conducteurs et les intégrer dans son outil de gestion de flotte. Le troisième cas d’usage est la tarification dynamique : le module Tariffs OCPI permet de publier des tarifs qui varient selon l’heure, le niveau de charge du réseau électrique ou la puissance souscrite, facilitant l’intégration avec les stratégies de smart charging. Le quatrième cas d’usage est l’audit automatique : les CDR OCPI constituent une source de données horodatées et signées permettant de reconstituer l’historique exact des sessions en cas de litige ou d’audit réglementaire.

Préparer sa migration vers OCPI 3.0 : les points de vigilance en 2026

OCPI 3.0 représente une évolution majeure du protocole, avec des changements structurels qui nécessitent une migration planifiée. Les entreprises qui déploient des bornes en 2026 doivent anticiper cette migration dès le choix du CSMS. Plusieurs points de vigilance sont à prendre en compte. Premièrement, le modèle d’authentification change : OAuth 2.0 remplace les tokens API statiques, ce qui implique une refonte de la couche de sécurité. Deuxièmement, le modèle de données évolue sur plusieurs entités (Location, Session, CDR), ce qui peut nécessiter des adaptations dans les systèmes de reporting aval. Troisièmement, le module de réservation est profondément remanié pour supporter la réservation garantie, fonctionnalité clé pour les flottes qui veulent planifier les recharges à l’avance. Quatrièmement, le support V2G (Vehicle-to-Grid) introduit de nouveaux types de sessions et de flux de données qui n’existaient pas en 2.2. En pratique, une coexistence OCPI 2.2 / 3.0 sera nécessaire pendant 2 à 3 ans, les deux versions devant être supportées simultanément. Choisir un CSMS avec une roadmap OCPI 3.0 publiée et un historique de mises à jour régulières est donc un critère de sélection essentiel pour tout déploiement prévu en 2026 ou après.

Passer a l action

Pour estimer precisement le cout total et la prime ADVENIR sur votre projet, utilisez le simulateur Loi LOM : calcul en 90 secondes, application automatique des baremes de l Arrete du 24 decembre 2025, breakdown reste a charge.

Pour comparer objectivement les 6 operateurs IRVE entreprise sur 27 criteres publics, utilisez le comparateur d operateurs : Driveco, ChargeGuru, ChargePoint, PowerDot, IZI by EDF, Beev.