Stratide Flux

Section 1 — Geste fondateur

1.1 Ce que cet article propose

Cet article présente Stratide Flux comme architecture pour les systèmes d'information de gestion. Il pose les concepts qui la structurent, articule leur cohérence d'ensemble, et fournit le cadre conceptuel suffisant à l'implémentation d'un noyau opérant.

Stratide Flux est une architecture-type : un régime articulé de concepts, de relations et de régularités, qui décrit comment un système d'information peut être organisé pour rester lisible, opérant et durable. Elle se distingue d'une technologie particulière, d'un produit logiciel ou d'un cadre de développement habituel par sa nature : c'est un cadre conceptuel relationnel, qui prescrit la cohérence d'ensemble plutôt que les choix techniques d'incarnation.

L'article s'adresse simultanément à deux publics. Aux architectes et théoriciens des systèmes d'information, il propose un cadre conceptuel cohérent et déployable, qui articule rigueur formelle et souplesse contextuelle. Aux développeurs et implémenteurs, il propose un référentiel pratique, qui identifie les modules-cibles, leurs responsabilités, leurs interfaces, et les conditions de leur articulation.

L'article est un document de référence à portée délimitée. Il pose suffisamment pour qu'un noyau puisse être construit, et il laisse aux projets qui l'adopteront le soin de spécifier les choix technologiques, les sémantiques métier et les options opérationnelles que leur contexte requiert. Ce qui dépasse cette portée relève des incarnations particulières et fait l'objet d'autres documents.

1.2 Trois niveaux articulés

Stratide Flux s'inscrit dans une stratification théorique plus large, qu'il importe de poser explicitement avant d'aborder son contenu propre.

Le premier niveau est celui de la théorie générale. L'ouvrage La structure lisible — Essai de théorie générale du mouvement contextuel pose les concepts fondamentaux : occurrence contextuelle, mouvement, stabilité directionnelle, champ, centre, régime, lisibilité. Cette théorie a une portée universelle : elle énonce les conditions générales d'apparition, de stabilisation, de transformation et de stratification des structures dans leur contexte, sans se limiter à un domaine particulier d'application.

Le deuxième niveau est celui de la théorie appliquée. La théorie Stratide spécialise la théorie générale au domaine de la stratification opérante. Elle pose les concepts qui caractérisent les régimes stratifiés : comment les couches s'articulent, comment elles se transforment, comment elles préservent leur cohérence à travers les évolutions contextuelles. Stratide est la discipline qui étudie le régime des strates.

Le troisième niveau est celui de l'architecture incarnée. Stratide Flux est une incarnation de Stratide dans le domaine particulier des systèmes d'information de gestion. Elle pose une architecture-type concrète : un ensemble articulé de Substrats, de Providers, d'Endpoints, de Datasets, de Contracts, de Leases, de Flows, organisés en un régime cohérent qui peut être analysé, construit, fait évoluer.

Ces trois niveaux sont distincts et articulés. La structure lisible fournit le socle conceptuel le plus général. Stratide spécialise ce socle à la stratification. Stratide Flux incarne Stratide dans le numérique. Le présent article concerne le troisième niveau, et il mobilise les deux premiers chaque fois que la cohérence l'exige.

1.3 La posture méthodologique

Stratide Flux adopte un régime énonciatif contextuel. Cette posture méthodologique mérite d'être posée explicitement, parce qu'elle structure l'ensemble de l'article et qu'elle distingue Stratide Flux des approches axiomatiques classiques.

Un système axiomatique pose des propositions premières dont tout dérive par déduction. Cette posture a une vertu de complétude apparente : tout ce qui est admissible y est posé d'emblée, et tout ce qui reste hors d'atteinte des axiomes est implicitement exclu. Cette vertu est aussi une limite. Un axiome est une clôture : il fixe l'univers du discours et restreint d'emblée l'espace des éventualités admissibles.

Stratide Flux adopte une posture distincte. La théorie qui la sous-tend pose le contexte comme horizon constitutif de toute manifestation. Une éventualité qui paraît hors de propos dans un contexte peut redevenir pertinente dans un autre. Une structure qui semble inactive peut être en dormance et se réveiller sous des conditions appropriées. Une règle qui tient par défaut peut être suspendue par un contexte qui la dépasse. Toute fermeture reste contextuellement réversible.

L'article adopte donc le régime énonciatif suivant. Les définitions introduisent du vocabulaire en laissant l'univers du discours ouvert : elles nomment des objets et des relations en préservant leur capacité à évoluer contextuellement. Les relations par défaut structurent les entités dans le contexte ordinaire d'usage : elles énoncent ce qui tient typiquement, en réservant la possibilité de variations contextuelles explicites. Les régularités contextuelles énoncent des comportements typiques susceptibles de suspension : leur réfutation dans un contexte particulier confirme la nature contextuelle du modèle et l'enrichit. Les états de dormance complètent les états terminaux : une entité préservée peut dormir et se réveiller selon les conditions du contexte.

Cette posture est une caractéristique structurelle qui reflète la nature même des systèmes d'information opérants. Un régime informatique vivant est un système qui évolue, dont les contextes changent, dont les besoins se transforment, et dont la cohérence se maintient par adaptation contextuelle plutôt que par fixité axiomatique. La posture énonciative contextuelle articule cette nature.

1.4 Le contexte comme horizon constitutif

Une décision méthodologique fondamentale traverse l'ensemble de l'article : le contexte est l'horizon dans lequel toutes les autres primitives apparaissent. Il occupe une position singulière, antérieure à toute autre primitive du modèle.

Définir, dans Stratide Flux, c'est définir-dans-un-contexte. Une relation tient-dans-un-contexte. Une dormance se réveille par-un-contexte. Une transformation se produit selon-un-contexte. Le contexte est ce dans quoi le modèle se déploie, et qui le rend opérant.

Cette décision a une conséquence pratique majeure pour l'implémentation. Toute entité du système se comprend relativement au contexte dans lequel elle se manifeste. Un dataset a un sens contextuel : il prend sens dans le contexte d'inscription qui le rend signifiant, dans le contexte d'admissibilité qui le rend opérant, dans le contexte de mobilisation qui le fait participer à un flux. Un endpoint est un centre stabilisé dans un contexte qui rend cette stabilisation possible. Un flow est un mouvement contextuel qui produit la stabilité de ce qu'il déplace.

Cette caractéristique distingue Stratide Flux des architectures qui posent un univers du discours fixe et qui traitent ensuite le contexte comme une variable secondaire. Dans Stratide Flux, le contexte vient en premier. Tout ce qui est ensuite posé l'est relativement à un contexte de manifestation. La théorie qui sous-tend l'architecture pose explicitement que l'occurrence contextuelle, c'est-à-dire le couple ordonné notion-contexte, est l'unité minimale de toute manifestation observable.

1.5 Périmètre de l'article

L'article a un périmètre délimité, dont la clarté contribue à son utilité. Quatre caractérisations positives en cernent les contours.

L'article propose un cadre conceptuel neutre relativement aux choix techniques. Les concepts qu'il pose peuvent être incarnés en Rust, en TypeScript, en Python, en Java, en Go, ou dans toute combinaison de technologies appropriée au contexte d'implémentation. Les Providers et les Substrats peuvent être relationnels, documentaires, événementiels, fichiers, ou hybrides. L'article fournit le cadre conceptuel ; les choix techniques relèvent du contexte de mise en œuvre, et chaque équipe les fixera selon ses propres contraintes.

L'article décrit une architecture-type, distincte des produits logiciels qui l'incarnent. Un produit logiciel particulier — par exemple un système de gestion des commandes — peut incarner Stratide Flux, et l'incarnation prendra alors son propre nom et son propre périmètre fonctionnel. Stratide Flux fournit le cadre dans lequel les produits concrets pourront être conçus et construits ; les produits eux-mêmes feront l'objet de leurs propres documents.

L'article pose un noyau conceptuel suffisant pour démarrer une implémentation, plutôt qu'un traité exhaustif de tous les patterns possibles. Il identifie ce qui est nécessaire à la cohérence d'ensemble, et laisse ouvertes les extensions qui seront pertinentes selon les contextes effectifs d'application. Cette ouverture est cohérente avec la posture énonciative générale : un article qui prétendrait épuiser tous les cas serait un article axiomatique, et Stratide Flux adopte explicitement la posture inverse.

L'article mobilise les concepts de La structure lisible et de Stratide en les convoquant plutôt qu'en les redémontrant. Le lecteur qui souhaite approfondir les fondements théoriques est invité à se reporter à ces ouvrages. L'article suppose une familiarité minimale avec les notions de mouvement, de stabilité, de centre, de champ, de régime, de lisibilité ; il les rappelle là où c'est utile à la cohérence de l'exposé, et il les complète de définitions opérantes spécifiques au domaine architectural.

1.6 L'architecture des sections suivantes

L'article se déploie en cinq sections supplémentaires, chacune avec une fonction spécifique dans la construction du cadre architectural.

La Section 2 pose les atomes et relations primitives. Elle introduit les notions et les contextes comme atomes premiers, l'occurrence comme leur appariement, l'inscription comme relation primitive de sens, le mouvement comme relation primitive originaire, et la stabilité directionnelle comme caractérisation des centres. Cette section fournit le vocabulaire fondamental que les sections suivantes mobiliseront.

La Section 3 déploie la stratification opérante. Elle présente les Substrats comme infrastructures des notions, les Providers comme infrastructures de l'inscription, les Datasets comme structures de notions identifiées, les Endpoints comme centres stabilisés, les Contracts comme datasets orientés, les Leases comme manifestations éphémères des contracts, les Flows comme manifestations du mouvement, les Projects comme centres d'autorité locale, et le ContractApi comme centre d'autorité globale. Cette section fournit l'inventaire des objets architecturaux qu'un implémenteur rencontrera.

La Section 4 articule le régime architectural. Elle montre comment les éléments de la stratification composent un régime cohérent au sens du socle théorique : succession des centres, dormance et réveil, asymétrie des voies de circulation, frontière technique. Cette section donne au cadre architectural sa cohérence d'ensemble, en mobilisant explicitement les régularités globales de la théorie.

La Section 5 présente le cadre d'implémentation. Elle identifie les modules-cibles du noyau, leurs interfaces principales, les contrats minimaux à supporter, les états observables, et explicite les responsabilités que le noyau délègue à ses utilisateurs. Cette section fournit le pont entre le cadre conceptuel et la pratique de construction.

La Section 6 articule la posture finale. Elle récapitule ce que l'article a posé, ce qu'il a délimité, son articulation avec les autres niveaux théoriques, et la posture du système qu'il décrit. Cette section ferme l'article en réaffirmant son périmètre et en ouvrant aux directions de développement ultérieures.

1.7 Posture de lecture

L'article peut être lu de deux manières complémentaires.

Une lecture linéaire, du début à la fin, suit la progression de la fondation théorique vers le cadre d'implémentation. Cette lecture convient au lecteur qui découvre Stratide Flux et qui souhaite en saisir la cohérence d'ensemble avant d'en mobiliser les éléments particuliers. Elle requiert un engagement de lecture continue, et elle donne accès à l'articulation systémique du cadre.

Une lecture consultative, par sections selon les besoins, traite l'article comme un référentiel. Cette lecture convient au lecteur qui implémente et qui cherche à retrouver un concept particulier, une définition, une régularité. Les sections sont autonomes dans la mesure où chacune s'appuie explicitement sur les précédentes par références, en mobilisant les concepts déjà posés plutôt qu'en les redéfinissant. La consultation reste possible pour qui aura déjà parcouru les sections fondatrices au moins une fois.

La progression conceptuelle du présent article suit la logique méthodologique posée par la théorie qui le sous-tend : mouvement → cadrage → stabilisation → compréhension → rupture → re-cadrage → régime. Chaque étape s'appuie sur les précédentes, et leur articulation cumulative produit la cohérence d'ensemble. La construction d'un noyau Stratide Flux suivra la même logique.

L'article peut maintenant aborder son contenu propre. La Section 2 ouvre la fondation conceptuelle, avec les atomes et les relations primitives.

Section 2 — Atomes et relations primitives

Cette section pose les fondations conceptuelles que mobilisent toutes les sections suivantes. Elle introduit progressivement les atomes premiers (notions, contextes), leur appariement (occurrences), les relations primitives qui les structurent (inscription, mouvement), et les notions dérivées qui en émergent (stabilité directionnelle, centre, champ, lisibilité).

La progression suit l'ordre génétique de la théorie : on part de ce qui est posé sans dérivation (les atomes), on introduit ce qui les met en relation (les relations primitives), puis on caractérise ce qui en résulte (les structures stables et les centres). Chaque concept reçoit une définition opérante, articulée à son rôle dans l'architecture, et complétée d'exemples concrets dans le domaine des systèmes d'information.

2.1 Notations en présence

L'article utilise un nombre limité de notations formelles, posées ici pour une référence ultérieure aisée.

L'ensemble des notions se note 𝓝. L'ensemble des contextes se note 𝓚. L'ensemble des occurrences se note Ω. La relation primitive d'inscription se note ▶. La relation primitive de mouvement se note ◁. Le domaine signifiant se note Ω^s. La stabilité directionnelle relative à une direction D se note ▲_D. Le champ d'une occurrence σ relativement à une direction D se note ◇_D(σ). La rupture relativement à une direction se note ▽_D. La succession relativement à une direction se note ↷_D. Le centre stabilisé se caractérise par la condition ◇_D(σ) ≠ ∅.

Ces notations apparaissent dans l'ouvrage La structure lisible avec leurs justifications complètes. Le présent article les mobilise sans les redémontrer, et il les complète des notations spécifiques au domaine architectural là où le besoin se présente.

2.2 Atomes premiers : notions et contextes

Définition D1 — Notions et contextes

La théorie pose deux ensembles atomiques : l'ensemble des notions 𝓝 et l'ensemble des contextes 𝓚. Ces ensembles sont premiers : leurs éléments sont posés directement plutôt que construits par composition d'autres ensembles, et ils servent de point de départ à toute la construction architecturale.

Les ensembles 𝓝 et 𝓚 sont disjoints : leur intersection est vide, et chaque élément appartient à exactement l'un des deux. Une notion et un contexte sont des entités de natures différentes, qui jouent des rôles distincts dans l'architecture.

Caractérisation des notions

Une notion est ce qui peut être pensé, désigné, posé comme objet de discours. Elle a une consistance qui lui est propre : elle peut être nommée, identifiée, mise en relation avec d'autres notions, indépendamment d'un contexte particulier de manifestation.

Dans le domaine des systèmes d'information de gestion, les notions typiques sont les entités métier au sens conceptuel : un produit en tant que catégorie, une commande en tant que type d'événement, un client en tant que rôle, un prix en tant que grandeur. Ces notions ont une existence conceptuelle indépendamment du contexte particulier dans lequel elles se manifestent.

Une notion seule, prise hors de tout contexte, demeure une abstraction : elle a la potentialité d'être manifestée, et sa manifestation effective requiert un contexte. La notion seule n'a donc pas le statut d'occurrence (voir 2.3) : elle attend qu'un contexte la rende manifestable.

Caractérisation des contextes

Un contexte est ce qui rend possible la manifestation d'une notion. Il fournit l'horizon dans lequel une notion peut apparaître, être observée, prendre sens, entrer en relation avec d'autres entités. Le contexte est ce dans quoi quelque chose se produit.

Dans le domaine des systèmes d'information de gestion, les contextes typiques sont les environnements opérationnels : un environnement de production, un environnement de test, un tenant client particulier, une session utilisateur, une transaction en cours. Le contexte fournit les conditions dans lesquelles une notion peut se manifester de façon opérante.

Un contexte seul, sans aucune notion qui s'y manifeste, demeure vide au sens architectural : il est un horizon disponible, et il attend qu'une notion s'y manifeste pour produire une occurrence observable. Le contexte seul n'a donc pas non plus le statut d'occurrence.

Statut philosophique

Le choix de poser 𝓝 et 𝓚 comme atomes premiers est une décision philosophique fondamentale. Stratide Flux adopte une ontologie où la notion et le contexte sont co-fondateurs : ils s'appellent l'un l'autre dès le départ, et leur articulation est constitutive de toute manifestation.

Cette décision distingue Stratide Flux des architectures qui posent le contexte comme une variable secondaire, ajoutée après coup à un univers de notions déjà fixé. Dans ces architectures, le contexte est traité comme une propriété ou une étiquette des objets. Dans Stratide Flux, le contexte est constitutif : toute manifestation suppose simultanément une notion et un contexte qui la rend manifestable.

2.3 L'occurrence comme couple

Définition D2 — Occurrence

Une occurrence est un couple ordonné (n, k) où n ∈ 𝓝 et k ∈ 𝓚. L'ensemble des occurrences se note Ω = 𝓝 × 𝓚.

Justification

Une notion n et un contexte k, considérés isolément, sont des entités atomiques avec leur consistance propre. Leur appariement sous forme de couple (n, k) crée une entité d'un nouveau genre : l'occurrence. L'occurrence est l'unité minimale de manifestation observable dans l'architecture.

Ce passage du couple à l'occurrence n'ajoute aucun ingrédient supplémentaire au-delà de la notion et du contexte eux-mêmes. L'occurrence est exactement le couple ordonné, et toute son information se trouve dans ses deux composantes. La nouveauté est relationnelle : c'est le fait qu'une notion soit dans un contexte qui constitue l'occurrence comme entité observable.

Implications architecturales

Toute manifestation observable dans Stratide Flux est une occurrence. Un dataset effectif (par opposition à un dataset abstrait) est une occurrence : il est une notion-de-dataset qui se manifeste dans un contexte d'inscription. Un endpoint actif est une occurrence : il est une notion-d'endpoint qui se manifeste dans un contexte d'environnement opérationnel. Un flow qui transite est une occurrence : il est une notion-de-flow qui se manifeste dans un contexte d'exécution.

Cette caractéristique a une conséquence pratique majeure pour l'implémentation. Les structures de données de Stratide Flux portent toujours simultanément l'information de la notion et celle du contexte. Toute entité observable du système se comprend relativement au contexte qui la rend manifestable, et toute entité se manifeste avec une notion qui l'identifie.

Le seuil d'observation

L'occurrence est le seuil d'observation du système. En deçà du couple notion-contexte, on dispose d'atomes potentiels (une notion, un contexte) sans manifestation observable. À partir du couple, on entre dans le domaine où l'observation devient possible : l'occurrence est ce qui peut être tracé, journalisé, mesuré, comparé.

2.4 L'inscription comme relation primitive de sens

Définition D3 — Inscription

L'inscription est une relation primitive ▶ ⊆ 𝓝 × 𝓚. Elle relie une notion à un contexte selon la modalité du prendre place : la notion s'inscrit dans le contexte, c'est-à-dire qu'elle y prend place de façon signifiante.

Justification

Toute occurrence est un couple notion-contexte. L'ensemble Ω rassemble formellement tous les couples possibles. Parmi ces couples, certains sont signifiants : la notion y prend place de façon stable, observable, mobilisable. C'est la fonction de l'inscription que de distinguer ces couples-là.

Quand (n, k) ∈ ▶, on dit que la notion n s'inscrit dans le contexte k. La notion prend alors place dans le contexte de façon stable, observable, mobilisable.

Domaine signifiant

L'ensemble des occurrences signifiantes se note Ω^s :

Ω^s = {(n, k) ∈ Ω | (n, k) ∈ ▶}

Ω^s est un sous-ensemble de Ω : il rassemble les couples notion-contexte effectivement inscrits, c'est-à-dire les manifestations qui produisent du sens dans leur contexte.

Implications architecturales

L'inscription est l'opération qui rend une notion manifeste dans un contexte. Elle correspond, dans le domaine des systèmes d'information, à ce que les Providers réalisent : un Provider est précisément une infrastructure qui matérialise l'inscription dans un Substrat. Quand un dataset s'inscrit dans un Substrat via un Provider, il devient une occurrence signifiante dans le contexte de ce Substrat.

L'inscription a le statut de relation primitive : elle est posée directement plutôt que dérivée d'opérations plus simples. La théorie générale justifie ce choix en montrant que la signifiance contextuelle se pose comme une relation irréductible. Stratide Flux hérite de cette posture : l'inscription est une primitive architecturale, et les Providers sont les entités qui l'incarnent.

2.5 Le mouvement comme relation primitive originaire

Définition D4 — Mouvement

Le mouvement est une relation primitive ◁ entre occurrences. Quand σ₁ ◁ σ₂, on dit que l'occurrence σ₁ se meut vers l'occurrence σ₂.

Justification

Le mouvement occupe une position singulière dans la théorie : il est la relation primitive originaire, celle dont les autres structures dérivent par cadrages successifs. Cette posture mérite d'être posée explicitement, parce qu'elle inverse l'ordre classique des architectures qui posent d'abord des objets stables et décrivent ensuite leurs transformations.

Stratide Flux adopte une ontologie où le mouvement est posé directement comme matrice première. Les structures stables que le système observe — les datasets persistants, les endpoints durables, les contracts pérennes — sont des résultats de cadrages appliqués à un mouvement plus fondamental. Elles émergent comme des stabilisations directionnelles, et elles peuvent à tout moment se révéler comme des phases d'un mouvement plus large qui les dépasse.

Implications architecturales

Le mouvement, dans Stratide Flux, est donc une relation primitive constitutive, et les flows de l'architecture en sont les manifestations contextuelles. Les flows ont le statut d'entités primaires : ils sont des occurrences à part entière, dotées de leur propre consistance, et ils participent de la matrice première du système.

Cette caractéristique a une conséquence pratique pour l'implémentation. Les flows sont traités comme des manifestations primaires, dotés du statut d'objet à part entière : ils ont leurs propriétés, leurs traces, leur cycle de vie. Le code qui implémente Stratide Flux accorde aux flows un statut d'entité observable, avec une identité propre, plutôt que de les réduire à de simples appels de fonction.

Statut philosophique

Le choix de poser le mouvement comme primitive originaire reflète une posture philosophique précise : Stratide Flux adopte une ontologie dynamique, où le monde se décrit fondamentalement par des mouvements et où les objets stables sont des cadrages relatifs de ces mouvements. Cette posture s'oppose aux ontologies statiques où le monde se décrit fondamentalement par des objets et où les changements sont des modifications appliquées à ces objets.

Cette posture sera explicitée plus largement en Section 4 (Régime architectural), quand sera discutée la composition d'ensemble du régime et les régularités globales que la théorie pose.

2.6 La stabilité directionnelle

Définition D5 — Stabilité directionnelle

Une occurrence σ est stable selon une direction D quand elle se maintient relativement à cette direction au cours du mouvement. La stabilité directionnelle se note ▲_D, et la propriété s'écrit σ ∈ ▲_D.

Justification

Le mouvement, posé comme primitive originaire, déplace, transforme, traverse. Parmi les occurrences soumises au mouvement, certaines présentent un comportement particulier : elles se maintiennent relativement à des directions données. Elles présentent une stabilité directionnelle, et c'est cette propriété qui les distingue.

