Supervision IRVE : outils, alerting et reporting mensuel au quotidien

Ce que superviser veut dire au quotidien sur un réseau national

Superviser un réseau de bornes de recharge, ce n’est pas regarder un écran vert et attendre qu’il passe au rouge. Quand on gère plus de 1000 stations réparties sur tout le territoire, la supervision devient un métier à part entière. C’est un flux continu d’événements à trier, de décisions à prendre en quelques minutes et de coordinations à lancer avec des prestataires terrain.

Concrètement, une journée type commence par la revue des alertes accumulées pendant la nuit. Sur un réseau de cette taille, il y a en moyenne 50 à 80 événements par jour qui nécessitent une analyse. La majorité sont des incidents mineurs : un redémarrage de connecteur, une perte de communication temporaire, une session interrompue par l’utilisateur. Mais dans ce bruit, il faut identifier les vraies pannes, les dégradations silencieuses et les tendances qui annoncent un problème plus grave.

La compétence clé n’est pas technique, elle est dans le tri. Savoir distinguer en 30 secondes un événement qui se résoudra seul d’un incident qui va immobiliser une station pendant trois jours. C’est cette capacité de triage qui fait la différence entre un réseau à 92 % de disponibilité et un réseau à 97 %.

OCPP StatusNotification : la fondation du monitoring, et ses limites

Tout le système de supervision repose sur un mécanisme simple du protocole OCPP : le message StatusNotification. Chaque connecteur envoie son état en temps réel au CPMS (Charging Point Management System). Available, Preparing, Charging, Finishing, Faulted, Unavailable : ces six statuts constituent la base de toute supervision.

En théorie, c’est suffisant. En pratique, c’est loin de l’être. Le premier problème, c’est la granularité. Un connecteur en statut « Faulted » peut aussi bien avoir un défaut mineur (erreur de communication passagère) qu’un problème matériel critique (module de puissance HS). Le champ errorCode d’OCPP 1.6 offre une dizaine de codes d’erreur, mais leur interprétation varie d’un constructeur à l’autre. Un « GroundFailure » chez un fabricant peut correspondre à un simple défaut de mesure chez un autre.

Le deuxième problème est plus vicieux : les pannes silencieuses. Une borne peut rester en statut « Available » tout en étant incapable de délivrer une charge complète. Le connecteur s’affiche disponible, l’utilisateur branche son véhicule, la session démarre, mais la puissance ne dépasse jamais 5 kW sur un chargeur 150 kW. Ou bien la session s’interrompt systématiquement après 2 minutes. StatusNotification ne remonte rien d’anormal dans ces cas.

C’est pourquoi la supervision ne peut pas se limiter aux statuts OCPP. Il faut croiser avec d’autres sources : les données de session (durée, énergie délivrée, puissance crête), les MeterValues en cours de charge, et les remontées utilisateurs. Un bon système de supervision est un système qui détecte les problèmes que le protocole ne signale pas.

Construire un système d’alerting : quoi surveiller, seuils et escalade

L’alerting est le cœur du réacteur. Un système d’alertes mal calibré produit deux résultats également néfastes : trop d’alertes et l’équipe les ignore (alert fatigue), pas assez et les pannes passent inaperçues pendant des heures.

Les événements à surveiller

• Passage en Faulted ou Unavailable depuis plus de 15 minutes. Un statut Faulted transitoire (moins de 5 minutes) est souvent un faux positif. Au-delà de 15 minutes, c’est généralement un vrai problème.
• Perte de communication OCPP (heartbeat absent depuis plus de 10 minutes). La borne ne répond plus : soit le réseau est coupé, soit la borne a planté.
• Sessions à 0 kWh ou énergie anormalement basse. Trois sessions consécutives à moins de 1 kWh sur un chargeur DC, c’est une alerte critique.
• Puissance crête anormalement basse. Un chargeur 150 kW qui ne dépasse pas 30 kW pendant 48 heures a probablement un module de puissance défaillant.
• Taux d’échec de session élevé. Plus de 30 % d’échecs sur un connecteur sur les dernières 24 heures, même si le statut reste « Available ».

Règles d’escalade

Toute alerte doit avoir un chemin d’escalade clair. Sur notre réseau, nous fonctionnons en trois niveaux :

1. Niveau 1 : traitement automatisé. Redémarrage à distance (OCPP Reset), réinitialisation du connecteur, redémarrage de la communication. Si la borne revient en service sous 10 minutes, l’incident est clos automatiquement.
2. Niveau 2 : analyse manuelle par l’équipe supervision. L’opérateur analyse les logs, identifie la cause probable et décide : nouvelle tentative de correction à distance, ou dispatch d’un technicien terrain.
3. Niveau 3 : intervention physique. Un ticket est créé dans l’outil de ticketing avec le diagnostic préliminaire, la pièce suspectée et la priorité. Le prestataire reçoit le ticket et s’engage sur un GTI.

