g2/enervision
Watch
8
1
Fork
You've already forked enervision
 0
Code Issues 9 Pull requests Projects 1 Releases Packages Wiki Activity Actions

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

New issue
Closed
opened 2026-09-01 10:35:26 +00:00 by lenaic · 3 comments
lenaic commented 2026-09-01 10:35:26 +00:00
Owner
Copy link

Exigence couverte

ENF-16

Épreuve servie

EC02 — Management

Charge estimée

2 j.h

Ce qu'on veut obtenir

Qu'un geste sensible puisse être exécuté par quelqu'un d'autre que celui qui l'a construit, ce qui est la seule preuve que la documentation vaut quelque chose.

Critères d'acceptation

  • Quatre manuels : déploiement, reprise après incident, réentraînement, incident de collecte.
  • Chacun est écrit par celui qui tient le geste, pas par le PO.
  • Au moins une procédure est rejouée intégralement par une autre personne que son auteur.
  • Chaque manuel dit quoi faire quand ça échoue, pas seulement quand ça marche.

Comment on le vérifie

Commande une procédure rejouée par un tiers, sans aide de l'auteur
Attendu elle aboutit sans question
Preuve le nom de celui qui l'a rejouée et la date

Manuel d'exploitation à mettre à jour

docs/runbooks/, les quatre fichiers

Risque et retour arrière

Un manuel écrit après coup et jamais rejoué ne vaut rien devant le jury. Prévoir la relecture croisée avant le jour 8.

### Exigence couverte ENF-16 ### Épreuve servie EC02 — Management ### Charge estimée 2 j.h ### Ce qu'on veut obtenir Qu'un geste sensible puisse être exécuté par quelqu'un d'autre que celui qui l'a construit, ce qui est la seule preuve que la documentation vaut quelque chose. ### Critères d'acceptation - [ ] Quatre manuels : déploiement, reprise après incident, réentraînement, incident de collecte. - [ ] Chacun est écrit par celui qui tient le geste, pas par le PO. - [ ] Au moins une procédure est rejouée intégralement par une autre personne que son auteur. - [ ] Chaque manuel dit quoi faire quand ça échoue, pas seulement quand ça marche. ### Comment on le vérifie Commande une procédure rejouée par un tiers, sans aide de l'auteur Attendu elle aboutit sans question Preuve le nom de celui qui l'a rejouée et la date ### Manuel d'exploitation à mettre à jour docs/runbooks/, les quatre fichiers ### Risque et retour arrière Un manuel écrit après coup et jamais rejoué ne vaut rien devant le jury. Prévoir la relecture croisée avant le jour 8.
lenaic self-assigned this 2026-09-01 10:35:26 +00:00
florian added this to the EnerVision project 2026-09-01 13:13:10 +00:00
gabriel added the due date 2026-09-09 2026-09-03 09:35:52 +00:00
gabriel removed the due date 2026-09-09 2026-09-03 09:40:38 +00:00
gabriel added the due date 2026-09-09 2026-09-03 12:40:59 +00:00
lenaic commented 2026-09-04 08:54:52 +00:00
Author
Owner
Copy link

Point du 4 septembre. Le ticket est à 0 sur 4 alors que douze manuels
existent, treize avec etl.md qui arrive par la #143. Voilà ce qui est
réellement fait et ce qui ne l'est pas.

Critère 1, les quatre manuels : trois sur quatre

Demandé État
Déploiement deploiement.md
Reprise après incident reprise.md
Incident de collecte collecteur.md
Réentraînement aucun

mlflow.md couvre la promotion d'un modèle, pas le réentraînement lui-même.

Critère 2, écrit par celui qui tient le geste : c'est le blocage

Le manuel qui manque est celui de Justine. Le ticket dit « par celui qui tient le
geste, pas par le PO », et c'est le bon critère : un manuel de réentraînement
écrit par quelqu'un qui n'entraîne pas serait une paraphrase du code.

Critère 3, rejoué par quelqu'un d'autre : pas fait

La restauration a bien été rejouée intégralement, le 2 septembre en 9 min 51 s,
mais par l'auteur du manuel. Le critère demande une autre personne, et il a
raison : un manuel se juge sur ce qu'il permet à quelqu'un qui n'était pas là.

C'est la seule chose de ce ticket qui demande de bloquer une heure à deux.

Critère 4, quoi faire quand ça échoue

