Comprendre le rôle d'un serveur OCPP dans une plateforme de recharge électrique : WebSocket, messages station, supervision, observabilité et fiabilité opérationnelle.
Publié le 2026-05-08 · Mis à jour le 2026-05-08 · Resonovia Mobility
Le rôle réel d'un serveur OCPP
Un serveur OCPP est la brique qui relie les bornes de recharge à une plateforme CPO. Il maintient les connexions WebSocket, reçoit les messages de la station, valide les payloads, transforme les événements terrain en états métier et expose ces informations aux outils d'exploitation.
La définition technique est simple. L'enjeu produit l'est beaucoup moins : lorsqu'un utilisateur arrive devant une borne, il ne juge pas le protocole, il juge la capacité du service à afficher un état fiable, accepter son moyen d'accès, lancer la session, mesurer l'énergie, terminer proprement la charge et produire une trace exploitable.
Dans un marché qui change d'échelle, cette différence devient décisive. Avere-France indique que la France comptait 192 008 points de recharge ouverts au public fin mars 2026, avec une disponibilité technique moyenne de 90 % et un taux d'accès immédiat de 96 %. Le même baromètre signale une consommation moyenne de 788 kWh par point de recharge sur le mois, en hausse de 62 % sur un an. Plus le réseau est utilisé, moins une architecture approximative pardonne.
Pourquoi le protocole ne suffit pas
OCPP définit des messages. Il ne garantit pas à lui seul une exploitation fiable. Entre la borne et l'utilisateur, il faut interpréter des états, corriger des incohérences, reprendre des connexions, corréler des commandes et expliquer les incidents.
Les messages les plus structurants sont :
BootNotification, qui annonce la borne et initialise sa relation avec la plateforme.Heartbeat, qui confirme que la station reste vivante.StatusNotification, qui décrit l'état d'un connecteur.Authorize, qui valide un badge, un token ou une autorisation distante.StartTransactionetStopTransaction, qui encadrent une session.MeterValues, qui transporte les relevés d'énergie.RemoteStartTransaction, qui permet de déclencher une charge à distance.DiagnosticsStatusNotification, qui aide à comprendre les problèmes terrain.
Ces messages doivent être reliés à des objets métier : station, connecteur, session, utilisateur, token, tarif, paiement, incident, intervention et export financier. Sans ce lien, le serveur OCPP devient une boîte de réception technique au lieu d'être un outil de pilotage.
Les chiffres montrent le vrai problème
L'observatoire Avere-France et AFIREV 2024 donne une lecture utile du terrain : 85,5 % des sessions de recharge analysées ont été réussies, 84 % des conducteurs disent avoir rencontré un défaut de charge au cours des six derniers mois, et 87 % ont déjà rencontré une borne hors service. Ces chiffres ne signifient pas que tout échoue. Ils montrent surtout que la recharge est un service d'exploitation, pas seulement un service logiciel.
Un serveur OCPP sérieux doit donc répondre à des questions très concrètes :
- la borne est-elle réellement connectée ou simplement connue de la base ?
- le connecteur est-il disponible, réservé, occupé, en erreur ou dans un état ambigu ?
- une commande distante a-t-elle été reçue, acceptée, refusée ou perdue ?
- la transaction OCPP correspond-elle bien à la session affichée dans l'application ?
- les valeurs compteur sont-elles cohérentes avec la facturation et le CDR ?
- l'incident vient-il de la station, du réseau, du firmware, du backend ou d'un partenaire ?
La valeur ne vient pas du fait de "supporter OCPP". Elle vient de la capacité à rendre ces réponses rapides, traçables et compréhensibles par les équipes produit, support et opérations.
Architecture recommandée
Un serveur OCPP robuste s'appuie généralement sur :
- une couche WebSocket dédiée, capable de gérer connexions longues, reconnexions, timeouts et identifiants de stations ;
- une validation stricte des messages, avec tolérance contrôlée pour les écarts firmware connus ;
- un journal protocolaire lisible, interrogeable par station, session, commande et période ;
- une base relationnelle pour l'état métier durable ;
- un bus d'événements pour diffuser les changements vers supervision, mobile, reporting et alerting ;
- des APIs produit pour l'application mobile, le backoffice et les outils de support ;
- des métriques sur disponibilité, latence, erreurs, commandes, sessions incomplètes et valeurs compteur ;
- des mécanismes de reprise pour éviter qu'une coupure réseau transforme une session en dette opérationnelle.
Cette architecture sépare trois niveaux qui sont trop souvent mélangés : le protocole OCPP, le domaine métier recharge et l'expérience utilisateur. C'est précisément cette séparation qui permet d'évoluer sans casser l'exploitation.
Ce qui distingue Resonovia
Resonovia ne traite pas OCPP comme un connecteur isolé. Nous le concevons comme une frontière critique entre infrastructure, produit et opérations.
Notre avantage vient de la combinaison de plusieurs compétences rarement réunies dans un même périmètre :
- architecture Java, Kotlin et Spring Boot pour des backends maintenables ;
- modélisation métier des stations, connecteurs, sessions, tarifs, CDR et incidents ;
- observabilité exploitable par des équipes non développeuses ;
- intégration mobile native, pour que les états affichés à l'utilisateur soient alignés avec le terrain ;
- compréhension OCPI et EMSP/CPO, pour éviter qu'OCPP devienne un silo technique ;
- culture d'exploitation, avec logs, rejeu, alertes et diagnostics pensés dès la conception.
La conséquence est simple : une solution serveur OCPP Resonovia ne se limite pas à accepter des WebSockets. Elle aide à réduire l'ambiguïté, accélérer le diagnostic et construire une plateforme capable de monter en charge.
Les erreurs courantes
Beaucoup de plateformes commencent par recevoir les messages, puis découvrent trop tard que les opérations exigent davantage.
Les erreurs les plus fréquentes sont :
- stocker les payloads sans créer une vraie chronologie métier ;
- afficher les derniers statuts sans distinguer état protocolaire et état produit ;
- traiter les commandes distantes comme des appels synchrones simples ;
- ignorer les différences de firmware entre modèles de bornes ;
- ne pas relier session, paiement, CDR et support ;
- ne pas donner aux équipes un moyen de comprendre pourquoi une charge a échoué.
Ces erreurs coûtent cher parce qu'elles se voient directement dans l'expérience utilisateur. Un réseau dense ne suffit pas si la disponibilité, la donnée et le support ne suivent pas.
FAQ
OCPP est-il uniquement un protocole de borne ?
Non. OCPP définit la communication entre borne et backend, mais la valeur vient de l'architecture qui transforme ces messages en états fiables, commandes maîtrisées, diagnostics et données exploitables.
Peut-on construire une plateforme CPO sans serveur OCPP interne ?
Oui, mais cela crée souvent une dépendance forte à une boîte noire. Pour certains produits, maîtriser cette brique améliore la traçabilité, la qualité de support et la capacité d'évolution.
Pourquoi l'observabilité OCPP est-elle si importante ?
Parce qu'un incident de recharge peut venir de plusieurs causes : réseau, firmware, token, commande, état backend, paiement ou partenaire. Sans traces corrélées, l'exploitation travaille trop lentement.