Mise en production : les trois écrans manquants, les documents d'épreuve, Trivy et l'IAM en Terraform #271

Merged

marvin merged 33 commits from develop into main 2026-09-10 18:50:33 +00:00

Conversation 1 Commits 33 Files changed 50 +3459 -165

gabriel commented 2026-09-10 17:48:24 +00:00

Member

Copy link

Ce que ça change

Mise en production de tout ce qui est entré dans develop depuis la livraison
du 09/09 au soir (#259) : les trois écrans qui manquaient au tableau de bord
(administration des comptes, contact, note d'information RGPD), un document
d'entrée par épreuve pour le correcteur, Trivy dans la chaîne d'intégration,
l'attribution RBAC Azure sortie du script d'amorçage, et le correctif du
drapeau « reconstitué » qui hachurait des barres saines. main = develop.

Aucun ticket à fermer ici : chacun l'a été par sa propre demande de fusion.
Cette demande sert le gel de vendredi 9h00 et la soutenance EC02 du 11/09.

Preuve

8 demandes de fusion, 33 commits, 16 fusions
50 fichiers, +3 459 / −165

Les demandes livrées :

#260  #261  #262  #263
#264  #266  #268  #270

Elles servent les tickets #16, #19, #20, #237, #265, #267 et #269 ; la #260
(rapport de sécurisation EC04) n'a pas de ticket, elle répond directement à
l'énoncé. Chacune est entrée dans develop avec ses six tâches de chaîne au
vert et l'approbation d'un pair — sauf la #264, fusionnée sans revue
formelle (voir « Où regarder en priorité »). Aucune n'a été forcée.

La chaîne est au vert sur la tête de develop (19efc19), les six tâches.

Aucune migration dans cette livraison, et c'est ce qui la distingue de la
#252 : db/migrations/ s'arrête toujours à 0022_cadence_dix_minutes.sql.
Pas de nouvelle variable d'environnement, pas de changement de compose,
d'infra/ansible/ ni de rôle Ansible. Le retour arrière est donc un
git revert -m 1 du commit de fusion, suivi du déploiement continu qui
repart tout seul sur main. Rien à défaire côté base ni côté Azure.

.forgejo/workflows/ci.yml change — Trivy entre dans la chaîne — mais sans
créer de nouveau contrôle requis : l'étape vit dans la tâche
« Python — qualité, tests et dépendances », déjà couverte par le motif
Intégration / * de la protection de main. Rien à retoucher dans la
configuration de la branche avant de fusionner.

Ce qui change pour la démonstration

• Le tableau de bord a enfin ses trois écrans manquants.
  /administration (#16) liste les comptes triés par adresse avec leur état
  et leur date de création, réservé au rôle admin — le contrôle reste côté
  API, la vue ne fait que l'annoncer ; l'API gagne GET /auth/users, qui
  complète les POST et PATCH déjà en place et n'expose jamais le condensé
  du mot de passe. /contact (#19) prépare un courriel et le remet au client
  de messagerie du poste, l'API n'ayant aucune route de contact, avec
  l'adresse de l'exploitant affichée en clair à côté pour le poste sans client
  configuré. /confidentialite (#20) porte la note d'information de
  l'article 13 du RGPD. Les deux dernières sont lisibles sans session, depuis
  le pied de la page de connexion et depuis le menu du compte.
• La note RGPD annonce la durée qu'on pratique vraiment. Elle disait
  « douze mois glissants » pour les journaux d'authentification quand l'API
  purge à 90 jours (AUDIT_RETENTION_DAYS). Sur une note article 13, c'est
  une inexactitude substantielle : la page dit désormais quatre-vingt-dix
  jours, et une ligne « Sessions » distincte rappelle la session absolue de
  trente jours et la purge à sept jours (SESSION_RETENTION_DAYS). Un test
  verrouille la durée affichée.
• Une barre n'est plus « reconstituée » pour une seule minute imputée
  (#267). Les trois requêtes de série posaient imputee avec un bool_or sur
  tout le seau : une minute interpolée sur 60 (barre horaire) ou sur 1 440
  (barre journalière) hachurait la barre entière. SITE003 (data center) et
  SITE005 (hôpital), seuls sites au régime « report » de l'ADR 0006,
  ressortaient hachurés sur toutes leurs barres à 100 % de disponibilité.
  Les requêtes remontent maintenant le nombre de minutes reconstituées et
  tranchent sur la part (SEUIL_SEAU_IMPUTE = 0.5). Décision produit prise
  dans le même fil : la courbe de la fiche site ne distingue plus visuellement
  le mesuré du reconstitué, une seule teinte pour la consommation, seule la
  prévision se détache. La méthode d'une valeur reste lisible au clic dans le
  panneau de traçabilité, fenêtre 24 h. Connu et assumé : sur les fenêtres
  7 j et 30 j, qui n'ont pas de traçabilité, la méthode n'apparaît plus nulle
  part.
• Un document d'entrée par épreuve (#269, #260). L'énoncé demande un
  rapport de sécurisation EC04 et des documentations EC03 / EC05 / EC06 ;
  la matière existait, éparpillée entre docs/api/, docs/data/, docs/adr/,
  tests/ci/ et les manuels, mais un correcteur qui cherchait ces livrables
  par leur nom ne trouvait rien. Quatre documents les rassemblent :
  RAPPORT-EC04-SECURISATION.md, EC03-INTEGRATION-CONTINUE.md,
  EC05-CHAINE-DE-DONNEES.md, EC06-MODELE-ET-PREVISION.md. Leurs
  paragraphes « comment le vérifier » ont été rejoués sur le serveur, pas
  seulement écrits.
• Trivy analyse le dépôt à chaque demande de fusion (#269). Secrets et
  vulnérabilités HIGH/CRITICAL sont bloquants ; les constats de configuration
  sont journalisés et suivis par le #269, le temps de les traiter. La tâche ne
  peut pas mentir sur son propre état : une panne d'outil — archive
  indisponible, empreinte inattendue, curl absent de l'image — est déclarée
  skipped ou failed, jamais passed. C'est d'ailleurs ce qui s'est passé
  en cours de route : l'étape avait été écrite en croyant curl présent dans
  l'image slim, elle n'analysait rien ; le correctif est dans le lot.
• L'IAM Azure est déclaré en Terraform, plus seulement en bash (#237).
  L'unique droit que ce projet attribue lui-même — « Storage Blob Data
  Contributor » sur le compte qui porte l'état Terraform — était posé par
  bootstrap.sh et invisible ailleurs. Il vit maintenant dans
  infra/terraform/acces-etat.tf, adopté par import et non recréé : le
  script reste l'amorçage, Terraform devient la référence lisible, et les deux
  ne peuvent plus diverger sans qu'un plan -refresh-only le montre.
• La chaîne ne rougira plus au passage d'une date (#265). Le test de
  chargement zone or portait la journée 2026-09-03 écrite en dur ; passé le
  10/09, le garde-fou de compression controler_fenetre (sept jours) refusait
  la journée et le job Python rendait 4 au lieu de 0. La date est devenue
  glissante.

Si ça touche infra/terraform/

• terraform plan -out=tfplan — fait avant la fusion dans develop,
  dans la #264 ; rien n'a touché infra/terraform/ depuis.
• terraform apply tfplan — sans objet. Cette livraison ne crée
  aucune ressource Azure : le seul changement d'état a été un
  terraform import, joué et tracé dans la #264. Fusionner vers main ne
  rejoue rien côté Azure, l'apply n'étant pas automatisé (ADR 0007).
• Le pair a relu le plan, pas seulement le code

Ce qui reste au plan, et pourquoi

azurerm_monitor_action_group.capacite       will be created
azurerm_monitor_metric_alert.capacite       will be created
azurerm_storage_management_policy.archive[0] will be created

Plan: 3 to add, 0 to change, 0 to destroy.

Ces trois lignes n'appartiennent pas à cette livraison : ce sont les
ressources du #69, non applicables avec le rôle école
(Microsoft.Insights/actionGroups/write et managementPolicies/write sont
refusés). Voir les corrections datées du 10/09 sur les ADR 0007 et 0012.
azurerm_role_assignment.etat_donnees n'y figure pas : il est importé.

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

Ce qui suit le code

• docs/runbooks/ mis à jour — terraform-etat.md (manœuvre d'import,
  épinglage du principal, remède RoleAssignmentExists, retour arrière
  state rm, piège MSYS_NO_PATHCONV), stockage-secours.md (§3 corrigé :
  l'alerte de capacité qu'il décrivait comme active ne l'a jamais été,
  403 AuthorizationFailed sur Microsoft.Insights/actionGroups/write),
  ci.md (le motif d'une exception checkov, faux depuis le #69), et le
  README.md des manuels
• Trivy n'est documenté nulle part — ni dans docs/runbooks/ci.md, ni
  dans le nouveau docs/EC03-INTEGRATION-CONTINUE.md, dont le §2 énumère
  pourtant « les six verrous ». Voir « Où regarder en priorité »
• docs/adr/ complété — ADR 0007 (listKeys est accordé) et ADR 0012
  (Microsoft.Insights/* ne l'est pas ; l'alerte du #69 n'a jamais été en
  service)
• docs/journal.md — rien à consigner, aucun incident de production sur
  la période
• Aucune nouvelle variable d'environnement, .env.example est inchangé

Où regarder en priorité

1. La #264 est entrée dans develop sans revue formelle. C'est la seule
   du lot dans ce cas, et c'est celle qui touche Azure. Le changement est
   pourtant le plus facile à vérifier : il n'ajoute aucune ressource, il en
   adopte une qui existait déjà. La case « le pair a relu le plan » ci-dessus
   reste à cocher : c'est le geste attendu sur cette demande-ci.
2. La perte de la distinction mesuré / reconstitué sur 7 j et 30 j. Le
   choix se défend — hachurer en permanence un hôpital faisait lire une
   avarie qui n'existe pas — mais il retire une information de l'écran sur
   deux fenêtres sur trois. À valider avant la démonstration, pas après : le
   jury regarde l'EF-04.
3. Trivy entre bloquant dans la chaîne, et n'est écrit dans aucun
   document. grep -ril trivy docs/ ne rend rien : ni runbooks/ci.md, ni
   le EC03-INTEGRATION-CONTINUE.md livré par la même demande de fusion,
   dont le §2 énumère pourtant « les six verrous, et ce que chacun refuse ».
   Un septième verrou peut désormais refuser une fusion sans qu'aucun manuel
   dise ce qu'il contrôle ni quoi faire quand il rougit — et la base de
   vulnérabilités bouge toute seule, donc il rougira un jour sur une demande
   qui n'a rien changé. Le code fait déjà le bon geste, il distingue le
   constat de la panne d'outil ; c'est la ligne du tableau qui manque. Petit
   ticket à ouvrir, à faire avant le gel plutôt qu'après.
4. docs/EC0*.md sont des livrables de jury, pas de la documentation
   interne. Une relecture à voix haute vaut le coup : ce sont les quatre
   fichiers que le correcteur ouvrira en premier.

## Ce que ça change Mise en production de tout ce qui est entré dans `develop` depuis la livraison du 09/09 au soir (#259) : les trois écrans qui manquaient au tableau de bord (administration des comptes, contact, note d'information RGPD), un document d'entrée par épreuve pour le correcteur, Trivy dans la chaîne d'intégration, l'attribution RBAC Azure sortie du script d'amorçage, et le correctif du drapeau « reconstitué » qui hachurait des barres saines. `main` = `develop`. Aucun ticket à fermer ici : chacun l'a été par sa propre demande de fusion. Cette demande sert le gel de vendredi 9h00 et la soutenance EC02 du 11/09. ## Preuve ``` 8 demandes de fusion, 33 commits, 16 fusions 50 fichiers, +3 459 / −165 ``` Les demandes livrées : ``` #260 #261 #262 #263 #264 #266 #268 #270 ``` Elles servent les tickets #16, #19, #20, #237, #265, #267 et #269 ; la #260 (rapport de sécurisation EC04) n'a pas de ticket, elle répond directement à l'énoncé. Chacune est entrée dans `develop` avec ses six tâches de chaîne au vert et l'approbation d'un pair — **sauf la #264, fusionnée sans revue formelle** (voir « Où regarder en priorité »). Aucune n'a été forcée. La chaîne est au vert sur la tête de `develop` (`19efc19`), les six tâches. **Aucune migration dans cette livraison**, et c'est ce qui la distingue de la #252 : `db/migrations/` s'arrête toujours à `0022_cadence_dix_minutes.sql`. Pas de nouvelle variable d'environnement, pas de changement de `compose`, d'`infra/ansible/` ni de rôle Ansible. Le retour arrière est donc un `git revert -m 1` du commit de fusion, suivi du déploiement continu qui repart tout seul sur `main`. Rien à défaire côté base ni côté Azure. `.forgejo/workflows/ci.yml` change — Trivy entre dans la chaîne — mais **sans créer de nouveau contrôle requis** : l'étape vit dans la tâche « Python — qualité, tests et dépendances », déjà couverte par le motif `Intégration / *` de la protection de `main`. Rien à retoucher dans la configuration de la branche avant de fusionner. ## Ce qui change pour la démonstration - **Le tableau de bord a enfin ses trois écrans manquants.** `/administration` (#16) liste les comptes triés par adresse avec leur état et leur date de création, réservé au rôle `admin` — le contrôle reste côté API, la vue ne fait que l'annoncer ; l'API gagne `GET /auth/users`, qui complète les `POST` et `PATCH` déjà en place et n'expose jamais le condensé du mot de passe. `/contact` (#19) prépare un courriel et le remet au client de messagerie du poste, l'API n'ayant aucune route de contact, avec l'adresse de l'exploitant affichée en clair à côté pour le poste sans client configuré. `/confidentialite` (#20) porte la note d'information de l'article 13 du RGPD. Les deux dernières sont lisibles sans session, depuis le pied de la page de connexion et depuis le menu du compte. - **La note RGPD annonce la durée qu'on pratique vraiment.** Elle disait « douze mois glissants » pour les journaux d'authentification quand l'API purge à 90 jours (`AUDIT_RETENTION_DAYS`). Sur une note article 13, c'est une inexactitude substantielle : la page dit désormais quatre-vingt-dix jours, et une ligne « Sessions » distincte rappelle la session absolue de trente jours et la purge à sept jours (`SESSION_RETENTION_DAYS`). Un test verrouille la durée affichée. - **Une barre n'est plus « reconstituée » pour une seule minute imputée** (#267). Les trois requêtes de série posaient `imputee` avec un `bool_or` sur tout le seau : une minute interpolée sur 60 (barre horaire) ou sur 1 440 (barre journalière) hachurait la barre entière. SITE003 (data center) et SITE005 (hôpital), seuls sites au régime « report » de l'ADR 0006, ressortaient hachurés sur **toutes** leurs barres à 100 % de disponibilité. Les requêtes remontent maintenant le nombre de minutes reconstituées et tranchent sur la part (`SEUIL_SEAU_IMPUTE = 0.5`). Décision produit prise dans le même fil : la courbe de la fiche site ne distingue plus visuellement le mesuré du reconstitué, une seule teinte pour la consommation, seule la prévision se détache. La méthode d'une valeur reste lisible au clic dans le panneau de traçabilité, fenêtre 24 h. **Connu et assumé** : sur les fenêtres 7 j et 30 j, qui n'ont pas de traçabilité, la méthode n'apparaît plus nulle part. - **Un document d'entrée par épreuve** (#269, #260). L'énoncé demande un rapport de sécurisation EC04 et des documentations EC03 / EC05 / EC06 ; la matière existait, éparpillée entre `docs/api/`, `docs/data/`, `docs/adr/`, `tests/ci/` et les manuels, mais un correcteur qui cherchait ces livrables par leur nom ne trouvait rien. Quatre documents les rassemblent : `RAPPORT-EC04-SECURISATION.md`, `EC03-INTEGRATION-CONTINUE.md`, `EC05-CHAINE-DE-DONNEES.md`, `EC06-MODELE-ET-PREVISION.md`. Leurs paragraphes « comment le vérifier » ont été rejoués sur le serveur, pas seulement écrits. - **Trivy analyse le dépôt à chaque demande de fusion** (#269). Secrets et vulnérabilités HIGH/CRITICAL sont bloquants ; les constats de configuration sont journalisés et suivis par le #269, le temps de les traiter. La tâche ne peut pas mentir sur son propre état : une panne d'outil — archive indisponible, empreinte inattendue, `curl` absent de l'image — est déclarée `skipped` ou `failed`, jamais `passed`. C'est d'ailleurs ce qui s'est passé en cours de route : l'étape avait été écrite en croyant `curl` présent dans l'image `slim`, elle n'analysait rien ; le correctif est dans le lot. - **L'IAM Azure est déclaré en Terraform, plus seulement en bash** (#237). L'unique droit que ce projet attribue lui-même — « Storage Blob Data Contributor » sur le compte qui porte l'état Terraform — était posé par `bootstrap.sh` et invisible ailleurs. Il vit maintenant dans `infra/terraform/acces-etat.tf`, **adopté par import** et non recréé : le script reste l'amorçage, Terraform devient la référence lisible, et les deux ne peuvent plus diverger sans qu'un `plan -refresh-only` le montre. - **La chaîne ne rougira plus au passage d'une date** (#265). Le test de chargement zone or portait la journée `2026-09-03` écrite en dur ; passé le 10/09, le garde-fou de compression `controler_fenetre` (sept jours) refusait la journée et le job Python rendait 4 au lieu de 0. La date est devenue glissante. ## Si ça touche `infra/terraform/` - [x] `terraform plan -out=tfplan` — fait **avant** la fusion dans `develop`, dans la #264 ; rien n'a touché `infra/terraform/` depuis. - [x] `terraform apply tfplan` — **sans objet**. Cette livraison ne crée aucune ressource Azure : le seul changement d'état a été un `terraform import`, joué et tracé dans la #264. Fusionner vers `main` ne rejoue rien côté Azure, l'`apply` n'étant pas automatisé (ADR 0007). - [ ] Le pair a relu le plan, pas seulement le code <details><summary>Ce qui reste au plan, et pourquoi</summary> ``` azurerm_monitor_action_group.capacite will be created azurerm_monitor_metric_alert.capacite will be created azurerm_storage_management_policy.archive[0] will be created Plan: 3 to add, 0 to change, 0 to destroy. ``` Ces trois lignes n'appartiennent pas à cette livraison : ce sont les ressources du #69, non applicables avec le rôle école (`Microsoft.Insights/actionGroups/write` et `managementPolicies/write` sont refusés). Voir les corrections datées du 10/09 sur les ADR 0007 et 0012. `azurerm_role_assignment.etat_donnees` n'y figure pas : il est importé. </details> ## 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 ## Ce qui suit le code - [x] `docs/runbooks/` mis à jour — `terraform-etat.md` (manœuvre d'import, épinglage du principal, remède `RoleAssignmentExists`, retour arrière `state rm`, piège `MSYS_NO_PATHCONV`), `stockage-secours.md` (§3 corrigé : l'alerte de capacité qu'il décrivait comme active ne l'a jamais été, `403 AuthorizationFailed` sur `Microsoft.Insights/actionGroups/write`), `ci.md` (le motif d'une exception checkov, faux depuis le #69), et le `README.md` des manuels - [ ] **Trivy n'est documenté nulle part** — ni dans `docs/runbooks/ci.md`, ni dans le nouveau `docs/EC03-INTEGRATION-CONTINUE.md`, dont le §2 énumère pourtant « les six verrous ». Voir « Où regarder en priorité » - [x] `docs/adr/` complété — ADR 0007 (`listKeys` **est** accordé) et ADR 0012 (`Microsoft.Insights/*` ne l'est **pas** ; l'alerte du #69 n'a jamais été en service) - [ ] `docs/journal.md` — rien à consigner, aucun incident de production sur la période - [ ] Aucune nouvelle variable d'environnement, `.env.example` est inchangé ## Où regarder en priorité 1. **La #264 est entrée dans `develop` sans revue formelle.** C'est la seule du lot dans ce cas, et c'est celle qui touche Azure. Le changement est pourtant le plus facile à vérifier : il n'ajoute aucune ressource, il en adopte une qui existait déjà. La case « le pair a relu le plan » ci-dessus reste à cocher : c'est le geste attendu sur cette demande-ci. 2. **La perte de la distinction mesuré / reconstitué sur 7 j et 30 j.** Le choix se défend — hachurer en permanence un hôpital faisait lire une avarie qui n'existe pas — mais il retire une information de l'écran sur deux fenêtres sur trois. À valider avant la démonstration, pas après : le jury regarde l'EF-04. 3. **Trivy entre bloquant dans la chaîne, et n'est écrit dans aucun document.** `grep -ril trivy docs/` ne rend rien : ni `runbooks/ci.md`, ni le `EC03-INTEGRATION-CONTINUE.md` livré par la **même** demande de fusion, dont le §2 énumère pourtant « les six verrous, et ce que chacun refuse ». Un septième verrou peut désormais refuser une fusion sans qu'aucun manuel dise ce qu'il contrôle ni quoi faire quand il rougit — et la base de vulnérabilités bouge toute seule, donc il rougira un jour sur une demande qui n'a rien changé. Le code fait déjà le bon geste, il distingue le constat de la panne d'outil ; c'est la ligne du tableau qui manque. Petit ticket à ouvrir, à faire avant le gel plutôt qu'après. 4. **`docs/EC0*.md` sont des livrables de jury, pas de la documentation interne.** Une relecture à voix haute vaut le coup : ce sont les quatre fichiers que le correcteur ouvrira en premier.

gabriel added 33 commits 2026-09-10 17:48:24 +00:00

[237] IAM Azure c33d4d9284

docs: rapport de securisation EC04 ... af2b6470e9

Le gel de vendredi 9h00 exige un rapport de securisation dans le depot. Aucun
document ne portait ce nom : la matiere existait, eparpillee entre api/securite,
runbooks/secrets, le plan de migration et les ENF du dossier collectif. Un jury
qui cherche ce livrable ne le trouvait pas.

CHAQUE MESURE PORTE SA PREUVE, sous la forme d une commande qui la verifie sur le
serveur. Une propriete de securite qu on ne sait pas controler n est pas une
propriete, c est une intention. Les sorties citees sont celles du 10/09.

Le paragraphe 9 nomme TROIS ECARTS OUVERTS plutot que de les taire : le socket
Docker qui atteint les conteneurs de tache et donne root a qui pousse, la forge
en reseau hote qui a deja coute la panne du 3 septembre, et l autorisation qui
ne restreint pas encore les sites. Chacun porte sa portee reelle, son correctif
et la raison pour laquelle il n est pas encore applique.

Un ecart trouve en ecrivant ce rapport et signale au paragraphe 6 : le mot de
passe du role grafana existe dans DEUX fichiers .env rendus depuis le meme
coffre, et ils ont diverge. Celui que Grafana utilise fonctionne, l autre est
perime. Rien ne l a signale parce que le mauvais n est jamais employe.

Merge pull request 'docs : rapport de sécurisation EC04' (#260) from lenaic/rapport-ec04 into develop ... 5634230d12

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

api: liste les comptes pour l'écran d'administration ... 2a14496d7d

Ajoute GET /auth/users (rôle admin) : tous les comptes triés par adresse,
avec is_active et created_at, le condensé du mot de passe exclu. Complète
POST et PATCH /auth/users déjà en place. Doc à jour.

Réf #16

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

dashboard: ajoute la page d'administration des comptes ... 290a3564c6

Écran réservé au rôle admin (le contrôle reste côté API) : créer un compte,
et sur chaque ligne activer/désactiver, changer le rôle, réinitialiser le
mot de passe — via GET/POST/PATCH /auth/users. Les gestes passent par des
boutons nommés, jamais par la sélection d'une liste (RGAA 11.10) ; le
résultat est annoncé en role=status, l'échec en role=alert. L'administrateur
connecté ne peut ni se rétrograder ni se désactiver, ces boutons sont
masqués sur sa ligne. Lien « Administration » dans le menu du compte, visible
des seuls administrateurs.

Closes #16

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

[237] Corrections 0b36a3b75c

Merge branch 'develop' into marvin/16-page-administration dacc31ef74

Merge pull request 'Front + API : page d'administration des comptes (#16)' (#263) from marvin/16-page-administration into develop ... d6f5727b37

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

tests: date glissante pour le chargement zone or, au lieu d'une date figée ... 802a9a7a8d

test_le_chargement_rend_zero_puis_referme_la_connexion chargeait 2026-09-03
en dur. Le garde-fou de compression (controler_fenetre, sept jours) refuse
depuis le 2026-09-10 : le job rend 4 au lieu de 0, et le job Python de la
chaîne est rouge sur develop pour tout le monde. main() n'expose pas
d'horloge, donc le cas prend maintenant « aujourd'hui moins deux jours ».
Le cas jumeau qui attend le code 4 garde sa date volontairement ancienne.

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

dashboard: ajoute la page de contact ... 6b3e0239a5

Formulaire nom / adresse / message qui prépare un courriel et le remet au
client de messagerie du poste (lien mailto), l'API n'ayant pas de route de
contact. L'adresse de l'exploitant est affichée en clair à côté, utilisable
même sans client configuré. Lisible sans session : « Signaler un problème
d'accès » y mène depuis la page de connexion.

Closes #19

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

dashboard: ajoute la page de politique de confidentialité (RGPD) ... 9c23af10fa

La note d'information de l'article 13 du RGPD : responsable, données
collectées (compte, journaux d'authentification, cookies de session),
finalités et base légale, destinataires, durées de conservation, cookies,
droits et réclamation CNIL. Lisible sans session, comme la connexion.

Atteignable depuis le pied de la page de connexion et depuis le menu du
compte. Le texte juridique exact reste à faire valider (ticket #20).

Closes #20

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

Merge pull request 'Front : page de contact (#19)' (#262) from marvin/19-page-contact into develop ... 50cc0d0fb6

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

[237] Retours PR 479f1785b3

api : une barre de conso n'est « reconstituée » qu'à partir de la moitié de ses minutes (#267) ... 764d3223fe

Les trois requêtes de série posaient `imputee` avec un `bool_or` sur tout
le seau : une seule minute interpolée sur 60 (barre horaire) ou sur 1 440
(barre journalière) hachurait la barre entière. SITE005, à 100 % de
disponibilité avec quelques minutes lissées, ressortait « reconstitué »
sur toutes ses barres, à toutes les fenêtres.

Les requêtes remontent désormais le nombre de minutes reconstituées du
seau, et `_seau_impute` tranche sur la part (SEUIL_SEAU_IMPUTE = 0.5).
En deçà, la barre reste « mesuré » ; le détail minute par minute reste
lisible dans l'infobulle et le panneau de traçabilité (EF-04). Le
contrat `imputee: bool` et le front sont inchangés.

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

Merge branch 'develop' into justine/237-iam-azure ... 92fe9b12b0

# Conflicts:
#	docs/runbooks/README.md

front : la courbe de la fiche site ne distingue plus le mesuré du reconstitué ... 787c710ac5

Décision produit dans le fil du #267. Sur un data center ou un hôpital, le
régime « report » de l'ADR 0006 reconstitue en continu une large part des
minutes : hachurer ces barres faisait lire une avarie permanente là où il
n'y en a pas. Toute la consommation est tracée dans une seule teinte ;
seule la prévision se détache.

- barres : plus de motif ni de contour, `imputee` n'influe plus sur le rendu
- légende : « mesuré / reconstitué (EF-04) » devient « consommation »
- infobulle et résumé clavier : ne qualifient plus la valeur de reconstituée

La méthode d'une valeur reste lisible au clic dans le panneau de
traçabilité (fenêtre 24 h). Connu et assumé : sur les fenêtres 7 j / 30 j,
qui n'ont pas de traçabilité, la méthode n'apparaît plus nulle part.

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

Merge branch 'develop' into marvin/test-chargement-date-glissante 61d2ed4789

Merge pull request 'tests : date glissante pour le chargement zone or (#265)' (#266) from marvin/test-chargement-date-glissante into develop ... 31511ebf2c

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

Merge remote-tracking branch 'origin/develop' into marvin/20-page-confidentialite ... 476f199e7a

# Conflicts:
#	services/dashboard/src/components/MenuProfil.vue
#	services/dashboard/src/router/index.js
#	services/dashboard/src/views/ConnexionView.vue
#	services/dashboard/tests/unit/ConnexionView.test.js
#	services/dashboard/tests/unit/MenuProfil.test.js

dashboard : la note RGPD annonce la durée de conservation réellement pratiquée ... d5ef14ea6c

Le texte disait « douze mois glissants » pour les journaux d'authentification,
alors que l'API purge à 90 jours (AUDIT_RETENTION_DAYS, docs/api/securite.md
et docs/api/configuration.md). Sur une note d'information article 13, annoncer
une durée qu'on ne pratique pas est une inexactitude substantielle : la page
dit désormais quatre-vingt-dix jours, et une ligne « Sessions » distincte
rappelle la session absolue de trente jours et la purge des sessions expirées
à sept jours (SESSION_RETENTION_DAYS).

Au passage :
- retire la référence à l'ENF-15, qui porte sur les comptes nominatifs et
  l'empreinte de clé côté infra, pas sur le journal d'auth applicatif ;
- l'attribut Secure des cookies est présenté comme conditionné à HTTPS
  (retiré si COOKIE_SECURE=false) ;
- le commentaire au-dessus de MISE_A_JOUR décrit enfin la constante ;
- le lien CNIL en nouvelle fenêtre l'annonce ;
- un test verrouille la durée affichée.

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

Merge branch 'develop' into justine/237-iam-azure 87eb711740

Merge pull request '[237] IAM Azure' (#264) from justine/237-iam-azure into develop ... 1c270c6cb6

Reviewed-on: https://10.105.200.41/g2/enervision/pulls/264

docs: un document d'entrée par épreuve, et Trivy dans la chaîne (#269) ... d021460d16

DEUX SUJETS, UNE SEULE DEMANDE, PARCE QU'ILS PARTENT ENSEMBLE AU GEL.

## Le nom que le correcteur cherche

L'énoncé demande « rapport de sécurisation EC04, documentations
EC03/EC05/EC06 ». Le rapport EC04 porte déjà ce nom. Les trois autres
n'existaient pas : la matière était là, répartie entre docs/data,
docs/adr, tests/ci et les manuels, et il fallait la deviner.

Trois documents d'entrée, sur le même modèle que le rapport EC04. Chacun
dit ce qui tourne, où c'est dans le dépôt, comment le vérifier sans nous
croire sur parole, et ce qui n'est pas livré. Aucun fichier n'est
renommé, aucun lien existant ne casse.

Le README porte la table « Documentation par épreuve », cinq lignes, qui
donne le document d'entrée et ses renvois.

## Trivy

pip-audit couvre les dépendances Python déclarées. Il ne voit ni un
secret laissé dans un fichier, ni une image de base vulnérable, ni une
ressource Terraform mal configurée.

Deux passes, et leur sévérité diffère à dessein :

- « vuln,secret » est BLOQUANTE. Elle est verte aujourd'hui, donc elle ne
  bloquera que sur du neuf. Éprouvée avant d'être écrite : zéro constat.
- « misconfig » est JOURNALISÉE. Elle rend deux constats réels, portés
  par le #269 avec ce qu'ils valent et la date où la passe devient
  bloquante. Les rendre bloquants ce soir arrêterait la chaîne sur un
  état connu, ce qui n'apprend rien à personne.

L'archive est épinglée par version ET par empreinte, vérifiée contre le
fichier de sommes publié avec la version. Comparer un numéro de version
ne prouve rien, c'est l'empreinte qui lie l'octet au projet — la leçon
du #88d8330, où l'épinglage avait été vérifié contre le mauvais miroir.

tests/ci/fixtures/ est exclu, et cette exclusion est obligatoire : ces
fichiers sont volontairement fautifs et servent à prouver que le garde
Terraform rougit. Les scanner ferait échouer la chaîne sur ses propres
cas d'essai.

## Vérifié avant de pousser

- trivy 0.74.0 joué sur le dépôt : 0 constat vuln+secret, 2 en misconfig
- test-hygiene-workflows.sh : les 37 noms de contrôle correspondent
- test-hygiene-bancs.sh : aucun « … | grep -q » sous pipefail
- test-liens-markdown.sh : 355 liens relatifs, aucun mort

ci: Trivy ne bloque que sur un constat, jamais sur une panne d'outil ... c786d8b790

LE DÉFAUT. La première version traitait tout code de retour non nul de
Trivy comme « un défaut a été trouvé ». Or Trivy sort aussi en erreur
quand il ne peut pas télécharger sa base de vulnérabilités : réseau
coupé, quota, miroir indisponible. La chaîne aurait rougi sans qu'aucun
défaut existe, et un rouge qui n'est pas une information finit par être
ignoré — c'est exactement le reproche que test-hygiene-bancs.sh fait aux
autres.

LA FORME RETENUE. « --exit-code 0 » toujours, sortie JSON, et c'est le
DÉCOMPTE lu dans le rapport qui décide. Pas de rapport exploitable, pas
de verdict : l'étape se déclare sautée et laisse passer.

.forgejo/scripts/trivy-compter.py rend le nombre de constats hauts et
critiques, ou « ERREUR » si le fichier n'existe pas ou n'est pas du JSON.
La distinction est le cœur du correctif : ERREUR n'est pas zéro.

Le décompte est un script et non un heredoc dans le workflow, parce
qu'un heredoc indenté dans un bloc YAML rend à Python des lignes à
espaces de tête et meurt sur une IndentationError.

ÉPROUVÉ, PAS SUPPOSÉ. L'étape a été extraite du YAML et rejouée sous
dash, le shell du runner :

  - dépôt réel, empreinte juste .... code 0, vuln+secret 0 constat,
                                     misconfig 2 constats en warned
  - empreinte fausse .............. code 1, « on n'exécute pas un
                                     binaire non vérifié »
  - rapport illisible ou absent .... « ERREUR », étape sautée

Bancs rejoués : test-hygiene-workflows.sh, test-hygiene-bancs.sh.

Merge branch 'develop' into marvin/267-seuil-seau-impute 7c94bcb410

Merge branch 'develop' into marvin/20-page-confidentialite 1066cd1f3e

ci : Trivy n'analysait rien, faute de curl dans l'image du job (#269) ... 89f03ffa1e

L'étape a été écrite en croyant curl présent dans le conteneur du job Python.
Il ne l'est pas : python:3.12-slim le purge avec ses dépendances de
construction, ce que les jobs « terraform » et « meta » savaient déjà
puisqu'ils l'installent tous les deux avec le commentaire « absents de l'image
slim ». Vérifié sur l'empreinte exacte que le job épingle : curl est absent,
tar et sha256sum sont là.

L'effet n'était pas un rouge, c'était pire. « if ! curl » attrapait le code 127
comme un échec de téléchargement, l'étape rapportait « Trivy (secrets,
vulnérabilités) | skipped | archive non téléchargeable » et sortait à zéro. La
chaîne restait verte, la synthèse portait une ligne rassurante, et le dépôt
n'était jamais analysé — le vert non informatif que l'en-tête de cette même
étape dit vouloir éviter.

Trois changements, et le troisième est celui qui compte :

- curl rejoint l'étape d'installation du job, comme dans les deux autres.
- Un garde « command -v curl » précède le téléchargement et ÉCHOUE. Un outil
  absent n'est pas une panne de réseau : c'est un défaut de la chaîne, et le
  repli « sauté » ne couvre plus que ce pour quoi il est écrit. Sans ce garde,
  la même faute repasserait en silence à la prochaine image.
- Les exclusions voyagent en paramètres positionnels. « $exclus » nu est le
  SC2086 que la tâche « meta » refuse — c'est ce qui la faisait rougir sur
  cette branche — et le quoter en aurait fait un seul argument.

Le commentaire annonçait aussi que Trivy voit « une image de base
vulnérable ». Non : « trivy fs » lit l'arbre du dépôt, les CVE d'une image
construite demandent « trivy image ». Laisser la phrase ferait porter au
rapport EC04 une couverture qu'il n'a pas.

Enfin, trivy-compter.py passe ruff format, qui le refusait et faisait rougir le
job Python.

docs : les §5 « comment le vérifier » se rejouent réellement (#269) ... c4eba2b02a

Ces trois sections existent pour qu'on ne nous croie pas sur parole, et c'est
la première chose qu'un correcteur tape. Rejouées ici, elles rendaient une
erreur ou du vide.

EC06. « valeur_kw » n'existe pas dans public.prevision : la colonne est
« valeur_prevue_kw » (migration 0011). La requête montre en plus
« modele_version », qui dit qui a produit la ligne. Les deux commandes mlflow
étaient des inventions — « runs list » prend « --experiment-id », et l'accès
par alias est une API Python, pas une sous-commande. Un bloc MlflowClient les
remplace, et il fait d'une pierre deux coups : il imprime les quatre métriques
que la surveillance de dérive relit, donc il répond aussi à « la dérive
mesure-t-elle quelque chose aujourd'hui ».

Car elle ne mesure que si la version promue les porte. La référence figée est
écrite par l'entraînement, pas par la promotion : « reference_promue.lire »
rend None pour toute version antérieure au #117, et la passe publie alors une
tentative sans mesure. Le §4 le dit et le §6 le porte comme ce qui n'est pas
livré — le code est en place et la passe l'appelle, ce qui manque est une
promotion postérieure au ticket.

EC05. « mesure_horaire » n'a pas de colonne « horodatage » : l'agrégat continu
nomme son seau « heure » (migration 0016). Et « silver.mesure_minute » n'existe
nulle part : la zone argent est en Parquet dans MinIO, pas en base. La requête
porte donc sur public.qualite_jour, qui est exactement la preuve annoncée au §3
— relèves attendues, manquantes, et la répartition par méthode d'imputation —
et le script echantillon-imputation.py montre les quatre méthodes sans même
toucher au serveur. Le §1 dit maintenant que sa colonne « Code » nomme ce qui
écrit la zone, et que seule la zone or est interrogeable en SQL.

EC03. L'API des tâches ne rend pas de champ « conclusion » ; le verdict est
dans « status ». Le jq imprimait null sur chaque ligne. Le chiffre du §4 est
relevé de nouveau et daté, parce qu'il bouge à chaque exécution : 2 846 tâches,
94,3 % vertes au 10/09 à 15 h 00.

docs : les commandes des §5, rejouées sur le serveur cette fois (#269) ... 763bf7e293

Le commit précédent corrigeait les §5 d'après le schéma des migrations. Les
avoir joués sur la machine change trois choses de plus, et la troisième change
un verdict.

LA BASE NE S'APPELLE PAS « enervision ». Elle n'existe pas sous ce nom : le
serveur porte « enervision_prod » et « enervision_preprod ». Toutes les lignes
psql d'EC05 et d'EC06 échouaient donc avant même de lire une table, sur un
« FATAL : la base de données n'existe pas ». Elles prennent la forme des
manuels — conteneur, port 5433, docs/runbooks/etl.md.

MESURER LA FRAÎCHEUR SUR L'AGRÉGAT HORAIRE FAIT DOUTER DE LA CADENCE POUR
RIEN. La requête rendait une à deux heures d'âge, ce qui est normal : la
politique laisse l'heure en cours dehors (`end_offset => 1 hour`), sans quoi la
moyenne bougerait à chaque passage. La fraîcheur annoncée au §2 est celle de la
série à la minute, que lit le pavé « état des sites » : 13 min 20 s au relevé
du 10/09 à 17 h 02, dans la fenêtre de 6 à 15 min. Les deux requêtes sont là
maintenant, avec ce que chacune mesure.

ET LE §6 D'EC06 PASSE D'UNE CONDITION À UN CONSTAT. La version qui porte
l'alias production est la 6, entraînée le 08/09 et remise en place le 09/09 par
le retour arrière de la recette #47. Son exécution porte « modele_mae » mais ni
« entrees_moyenne_kw », ni « entrees_ecart_type_kw », ni « entrees_n » : la
référence figée que la dérive relit n'y est pas. « reference_promue.lire » rend
None, et la passe horaire publie une tentative sans mesure. Ce qui manque n'est
pas du code — il est en place et la passe l'appelle — mais un réentraînement
postérieur au #117, puis sa promotion.

Les deux commandes mlflow deviennent des appels à l'API REST du serveur de
suivi : rien à installer, et ce sont exactement celles qui ont produit le
constat ci-dessus.

Enfin, un commentaire du §5 d'EC03 annonçait « le taux de vert » au-dessus
d'une commande qui ne rend que le total. Il dit maintenant ce qu'elle fait, et
comment le taux se calcule.

Merge branch 'develop' into lenaic/269-docs-epreuves-et-trivy 082e90ff58

Merge pull request 'docs : un document d'entrée par épreuve, et Trivy dans la chaîne (#269)' (#270) from lenaic/269-docs-epreuves-et-trivy into develop ... 9707de8d3a

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

Merge pull request 'api+front : le drapeau « reconstitué » des courbes suit la part imputée du seau (#267)' (#268) from marvin/267-seuil-seau-impute into develop ... bd8f91af00

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

Merge pull request 'Front : page de politique de confidentialite (RGPD) (#20)' (#261) from marvin/20-page-confidentialite into develop ... 19efc196e7

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

gabriel requested review from marvin 2026-09-10 18:49:55 +00:00

marvin approved these changes 2026-09-10 18:50:00 +00:00

marvin merged commit 0e9a15a0a1 into main 2026-09-10 18:50:33 +00:00

marvin referenced this pull request from a commit 2026-09-10 18:50:34 +00:00

Merge pull request 'Mise en production : les trois écrans manquants, les documents d'épreuve, Trivy et l'IAM en Terraform' (#271) from develop into main

gabriel referenced this pull request 2026-09-10 20:03:18 +00:00

api : le seuil du seau reconstitué se calcule sur le type que la base rend (#267) #272

gabriel referenced this pull request 2026-09-10 20:23:50 +00:00

Mise en production : le tableau de bord répond de nouveau (#267) #273

Sign in to join this conversation.

Reviewers

No reviewers

marvin

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

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

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!271

No description provided.