OCPP 2.0.1 vs 1.6 : ce qui change vraiment pour les opérateurs IRVE

Résumé rapide

OCPP 2.0.1 n'est pas une mise à jour cosmétique : modèle de données restructuré, sécurité TLS mutuelle obligatoire en profil 3, configuration par variables et support natif de Plug & Charge via ISO 15118. Pour un opérateur IRVE, la migration est avant tout un projet d'architecture CSMS et de cycle de vie firmware, pas un simple changement de version dans une borne.

Contexte

OCPP 1.6 reste la version la plus déployée du parc IRVE européen. Elle est suffisante pour exploiter une station, lancer une transaction et facturer. Mais elle a été pensée à une époque où l'authentification se faisait uniquement par badge RFID et où les bornes étaient des objets relativement statiques.

OCPP 2.0.1, publié par l'Open Charge Alliance, redéfinit la relation entre la borne et le CSMS. L'objectif n'est plus seulement de faire passer une transaction, mais de permettre une supervision fine, sécurisée et interopérable avec les véhicules électriques eux-mêmes via ISO 15118.

Analyse

Trois changements structurent toute la version 2.0.1.

1. Modèle par variables et composants

Dans 1.6, la configuration repose sur une liste plate de clés/valeurs (ChangeConfiguration). Dans 2.0.1, chaque borne expose un modèle hiérarchique de composants (Connector, EVSE, ChargingStation, OCPPCommCtrlr) et chaque composant porte des variables typées et documentées.

Cela change la manière de superviser un parc :

• Le CSMS peut interroger précisément OCPPCommCtrlr.HeartbeatInterval ou EVSE[1].AvailabilityState.
• Les firmwares ne décident plus seuls du nom des paramètres.
• L'audit de configuration devient automatisable.

2. Sécurité TLS mutuelle (profil 3)

OCPP 2.0.1 définit trois profils de sécurité. Le profil 3 impose le TLS mutuel : la borne authentifie le CSMS avec un certificat, et le CSMS authentifie la borne avec un autre. Cela ferme la classe d'attaques où un attaquant pose un proxy entre la borne et le CSMS.

En pratique, cela impose une PKI : émission, renouvellement, révocation, stockage sécurisé de la clé privée dans la borne. C'est rarement un effort raisonnable au cas par cas, c'est un projet en soi.

3. Plug & Charge via ISO 15118

La version 2.0.1 intègre nativement les flux ISO 15118 nécessaires au Plug & Charge : Get15118EVCertificate, SignCertificate, AuthorizeRequest avec idToken enrichi. La borne devient un relais sécurisé entre le véhicule et son contrat de mobilité.

C'est le seul mécanisme normalisé qui supprime totalement le geste utilisateur (pas de badge, pas d'application). Pour un opérateur de flottes ou un site logistique, c'est un gain d'usage massif.

Impact marché et technique

Pour les CPO et les fabricants, la migration n'est pas un simple flag :

• Firmware : l'implémentation du modèle composants/variables impose un refactor profond du code embarqué. Beaucoup de bornes 1.6 n'auront jamais une vraie 2.0.1.
• CSMS : passer de "clé/valeur" à un modèle objet typé exige un nouveau schéma en base, de nouvelles APIs internes et une refonte des dashboards de supervision.
• Roaming : Hubject, GIREVE, e-clearing.net adaptent leurs ponts. Pendant la phase de transition, beaucoup d'acteurs maintiennent les deux protocoles côte à côte.
• AFIR : la régulation européenne pousse à l'interopérabilité, à l'authentification ad hoc et à la transparence des prix. OCPP 2.0.1 n'est pas obligatoire, mais il s'aligne mieux sur ces exigences que 1.6.

Une stratégie réaliste consiste à figer la flotte 1.6 existante, exiger 2.0.1 sur toute nouvelle commande de bornes et planifier la migration CSMS sur 18 à 24 mois.

Conclusion

OCPP 2.0.1 est moins une nouvelle version qu'un nouveau référentiel. Pour les opérateurs sérieux, le passage est inévitable parce qu'il aligne enfin la stack IRVE avec les standards de sécurité et d'interopérabilité attendus en 2026. La vraie question n'est plus "faut-il migrer" mais "quel parcours firmware et CSMS pour migrer sans casser l'exploitation".

FAQ