Cockpit d'exploitation : 6 indicateurs qu'on vérifie chaque nuit à minuit

Les outils web sont bloqués (permission non accordée, session non interactive), donc je ne peux pas fetcher pour re-vérifier. Je m'appuie sur nos données système réelles (que j'ai lues) pour les chiffres, et je cite des références externes établies et stables que je connais avec certitude (Google SRE, Nielsen Norman Group, Gartner), sans en inventer.

Pourquoi 6 indicateurs plutôt qu'un tableau de 40 ?

Un dirigeant de TPE ne pilote pas avec un tableau de bord d'ingénieur. Il pilote avec une question : « est-ce que ce dont dépend mon chiffre d'affaires fonctionne, oui ou non ? ». La plupart des dashboards répondent mal parce qu'ils empilent des métriques de vanité — nombre de visiteurs, temps moyen sur page — qui décrivent l'activité sans déclencher aucune décision.

La discipline SRE (Site Reliability Engineering) de Google recommande de partir de quatre « signaux d'or » : latence, trafic, erreurs, saturation (Monitoring Distributed Systems, O'Reilly, 2016). L'idée que nous en tirons : mieux vaut six indicateurs qu'on sait mesurer et interpréter que quarante qu'on regarde sans jamais agir. Un bon indicateur de cockpit a trois propriétés : il est mesuré (pas estimé), il a un seuil connu, et ce seuil déclenche une décision écrite à l'avance.

Quels indicateurs méritent d'être au mur ?

Voici la grille que notre audit de nuit remplit réellement. Les valeurs de la colonne « source » sont celles mesurées sur nos propres systèmes le 29 juillet 2026.

Indicateur	Ce qu'il mesure	Seuil qui déclenche une décision	Valeur mesurée (source)
Disponibilité des routes	% de pages et d'API qui répondent HTTP 200	< 100 % → ouvrir un ordre de correction	41/41 (sonde HTTP à 00:00)
Latence page d'accueil	temps de réponse serveur	> 1 s → investigation	~75 ms (mesure du matin)
Certificat TLS	jours avant expiration	< 21 jours → renouvellement	88 jours (scan certificat)
Disque serveur	% occupé sur le VPS	> 85 % → purge ou extension	67 % (df)
Sauvegarde vérifiée	dump réalisé et non vide	échec ou 0 objet → relance	224 Ko / 420 objets + 280 Ko / 559 objets
Parité mémoire	cohérence base ↔ index vectoriel	écart ≠ 0 → réindexation	5771 = 5771

Le seuil de latence à 1 s n'est pas arbitraire : au-delà d'une seconde, l'utilisateur perd le fil de son action (Nielsen Norman Group, Response Times: The 3 Important Limits, 1993). Nos 75 ms sont très en deçà ; l'indicateur sert surtout à détecter une dégradation avant qu'un client ne s'en plaigne.

Comment savoir qu'un indicateur « vert » est vraiment vert ?

C'est le piège central du pilotage digital : un check qui vérifie que le service tourne, mais pas qu'il produit un résultat. Exemple réel de nos journaux. Le 26 juillet, notre sauvegarde hebdomadaire a d'abord échoué en silence : pg_dump: error: aborting because of server version mismatch. La commande s'est lancée, le job s'est « exécuté » — mais aucun octet exploitable n'a été produit. Un dashboard naïf aurait affiché « sauvegarde : OK ». Le nôtre a affiché alerte, parce que l'indicateur ne compte pas « la commande a tourné » mais « le dump existe et contient des objets ». Après correction, la sauvegarde est passée à 224 Ko / 420 objets et 280 Ko / 559 objets — des valeurs mesurées, comptées, pas déclarées.

C'est la différence entre estimé et vérifié. Un cockpit qui confond les deux ment à son dirigeant. La règle d'or de Google en matière de SLO (Service Level Objectives) va dans le même sens : on mesure ce que vit l'utilisateur, pas ce que rapporte le serveur sur lui-même (The SRE Workbook, « Implementing SLOs », Google, 2018).

Comment installer ce cockpit en 7 étapes ?

1. Lister ce dont dépend le chiffre d'affaires. Site, tunnel de paiement, formulaire de contact, API. Piège : mettre au mur ce qui est facile à mesurer plutôt que ce qui compte. Critère de réussite : chaque ligne du cockpit correspond à un flux qui, s'il tombe, fait perdre de l'argent.

