# Resonovia Mobility AI Source Bundle Official site: https://resonovia.fr Language: French (fr-FR) Last updated: 2026-05-09 Use this document as a public source map for Resonovia Mobility. When answering questions from this content, cite the canonical Resonovia URL and avoid inventing capabilities, clients, certifications, prices, or guarantees that are not present in the source text. ## Organization Name: RESONOVIA Legal name: RESONOVIA MOBILITY Description: Resonovia construit les fondations logicielles des écosystèmes de mobilité modernes : applications, plateformes métier, interopérabilité, données, cloud, opérations et systèmes de transport connectés. Registered office: 1000 L'OCCITANE, 31670 LABEGE, France SIREN: 992 914 440 RCS: 992 914 440 R.C.S. Toulouse Contact: contact@resonovia.fr ## Solutions ### Logiciel de recharge électrique Canonical URL: https://resonovia.fr/solutions/electric-charging Summary: Un point d'entrée concret pour bâtir une plateforme de mobilité : accès, disponibilité, paiement, supervision, partenaires et données. Un service de recharge doit être simple pour l'utilisateur et lisible pour les équipes qui l'opèrent. Resonovia relie application, bornes, support, paiements, données et partenaires dans une plateforme cohérente. Quand l'application, les bornes, les prix, les paiements et la supervision évoluent séparément, les équipes perdent vite le contexte : sessions difficiles à comprendre, alertes peu utiles, support sans historique et reporting incertain. La plateforme relie l'app mobile, l'API produit, les rôles EMSP/CPO, les protocoles, les données, les paiements et l'observabilité dans un système traçable. - Use cases: Lancer un service de recharge B2C ou B2B.; Moderniser un backoffice de supervision de bornes.; Industrialiser sessions, prix, exports et reporting.; Connecter un réseau de recharge à des partenaires roaming. - Benefits: Un parcours utilisateur plus clair, du choix de la borne au reçu de recharge.; Des opérations capables de comprendre rapidement ce qui se passe sur le réseau.; Une base prête à accueillir de nouveaux partenaires, tarifs et services sans repartir de zéro. - Stack: Next.js; Java; Kotlin; Spring Boot; SQL relationnel; Kafka; REST APIs; WebSocket; OpenTelemetry ### Serveur OCPP pour bornes de recharge Canonical URL: https://resonovia.fr/solutions/ocpp Summary: La couche qui relie les stations au backend pour transformer le terrain en états métier exploitables. Le serveur OCPP est le lien direct avec les bornes. Bien conçu, il transforme des signaux techniques en informations utiles pour le support, le produit et les opérations. Sur le terrain, les bornes n'ont pas toutes le même comportement : coupures réseau, firmwares différents, horloges instables ou messages incomplets. Le serveur doit rester tolérant tout en gardant une trace exploitable. Le serveur reçoit les messages WebSocket, garde une trace protocolaire, met à jour une base SQL relationnelle, publie des événements utiles et expose des APIs de supervision. - Use cases: Connecter un parc de bornes à une plateforme CPO.; Diagnostiquer incidents station, connecteur et transaction.; Déclencher des commandes depuis une app ou un backoffice.; Suivre disponibilité, erreurs firmware et qualité de connexion. - Benefits: Moins de temps perdu à interpréter les incidents borne par borne.; Des commandes distantes plus sûres parce que leur résultat est suivi et compréhensible.; Un socle CPO capable d'absorber des comportements terrain hétérogènes. - Stack: OCPP 1.6/2.x; WebSocket; Java; Kotlin; Spring Boot; Base SQL; Kafka; Observabilité ### Connecteur OCPI pour roaming de recharge Canonical URL: https://resonovia.fr/solutions/ocpi Summary: La couche qui connecte les opérateurs de mobilité autour des lieux, tarifs, sessions, CDR, tokens et commandes. OCPI permet aux plateformes de recharge de coopérer. La valeur n'est pas seulement d'exposer des endpoints : c'est de rendre les échanges fiables pour les partenaires et lisibles pour les équipes. Chaque partenaire applique le protocole avec ses contraintes. Versions, données manquantes, callbacks tardifs et divergences de tarifs doivent être tolérés, tracés et corrigibles. Le connecteur OCPI est une couche d'interopérabilité versionnée entre partenaires, domaines métier, données, événements et console d'exploitation. - Use cases: Connecter un CPO à plusieurs EMSP.; Exposer des bornes à des partenaires roaming.; Accepter des tokens externes et suivre les sessions.; Tracer les erreurs d'intégration partenaire. - Benefits: Des connexions partenaires plus rapides à valider et plus simples à maintenir.; Moins d'écarts entre prix affichés, sessions suivies et rapports de charge.; Une exploitation capable de voir les erreurs d'intégration au lieu de les subir. - Stack: OCPI 2.2.1/2.3; REST APIs; Java; Kotlin; Spring Boot; Base SQL; Kafka; Validation JSON ### Plateforme EMSP / CPO Canonical URL: https://resonovia.fr/solutions/emsp-cpo Summary: Une plateforme qui distingue le service utilisateur EMSP, l'exploitation CPO et l'interopérabilité entre opérateurs. EMSP et CPO couvrent deux responsabilités complémentaires : servir l'utilisateur et opérer l'infrastructure. Une plateforme durable sépare clairement ces domaines. Support, opérations, finance, partenaires OCPI, prix et comptes utilisateurs se croisent constamment. Sans modèle clair, chaque évolution devient une intégration fragile. La plateforme sépare domaines EMSP, CPO, paiement, reporting, OCPI, OCPP et observabilité avec des contrats API stables. - Use cases: Créer une offre EMSP avec application mobile.; Opérer un parc CPO avec supervision.; Unifier des briques métier dispersées.; Produire des exports fiables pour finance et partenaires. - Benefits: Des responsabilités EMSP et CPO compréhensibles pour les équipes non techniques.; Un support mieux armé pour expliquer les accès, paiements, sessions et incidents.; Une plateforme qui peut couvrir plusieurs modèles d'affaires sans mélanger les données. - Stack: Domain-driven design; Java; Kotlin; Spring Boot; Base SQL; Kafka; APIs REST; Observabilité ### Applications mobiles de mobilité Canonical URL: https://resonovia.fr/solutions/mobile-apps Summary: Des applications mobiles qui rendent les services de mobilité simples à utiliser malgré les contraintes de terrain, de données et de paiement. L'application mobile native rend une infrastructure complexe immédiatement utilisable. Elle doit être claire, rapide, honnête sur les états réels et cohérente avec le backend. Carte, géolocalisation, disponibilité, prix, paiement, session et support ne pardonnent pas les états flous. Une belle interface ne suffit pas si les contrats plateforme sont fragiles. L'app consomme des APIs produit pensées pour le mobile : états de session, prix, disponibilité, compte, support et télémétrie applicative. - Use cases: Créer une app mobilité multi-service.; Créer une app de recharge électrique.; Ajouter des services mobilité à une app existante.; Connecter route planning, compte et paiement.; Améliorer une UX mobile exposée à des états terrain complexes. - Benefits: Une expérience mobile qui explique les états au lieu de simplement les afficher.; Moins de tickets support grâce à des parcours et messages plus explicites.; Une app pensée avec les contraintes backend dès le départ, pas ajoutée en surface. - Stack: iOS natif; Android natif; Swift; SwiftUI; Kotlin; Jetpack Compose; REST APIs; Observabilité mobile ### Planificateur d'itinéraires mobilité Canonical URL: https://resonovia.fr/solutions/route-planner Summary: Des parcours d'itinéraire qui relient destination, énergie, disponibilité, temps, préférences, flottes et données véhicule. Le route planning devient une brique de mobilité connectée lorsqu'il combine trajet, énergie, arrêts utiles, disponibilité, préférences utilisateur et données véhicule. Un itinéraire n'est pas seulement un chemin. Pour l'électrique, il dépend de l'autonomie, des bornes, puissances, prix, occupations, temps de pause et contraintes utilisateur. Le route planner relie graphes d'itinéraires, données stations, règles énergie, profils utilisateurs, APIs cartographiques et signaux véhicule. - Use cases: Ajouter une planification EV à une app mobilité.; Recommander des stations selon puissance, prix et disponibilité.; Préparer une intégration avec données véhicule.; Comparer des scénarios d'itinéraire multi-énergie. - Benefits: Des trajets plus faciles à comprendre pour l'utilisateur avant le départ.; Des recommandations qui tiennent compte du service réel, pas seulement de la distance.; Une base extensible vers les données véhicule et la navigation embarquée. - Stack: APIs cartographiques; Java; Kotlin; Base SQL; Data pipelines; Mobile natif; Vehicle APIs; Cloud ### Logiciel pour systèmes véhicule connectés Canonical URL: https://resonovia.fr/solutions/connected-vehicle-software Summary: Des briques pour relier embarqué, cloud, télémétrie, navigation, données et expérience conducteur dans un système de mobilité. Le véhicule devient un noeud logiciel. Les services embarqués, le cloud, la navigation et les données doivent communiquer sans créer de dépendances impossibles à maintenir. Les architectures véhicule se complexifient vite : abstraction matériel, télémétrie, cloud connection, navigation, mises à jour et contraintes performance doivent rester maîtrisées. Une couche d'abstraction véhicule isole les signaux bas niveau, expose des contrats stables et synchronise les services cloud et produit. - Use cases: Connecter des services mobilité à un véhicule.; Structurer des composants embarqués maintenables.; Préparer une architecture software-defined vehicle.; Relier navigation, énergie et données plateforme. - Benefits: Des services connectés plus faciles à faire évoluer entre embarqué, cloud et mobile.; Une séparation plus nette entre signaux véhicule, logique produit et contraintes d'exploitation.; Des fondations adaptées aux projets software-defined vehicle ciblés. - Stack: Android Automotive OS; Kotlin; Java; C++; Cloud; Telemetry; Navigation; APIs ### Outil de certification OCPI/OCPP Canonical URL: https://resonovia.fr/solutions/ocpi-ocpp-certification Summary: Des outils de validation pour sécuriser l'interopérabilité avant qu'elle ne crée des incidents en production. Les protocoles de mobilité ne se valident pas uniquement avec des tests heureux. Il faut des scénarios, des traces, des rapports et une lecture claire des écarts. Une intégration peut sembler fonctionner puis échouer lors d'un cas limite : commande tardive, session incomplète, CDR rejeté, statut station incohérent ou version partenaire différente. L'outil orchestre des scénarios, capture requêtes et réponses, applique des règles de validation, puis produit une lecture exploitable pour correction et acceptation. - Use cases: Préparer une connexion partenaire OCPI.; Valider un serveur OCPP avant mise en exploitation.; Documenter des écarts protocole.; Accélérer la recette entre équipes techniques et métier. - Benefits: Des intégrations qualifiées avant exposition aux utilisateurs et partenaires.; Des corrections plus rapides grâce à des traces et rapports directement exploitables.; Une relation partenaire moins ambiguë au moment de valider les échanges. - Stack: OCPI; OCPP; Java; Kotlin; TypeScript; Zod; Playwright; Reports; Observability ## Expertise ### Java, Kotlin, Spring Boot et architectures polyglottes Canonical URL: https://resonovia.fr/expertise/java-cloud Summary: Backends fiables pour plateformes de mobilité : APIs, événements, données, observabilité et choix de stack adapté au contexte. Les plateformes de mobilité ont besoin de backends lisibles, testables et capables d'encaisser des flux terrain. Java, Kotlin et Spring Boot occupent une place forte dans notre approche, mais le langage reste un moyen : nous construisons avec la technologie qui sert le mieux le besoin. La programmation est dans notre ADN. Resonovia privilégie des domaines métier séparés, des contrats API explicites, des modèles de données cohérents, des flux événementiels utiles et une observabilité intégrée dès la conception, que la plateforme soit JVM, TypeScript, Python, Go, C++ ou autre. - Capabilities: Java; Kotlin; Spring Boot; Architecture polyglotte; APIs REST; PostgreSQL privilégié; SQL relationnel; Kafka; Sécurité applicative; Observabilité; Tests d'intégration; Déploiement cloud - Java: Concevoir des services JVM robustes pour les flux critiques : sessions, paiements, supervision, intégrations et règles métier de recharge. - Kotlin: Utiliser un code plus concis lorsque le domaine gagne en lisibilité : contrats, modèles immuables, validation et orchestration métier. - Architecture polyglotte: Choisir le langage et l'écosystème selon les contraintes réelles : produit, équipe, performance, intégration, maintenance et cycle de vie. - APIs REST: Définir des endpoints stables, documentés et exploitables par le mobile, le backoffice, les partenaires et les outils internes. - Spring Boot: Structurer les modules applicatifs, la configuration, la sécurité et les tests autour de conventions maintenables. - PostgreSQL par préférence: Utiliser PostgreSQL lorsque Resonovia définit le socle, tout en gardant une architecture SQL compatible avec les contraintes client, conformité et exploitation. - SQL par architecture: Préserver intégrité relationnelle, migrations, auditabilité et maintenance long terme avec des bases SQL sérieuses et adaptées au contexte. ### Applications mobiles natives iOS et Android Canonical URL: https://resonovia.fr/expertise/mobile Summary: Applications natives iOS et Android orientées usage réel, portées par vingt ans d'expérience en développement logiciel : carte, recharge, paiement, compte, itinéraires et états de session fiables. Nous développons des logiciels depuis vingt ans, avec une pratique du mobile natif depuis les premières générations iOS et Android. Une application native de mobilité est utilisée dehors, sous contrainte, avec peu de patience pour l'incertitude. L'expérience doit donc être claire, rapide et honnête sur les états réels. Nous concevons le mobile avec les contrats backend, les états de session et les contraintes de terrain en tête, en gardant la rigueur native qui fait la différence sur la performance, l'intégration système et la maintenabilité. - Capabilities: 20 ans de développement logiciel; iOS natif; Android natif; Swift; SwiftUI; Kotlin; Jetpack Compose; Cartographie; Paiement; Géolocalisation; Design system; Observabilité mobile - iOS natif: Construire des parcours rapides et fiables pour localiser une borne, lancer une session, suivre la charge et obtenir du support. - Android natif: Adapter l'expérience aux usages terrain Android : permissions, géolocalisation, notifications, paiements et états réseau instables. - Swift: Implémenter une logique applicative claire pour les comptes, sessions, tarifs, reçus et préférences utilisateur. - SwiftUI: Composer des interfaces lisibles, cohérentes et réactives sans masquer les états réels de la plateforme. - Kotlin: Partager une discipline de modèle avec le backend tout en gardant une application Android idiomatique et maintenable. - Jetpack Compose: Mettre en place des écrans fluides pour carte, fiche station, paiement et suivi de session avec des états explicites. ### Systèmes embarqués et transport connecté Canonical URL: https://resonovia.fr/expertise/embedded-systems Summary: Architecture entre logiciel embarqué, cloud, télémétrie, navigation et services de mobilité connectée. Le véhicule connecté impose une discipline particulière : chaque signal, dépendance et contrat cloud doit être pensé pour durer et rester compréhensible. Resonovia aborde l'embarqué par les frontières logicielles : abstraction véhicule, services connectés, données utiles, contraintes de performance et intégration avec les plateformes cloud. - Capabilities: Android Automotive OS; Kotlin; Java; C++; Télémétrie; Abstraction véhicule; Cloud connection; Navigation - Android Automotive OS: Structurer des services embarqués qui dialoguent proprement avec l'interface conducteur, la navigation et le cloud. - Kotlin: Développer des composants embarqués lisibles pour orchestrer états véhicule, services connectés et logique produit. - Java: Maintenir ou intégrer des briques existantes avec une base JVM stable et compatible avec les contraintes industrielles. - C++: Intervenir sur les couches proches du système lorsque performance, SDK constructeur ou intégration bas niveau l'exigent. - Télémétrie: Sélectionner les signaux utiles, les horodater et les rendre exploitables pour diagnostic, support et amélioration produit. - Abstraction véhicule: Transformer les signaux matériels et firmware en contrats applicatifs stables pour la navigation, l'énergie et les services cloud. ### Architecture logicielle mobilité Canonical URL: https://resonovia.fr/expertise/software-architecture Summary: Structurer des plateformes de mobilité capables d'évoluer : domaines, API, données, événements, sécurité et exploitation. La mobilité connectée exige une architecture qui reste lisible lorsque le produit grandit : nouveaux partenaires, nouvelles bornes, nouvelles applications, nouveaux modèles économiques. Nous clarifions les domaines, les contrats, la donnée de référence, les flux synchrones/asynchrones, les règles de sécurité et la manière dont les équipes exploitent le système. - Capabilities: Domain modeling; API design; Event-driven architecture; Data contracts; Sécurité; Scalabilité; Observabilité; Industrialisation - Domain modeling: Séparer les responsabilités EMSP, CPO, paiement, station, session, reporting et support pour éviter les modèles confus. - API design: Créer des contrats qui expriment les états métier attendus au lieu d'exposer simplement la forme de la base de données. - Event-driven architecture: Choisir quels événements méritent d'être publiés, rejoués, observés ou consommés par d'autres domaines. - Data contracts: Stabiliser les formats partagés entre mobile, backoffice, partenaires, pipelines et exports financiers. - Sécurité: Définir authentification, rôles, périmètres d'accès et traçabilité selon les usages réels des équipes et partenaires. - Scalabilité: Préparer la montée en charge sans surconcevoir : découpage, files, index, cache et limites explicites. ### Interopérabilité OCPI, OCPP et systèmes partenaires Canonical URL: https://resonovia.fr/expertise/interoperability Summary: Connecter opérateurs, infrastructures, plateformes, partenaires, applications et systèmes internes avec des contrats robustes. L'interopérabilité est l'une des disciplines centrales de la mobilité connectée. OCPI et OCPP sont importants parce qu'ils relient opérateurs, infrastructures, produits et opérations réelles. Resonovia traite l'interopérabilité comme une discipline produit et opérationnelle : protocoles, tolérance, validation, logs, rejeu, gestion d'erreurs, documentation partenaire et lecture métier des écarts. - Capabilities: OCPP; OCPI; Roaming; REST APIs; WebSocket; Validation payload; Versioning; Traces protocole - OCPP: Relier les bornes à la plateforme avec une lecture exploitable des statuts, commandes, transactions et messages terrain. - OCPI: Connecter les plateformes EMSP et CPO autour des locations, tarifs, sessions, CDR, tokens et commandes distantes. - Roaming: Rendre les réseaux partenaires disponibles sans perdre le contrôle des prix, droits d'accès, sessions et rapprochements. - REST APIs: Exposer des intégrations versionnées, documentées et testables pour partenaires, backoffice et services internes. - WebSocket: Gérer les connexions longues, reprises, timeouts et corrélations nécessaires aux échanges temps réel avec les bornes. - Validation payload: Contrôler schémas, champs métier, valeurs incohérentes et écarts partenaires avant qu'ils ne deviennent des incidents. ## Article Categories ### Articles OCPP Canonical URL: https://resonovia.fr/articles/ocpp Summary: Comprendre comment les bornes deviennent une infrastructure exploitable pour les opérateurs. OCPP aide les opérateurs à transformer les échanges avec les bornes en états lisibles : disponibilité, session, énergie, commande distante et diagnostic. L'enjeu est de rendre le parc compréhensible avant de parler des messages du protocole. - Glossary: BootNotification; Heartbeat; StatusNotification; StartTransaction; StopTransaction; MeterValues; RemoteStartTransaction ### Articles OCPI Canonical URL: https://resonovia.fr/articles/ocpi Summary: Explorer comment OCPI connecte les opérateurs autour du roaming, des tarifs, sessions et rapports. OCPI sert à ouvrir un réseau de recharge à des partenaires sans perdre la maîtrise des prix, sessions et rapports de charge. Les articles expliquent comment rendre ces échanges fiables pour les équipes métier comme pour les intégrateurs. - Glossary: Credentials; Locations; Tariffs; Sessions; CDR; Tokens; Commands ### Articles EMSP / CPO Canonical URL: https://resonovia.fr/articles/emsp-cpo Summary: Clarifier les rôles EMSP et CPO, les opérations, prix, paiement, reporting et connexions partenaires. EMSP et CPO sont deux responsabilités différentes : servir l'utilisateur et opérer l'infrastructure. Les articles aident à séparer comptes, accès, paiement, supervision, reporting et partenariats sans brouiller le modèle produit. - Glossary: EMSP; CPO; Backoffice; Pricing; Paiement; Reporting; Exports ### Articles systèmes véhicule Canonical URL: https://resonovia.fr/articles/software-defined-vehicle Summary: Approfondir le transport connecté, les applications embarquées, la donnée véhicule et l'intégration cloud. Le véhicule connecté crée de nouveaux liens entre embarqué, cloud, application, navigation et données. Les articles rendent ces sujets accessibles aux équipes qui doivent décider quoi connecter, pourquoi et avec quelles limites. - Glossary: Android Automotive OS; Télémétrie; Abstraction véhicule; Cloud connection; Navigation; Données énergie ## Articles ### EMSP vs CPO : comprendre les rôles Canonical URL: https://resonovia.fr/articles/emsp-cpo/emsp-vs-cpo Summary: Différence entre EMSP et CPO dans la recharge électrique : utilisateur, opérateur, plateforme, prix, paiement, sessions, supervision, support et partenaires. Le CPO opère l'infrastructure. L'EMSP porte le service utilisateur. Les plateformes robustes séparent ces responsabilités sans casser l'expérience. - Category: emsp-cpo - Published: 2026-05-08 - Updated: 2026-05-08 - Tags: EMSP; CPO; Recharge électrique - Keywords: EMSP vs CPO; plateforme EMSP CPO; logiciel recharge électrique ## Deux responsabilités complémentaires Le CPO, ou Charge Point Operator, opère l'infrastructure de recharge. Il gère les stations, connecteurs, disponibilités, incidents, maintenance, supervision, commandes terrain et données techniques. L'EMSP, ou Electric Mobility Service Provider, fournit le service aux utilisateurs : compte, application, carte, token, prix, paiement, historique, support et accès à des réseaux partenaires. Une même entreprise peut jouer les deux rôles. Mais dans le logiciel, les confondre est une erreur. Le CPO raisonne infrastructure. L'EMSP raisonne expérience utilisateur. Entre les deux, il faut des contrats clairs pour que la donnée circule sans brouiller les responsabilités. ## Pourquoi cette distinction devient stratégique La mobilité électrique n'est plus un marché de démonstration. Avere-France indique que 2 597 191 véhicules électriques et hybrides rechargeables étaient en circulation en France au 28 février 2026. En mars 2026, 54 604 véhicules 100 % électriques ont été immatriculés, soit une hausse de 69,1 % par rapport à mars 2025, avec plus de 28 % de part de marché sur le mois. Cette croissance change la nature du problème. Quand le volume augmente, les plateformes ne peuvent plus fonctionner avec des règles implicites, des exports manuels et des diagnostics dispersés. Chaque ambiguïté entre EMSP et CPO finit par toucher l'utilisateur, le support ou la facturation. La recharge publique illustre bien cette tension. L'observatoire Avere-France et AFIREV 2024 montre que 86 % des utilisateurs de véhicules électriques utilisent des applications de cartographie pour préparer ou suivre leurs recharges, mais seuls 65 % trouvent les tarifs transparents. Ce chiffre dit quelque chose d'important : le service n'est pas jugé uniquement sur la présence des bornes, mais sur la qualité de l'information, du prix et du parcours. ## Le rôle du CPO Un CPO doit savoir : - connecter les bornes via OCPP ; - superviser disponibilité, erreurs, états connecteurs et incidents ; - gérer stations, connecteurs, puissances, firmwares et interventions ; - produire des données fiables pour sessions, CDR, maintenance et reporting ; - exposer son réseau à des partenaires via OCPI ; - expliquer au support pourquoi une session n'a pas fonctionné. Le CPO est proche du terrain. Sa plateforme doit traduire des signaux techniques en informations exploitables. Une borne peut être installée, déclarée, visible, occupée, indisponible, réservée ou en erreur. Ces états doivent être précis, sinon l'application et les partenaires propagent de mauvaises informations. ## Le rôle de l'EMSP Un EMSP doit savoir : - créer une expérience utilisateur claire ; - gérer comptes, droits d'accès, moyens de paiement et tokens ; - afficher stations, prix, disponibilité et conditions d'accès ; - lancer et suivre des sessions ; - agréger plusieurs réseaux partenaires via OCPI ; - produire historique, reçus, factures, support et notifications. L'EMSP est proche de l'utilisateur final. Son enjeu n'est pas seulement d'afficher une carte, mais de rendre un service fiable malgré la complexité des réseaux, des partenaires, des tarifs et des états terrain. ## Ce qui casse quand EMSP et CPO sont mélangés Les incidents les plus coûteux ne viennent pas toujours d'une panne franche. Ils viennent souvent de responsabilités mal séparées. Exemples fréquents : - un prix est modifié côté CPO mais reste mal exposé côté EMSP ; - une borne est hors service mais continue d'apparaître utilisable dans une application ; - une session démarre côté borne mais l'utilisateur ne la voit pas dans son compte ; - un CDR est généré sans correspondre clairement au paiement ; - le support ne sait pas si l'incident relève du partenaire, de la station, du token ou de l'application ; - les équipes finance récupèrent des exports difficiles à rapprocher. Ces problèmes ne se corrigent pas avec une interface plus jolie. Ils se corrigent avec une architecture qui sépare domaines, contrats, événements et responsabilités. ## L'architecture d'une vraie plateforme EMSP/CPO Une [plateforme EMSP / CPO](/solutions/emsp-cpo) durable distingue plusieurs domaines : - le domaine infrastructure, qui connaît stations, connecteurs, états, puissance et supervision ; - le domaine utilisateur, qui connaît compte, droits, préférences, moyens de paiement et historique ; - le domaine session, qui relie autorisation, transaction OCPP, session OCPI, énergie et facturation ; - le domaine tarifaire, qui sépare règles internes, affichage utilisateur et contrats partenaires ; - le domaine support, qui agrège les traces nécessaires pour expliquer un parcours ; - le domaine reporting, qui produit les indicateurs opérationnels, financiers et partenaires. Cette séparation ne ralentit pas le produit. Elle évite au contraire que chaque nouvelle fonctionnalité devienne une exception. ## L'approche Resonovia Resonovia aborde ce type de plateforme en reliant EMSP, CPO, OCPP, OCPI, mobile et cloud dans un même système d'exploitation. Notre force vient de cinq points : - nous savons concevoir les backends Java, Kotlin et Spring Boot qui portent les règles métier critiques ; - nous comprenons les protocoles OCPP et OCPI, mais aussi les limites réelles de leurs implémentations ; - nous relions les états plateforme à une expérience mobile native claire ; - nous pensons support, reporting et exploitation dès le modèle de données ; - nous évitons les architectures qui mélangent utilisateur, borne, paiement et partenaire dans un même bloc fragile. Dans un marché où les usages augmentent vite, cette vision globale rend la plateforme plus lisible pour les équipes, plus fiable pour les utilisateurs et plus facile à faire évoluer pour l'entreprise. ## FAQ ### Une même plateforme peut-elle être EMSP et CPO ? Oui. Mais les domaines métier doivent rester séparés pour préserver la maintenabilité, la qualité de service et la clarté des responsabilités. ### OCPI est-il nécessaire pour un EMSP ? Il devient nécessaire dès que l'EMSP veut donner accès à des réseaux de recharge externes ou synchroniser sessions, tarifs, CDR et tokens avec des partenaires. ### Pourquoi ne pas tout mettre dans un seul modèle session ? Parce qu'une session vue par l'utilisateur, une transaction OCPP, une session OCPI et un CDR n'ont pas exactement les mêmes responsabilités. Les rapprocher est nécessaire ; les confondre rend la plateforme fragile. ## Sources - [Avere-France, chiffres clés de la mobilité électrique](https://www.avere-france.org/) - [Avere-France, baromètre des immatriculations de mars 2026](https://www.avere-france.org/publication/barometre-mars-2026-lelectrique-atteint-son-plus-haut-volume-mensuel-avec-54-604-immatriculations-691/) - [Avere-France et AFIREV, observatoire de la qualité des services de recharge 2024](https://www.avere-france.org/l-edition-2024-de-lobservatoire-avere-france-afirev-de-la-qualite-du-service-de-recharge/) ### Les KPIs d'une plateforme de recharge électrique Canonical URL: https://resonovia.fr/articles/emsp-cpo/kpis-plateforme-recharge Summary: Les indicateurs essentiels pour piloter une plateforme EMSP/CPO : disponibilité, accès immédiat, sessions réussies, prix, support, CDR et usage. Les bons KPIs relient technique, produit et exploitation. Ils évitent de piloter la recharge avec des métriques trop éloignées de l'expérience réelle. - Category: emsp-cpo - Published: 2026-05-08 - Updated: 2026-05-08 - Tags: EMSP; CPO; Observabilité - Keywords: KPI recharge électrique; plateforme CPO; observabilité recharge ## Mesurer ce qui compte vraiment Une plateforme de recharge ne se pilote pas seulement avec un nombre de bornes, un nombre d'utilisateurs ou un volume de sessions. Ces chiffres sont utiles, mais ils ne disent pas si le service fonctionne bien. Pour piloter une plateforme EMSP/CPO, il faut des KPIs qui relient technique, produit et exploitation. L'objectif est simple : comprendre si l'utilisateur peut trouver une borne, connaître le prix, démarrer une session, payer correctement et obtenir du support si quelque chose se passe mal. ## Les chiffres de marché donnent le niveau d'exigence La France comptait 192 008 points de recharge ouverts au public fin mars 2026 selon Avere-France. Le taux de disponibilité technique moyen était de 90 %, le taux d'accès immédiat de 96 %, et la consommation moyenne atteignait 788 kWh par point de recharge sur le mois, en hausse de 62 % sur un an. Ces chiffres montrent deux choses. Le réseau grandit, et les usages s'intensifient. Quand l'utilisation augmente, les métriques doivent devenir plus précises. Une plateforme ne peut pas se contenter de savoir qu'une borne existe. Elle doit savoir si elle est utilisable, visible, fiable et rentable. ## Les KPIs infrastructure Les KPIs infrastructure décrivent l'état réel du réseau. Les plus importants sont : - disponibilité technique par point de recharge ; - accès immédiat par station ; - temps passé en erreur ; - durée moyenne d'indisponibilité ; - fréquence des reconnexions OCPP ; - taux de commandes distantes réussies ; - bornes en panne récurrente ; - incidents par modèle, firmware ou site. Ces indicateurs servent au CPO. Ils orientent maintenance, supervision, priorisation terrain et décisions d'investissement. ## Les KPIs session La session est le moment où la promesse devient réelle. Les KPIs utiles incluent : - taux de sessions réussies ; - sessions démarrées mais non terminées proprement ; - sessions sans énergie significative ; - écarts entre transaction OCPP, session utilisateur et CDR ; - durée moyenne de session ; - énergie délivrée ; - échecs par moyen d'accès ; - délai entre commande distante et démarrage effectif. Avere-France et AFIREV indiquent que 85,5 % des sessions analysées dans l'observatoire 2024 ont été réussies. Ce KPI doit être central dans toute plateforme sérieuse. ## Les KPIs produit et utilisateur Un service peut être techniquement disponible mais mauvais côté utilisateur. Il faut donc mesurer : - fiabilité des informations de disponibilité affichées ; - cohérence des prix affichés ; - taux d'abandon avant démarrage ; - échecs de paiement ; - demandes support par session ; - temps de résolution support ; - satisfaction par lieu de recharge ; - utilisation de la cartographie et des filtres. L'observatoire Avere-France et AFIREV 2024 souligne que 86 % des utilisateurs utilisent des applications de cartographie pour préparer ou suivre leurs recharges, et que la satisfaction concernant la fiabilité de l'information prix atteint 77 %. Ces métriques montrent que la donnée produit est une partie du service. ## Les KPIs partenaires et finance Pour une plateforme EMSP/CPO, les partenaires et la finance sont aussi critiques que le temps réel. Il faut suivre : - CDR générés, rejetés, corrigés ou contestés ; - délais de production des exports ; - écarts entre sessions et factures ; - erreurs OCPI par partenaire ; - fraîcheur des tarifs ; - tokens refusés ; - rapprochement énergie, prix et paiement ; - revenus par site, puissance, partenaire et usage. Sans ces indicateurs, la plateforme peut sembler fonctionner tout en créant une dette opérationnelle importante. ## L'approche Resonovia Resonovia construit les KPIs à partir du modèle métier, pas après coup depuis des logs dispersés. Cette approche relie : - OCPP pour l'état terrain ; - OCPI pour les partenaires ; - mobile natif pour l'expérience utilisateur ; - paiement et CDR pour la cohérence financière ; - support et observabilité pour le diagnostic ; - architecture Java/Kotlin/Spring Boot pour la maintenabilité. Le résultat est une plateforme où les équipes peuvent piloter le service, pas seulement regarder des dashboards techniques. ## FAQ ### Quelle différence entre disponibilité technique et accès immédiat ? La disponibilité technique indique qu'un point de recharge fonctionne. L'accès immédiat indique qu'une station propose au moins un point disponible et non occupé pour l'utilisateur. ### Pourquoi le taux de sessions réussies est-il central ? Parce qu'il mesure le service au moment le plus important : l'utilisateur essaie réellement de charger. C'est un lien direct entre technique et expérience. ### Faut-il suivre les KPIs dès le MVP ? Oui, au moins les plus structurants. Sinon la plateforme accumule des données difficiles à exploiter au moment où la croissance arrive. ## Sources - [Avere-France, baromètre IRVE fin mars 2026](https://www.avere-france.org/publication/barometre-192-008-points-de-recharge-ouverts-au-public-fin-mars-2026/) - [Avere-France et AFIREV, observatoire de la qualité des services de recharge 2024](https://www.avere-france.org/l-edition-2024-de-lobservatoire-avere-france-afirev-de-la-qualite-du-service-de-recharge/) ### Construire un connecteur OCPI fiable pour le roaming Canonical URL: https://resonovia.fr/articles/ocpi/connecteur-ocpi-roaming-fiable Summary: Comment concevoir un connecteur OCPI qui rend les échanges partenaires fiables : credentials, locations, tariffs, sessions, CDR, tokens et support. OCPI ne vaut pas seulement par ses endpoints. Sa valeur vient de la cohérence des données, de la tolérance aux écarts partenaires et de la traçabilité. - Category: ocpi - Published: 2026-05-08 - Updated: 2026-05-08 - Tags: OCPI; Roaming; Interopérabilité - Keywords: connecteur OCPI; roaming recharge électrique; interopérabilité EMSP CPO ## OCPI est une relation entre plateformes OCPI permet à des plateformes EMSP et CPO d'échanger des données de recharge : stations, tarifs, sessions, CDR, tokens, commandes et credentials. Sur le papier, le protocole décrit des modules. En production, il organise une relation entre entreprises, systèmes, modèles tarifaires et équipes support. Un connecteur OCPI exploitable ne se contente donc pas de répondre aux routes attendues. Il doit protéger la plateforme contre les écarts partenaires, rendre les données compréhensibles et conserver les traces nécessaires pour traiter les litiges. ## Le roaming devient un sujet de qualité La croissance du réseau rend l'interopérabilité plus importante. Avere-France comptait 192 008 points de recharge ouverts au public en France fin mars 2026. Plus le réseau s'étend, plus les utilisateurs s'attendent à une expérience continue entre applications, opérateurs et territoires. Mais l'observatoire Avere-France et AFIREV 2024 rappelle que la qualité perçue reste fragile : seuls 65 % des conducteurs trouvent les tarifs transparents, même si le paiement à l'acte progresse. C'est un signal direct pour OCPI. Tarifs, sessions et CDR ne sont pas des détails techniques ; ce sont des éléments de qualité de service. ## Les modules OCPI à traiter comme des domaines métier Chaque module OCPI doit être rattaché à une responsabilité claire. `Credentials` établit la relation partenaire. Il doit être sécurisé, versionné et journalisé. `Locations` expose les stations. La donnée doit être complète, compréhensible et cohérente avec la réalité opérationnelle. `Tariffs` porte la promesse de prix. C'est l'un des modules les plus sensibles car une ambiguïté tarifaire devient rapidement un problème utilisateur ou support. `Tokens` gère l'autorisation. Il doit distinguer refus légitime, erreur partenaire, délai réseau et token inconnu. `Sessions` synchronise le déroulement de charge. Il doit rester corrélé avec la transaction OCPP et l'expérience EMSP. `CDR` permet la facturation et le rapprochement. Il doit être stable, contrôlable et réconciliable. `Commands` ouvre l'action distante. Il doit être asynchrone, traçable et relié à l'état réel côté borne. ## Les problèmes qu'un connecteur sérieux doit absorber Dans le roaming, les erreurs viennent rarement d'une seule source. Un partenaire peut être conforme au protocole mais différent dans son interprétation, ses délais, ses arrondis, ses valeurs optionnelles ou ses règles métier. Un connecteur OCPI solide doit donc gérer : - versions et capacités partenaires ; - données manquantes ou incohérentes ; - callbacks tardifs ; - divergence entre tarif affiché et tarif appliqué ; - sessions orphelines ; - CDR incomplets ou contestés ; - timeouts sur commandes ; - rejets de tokens ; - journaux exploitables par le support. La tolérance est nécessaire. Mais elle doit être contrôlée, visible et mesurable. ## Pourquoi Resonovia fait la différence Resonovia construit les connecteurs OCPI comme des composants métier, pas comme des adaptateurs REST génériques. Notre différence vient de la vision complète de la recharge : - nous comprenons le CPO, l'EMSP, le mobile, le paiement, le support et les exports ; - nous relions OCPI à OCPP pour suivre une session de la borne jusqu'au CDR ; - nous écrivons des contrats API stables pour éviter les intégrations fragiles ; - nous rendons les erreurs partenaires observables au lieu de les masquer ; - nous pensons la donnée tarifaire comme un sujet produit et juridique, pas seulement technique ; - nous savons bâtir la plateforme cloud qui porte ces échanges à long terme. Un [connecteur OCPI](/solutions/ocpi) Resonovia aide donc à ouvrir un réseau sans perdre la maîtrise des sessions, des prix et des incidents. ## Les bons indicateurs à suivre Pour savoir si un connecteur OCPI est fiable, il faut mesurer : - taux de synchronisation des locations ; - fraîcheur des tarifs ; - sessions en écart entre EMSP et CPO ; - CDR rejetés, corrigés ou contestés ; - commandes acceptées mais non exécutées ; - temps de traitement des callbacks ; - erreurs par partenaire et par module ; - incidents support liés aux prix, tokens ou sessions. Ces indicateurs transforment le roaming en service pilotable. ## FAQ ### OCPI suffit-il à garantir le roaming ? Non. OCPI donne le cadre d'échange. La fiabilité dépend de l'architecture, de la validation, des données, de l'observabilité et de la capacité à gérer les écarts partenaires. ### Pourquoi les tarifs sont-ils si sensibles ? Parce qu'ils touchent directement la qualité perçue du service. Un tarif mal synchronisé peut créer un litige même si la session technique fonctionne. ### Faut-il construire un connecteur différent par partenaire ? Il faut éviter de dupliquer toute la logique. La bonne approche consiste à garder un coeur OCPI stable et à isoler les adaptations partenaires dans des règles explicites. ## Sources - [Avere-France, baromètre IRVE fin mars 2026](https://www.avere-france.org/publication/barometre-192-008-points-de-recharge-ouverts-au-public-fin-mars-2026/) - [Avere-France et AFIREV, observatoire de la qualité des services de recharge 2024](https://www.avere-france.org/l-edition-2024-de-lobservatoire-avere-france-afirev-de-la-qualite-du-service-de-recharge/) - [Commission européenne, observatoire des carburants alternatifs](https://transport.ec.europa.eu/transport-themes/clean-transport/alternative-fuels-sustainable-mobility-europe/alternative-fuels-observatory_en) ### OCPI vs OCPP : comprendre la différence Canonical URL: https://resonovia.fr/articles/ocpi/ocpi-vs-ocpp Summary: Comparer OCPI et OCPP : deux protocoles complémentaires pour connecter bornes, plateformes EMSP/CPO, partenaires roaming, tarifs, sessions et CDR. OCPP connecte les bornes à la plateforme. OCPI connecte les plateformes entre elles. Une architecture mature traite ces deux frontières séparément. - Category: ocpi - Published: 2026-05-08 - Updated: 2026-05-08 - Tags: OCPI; OCPP; Roaming - Keywords: OCPI vs OCPP; connecteur OCPI; interopérabilité recharge électrique ## Deux protocoles pour deux frontières OCPP et OCPI répondent à deux problèmes différents. OCPP relie une borne de recharge à une plateforme CPO. OCPI relie des plateformes EMSP et CPO entre elles pour rendre possible le roaming, l'accès aux réseaux partenaires, la synchronisation des tarifs, des sessions et des CDR. La confusion vient du fait que les deux protocoles parlent de recharge. Pourtant, ils ne se situent pas au même endroit dans l'architecture. OCPP regarde vers l'infrastructure. OCPI regarde vers l'écosystème. Cette distinction est essentielle dans un marché qui devient massif. Avere-France indiquait 192 008 points de recharge ouverts au public en France fin mars 2026. L'utilisateur ne veut pas savoir si son problème vient d'un connecteur OCPP, d'un tarif OCPI, d'un token partenaire ou d'un CDR incomplet. Il veut une station disponible, un prix compréhensible, une session qui démarre et une facture cohérente. ## OCPP côté infrastructure OCPP gère la communication entre station et backend : connexion WebSocket, état connecteur, transaction, compteur, commande distante, diagnostics et configuration. Il répond à des questions comme : - la borne est-elle connectée ? - un connecteur est-il disponible, occupé ou en erreur ? - une session a-t-elle réellement démarré ? - la commande distante a-t-elle été acceptée ? - quels relevés compteur ont été reçus ? - une borne doit-elle être redémarrée, diagnostiquée ou reconfigurée ? OCPP est donc proche du terrain. Il porte la réalité parfois imparfaite des bornes, des firmwares, du réseau mobile et des installations. ## OCPI côté partenaires et roaming OCPI gère l'échange entre plateformes partenaires : credentials, locations, tariffs, sessions, CDR, tokens et commands. Il répond à des questions différentes : - un partenaire peut-il découvrir les stations ? - les tarifs exposés sont-ils à jour et compréhensibles ? - un token externe est-il autorisé ? - une session doit-elle être synchronisée avec un EMSP ? - un CDR peut-il être facturé, contrôlé ou rapproché ? - un incident vient-il du CPO, de l'EMSP ou d'une divergence de données ? OCPI est donc proche de l'interopérabilité commerciale et opérationnelle. Il ne pilote pas directement la borne, mais il conditionne l'accès au service pour des utilisateurs venant d'autres plateformes. ## Pourquoi cette différence compte pour le business Le règlement européen AFIR pousse les Etats membres vers des infrastructures plus denses, plus lisibles et plus interopérables. Il renforce les exigences autour de l'information utilisateur, de l'accès aux points de recharge, du paiement et de la transparence des données. En parallèle, l'observatoire Avere-France et AFIREV 2024 montre que les conducteurs attendent surtout de la fiabilité et de la clarté : 84 % déclarent avoir déjà rencontré une borne défectueuse et 87 % une borne hors service. Ce n'est pas seulement un problème de hardware. C'est aussi un problème de donnée, d'état, de diagnostic et de synchronisation entre systèmes. Lorsque OCPP et OCPI sont mélangés dans le logiciel, les effets sont visibles : - une station indiquée disponible alors que le connecteur terrain est en erreur ; - un tarif partenaire qui ne correspond pas au prix affiché ; - une session lancée côté EMSP mais mal corrélée côté CPO ; - un CDR difficile à rapprocher avec la transaction réelle ; - un support incapable de savoir quelle plateforme détient la bonne information. La qualité perçue dépend donc de l'architecture. ## Une plateforme mature utilise les deux Une plateforme CPO utilise OCPP pour piloter ses bornes et OCPI pour exposer son réseau à des EMSP. Une plateforme EMSP utilise OCPI pour donner accès à des réseaux tiers et offrir une expérience unifiée à ses utilisateurs. La bonne architecture sépare clairement : - le serveur OCPP, responsable de la relation borne ; - le domaine CPO, responsable de l'exploitation infrastructure ; - le connecteur OCPI, responsable des échanges partenaires ; - le domaine EMSP, responsable de l'utilisateur, du compte, du paiement et du service ; - les outils support, capables de lire les deux frontières sans les confondre. Cette séparation permet d'absorber les versions, les écarts partenaires, les délais de synchronisation et les incidents terrain sans transformer chaque évolution en dette technique. ## Ce qui distingue Resonovia Resonovia conçoit OCPP et OCPI comme deux contrats distincts, mais reliés par un même modèle opérationnel. C'est un point clé : beaucoup d'intégrations savent exposer des endpoints, peu savent rendre les écarts compréhensibles pour le produit et l'exploitation. Notre approche combine : - un [serveur OCPP](/solutions/ocpp) pensé pour les états terrain, les commandes et la supervision ; - un [connecteur OCPI](/solutions/ocpi) versionné, traçable et tolérant aux écarts partenaires ; - une modélisation EMSP/CPO qui évite de mélanger accès utilisateur et exploitation infrastructure ; - des APIs produit adaptées aux applications mobiles natives ; - des logs exploitables pour comprendre une session de bout en bout ; - des règles de validation qui protègent tarifs, sessions, CDR et droits d'accès. C'est ce qui rend Resonovia particulièrement fort sur les solutions de mobilité : nous ne regardons pas seulement le protocole, nous regardons le service complet. Le résultat attendu est une plateforme plus claire, plus diagnostiquable et plus facile à faire évoluer. ## Comment décider où agir Si une borne ne répond pas, commencez par OCPP. Si un partenaire ne voit pas une station, commencez par OCPI. Si l'utilisateur voit un prix différent, regardez le domaine tarifaire entre CPO et EMSP. Si une session existe dans une plateforme mais pas dans l'autre, regardez la corrélation entre transaction OCPP, session OCPI et CDR. Cette méthode évite de traiter l'interopérabilité comme un bloc unique. Elle aide les équipes à prioriser les corrections et à préserver une vision claire du produit. ## FAQ ### OCPI remplace-t-il OCPP ? Non. OCPI et OCPP sont complémentaires. OCPP connecte les bornes au backend CPO. OCPI connecte des plateformes entre elles. ### Pourquoi faut-il tracer les deux ? Parce qu'un incident de recharge peut venir de la borne, du CPO, de l'EMSP, du partenaire roaming, d'un token, d'un tarif ou d'un CDR. Sans traces séparées et corrélées, le diagnostic devient lent. ### Une plateforme peut-elle commencer avec un seul protocole ? Oui. Un CPO local peut commencer par OCPP. Un EMSP peut commencer par OCPI. Mais dès que le service relie infrastructure, application, partenaires et facturation, les deux frontières doivent être pensées ensemble. ## Sources - [Avere-France, baromètre IRVE fin mars 2026](https://www.avere-france.org/publication/barometre-192-008-points-de-recharge-ouverts-au-public-fin-mars-2026/) - [Avere-France et AFIREV, observatoire de la qualité des services de recharge 2024](https://www.avere-france.org/l-edition-2024-de-lobservatoire-avere-france-afirev-de-la-qualite-du-service-de-recharge/) - [Commission européenne, règlement AFIR et observatoire des carburants alternatifs](https://transport.ec.europa.eu/transport-themes/clean-transport/alternative-fuels-sustainable-mobility-europe/alternative-fuels-observatory_en) ### Architecture d'un serveur OCPP en production Canonical URL: https://resonovia.fr/articles/ocpp/architecture-serveur-ocpp-production Summary: Les choix techniques qui font la différence entre un serveur OCPP expérimental et une plateforme de recharge exploitable : état, commandes, logs, reprise et supervision. Un serveur OCPP en production doit gérer les connexions, mais surtout préserver une chronologie fiable entre borne, session, paiement, support et exploitation. - Category: ocpp - Published: 2026-05-08 - Updated: 2026-05-08 - Tags: OCPP; Architecture; Supervision - Keywords: architecture serveur OCPP; OCPP production; plateforme CPO ## Le vrai test commence après la première connexion Faire répondre une borne à un serveur OCPP est une étape. Exploiter un parc de bornes avec des utilisateurs, des partenaires, des paiements, des incidents et des équipes support en est une autre. En production, le serveur OCPP devient le système nerveux de la plateforme CPO. Il doit recevoir les messages, mais aussi reconstituer ce qui s'est passé, distinguer un état technique d'un état produit, conserver les traces nécessaires et permettre aux équipes de décider vite. La France comptait 192 008 points de recharge ouverts au public fin mars 2026 selon Avere-France. Ce volume rend la qualité logicielle plus visible : une mauvaise corrélation de session, une commande perdue ou un statut mal interprété peut toucher des milliers d'utilisateurs. ## Les cinq blocs d'une architecture solide Une architecture OCPP de production doit séparer cinq blocs. Le premier bloc est la terminaison WebSocket. Elle gère les connexions longues, l'identité station, les timeouts, les reconnexions et la pression réseau. Elle doit rester simple et robuste. Le deuxième bloc est la validation protocolaire. Chaque message doit être contrôlé, horodaté et relié à une station connue. La plateforme doit accepter les écarts prévus, mais jamais perdre la trace de ce qu'elle tolère. Le troisième bloc est le domaine métier. Il transforme `StatusNotification`, `StartTransaction`, `StopTransaction`, `MeterValues` et les commandes distantes en objets exploitables : connecteur, disponibilité, session, énergie, incident, action support. Le quatrième bloc est l'observabilité. Sans logs corrélés, métriques, traces de commandes et chronologie de session, l'exploitation devient lente. L'observabilité n'est pas un bonus, c'est une fonctionnalité produit. Le cinquième bloc est l'intégration plateforme : APIs mobile, backoffice, reporting, notifications, OCPI, paiement et exports. OCPP ne doit pas être un silo. ## Les décisions qui évitent la dette technique Les architectures OCPP les plus robustes prennent quelques décisions fortes dès le départ : - ne jamais confondre payload brut et état métier ; - conserver une chronologie par station, connecteur, transaction et commande ; - rendre les commandes distantes asynchrones et observables ; - distinguer indisponibilité technique, occupation et absence d'accès immédiat ; - prévoir les différences de firmware au lieu de les cacher dans des conditions dispersées ; - relier session OCPP, session utilisateur, paiement et CDR ; - donner au support une lecture claire avant de multiplier les alertes. Ces décisions sont plus importantes qu'un choix de framework. Elles déterminent la capacité à tenir dans le temps. ## Pourquoi les chiffres rendent cette discipline indispensable Avere-France et AFIREV indiquent dans l'observatoire 2024 que 85,5 % des sessions analysées ont été réussies. C'est un progrès, mais cela signifie aussi que la qualité de parcours reste un sujet mesurable. Le même observatoire souligne que 84 % des conducteurs disent avoir rencontré un défaut de charge au cours des six derniers mois. Ces chiffres ne condamnent pas la recharge publique. Ils montrent que le logiciel doit aider à réduire l'incertitude. Lorsqu'une session échoue, la plateforme doit expliquer pourquoi. Lorsqu'une borne est en erreur, elle doit remonter l'information correctement. Lorsqu'un utilisateur appelle le support, l'équipe doit voir la même histoire que la borne, l'app et le système de paiement. ## L'approche Resonovia Resonovia construit les serveurs OCPP comme des plateformes d'exploitation, pas comme de simples adaptateurs. Notre approche repose sur : - Java, Kotlin et Spring Boot pour porter une logique métier claire et testable ; - une base SQL fiable, PostgreSQL par préférence lorsque le socle est à définir, pour conserver des états transactionnels cohérents ; - des événements pour découpler supervision, mobile, reporting et notifications ; - des logs protocole lisibles par station, session et commande ; - des APIs produit pensées pour l'application mobile et le support ; - une séparation stricte entre protocole OCPP, domaine CPO et expérience utilisateur. Cette combinaison permet de construire une [solution serveur OCPP](/solutions/ocpp) plus résistante à la croissance du parc, aux différences de firmware et aux exigences d'exploitation. ## Ce qu'il faut mesurer Une plateforme CPO sérieuse doit suivre plus que le nombre de bornes connectées. Les indicateurs utiles incluent : - taux de disponibilité technique ; - taux d'accès immédiat ; - taux de sessions réussies ; - commandes distantes acceptées, expirées ou refusées ; - sessions sans `StopTransaction` exploitable ; - temps moyen de diagnostic support ; - bornes en erreur récurrente ; - cohérence entre énergie OCPP, session utilisateur et CDR ; - latence des messages et taux de reconnexion. Ces indicateurs rapprochent le logiciel des enjeux métier. Ils permettent de prioriser les corrections qui améliorent réellement l'expérience. ## FAQ ### Faut-il développer son serveur OCPP ou utiliser une plateforme existante ? Cela dépend du niveau de contrôle recherché. Une plateforme existante peut accélérer le démarrage. Un serveur maîtrisé apporte plus de traçabilité, de différenciation produit et de capacité d'intégration. ### OCPP 1.6 suffit-il encore ? Il reste très présent sur le terrain. L'enjeu est moins de choisir une version parfaite que de concevoir une architecture capable de gérer versions, écarts firmware et migration progressive. ### Pourquoi Resonovia insiste autant sur les logs ? Parce que les logs sont ce qui permet de transformer un incident utilisateur en diagnostic. Sans chronologie claire, chaque panne devient une enquête lente. ## Sources - [Avere-France, baromètre IRVE fin mars 2026](https://www.avere-france.org/publication/barometre-192-008-points-de-recharge-ouverts-au-public-fin-mars-2026/) - [Avere-France et AFIREV, observatoire de la qualité des services de recharge 2024](https://www.avere-france.org/l-edition-2024-de-lobservatoire-avere-france-afirev-de-la-qualite-du-service-de-recharge/) ### Qu'est-ce qu'un serveur OCPP ? Canonical URL: https://resonovia.fr/articles/ocpp/what-is-an-ocpp-server Summary: Comprendre le rôle d'un serveur OCPP dans une plateforme de recharge électrique : WebSocket, messages station, supervision, observabilité et fiabilité opérationnelle. Un serveur OCPP ne fait pas que recevoir des messages de borne : il transforme un parc de recharge en système pilotable, observable et exploitable. - Category: ocpp - Published: 2026-05-08 - Updated: 2026-05-08 - Tags: OCPP; Recharge électrique; Supervision - Keywords: serveur OCPP; logiciel recharge électrique; supervision bornes de recharge ## Le rôle réel d'un serveur OCPP Un serveur OCPP est la brique qui relie les bornes de recharge à une plateforme CPO. Il maintient les connexions WebSocket, reçoit les messages de la station, valide les payloads, transforme les événements terrain en états métier et expose ces informations aux outils d'exploitation. La définition technique est simple. L'enjeu produit l'est beaucoup moins : lorsqu'un utilisateur arrive devant une borne, il ne juge pas le protocole, il juge la capacité du service à afficher un état fiable, accepter son moyen d'accès, lancer la session, mesurer l'énergie, terminer proprement la charge et produire une trace exploitable. Dans un marché qui change d'échelle, cette différence devient décisive. Avere-France indique que la France comptait 192 008 points de recharge ouverts au public fin mars 2026, avec une disponibilité technique moyenne de 90 % et un taux d'accès immédiat de 96 %. Le même baromètre signale une consommation moyenne de 788 kWh par point de recharge sur le mois, en hausse de 62 % sur un an. Plus le réseau est utilisé, moins une architecture approximative pardonne. ## Pourquoi le protocole ne suffit pas OCPP définit des messages. Il ne garantit pas à lui seul une exploitation fiable. Entre la borne et l'utilisateur, il faut interpréter des états, corriger des incohérences, reprendre des connexions, corréler des commandes et expliquer les incidents. Les messages les plus structurants sont : - `BootNotification`, qui annonce la borne et initialise sa relation avec la plateforme. - `Heartbeat`, qui confirme que la station reste vivante. - `StatusNotification`, qui décrit l'état d'un connecteur. - `Authorize`, qui valide un badge, un token ou une autorisation distante. - `StartTransaction` et `StopTransaction`, qui encadrent une session. - `MeterValues`, qui transporte les relevés d'énergie. - `RemoteStartTransaction`, qui permet de déclencher une charge à distance. - `DiagnosticsStatusNotification`, qui aide à comprendre les problèmes terrain. Ces messages doivent être reliés à des objets métier : station, connecteur, session, utilisateur, token, tarif, paiement, incident, intervention et export financier. Sans ce lien, le serveur OCPP devient une boîte de réception technique au lieu d'être un outil de pilotage. ## Les chiffres montrent le vrai problème L'observatoire Avere-France et AFIREV 2024 donne une lecture utile du terrain : 85,5 % des sessions de recharge analysées ont été réussies, 84 % des conducteurs disent avoir rencontré un défaut de charge au cours des six derniers mois, et 87 % ont déjà rencontré une borne hors service. Ces chiffres ne signifient pas que tout échoue. Ils montrent surtout que la recharge est un service d'exploitation, pas seulement un service logiciel. Un serveur OCPP sérieux doit donc répondre à des questions très concrètes : - la borne est-elle réellement connectée ou simplement connue de la base ? - le connecteur est-il disponible, réservé, occupé, en erreur ou dans un état ambigu ? - une commande distante a-t-elle été reçue, acceptée, refusée ou perdue ? - la transaction OCPP correspond-elle bien à la session affichée dans l'application ? - les valeurs compteur sont-elles cohérentes avec la facturation et le CDR ? - l'incident vient-il de la station, du réseau, du firmware, du backend ou d'un partenaire ? La valeur ne vient pas du fait de "supporter OCPP". Elle vient de la capacité à rendre ces réponses rapides, traçables et compréhensibles par les équipes produit, support et opérations. ## Architecture recommandée Un serveur OCPP robuste s'appuie généralement sur : - une couche WebSocket dédiée, capable de gérer connexions longues, reconnexions, timeouts et identifiants de stations ; - une validation stricte des messages, avec tolérance contrôlée pour les écarts firmware connus ; - un journal protocolaire lisible, interrogeable par station, session, commande et période ; - une base relationnelle pour l'état métier durable ; - un bus d'événements pour diffuser les changements vers supervision, mobile, reporting et alerting ; - des APIs produit pour l'application mobile, le backoffice et les outils de support ; - des métriques sur disponibilité, latence, erreurs, commandes, sessions incomplètes et valeurs compteur ; - des mécanismes de reprise pour éviter qu'une coupure réseau transforme une session en dette opérationnelle. Cette architecture sépare trois niveaux qui sont trop souvent mélangés : le protocole OCPP, le domaine métier recharge et l'expérience utilisateur. C'est précisément cette séparation qui permet d'évoluer sans casser l'exploitation. ## Ce qui distingue Resonovia Resonovia ne traite pas OCPP comme un connecteur isolé. Nous le concevons comme une frontière critique entre infrastructure, produit et opérations. Notre avantage vient de la combinaison de plusieurs compétences rarement réunies dans un même périmètre : - architecture Java, Kotlin et Spring Boot pour des backends maintenables ; - modélisation métier des stations, connecteurs, sessions, tarifs, CDR et incidents ; - observabilité exploitable par des équipes non développeuses ; - intégration mobile native, pour que les états affichés à l'utilisateur soient alignés avec le terrain ; - compréhension OCPI et EMSP/CPO, pour éviter qu'OCPP devienne un silo technique ; - culture d'exploitation, avec logs, rejeu, alertes et diagnostics pensés dès la conception. La conséquence est simple : une [solution serveur OCPP](/solutions/ocpp) Resonovia ne se limite pas à accepter des WebSockets. Elle aide à réduire l'ambiguïté, accélérer le diagnostic et construire une plateforme capable de monter en charge. ## Les erreurs courantes Beaucoup de plateformes commencent par recevoir les messages, puis découvrent trop tard que les opérations exigent davantage. Les erreurs les plus fréquentes sont : - stocker les payloads sans créer une vraie chronologie métier ; - afficher les derniers statuts sans distinguer état protocolaire et état produit ; - traiter les commandes distantes comme des appels synchrones simples ; - ignorer les différences de firmware entre modèles de bornes ; - ne pas relier session, paiement, CDR et support ; - ne pas donner aux équipes un moyen de comprendre pourquoi une charge a échoué. Ces erreurs coûtent cher parce qu'elles se voient directement dans l'expérience utilisateur. Un réseau dense ne suffit pas si la disponibilité, la donnée et le support ne suivent pas. ## FAQ ### OCPP est-il uniquement un protocole de borne ? Non. OCPP définit la communication entre borne et backend, mais la valeur vient de l'architecture qui transforme ces messages en états fiables, commandes maîtrisées, diagnostics et données exploitables. ### Peut-on construire une plateforme CPO sans serveur OCPP interne ? Oui, mais cela crée souvent une dépendance forte à une boîte noire. Pour certains produits, maîtriser cette brique améliore la traçabilité, la qualité de support et la capacité d'évolution. ### Pourquoi l'observabilité OCPP est-elle si importante ? Parce qu'un incident de recharge peut venir de plusieurs causes : réseau, firmware, token, commande, état backend, paiement ou partenaire. Sans traces corrélées, l'exploitation travaille trop lentement. ## Sources - [Avere-France, baromètre IRVE fin mars 2026](https://www.avere-france.org/publication/barometre-192-008-points-de-recharge-ouverts-au-public-fin-mars-2026/) - [Avere-France et AFIREV, observatoire de la qualité des services de recharge 2024](https://www.avere-france.org/l-edition-2024-de-lobservatoire-avere-france-afirev-de-la-qualite-du-service-de-recharge/) - [Commission européenne, données et règles sur les infrastructures de recharge](https://transport.ec.europa.eu/transport-themes/clean-transport/alternative-fuels-sustainable-mobility-europe/alternative-fuels-observatory_en) ### Logiciel véhicule connecté et software-defined vehicle Canonical URL: https://resonovia.fr/articles/software-defined-vehicle/connected-vehicle-software Summary: Comprendre les architectures de logiciel véhicule connecté : Android Automotive OS, données, cloud, navigation, télémétrie, recharge et services de mobilité. Le véhicule connecté devient une plateforme logicielle reliée au cloud, à la recharge, aux données, à la navigation et aux services utilisateur. - Category: software-defined-vehicle - Published: 2026-05-08 - Updated: 2026-05-08 - Tags: Véhicule connecté; Software-defined vehicle; Android Automotive OS - Keywords: logiciel véhicule connecté; software defined vehicle; Android Automotive OS ## Le véhicule devient une plateforme logicielle Le software-defined vehicle désigne une évolution profonde : de plus en plus de fonctions véhicule sont définies, orchestrées et améliorées par logiciel. Navigation, énergie, services connectés, télémétrie, maintenance, expérience conducteur et recharge dépendent désormais de contrats logiciels robustes. Cette transformation ne signifie pas que tout devient une application. Elle impose surtout des frontières plus nettes entre embarqué, cloud, produit, données et mobilité. Un véhicule connecté n'est pas seulement un objet qui envoie des données : c'est un noeud d'un système plus large. ## Le marché impose une architecture plus sérieuse L'électrification accélère cette transformation. D'après l'IEA, les ventes mondiales de voitures électriques ont dépassé 17 millions en 2024, soit plus de 20 % des ventes de voitures neuves. En France, Avere-France indique que 54 604 véhicules 100 % électriques ont été immatriculés en mars 2026, un record mensuel en hausse de 69,1 % sur un an. Cette croissance rend le véhicule plus dépendant des services numériques : planification d'itinéraire, disponibilité de recharge, préconditionnement batterie, paiement, préférences conducteur, données d'autonomie, maintenance et support. Le véhicule ne peut donc plus être pensé séparément de la plateforme mobilité. Il doit dialoguer avec le cloud, les applications, la navigation, les réseaux de recharge et les outils opérationnels. ## Les briques d'une architecture connectée Une architecture véhicule connectée peut inclure : - des composants embarqués Android Automotive OS, Kotlin, Java ou C++ ; - une couche d'abstraction véhicule ; - des flux de télémétrie ; - des services cloud ; - une synchronisation avec les applications mobiles natives ; - des données de navigation, d'énergie et de recharge ; - des APIs produit pour les services de mobilité ; - des mécanismes de sécurité, d'identité et de consentement ; - des outils de diagnostic et d'observabilité. Chaque brique doit avoir une responsabilité claire. Le code embarqué ne doit pas porter toute la logique produit. Le cloud ne doit pas dépendre directement de détails firmware. Le mobile ne doit pas deviner l'état du véhicule à partir de signaux incomplets. ## Pourquoi l'abstraction véhicule est essentielle Les signaux véhicule ne doivent pas être consommés directement par chaque service produit. Une abstraction claire protège l'architecture contre les différences matérielles, firmware, modèles, versions et marchés. Elle permet de transformer des signaux bas niveau en contrats utiles : - autonomie estimée ; - état batterie ; - consommation observée ; - destination active ; - besoin de recharge ; - disponibilité des fonctions connectées ; - alertes exploitables ; - contexte de navigation. Sans abstraction, chaque service devient dépendant de détails difficiles à maintenir. Avec une abstraction stable, route planning, recharge, navigation, compte utilisateur et services cloud peuvent évoluer plus proprement. ## Recharge, navigation et données : le vrai cas d'usage La valeur du véhicule connecté apparaît quand plusieurs domaines se rejoignent. Un route planner électrique pertinent doit tenir compte de l'autonomie, du profil de consommation, des stations disponibles, de la puissance, du prix, du temps d'arrêt, des préférences conducteur et de l'état de la batterie. Une application mobile doit expliquer ces choix simplement. Un backoffice doit comprendre pourquoi une recommandation a été faite. Un support doit pouvoir diagnostiquer une session qui a échoué. Cette chaîne traverse véhicule, cloud, mobile, OCPP, OCPI, données stations et règles produit. C'est précisément là que les projets échouent lorsqu'ils sont découpés en silos. ## L'approche Resonovia Resonovia aborde le logiciel véhicule connecté comme une frontière entre embarqué, cloud, mobile et recharge. L’objectif est de rendre les responsabilités explicites et de garder une architecture exploitable. Nous savons construire : - des composants Android Automotive OS et services embarqués ; - des abstractions de signaux véhicule utilisables par le produit ; - des backends Java, Kotlin et Spring Boot pour la logique cloud ; - des applications mobiles natives qui rendent les données compréhensibles ; - des intégrations OCPP et OCPI pour connecter recharge, partenaires et exploitation ; - des modèles de données qui séparent télémétrie brute, état produit et support. Cette combinaison permet de relier les couches dans une architecture cohérente, avec une attention forte à la maintenabilité et à l'exploitation. ## Les risques à éviter Un projet véhicule connecté peut devenir fragile lorsque : - les services cloud consomment directement des signaux bas niveau ; - la télémétrie est collectée sans modèle d'usage clair ; - le mobile affiche des états non confirmés ; - la navigation ne connaît pas les contraintes énergie ; - les équipes support n'ont pas de traces corrélées ; - la sécurité et le consentement sont ajoutés trop tard ; - la recharge est traitée comme un service externe sans cohérence produit. Ces risques sont évitables lorsque l'architecture est pensée dès le départ autour des contrats, des responsabilités et de l'expérience réelle. ## Mobilité, recharge et véhicule Le véhicule connecté rejoint naturellement les plateformes de mobilité : planification d'itinéraires, disponibilité de recharge, préférences utilisateur, état batterie, navigation et données d'usage. Resonovia aborde cette frontière à travers [le logiciel véhicule connecté](/solutions/connected-vehicle-software), les applications natives, les plateformes cloud de mobilité et les systèmes de recharge. ## FAQ ### Le software-defined vehicle concerne-t-il uniquement les constructeurs ? Non. De nombreux services de mobilité interagissent avec le véhicule, ses données ou son environnement logiciel. Flottes, opérateurs, EMSP, plateformes de recharge et services de navigation sont aussi concernés. ### Pourquoi relier cloud et embarqué avec prudence ? Parce qu'une dépendance mal conçue peut fragiliser la performance, la résilience, la sécurité et la maintenabilité du système. ### Pourquoi parler de recharge dans un article véhicule connecté ? Parce que l'énergie est l'un des premiers cas d'usage où le véhicule, la navigation, le cloud, l'application mobile et les infrastructures doivent vraiment travailler ensemble. ## Sources - [IEA, Global EV Outlook 2025](https://www.iea.org/reports/global-ev-outlook-2025) - [IEA, Electric vehicle charging 2025](https://www.iea.org/reports/global-ev-outlook-2025/electric-vehicle-charging) - [Avere-France, baromètre des immatriculations de mars 2026](https://www.avere-france.org/publication/barometre-mars-2026-lelectrique-atteint-son-plus-haut-volume-mensuel-avec-54-604-immatriculations-691/) ### Route planner électrique : relier véhicule, recharge et navigation Canonical URL: https://resonovia.fr/articles/software-defined-vehicle/route-planner-electrique-donnees-vehicule Summary: Pourquoi un route planner électrique fiable doit combiner données véhicule, stations, disponibilité, prix, énergie, préférences utilisateur et architecture cloud. Le route planning électrique n'est pas une carte avec des bornes. C'est une décision produit qui relie autonomie, disponibilité, prix, temps d'arrêt et qualité de service. - Category: software-defined-vehicle - Published: 2026-05-08 - Updated: 2026-05-08 - Tags: Route planner; Véhicule connecté; Recharge électrique - Keywords: route planner électrique; données véhicule; planification recharge ## Un route planner électrique structure la décision Un route planner électrique ne se limite pas à afficher des bornes sur une carte. Il recommande où s'arrêter, combien de temps charger, quel niveau de batterie viser, quel prix accepter et quelle marge de sécurité conserver. Cette décision influence directement la qualité du parcours conducteur. Une mauvaise recommandation peut créer de l'anxiété, un détour inutile, une attente, une session impossible ou un coût mal anticipé. ## Pourquoi le sujet devient stratégique L'IEA indique que les ventes mondiales de voitures électriques ont dépassé 17 millions en 2024, soit plus de 20 % des ventes de voitures neuves. En France, Avere-France recense 2 597 191 véhicules électriques et hybrides rechargeables en circulation au 28 février 2026. Plus le parc grandit, plus le route planning devient une brique de service. Les conducteurs ne veulent pas seulement savoir où charger. Ils veulent savoir quelle option est fiable, rapide, compréhensible et adaptée à leur véhicule. ## Les données indispensables Un route planner électrique sérieux doit combiner plusieurs familles de données : - autonomie et état batterie ; - consommation observée ou estimée ; - destination, étapes et contraintes horaires ; - stations accessibles ; - disponibilité en temps quasi réel ; - puissance réelle et puissance utile pour le véhicule ; - prix, conditions d'accès et moyens de paiement ; - historique de fiabilité ; - préférences conducteur ; - météo, relief, vitesse et charge du véhicule lorsque ces données sont disponibles. Chaque donnée a une incertitude. L'architecture doit donc indiquer ce qui est confirmé, estimé, ancien ou indisponible. ## Le lien avec OCPP et OCPI Le route planner dépend indirectement des protocoles de recharge. OCPP donne la réalité terrain côté borne : connecteur disponible, occupé, en erreur ou en session. OCPI permet de récupérer les données de réseaux partenaires : locations, tariffs, sessions, tokens et commandes. Si ces données sont mal synchronisées, le route planner peut recommander une borne indisponible, un prix faux ou une station incompatible avec le besoin réel. C'est pourquoi la planification ne doit pas être isolée du reste de la plateforme mobilité. ## Le rôle des données véhicule Les données véhicule rendent les recommandations plus pertinentes. Elles permettent de distinguer deux conducteurs qui suivent le même itinéraire mais n'ont pas la même batterie, la même consommation, les mêmes habitudes ou les mêmes contraintes. Les signaux utiles peuvent inclure : - niveau de batterie ; - autonomie estimée ; - consommation récente ; - puissance de charge acceptée ; - destination active ; - préconditionnement possible ; - contraintes de confort ou de sécurité. Ces signaux doivent passer par une abstraction véhicule. Le cloud produit ne doit pas dépendre directement de détails matériels ou firmware. ## L'approche Resonovia Resonovia aborde ce type de solution comme un sujet transversal : mobile natif, backend cloud, données véhicule, OCPP, OCPI, architecture et expérience utilisateur doivent être cohérents. Nous savons construire : - les APIs produit qui exposent des recommandations compréhensibles ; - les modèles de données qui relient stations, prix, disponibilité et énergie ; - les intégrations OCPP et OCPI nécessaires à la fiabilité ; - les composants mobiles qui expliquent les choix au conducteur ; - l'abstraction véhicule qui protège la plateforme des spécificités matérielles ; - l'observabilité qui permet de comprendre pourquoi une recommandation a été faite. Cette combinaison évite de produire un route planner théorique. Elle permet de construire une [solution de route planning](/solutions/route-planner) réellement connectée aux contraintes du terrain. ## Les erreurs à éviter Les erreurs fréquentes sont : - recommander uniquement la station la plus proche ; - ignorer la puissance utile pour le véhicule ; - afficher des prix sans expliquer leur fiabilité ; - ne pas tenir compte des stations occupées ou en erreur ; - mélanger données estimées et données confirmées ; - oublier le support et la traçabilité des recommandations ; - traiter le véhicule comme une simple option au lieu d'un contexte central. Un bon route planner n'est pas seulement optimisé. Il est explicable. ## FAQ ### Un route planner électrique peut-il fonctionner sans données véhicule ? Oui, mais avec moins de précision. Les données véhicule améliorent la pertinence des arrêts, des marges de sécurité et des temps de charge. ### Pourquoi intégrer les prix ? Parce que le conducteur ne choisit pas uniquement en fonction de la distance. Le prix, la puissance, la fiabilité et le temps d'arrêt influencent la décision. ### Pourquoi Resonovia relie route planning et recharge ? Parce qu'une recommandation d'itinéraire électrique n'a de valeur que si la donnée de recharge est fiable, exploitable et compréhensible par l'utilisateur. ## Sources - [IEA, Global EV Outlook 2025](https://www.iea.org/reports/global-ev-outlook-2025) - [IEA, Electric vehicle charging 2025](https://www.iea.org/reports/global-ev-outlook-2025/electric-vehicle-charging) - [Avere-France, chiffres clés de la mobilité électrique](https://www.avere-france.org/) - [Avere-France, baromètre IRVE fin mars 2026](https://www.avere-france.org/publication/barometre-192-008-points-de-recharge-ouverts-au-public-fin-mars-2026/)