Le retard est réel
Les ventes mondiales de véhicules électriques ont dépassé 20 millions d’unités en 2025. L’infrastructure de recharge, elle, n’a pas suivi le rythme selon la plupart des indicateurs. Le ratio entre véhicules électriques et points de recharge publics varie énormément d’une région à l’autre — certains marchés sont bien servis, d’autres nettement sous-équipés.
Et le problème n’est pas seulement quantitatif. C’est une question de fiabilité. Une borne hors service 30 % du temps ne fait pas vraiment partie du réseau. Les études menées aux États-Unis et en Europe montrent régulièrement que 10 à 25 % des bornes publiques sont indisponibles à un instant donné, pour des raisons allant des problèmes de connectivité aux pannes des systèmes de paiement en passant par les bugs de firmware.
Ce dernier point, lui, nous pouvons réellement le corriger.
La couche logicielle
Une borne de recharge moderne est un équipement en réseau sophistiqué. Elle fait tourner Linux (ou FreeRTOS sur du matériel plus simple), parle plusieurs protocoles, gère des paiements, pilote sa thermique et dialogue avec des services cloud. La pile logicielle est loin d’être mince.
Et pourtant l’outillage à disposition des développeurs de firmware est resté en arrière. Le secteur de la borne a longtemps été dominé par des industriels du matériel qui ont greffé le logiciel après coup. Le résultat : un firmware fragmenté, souvent bogué, qui cause exactement les problèmes de fiabilité que la filière cherche à résoudre.
Cela change. Une nouvelle génération d’entreprises conçoit des produits de recharge avec une culture logicielle d’abord. Elles recrutent des ingénieurs venus du Linux embarqué, des systèmes distribués et du réseau — pas seulement de l’électronique de puissance. Elles écrivent des tests, font tourner des chaînes de CI et traitent le logiciel comme un livrable de premier rang.
La fragmentation des protocoles est (presque) réglée
Il y a quelques années, l’interopérabilité était un vrai problème. Les éditeurs de CSMS implémentaient OCPP différemment ; une borne certifiée contre un serveur ne fonctionnait pas toujours proprement avec un autre.
OCPP 1.6 avec le binding JSON (OCPP-J) s’est imposé comme le socle de fait. Si vous supportez correctement OCPP 1.6-J, vous fonctionnerez avec la grande majorité des CSMS déployés sur le terrain. OCPP 2.0.1 gagne du terrain sur les nouveaux déploiements, en particulier ceux qui exigent une recharge intelligente plus fine, ISO 15118 (Plug&Charge) et une meilleure sécurité — mais 1.6 n’est pas près de disparaître.
Ce que les développeurs construisent
Les travaux les plus intéressants du moment portent sur :
La recharge intelligente et le pilotage de charge : ajuster dynamiquement la puissance selon l’état du réseau, la charge locale et les signaux tarifaires du fournisseur. Cela demande une intégration étroite entre le CSMS, la borne, et parfois la gestion énergétique du bâtiment.
Plug&Charge (ISO 15118) : l’authentification automatique par le certificat du véhicule. Pas d’application, pas de badge RFID. Le véhicule et la borne négocient directement. L’implémentation est complexe, mais le gain d’expérience utilisateur est considérable.
La recharge bidirectionnelle (V2G/V2H) : utiliser la batterie du véhicule comme stockage réseau ou secours domestique. Cela demande un support matériel et des extensions de protocole importantes au-delà d’OCPP standard.
L’outillage de fiabilité : supervision, diagnostic, mise à jour de firmware à distance. Quand un opérateur passe à plusieurs milliers de bornes, l’intervention manuelle devient irréaliste.
L’opportunité pour les développeurs
Si vous êtes développeur et que l’infrastructure qui compte vous intéresse, la recharge de véhicules électriques est l’un des terrains les plus intéressants du moment. Les problèmes sont réels, l’échelle grandit, et le niveau de qualité logicielle de beaucoup de produits en place n’est — honnêtement — pas très élevé. Il y a de la place pour faire nettement mieux.
Nous construisons des outils pour aider les développeurs de ce secteur à aller plus vite et à livrer un firmware plus fiable. TestPilot est venu en premier ; SimPilot (simuler une borne), ChargePilot (exploiter un réseau) et HubPilot (itinérance OCPI, en développement) ont suivi, tous sur le même moteur OCPP.