Les choix techniques qui font la différence entre un serveur OCPP expérimental et une plateforme de recharge exploitable : état, commandes, logs, reprise et supervision.
Publié le 2026-05-08 · Mis à jour le 2026-05-08 · Resonovia Mobility
Le vrai test commence après la première connexion
Faire répondre une borne à un serveur OCPP est une étape. Exploiter un parc de bornes avec des utilisateurs, des partenaires, des paiements, des incidents et des équipes support en est une autre.
En production, le serveur OCPP devient le système nerveux de la plateforme CPO. Il doit recevoir les messages, mais aussi reconstituer ce qui s'est passé, distinguer un état technique d'un état produit, conserver les traces nécessaires et permettre aux équipes de décider vite.
La France comptait 192 008 points de recharge ouverts au public fin mars 2026 selon Avere-France. Ce volume rend la qualité logicielle plus visible : une mauvaise corrélation de session, une commande perdue ou un statut mal interprété peut toucher des milliers d'utilisateurs.
Les cinq blocs d'une architecture solide
Une architecture OCPP de production doit séparer cinq blocs.
Le premier bloc est la terminaison WebSocket. Elle gère les connexions longues, l'identité station, les timeouts, les reconnexions et la pression réseau. Elle doit rester simple et robuste.
Le deuxième bloc est la validation protocolaire. Chaque message doit être contrôlé, horodaté et relié à une station connue. La plateforme doit accepter les écarts prévus, mais jamais perdre la trace de ce qu'elle tolère.
Le troisième bloc est le domaine métier. Il transforme StatusNotification, StartTransaction, StopTransaction, MeterValues et les commandes distantes en objets exploitables : connecteur, disponibilité, session, énergie, incident, action support.
Le quatrième bloc est l'observabilité. Sans logs corrélés, métriques, traces de commandes et chronologie de session, l'exploitation devient lente. L'observabilité n'est pas un bonus, c'est une fonctionnalité produit.
Le cinquième bloc est l'intégration plateforme : APIs mobile, backoffice, reporting, notifications, OCPI, paiement et exports. OCPP ne doit pas être un silo.
Les décisions qui évitent la dette technique
Les architectures OCPP les plus robustes prennent quelques décisions fortes dès le départ :
- ne jamais confondre payload brut et état métier ;
- conserver une chronologie par station, connecteur, transaction et commande ;
- rendre les commandes distantes asynchrones et observables ;
- distinguer indisponibilité technique, occupation et absence d'accès immédiat ;
- prévoir les différences de firmware au lieu de les cacher dans des conditions dispersées ;
- relier session OCPP, session utilisateur, paiement et CDR ;
- donner au support une lecture claire avant de multiplier les alertes.
Ces décisions sont plus importantes qu'un choix de framework. Elles déterminent la capacité à tenir dans le temps.
Pourquoi les chiffres rendent cette discipline indispensable
Avere-France et AFIREV indiquent dans l'observatoire 2024 que 85,5 % des sessions analysées ont été réussies. C'est un progrès, mais cela signifie aussi que la qualité de parcours reste un sujet mesurable. Le même observatoire souligne que 84 % des conducteurs disent avoir rencontré un défaut de charge au cours des six derniers mois.
Ces chiffres ne condamnent pas la recharge publique. Ils montrent que le logiciel doit aider à réduire l'incertitude. Lorsqu'une session échoue, la plateforme doit expliquer pourquoi. Lorsqu'une borne est en erreur, elle doit remonter l'information correctement. Lorsqu'un utilisateur appelle le support, l'équipe doit voir la même histoire que la borne, l'app et le système de paiement.
L'approche Resonovia
Resonovia construit les serveurs OCPP comme des plateformes d'exploitation, pas comme de simples adaptateurs.
Notre approche repose sur :
- Java, Kotlin et Spring Boot pour porter une logique métier claire et testable ;
- une base SQL fiable, PostgreSQL par préférence lorsque le socle est à définir, pour conserver des états transactionnels cohérents ;
- des événements pour découpler supervision, mobile, reporting et notifications ;
- des logs protocole lisibles par station, session et commande ;
- des APIs produit pensées pour l'application mobile et le support ;
- une séparation stricte entre protocole OCPP, domaine CPO et expérience utilisateur.
Cette combinaison permet de construire une solution serveur OCPP plus résistante à la croissance du parc, aux différences de firmware et aux exigences d'exploitation.
Ce qu'il faut mesurer
Une plateforme CPO sérieuse doit suivre plus que le nombre de bornes connectées.
Les indicateurs utiles incluent :
- taux de disponibilité technique ;
- taux d'accès immédiat ;
- taux de sessions réussies ;
- commandes distantes acceptées, expirées ou refusées ;
- sessions sans
StopTransactionexploitable ; - temps moyen de diagnostic support ;
- bornes en erreur récurrente ;
- cohérence entre énergie OCPP, session utilisateur et CDR ;
- latence des messages et taux de reconnexion.
Ces indicateurs rapprochent le logiciel des enjeux métier. Ils permettent de prioriser les corrections qui améliorent réellement l'expérience.
FAQ
Faut-il développer son serveur OCPP ou utiliser une plateforme existante ?
Cela dépend du niveau de contrôle recherché. Une plateforme existante peut accélérer le démarrage. Un serveur maîtrisé apporte plus de traçabilité, de différenciation produit et de capacité d'intégration.
OCPP 1.6 suffit-il encore ?
Il reste très présent sur le terrain. L'enjeu est moins de choisir une version parfaite que de concevoir une architecture capable de gérer versions, écarts firmware et migration progressive.
Pourquoi Resonovia insiste autant sur les logs ?
Parce que les logs sont ce qui permet de transformer un incident utilisateur en diagnostic. Sans chronologie claire, chaque panne devient une enquête lente.