Implémentation — Propagation

La traversée

Propagation inscrivante, valeur courante par trace, idempotence

La dynamique du socle, parcourue d'un endpoint source à un endpoint destination

Avant-propos

L'article Le socle stratifié a posé le triangle Endpoint–Contract–Endpoint comme primitive de traversée du socle. Le présent texte montre ce qui se passe quand cette traversée a effectivement lieu : comment une transformation parcourt les quatre strates fonctionnelles, quelles inscriptions elle dépose, ce qu'elle ne touche pas.

Cette dynamique est ce qui distingue le plus radicalement Stratide Flux des modèles classiques de propagation. Là où la plupart des systèmes propagent en mutant — la valeur d'un point B devient celle qu'on lui assigne depuis A —, Stratide Flux propage en inscrivant — l'opération laisse une trace explicite sans modifier sa destination. Cette différence n'est pas anecdotique : elle structure tout le rapport du modèle au temps, à l'historique, à la lisibilité.

Sept sections. La première pose la rupture conceptuelle. La deuxième présente le mécanisme de la propagation inscrivante. La troisième détaille le principe de non-mutation. La quatrième explique comment la valeur courante d'un endpoint se résout par lecture de trace. La cinquième traite de l'idempotence. La sixième transpose ces principes à la transition d'état d'une entité quelconque. La septième conclut.

Section 1 — La rupture avec la propagation classique

Dans un modèle classique, propager une transformation consiste à transmettre une valeur d'un point à un autre. La valeur d'origine est calculée, transformée, puis assignée à la destination. Au terme de l'opération, la destination détient la nouvelle valeur. L'origine, elle, a peut-être encore l'ancienne valeur, ou peut-être pas — c'est selon.

Cette manière de propager a une qualité évidente : la simplicité. Elle a aussi un défaut massif : elle efface. Une fois la propagation effectuée, l'historique de ce qui s'est passé n'est plus lisible. La destination contient la valeur courante, mais les valeurs antérieures ne sont nulle part — sauf à les avoir explicitement journalisées dans une structure parallèle.

Stratide Flux refuse cette mécanique. La propagation y est inscrivante. Au lieu de transmettre une valeur en mutant la destination, l'opération inscrit deux nouvelles entités — un Lease et un Flow — qui matérialisent la transformation. La destination, elle, n'est pas touchée.

Deux manières de propager Propagation classique par mutation A v=10 transmet et mute B v=20 B est modifié. L'historique n'est pas conservé Propagation inscrivante par inscription A v=10 inscrit Lease + Flow B intact B est intact. Deux inscriptions tracent l'opération Conséquences de la rupture → L'historique des transformations est conservé par construction. → La valeur courante d'un point est dérivable de sa trace. → Aucune écriture concurrente sur la destination — elle ne change pas. → La trace est l'opération, l'opération est la trace. Pas d'événement séparé.
Figure 1 — Les deux manières de propager. À gauche, la propagation classique par mutation : la valeur de B est écrasée par celle issue de A, l'historique n'est pas conservé. À droite, la propagation inscrivante : B reste intact, deux inscriptions sont déposées qui tracent l'opération. Cette différence structurelle est ce qui rend le modèle Stratide Flux historiquement lisible par construction.

Cette rupture conceptuelle traverse tout le socle. Elle n'est pas un détail d'implémentation : elle est la signature même du modèle. Comprendre la propagation inscrivante, c'est comprendre pourquoi le socle peut prétendre à une lisibilité opérante au sens fort du mot.

Section 2 — La propagation inscrivante

Une traversée du socle commence par une requête de propagation. Cette requête désigne un Contract sous lequel l'opération doit s'exécuter, une valeur source à transformer, et une clé d'idempotence qui identifie l'opération.

Le mécanisme de propagation parcourt sept étapes ordonnées. Aucune n'est facultative ; aucune n'est intervertie.

