Cap général distribué

StrateFluxDistr est l'extension distribuée du noyau Stratide Flux v2. Elle projette le modèle de référence — endpoints, Contracts, Leases, Flows — sur un protocole gRPC, ajoute la sécurité formelle par contexte, et fournit un serveur de référence qui matérialise les invariants du modèle.

Cette page présente les choix structurants du projet, le périmètre V0 fermé, et la trajectoire au-delà.

Trois caps successifs

Le projet distribué se déploie en trois caps successifs, chacun étant une étape complète de gouvernance.

Cap 1 — L'instance dédiée

Une seule instance StrateFluxDistr est déployée pour un cas d'usage précis et sert un ensemble bien identifié de clients. Tous les acteurs autorisés, tous les Contracts, tous les endpoints cohabitent dans cette instance unique. Les inscriptions vivent dans son store, l'authentification se fait contre sa propre table d'acteurs, la trace persistante s'inscrit chez elle, et le retour des opérations passe par elle.

Ce qui rend ce cap fondateur : il permet d'éprouver intégralement le modèle — endpoints, Contracts, Leases, Flows, sécurité formelle par contexte, idempotence, gouvernance de la trace — sans introduire la coordination inter-instances. La cohérence est locale, la correction est observable, les invariants sont vérifiables au sein d'un seul système.

C'est le cap actuel. Le serveur de référence, son protocole gelé en V0-final, son durcissement V0.1, son application pilote, tout cela tient à l'horizon d'une instance unique. Les questions qui se posent à ce niveau sont celles de la fidélité au modèle, de la robustesse de l'implémentation, et de l'exploitabilité par un opérateur réel.

Le cap d'instance dédiée n'est pas un brouillon avant les caps suivants. C'est une réponse complète à un type de besoin : un domaine bien circonscrit, un cas d'usage maîtrisable, des acteurs identifiés, une autorité technique claire. Beaucoup de déploiements n'ont pas besoin d'aller au-delà.

Cap 2 — Le multi-nœuds

Plusieurs instances StrateFluxDistr coopèrent pour servir un cas d'usage dont l'échelle, la disponibilité ou la répartition géographique exigent plus d'un nœud. Les instances partagent un même cas d'usage, sous une même autorité technique, mais la cohérence ne peut plus être supposée locale : elle doit être construite.

Ce cap introduit des questions absentes du précédent. Comment une inscription faite sur un nœud devient-elle visible sur les autres ? Quels sont les invariants préservés à travers les nœuds, et lesquels sont relâchés au profit de la disponibilité ? L'idempotence reste-t-elle globale ou devient-elle locale au nœud ? Comment se résout un conflit d'inscription entre deux nœuds qui ont reçu la même clé en parallèle ? Quelle est la stratégie face à un nœud injoignable temporairement ?

Aucune de ces questions n'a de réponse évidente. Chacune ouvre des arbitrages explicites entre cohérence forte, cohérence à terme, partition tolérante, et coordination synchrone. Le multi-nœuds n'est pas un simple agrandissement de l'instance dédiée — il en bouscule certains invariants implicites et exige de les reposer formellement.

Ce cap reste explicitement hors V0. Il fera l'objet d'un cycle de gouvernance dédié, conduit après que l'application pilote du cap 1 aura fourni les retours d'usage qui permettront d'arbitrer ces questions sur des bases empiriques plutôt que théoriques.

Cap 3 — La fédération

Plusieurs domaines indépendants, chacun avec ses instances, ses acteurs, ses Contracts, coopèrent en préservant leur autonomie. Il ne s'agit plus de coordonner les nœuds d'un même cas d'usage, mais de faire dialoguer des cas d'usage distincts qui ont chacun leur propre périmètre de confiance, leur propre table d'acteurs, leurs propres règles de sécurité.

Ce cap introduit la notion d'autorité distribuée. Aucun acteur central ne peut imposer ses décisions à tous les domaines. Chaque domaine reste maître de ses propres règles. Mais des dialogues croisés existent : un endpoint d'un domaine émet vers un endpoint d'un autre domaine, sous un Contract qui doit être reconnu de part et d'autre, avec des règles d'authentification et d'autorisation qui doivent s'articuler sans s'imposer.

Les questions qui se posent à ce niveau dépassent largement la technique. Comment deux domaines négocient-ils la reconnaissance mutuelle des Contracts ? Comment les preuves de sécurité (les SecurityEvidence) circulent-elles entre domaines sans compromettre la souveraineté de chacun ? Comment la trace persistante d'un Lease inter-domaine s'inscrit-elle, et chez qui ? Comment se résolvent les divergences quand les règles de sécurité d'un domaine entrent en conflit avec celles d'un autre ?

La fédération est posée comme horizon, pas comme objectif court-terme. Elle est cohérente avec la posture méthodologique de Stratide — un régime où la cohérence se construit par articulation contextuelle plutôt que par centralisation autoritaire — mais elle exige une maturité du protocole et une expérience opérationnelle qui ne peuvent venir que des deux caps précédents stabilisés.

Pour explorer les composants concrets : spécification protocolaire, serveur de référence V0.1, sécurité formelle par contexte.