Configurer l’accès RFID aux bornes de recharge professionnelles

Pour configurer l’accès RFID aux bornes de recharge professionnelles, vérifiez que le lecteur prend en charge votre support d’identification, relevez l’identifiant réellement transmis par la borne, enregistrez cette valeur dans la plateforme de recharge, attribuez les droits d’accès nécessaires et testez la session de recharge complète. Testez ensuite le comportement en cas de perte de connexion et de révocation d’une carte.

Commandez le lot de production après qu’un échantillon représentatif a passé cette procédure avec succès. La lecture réussie d’une carte ne confirme qu’une partie du résultat. Votre dossier de réception doit aussi attester du bon point de recharge, du bon compte, du relevé d’énergie et du comportement à l’arrêt.

Ce guide traite de la gestion des accès après l’installation et la mise en service des équipements de recharge par un installateur qualifié. Il s’adresse à l’équipe qui relie les supports d’identification physiques à un système de gestion de la recharge.

Comprendre quel système prend chaque décision

Dans un processus d’autorisation en ligne, le lecteur RFID lit un identifiant, la borne le transmet à un système de gestion des bornes de recharge, ou CSMS, puis la plateforme renvoie un résultat d’autorisation. OCPP régit les échanges entre la borne et ce système de gestion. L’interface radio entre la carte et le lecteur constitue une partie distincte de l’intégration. Consultez la présentation du protocole par l’Open Charge Alliance.

Désignez un responsable pour chaque couche. Le fournisseur de cartes peut livrer le support physique et le fichier d’identifiants convenus ; l’intégrateur des bornes confirme le comportement du lecteur ; l’exploitant de la plateforme contrôle l’enregistrement des comptes et les droits. Consignez qui résout les écarts avant le début de la mise en service.

1. Confirmer les capacités du lecteur et de l’autorisation

Demandez les spécifications du lecteur pour le modèle exact de borne, la révision matérielle et le micrologiciel installé. Notez les normes sans contact prises en charge, le mode d’utilisation du support et les éventuelles conversions d’identifiant configurables. Une mention comme « compatible RFID » ne répond pas à ces questions.

NFC fonctionne à 13,56 MHz et englobe plusieurs technologies sans contact, dont ISO/IEC 14443 Type A, Type B et ISO/IEC 15693. Une fréquence identique ne constitue donc pas à elle seule une spécification d’achat complète. Vérifiez la correspondance entre la technologie réelle de la carte et l’implémentation du lecteur. La présentation technique du NFC Forum explique ces protocoles sous-jacents.

Déterminez ensuite ce que la borne et le système central implémentent réellement :

La certification OCPP doit être examinée fonction par fonction. Dans sa mise à jour de décembre 2025, l’OCA classe Local List Management parmi les fonctions facultatives du profil OCPP 2.0.1 Core. Le programme de certification actualisé ne garantit donc pas que chaque borne certifiée prend en charge les listes locales. La note d’application OCPP 2.Lite, section C de l’OCA explique également que le cache d’autorisation peut être omis et que les implémentations peuvent prendre en charge différentes méthodes d’autorisation.

Demandez le périmètre du certificat et le Protocol Implementation Conformance Statement, lorsqu’ils sont disponibles, puis vérifiez leur concordance avec le logiciel installé. Conservez ces justificatifs avec la configuration du site.

L’OCA publie actuellement des ensembles documentaires OCPP 1.6, 2.0.1 et 2.1. Les exemples ci-dessous concernent spécifiquement les versions 1.6 et 2.0.1 ; pour une installation en 2.1, utilisez la spécification correspondante. Consultez les téléchargements officiels et errata lors de la mise en service ou d’une mise à niveau.

2. Relever l’identifiant sur la borne réellement utilisée

Commencez par un petit ensemble de cartes de test identifiables. Séparez la référence imprimée sur la carte de la valeur électronique : un numéro de série visible comme CRF-TEST-0042 est utile à l’assistance, mais sa relation avec l’identifiant du système central doit être documentée.

Voici des fragments de données utiles illustrant une demande d’autorisation OCPP en ligne avec un identifiant fictif :

OCPP 1.6

{"idTag":"04A1B2C3D4E5F7"}

OCPP 2.0.1

{"idToken":{"idToken":"04A1B2C3D4E5F7","type":"ISO14443"}}

Ces fragments omettent l’encapsulation des messages WebSocket. Les schémas officiels fixent un maximum de 20 caractères pour idTag en 1.6 et de 36 pour la chaîne idToken en 2.0.1 ; la version 2.0.1 exige aussi le type de jeton. Validez avec l’ensemble OCPP 1.6 ou l’ensemble OCPP 2.0.1 Edition 4 utilisé pour votre intégration.

