Il n'y a rien de plus démoralisant que de voir votre tableau de bord afficher un état de santé du réseau à 100 % alors que votre service client est submergé d'appels de conducteurs en panne. Vous avez payé pour un avenir « prêt à l'emploi », et pourtant, vous vous retrouvez à déboguer des journaux JSON à minuit.

On vous avait promis que la norme OCPP résoudrait ce problème. Mais les problèmes d'interopérabilité des normes de recharge des véhicules électriques sont rarement résolus par un simple autocollant «Nous sommes conformes ! ».

Ce guide va au-delà des brochures marketing pour dévoiler les aspects techniques liés au déploiement d'une plateforme OCPP :‍

• Lemythe de la conformité : pourquoi le matériel « certifié OCPP » ne parvient toujours pas à communiquer avec les logiciels « conformes à l'OCPP ».
• Le dilemme des dialectes: comment de subtiles variations dans les messages JSON provoquent des pannes réseau silencieuses.‍
• Le piège des versions : pourquoi passer à OCPP 2.0.1 pourrait en réalité ramener votre réseau de recharge pour véhicules électriques au « plus petit dénominateur commun ».‍
• Les traces de la bataille: études de cas concrets sur les sessions fantômes, les fusibles grillés et le redoutable « brick » du micrologiciel.‍
• L'audit des marchés publics: les quatre questions « d'alerte » à poser aux fournisseurs avant de signer un contrat de cinq ans.

1. Comment fonctionne réellement l'OCPP (et pourquoi il tombe en panne)

Pour comprendre l'échec, il faut d'abord comprendre l'outil. Qu'est-ce que l'OCPP ?

Le protocole Open Charge Point est le langage standard mondial qui permet aux chargeurs de véhicules électriques (matériel) de communiquer avec le système de gestion d'une station de recharge (logiciel). Il a été conçu par l'Open Charge Alliance afin de garantir l'interopérabilité, ce qui vous évite d'être lié à un seul fabricant de matériel.

Mais voici le hic : l'OCPP n'est pas un port USB universel ; c'est un langage qui comporte plusieurs dialectes.

« Compatible OCPP » signifie simplement que votre chargeur et votre logiciel parlent la même langue. Cela ne garantit pas pour autant qu’ils se comprennent. C’est un peu comme un Texan et un habitant de Glasgow : ils parlent tous les deux anglais, mais bonne chance pour les faire se comprendre.

Lorsque votre nouveau matériel coûteux utilise le « dialecte A » de l'OCPP 1.6 et que votre CPMS attend le « dialecte B », votre réseau ne tombe pas simplement en panne : il tombe en panne sans donner aucun signe.

Les aspects techniques de l'OCPP

Sur le plan technique, les implémentations modernes des serveurs OCPP (notamment les versions OCPP 1.6J et 2.0.1) communiquent via WebSockets. Cela permet d'établir une connexion bidirectionnelle permanente entre le chargeur et le cloud. La communication se déroule en trois étapes principales :

1. La connexion: le chargeur compatible OCPP se connecte à l'URL du serveur.
2. Le signal de vie: le chargeur envoie une impulsion toutes les X secondes pour signaler qu'il est en état de marche.
3. La transaction: le chargeur envoie des données concernant le début, la fin et les valeurs du compteur d'une session.

Maintenant que nous disposons de ces connaissances pratiques sur la mise en œuvre du protocole OCPP, voyons comment les différents dialectes posent des défis concrets pour les logiciels des bornes de recharge OCPP.

‍

‍

2. Le dilemme du « dialecte »

Le plus grand mythe concernant les exigences de conformité OCPP pour les bornes de recharge de véhicules électriques est que cette norme serait rigide. Ce n'est pas le cas. La spécification OCPP est « souple ».

Si le protocole définit la structure d'un message, il laisse une marge d'interprétation quant au moment et à la raison de son envoi.

• Le fabricant A peut envoyer une notification d'état dès la connexion.
• Le fabricant B pourrait attendre que l'autorisation soit accordée.

Techniquement, les deux sont « conformes ». Mais si le système d'administration de votre station de recharge s'attend à ce que la notification de la première étape déclenche un changement d'interface utilisateur dans votre application, les chargeurs du fabricant B donneront l'impression de ne pas fonctionner correctement à vos clients.

Vous n'achetez pas seulement un logiciel ; vous achetez souvent un projet d'intégration coûteux destiné à traduire ces « langages » matériels.

Le manque de conformité à l'OCPP est d'autant plus flagrant lorsqu'on examine les différentes versions de l'OCPP actuellement prises en charge par les fournisseurs.

3. La guerre des versions : OCPP 1.6 contre 2.0.1

Si l'on en croit l'actualité de l'OCPP aujourd'hui, le secteur est obsédé par la transition vers la version 2.0.1. Mais pour un opérateur de bornes de recharge (CPO), cette transition s'apparente à un véritable champ de mines. Pour comprendre où cette transition achoppe, examinons de plus près les différences concrètes entre les versions 1.6 et 2.0.1 de l'OCPP.

Qu'est-ce que l'OCPP 1.6 ?

