Changer de supervision CSMS sans perdre son parc de bornes

Une borne reste en service bien plus longtemps que le contrat de son logiciel de supervision. L'Open Charge Alliance (OCA) le constate dans son livre blanc Migrating Charging Stations publié en novembre 2025 : les exploitants changent de plateforme, certains opérateurs disparaissent, et des bornes en parfait état doivent être rattachées à un nouveau système central de gestion (CSMS). Ce guide reprend la méthode de l'OCA et la traduit en liste de contrôle pour un exploitant.

Trois situations, une même méthode

• Migration interne : l'exploitant adopte une nouvelle plateforme et y transfère ses propres bornes.
• Migration entre sociétés : un nouvel opérateur reprend les bornes de l'ancien dans son CSMS.
• Migration individuelle : un client change d'opérateur en gardant sa borne.

Dans les trois cas, l'OCA relève que des bornes et des CSMS certifiés OCPP simplifient nettement la migration. La certification d'un produit se vérifie sur le site de l'OCA. Si vos bornes ne sont pas certifiées, prévoyez plus de temps de test.

L'inventaire avant toute bascule

La migration ne touche pas que le logiciel : l'OCA liste des éléments physiques et numériques à transférer ou à reconfigurer. Pour chaque modèle de borne, relevez :

• La version OCPP et la version de firmware réellement installée, borne par borne : un même modèle peut tourner sous plusieurs versions.
• La méthode de reconfiguration possible : commande OCPP, mise à jour de firmware, script fourni par le fabricant ou intervention sur site.
• Les clés de configuration propres au fabricant : adresse du serveur, mot de passe, profil de sécurité.
• Les cartes SIM et l'APN : les SIM sont rattachées au compte de l'ancien opérateur, qui doit demander leur transfert. À défaut, il faut les remplacer sur place.
• Le terminal de paiement : contrat avec le prestataire de paiement et paramétrage (nouveau commerçant).
• Les QR codes, étiquettes NFC et la signalétique qui renvoient vers l'ancien opérateur.
• Les listes locales d'autorisation et, si l'opérateur a des contrats directs avec des conducteurs, leurs comptes.

Cet inventaire fixe aussi le volume de déplacements à prévoir : chaque borne qui ne se reconfigure pas à distance, ou dont la SIM ne se transfère pas, demande une visite.

Reconfigurer la connexion OCPP

En OCPP 1.6 : ChangeConfiguration et clés non standardisées

OCPP 1.6 ne prescrit pas comment la borne se connecte au serveur central. Quand le fabricant expose ces réglages en clés de configuration, le CSMS les modifie par ChangeConfiguration, et la borne répond Accepted, RebootRequired, NotSupported ou Rejected. Les noms de clés ne sont pas normalisés : l'OCA cite par exemple « OcppCsmsUrl » ou « CSMSURL » pour l'adresse, « BasicAuthPassword » ou « AuthorizationKey » pour le mot de passe, « SecurityProfile » pour le profil. La documentation du fabricant fait foi.

Si la connexion n'est pas configurable par clés, il faut passer par le fabricant (accès par un port propriétaire, paquet installé par UpdateFirmware) ou, à défaut, se rendre sur place. Point de vigilance relevé par l'OCA : une configuration envoyée en plusieurs messages et interrompue à mi-chemin peut laisser la borne incapable de joindre le moindre serveur.

En OCPP 2.0.1 : SetNetworkProfile et SetVariables

OCPP 2.0.1 décrit la migration dans ses cas d'usage B09 (nouveau profil de connexion) et B10 (migration vers un nouveau CSMS). La séquence décrite par l'OCA :

• Installer le certificat racine du nouveau CSMS (message InstallCertificate, type CSMSRootCertificate).
• Écrire le profil du nouveau serveur dans un second emplacement par SetNetworkProfile (adresse, profil de sécurité), l'ancien restant dans le premier.
• Si l'identifiant ou le mot de passe de connexion changent, les régler par SetVariables : en 2.0.1, ils ne font pas partie du profil réseau.
• Régler la variable OCPPCommCtrlr.NetworkConfigurationPriority sur « 2,1 » : la borne essaie le nouveau serveur, puis l'ancien en cas d'échec.
• Redémarrer la borne (Reset), accepter son BootNotification, demander l'inventaire complet par GetBaseReport (FullInventory), puis supprimer l'ancien profil une fois la bascule confirmée.

La spécification prévoit un garde-fou : si aucun profil ne fonctionne, la borne revient aux paramètres de sa dernière connexion réussie. C'est ce qui rend le retour arrière possible sans déplacement.

