Options de déploiement

Avant-propos

Les articles précédents ont posé le socle dans sa structure interne — strates fonctionnelles, atomes, entités, propagation inscrivante. Le présent texte traite d'une question distincte : comment ce socle, dont la dynamique interne est posée, peut-il être effectivement déployé ? Combien de processus, quelle articulation entre eux, par quels canaux d'échange ?

Quatre topologies typées sont admissibles. Elles ne sont pas concurrentes : elles forment un continuum. Du monolithe in-process, où toutes les strates fonctionnelles cohabitent dans un seul processus, jusqu'à la fédération multi-nœud, où chaque instance porte sa propre boucle d'inscription, le passage d'une option à la suivante consiste à séparer ce qui était articulé par appel de fonction, et à le réarticuler par sérialisation explicite.

Toutes ces topologies préservent les invariants posés dans les articles précédents — non-mutation du sink, idempotence, lisibilité opérante. C'est même ce qui les rend admissibles. La mobilité du régime stratifié n'est pas une option offerte au socle : c'est une propriété qui le caractérise.

Sept sections. La première pose le critère qui sépare une option d'une autre. Les quatre suivantes parcourent les quatre options par ordre croissant de séparation. La sixième présente la matrice de comparaison rapidité / cohérence / duplication. La septième conclut sur la mobilité comme propriété constitutive du régime.

Section 1 — Le critère de tranchée

Avant de décrire les quatre options, il faut préciser ce qui les sépare. Le critère qui distingue une topologie d'une autre n'est pas le nombre de processus ni la nature du transport. Ce critère est l'articulation des strates fonctionnelles.

Cette précision compte. Beaucoup de typologies de déploiement classent les architectures par couche réseau — TCP, HTTP, gRPC, message queue —, ou par modèle de communication — synchrone, asynchrone, pub/sub. Stratide Flux ne se classe pas selon ces axes. Une topologie A peut utiliser HTTP et une topologie B utiliser gRPC sans qu'on les distingue : ce qui les sépare, c'est quelles strates fonctionnelles cohabitent dans le même processus.

Les quatre strates fonctionnelles du socle — support, traitement, coordination, exposition — peuvent être regroupées de quatre manières typées. Soit toutes les quatre cohabitent dans un seul processus. Soit le support est isolé, les trois autres restant ensemble. Soit chaque strate fonctionnelle a son propre processus. Soit chaque instance déployée est une boucle complète qui réplique l'ensemble. Ces quatre regroupements définissent les quatre options A, B, C, D.

Cette précision a une conséquence pratique forte : choisir une topologie pour un déploiement Stratide Flux ne se fait pas en termes de protocole réseau. Cela se fait en termes d'articulation entre les strates fonctionnelles. Le protocole, lui, est une décision qui vient ensuite, à l'intérieur de chaque option.

Section 2 — Option A : monolithe in-process

Dans l'option A, les quatre strates fonctionnelles du socle cohabitent dans un seul processus. Aucune sérialisation n'intervient entre les strates : leur articulation se fait par appel de fonction, dans la mémoire du même processus. Cette topologie est la plus cohésive, et celle qui offre les latences les plus faibles.

L'option A est la topologie de référence pour les déploiements à enjeu faible ou moyen, où la simplicité opérationnelle prime sur la disponibilité. C'est aussi la topologie naturelle pour le développement, le test, et l'intégration continue. Aucune décision réseau n'est requise ; aucune sérialisation n'est exposée. Tout le socle est manipulé à travers une seule API d'usage.

L'option A préserve trivialement tous les invariants du modèle. La non-mutation du sink, l'idempotence, la lisibilité opérante des strates — toutes ces propriétés tiennent dans la mémoire d'un seul processus.

Section 3 — Option B : matière séparée