La direction D est ici à comprendre au sens large : elle peut être une dimension temporelle (la stabilité dans le temps), une dimension fonctionnelle (la stabilité dans une fonction donnée), une dimension contextuelle (la stabilité à travers des contextes connexes). La théorie générale développe ces cas dans La structure lisible. Dans Stratide Flux, la direction D principale est typiquement la persistance opérationnelle : une stabilité qui permet à une occurrence d'être référencée, mobilisée, observée de façon répétée.

Implications architecturales

La stabilité directionnelle est ce qui distingue les objets durables de l'architecture (datasets persistants, endpoints, contracts) des manifestations éphémères (leases d'exécution, flows en transit). Les premiers sont des occurrences qui satisfont à ▲_D pour la direction de persistance opérationnelle ; les secondes sont des occurrences qui se manifestent dans une direction de mobilisation contextuelle plus fugitive.

Cette distinction est au cœur du fonctionnement de Stratide Flux. Les implémentations articulent clairement les deux régimes : un régime de persistance pour ce qui est stable directionnellement, et un régime de manifestation contextuelle pour ce qui se déploie dans le temps de l'exécution.

2.7 Centre et champ

Définition D6 — Centre stabilisé

Une occurrence σ est un centre stabilisé relativement à une direction D quand son champ relativement à D est non vide :

σ est un centre selon D ⟺ ◇_D(σ) ≠ ∅

Définition D7 — Champ d'une occurrence

Le champ ◇_D(σ) d'une occurrence σ relativement à une direction D est l'ensemble des occurrences qui se stabilisent relativement à σ selon cette direction. Le champ rassemble ce qui dépend de σ, ce qui s'organise autour de σ, ce qui s'inscrit dans son rayon de stabilité directionnelle.

Justification

Une occurrence stable directionnellement (σ ∈ ▲_D) acquiert une fonction structurelle quand d'autres occurrences se stabilisent relativement à elle. Elle devient alors un point de référence pour ces autres occurrences, qui forment son champ.

Le couple centre-champ caractérise une organisation polarisée : un centre stable autour duquel s'organise un ensemble de manifestations qui dépendent de lui. Cette organisation polarisée est l'unité élémentaire de la stratification opérante.

Implications architecturales

Dans Stratide Flux, les endpoints sont les centres stabilisés par excellence. Un endpoint est une occurrence d'un type particulier qui satisfait simultanément trois conditions de lisibilité (voir 2.8). Autour de chaque endpoint s'organise un champ : les datasets qui s'y inscrivent, les contracts qui en partent ou y arrivent, les leases qui le mobilisent, les flows qui le traversent. Le champ d'un endpoint rassemble l'ensemble des occurrences qui dépendent de lui pour leur cohérence directionnelle.

D'autres entités architecturales tiennent aussi le rôle de centres, à des niveaux de stratification différents. Les Projects sont des centres d'autorité locale : ils stabilisent un ensemble d'endpoints qui dépendent d'eux pour leur gouvernance. Le ContractApi est un centre d'autorité globale : il stabilise l'ensemble des Projects qui dépendent de lui pour la cohérence des contracts inter-Projects. Cette articulation hiérarchique de centres se développe en Section 3.

2.8 La structure lisible comme centre maximalement lisible

Définition D8 — Lisibilité

Une occurrence σ est lisible relativement à une direction D quand elle satisfait simultanément trois conditions :

1. Sens : σ est une occurrence signifiante (σ ∈ Ω^s)
2. Atteignabilité : σ est accessible depuis le contexte d'usage par les voies disponibles
3. Compréhension : σ est interprétable de façon cohérente dans le contexte d'usage

Une occurrence lisible est par ailleurs un centre stabilisé selon D : elle satisfait également ◇_D(σ) ≠ ∅.

Justification

La lisibilité est le concept central de la théorie. Elle articule trois dimensions distinctes qui doivent être satisfaites simultanément pour qu'une occurrence joue pleinement son rôle dans le régime.

Le sens distingue les couples signifiants des couples formels : avec inscription, l'occurrence acquiert une portée architecturale ; sans inscription, elle reste une coïncidence formelle. L'atteignabilité distingue les occurrences accessibles des occurrences isolées : avec accès depuis le contexte d'usage, l'occurrence devient mobilisable ; sans accès, elle existe sans pouvoir participer aux flux. La compréhension distingue les occurrences interprétables des occurrences opaques : avec cohérence interprétative dans le contexte d'usage, l'occurrence devient utilisable ; sans cohérence, elle reste inutilisable même atteinte.

Une occurrence qui satisfait les trois conditions est pleinement lisible : elle a du sens, elle est atteignable, et elle se comprend de façon cohérente.

Implications architecturales

Les endpoints sont les occurrences maximalement lisibles dans Stratide Flux : ils satisfont au plus haut degré les trois conditions. Un endpoint est signifiant (il s'inscrit comme dataset orienté dans son substrat), atteignable (les voies de circulation permettent d'y accéder depuis les contextes d'usage), et compréhensible (sa structure et son rôle se documentent et se transmettent).

Un endpoint a le statut d'occurrence qui satisfait les trois conditions de la lisibilité, et il peut donc tenir le rôle de centre stabilisé dans le régime architectural. D'autres occurrences architecturales présentent une lisibilité partielle. Un Substrat est signifiant et atteignable, et sa compréhension passe par les Datasets qui s'y inscrivent. Un Provider est signifiant et compréhensible, et son atteignabilité passe par les Substrats qu'il sert. La lisibilité maximale est l'apanage des centres stabilisés que sont les endpoints.

La lisibilité comme objectif architectural

L'objectif central de Stratide Flux est de maintenir un régime de lisibilité maximale. Tout choix architectural dans ce cadre vise à préserver ou à améliorer la lisibilité du système : la signifiance des inscriptions, l'atteignabilité des centres, la compréhension des structures. Les régularités contextuelles que les sections suivantes poseront (asymétrie sortie/entrée, dormance et réveil, etc.) sont autant de moyens de préserver la lisibilité face aux évolutions du système.

2.9 Synthèse des concepts posés

Cette section a posé les fondations conceptuelles de Stratide Flux. Le tableau ci-dessous récapitule les éléments introduits et leur rôle architectural.

Ces concepts forment le vocabulaire fondamental que la Section 3 mobilisera pour déployer la stratification opérante de Stratide Flux. Chaque entité architecturale qui sera présentée — Substrat, Provider, Dataset, Endpoint, Contract, Lease, Flow, Project, ContractApi — recevra sa caractérisation en termes des concepts posés ici. La Section 3 ouvre cette caractérisation systématique.

Section 3 — Stratification opérante

Cette section déploie les neuf entités architecturales que Stratide Flux articule pour composer un système d'information opérant. Chaque entité reçoit une définition opérante en termes des concepts posés en Section 2, une caractérisation typologique, une articulation aux régularités contextuelles qui la structurent, et des exemples concrets dans le domaine des systèmes d'information de gestion.

La progression suit une stratification ascendante, des couches infrastructurelles vers les couches de gouvernance. Les Substrats et les Providers forment l'infrastructure matérielle de l'inscription. Les Datasets organisent les notions identifiées et versionnées. Les Endpoints sont les centres stabilisés du régime. Les Contracts spécifient les mouvements entre endpoints. Les Leases matérialisent les contracts dans des contextes d'exécution. Les Flows sont les manifestations primaires du mouvement. Les Projects stabilisent localement des ensembles d'endpoints et de contracts. Le ContractApi stabilise globalement l'ensemble des Projects.

Chaque niveau s'appuie sur les précédents. La compréhension d'un Endpoint mobilise celle des Datasets et des Providers ; la compréhension d'un Lease mobilise celle des Contracts et des Endpoints ; la compréhension d'un Project mobilise l'ensemble des niveaux qu'il gouverne. La progression est cumulative.

3.1 Substrats — l'infrastructure des notions

Définition D10 — Substrat

Un Substrat est une infrastructure matérielle qui porte les notions du système. Il est le support physique dans lequel les notions peuvent s'inscrire pour devenir des occurrences signifiantes.

Formellement, un Substrat est une occurrence (n_S, k_S) où n_S est une notion-de-substrat (une classe d'infrastructures partageant des propriétés communes) et k_S est un contexte d'instanciation particulier (un substrat effectif déployé dans un environnement).

Caractérisation

Le Substrat est l'infrastructure de l'inscription : c'est le lieu matériel dans lequel une notion prend place pour devenir manifeste. Sans Substrat, une notion reste une abstraction sans support de manifestation. Avec Substrat, la notion peut s'inscrire et devenir une occurrence observable.

Typologie des Substrats

Quatre types principaux de Substrats structurent l'architecture :

• Substrat relationnel : porte des notions sous forme de tuples organisés en tables, avec contraintes d'intégrité référentielle. Exemples : PostgreSQL, MySQL, Oracle, SQL Server.

• Substrat documentaire : porte des notions sous forme de documents semi-structurés. Exemples : MongoDB, CouchDB, Elasticsearch.

• Substrat événementiel : porte des notions sous forme d'événements ordonnés dans un journal. Exemples : Apache Kafka, Apache Pulsar, EventStore.

• Substrat fichier : porte des notions sous forme de fichiers identifiés et versionnés. Exemples : système de fichiers local, S3, MinIO, blob storage.

Cette typologie est extensible : un contexte d'implémentation peut introduire d'autres types de Substrats selon ses besoins (graphe, séries temporelles, vectoriel pour embeddings, etc.). La typologie minimale ci-dessus couvre la majorité des cas opérationnels.

Régularité — Neutralité métier des Substrats

Un Substrat est neutre relativement à la sémantique métier qu'il accueille. Il porte des structures de données sans préjuger du sens métier que ces structures portent. Une même base PostgreSQL peut accueillir des notions de produits, de commandes, de clients, de comptes, sans que cette diversité métier affecte la nature du Substrat.

Cette régularité a une implication architecturale importante : la séparation des préoccupations entre l'infrastructure technique (le Substrat) et la sémantique métier (les Datasets qui s'y inscrivent). Le Substrat est choisi pour ses propriétés techniques (performance, transactionnalité, durabilité, scalabilité) ; la sémantique métier est portée par les Datasets qui s'y inscrivent et par les Providers qui orchestrent ces inscriptions.

Régularité — Manifestation et inactivité

Un Substrat passe par des états de manifestation (déployé et opérant), d'inactivité (déployé et en attente), de dormance (déployé et suspendu), de réveil (passage de la dormance à la manifestation). La théorie pose que ces états sont contextuels : un Substrat peut dormir dans un contexte (par exemple un environnement de test inactif) et se réveiller dans un autre (par exemple lors d'une session de test).

Les implémentations gèrent ces transitions d'état par des mécanismes appropriés : startup et shutdown contrôlés, mise en veille programmée, redémarrage automatique sur événement contextuel.

3.2 Providers — l'infrastructure de l'inscription

Définition D11 — Provider

Un Provider est une infrastructure qui matérialise l'opération d'inscription ▶ dans un Substrat. Il est l'agent technique qui prend une notion et la fait s'inscrire dans un contexte de Substrat pour produire une occurrence signifiante.

Formellement, un Provider est une occurrence (n_P, k_P) où n_P est une notion-de-provider (une combinaison engine × function) et k_P est un contexte d'instanciation particulier (un provider effectif rattaché à un Substrat).

Composition Engine × Function

Tout Provider se décompose en deux dimensions :

