Les neuf entités

Neuf inscriptions, un seul mécanisme

Le catalogue des entités manipulables dans le socle Stratide Flux

Avant-propos

L'article Atomes et inscription a posé le mécanisme : une notion s'inscrit dans un contexte, le résultat est une occurrence. Le présent texte présente les neuf entités effectivement manipulables dans le socle. Chacune est une occurrence au sens strict — produite par inscription — distinguée des autres uniquement par le type du contexte qui la qualifie.

Cette unité du mécanisme combinée à la diversité des entités est la signature même du modèle. Une seule grammaire, neuf manifestations. L'article parcourt les neuf entités groupées en quatre familles : les fondations qui portent l'exécution, la matière manipulée, les inscriptions d'exécution, les inscriptions de gouvernance.

Sept sections. La première donne la vue d'ensemble. Les quatre suivantes parcourent les familles. La sixième traite du principe de référence par identifiant universel. La septième conclut.

Section 1 — Vue d'ensemble

Le socle manipule neuf entités. Aucune n'a de structure fondamentale propre : toutes sont des occurrences au sens posé dans l'article précédent. Ce qui les distingue, c'est le type du contexte qui les qualifie — et donc la nature de leur substance.

Les neuf entités se groupent en quatre familles fonctionnelles distinctes.

Figure 1 — Vue d'ensemble des neuf entités du socle, regroupées en quatre familles fonctionnelles. Fondations (Substrat, Provider) pour porter l'exécution. Matière (Dataset, Endpoint, Contract) pour qualifier les données et les échanges. Exécution (Lease, Flow) pour matérialiser les transformations. Gouvernance (Project, ContractApi) pour déclarer les politiques.

Cette typologie n'est pas hiérarchique. Aucune entité n'a de privilège sur une autre. Toutes sont des occurrences ; toutes peuvent être inscrites, résolues, parcourues. Ce qui les rapproche dans une famille n'est pas une parenté de structure mais une parenté de rôle dans l'organisation du régime.

Section 2 — Fondations : Substrat, Provider

Les deux entités fondamentales sont le Substrat et le Provider. Elles désignent ce qui porte l'exécution du socle : la matière physique sur laquelle il s'exécute, et le fournisseur de services qui s'y appuie.

Un Substrat est une qualification du substrat physique d'exécution. Il porte un régime déclaré — ce que le substrat se présente comme étant — et une fonction — ce qu'il fait. Le Substrat est la première inscription qui apparaît dans un socle : il est l'inscription du fait que le socle s'exécute.

Cette circularité — le socle inscrit son propre support d'exécution — n'est pas un paradoxe. C'est une co-fondation. Le socle a besoin d'un Substrat pour exister, et le Substrat a besoin du socle pour être inscrit. Les deux apparaissent simultanément. Cette inscription première est ce qui rend toute autre inscription possible.

Un Provider est une qualification d'un fournisseur de service. Il porte un moteur — ce qui exécute la fonction —, une fonction — ce que le service rend —, et une référence vers son substrat. Le Provider est ce qui permet à des consommateurs de s'adresser à des services typés, sans connaître les détails de leur substrat.

Figure 2 — Substrat et Provider, les deux entités fondamentales. Le Substrat porte l'exécution — il est la première inscription du socle, qui co-fonde le socle et le support sur lequel il s'exécute. Le Provider porte un service — il référence un Substrat et expose une fonction au reste du modèle.

Au démarrage du socle, les deux entités sont inscrites en parallèle dans la strate de support. Le couple Substrat–Provider est ce qui rend visible, dans le modèle lui-même, l'identité du socle qui l'exécute.

Section 3 — Matière : Dataset, Endpoint, Contract

La matière manipulée par le socle se présente sous trois formes : les jeux de données, les points d'accès, les contrats d'échange.