Dans l'option B, le support — qui tient la matière du régime — est extrait du processus principal et déployé séparément. Les trois autres strates fonctionnelles — traitement, coordination, exposition — restent ensemble dans un second processus. L'articulation entre le support isolé et le reste se fait par sérialisation explicite : les inscriptions sont sérialisées au moment de leur dépôt et désérialisées au moment de leur lecture.

L'option B introduit une première sérialisation. Cette sérialisation porte sur les identifiants d'occurrences et sur leurs payloads typés — ce sont les seuls objets qui transitent entre le service et son support. Aucun état partagé en mémoire, aucune référence directe : le service obtient ses inscriptions par lecture du support, et y dépose ses inscriptions par sérialisation.

Cette topologie offre deux avantages structurels. Le support peut être redémarré, sauvegardé, voire remplacé indépendamment du processus de service. Et plusieurs processus de service peuvent partager le même support, ce qui permet par exemple d'avoir une exposition principale et une exposition d'audit sur la même matière inscrite, sans dupliquer le contenu.

Les invariants restent préservés. La non-mutation du sink reste vraie — le support n'écrase rien. L'idempotence reste vraie — la clé d'idempotence est portée dans la sérialisation. La lisibilité opérante des strates reste vraie — chacune a son rôle et ses opérations propres, séparées par la frontière de sérialisation.

Section 4 — Option C : par strate fonctionnelle

Dans l'option C, chacune des quatre strates fonctionnelles est déployée dans son propre processus. Cette topologie applique le critère de tranchée à son extrémité naturelle : aucune strate ne cohabite avec une autre. Chaque articulation entre strates voisines passe par sérialisation.

L'option C est la première topologie où le passage à l'échelle horizontale devient possible sans contrainte forte. Plusieurs façades d'exposition peuvent coexister sans interférer. Plusieurs workers de traitement peuvent travailler en parallèle, gardés par les clés d'idempotence qui empêchent les collisions. Le support peut être répliqué en lecture pour absorber un volume de requêtes important.

La coordination, en revanche, reste unique. C'est le point qui garantit l'unicité des décisions de politique — admission d'un Contract, applicabilité d'une règle d'idempotence, arbitrage d'une collision. Cette unicité n'est pas un défaut de l'architecture : c'est ce qui rend la cohérence possible. La coordination peut elle-même être rendue tolérante aux pannes par réplication active, mais sa fonction de point de décision reste centralisée.

Les invariants restent préservés. La non-mutation du sink est garantie par la chaîne sérialisée — aucune écriture concurrente n'est possible parce que l'écriture passe par le support unique. L'idempotence est garantie par la coordination, qui voit toutes les demandes avant qu'elles n'atteignent le traitement. La lisibilité opérante est même renforcée : chaque strate est observable indépendamment des autres, parce qu'elle vit dans son propre processus.

Section 5 — Option D : distribué multi-nœud

Dans l'option D, chaque instance du modèle correspond à un nœud autonome qui porte sa propre boucle complète des quatre strates. Plusieurs nœuds coexistent ; chacun inscrit dans son propre support. La cohérence inter-nœud est maintenue par réplication d'inscriptions — non pas par un état partagé, mais par diffusion des occurrences inscrites.

L'option D est la topologie qui pousse le critère de tranchée à son extrémité opposée du monolithe. Là où l'option A maximise la cohésion, l'option D maximise la distribution. Chaque nœud est une instance autonome avec son propre identifiant ; les occurrences qu'il inscrit portent ce préfixe d'instance et sont distinctes de celles d'un autre nœud, même si elles partagent la même notion et le même contexte.

Cette propriété — l'inscription préfixée par l'instance — est ce qui rend la réplication possible sans risque de collision. Quand un nœud diffuse une occurrence qu'il a inscrite à un autre nœud, l'occurrence reçue conserve le préfixe du nœud émetteur. Le nœud récepteur ne peut pas l'écraser, parce que son identifiant universel est différent de tout ce que le nœud récepteur a lui-même inscrit.

