1. Qu’est-ce que l’OCPP et pourquoi les CPO doivent s’en préoccuper ?

OCPP (Open Charge Point Protocol) est la norme de communication entre les bornes de recharge et un système central de gestion (CSMS). Elle définit comment une borne de recharge communique son état à la plateforme, reçoit les commandes à distance, gère l'autorisation de paiement et signale les pannes. En bref : elle détermine si votre réseau de recharge est ouvert ou réservé à un seul fournisseur.

Deux choses que tout directeur des achats doit comprendre :

Tout d'abord, OCPP est une norme ouverte. Maintenue par l'Open Charge Alliance (OCA), elle n'appartient à aucun fabricant de matériel ni à aucune plateforme logicielle. Un chargeur compatible OCPP peut communiquer avec n'importe quel CSMS compatible OCPP. Vous n'êtes donc pas dépendant d'un fournisseur de matériel : si vous souhaitez changer de fournisseur de plateforme dans trois ans ou intégrer des chargeurs d'un autre fabricant au même réseau, le coût de la migration est quasi nul, à condition que les deux parties prennent en charge OCPP.

Deuxièmement, OCPP est différent d'OCPI. OCPI (Open Charge Point Interface) gère l'itinérance et le règlement entre différents réseaux de recharge ; par exemple, un conducteur de véhicule électrique utilise l'application du réseau A pour recharger son véhicule à une borne du réseau B. OCPP gère la communication entre une borne de recharge et sa propre plateforme de gestion. Ces deux technologies répondent à des problématiques différentes. Ce guide traite d'OCPP.

2. Les réalisations et les lacunes d'OCPP 1.6

OCPP 1.6 (publié en 2015, mis à jour en version 1.6J en 2017) est la version du protocole de recharge la plus répandue au monde. Elle a rempli la mission fondamentale d'OCPP : standardiser les flux de travail de base pour la gestion des sessions de recharge, le démarrage/arrêt à distance, la transmission des données et les mises à jour du micrologiciel.

Cependant, la version 1.6 présente trois limitations structurelles :

1. Absence de modèle de données standardisé pour les appareils. La norme OCPP 1.6 ne définit pas de modèle de données uniforme pour les variables des chargeurs. Chaque fabricant représente différemment la “ puissance de charge ”, le “ capteur de température ” et le “ code d'erreur ”. Lorsqu'un gestionnaire de points de service (CPO) administre un réseau de bornes de recharge multimarques, un même paramètre peut présenter des noms de champs, des unités et des plages de valeurs totalement différents selon les marques de chargeurs. Cela complique la surveillance et le diagnostic unifiés.

2. La sécurité est facultative, non obligatoire. Les spécifications de sécurité d'OCPP 1.6 sont optionnelles. Le chiffrement TLS, la gestion des certificats et les mises à jour sécurisées du firmware sont présents dans la version 1.6, mais ne sont pas obligatoires. De nombreux déploiements en production utilisent des connexions WebSocket non chiffrées ou des certificats auto-signés. D'ici 2026, cette pratique ne sera plus acceptable pour un système d'exploitation traitant des données de paiement et des informations personnelles.

3. Le support de charge intelligent est fin. La fonctionnalité de recharge intelligente d'OCPP 1.6 permet d'appliquer des profils de recharge (limites de puissance, plages horaires), mais ne prend pas en charge nativement la gestion dynamique de la charge, l'intégration des énergies renouvelables ni la recharge bidirectionnelle V2G. Il ne s'agit pas de cas d'usage futurs en 2026, mais d'exigences opérationnelles déployées à grande échelle.

3. OCPP 2.0.1 : Principales améliorations du point de vue d’un CPO

OCPP 2.0.1 (publié en 2020, premiers tests de certification terminés en 2023) n'est pas une simple mise à jour d'OCPP 1.6. Il s'agit d'une refonte architecturale. Voici les cinq changements les plus importants pour les CPO.

3.1 Amélioration 1 : Modèle de périphérique — Un langage de gestion unifié

OCPP 2.0.1 introduit un modèle de périphérique standardisé. Tous les paramètres configurables, les variables de surveillance et les informations de diagnostic d'un chargeur sont organisés dans une structure de données hiérarchique unifiée. Chaque paramètre possède un nom standardisé, un type de données, une plage de valeurs, des autorisations d'accès et un indicateur précisant si sa modification nécessite un redémarrage.

