Implémentation — Article principal

Le socle stratifié

Quatre strates fonctionnelles, un triangle architectural

Avant-propos

L'article fondateur de Stratide pose la strate comme couche opérante d'un régime, et le régime stratifié comme l'ensemble organisé des strates qui articulent une dynamique. Le présent texte applique cette grille au socle Stratide Flux : il montre comment le socle s'organise en quatre strates fonctionnelles distinctes, comment ces strates s'articulent autour d'un triangle architectural primitif, et comment elles satisfont conjointement les critères de lisibilité opérante posés par l'article fondateur.

L'article est court et ciblé. Il ne décrit pas le détail des entités — c'est l'objet de l'article Les neuf entités. Il ne traite pas non plus de la propagation au sens dynamique — c'est l'objet de l'article La traversée. Il pose la structure interne du socle, et seulement cela.

Six sections. La première situe le socle comme régime. Les deuxième et troisième présentent les strates fonctionnelles et le triangle architectural qui les articule. La quatrième énonce la règle d'or qui gouverne tout le modèle. La cinquième montre comment chaque strate satisfait la lisibilité opérante. La sixième ouvre vers les autres articles de la section.


Section 1 — Le socle comme régime

Le socle Stratide Flux n'est pas un simple ensemble de fonctions. Ce n'est pas non plus une bibliothèque utilitaire. C'est un régime au sens fort : une organisation interne dont chaque partie tient un rôle nommé, dont les parties sont articulées entre elles selon des conditions de traduction explicites, et dont la dynamique d'ensemble peut être décrite, testée, observée.

Cette qualification de régime est structurante. Elle implique trois conséquences directes.

Première conséquence : la stratification est constitutive. Le socle n'est pas réductible à un ensemble plat de modules qui se partageraient des fonctions par voisinage. Il est stratifié. Chaque strate porte une identité fonctionnelle distincte, stabilise ses propres formes, articule les strates voisines selon des conditions de traduction nommées. Cette stratification n'est pas une commodité de présentation : c'est ce qui fait du socle un objet lisible.

Deuxième conséquence : la traversée est le critère de fonctionnement. Un régime stratifié n'opère pas si une dynamique ne le parcourt pas. Le socle est dit fonctionner lorsqu'une traversée — l'exécution d'une transformation entre deux endpoints — peut s'inscrire entièrement, du point d'entrée au point de sortie, en passant par chaque strate fonctionnelle nécessaire. Le régime ne fonctionne pas en pièces : il fonctionne en traversées.

Troisième conséquence : la mobilité est admise. Un régime stratifié peut évoluer — fusionner deux strates, en scinder une, déplacer une articulation — pour autant que les conditions de traduction entre strates voisines restent satisfaites et que la traversée reste possible. Le socle Stratide Flux n'est pas un édifice gelé. Il est un régime mobile, dont les options de déploiement sont une expression directe de cette mobilité.

Le socle comme régime stratifié Stratification constitutive Chaque strate : — porte une identité fonctionnelle distincte — stabilise ses formes — articule ses voisines Le socle est lisible parce qu'il est stratifié Traversée comme critère Le régime opère si et seulement si une dynamique le parcourt entièrement Pas de fonctionnement en pièces — en traversées Mobilité admise Le socle peut : — fusionner deux strates — en scinder une — déplacer une articulation tant que la traduction reste possible Régime mobile Le socle Stratide Flux est un régime, pas une bibliothèque. Il est stratifié, traversable, mobile — par construction. Cette qualification de régime est structurante : elle décide tout ce qui suit.
Figure 1 — Les trois conséquences directes de la qualification du socle comme régime stratifié. La stratification est constitutive, la traversée est le critère de fonctionnement, la mobilité est admise. Aucune de ces propriétés n'est ajoutée après-coup : elles sont impliquées par le statut même de régime.

Ces trois conséquences traversent l'ensemble du socle. Elles fondent le découpage en strates fonctionnelles présenté à la section suivante, l'identification du triangle architectural primitif présenté à la section 3, et les options de déploiement présentées dans l'article dédié.


Section 2 — Quatre strates fonctionnelles

Le socle s'organise en quatre strates fonctionnelles distinctes. Cette typologie n'est pas inventée pour la circonstance : elle reprend la typologie indicative posée par l'article fondateur de Stratide, qui distingue les strates de support, de traitement, de coordination et d'exposition comme les quatre couches opérantes possibles d'un régime.

La strate de support tient la matière du régime. Elle assure la persistance des inscriptions, leur disponibilité, leur résolution. Toute occurrence inscrite dans le socle est nommable par un identifiant universel et résoluble par cette strate. Le support est ce qui fait que ce qui a été inscrit reste, qu'on peut le retrouver, qu'on peut en parler.