L'OCPP 1.6 (JSON) est aujourd'hui la norme de référence du secteur. Il bénéficie d'une large prise en charge, a fait ses preuves sur le terrain et est stable. Et ce, pour de bonnes raisons. Ce protocole gère de manière fiable et à grande échelle les aspects fondamentaux de la gestion de la recharge des véhicules électriques.

Cela dit, il a été conçu pour une époque où les infrastructures de recharge étaient plus rudimentaires.

Dans sa version standard, OCPP 1.6 ne dispose pas de fonctionnalités de sécurité natives, ce qui nécessite généralement l'utilisation de VPN ou de couches TLS supplémentaires pour répondre aux normes réseau actuelles. Il offre également une prise en charge limitée des structures tarifaires complexes, un aspect qui revêt une importance croissante à mesure que les modèles de tarification gagnent en sophistication.

Qu'en est-il de la norme ISO 15118 « Plug & Charge » ?

La fonctionnalité « Plug & Charge » ne fait pas partie de la spécification de base de l'OCPP 1.6, mais elle est déjà disponible aujourd'hui. L'Open Charge Alliance a publié une note d'application officielle détaillant comment la mettre en œuvre via le mécanisme DataTransfer intégré au protocole, ce qui signifie que les opérateurs n'ont pas besoin d'attendre une mise à niveau complète de la plateforme pour bénéficier de cette fonctionnalité.

Qu'est-ce que l'OCPP 2.0.1 ?

La version OCPP 2.0.1 incarne la nouvelle génération de la norme : elle intègre la prise en charge native du protocole TLS et de la gestion des certificats, des fonctionnalités de diagnostic à distance et de gestion des appareils considérablement améliorées, ainsi qu’une prise en charge complète de la norme ISO 15118 Plug & Charge au cœur même de la spécification, y compris des capacités de recharge intelligente qui vont bien au-delà de ce que permet la solution de contournement DataTransfer.

Le piège de la « fragmentation des versions »

Le nombre de recherches concernant l'actualité de l'OCPP 2.0.1 est en forte hausse, et cela se comprend ! Tout le monde veut la version qui offre davantage de fonctionnalités. Mais avant de vous lancer à la recherche de ces fonctionnalités, soyez vigilant. Il existe un piège qu'il convient de connaître : toutes les plateformes « compatibles 2.0.1 » ne se valent pas.

De nombreux fournisseurs de systèmes de gestion des bornes de recharge (CPMS) affirment prendre en charge ces deux versions. Dans la pratique, ils exploitent souvent une pile 1.6 stable parallèlement à une implémentation 2.0.1 encore immature.

Lorsque des chargeurs 1.6 et 2.0.1 partagent le même réseau, la plateforme se rabat souvent sur le plus petit dénominateur commun, et votre matériel haut de gamme 2.0.1 finit par être géré comme un appareil basique 1.6.

Résultat : vous avez investi dans une infrastructure de recharge de pointe, mais votre logiciel n'est pas en mesure d'en tirer pleinement parti.

Le numéro de version indiqué sur une fiche technique n'est qu'une partie du tableau. La véritable mesure de la qualité d'une implémentation OCPP réside dans ses performances en conditions réelles, lorsque la connexion est interrompue, que le matériel présente des dysfonctionnements et que des cas limites, que nul test en laboratoire ne peut anticiper, commencent à se manifester. Voyons comment cela se passe dans la pratique.

‍

4. Études de cas concrets (les traces laissées par les combats)

Pour illustrer la réalité de l'intégration de l'OCPP aux systèmes de gestion de la recharge des véhicules électriques, voici quelques cas anonymisés que nous avons résolus pour nos clients. Ceux-ci mettent en évidence la différence entre un CPMS « standard » et un CPMS « opérationnel ».

Étude de cas n° 1 : Défaillance du système de gestion de charge au-delà de la « limite de sécurité »

• ‍Le scénario: un site dont la capacité du réseau était limitée a utilisé des profils de recharge intelligente OCPP pour limiter la consommation électrique de manière dynamique.‍
• La panne: la connexion Internet du site a été coupée pendant un orage.‍
• Résultat: le CPMS « Standard » a cessé d'envoyer des profils. Les chargeurs, ne recevant plus d'instructions, sont revenus à leur intensité maximale (32 A).‍
• Les conséquences: le site a fait sauter le fusible principal, ce qui a nécessité l'intervention d'un électricien en urgence et a mis le réseau hors service pendant 24 heures.‍
• La solution opérationnelle: une plateforme OCPP aboutie utilise une logique de « limite de sécurité ». Elle configure les paramètres de secours internes du chargeur via des clés OCPP avant toute coupure de connexion Internet. En cas de perte de connexion, le chargeur passe automatiquement à un courant de sécurité de 6 A, permettant ainsi au site de rester opérationnel. C'est exactement le type de scénario pour lequel une logique de gestion de charge aboutie a été conçue.

Étude de cas n° 2 : la perte de revenus liée aux « sessions fantômes »