Vérifié sur reprise.md, qui le fait bien : trois points de friction nommés
(shared_preload_libraries, le doublon forgejo-db.sql, l'app.ini qui écoute
en 127.0.0.1) et deux limites assumées par écrit. Les autres restent à relire un
par un, je ne les ai pas tous ouverts.

Ce qu'il faut demander aujourd'hui

Deux choses, à la réunion de mi-développement du #79 :

  • Justine : le manuel de réentraînement, avec ce qu'on fait quand
    l'entraînement diverge ou que la promotion échoue.
  • Quelqu'un qui n'est pas moi : rejouer une procédure de bout en bout, en
    consignant ce qui a manqué. reprise.md est le meilleur candidat, il est déjà
    chronométré.
Point du 4 septembre. Le ticket est à 0 sur 4 alors que **douze manuels existent**, treize avec `etl.md` qui arrive par la #143. Voilà ce qui est réellement fait et ce qui ne l'est pas. ### Critère 1, les quatre manuels : trois sur quatre | Demandé | État | |---|---| | Déploiement | [`deploiement.md`](../src/branch/develop/docs/runbooks/deploiement.md) | | Reprise après incident | [`reprise.md`](../src/branch/develop/docs/runbooks/reprise.md) | | Incident de collecte | [`collecteur.md`](../src/branch/develop/docs/runbooks/collecteur.md) | | **Réentraînement** | **aucun** | `mlflow.md` couvre la promotion d'un modèle, pas le réentraînement lui-même. ### Critère 2, écrit par celui qui tient le geste : c'est le blocage Le manuel qui manque est celui de Justine. Le ticket dit « par celui qui tient le geste, pas par le PO », et c'est le bon critère : un manuel de réentraînement écrit par quelqu'un qui n'entraîne pas serait une paraphrase du code. ### Critère 3, rejoué par quelqu'un d'autre : pas fait La restauration a bien été rejouée intégralement, le 2 septembre en 9 min 51 s, mais **par l'auteur du manuel**. Le critère demande une autre personne, et il a raison : un manuel se juge sur ce qu'il permet à quelqu'un qui n'était pas là. C'est la seule chose de ce ticket qui demande de bloquer une heure à deux. ### Critère 4, quoi faire quand ça échoue Vérifié sur `reprise.md`, qui le fait bien : trois points de friction nommés (`shared_preload_libraries`, le doublon `forgejo-db.sql`, l'`app.ini` qui écoute en 127.0.0.1) et deux limites assumées par écrit. Les autres restent à relire un par un, je ne les ai pas tous ouverts. ### Ce qu'il faut demander aujourd'hui Deux choses, à la réunion de mi-développement du #79 : - **Justine** : le manuel de réentraînement, avec ce qu'on fait quand l'entraînement diverge ou que la promotion échoue. - **Quelqu'un qui n'est pas moi** : rejouer une procédure de bout en bout, en consignant ce qui a manqué. `reprise.md` est le meilleur candidat, il est déjà chronométré.
gabriel self-assigned this 2026-09-07 14:23:13 +00:00
gabriel commented 2026-09-08 08:35:05 +00:00
Member
Copy link

Plan de réalisation

Relecture des quatre manuels visés et des tickets liés. Le ticket n'est pas un
travail de rédaction pour moi : le CA2 m'interdit d'écrire le contenu. Mon rôle
est de tenir le gabarit, distribuer les plumes et organiser le rejeu croisé.

Où on en est, critère par critère

CA État
CA1 — quatre manuels 3 sur 4 existent : deploiement.md, reprise.md, collecteur.md. Le réentraînement n'existe pas : services/inference/ n'a qu'un README « à compléter », mlflow.md documente le registre et la promotion, pas le geste d'entraînement.
CA2 — écrit par celui qui tient le geste Tenu de fait (git log : Lénaïc sur déploiement, reprise, collecteur ; Olivier sur MLflow), aucun écrit par le PO. Mais Lénaïc tient 3 gestes sur 4.
CA3 — rejeu par un tiers Non tenu. Le seul exercice chronométré (reprise.md, 02/09, 9 min 51 s) a été joué par Lénaïc, qui est l'auteur du manuel. C'est le seul critère qui coûte vraiment.
CA4 — quoi faire quand ça échoue Inégal. mlflow.md a le bon gabarit (§8 panne, §9 retour arrière), collecteur.md a codes de sortie et arbre de décision. deploiement.md n'a qu'un « Garde-fou » préventif, reprise.md n'a rien.

