Chapitre 4

Le Terrain Test

16 mars 2026

Chapitre 4 — Le Terrain Test

Sources :

  • git log 2026-03-17 matin : commits bsi: open claim sess-20260317-0000-brain-api-key → ec86dc8 feat(brain-hypervisor): spec complet
  • wiki/brain-api-key.md — architecture Brain API Key
  • scripts/brain-launch.sh — cases so3-1 à so3-4, case hypervisor
  • toolkit/bact/patterns/workflow.yml — pattern coach-as-hypervisor, champ discovery

La nuit du 17 mars commence à 00h00 avec un commit d’ouverture de claim : Brain API Key. Phases 1 à 5 enchaînées, méthodiquement. À 10h00 du matin, c’est terminé.

Le système est en prod. keys.tetardtek.com répond. Le key-guardian valide au boot, écrit le feature_set dans brain-compose.local.yml, tombe en grace period si le VPS est muet. Tier free sans clé — silencieux, sans blocage. Tier pro ou full avec une clé bk_live_. La règle d’or tient : jamais d’erreur, jamais de blocage, le brain fonctionne toujours. Le commit scribe: focus v0.8.0 marque la livraison.

Ce qui a été construit est propre. Mais c’est ce qui suit qui intéresse.

Il fallait un terrain pour tester le brain-hypervisor — le protocole de supervision multi-fenêtres qui séquence les workflows sans que l’humain devienne un simple pipe entre sessions. SuperOAuth Tier 3 s’impose naturellement : projet réel, contraintes réelles. Seize vulnérabilités npm (onze high), un pipeline CI/CD mort sur SSH i/o timeout, un sprint Tier 3 à livrer (per-tenant providers, client auth, audit log), un deploy prod au bout. Quatre steps, quatre zones BSI différentes, des drifts de zone détectables à chaque transition.

Le workflow superoauth-tier3.yml est créé. Le brain-launch.sh reçoit ses cases so3, so3-1, so3-2, so3-3, so3-4 — chaque case génère un prompt ciblé à coller dans une fenêtre satellite. Le brain-hypervisor dans sa fenêtre superviseur reçoit les rapports, détecte les drifts de zone (code → CI/CD → code → deploy prod), tient les gates humains.

Le terrain test révèle ce qu’on ne voit qu’en pratique : la fenêtre hyperviseur séparée transforme l’humain en messager. Il reçoit le rapport so3-1 ok, le recolle dans la fenêtre superviseur, copie le brief so3-2, le colle dans une troisième fenêtre. Le protocole est correct. La friction est inutile.

La découverte est capturée dans workflow.yml sous le champ discovery du pattern coach-as-hypervisor : “Découvert par friction : fenêtre hyperviseur séparée = humain devient le pipe entre fenêtres. L’Agent tool supprime ce frottement. Le terrain test superoauth-tier3 était nécessaire pour comprendre le protocole avant de le fusionner dans le coach.”

La case hypervisor est ajoutée à brain-launch.sh. Le coach exécute le protocole dans sa propre fenêtre, spawne les agents delegates en background via l’Agent tool, l’humain ne voit plus que les gates. Stack probe avant délégation. Scan des dépendances cross-projet. Injection de secrets minimaux dans chaque brief. Le workflow-auditor est créé pour les KPIs post-session : autonomy rate, ratio legit/parasite, drift compliance.

SuperOAuth Tier 3 était un projet à livrer. Il est devenu, en même temps, la preuve que le protocole hyperviseur fonctionnait — et l’outil pour le corriger.

Ce qui a été construit

  • Brain API Key phases 1-5 : schema (brain-compose.yml), serveur VPS (brain-key-server.py, brain-key-admin.sh), agent key-guardian, intégration kernel (helloWorld, feature_set, tier_required), sync template. Live en prod sur keys.tetardtek.com.
  • Workflow superoauth-tier3 : 4 steps séquencés avec zones BSI, gates humains, briefs satellites via brain-launch.sh so3-N.
  • brain-hypervisor spec : loop, drift detection, BACT hook, modes manuel et v3-9.
  • Pattern coach-as-hypervisor : capturé dans workflow.yml avec structure, règles, et discovery.
  • workflow-auditor : KPIs sudo-superviseur post-workflow (autonomy rate, legit/parasite gate, drift compliance).

Décisions clés

  • Tier free = default non-dégradé : clé absente ou invalide → tier: free silencieux. Le brain complet reste accessible sans clé. Les tiers supérieurs débloquent des agents calibrés, pas le fonctionnement de base.
  • Grace period 72h : si le VPS est inaccessible, le dernier feature_set connu est conservé. Pas de downgrade brutal sur une panne réseau.
  • Terrain test avant fusion : le pattern coach-as-hypervisor n’a pas été designé a priori. Il a émergé de la friction observée sur SuperOAuth Tier 3. Le terrain test était le prérequis, pas une validation a posteriori.
  • L’Agent tool comme infrastructure : la fusion hyperviseur dans le coach n’est pas une optimisation de confort — c’est une décision architecturale. L’humain ne doit gérer que les gates, pas le transport d’information entre fenêtres.