Partir du travail à accomplir
Avant de choisir un outil, il faut décrire une situation précise. Une station ne communique plus. Plusieurs alertes arrivent. Un ticket existe peut-être déjà. Le coordinateur doit savoir ce qui est confirmé, ce qui manque et qui prend la suite. Automatiser ce parcours a plus de valeur que multiplier les notifications.
Un premier périmètre peut tenir en une phrase : lorsqu’un incident nouveau est confirmé, préparer un dossier et le présenter au coordinateur. Ce périmètre évite de mêler, dès le départ, détection, diagnostic, commande à distance et envoi d’un technicien.
Construire un événement exploitable
Chaque événement doit retrouver le bon site, le bon équipement et le bon point de charge. Conserver l’identifiant source, la date avec son fuseau, le type de message et la version de la règle permet ensuite de reconstituer le traitement. L’heure d’arrivée dans un outil et l’heure réelle de l’événement peuvent différer.
OCPP organise les échanges entre station et système de supervision. Les versions et fonctions prises en charge doivent être identifiées avant de construire un connecteur : un même traitement ne se transpose pas mécaniquement d’OCPP 1.6 à 2.0.1. L’Open Charge Alliance décrit les fonctions et différences entre versions (nouvel onglet).
La normalisation ne doit pas effacer la source. Garder le message initial, à côté des champs utiles au traitement, permet d’examiner une anomalie de conversion sans dépendre d’un résumé incomplet.
Éviter les tickets en double
La bonne unité de traitement est l’incident. Une clé associant équipement, famille d’événement et incident ouvert permet de rattacher une nouvelle alerte au dossier existant. Une période de confirmation, définie selon le type de défaut, aide à distinguer un signal fugace d’une situation persistante.
Prévoir aussi les événements reçus dans le désordre, les tentatives répétées après un échec et les interruptions de connexion. Rejouer un événement déjà traité doit retrouver le résultat existant, sans créer un nouveau dossier. C’est ce que l’on attend d’un traitement idempotent.
Séparer préparation et exécution
Le flux peut rapprocher les informations, chercher une procédure, préparer le compte rendu et proposer une affectation. Les actions qui modifient l’équipement ou engagent un prestataire demandent une règle d’autorisation explicite, adaptée au contexte et aux responsabilités.
| Étape | Résultat attendu |
|---|---|
| Rapprocher | Site, équipement, incident et historique réunis. |
| Qualifier | Faits confirmés, informations manquantes et priorité proposée. |
| Préparer | Ticket renseigné, procédure pertinente et interlocuteur identifié. |
| Valider | Décision humaine tracée avant une action engageante. |
Traiter les exceptions dès le départ
Un équipement inconnu, une API indisponible ou un dossier incomplet doivent produire un état visible. Une file « à examiner » est souvent plus utile qu’une relance silencieuse sans limite. Chaque erreur doit indiquer ce qui a échoué, ce qui a déjà été fait et comment reprendre sans doublon.
Un journal d’exécution et un mécanisme d’arrêt permettent de reprendre la main. Avant d’étendre le flux, le faire fonctionner sur un périmètre limité, comparer ses propositions aux décisions du coordinateur et corriger les règles.
Mesurer le service rendu
Compter les automatisations exécutées ne suffit pas. Suivre le temps de qualification, les faux positifs, les doublons, les dossiers repris manuellement et les informations encore demandées au terrain donne une lecture plus utile. Une règle est intéressante si elle réduit un travail réel sans dégrader le diagnostic.
Le livrable de départ peut rester simple : un schéma du flux, une table de règles, une liste d’exceptions et un historique des décisions. Pour organiser l’étape suivante, voir le dossier sur la préparation et la planification des techniciens.