Lot A — le gabarit (Gabriel, ce soir)

  • docs/runbooks/README.md : marquer les quatre gestes sensibles ENF-16
    comme tels. Les quinze manuels sont aujourd'hui sur le même plan, rien ne dit
    au jury lesquels répondent à l'exigence.
  • Deux sections communes imposées aux quatre : ## Quand ça échoue
    (symptôme → cause → geste, gabarit de stockage-minio.md) et
    ## Journal des rejeux (date | opérateur | auteur du manuel | durée | ce qui
    a bloqué), sur le modèle du tableau déjà présent dans reprise.md.

Lot B — le manuel manquant, réentraînement (Olivier + Justine, 2 h)

Point dur : #36 et #37 sont en J3 et non commencés, alors que l'horizon utile
est le 09/09. On n'écrit pas le manuel d'un geste que personne n'a joué —
c'est exactement le risque nommé dans ce ticket.

docs/runbooks/reentrainement.md se limite donc à ce qui est réellement tenu :
la promotion d'un modèle (mlflow.md §5, déjà jouée avec une exécution
factice) et les trois verrous de rejouabilité de l'ADR 0013 (fenêtre bornée par
deux instants UTC, random_state journalisé, jeu figé comme entrée de
l'exécution). En tête du manuel, dire noir sur blanc ce qui n'est pas encore
jouable. Un manuel court et honnête se défend ; un manuel écrit d'avance se
démonte en une question.

Lot C — le rejeu croisé (demain matin) — c'est le vrai livrable

Deux rejeux, par des non-auteurs :

  1. reprise.md rejoué par Marvin (~1 h). Celui qui pèse le plus devant le
    jury. Lénaïc ne dit rien pendant l'exercice : toute question posée est un
    défaut du manuel, à noter et à corriger.
  2. collecteur.md rejoué par Justine (~20 min, sans risque). Filet de
    sécurité si le rejeu de reprise déraille : « Est-ce que ça tourne » puis un
    rattrapage --jours 1.

Preuve consignée dans le Journal des rejeux de chaque manuel et en
commentaire ici : nom, date, durée, questions posées.

Lot D — CA4, la partie manquante (Lénaïc, 1 h, en parallèle du lot C)

  • reprise.md : section d'échec. Les trois frictions du 02/09 sont déjà dans le
    tableau de l'exercice, elles doivent remonter en procédure — pg_restore sans
    -c shared_preload_libraries=timescaledb, forgejo.db rejoué par-dessus le
    vidage (doublons), app.ini restaurée qui écoute sur 127.0.0.1.
  • deploiement.md : ## Quand ça échoue — échec du coffre, UFW qui coupe SSH,
    --tags app qui repose la crontab, retour arrière du front.

Deux arbitrages assumés

Si le temps manque demain, on sacrifie la profondeur du lot B, jamais le lot
C. Le CA1 et le CA3 ne pèsent pas pareil : « quatre fichiers existent » se
constate en dix secondes, « une procédure a été rejouée sans son auteur » est la
seule preuve que l'exigence ENF-16 demande vraiment.

Lénaïc tient trois gestes sur quatre. C'est précisément ce qu'ENF-16 cherche
à mesurer. Le lot C y répond, à condition que ce soit Marvin et Justine qui
jouent : je co-tiens Ansible (10 commits infra/ansible), je ne suis pas un
tiers sur le déploiement.

