valider : la recette Prometheus attend une minute au plus que ses cibles soient relevees

La reconstruction de Technolibre s'est arretee : la recette a juge Prometheus 18 s apres sa relance par le premier depot d'obs-01. Elle redemande desormais, puis juge. Journal (112) Keycloak et (113).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CHANGELOG.md

@@ -1,5 +1,61 @@
 # CHANGELOG — Set-OPS
 
+## 2026-10-08 (113) — La recette jugeait Prometheus 18 secondes après sa relance
+
+**94 preuves.** La reconstruction de Technolibre (`2dce6ea`) s'est arrêtée à `valider` :
+« cibles DOWN : `10.23.18.11:9187`, `localhost:9090` », sur `obs-01`.
+
+### Ce qui s'est passé
+
+- 13:42:30 : `serveur_prometheus` arrête Prometheus, remet la base de l'instantané d'avant
+  rasage, relance. Rejeu du WAL restauré : 0,46 s ; prêt dans la seconde. **La restauration a
+  fonctionné.**
+- 13:59:53 : le premier dépôt d'`obs-01` (gestionnaire « Premier rapport à Icinga » de
+  `client_backup`, en fin de déploiement) fait sa copie à froid. Prometheus est arrêté 388 ms,
+  puis relancé. C'est nouveau : hier, `obs-01` n'était pas sauvegardé.
+- 14:00:11 : la recette interroge les cibles, **18 s après la relance** ; deux n'ont pas encore
+  de relevé réussi.
+- 16:17 : interrogé à nouveau, aucune cible en panne.
+
+### Fait
+
+La recette Prometheus redemande les cibles **jusqu'à ce que toutes soient relevées, une minute
+au plus**, puis juge. Une vraie panne échoue toujours, une minute plus tard. La condition est
+éprouvée sur des réponses fabriquées (toutes saines : arrêt ; une inconnue : attente ; une en
+panne après six tentatives : jugement ; API muette : pas d'attente vaine). Syntaxe et lint
+propres.
+
+**Pas éprouvé en vrai** : la reprise ne reproduira pas la relance (le premier rapport
+d'`obs-01` est fait, son marqueur posé). La prochaine reconstruction de Chezlepro, oui.
+
+## 2026-10-08 (112) — Keycloak ne régénère pas ses clés à la reconstruction ; ses sessions hors ligne perdues sont celles d'admin-cli
+
+**94 preuves.** Deux signaux des témoins, à chaque reconstruction : `component_config`
+« 23 retirée(s), 23 nouvelle(s) » sur 139, et les sessions hors ligne perdues. Hypothèse :
+les clés de signature du royaume régénérées par le rôle, ce qui invaliderait tous les jetons
+en circulation.
+
+### Mesuré, et l'hypothèse tombe
+
+Chezlepro, instantané `avant-raser` (`54444365`) contre base vivante, composant par
+composant et valeur par valeur : **38 composants des deux côtés, aucun perdu, aucun nouveau,
+aucune valeur changée**, clés comprises. Les « 23 renouvelées » étaient un faux signal du
+comparateur : il juge une table par sa première colonne, et celle de `component_config` est
+un identifiant de ligne, que Keycloak réécrit à contenu égal. Listé sans écart, donc sans
+conséquence, mais trompeur.
+
+### Les sessions hors ligne
+
+Toutes celles de la base vivante appartiennent à **`admin-cli`**, pour un seul compte :
+l'outillage des déploiements, qui les recrée. Aucune application des utilisateurs n'en
+détient. Les sessions de navigateur, elles, disparaissent avec les VM : se reconnecter une
+fois après une reconstruction en fait partie.
+
+**Pas un défaut aujourd'hui.** Il le deviendrait le jour où une application gardera des
+jetons hors ligne pour le compte d'une personne (client de synchronisation Nextcloud de
+bureau ou mobile, par exemple) : chaque reconstruction obligerait à se réauthentifier. La
+raison pour laquelle les sessions d'`admin-cli` disparaissent n'est pas établie.
+
 ## 2026-10-08 (111) — Le catalogue des capteurs au site, et une mise à jour que la simulation ne montrait pas
 
 **94 preuves.** Le catalogue des capteurs d'Icinga (accents, consignes « action », 2026-10-04)

playbooks/valider.yml

@@ -11,11 +11,23 @@
   gather_facts: false
   become: false
   tasks:
-    - name: Interroger l'API des cibles actives
+    # UN PROMETHEUS QUI VIENT DE REDEMARRER N'A PAS ENCORE RELEVE SES CIBLES (2026-10-08).
+    # Depuis qu'obs-01 est sauvegarde, son premier depot (copie a froid, en fin de
+    # deploiement) relance Prometheus : a la reconstruction de Technolibre, la recette l'a
+    # interroge 18 s apres, et deux cibles n'avaient pas encore de releve reussi — saines
+    # quelques minutes plus tard. On redemande donc, une minute au plus, avant de juger :
+    # une vraie panne echoue toujours, une minute plus tard.
+    - name: Interroger l'API des cibles actives (jusqu'a ce que toutes soient relevees, une minute au plus)
       ansible.builtin.uri:
         url: "http://localhost:9090/api/v1/targets?state=active"
         return_content: true
       register: prom_targets
+      until: >-
+        ((prom_targets.content | default('{}') | from_json).get('data', {}).get('activeTargets', [])
+         | rejectattr('health', 'equalto', 'up') | list | length == 0)
+        or (prom_targets.attempts | default(0) | int >= 6)
+      retries: 6
+      delay: 10
 
     - name: Analyser up / down
       vars: