Supervision de plusieurs marques de bornes : préparer les essais

Une supervision multimarque se valide par des tests de compatibilité menés sur chaque combinaison réellement présente dans le parc : modèle de borne, version de firmware, version d’OCPP et fonctions attendues. Une connexion réussie sur une borne ne prouve rien pour les autres. Les mêmes scénarios, rejoués partout et consignés, rendent les écarts visibles.

Vous saurez lister les combinaisons à essayer, lire les certificats, écrire un protocole commun, éprouver le fonctionnement hors ligne et le pilotage de puissance, puis trier les écarts avant d’étendre la supervision au parc.

Supervision multimarque : pourquoi les tests de compatibilité se font modèle par modèle

Parce que les implémentations du protocole diffèrent d’un fabricant à l’autre : un logiciel peut dialoguer parfaitement avec une borne et mal avec sa voisine. L’essai porte donc sur le couple borne et supervision, pas sur la marque.

OCPP, pour Open Charge Point Protocol, est présenté par l’Open Charge Alliance (OCA), qui le publie, comme le protocole de communication ouvert entre les bornes et les systèmes qui les gèrent. Trois versions coexistent : 1.6, publiée en 2015, 2.0.1 en 2020 et 2.1 en 2025. OCPP 2.0.1 n’est pas rétrocompatible avec 1.6 : la gestion des transactions a été revue. Une borne et sa supervision doivent donc parler la même version, ou la supervision doit gérer les deux. Le comparatif des versions OCPP 1.6, 2.0.1 et 2.1 aide à les situer.

Le livre blanc de l’OCA sur la migration des bornes le dit sans détour : toutes les implémentations d’OCPP ne se valent pas. Sauf si la borne et la supervision ont toutes deux une certification OCPP officielle, il est indispensable de tester leur compatibilité. Et, certification ou non, l’OCA demande de tester chaque modèle, avec ses différentes versions logicielles, sur la nouvelle supervision avant toute migration à grande échelle.

Distinguez donc dans vos notes la conformité annoncée par les documents et l’intégration observée sur votre parc.

Dresser la liste des combinaisons à tester

Une ligne par combinaison, pas par marque : modèle exact, version de firmware, version d’OCPP et mode de connexion. Le firmware est le logiciel embarqué de la borne ; deux bornes identiques qui n’ont pas la même version peuvent se comporter différemment.

Prenons un parking équipé de trois modèles, dont l’un existe en deux versions de firmware : cela fait quatre combinaisons à essayer, pas trois. À l’inverse, vingt bornes du même modèle avec le même firmware et la même liaison forment une seule combinaison ; l’essai peut porter sur une ou deux d’entre elles. La méthode d’inventaire technique d’un parc de bornes aide à réunir ces informations.

Le BootNotification est le message par lequel la borne se présente à la supervision, version de firmware comprise : c’est cette version que le certificat doit mentionner.

Lire les certificats OCPP pour savoir où l’essai peut être allégé

Un certificat allège la vérification du protocole, jamais l’essai du modèle sur votre supervision. Encore faut-il qu’il corresponde exactement à ce qui est installé.

Selon la procédure de certification de l’OCA (version 3.6.2 du 3 juillet 2026), un fabricant peut implémenter OCPP sans être certifié, mais il ne peut pas se dire conforme OCPP sans certification. Le certificat mentionne la version d’OCPP, les profils certifiés, le jeu de fonctions matérielles et la version de firmware, celle que la borne déclare dans son BootNotification. Tous les certificats sont publiés dans l’annuaire « OCPP Certification Directory » de l’OCA. Une nouvelle version de firmware n’est plus certifiée tant qu’elle n’a pas été recertifiée.