Un démarrage autorisé localement peut suivre une séquence de messages différente. Demandez à l’intégrateur d’indiquer où le support et la décision d’autorisation sont consignés pour ce mode.

3. Convenir de la représentation des UID avant d’importer les cartes

Pour un jeton ISO14443, OCPP 2.0.1 recommande les octets hexadécimaux de l’UID avec l’octet 0 en premier. Le comportement des produits existants doit néanmoins être vérifié : le guide d’activation OCPP de Wallbox impose des valeurs hexadécimales en ordre petit-boutiste, sans séparateurs, pour les produits qu’il couvre. Il s’agit d’une instruction propre à ces produits, pas d’une règle universelle de conversion. Consultez OCPP 2.0.1, section d’autorisation C.1.1 et le guide d’activation Wallbox, pages 14 et 20.

Pour cette séquence fictive de sept octets, les représentations sont les suivantes :

Le tableau présente des transformations, pas quatre valeurs interchangeables dans le système central. Importez la représentation requise par l’intégration. Inverser les octets modifie leur ordre par paires de caractères ; inverser chaque caractère donne un autre résultat.

Conservez une correspondance écrite entre les données du fournisseur, le journal de la borne et le champ d’importation du système central. Précisez la longueur en octets, la notation hexadécimale ou décimale, l’ordre des octets, les séparateurs et toute transformation explicitement documentée. Conservez le fichier source brut. Évitez les troncatures non documentées et ne devinez pas les octets manquants.

Vérifiez les paramètres de l’appareil qui transforment les identifiants. Le manuel Wallbox eM4 WebAdmin comprend par exemple une option « Shorten UIDs » et avertit que les paramètres d’autorisation peuvent être modifiés depuis l’interface locale comme depuis le système central. Consultez le manuel Wallbox WebAdmin, page 23. Consignez la configuration effective après la connexion des deux systèmes.

Importez les colonnes d’identifiants dans les tableurs au format texte. Excel peut supprimer les zéros initiaux et limite la précision numérique à 15 chiffres significatifs ; notre exemple décimal comporte 16 chiffres. Appliquer un format d’affichage après modification des données ne restitue pas l’identifiant d’origine. Suivez les conseils de Microsoft pour préserver les données d’identifiants.

Utilisez le convertisseur UID ChargeRFID pour examiner les représentations et l’outil de rapprochement des fichiers d’identifiants pour comparer les fichiers de production et du système central. Confirmez la correspondance proposée à partir d’un vrai journal de borne avant de l’appliquer au lot.

4. Enregistrer les supports et attribuer les droits commerciaux

Créez l’enregistrement du support selon la procédure d’enrôlement ou d’importation documentée par la plateforme. Associez-le au conducteur, au véhicule, au service ou au compte client prévu, selon la méthode d’attribution des recharges utilisée par votre organisation.

Pour chaque support du pilote, consignez :

Traitez ces points comme des questions de réception distinctes. Un support peut figurer dans la base de données sans disposer du droit d’accès au lieu ou de l’affectation au compte prévu. De même, un démarrage réussi ne prouve pas que les bonnes modalités de facturation ont été appliquées.

Utilisez un registre d’enrôlement comportant la référence du lot, le résultat de l’importation, le motif d’exception et le vérificateur. Résolvez les doublons et les affectations contradictoires avant diffusion. Adaptez le modèle de remise des UID aux exigences réelles d’importation de votre plateforme ; sa ligne d’exemple contient des données de test.

Pour les véhicules partagés, convenez de qui peut arrêter une session. Les cas de test OCPP 1.6 de l’OCA couvrent explicitement l’arrêt avec la carte ayant lancé la session et l’arrêt avec une autre carte liée par un identifiant parent identique. Testez le comportement de groupe que vous souhaitez activer. Consultez les cas de test OCTT 2026-02, sections 2.3.1 et 2.3.2.

5. Définir une politique explicite d’accès hors ligne

Décidez si la recharge doit rester possible lorsque la borne ne peut pas joindre son système de gestion. Pour un dépôt de flotte à accès restreint, une politique de départ raisonnable consiste à accepter les supports prévus autorisés localement et à refuser les cartes inconnues pendant une panne. Confirmez que les équipements peuvent appliquer cette politique avant de vous y fier.

Un cache d’autorisation conserve les informations d’autorisation apprises lors d’échanges précédents. Une liste locale d’autorisation est administrée et synchronisée depuis le système central. Ce sont deux mécanismes distincts. Vider l’un ne prouve pas que l’autre a été mis à jour. OCPP 1.6 décrit leur relation dans la section 3.5 de la spécification.