Certificats et profils de sécurité

L'extension de sécurité d'OCPP 1.6, décrite dans le livre blanc de sécurité OCPP 1.6, et OCPP 2.0.1 définissent trois profils :

L'OCA juge le profil 1 insuffisant en production, sauf réseau de confiance (VPN ou APN privé), car le mot de passe circule en clair. Trois règles pèsent sur une migration :

• La borne doit faire confiance au nouveau serveur : son certificat racine est installé avant la bascule. Si la variable AdditionalRootCertificateCheck est active, la borne n'accepte un nouveau certificat racine que s'il est signé par le certificat racine actuel.
• En profil 3, le nouveau CSMS doit accepter les certificats clients signés par l'ancien opérateur, le temps de faire générer et signer de nouveaux certificats (SignCertificate puis CertificateSigned).
• On ne redescend pas : l'abaissement n'est possible que du profil 3 vers le profil 2, si la clé AllowSecurityProfileDowngrade existe et vaut true, et jamais vers le profil 1 par OCPP. Le nouveau CSMS doit donc accepter au moins le profil en place.

Cas délicat : sans coopération de l'ancien opérateur, l'OCA décrit le recours à un accès de maintenance du fabricant, qui impose de repartir provisoirement en profil 1 avant d'installer le certificat racine et de remonter en profil 2. Cette fenêtre d'exposition doit rester la plus courte possible. Le Security Operations Guide de l'OCA détaille ces règles d'abaissement.

Plan de bascule et tests

L'OCA recommande de tester chaque modèle avant la bascule, puis de migrer par lots contrôlés plutôt que tout le parc d'un coup :

• Lot pilote : un exemplaire de chaque couple modèle et firmware, sur site réel.
• Pour chaque lot : transfert ou remplacement des SIM avec test de connexion, reconfiguration réseau, autres paramètres utiles au nouveau réseau, liste locale d'autorisation, QR codes et signalétique.
• Recette borne par borne : BootNotification accepté, Heartbeat régulier, StatusNotification cohérents, démarrage et arrêt d'une session, commande à distance, paiement, autorisation d'un badge en itinérance.
• Critère d'arrêt défini avant chaque lot, avec retour vers l'ancien serveur tant que son profil n'est pas supprimé.
• Écarts d'interprétation d'OCPP : soit le fabricant corrige le firmware, soit le nouveau CSMS s'adapte, selon les ressources disponibles.

Gardez l'ancien CSMS actif pendant toute la durée des lots : c'est la seule voie de repli à distance. Si la migration s'accompagne d'un changement de version OCPP, la spécification 2.0.1 recommande d'installer un profil de connexion de repli avec la nouvelle configuration.

Ce qui se perd : historique et identifiants

La borne ne garde presque rien : sessions, alarmes et interventions sont stockées dans l'ancien CSMS. Sans coopération de l'ancien opérateur, l'OCA prévient qu'il ne sera pas possible de migrer les données et qu'il faudra ressaisir chaque borne. Concrètement :

• Exportez avant la fin du contrat l'historique des statuts, des sessions et des interventions. Sans lui, vos indicateurs de maintenance repartent de zéro.
• Les listes locales d'autorisation se copient par un mécanisme propre à chaque CSMS.
• Pour l'itinérance, l'identifiant externe des points de charge (EVSEID) change avec l'opérateur. Les accords et interfaces d'itinérance, par exemple en OCPI, sont à activer chez le nouvel opérateur. Voir notre article sur l'interopérabilité et l'itinérance.
• L'article 20 du règlement AFIR prévoit des codes d'identification délivrés par une organisation désignée dans chaque État membre, au moins pour les exploitants de points de recharge, et impose de publier données statiques et dynamiques. En France, les articles R353-4-4 et R353-4-5 du code de l'énergie imposent de publier ces données sur transport.data.gouv.fr (voir notre article sur la publication des données) : elles sont à mettre à jour avec le nouvel opérateur.

L'OCA recommande d'anticiper dès la signature : clause de coopération obligatoire de l'opérateur en cas de migration, contrats de support de longue durée avec le fabricant, et dépôt sous séquestre (escrow) du firmware et des informations de configuration réseau.

Ce que JCSM prend en charge

JCSM assure la supervision à distance OCPP et la maintenance de parcs multi-marques. Lors d'un changement de CSMS ou d'opérateur, nous faisons l'inventaire technique des bornes, testons chaque modèle sur le nouveau système, intervenons sur site pour celles qui ne se reconfigurent pas à distance et vérifions chaque borne après la bascule. Voir la page supervision et exploitation.

Questions fréquentes