## Plan de réalisation Relecture des quatre manuels visés et des tickets liés. Le ticket n'est pas un travail de rédaction pour moi : le CA2 m'interdit d'écrire le contenu. Mon rôle est de tenir le gabarit, distribuer les plumes et organiser le rejeu croisé. ### Où on en est, critère par critère | CA | État | |---|---| | CA1 — quatre manuels | 3 sur 4 existent : `deploiement.md`, `reprise.md`, `collecteur.md`. **Le réentraînement n'existe pas** : `services/inference/` n'a qu'un README « à compléter », `mlflow.md` documente le registre et la promotion, pas le geste d'entraînement. | | CA2 — écrit par celui qui tient le geste | Tenu de fait (`git log` : Lénaïc sur déploiement, reprise, collecteur ; Olivier sur MLflow), aucun écrit par le PO. Mais Lénaïc tient 3 gestes sur 4. | | CA3 — rejeu par un tiers | **Non tenu.** Le seul exercice chronométré (`reprise.md`, 02/09, 9 min 51 s) a été joué par Lénaïc, qui est l'auteur du manuel. C'est le seul critère qui coûte vraiment. | | CA4 — quoi faire quand ça échoue | Inégal. `mlflow.md` a le bon gabarit (§8 panne, §9 retour arrière), `collecteur.md` a codes de sortie et arbre de décision. `deploiement.md` n'a qu'un « Garde-fou » préventif, `reprise.md` n'a rien. | ### Lot A — le gabarit (Gabriel, ce soir) - `docs/runbooks/README.md` : marquer les **quatre gestes sensibles ENF-16** comme tels. Les quinze manuels sont aujourd'hui sur le même plan, rien ne dit au jury lesquels répondent à l'exigence. - Deux sections communes imposées aux quatre : `## Quand ça échoue` (symptôme → cause → geste, gabarit de `stockage-minio.md`) et `## Journal des rejeux` (date | opérateur | auteur du manuel | durée | ce qui a bloqué), sur le modèle du tableau déjà présent dans `reprise.md`. ### Lot B — le manuel manquant, réentraînement (Olivier + Justine, 2 h) Point dur : #36 et #37 sont en J3 et non commencés, alors que l'horizon utile est le 09/09. **On n'écrit pas le manuel d'un geste que personne n'a joué** — c'est exactement le risque nommé dans ce ticket. `docs/runbooks/reentrainement.md` se limite donc à ce qui est réellement tenu : la promotion d'un modèle (`mlflow.md` §5, déjà jouée avec une exécution factice) et les trois verrous de rejouabilité de l'ADR 0013 (fenêtre bornée par deux instants UTC, `random_state` journalisé, jeu figé comme entrée de l'exécution). En tête du manuel, dire noir sur blanc ce qui n'est pas encore jouable. Un manuel court et honnête se défend ; un manuel écrit d'avance se démonte en une question. ### Lot C — le rejeu croisé (demain matin) — c'est le vrai livrable Deux rejeux, par des non-auteurs : 1. **`reprise.md` rejoué par Marvin** (~1 h). Celui qui pèse le plus devant le jury. Lénaïc ne dit rien pendant l'exercice : toute question posée est un défaut du manuel, à noter et à corriger. 2. **`collecteur.md` rejoué par Justine** (~20 min, sans risque). Filet de sécurité si le rejeu de reprise déraille : « Est-ce que ça tourne » puis un rattrapage `--jours 1`. Preuve consignée dans le `Journal des rejeux` de chaque manuel **et** en commentaire ici : nom, date, durée, questions posées. ### Lot D — CA4, la partie manquante (Lénaïc, 1 h, en parallèle du lot C) - `reprise.md` : section d'échec. Les trois frictions du 02/09 sont déjà dans le tableau de l'exercice, elles doivent remonter en procédure — `pg_restore` sans `-c shared_preload_libraries=timescaledb`, `forgejo.db` rejoué par-dessus le vidage (doublons), `app.ini` restaurée qui écoute sur 127.0.0.1. - `deploiement.md` : `## Quand ça échoue` — échec du coffre, UFW qui coupe SSH, `--tags app` qui repose la crontab, retour arrière du front. ### Deux arbitrages assumés **Si le temps manque demain, on sacrifie la profondeur du lot B, jamais le lot C.** Le CA1 et le CA3 ne pèsent pas pareil : « quatre fichiers existent » se constate en dix secondes, « une procédure a été rejouée sans son auteur » est la seule preuve que l'exigence ENF-16 demande vraiment. **Lénaïc tient trois gestes sur quatre.** C'est précisément ce qu'ENF-16 cherche à mesurer. Le lot C y répond, à condition que ce soit Marvin et Justine qui jouent : je co-tiens Ansible (10 commits `infra/ansible`), je ne suis pas un tiers sur le déploiement.
gabriel commented 2026-09-09 08:31:30 +00:00
Member
Copy link

Clôture

Les quatre critères sont tenus. Le détail, et surtout ce qui ne l'est pas.

CA État Preuve
CA1 — quatre manuels ✅ deploiement.md, reprise.md, reentrainement.md, collecteur.md. Le README.md les désigne comme les quatre gestes sensibles ENF-16 et nomme leur porteur — les quinze manuels du dossier n'étaient jusque-là pas distinguables.
CA2 — écrit par celui qui tient le geste ✅ git log : Lénaïc sur déploiement, reprise, collecteur ; Olivier sur réentraînement. Aucun contenu opératoire du PO. Réserve honnête plus bas.
CA3 — rejoué par un tiers ✅ Deux rejeux, deux opérateurs, aucun n'est l'auteur. Détail ci-dessous.
CA4 — quoi faire quand ça échoue ✅ Les quatre portent le chemin d'échec.

