Le contexte : un parc qui grandit plus vite que les process
Quand j’ai commencé à superviser des stations de recharge, le parc comptait environ 200 points de charge. Trois ans plus tard, on dépasse les 1000 stations actives réparties sur l’ensemble du territoire français. Cette croissance, aussi excitante soit-elle, a révélé une vérité fondamentale : les méthodes artisanales qui fonctionnent à 200 stations explosent en vol à 500.
Le premier réflexe de tout opérateur IRVE en croissance est de multiplier les tableaux Excel, les boucles WhatsApp et les alertes email. C’est humain. C’est aussi le meilleur chemin vers le burnout opérationnel. J’ai traversé cette phase, et cet article résume ce que j’ai appris en structurant la supervision d’un réseau national.
Construire un stack de monitoring efficace
La supervision d’un parc IRVE repose sur trois couches complémentaires, et la plupart des opérateurs n’en exploitent qu’une seule correctement.
Couche 1 : Le superviseur OCPP
C’est la base. Le superviseur (ou CPMS. Charge Point Management System) collecte les messages OCPP de chaque borne. Heartbeat, StatusNotification, MeterValues. Ce flux de données est votre pouls opérationnel. Sur un parc de 1000 stations, ça représente plusieurs millions de messages par jour. Encore faut-il savoir les exploiter.
Ce que j’ai appris à la dure : les plateformes de supervision ne se valent pas du tout. Certaines agrègent les StatusNotification mais ne conservent pas l’historique des transitions d’état. D’autres n’exposent pas de webhooks exploitables. Il faut évaluer ces outils sur des critères opérationnels concrets :
- Latence d’alerte : combien de temps entre un passage en erreur et la notification ?
- Granularité des filtres : peut-on distinguer un ConnectorStatusError d’un simple reboot ?
- API et webhooks : peut-on automatiser des actions correctives sans clic humain ?
- Historique des états : peut-on reconstituer la timeline d’un incident a posteriori ?
Couche 2 : Le monitoring réseau
Une borne qui ne communique pas, c’est une borne invisible. Le protocole OCPP repose sur une connexion WebSocket permanente, et les pertes de connectivité sont la première cause de faux-positifs dans les alertes. Superviser la couche réseau (4G, fibre, routeurs) est indispensable pour distinguer un vrai défaut matériel d’une simple coupure telco.
Couche 3 : Les remontées de site
Aucun outil logiciel ne remplace l’oeil d’un technicien. Mais on peut structurer les retours des techniciens : application mobile standardisée, checklist photographique, géolocalisation horodatée. En industrialisant la boucle intervention-supervision, on réduit le MTTR (Mean Time To Repair) de 35 à 40 % d’après mes observations.
Les KPI qui comptent vraiment
Dans l’IRVE, tout le monde parle de disponibilité. Mais derrière ce mot se cachent des définitions très différentes selon les acteurs. Voici les métriques que je suis au quotidien, et pourquoi.
Disponibilité technique vs disponibilité perçue
La disponibilité technique mesure le ratio temps disponible / temps total, hors maintenance planifiée. C’est le KPI contractuel classique. Sur mon parc, on vise un objectif de 97 % et on atteint en moyenne 95,8 % sur 12 mois glissants.
La disponibilité perçue, elle, intègre l’expérience utilisateur réelle : une borne techniquement « Available » mais avec un écran cassé ou un lecteur de carte défaillant n’est pas disponible pour le conducteur. C’est ce delta entre les deux métriques qui révèle la qualité réelle de votre exploitation.
Les 5 KPI de mon tableau de bord quotidien
- Uptime réseau. % de stations avec au moins 1 connecteur opérationnel (cible : 97 %)
- MTTR : temps moyen entre la détection d’un défaut et sa résolution (cible : <48 h)
- Taux de first-time-fix. % d’interventions résolues au premier passage (cible : >75 %)
- Taux de récurrence. % de stations avec plus de 2 pannes/mois sur le même connecteur
- Sessions échouées : ratio sessions 0 kWh / sessions totales (alerte si >8 %)
Gestion des incidents : du chaos au workflow
À 200 stations, on peut gérer les incidents « à la main ». À 1000, c’est impossible. La mise en place d’un workflow d’incident structuré a été le point de bascule le plus impactant dans ma trajectoire d’opérateur.
La matrice de priorisation
Tous les incidents ne se valent pas. J’ai mis en place une classification en 4 niveaux :
- P1. Critique : Station totalement hors service (tous connecteurs HS). Objectif résolution : 24 h. Exemples : défaut TGBT, carte de communication HS, erreur firmware bloquante.
- P2. Majeur : Service dégradé (1 connecteur sur 2 HS, puissance réduite). Objectif : 48 h. Exemples : connecteur défaillant, module de puissance en erreur.
- P3. Mineur : Fonctionnel mais dégradé non bloquant. Objectif : 5 jours ouvrés. Exemples : écran partiellement endommagé, éclairage HS, signalétique manquante.
- P4. Cosmétique : Aucun impact utilisateur. Planification lors du prochain passage. Exemples : autocollants décollés, traces superficielles.
L’automatisation des escalades
Chaque niveau de priorité déclenche un workflow automatisé : notification au bon interlocuteur, création de ticket chez le sous-traitant, relance automatique si le SLA n’est pas respecté. Sur un parc de 1000+ stations, je traite en moyenne 120 à 150 incidents par semaine. Sans automatisation, c’est tout simplement ingérable.
Coordination avec les équipes d’intervention
L’enjeu majeur de la supervision à grande échelle, c’est la distance entre celui qui détecte le problème et celui qui le résout. Le superviseur voit l’alerte à Bordeaux ; le technicien intervient à Lille. Cette asymétrie d’information est la source de la plupart des inefficacités opérationnelles.
Pour y remédier, j’ai structuré la communication opérationnelle autour de trois principes :
- Pré-diagnostic systématique : avant d’envoyer un technicien, le superviseur effectue un diagnostic à distance (reset OCPP, lecture des error codes, vérification de la connectivité). Cela évite 20 à 25 % des déplacements inutiles.
- Fiche d’intervention standardisée : chaque technicien reçoit un brief précis : symptôme, historique de la station, pièces susceptibles d’être nécessaires, accès au site.
- Compte-rendu photographique obligatoire : avant/après intervention, avec horodatage. C’est la base pour la traçabilité et l’analyse des récurrences.
Préventif vs correctif : trouver le bon ratio
Quand on démarre l’exploitation d’un parc IRVE, on est en mode 100 % réactif : une panne survient, on intervient. C’est naturel mais coûteux. L’objectif est de migrer progressivement vers un modèle où le préventif représente 30 à 40 % des interventions.
Ce que le préventif couvre concrètement
- Inspection visuelle semestrielle : état des câbles, connecteurs, signalétique, propreté
- Contrôle électrique annuel : conformité, serrage, mesures d’isolement
- Mise à jour firmware : déploiement coordonné, validation post-update
- Nettoyage des filtres : critique pour les chargeurs DC avec refroidissement actif
- Test de charge fonctionnel : simulation d’une session complète avec véhicule test
Le ROI du préventif en chiffres
Sur mon parc, le passage d’un modèle 100 % correctif à un ratio 65/35 (correctif/préventif) a produit des résultats mesurables après 6 mois : baisse de 28 % des pannes récurrentes, augmentation de la disponibilité de 2,3 points, et réduction du coût moyen par intervention de 15 % (car les pannes détectées tôt sont moins coûteuses à réparer).
Les défis du passage à l’échelle
Superviser 1000 stations n’est pas « superviser 100 stations, fois 10 ». Les problèmes changent de nature quand on passe à l’échelle. Voici les trois défis que je n’avais pas anticipés.
La fatigue d’alerte
À 200 stations, chaque alerte compte. À 1000, si vos seuils ne sont pas calibrés, vous recevez 300+ alertes par jour. Le cerveau humain filtre, puis ignore, puis rate les alertes critiques. La solution : une hiérarchisation agressive avec suppression des alertes non actionnables, et une revue hebdomadaire des seuils.
L’hétérogénéité du parc
Un parc national, c’est 6 constructeurs différents, 15 versions de firmware, 3 générations de hardware. Chaque combinaison a ses spécificités, ses bugs connus, ses procédures de dépannage. Sans une base de connaissances structurée (que j’ai mise en place sous forme de knowledge base interne), chaque incident redevient un cas unique.
La dépendance aux sous-traitants
À l’échelle nationale, vous ne pouvez pas avoir vos propres techniciens partout. La gestion des sous-traitants (qualité, réactivité, coûts) devient un métier à part entière. La clé : des SLA clairs, un suivi granulaire de la performance par prestataire, et la capacité à réattribuer des zones géographiques si la qualité baisse.