supervision : la regle qui decide COMBIEN de sondes

Question posee : « une sonde par role, est-ce parce qu elles agregent
plusieurs verifications ? » Oui — et « une par role » n etait pas mon
critere, c etait une coincidence : la plupart de ces roles n ont qu une
preoccupation. Mesure : les quatorze sondes agregent de 2 a 6 chemins d
echec chacune.

Le critere, applique en silence jusqu ici, est desormais ecrit : UNE SONDE
PAR CAUSE D ACTION — ni par role, ni par verification.

CE QUE COUTE UNE AGREGATION ABUSIVE, dans le modele d Icinga : un service
= un etat, un historique, un acquittement. Fondre deux causes qui
appellent des gestes differents, c est ne plus pouvoir acquitter l une
pendant que l autre alerte, et lire comme un service instable ce qui est
deux faits distincts qui alternent.

CE QUE COUTE L EXCES INVERSE : un voyant de plus est un voyant de moins
regarde.

Le test : les deux echecs appellent-ils le meme geste, de la meme
personne, dans le meme delai ? Si oui une sonde, et le message nomme
lequel a parle. Si non, deux.

Par ce critere, deux sondes existantes sont abusives : `certificat` (trois
gestes — minuteur bloque, AC changee, consommateur a recharger) et
`cache-apt` (deux delais — panne immediate contre billet pour demain).
Non scindees : c est une decision sur le nombre de voyants au mur.

make prouver : CONFORME, 64 OK, 0 echec, 0 saute.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q

docs/supervision-conception.md

@@ -105,6 +105,35 @@ utilisait `openssl verify -CAfile racine`, alors que nos certificats sont signé
 allumée ne vaut pas mieux qu'une alarme jamais allumée : elle apprend à ne plus regarder.
 Une sonde se prouve donc **deux fois** — verte sur le sain, rouge sur le cassé.
 
+## Combien de sondes : une par CAUSE D'ACTION
+
+Ni une par rôle, ni une par vérification. **Une par geste que le verdict appelle.**
+
+Les quatorze premières sondes agrègent chacune de deux à six chemins d'échec, et ce choix
+avait été fait **sans être écrit** — d'où cette section, ajoutée le 2026-09-10 après la
+question : *« est-ce parce qu'elles agrègent plusieurs vérifications ? »*
+
+**Ce que coûte une agrégation abusive**, dans le modèle d'Icinga : un service = **un état,
+un historique, un acquittement**. Fondre deux causes qui appellent des gestes différents,
+c'est ne plus pouvoir acquitter l'une pendant que l'autre alerte — et lire comme *un
+service instable* ce qui est en réalité *deux faits distincts qui alternent*.
+
+**Ce que coûte l'excès inverse** : un voyant de plus est un voyant de moins regardé. Le
+dépôt le répète assez — *une supervision creuse est pire qu'aucune*.
+
+Le test pratique, à appliquer sans état d'âme :
+
+> Les deux échecs appellent-ils **le même geste, de la même personne, dans le même délai** ?
+> Si oui, une seule sonde, et le message nomme lequel des deux a parlé.
+> Si non, deux sondes.
+
+**Exemple d'agrégation légitime** — `moteur` : `icinga2` mort, `icingadb` mort, état figé en
+base. Trois causes, un seul geste : *va regarder la supervision*. Le message dit laquelle.
+
+**Exemple d'agrégation abusive** — `cache-apt` : « ne répond pas » arrête tout `apt` de
+l'écosystème, « volume à 90 % » est un billet pour demain. Même personne, gestes et
+**délais** différents : deux sondes.
+
 ## Une sonde doit pouvoir être mise en défaut *par paramètre*
 
 Corollaire des deux règles précédentes, et c'est ce qui rend la discipline tenable à