53 commits en 3 jours : naissance de Basalt Beholder

Le problème réel

Les audits prenaient dix jours. Dix jours pour évaluer la maturité d’une équipe technique sur une grille CMMI. Pas parce que l’évaluation est complexe - parce que l’outil était un tableur Excel de 47 onglets, maintenu à la main, sans validation, sans historique, et sans moyen de générer un rapport propre.

J’ai ouvert ce tableur un lundi matin. J’ai compté les formules cassées : quatorze. Les références circulaires : trois. Les onglets vides qui servaient à “plus tard” : neuf. J’ai fermé le fichier et j’ai commencé à coder.

Le pari zéro-backend

Pas de serveur. Pas de base de données distante. Pas d’API. Pas d’authentification côté serveur. Tout tourne dans le navigateur.

C’est un choix radical qui élimine 80% de la complexité d’un projet web classique. Pas de déploiement serveur, pas de gestion de sessions, pas de CORS, pas de migration de schéma en production. Le prix à payer : les données vivent dans le navigateur. Si l’utilisateur vide son cache, c’est perdu.

Sauf que non. La File System Access API permet de lire et écrire des fichiers sur le disque de l’utilisateur. L’audit est sauvegardé en JSON dans un dossier que l’utilisateur choisit. IndexedDB sert de cache local pour les sessions de travail. Le fichier JSON est la source de vérité.

async function saveAudit(audit: Audit): Promise<void> {
  const handle = await window.showSaveFilePicker({
    suggestedName: `audit-${audit.client}-${audit.date}.json`,
    types: [
      {
        description: 'Audit Basalt',
        accept: { 'application/json': ['.json'] },
      },
    ],
  });
  const writable = await handle.createWritable();
  await writable.write(JSON.stringify(audit, null, 2));
  await writable.close();
}

C’est une PWA. Service worker, manifest, cache-first strategy. L’application fonctionne sans connexion internet. On peut faire un audit dans un sous-sol sans Wi-Fi, sauvegarder en local, et synchroniser plus tard.

La base de connaissances CMMI

Le référentiel CMMI est un arbre de pratiques : domaines, objectifs, pratiques spécifiques, artefacts attendus. Tout ça était enterré dans le tableur sous forme de cellules avec des codes couleur.

J’ai extrait la totalité du référentiel en YAML. Chaque pratique a un identifiant, un libellé, un niveau de maturité, des critères d’évaluation, et des exemples d’artefacts.

domains:
  - id: PM
    name: 'Project Management'
    goals:
      - id: PM-SG1
        name: 'Establish Estimates'
        practices:
          - id: PM-SP1.1
            name: 'Estimate Scope'
            level: 2
            criteria:
              - 'Work breakdown structure exists'
              - 'Scope documented and validated'
              - 'Change control process defined'
            artifacts:
              - 'WBS document'
              - 'Scope statement'
              - 'Change log'

42 pratiques réparties en 8 domaines. Chaque pratique peut être évaluée sur une échelle de 0 à 3 : non implémenté, partiellement, largement, complètement. Le score global se calcule automatiquement.

L’avantage du YAML sur le tableur : c’est versionné dans git. Quand le référentiel évolue, on fait un diff propre. Pas de formule cassée, pas de référence circulaire.

L’interface d’audit

Nuxt 4 avec Vue 3 Composition API. L’interface est construite autour d’un flow linéaire : on sélectionne un domaine, on parcourt les pratiques une par une, on note, on commente, on passe à la suivante.

Chaque pratique affiche ses critères d’évaluation comme une checklist. L’auditeur coche ce qui est en place, ajoute des commentaires, attache des captures d’écran (stockées en base64 dans IndexedDB). Le score se calcule en temps réel.

Le composant central :

<template>
  <div class="practice-evaluator">
    <h3>{{ practice.name }}</h3>
    <p class="practice-level">Niveau {{ practice.level }}</p>

    <div v-for="criterion in practice.criteria" :key="criterion" class="criterion">
      <label>
        <input
          type="checkbox"
          :checked="evaluation.criteria[criterion]"
          @change="toggleCriterion(criterion)"
        />
        {{ criterion }}
      </label>
    </div>

    <textarea
      v-model="evaluation.comment"
      placeholder="Observations, preuves, recommandations..."
      rows="4"
    />

    <ScoreSelector v-model="evaluation.score" />
  </div>
