g2/enervision

Watch

Fork 0

runbook : reprise.md autoportante, les trois trous du rejeu tiers (#44) #230

Merged

lenaic merged 1 commit from gabriel/44-reprise-autoportante into develop

2026-09-09 08:36:16 +00:00

gabriel commented

2026-09-09 08:30:06 +00:00

Member

Comble les trois trous relevés par le rejeu à blanc de reprise.md mené par Marvin le 09/09, sans son auteur (relevé complet : docs/runbooks/reprise-rejeu-2026-09-09-marvin.md). C'est la boucle que l'exigence ENF-16 attend : un tiers rejoue, ce qui le bloque est le livrable, et ce qui le bloque est comblé.

Ce que ça change


R1 — étape 1	`Ubuntu 24.04` exact (assertion de tête de `site.yml`) ; renvoi à `deploiement.md` § Prérequis et § Amorçage d'une cible neuve. `hosts.ini` est ignoré par Git : absent d'un poste neuf, il fallait le dire.
R2 — étape 2	Variante d'amorçage cloud (en-tête de `bootstrap.yml`) ; `--check --diff` rétabli, que `site.yml` impose et que le manuel sautait ; la séquence en deux passes que « bases créées vides » masquait — or `restore.yml` restaure la base `mlflow` à l'étape 3.
R3 — étape 4	Deux contrôles copiables remplacent « un parcours métier court » : la requête sur `mesure_horaire` (`etl.md`) puis les trois `curl` (`application.md`). La base avant l'API — une API qui répond sur une base vide ne prouve rien.

Au passage, 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), pas restore.yml. reprise.md portait déjà la distinction en tête, deploiement.md ne la portait pas.

Lénaïc, deux points pour ta relecture

Le CA2 du #44 dit que le manuel est écrit par celui qui tient le geste, pas par le PO. Ces commits sont de moi et je l'assume à découvert : ce ne sont que des renvois vers tes propres sections de deploiement.md, plus deux commandes déjà publiées et vérifiées ailleurs dans docs/runbooks/. Aucune commande nouvelle n'est inventée — le README l'interdit, et je n'ai pas de cible pour en vérifier une. Ton approbation est ce qui rend le geste à son auteur ; si une formulation ne te convient pas, c'est la tienne qui gagne.
Rien n'a été rejoué pour valider ces corrections. Le journal des rejeux n'est donc pas touché : je n'y écrirai pas une ligne au nom de quelqu'un qui n'a pas joué. Si Marvin relit les étapes 1, 2 et 4 corrigées, c'est lui qui ajoute sa ligne.

Ferme la partie « autoportance » du rejeu du 09/09. Ne ferme pas le #41 : le rejeu réel et chronométré de restore.yml reste dû.

Comble les trois trous relevés par le **rejeu à blanc de `reprise.md` mené par Marvin le 09/09, sans son auteur** (relevé complet : `docs/runbooks/reprise-rejeu-2026-09-09-marvin.md`). C'est la boucle que l'exigence ENF-16 attend : un tiers rejoue, ce qui le bloque est le livrable, et ce qui le bloque est comblé. ### Ce que ça change | | | |---|---| | **R1** — étape 1 | `Ubuntu 24.04` exact (assertion de tête de `site.yml`) ; renvoi à `deploiement.md` § Prérequis et § Amorçage d'une cible neuve. `hosts.ini` est ignoré par Git : absent d'un poste neuf, il fallait le dire. | | **R2** — étape 2 | Variante d'amorçage cloud (en-tête de `bootstrap.yml`) ; `--check --diff` rétabli, que `site.yml` impose et que le manuel sautait ; la séquence **en deux passes** que « bases créées vides » masquait — or `restore.yml` restaure la base `mlflow` à l'étape 3. | | **R3** — étape 4 | Deux contrôles copiables remplacent « un parcours métier court » : la requête sur `mesure_horaire` (`etl.md`) puis les trois `curl` (`application.md`). La base avant l'API — une API qui répond sur une base vide ne prouve rien. | Au passage, `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), pas `restore.yml`. `reprise.md` portait déjà la distinction en tête, `deploiement.md` ne la portait pas. ### Lénaïc, deux points pour ta relecture 1. **Le CA2 du #44 dit que le manuel est écrit par celui qui tient le geste, pas par le PO.** Ces commits sont de moi et je l'assume à découvert : ce ne sont que des **renvois** vers tes propres sections de `deploiement.md`, plus deux commandes **déjà publiées et vérifiées ailleurs** dans `docs/runbooks/`. **Aucune commande nouvelle n'est inventée** — le README l'interdit, et je n'ai pas de cible pour en vérifier une. Ton approbation est ce qui rend le geste à son auteur ; si une formulation ne te convient pas, c'est la tienne qui gagne. 2. **Rien n'a été rejoué pour valider ces corrections.** Le journal des rejeux n'est donc **pas** touché : je n'y écrirai pas une ligne au nom de quelqu'un qui n'a pas joué. Si Marvin relit les étapes 1, 2 et 4 corrigées, c'est **lui** qui ajoute sa ligne. Ferme la partie « autoportance » du rejeu du 09/09. Ne ferme pas le #41 : le rejeu réel et chronométré de `restore.yml` reste dû.

