Aller au contenu

Machine d'états

Cette page inclut le contenu complet du document de référence sdlc/SDLC.md. C'est la source de vérité pour la machine d'états : méta-états, workflows par objet (BE / FE / US), mapping des 4 portes G1–G4 (+ boucle MVP→G1) aux transitions, usage de la CLI, invariant de sécurité.

Pour la source exécutable, se reporter à sdlc/schema.js. Pour la documentation par porte avec préconditions, invariants et checks, se reporter à Les 4 portes.

Inclusion directe

Le contenu ci-dessous est inclus depuis sdlc/SDLC.md. Toute modification de la machine d'états doit être faite dans le fichier source — pas ici.

SDLC sdeg-kernel — Machine d'États par Étape Décisionnelle (v3)

Source : sdlc/schema.js · CLI : node sdlc/sdlc.js · Registre : .product/sdlc-registry.json

Principe fondateur : LIVING / COLD

Décision prise
      │
      ▼
  ┌───────────┐     La décision GÈLE les artefacts qui l'ont précédée.
  │   COLD    │  ←  Ils deviennent COLD : non modifiables, historique définitif.
  └───────────┘     On ne revient pas sur le passé — on ouvre un nouveau grain.

Avant la décision
      │
      ▼
  ┌───────────┐
  │  LIVING   │  ←  L'artefact évolue, on apprend, on raffine.
  └───────────┘     N'importe quel changement est possible.

"On fige le passé en prenant des décisions de design." — Le modèle de connaissance du programme

Les 5 Méta-États

Méta-état Heat Signification Badge
NOT_STARTED COLD Ambition non engagée — backlog froid ○
IN_PROGRESS LIVING Artefact actif, mutable, en cours d'apprentissage ●
BLOCKED LIVING-gelé En attente d'une dépendance externe (gouvernance, accès, budget) ◐
DONE COLD Décision prise, artefacts gelés, historique définitif ✓
ARCHIVED COLD Déprioritisé sans conclusion formelle ✕

Règle de dérivation : la propriété heat est dérivée du méta-état. On ne la saisit jamais manuellement.

Pourquoi BLOCKED séparé d'IN_PROGRESS ? En contexte entreprise, les instances de gouvernance sont calendrées, les accès attendent une revue conformité, les budgets sont en review. Sans BLOCKED, tout IN_PROGRESS qui attend devient un bruit. BLOCKED = LIVING mais progression gelée en attente d'un événement externe documenté.

Pourquoi distinguer TERMINE / PIVOTED / ARCHIVED dans DONE ? Ces trois fins de vie ont des significations portfolio radicalement différentes : - TERMINE : ROI atteint, hypothèse validée → capitalisation dans la vision - PIVOTED : hypothèse infirmée → apprentissage documenté, nouvelle BE ouverte - ARCHIVED : déprioritisation → ni succès ni échec formel

Workflow des États par Objet