Le passage du niveau 1 au niveau 2 doit se faire en moins de 30 minutes. Le passage du niveau 2 au niveau 3 dépend de la criticité de la station (flux, nombre de connecteurs restants, présence d’alternatives à proximité), mais ne doit jamais dépasser 2 heures en journée.

Triage automatisé vs manuel : gérer 50+ alertes par jour

Avec 50 à 80 événements quotidiens, il est impossible de tout traiter manuellement. La clé, c’est d’automatiser le traitement des incidents standards pour libérer du temps sur les cas complexes.

Le triage automatisé repose sur des règles simples mais rigoureuses. Quand une borne passe en Faulted, le système tente un Reset soft (sans redémarrage physique). Si le statut ne revient pas à Available sous 5 minutes, il tente un Reset hard. Si la borne revient en service, un log est créé pour suivi statistique mais aucune action humaine n’est requise. Ce mécanisme résout environ 35 à 40 % des incidents sans intervention humaine.

Pour les pertes de communication, le système vérifie d’abord si d’autres bornes du même site sont également déconnectées. Si oui, c’est probablement un problème réseau ou électrique général, pas un défaut de borne. L’alerte est alors escaladée directement en niveau 3 avec la mention « problème site » plutôt que « problème borne ».

Le triage manuel reste indispensable pour les cas ambigus : une borne qui alterne entre Available et Faulted toutes les 20 minutes, un chargeur dont la puissance baisse progressivement sur plusieurs jours, un site où les sessions échouent uniquement entre 18 h et 20 h. Ces schémas nécessitent une analyse humaine, une connaissance du matériel et parfois un appel au constructeur.

Reporting mensuel : les métriques qui comptent

Le reporting n’est pas un exercice administratif. C’est l’outil qui permet de piloter la performance du réseau, d’identifier les tendances et de justifier les investissements. Après avoir testé des dizaines de formats, j’ai réduit le reporting mensuel à six indicateurs essentiels.

Les six métriques du rapport mensuel

• Taux de disponibilité (uptime). Pourcentage du temps où chaque connecteur est opérationnel. Attention à la définition : un connecteur en maintenance préventive planifiée est-il « indisponible » ? Ma recommandation : oui, car l’utilisateur ne peut pas charger. L’objectif cible se situe entre 95 % et 97 %.
• MTTR (Mean Time To Repair). Temps moyen entre la détection d’une panne et le retour en service. Cet indicateur mesure l’efficacité de toute la chaîne : détection, diagnostic, dispatch, intervention, résolution. Un bon MTTR sur un réseau national se situe sous les 24 heures.
• MTBF (Mean Time Between Failures). Temps moyen entre deux pannes sur un même équipement. Cet indicateur révèle la fiabilité intrinsèque du matériel et la qualité de la maintenance préventive. Un MTBF qui diminue sur un type de borne doit déclencher une analyse de cause racine.
• Sessions à 0 kWh. Pourcentage de sessions où aucune énergie n’a été délivrée. C’est l’indicateur le plus directement lié à l’expérience utilisateur. Au-delà de 5 %, il y a un problème systémique à investiguer.
• Taux de résolution au premier passage. Pourcentage d’interventions terrain qui résolvent le problème dès la première visite. Un bon prestataire est au-dessus de 80 %. En dessous, il y a un problème de diagnostic amont ou de stock de pièces.
• Nombre de tickets ouverts et ancienneté moyenne. Le stock de tickets ouverts est un indicateur avance : s’il augmente régulièrement, la capacité de maintenance est insuffisante par rapport au volume d’incidents.

Chaque métrique doit être découpée par région, par constructeur de borne et par prestataire de maintenance. C’est cette triple segmentation qui permet d’identifier précisément où agir. Un MTTR global de 22 heures peut masquer un prestataire à 12 heures et un autre à 36 heures.

Outils et plateformes : CPMS, ticketing et dashboards

La supervision s’appuie sur trois couches d’outils complémentaires. Chacune a son rôle, et les trous entre ces couches sont les endroits où les incidents passent entre les mailles du filet.

Le CPMS (Charging Point Management System)

C’est la couche de base. Le CPMS reçoit les messages OCPP, affiche les statuts en temps réel et permet les commandes à distance (Reset, ChangeAvailability, RemoteStartTransaction). Un bon CPMS offre également une première couche d’alerting native et un historique des événements. Le piège, c’est de croire que le CPMS suffit. Il affiche ce que la borne lui envoie, rien de plus. Si la borne ment (ou omet), le CPMS ne corrigera pas.