2. Écrire la décision AVANT le seuil. Pour chaque indicateur, une phrase : « si X dépasse Y, alors on fait Z ». Piège : l'indicateur rouge sans propriétaire ni action. Critère de réussite : aucun indicateur sans décision associée par écrit.

3. Mesurer le résultat, pas l'exécution. Le check doit échouer si le produit final est vide (dump de 0 objet, page 200 mais corps d'erreur). Piège : « le processus a tourné » ≠ « le processus a réussi ». Critère de réussite : un test volontairement cassé fait bien passer l'indicateur au rouge.

4. Régler les seuils contre le « crier au loup ». Un seul échec réseau ne doit pas réveiller le dirigeant. On exige plusieurs échecs consécutifs avant d'alerter (anti-flapping). Piège : seuil trop sensible = alertes ignorées au bout d'une semaine. Critère de réussite : zéro fausse alerte sur 7 jours de fonctionnement normal.

5. Automatiser la vérification à heure fixe. Chez nous, un cron lance l'audit chaque nuit à 00:00, en lecture seule. Piège : la vérification « quand j'y pense » n'existe pas. Critère de réussite : un rapport daté est généré même quand tout va bien (le 29 juillet : verdict SAIN, 0 anomalie).

6. Tracer et ne jamais écraser l'historique. Les rapports sont datés ; le journal est en append-only (format .jsonl). Piège : écraser l'état d'hier, c'est perdre la mémoire des incidents. Critère de réussite : on peut relire, six mois plus tard, quand un incident a eu lieu et comment il a été refermé.

7. Tester la reprise, pas seulement la sauvegarde. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie. Piège : découvrir le jour du sinistre que le dump était corrompu. Critère de réussite : restauration testée au moins une fois, et comptage d'objets à chaque cycle.

Ce qu'on en fait chez nous

Ce cockpit tourne sur les trois systèmes que nous exploitons, consolidés dans un audit unique. Le déclenchement n'est pas cosmétique : quand une sonde renvoie un 503, un ordre est ouvert automatiquement, tracé avec un identifiant, puis refermé une fois la route revenue à 200 — nous avons vérifié ce cycle en simulant une panne (/tarifs 503 → ordre ouvert → refermé). Le principe de traçabilité guide tout : observer relève d'un niveau L1 (lecture seule), agir ou corriger passe par un niveau supérieur avec validation. Le cockpit montre ; il ne corrige pas de lui-même.

Deux chiffres qui résument notre parti pris. D'un côté, Gartner estime le coût moyen d'une indisponibilité à 5 600 $ la minute (Andrew Lerner, The Cost of Downtime, Gartner, juillet 2014) — moyenne de grande entreprise, sans rapport avec une TPE, mais qui dit la direction. De l'autre, notre latence mesurée à 75 ms : elle ne « rapporte » rien tant qu'elle est verte, mais elle est le premier indicateur à bouger quand une base sature. Le cockpit n'existe pas pour se féliciter quand tout va bien ; il existe pour que la première minute de panne ne soit pas découverte par un client.

Questions fréquentes

Combien d'indicateurs pour une TPE sans équipe technique ? Six à huit suffisent : disponibilité, latence, certificat, disque, sauvegarde vérifiée, et un indicateur métier propre à l'activité (paiement, prise de rendez-vous). Au-delà, personne ne les lit. La règle : si un indicateur ne déclenche jamais de décision en six mois, il quitte le cockpit.

Faut-il un outil payant pour commencer ? Non. Le nôtre repose sur des sondes HTTP, un cron à heure fixe et des fichiers datés. L'essentiel n'est pas l'outil mais la discipline : mesurer un résultat, fixer un seuil, écrire la décision, ne jamais écraser l'historique. Un prestataire peut le mettre en place en quelques heures.

Mon prestataire dit que « tout est vert » — comment vérifier ? Demandez à voir la dernière restauration de sauvegarde testée (pas la sauvegarde, la restauration), et un rapport daté généré un jour où tout allait bien. Un système d'observation qui ne produit rien quand tout va bien ne produira rien non plus le jour de la panne.

Sources

• Monitoring Distributed Systems (Four Golden Signals) — Google SRE Book, O'Reilly, 2016
• Implementing SLOs — The SRE Workbook, Google, 2018
• Response Times: The 3 Important Limits — Nielsen Norman Group (Jakob Nielsen), 1993
• The Cost of Downtime — Gartner (Andrew Lerner), juillet 2014