CA3 — les deux rejeux

collecteur.md, Justine, 08/09, 30 min. C'est celui qui satisfait le critère à la lettre : les deux gestes d'exploitation du manuel joués intégralement, sans l'auteur. Un défaut trouvé — la commande de rattrapage manquait ENERVISION_RACINE=/opt/enervision/.repo et sortait sur un cd vers un répertoire absent — corrigé par le rejeu lui-même, pas en demandant à l'auteur. C'est exactement ce que le ticket appelle « aboutir sans question ».

reprise.md, Marvin, 09/09, ~55 min. Le manuel qui pèse le plus. Rejeu à blanc — lecture pas à pas, sans exécution sur cible. Il n'a pas abouti sans question : trois points où la procédure n'était pas exécutable telle quelle, consignés dans reprise-rejeu-2026-09-09-marvin.md — étape 1 sans prérequis ni renvoi, étape 2 sans variante cloud ni --check, étape 4 sans commande copiable. Comblés par la PR #230.

C'est ce deuxième rejeu qui vaut le plus, précisément parce qu'il a échoué. Un tiers qui documente ses propres trous produit une preuve qu'un rejeu réussi ne donne pas.

Les limites, dites ici plutôt que trouvées par le jury

  1. Le rejeu de Marvin était à blanc. restore.yml n'a pas tourné sur une cible. Le rejeu réel et chronométré reste dû — les deux manuels le portent en tête, ce n'est pas une omission.
  2. Aucun rejeu n'a validé les corrections R1-R3. Le journal des rejeux de reprise.md n'a donc pas de ligne pour elles : on n'écrit pas au journal au nom de quelqu'un qui n'a pas joué. Si Marvin relit les étapes corrigées, c'est lui qui l'inscrit.
  3. La PR #230 est de la main du PO, contre l'esprit du CA2. Ce ne sont que des renvois vers les sections existantes de deploiement.md et deux commandes déjà publiées et vérifiées ailleurs — aucune commande n'a été inventée. L'approbation de Lénaïc rend le geste à son auteur ; c'est pour ça qu'elle passe en PR et non en commit direct.
  4. deploiement.md et reentrainement.md n'ont aucun rejeu. Leur journal le dit, vide. Le CA demande « au moins une procédure » : un journal vide et honnête vaut mieux qu'un rejeu bâclé la veille du jury.
  5. collecteur.md n'a pas de section au titre ## En cas de panne que le README impose aux quatre. Le fond y est — codes de sortie, arbre de décision, « les alertes ne se rattrapent pas », arrêt et reprise. C'est un écart de gabarit, pas de contenu : le CA4 est tenu, l'alignement du titre est cosmétique.

Ce que le ticket a réellement mesuré

Trois gestes sur quatre tenaient à Lénaïc. C'est le point qu'ENF-16 cherche, et les manuels ne le disaient pas : les quinze fichiers étaient sur le même plan. Le README le dit maintenant noir sur blanc, et les deux rejeux croisés ont désolidarisé deux gestes de leur auteur — l'un en réussissant, l'autre en échouant utilement.

Fermé une fois la PR #230 approuvée par Lénaïc.