Business Epic (BE)

        ╔══════════════════════════════════════════════════════════════╗
        ║  COLD — ambition non démarrée                                ║
        ║  NOT_STARTED  ○                                              ║
        ╚══════════════════╤═══════════════════════════════════════════╝
                           │  Ouverture du cycle de Vision
                           ▼
        ╔══════════════════════════════════════════════════════════════╗
        ║  LIVING                                                      ║
        ║  VISION_EN_COURS  ●                                          ║
        ║  Artefacts LIVING : asis · tobe · ehs · lbc · okrs · decision║
        ╚══════════════════╤═════════════════════════════════╤═════════╝
                           │  G1 — Vision arrêtée            │ BLOCKED ◐
                           │  Gèle asis+tobe+ehs+lbc+okrs+decision → COLD
                           ▼                                 ▼
        ╔══════════════════════════════════════════════════════════════╗
        ║  COLD côté Vision · LIVING côté plan de dév                  ║
        ║  ENGAGE  ●                                                   ║
        ╚══════════════════╤═══════════════════════════════════════════╝
                           │  Ouverture du Plan de dév BE
                           ▼
        ╔══════════════════════════════════════════════════════════════╗
        ║  LIVING                                                      ║
        ║  DEV_PLAN_EN_COURS  ●                                        ║
        ║  Artefacts LIVING : plan-dev.md + dossiers Feature           ║
        ╚══════════════════╤═══════════════════════════════════════════╝
                           │  G2 — Plan de dév BE arrêté
                           │  Gèle plan-dev.md → COLD ; ≥ 1 FE rattachée
                           ▼
        ╔══════════════════════════════════════════════════════════════╗
        ║  DEV_PLAN_ARRETE  ●                                          ║
        ╚══════════════════╤═══════════════════════════════════════════╝
                           │  Lancement de la fabrication MVP
                           ▼
        ╔══════════════════════════════════════════════════════════════╗
        ║  FABRICATION_MVP  ●                                          ║
        ║  Les Features fabriquent ; les USs livrent (G3 puis G4)      ║
        ╚══════════════════╤═══════════════════════════════════════════╝
                           │  Déploiement MVP en conditions réelles
                           ▼
        ╔══════════════════════════════════════════════════════════════╗
        ║  REVUE_MVP  ●                                                ║
        ║  Bilan factuel outcomes réels vs EHS                         ║
        ╚══════╤══════════════╤══════════════╤══════════════╤══════════╝
               │              │              │              │
    TERMINE ✓  │  PERSEVERE ● │  PIVOTED ✓  │  ARCHIVED ✕  │
    (ROI max)  │  (Re-G1 :    │  (hypothèse  │  (abandon)   │
               │   nouveau    │   infirmée)  │              │
               │   cycle)     │              │              │
               ▼              ▼              ▼              ▼
             COLD          LIVING          COLD           COLD
             ████           ▼              ████           ████
                      VISION_EN_COURS
                      (boucle MVP→G1)

Feature (FE)

        NOT_STARTED ○
             │  Ouverture du cadrage PRD (parent BE en DEV_PLAN_ARRETE+)
             ▼
        PRD_EN_COURS ●
             │  Artefact LIVING : prd.md (problème · personas · succès)
             │  Le PRD reste LIVING jusqu'à G3.
             ▼
        FAB_PLAN_EN_COURS ●
             │  Artefacts LIVING : spec.md · plan-fab.md · USs
             │
             │  G3 — Plan de fab FE arrêté
             │  Gèle prd.md + spec.md + plan-fab.md → COLD ; ≥ 3 USs INVEST attachées
             ▼
        FAB_PLAN_ARRETE ●  [G3]
             │  Lancement de la fabrication
             ▼
        FABRICATION ●
             │  Quand toutes les USs sont LIVRE → agrégation
             ▼
        LIVRE ✓   COLD ████

v3 (ADR-0009) : PRD_EN_COURS est un statut LIVING intermédiaire. Il ouvre la rédaction du PRD (problème, personas, critères de succès) avant la décomposition en use cases / USs. La transition directe NOT_STARTED → FAB_PLAN_EN_COURS reste disponible en deprecated: true pour la migration v2→v3.

Récit / User Story (US)

        NOT_STARTED ○
             │  Démarrage dev (parent FE en FAB_PLAN_ARRETE+)
             ▼
        DEV ●
             │  TDD : RED → GREEN → REFACTOR
             │
             │  G4 — Incrément livré
             │  Frontmatter requis : pr_url · merge_sha · ci_status ∈ [green, passed, success] · deployed_at
             │  Gèle story.md → COLD
             ▼
        LIVRE ✓   COLD ████

Les 4 Portes sdeg + Boucle MVP→G1

Porte Nom Objet Transition Artefacts gelés
G1 Vision arrêtée BE VISION_EN_COURS → ENGAGE asis · tobe · ehs · lbc · okrs · decision
G2 Plan de dév BE arrêté BE DEV_PLAN_EN_COURS → DEV_PLAN_ARRETE plan-dev.md + ≥ 1 FE rattachée
G3 Plan de fab FE arrêté FE FAB_PLAN_EN_COURS → FAB_PLAN_ARRETE prd.md · spec.md · plan-fab.md + ≥ 3 USs
G4 Incrément livré US DEV → LIVRE story.md (PR mergée, CI verte, déploiement)
Re-G1 Nouveau cycle de vision (boucle MVP→G1) BE PERSEVERE → VISION_EN_COURS — (rouvre la Vision pour un nouveau cycle)

