Lorsque vous achetez des bornes de recharge ou choisissez un logiciel de recharge aujourd’hui, trois versions de l’OCPP figurent sur les fiches techniques : 1.6J, 2.0.1 et 2.1. Elles partagent un nom et un objectif, mais ce n’est pas le même protocole, et leurs différences ont un impact sur la sécurité, les fonctionnalités et la facilité avec laquelle votre réseau pourra se développer.
Cet article compare concrètement l’OCPP 1.6J, 2.0.1 et 2.1. Il explique ce qui a changé d’une version à l’autre, comment exploiter un réseau mixte, comment planifier une migration et quelles exigences inscrire dans votre cahier des charges lorsque vous achetez des bornes dès maintenant.
- L’OCPP 1.6J reste la version la plus déployée et constitue une base fiable pour la supervision, l’autorisation et le pilotage à distance.
- L’OCPP 2.0.1 est une refonte : il n’est pas rétrocompatible avec la 1.6, mais il apporte une sécurité intégrée, un modèle de données (device model) et une meilleure gestion des transactions.
- L’OCPP 2.1 s’appuie sur la 2.0.1 et reste rétrocompatible avec elle ; il ajoute la recharge bidirectionnelle, le pilotage des DER, les tarifs locaux et la prise en charge des terminaux de paiement.
- Pour tout nouvel achat, privilégiez du matériel compatible 2.0.1 (ou 2.1) et TLS, ainsi qu’un CSMS capable de faire fonctionner toutes les versions en parallèle.
Brève histoire des trois versions
Toutes les versions de l’OCPP sont publiées par l’Open Charge Alliance (OCA). L’OCPP 1.6 est sorti en 2015 en deux variantes : 1.6S, qui utilise SOAP, et 1.6J, qui utilise JSON sur WebSocket. La variante SOAP n’est presque plus utilisée : en pratique,« OCPP 1.6 » désigne généralement la 1.6J.
L’OCPP 2.0 a suivi en 2018. Il contenait des erreurs corrigées dans l’OCPP 2.0.1, publié en 2020, et c’est cette édition 2.0.1 que l’industrie implémente. L’OCPP 2.0.1 a ensuite été adopté comme norme internationale IEC 63584 en 2024.
L’OCPP 2.1 a été publié par l’OCA en janvier 2025, puis par l’IEC sous la référence IEC 63584-210. Il s’agit d’une évolution de la 2.0.1 plutôt que d’une nouvelle conception.
OCPP 1.6J : la base éprouvée
L’OCPP 1.6J couvre tout ce dont un réseau de recharge classique a besoin au quotidien. Une borne s’annonce avec BootNotification, reste visible grâce au Heartbeat, signale l’état de ses connecteurs avec StatusNotification et enregistre les sessions avec StartTransaction, StopTransaction et MeterValues. Le CSMS peut envoyer des commandes comme RemoteStartTransaction, RemoteStopTransaction, Reset, UnlockConnector, ChangeAvailability et ChangeConfiguration.
La version 1.6 inclut aussi la recharge intelligente via des profils de charge (ChargePointMaxProfile, TxDefaultProfile et TxProfile), l’autorisation hors ligne avec une liste locale et un cache, les réservations et les mises à jour de firmware.
Ses principales faiblesses concernent la sécurité et la structure. Les profils de sécurité ont été ajoutés après coup via l’extension de sécurité de l’OCA, si bien que leur prise en charge varie selon les fabricants. La configuration est une simple liste de clés, et de nombreux fabricants ajoutent leurs propres clés ou utilisent DataTransfer pour des fonctions propriétaires, ce qui réduit l’interopérabilité.
OCPP 2.0.1 : une refonte pour la sécurité et le passage à l’échelle
L’OCPP 2.0.1 conserve le même principe de base, une connexion JSON sur WebSocket entre la borne et le CSMS, mais modifie de nombreux messages. Les changements les plus importants sont les suivants :
- TransactionEvent : un seul message, avec les types d’événement Started, Updated et Ended, remplace StartTransaction, StopTransaction et les MeterValues liées aux transactions. La gestion des sessions devient ainsi plus cohérente.
- Device model : la borne est décrite sous forme de composants et de variables. Le CSMS les lit et les écrit avec GetVariables et SetVariables au lieu de clés de configuration à plat.
- RequestStartTransaction et RequestStopTransaction : ces messages remplacent les commandes de démarrage et d’arrêt à distance de la 1.6.
- Sécurité intégrée : profils de sécurité, gestion des certificats et notifications d’événements de sécurité font partie de la spécification de base.
- Recharge intelligente améliorée et prise en charge d’ISO 15118 : la borne peut transmettre des informations issues du véhicule, ce qui permet des plannings de charge plus précis et le Plug & Charge.
- Messages d’affichage et diagnostic : le CSMS peut afficher des messages sur l’écran de la borne, et le signalement des erreurs est plus détaillé.
Les messages étant différents, une borne 2.0.1 ne peut pas dialoguer avec un CSMS qui ne comprend que la 1.6, et inversement.
OCPP 2.1 : de nouveaux usages énergétiques
L’OCPP 2.1 est rétrocompatible avec la 2.0.1. Un système qui implémente déjà la 2.0.1 a besoin d’extensions, pas d’une réécriture. Les nouvelles fonctions portent sur le rôle de la recharge dans le système énergétique au sens large et sur le paiement :
- La recharge bidirectionnelle (V2X), qui permet à un véhicule de restituer de l’énergie à un bâtiment ou au réseau.
- Le pilotage des ressources énergétiques distribuées (DER).
- Le calcul local des coûts et des tarifs sur la borne.
- La prise en charge des terminaux de paiement et du paiement ponctuel (ad hoc).
- L’échange de batteries et des améliorations pour ISO 15118-20.
Beaucoup de ces fonctions dépendent du matériel, des véhicules et de la réglementation locale. Pour la plupart des opérateurs, l’intérêt concret de la 2.1 aujourd’hui est d’être l’option la plus pérenne.
Tableau comparatif : OCPP 1.6J vs 2.0.1 vs 2.1
| Critère | OCPP 1.6J | OCPP 2.0.1 | OCPP 2.1 |
|---|---|---|---|
| Publication | 2015 | 2020 | 2025 |
| Transport | JSON sur WebSocket | JSON sur WebSocket | JSON sur WebSocket |
| Compatibilité | Non compatible avec la 2.x | Non compatible avec la 1.6 | Rétrocompatible avec la 2.0.1 |
| Transactions | StartTransaction / StopTransaction | TransactionEvent | TransactionEvent |
| Configuration | Clés de configuration à plat | Device model (composants et variables) | Device model |
| Sécurité | Ajoutée ultérieurement via l’extension de sécurité | Intégrée, avec événements de sécurité | Intégrée |
| Recharge intelligente | Profils de charge | Améliorée, avec données ISO 15118 | Encore étendue, y compris V2X et DER |
| Paiement et tarifs | Absents du cœur du protocole | Limités | Calcul local des coûts, terminaux de paiement |
| Déploiement sur le terrain | La plus déployée | En progression | Débuts |
Exploiter un parc de bornes mixte
La plupart des réseaux réels sont mixtes. Les bornes plus anciennes fonctionnent en 1.6J, les modèles récents sont livrés en 2.0.1, et certains fabricants proposent un firmware compatible avec les deux. C’est normal et cela ne pose pas de problème, à condition que votre CSMS gère correctement chaque version.
Pour un réseau mixte, vérifiez les points suivants :
- Le CSMS doit détecter la version lors du handshake WebSocket et afficher toutes les bornes dans un seul tableau de bord, avec les mêmes noms d’état et les mêmes rapports.
- Les données de session issues des transactions 1.6 et des événements de transaction 2.0.1 doivent alimenter le même historique de sessions et les mêmes rapports.
- Les commandes à distance doivent être traduites dans le bon message pour chaque version, par exemple l’arrêt à distance.
- Les journaux doivent afficher les messages bruts, afin de diagnostiquer les comportements propres à chaque version.
Üreticy a été conçu pour cette situation. Les bornes OCPP 1.6J, 2.0.1 et 2.1 se connectent au même tableau de bord, et les bornes 2.1 utilisent le socle de messages qu’elles partagent avec la 2.0.1. Pour l’opérateur, sessions, rapports et commandes à distance fonctionnent de la même façon quelle que soit la version. Plus de détails sur la page du logiciel OCPP Üreticy.
Conseils de migration
Inutile de remplacer des bornes 1.6J qui fonctionnent sous prétexte qu’une version plus récente existe. Voici une approche raisonnable :
- Inventoriez votre matériel. Listez chaque modèle de borne, sa version de firmware et la disponibilité éventuelle d’un firmware 2.0.1 chez le fabricant.
- Sécurisez l’existant. Lorsque vos bornes 1.6J prennent en charge l’extension de sécurité, passez-les d’une connexion
ws://en clair àwss://avec TLS. - Testez avant de migrer. Passez une borne par modèle en firmware 2.0.1, connectez-la et vérifiez le démarrage, l’autorisation, les sessions et les commandes à distance.
- Migrez par lots. Changez la version du protocole par site ou par modèle, en conservant les mêmes identifiants de borne pour garder l’historique.
- Achetez du matériel neuf en 2.0.1 ou 2.1. Laissez le réseau évoluer naturellement au fil des nouveaux sites.
Quoi exiger à l’achat de bornes aujourd’hui
Inscrivez ces exigences dans votre appel d’offres ou votre bon de commande :
- Prise en charge de l’OCPP 2.0.1 dès aujourd’hui et feuille de route annoncée pour la 2.1, ainsi que l’OCPP 1.6J pour la compatibilité avec les systèmes existants.
- Prise en charge de TLS (profil de sécurité 2 au minimum ; profil 3 si vous gérez des certificats).
- Certification OCA ou résultats documentés de tests d’interopérabilité.
- Mises à jour de firmware assurées par le fabricant pendant toute la durée de vie prévue du produit.
- Aucune dépendance au cloud du fabricant pour les fonctions de base.
Si vous n’avez pas encore choisi votre logiciel, notre check-list pour choisir un logiciel OCPP explique comment évaluer un CSMS au regard de ces points.
Questions fréquentes
L’OCPP 1.6J est-il obsolète ?
Non. L’OCPP 1.6J reste la version la plus déployée et gère très bien la supervision, l’autorisation, les sessions et les commandes à distance. Sa principale limite est la sécurité, qui dépend de la prise en charge de l’extension de sécurité par la borne. Il reste un choix solide pour le matériel existant.
Une borne OCPP 2.0.1 peut-elle se connecter à un serveur 1.6 ?
Non. Les deux versions utilisent des messages différents et ne sont pas rétrocompatibles. La borne et le CSMS doivent utiliser la même version. Certaines bornes prennent en charge les deux et permettent d’en choisir une dans leurs paramètres.
L’OCPP 2.1 est-il compatible avec l’OCPP 2.0.1 ?
Oui. L’OCPP 2.1 est rétrocompatible avec la 2.0.1 : une implémentation 2.0.1 peut donc être étendue pour prendre en charge la 2.1. Les messages de base restent les mêmes, et la 2.1 ajoute de nouvelles fonctions comme la recharge bidirectionnelle et les tarifs locaux.
Faut-il attendre du matériel OCPP 2.1 avant d’acheter des bornes ?
Généralement non. Les bornes compatibles 2.0.1 aujourd’hui sont un excellent choix, surtout si le fabricant prévoit un passage à la 2.1 par mise à jour de firmware. Attendre retarde vos revenus et votre retour d’expérience, alors qu’un CSMS flexible vous permet d’ajouter du matériel plus récent par la suite.
Quelle version un nouvel opérateur de recharge doit-il choisir ?
Choisissez du matériel compatible OCPP 2.0.1 et TLS, avec la 1.6J en solution de repli. Associez-le à un CSMS qui prend en charge toutes les versions actuelles. Vous gagnez ainsi en sécurité et en souplesse sans vous enfermer dans une génération de matériel.
Exploitez vos bornes 1.6J, 2.0.1 et 2.1 côte à côte dans un seul tableau de bord. Découvrez le logiciel OCPP Üreticy ou consultez la tarification par connecteur.