OCPP 1.6 ou 2.0.1 : que changer, que vérifier avant de migrer

Votre fournisseur de supervision propose « OCPP 2.0.1 », ou un constructeur vante une borne « compatible 2.0.1 ». Pour un exploitant, la question utile n’est pas quelle version est la plus récente, mais ce que chacune change dans l’exploitation du parc, et ce qu’un nom de version ne garantit pas. Les informations ci-dessous viennent des documents de l’Open Charge Alliance, consultés le 1er novembre 2026.

Ce que fait OCPP, et ce que sa version ne dit pas

OCPP organise le dialogue entre une borne et son système de gestion. Il ne décrit pas l’échange entre le véhicule et la borne. Sa version fixe un cadre de messages, pas la liste des fonctions qu’un produit propose. L’Open Charge Alliance précise elle-même que la 2.0.1 contient de nombreuses fonctions qui peuvent ne pas être nécessaires à chaque constructeur ou exploitant, et que la certification impose un jeu minimal de fonctions, complété par des profils supplémentaires comme la gestion de charge ou l’ISO 15118.

Conséquence directe : deux bornes affichant la même version peuvent ne pas faire la même chose. Un cahier des charges doit donc nommer les fonctions attendues, pas seulement le numéro de version.

Les deux versions ne sont pas interchangeables

Selon l’Open Charge Alliance, OCPP 1.6 et 2.0.1 ne sont pas compatibles, et la 2.0.1 n’est pas une évolution incrémentale de la 1.6 : elle partage certains concepts et messages, mais pas la totalité. La 1.6 existe en SOAP et en JSON sur WebSocket, la 2.0.1 en JSON sur WebSocket seulement. La version 2.1, publiée en 2025, repose sur la 2.0.1 et reste compatible avec elle.

En pratique, une borne et une supervision doivent parler la même version. Une supervision qui prend en charge les deux est possible, mais c’est une caractéristique de l’éditeur à faire confirmer, pas un acquis.

Ce que la 2.0.1 ajoute

• Un modèle de dispositif, qui décrit les composants de la borne, remonte les événements avec le composant concerné et permet une surveillance paramétrable. L’alliance souligne son intérêt pour les parcs mêlant plusieurs constructeurs.
• Un message de transaction unique, qui remplace les messages de début, de fin et de relevés de la 1.6, avec des conditions de début et d’arrêt configurables.
• Un comportement hors connexion mieux défini : numéros de transaction temporaires générés par la borne, numérotation des messages, liste d’autorisation locale.
• Trois profils de sécurité, la gestion des certificats côté borne, des mises à jour de micrologiciel signées et un journal d’événements de sécurité.
• La prise en charge de l’ISO 15118-2, dont la recharge sans badge par certificat. En 1.6, la recharge sans badge n’a été couverte que par une note d’application distincte.
• Des messages d’affichage, plusieurs langues et le suivi du coût en cours de charge.

La 1.6, de son côté, reste décrite par l’alliance comme largement mise en œuvre par les constructeurs et les éditeurs, et reste certifiable. La 2.0.1 est présentée comme en passe de la remplacer comme norme du secteur : c’est une tendance annoncée, pas une obligation.

Et la version 2.1 ? Publiée en 2025, elle s’appuie sur la 2.0.1 et ajoute notamment l’ISO 15118-20 avec transfert d’énergie bidirectionnel, la recharge bidirectionnelle (V2X), la gestion de ressources énergétiques décentralisées et la prise en charge de l’échange de batteries. Au moment de la consultation, la FAQ de l’alliance indique que les détails de certification restent à annoncer : un produit « 2.1 » n’a donc pas encore le même recul qu’un produit certifié en 1.6 ou en 2.0.1.

Questions à poser avant de choisir ou de migrer

1. Quelles fonctions précises sont mises en œuvre côté borne et côté supervision : gestion de charge, liste d’autorisation locale, mise à jour à distance, recharge sans badge ?
2. Le produit est-il certifié par l’Open Charge Alliance, pour quelle version et quels profils ? Le programme existe pour la 1.6 et la 2.0.1.
3. Le constructeur décrit-il par écrit un chemin de mise à jour de la borne, et la supervision gère-t-elle la version cible ?
4. Que deviennent les états, alertes et historiques utilisés par vos tableaux de bord ? Les transactions étant regroupées différemment, les indicateurs doivent être revalidés.
5. Qui porte la responsabilité du test sur site, et quel jeu d’essais prouve le retour à la normale ?

Conduire une migration sans perdre la lecture du parc

Procédez par un lot pilote, une borne ou un site, plutôt que sur l’ensemble du parc. Conservez avant le changement la chronologie des communications et les réglages connus, puis tracez chaque action avec son heure. Après le changement, distinguez trois constats : la borne communique, la supervision la voit, une charge réelle démarre et remonte son compte rendu. Ces trois constats ne sont pas équivalents. Passer en 2.0.1 ne rend pas non plus la communication plus sûre par automatisme : la sécurité dépend du profil retenu, des certificats et de la façon dont ils sont gérés. La logique est la même que pour une borne hors ligne, détaillée dans le guide sur la supervision.

Les réglages de la borne, les certificats et les accès relèvent de personnes habilitées et autorisées, avec la documentation du constructeur. N’ouvrez pas d’accès pour « essayer » et ne désactivez pas de vérification de sécurité pour accélérer un test.

Quand la communication casse après un changement

Après une migration ou une mise à jour, une borne peut apparaître hors ligne sans être hors service. Vérifiez d’abord l’étendue (une borne ou tout un lot) et l’heure de la dernière communication. La page /panne oriente selon le symptôme, et la page /depannage-borne-de-recharge présente le dépannage par ville, dont /belgique/depannage-borne-de-recharge/bruxelles pour la Belgique.