• L'Engine est le moteur technique qui réalise l'opération matérielle d'inscription. Exemples d'engines : SQL, REST, gRPC, Kafka API, GraphQL, FTP, SFTP.

• La Function est la sémantique d'inscription que le Provider accomplit. Exemples de functions : CRUD (Create-Read-Update-Delete), Publish-Subscribe, Request-Response, Resource Manipulation, Event Sourcing.

Un Provider concret est un couple engine × function appliqué à un Substrat. Quelques couples typiques :

Régularité — Spécialisation par couple engine × function

Un Provider effectif se spécialise par le couple engine × function qu'il met en œuvre. Un Provider SQL/CRUD ne réalise pas les mêmes inscriptions qu'un Provider REST/Resource. Cette spécialisation est une caractéristique structurelle qui aide à la lisibilité du système : un développeur identifie immédiatement la nature des inscriptions qu'un Provider donné peut réaliser.

Régularité — Couplage Substrat-Provider

Un Provider est couplé à un Substrat compatible : un Provider SQL/CRUD se rattache à un Substrat relationnel ; un Provider Kafka API/Publish-Subscribe se rattache à un Substrat événementiel ; un Provider FTP/File Transfer se rattache à un Substrat fichier. Cette compatibilité est contextuelle : elle se décide selon les caractéristiques techniques du Substrat et du Provider. Un Substrat documentaire peut accueillir un Provider SQL/CRUD via un adaptateur (par exemple PostgreSQL avec colonne JSONB) ; cette possibilité fait l'objet de variations contextuelles documentées par les implémentations.

Régularité — Manifestation et inactivité

Un Provider passe par des états analogues à ceux des Substrats : manifestation, inactivité, dormance, réveil. Les implémentations gèrent ces transitions selon les mécanismes appropriés au type d'engine.

3.3 Datasets — les notions identifiées et versionnées

Définition D12 — Dataset

Un Dataset est une structure de notions cohérentes, identifiée et versionnée, qui s'inscrit dans un Substrat via un Provider. Il est l'unité élémentaire de structure signifiante dans Stratide Flux.

Formellement, un Dataset est une occurrence (n_D, k_D) où n_D est une notion-de-dataset (un schéma de structure cohérente) et k_D est un contexte d'instanciation particulier (un dataset effectif inscrit dans un Substrat).

Caractérisation

Un Dataset porte une sémantique métier : il identifie un type d'entité, un type d'événement, un type de relation que le système manipule. Un Dataset Produit porte la sémantique des produits ; un Dataset Commande porte la sémantique des commandes ; un Dataset Inventaire porte la sémantique des stocks.

Le Dataset est articulé à plusieurs niveaux :

• Il a une structure : un schéma qui définit les notions qu'il porte (champs, types, contraintes)
• Il a une identité : un nom qualifié qui le distingue des autres Datasets
• Il a un versionnement : un mécanisme de gestion des évolutions de structure
• Il a une inscription : il est inscrit dans un Substrat particulier via un Provider particulier

Régularité — Identification stable

Un Dataset reçoit une identification stable qui le distingue durablement des autres Datasets. Cette identification est le point d'entrée par lequel les autres entités du système (Endpoints, Contracts, Flows) référencent le Dataset.

Régularité — Versionnement explicite

Les évolutions de structure d'un Dataset font l'objet d'un versionnement explicite. Les versions successives coexistent quand le contexte le requiert : une nouvelle version peut être déployée pendant qu'une ancienne version reste mobilisable pour les consommateurs qui ne se sont pas encore mis à jour. Le versionnement préserve la lisibilité du système face à ses évolutions.

Régularité — Inscription opérante

Un Dataset effectif est inscrit dans un Substrat via un Provider. L'inscription est ce qui rend le Dataset opérant : les données qu'il porte sont alors lisibles, modifiables, mobilisables selon les modalités du Provider.

3.4 Endpoints — les centres stabilisés

Définition D13 — Endpoint

Un Endpoint est une occurrence maximalement lisible qui satisfait simultanément les trois conditions de la lisibilité (sens, atteignabilité, compréhension). Il est l'unité de centre stabilisé du régime architectural de Stratide Flux.

Formellement, un Endpoint est une occurrence (n_E, k_E) où n_E est une notion-d'endpoint (une définition de centre opérationnel) et k_E est un contexte d'activation particulier (un endpoint effectif déployé et opérant).

Caractérisation

L'Endpoint est le pivot du régime architectural. Tout flux significatif du système passe par un ou plusieurs endpoints : ils sont les points par lesquels les données entrent dans le système, sortent du système, transitent entre composants, font l'objet de transformations.

L'Endpoint réalise les trois conditions de la lisibilité :

• Sens : l'endpoint s'inscrit comme structure orientée dans un Substrat via un Provider, ce qui en fait une occurrence signifiante (Ω^s)
• Atteignabilité : l'endpoint est accessible depuis les contextes d'usage par les voies de circulation que son Provider expose
• Compréhension : l'endpoint a une structure documentée, un comportement spécifié, un contrat d'usage transmissible

Typologie des Endpoints

Les endpoints se distinguent par le degré auquel ils satisfont les trois conditions de la lisibilité.

Un endpoint pleinement lisible satisfait les trois conditions au plus haut degré. Sa structure est explicite, ses voies d'accès sont stables, sa documentation est complète. C'est le cas typique d'un endpoint de production mûr.

Un endpoint partiellement lisible satisfait les trois conditions à un degré moindre. Sa structure peut être en cours de spécification, ses voies d'accès peuvent connaître des limitations, sa documentation peut être incomplète. C'est le cas typique d'un endpoint en cours de développement ou d'un endpoint déprécié en phase de retrait.

Cette typologie graduelle reflète la nature contextuelle de la lisibilité : la lisibilité maximale est un objectif, et le système peut connaître des endpoints à différents degrés de maturité simultanément.

Régularité — Centre stabilisé

Un Endpoint pleinement lisible est un centre stabilisé au sens de la Section 2.7 : son champ ◇_D(σ) est non vide, et il rassemble l'ensemble des entités qui dépendent de lui pour leur cohérence directionnelle. Le champ d'un endpoint comprend typiquement :

• Les Datasets qui s'y manifestent
• Les Contracts qui en partent ou y arrivent
• Les Leases qui le mobilisent
• Les Flows qui le traversent
• Les projets externes qui s'y connectent

Régularité — Pivot architectural

Tout flux significatif du système passe par un ou plusieurs endpoints. Cette régularité fait des endpoints les pivots architecturaux sur lesquels s'organise la circulation des données dans Stratide Flux. Les implémentations adoptent une posture explicite à cet égard : les endpoints sont nommés, documentés, gouvernés en tant que tels, distincts des structures techniques anonymes qui pourraient les supporter.

3.5 Contracts — datasets orientés

Définition D14 — Contract

Un Contract est un dataset orienté qui spécifie un mouvement entre endpoints. Il porte la sémantique du transit signifiant entre deux ou plusieurs centres stabilisés.

Formellement, un Contract est une occurrence (n_C, k_C) où n_C est une notion-de-contract (une spécification de mouvement orienté) et k_C est un contexte d'activation particulier.

Caractérisation

Le Contract spécifie ce qui doit transiter, et non comment. Il décrit la structure des données qui circulent, les endpoints d'origine et de destination, les conditions sous lesquelles le transit est autorisé, les garanties qui doivent être satisfaites. Le comment du transit relève des Leases, des Flows et de leurs Providers.

Cette distinction entre le quoi (Contract) et le comment (Lease + Flow + Provider) est fondamentale pour la lisibilité du système. Le Contract est un document de référence stable, lisible indépendamment des choix d'implémentation. Les Leases, Flows et Providers peuvent évoluer dans leur incarnation technique sans que le Contract change, à condition que les garanties contractuelles soient préservées.

Régularité — Orientation explicite

Un Contract a une orientation explicite : il a un endpoint d'origine, un ou plusieurs endpoints de destination, un sens de circulation. Cette orientation est partie intégrante de l'identité du Contract : un même appariement d'endpoints peut donner lieu à plusieurs Contracts orientés différemment.

Régularité — Spécification déclarative

Un Contract spécifie de façon déclarative ce qui doit transiter et sous quelles conditions. Cette spécification est lisible par des humains et par des systèmes automatisés. Elle sert de référence pour la validation des manifestations effectives du contract (les Leases) et pour la documentation du système.

Régularité — Stabilité contractuelle

Un Contract reste stable sur des périodes longues, par opposition aux Leases qui en sont les manifestations éphémères. Cette stabilité contractuelle préserve la confiance entre les composants du système : un consommateur d'un Contract peut construire son propre comportement sur cette base sans craindre des changements imprévus.

Les évolutions de Contract se font de façon contrôlée, avec versionnement explicite et période de coexistence des versions, selon les mêmes principes que pour les Datasets (3.3).

3.6 Leases — manifestations éphémères des contracts

Définition D15 — Lease

Un Lease est une occurrence signifiante éphémère qui matérialise un Contract dans un contexte d'exécution particulier. Il est l'instance opérante d'un Contract pour une durée déterminée.

Formellement, un Lease est une occurrence (n_L, k_L) où n_L est une notion-de-lease (une instance ponctuelle d'un Contract) et k_L est un contexte d'exécution particulier (une transaction, une session, une fenêtre temporelle).

Caractérisation

Le Lease est ce qui rend un Contract effectivement opérant dans un moment donné. Le Contract spécifie ce qui doit transiter ; le Lease est ce qui transite effectivement. Le Contract est stable et persistant ; le Lease est éphémère et contextuel.

Un Lease est typiquement caractérisé par :

• Une identité : un identifiant unique qui le distingue des autres Leases (typiquement un UUID)
• Un Contract : le contract qu'il instancie
• Un contexte d'exécution : les paramètres qui qualifient son occurrence (timestamp, source, destination, données mobilisées)
• Un état : sa position dans son cycle de vie

États du Lease

Le Lease passe par plusieurs états contextuels :

• Active : le Lease est en cours d'exécution, le transit est en train de s'accomplir
• Dormante : le Lease est suspendu, en attente d'une condition de réveil
• Terminée : le Lease a accompli son transit avec succès
• Échouée : le Lease a rencontré une condition d'échec qualifiée

Le passage d'un état à un autre fait l'objet de transitions contextuelles : un Lease active devient terminé quand le transit est accompli, ou échoué quand une condition d'échec est qualifiée. Un Lease peut aussi devenir dormant pour des raisons contextuelles (suspension volontaire, attente d'événement externe, etc.).

Régularité — Anti-replay et réveil contextuel

L'identité unique du Lease garantit l'anti-replay : un Lease terminé ne peut pas être rejoué tel quel ; toute nouvelle occurrence du transit produira un nouveau Lease avec une nouvelle identité.

La régularité de réveil contextuel pose qu'un Lease dormant peut être réveillé quand le contexte le requiert : par exemple, un Lease en attente d'un événement externe se réveille quand l'événement survient, et reprend alors son cycle d'exécution. Le réveil ne crée pas un nouveau Lease ; il réactive le Lease existant dans son contexte d'origine.

Cette articulation anti-replay / réveil contextuel reflète la régularité globale Rg-G1 de réversibilité posée par La structure lisible : aucune entité signifiante du système n'est définitivement perdue, et toute entité préservée peut être réactivée si le contexte le requiert.

Régularité — Trace obligatoire

Tout Lease produit une trace dans le système : un enregistrement persistant qui consigne son existence, son contract, son contexte d'exécution, son état, ses transitions. Cette trace est inscrite dans un Substrat dédié (typiquement événementiel ou relationnel) et peut être mobilisée pour des fins d'audit, d'analyse opérationnelle, de débogage.

