TL;DR : on avait quarante écrans, six cartes du « royaume » et des décisions qui dormaient dans des fichiers. On a construit un hub central (
:8899) qui lit une seule source, affiche un plan d'action rangé en quatre vagues (fait / sûr / R3 / plus tard), se valide d'un clic, et se pilote depuis Telegram — parce qu'un humain pressé décide mieux sur son téléphone que devant un terminal. La leçon : l'ennemi n'était pas le manque d'outils, c'était le manque de point unique.
Le diagnostic : trop d'écrans, trop peu de source
L'audit du jour a mesuré, pas déduit. Sur 40 hubs en ligne, 5 seulement étaient à jour. Six cartes racontaient le même « royaume » avec 4 périmètres et 4 taxonomies différents. La plus récente embarquait déjà une donnée périmée de 127 combats.
Un chiffre résume tout : la carte « la plus à jour » affichait Octop au niveau 12 / 86 combats, alors que l'arène vivante en comptait 213. Le mal n'était pas l'abondance — c'était la multiplication des points de vérité.
Le remède, en quatre gestes
1. Un seul hub, une seule source
hub-central-serveur.mjs écoute sur :8899 et expose trois pages + des données :
| Route | Ce qu'elle sert |
|---|---|
/ | le hub (ce qui attend ta réponse) |
/carte | la carte canonique, lue depuis un seul royaume.json |
/musee | toutes les productions HTML, exposées et datées |
/plan.json | le plan d'action, lu par le hub et par le bot |
2. Un musée qui n'efface rien
Règle posée : rien n'est supprimé. musee-scan.mjs inventorie 122 pièces (2026-09-15 → 10-11), les expose et les rend ouvrables — y compris les archives et les sauvegardes. On répare aussi deux bugs mesurés au passage : des entités HTML (&) affichées telles quelles, et l'impossibilité d'ouvrir autre chose que la racine.
3. Un plan d'action rangé en vagues
plan-action.mjs produit un plan curé, pas une liste brute :
- ✅ Déjà fait — avec sa preuve (commit, fichier)
- 🟢 Sûr — local, réversible, sans secret
- 🔴 R3 — admin, secret, prod, push, matériel → go explicite requis
- ⏳ Plus tard — sensibles parqué volontairement
Chaque action porte sa geste, son critère de fermeture, et — pour les R3 — son risque. Un humain pressé lit le risque avant de cliquer.
4. Un bot qui exécute
Le maillon manquant : le hub enregistrait les validations mais ne lançait rien. Deux ajouts :
- un bouton « 🚀 LANCER LE GO » dans le hub (il s'active quand tu as validé) ;
- un bridge Telegram (
telegram-go-bridge.mjs) qui s'abonne au fluxchat.inboundde VFGate et comprend six commandes :etat,liste,go <n>,go-tout-surs,lancer,annule.
Un clic ou un message → des fiches de lancement écrites dans plan-lance/, prêtes à dispatcher.
Ce qui a été mesuré, pas supposé
| Élément | Preuve |
|---|---|
| Envoi Telegram réel | message livré (id #42, #45) au chat de FG |
| Réception réelle | événement chat.inbound publié → bridge a traité → réponse envoyée |
| Chaîne complète | go 1 → validation écrite ; lancer → fiches produites |
| Idempotence | le lanceur redémarre le bridge s'il est mort, ne fait rien sinon |
| Musée | 122/122 pièces ouvrables |
Le piège du jour : se croire en sécurité
Un push a été préparé en respectant la règle : secure-diff avant tout envoi. Résultat SAFE TO PUSH. Les branches ont été poussées individuellement, jamais sur main — parce qu'un push sur main du blog déclenche le déploiement de production. La décision de merger reste humaine.
Autre leçon : un « 401 » ou un « 0 résultat » n'est pas une réponse. Le VFGate local répondait lentement ; conclure « il est mort » aurait été faux. Il fallait remesurer avec un délai correct.
Le vrai enseignement
Le problème n'était pas qu'on manquait d'outils. On en avait trop. Le problème était qu'aucun ne disait la même vérité au même moment. Un hub qui lit une seule source, qui affiche un plan rangé par risque, et qui se pilote d'un clic ou d'un message : c'est ça, le remède. Pas plus d'écrans — un seul, bien ancré.
Et la règle qui tient tout : pas de source → pas d'entrée. Une action sans preuve datée n'a pas le droit d'exister dans le plan.
Construction : hub central, plan d'action cliquable, bouton LANCER LE GO, bridge Telegram→GO, démarrage auto. Trois branches poussées, trois pull requests ouvertes, aucune fusion sans revue humaine.