Monitoring des web services SGE 🔔

Contexte

Les web services SGE sont la porte d'entrée des acteurs du marché de l'électricité vers les données de raccordement et de consommation. Côté homologation, une panne sur l'un d'eux ne se voyait pas tout de suite : on l'apprenait quand un utilisateur signalait que son appel ne passait plus, parfois plusieurs heures après.

Ma première approche avait été un script de collecte alimentant un dashboard. Elle répondait au besoin de reporting, mais pas au vrai problème : personne ne regarde un dashboard en continu. Ce qu'il fallait, c'était que le système prévienne de lui-même.

Projet interne : présenté de façon générique, le code source n'est pas public.

Ce que fait l'outil

• Interroge périodiquement une quinzaine de services avec des jeux de requêtes représentatifs des usages réels.
• Valide chaque réponse au-delà du simple « ça répond » : code retour, structure du message, présence du contenu métier attendu.
• Mesure les temps de réponse pour repérer une dégradation avant la panne franche.
• Alerte l'équipe dès qu'un service sort de ses critères, avec le détail de ce qui a échoué.

Approche technique

Les scénarios sont des tests, pas des scripts. Chaque service est décrit comme un cas pytest paramétré : l'appel, les paramètres d'entrée, les assertions attendues. Ajouter un service revient à ajouter une entrée de données, pas à écrire du code. Ça a deux effets concrets : la couverture s'étend sans que le socle bouge, et un collègue qui ne connaît pas le projet peut relire ce qui est vérifié sans lire d'implémentation.

Valider la réponse, pas le transport. Un 200 OK ne dit pas que le service fonctionne : il peut renvoyer une enveloppe vide ou un code métier d'erreur. Les assertions descendent donc jusqu'au contenu — le champ attendu est-il là, le code métier est-il celui d'un cas nominal. C'est la différence entre un ping et une vraie vérification de bout en bout.

Le packaging compte autant que la logique. Le code est un package Python installable, avec sa configuration séparée des scénarios et des secrets hors du dépôt. Il tourne à l'identique en local pour le debug et dans la CI pour l'exécution planifiée, ce qui évite la classe de bugs « ça marche sur mon poste ».

L'exécution est déléguée à la CI. Une pipeline GitLab planifiée déclenche les contrôles, publie un rapport lisible et notifie en cas d'anomalie. Pas de machine dédiée à maintenir, pas de tâche planifiée sur un poste qui s'éteint : l'infrastructure qui fait déjà tourner les tests fait tourner la surveillance.

Tolérance aux faux positifs. Un timeout réseau isolé ne doit pas réveiller l'équipe pour rien. Les contrôles distinguent l'échec ponctuel de l'échec persistant, et seul le second déclenche une alerte — sinon le bruit finit par faire ignorer les vraies pannes.

Ce que ça a appris

Le plus instructif a été de constater qu'une bonne partie des « pannes » remontées historiquement n'en étaient pas : des appels mal formés côté client, ou des jeux de données absents en homologation. En validant le contenu métier plutôt que le seul code HTTP, les rapports ont commencé à distinguer les deux — ce qui a changé la conversation avec les équipes, d'un « le service est tombé » vers un « voici ce qui a échoué, et pourquoi ».

L'autre enseignement porte sur la reprise d'un travail existant. La solution précédente n'était pas mauvaise, elle répondait à une autre question. Repartir de la question — qui doit être prévenu, et quand — plutôt que du code déjà écrit a mené à quelque chose de plus simple et de plus utile.

Limites connues

• Les seuils de temps de réponse sont fixés empiriquement, pas dérivés d'un SLA formalisé.
• La couverture porte sur les cas nominaux et quelques cas d'erreur connus, pas sur l'exhaustivité fonctionnelle des services.
• L'alerting suppose que l'équipe lit le canal de notification : la surveillance ne remplace pas une astreinte.