La strate de traitement fait évoluer le contenu sans le muter. Une transformation appliquée à une valeur produit un Lease — un bail d'exécution typé — accompagné d'un Flow — la trace de l'exécution elle-même. Ces deux inscriptions sont déposées dans la strate de support. La valeur d'origine n'est pas modifiée : elle reste lisible, et la nouvelle valeur s'obtient par lecture de la trace. La strate de traitement transforme par accrétion, jamais par effacement.

La strate de coordination tient la cohérence d'ensemble. C'est elle qui détient les politiques d'admission des Contracts, les règles d'idempotence, les politiques de collision. C'est elle qui orchestre la mise en relation entre strates. C'est elle qui borde l'usage de l'agent d'analyse en lui interdisant toute écriture directe sur les autres strates. La coordination est le point où l'on décide ce qui peut se traduire d'une strate à l'autre.

La strate d'exposition rend le régime accessible. Elle porte les vues — la trace par notion, le registre des endpoints actifs, le rapport d'audit d'un projet. Elle porte les façades — la couche d'API ergonomique qui présente le socle à un consommateur. Elle porte aussi les expressions adressables — un DSL de description du Flux, un point d'entrée d'audit. L'exposition est ce qui fait que le régime peut être lu de l'extérieur.

Les quatre strates fonctionnelles du socle Exposition Rend le régime accessible Vues · façades · expressions adressables · audit Coordination Tient la cohérence d'ensemble Politiques d'admission · idempotence · orchestration Traitement Fait évoluer le contenu sans muter Transformations → Lease + Flow inscrits Support Tient la matière du régime Persistance · disponibilité · résolution par identifiant universel Chaque strate articule la suivante par des conditions de traduction nommées.
Figure 2 — Les quatre strates fonctionnelles du socle, ordonnées du support au plus exposé. Le support tient la matière. Le traitement fait évoluer le contenu par accrétion. La coordination tient la cohérence. L'exposition rend le tout accessible. Les flèches dénotent les conditions de traduction qui articulent chaque strate à la suivante.

Cette typologie est exhaustive pour le socle. Aucune autre strate fonctionnelle ne s'y trouve. Toute autre découpe — par module technique, par domaine métier, par chemin de fichier — est une découpe orthogonale qui n'épuise pas la stratification fonctionnelle.

L'ordre dans lequel ces strates sont présentées — support, traitement, coordination, exposition — est l'ordre d'opération, pas l'ordre de présentation à l'utilisateur. L'utilisateur d'un socle voit d'abord son exposition. Le concepteur d'un socle pense d'abord son support. Les deux lectures sont valides. Elles décrivent le même régime, lu depuis deux extrémités.


Section 3 — Le triangle architectural

Les quatre strates fonctionnelles s'articulent autour d'une primitive de traversée : le triangle Endpoint–Contract–Endpoint. Ce triangle est l'unité minimale d'une opération significative dans le socle. Toute traversée s'y ramène.

Trois rôles : un Endpoint source, un Contract qui qualifie l'échange, un Endpoint destination. Aucune dynamique du socle n'opère hors de ce triangle. Toute transformation, toute lecture, toute coordination, toute exposition se ramène à un parcours Endpoint → Contract → Endpoint, plus ou moins enrichi.

Le triangle n'est pas une métaphore. C'est la forme effective du modèle. Un Endpoint est une inscription qui désigne un point d'accès à un service ou à une donnée. Un Contract est une inscription qui qualifie un échange admissible entre deux endpoints — type des données échangées, conditions d'admission, politique d'idempotence. La paire Endpoint source — Contract — Endpoint destination est ce qui fait qu'une opération a un sens dans le socle.

Le triangle architectural primitif Endpoint source Contract qualifie l'échange Endpoint destination émission réception Au passage du triangle : → inscription d'un Lease → inscription d'un Flow Aucune dynamique du socle n'opère hors de ce triangle. Toute traversée s'y ramène.
Figure 3 — Le triangle architectural primitif. Endpoint source — Contract — Endpoint destination. Au passage du triangle, deux inscriptions sont produites : un Lease qui matérialise le bail d'exécution, un Flow qui matérialise la trace de l'exécution. La destination n'est jamais mutée.

Ce triangle traverse les quatre strates fonctionnelles selon un ordre fixe :

Ce parcours fait qu'une opération qui aboutit a laissé deux traces inscrites — un bail et un flux — qui suffisent à reconstruire ce qui s'est passé. Pas d'événement séparé. Pas de journal parallèle. La trace de l'opération est l'occurrence qu'elle a inscrite.


Section 4 — La règle d'or

Au cœur du socle, une règle d'or gouverne la totalité du modèle. Elle tient en une phrase :

Une notion s'inscrit dans un contexte. Le résultat de cette inscription est une occurrence. Cette occurrence est l'entité.

Pas autre chose. Pas une structure supplémentaire à fabriquer en plus de l'occurrence. Pas un identifiant à inventer en parallèle. Pas de champs qui flottent à côté.

