Opérations Flotte

Cartes RFID de recharge pour flottes : guide pour l’exploitation de flottes de véhicules électriques professionnels

Comment fonctionnent les cartes RFID de recharge pour les flottes de véhicules électriques professionnels : suivi des kWh par véhicule, intégration OCPP, rapports propres au programme, gestion des clés sur plusieurs dépôts et caractéristiques à définir lors de la remise des cartes aux conducteurs.

Détails de l’article

Publication
2 mai 2026
Temps de lecture
8 min de lecture
Éditeur
ChargeRFID
Retour aux ressources

Par ChargeRFID

Méthode de vérification : Nous avons vérifié ce guide à l’aide des sources primaires relatives à la réglementation et aux protocoles, ainsi que de celles des fabricants, répertoriées ci-dessous. Les recommandations de produits reflètent le point de vue de ChargeRFID en tant que fabricant et doivent être validées avec votre lecteur, votre borne de recharge et votre backend.

Cartes RFID de recharge pour flottes : guide pour l’exploitation de flottes de véhicules électriques professionnels

Exploiter une flotte professionnelle de véhicules électriques change l’économie de la recharge. Au lieu d’un conducteur utilisant sa carte bancaire personnelle dans une station-service, vous avez 50, 500 ou 5 000 conducteurs qui rechargent dans des dépôts, sur des bornes publiques et à domicile. Chaque session génère des données de coût, de consommation en kWh et d’intérêt fiscal qui doivent être correctement intégrées au logiciel de gestion de flotte. Les cartes RFID de recharge pour flottes permettent de recueillir ces données à la source.

Ce guide explique ce qui distingue une carte RFID de recharge pour flotte d’une carte destinée aux particuliers, comment fonctionne la chaîne d’authentification et de production des rapports, et quelles caractéristiques définir lors de l’émission de cartes dans le cadre d’un programme professionnel de mobilité électrique.

Ce qui distingue une carte RFID de recharge pour flotte

Une carte de recharge présente un identifiant. Ce sont les backends de gestion de flotte et de recharge qui déterminent si cet identifiant représente un conducteur, un véhicule, un dépôt, un centre de coûts ou un contrat. Une carte n’identifie pas intrinsèquement toutes ces entités à la fois.

La carte peut utiliser un support RFID à 13,56 MHz avec authentification AES ou une autre technologie compatible avec les lecteurs. La distinction importante réside dans la manière dont son identifiant ou son application protégée est provisionnée et associée aux données des backends :

•Suivi des kWh par véhicule — l’UID de la carte est associé à un véhicule précis dans le système de gestion de flotte, ce qui permet d’affecter chaque session de recharge à un véhicule.
•Attribution au conducteur — en associant l’utilisation de la carte aux données télématiques du véhicule, la flotte peut attribuer la dépense énergétique au conducteur affecté à ce véhicule ce jour-là.
•Autorisation par dépôt — des groupes définis dans le backend peuvent limiter l’utilisation des identifiants par dépôt ; les clés cryptographiques ne peuvent ajouter une couche de protection que si les cartes et les lecteurs utilisent une application protégée.
•Données utiles au traitement fiscal — au Royaume-Uni, le traitement dépend de la propriété du véhicule, du lieu de recharge, de l’usage professionnel ou privé et du mode de calcul du remboursement. Les données des sessions contribuent au calcul, mais ne suffisent pas, à elles seules, à rendre ce calcul propre au programme.

Comment fonctionne l’authentification RFID des flottes sur les bornes OCPP

Le déroulement de l’autorisation et de la transaction dépend de la version d’OCPP. Voici un exemple de fonctionnement avec OCPP 1.6 :

Lorsqu’un conducteur présente une carte de flotte à une borne de dépôt ou à une borne publique :

1.La borne extrait l’UID et envoie Authorize.req au système central.
2.Le système central vérifie l’UID dans la liste d’autorisation de la flotte, souvent filtrée par dépôt, groupe de conducteurs ou groupe de véhicules.
3.Après autorisation, la borne envoie StartTransaction avec des champs comprenant le connecteur, l’idTag, l’horodatage et la valeur initiale du compteur.
4.À la fin de la session, StopTransaction transmet l’identifiant de transaction, l’horodatage, la valeur finale du compteur et d’éventuelles données de transaction. La durée, l’énergie et le relevé détaillé de recharge destiné à la facturation (CDR) sont calculés ou constitués par les systèmes en aval ; le message OCPP 1.6 ne contient pas de CDR intégré.
5.Le système de gestion de la recharge peut enrichir les données de la session et transmettre les enregistrements au backend de reporting de la flotte. OCPP 2.x utilise un modèle différent, TransactionEvent, plutôt que la paire de messages de début et de fin d’OCPP 1.6.