gabriel added 1 commit

2026-09-09 08:30:06 +00:00

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

Intégration / Contrôles statiques du dépôt (pull_request) Successful in 9s

Details

Intégration / Workflows — lint et audit de sécurité (pull_request) Successful in 23s

Details

Intégration / Tableau de bord — dépendances, tests et construction (pull_request) Successful in 44s

Details

Intégration / Python — qualité, tests et dépendances (pull_request) Successful in 5m50s

Details

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.

gabriel referenced this pull request

2026-09-09 08:31:30 +00:00

[infra] Manuels d'exploitation, un par geste sensible #44

lenaic approved these changes

2026-09-09 08:32:13 +00:00

lenaic left a comment

Relu en vérifiant chaque affirmation plutôt qu'en te croyant. Les cinq tiennent.

Ce que la PR affirme	Vérifié
`site.yml` refuse toute version autre qu'Ubuntu 24.04	`site.yml:24`, `ansible_distribution_version == "24.04"`
`hosts.ini` est ignoré par Git	`.gitignore:35`, et l'inventaire ne porte que `hosts.ini.example`
`site.yml` impose `--check --diff` d'abord	`site.yml:8` et `deploiement.md:259`
`restore.yml` restaure la base `mlflow`	`restore.yml:23`, elle est dans la liste
`mlflow.env` vient de `genere-identifiants.sh`, le coffre l'ignore	`roles/app/tasks/main.yml:289` et `:490`

Et les deux commandes ajoutées sont bien déjà publiées ailleurs : la requête mesure_horaire est à etl.md:350, les trois curl à application.md:156-158. Aucune commande inventée, ta déclaration est exacte.

Sur ton point 1

Approuvé, et sur la base que tu poses toi-même. Ce sont des renvois vers des sections existantes et des commandes déjà vérifiées ailleurs. Le CA2 est respecté dans son intention : personne n'a inventé un geste qu'il n'a pas tenu.

Sur ton point 2

Bien vu de ne pas écrire au journal des rejeux au nom de quelqu'un qui n'a pas joué. C'est exactement la règle, et elle est plus facile à enfreindre qu'à tenir quand on veut fermer un ticket.

Un point, et il porte sur le seul geste qui compte vraiment

--check --diff marqué « obligatoire d'abord » à l'étape 2 vient d'un garde-fou écrit pour une autre situation. Dans deploiement.md, il protège d'un site.yml joué sur le serveur de travail qui écraserait l'état courant. C'est juste là-bas.

Sur une cible NEUVE, il n'y a rien à écraser, et --check sur une machine vierge échoue en cascade : une tâche interroge ce qu'une tâche précédente, non jouée en mode simulation, aurait dû créer. Le mode simulation d'Ansible n'a pas d'état intermédiaire.

Ni toi ni moi ne pouvons trancher : le groupe neuf est encore commenté, aucune cible vierge n'a jamais été déclarée. Mais le risque n'est pas symétrique — si ça casse, ça casse à l'étape 2 d'une procédure de reprise, c'est-à-dire à trois heures du matin avec la production à terre. C'est le pire endroit pour découvrir qu'une consigne ne s'applique pas.