L’outil de ticketing

Chaque incident qui nécessite une action (qu’elle soit à distance ou sur site) doit devenir un ticket. Le ticket porte le diagnostic préliminaire, la priorité, le prestataire assigné, les délais contractuels et l’historique des actions. Sans ticketing structuré, les incidents se perdent dans des échanges de mails et des conversations téléphoniques. Le ticketing, c’est la mémoire du réseau. Un technicien qui arrive sur site doit pouvoir lire l’historique complet de la borne en 2 minutes.

Les dashboards

Les dashboards servent deux publics différents. Le dashboard opérationnel (mis à jour en temps réel) est utilisé par l’équipe supervision au quotidien : carte des statuts, alertes actives, tickets en cours. Le dashboard de pilotage (mis à jour quotidiennement ou hebdomadairement) est destiné au management : tendances d’uptime, MTTR par zone, comparaison entre prestataires. Ne mélangez jamais ces deux usages dans un même écran. L’opérationnel a besoin de détail et de réactivité. Le pilotage a besoin de synthèse et de tendances.

L’intégration entre ces trois couches est critique. Le CPMS doit alimenter automatiquement le ticketing (à travers les règles d’alerting). Le ticketing doit alimenter les dashboards (pour le calcul des métriques). Et les dashboards doivent pouvoir pointer vers le détail d’un ticket ou d’un événement OCPP en un clic.

La règle des 60 % : automatiser le standard pour se concentrer sur le complexe

Après avoir analysé des milliers d’incidents sur plusieurs années, un constat s’impose : environ 60 % des incidents suivent des schémas répétitifs et prévisibles. Ce sont les mêmes codes d’erreur, les mêmes séquences d’événements, les mêmes causes racines.

Ces 60 % se décomposent grossièrement ainsi :

• 35–40 % sont résolubles par Reset à distance (comme mentionné plus haut). Erreurs logicielles, blocages de communication, états incohérents après une session interrompue.
• 15–20 % sont des incidents récurrents connus qui nécessitent une intervention terrain, mais dont le diagnostic est immédiat. Le ticket peut être créé automatiquement avec le bon diagnostic, la bonne pièce et la bonne priorité.
• 5–10 % sont des faux positifs identifiables automatiquement (coupure réseau temporaire, redémarrage planifié, intervention en cours).

Automatiser le traitement de ces 60 % signifie que l’équipe supervision peut concentrer 100 % de son attention sur les 40 % restants : les pannes inconnues, les dégradations lentes, les problèmes intermittents, les interactions entre composants. C’est sur ces 40 % que la compétence humaine fait la différence.

Pour y arriver, il faut investir dans la construction progressive d’un moteur de règles. Chaque incident résolu manuellement doit poser la question : « Ce cas peut-il être automatisé la prochaine fois ? » Si la réponse est oui, on écrit la règle, on la teste pendant deux semaines en mode observation, puis on l’active en mode automatique.

Supervision et expérience utilisateur : le lien direct avec les notes Chargemap

La supervision n’est pas un sujet purement technique. Elle a un impact mesurable et direct sur l’expérience des utilisateurs et, par extension, sur la réputation du réseau.

Un utilisateur qui arrive sur une station avec un connecteur en panne vit une mauvaise expérience. S’il doit essayer trois connecteurs avant d’en trouver un fonctionnel, c’est encore pire. Et s’il lance une session qui s’arrête au bout de 2 minutes sans explication, il laisse un avis négatif sur Chargemap dans les 5 minutes qui suivent.

La corrélation entre qualité de supervision et notes utilisateurs est forte. Sur les réseaux que j’ai gérés, les stations avec un uptime supérieur à 96 % ont en moyenne 0,8 point de plus sur Chargemap que les stations entre 90 % et 93 %. 0,8 point sur une échelle de 5, c’est la différence entre une station recommandée et une station évitée.

Le temps de réaction est l’autre facteur déterminant. Une borne en panne détectée et réparée en 4 heures génère zéro ou un avis négatif. La même borne en panne pendant 3 jours peut accumuler 5 à 10 avis négatifs, chacun visible publiquement et durablement. La supervision rapide n’est pas un luxe opérationnel, c’est un investissement dans la réputation du réseau.

Enfin, une bonne supervision permet la communication proactive. Quand on détecte une panne avant les utilisateurs, on peut afficher un message sur l’application, signaler le connecteur comme indisponible sur l’itinérance et éviter que des conducteurs fassent un détour inutile. Détecter une panne en 5 minutes et la communiquer en 10, c’est transformer un incident technique en preuve de professionnalisme.