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 faisait l'outil

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

Approche technique

Les scénarios étaient des tests, pas des scripts. Chaque service était décrit comme un cas pytest paramétré : l'appel, les paramètres d'entrée, les assertions attendues. Ajouter un service revenait à ajouter une entrée de données, pas à écrire du code. Ça avait deux effets concrets : la couverture s'étendait sans que le socle bouge, et un collègue qui ne connaissait pas le projet pouvait relire ce qui était 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 descendaient 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 comptait autant que la logique. Le code était un package Python installable, avec sa configuration séparée des scénarios et des secrets hors du dépôt. Il tournait à l'identique en local pour le debug et dans la CI pour l'exécution planifiée, ce qui évitait la classe de bugs « ça marche sur mon poste ».

L'exécution était déléguée à la CI. Une pipeline GitLab planifiée déclenchait les contrôles, publiait un rapport lisible et notifiait 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 faisait déjà tourner les tests faisait tourner la surveillance.

Tolérance aux faux positifs. Un timeout réseau isolé ne devait pas réveiller l'équipe pour rien. Les contrôles distinguaient l'échec ponctuel de l'échec persistant, et seul le second déclenchait 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 étaient fixés empiriquement, pas dérivés d'un SLA formalisé.
• La couverture portait sur les cas nominaux et quelques cas d'erreur connus, pas sur l'exhaustivité fonctionnelle des services.
• L'alerting supposait que l'équipe lise le canal de notification : la surveillance ne remplaçait pas une astreinte.