L'architecture, en bref

Le détail vit dans docs/vision/ ; cette page tient sur un écran et rappelle ce qui commande les choix du dépôt.

Trois couches

        Cloud OCTOPUS (VPS)                Serveur du client              Postes
 ┌────────────────────────────┐    ┌──────────────────────────┐    ┌──────────────┐
 │ Central : licences, Store, │◄───┤ Server : Core + modules, │◄───┤ Poste web    │
 │ sous-domaines, tunnel      │    │ base, mises à jour, IA   │    │ Desktop      │
 └────────────────────────────┘    └──────────────────────────┘    │ Mobile       │
        ▲ le Server appelle                                        └──────────────┘
        │ toujours vers l'extérieur : aucun port ouvert chez le client

Le Server ouvre lui-même la connexion vers Central. Les postes locaux parlent directement au Server en HTTPS ; un utilisateur distant passe par le sous-domaine du client, relayé par Central. La vidéo ne passe pas par le tunnel : WebRTC en pair-à-pair, relais TURN en secours.

Règle de conception : une coupure internet ou une panne du VPS ne doit rien arrêter en salle de contrôle.

Le noyau et les modules

Le Core est une plateforme, pas une application : ses propres modules passent par le contrat du SDK, comme ceux du Store.

Manifeste par module : nom, version, compatibilité noyau, permissions, dépendances, points d'extension.
Points d'extension : entrée de lanceur, blocs du tableau de bord, types d'événements, actions de scénario, commandes OCTOBOT, calques 3D, modèles de rapport.
Exécution hors du noyau : un module tourne dans son processus et ne parle au Core que par l'API interne, avec les seules permissions de son manifeste.
Compatibilité sémantique : un module « >=4.0.0 <5.0.0 » vaut pour toutes les 4.x, et le noyau refuse ce qui sort de la plage.
Un schéma de base par module : PostgreSQL tient le site, chaque module y possède son schéma et ses migrations, embarquées dans le binaire et appliquées au démarrage. Le noyau ne connaît aucune de leurs tables — il tient le registre de ce qui a été appliqué. ADR 0005.

Le noyau de sécurité

Petit, isolé, et traversé par tout le reste : authentification, autorisations, journal d'audit, secrets, vérification des signatures. Le journal est chaîné — chaque entrée porte l'empreinte de la précédente — pour qu'une ligne retirée ou retouchée se voie.

L'identité vient du client. OpenID Connect avec PKCE, session côté serveur derrière un cookie opaque, six rôles livrés et une correspondance déclarée avec les groupes de l'annuaire. Les droits se nomment <module>.<action>, le refus explicite l'emporte sur tout, et un module fermé répond comme un module absent. Détail et raisons : ADR 0004.

Les machines ont leur propre identité. Un driver, une passerelle, un script d'exploitation présentent un jeton de service révocable, avec les seuls droits qu'on leur a donnés — jamais le compte d'une personne, sinon la main courante attribuerait à quelqu'un ce qu'une machine a fait. ADR 0006.

Les modules se parlent par des faits

Le registre du parc et les procédures guidées écoutent le flux d'événements sans connaître le module qui le produit : ce qui traverse la frontière est un fait — « cet équipement a parlé, à telle heure, de tel endroit » — pas un type appartenant à un autre module. Deux abonnés, deux métiers : le registre note qui a parlé, les scénarios décident si quelqu'un doit faire quelque chose. Le bus NATS prendra la place du canal en mémoire sans que les modules changent. ADR 0008, ADR 0009.

La plateforme propose, l'agent fait. Une procédure guidée ne s'exécute pas toute seule : en sécurité physique, cela retirerait la responsabilité à celui qui en répond. Les actions automatiques ont leur module, et il porte un autre nom — Automatismes.

Tout ne s'écoute pas. Le module Incidents, lui, n'est branché sur rien : un dossier s'ouvre parce que quelqu'un a décidé qu'il s'était passé quelque chose. Un événement critique n'est pas un incident — c'est peut-être une porte mal fermée. ADR 0010.

Ce qui doit se prouver est chaîné. La piste d'audit du noyau et la main courante du poste partagent le même principe et la même primitive : chaque ligne porte l'empreinte de la précédente, si bien qu'on ne peut ni en retirer une ni la réécrire sans que la vérification le dise, et à quelle ligne. ADR 0011.

Connect : les drivers, hors du noyau

Un driver tourne dans son processus, ne touche ni à la base ni au disque du serveur, et dépose ses événements par l'API comme n'importe quelle interface. Il traduit vers le vocabulaire commun ; ce sont les scénarios, en aval, qui décident. C'est la surface la plus exposée aux pannes du site : elle doit pouvoir tomber seule. ADR 0007.

Les surfaces d'attaque ajoutées par la 4.0

Surface	Parade
Modules tiers	Signature, permissions déclarées, revue, isolation, révocation
Accès distant	Tunnel sortant, 2FA, désactivation par le client, journal
Chaîne de mise à jour	Paquets signés en Ed25519, clés hors ligne, canaux, retour arrière

Les quatre phases

Socle — noyau Go, Core, SDK, Server Windows et Linux, reprise des 22 modules publiés. Le SDK est validé par nos propres modules.
Cloud — Central : licences, mises à jour, Store, sous-domaines et tunnel.
Ouverture — console développeurs, Store ouvert aux tiers, mobile, modèles IA.
Appliance — OCTOPUS OS, gamme S/M/L, haute disponibilité, portail partenaires.

Nous sommes au début de la phase 1.