Les sept étapes de la propagation inscrivante ① Résoudre le Contract à partir de son identifiant universel — le Contract devient l'objet typé de référence ② Vérifier la clé d'idempotence si la clé existe déjà : rejouer le résultat précédent ou rejeter — selon la politique du Project ③ Horodater l'opération le moment de l'opération est figé — il sera porté par toutes les inscriptions à venir ④ Calculer la valeur transformée la transformation est appliquée à la valeur source pour produire la nouvelle valeur ⑤ Inscrire un Lease — état engagé le bail d'exécution est inscrit avec sa nouvelle valeur, son contrat, sa clé d'idempotence ⑥ Inscrire un Flow — état complété le flux d'exécution référence le Lease, porte la même clé, état completé, horodatages ⑦ Aucune mutation du sink l'endpoint destination n'est pas touché — sa qualification précédente reste intacte
Figure 2 — Les sept étapes ordonnées de la propagation inscrivante. Quatre étapes préparatoires (résolution, idempotence, horodatage, calcul). Deux étapes d'inscription (Lease, Flow) — les seules qui modifient le contenu du socle. Une étape négative — la non-mutation du sink — qui n'est pas une absence d'action mais une garantie active du mécanisme.

Au terme de la propagation, deux nouvelles inscriptions sont présentes dans la strate de support — un Lease et un Flow. Ces deux inscriptions, prises ensemble, racontent toute l'opération : sous quel contrat elle s'est exécutée, à quel moment, avec quelle clé d'identification, quelle valeur en a résulté. Aucune autre information n'est nécessaire pour reconstruire ce qui s'est passé.

Section 3 — La non-mutation du sink

Le septième point — la non-mutation du sink — n'est pas une absence d'action. C'est une garantie active du mécanisme. Le socle s'engage à ce que, après une propagation, la qualification de l'endpoint destination soit identique à ce qu'elle était avant l'opération.

Cette garantie peut sembler contre-intuitive. Pourquoi propager si la destination n'est pas modifiée ? La réponse tient au déplacement du centre de gravité du modèle. Dans Stratide Flux, ce qui compte n'est pas la valeur courante d'un endpoint — c'est l'ensemble des inscriptions qui en racontent l'historique. La valeur courante n'est pas une donnée de premier rang ; elle est une dérivée des inscriptions.

Cette garantie a trois conséquences pratiques importantes.

Première conséquence : pas de course à l'écriture. Plusieurs propagations peuvent s'exécuter en parallèle vers le même endpoint sans entrer en conflit pour la modification de sa qualification. Aucune d'elles ne le modifie. Chacune inscrit ses propres Lease et Flow, qui coexistent sans se chevaucher.

Deuxième conséquence : pas d'effet de bord caché. Lire la qualification d'un endpoint n'a aucun lien avec le fait qu'une propagation soit en cours. Les deux opérations sont indépendantes. La lecture d'un endpoint ne dépend que de l'état présent de la strate de support, pas d'une éventuelle écriture concurrente.

Troisième conséquence : reproductibilité totale. Si l'on rejoue la même séquence d'inscriptions, on obtient le même état du socle. Aucune opération ne dépend d'un ordre d'écriture sur une donnée mutable, parce qu'il n'y a pas de donnée mutable.

La non-mutation comme garantie active Avant la propagation Endpoint destination qualification = X Après la propagation Endpoint destination qualification = X   (inchangée) Trois conséquences directes Pas de course à l'écriture Plusieurs propagations en parallèle vers le même endpoint sans conflit. Aucune ne le modifie. Pas d'effet de bord caché Lecture et écriture sont indépendantes. Aucune coordination requise. Reproductibilité totale Rejouer la même séquence d'inscriptions produit le même état. Pas de donnée mutable.
Figure 3 — La non-mutation du sink comme garantie active. La qualification d'un endpoint destination est identique avant et après une propagation. Trois conséquences pratiques : aucune course à l'écriture, aucun effet de bord caché, reproductibilité totale. Ces propriétés font de la concurrence un non-problème — il n'y a pas d'écriture concurrente sur les endpoints.

Section 4 — La valeur courante par lecture de trace