Impact pratique pour les gestionnaires de points de vente : dans un réseau de recharge multimarque, il est désormais possible de consulter la température, la puissance de sortie, les codes d’erreur et les versions de micrologiciel de tous les chargeurs via une interface unique. Le système de gestion des points de vente (CSMS) n’a plus besoin de gérer une table de correspondance distincte pour chaque fabricant. Plus votre réseau est étendu, plus cet avantage est significatif.

3.2 Amélioration 2 : Architecture de sécurité — TLS et la gestion des certificats deviennent obligatoires

OCPP 2.0.1 rend obligatoires les fonctionnalités de sécurité suivantes :

• Chiffrement TLS 1.2 (ou supérieur) : Toutes les communications entre le chargeur et le CSMS doivent être chiffrées. Les connexions WebSocket en clair ne sont plus autorisées.

• Gestion des certificats X.509 : la version 2.0.1 définit la gestion complète du cycle de vie des certificats de chargeur (installation, renouvellement et révocation). Ceci permet aux responsables de la protection des données (CPO) d’établir des chaînes de confiance basées sur les certificats, empêchant ainsi les attaques de type « homme du milieu » et les accès non autorisés.

• Mises à jour sécurisées du micrologiciel : les packages du micrologiciel doivent être signés numériquement et le chargeur doit vérifier la signature avant l’installation. Cela empêche l’injection de micrologiciel malveillant, une faille de sécurité connue dans les déploiements de la version 1.6.

• Journal de sécurité : les chargeurs enregistrent tous les événements liés à la sécurité (échecs d’authentification, modifications de configuration, opérations sur le micrologiciel), et le CSMS peut collecter et analyser activement ces journaux.

Pour les réseaux de paiement qui acceptent les paiements par carte bancaire ou traitent les données personnelles des utilisateurs, ces exigences de sécurité constituent un minimum de conformité, et non une option.

3.3 Amélioration 3 : Recharge intelligente — Des limites statiques à la coordination dynamique

La fonction de charge intelligente d'OCPP 1.6 est essentiellement statique : vous définissez un profil de charge (limite de puissance, plage horaire) et le chargeur l'exécute. Elle ne tient pas compte des conditions dynamiques du réseau, de la production solaire sur site ni des états de charge/décharge du système de stockage d'énergie par batterie.

OCPP 2.0.1 introduit des primitives de charge intelligente plus riches :

• Programme composite : les chargeurs peuvent signaler leur consommation d’énergie prévue sur différentes périodes, et le CSMS peut ajuster le programme de chaque chargeur en fonction de la charge totale du site.

• Intégration de systèmes de gestion de l'énergie externes : la version 2.0.1 prend en charge nativement les interfaces avec les systèmes de gestion de l'énergie externes (EMS), permettant aux bornes de recharge de répondre aux signaux de prix ou aux commandes de répartition du réseau.

• Intégration ISO 15118 : Prend en charge la communication de charge intelligente avec le véhicule — le véhicule peut indiquer au chargeur l’état de sa batterie, le SOC cible et l’heure de départ prévue, et le chargeur optimise la courbe de charge en conséquence.

Impact concret pour les CPO : si votre site est équipé de panneaux solaires ou d’un système de stockage, ou si votre marché applique une tarification de l’électricité en fonction des heures de consommation, les fonctionnalités de recharge intelligente de la version 2.0.1 se traduisent directement par une réduction des coûts d’exploitation. Il ne s’agit pas d’une fonctionnalité future : elle est disponible dès maintenant sur le matériel actuel et ne nécessite qu’une prise en charge au niveau du protocole.

3.4 Amélioration 4 : Gestion des transactions — Facturation plus fiable

OCPP 2.0.1 repense le flux de traitement des transactions et introduit un modèle d'événement de facturation plus précis. Principales améliorations :

• Prise en charge des transactions hors ligne : en cas d’interruption de la communication entre le chargeur et le CSMS, le chargeur peut mettre en cache les données de transaction localement et les télécharger en masse une fois la connexion rétablie. Dans les régions où l’infrastructure réseau est instable, cela a un impact direct sur l’intégrité des revenus.

• Granularité de la facturation : La version 1.6 facture au niveau de la session. La version 2.0.1 prend en charge plusieurs segments de facturation au sein d’une même session — par exemple, un tarif pour les 30 premières minutes, puis un autre tarif. Ceci permet des stratégies tarifaires plus flexibles.