Les noms ci-dessous sont des exemples propres à chaque version à discuter avec l’intégrateur, et non un fichier de configuration à copier dans une borne :

Ces noms ne signifient pas que chaque fonction est implémentée, activée ou modifiable. OCPP 2.0.1 utilise un adressage par composants et variables ; le modèle d’appareil et le cas d’usage applicable déterminent le fonctionnement de chaque paramètre. Consultez les sections de l’Edition 4 consacrées à l’autorisation et aux variables référencées.

Consignez la capacité de la liste locale, l’accusé de mise à jour, le traitement des expirations, la persistance après redémarrage et le comportement lorsque le stockage est plein. Testez un support connu mais jamais utilisé sur la borne, ainsi qu’un support déjà autorisé sur celle-ci. Cela permet d’établir sur quel mécanisme local le déploiement repose réellement.

Incluez la reconnexion dans le test. Vérifiez comment les transactions hors ligne parviennent au système central, comment elles sont rapprochées et ce qu’il advient d’une session en cours si le système central refuse son support après le rétablissement de la connexion. Convenez avec le propriétaire du site de l’exposition opérationnelle et financière acceptable.

6. Choisir délibérément le modèle de sécurité des supports

Demandez si le lecteur se contente de lire un identifiant ou s’il effectue une authentification cryptographique avec le support. Dans une architecture fondée uniquement sur l’UID, l’acceptation d’un identifiant correspondant ne démontre pas la possession d’un secret cryptographique. Acheter une puce dotée de fonctions de sécurité n’apporte de valeur que si le lecteur et l’application déployés utilisent ces fonctions.

Lorsqu’une authentification cryptographique de la carte est requise, documentez l’application prise en charge, la propriété des clés, la procédure de provisionnement, la procédure de remplacement et les responsabilités de migration. Excluez les secrets des fichiers de remise des UID. Le guide de sécurité RFID du NIST, section 5.3.1, décrit la distinction entre identifiants et contrôles d’authentification. Ce document de référence a été publié en 2007 ; utilisez la documentation produit actuelle pour sélectionner les algorithmes et mécanismes de gestion des clés pris en charge.

Sécurisez séparément la liaison entre la borne et le système central. Le Security Operations Guide actuel de l’OCA, sections 4.2 et 4.4, décrit Security Profile 2 comme TLS avec Basic Authentication et Profile 3 comme TLS avec certificats côté client, et traite du stockage des données d’authentification. Confirmez le profil de transport déployé, la validation des certificats et la gestion des données d’authentification de la borne. Ces paramètres protègent une autre liaison que celle entre la carte et le lecteur.

7. Ajouter l’autorisation d’itinérance seulement si le service l’exige

Une installation privée sur un lieu de travail peut n’avoir besoin que du registre de supports de sa propre plateforme. L’itinérance ajoute une autre frontière : l’opérateur des points de recharge, ou CPO, doit obtenir une autorisation du fournisseur de services de mobilité électrique concerné, ou eMSP, via l’intégration prise en charge et l’accord commercial applicable.

Dans OCPI 2.3.0, un enregistrement de jeton contient les identifiants de pays et de partie du fournisseur propriétaire, un UID de jeton, un type, une validité et une politique de liste blanche. La politique ALLOWED_OFFLINE concerne la communication entre le CPO et l’eMSP. La perte de liaison entre une borne et le CSMS est une panne distincte. Testez les deux frontières si elles existent toutes deux.

Le module Tokens distingue également un jeton valide d’un jeton autorisé à un emplacement donné. L’invalidation se propage par un jeton mis à jour avec valid: false ; la suppression des jetons via cette interface n’est pas le mécanisme prévu. Vérifiez le module Tokens officiel d’OCPI 2.3.0 par rapport à la version convenue avec votre partenaire.

Pour le pilote, nommez l’émetteur et le réseau participant, établissez le chemin d’autorisation attendu et vérifiez la session et le relevé de recharge obtenus. Réutiliser la même carte physique pour plusieurs services exige toujours les enregistrements, les droits et les accords appropriés.

8. Vérifier le cycle complet des accès à la mise en service

Utilisez une matrice de tests dont les résultats attendus sont écrits avant l’exécution. Appliquez-la à chaque configuration distincte de matériel, de micrologiciel et de système central, puis contrôlez par sondage le parc installé par rapport à cette configuration approuvée.