3.7 Flows — manifestations du mouvement

Définition D16 — Flow

Un Flow est une manifestation contextuelle du mouvement primitif ◁ dans le régime architectural. Il est l'unité opérante du transit entre endpoints, et il accomplit ce que le Contract spécifie via le Lease qui le porte.

Formellement, un Flow est une occurrence (n_F, k_F) où n_F est une notion-de-flow (un type de mouvement contextuel) et k_F est un contexte d'exécution particulier.

Caractérisation

Le Flow est l'incarnation primaire du mouvement dans Stratide Flux. Il a le statut d'occurrence à part entière, conformément à la posture philosophique posée en Section 2.5 : le mouvement est primitif, et les flows en sont les manifestations contextuelles primaires.

Un Flow est articulé à plusieurs entités :

• Il est porté par un Lease qui le contextualise dans une instance de Contract
• Il s'appuie sur un Contract qui spécifie ce qu'il doit accomplir
• Il connecte des Endpoints (origine et destination) que sa traversée articule
• Il mobilise des Providers qui matérialisent les inscriptions intermédiaires nécessaires
• Il produit une trace qui consigne son passage

Régularité — Idempotence par clé

Un Flow respecte une régularité d'idempotence par clé : appliquer plusieurs fois le même Flow avec la même clé d'identité produit le même résultat qu'une application unique. Cette régularité préserve la cohérence du système face aux retries, aux dédoublements, aux conditions de course.

L'idempotence est garantie par construction : le système identifie chaque Flow par une clé unique (typiquement dérivée du Lease qui le porte) et garantit qu'une même clé ne produit qu'une seule manifestation effective, quels que soient le nombre de tentatives.

Régularité — Trace obligatoire

Tout Flow produit une trace persistante : un enregistrement qui consigne son existence, son contexte, ses inscriptions, ses transitions. Cette trace est elle-même une occurrence inscrite dans un Substrat dédié, et elle constitue la mémoire opérationnelle du système.

La trace permet l'observabilité du système : un opérateur peut reconstruire l'histoire d'une transaction métier en suivant la chaîne des Flows et de leurs traces. Elle permet aussi l'audit : la trace persistante des Flows est lisible par des systèmes externes pour des fins de conformité réglementaire.

Régularité — Composition

Les Flows peuvent être composés entre eux : un Flow de niveau supérieur peut articuler plusieurs Flows de niveau inférieur. Cette composition se fait par les Contracts (qui peuvent référencer d'autres Contracts) et par les Leases (qui peuvent référencer d'autres Leases comme dépendances).

La composition préserve les régularités précédentes : un Flow composé respecte l'idempotence et la trace au niveau global, et chaque sous-Flow respecte ses propres régularités au niveau local.

3.8 Projects — centres d'autorité locale

Définition D17 — Project

Un Project est un centre d'autorité locale qui gouverne un ensemble d'endpoints, de contracts, de datasets et d'autres entités architecturales rattachées. Il est l'unité de gouvernance intermédiaire dans Stratide Flux.

Formellement, un Project est une occurrence (n_Pr, k_Pr) où n_Pr est une notion-de-projet (une définition de domaine de gouvernance) et k_Pr est un contexte d'instanciation (un projet effectif déployé).

Caractérisation

Le Project rassemble un ensemble cohérent d'entités qui partagent une gouvernance commune : règles d'accès, politiques de versionnement, choix techniques, équipe responsable, cycle de vie. Le Project est le périmètre dans lequel ces choix sont fixés et appliqués.

Un Project gouverne typiquement :

• Un ou plusieurs Endpoints qui forment ses centres stabilisés
• Les Contracts qui partent de ou arrivent à ces endpoints
• Les Datasets qui s'inscrivent via les Providers du projet
• Les Substrats et Providers dédiés au projet (le cas échéant)
• Les politiques de gouvernance qui s'appliquent à l'ensemble

Régularité — Champ de gouvernance local

Le Project définit un champ de gouvernance local : un ensemble d'entités sur lesquelles ses politiques s'appliquent. Ce champ est explicite : chaque entité du système est rattachée à un et un seul Project.

Cette régularité préserve la lisibilité du système : un opérateur identifie immédiatement quel Project gouverne une entité donnée, et donc quelles politiques s'appliquent à elle.

Régularité — Autonomie opérationnelle

Un Project a une autonomie opérationnelle : ses choix de gouvernance sont fixés en interne, sans coordination obligatoire avec les autres Projects. Cette autonomie permet une évolution parallèle des Projects, et préserve leur capacité à se transformer selon leurs propres rythmes.

L'autonomie est cependant bornée par les Contracts qui traversent les frontières du Project : ces Contracts engagent le Project envers ses partenaires, et leur évolution requiert une coordination contextuelle.

Régularité — Composition de centres

Le Project est lui-même un centre stabilisé d'un niveau supérieur. Son champ ◇_D(σ) rassemble l'ensemble des entités qu'il gouverne, et il participe au régime architectural en tant qu'unité reconnaissable. Plusieurs Projects coexistent dans un même système, et leur articulation forme la stratification de gouvernance dont le ContractApi est le centre global.

3.9 ContractApi — gardien universel

Définition D18 — ContractApi

Le ContractApi est le centre d'autorité globale qui stabilise l'ensemble des Projects et qui veille à la cohérence des Contracts inter-Projects. Il est l'unité de gouvernance globale dans Stratide Flux.

Formellement, le ContractApi est une occurrence (n_API, k_API) où n_API est la notion-de-contract-api (une définition de gouvernance globale) et k_API est un contexte d'instanciation particulier (un ContractApi effectif déployé pour un système Stratide Flux donné).

Caractérisation

Le ContractApi joue le rôle de gardien universel des Contracts. Il maintient le registre global des Contracts actifs, valide leur cohérence, arbitre les conflits potentiels, et garantit que les Contracts inter-Projects respectent les régularités globales du système.

Un système Stratide Flux comporte typiquement un seul ContractApi opérant à un moment donné. Cette unicité préserve la cohérence globale : tous les Projects se réfèrent au même ContractApi, et les Contracts qu'ils établissent passent par lui.

Régularité — Centre d'autorité globale

Le ContractApi est le centre d'autorité globale du système. Son champ ◇_D(σ) rassemble l'ensemble des Projects, qui dépendent de lui pour la cohérence des Contracts inter-Projects. Cette régularité fait du ContractApi le pivot ultime du régime architectural : c'est par lui que les Projects se coordonnent et que la cohérence globale du système se maintient.

Régularité — Délégation aux Projects

Le ContractApi délègue aux Projects la gouvernance locale de leurs entités internes. Son périmètre d'intervention se limite à la coordination inter-Projects et à la cohérence globale ; les choix techniques internes de chaque Project et les Contracts intra-Project restent du ressort exclusif du Project concerné.

Cette régularité de délégation préserve l'autonomie des Projects (cf. 3.8) et maintient le ContractApi à son rôle de gardien global, sans en faire un goulot d'étranglement opérationnel.

Régularité — Stratification de l'autorité

L'articulation Endpoint / Project / ContractApi compose une stratification de l'autorité à trois niveaux :

Chaque niveau gouverne sa zone, en s'appuyant sur les niveaux inférieurs et en se référant au niveau supérieur. Cette stratification est la manifestation concrète de la régularité globale Rg-G3 de co-fondation posée par La structure lisible : les centres de différents niveaux se fondent mutuellement, et leur articulation compose le régime opérant.

3.10 Synthèse des entités architecturales

Cette section a déployé les neuf entités architecturales de Stratide Flux. Le tableau ci-dessous récapitule leur articulation.

Ces neuf entités forment l'inventaire architectural que la Section 4 articulera en régime cohérent, et que la Section 5 traduira en cadre d'implémentation. Chaque entité a reçu sa caractérisation typologique, ses régularités contextuelles, et ses exemples métier. Les implémentations construiront leurs modules en référence à cet inventaire, avec les spécialisations techniques que leur contexte requiert.

La Section 4 ouvre l'articulation en régime, en montrant comment ces entités composent un système cohérent traversé par les régularités globales de la théorie : succession des centres, dormance et réveil, asymétrie sortie/entrée, frontière technique.

Section 4 — Régime architectural

Les sections précédentes ont posé les fondations conceptuelles (Section 2) et déployé les neuf entités architecturales (Section 3). La présente section articule ces éléments en régime cohérent au sens du socle théorique : Stratide Flux compose un système où des centres stabilisés s'organisent en stratification, où des successions transforment les structures, où des dormances et des réveils préservent la mémoire, où des asymétries structurelles orientent la circulation, et où des frontières techniques articulent les choix d'implémentation.

La progression de cette section suit l'ordre des manifestations du régime : on part de la stratification comme caractéristique générale, on aborde la succession comme dynamique de transformation, on précise la dormance et le réveil comme régularité de réversibilité, on caractérise l'asymétrie sortie/entrée comme structure de circulation, et on articule la frontière technique comme zone de variation contextuelle.

4.1 Stratide Flux comme régime stratifié

Caractérisation du régime

Stratide Flux compose un régime stratifié : ses entités s'articulent en niveaux hiérarchisés, et chaque niveau a sa fonction propre dans l'économie d'ensemble. Les niveaux supérieurs gouvernent les niveaux inférieurs, et les niveaux inférieurs portent les niveaux supérieurs. Cette articulation bilatérale est la caractéristique structurelle du régime.

La stratification se déploie sur cinq niveaux principaux :

Chaque niveau stabilise les niveaux qu'il contient et dépend des niveaux qu'il contient. Le ContractApi stabilise les Projects ; les Projects dépendent du ContractApi pour leur cohérence inter-domaines. Les Projects stabilisent les Endpoints ; les Endpoints dépendent des Projects pour leur gouvernance. Les Endpoints stabilisent les Flows et les Leases ; les Flows et Leases dépendent des Endpoints pour leur orientation. Les Flows et Leases mobilisent les Providers, Substrats, Datasets ; ces infrastructures portent matériellement la manifestation des Flows et Leases.

Régularité — Stratification dynamique

La stratification de Stratide Flux est dynamique : les niveaux sont stables dans leur fonction, et les entités qui les peuplent évoluent dans le temps. Un Project peut accueillir de nouveaux Endpoints, retirer d'anciens Endpoints, modifier ses politiques de gouvernance. Le ContractApi peut accueillir de nouveaux Projects, en retirer, faire évoluer ses régularités globales.

Cette dynamique est elle-même cadrée par les régularités du régime : les évolutions se font de façon contrôlée, avec versionnement explicite, période de coexistence des versions, traçabilité des transitions. La dynamique de la stratification préserve la lisibilité du régime à chaque instant.

Articulation à la régularité globale Rg-G3 de co-fondation

La stratification de Stratide Flux manifeste la régularité globale Rg-G3 de co-fondation posée par La structure lisible. Cette régularité énonce que les centres de différents niveaux se fondent mutuellement : chaque niveau stabilise ce qu'il contient, et reçoit sa propre stabilisation du niveau qui le contient.

Dans Stratide Flux, cette co-fondation prend la forme suivante : un Endpoint est stabilisé par le Project qui le gouverne, et il stabilise les Flows et Leases qui en dépendent. Un Project est stabilisé par le ContractApi qui le coordonne, et il stabilise les Endpoints qu'il gouverne. Aucun niveau n'est isolé : chacun reçoit sa cohérence du niveau supérieur et la transmet au niveau inférieur.

4.2 Succession et transformation