• Assistance en matière de taxes et de surtaxes : les données transactionnelles peuvent inclure des ventilations fiscales, simplifiant ainsi la conformité fiscale dans plusieurs juridictions.

3.5 Amélioration 5 : Affichage des messages et expérience utilisateur

OCPP 2.0.1 normalise le format des messages affichés sur les écrans des bornes de recharge. Le CSMS peut diffuser des messages structurés (informations tarifaires, progression de la charge, notifications de panne) que la borne présente à l'utilisateur dans un format uniforme. Pour les réseaux de recharge publics, cela améliore l'expérience utilisateur : quelle que soit la marque de la borne utilisée, les informations affichées à l'écran sont identiques.

4. Chemin de migration : de la version 1.6 à la version 2.0.1

La migration vers OCPP 2.0.1 n'est pas une simple mise à jour du micrologiciel. Il s'agit d'un projet global impliquant le matériel, la plateforme et les processus opérationnels. Vous trouverez ci-dessous le plan de migration par étapes.

4.1 Phase 1 : Évaluation (1 à 2 semaines)

Étape 1 : Audit de compatibilité matérielle. OCPP 2.0.1 requiert une configuration matérielle minimale. Les anciens contrôleurs de chargeur peuvent ne pas disposer de la puissance de traitement, de la mémoire ou de l'accélération matérielle TLS nécessaires à l'exécution du protocole 2.0.1. Veuillez contacter le fabricant de votre chargeur afin de vérifier, pour chaque modèle, sa compatibilité avec OCPP 2.0.1 et le niveau de prise en charge (fonctionnalités complètes ou partielles).

Informations clés à obtenir : modèle du processeur, mémoire disponible, prise en charge matérielle TLS et procédure de mise à niveau depuis la version actuelle du firmware.

Étape 2 : Confirmation de compatibilité CSMS. Votre plateforme de gestion prend-elle en charge OCPP 2.0.1 ? Si oui, s’agit-il d’une prise en charge complète ou d’une prise en charge partielle des fonctionnalités ? La prise en charge de la version 2.0.1 nécessite généralement un travail de développement important côté plateforme ; il ne s’agit pas d’une simple option à activer ou désactiver.

Étape 3 : Priorisation des fonctionnalités. Toutes les fonctionnalités de la version 2.0.1 n'ont pas la même importance pour votre activité. Si vous gérez un réseau public de recharge rapide, les améliorations en matière de sécurité et de transactions sont probablement prioritaires. Si vous gérez un dépôt de véhicules équipé de panneaux solaires et d'un système de stockage, les fonctionnalités de recharge intelligente sont peut-être plus importantes. Définissez clairement vos priorités : n'essayez pas d'activer toutes les fonctionnalités en même temps.

4.2 Phase 2 : Planification (2 à 4 semaines)

Étape 4 : Choisir une stratégie de déploiement. Trois stratégies sont disponibles :

• Nouveau site : Déployer OCPP 2.0.1 directement sur les nouveaux sites. C’est la solution la plus simple et elle évite les coûts de migration ultérieurs.

• Exécution en parallèle : Sélectionner 1 à 2 sites existants comme sites pilotes. Migrer une partie des bornes de recharge vers la version 2.0.1 tout en conservant les autres en version 1.6. Le CSMS doit prendre en charge simultanément les deux versions du protocole.

• Big Bang : Mise à niveau de l’ensemble du réseau en une seule fois. Convient uniquement aux petits réseaux (< 20 bornes de recharge) ou lorsque la compatibilité matérielle et logicielle a été rigoureusement validée.

Étape 5 : Élaborer un plan de repli. Chaque migration nécessite une procédure de restauration validée. Avant de lancer une migration par lots, vérifiez la procédure complète de retour à la version 1.6 depuis la version 2.0.1 sur un chargeur de test. La restauration doit être une étape planifiée et non une mesure d'urgence.

