Nexika

Le serveur multi-postes de ResonLab.

Le nom dit ce qu'il fait : le nexus, le lien. Il ne détient pas un métier, il relie des postes à une seule vérité. Le suffixe est celui de la famille — Scenika, Acustika, Nexika.

Il est commun aux applications de la maison : Ohmnia et Scenika. Acustika en est exclue volontairement : elle travaille sur des fichiers de projet, pas sur des données d'entreprise partagées.

Il ne connaît aucune opération métier. Chaque application lui passe son registre d'opérations, sa table de droits et de quoi ouvrir sa base ; lui apporte le reste : transport HTTP(S), comptes, sessions, journal des accès, contrôle des droits, certificat auto-signé, lancement en ligne de commande.

Pourquoi il existe

Une entreprise à plusieurs postes veut travailler sur les mêmes données. Sans ce composant, chaque application aurait son propre serveur de comptes — et deux serveurs de comptes qui divergent valent moins que pas de serveur du tout.

Le mode local reste le défaut partout. Sans choix explicite de l'utilisateur, les applications fonctionnent hors ligne, exactement comme avant. C'est un principe de la maison, pas un réglage.

Ce qu'il refuse de faire

• Écouter sur le réseau tant qu'aucun compte administrateur n'existe. Sinon le premier venu créerait le sien et prendrait la comptabilité.
• Écouter sur le réseau sans chiffrement. Mots de passe et jetons y circuleraient en clair. Sur 127.0.0.1, HTTP reste accepté : le trafic ne quitte pas la machine.
• Exécuter une opération sans droit déclaré. Les droits sont écrits à la main par chaque application, jamais déduits du nom du canal.
• Rétrograder ou désactiver le dernier administrateur. Un serveur sans administrateur ne se reprend plus en main.

Chacun de ces refus est vérifié automatiquement, et chacun a été éprouvé en le cassant volontairement.

L'installer

Nexika s'installe depuis GitHub, comme une dépendance ordinaire :

npm install github:ResonLab/nexika

Le paquet livre du TypeScript, pas du JavaScript compilé, et c'est délibéré : il n'est jamais chargé tel quel par Node. Chaque application le regroupe avec son propre code en un seul fichier (esbuild), qu'on copie sur la machine qui héberge les données. Livrer une version compilée en plus, ce serait deux vérités pour le même code.

exports expose la racine — from 'nexika' — et tout le reste par son chemin, nexika/serveur/demarrer par exemple.

En développement, une modification de Nexika n'atteint l'application qu'après un npm install github:ResonLab/nexika de plus : npm garde la copie clonée dans node_modules. Pour travailler sur les deux à la fois, npm link évite l'aller-retour par GitHub.

Mettre un serveur en service — une commande

node ohmnia-serveur.mjs --assistant --donnees "D:\Serveur"

Elle fait tout ce qu'une machine peut faire seule : le dossier, le certificat auto-signé, le premier administrateur, et le fichier qui fera repartir le serveur après un redémarrage. Puis elle affiche la commande à lancer et l'adresse à renseigner sur les postes.

Rien n'est écrasé — un certificat déjà accepté par les postes, un compte déjà créé : l'assistant les constate et passe. On peut donc le relancer sans réfléchir.

Il ne remplace aucun refus : il les satisfait dans le bon ordre, ce qui est différent. La procédure à la main reste possible, --aide la décrit.

Démarrage automatique

L'assistant écrit le fichier qu'il faut, et affiche la commande à lancer — schtasks sous Windows, systemctl sous Linux. Il ne l'installe pas à votre place : un programme installé en silence est un programme que personne ne sait arrêter six mois plus tard.

Brancher une application

import { demarrerDepuisLaLigneDeCommande } from 'nexika'

demarrerDepuisLaLigneDeCommande(
  {
    nom: 'Ohmnia',
    registre: REGISTRE,     // canal → opération
    roleExige,              // canal → rôle nécessaire
    ouvrirBase: (dossier, version) => { /* … */ },
    fermerBase: () => { /* … */ }
  },
  process.argv.slice(2),
  VERSION,
  'ohmnia-serveur.mjs'
)

Protocole

POST /api/<canal> avec { "arguments": [ ... ] }.

Code	Sens
200	{ "resultat": … }
400	erreur métier, message en français
401	pas de session valable
403	session valable, droits insuffisants
404	opération inconnue

Les noms de canaux sont exactement ceux de l'IPC des applications : une opération se comporte pareil qu'elle passe par la fenêtre ou par le réseau.

Le site

https://resonlab.github.io/nexika/ — en français et en anglais (docs/en/).

Le CSS est repris tel quel de celui des autres sites de la maison, seule la palette change. Recopié à la main, il aurait divergé au premier correctif de mise en forme.

La page anglaise est fabriquée depuis la française par substitutions explicites. node verifier.mjs compare la structure des deux langues et refuse que les deux CSS diffèrent : s'ils diffèrent, c'est que la page traduite a été éditée à la main, et la prochaine génération l'écrasera. Éprouvé en le cassant.

Le vérifier

npm test        # le serveur, sans rien installer
npm run verifier   # le serveur et le site

Aucune installation nécessaire. Node 24 dépouille les types tout seul, et Nexika désigne ses modules internes avec leur extension : il se charge donc sans empaqueteur. Un test qu'on peut lancer sans npm install reste lançable dans six mois.

La suite éprouve ce qui appartient à Nexika, avec une application factice — trois opérations, une table de droits, pas de base : exactement ce que Nexika demande à ses hôtes. Lecture des arguments, rôles, mots de passe, certificat, refus du réseau sans administrateur, mise en service, et le protocole complet sur un vrai serveur qu'on attaque par le réseau.

Les applications continuent de l'éprouver de leur côté (APP/tests/serveur-*.mjs), et c'est complémentaire : elles vérifient leur usage, celle-ci vérifie le composant.

Licence

MIT.