La succession comme régularité dynamique

Le régime de Stratide Flux connaît des transformations : les centres se déplacent, de nouvelles versions remplacent les anciennes, des restructurations modifient l'agencement des entités. La théorie générale pose que ces transformations relèvent de la succession ↷_D : un nouveau centre prend la place d'un ancien centre selon une direction déterminée.

Dans le domaine architectural, la succession se manifeste typiquement sous trois formes :

• Succession de versions : une nouvelle version d'un Dataset, d'un Contract ou d'un Endpoint remplace une version antérieure
• Succession d'instances : un Endpoint déployé dans un environnement de test devient un Endpoint déployé en production
• Succession de stratifications : un Project se restructure en plusieurs Projects, ou plusieurs Projects fusionnent en un Project unique

Chaque succession s'inscrit dans une direction explicite (versionnement, déploiement, gouvernance) et préserve la lisibilité du régime à travers la transformation.

Régularité — Progressivité des transformations

Les transformations dans Stratide Flux sont progressives. Une nouvelle version coexiste avec l'ancienne pendant une période de transition. Un nouvel Endpoint est déployé en parallèle de l'ancien avant que celui-ci ne soit retiré. Une restructuration de Projects se fait par étapes successives, chacune préservant la cohérence du système.

Cette progressivité manifeste la régularité globale Rg-G2 de progressivité posée par La structure lisible. La régularité énonce que les transformations cohérentes se font par étapes, sans saut brutal qui romprait la lisibilité du régime. Les transformations brutales sont possibles dans des contextes exceptionnels, et elles relèvent alors d'une rupture (▽_D) plutôt que d'une succession.

Régularité — Traçabilité des successions

Toute succession dans Stratide Flux laisse une trace : un enregistrement persistant qui consigne le centre antérieur, le centre successeur, la direction de succession, le contexte de transition. Cette trace constitue la mémoire des transformations du régime, et elle permet de reconstruire l'histoire d'un centre à travers ses successions.

Cette traçabilité s'appuie sur les Substrats événementiels typiquement, qui portent naturellement la sémantique de l'enregistrement ordonné. Un opérateur peut interroger cette trace pour comprendre comment un centre actuel s'est constitué à travers ses successions antérieures.

4.3 Dormance et réveil contextuel

La dormance comme état architectural

Le régime de Stratide Flux reconnaît un état de dormance distinct de l'état d'inactivité ou de destruction. Une entité dormante existe dans le système, garde son identité, conserve ses propriétés, et peut être réveillée quand le contexte le requiert. La dormance est un état de présence préservée, qui se distingue de l'inactivité (entité présente mais non opérante) et de la destruction (entité retirée du système).

Plusieurs entités architecturales connaissent un état de dormance :

• Un Substrat peut dormir quand son contexte d'instanciation est suspendu (environnement de test inactif, base de données arrêtée pour maintenance)
• Un Provider peut dormir quand son Substrat est dormant ou quand sa fonction est temporairement désactivée
• Un Endpoint peut dormir quand son contexte d'activation est suspendu (déploiement retiré, fonction métier mise en pause)
• Un Lease peut dormir en attente d'un événement externe ou d'une condition contextuelle de réveil
• Un Project peut dormir quand l'ensemble de ses entités est mis en pause

Le réveil comme manifestation contextuelle

Le réveil d'une entité dormante se déclenche quand le contexte le requiert. La condition de réveil est explicite et documentée : événement externe attendu, retour d'un environnement, demande d'opérateur, échéance temporelle.

Le réveil ne crée pas une nouvelle entité ; il réactive l'entité existante dans son contexte d'origine. L'identité de l'entité réveillée est la même que celle de l'entité dormante. Ses propriétés, son histoire, ses traces sont préservées. Cette continuité d'identité est la caractéristique distinctive du couple dormance/réveil par opposition à un couple destruction/création.

Régularité — Réversibilité contextuelle

Le couple dormance/réveil manifeste la régularité globale Rg-G1 de réversibilité posée par La structure lisible. Cette régularité énonce que les transformations du régime sont contextuellement réversibles : aucune transformation ne ferme définitivement la possibilité d'un retour ou d'une réactivation.

La régularité de réversibilité a une conséquence pratique majeure : les implémentations de Stratide Flux préservent l'identité des entités plutôt que de la détruire. La destruction effective d'une entité est une opération exceptionnelle, qui requiert un contexte explicite et qui laisse elle-même une trace (la trace de destruction). Dans le cas général, une entité retirée du fonctionnement courant passe en dormance et reste préservée pour un éventuel réveil.

Régularité — Cohérence des réveils

Le réveil d'une entité préserve la cohérence du régime. Une entité réveillée se réinsère dans le régime selon son contexte d'origine, et elle s'articule de nouveau avec les entités qui dépendent d'elle (son champ ◇_D(σ)). Si le régime a évolué pendant la dormance, le réveil mobilise des mécanismes contextuels d'adaptation : mise à jour de version, reconfiguration des dépendances, validation des contracts associés.

Cette régularité préserve la lisibilité du régime à travers les cycles dormance/réveil : un opérateur peut compter sur le fait qu'une entité réveillée fonctionne de façon cohérente avec l'état actuel du régime, et non avec un état figé qui aurait été celui de la dormance.

4.4 Asymétrie sortie/entrée

La structure asymétrique de la circulation

Stratide Flux pose une asymétrie structurelle entre les voies de sortie et les voies d'entrée du système. Cette asymétrie est une caractéristique architecturale fondamentale, et elle organise la circulation des données dans le régime.

La sortie du système suit le chemin :

Endpoint d'origine ▶ Contract ▶ Lease ▶ Flow ▶ Endpoint de destination

L'entrée dans le système suit le chemin :

Source externe ▶ Provider ▶ Substrat ▶ Dataset ▶ Endpoint

Régularité — Sortie par contrat

Toute donnée qui quitte le système (qui est transmise à un destinataire externe ou à un autre système) le fait via un Contract explicite. Le Contract spécifie ce qui peut sortir, sous quelles conditions, vers quel destinataire. Cette régularité préserve la lisibilité du système face aux flux sortants : toute donnée qui quitte le système est légitimée par un Contract qui en autorise la sortie.

Cette régularité a des implications pratiques : les implémentations imposent qu'un endpoint qui exporte des données possède un Contract de sortie associé, et que toute opération d'exportation passe par un Lease instancié à partir de ce Contract. Les opérations d'export ad hoc, sans Contract préalable, relèvent d'exceptions contextuelles documentées.

Régularité — Entrée par provider

Toute donnée qui entre dans le système (qui provient d'une source externe pour s'inscrire dans un Substrat) le fait via un Provider explicite. Le Provider contrôle l'entrée, valide le format, applique les transformations nécessaires, inscrit la donnée dans le Substrat sous-jacent. Cette régularité préserve la lisibilité du système face aux flux entrants : toute donnée qui s'inscrit dans un Substrat est médiée par un Provider qui en garantit la conformité.

Cette régularité a des implications pratiques : les implémentations imposent qu'un Substrat reçoive ses inscriptions via un Provider qualifié, et que les inscriptions directes sans Provider relèvent d'opérations exceptionnelles (typiquement des migrations initiales) qui font l'objet d'un encadrement contextuel.

Symétrie structurelle de l'asymétrie

