Distribution — Serveur

Serveur de référence V0.1

Architecture, responsabilités, durcissement par paliers

Le serveur de référence StrateFluxDistr matérialise la spécification protocolaire V0-final, applique la sécurité formelle par contexte, et expose les sept opérations canoniques au-dessus du transport gRPC.

Il est en version V0.1 durcie après cinq paliers d'évolution successifs.

Trois couches de responsabilités

Trois couches aux responsabilités séparées Couche transport serveur gRPC, pipeline, handlers, sécurité applicative 7 handlers RPC pipeline 18 étapes trace persistante authentification contraintes V0.1 store persistant démarrage du serveur, exploitation par l'opérateur utilise utilise Couche wire types Protobuf + conversions représentation sur le réseau conversions explicites vers le canonique cohérent avec le .proto V0-final Couche canonique modèle métier autonome D13–D16, identifiants, validation store, sécurité formelle indépendant du transport utilise V0.1 durci · couverture de tests étendue cinq paliers d'évolution successifs tests unitaires et tests d'intégration end-to-end
Figure 1 — Le serveur de référence est organisé en trois couches aux responsabilités strictement séparées. La couche canonique porte le modèle métier indépendamment du transport. La couche wire définit la représentation réseau. La couche transport implémente le serveur gRPC, le pipeline en 18 étapes et la sécurité applicative.

Cette organisation à trois couches préserve la séparation entre le modèle métier (autonome, indépendant de toute technologie de transport), la représentation wire (au format Protobuf, cohérente avec le .proto V0-final), et la matérialisation gRPC concrète (pipeline, handlers, sécurité, persistance).

Caractéristiques V0.1

Le serveur V0.1 a été durci par cinq paliers successifs : sécurité baseline, contraintes contractuelles, configuration runtime, exploitation opérateur, application pilote.

Authentification. Mode dev/test pour le développement et le bootstrap, mode strict pour les environnements durcis avec vérification de signature de jeton. L'identité de l'acteur est toujours dérivée par le serveur, jamais déclarée par le client.

Contraintes contractuelles V0.1. Vérification du schéma de payload, du format, du type exact, présence des champs requis, limite de taille. Chaque échec produit un diagnostic stable et exploitable.

Configuration externe. Le serveur peut être configuré sans recompilation : acteurs autorisés, sources d'émission, Contracts sensibles, politique de trace minimale. Ces paramètres sont externalisés dans un fichier de configuration au format TOML, avec quelques variables d'environnement pour les surcharges.

Persistance. Le serveur dispose d'un store en mémoire pour les démarrages rapides, et d'un store persistant qui rejoue son état au redémarrage. La persistance V0 reste simple et non transactionnelle ; elle suffit pour l'application pilote.

Trace persistante effective. Quand la politique de trace est suffisante, le serveur inscrit dans le store un Lease protocolaire et, au niveau le plus exigeant, un Flow protocolaire. Ces inscriptions matérialisent l'audit complet du dialogue. Si l'inscription échoue, la requête principale n'échoue pas pour autant : un avertissement est ajouté à la réponse et un compteur d'audit est incrémenté.

Lookup contractuel à deux modes. Mode tolérant pour le bootstrap (un Contract absent du store n'arrête pas l'opération mais déclenche un avertissement) ; mode strict pour les environnements durcis (un Contract absent fait échouer l'opération).

Couverture de tests

Le serveur V0.1 est couvert par une suite de tests qui exerce à la fois les composants pris isolément et les opérations gRPC de bout en bout. Les scénarios d'intégration end-to-end couvrent notamment : Catalog dynamique, Inscribe et Resolve, idempotence en replay et en conflit, refus d'une source non autorisée, renforcement de la politique de trace pour les Contracts sensibles, trace persistante effective, fenêtre d'admissibilité fermée, tolérance face à un Contract non résolvable, contraintes V0.1, authentification dev versus strict, redémarrage avec store persistant, audit des inscriptions de trace.

Démarrage et exploitation

Le serveur est conçu pour être démarrable rapidement par un opérateur, sans installation complexe ni connaissance approfondie du modèle. Une fois démarré, il publie le service StratideFlux avec ses sept opérations canoniques sur l'adresse configurée.

Un script de validation de statut est fourni pour permettre à un opérateur de vérifier l'état du serveur sans lire le code source : disponibilité du port, retour du Catalog, présence des informations d'instance et de version protocolaire.

Le code source du serveur de référence n'est pas diffusé publiquement à ce stade. Les documents qui en décrivent l'organisation, les invariants et la couverture de tests sont en revanche disponibles dans la cartographie technique et la documentation de gouvernance.