Admin-Ka — administration-ka.com
Le Control Center du Groupe Ka.
Console d'administration privée qui pilote le vrai Claude Code CLI sur le cluster MacLustr,
surveille les 19 sites de l'écosystème en temps réel et mesure le trafic humain de toutes les plateformes.
www.administration-ka.com · nœud M3U96a · port 3300 · launchd + ngrok
Console privée. L'accès est protégé par un mot de passe d'application (haché scrypt, cookie de session HttpOnly/Secure). Il n'y a pas d'inscription : c'est l'outil interne d'exploitation du Groupe Ka. Aucun secret n'est présent dans ce dépôt — la configuration sensible vit dans
data/config.json(non versionné) et la clé Anthropic est lue depuis~/.claude/.envsur le nœud.
Sommaire
- C'est quoi, Admin-Ka ?
- Visite guidée en 10 captures
- Les modules, en détail
- Claude Code — pilotage du vrai CLI
- Sessions — détachées, reprenables, rejouables
- Prompts — bibliothèque + upgradeur
- Écosystème — monitoring 19 sites
- Visiteurs — analytics v2 « humains d'abord »
- Vue d'ensemble — le cockpit
- Studio — module Social
- Gardiens KA Guardian (ka2 / ka4 / ka6)
- Écran du nœud (noVNC)
- Identité visuelle
- Architecture
- Modes de permission
- Auth & sécurité
- Structure du dépôt
- Déploiement & exploitation
- Apps natives compagnes
- Contact
C'est quoi, Admin-Ka ?
Admin-Ka est né comme une console chat mobile-first pour lancer Claude Code sur le nœud M3U96a depuis un iPhone. C'est devenu, au fil des versions (v2 puis v3 « Control Center »), le poste de commandement complet du Groupe Ka :
iPhone / Mac ⇄ https://www.administration-ka.com (ngrok) ⇄ backend :3300 (M3U96a)
├── claude CLI local (apps M3U96a)
├── ssh <nœud> → claude CLI (apps distantes, repo de prod)
├── monitor.js → health checks 19 sites, sweep nœuds
├── analytics.js → trafic humain des plateformes Ka
└── social.js → Studio (posts FB, Reels, musique)Principe fondateur — rien de simulé : le chat parle au vrai binaire claude (jamais à l'API Messages pour coder), le monitoring frappe les vrais sites en HTTPS, les analytics comptent les vrais visiteurs, les actions d'admin exécutent de vrais pm2 restart / git log sur les nœuds.
Un seul opérateur, dix-neuf sites, vingt nœuds : tout se pilote depuis cette page.
Visite guidée en 10 captures
Les captures 03 à 10 montrent la console connectée (après authentification) ; les captures 01, 02 et le login mobile montrent ce que voit un visiteur non authentifié : un simple mot de passe, rien d'autre.
01 — Écran de connexion (desktop)

La porte d'entrée : pastille « Ka » orange, un champ mot de passe, un bouton. Aucune information n'est exposée avant l'authentification — la mention discrète M3U96a · MacLustr rappelle seulement sur quel nœud la console tourne.
02 — Écran de connexion (mobile)
Le même login, pensé iPhone d'abord : carte centrée, safe-areas respectées, champ à 16 px (anti-zoom iOS).
03 — Console connectée : la Vue d'ensemble

Premier écran après connexion : le cockpit. Sidebar de navigation à gauche (Vue d'ensemble, Claude Code, Sessions, Prompts, Écosystème, Visiteurs, Studio, Réglages), KPIs en tuiles (humains en ligne / aujourd'hui, sessions, pages vues, 19/19 sites en ligne, incidents, uptime 24 h, latence moyenne, sessions Claude actives, coût Claude cumulé), graphique « Visiteurs humains — 30 jours » avec l'ancienne série v1 en pointillé, chips d'état des 19 sites avec leur latence live, et le journal des incidents récents.
04 — Onglet Sessions

Toutes les conversations Claude Code, filtrables par recherche, application et statut. Chaque ligne affiche le premier prompt, l'app cible (ou « Orchestrateur multi-sites »), le modèle, la taille de contexte (ctx), le coût en dollars et l'ancienneté — avec un bouton Reprendre (le --resume du CLI, transcript rejoué) et une suppression.
05 — Onglet Écosystème

Le monitoring temps réel : bandeau global (19/19 en ligne, uptime 24 h, latence moyenne, 36,5 k checks/24 h, échecs, incidents), puis une carte par site — sparkline de latence, barre d'uptime, p95/p99, nombre de checks, et la ligne d'infrastructure : nœud, état du process (pm2/launchd), âge du dernier commit, jours restants sur le certificat SSL.
06 — Console mobile
La même console sur iPhone : bottom nav 5 entrées (Vue d'ensemble, Claude Code, Écosystème, Visiteurs, Plus), cartes empilées, tout le contenu de l'Écosystème accessible au pouce. C'est l'usage d'origine d'Admin-Ka : administrer le groupe depuis n'importe où.
07 — Vue d'ensemble (rafraîchie)

Le cockpit se met à jour en continu (horodatage maj en haut à droite) : latences recalculées à chaque cycle de checks, ligne de synthèse du filtrage de trafic du jour (ex. « 92 humains · trafic filtré : 51 149 crawler + 36 datacenter + 274 automation »), anomalies de la dernière heure.
08 — Onglet Claude Code

Le cœur historique : « Le vrai Claude Code, lancé sur le nœud de chaque app du Groupe KA ». Picker de cible (une app précise, ou Tous les sites KA (20) = mode orchestrateur multi-sites), choix du modèle et du mode de permissions, suggestions de démarrage, reprise en un tap des dernières sessions, et le champ « Demander à Claude Code… » avec son bouton d'envoi orange.
09 — Onglet Prompts

La bibliothèque de prompts réutilisables : chaque prompt a un titre, une app cible (ou « app au choix »), un aperçu, et quatre actions — Lancer (démarre une session Claude Code avec ce prompt), ✨ Améliorer (l'upgradeur de prompts réécrit la demande via l'API Anthropic avec la connaissance du Groupe Ka injectée), Éditer, Dupliquer, plus favoris ★ et compteur d'usage.
10 — Onglet Visiteurs

Les analytics v2 : bascule Humains / Tout le trafic, KPIs (en ligne < 2 min, humains du jour avec variation vs hier, sessions, pages vues, uniques 7 j / 30 j), barre de répartition par classe (humains / crawlers / datacenter / automation / interne — ici 900 humains pour 51 153 hits de crawlers filtrés), temps réel, panneau d'anomalies avec inspecteur d'IP/visiteur, puis les cartes par application (humains, sessions, pages, 7 j, tendance vs hier).
Les modules, en détail
1) Claude Code — pilotage du vrai CLI
L'exigence non négociable du projet : jamais l'API Messages pour coder, toujours le binaire claude, en mode headless :
claude -p --output-format stream-json --verbose --include-partial-messagescwd= le repo de prod de l'app choisie, sur son nœud de déploiement. Les apps de M3U96a tournent en local ; les autres (lou-ka sur M3U96b, immo-ka sur M4M64a, house-ka sur M4M64b, trouve-ka sur M2M32…) sont pilotées via SSH sur leur nœud — le repo de prod est la seule source de vérité, aucun clone.- Streaming intégral : chaque événement du stream (texte, thinking,
tool_use,tool_result, result) est relayé au navigateur et rendu comme dans le terminal — diffs colorés pour Edit/Write, blocs outils repliables, TodoWrite en checklist, Markdown (marked) + coloration syntaxique (highlight.js), copie des blocs de code. - Options exposées dans l'UI : modèle par session (Fable 5 par défaut, Opus, Sonnet, Haiku —
--modeltoujours passé explicitement, sinon les nœuds retombent sur leur défaut local), mode de permissions, choix du projet,/clear/compact/cost/resume, modèle actif, session ID, coût cumulé en direct, tokens de contexte (+ %), file d'attente de messages, chrono d'exécution. - Mode orchestrateur multi-sites : la cible « Tous les sites KA » lance une session qui coordonne des changements sur l'ensemble du parc (c'est le mode utilisé pour les campagnes transverses — mobile, stats, README…).
- Chaque run reçoit un
--append-system-promptmaison : après toute modification → rebuild +pm2 restart+ healthcheck + commit/push spbgit (origin, jamais GitHub).
2) Sessions — détachées, reprenables, rejouables
Le process claude ne dépend jamais du WebSocket :
- On peut fermer l'onglet, verrouiller l'iPhone, perdre le réseau — la tâche continue sur le nœud.
- Le transcript est persisté en JSONL (
data/transcripts/*.jsonl) ; à la reconnexion, l'app rejoue l'historique manqué puis reprend le live. - Reprise auto durcie : la console rouvre la dernière conversation au lancement (
lastChatId) et force reconnexion + resync au retour au premier plan (visibilitychange/online— iOS coupe le WS à l'écran verrouillé). Reconnexion avec backoff + indicateur d'état. - États clairs : en cours / en attente de permission / inactive ; notifications in-app en fin de tâche ou quand une permission attend.
--resume <session-id>pour continuer une session CLI existante, coût et contexte conservés.
3) Prompts — bibliothèque + upgradeur de prompts
- Prompts réutilisables associés à une app (ou « app au choix »), avec favoris ★, duplication, compteur d'usage, recherche et filtre par app.
- Upgradeur de prompts : le bouton ✨ Améliorer envoie la demande brute à l'API Anthropic (modèle configurable, Opus par défaut) avec un système de connaissance du Groupe Ka injecté (les 19 sites, leurs nœuds, leurs process managers, les conventions remote-first) — et renvoie un prompt excellent, prêt pour Claude Code. L'upgradeur ne répond jamais lui-même : il ne fait que réécrire.
4) Écosystème — monitoring des 19 sites
server/monitor.js, zéro dépendance native (node:sqlite intégré) :
- Health checks HTTPS toutes les 45 s de chacun des 19 sites du groupe depuis M3U96a : latence, code HTTP, jours restants sur le certificat SSL.
- Sweep des nœuds toutes les 5 min : charge / RAM / disque + statut, CPU et mémoire des process PM2 + âge du dernier commit git. Les sites sous launchd (KA Guardian sur M4M36) sont gérés spécifiquement — pas de pm2 sur ce nœud.
- Historique SQLite (
data/eco.sqlite, rétention 35 j) : uptime 24 h / 7 j / 30 j, latence moyenne et p95/p99, sparklines, graphique 24 h, barres d'uptime 14 j. - Incidents : 2 échecs consécutifs → alerte ; rétablissement → alerte verte ; vue Incidents globale avec durées.
- Actions d'admin par site, exécutées localement ou via ssh sur le nœud du site : redémarrer PM2 (
/api/admin/action), logs récents (/api/admin/logs), git & derniers commits (/api/admin/commits). - Push temps réel vers l'UI via le même WebSocket que le chat.
5) Visiteurs — analytics v2 « trafic humain »
server/analytics.js + le beacon public/ka-a.js, déployé sur les sites du groupe. Définitions officielles :
- Visiteur humain : identifiant classé
human= UA navigateur + JS réellement exécuté + réseau non-datacenter/non-proxy + pas interne + pas de flood. - Session : trou > 30 min = nouvelle session. Page vue : événement
pvréel (navigation, SPA incluse) — un heartbeat n'est jamais une page vue. En ligne : dernier événement humain < 120 s, expire tout seul. - 5 classes :
human / crawler / datacenter / automation / internal, classées à l'insertion (regex UA + cache IP-intelligence avec hosting/proxy/ASN, reclassement rétroactif, anti-flood). Les métriques principales n'affichent que les humains ; le reste vit dans la barre de répartition et le toggle « Tout le trafic ». - Beacon v2 (
ka-a.js) : vid/sid en localStorage, pv SPA viapushState, heartbeat 25 s seulement onglet visible + interaction récente. Le beacon v1 reste supporté (dé-duplication côté serveur) et l'ancienne série s'affiche en pointillé « ancien comptage v1 (non filtré) » — jamais comparée directement. - Tables SQLite :
events(brut, 45 j),ipinfo(cache),daily2(rollup quotidien par classe, long terme). Anomalies de trafic + inspecteur d'IP / de visiteur intégré. - Suite de tests :
node server/test-analytics.mjs— 28 scénarios (humain/refresh/SPA, Googlebot, bot d'uptime, IP AWS, curl, interne, dédup v1, invariants uniques ≤ sessions ≤ pv, expiration en ligne). À lancer depuis une copie du dépôt (écrit dansdata/).
6) Vue d'ensemble — le cockpit
La page d'accueil de la v3 « Control Center » : elle agrège tout ce qui précède en un écran — KPIs humains + écosystème + Claude (dont le coût cumulé), graphique 30 jours, chips des 19 sites, incidents récents, anomalies de la dernière heure, raccourcis vers les sessions Claude.
7) Studio — module Social (Facebook & Reels)
server/social.js + server/social/*.py :
- Auto-post Facebook : cartes statistiques et carrousels générés aux couleurs de chaque site du groupe (rendu HTML → image), publiés sur la page Facebook Groupe Ka.
- Reels multi-scènes :
make_reel.pyassemble des vidéos verticales multi-scènes à partir des données live des plateformes. - Moteur musical numpy :
music_engine.pysynthétise les pistes audio des Reels (pas de banque de sons externe). - Galerie des rendus dans l'onglet Studio, insights de page (
insights.py). - Les rendus vivent dans
data/social/(non versionné).
8) Gardiens KA Guardian (ka2 / ka4 / ka6)
Les trois agents gardiens autonomes des connecteurs (ka2.bot / ka4.bot / ka6.bot — un seul repo FastAPI sur M4M36, sous launchd) sont intégrés à la console :
- Chat direct avec chaque gardien depuis Admin-Ka.
- Cartes dédiées dans l'Écosystème (health checks, latence, uptime comme les autres sites).
- Actions launchd sur M4M36 (redémarrage des gardiens) depuis l'interface.
9) Écran du nœud (noVNC)
Un pont WebSocket intégré (/vncws) relie le client noVNC embarqué au Partage d'écran du nœud (127.0.0.1:5900) : on voit et contrôle l'écran de M3U96a directement dans le navigateur, sans exposer VNC sur le réseau — utile notamment pour le module Social (automatisation d'interface).
Identité visuelle
L'identité Groupe Ka, déclinée « console » :
- Crème
#F2F1ECen fond, orange#F97316en accent (traits de graphe#e05f00), encre#1a1611. - Héritage néo-brutaliste (cartes à bords francs, pills, pastille « Ka », typo ronde) modernisé en v3.1 : hairlines + ombres douces, rayons contenus, segmented controls nets — esprit Linear/Vercel, identité crème + orange conservée.
- Dark mode réel (
ka_themeauto / clair / sombre) via variables CSS. - Desktop-first depuis la v3 : sidebar ≥ 1020 px + topbar ; mobile : bottom nav 5 entrées avec safe-areas iPhone.
- Statuts jamais en couleur seule (● ▲ ■ + libellé).
Architecture
iPhone / Mac ⇄ wss://www.administration-ka.com (ngrok) ⇄ backend :3300 (M3U96a, loopback)
backend ⇄ claude CLI (local — apps M3U96a)
backend ⇄ ssh <nœud> claude CLI (apps distantes, repo de prod)
└ tunnel SSH inverse -R : cartes de permission (perm-mcp MCP)
backend ⇄ monitor.js : health checks 45 s + sweep nœuds 5 min + SQLite + push WS
backend ⇄ analytics.js: beacon ka-a.js → events/ipinfo/daily2 (SQLite)
backend ⇄ social.js : Studio (Python : cartes, Reels, musique)
backend ⇄ /vncws : pont noVNC → Partage d'écran 127.0.0.1:5900- Node.js pur (modules ES), serveur HTTP + WebSocket maison — deux seules dépendances npm :
wset@novnc/novnc. SQLite vianode:sqliteintégré (aucune dépendance native). - Frontend une page, aucun framework :
public/index.html+app.js+style.css, vendors locaux (marked, highlight.js, noVNC). - Permissions distantes :
server/perm-mcp.jsest un serveur MCP stdio (--permission-prompt-tool mcp__adminka__approve), déployé aussi sur M3U96b / M4M64a / M4M64b / M2M32 dans~/.adminka/. Chaque demande de permission devient une carte Autoriser / Refuser dans le chat (long-poll, timeout 10 min → refus). Comme l'IPv4 LAN n'est pas routée entre tous les nœuds et que Tailscale inter-nœuds est bloqué, les réponses transitent par un tunnel SSH inverse (-R). - Persistance (
data/, non versionné) :config.json(secrets et réglages),sessions.json,chats.json,transcripts/*.jsonl,eco.sqlite,analytics.sqlite,audit.jsonl, logs.
Modes de permission
- Sûr (défaut) : lecture libre (
Read, Glob, Grep, LS, WebFetch, WebSearch, TodoWrite, NotebookRead, Task) ; tout le reste (Bash, Edit, Write…) déclenche une carte dans le chat : Autoriser / Toujours (cet outil) / Tout autoriser / Refuser. - « Tout autoriser » : le serveur approuve toutes les permissions suivantes jusqu'à la fin de la conversation — la tâche va au bout sans jamais réattendre l'utilisateur.
- Modes CLI également exposés :
acceptEdits,plan, et bypass (--dangerously-skip-permissions) derrière une confirmation explicite dans l'UI.
Auth & sécurité
- Mot de passe d'application haché scrypt → cookie
akidHttpOnly/Secure, 7 j d'inactivité / 30 j max. - Rate-limit login : 8 échecs / 15 min / IP.
- Backend lié à 127.0.0.1 — seul le tunnel ngrok y accède.
- Audit complet :
data/audit.jsonl(logins, prompts, tool_use, permissions, coûts). - Changement de mot de passe :
node server/set-password.js '<nouveau>'puis redémarrage du backend. - Aucun secret dans le dépôt :
data/est hors git (config, bases, transcripts), la clé Anthropic vient de~/.claude/.envdu nœud.
Structure du dépôt
admin-ka/
├── server/
│ ├── server.js # HTTP + WS :3300, orchestration claude (local + ssh), upgradeur de prompts, pont /vncws
│ ├── monitor.js # Écosystème : checks 45 s, sweep nœuds, eco.sqlite, incidents, push WS
│ ├── analytics.js # Analytics v2 : classification humain/crawler/…, sessions, rollups, API
│ ├── perm-mcp.js # Serveur MCP stdio (permission-prompt-tool) — aussi déployé sur les nœuds distants
│ ├── social.js # Studio : posts FB, Reels, galerie, insights
│ ├── social/ # Python : make_reel.py, music_engine.py (numpy), render_card_html.py, insights.py
│ ├── set-password.js # Changement du mot de passe d'app (scrypt)
│ └── test-analytics.mjs # 28 tests analytics
├── public/
│ ├── index.html # SPA sans framework — 8 vues
│ ├── app.js # logique complète du front (WS, replay, rendu stream-json, thème…)
│ ├── style.css # design system crème/orange, dark mode, mobile
│ ├── ka-a.js # beacon analytics v2 embarqué par les sites Ka
│ └── vendor/ # marked, highlight.js, noVNC (locaux)
├── deploy/
│ ├── io.adminka.backend.plist # launchd : node server/server.js (KeepAlive)
│ └── io.adminka.ngrok.plist # launchd : ngrok http --url=www.administration-ka.com 3300
├── docs/screenshots/ # les 10 captures de la visite guidée
├── CLAUDE.md # exigences + pièges connus (à lire avant toute modif)
└── data/ # NON VERSIONNÉ : config.json, SQLite, transcripts, audit, logsDéploiement & exploitation (sur M3U96a)
Le service tourne sous launchd (KeepAlive) sur le nœud M3U96a, exposé par ngrok sur le domaine réservé :
# statut
launchctl print gui/501/io.adminka.backend | head -20
curl -s http://127.0.0.1:3300/healthz
# redémarrer
launchctl kickstart -k gui/501/io.adminka.backend
launchctl kickstart -k gui/501/io.adminka.ngrok
# logs
tail -f ~/apps/admin-ka/data/backend.err.log ~/apps/admin-ka/data/ngrok.log
# changer le mot de passe d'app
node server/set-password.js '<nouveau>' && launchctl kickstart -k gui/501/io.adminka.backend- Clé API : lue depuis
~/.claude/.env(ANTHROPIC_API_KEY) au démarrage du backend (pas de login OAuth sur les nœuds). - Projets proposés dans le sélecteur :
~/groupe-ka/*(clones des repos spbgit),~/apps/*(apps déployées sur ce nœud), et~(home). - Registre des déploiements du cluster :
cluster-deployments.json(laptop, source de vérité). - Repo git : spbgit (git perso) —
~/srv/git/admin-ka.gitsur M3U96a, remoteorigin. Pas GitHub.
Pièges connus (ne pas re-découvrir)
- Tailscale inter-nœuds bloqué (ACL) : depuis M3U96a, joindre les nœuds via les noms Bonjour
.local; M2U64 = sous-réseau 192.168.0.x. - IPv4 LAN non routée entre certains nœuds (EHOSTUNREACH) : les permissions distantes passent par le tunnel SSH inverse.
ControlPathssh trop long avec les hostnames.local→%C.- Sans
--model, un nœud retombe sur son défaut local → toujours le passer explicitement.
Apps natives compagnes
La console a deux enveloppes natives (WKWebView + identité Ka), distribuées hors de ce dépôt :
- Admin-Ka iOS — app SwiftUI (repo spbgit
admin-ka-ios.git), distribuée via TestFlight ; panneaux JS natifs (WKUIDelegate), icône et splash Ka. - Admin-Ka macOS — app SwiftUI notarisée (Developer ID, repo spbgit
admin-ka-macos.git), livrée en DMG.
Contact
- Groupe Ka — www.groupe-ka.com · groupe-ka.com/contact
- Console : www.administration-ka.com (accès privé)
- Infra : cluster MacLustr — nœud M3U96a
© Groupe Ka — Admin-Ka v3 « Control Center ». Console privée d'exploitation ; tout est branché sur le vrai CLI et les vrais sites, rien n'est simulé.