Abonnements multi-CPO : impacts techniques sur l'infrastructure IRVE
Plugsurfing travaille sur des modèles d'abonnement valables chez plusieurs CPO. Cette évolution nécessite des ajustements techniques profonds sur les protocoles OCPP, la supervision et la gestion des identités.
Résumé rapide
Plugsurfing explore des modèles d'abonnement applicables chez plusieurs opérateurs de recharge (CPO). Cette approche, qui dépasse le simple roaming, implique des défis techniques majeurs en matière d'interopérabilité, de gestion des identités et de supervision centralisée. L'analyse technique révèle des impacts sur OCPP, les systèmes de backoffice et la communication véhicule-borne.
Contexte
Dans un écosystème de recharge fragmenté, l'utilisateur final doit souvent gérer plusieurs comptes et formules tarifaires. Les agrégateurs comme Plugsurfing, historiquement focalisés sur le roaming (accès ponctuel), évoluent vers des modèles d'abonnement unifiés. L'objectif est de proposer un forfait unique permettant d'accéder aux réseaux de plusieurs CPO partenaires, avec des avantages tarifaires ou des conditions privilégiées. Cette transition, évoquée par Wilhelm Henriksson de Plugsurfing, ne se limite pas à une simple interface commerciale. Elle requiert une intégration technique profonde entre les systèmes des différents CPO, les plateformes d'agrégation et les bornes sur le terrain. Les acteurs concernés sont les CPO, les eMSP (Mobility Service Providers), les installateurs gérant l'intégration technique, et les fabricants de matériel dont le firmware doit supporter ces nouvelles logiques.
Analyse
Le déploiement d'un abonnement valable sur plusieurs réseaux est un problème d'ingénierie système avant d'être un modèle commercial. Il repose sur trois piliers techniques interconnectés.
La gestion centralisée de l'identité et de l'autorisation
Dans un modèle roaming classique, l'autorisation est gérée par le CPO qui héberge la borne, après une vérification via l'agrégateur (eMSP). Avec un abonnement multi-CPO, la logique d'autorisation et de facturation devient distribuée.
- Rôle d'OCPP : Le protocole OCPP, notamment dans sa version 2.0.1, définit les messages
AuthorizeetTransactionEvent. Pour un abonnement, l'agrégateur doit pouvoir envoyer un token d'identification (ex :idTokende typeISO14443) qui est reconnu et accepté par le système du CPO. Cela nécessite une configuration spécifique dans leLocalAuthorizationListde la borne ou une autorisation en temps réel via le backend du CPO. - ISO 15118 et le Plug & Charge : À terme, les modèles d'abonnement pourraient s'appuyer sur le standard ISO 15118 et sa fonctionnalité Plug & Charge. Le contrat d'abonnement (y compris les CPO autorisés) pourrait être intégré dans le certificat du véhicule. À la connexion, la borne identifie automatiquement le véhicule abonné et applique les conditions contractuelles sans intervention de l'utilisateur. Cela implique une harmonisation des politiques de certification entre les différents acteurs du réseau.
L'harmonisation des données de transaction et de tarification
La facturation d'un abonnement nécessite une vue unifiée des sessions, quelle que soit la borne utilisée.
- Format des données OCPP : Les messages
MeterValueset leStopTransactiondoivent contenir des données normalisées (kWh, durée, puissance max) pour permettre une agrégation et une facturation cohérente par la plateforme d'abonnement. Des écarts dans la granularité ou la précision des mesures entre différents modèles de bornes peuvent compliquer le calcul. - Cadre tarifaire complexe : L'abonnement peut mixer un coût fixe mensuel avec un prix au kWh variable selon le CPO ou le type de borne (AC, DC). Le système de supervision de l'agrégateur doit être capable de recevoir, via les API des CPO, les tarifs applicables en temps quasi-réel pour chaque session et les appliquer à la logique d'abonnement.
La supervision et la maintenance du service
L'agrégateur devient responsable de la qualité de service perçue par l'abonné sur l'ensemble des réseaux partenaires.
- Monitoring multi-sources : La plateforme de supervision de l'agrégateur doit agréger les statuts des bornes (
Heartbeat,StatusNotification) de multiples backends CPO via leurs API. Elle doit pouvoir identifier si une panne est localisée à une borne, affecte un réseau entier, ou est liée à un problème de communication entre le CPO et l'agrégateur. - Gestion des mises à jour : Les évolutions du modèle d'abonnement (ajout d'un CPO, changement de tarifs) doivent être propagées à l'ensemble de l'écosystème. Cela peut nécessiter des mises à jour de configuration (
ChangeConfigurationOCPP) sur les bornes, notamment pour modifier les listes d'autorisation locales, ou des synchronisations entre les bases de données des différents backends.
Impact marché et technique
Pour les CPO, ce modèle implique d'exposer des API robustes, sécurisées et normalisées pour l'échange de données de session, de statut et de tarification en temps réel. Ils perdent une partie du contrôle direct sur la relation client et la tarification finale, mais gagnent en volume d'utilisation potentiel. Leur système de supervision doit pouvoir isoler les sessions issues d'abonnements externes pour le reporting et le support.
Pour les installateurs et mainteneurs IRVE, la complexité augmente. Une borne doit être configurée pour accepter non seulement les tokens du CPO propriétaire, mais aussi ceux des agrégateurs partenaires. Cela peut influencer le choix du firmware et des paramètres OCPP lors de l'installation. Le dépannage d'une session refusée pour un abonné nécessite de vérifier la chaîne d'autorisation depuis la borne jusqu'au backend de l'agrégateur.
Pour les fabricants de matériel (Hardware Manufacturers), la pression pour supporter les dernières versions d'OCPP (2.0.1+) et d'ISO 15118 s'accentue. Le firmware doit offrir une flexibilité suffisante pour gérer plusieurs sources d'autorisation et permettre des mises à jour de configuration à distance fiables. La sécurité des échanges de données (tokens, certificats) devient critique.
Pour les gestionnaires de flottes, un tel modèle d'abonnement pourrait simplifier la gestion et le contrôle des coûts de recharge sur des territoires étendus, à condition que la couverture réseau des CPO partenaires soit suffisante et que le reporting fourni par l'agrégateur soit détaillé et fiable.
Conclusion
Les abonnements multi-CPO représentent une étape logique vers une expérience utilisateur simplifiée, mais constituent un défi d'intégration systémique. Leur succès technique repose sur une interopérabilité poussée des protocoles (OCPP, ISO 15118), une architecture d'échange de données sécurisée et normalisée entre backends, et une supervision capable de gérer un écosystème distribué. Pour les CPO, c'est une opportunité d'augmenter l'utilisation de leur réseau, au prix d'une standardisation accrue de leurs interfaces. Pour l'ensemble de la chaîne de valeur, cela renforce la nécessité de concevoir les infrastructures IRVE avec une approche ouverte et interconnectée dès le départ.
FAQ
Questions fréquentes
- Quels sont les prérequis OCPP pour un abonnement multi-CPO ?
- L'idéal est OCPP 2.0.1 pour sa gestion avancée des tokens (`IdToken`, types multiples), des messages de tarification (`CostUpdated`) et des autorisations locales. OCPP 1.6J peut être utilisé avec des extensions propriétaires, mais cela limite l'interopérabilité. La borne doit supporter l'envoi de `MeterValues` granulaires et l'acceptation d'autorisations via le backend (ou une liste locale mise à jour régulièrement).
- Comment l'ISO 15118 et le Plug & Charge changent-ils la donne ?
- Ils permettent une authentification et une autorisation totalement automatiques à la prise, sans carte ou smartphone. Un abonnement multi-CPO pourrait être codé dans le certificat du véhicule, indiquant à la borne chez quels CPO le forfait est valable. Cela élimine les problèmes de connectivité réseau pour l'autorisation, mais nécessite une infrastructure à clé publique (PKI) commune ou interconnectée entre les différents CPO et l'agrégateur, ce qui est complexe à mettre en place.
- Quel est l'impact sur la supervision des bornes pour un installateur ?
- La supervision doit désormais distinguer l'origine des sessions. Une panne peut provenir de la borne, du réseau du CPO, ou de la plateforme de l'agrégateur. L'installateur doit avoir accès aux logs OCPP de la borne pour vérifier les messages `Authorize` et `StartTransaction`, et potentiellement collaborer avec les équipes techniques du CPO et de l'agrégateur pour diagnostiquer un problème affectant spécifiquement les abonnés.