Les profils disent ce qui a été vérifié. En OCPP 1.6, la même procédure exige des bornes, depuis octobre 2025, au moins le profil de sécurité 2, c’est-à-dire une liaison chiffrée en TLS 1.2 ou plus avec authentification de base ; le Smart Charging, ou recharge intelligente, y reste optionnel pour une borne, alors qu’il est obligatoire pour une supervision certifiée 1.6. En OCPP 2.0.1, seul le Core est obligatoire. Notez, combinaison par combinaison, les profils certifiés : une fonction qui n’y figure pas sera testée en priorité. Le guide des preuves à demander pour une borne annoncée OCPP détaille cette lecture.

Choisir les fonctions à vérifier sur chaque borne

Testez d’abord ce qui bloque l’exploitation : autoriser, démarrer, arrêter, compter, remonter un état. Viennent ensuite les fonctions que votre parc utilise réellement, décrites dans le guide du logiciel de supervision de bornes.

Deux différences entre versions faussent les comparaisons. En OCPP 1.6, une transaction commence au branchement avec autorisation accordée ; OCPP 2.0.1 rend ces instants configurables, du branchement du câble jusqu’au débranchement par exemple. Selon leur version et leur configuration, deux bornes peuvent donc produire des durées différentes pour une même recharge. Ensuite, les statuts diffèrent : neuf valeurs en 1.6, cinq en 2.0.1. Vérifiez que la supervision les traduit dans un affichage commun.

Écrire un protocole d’essai commun à toutes les marques

Même scénario, même ordre, même fiche pour toutes les combinaisons : c’est la condition pour qu’un écart vienne de l’équipement et non de la façon de tester.

Chaque scénario suit la même trame :

1. noter la combinaison testée, la version de la supervision et la date ;
2. décrire le résultat attendu avant de commencer ;
3. faire le geste réel : garer la voiture, brancher le câble, présenter le badge, lancer l’arrêt ;
4. relever l’heure exacte de chaque geste, qui permet de retrouver le message correspondant dans les journaux de la supervision ;
5. consigner ce que voit le conducteur (voyant, écran, application) et ce que reçoit l’exploitant (session, statut, alerte) ;
6. conclure : conforme, écart, ou essai à refaire.

« Cela fonctionne » ne suffit pas comme conclusion. Si le comptage remonte mais que la limite de puissance demandée ne s’applique pas, la fiche doit le dire en toutes lettres, avec les versions en cause. Préparez aussi vos badges d’essai à l’avance : un badge autorisé, un badge inconnu de la supervision et un badge que vous désactiverez juste avant l’essai hors ligne.

Tester la perte de connexion et la reprise sur chaque marque

Pour savoir comment chaque modèle se comporte hors ligne, provoquez une coupure de la liaison de données, planifiée avec le prestataire de supervision. Il s’agit de couper la communication, jamais l’alimentation électrique : toute manœuvre dans le tableau relève d’un électricien qualifié.

Selon le livre blanc de l’OCA sur la disponibilité des bornes, les recharges en cours continuent hors ligne et leurs messages, arrêt compris, sont gardés en mémoire puis transmis au retour de la connexion ; autoriser une nouvelle session peut en revanche être impossible. Seuls les messages liés aux transactions sont conservés : les refus d’autorisation et les changements d’état survenus pendant la coupure ne remontent pas, sauf en OCPP 2.0.1 avec la variable QueueAllMessages activée.

Deux mécanismes acceptent des badges hors ligne : le cache d’autorisation, qui garde le résultat des badges récemment utilisés, et la liste d’autorisation locale, fonction optionnelle absente de certaines bornes. Un réglage dédié permet aussi d’accepter n’importe quel badge hors ligne, mais les sessions des badges inconnus ne pourront pas être facturées. Pendant la coupure, présentez un badge habituel, le badge inconnu et le badge désactivé, qu’une borne peut encore accepter d’après son cache ; comparez l’historique après la reprise. Le guide pour tester une reprise après coupure réseau détaille le déroulé.

Vérifier le pilotage de puissance marque par marque

Les marques peuvent différer sur ce point, car le pilotage est optionnel pour certifier une borne : elle peut être certifiée OCPP sans savoir appliquer un profil de charge.