Si l'endpoint n'est pas mis à jour, comment sa valeur courante se détermine-t-elle ? La réponse est précise : la valeur courante d'un endpoint, sous un contrat donné, est la valeur portée par le dernier Lease engagé pour ce contrat. Cette résolution s'opère par lecture de la trace, jamais par écriture sur l'endpoint.

Le mécanisme est simple. Pour connaître la valeur courante d'un endpoint vis-à-vis d'un contrat, on parcourt les Leases inscrits qui référencent ce contrat, on identifie le plus récent dont l'état est engagé ou complété, et on lit son payload. Cette opération est une opération de lecture pure — elle ne modifie rien.

Cette résolution par lecture a une conséquence intéressante : la valeur courante d'un endpoint n'existe pas comme donnée stockée. Elle est calculée à la demande, à partir d'inscriptions qui, elles, sont stockées. Cette inversion — la valeur courante comme dérivée, l'inscription comme primitive — est typique des modèles inscrivants.

La valeur courante par lecture de trace Endpoint destination qualification stable Leases inscrits sous le même contrat Lease ① à t₁ payload = 10 état = complété premier Lease émis Lease ② à t₂ payload = 25 état = complété propagation suivante Lease ③ à t₃ payload = 42 état = complété le plus récent résolution « Quelle est la valeur courante de cet endpoint sous ce contrat ? » → Lecture de la trace : le plus récent Lease engagé porte payload = 42. L'endpoint n'a jamais été muté. Sa valeur courante n'est pas stockée — elle est calculée.
Figure 4 — La valeur courante d'un endpoint comme dérivée de la trace. Plusieurs Leases s'inscrivent successivement sous le même contrat, chacun portant un payload distinct. Pour connaître la valeur courante, on lit la trace et on identifie le Lease le plus récent. L'endpoint lui-même n'est pas modifié — il sert de référence stable, pas de stockage de valeur.

Cette mécanique a un effet important sur la lecture du modèle. Il y a, à tout instant, deux niveaux d'information sur un endpoint : sa qualification stable (ce qu'il est, son rôle, sa fonction) et la trace de ce qui a transité par lui (les valeurs successivement échangées). Ces deux niveaux ne se confondent jamais. La qualification reste stable ; la trace s'enrichit à chaque propagation.

Section 5 — L'idempotence des clés répétées

Une propagation est identifiée par une clé d'idempotence. Cette clé n'est pas une simple curiosité technique : elle est ce qui rend la propagation reproductible. Soumettre deux fois la même clé d'idempotence produit toujours le même résultat — soit l'opération initiale est rejouée, soit elle est rejetée, selon la politique du Project sous lequel elle s'exécute.

Deux politiques d'idempotence sont possibles. La première, le rejeu, retourne le résultat de la première occurrence de la clé sans inscrire de nouveau Lease. Cette politique est utile quand on veut garantir qu'une opération demandée plusieurs fois ne produit qu'un seul effet — typiquement quand un consommateur retentait une opération suite à une perte de connectivité. La seconde, le rejet, retourne une erreur explicite signalant la collision. Cette politique est utile quand on veut détecter les doublons comme anomalies.

