Spécialiste européen du reconditionné
61 règles d'alerte qui surveillent le métier autant que les serveurs.
61
règles d'alerte chargées en production
26
portent sur des invariants métier
12
tableaux de bord par usage
En bref
- Le problème
- Un système distribué peut rester entièrement au vert côté machines pendant qu'un planificateur est arrêté depuis trois jours ou qu'une synchronisation vers l'ERP échoue en silence.
- La décision
- Une plateforme d'observabilité sur son propre serveur, dont les alertes portent sur les invariants métier et sur l'absence de signal, pas seulement sur les seuils d'infrastructure.
- Le résultat
- En production depuis juillet 2026 : l'alerte nomme le problème métier au lieu d'un symptôme technique, et arrive avant l'appel du client.
Le contexte
Le système fonctionnait. Le problème n'était pas de le faire tourner, c'était de pouvoir affirmer, à un instant donné, qu'il tournait correctement.
La supervision classique peut rester au vert pendant que l'activité est à l'arrêt, parce qu'elle surveille des machines et non le métier.
Nous exploitons pour ce client une plateforme distribuée : plusieurs services spécialisés, un bus d'événements, des adaptateurs vers des canaux externes, un ERP et un prestataire de paiement à l'autre bout.
La supervision classique répond mal à cette question. Elle surveille des machines : processeur, mémoire, disque, disponibilité HTTP. Tous ces indicateurs peuvent rester au vert pendant qu'un planificateur s'est arrêté trois jours plus tôt, qu'une file d'attente s'allonge sans être consommée, qu'une synchronisation vers l'ERP échoue silencieusement, ou que le stock affiché ne correspond plus au stock réel. Aucun serveur n'est en panne. L'activité, elle, est à l'arrêt.
Nous avons donc construit une plateforme d'observabilité dédiée, dont le principe directeur est simple : une alerte doit se déclencher sur ce qui compte pour l'exploitation du métier, pas seulement sur ce qui est facile à mesurer sur une machine.
Les décisions d'architecture
La pile de supervision tourne sur son propre serveur, pour rester lisible au moment précis où la machine surveillée tombe.
Pile de supervision sur son propre serveur, séparé des applications surveillées, pas Installer la collecte et les tableaux de bord sur les serveurs applicatifs existants. Une supervision hébergée sur la machine qu'elle surveille disparaît en même temps qu'elle. Or c'est précisément au moment où un hôte sature, redémarre en boucle ou perd son disque que l'on a besoin de lire ses métriques et ses journaux des dernières heures. Un serveur dédié garantit que l'incident et son témoin ne partagent aucun point de défaillance : saturation disque, panne d'hôte, redémarrage d'orchestration.
Trade-off assumé : Une machine de plus à financer, à durcir et à maintenir, et un flux de données à faire transiter entre réseaux. La collecte se fait donc en mode « push » depuis chaque hôte surveillé vers la pile centrale, sur des accès authentifiés et chiffrés, plutôt qu'en ouvrant les hôtes de production à un collecteur externe.
Sur les 61 règles chargées en production, 26 ne parlent pas de serveurs mais d'invariants métier : stock, paiements, commandes, quotas, tâches planifiées.
Des règles d'alerte sur les invariants métier, pas seulement sur l'infrastructure, pas S'en tenir aux exportateurs standards : hôte, conteneurs, disponibilité des URL. Sur les 61 règles chargées en production, 26 ne parlent pas de serveurs. Elles surveillent des propriétés que le métier considère comme toujours vraies : le stock annoncé correspond au stock réel, les paiements encaissés se réconcilient avec les commandes, les commandes partent bien vers l'ERP, le quota d'API vers cet ERP n'est pas consommé avant la fin de journée, les tâches planifiées ont toutes tourné dans leur fenêtre. Une violation de l'une de ces propriétés coûte de l'argent en quelques heures, alors qu'aucun indicateur d'infrastructure ne bouge.
Trade-off assumé : Ces règles ne s'installent pas : elles supposent que chaque application publie l'invariant sous forme de mesure. C'est du travail d'instrumentation dans le code applicatif, et une règle à maintenir chaque fois que la règle de gestion évolue. En contrepartie, l'alerte arrive avant l'appel du client, et elle nomme le problème métier au lieu de décrire un symptôme technique.
Une règle se déclenche aussi sur l'absence de signal, parce qu'un planificateur arrêté n'émet pas d'erreur : il n'émet plus rien.
Alerter sur l'absence de signal autant que sur sa valeur, pas Ne déclencher que sur des seuils dépassés : taux d'erreur, latence, saturation. Les pannes coûteuses sont silencieuses. Un planificateur arrêté n'émet pas d'erreur, il n'émet plus rien. Une règle de seuil ne se déclenche jamais sur une série de mesures qui a cessé d'exister : elle reste sans données, donc sans alerte. Nous avons donc une famille de règles dédiées à l'absence : 17 règles qui vérifient que chaque tâche planifiée a bien tourné dans sa fenêtre, des règles qui détectent qu'un hôte a cessé d'envoyer ses métriques ou ses journaux, des règles qui signalent qu'un contrôle d'intégrité ne rend plus son verdict, et un signal de vie permanent dont la disparition est elle-même une alerte.
Trade-off assumé : Beaucoup de règles, donc un risque de bruit et d'usure des astreintes. La contrepartie est un routage strict : chaque règle est classée en « à traiter maintenant » ou « à traiter dans la journée », avec des seuils distincts entre pré-production et production, et les alertes de disponibilité et de latence sont pilotées par vitesse de consommation du budget d'erreur plutôt que par seuil brut.
L'exécution
Rien n'est édité à la main sur les serveurs : toute la configuration de supervision vit dans un dépôt git et se déploie par fusion de branche.
Une règle d'alerte se relit en revue de code, et l'historique dit qui a changé quoi, quand et pourquoi.
Les règles d'alerte, les tableaux de bord, les cibles de sonde, les durées de rétention et la configuration de routage vivent dans un dépôt git. Une fusion sur la branche d'un environnement déclenche GitHub Actions, qui déploie la configuration correspondante.
73 versionnées / 61 chargéesDeux environnements sont surveillés avec la même mécanique et des réglages différents : 73 règles versionnées au total, dont les 61 chargées en production.
Les règles restantes sont les variantes de pré-production, avec leurs propres seuils.
La pré-production garde ses journaux quelques jours, la production les garde 30 jours, avec 90 jours de métriques plafonnés à 40 Go. Chaque hôte surveillé fait tourner un agent de collecte qui pousse métriques et journaux vers la pile centrale ; les journaux sont structurés et étiquetés par service, ce qui permet de passer d'une alerte à la ligne de journal qui l'explique sans changer d'outil.
Des sondes externes interrogent les URL publiques depuis le serveur de supervision, seul point de vue qui corresponde à celui d'un client.
Depuis le serveur de supervision, donc depuis l'extérieur de l'infrastructure applicative, des requêtes réelles vérifient que les URL publiques répondent, que les redirections sont correctes et que les certificats TLS ne sont pas près d'expirer.
Les 12 tableaux de bord sont découpés par usage plutôt que par technologie, jusqu'à une vue de la supervision elle-même.
Une vue de flotte pour l'état général du parc, des vues par service, une vue commandes et paiements, des vues files d'attente adossées à leurs propres règles de saturation et de retard, une vue journaux, une vue budget d'erreur, et une vue de la supervision elle-même.
Les leçons
Leçon 1Un tableau de bord tout vert ne prouve rien s'il ne regarde que des machines.
Nos premières semaines ont validé la pile technique avec des règles d'infrastructure classiques, et ces règles n'ont presque jamais parlé. Ce n'était pas le signe que tout allait bien, c'était le signe qu'elles regardaient ailleurs. Les incidents qui ont réellement coûté quelque chose se voyaient dans l'écart entre deux compteurs métier, jamais dans une courbe de processeur. C'est ce constat qui a fait basculer près de la moitié de l'effort de conception vers les règles métier.
Leçon 2La question utile n'est pas « le système a-t-il envoyé une alerte ? », c'est « saurions-nous qu'il ne peut plus en envoyer ? ».
Une pile d'observabilité est un système en production comme un autre : elle tombe, elle sature, elle rate une collecte. Tant qu'elle n'est pas surveillée, elle transforme une panne en silence rassurant. Nous traitons donc l'absence de verdict comme un verdict négatif : un contrôle d'intégrité qui ne rend plus de résultat déclenche la même alerte que le contrôle échoué, et un signal de vie émis en continu doit être reçu par un témoin extérieur, faute de quoi quelqu'un est prévenu.
En production aujourd'hui
La plateforme tourne depuis juillet 2026 sur son serveur dédié, et a reçu près de 190 évolutions depuis sa mise en service. Elle surveille en continu la pré-production et la production de la plateforme du client : 61 règles d'alerte chargées, dont 26 portent sur des invariants métier, 12 tableaux de bord, 30 jours de journaux interrogeables et 90 jours de métriques.
C'est la brique que nous installons en phase d'Exploitation sur les systèmes que nous livrons, et la source des rapports mensuels remis au client. Une seconde instance est en cours de mise en place, sur le même modèle, pour les services que nous exploitons en propre.
Un système à concevoir, déployer ou reprendre en main ?
Avec ou sans cahier des charges : décrivez votre situation, nous répondons par écrit sous 48 h ouvrées.