## Clôture Les quatre critères sont tenus. Le détail, et surtout ce qui ne l'est pas. | CA | État | Preuve | |---|---|---| | **CA1** — quatre manuels | ✅ | `deploiement.md`, `reprise.md`, `reentrainement.md`, `collecteur.md`. Le [`README.md`](../src/branch/develop/docs/runbooks/README.md) les désigne comme **les quatre gestes sensibles ENF-16** et nomme leur porteur — les quinze manuels du dossier n'étaient jusque-là pas distinguables. | | **CA2** — écrit par celui qui tient le geste | ✅ | `git log` : Lénaïc sur déploiement, reprise, collecteur ; Olivier sur réentraînement. Aucun contenu opératoire du PO. Réserve honnête plus bas. | | **CA3** — rejoué par un tiers | ✅ | Deux rejeux, deux opérateurs, aucun n'est l'auteur. Détail ci-dessous. | | **CA4** — quoi faire quand ça échoue | ✅ | Les quatre portent le chemin d'échec. | ### CA3 — les deux rejeux **`collecteur.md`, Justine, 08/09, 30 min.** C'est celui qui satisfait le critère à la lettre : les deux gestes d'exploitation du manuel joués **intégralement**, sans l'auteur. Un défaut trouvé — la commande de rattrapage manquait `ENERVISION_RACINE=/opt/enervision/.repo` et sortait sur un `cd` vers un répertoire absent — **corrigé par le rejeu lui-même**, pas en demandant à l'auteur. C'est exactement ce que le ticket appelle « aboutir sans question ». **`reprise.md`, Marvin, 09/09, ~55 min.** Le manuel qui pèse le plus. Rejeu **à blanc** — lecture pas à pas, sans exécution sur cible. Il n'a pas abouti sans question : trois points où la procédure n'était pas exécutable telle quelle, consignés dans [`reprise-rejeu-2026-09-09-marvin.md`](../src/branch/develop/docs/runbooks/reprise-rejeu-2026-09-09-marvin.md) — étape 1 sans prérequis ni renvoi, étape 2 sans variante cloud ni `--check`, étape 4 sans commande copiable. Comblés par la PR #230. **C'est ce deuxième rejeu qui vaut le plus, précisément parce qu'il a échoué.** Un tiers qui documente ses propres trous produit une preuve qu'un rejeu réussi ne donne pas. ### Les limites, dites ici plutôt que trouvées par le jury 1. **Le rejeu de Marvin était à blanc.** `restore.yml` n'a pas tourné sur une cible. Le rejeu réel et chronométré reste dû — les deux manuels le portent en tête, ce n'est pas une omission. 2. **Aucun rejeu n'a validé les corrections R1-R3.** Le journal des rejeux de `reprise.md` n'a donc **pas** de ligne pour elles : on n'écrit pas au journal au nom de quelqu'un qui n'a pas joué. Si Marvin relit les étapes corrigées, c'est lui qui l'inscrit. 3. **La PR #230 est de la main du PO**, contre l'esprit du CA2. Ce ne sont que des renvois vers les sections existantes de `deploiement.md` et deux commandes déjà publiées et vérifiées ailleurs — aucune commande n'a été inventée. L'approbation de Lénaïc rend le geste à son auteur ; c'est pour ça qu'elle passe en PR et non en commit direct. 4. **`deploiement.md` et `reentrainement.md` n'ont aucun rejeu.** Leur journal le dit, vide. Le CA demande « au moins une procédure » : un journal vide et honnête vaut mieux qu'un rejeu bâclé la veille du jury. 5. **`collecteur.md` n'a pas de section au titre `## En cas de panne`** que le README impose aux quatre. Le fond y est — codes de sortie, arbre de décision, « les alertes ne se rattrapent pas », arrêt et reprise. C'est un écart de gabarit, pas de contenu : le CA4 est tenu, l'alignement du titre est cosmétique. ### Ce que le ticket a réellement mesuré Trois gestes sur quatre tenaient à **Lénaïc**. C'est le point qu'ENF-16 cherche, et les manuels ne le disaient pas : les quinze fichiers étaient sur le même plan. Le README le dit maintenant noir sur blanc, et les deux rejeux croisés ont désolidarisé deux gestes de leur auteur — l'un en réussissant, l'autre en échouant utilement. Fermé une fois la PR #230 approuvée par Lénaïc.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
develop
main
lenaic/heure-locale
justine/72-garde-terraform
justine/69-stockage-archive-azure
lenaic/44-manuels-echec
olivier/44-runbook-reentrainement
justine/37-inference-prevision-servie
lenaic/176-montages-fichiers
gabriel/112-dashboard-chaine-donnee
lenaic/bancs-faux-negatif
lenaic/172-sauvegarde-observable
olivier/36-entrainement-modele
marvin/24-demo-donnees
marvin/25-connexion-session
lenaic/148-chaine-tableau-de-bord
olivier/148-chaine-tableau-de-bord
marvin/94-api-mock-et-tableau-de-bord
lenaic/0-dossier-architecture
lenaic/outillage-skills
No results found.
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
Projects
Clear projects
No items
No project
EnerVision
Assignees
Clear assignees
No assignees
gabriel
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".
2026-09-09
Depends on
#41 [infra] Déploiement Ansible et compte deploy dédié
g2/enervision
Reference
g2/enervision#44
No description provided.