Étude de cas : basalt-beholder (BMAD)

Basalt Beholder

PWA d'audit et base de connaissances CMMI

Application progressive d'évaluation de maturité organisationnelle, avec base de connaissances intégrée, évaluation par critères (0-5) et stockage local sécurisé via IndexedDB et File System Access API. Pilotée par la méthodologie BMAD avec stories Gherkin.

Nuxt 4Vue 3PWAIndexedDBFile System Access APIVitestBMADYAML

basalt-beholder est une application Nuxt 4 pilotée par la méthodologie BMAD (Build Measure Analyze Decide), un framework structuré de gestion de projet intégré directement dans le dépôt. 68 commits et 85 sessions Claude en 2026.

Stack Nuxt 4 / Vue 3.5

Méthodologie BMAD Workflow

Commits 2026 68

Sessions Claude 85

1. Contexte et objectifs

basalt-beholder est conçu comme une PWA d'audit et de base de connaissances. Le projet est remarquable non pas par sa complexité technique, mais par sa méthodologie : BMAD impose une structure de gestion de projet file-based intégrée au dépôt Git.

Stack technique

• Nuxt 3 avec Vue 3 Composition API
• TypeScript strict mode
• Vitest pour les tests (objectif 40-50 tests/feature majeure)
• Convention : <script setup lang="ts">, PascalCase pour les fichiers

2. Parcours utilisateur illustré

Découvrez le parcours complet d'un auditeur dans Basalt Beholder : de la configuration du workspace à la génération du rapport, en passant par la base de connaissances CMMI.

Configuration du workspace

L'application fonctionne entièrement en local : l'utilisateur sélectionne un dossier sur son système de fichiers via la File System Access API. Toutes les données (audits, base de connaissances, documents) sont stockées en YAML dans ce dossier, compatible Git.

Accueil — Workspace local configuré, prêt à travailler

Liste des audits — Filtres par statut, tri par date ou nom

Tableau de bord d'audit

Le dashboard centralise toute l'information d'un audit en cours : progression globale (21%), répartition par volet, activité récente et documents associés. Les 6 volets sélectionnés couvrent 81 questions au total.

Dashboard — Progression 21%, 81 questions sur 6 volets, activité récente

Sélection des volets et exécution

L'auditeur configure les volets à inclure dans l'évaluation (récupération, tolérance aux pannes, qualité des données, conformité, QA & DevOps, architecture). L'exécution se fait question par question avec navigation au clavier, niveaux de maturité (0-4) et priorisation MoSCoW.

Configuration des volets — 6 sélectionnés, ordre d'exécution personnalisable

Exécution — Questions par volet, niveaux 0-4, raccourcis clavier

Génération du rapport

Une fois l'évaluation complétée, l'auditeur peut générer un rapport PDF personnalisable : couleur principale, logo, pièces jointes en annexe. Le résumé affiche les statistiques clés (81 questions, 17 répondues, niveau moyen 2.2).

Rapport — Résumé de l'audit, configuration du PDF, aperçu HTML ou export PDF

Base de connaissances

La base de connaissances regroupe 17 volets et 187 questions couvrant tous les domaines d'évaluation : résilience, sécurité, observabilité, scalabilité, conformité, FinOps, tests, etc. Chaque volet détaille ses questions avec guidance et critères d'évaluation.

Vue d'ensemble — 17 volets, 187 questions, organisés par domaine

Détail d'un volet — Questions classées par priorité (Important / Autres)

3. La méthodologie BMAD

BMAD est un framework de gestion de projet qui vit entièrement dans le dépôt, structuré en 4 phases séquentielles avec un moteur de workflow XML.

Les 4 phases

Arborescence BMAD

basalt-beholder/
├── CLAUDE.md                    # Instructions + workflow BMAD obligatoire
├── .claude/
│   ├── commands/                # Commandes Claude Code
│   └── settings.local.json
├── _bmad/                       # Framework BMAD complet
│   ├── _config/                 # Configuration du workflow
│   ├── _memory/                 # Mémoire persistante inter-sessions
│   ├── bmb/                     # Business Model Builder
│   ├── bmm/                     # Business Model Manager
│   │   └── workflows/
│   │       ├── 1-analysis/
│   │       ├── 2-plan-workflows/
│   │       ├── 3-solutioning/
│   │       ├── 4-implementation/
│   │       │   └── dev-story/
│   │       │       └── instructions.xml  # Moteur de workflow
│   │       └── bmad-quick-flow/
│   ├── cis/                     # Configuration & Integration Scripts
│   └── core/                    # Noyau du framework
└── _bmad-output/
    └── implementation-artifacts/
        ├── 1-1-initialisation-projet-nuxt-4.md
        ├── 1-2-composant-header.md
        ├── 1-3-composant-footer.md
        └── ... (~20+ stories)

Format d'une dev story

Chaque story suit un format strict avec critères d'acceptation en Gherkin :

# Story 1-1: Initialisation Projet Nuxt 4

## Status: Done

## Story
En tant que développeur, je veux initialiser le projet Nuxt
avec la configuration de base pour démarrer le développement.

## Acceptance Criteria (Gherkin)
Given le projet est initialisé
When je lance `npm run dev`
Then l'application démarre sans erreur
And la page d'accueil s'affiche

## Tasks
- [x] Initialiser le projet Nuxt 3
- [x] Configurer TypeScript strict
- [x] Configurer Vitest
- [x] Ajouter les dépendances de base

Moteur de workflow XML

Le fichier instructions.xml orchestre l'exécution des stories avec des étapes séquentielles, un suivi d'état via sprint-status.yaml, et des conditions HALT pour bloquer l'avancement si les critères ne sont pas remplis.

<!-- Extrait simplifié du workflow engine -->
<workflow name="dev-story">
  <step name="read-story">
    Lire le fichier story et comprendre les acceptance criteria
  </step>
  <step name="implement">
    Implémenter en suivant le cycle Red-Green-Refactor
  </step>
  <step name="validate">
    Vérifier TOUS les acceptance criteria
    <halt-if>Un critère n'est pas rempli</halt-if>
  </step>
  <step name="update-status">
    Mettre à jour sprint-status.yaml → Done
  </step>
</workflow>

Sprint tracking (sprint-status.yaml)

Le suivi d'avancement est centralisé dans un fichier YAML versionné :

# _bmad-output/sprint-status.yaml
sprint: 1
status: in_progress
started: 2025-01-15
target: 2025-02-01

stories:
  - id: "1-1"
    title: "Initialisation Projet Nuxt 4"
    status: done
    completed: 2025-01-16
    tests: 4/4
    notes: "Setup complet, CI green"

  - id: "1-2"
    title: "Composant Header"
    status: done
    completed: 2025-01-18
    tests: 12/12
    notes: "Responsive + dark mode"

  - id: "1-3"
    title: "Composant Footer"
    status: in_progress
    tests: 8/10
    blockers:
      - "Lien vers mentions légales non défini"

  - id: "1-4"
    title: "Système de navigation"
    status: pending
    depends_on: ["1-2", "1-3"]

velocity:
  stories_done: 2
  stories_total: 4
  estimated_completion: 2025-01-28

Cycle de vie complet d'une story

Voici le parcours d'une story du backlog à la production :

4. Analyse critique

Comparaison avec d'autres approches

5. Métriques

Répartition des commits

6. Enseignements