Hub — Interface d'administration Synedre OS

Le Hub — interface d'administration du harnais agentique

Le Hub est l'interface d'administration privée de Synedre OS. Accessible uniquement depuis le VPS du vaisseau-mère via un tunnel sécurisé, il centralise le pilotage des agents, des chantiers, des runs, des négociations, de la mémoire et de l'infrastructure.

Architecture de l'application

L'application du Hub est construite en Nuxt standalone, sans héritage de couche partagée avec d'autres produits. Elle est volontairement limitée au français et au thème sombre : la bascule clair/sombre a été retirée, et la classe dark est forcée au montage sur l'élément racine HTML.

Le Hub n'est pas un monolithe. Ses fonctionnalités sont réparties en modules indépendants, chargés comme des couches Nuxt (layers) via la directive extends de la configuration principale. Chaque couche auto-découvre ses pages, ses endpoints d'API et son code serveur. Un module peut ainsi apporter :

• des pages accessibles sous /hub/*,
• des endpoints d'API dédiés,
• de la logique serveur (base de données, utilitaires).

L'application compte actuellement 27 couches actives, couvrant les domaines suivants : suivi d'activité, agents, rédaction automatisée, automates, backlog, centrage client, chantiers, cicatrices, configuration, conduite, correspondance, réunions quotidiennes, exercices, données collaborateur, expertises, retours, flotte, hub central, usurpation de session, incidents, facturation, supervision, métadonnées de pages, réunions, intégration e-commerce et outils transverses.

Note d'architecture : ces modules doivent être déclarés comme couches (layers) dans la directive extends, et non comme modules Nuxt dans modules:[]. Cette confusion provoque une erreur de chargement — le pattern correct impose à chaque couche un fichier de manifeste et une configuration Nuxt minimale.

Carte des modules et pages

Pages du cœur du système

Huit pages sont hébergées directement dans le cœur de l'application, hors des modules :

• Page d'accueil — n'est pas une page à part entière : elle redirige automatiquement (HTTP 302) vers le terminal principal.
• Supervision de la résilience (/hub/sre) — tableau de bord SRE.
• Coûts (/hub/cost) — vue des coûts agrégés.
• Apprentissage agentique — synthèse des apprentissages issus des runs.
• Index des chantiers — liste des chantiers actifs.
• Sauvegardes — état des sauvegardes du vaisseau-mère.
• Détail budgétaire — vue des coûts par chantier et budget annuel ; accessible depuis la page coût principale, non exposée dans la barre latérale.
• Cadran de maintenance — tableau de bord de la boucle d'auto-inspection de la documentation, décrit ci-dessous.

Le cadran de maintenance

Le cadran de maintenance est le tableau de bord de la boucle nocturne d'inspection et de régénération de la documentation. Il expose deux onglets :

1. Tableau de bord global : jauge de santé synthétique, quatre dimensions d'analyse (proprioception, dette, apprentissage, automates), courbe des 7 derniers jours et tableau des dérives documentaires. Les dérives détectées sont classées selon leur nature : référence morte, contenu publié devenu obsolète, code plus récent que la doc, contenu non encore publié.
2. Regard externe : l'opérateur sélectionne un chapitre de documentation publique, génère un prompt épuré de toute donnée sensible, le soumet à un modèle d'IA externe, puis colle la réponse dans le formulaire. L'historique des soumissions est consultable. La taille maximale d'une réponse soumise est de 50 000 caractères. Les chapitres disponibles couvrent onze domaines : vue d'ensemble, couche de données, cœur agentique, chantiers, automates, hub, e-mail, mémoire, déploiement, façades, compétences et réflexes.

Pages portées par les modules

Les modules apportent 49 pages supplémentaires sous /hub/*, réparties comme suit :

Domaine fonctionnel	Nombre de pages	Périmètre couvert
Cœur agentique	38	Agents, brainstorm, chantiers, clients, conseil, constitution, dispatch, doctrine, e-mails, réflexes, boîte de réception, juridique, mémoire, négociations, questions, réacteur, runs, sessions, paramètres, compétences, tâches, modèle utilisateur
Backlog & planification	3	Backlog, planning, backlog système
Chantiers	2	Fiche chantier, cockpits
Exercices	2	Session d'exercice, exercice par agent
Cicatrices	1	Journal des cicatrices
Conduite	1	Tableau des conduites
Automates	1	Gestionnaire d'automates système
Supervision SEO	1	Cockpit SEO multi-client (décrit ci-dessous)

Surface publique des exercices : le module d'exercices expose également quatre pages accessibles publiquement sur synedre.com (hors /hub/) : index des exercices, historique, journal des cicatrices publiques et détail d'une épreuve. Ces pages ne sont pas comptabilisées dans les 49 pages hub ci-dessus.

Le cockpit de supervision SEO

Le cockpit de supervision SEO est un tableau de bord technique multi-client accessible par URL directe, non référencé dans la barre latérale principale. Il présente pour chaque client :

• un verdict de santé SEO,
• le taux d'erreurs 404 (indicateur avancé),
• la tendance des clics et impressions via Google Search Console (indicateur retardé),
• un mode observation seule ou auto-remédiation,
• un journal des alertes émises.

Modules serveur uniquement

Dix-huit modules n'exposent aucune page Vue : ils fournissent exclusivement des endpoints d'API et de la logique base de données, consommés par d'autres pages du Hub ou par les automates Python. Ces domaines couvrent : la formation interne, le suivi d'activité, la rédaction automatisée, le centrage client, la configuration par client, la correspondance, les réunions quotidiennes, les données collaborateur, les retours utilisateurs, la flotte, le hub central (statistiques, constitution, charte), l'usurpation de session, les incidents, la facturation, les métadonnées de pages publiques, les réunions périodiques, l'intégration e-commerce et les outils transverses.

Cas particulier : le module d'expertises apporte des pages à vocation publique et SEO (hors /hub/), sans page d'administration dans le cockpit.

Navigation — la barre latérale

La barre latérale du cockpit est organisée en sept zones fonctionnelles, codées en dur dans la mise en page principale :

Zone	Entrées
Pilotage	Terminal, E-mails, Brainstorm, Modèle utilisateur
Business	Négociations, Conseil, Juridique
Exécution	Backlog, Chantier, Runs, Questions, Nouvelle tâche, Sessions
Doctrine & Apprentissage	Doctrine, Constitution, Cicatrices, Exercices
Agentique	Agents, Réacteur, Compétences, Propositions de compétences, Automates système, Dispatch, Réflexes & Hooks, Apprentissage agentique
Mémoire	Brain (mémoire structurée), Recall RAG (recherche sémantique)
Système	SRE, Cadran de maintenance, Coûts, Sauvegardes, Paramètres

La détection de l'entrée active fonctionne par correspondance exacte ou par préfixe de sous-route : une entrée est marquée active si la route courante est identique à la cible ou commence par cette cible suivie d'un séparateur.

Changement récent : le raccourci direct vers la surface e-commerce a été retiré de la barre latérale. Le terminal, point d'entrée par défaut du Hub, est la page vers laquelle redirige la racine /hub.

Les trois familles d'endpoints

Le découpage de la surface API n'est pas qu'organisationnel : il porte une sémantique de droits. Trois préfixes de routage coexistent, chacun avec son modèle d'accès.

• Back-office fondateur / cron — protégé en amont par une barrière infrastructure ; certains endpoints n'ajoutent pas de vérification applicative supplémentaire.
• Cockpit employé (hub) — garde de session employé appliquée de façon quasi-systématique sur l'ensemble des routes.
• Transcription audio (voice) — garde de session employé et défense anti-CSRF cumulées.

Back-office fondateur

Cette famille regroupe plusieurs dizaines d'endpoints répartis en sous-domaines fonctionnels. Les principaux domaines couverts sont :

• Apprentissage — consultation du fil d'apprentissage, application et modification de fiches.
• Chantier — décomposition, replanification, changement de statut et lancement de phases pour un chantier donné.
• Indicateurs de coût — tableau de bord, budget (lecture/écriture), séries temporelles et ventilation par chantier.
• Messagerie entrante — synchronisation IMAP déclenchée par cron (voir ci-dessous), liste et détail des messages, gestion des pièces jointes, rattachement à un chantier.
• Pilotage système — sauvegardes (liste, téléchargement), métriques d'observabilité, statut d'expédition automatique par tenant.
• Maintenance documentaire — lecture de l'état de santé du corpus et de la dérive détectée ; sous-section dédiée à la révision externe : liste des chapitres éligibles, génération du prompt épuré pour un modèle IA externe, historique des révisions avec filtres, soumission d'une révision (modèle, réponse externe, traçabilité de l'auteur).

Modèle d'authentification du back-office

Certains endpoints de cette famille s'appuient exclusivement sur la barrière infrastructure (décrite en section Authentification ci-dessous) plutôt que sur la garde de session applicative. C'est notamment le cas de la route de synchronisation de la messagerie entrante, conçue pour être appelée par un planificateur externe (cron système).

Un planificateur interne au serveur d'application a été réactivé et prend en charge sept tâches récurrentes :

• Traitement de la file d'envoi d'e-mails — toutes les 2 minutes.
• Surveillance de disponibilité — toutes les 15 minutes.
• Veille dictionnaire — toutes les 30 minutes.
• Veille des dépendances — quotidienne à 2 h.
• Réunion quotidienne automatisée — quotidienne à 8 h.
• Surveillance des certificats SSL — quotidienne à 9 h.
• Veille de marque — quotidienne à 12 h.

La synchronisation de la messagerie entrante reste délibérément exclue de ce planificateur interne en raison de contraintes liées au modèle d'E/S du serveur (opération bloquante incompatible avec la boucle d'événements) ; elle est assurée par un cron système indépendant.

Cockpit employé

Cette famille est de loin la plus volumineuse : elle couvre les interactions quotidiennes des employés avec le système. La garde de session employé est appliquée dans la très grande majorité des handlers ; les seules exceptions sont des utilitaires internes non exposés directement et certains flux de données en temps réel (Server-Sent Events).

Les grandes familles de routes couvrent :

• Gestion des chantiers et de leurs tâches, travaux, équipes, contexte et pertinence d'audit.
• Historique et détail des runs d'agents (dont réponses, spawns de correctifs, profils d'agent).
• Négociations, sessions de conseil, brainstorming.
• Mémoire, doctrine et compétences des agents.
• Questions, modèle utilisateur, paramètres.
• Dispatch global, état de la cartographie Atlas, liste des agents disponibles pour un prompt.
• Hooks d'événements et interface CLI Synedre.
• Flux d'événements agent en temps réel (SSE) au niveau du chantier et du run.

Transcription audio

Un unique endpoint reçoit un fichier audio WAV en multipart et retourne le texte transcrit accompagné de métadonnées (langue détectée, durée, modèle utilisé, moteur de transcription). La délégation se fait vers un service de transcription interne.

Plusieurs garde-fous sont appliqués cumulativement :

• Garde de session employé obligatoire.
• Taille maximale du fichier audio : 5 Mo.
• Limitation de débit : 100 transcriptions par tranche de 5 minutes par session.
• Audio jamais écrit sur disque — traitement en mémoire vive uniquement.
• Défense CSRF par vérification de correspondance entre l'en-tête d'origine et l'hôte.

---

Authentification

Un modèle en deux couches indépendantes

La sécurité d'accès repose sur deux couches orthogonales qui se complètent :

• Couche infrastructure — un tunnel chiffré combiné à une barrière de filtrage HTTP (cookie d'accès + identifiant secret) garantit que seul l'opérateur autorisé peut atteindre le serveur d'application. Les requêtes arrivent donc déjà qualifiées « propriétaire uniquement ».
• Couche applicative — un middleware de démarrage pose automatiquement une session fondateur signée sur chaque requête ne disposant pas encore de session valide. La garde de session applicative voit donc toujours un employé valide ; la sécurité réelle est déléguée à la couche infra.

Les gardes de session

Un utilitaire central gère l'ensemble du cycle de vie des sessions :

• Lecture de session — décode le cookie de session (JSON encodé en base64url, signé par HMAC-SHA256). Retourne null si le cookie est absent ou invalide.
• Garde employé standard — retourne la session si le type d'utilisateur est employee, déclenche une erreur 401 sinon. C'est la garde appliquée sur l'ensemble des routes cockpit et audio.
• Garde fondateur — exige en outre le statut Super-Admin SaaS ; retourne 403 sinon.
• Garde par rôle ou SaaS — accepte soit un rôle fonctionnel précis, soit le statut Super-Admin SaaS.
• Détection Super-Admin SaaS — liste blanche d'adresses e-mail codée en dur dans le source, délibérément hors base de données : toute modification implique une revue de code explicite.

La structure d'une session comprend : identifiant employé, adresse e-mail, prénom, nom, rôle, identifiant de profil, identifiant client, type d'utilisateur, indicateur administrateur.

La session fondateur automatique

Le middleware de démarrage (priorité la plus haute dans la chaîne) intercepte chaque requête dépourvue de session valide et signe immédiatement un cookie de session dont le payload correspond au profil fondateur (rôle Super-Admin, durée de vie 30 jours). Sur le runtime du vaisseau-mère, la garde employé standard passe donc toujours — la protection réelle est assurée par l'infrastructure (tunnel + barrière HTTP).

Périmètre strict — ce middleware n'existe que sur le runtime du vaisseau-mère. Il est absent des modules client et des runtimes tenant publics, où la garde de session reste pleinement obligatoire.

Le middleware de routage front est désactivé

Un middleware de routage côté client référencé par un grand nombre de pages du cockpit a été volontairement réduit à une fonction neutre (no-op) : la barrière infrastructure et le tunnel SSH assurent l'authentification en amont, rendant ce middleware redondant. Il reste déclaré dans le code pour ne pas casser les métadonnées de page qui le référencent.

Note de cohérence — le commentaire d'en-tête de ce fichier indique un nombre de pages référençant le middleware inférieur au compte réel ; cet écart n'a pas d'impact fonctionnel (le middleware étant un no-op) mais devrait être corrigé lors du prochain passage de maintenance.

---

Layout du cockpit

Le cockpit repose sur un layout unique qui structure l'ensemble des pages employé : navigation latérale, en-tête, zone de contenu principale. Ce layout est autonome — le vaisseau-mère n'hérite d'aucune couche de base partagée avec les modules client.

• Le titre du navigateur suit le gabarit … — Synedre OS.
• L'identité visuelle (favicon) pointe vers le logo Synedre.
• L'utilisateur affiché dans l'interface est une constante statique ; l'authentification dynamique côté Nuxt a été retirée, la sécurité étant portée par l'infrastructure.
• Les pages déclarent un rendu exclusivement client (ssr: false), en particulier les vues temps réel (tableau de bord réacteur, suivi de chantier).

Note de cohérence — le commentaire d'en-tête du layout liste les entrées de navigation de façon incomplète (deux entrées présentes dans la configuration réelle sont absentes du commentaire). La configuration effective du tableau de navigation fait toujours foi sur le commentaire.

Les surfaces de pilotage du Hub

Le Hub expose plusieurs consoles de pilotage dédiées aux agents. Chaque console correspond à un domaine fonctionnel distinct : exécutions scopées, gestion de projets, négociations commerciales, supervision de la flotte ou vue orbitale temps réel. Les données sont centralisées dans un modèle commun dont les entités métier sont partagées entre les différents modules.

Exécutions scopées (Runs)

Un run représente l'exécution d'Atlas dans un périmètre défini — vaisseau-mère ou tenant — déclenchée depuis le chat, un email entrant ou une tâche planifiée. Chaque run expose les informations suivantes : identifiant, source de déclenchement, nature du déclencheur, périmètre, titre, statut, type et identifiant de référence, ainsi que les horodatages de création et de fin.

Deux sources de déclenchement existent :

• Email entrant — Atlas traite le message et ouvre un run associé.
• Chat console — l'opérateur interagit directement depuis l'interface Hub.

À noter : les emails dont l'intention est classifiée comme question, bruit ou ouverture de chantier ne génèrent pas de run : ils restent traités dans les consoles Questions et Chantiers respectivement. Une exécution de tâche planifiée est une entité distincte du run Atlas.

La console Runs expose les fonctionnalités suivantes via ses endpoints :

• Listage et filtrage des runs par périmètre et portée.
• Détail d'un run individuel (profil, événements en temps réel via flux SSE).
• Génération et validation de brouillons de réponse.
• Déclenchement d'un correctif depuis un run (spawn-fix).

Gestion de projets (Chantiers)

Un chantier est l'unité de projet principale de Synedre OS. Il se décompose hiérarchiquement :

1. Un chantier regroupe un ensemble de travaux.
2. Chaque travail contient un ensemble de tâches.

La création canonique d'un chantier suit une procédure en sept étapes qui instancie automatiquement la structure squelette (chantier + travaux initiaux + tâches), les liens d'équipe et le contexte d'audit.

Les interfaces associées comprennent :

• Une vue liste des chantiers actifs.
• Un tableau kanban par travail.
• Un détail par travail avec ses tâches.
• Les cockpits — vues consolidées de sessions actives.

Les endpoints couvrent l'ensemble du cycle de vie : sessions actives, détection de bugs, génération de mission, archivage, clôture avec brouillon d'email, bascule en brainstorm, gestion des livrables, des membres d'équipe et de la pertinence d'audit.

Mécanismes de contrôle de concurrence et d'audit

Plusieurs composants garantissent la cohérence des opérations concurrentes sur un chantier :

Composant	Rôle
Verrou de chantier	Verrou distribué par chantier. Empêche deux sessions parallèles (session opérateur et sous-agent spawné) de modifier simultanément le même chantier. Clé composite (identifiant chantier, type propriétaire). TTL de 30 minutes renouvelable par battement de cœur. Mode de compatibilité ascendante : si la table de verrous est absente, l'acquisition est considérée réussie.
Erreur de verrou actif	Exception levée lorsque le contexte d'un chantier est demandé alors qu'une autre session en détient le verrou. Interceptée par le module de traitement des chantiers pour renvoyer un message explicite à l'opérateur.
Journal d'audit des découvertes	Enregistre chaque invocation du pipeline de découverte automatique de travaux. Une ligne est créée en état pending puis mise à jour vers success, validation_failed, llm_failed ou killswitched. Colonnes notables : modèle IA utilisé, fournisseur, tokens consommés, coût estimé en euros, plan généré, nombre de travaux créés. Rétention : 90 jours. Un compteur sur les dernières 24 heures sert de coupe-circuit configurable avant chaque exécution.
Graphe de dépendances de tâches	Modélise les dépendances entre tâches au sein d'un travail sous forme de DAG orienté. L'ajout d'une dépendance valide : absence d'auto-référence, appartenance au même travail, absence de cycle (détection DFS). Les dépendances inter-travaux font l'objet d'une table dédiée (statut à confirmer). Erreurs explicites : cycle détecté, tâches appartenant à des travaux différents.

Console CLI intégrée

Une surface dédiée permet de piloter une session Claude CLI réelle depuis le cockpit, sans quitter l'interface Hub. Elle expose trois opérations :

• Statut — interroge un daemon tournant sur la machine hôte (et non dans un container isolé) ; renvoie { ok, alive, info }. Lorsque le daemon est indisponible, la réponse reste un succès HTTP avec alive: false — le message d'erreur interne n'est jamais transmis au client.
• Envoi de frappes — transmet des entrées clavier à la session active.
• Flux temps réel — flux SSE de la sortie de la session CLI.

Sécurité : le daemon cible la machine hôte et non le container applicatif — un correctif a aligné ce comportement lors d'un travail de stabilisation.

Négociations commerciales

La console Négociations matérialise le pipeline de qualification des leads entrants :

1. Un email entrant est transmis à Atlas.
2. Atlas classifie l'intention comme negociation.
3. Un enregistrement de négociation est créé.
4. Les agents travaillent sur cet enregistrement depuis la vue détail.

Les opérations disponibles sur une négociation couvrent : assignation, gestion des contacts, livrables (avec pièces jointes), historique des emails, événements, propositions commerciales (avec décision accept/reject), statut et frise chronologique.

Supervision de la flotte

Le module de flotte est un module serveur sans interface Hub propre à ce stade. Il maintient un registre des instances déployées chez les clients, avec pour chaque instance : identifiant client, nom, domaine, offre souscrite, revenu mensuel récurrent, frais d'installation, statut, région VPS, URL d'administration, fournisseur et modèle IA utilisé.

⚠️ Points d'attention :

• Le pilotage opérationnel de la flotte s'effectue principalement via les consoles d'administration des sites et des utilisateurs Hub — pas directement via ce registre.
• La source de vérité opérationnelle des VPS clients est une table distincte ; la relation exacte entre les deux registres est à confirmer.
• Ce registre est un schéma legacy hérité de l'époque PaaS. Il contenait historiquement des colonnes pour des secrets d'accès — ce schéma est en cours d'audit et ne doit pas être considéré comme source canonique de secrets. La doctrine en vigueur impose zéro secret en clair dans les tables métier.

Vue orbitale — Réacteur

La page Réacteur offre une visualisation orbitale temps réel de l'activité des agents. Elle est composée de trois anneaux concentriques :

• Anneau intérieur — agents de direction.
• Anneau intermédiaire — agents de cadrage et d'exécution.
• Anneau extérieur — agents de validation.

Un logo pieuvre occupe le centre. Les mises à jour sont reçues en temps réel via un flux SSE. La page est rendue côté client uniquement. Elle partage son modèle visuel avec la page marketing publique dédiée au réacteur.

Points d'entrée pour les contributeurs

Objectif	Mécanisme
Ajouter une entrée dans la barre de navigation Hub	Déclarer l'entrée dans le tableau de sections de navigation du layout Hub.
Ajouter une page /hub/X	Créer la page dans le module concerné et déclarer le layout hub via les métadonnées de page.
Ajouter un endpoint cockpit	Créer l'endpoint dans le répertoire API du module et y appliquer le middleware de vérification de session employé.
Comprendre l'authentification	Consulter les utilitaires de session et le middleware d'auto-session vaisseau-mère.
Brancher un nouveau module applicatif	Déclarer le module dans la configuration d'extension Nuxt, fournir son manifeste et sa configuration locale.
Accéder au modèle de données des runs et chantiers	Consulter les entités métier partagées et les tables correspondantes : runs, chantiers, travaux, tâches, négociations.
Cadran de maintenance et dérive de documentation	Consulter la page de maintenance Hub et ses endpoints associés, qui s'appuient sur les tables de santé documentaire et de dérive détectée.
Revue externe de documentation	Consulter le composant de panel de revue externe et ses endpoints, qui s'appuient sur la table de revues externes.
Registre des réflexes et hooks agents	Consulter la page Hub dédiée aux hooks et son endpoint de listage, qui expose le registre des réflexes organisés par tiers (tronc / bras).
Verrou de chantier — gestion de la concurrence CLI	Le verrou distribué expose les opérations : tentative d'acquisition, prise de force, libération, battement de cœur.
Journal d'audit des découvertes automatiques	Le journal expose les opérations : récupération des entrées récentes par chantier, comptage sur les dernières 24 heures.
Graphe de dépendances de tâches (DAG)	Le gestionnaire de dépendances expose : ajout, suppression, listage par travail, avec détection anti-cycle par parcours en profondeur.

Secrets : aucun secret n'est stocké en clair dans le code. Le secret de signature des sessions est consommé par le module de cryptographie de session (HMAC) et vit exclusivement dans les fichiers d'environnement exclus du contrôle de version, conformément à la doctrine des secrets documentée séparément.