Pour chaque exécution, conservez l’heure, les identifiants de borne et de connecteur, le micrologiciel, la référence de carte de test, la configuration effective, le résultat attendu, le résultat réel et le relevé de transaction pertinent. Masquez les données personnelles dans les justificatifs partagés hors de l’équipe d’exploitation.

Lorsqu’une carte est perdue, notez l’heure du signalement et celle à laquelle chaque système connecté a accusé réception du changement. Une borne déconnectée ne peut pas recevoir immédiatement une nouvelle révocation. L’exposition réelle dépend de son état d’autorisation stocké, des règles d’expiration et du comportement à la reconnexion. Traitez cet intervalle dans la procédure d’exploitation.

Diagnostiquer une lecture infructueuse à la bonne frontière

Recueillez une tentative échouée avec son horodatage et sa référence de carte, puis examinez les éléments disponibles. Ces vérifications ciblent l’enquête sans supposer que tous les refus ont la même cause.

Exemple de déploiement pour un dépôt de flotte

Prenons un dépôt fictif de 60 conducteurs, 12 points de recharge et deux modèles de bornes. L’exploitant souhaite attribuer l’accès à chaque conducteur, le limiter au dépôt et permettre aux conducteurs approuvés de recharger pendant une panne du système central.

Commencez par cinq échantillons de supports d’identification. Sur chaque modèle de borne, relevez l’identifiant transmis et convenez de sa correspondance avec le fichier du fournisseur. Enregistrez les échantillons dans un compte pilote, attribuez l’accès au dépôt et confirmez le centre de coûts prévu.

Si l’équipement prend en charge une liste locale administrée, préchargez les supports du pilote et notez la version acquittée. Pour cette politique proposée, laissez désactivée l’acceptation des supports inconnus hors ligne. Déconnectez la borne du CSMS dans le cadre d’un test contrôlé, puis essayez une carte préchargée, une carte inconnue et une carte révoquée dont l’état local obsolète a été délibérément documenté. Rétablissez la connexion et vérifiez la mise à jour et les relevés de transaction.

Effectuez les tests de refus en ligne, d’arrêt de session et de facturation sur les deux modèles. Une fois le pilote validé, rapprochez le fichier de production des 60 cartes avec le registre du système central, résolvez les exceptions et distribuez les cartes avec une procédure simple de signalement des pertes. Répétez les tests de réception pertinents après toute modification importante du micrologiciel, du mode du lecteur ou de la plateforme.

Questions à résoudre avant de commander

Les cartes RFID de recharge doivent-elles être programmées ?

Pour une architecture qui lit l’UID existant de la carte, la configuration peut consister à enregistrer cette valeur et à attribuer l’accès dans la plateforme. Une architecture utilisant une application protégée peut nécessiter une personnalisation des cartes et une configuration coordonnée des lecteurs. Définissez précisément le fonctionnement du lecteur avant de commander l’un ou l’autre de ces services.

Un badge de salarié existant peut-il aussi déverrouiller une borne ?

Cela peut être possible si le lecteur prend en charge la technologie du badge, si l’identifiant nécessaire est disponible et stable, et si la plateforme permet son enregistrement. Obtenez l’accord du responsable du système de badges et testez de vrais échantillons. À titre d’exemple d’enrôlement propre à une plateforme, la documentation Easee sur les comptes et les clés locales décrit des périmètres d’enregistrement distincts et met en garde contre les identifiants changeants.

Une carte fonctionnera-t-elle sur tous les réseaux de recharge ?

Établissez individuellement les réseaux visés. La lisibilité physique, l’enregistrement du support, les droits du compte et les éventuels accords d’itinérance font tous partie des critères de réception. Testez le réseau participant plutôt que de déduire la couverture de l’apparence de la carte.

Que faut-il transmettre au fournisseur de cartes ?

Fournissez les exigences du lecteur, la correspondance d’identifiants validée sur l’échantillon, le plan de numérotation visible, les spécifications de matériau et d’impression, la quantité et le format convenu de livraison des données. Indiquez la personne responsable de l’importation dans le système central et de la réception des échantillons. Transférez les secrets d’application selon une procédure de provisionnement sécurisée convenue séparément lorsque l’architecture l’exige.

Préparer une spécification d’échantillon pour votre déploiement

Réunissez dans une même spécification le modèle de borne et son micrologiciel, le nom du système central et la version du protocole, le mode de support requis, la représentation confirmée de l’identifiant et la politique hors ligne prévue. Utilisez le laboratoire d’identification ChargeRFID pour examiner la remise des données et demandez des échantillons finis pour votre pilote. Approuvez ensemble le support physique et son parcours d’accès complet avant de lancer la commande de production.