Un Dataset est une qualification d'un jeu de données. Il porte un schéma — la forme des données qu'il représente —, une version — la révision qu'il décrit —, un domaine — la zone applicative à laquelle il appartient. Le Dataset n'est pas la donnée elle-même : il est la qualification de la donnée. Il dit ce qu'on peut attendre d'un certain ensemble de valeurs sans contenir ces valeurs.

Un Endpoint est une qualification d'un point d'accès. Il porte un rôle — ce que ce point d'accès est censé faire dans l'écosystème —, et facultativement une fonction, un déploiement, une autorisation, un projet de rattachement. L'Endpoint est l'adresse typée par laquelle un consommateur s'adresse au socle pour lire ou alimenter une donnée.

Un Contract est une qualification d'un échange admissible entre deux endpoints. Il porte la définition du payload échangé, sa version, ses contraintes d'admission. Le Contract est ce qui rend un échange légitime dans le socle : un échange entre deux endpoints sans Contract qui le couvre est un échange inadmissible.

Figure 3 — La famille de la matière. Le Dataset qualifie une donnée sans la contenir. L'Endpoint qualifie un point d'accès. Le Contract qualifie un échange admissible. Ces trois entités s'articulent pour former le triangle architectural primitif Endpoint–Contract–Endpoint, qui est la seule unité significative d'opération dans le socle.

Cette famille porte la matière du socle au sens fonctionnel. Elle ne s'occupe pas des transformations — c'est l'objet de la famille suivante. Elle pose les objets sur lesquels les transformations s'appliqueront.

Section 4 — Exécution : Lease, Flow

Quand une transformation s'exécute dans le socle, elle ne mute rien. Elle inscrit deux objets supplémentaires : un Lease et un Flow. Ces deux entités forment la trace inscrite de l'exécution.

Un Lease est une qualification d'un bail d'exécution. Il porte le type d'opération, le contrat sous lequel l'opération s'exécute, une clé d'idempotence qui l'identifie de manière reproductible, le payload résultant de la transformation, son état d'exécution. Le Lease est ce qui dit qu'une transformation a été engagée sous un certain contrat.

Un Flow est une qualification d'un flux d'exécution. Il porte le type de flux, la référence au Lease qu'il instancie, la même clé d'idempotence, son état (engagé, complété, échoué), ses horodatages de début et de fin. Le Flow est ce qui dit qu'une transformation a été parcourue, du début à la fin, dans une exécution donnée.

La distinction entre Lease et Flow n'est pas redondante. Le Lease est l'engagement contractuel ; le Flow est l'exécution effective. Plusieurs Flows peuvent référencer un même Lease — pour autant qu'ils soient gardés par leur clé d'idempotence et que la politique de collision le permette. Cette distinction est ce qui permet de séparer le permis d'exécuter de l'acte d'avoir exécuté.

Figure 4 — Lease et Flow, les deux inscriptions d'exécution. Le Lease porte l'engagement contractuel — quel contrat est mis en jeu, quelle valeur résulte, quelle clé d'idempotence l'identifie. Le Flow porte l'acte effectif — la référence au Lease, l'état d'avancement, les horodatages. Toute transformation produit le couple, jamais l'un sans l'autre.

Cette dualité Lease–Flow est ce qui matérialise la propagation inscrivante du socle : à chaque transformation, deux inscriptions distinctes mais corrélées sont déposées. Ces deux inscriptions, lues conjointement, racontent toute l'opération — son intention, son exécution, son résultat. La destination de la transformation, elle, n'a pas changé. C'est la particularité du modèle, traitée en détail dans La traversée.

Section 5 — Gouvernance : Project, ContractApi

Au-dessus de la matière et de l'exécution, deux entités portent les politiques qui gouvernent l'usage du socle : le Project et la ContractApi.