L'asymétrie sortie/entrée est elle-même structurellement symétrique : la sortie passe par un Contract qui spécifie un mouvement orienté, et l'entrée passe par un Provider qui matérialise une inscription orientée. Les deux voies sont articulées à des entités spécialisées (Contract pour la sortie, Provider pour l'entrée), ce qui préserve la lisibilité de chaque voie tout en respectant leur nature distincte.

Cette symétrie structurelle distingue Stratide Flux des architectures qui traiteraient les deux voies de façon homogène (par exemple, toutes les manipulations passant par des « interfaces » génériques). Dans Stratide Flux, la sortie et l'entrée ont des fonctions architecturales distinctes, qui se reflètent dans l'identification d'entités spécialisées (Contract vs Provider).

4.5 Frontière technique

La compatibilité techno-Substrat comme frontière

Stratide Flux articule une frontière technique entre les choix d'engine technique et les types de Substrats. Cette frontière organise les compatibilités possibles entre les Providers et les Substrats, et elle pose les conditions sous lesquelles une combinaison engine × function × substrat est opérante.

La frontière technique se manifeste concrètement par les couples typiques posés en Section 3.2 :

Les compatibilités directes correspondent aux usages typiques. Les compatibilités via adaptateur ou mapping correspondent à des usages contextuels qui requièrent une couche de traduction.

Régularité — Variations contextuelles

La compatibilité techno-Substrat varie selon le contexte technique. Une combinaison qui requiert un adaptateur dans un contexte peut devenir directe dans un autre contexte (par exemple, un Substrat documentaire qui expose une interface SQL native via une extension).

Cette régularité de variation contextuelle est cohérente avec la posture énonciative générale : la frontière technique est elle-même contextuelle, et les implémentations documentent les compatibilités effectives selon leur propre contexte technique.

Régularité — Décision technique localisée

Les choix techniques de compatibilité sont localisés au niveau du Project qui les met en œuvre. Le Project décide quels couples engine × function × substrat il autorise, quels adaptateurs il déploie, quelles variations contextuelles il documente. Le ContractApi délègue cette décision aux Projects, conformément à la régularité de délégation posée en Section 3.9.

Cette régularité préserve l'autonomie opérationnelle des Projects : chaque Project ajuste ses choix techniques selon ses contraintes propres, sans coordination obligatoire avec les autres Projects sur ce périmètre.

4.6 Synthèse du régime

Cette section a articulé les neuf entités architecturales en régime cohérent. Le régime de Stratide Flux se caractérise par :

• Une stratification à cinq niveaux (Global, Local, Centre, Manifestation, Infrastructure) qui manifeste la régularité globale de co-fondation
• Une dynamique de succession qui transforme les centres tout en préservant la lisibilité, conformément à la régularité globale de progressivité
• Un couple dormance/réveil qui préserve l'identité des entités à travers les cycles d'activité, conformément à la régularité globale de réversibilité
• Une asymétrie sortie/entrée structurée qui organise la circulation des données par Contracts et Providers
• Une frontière technique localement gouvernée qui organise les compatibilités entre engines et Substrats

Le régime ainsi caractérisé compose un système d'information opérant : un régime stratifié qui se transforme progressivement, qui préserve la mémoire de ses entités, qui circule selon des voies orientées explicites, et qui s'incarne dans des choix techniques contextuels.

La Section 5 traduit ce régime architectural en cadre d'implémentation : elle identifie les modules-cibles que doit comporter un noyau Stratide Flux, leurs interfaces principales, les contrats minimaux à supporter, et les états observables. Elle fait le pont entre le cadre conceptuel et la pratique de construction.

Section 5 — Cadre d'implémentation

Les sections précédentes ont posé le cadre conceptuel de Stratide Flux : ses fondations (Section 2), ses entités architecturales (Section 3), son régime cohérent (Section 4). La présente section traduit ce cadre en éléments d'implémentation : modules-cibles, interfaces principales, contrats minimaux à supporter, états observables.

La progression suit l'ordre de construction : on identifie d'abord les modules-cibles que doit comporter un noyau, on caractérise les interfaces principales qu'ils exposent, on précise les contrats minimaux que le noyau initial supporte, on articule les états observables que le système rend visibles, et on explicite les responsabilités déléguées aux utilisateurs du noyau.

Le cadre proposé reste neutre relativement aux choix techniques : il pose ce qui doit être présent dans tout noyau Stratide Flux, et il laisse ouverts les choix d'incarnation technique. Une équipe d'implémentation décline ce cadre selon ses propres contraintes (langage, infrastructure cible, contraintes de performance, équipe disponible).

5.1 Modules-cibles du noyau

Un noyau Stratide Flux comporte sept modules principaux, articulés selon la stratification du régime.

Module Notion-Context

Le module Notion-Context porte les atomes premiers du système : les notions et les contextes. Il fournit les structures de données et les opérations élémentaires qui permettent d'identifier, de comparer, de mettre en relation des notions et des contextes.

Responsabilités principales : - Représentation typée des notions et des contextes - Construction d'occurrences (couples notion-contexte) - Identification stable des occurrences - Vérification de la disjonction 𝓝 ∩ 𝓚 = ∅ par construction du typage

Ce module est le plus fondamental : tous les autres modules le mobilisent pour construire leurs propres entités.

Module Inscription

Le module Inscription porte la relation primitive ▶ et le domaine signifiant Ω^s. Il fournit les opérations qui permettent d'inscrire une notion dans un contexte, de vérifier qu'une occurrence est inscrite, de mobiliser le domaine signifiant pour des requêtes.

Responsabilités principales : - Mécanismes d'inscription d'une notion dans un contexte - Vérification d'inscription d'une occurrence - Construction et interrogation du domaine signifiant Ω^s - Articulation aux Providers qui matérialisent l'inscription dans des Substrats concrets

Module Movement

Le module Movement porte la relation primitive ◁ et les flows comme manifestations du mouvement. Il fournit les structures et les opérations qui permettent de représenter un flow, de le mobiliser dans un contexte d'exécution, de tracer son passage.

Responsabilités principales : - Représentation des flows comme entités primaires - Composition de flows - Garantie d'idempotence par clé d'identité - Articulation aux Leases qui contextualisent les flows - Production de traces persistantes des flows

Module Substrate-Provider

Le module Substrate-Provider porte les infrastructures matérielles : les Substrats qui hébergent les notions, et les Providers qui matérialisent les inscriptions. Il fournit les interfaces génériques qui permettent à différents types de Substrats et de Providers de coexister dans un même noyau.

Responsabilités principales : - Interface générique des Substrats (relationnel, documentaire, événementiel, fichier) - Interface générique des Providers (engine × function) - Couplage Substrat-Provider selon les compatibilités contextuelles - Gestion des états de manifestation, inactivité, dormance, réveil

Module Endpoint-Field

Le module Endpoint-Field porte les centres stabilisés : les endpoints comme occurrences maximalement lisibles et leurs champs ◇_D(σ). Il fournit les structures qui permettent de définir un endpoint, de le déployer, de le mobiliser.

Responsabilités principales : - Représentation des endpoints comme occurrences satisfaisant les trois conditions de la lisibilité - Calcul des champs ◇_D(σ) pour chaque endpoint - Gestion des transitions d'état des endpoints (manifestation, dormance, réveil) - Articulation aux Datasets qui s'inscrivent et aux Contracts qui en partent ou y arrivent

Module Lease-Flow

Le module Lease-Flow porte les manifestations contextuelles des transits : les leases comme instances de contracts, et les flows comme manifestations du mouvement. Il fournit les mécanismes d'exécution qui rendent les contracts effectifs.

Responsabilités principales : - Création et gestion du cycle de vie des leases - Mobilisation des flows portés par les leases - Garanties d'anti-replay par identité unique - Mécanismes de réveil contextuel des leases dormants - Production des traces persistantes des leases et des flows

Module ContractApi-Project

Le module ContractApi-Project porte la gouvernance : les projects comme centres d'autorité locale, le ContractApi comme centre d'autorité globale. Il fournit les mécanismes de coordination inter-projects et de gestion globale des contracts.

Responsabilités principales : - Représentation des projects et de leurs périmètres de gouvernance - Registre global des contracts gérés par le ContractApi - Validation de la cohérence des contracts inter-projects - Délégation aux projects de la gouvernance locale - Traçabilité des transformations de gouvernance

Articulation entre modules

Les sept modules s'articulent selon la stratification posée en Section 4.1. Le tableau suivant récapitule leurs dépendances :

Cette articulation est cohérente avec la stratification ascendante : les modules infrastructurels (Notion-Context, Inscription, Movement, Substrate-Provider) supportent les modules de manifestation (Endpoint-Field, Lease-Flow), qui à leur tour supportent le module de gouvernance (ContractApi-Project).

5.2 Interfaces principales

Le noyau Stratide Flux expose un nombre limité d'interfaces que les implémenteurs et les utilisateurs mobilisent. Cette section identifie les interfaces principales sans en spécifier la syntaxe technique : la déclinaison en interfaces de programmation effectives relève des choix de langage et de plateforme.

Interface de définition d'entités architecturales

Le noyau expose une interface qui permet de définir les entités architecturales : Substrats, Providers, Datasets, Endpoints, Contracts, Projects. Cette interface est typiquement déclarative : l'utilisateur fournit une description structurée de l'entité (son schéma, son identification, ses dépendances, ses politiques), et le noyau valide la cohérence de la définition relativement aux régularités de Stratide Flux.

Interface de mobilisation des entités

Une fois définies, les entités architecturales peuvent être mobilisées : un Endpoint peut être atteint, un Contract peut être instancié en Lease, un Lease peut être exécuté en Flow. Le noyau expose une interface de mobilisation qui orchestre ces opérations en respectant les régularités contextuelles.

Interface d'observation des états

Le noyau expose une interface d'observation qui permet aux utilisateurs et aux opérateurs de connaître l'état courant des entités : un Endpoint est manifeste ou dormant, un Lease est actif ou terminé, un Substrat est opérant ou suspendu. Cette interface est en lecture seule et sans effet de bord sur le régime.

Interface de transformation contrôlée

Le noyau expose une interface de transformation contrôlée qui permet de faire évoluer les entités existantes : déclarer une nouvelle version d'un Dataset, déployer un nouvel Endpoint en parallèle d'un endpoint existant, retirer un Project de la gouvernance globale. Cette interface garantit la progressivité des transformations conformément à la régularité globale Rg-G2.

Interface d'extension

Le noyau expose une interface d'extension qui permet d'introduire de nouveaux types de Substrats, de Providers, ou de fonctions d'inscription. Cette interface respecte les contrats du noyau et permet aux implémentations de s'adapter à des contextes techniques particuliers sans remettre en cause les régularités générales.

5.3 Contrats minimaux à supporter

Un noyau Stratide Flux opérant supporte un ensemble minimal de contrats internes qui caractérisent son fonctionnement. Cette section identifie les contrats que le noyau initial expose à ses utilisateurs.

Contrat de cohérence d'inscription

Le noyau garantit que toute inscription effectuée via un Provider produit une occurrence dans le domaine signifiant Ω^s du Substrat correspondant. Cette garantie est vérifiable : un utilisateur qui inscrit une notion dans un contexte via un Provider peut interroger le Substrat pour confirmer que l'occurrence y est présente et signifiante.

Contrat d'idempotence des flows

Le noyau garantit que tout Flow portant une clé d'identité produit le même résultat quel que soit le nombre de fois où il est mobilisé avec cette clé. Cette garantie est essentielle pour la robustesse face aux retries, aux dédoublements, aux conditions de course.

Contrat de traçabilité

Le noyau garantit que toute manifestation effective (création d'entité, transition d'état, exécution de flow, succession) produit une trace persistante dans le système. Cette trace est interrogeable a posteriori et préserve la mémoire opérationnelle du régime.

Contrat de réversibilité contextuelle

Le noyau garantit que toute entité retirée du fonctionnement courant passe en dormance plutôt qu'en destruction immédiate. La destruction effective d'une entité requiert un contexte explicite et laisse elle-même une trace de destruction.

Contrat de cohérence inter-projects

Le noyau garantit que les contracts inter-projects respectent la cohérence globale : leur création passe par le ContractApi, leur évolution est coordonnée, leurs garanties sont préservées à travers les transformations des projects qu'ils articulent.

5.4 États observables

Le noyau rend observables un ensemble d'états que les utilisateurs et les opérateurs peuvent interroger pour comprendre le fonctionnement courant du système. Cette section identifie les états principaux.

États des entités architecturales

Chaque entité architecturale a un état observable qui caractérise sa situation dans le régime :

Ces états sont observables individuellement et collectivement : un opérateur peut interroger l'état d'une entité particulière, ou obtenir une vue agrégée de l'état d'un Project, voire de l'ensemble du système.

Trace des transitions

Le noyau expose la trace persistante des transitions d'état. Chaque transition (par exemple un Lease qui passe d'active à terminée, un Endpoint qui passe de dormant à actif) produit un enregistrement persistant qui consigne l'identité de l'entité, l'état antérieur, l'état nouveau, le contexte de transition, le timestamp.

Cette trace est interrogeable selon différentes dimensions : par entité, par contexte, par période temporelle, par type de transition. Elle constitue la base de l'observabilité opérationnelle du système.

Métriques agrégées

Le noyau peut exposer des métriques agrégées qui caractérisent le fonctionnement du système à un niveau global : nombre d'occurrences signifiantes par Substrat, taux de succès des Flows, durée moyenne des Leases, fréquence des successions par type d'entité. Ces métriques sont utiles pour le pilotage opérationnel et l'optimisation continue.

5.5 Responsabilités déléguées

Le noyau Stratide Flux a un périmètre fonctionnel délimité : il pose le cadre architectural et fournit les mécanismes opérationnels, et il délègue un certain nombre de responsabilités aux utilisateurs et aux projets qui le mobilisent. Cette section explicite les responsabilités déléguées.

Sémantique métier des Datasets

Le noyau fournit l'infrastructure générique des Datasets (identification, versionnement, inscription dans un Substrat). La sémantique métier des Datasets — quels champs ils contiennent, quelles contraintes ils respectent, quelles règles métier ils incarnent — est définie par les utilisateurs du noyau. Le noyau valide la cohérence structurelle ; il délègue la cohérence métier au Project qui définit le Dataset.

Politiques de gouvernance des Projects

Le noyau fournit l'infrastructure des Projects (centre d'autorité locale, périmètre de gouvernance, articulation au ContractApi). Les politiques de gouvernance internes à un Project — règles d'accès, processus de validation, cycle de vie des entités, choix techniques — sont définies par le Project lui-même. Le noyau garantit que les décisions du Project s'appliquent à son périmètre ; il délègue le contenu de ces décisions au Project.

Choix d'incarnation technique

Le noyau fournit les interfaces génériques des Substrats et des Providers. Le choix d'incarnation technique — quel SGBD, quel broker événementiel, quel format de fichier, quel protocole d'API — relève du Project qui les met en œuvre. Le noyau supporte les compatibilités techniques courantes et permet l'extension à de nouvelles incarnations via son interface d'extension.

Orchestration globale

Le noyau accommode plusieurs approches d'orchestration globale. La coordination des activités d'un système Stratide Flux peut être centralisée (par un orchestrateur) ou décentralisée (par événements). Le choix d'orchestration relève du contexte de déploiement, et le noyau fonctionne aussi bien avec l'une qu'avec l'autre approche.

Sécurité et contrôle d'accès