4.3 Phase 3 : Exécution (La durée varie selon l'échelle)

Étape 6 : Validation de l'environnement de test. Effectuez les tests suivants dans un environnement isolé :

• 2.0.1 Établissement et maintien de la connexion entre le chargeur et le CSMS

• Cycle de vie complet d'une session de facturation (démarrage/arrêt, facturation, rapports de données)

• Gestion de l'installation, du renouvellement et de l'expiration des certificats TLS

• Rapports et analyses des journaux de sécurité

• Simulation de panne (perte de communication, certificat invalide, échec de la vérification de la signature du firmware)

Étape 7 : Projet pilote de production. Pour la première phase de migration, choisissez un site à faible risque (faible trafic, impact des pannes gérable). Surveillez-le pendant au moins deux semaines et vérifiez que les indicateurs suivants correspondent aux valeurs de référence d'avant la migration : taux de réussite de la facturation, exactitude de la facturation, temps de réponse moyen aux pannes et taux de réussite des paiements des utilisateurs.

Étape 8 : Déploiement progressif. Après chaque migration par lot, prévoyez au moins une semaine d'observation avant de lancer la migration du lot suivant. Ne migrez pas plus de 20% de vos chargeurs lors d'une même opération de maintenance ; en cas de problème, le rayon d'action reste maîtrisable.

4.4 Phase 4 : Validation et optimisation (en cours)

Après la migration, surveillez en continu les indicateurs suivants par rapport aux valeurs de référence d'avant la migration :

• Taux de réussite des sessions de facturation

• Fréquence des interruptions de communication et temps de rétablissement

• Nombre et type d'événements de sécurité

• Intégrité des données transactionnelles et exactitude de la facturation

• Adoption et efficacité des nouvelles fonctionnalités (par exemple, réduction de la charge de pointe grâce à la recharge intelligente)

5. Erreurs courantes et comment les éviter

Voici quelques erreurs fréquentes observées dans des projets de migration réels.

Erreur n° 1 : Ignorer les limitations matérielles. L'erreur la plus coûteuse consiste à supposer que le matériel existant est compatible avec OCPP 2.0.1, puis à découvrir lors de la migration que le contrôleur est sous-dimensionné : les chargeurs subissent des pics de latence lors des échanges TLS, ce qui dégrade l'expérience utilisateur. Il est donc essentiel de réaliser un audit matériel complet dès la phase d'évaluation pour éviter ce problème.

Erreur n° 2 : Commencer la migration avec une prise en charge incomplète de la plateforme. Certains fournisseurs de CSMS affirment prendre en charge OCPP 2.0.1, mais n'ont implémenté que les messages de base, négligeant des fonctionnalités avancées telles que la facturation intelligente ou la journalisation de sécurité. Avant toute migration, exigez de votre fournisseur une liste détaillée des fonctionnalités de son implémentation OCPP 2.0.1 ; un simple “ nous le prenons en charge ” ne suffit pas. Demandez des précisions jusqu'au type de message.

Erreur 3 : Négliger l’environnement de test. Effectuer des tests de migration sur des chargeurs connectés en production revient à expérimenter en environnement réel. Prévoyez du matériel dédié aux tests (même un seul chargeur) et validez l'intégralité du processus dans un environnement réseau isolé.

Erreur 4 : Migrer l'ensemble du réseau simultanément. Quelle que soit la taille du réseau, la migration par étapes avec validation par lots et fenêtres de restauration est la seule solution sûre. L'étendue maximale de la migration au cours d'une même fenêtre de maintenance dépend de la capacité de réaction de votre équipe d'exploitation en cas de panne.

Erreur n°5 : Suivre uniquement les indicateurs techniques et ignorer les indicateurs opérationnels. La réussite d'une migration ne se résume pas à la simple communication du chargeur. Elle se définit par des données opérationnelles égales ou supérieures aux valeurs de référence antérieures à la migration. L'exactitude de la facturation, le taux de réussite des paiements et le volume des réclamations des utilisateurs doivent faire partie des critères de réussite de la migration, et non se limiter à une validation technique.

6. Résumé du livre blanc sur la sécurité

L'architecture de sécurité d'OCPP 2.0.1 repose sur les principes suivants :

Défense en profondeur : la sécurité ne repose pas sur un seul mécanisme. Le chiffrement TLS protège la couche transport. La gestion des certificats protège l’identité et l’authentification. La signature du firmware garantit l’intégrité du code. La journalisation de sécurité fournit des pistes d’audit. La défaillance d’une seule couche ne doit pas compromettre la sécurité globale.

Principe du moindre privilège : les chargeurs ne disposent que des autorisations minimales nécessaires à leur fonctionnement. La gestion des certificats et des rôles de la version 2.0.1 permet un contrôle d’accès précis ; un système de surveillance en lecture seule ne doit pas avoir accès aux privilèges de mise à jour du micrologiciel ni de modification de la configuration.

Gestion du cycle de vie de la sécurité : les certificats ont une date d’expiration. Les clés de signature du firmware peuvent être renouvelées. Les journaux de sécurité sont automatiquement purgés après leur période de conservation. La sécurité n’est pas une configuration ponctuelle ; c’est un processus continu qui exige une surveillance opérationnelle permanente.

Concrètement, pour les responsables de la sécurité des systèmes d'information (CPO) : le déploiement d'OCPP 2.0.1 ne garantit pas automatiquement la sécurité. Il est nécessaire de configurer les certificats TLS, de gérer leur cycle de vie, de surveiller les journaux de sécurité et de traiter les événements d'expiration et de révocation des certificats. La version 2.0.1 fournit les fonctionnalités de sécurité ; leur mise en œuvre concrète reste à la charge de l'opérateur.

7. Protocoles OCPP vs. Protocoles propriétaires : le risque à long terme du CPO

Certains fabricants de chargeurs utilisent encore des protocoles de communication propriétaires. Ceux-ci peuvent offrir des fonctionnalités spécifiques et différenciées, mais le risque à long terme pour le CPO est structurel :

Dépendance vis-à-vis du fournisseur. Un protocole propriétaire signifie que votre réseau de recharge ne peut fonctionner qu'avec la plateforme spécifique d'un fabricant donné. Si vous n'êtes pas satisfait des performances, du prix ou du service, le coût d'un changement de fournisseur équivaut à la reconstruction complète de la couche de communication de votre réseau. Le coût et le délai d'une telle migration dépassent généralement les économies réalisées sur l'achat initial du matériel.

Obstruction des audits de sécurité. Les propriétés de sécurité d'un protocole propriétaire sont opaques. Les audits de sécurité réalisés par des tiers indépendants ne peuvent vérifier la validité de la mise en œuvre du chiffrement, la robustesse de la gestion des clés ni la sécurité des mécanismes de mise à jour du micrologiciel dans un protocole non divulgué. Seule l'autodéclaration du fabricant constitue le véritable enjeu.

Perte d'interopérabilité. À l'avenir, vous pourriez souhaiter intégrer de nouveaux fournisseurs de matériel ou de nouvelles fonctionnalités de plateforme, par exemple en connectant votre borne de recharge au système de gestion d'une centrale électrique virtuelle. Si le protocole sous-jacent est propriétaire, chaque intégration nécessite un développement sur mesure. Si le protocole sous-jacent est OCPP 2.0.1, l'intégration se résume à une configuration conforme à une norme publiée.

La tendance du secteur est claire. Le programme de certification de l'OCA encourage les tests de conformité à la norme OCPP 2.0.1. Les principaux fournisseurs de plateformes et de matériels ont finalisé ou sont en train de finaliser leur implémentation de la norme 2.0.1. Si vous prenez des décisions d'achat aujourd'hui, exiger la prise en charge de la norme OCPP 2.0.1 n'est pas un gage de pérennité ; c'est le prérequis pour l'évaluation technique actuelle.

8. Liste de contrôle des actions du CPO

Si vous exploitez actuellement un réseau OCPP 1.6 :

1. Demandez à votre fournisseur de matériel les déclarations de compatibilité OCPP 2.0.1 pour chaque modèle de chargeur (et non des documents marketing, mais des spécifications techniques).

2. Demandez à votre fournisseur CSMS une liste détaillée des fonctionnalités prises en charge par OCPP 2.0.1.

3. Identifier 1 à 2 sites à faible risque et élaborer un plan de migration pilote

4. Inclure la prise en charge d'OCPP 2.0.1 dans les exigences techniques pour tout nouvel achat d'équipement.

Si vous vous procurez de nouveaux équipements et construisez de nouveaux sites :

1. Exiger explicitement la prise en charge d'OCPP 2.0.1 (version complète, et non un sous-ensemble) dans les documents d'appel d'offres

2. Exiger des fournisseurs qu'ils fournissent une certification OCA ou des rapports de tests de conformité équivalents effectués par un tiers.

3. Exiger que le CSMS prenne en charge à la fois OCPP 1.6 et 2.0.1 — cela préserve la compatibilité pour les futurs ajouts d'équipements 1.6.

4. Inclure une vérification fonctionnelle complète du jeu de messages OCPP 2.0.1 dans les tests d'acceptation