</template>

L’UI repose sur shadcn-nuxt (base reka-ui) avec TailwindCSS - des composants accessibles, thémables, sans le poids d’un framework comme Vuetify ou PrimeVue.

La génération PDF

Le rapport final doit être un PDF. Les clients veulent un document qu’ils peuvent imprimer, signer, archiver. Pas un lien vers une application web.

Génération PDF côté client avec html2pdf.js, en réutilisant directement les composants Vue pour le rendu. Pas de serveur, pas de Puppeteer, pas de headless Chrome. Le PDF se génère dans le navigateur en une vingtaine de secondes.

Le rapport contient : page de garde avec le nom du client et la date, sommaire, synthèse exécutive avec le score global et un radar chart, détail par domaine avec les scores et les commentaires, plan d’action recommandé, et annexes avec les captures d’écran.

Les radar charts et la distribution des niveaux sont générés directement dans les composants Vue, puis convertis en PDF via html2pdf.js. L’avantage : le rendu du rapport est identique à ce qu’on voit dans l’application.

La méthodologie BMAD

Le projet a été développé avec Claude Code, orchestré par BMAD (Business-Minded AI Development) - une méthodologie agile maison avec ses propres agents (dev, PM, architecte, testeur) et workflows structurés en epics/stories.

Le dossier _bmad/ contient agents, workflows et templates. Le project-context.md définit des règles strictes pour les agents IA - un véritable cahier des charges pour Claude. Les workflows incluent dev-story, create-story, sprint-status, code-review, quick-dev.

Les 53 commits en 3 jours

Jour 1 (13 jan) : scaffold Nuxt 4, base de connaissances YAML, store Pinia, IndexedDB service. 5 commits. Le soir, on pouvait naviguer dans le référentiel et noter les pratiques.

Jour 2 (15 jan) : interface d’évaluation complète, calcul des scores, radar chart, upload de pièces jointes, PWA, support DOCX/XLSX. 30 commits. La journée la plus productive de loin.

Jour 3 (16 jan) : version management, réordonnancement des questions, PDF enrichi avec radar charts, command palette, mobile nav, accessibilité, corrections finales. 16 commits.

Le ratio entre les trois jours est révélateur. Le deuxième jour concentre 30 des 53 commits - c’est là que le gros de la logique métier s’est construite.

Le test terrain

Le premier vrai audit avec Basalt Beholder a pris une heure quarante. Contre dix jours avec le tableur. Le client a reçu son PDF dans la foulée. Le radar chart montrait clairement les domaines forts et les points à améliorer. Le plan d’action était généré automatiquement à partir des pratiques non implémentées.

L’auditeur m’a signalé deux bugs : un score qui ne se mettait pas à jour quand on décochait un critère (reactive dependency manquante dans le computed), et une capture d’écran qui ne s’affichait pas dans le PDF (résolu en redimensionnant l’image avant stockage).

Deux bugs pour un outil construit en trois jours. C’est un ratio que j’accepte.

Ce que j’en retiens

Le zéro-backend n’est pas pour tout le monde. Il faut que les données soient personnelles, que la synchronisation ne soit pas critique, et que les utilisateurs acceptent de gérer des fichiers JSON. Pour un outil d’audit utilisé par trois personnes, ça fonctionne parfaitement.

La PWA offline-first est sous-estimée. La majorité des applications web n’ont pas besoin d’un serveur en permanence. Un service worker, un cache intelligent, et la File System Access API couvrent 90% des cas d’usage d’un outil métier simple.

53 commits en 3 jours, c’est la preuve que la contrainte de temps peut être un moteur. Pas le temps de débattre entre Vuetify et PrimeVue. Pas le temps de configurer un pipeline CI/CD. Pas le temps de faire du bike-shedding sur l’architecture. On code, on teste, on livre.