Mise en production : la supervision qui voit le chemin du jury, le stockage de secours, la traçabilité honnête #233

Merged

gabriel merged 22 commits from develop into main 2026-09-09 09:15:47 +00:00

Conversation 1 Commits 22 Files changed 43 +5253 -343

gabriel commented 2026-09-09 09:09:22 +00:00

Member

Copy link

Ce que ça change

Mise en production de tout ce qui est entré dans develop depuis la livraison
du 08/09 au soir (#220) : la supervision qui sonde enfin le chemin du jury et
les sept tâches planifiées, le stockage de secours Azure, le panneau de
traçabilité qui dit la vérité sur ce qu'il montre, et la documentation d'EC02.
C'est le critère de sortie du jalon J2 : main = develop.

Refs #48

Preuve

9 demandes de fusion, 22 commits, 11 fusions
43 fichiers, +5 253 / −343

Les demandes livrées :

#222  #223  #224  #226  #227
#229  #230  #231  #232

Elles servent les tickets #44, #48, #69, #215 et #228. Chacune est entrée dans
develop avec ses quatre tâches de chaîne au vert et l'approbation d'un pair.
Aucune n'a été forcée. La chaîne est au vert sur la tête de develop
(96eb3fd), les quatre tâches.

Aucune migration dans cette livraison. db/migrations est inchangé, et
.forgejo/workflows aussi. Le retour arrière est un git revert du commit de
fusion suivi d'un redéploiement, sans opération de base à défaire — ce qui
n'était pas le cas de la #220.

Ce qui change pour la démonstration

• La supervision voit le chemin du jury (#228). Jusqu'ici le job blackbox
  interrogeait chaque service sur son écoute directe : il serait resté tout vert
  avec Caddy arrêté, un vhost mal routé ou un /srv/www/app vide — les trois cas
  où plus personne ne peut ouvrir l'application. Le front n'était sondé nulle
  part. Un job blackbox-vhost sonde maintenant app.g2.enervision en 443, TLS
  et routage par nom d'hôte compris. MLflow et MinIO, également sans sonde,
  en ont une.
• L'arrêt d'une tâche planifiée se voit (#228). Sept tâches tournaient sous
  le cron de deploy, une seule publiait une métrique : l'arrêt de l'ETL argent,
  de l'ETL or, du chargement PostgreSQL, de la prévision ou des recommandations
  ne se voyait nulle part. bin/_metriques-ops.sh sort le mécanisme de
  collecte-current.sh et les six autres s'en servent ; une seule règle
  « tâche en retard » les couvre toutes, à partir de la cadence publiée.
• Deux tableaux Grafana neufs : « disponibilité » et « sorties produit ».
  Cinq règles d'alerte s'ajoutent — l'ENF-08 en compte dix (#232).
• Le panneau de traçabilité ne ment plus (#215). La courbe affiche une
  moyenne horaire, le panneau lisait la minute pile du haut de l'heure : jusqu'à
  52 kW d'écart relevés sur SITE003, sous une ligne intitulée « Valeur
  affichée ». Le panneau montre désormais les deux grandeurs, séparées et
  nommées, avec le nombre de minutes retenues — une heure dont la moyenne ne
  porte que sur deux minutes le dit maintenant.
• Le stockage de secours existe (#69). Compte de stockage adopté par
  Terraform, alerte de capacité qui sonne pour de vrai, runbook
  stockage-secours.md.
• La procédure de reprise a été rejouée par un tiers (#44, #222, #226).
  reprise.md est autoportante depuis, et le relevé du rejeu est au dépôt.
• EC02 : docs/RAPPORT-EC02.md, le planning annoncé contre le réalisé, et
  le journal d'équipe complété de son J5 et du week-end.

Relecture

• Un pair a relu et laissé un commentaire, même court
• Ses remarques sont traitées, ou une réponse explique pourquoi elles ne le sont pas

Où regarder en priorité

1. Ce que la fusion déclenche vraiment. Le rôle Ansible app déploie
repo_version: develop, pas main (infra/ansible/group_vars/all/vars.yml).
La fusion vers main déclenche donc un déploiement dont le contenu vient de
develop — identique à ce qui est fusionné à cet instant, mais ce n'est vrai
que parce que les deux branches coïncident au moment du push. Constat
antérieur, sans ticket ; il vaut d'être vu ici.

2. Le déploiement n'est toujours pas gardé par la chaîne. deploy.yml se
déclenche sur push: main, sans workflow_run ni needs. Sur un exécuteur
unique le déploiement peut partir avant le verdict de la chaîne. La barrière
reste une convention de fusion. Inchangé depuis la #220, redit ici parce que
c'est la deuxième mise en production.

3. La pile de supervision est recréée par le déploiement. supervision
est dans app_stacks avec recreate: true : Prometheus, Grafana et les
exportateurs redémarrent pendant le déploiement. Cette livraison change la
configuration de Prometheus, les règles d'alerte et les tableaux — c'est donc
le redémarrage qui les prend en compte, et une supervision brièvement muette
pendant qu'il se joue. À ne pas confondre avec une panne si quelqu'un regarde
au même moment.

4. Terraform ne part pas tout seul, et c'est voulu. stockage.tf,
alerte-capacite.tf et les sorties du #69 s'appliquent à la main, poste par
poste, sur l'abonnement école. Le plan attendu selon l'état du compte est
décrit dans infra/terraform/README.md. Rien dans cette fusion ne joint Azure.

5. Les scripts de tâches planifiées sourcent un fichier neuf.
bin/_metriques-ops.sh est sourcé par six scripts de cron. Il arrive par le
clone du dépôt que fait le rôle app, donc en même temps qu'eux — mais c'est
le point où un déploiement partiel casserait les six d'un coup. Le fichier est
écrit pour ne jamais faire échouer son appelant (ops_publier_resultat rend
toujours 0) ; c'est le point à vérifier en relecture.

## Ce que ça change Mise en production de tout ce qui est entré dans `develop` depuis la livraison du 08/09 au soir (#220) : la supervision qui sonde enfin le chemin du jury et les sept tâches planifiées, le stockage de secours Azure, le panneau de traçabilité qui dit la vérité sur ce qu'il montre, et la documentation d'EC02. C'est le critère de sortie du jalon J2 : `main` = `develop`. Refs #48 ## Preuve ``` 9 demandes de fusion, 22 commits, 11 fusions 43 fichiers, +5 253 / −343 ``` Les demandes livrées : ``` #222 #223 #224 #226 #227 #229 #230 #231 #232 ``` Elles servent les tickets #44, #48, #69, #215 et #228. Chacune est entrée dans `develop` avec ses quatre tâches de chaîne au vert et l'approbation d'un pair. Aucune n'a été forcée. La chaîne est au vert sur la tête de `develop` (`96eb3fd`), les quatre tâches. **Aucune migration dans cette livraison.** `db/migrations` est inchangé, et `.forgejo/workflows` aussi. Le retour arrière est un `git revert` du commit de fusion suivi d'un redéploiement, sans opération de base à défaire — ce qui n'était pas le cas de la #220. ## Ce qui change pour la démonstration - **La supervision voit le chemin du jury** (#228). Jusqu'ici le job `blackbox` interrogeait chaque service sur son écoute directe : il serait resté tout vert avec Caddy arrêté, un vhost mal routé ou un `/srv/www/app` vide — les trois cas où plus personne ne peut ouvrir l'application. Le front n'était sondé nulle part. Un job `blackbox-vhost` sonde maintenant `app.g2.enervision` en 443, TLS et routage par nom d'hôte compris. MLflow et MinIO, également sans sonde, en ont une. - **L'arrêt d'une tâche planifiée se voit** (#228). Sept tâches tournaient sous le cron de `deploy`, une seule publiait une métrique : l'arrêt de l'ETL argent, de l'ETL or, du chargement PostgreSQL, de la prévision ou des recommandations ne se voyait nulle part. `bin/_metriques-ops.sh` sort le mécanisme de `collecte-current.sh` et les six autres s'en servent ; une seule règle « tâche en retard » les couvre toutes, à partir de la cadence publiée. - **Deux tableaux Grafana neufs** : « disponibilité » et « sorties produit ». Cinq règles d'alerte s'ajoutent — l'ENF-08 en compte dix (#232). - **Le panneau de traçabilité ne ment plus** (#215). La courbe affiche une moyenne horaire, le panneau lisait la minute pile du haut de l'heure : jusqu'à 52 kW d'écart relevés sur SITE003, sous une ligne intitulée « Valeur affichée ». Le panneau montre désormais les deux grandeurs, séparées et nommées, avec le nombre de minutes retenues — une heure dont la moyenne ne porte que sur deux minutes le dit maintenant. - **Le stockage de secours existe** (#69). Compte de stockage adopté par Terraform, alerte de capacité qui sonne pour de vrai, runbook `stockage-secours.md`. - **La procédure de reprise a été rejouée par un tiers** (#44, #222, #226). `reprise.md` est autoportante depuis, et le relevé du rejeu est au dépôt. - **EC02** : `docs/RAPPORT-EC02.md`, le planning annoncé contre le réalisé, et le journal d'équipe complété de son J5 et du week-end. ## Relecture - [ ] Un pair a relu et laissé un commentaire, même court - [ ] Ses remarques sont traitées, ou une réponse explique pourquoi elles ne le sont pas ## Où regarder en priorité **1. Ce que la fusion déclenche vraiment.** Le rôle Ansible `app` déploie `repo_version: develop`, pas `main` (`infra/ansible/group_vars/all/vars.yml`). La fusion vers `main` déclenche donc un déploiement dont le contenu vient de `develop` — identique à ce qui est fusionné à cet instant, mais ce n'est vrai que parce que les deux branches coïncident au moment du push. Constat antérieur, sans ticket ; il vaut d'être vu ici. **2. Le déploiement n'est toujours pas gardé par la chaîne.** `deploy.yml` se déclenche sur `push: main`, sans `workflow_run` ni `needs`. Sur un exécuteur unique le déploiement peut partir avant le verdict de la chaîne. La barrière reste une convention de fusion. Inchangé depuis la #220, redit ici parce que c'est la deuxième mise en production. **3. La pile de supervision est recréée par le déploiement.** `supervision` est dans `app_stacks` avec `recreate: true` : Prometheus, Grafana et les exportateurs redémarrent pendant le déploiement. Cette livraison change la configuration de Prometheus, les règles d'alerte et les tableaux — c'est donc le redémarrage qui les prend en compte, et une supervision brièvement muette pendant qu'il se joue. À ne pas confondre avec une panne si quelqu'un regarde au même moment. **4. Terraform ne part pas tout seul, et c'est voulu.** `stockage.tf`, `alerte-capacite.tf` et les sorties du #69 s'appliquent à la main, poste par poste, sur l'abonnement école. Le `plan` attendu selon l'état du compte est décrit dans `infra/terraform/README.md`. Rien dans cette fusion ne joint Azure. **5. Les scripts de tâches planifiées sourcent un fichier neuf.** `bin/_metriques-ops.sh` est sourcé par six scripts de cron. Il arrive par le clone du dépôt que fait le rôle `app`, donc en même temps qu'eux — mais c'est le point où un déploiement partiel casserait les six d'un coup. Le fichier est écrit pour ne jamais faire échouer son appelant (`ops_publier_resultat` rend toujours 0) ; c'est le point à vérifier en relecture.

gabriel added this to the J2 — 09/09 démontrable milestone 2026-09-09 09:09:22 +00:00

gabriel self-assigned this 2026-09-09 09:09:22 +00:00

gabriel added 22 commits 2026-09-09 09:09:22 +00:00

[69] Stockage de secours 763b1b7064

Merge branch 'develop' into justine/69-stockage-archive-azure ... 87f3c986f3

# Conflicts:
#	docs/PLAN-MIGRATION-CLOUD.md
#	docs/adr/0012-plafond-de-depense-declare-hors-terraform.md

runbook : releve de rejeu de la procedure de reprise sans son auteur (#44) ... 955e0a13c0

Rejeu a blanc de reprise.md par un operateur autre que l'auteur (ENF-16 / EC02).

runbook : ligne du 2026-09-09 au journal des rejeux (#44) f9a44f46b6

Merge pull request 'runbook : rejeu de la procedure de reprise sans son auteur (#44)' (#222) from marvin/44-rejeu-reprise-enf16 into develop ... 11630ee10c

Reviewed-on: https://10.105.200.41/g2/enervision/pulls/222
Reviewed-by: gabriel <gabriel@noreply.10.105.200.41>

front+api: le panneau de tracabilite nomme les deux grandeurs qu'il montre (#215) ... e7254aec8c

La courbe a un pas d'une heure : chaque barre est la moyenne des soixante
minutes, lue dans mesure_horaire. La route de tracabilite lit public.mesure a la
cle exacte (site_id, horodatage), donc la minute PILE du haut de l'heure, une
sur soixante. La ligne s'appelait « Valeur affichee ». Elle ne l'etait pas.

Releve sur enervision_prod, SITE003, le 09/09 :

    heure    courbe      panneau     ecart
    05:00   749,40 kW   744,11 kW    -5,29
    04:00   757,55 kW   810,26 kW   +52,71
    03:00   763,90 kW   773,61 kW    +9,71

Le mecanisme d'auditabilite est juste de bout en bout : la cle est commune de la
zone bronze a la zone or, c'est verifiable et c'est l'ENF-07. C'etait son
APPARIEMENT a l'ecran qui mentait, et PanneauIdentite.vue affirme mot pour mot
« Chaque valeur affichee remonte a sa lecture et a sa methode ».

Le panneau montre desormais les deux, separes et nommes. « Ce que la courbe
affiche » : la moyenne de l'heure, et sur combien de minutes elle porte. « Lecture
d'origine d'une de ces minutes » : valeur retenue, valeur brute, methode,
qualite. Une phrase sous les deux blocs dit que l'ecart est normal.

C'est plus fort que l'ancien affichage, parce que c'est vrai : on voit la
moyenne, on voit une des minutes qui la composent, et on voit le lien.

La serie porte donc minutes_retenues et minutes_ecartees, sommes de
releves_pris_en_compte et releves_exclus que la migration 0016 pose depuis
toujours et que personne ne lisait. Second usage, dans le meme sujet : une heure
dont la moyenne porte sur DEUX minutes s'affichait comme une heure pleine — vu le
08/09 a 08:00 sur SITE003. Le panneau le signale maintenant.

chargerTracabilite prend le point entier et non son seul horodatage. Il reste
compatible avec un horodatage nu, que les cas d'essai et la vue site lui passent.

Eprouve : cinq cas neufs sur le panneau, trois assertions de GraphiqueSite mises
a jour, 346 cas Python au vert, mypy --strict et ruff propres. La requete a ete
passee a la main sur enervision_prod.

Une assertion de test a failli partir fausse : formaterKw arrondit a l'entier
(maximumFractionDigits: 0), 757,55 s'ecrit donc « 758 » et non « 757,6 ».
Verifie avant de commettre, pas apres la chaine rouge.

Merge branch 'develop' into justine/69-stockage-archive-azure 5aee54bce9

runbook : releve de rejeu, retrait de la ligne sur la programmation du #41 ... a3fbb310dc

La phrase laissait entendre que programmer l'exercice #41 relevait de ce
rejeu. Ce n'est pas le cas : le role tenu ici est de suivre la procedure
et de noter les blocages, pas d'organiser le rejeu chronometre. Le fait
que #41 reste a jouer est deja dit, comme constat neutre, dans la section
"Cadre" du meme fichier et en tete de reprise.md.

Merge pull request 'justine/69-stockage-archive-azure' (#223) from justine/69-stockage-archive-azure into develop ... 5c20eaede2

Reviewed-on: https://10.105.200.41/g2/enervision/pulls/223
Reviewed-by: marvin <marvin@noreply.10.105.200.41>

Merge pull request 'runbook : releve de rejeu, retrait d'une ligne qui attribuait le #41 a tort' (#226) from marvin/44-releve-retrait-ligne-41 into develop ... 7814d6e649

Reviewed-on: https://10.105.200.41/g2/enervision/pulls/226
Reviewed-by: gabriel <gabriel@noreply.10.105.200.41>

docs: rapport EC02, planning annonce contre realise (#48) ... 1540e3e5e5

Repond aux quatre criteres du ticket : decisions revisees avec leur motif, ecart
planning/realise mesure et explique, rituels dates, rendu avant le jour 9.

TOUS LES CHIFFRES SONT MESURES SUR LA FORGE ET LE DEPOT, aucun n'est estime de
memoire, et l'annexe donne les commandes qui les produisent. C'etait la condition
pour que ce rapport vaille quelque chose.

Ce que la mesure a appris, et que personne dans l'equipe ne savait avant :

66,5 jours-homme estimes ont ete fermes avec 40 jours-personne disponibles, soit
+66 %. L'ecart ne dit pas que l'equipe a produit deux tiers de plus que sa
capacite. Il dit que nos estimations etaient systematiquement genereuses, ecrites
au jour 1 avant que le socle existe, et jamais rouvertes. On ne l'a pas vu avant
de le mesurer pour ce rapport.

Les 5 et 6 septembre ont ete travailles. C'etaient un samedi et un dimanche, et
le planning annonce au jour 1 ne prevoyait pas de week-end. Le retard ne s'est
pas vu dans les livrables, il s'est absorbe dans du temps non prevu. Un planning
qui tient parce qu'on travaille le week-end est un planning qui n'a pas tenu.

Sept decisions du dossier individuel ont ete rouvertes en decision collective,
dix ADR sur treize portent une revision datee. Les deux qui ont coute sont
nommees : la fenetre de promotion du modele portee de trois a quatorze jours le
08/09, et les quatre regimes d'imputation qui ont remplace trois le 02/09.

Le rapport porte aussi ce que je referais autrement, parce que l'epreuve demande
un regard critique et pas un bilan : brancher la production plus tot, reestimer
au tiers du parcours, et ecrire les manuels avant d'en avoir besoin.

docs: le week-end a ete travaille par une seule personne, pas par l equipe (#48) ... 7813952350

Verifie sur le depot : les 5 et 6 septembre ne portent de commits que sous un
seul nom, vingt-six au total. Le rapport ecrivait « l'equipe travaille le
week-end », ce qui est faux et affaiblit le constat au lieu de le renforcer.

Le fait exact est plus dur et plus utile : le retard a ete absorbe par le Tech
Lead, seul, hors du temps prevu. Le debordement a donc disparu des indicateurs,
et l'equipe n'a pas pu arbitrer ce qu'elle ne voyait pas.

Une quatrieme lecon en decoule, ajoutee a la section critique : poser le
debordement au lieu de l'absorber.

docs: le journal d equipe retrouve son J5 et son week-end (#48) ... 65d99c85a7

Deux trous trouves en preparant le rapport EC02, comblés plutot que laisses.

J5, VENDREDI 4 SEPTEMBRE. Le detail par personne existait dans journal/j5.md
depuis le 07/09, mais le journal d equipe passait de J4 a J6 sans rien dire du 4
septembre. C etait pourtant la deuxieme meilleure journee du projet en nombre de
tickets fermes : onze, dont la zone or, l API sur donnees fictives, les deux
tickets Terraform et la planification de la zone argent.

LE WEEK-END DES 5 ET 6, qui n avait d entree nulle part. Vingt-six commits, tous
sous un seul nom. Le lundi 7 a demarre avec une pile applicative sur le serveur
parce que ces deux jours ont eu lieu ; sans eux il aurait demarre sans, et l
equipe l aurait vu.

L entree le dit pour ce que c est : un rattrapage et pas une performance. Le
debordement absorbe par une personne hors du temps prevu disparait des
indicateurs, et personne n arbitre ce qu il ne voit pas.

Les deux entrees portent leur mention de reconstruction et leur date, comme J6
et J7 avant elles. Un journal reconstruit qui le dit vaut mieux qu un trou.

docs: reprise.md devient autoportante, les trois trous du rejeu tiers (#44) ... 23a56515e5

Le rejeu à blanc de Marvin du 09/09, mené sans l'auteur, a relevé trois points
où la procédure n'est pas exécutable telle quelle par un opérateur qui n'a pas
déjà deploiement.md en tête. Aucun n'est structurel : ce sont des renvois
manquants et deux commandes absentes.

R1, étape 1 — Ubuntu 24.04 exact (assertion de tête de site.yml), et renvoi à
deploiement.md pour les prérequis et pour hosts.ini, ignoré par Git donc absent
d'un poste neuf.

R2, étape 2 — la variante d'amorçage cloud (en-tête de bootstrap.yml), le
--check --diff que site.yml impose et que le manuel sautait, et la séquence en
deux passes que « bases créées vides » masquait, alors que restore.yml restaure
la base mlflow à l'étape suivante.

R3, étape 4 — deux contrôles copiables à la place de « un parcours métier
court » : la requête de contrôle sur mesure_horaire (etl.md) et les trois curl
d'application.md, la base avant l'API.

Aucune commande nouvelle n'est introduite : toutes sont déjà publiées et
vérifiées ailleurs dans docs/runbooks/, comme le README l'exige. Le contenu
opératoire reste celui de son auteur.

deploiement.md : la « restauration chronométrée du #41 » est resserrée sur ce
qu'elle prouve réellement, l'exercice manuel en conteneurs du 2 septembre
(#92), et non restore.yml — distinction que reprise.md porte déjà en tête.

Merge pull request 'front+api : le panneau de traçabilité nomme les deux grandeurs qu'il montre' (#224) from lenaic/215-tracabilite-honnete into develop 4446236eec

Merge pull request 'docs : rapport EC02, le planning annoncé contre le réalisé' (#227) from lenaic/48-rapport-ec02 into develop 2564e3c4c1

Merge pull request 'docs : le journal d'équipe retrouve son J5 et son week-end' (#229) from lenaic/48-journal-j5-weekend into develop aab743252f

Merge pull request 'runbook : reprise.md autoportante, les trois trous du rejeu tiers (#44)' (#230) from gabriel/44-reprise-autoportante into develop 1055305b9b

supervision: combler les angles morts — sondes, tâches, sorties produit (#228) ... ac70d4a054

Relevé sur la production le 09/09 : la supervision était verte sur ce qu'elle
regardait, pas sur ce qui pouvait casser. Cinq trous, comblés ici.

1. SIX TÂCHES PLANIFIÉES SUR SEPT NE PUBLIAIENT AUCUNE MÉTRIQUE. Seul
   `collecte-current.sh` déposait un `.prom`. L'arrêt de l'ETL argent, de
   l'ETL or, du chargement PostgreSQL, de la prévision ou des recommandations
   ne se voyait nulle part. Le mécanisme sort de `collecte-current.sh` vers
   `bin/_metriques-ops.sh`, que les sept lanceurs sourcent. Chacun publie
   tentative, réussite, code, durée et CADENCE — cette dernière permet une
   règle d'alerte unique pour les sept au lieu de sept seuils recopiés.

   Les six lanceurs lançaient leur travail par `exec` : le shell était
   remplacé, rien ne pouvait s'exécuter après. Ils gardent la main, capturent
   le code, publient, et ressortent avec le même code. Le banc de supervision
   refuse désormais un `exec` en dernière ligne.

2. TREIZE MÉTRIQUES `probe_*` COLLECTÉES, AFFICHÉES NULLE PART. Nouveau
   tableau de bord `disponibilite` : frise de disponibilité par service,
   latences, décomposition HTTP, table des sondes, table des tâches, âge des
   sauvegardes, et l'état des alertes sur le même écran.

3. LE FRONT N'ÉTAIT SONDÉ NULLE PART. Les sondes visaient chaque service sur
   son écoute directe : elles seraient restées vertes avec un Caddy arrêté, un
   vhost mal routé ou un `/srv/www/app` vide — les trois cas où plus personne
   ne peut ouvrir l'application. Nouveau job `blackbox-vhost` qui traverse
   Caddy en 443. `app.g2.enervision` ne se résolvant pas depuis le serveur, le
   nom part en paramètre `hostname`, que blackbox pose en Host et en SNI.
   MLflow et MinIO, eux non plus sondés, rejoignent le job `blackbox`.

4. LES SORTIES DU PRODUIT N'ÉTAIENT PAS MONITORÉES. `prevision`,
   `recommandation`, `alerte` et `qualite_jour` n'avaient aucun panneau : le
   tableau de bord « chaîne de donnée » s'arrête à la zone or. Nouveau
   tableau de bord `sorties-produit`, qui reprend là où il finit.

5. CINQ ALERTES MANQUAIENT. Notre API n'en avait aucune alors que l'API source
   en avait une ; s'y ajoutent l'application injoignable, PostgreSQL
   injoignable, une tâche planifiée en retard et la mémoire du serveur. Un
   second groupe « Disponibilité » les porte, celui du #42 reste intact. La
   règle « cible tombée » couvre en plus `noms-conteneurs` et le nouveau job.

Vérifié contre la production, en lecture seule : les quatre nouvelles sondes
répondent 200 (conteneur blackbox jetable, arrêté depuis), `promtool check
config` accepte la configuration, `promtool check metrics` accepte chaque
fichier de métriques, et les treize requêtes SQL du nouveau tableau de bord
rendent le résultat attendu. Les sept lanceurs sont joués sur un banc à faux
interpréteur : code de sortie préservé, métrique juste, fichier de réussite
écrit seulement sur un succès, et une passe de préproduction ne rafraîchit
pas la fraîcheur de la production.

Trois trous restent ouverts et sont nommés dans le runbook et le ticket :
l'API n'expose aucune métrique applicative, les journaux ne sont pas agrégés,
les métriques HTTP par vhost de Caddy ne sont pas activées. Leur correctif
touche l'API ou le Caddy de la forge — pas dans une fenêtre de deux jours.

Merge pull request 'supervision : combler les angles morts — sondes, tâches planifiées, sorties produit (#228)' (#231) from gabriel/228-angles-morts-supervision into develop e76f346f04

docs: l ENF-08 compte dix alertes et non cinq (#228) ... 0b078d19ae

Le #228 en a ajoute cinq aux cinq du #42, en deux groupes. Le README de la pile
de supervision a suivi, l exigence non : elle annoncait toujours cinq.

Cinq n etait pas un plafond mais un plancher, donc dix ne violait rien. Mais un
jury qui compare l exigence au provisionne compte, et un ecart non explique se
lit comme un oubli plutot que comme un depassement. Le texte dit maintenant
« cinq au moins », avec le nombre reel et le ticket qui l a porte.

Merge pull request 'docs : l'ENF-08 compte dix alertes et non cinq' (#232) from lenaic/enf08-dix-alertes into develop ... 96eb3fddfb

Reviewed-on: https://10.105.200.41/g2/enervision/pulls/232
Reviewed-by: gabriel <gabriel@noreply.10.105.200.41>

gabriel requested review from lenaic 2026-09-09 09:09:31 +00:00

lenaic approved these changes 2026-09-09 09:10:55 +00:00

gabriel merged commit 415af1ad40 into main 2026-09-09 09:15:47 +00:00

gabriel referenced this pull request from a commit 2026-09-09 09:15:48 +00:00

Merge pull request 'Mise en production : la supervision qui voit le chemin du jury, le stockage de secours, la traçabilité honnête' (#233) from develop into main

gabriel referenced this pull request 2026-09-09 17:39:00 +00:00

Mise en production : la dérive du modèle, la chaîne aux dix minutes, les règles hors du code #252

gabriel referenced this pull request 2026-09-09 17:54:11 +00:00

supervision : la dérive du modèle se regarde, pas seulement s'alerte (#117) #253

Sign in to join this conversation.

Reviewers

No reviewers

lenaic

Labels

Clear labels   

Compat/Breaking

Breaking change that won't be backward compatible

  

EC01

Preuve pour l'épreuve Architecture

  

EC02

Preuve pour l'épreuve Management

  

EC03

Preuve pour l'épreuve CI/CD

  

EC04

Preuve pour l'épreuve Cloud

  

EC05

Preuve pour l'épreuve Data et BI

  

EC06

Preuve pour l'épreuve IA

  

Kind/BDD

BDD

  

Kind/Back

Back

  

Kind/Bug

Something is not working

  

Kind/CICD

CICD

  

Kind/Cloud

Cloud

  

Kind/Contenu

Contenu

  

Kind/Data

Data

  

Kind/Documentation

Documentation changes

  

Kind/Enhancement

Improve existing functionality

  

Kind/Feature

New functionality

  

Kind/Front

Front

  

Kind/IA

IA

  

Kind/Infra

Serveur, déploiement, chaîne, supervision

  

Kind/Monitoring

Monitoring

  

Kind/Security

This is security issue

  

Kind/Testing

Issue or pull request related to testing

  

Portée/Post-jury

Périmètre documenté, hors de la fenêtre du 11/09. Repris après le jury. Rien nest supprimé.

  

Priority

Critical

The priority is critical

  

Priority

High

The priority is high

  

Priority

Low

The priority is low

  

Priority

Medium

The priority is medium

  

Reviewed

Confirmed

Issue has been confirmed

  

Reviewed

Duplicate

This issue or pull request already exists

  

Reviewed

Invalid

Invalid issue

  

Reviewed

Won't Fix

This issue won't be fixed

  

Status

Abandoned

Somebody has started to work on this but abandoned work

  

Status

Blocked

Something is blocking this issue or pull request

  

Status

Need More Info

Feedback is required to reproduce issue or to continue work

  

ops/alerte

Alerte d'exploitation (relais Grafana, #42)

No labels

Compat/Breaking

EC01

EC02

EC03

EC04

EC05

EC06

Kind/BDD

Kind/Back

Kind/Bug

Kind/CICD

Kind/Cloud

Kind/Contenu

Kind/Data

Kind/Documentation

Kind/Enhancement

Kind/Feature

Kind/Front

Kind/IA

Kind/Infra

Kind/Monitoring

Kind/Security

Kind/Testing

Portée/Post-jury

Priority

Critical

Priority

High

Priority

Low

Priority

Medium

Reviewed

Confirmed

Reviewed

Duplicate

Reviewed

Invalid

Reviewed

Won't Fix

Status

Abandoned

Status

Blocked

Status

Need More Info

ops/alerte

Milestone

Clear milestone

No items

No milestone

J2 — 09/09 démontrable

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

gabriel

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

g2/enervision!233

No description provided.