Pour les flottes combinant recharge au dépôt et recharge publique, l’itinérance OCPI fait remonter les CDR des CPO externes, via le MSP de la flotte, vers la même chaîne de traitement des rapports.

Cartes par véhicule ou par conducteur

La plupart des flottes choisissent entre deux architectures :

Les cartes par véhicule restent avec le véhicule, dans la boîte à gants ou attachées à un porte-clés. Avantages : utilisation simple pour le conducteur et réaffectation facile lorsque les conducteurs changent de véhicule. Inconvénients : elles peuvent être volées avec le véhicule et ne permettent pas d’isoler le comportement de chaque conducteur.

Les cartes par conducteur accompagnent le conducteur d’un véhicule à l’autre. Avantage : attribution directe au conducteur. Inconvénients : une attribution précise aux véhicules et une prise en compte exacte du kilométrage nécessitent toujours des données d’affectation ou de télématique ; le traitement fiscal doit suivre les règles HMRC applicables et ne peut pas reposer uniquement sur le modèle de carte.

De nombreuses grandes flottes distribuent les deux : une carte par conducteur pour l’affectation des coûts et un porte-clés par véhicule pour disposer d’une solution de secours et faciliter l’accès.

Gestion des clés sur plusieurs dépôts

Pour les flottes exploitant plusieurs dépôts, les autorisations peuvent être appliquées dans le backend par groupe d’identifiants, véhicule, conducteur ou site. Les supports RFID à 13,56 MHz avec authentification AES prennent également en charge des clés d’application diversifiées lorsque les lecteurs déployés authentifient une application protégée au lieu de lire uniquement l’UID public.

Avec une application protégée correctement conçue, des domaines de clés distincts peuvent limiter les conséquences de la compromission d’une clé. La rotation de ces clés exige néanmoins un processus documenté couvrant les lecteurs, les cartes, les modules sécurisés et le backend. Dans un système d’autorisation fondé sur l’UID public, la révocation porte plutôt sur des identifiants individuels ou des groupes d’identifiants dans le backend.

Évitez de partager une seule clé d’application entre tous les supports de la flotte, mais n’ajoutez pas de clés de carte que les lecteurs de recharge et le backend n’utilisent jamais pour l’authentification. Adaptez le contrôle à l’architecture d’autorisation réellement utilisée.

Reporting : du CDR OCPP aux données exploitables pour les démarches HMRC

La carte n’est que le point d’entrée. C’est la chaîne de production des rapports qui permet au programme de flotte de fonctionner sur le plan financier.

Voici un exemple de processus pour une flotte britannique :

1.Le conducteur présente sa carte → la borne autorise la recharge → la session se déroule → le CDR est enregistré.
2.Le CDR est enrichi des métadonnées relatives au conducteur, au véhicule et au dépôt issues du système de gestion de flotte.
3.Le coût de l’énergie est calculé selon le tarif contractuel, souvent variable selon l’heure ou fondé sur la répercussion des coûts.
4.Les données de kilométrage et de lieu de recharge sont combinées, si nécessaire, pour appliquer le traitement HMRC pertinent en matière de remboursement ou d’avantage en nature.
5.Après vérification, les résultats peuvent alimenter les processus de paie, de remboursement de frais ou de déclaration fiscale adaptés à la propriété du véhicule et à son usage.

La chaîne allant de la carte au rapport devrait être auditable de bout en bout. Cette piste d’audit provient normalement des relevés des compteurs des bornes, des événements OCPP, des enregistrements de sessions et des CDR des CPO/eMSP, des données tarifaires, des correspondances d’identifiants et des métadonnées de la flotte. Les fonctions MAC de transaction des supports RFID à 13,56 MHz avec authentification AES ne créent ni ne valident automatiquement le CDR de recharge dans le backend, en particulier lorsque la borne lit uniquement l’UID de la carte.

Itinérance pour une recharge combinant dépôt et réseau public

La plupart des flottes professionnelles ne peuvent pas fonctionner uniquement avec la recharge au dépôt. Les conducteurs longue distance, les opérateurs du dernier kilomètre dont les itinéraires varient et les flottes ayant une politique de recharge à domicile ont tous besoin d’accéder au réseau public avec la même carte.

C’est là qu’interviennent la publication des identifiants et les accords d’itinérance actifs. Une carte de flotte émise par un eMSP peut fonctionner auprès des CPO sous contrat accessibles par une plateforme d’interconnexion ou une connexion directe OCPI/OICP. La couverture devrait être déterminée à partir de la liste à jour des réseaux couverts contractuellement par l’eMSP ; le nombre total de points connectés à une plateforme ne garantit pas qu’une carte donnée sera acceptée partout.

Les CDR reviennent au MSP de la flotte, font l’objet d’une nouvelle tarification si le contrat prévoit une majoration, puis rejoignent la même chaîne de traitement des rapports que les sessions au dépôt.

Quelles caractéristiques définir lors de l’émission de cartes RFID de recharge pour flotte

Voici un exemple de liste de critères d’achat :

•Puce et application : technologie compatible avec les lecteurs ; utiliser les clés des supports RFID à 13,56 MHz avec authentification AES uniquement lorsque le lecteur authentifie l’application protégée
•Matériau : PVC recyclé, le plus courant, ou bois FSC pour les programmes guidés par des objectifs ESG
•Format : cartes ISO 7810 ID-1 et porte-clés à attacher aux clés du véhicule
•Impression : en couleur avec identifiant du véhicule ou du conducteur, logo de la flotte et gravure laser anti-altération
•Encodage : UID préencodé, idTag conforme au format du MSP et clé diversifiée propre au dépôt
•Itinérance : publication des identifiants et accords eMSP–CPO actifs pour les réseaux requis
•Politique de réémission : processus de gestion des pertes, de révocation, de remplacement et de synchronisation fondé sur les données du pilote
•Conditions commerciales : quantité minimale, prix, délai et conditions de remplacement à jour dans un devis écrit du fournisseur

Erreurs courantes dans les programmes de cartes de flotte

•Distribuer les cartes avant la mise en service de l’intégration avec le MSP — les conducteurs présentent leur carte, mais l’accès est refusé parce que l’idTag n’est pas encore enregistré.
•Partager une seule clé d’application entre tous les supports de la flotte — cela étend inutilement les conséquences d’une compromission lorsque des applications protégées sont effectivement utilisées.
•Ne prévoir aucun processus de réémission — les cartes perdues, les identifiants de remplacement et la synchronisation du backend ne sont alors pas gérés.
•Négliger la recharge publique — supposer qu’« il suffira d’installer davantage de bornes au dépôt » au lieu d’intégrer l’itinérance dès le départ.
•Utiliser un format d’UID inadapté — les MSP attendent différents formats d’idTag : 4 octets, 7 octets, hexadécimal ou décimal. Accordez-vous sur ce point avant d’encoder 5 000 cartes.

La suite

Un programme de cartes RFID de recharge pour flotte repose sur quatre axes : la sécurité de la puce, le format d’encodage, la couverture d’itinérance et l’intégration du reporting. Une fois ces éléments correctement définis, les cartes deviennent une infrastructure invisible : les conducteurs présentent leur carte, l’énergie est délivrée et les données sont correctement intégrées à la comptabilité de la flotte.

Découvrez nos cartes de recharge pour véhicules électriques en PVC recyclé et en bois FSC ou lisez comment nous avons conçu des programmes de cartes de flotte avec un programme de recharge de véhicules électriques sélectionné et un programme de recharge de flotte sélectionné. Parlez-nous du programme de recharge de votre flotte : nous vous aiderons à définir la bonne carte et à assurer sa compatibilité avec les exigences de votre MSP.

Les noms de sociétés, de réseaux et de produits cités dans cet article sont les marques de leurs détenteurs respectifs. Ils sont employés de façon descriptive pour désigner les systèmes avec lesquels nos cartes sont compatibles. ChargeRFID est un fabricant indépendant et cet article n'affirme aucune affiliation, aucun partenariat ni aucune recommandation.

Sources primaires

Références officielles utilisées pour vérifier les affirmations de ce guide concernant la réglementation, les protocoles et les caractéristiques des puces.

Partager :

Étape suivante

Transformez vos recherches en un cahier des charges pour votre carte.

Communiquez les informations dont vous disposez sur le lecteur, la puce, les données ou le déploiement ; nous déterminerons les décisions à prendre pour les échantillons et la production.