L'inscription d'une notion dans un contexte donne une occurrence, et cette occurrence est tout ce qui doit exister pour cette inscription-là. Cette règle s'applique à toutes les entités du modèle, sans exception. Substrat, Provider, Dataset, Endpoint, Contract, Lease, Flow, Project, ContractApi : neuf inscriptions distinctes, un seul mécanisme.

La règle d'or — l'inscription comme acte primitif Notion porte l'identité stable, indépendante s'inscrit dans Contexte porte la substance qualification typée produit Occurrence l'entité elle-même identifiant universel = (instance · notion · contexte) immuable une fois inscrite « L'occurrence est l'entité. » Pas de structure supplémentaire — pas d'identifiant parallèle — pas de champs qui flottent.
Figure 4 — La règle d'or matérialisée. Une notion porte l'identité. Un contexte porte la substance. Leur inscription mutuelle produit une occurrence dont l'identifiant est composé du triplet, et qui est immuable une fois inscrite. Toute autre construction est dérivée de ce mécanisme.

La conséquence pratique est massive. Aucune des neuf entités du modèle n'a de structure fondamentale propre. Toutes ont la même forme — un identifiant composé, une notion, un contexte typé — et se distinguent uniquement par le type de leur contexte. Une seule grammaire dans le modèle, neuf grammaires distinctes dans le langage qui le porte. C'est cette unité qui rend le socle homogène.

La conséquence théorique est plus profonde. La règle d'or interdit toute mutation. Si l'occurrence est l'entité, et si l'occurrence est immuable, alors une transition d'état n'est pas une mutation : c'est une nouvelle inscription qui produit une nouvelle occurrence avec un nouvel identifiant. L'ancienne occurrence persiste, comme inscription antérieure de la même notion dans un autre contexte. C'est par accrétion que le modèle évolue, pas par effacement.


Section 5 — Lisibilité opérante des strates

L'article fondateur pose trois critères qu'une strate doit satisfaire pour être dite opérante : porter une identité fonctionnelle distincte, stabiliser ses propres formes au cours du temps, articuler ses voisines selon des conditions de traduction nommées. Une strate qui ne satisfait pas ces trois critères n'est pas opérante : elle est nominale.

Les quatre strates du socle satisfont conjointement ces critères. Le tableau ci-dessous le rend explicite.

Lisibilité opérante des quatre strates Strate Identité fonctionnelle distincte Stabilisation des formes propres Articulation aux strates voisines Support tient la matière persistance et résolution par identifiant universel inscription unique par identifiant, duplicates rejetés opérations d'inscription et de résolution typées Traitement fait évoluer sans muter propagation inscrivante : Lease, Flow, sink intact cycle d'exécution déterministe par clé d'idempotence consomme le Contract résolu, inscrit dans le support Coordination tient la cohérence politiques d'admission des Contracts et d'idempotence règles déclarées au niveau du Project, appliquées uniformément borde le traitement, arbitre l'admission, interdit l'écriture libre Exposition rend accessible vues, registres, audit, façades ergonomiques dérivation pure sur le support — vues stables lit le support, dialogue avec la coordination
Figure 5 — Diagnostic de lisibilité opérante des quatre strates du socle. Chaque strate satisfait les trois critères posés par l'article fondateur : identité fonctionnelle distincte, stabilisation des formes propres, articulation aux strates voisines selon des conditions de traduction nommées. Verdict : régime stratifié opérant.

Ce diagnostic n'est pas formel au sens de la spéculation : il est observable. Chaque ligne du tableau renvoie à un comportement testable du socle. Le support rejette les inscriptions en double, le traitement préserve la valeur d'origine, la coordination applique uniformément ses politiques, l'exposition produit des vues stables. Ces propriétés sont la signature opérante des strates.


Section 6 — Conclusion

Le socle Stratide Flux est un régime stratifié à quatre strates fonctionnelles, articulé autour du triangle Endpoint–Contract–Endpoint, gouverné par la règle d'or qui fait de l'occurrence l'entité elle-même. Cette structure interne est posée. Elle est lisible. Elle est testable.

Trois articles de cette section déclinent ce qui a été ici esquissé. Atomes et inscription entre dans le détail des deux atomes premiers — notion et contexte — et de l'acte qui les noue. Les neuf entités présente le catalogue des inscriptions manipulables dans le socle. La traversée décrit la dynamique qui parcourt les strates et matérialise la propagation inscrivante.

Un quatrième article — Options de déploiement — traite d'une question distincte : comment ce socle, dont la structure interne est posée, peut-il être déployé ? Combien de processus, combien de réplicas, par quels canaux ? Cette question relève d'un autre domaine : celui de la mobilité du régime, telle que l'admet la posture stratifiée. Les options de déploiement qui en découlent — du monolithe in-process à la fédération multi-nœud — préservent toutes les propriétés présentées ici. C'est le sens même de la mobilité : transformer la topologie du déploiement sans défaire la lisibilité du régime.