Un profil de charge est une consigne envoyée par la supervision, par exemple une puissance maximale pendant une plage horaire. La page de l’OCA sur la certification OCPP 2.0.1 range le Smart Charging parmi les profils optionnels, avec Advanced Security et ISO 15118 Support. Si le partage de puissance entre bornes repose sur la supervision, chaque combinaison doit donc prouver qu’elle applique la consigne.

L’essai se mène en trois temps. Lancez une recharge, envoyez une limite nettement inférieure à la puissance en cours, puis relevez la puissance réellement délivrée côté supervision. Retirez ensuite la limite et vérifiez le retour à la normale. Enfin, demandez au fabricant par écrit ce que fait la borne quand la supervision ne répond plus : garde-t-elle la dernière consigne ou revient-elle à sa puissance par défaut ?

Si le délestage est confié à un gestionnaire local, l’essai change de nature : l’article sur la supervision et le délestage aide à situer la décision.

Classer les écarts et les attribuer au bon interlocuteur

Chaque écart reçoit une gravité et un responsable avant toute décision de déploiement.

Trois catégories suffisent :

• blocage : la borne ne peut pas être exploitée normalement, par exemple une session non enregistrée ou un badge valide refusé ;
• fonction optionnelle indisponible : le pilotage ou la liste locale manque sur un modèle, ce qui limite son usage sans l’empêcher ;
• différence d’interface acceptable : un libellé ou un statut affiché autrement, sans perte d’information.

Ne concluez pas trop vite que le protocole est en cause. L’OCA rappelle qu’OCPP n’est qu’un jeu de messages : il aide à détecter les pannes, il n’en est pas responsable. Un défaut peut venir du firmware, qui relève du fabricant, de l’interprétation des messages par la supervision, qui relève de l’éditeur, ou de la liaison et de la configuration, qui relèvent de l’installateur ou de l’exploitant.

Déployez ensuite par lots contrôlés, comme l’OCA le recommande pour les migrations, et refaites l’essai de la combinaison concernée après chaque mise à jour importante du firmware ou de la supervision.

Préparer la campagne d’essais : liste de contrôle

Une campagne se prépare sur papier avant le premier branchement. Vérifiez les points suivants :

• l’inventaire liste chaque combinaison, avec la version de firmware lue dans la supervision ;
• le certificat de chaque modèle est retrouvé dans l’annuaire de l’OCA et comparé au firmware installé ;
• les critères d’acceptation sont écrits : fonctions obligatoires, fonctions optionnelles, écarts tolérés ;
• les badges d’essai et un véhicule sont disponibles, avec un créneau où le parking peut être occupé ;
• la coupure de liaison est planifiée avec le prestataire, qui sait quoi observer de son côté.

Côté contrat, l’OCA recommande de conclure avec les fabricants des accords de support de longue durée et un séquestre de leur firmware, c’est-à-dire un dépôt chez un tiers récupérable en cas de défaillance. Si vous équipez ou étendez un parc, la page supervision OCPP des bornes présente notre approche, et la demande de devis professionnel déclenche une visite technique puis un devis détaillé. Objectif : devis sous 48 h après dossier complet.

L’essentiel à retenir

• Une supervision multimarque se teste par combinaison de modèle, de firmware, de version d’OCPP et de liaison, jamais par marque.
• Un certificat OCPP vaut pour un modèle et une version de firmware précis ; une nouvelle version n’est plus certifiée tant qu’elle n’a pas été recertifiée.
• Même avec des certificats, l’OCA demande, avant de migrer un parc, de tester chaque modèle sur la nouvelle supervision.
• Le pilotage de puissance est optionnel pour certifier une borne : il se prouve par un essai de consigne, combinaison par combinaison.
• Une coupure de liaison planifiée révèle ce que chaque modèle garde, accepte et perd hors ligne.
• Chaque écart reçoit une gravité et un responsable, et l’essai se refait après chaque mise à jour importante.