Savoir avant que le client n'appelle

Une panne franche se voit. Ce qui coûte réellement, ce sont les dégradations : un traitement de nuit qui n'a pas tourné, une file d'intégration qui monte doucement, des temps de réponse qui doublent sur une population d'utilisateurs. Personne ne les remarque tant qu'un client ne s'en plaint pas, et l'on répare alors dans l'urgence.

La supervision sert à déplacer ce moment. Elle ne rend pas le système plus fiable, elle fait arriver l'information avant la plainte — ce qui n'est pas la même chose, mais change tout à la conduite d'une exploitation.

Fonctionnalités principales

• Dashboards infra : CPU/RAM, Postgres, Nginx, workers Odoo, caches.
• Dashboards métiers : volume commandes, délais livraison, erreurs d’intégration.
• Sources de données : Prometheus, Loki, Postgres/Timescale, Elasticsearch.
• Alerting multi-canaux et maintenance windows.
• Embedding possible dans Odoo (portail/supervision).

Données échangées (exemples)

• Métriques temps réel, logs applicatifs, traces d’intégration.
• Annotations (déploiements, incidents) pour la corrélation.

Questions fréquentes

Quelle différence avec un outil de restitution ?

L'angle du temps. Ici on regarde ce qui se passe maintenant et comment cela évolue, avec des alertes quand un seuil est franchi. Pour analyser l'activité et croiser des données, voir Metabase ou Qlik Sense.

Peut-on suivre des indicateurs métier ?

Oui, et c'est souvent le plus utile. Le nombre de commandes non intégrées, l'âge de la plus ancienne en attente, le délai de préparation : ces courbes-là parlent aux exploitants, pas seulement aux techniciens.

Combien d'alertes faut-il régler ?

Le moins possible. Une alerte qui se déclenche souvent sans conséquence apprend à être ignorée, et c'est ainsi qu'on rate la seule qui comptait. Mieux vaut trois alertes qu'on traite que trente qu'on archive. Sur l'instrumentation en amont, voir OpenTelemetry.