Foyer — Cadre d'agents pour le logiciel sobre, durable, transmissible

→

Production intellectuelle de Gilles Maury, dérivée du Manifeste Maury (github.com/gilmry/manifest, CC BY-SA 4.0). Cadre généralisable à toute organisation qui arbitre, sous responsabilité humaine (répondre-de), ses choix technologiques hybrides — cloud / on-premise, propriétaire / open source, avec ou sans support, IA souveraine / API tierce. La même machinerie de décision gouverne chacune de ces surfaces ; l'agent IA n'en est qu'une (voir skills/arbitrage-hybride.md).

Portable : Chaque fichier se charge dans le contexte d'un agent (AGENTS.md pour OpenCode/Codex/Aider, CLAUDE.md pour Claude Code, ou champ instructions d'opencode.json).

🚀 Démarrage rapide (Starter go)

👉 En local (Linux/MacOS/Windows)

Après le 'git clone' de votre fork, dans la CLI (Command Line Interface = Console) et dans le dossier du projet :

./go

(Installation des dépendances si pas déjà fait, lancement de l'app et activation du Hot Reload)

→ URL locale : http://localhost:8000

Notes utiles :

• Port et hôte personnalisables via FOYER_PORT et FOYER_HOST dans les fichiers starter './go'.
• Sous Linux/MacOS ('./go'), si besoin : chmod +x go.
• Sous Windows ('./go.ps1'), si les scripts sont bloqués : Set-ExecutionPolicy -Scope Process Bypass.
• Hot reload actif: Toute modification dans README.md, Manifeste-Foyer.md, Methode-Foyer.md, Boucle-de-retroaction.md, Simulateur-Synthese.md, skills/, personas/, bmad/, tools/ ou notebooklm/ déclenche une reconstruction automatique du site.

👉 Et encore + simple et sans rien installer : Codespace

→

Opérationnel : Hot Reload, et bien-sûr, commits & push 👍

Rappel : Avant de lancer avec `./go`, autoriser l'exécution avec `chmod +x go`
         (Uniquement lors de la création car l'OS d'un CodeSpace est Linux)

📖 Documentation en ligne

➡️ gilmry.github.io/foyer — site MkDocs Material qui rassemble le Manifeste, la méthode, les skills, les personas et la galerie de supports pédagogiques : vidéos, podcasts, infographies et pitchs.

Le site est reconstruit et redéployé automatiquement à chaque push sur main (GitHub Actions → Pages). La galerie de supports se régénère seule depuis notebooklm/ — voir scripts/gen_supports.py et .github/workflows/docs.yml.

Pour le vibe codeur : décris ton app, l'agent la construit

Foyer sépare trois choses que rien ne t'oblige à savoir assembler toi-même :

• un cadre-harnais (le pilote + les gates : des commandes à exit code qui objectivent le résultat),
• un modèle (l'agent : Claude Code, ChatGPT, Qwen, OpenCode… peu importe),
• un kit (un squelette d'app exécutable, en architecture hexagonale, prêt à piloter).

1. Lancer le pilotage (aucune compétence de dev requise)

Clone ce dépôt, puis donne pilote/BOOTSTRAP.md à ton agent et décris ton app en langage courant (« je veux une todo list avec une interface »). L'agent :

1. lit le cœur (pilote/parcours.md, pilote/defaults.md), sonde ton environnement et choisit le substrat (Docker si besoin) — tu n'installes rien ;
2. déduit l'archétype et choisit un kit (cf. KITS.md) : ce sont des défauts annoncés, pas des questions techniques ;
3. construit, fait passer les gates couche par couche, jusqu'à la preuve de valeur (une vidéo du parcours rejoué) — sans que tu aies à la réclamer.

Tu ne réponds qu'à des questions métier en langage clair (« une seule liste, ou des comptes utilisateurs ? »). Jamais « ORM ou SQL ? » — ça, l'agent le tranche (voir pilote/defaults.md).

2. Utiliser un kit directement

Chaque kit marche direct après clone, sur images Docker publiques :

cd kit-fastapi          # ou kit-php
bash docker/build.sh    # images depuis des bases publiques
bash harness/ci.sh      # tous les gates verts, jusqu'à la preuve de valeur

Puis l'agent remplace le domaine d'exemple (Todo) par ton métier. Le cœur (Domaine + Application) est pur ; on ne touche qu'aux adaptateurs. → détails : KITS.md.

3. Pourquoi c'est portable et agnostique

• Agnostique de l'agent : le comportement est défini par des fichiers Markdown (AGENTS.md pour OpenCode/Codex, CLAUDE.md pour Claude Code, champ instructions d'opencode.json). Dev et PO travaillent sur des modèles différents mais le même registre d'état commité.
• Agnostique de la stack : les kits partagent la même loi hexagonale ; seuls changent les adaptateurs, tous enfichables — HTTP (FastAPI, vanilla, API Platform…) et persistance (CQRS SQL pur ↔ ORM). On prouve l'interchangeabilité en rejouant les gates sur chaque choix.
• Agnostique de l'outillage : les gates sont des commandes à exit code qui tournent à l'identique en local et en CI, via conteneurs — pas d'installation imposée au PO.

L'idée en une phrase

Tout travail tourne sur un même cycle — Conception → Construction → Résultat → Évaluation → Amélioration — où un outil externe objective le résultat, et où l'humain garde la responsabilité (« pourrai-je en répondre, et devant qui ? »).

flowchart LR
    A[<b>C</b>onception] --> B[<b>C</b>onstruction]
    B --> C[<b>R</b>ésultat]
    C --> D[<b>É</b>valuation]
    D --> E[<b>A</b>mélioration]
    E --> A
    C --- F((Un <b>outil externe\nobjective le résultat</b>))
    D --- G((<b></b>Responsabilité humaine\n« Pourrai‑je en répondre,<br/>et devant qui ? »))

Loading

Les trois axes

• Qui est l'agent (valeurs) → Manifeste-Foyer.md
• Quel outil objective (terrain) → skills/
• Qui tient le cercle, à quel grain (rôle) → personas/ et bmad/personas/

Carte

Manifeste-Foyer.md          Identité positive de l'agent (+ annexe sagesses↔invariants)
Methode-Foyer.md            Vue d'ensemble opérationnelle
Boucle-de-retroaction.md   LA PRIMITIVE — le cercle dont tout hérite

bmad/                      PHASE 1 · Conception (vision → backlog)
  BMAD-Conception.md         orchestrateur (pipeline TOGAF A-F)
  archetypes.md              conditionnement : stateless/stateful × API-first/full-stack
  personas/                  Analyste → PM → Architecte → Scrum Master → Validateur
  livrables/                 5 templates (Brief, PRD, Architecture, Stories, Validation)

skills/                    Les 4 outils d'objectivation (enfants de la primitive)
  cycle-dev.md               tests pré-écrits (rouge/vert/bleu, 4 tags)
  gates.md                   analyseurs (quality + security) — transversal
  convergence-iac.md         état observé (salt-ssh, GitOps, distroless, rollback)
  adoption.md                usage réel (RACE → Adoption, RICE/WSJF)
  abaque-cout-capacite.md    estimation prospective TCO + ROI + empreinte mémoire
  arbitrage-hybride.md       grille de souveraineté pour tout choix hybride (cloud/on-prem, proprio/OSS, support, IA)
  enforcement.md             les 3 anneaux : permissions / plugin / substrat
  conformite.md              mapping mondial→européen→belge (ISO 42001/27001, AI Act, NIS2/CyFun, CRA) + angles morts
   bootstrap-delivrabilite.md story habilitante aboutie : git clone + agent = tout configuré
   bootstrap-nouveau-projet.md    partir d'un projet neuf avec le kit : archétype, harnais d'abord, métier ensuite
   migration-projet-existant.md   rétrofit d'un projet non conforme : diagnostic, strangler, verrouillage
   documentation-vivante.md       la preuve de valeur : parcours rejoué en cadence (galerie + vidéo), sans dette de doc (sœur de contrat-api.md)

tools/gates/               Le COMMENT exécutable, en regard du pourquoi de skills/gates.md
  ADR-outillage.md           LA LISTE CONSOLIDÉE — un outil par gate, verdict de veto
                             ligne par ligne, écartés nommés, + cercle de réexamen
  TOOLS.md                   justification fine par écosystème + annexe agrégateur
  github/ gitlab/            templates CI par stack (8 stacks) — des exemples, pas un livrable
  workstation/               gates de poste (pre-commit) : seuls les secrets bloquent

personas/                  PHASES 2-4 · qui tient le cercle
  chef-de-projet · csi-engineer · support-engineer · estimateur-capacite-cout   (invariants)
  scrum-master · lead-developer · platform-engineer     (conditionnels barreau)
  nexus-integration-team · rte                          (conditionnels échelle)

Le flux de bout en bout

1. Conception (BMAD) — cinq personas produisent un backlog validé « Agent IA Ready ». Sortie au verdict PASS uniquement.
2. Pilotage — le chef de projet : WBS → Gantt (axe = passes d'agent) → coût (tokens + superviseur vs target) → choix du barreau (Scrum/Nexus/SAFe).
3. Fabrication — lead developer + scrum master font tourner cycle-dev (+ gates) story par story.
4. Production — platform engineer tient convergence-iac (trigger : AlertManager).
5. Pilotage continu — CSI engineer resserre l'estimation (dogfooding) ; support engineer objective l'adoption (adoption) et rouvre une capacité via RICE.

La méta-boucle ADR/ADM (tenue par l'architecte solution = l'agent du Manifeste) est nourrie par toutes ces boucles et cadencée par le barreau déployé.

Deux coûts, partout

• Tokens (génération du modèle, piloté par OpenCode) — 0,85 €/Mtok in, 2,55 €/Mtok out
• Wall-clock (latence d'objectivation → temps superviseur) — tailles S=0,5 j / M=0,75 j / L=1 j

Registre

Tous ces fichiers orientent (guidance). Le blocage déterministe est l'enforcement — formalisé en trois anneaux (skills/enforcement.md) : permissions agent, plugin, et substrat (hooks git, CI, protection de branche, sandbox) — ce dernier étant le seul dont on répond vraiment. Un beau cadre ne dispense pas de vérifier : « assez fiable pour qu'on cesse de vérifier » est le danger surveillé.