La cohérence est éventuelle et non pas forte. À un instant donné, deux nœuds peuvent avoir une vision légèrement différente de l'ensemble des occurrences inscrites — celles qu'un nœud a fraîchement inscrites n'ont pas encore atteint l'autre. Cette propriété est inhérente au déploiement distribué : on ne peut pas avoir simultanément une cohérence forte et une disponibilité maximale en cas de partition réseau.

Les invariants critiques restent préservés. La non-mutation du sink est vraie sur chaque nœud individuellement, et la réplication n'écrase rien. L'idempotence est garantie par la clé d'idempotence portée dans chaque inscription répliquée. La lisibilité opérante des strates reste vraie au niveau de chaque nœud.

Section 6 — Matrice rapidité × cohérence × duplication

Les quatre options forment un continuum, et chaque position de ce continuum a un profil propre sur trois axes principaux : la rapidité de réaction du socle, la cohérence de ses inscriptions, et la duplication possible de ses composants.

Lire cette matrice ne donne pas une réponse universelle au choix d'option. Elle expose des compromis. Plus on s'éloigne du monolithe, plus on gagne en disponibilité et en passage à l'échelle, mais plus on paie en complexité opérationnelle et, à partir de l'option D, en cohérence forte. Le choix d'une option pour un déploiement donné dépend des compromis acceptables.

Une remarque importante : aucune option n'est dégradée. Le monolithe in-process ne fait pas de compromis sur les invariants ; il fait un compromis sur la disponibilité et sur le passage à l'échelle. Le distribué multi-nœud ne fait pas de compromis sur la lisibilité opérante ; il fait un compromis sur la cohérence forte au profit de la disponibilité. Les invariants structurels du modèle — non-mutation, idempotence, lisibilité — sont préservés à toute trajectoire.

Section 7 — Conclusion : la mobilité comme propriété constitutive

Quatre options de déploiement ne forment pas une liste de variantes parmi lesquelles il faudrait choisir une fois pour toutes. Elles forment un continuum, qui exprime une propriété fondamentale du socle : sa mobilité. Le régime stratifié de Stratide Flux n'est pas figé dans une topologie unique ; il peut traverser ce continuum selon les contraintes qu'on lui pose, sans perdre son identité.

Cette mobilité est une propriété constitutive, pas une option offerte au socle. Elle découle directement de la qualification du socle comme régime stratifié, telle qu'elle a été posée dans Le socle stratifié. Un régime n'est pas un assemblage figé d'éléments : c'est une organisation interne qui peut se déployer sous plusieurs topologies pour autant que ses conditions de traduction restent satisfaites. Les quatre options A, B, C, D sont quatre actualisations distinctes de cette mobilité.

Le passage d'une option à une autre n'est pas une refonte. Il consiste à séparer ce qui était articulé en mémoire et à le réarticuler par sérialisation, ou inversement à fusionner deux processus séparés dans une même mémoire. Ces transformations préservent l'ensemble des invariants — c'est ce qui les rend possibles. Aucune option ne demande à reconcevoir le modèle.

Cette propriété a une conséquence pratique importante : un déploiement Stratide Flux peut évoluer en topologie sans reconcevoir son socle. Un système qui démarre comme monolithe in-process pour les besoins du développement peut être recompilé en mode matière séparée pour la production initiale, puis évoluer vers une topologie par strate quand le volume l'exige, et finalement passer en multi-nœud quand la disponibilité devient critique. Aucune de ces transitions ne demande de réécrire la logique métier ; elles modifient seulement l'articulation des strates fonctionnelles.

Cette section Implémentation du site présente le socle Stratide Flux dans son intégralité conceptuelle. Elle a parcouru la stratification interne, les atomes premiers, le catalogue des entités, la dynamique de traversée, et les options de déploiement. Pour qui veut entrer dans le détail technique de la matérialisation Rust du noyau, l'article long de matérialisation reste la référence. Pour qui s'intéresse à la projection du socle sur un protocole gRPC pour usage distribué, la section Distribution du site déploie ce volet.