Idempotence — deux politiques face à la collision Premier appel propagation avec clé K → Lease ① + Flow ① inscrits Second appel — même clé K Politique : rejeu → Aucun nouveau Lease inscrit → Retourne le résultat ① → Drapeau « rejoué » à vrai Utile quand un consommateur retente une opération qu'il croit avoir échouée. L'effet n'est appliqué qu'une fois. Politique : rejet → Aucun nouveau Lease inscrit → Erreur de collision retournée → Le résultat ① reste accessible Utile quand un doublon doit être détecté comme anomalie. Pas de double exécution silencieuse. La politique est déclarée par le Project. Elle s'applique uniformément à toutes ses propagations.
Figure 5 — L'idempotence des clés répétées. Soumettre deux fois la même clé d'idempotence produit un comportement déterministe : rejeu (l'effet n'est appliqué qu'une fois et le résultat précédent est retourné) ou rejet (la collision est signalée comme anomalie). La politique applicable est déclarée au niveau du Project et s'applique uniformément à toutes ses propagations.

L'idempotence est ce qui permet au socle de fonctionner dans un environnement où les requêtes peuvent être perdues, retentées, dupliquées. Elle garantit qu'une opération a un effet déterministe : soit elle est exécutée une fois, soit elle ne l'est pas, mais jamais deux fois de manière identique sans que cela soit explicitement voulu.

Section 6 — La transition d'état

Le principe de la propagation inscrivante s'étend au-delà des transformations entre endpoints. Il s'applique aussi aux transitions d'état des entités. Quand une entité doit passer d'un état à un autre — un endpoint qui passe d'actif à retiré, un projet qui passe d'ouvert à clos —, la transition n'est pas une mutation de l'entité existante. Elle est une nouvelle inscription qui produit une nouvelle occurrence avec un nouvel identifiant universel.

Cette mécanique est cohérente avec la règle d'or posée dans Atomes et inscription. Si l'occurrence est l'entité, et si l'occurrence est immuable, alors une transition d'état ne peut pas modifier une occurrence existante. Elle inscrit la même notion dans un nouveau contexte — un contexte qui porte le nouvel état —, ce 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.

Cette propriété rend l'historique d'une entité lisible par construction. Pour reconstituer le parcours d'une entité, on parcourt les inscriptions qui partagent la même notion sous la même instance. Cette suite d'inscriptions est la trace de l'entité au fil du temps. Aucune information n'est perdue ; rien n'a été effacé.

La transition d'état comme nouvelle inscription notion partagée stable à travers le temps Occurrence à t₁ contexte « actif » id = i · n · c₁ persiste au-delà de t₂ Occurrence à t₂ contexte « suspendu » id = i · n · c₂ persiste au-delà de t₃ Occurrence à t₃ contexte « retiré » id = i · n · c₃ qualification courante Trois identifiants distincts. Trois occurrences distinctes. Une seule notion partagée. Trois qualifications successives. L'historique est lisible — par lecture des inscriptions successives sur la même notion.
Figure 6 — La transition d'état comme nouvelle inscription. Quand un endpoint passe d'actif à suspendu puis à retiré, trois occurrences distinctes sont produites — une par étape — qui partagent toutes la même notion. Aucune n'est effacée. La qualification courante est portée par la dernière inscription ; l'historique complet est lisible par parcours des inscriptions qui partagent cette notion.

Le principe est uniforme entre la propagation inter-endpoints et la transition d'état d'une entité. Dans les deux cas, la dynamique du modèle s'exprime par accrétion. Aucune mutation. Aucun écrasement. Tout ce qui a été inscrit reste, et l'évolution se lit dans la suite des inscriptions plutôt que dans l'état présent d'un objet.

Section 7 — Conclusion

La traversée du socle Stratide Flux est inscrivante par construction. Une transformation entre endpoints inscrit deux nouvelles entités — Lease et Flow — sans modifier la destination. Une transition d'état d'une entité produit une nouvelle occurrence avec un nouvel identifiant, sans effacer la précédente. Dans les deux cas, le modèle évolue par accrétion. Rien ne se perd parce que rien n'est écrasé.

Cette propriété est ce qui rend le socle lisible dans le temps. À tout moment, l'historique de toute opération est reconstituable par lecture de la trace. Aucune information n'a besoin d'être journalisée à part — la trace est l'opération, l'opération est la trace. Cette identification entre le fait et son inscription est la signature de la propagation inscrivante.

L'article suivant, Options de déploiement, traite d'une question distincte : comment ce socle, dont la dynamique interne est posée, peut-il être déployé ? Quatre topologies typées sont possibles, du monolithe in-process à la fédération multi-nœud. Toutes préservent les propriétés présentées dans cet article — c'est même ce qui les rend admissibles. La mobilité du régime est la condition de cette diversité topologique sans dégradation des invariants.