Je ne bloque pas là-dessus. Une phrase suffit, et je te la propose plutôt que de la pousser sur ta branche :

--check sur une cible NEUVE peut échouer en cascade, le mode simulation
n'ayant pas d'état intermédiaire. Sur une reprise à froid, le sauter et jouer
site.yml directement : il n'y a rien à écraser. Le garde-fou de
deploiement.md vise le serveur de travail, pas une machine vierge.

Si tu préfères la formuler autrement, c'est la tienne qui gagne. Si tu préfères la laisser telle quelle et l'éprouver le jour du rejeu, dis-le et j'approuve quand même — c'est écrit ici, ça suffit à la tracer.

Bon pour moi.

Relu en vérifiant chaque affirmation plutôt qu'en te croyant. **Les cinq tiennent.** | Ce que la PR affirme | Vérifié | |---|---| | `site.yml` refuse toute version autre qu'Ubuntu 24.04 | `site.yml:24`, `ansible_distribution_version == "24.04"` | | `hosts.ini` est ignoré par Git | `.gitignore:35`, et l'inventaire ne porte que `hosts.ini.example` | | `site.yml` impose `--check --diff` d'abord | `site.yml:8` et `deploiement.md:259` | | `restore.yml` restaure la base `mlflow` | `restore.yml:23`, elle est dans la liste | | `mlflow.env` vient de `genere-identifiants.sh`, le coffre l'ignore | `roles/app/tasks/main.yml:289` et `:490` | Et les deux commandes ajoutées sont bien déjà publiées ailleurs : la requête `mesure_horaire` est à `etl.md:350`, les trois `curl` à `application.md:156-158`. **Aucune commande inventée**, ta déclaration est exacte. ### Sur ton point 1 Approuvé, et sur la base que tu poses toi-même. Ce sont des renvois vers des sections existantes et des commandes déjà vérifiées ailleurs. Le CA2 est respecté dans son intention : personne n'a inventé un geste qu'il n'a pas tenu. ### Sur ton point 2 Bien vu de ne pas écrire au journal des rejeux au nom de quelqu'un qui n'a pas joué. C'est exactement la règle, et elle est plus facile à enfreindre qu'à tenir quand on veut fermer un ticket. ### Un point, et il porte sur le seul geste qui compte vraiment **`--check --diff` marqué « obligatoire d'abord » à l'étape 2 vient d'un garde-fou écrit pour une autre situation.** Dans `deploiement.md`, il protège d'un `site.yml` joué sur le serveur de travail qui écraserait l'état courant. C'est juste là-bas. Sur une cible NEUVE, il n'y a rien à écraser, et `--check` sur une machine vierge échoue en cascade : une tâche interroge ce qu'une tâche précédente, non jouée en mode simulation, aurait dû créer. Le mode simulation d'Ansible n'a pas d'état intermédiaire. Ni toi ni moi ne pouvons trancher : le groupe `neuf` est encore commenté, aucune cible vierge n'a jamais été déclarée. Mais le risque n'est pas symétrique — si ça casse, ça casse à l'étape 2 d'une procédure de reprise, c'est-à-dire à trois heures du matin avec la production à terre. C'est le pire endroit pour découvrir qu'une consigne ne s'applique pas. Je ne bloque pas là-dessus. Une phrase suffit, et je te la propose plutôt que de la pousser sur ta branche : > `--check` sur une cible NEUVE peut échouer en cascade, le mode simulation > n'ayant pas d'état intermédiaire. Sur une reprise à froid, le sauter et jouer > `site.yml` directement : il n'y a rien à écraser. Le garde-fou de > `deploiement.md` vise le serveur de travail, pas une machine vierge. Si tu préfères la formuler autrement, c'est la tienne qui gagne. Si tu préfères la laisser telle quelle et l'éprouver le jour du rejeu, dis-le et j'approuve quand même — c'est écrit ici, ça suffit à la tracer. Bon pour moi.

lenaic merged commit 1055305b9b into develop

2026-09-09 08:36:16 +00:00

lenaic deleted branch gabriel/44-reprise-autoportante

2026-09-09 08:36:16 +00:00

lenaic referenced this pull request from a commit

2026-09-09 08:36:17 +00:00

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