Le noyau fournit l'infrastructure d'identification et de traçabilité. Les politiques de sécurité spécifiques — authentification des utilisateurs, autorisation par rôle, chiffrement des données, audit de conformité — sont définies par le contexte de déploiement et mobilisent les mécanismes appropriés (tiers d'authentification, certificats, vault, etc.). Le noyau s'articule avec ces mécanismes plutôt que de les intégrer.

5.6 Synthèse du cadre d'implémentation

Cette section a posé le cadre dans lequel un noyau Stratide Flux peut être construit. Le cadre se caractérise par :

• Sept modules-cibles organisés selon la stratification du régime, avec leurs responsabilités principales et leurs dépendances explicitées
• Cinq interfaces principales que le noyau expose : définition d'entités, mobilisation, observation, transformation contrôlée, extension
• Cinq contrats minimaux que le noyau garantit : cohérence d'inscription, idempotence des flows, traçabilité, réversibilité contextuelle, cohérence inter-projects
• Des états observables pour chaque entité architecturale, une trace des transitions, des métriques agrégées pour le pilotage opérationnel
• Cinq familles de responsabilités déléguées aux utilisateurs : sémantique métier, politiques de gouvernance, choix techniques, orchestration globale, sécurité

Le cadre laisse ouverts les choix d'incarnation technique : un noyau Stratide Flux peut être construit en Rust, en TypeScript, en Python, en Java, en Go, ou dans toute combinaison appropriée. Les modules sont définis par leurs responsabilités et leurs interfaces, et chaque équipe d'implémentation décline ces définitions selon ses propres contraintes.

La Section 6 referme l'article par une posture finale qui récapitule ce qui a été posé, articule l'article aux autres niveaux théoriques (théorie générale, théorie appliquée, produit logiciel), et ouvre aux directions de développement ultérieures.

Section 6 — Posture finale

Cet article a posé Stratide Flux comme architecture-type pour les systèmes d'information de gestion. Il a articulé un cadre conceptuel cohérent, un régime architectural qui le déploie, et un cadre d'implémentation qui le rend constructible. La présente section referme l'article en récapitulant ce qui a été posé, en articulant la place de l'article dans la stratification théorique plus large, et en ouvrant aux directions que les développements ultérieurs pourront emprunter.

6.1 Ce que l'article a posé

L'article a déployé son contenu sur cinq sections, chacune avec une fonction propre dans la construction d'ensemble.

La Section 1 a posé le geste fondateur : la nature de Stratide Flux comme architecture-type, son inscription dans la stratification théorique (théorie générale → théorie appliquée → architecture incarnée), sa posture méthodologique fondée sur le régime énonciatif contextuel, et le contexte comme horizon constitutif de toute manifestation.

La Section 2 a posé les fondations conceptuelles : neuf définitions formelles (D1 à D9) qui caractérisent les notions et les contextes comme atomes premiers, l'occurrence comme leur appariement, l'inscription comme relation primitive de sens, le mouvement comme relation primitive originaire, la stabilité directionnelle, le centre, le champ, et la lisibilité comme caractérisation des centres pleinement opérants.

La Section 3 a déployé la stratification opérante : neuf entités architecturales (D10 à D18) qui composent l'inventaire concret de Stratide Flux. Substrats et Providers comme infrastructures matérielles, Datasets comme structures signifiantes, Endpoints comme centres stabilisés maximalement lisibles, Contracts comme datasets orientés, Leases comme manifestations éphémères, Flows comme manifestations primaires du mouvement, Projects comme centres d'autorité locale, ContractApi comme centre d'autorité globale.

La Section 4 a articulé le régime architectural : la stratification à cinq niveaux (Global, Local, Centre, Manifestation, Infrastructure), la dynamique de succession qui transforme progressivement les centres, le couple dormance/réveil qui préserve l'identité des entités, l'asymétrie sortie/entrée structurée par Contract et Provider, et la frontière technique qui organise les compatibilités contextuelles. Cette articulation a mobilisé explicitement les trois régularités globales de la théorie : Rg-G1 de réversibilité, Rg-G2 de progressivité, Rg-G3 de co-fondation.

La Section 5 a traduit le régime en cadre d'implémentation : sept modules-cibles d'un noyau (Notion-Context, Inscription, Movement, Substrate-Provider, Endpoint-Field, Lease-Flow, ContractApi-Project), cinq interfaces principales, cinq contrats minimaux que le noyau garantit, des états observables pour chaque entité, et cinq familles de responsabilités déléguées aux utilisateurs.

L'ensemble compose un cadre cohérent et constructible : un noyau Stratide Flux peut être conçu, construit, déployé en s'appuyant sur ce qui a été posé.

6.2 Ce que l'article a délimité

L'article a délimité son périmètre par quatre caractérisations positives, posées en Section 1.5 et confirmées par le déploiement des sections suivantes.

L'article propose un cadre conceptuel neutre relativement aux choix techniques. Les concepts qu'il pose se déclinent dans tout langage de programmation et toute infrastructure technique compatibles avec les régularités du régime. Les implémentations effectives feront leurs propres choix selon leurs contraintes.

L'article décrit une architecture-type distincte des produits logiciels qui l'incarnent. Un produit concret incarnant Stratide Flux portera son propre nom et son propre périmètre fonctionnel ; il fera l'objet de ses propres documents.

L'article pose un noyau conceptuel suffisant pour démarrer une implémentation plutôt qu'un traité exhaustif. Les développements ultérieurs pourront enrichir ce noyau de patterns, d'extensions et de spécialisations selon les contextes effectifs d'application.

L'article mobilise les concepts de La structure lisible et de Stratide en les convoquant plutôt qu'en les redémontrant. Le lecteur trouvera les fondements théoriques dans ces ouvrages, et il les retrouvera mobilisés ici dans leur fonction architecturale.

6.3 Articulation aux autres niveaux

L'article occupe une position spécifique dans une stratification théorique plus large, qu'il importe de récapituler en clôture.

Le niveau le plus général est celui de la théorie générale : La structure lisible — Essai de théorie générale du mouvement contextuel. Cet ouvrage pose les concepts fondamentaux (occurrence contextuelle, mouvement, stabilité directionnelle, centre, champ, régime, lisibilité) et les régularités globales (réversibilité, progressivité, co-fondation) qui structurent toute manifestation du contextuel. La théorie générale est neutre relativement aux domaines d'application : elle énonce les conditions universelles d'apparition, de stabilisation, de transformation et de stratification des structures.

Le niveau intermédiaire est celui de la théorie appliquée : la théorie Stratide. Elle spécialise la théorie générale au domaine de la stratification opérante. Elle développe les concepts qui caractérisent les régimes stratifiés : articulation des couches, transformations cohérentes, préservation de la lisibilité à travers les évolutions. Stratide est la discipline qui étudie le régime des strates, et un ouvrage théorique pourra à terme la développer dans son autonomie.

Le niveau de l'architecture incarnée est celui que cet article occupe : Stratide Flux. Il incarne la théorie Stratide dans le domaine particulier des systèmes d'information de gestion. Il compose un régime architectural opérant qui peut être analysé, construit, fait évoluer.

Le niveau du produit logiciel concret est celui qui suivra. Un produit incarnant Stratide Flux pour un domaine métier particulier — par exemple un système de gestion des commandes — portera son propre nom, déclinera l'architecture-type selon ses contraintes propres, et fera l'objet de ses propres documents. Stratide Flux fournit le cadre dans lequel ce produit peut être conçu et construit.

Cette stratification à quatre niveaux est elle-même une manifestation de la régularité globale Rg-G3 de co-fondation : chaque niveau stabilise ce qui le contient et reçoit sa stabilisation du niveau qui le contient. La théorie générale stabilise la théorie appliquée, qui stabilise l'architecture incarnée, qui stabilise les produits logiciels concrets. Aucun niveau n'est isolé : leur articulation cumulative compose le régime théorique complet.

6.4 Posture du système

L'article a posé Stratide Flux comme système doté de quatre caractéristiques structurelles, qu'il convient de réaffirmer en clôture.

Le contexte est l'horizon constitutif. Toute entité de Stratide Flux se comprend relativement au contexte qui la rend manifestable. Cette caractéristique a un statut constitutif : elle structure le régime architectural à un niveau plus fondamental que les options méthodologiques ordinaires.

Le mouvement est la relation primitive originaire. Les structures stables que le système observe sont des cadrages relatifs d'un mouvement plus fondamental, et elles peuvent à tout moment se révéler comme des phases d'un mouvement plus large. Cette caractéristique inverse l'ordre classique des architectures qui posent d'abord des objets statiques.

La cohérence est relationnelle, et non substantielle. Les entités du système tirent leur identité de leurs articulations avec d'autres entités, plutôt que d'une essence propre indépendante. Un Endpoint est ce qu'il est par les Datasets qui s'y inscrivent, par les Contracts qui en partent ou y arrivent, par les Flows qui le traversent, par le Project qui le gouverne.

Le régime préserve l'identité plutôt que de la détruire. La dormance se substitue à la destruction comme état par défaut des entités retirées du fonctionnement courant. La trace persistante consigne la mémoire des transformations. Cette caractéristique manifeste la régularité globale de réversibilité dans l'architecture.

Ces quatre caractéristiques distinguent Stratide Flux des architectures qui partiraient d'une posture inverse : contexte secondaire, objets statiques premiers, cohérence substantielle, destruction comme état terminal. Elles définissent la signature architecturale propre de Stratide Flux, et elles structurent toutes les décisions de conception qui s'inscrivent dans ce cadre.

6.5 Ouvertures

L'article referme un cadre suffisant et ouvre plusieurs directions de développement.

Une première direction est l'enrichissement théorique : un ouvrage consacré spécifiquement à la théorie Stratide pourra développer ce qui demeure ici à l'état de spécialisation implicite. Il articulera la théorie de la stratification opérante dans son autonomie, indépendamment du domaine particulier des systèmes d'information.

Une deuxième direction est l'extension de l'inventaire architectural : les neuf entités posées dans cet article composent un noyau minimal. Des entités supplémentaires pourront être identifiées par la pratique d'implémentation et de déploiement : patterns récurrents, types spécialisés de Substrats ou de Providers, formes particulières de Contracts ou de Flows.

Une troisième direction est la construction d'un noyau de référence : une implémentation concrète du cadre posé en Section 5, qui servira de base à des produits logiciels particuliers. Ce noyau constituera la première incarnation effective de Stratide Flux, et il fournira un point de départ aux développements ultérieurs.

Une quatrième direction est la conception d'un premier produit logiciel incarnant Stratide Flux : un système de gestion concret pour un domaine métier particulier. Ce produit portera son propre nom et fera l'objet de sa propre documentation. Il manifestera l'architecture-type dans une incarnation effective et opérante, et il alimentera en retour l'enrichissement du cadre.

Ces directions sont articulées : l'enrichissement théorique nourrit l'extension de l'inventaire architectural, qui nourrit le noyau de référence, qui nourrit les produits concrets, qui en retour alimentent la théorie appliquée. La progression est cumulative et réciproque, à l'image de la stratification théorique qu'elle déploie.

6.6 Clôture

Stratide Flux a été posé comme architecture-type lisible pour les systèmes d'information de gestion. L'article a fourni le cadre conceptuel, le régime architectural, le cadre d'implémentation. Il appartient désormais aux équipes qui construiront et qui déploieront cette architecture de la rendre opérante dans leurs contextes propres.

Le présent article se referme sur lui-même comme un régime contextuel de plus dans la stratification théorique : il a son propre centre stabilisé (l'architecture-type Stratide Flux), il s'organise autour de régularités contextuelles documentées, et il préserve son identité pour les développements ultérieurs qui le convoqueront. La théorie qui l'a fondé — La structure lisible — décrit précisément ce mode d'existence des constructions lisibles : posées avec rigueur, ouvertes au contexte, transformables sans perte d'identité.

L'architecture est en place. La construction peut commencer.