• ‍Le contexte: un responsable des achats a constaté un écart entre la quantité d'énergie fournie et les factures émises.‍
• L'incident: un conducteur a branché son véhicule, mais l'autorisation a échoué en raison d'un problème de réseau mobile. Le chargeur a envoyé une commande « StartTransaction », mais le serveur n'a jamais reçu cette commande. Le chargeur, pensant être connecté, a commencé à fournir de l'énergie.‍
• Résultat : une session « zombie » ou « fantôme » où l'énergie circule sans qu'aucun enregistrement de facturation n'existe.‍
• Solution opérationnelle: le système recherche les bornes de recharge « occupées » pour lesquelles aucune transaction n'est enregistrée dans la base de données. Il déclenche ensuite un TriggerMessage afin de synchroniser l'état de la borne avec le cloud, ce qui permet de récupérer rétroactivement les données de facturation manquantes.

Étude de cas n° 3 : Le « brickage » du micrologiciel

• ‍Le scénario: un gestionnaire de flotte a déployé une mise à jour du micrologiciel recommandée par le fabricant sur 200 bornes de recharge OCPP.‍
• Le problème: la mise à jour a légèrement modifié le format de l'horodatage dans le message MeterValues (une erreur courante dans la mise en œuvre du protocole).‍
• Résultat : le logiciel backend OCPP a rejeté les messages en les qualifiant de « JSON mal formé ». Les chargeurs fonctionnaient, mais aucune donnée n'a été enregistrée.‍
• Solution opérationnelle: cela nécessite un système de gestion de la performance des centres de données (CPMS) doté d'une couche d'ingestion « tolérante », c'est-à-dire capable de signaler un avertissement en cas de données mal formées tout en les enregistrant, plutôt que de les rejeter purement et simplement et de perdre ainsi l'enregistrement des recettes.

Toutes ces mésaventures pourraient être évitées si l'on savait mettre en œuvre correctement un logiciel conforme à l'OCPP.

5. Bonnes pratiques pour la mise en œuvre de l'OCPP

Si vous recherchez les meilleures pratiques pour la mise en œuvre d'une infrastructure de recharge de véhicules électriques OCPP, vous devez aller au-delà des fonctionnalités logicielles et vous intéresser à la gouvernance.

Pour éviter les problèmes d'intégration du CPMS, vous devez aborder votre processus d'approvisionnement comme un audit technique. Voici les questions à poser à un fournisseur avant de signer un contrat de cinq ans :

Les questions qui doivent vous alerter

Ne vous fiez pas aux colonnes « Oui » ou « Non » d'un appel d'offres. Posez ces questions pour évaluer le véritable niveau de maturité :

1. « Montre-moi ta logique de « Ghost Session ». »
   À vérifier : disposent-ilsde scripts automatisés pour détecter lorsqu'un chargeur fournit de l'énergie sans session de facturation valide ?

2. « Comment gérez-vous les "dialectes" ? »
   Ce qu'il faut rechercher : s'ils répondent « Nous respectons parfaitement la norme », fuyez. Ils devraient plutôt dire : « Nous disposons d'une couche d'adaptation pour les différentes marques de matériel. »

3. « Présentez une mise à jour groupée du micrologiciel sur un parc hétérogène. »
   Points à vérifier : demandez comment ils gèrent les mises à jour OCPP 1.6 et 2.0.1 simultanément sans provoquer de panne du réseau.

4. «En quoi consiste votre protocole « Safe Limit » ? »
   À vérifier: si la connexion Internet est coupée pendant une opération de gestion de la charge, le chargeur fait-il sauter le fusible ou passe-t-il à un niveau minimum de sécurité ?

6. Conclusion : Bienvenue dans l'ère opérationnelle

Nous n'écrivons pas cela pour vous faire peur. Nous écrivons cela parce que l'ère de la « ruée vers les emplacements » dans le domaine de la recharge des véhicules électriques est révolue. Nous sommes désormais entrés dans l'ère de l'exploitation.

Les règles du jeu ont changé. La rentabilité ne dépend plus du nombre de bornes installées, mais de la disponibilité du système, de l'intégrité des revenus et du coût de service. Les difficultés liées à la mise en œuvre de l'OCPP constituent le principal obstacle à cette rentabilité.

Chez Ocean, nous ne prétendons pas que notre logiciel est magique. Nous nous présentons comme le partenaire qui a fait ses preuves sur le terrain. Nous avons passé des années à perfectionner notre logiciel OCPP afin qu'il puisse gérer la réalité complexe et fragmentée du marché du matériel informatique, pour que vous n'ayez pas à le faire.

Si vous souhaitez passer du « Plug and Play » au « Plug and Partner », vous êtes au bon endroit.

Prêt à contrôler votre fournisseur ?

Télécharger le guide « Approvisionnement stratégique CPMS »

Procurez-vous le guide complet qui contient les spécifications techniques, les clauses pénales et les « questions décisives » dont vous avez besoin pour vous assurer une plateforme de qualité professionnelle.

Discutez avec notre équipe de la mise en œuvre concrète de l'OCPP

Nous allons vous montrer nos cicatrices de guerre. Et comment nous les avons surmontées.