Un Project est une qualification d'une unité de gouvernance. Il porte un domaine de gouvernance — la zone d'application des politiques —, un ensemble de politiques d'admission, une politique d'idempotence, des règles de collision. Le Project est l'objet par lequel des règles déclaratives sont rattachées à un sous-ensemble du modèle. Quand une opération est exécutée sous un Project, les politiques de ce Project s'appliquent uniformément.

Une ContractApi est une qualification d'une coordination inter-projets. Elle porte un périmètre de gouvernance qui dépasse celui d'un Project unique — typiquement une ligne directrice partagée entre plusieurs projets, des politiques globales applicables à plus d'une zone. La ContractApi est ce qui permet d'articuler des règles à un niveau plus large que celui du Project sans pour autant rendre toutes les règles globales.

Figure 5 — La famille de la gouvernance. Plusieurs Projects coexistent dans le socle, chacun porteur de ses propres politiques. Une ContractApi articule des règles transversales applicables à plusieurs Projects. Cette stratification de la gouvernance permet d'avoir des règles locales fines tout en maintenant une cohérence d'ensemble.

La gouvernance par Project est ce qui rend le socle adaptable à des contextes applicatifs distincts. Chaque application qui consomme le socle peut déclarer son propre Project, avec ses propres politiques, sans interférer avec les autres. Le socle, lui, applique uniformément les règles déclarées par chaque Project sur les opérations qui s'y rattachent.

Section 6 — Références par identifiant universel

Une propriété structurante traverse les neuf entités : aucune entité ne contient une autre entité par valeur. Toutes les références entre entités passent par identifiant universel.

Quand un Lease référence un Contract, il ne contient pas le Contract — il contient l'identifiant universel du Contract. Quand un Flow référence un Lease, il contient l'identifiant universel du Lease. Quand un Endpoint est rattaché à un Project, il contient l'identifiant universel du Project. Cette propriété est uniforme.

Les conséquences sont multiples. Premièrement, la sérialisation des entités est triviale — chaque entité est un objet plat de taille bornée. Deuxièmement, le partage est massif et sans copie — plusieurs entités peuvent référencer le même objet sans le dupliquer. Troisièmement, les cycles de propriété sont impossibles — aucune entité ne peut s'imbriquer dans une autre. Quatrièmement, la traversée du modèle est lisible — partir d'un identifiant et résoudre les références produit un cheminement explicite.

Figure 6 — Le principe de référence par identifiant universel. Aucune entité ne contient une autre entité par valeur ; toutes les flèches inter-entités sont des identifiants. Cette propriété structurelle est ce qui rend le modèle homogène, sérialisable, partageable et dépourvu de cycles de propriété.

Ce principe a aussi un effet sur la lecture du modèle : pour comprendre une opération, il suffit de partir d'un identifiant et de suivre les références. Chaque identifiant universel résoud à une occurrence ; chaque occurrence porte ses propres références sortantes. La traversée est explicite, déterministe, et ne nécessite aucun mécanisme caché.

Section 7 — Conclusion

Neuf entités, quatre familles, un seul mécanisme. Les fondations portent l'exécution. La matière qualifie les données et les échanges. L'exécution inscrit la trace des transformations. La gouvernance déclare les politiques applicables. Tout repose sur une seule grammaire — l'inscription d'une notion dans un contexte typé — et un seul principe de référence — l'identifiant universel comme clé exclusive entre entités.

Cette unité est ce qui rend le modèle homogène. Apprendre une entité, c'est apprendre toutes les entités, parce qu'elles partagent toutes la même structure profonde. Comprendre comment référencer un Contract, c'est comprendre comment référencer n'importe quelle autre entité, parce que la référence se fait par identifiant universel partout.

L'article suivant, La traversée, montre comment ces neuf entités s'articulent dans la dynamique du socle. La propagation inscrivante y prend tout son sens : à chaque transformation, deux nouvelles entités d'exécution sont inscrites, qui matérialisent l'opération sans muter sa destination. C'est là que les neuf entités de ce catalogue se rencontrent dans une opération vivante.