Pas de porte distincte pour la fin de Feature ni pour la livraison/déploiement : la fin de FE est l'agrégation de toutes ses USs en LIVRE. La livraison/déploiement est encodée dans le frontmatter de l'US à G4 (deployed_at).

Usage du CLI

# Vue d'ensemble du portefeuille
node sdlc/sdlc.js status

# Voir la prochaine porte d'un objet + ses prérequis
node sdlc/sdlc.js check BE-I

# Transitionner (interactif — checklist obligatoire)
node sdlc/sdlc.js move BE-I ENGAGE

# Transitionner avec message de contexte
node sdlc/sdlc.js move BE-I REVUE_MVP --message "MVP Sprint 4 déployé"

# Transitionner sans validation interactive (CI/CD, scripts)
node sdlc/sdlc.js move US-1 LIVRE --force

# Créer un nouvel objet
node sdlc/sdlc.js init be BE-VI "Nouvelle Business Epic"
node sdlc/sdlc.js init fe FE-1 "Feature exemple"
node sdlc/sdlc.js init us US-1 "Récit exemple"

# Voir l'historique des transitions d'un objet
node sdlc/sdlc.js log BE-I

# Valider la cohérence du registre (appelé par le pre-commit hook)
node sdlc/sdlc.js validate

Options globales

Option Effet
--force Ignore la checklist interactive (conservé dans l'historique)
--no-git Ne crée pas de commit automatique
--message "texte" Ajoute une note de contexte dans l'historique et l'événement

Architecture des fichiers

sdlc/
  schema.js          ← Source unique de vérité : états et transitions autorisés
  sdlc.js            ← CLI — SEUL POINT de modification d'état
  install-hooks.js   ← Installe le pre-commit hook de validation
  SDLC.md            ← Cette documentation

.product/
  sdlc-registry.json ← Registre persistant de l'état de tous les objets
  .events/
    YYYY-MM-DD-sdlc-<id>-<statut>.md  ← Journal des transitions

Invariant de sécurité

              ┌─────────────────────┐
              │  sdlc-registry.json │  ← état versionné dans git
              └──────────┬──────────┘
                         │ modifié UNIQUEMENT par
                         ▼
              ┌─────────────────────┐
              │    sdlc/sdlc.js     │  ← seul acteur autorisé
              └──────────┬──────────┘
                         │ validé par
                         ▼
              ┌─────────────────────┐
              │   sdlc/schema.js    │  ← référentiel des transitions
              └─────────────────────┘

  pre-commit hook → bloque tout commit qui contient
  une modification de sdlc-registry.json non validée

Installation du hook (une fois)

node sdlc/install-hooks.js

Règles de gouvernance

  1. Le registre ne se modifie jamais à la main. Seul sdlc.js y écrit.
  2. Chaque transition crée un événement dans .product/.events/ et un commit git.
  3. Un objet COLD est en lecture seule. Toute évolution = nouveau cycle (Re-G1 pour une BE) ou nouvelle BE/FE/US.
  4. BLOCKED est une transition visible. Il ne faut pas laisser un IN_PROGRESS stagner sans raison documentée.
  5. PERSEVERE n'est pas un état terminal. C'est une décision de réinvestissement → boucle MVP→G1 : retour à VISION_EN_COURS pour un nouveau cycle de Vision.
  6. L'historique git + les .events/ sont le journal de bord du programme. Ne jamais amender un commit de transition.

Historique du modèle

  • v1 (jusqu'à avril 2026) : 10 portes P1–P10. Découpage fin (P1 réception EO, P2 GO Cadrage, P3 GO Fabrication, P4 PI Planning, P5 DOR récit, P6 DoD, P7 validation iso-prod, P8 homologation, P9 déploiement, P10 bilan MVP).
  • v2 (à partir d'avril 2026) : 4 portes macro G1–G4 + boucle MVP→G1. Le découpage v1 reste consultable dans le journal et les ADR.
  • v3 (ADR-0009, avril 2026) : intégration Nick Tune. Ajout du statut FE PRD_EN_COURS (artefact PRD LIVING pré-G3, freeze à G3) ; 4 portes G1–G4 inchangées. D3/D4/D5 (skills task-level, skill prd-architect, sdeg-reflection) livrées séparément. Transition legacy fe.NOT_STARTED → FAB_PLAN_EN_COURS conservée en deprecated: true pour la migration v2→v3.