--- title: "Pourquoi votre ordinateur se souvient-il de tout sans rien comprendre ?" code: "RP-0108" language: "fr" canonical: "https://regentspark.ai/fr/RP-0108/" html: "https://regentspark.ai/fr/RP-0108/" markdown: "https://regentspark.ai/fr/RP-0108.md" updated: "4 April 2026" --- # Note de recherche 011 — État et mémoire : le problème de granularité *Tout est un registre. La question est la langue que l'on utilise pour parler des reçus.* La mémoire numérique couvre un spectre immense, depuis les piles d'annulation de moins d'une seconde jusqu'aux ancres permanentes de blockchain, mais chaque couche a été construite par une équipe différente, sans lien avec les couches au-dessus ou au-dessous. Les CRDT capturent des opérations au niveau de la frappe avec fusion automatique. Git capture des commits intentionnels et annotés. L'event sourcing et les bases temporelles font du temps un élément de premier rang. Bitcoin apporte une permanence soutenue par l'énergie. Entre chaque paire de couches se trouve un vide : aucun système ne permet de promouvoir en douceur un état CRDT en version nommée, une sauvegarde de fichier en commit significatif, ou un commit en enregistrement permanent. La conclusion de la v1, construire un registre unifié couvrant tout le spectre, était fausse. C'est le piège de la super app appliqué à la mémoire. La pièce réellement manquante est un **vocabulaire partagé de l'intention de mémoire** : un petit ensemble de déclarations (éphémère, travail, jalon, enregistrement, permanent) que n'importe quel système peut comprendre et appliquer. Ce vocabulaire permet promotion et rétrogradation entre niveaux, donne à l'IA la capacité de comprendre votre intention, rend de l'agency aux utilisateurs, et rend les systèmes existants interopérables sans les remplacer. L'oubli devient le comportement par défaut des niveaux inférieurs : les événements se dégradent sauf promotion explicite, comme la mémoire humaine compresse et jette pour préserver le sens. **Série :** Les quatre primitives **Statut :** v2.1 **Date :** 4 avril 2026 --- ## Ce que vous faites déjà > **Résumé :** Un seul paragraphe traverse tout le spectre de la mémoire, des piles d'annulation à la notarisation blockchain, et révèle que chaque couche a été construite indépendamment, sans lien avec les autres. Votre ordinateur se souvient de tout et ne comprend rien. C'est le problème de granularité. Vous écrivez un e-mail. Vous tapez une phrase, vous hésitez, vous en supprimez la moitié, vous la retapez. Vous n'y pensez pas. Vos doigts frappent les touches, la pile d'annulation capture chaque caractère, et si vous appuyez cinq fois sur Ctrl-Z vous revenez cinq étapes en arrière. Cette mémoire dure quelques secondes. Au moment où vous envoyez l'e-mail, tous les états intermédiaires, chaque mot supprimé, chaque hésitation, ont disparu. Reculez. L'e-mail parle d'un plan de projet. Ce plan vit dans un Google Doc que Sarah et vous modifiez depuis deux semaines. Le document a un historique de versions : vous pouvez remonter des instantanés nommés, voir qui a changé quoi, à peu près quand. Cette mémoire dure des semaines, peut-être des mois. Elle capture les grandes lignes, pas les frappes. Reculez encore. Le plan devient une décision. La décision est consignée dans des notes de réunion. Les notes renvoient à un ticket Jira. Le ticket renvoie à un commit git. Le commit fait partie d'une release. La release est taguée, versionnée, déployée. Six mois plus tard, quelqu'un demande « pourquoi avons-nous construit cela ainsi ? » et la réponse est dispersée dans cinq systèmes qui ne se connaissent pas. Reculez une dernière fois. Les transactions financières de l'entreprise sont dans un registre. Le registre est audité. Certaines entrées sont notariées. Quelques-unes sont ancrées dans une blockchain. Ces enregistrements sont censés durer des décennies, des siècles. Ils sont conçus pour être indéniables. Vous venez de traverser tout le spectre de la mémoire informatique moderne, de l'annulation sous la seconde à la notarisation permanente, en un seul paragraphe. Et vous l'avez sans doute remarqué : chaque couche a été construite par une équipe différente, pour un objectif différent, sans lien avec les couches au-dessus ou au-dessous. La pile d'annulation ne connaît pas l'historique de versions. L'historique de versions ne connaît pas les commits git. Git ne connaît pas la blockchain. Chaque système a choisi une granularité et s'est arrêté là. C'est le problème de granularité. La mémoire en informatique n'est pas absente ; elle est fragmentée entre une douzaine de systèmes qui traitent chacun une tranche du spectre temporel. Résultat : votre ordinateur se souvient de tout et ne comprend rien. --- ## Le spectre > **Résumé :** Toute forme de mémoire numérique se place sur deux axes : granularité (à quel point est-elle fine ?) et permanence (combien de temps est-elle gardée ?). L'agency passe de l'automatique à l'extrémité éphémère à l'intentionnel à l'extrémité permanente. Aucun système ne couvre plus de deux ou trois couches adjacentes, et le coût augmente avec la permanence. Le motif unificateur est état = f(événements) : chaque couche est un journal d'événements qui diffère par ce qui compte comme événement, sa durée de conservation et son modèle de confiance. Mais reconnaître un motif commun ne veut pas dire qu'il faut un seul système. Cartographions. Toute forme de mémoire numérique peut être placée sur un plan défini par deux dimensions : **granularité** (la finesse des unités enregistrées) et **permanence** (la durée de conservation). Ces dimensions sont liées mais distinctes. Un CRDT capture des opérations fines qui peuvent persister toute la vie du document. Une sauvegarde de fichier est plus grossière, vous avez choisi de sauvegarder, mais peut disparaître quand vous videz la corbeille la semaine suivante. Une entrée blockchain est l'unité la plus grossière (un hash, une transaction) mais la chose la plus permanente en informatique. ```mermaid block-beta columns 4 space:1 A["← Fin"]:2 B["Curaté →"]:1 C["Permanent ↑"]:1 CRDT["🔄 Ops CRDT\n(fines, durables)"]:1 space:1 BTC["⛓️ Bitcoin\n(curaté, permanent)"]:1 space:1 AUTO["💾 Autosave"]:1 GIT["📦 Commit Git"]:1 LED["📒 Entrée de registre"]:1 D["Éphémère ↓"]:1 UNDO["⏱️ Pile d'annulation\n(fine, secondes)"]:1 FILE["📄 Sauvegarde fichier"]:1 REL["🏷️ Tag de release"]:1 ``` *Deux dimensions : vertical = permanence (éphémère en bas, permanent en haut). Horizontal = granularité (fin à gauche, curaté à droite). La couleur encode les deux : chaud/orange = opérations fines, froid/bleu-violet = enregistrements curatés.* | Couche | Granularité | Permanence | Exemple | Qui décide ? | |-------|-----------|-----------|---------|-------------| | Pile d'annulation | Frappe | Session (minutes) | Ctrl-Z dans un éditeur | Le système, automatiquement | | Opérations CRDT | Caractère/opération | Vie du document | Automerge, Yjs | Le protocole, automatiquement | | Autosave | Instantané périodique | Jours/semaines | Google Docs, Apple Notes | Le système, sur minuteur | | Sauvegarde fichier | Instantané déclenché par l'utilisateur | Jusqu'à suppression | Cmd-S | L'humain, intentionnellement | | DHT BitTorrent | Hash de contenu + pairs | Tant qu'il y a des seeders (heures-années) | Mainline DHT | L'essaim, collectivement | | Commit Git | Changeset curaté | Vie du dépôt | `git commit -m "..."` | L'humain, avec message | | Version/release | Jalon tagué | Vie du produit | `v2.1.0` | L'équipe, avec cérémonie | | Entrée de registre | Événement métier | Période réglementaire | Facture, écriture comptable | L'organisation, par politique | | Ancre Bitcoin | Engagement de hash | Indéfini | OP_RETURN, OP_TIMESTAMP | Le réseau, par consensus soutenu par l'énergie | Trois choses sautent aux yeux. D'abord, **l'agency se déplace vers la permanence.** À l'extrémité éphémère, le système se souvient automatiquement : vous ne choisissez pas de peupler la pile d'annulation. À l'extrémité permanente, se souvenir exige une action délibérée et un coût réel. Personne n'ancre accidentellement quelque chose sur Bitcoin. Le spectre va de l'automatique à l'intentionnel. Ensuite, **aucun système ne couvre plus de deux ou trois couches adjacentes.** Google Docs couvre l'autosave et un historique de versions grossier. Git couvre commits et releases. Une blockchain couvre ses propres entrées. Rien ne relie l'annulation à la blockchain. Rien ne donne une vue unifiée de « ce qui est arrivé à cette chose, à toutes les échelles, depuis sa création ». Enfin, **le coût augmente avec la permanence.** La RAM est bon marché et fugace. Le disque est bon marché et durable. Une table de hachage distribuée exige que des pairs restent en ligne. Une blockchain exige de l'énergie réelle, physique, continue, pour garantir l'irréversibilité des enregistrements. Ce n'est pas un défaut. C'est la physique fondamentale de la mémoire : la permanence a un prix. ### Le motif unificateur Y en a-t-il un ? « Tout est un registre, en un sens », disait Nico. À chaque couche, le même motif se répète : 1. **Quelque chose arrive** (une frappe, une modification, un commit, une transaction) 2. **C'est enregistré** (dans un buffer, un journal, un DAG, une chaîne) 3. **L'état est dérivé de l'enregistrement** (le document courant, la dernière version, le solde du compte) État = f(événements). Ce n'est pas une observation nouvelle : c'est l'intuition fondatrice de l'event sourcing, de Datomic de Rich Hickey, de tout le mouvement append-only. Chaque couche du spectre est un journal d'événements. Ce qui diffère : - **Ce qui compte comme événement** (frappe contre commit contre transaction) - **Combien de temps les événements sont gardés** (session contre toujours) - **Qui décide quoi enregistrer** (système contre humain contre consensus) - **Quel modèle de confiance gouverne le journal** (local contre répliqué contre tolérant aux fautes byzantines) - **Quelle énergie soutient la permanence** (électrons en RAM contre preuve de travail) Le motif est universel. Mais, et c'est là que la v1 de cette note se trompait, reconnaître un motif partagé ne veut pas dire qu'il faut un système unique. On ne construit pas un seul tuyau pour l'eau potable, les eaux usées et le gaz naturel simplement parce que ce sont tous des « fluides dans des tubes ». Différentes couches de permanence ont différentes physiques, différents coûts, différents modèles de confiance. Elles ont besoin de systèmes différents. Ce qui manque n'est pas un registre unifié. C'est une **langue** partagée pour parler de mémoire entre ces couches. ```mermaid flowchart LR E(["Quelque chose\narrive"]) --> R[("C'est\nenregistré")] --> S["L'état est\ndérivé"] ``` *Le motif universel : état = f(événements). Chaque couche de mémoire suit cela ; ce qui diffère est la granularité des événements, la durée de conservation et le modèle de confiance.* Personne n'a construit cette langue. Regardons qui a construit les couches. --- ## CRDT et état partagé > **Résumé :** Les CRDT fusionnent deux couches du spectre en une : détail au niveau de la frappe ET persistance au niveau du document. Un document CRDT EST son historique complet d'édition. Mais cette force crée des problèmes : croissance illimitée, pas de frontières sémantiques, pas de chemin vers l'historique de versions significatif. Les CRDT ont résolu le bas du spectre avec une élégance extraordinaire, mais ils ne se connectent pas aux couches supérieures. ### La révolution local-first En 2019, Ink & Switch a publié un essai qui a discrètement changé la manière dont une génération de développeurs pense au logiciel. « Local-first software: You own your data, in spite of the cloud » exposait sept idéaux pour un logiciel qui fonctionne localement, se synchronise quand c'est possible, et ne prend jamais vos données en otage sur un serveur. Kleppmann, M., Wiggins, A., van Hardenberg, P., & Gentle, M. (2019). Local-first software: You own your data, in spite of the cloud. Onward! 2019. Les sept idéaux : rapide, multi-appareil, hors ligne, collaboratif, durable, sûr/privé, propriété utilisateur. Au cœur de leur proposition : les **Conflict-free Replicated Data Types** (CRDT). Au lieu d'envoyer vos modifications à un serveur central qui arbitre les conflits, chaque appareil maintient sa propre copie des données. Les modifications sont des opérations qui peuvent être appliquées dans n'importe quel ordre et convergent vers le même résultat. Pas de serveur nécessaire. Pas d'interface de résolution de conflit. Pas de « quelqu'un d'autre édite cette section ». Les trois grandes implémentations CRDT pour le texte : **Automerge** : projet de recherche de Martin Kleppmann, aujourd'hui à la Technical University of Munich. Modélise les documents comme un arbre d'objets et tableaux imbriqués, chaque élément étant suivi par un identifiant d'opération unique. Stocke l'historique complet des opérations, donc tout état passé est récupérable. La dernière version utilise un encodage en colonnes qui a réduit la taille des documents de 50 à 90 fois. Kleppmann, M. & Gentle, S. (2020). Automerge: Real-Time Collaborative Text Editing with CRDTs. Travail plus large de Kleppmann : Designing Data-Intensive Applications (O'Reilly, 2017). **Yjs** : implémentation JavaScript de Kevin Jahns, probablement la bibliothèque CRDT la plus déployée en production. Utilisée par Notion, JupyterLab et de nombreux éditeurs collaboratifs. Optimisée pour les motifs d'édition réels : pragmatique plutôt que théoriquement élégante. **Diamond Types** : implémentation Rust de Seph Gentle, environ 5 000 fois plus rapide que les implémentations CRDT précédentes pour fusionner des modifications concurrentes. Son billet « CRDTs go brrr » a montré que les coûts de performance longtemps attribués aux CRDT relevaient de l'implémentation, pas de limites fondamentales. Gentle, S. (2021). CRDTs go brrr. Diamond Types a montré que des choix soignés de structures de données pouvaient éliminer la majorité du surcoût CRDT. Source : github.com/josephg/diamond-types. ### Ce que sont les CRDT, en termes de mémoire Un CRDT est un journal d'événements avec fusion automatique. Chaque édition est une opération. Le document à tout moment est l'état dérivé de l'application de toutes les opérations. C'est le motif « état = f(événements) » au niveau de la frappe. Ce qui rend les CRDT particuliers, c'est qu'ils fusionnent deux couches du spectre de granularité. Le journal d'opérations capture le détail au niveau de la frappe ET fournit une persistance au niveau du document. Un document CRDT EST son historique complet d'édition. Ouvrez un document Automerge vieux d'un an et vous pouvez rejouer chaque frappe, chaque session de collaboration, dans l'ordre. Cela signifie qu'un document CRDT ne stocke pas seulement ce que la chose EST ; il stocke comment elle EST DEVENUE ce qu'elle est. Le processus, pas seulement le produit. ### Ce que les CRDT ne résolvent pas Mais cette force crée des problèmes qui correspondent directement au problème de granularité. **Croissance illimitée.** Chaque opération jamais appliquée est stockée pour toujours. Supprimez un caractère et la suppression est enregistrée comme tombstone : un marqueur qui dit « cet élément était ici et ne l'est plus ». Le tombstone ne peut jamais être supprimé, parce qu'un pair qui n'a pas encore vu la suppression pourrait essayer d'insérer près de l'élément supprimé. Un document d'une page avec dix ans d'édition collaborative peut peser des mégaoctets. Problème des tombstones CRDT : voir la discussion IPFS sur la garbage collection CRDT et le design de garbage collection de Yorkie. Tension centrale : les tombstones sont nécessaires à la correction pendant l'édition concurrente, mais inutiles une fois tous les pairs synchronisés. **La garbage collection est difficile.** Vous pouvez supprimer des tombstones SI vous savez que tous les pairs ont vu la suppression. Mais « savoir que tous les pairs ont vu quelque chose » exige une coordination, exactement ce que les CRDT évitent. Oublier exige de l'accord, alors que tout le point était d'éviter d'exiger de l'accord. **Pas de frontières sémantiques.** Les CRDT enregistrent TOUT. Chaque frappe. Chaque mouvement de curseur. Mais ils ne distinguent pas « j'explore une idée » de « j'ai décidé que c'est la version finale ». Il n'y a pas de concept intégré de commit, de version, de jalon. La granularité est fixée au niveau le plus fin. Vous ne pouvez pas dire au CRDT : « souviens-toi de ce moment comme important ». Ce dernier point est le nœud. Les CRDT ont résolu le bas du spectre, mémoire partagée en temps réel au niveau des opérations, avec une élégance extraordinaire. Mais ils ne se connectent pas vers le haut. Il n'y a pas de chemin du « journal d'opérations CRDT » vers un « historique de versions significatif ». L'écart entre journal d'opérations et commit git reste non comblé. --- ## Le contrôle de version comme mémoire > **Résumé :** Git implémente accidentellement quelque chose de proche de la mémoire humaine : les commits sont du rappel intentionnel, les branches des lignes temporelles parallèles, les merges des réconciliations, les tags des repères. Mais git est enchaîné au texte : son modèle de DAG d'instantanés vaut pour tout, mais pas sa machinerie de diff/merge. L'écart critique : aucun pont n'existe entre journaux d'opérations CRDT et commits à la Git. Promouvoir un moment CRDT en version nommée devrait être fluide, et promouvoir des versions en releases ou enregistrements devrait l'être aussi. C'est cette chaîne de promotion ascendante qu'aucun système existant ne soutient. ### Le modèle involontaire de mémoire humaine de Git Git n'est pas un système de contrôle de version. Enfin si, mais cette description sous-estime ce que Linus Torvalds a vraiment construit. Git est une **machine d'historique adressable par contenu, append-only, structurée en DAG**. Et il implémente accidentellement quelque chose de remarquablement proche de la mémoire humaine. Torvalds, L. (2005). Git source code management. Git Internals: Git Objects : « Git is a content-addressable filesystem. At the core of Git is a simple key-value data store. » Git stocke quatre types d'objets (blobs, trees, commits, tags), chacun identifié par le hash SHA de son contenu. Un commit pointe vers un tree (l'état du projet à ce moment) plus son ou ses parents. Cela crée un **graphe acyclique dirigé** (DAG) d'instantanés, où chaque instantané est une image complète à un moment donné. Correspondances avec la mémoire humaine : **Un commit est un acte de rappel intentionnel.** Vous ne committez pas chaque frappe ; vous committez quand quelque chose de significatif est arrivé. « Fixed the login bug. » « Restructured the essay. » Chaque commit est un moment que vous avez *choisi* de retenir, accompagné d'un message expliquant *pourquoi*. C'est une mémoire épisodique : encoder des moments nouveaux, émotionnels ou importants, avec un sens narratif. **Les branches sont des lignes temporelles parallèles.** « Et si nous essayions une approche complètement différente ? » La mémoire humaine fait quelque chose de similaire : nous maintenons des récits contrefactuels à côté des récits réels. **Le merge est une réconciliation.** Quand deux branches se rejoignent, git réconcilie les différences. Parfois proprement, parfois avec des conflits qui exigent un jugement humain. Cela ressemble à ce qui se passe quand deux personnes se souviennent différemment du même événement. **Les tags sont des repères.** « v2.0 » : un moment désigné comme particulièrement significatif. Tous les commits ne reçoivent pas de tag. Seulement les jalons. La mémoire humaine fonctionne pareil : anniversaires, diplômes, premiers jours. La plupart des jours se brouillent ; les jours tagués persistent. ### Pourquoi git ne marche que pour le texte Malgré cette élégance structurelle, git est enchaîné au texte. Essayez de versionner un fichier Figma. Vous pouvez le stocker, git suivra n'importe quel blob binaire, mais vous ne pouvez pas le différencier, le fusionner, ou voir un historique de changements significatif. Deux versions d'un fichier Figma sont opaques pour git. Ce n'est pas une limite du modèle de données de git : le DAG d'instantanés marche pour tout. C'est une limite de la **machinerie de diff et merge**, qui opère sur des lignes de texte. Le concept, des instantanés liés par des commits intentionnels et des messages, est universel. L'implémentation ne l'est pas. Cela compte parce que la plupart des choses que les gens créent ne sont pas des fichiers texte. Ce sont des designs, tableurs, présentations, bases de données, canvases, enregistrements audio. Le modèle git, mémoire intentionnelle, annotée, structurée en DAG, est exactement juste. Il doit seulement marcher pour tout. La note 008 introduisait indépendamment cette idée : « les versions sont des entités liées par `derivedFrom` ». C'est le graphe de commits de git, exprimé en termes d'entités et relations. L'historique de version n'est pas une métadonnée cachée dans une couche de stockage : c'est une relation structurelle entre entités. ### L'écart entre CRDT et git Voici l'écart que personne n'a comblé. Les CRDT donnent une mémoire automatique au niveau des opérations en bas. Git donne une mémoire intentionnelle au niveau des commits au milieu. Mais il n'y a pas de pont. Imaginez : vous écrivez dans un éditeur alimenté par CRDT. Chaque frappe est capturée. Puis vous vous arrêtez, relisez, et pensez : « bon point d'arrêt ». Vous devriez pouvoir promouvoir ce moment du journal d'opérations CRDT en version nommée, un « commit » au sens de git, sans quitter l'éditeur, sans changer d'outil. Et plus tard, vous devriez pouvoir promouvoir cette version plus loin : en artefact publié, en document publié, en jalon tagué. Chaque promotion déplace la mémoire vers le haut de l'axe de permanence, ajoutant intentionnalité et métadonnées tout en pouvant jeter le détail inférieur. Cette promotion ascendante, de la frappe à la version, de la version à la release, de la release à l'enregistrement, est ce qu'aucun système n'accompagne fluidement. Il faut exporter, sauvegarder, committer, taguer, notarier à la main. Chaque transition est une cérémonie manuelle dans un outil différent. --- ## Journaux append-only et event sourcing > **Résumé :** L'intuition de Jay Kreps, le journal append-only comme structure de données la plus fondamentale en informatique, a été implémentée dans Kafka et formalisée dans l'event sourcing. Datomic de Rich Hickey va plus loin, rendant le temps de premier rang et traitant les bases comme des accumulations de faits immuables. Nostr applique le modèle event-first aux protocoles sociaux : tout est un événement signé et horodaté ; l'état est toujours dérivé. Ces systèmes couvrent le milieu du spectre, mais ne relient ni vers les enregistrements permanents ni vers les CRDT au niveau de la frappe. ### Le journal est la base de données En 2013, Jay Kreps, alors chez LinkedIn puis co-créateur d'Apache Kafka, a écrit « The Log: What every software engineer should know about real-time data's unifying abstraction ». Thèse : **le journal, une séquence ordonnée et append-only d'enregistrements, est la structure de données la plus fondamentale en informatique.** Kreps, J. (2013). The Log. Voir aussi : Kreps, J. et al. (2011). Kafka: a Distributed Messaging System for Log Processing. Kafka implémente cela. Au cœur, Kafka est un journal de commits distribué : une séquence append-only d'événements partitionnée entre machines. Le journal est la source de vérité. Tout le reste, bases, caches, index de recherche, est une vue matérialisée dérivée du journal. L'event sourcing le formalise. Au lieu de stocker « l'état courant d'une commande est : expédiée, payée, 3 articles », on stocke les événements : OrderCreated, PaymentReceived, ItemsPicked, OrderShipped. L'état courant est dérivé en rejouant les événements. Vous voulez l'état à l'étape 2 ? Rejouez les événements 1-2. Vous voulez l'historique d'audit complet ? C'est le journal lui-même. Microsoft Azure Architecture Center : Event Sourcing Pattern. Voir aussi Fowler, M. (2005). Event Sourcing. ### Bases temporelles : faire du temps un élément de premier rang Rich Hickey a poussé cela plus loin avec Datomic. Les bases de données traditionnelles se trompent fondamentalement sur le temps : elles modélisent « le monde tel qu'il est maintenant » en écrasant les anciennes valeurs par les nouvelles. Mais l'information est immuable. « Le prix était de 10 $ le 1er mars » reste vrai après que le prix passe à 12 $. Une base qui écrase 10 $ par 12 $ a détruit de l'information. Hickey, R. (2012). The Datomic Information Model. « Datomic considers a database to be an information system, where information is a set of facts, and facts are things that have happened. » Voir aussi Hickey, R. (2012). The Value of Values (talk, JaxConf). Datomic stocke des **datoms** : faits atomiques de la forme `[entity, attribute, value, transaction, added?]`. Chaque fait inclut quand il est devenu vrai. La base est une accumulation de faits dans le temps. Vous pouvez interroger « as of » n'importe quelle transaction passée. Les bases bitemporelles ajoutent deux axes temporels : **valid time** (quand ce fait était-il vrai dans le monde réel ?) et **transaction time** (quand l'avons-nous appris ?). Les deux horodatages comptent pour l'audit, la conformité et la compréhension de la circulation de l'information. SQL:2011 a ajouté le support des tables temporelles au standard SQL. XTDB (anciennement Crux) implémente une bitemporalité complète. ### Nostr : les événements comme primitive sociale Nostr applique le modèle event-first à un protocole social. Chaque donnée dans Nostr est un **événement signé** : un objet JSON avec un id (hash SHA-256), une clé publique, un timestamp, un kind, des tags et un contenu. Les événements sont publiés à des relais. Les clients interrogent les relais pour des événements correspondant à des filtres. Protocole Nostr : NIP-01 définit la structure de base des événements. Les kinds définissent le sens : kind 1 = note courte, kind 0 = métadonnées de profil, kind 3 = liste de follow. Tout est événement. L'état est toujours dérivé par les clients. Ce qui est intéressant pour la mémoire : Nostr est naturellement event-sourced. Votre profil n'est pas un enregistrement ; c'est le dernier événement kind-0 signé par votre clé. Votre liste de follow n'est pas une table ; c'est le dernier événement kind-3. L'état est toujours dérivé des événements. Et parce que les événements sont signés et horodatés, ils forment un enregistrement chronologique vérifiable. Le modèle Nostr, événements signés, horodatés, relayés, est proche de « tout est un registre ». Le flux d'événements de chaque utilisateur EST un registre personnel. La question est combien de temps les relais gardent les événements, et quels événements en remplacent d'autres. Nostr ne garantit pas la permanence : les relais peuvent supprimer des événements à tout moment. Pour cela, il faut plus lourd. --- ## Bitcoin et l'ancre de permanence > **Résumé :** Bitcoin est l'enregistrement numérique le plus permanent produit par l'humanité : un registre append-only continu, sans interruption depuis 2009, soutenu par la thermodynamique plutôt que par des promesses contractuelles. Le même registre transmet de la valeur ET enregistre de la mémoire. OP_RETURN et OpenTimestamps permettent d'ancrer des données externes dans la permanence de Bitcoin. Mais tout ne mérite pas la permanence blockchain : l'intuition architecturale clé est la permanence par niveaux, différentes couches (RAM, disque, pairs, blockchain) pour différents besoins, reliées par ancrage. Le coût signale la permanence voulue, comme le monde physique distingue les gribouillis de serviette des inscriptions dans la pierre. ### Le registre qui n'oublie pas La plupart des systèmes de mémoire évoqués ont une durée de vie. Les piles d'annulation durent une session. Les CRDT durent tant que leur application tourne. Les dépôts Git durent tant que quelqu'un les héberge. Même des bases cloud peuvent être fermées, acquises, abandonnées. Bitcoin est différent. C'est un registre append-only continu qui fonctionne sans interruption depuis plus de quinze ans. Il n'a pas de temps humain, pas de week-ends, pas de jours fériés, pas d'arrêt, mais il a un **temps de bloc** : environ un nouveau bloc toutes les dix minutes, un battement maintenu par la dépense énergétique collective du réseau. Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. En 2026, Bitcoin a produit plus de 800 000 blocs sans rupture de chaîne depuis le 3 janvier 2009. Le plus long registre continu de l'histoire numérique. Ses propriétés comme système de mémoire : - **Append-only.** On peut y ajouter. On ne peut pas modifier ou supprimer. - **Immuable.** Une fois une transaction confirmée, enfouie sous les blocs suivants, l'inverser demanderait plus d'énergie que celle utilisée pour créer ces blocs, un coût qui grandit avec chaque bloc. - **Partagé par l'humanité.** Pas possédé par une entreprise, un pays ou un consortium. Tout le monde peut lire. Tout le monde peut écrire, moyennant frais. - **Permanence soutenue par l'énergie.** Propriété clé. L'immuabilité de Bitcoin n'est pas garantie par un contrat juridique ou la promesse d'une entreprise de garder des serveurs. Elle est garantie par la thermodynamique. L'énergie a déjà été dépensée. L'enregistrement est aussi permanent que le travail physique qui l'a produit. ### Valeur ET mémoire sur le même registre Voici ce qui rend Bitcoin particulièrement intéressant pour cette recherche : **le même registre qui transmet de la valeur enregistre aussi de la mémoire.** Quand vous envoyez du bitcoin, la transaction enregistre un transfert de valeur. Mais elle est aussi un événement horodaté et signé cryptographiquement : une mémoire. « Cette clé a envoyé ce montant à cette clé à cette hauteur de bloc. » Valeur et mémoire se rencontrent sur la même infrastructure. Ce n'est pas accidentel. L'innovation centrale de Satoshi Nakamoto était de résoudre le problème de double dépense sans autorité centrale, et la solution était une **mémoire partagée et ordonnée** de toutes les transactions. Le mécanisme de consensus, preuve de travail, existe pour s'accorder sur ce qui s'est passé et dans quel ordre. Bitcoin est, fondamentalement, un serveur d'horodatage soutenu par l'énergie. Nakamoto (2008) : « We propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. » Le serveur d'horodatage EST l'innovation ; le transfert de valeur est la première application construite dessus. **OP_RETURN** permet d'intégrer des données arbitraires (jusqu'à 80 octets) dans une transaction Bitcoin. Cela sert à ancrer des données externes dans la permanence de Bitcoin : hashez un document, intégrez le hash dans une sortie OP_RETURN, et vous avez une preuve horodatée que le document existait sous cette forme à ce moment. Le document lui-même vit ailleurs, sur votre machine, dans une base, sur IPFS, mais son existence est ancrée au registre numérique le plus permanent jamais produit. **OpenTimestamps** formalise ce motif : donné un fichier, produire une preuve que le fichier existait à un certain point de la chronologie Bitcoin. La preuve est minuscule, le fichier ne touche jamais la chaîne, et l'ancre est aussi permanente que Bitcoin. OpenTimestamps : « A timestamping proof standard. Uses Bitcoin as a timestamp notary. » Créé par Peter Todd. Voir aussi OP_RETURN, autorisé depuis Bitcoin Core 0.9 (2014) pour l'intégration de données. ### Permanence par niveaux Tout ne mérite pas la permanence blockchain. C'est une intuition essentielle que la v1 de cette note avait manquée. Votre pile d'annulation n'a pas besoin d'être sur Bitcoin. Vos opérations CRDT n'ont pas besoin de preuve de travail. La plupart des brouillons, messages et travaux quotidiens sont correctement éphémères. Tout stocker pour toujours serait du gaspillage, pas seulement de stockage mais d'énergie. L'immuabilité a un coût, et ce coût est une fonctionnalité : il oblige à choisir ce qui mérite d'être retenu pour toujours. Le monde physique fonctionne ainsi depuis toujours. Griffonner sur une serviette ne coûte rien et la serviette finit jetée. Imprimer un livre coûte plus et dure des décennies. Graver dans la pierre coûte beaucoup et dure des siècles. Le coût du support signale la permanence voulue du message. Une société qui graverait chaque note de serviette dans la pierre s'arrêterait. ```mermaid graph LR RAM(["⏱️ RAM\ngratuite · secondes"]) DISK[("💾 Disque\nbon marché · jours-années")] PEERS{{"🌐 Pairs\nmodéré · mois"}} CHAIN[/"⛓️ Blockchain\nsoutenue par l'énergie · permanent"/] RAM -->|"déclin auto"| DISK DISK -->|"répliquer"| PEERS PEERS -->|"ancrer hash"| CHAIN ``` Comparez la permanence de Bitcoin à celle du **DHT BitTorrent** (Distributed Hash Table). Le Mainline DHT de BitTorrent est aussi un système distribué : des millions de nœuds stockant des données adressées par contenu. Mais il n'a ni preuve de travail ni immuabilité soutenue par l'énergie. Les données persistent tant que des pairs les détiennent et répondent aux requêtes. Arrêtez de seeder, et le contenu finit par devenir inaccessible. Cela rend le DHT excellent pour des données sociales qui doivent être largement disponibles sans durer éternellement : métadonnées de profil, graphes sociaux, contenus éphémères. C'est le niveau intermédiaire, plus permanent qu'un serveur unique, moins qu'une blockchain. BitTorrent Mainline DHT : fondé sur Kademlia. En 2026, l'un des plus grands systèmes distribués en opération avec des millions de nœuds actifs. Utilisé par des projets comme BEP 44 pour le stockage de données mutables/immutables au-delà du partage de fichiers. Nostr occupe un niveau de permanence similaire. Les relais stockent les événements, mais peuvent les supprimer, tomber hors ligne ou fermer. Votre flux Nostr est plus durable qu'un serveur unique, parce que plusieurs relais peuvent le stocker, mais moins durable qu'une blockchain, parce qu'aucun relais n'est obligé de le garder pour toujours. Pour des enregistrements vraiment permanents, des événements Nostr peuvent être *ancrés* à Bitcoin : les données restent sur les relais, mais un hash de l'événement, ou d'un lot d'événements, est horodaté on-chain. Cette stratification est l'intuition architecturale clé : **différents niveaux de permanence pour différents besoins, reliés par ancrage.** Le CRDT capture chaque frappe en RAM et sur disque. Les versions significatives sont committées et répliquées vers des pairs. Les jalons vraiment importants sont ancrés dans la blockchain. Chaque couche utilise la bonne technologie pour ses exigences de permanence et son coût acceptable. Les couches n'ont pas besoin d'être un seul système. Elles doivent pouvoir se référencer. --- ## Le problème de l'oubli > **Résumé :** La mémoire humaine oublie par design : déclin, rétention pondérée par l'importance, compression et reconstruction sont des fonctionnalités, pas des bugs. Les systèmes numériques font l'inverse : ils se souviennent de tout et ne comprennent rien. Le droit à l'effacement du RGPD entre en collision directe avec les architectures append-only. Le juste milieu, un oubli gracieux, progressif et pondéré par l'importance, reste à construire. Le modèle de permanence par niveaux fournit un mécanisme : les événements se dégradent naturellement dans les niveaux inférieurs sauf promotion. L'oubli n'est pas un système séparé ; c'est le comportement par défaut des niveaux bas. ### La totalité pathologique de la mémoire numérique La mémoire humaine oublie. Ce n'est pas un bug. Les neurosciences ont montré que c'est une fonction essentielle. Frederic Bartlett a établi dans les années 1930 que la mémoire humaine est **reconstructive**, pas reproductive. Nous ne rejouons pas des enregistrements ; nous reconstruisons des souvenirs à partir de fragments, en comblant les trous avec des schémas. Chaque acte de mémoire est un acte de création. Les souvenirs changent chaque fois qu'on les rappelle. Bartlett, F. C. (1932). Remembering: A Study in Experimental and Social Psychology. Voir aussi Schacter, D. L. (2001). The Seven Sins of Memory (Houghton Mifflin), qui catalogue oubli, distorsion et interférence comme fonctions utiles. Cela ressemble à un défaut. Mais considérez l'alternative. Une condition rare, l'hyperthymésie, donne à certaines personnes un rappel presque parfait de leur vie quotidienne. Les études révèlent une surprise : le rappel total n'améliore pas la décision, et peut l'entraver. Ne pas pouvoir oublier, c'est ne pas pouvoir généraliser. La forêt disparaît parce qu'on voit chaque feuille. L'oubli sert au moins trois fonctions : 1. **Compression.** Vous ne vous souvenez pas de chaque repas jamais mangé. Vous vous souvenez que « j'aime les sushis » et que « ce restaurant était mauvais ». Des généralisations extraites de milliers de détails oubliés. 2. **Filtrage de pertinence.** Les souvenirs qui persistent sont ceux qui comptent : émotionnels, nouveaux, répétés ou reliés à un savoir existant. Le reste s'efface. Une politique naturelle de rétention. 3. **Cohérence narrative.** Nous éditons nos souvenirs pour former des récits cohérents. Le désordre de l'expérience réelle devient « ce qui s'est passé ». Ce n'est pas de la malhonnêteté ; c'est ainsi que nous faisons sens. Les systèmes numériques font l'inverse. Ils se souviennent de tout et ne comprennent rien. Votre boîte mail contient chaque message depuis 2008. Votre Google Drive contient des fichiers de projets dont vous avez oublié l'existence. Votre téléphone contient 47 000 photos. Les données sont là. Le sens a disparu. Une mémoire parfaite sans oubli sélectif produit l'équivalent numérique de l'accumulation compulsive. ### RGPD et droit à l'oubli Le RGPD européen consacre un « droit à l'effacement » (article 17) : les individus peuvent exiger que les organisations suppriment leurs données personnelles. Cela crée une collision directe avec les architectures append-only. RGPD article 17 : Right to erasure ('right to be forgotten'). Pour la tension blockchain : Oxford Academic (2025), Reconciling blockchain technology and data protection laws. Si votre système est un journal append-only, comment supprimez-vous quelque chose ? L'événement qui a enregistré « Alice a acheté un livre à 15 h » est un fait immuable. Le supprimer casserait le journal. Approches actuelles : - **Stockage off-chain :** stocker les données personnelles hors chaîne ; mettre seulement un hash on-chain. Supprimer les données off-chain à la demande. Le hash devient vide de sens sans sa source. - **Crypto-shredding :** chiffrer les données avant de les écrire dans le journal. À la demande d'effacement, détruire la clé. Les données chiffrées restent mais sont illisibles. - **Événements de rédaction :** ajouter un nouvel événement marquant l'ancien comme expurgé. Pas une vraie suppression, mais un effacement fonctionnel. Aucune solution n'est pleinement satisfaisante. Ce sont des rustines sur une tension fondamentale : les systèmes append-only supposent qu'on n'a jamais besoin d'oublier. Le monde réel exige l'oubli. ### La mémoire numérique devrait-elle ressembler davantage à la mémoire humaine ? La question n'est pas de savoir si les systèmes numériques devraient oublier : ils le doivent, pour des raisons pratiques (stockage), juridiques (RGPD) et cognitives (utilisabilité). La question est : quel modèle d'oubli ? La mémoire humaine offre un modèle provocant : - **Déclin par défaut.** Sauf renforcement, les souvenirs s'effacent. Équivalent numérique : les événements expirent après une période de rétention sauf promotion explicite. - **Rétention pondérée par l'importance.** Les événements émotionnels ou nouveaux sont mieux retenus. Équivalent numérique : les événements qui ont déclenché des décisions ou ont été marqués explicitement sont gardés plus longtemps. - **Compression dans le temps.** Les souvenirs détaillés de la semaine dernière deviennent des souvenirs vagues du mois dernier. Équivalent numérique : les événements fins sont périodiquement compressés en résumés. - **Reconstruction à partir de fragments.** La mémoire humaine comble les trous par des inférences plausibles. Équivalent numérique : conserver assez de données résumées pour reconstruire des états passés approximatifs sans replay parfait. Aucun système existant ne fonctionne ainsi. Les systèmes actuels offrent un binaire : tout retenir pour toujours ou supprimer irrévocablement. Le milieu, oubli progressif, gracieux, pondéré par l'importance, reste à construire. ```mermaid flowchart TB subgraph human["Modèle de mémoire humaine"] direction TB DECAY["⏳ Déclin par défaut\nsauf renforcement"] WEIGHT{{"⚖️ Rétention pondérée\npar l'importance"}} COMPRESS["📦 Compression\navec le temps"] RECON(["🧩 Reconstruction\nà partir de fragments"]) DECAY --> WEIGHT --> COMPRESS --> RECON end subgraph digital["Équivalent numérique"] direction TB EXPIRE["Les événements expirent\nsauf promotion"] MARKED{{"Événements déclenchés / marqués\ngardés plus longtemps"}} SUMMARY["Événements fins compressés\nen résumés"] APPROX(["États passés approximatifs\nsans replay bit-perfect"]) EXPIRE --> MARKED --> SUMMARY --> APPROX end ``` *L'oubli humain comme modèle de design pour la mémoire numérique. Chaque mécanisme humain a un équivalent numérique qu'aucun système existant n'implémente pleinement.* Le modèle de permanence par niveaux de la section Bitcoin fournit un mécanisme : **les événements se dégradent naturellement dans les niveaux sauf promotion explicite.** Le journal d'opérations CRDT se compacte après commit du document. La version committée est réduite à un résumé après la release. Seul ce qui est explicitement ancré persiste définitivement. L'oubli n'est pas un système séparé : c'est le comportement par défaut des couches inférieures. --- ## Mémoire à travers les espaces > **Résumé :** Quand des objets traversent des frontières d'espace, leur mémoire a trois options : transfert complet d'historique, écrasant et potentiellement intrusif ; transfert d'instantané, amnésique, le problème du dossier Downloads ; ou historique sélectif, curaté, comme un git push. Le monde physique donne le modèle : un bol en céramique porte qui l'a fait et ce qu'il est, mais pas chaque échec ni les frustrations du fabricant. Les défauts sociaux déterminent ce qui voyage automatiquement, ce qui exige un choix explicite, et ce qui ne traverse jamais sauf si on le donne volontairement. ### Quand les objets bougent, que devient leur histoire ? La note 010 a établi que les espaces sont des namespaces : des environnements isolés et cadrés où l'on apporte des choses et travaille avec elles. L'axiome de la porte fermée dit que dans un espace, le dehors n'existe pas. Maintenant : quand un objet traverse la frontière d'un espace, que devient sa mémoire ? Exemple concret. Vous écrivez une note de recherche dans votre espace privé (espace A). Vous l'éditez pendant trois semaines, accumulant historique CRDT, messages de commit, commentaires de relecteurs. Puis vous la déplacez vers un espace projet partagé (espace B) pour collaboration. Plusieurs choses peuvent arriver : **Transfert complet d'historique.** La note arrive avec toute son histoire : chaque frappe, chaque commentaire, chaque version. Transparence maximale, mais potentiellement écrasante et intrusive. Peut-être ne voulez-vous pas que les collaborateurs voient vos sessions d'édition de 3 h du matin. **Transfert d'instantané (amnésie).** La note arrive telle qu'elle est maintenant, sans histoire. Table rase. C'est ce qui arrive quand vous envoyez un fichier par e-mail : il arrive dépouillé de contexte. Le problème du dossier Downloads de la note 008. **Historique sélectif.** La note arrive avec une histoire curatée : versions nommées, messages de commit, commentaires marqués comme publics. Les états intermédiaires désordonnés sont élagués. C'est ce que fait un git push : vous partagez vos commits, pas votre stash, votre working directory ou vos branches abandonnées. ### Le monde physique fait cela correctement C'est ici que l'informatique peut apprendre des pièces. Vous passez une semaine à faire un bol en céramique chez vous. Vous pétrissez l'argile, vous la formez, vous la cuisez, vous l'émaillez, vous la recuisez. Puis vous l'apportez chez un ami pour un dîner. Ce qui voyage avec le bol : - **Qui l'a fait.** « Je l'ai fait. » Automatique, défaut social. - **À peu près quand.** « La semaine dernière. » Temps approximatif, pas timestamp. - **Ce que c'est.** Évidemment : c'est un bol. Son état courant est visible. Ce qui ne voyage pas : - **Chaque tentative ratée.** Vous n'avez pas apporté les trois bols qui ont fissuré au four. - **Le processus complet.** Votre ami ne voit pas le pétrissage, le centrage, les heures au tour. - **Vos frustrations privées.** « J'ai failli jeter l'argile contre le mur à 2 h du matin » reste dans votre cuisine. Certaines choses sont à votre choix : - « L'émail est une expérience, première fois avec cette couleur. » - « La forme s'inspire d'un bol vu au Japon. » - Ce sont des détails de provenance que vous donnez volontairement, pas des choses qui voyagent automatiquement. Cela correspond précisément à l'axiome de la porte fermée de la note 010. La table du dîner de l'ami est un espace. Le bol y entre. L'ami voit le bol tel qu'il est, sait qui l'a fait (défaut social), et apprend ce que vous choisissez de raconter. Votre atelier privé, votre espace A, reste invisible. Pas « accès refusé » : l'atelier n'existe pas depuis la table du dîner. Note 010 : « Quand vous êtes dans un espace, le dehors n'existe pas. Pas caché. Pas verrouillé. Pas filtré. Inexistant. » Appliqué à la mémoire, l'axiome de la porte fermée signifie que l'histoire privée de fabrication n'est pas « cachée » dans le nouvel espace : elle ne fait littéralement pas partie de son univers. Les règles de ce qui traverse les frontières d'espace devraient suivre la même logique sociale : - **Automatique (défauts sociaux) :** identité du créateur, date de création approximative, état courant. Cela voyage parce que ce serait étrange autrement, comme un bol sans fabricant. - **Choix explicite :** provenance détaillée, historique de versions, notes de processus. Le créateur choisit quoi partager. - **Jamais (sauf si vous le dites) :** brouillons privés, contenu supprimé, états intermédiaires. Votre session de 3 h du matin est l'argile qui a fissuré au four. ```mermaid graph LR subgraph SA["🔒 Espace A — Atelier privé"] D1["v0.1\n(brouillon brut)"] D2["v0.2\n(restructuré)"] D3["v0.3\n(poli)"] D1 --> D2 --> D3 end subgraph SB["🌐 Espace B — Projet partagé"] D4["v1.0\n(partagé pour revue)"] D5["v1.1\n(avec retours)"] D4 --> D5 end D3 -.->|"porte :\n👤 auteur\n📅 ~quand\n📄 état courant\n\nne porte pas :\n🚫 v0.1, v0.2\n🚫 éditions privées"| D4 ``` ### La chaîne de provenance La provenance, le registre d'où vient quelque chose et comment il a été transformé, est un type précis de mémoire qui devient critique quand les objets se déplacent entre espaces. Le lien de provenance entre l'espace A et l'espace B est l'artefact de mémoire critique. Sans lui, l'espace B ne sait pas que la note a traversé des brouillons privés. Avec lui, on peut remonter, mais seulement si le propriétaire de l'espace A l'autorise. Vie privée et provenance sont en tension. Le modèle du monde physique résout cela : le fabricant du bol peut vous parler du processus s'il le choisit, mais vous ne pouvez pas entrer dans sa cuisine sans invitation. Le modèle d'entités de la note 008 donne le vocabulaire : chaque version est une entité liée par `derivedFrom`. La question est quelles entités-version sont visibles dans quel espace, et si la chaîne `derivedFrom` traverse les frontières d'espace. Réponse : elle traverse, mais d'un seul saut. Vous pouvez voir « ceci dérive de quelque chose dans un espace privé » sans voir le contenu de cet espace privé. --- ## Les objets comme atomes de mémoire ? > **Résumé :** Les événements de mémoire (opérations CRDT, commits git, entrées de registre) correspondent tous au modèle d'entité de la note 008 : ils ont identité, propriétés et relations. Cela suggère que les événements de mémoire SONT des objets, unifiant l'ontologie. Mais l'argument opposé existe : la mémoire pourrait être fondamentalement relationnelle, non pas un objet mais un lien entre objets et temps. Les deux vues ont du mérite, et l'ontologie d'entités est assez flexible pour les deux. Dans tous les cas, les événements de mémoire ont besoin des deux mêmes propriétés : une position sur l'axe de granularité et une position sur l'axe de permanence. ### Une question ouverte La note 008 définissait une entité comme toute chose avec identité, propriétés et relations, et donnait aux entités quatre capacités optionnelles : +contenu, +contenant, +agency, +narration. La mémoire (+narration) était l'une de ces capacités. Mais maintenant que nous avons cartographié le spectre de granularité, une question plus dure apparaît : **Les événements de mémoire sont-ils eux-mêmes des objets ?** Regardez ce que contient le spectre : - Un lot d'opérations CRDT est... une chose. Il a une identité (les IDs d'opération), des propriétés (timestamp, auteur), et des relations (partie de l'historique de ce document). - Un commit git est... une chose. Il a une identité (le SHA), des propriétés (message, auteur, date), et des relations (commits parents, tree pointé). - Un tag de release est... une chose. - Une entrée de registre est... une chose. - Une transaction Bitcoin est... une chose. Chacune correspond au modèle d'entité de la note 008. Chacune a identité, propriétés et relations. Chacune pourrait porter des capacités : un commit a +contenu (le diff), une release a +contenant (les artefacts qu'elle regroupe). Si les événements de mémoire sont des objets avec contexte, alors le spectre de granularité n'est pas une préoccupation séparée de l'ontologie d'entités : c'est l'ontologie appliquée aux artefacts temporels. Une opération CRDT est une entité à haute granularité et faible permanence. Une ancre blockchain est une entité à faible granularité et haute permanence. La « couche mémoire » est simplement l'ensemble des entités qui portent sur le changement dans le temps. ### L'autre côté Mais il existe un argument contre cette unification. La mémoire pourrait être une *sorte* de chose fondamentalement différente : pas un objet, mais une relation entre objets et temps. Quand vous vous souvenez d'avoir fait le bol en céramique, le souvenir n'est pas une chose que vous pouvez tenir. C'est une connexion entre vous (une personne), le bol (un objet), votre cuisine (un espace) et mardi dernier (un temps). La mémoire est *à propos* de ces choses, mais elle n'est pas l'une d'elles. Les mémoires sont relationnelles, pas substantielles. Techniquement : une opération CRDT n'est pas le même type d'entité que le document qu'elle modifie. L'opération est une métadonnée *sur* l'évolution du document. Elle existe dans un plan conceptuel différent : le plan de « ce qui s'est passé » plutôt que de « ce qui est ». Les deux vues ont du mérite : | Mémoire comme objet | Mémoire comme relation | |:---:|:---:| | Simplifie l'ontologie (un seul modèle pour tout) | Préserve une distinction utile | | Les événements de mémoire peuvent être versionnés, partagés, déplacés entre espaces | La mémoire est toujours *à propos* de quelque chose : elle est de second ordre | | Un commit est clairement une chose (il a un SHA, on peut `git show`) | Mais le commit n'a de sens que par rapport à son parent et son contenu | | Permet une « mémoire sur la mémoire » (la méta-mémoire est une entité de plus) | Évite la régression infinie : la mémoire est la couche narrative, pas une couche d'objets de plus | Nous ne tranchons pas ici. Il se peut que la réponse soit contextuelle : certains événements de mémoire, un commit, une entrée de registre, sont assez object-like pour être traités comme des entités. D'autres, le fait que vous ayez édité ce document à 3 h du matin, sont mieux modélisés comme propriétés d'une relation. L'ontologie d'entités est assez flexible pour les deux : les relations sont aussi des entités, dans la note 008. Ce que nous pouvons dire : que les événements de mémoire soient des objets ou des relations à propos d'objets, ils ont besoin des deux mêmes propriétés. Ils ont besoin d'une position sur l'axe de **granularité** (à quel point détaillé ?) et d'une position sur l'axe de **permanence** (combien de temps gardé ?). Le vocabulaire de l'intention de mémoire s'applique quel que soit le statut ontologique. --- ## La langue de l'intention de mémoire > **Résumé :** Quatre écarts définissent le paysage : opérations CRDT → versions significatives, sauvegarde fichier → commit git, commit git → enregistrement permanent, et provenance entre systèmes. La conclusion v1 (construire un registre unifié) était le piège de la super app. La vraie primitive n'est pas un système : c'est un vocabulaire de l'intention de mémoire, éphémère, travail, jalon, enregistrement, permanent. Ces déclarations permettent à n'importe quel système de comprendre et d'agir sur votre intention, à l'IA de raisonner sur vos données, aux utilisateurs de retrouver de l'agency, et aux systèmes existants d'interopérer grâce à une langue-pont partagée. ### Ce qui manque vraiment Nous avons examiné le paysage. Les CRDT couvrent le bord gauche (opérations temps réel). Git couvre le milieu (commits intentionnels). L'event sourcing couvre les événements métier. Bitcoin couvre le bord droit (enregistrements permanents). BitTorrent DHT et Nostr couvrent les niveaux intermédiaires. Entre chaque paire, il y a un vide : ```mermaid flowchart LR CRDT(["🔄 Opérations\nCRDT"]) -.->|"Écart 1"| VER["🏷️ Versions\nsignificatives"] SAVE(["💾 Sauvegarde\nfichier"]) -.->|"Écart 2"| GIT["📦 Commit\nGit"] GIT -.->|"Écart 3"| RECORD[/"📒 Enregistrement\npermanent"/] APP1(["Mémoire\napp A"]) -.->|"Écart 4"| APP2(["Mémoire\napp B"]) ``` *Quatre écarts dans le paysage de la mémoire. Flèches pointillées = aucun chemin fluide n'existe aujourd'hui. Chaque écart exige une cérémonie manuelle dans un outil différent.* **Écart 1 : opérations CRDT → versions significatives.** Aucun système ne permet de promouvoir en douceur un état CRDT en version nommée. **Écart 2 : sauvegarde fichier → commit git.** L'immense majorité des utilisateurs d'ordinateur n'utilise jamais de contrôle de version. L'écart entre Cmd-S et un commit significatif est à la fois conceptuel et pratique. **Écart 3 : commit git → enregistrement permanent.** Si quelque chose compte assez pour être notarié, il faut un système entièrement différent. **Écart 4 : tout système → provenance entre systèmes.** Même à un seul niveau de granularité, la mémoire est cloisonnée par application. L'historique Google Docs ne connaît pas les commits git. Git ne connaît pas les tickets Jira. Chaque application maintient sa propre mémoire. La v1 de cette note concluait : construire un registre unifié. Un système couvrant tout le spectre. Un format d'événement, un moteur de rétention, une chaîne de promotion. C'est faux. C'est le piège de la super app appliqué à la mémoire : l'impulsion d'absorber toutes les fonctions voisines dans un seul système. Chaque app essaie d'être l'app-qui-fait-tout. Nico a identifié le même motif au niveau des espaces : « Chaque app essaie de résoudre ça. Mais ce ne sont pas des solutions universelles. L'utilisateur se retrouve avec des super apps encore plus complexes. » Nico sur la conclusion du registre unifié : « Je ne pense pas que ça puisse marcher. Il nous faut une architecture en couches et il nous faut une primitive. » (4 avril 2026) Un registre unifié couvrant des piles d'annulation à la blockchain devrait gérer une dynamique temporelle d'environ 10^15 (de la sous-milliseconde au permanent), tout le spectre des modèles de consensus (local à tolérant aux fautes byzantines), et tous les schémas d'événements imaginables. Ce serait un couteau suisse de la taille d'un immeuble. Personne ne l'utiliserait. Et même s'il était utilisé, il deviendrait le point de défaillance unique de toute la mémoire, exactement le problème de centralisation que les systèmes distribués existent pour éviter. ### La primitive n'est pas un système. C'est un vocabulaire. Voici le recadrage. La pièce manquante n'est pas un système qui traite toutes les couches. La pièce manquante est une **langue** : un vocabulaire partagé pour exprimer quel type de mémoire vous voulez. Quand vous dites « garde ceci pour toujours », vous exprimez une intention de mémoire. Quand vous dites « ce n'est qu'un brouillon », vous en exprimez une autre. Quand vous dites « je veux pouvoir annuler cela pendant l'heure qui vient mais je m'en fiche ensuite », encore une autre. Aujourd'hui, ces intentions n'ont pas de manière cohérente d'être exprimées. Chaque système a son propre mécanisme : git a des messages de commit, Google Docs a l'historique automatique, Bitcoin a les transactions, mais il n'y a pas de vocabulaire partagé entre eux. Et s'il y en avait un ? Considérez un petit ensemble de primitives d'intention de mémoire : - **« Ceci est éphémère. »** Garder en RAM, disque local au maximum. Permanence de pile d'annulation. - **« Ceci est un état de travail. »** Garder pour la durée du projet. Permanence CRDT ou autosave. - **« Ceci est un jalon. »** Garder explicitement. Le nommer. Permanence de commit git. - **« Ceci est un enregistrement. »** Garder pour conformité, audit ou importance personnelle. Permanence de registre. - **« Ceci est permanent. »** L'ancrer. Le rendre indéniable. Permanence blockchain. Ce ne sont pas des appels API à un système unifié. Ce sont des **déclarations d'intention** que n'importe quel système peut comprendre et appliquer. Une bibliothèque CRDT qui comprend « ceci est un jalon » peut créer un instantané nommé. Un système git qui comprend « ceci est un enregistrement » peut taguer et signer. Un service d'horodatage qui comprend « ceci est permanent » peut ancrer à Bitcoin. Différents systèmes traitent différents niveaux de permanence, mais ils partagent le vocabulaire. ```mermaid graph LR subgraph intent["Ce que vous dites"] I1["⏱️ éphémère"] I2["📝 travail"] I3["🏷️ jalon"] I4["📒 enregistrement"] I5["⛓️ permanent"] end I1 -.->|"Annulation / RAM"| I2 I2 -.->|"CRDT / Autosave"| I3 I3 -.->|"Git / Versions"| I4 I4 -.->|"Registre"| I5 I5 -.->|"Bitcoin"| OUT((" ")) ``` *Le vocabulaire est la primitive. Les systèmes dessous sont interchangeables.* Le vocabulaire permet la **promotion** : déplacer la mémoire vers le haut de l'axe de permanence en changeant la déclaration d'intention. Et la rétrogradation : décider que quelque chose marqué comme « enregistrement » n'est finalement qu'un « état de travail » et peut être compressé. ### Pourquoi la langue change tout Trois conséquences d'un vocabulaire partagé pour l'intention de mémoire : **1. L'IA peut comprendre votre intention.** Aujourd'hui, un assistant IA n'a aucun moyen de savoir si un document est précieux ou jetable. Avec un vocabulaire d'intention de mémoire, vous pouvez lui dire : « ceci est un brouillon » ou « ceci compte, garde-le pour toujours ». L'IA peut alors agir correctement : proposer du nettoyage pour les brouillons, proposer un ancrage pour les enregistrements permanents, vous avertir avant des opérations destructrices sur des choses marquées importantes. **2. Vous retrouvez de l'agency.** Aujourd'hui, le comportement mémoire de chaque application est invisible et non négociable. Google Docs auto-sauvegarde que vous le vouliez ou non. Git ne se souvient de rien sauf si vous committez manuellement. Il n'y a aucun moyen d'exprimer « je veux que cela soit retenu au niveau version, pas au niveau frappe ». Avec un vocabulaire d'intention, vous pouvez communiquer vos attentes, et le système devient lisible. **3. Les systèmes existants deviennent interopérables.** Vous n'avez pas besoin de remplacer Google Docs, git ou Bitcoin. Il vous faut un pont entre eux : une manière pour un système de passer le relais à un autre quand le niveau de permanence change. Le vocabulaire EST ce pont. « Ceci est maintenant un jalon » est un message que tout système peut écouter et appliquer. Nico sur la langue comme clé : « Quand on a une langue qui décrit les différents types de mémoire, on y est presque. Parce que l'IA peut comprendre votre intention. Vous retrouvez de l'agency parce que vous pouvez communiquer vos attentes avec des règles sociales. Les systèmes existants deviennent utilisables parce que vous avez un pont. » (4 avril 2026) C'est la même intuition qui guide l'approche de Regent's Park pour les quatre primitives : la réponse n'est pas de construire un nouveau système. C'est de trouver le bon vocabulaire, assez simple pour sembler évident, assez précis pour être opératoire. Les gens pensent déjà la mémoire en ces niveaux. « Juste une note » contre « document important » contre « enregistrement légal » : ce sont des catégories naturelles. Ce qui manque est une façon de dire à votre ordinateur dans quel niveau vous êtes. --- **Résultats clés :** - La mémoire en informatique n'est pas absente : elle est fragmentée entre une douzaine de systèmes qui traitent chacun une tranche du spectre temporel, sans connexions entre couches - Le motif universel est état = f(événements), mais les différentes couches de permanence ont différentes physiques, coûts et modèles de confiance : elles ont besoin de systèmes différents, pas d'un registre unifié - Les CRDT ont élégamment résolu la mémoire collaborative temps réel mais ne fournissent aucun chemin vers des versions significatives ; git a résolu le versionnement intentionnel mais seulement pour le texte - La permanence a un prix, et ce prix est une fonctionnalité : le coût signale la permanence voulue, comme la pierre coûte plus qu'une serviette - Le modèle de permanence par niveaux (RAM → disque → pairs → blockchain) fournit un mécanisme d'oubli gracieux : les événements déclinent sauf promotion explicite - Quand des objets traversent des frontières d'espace, les défauts sociaux du monde physique donnent le modèle : créateur et état courant voyagent automatiquement ; l'historique de processus exige un partage explicite - La primitive manquante n'est pas un système mais un **vocabulaire** : un petit ensemble de déclarations d'intention de mémoire (éphémère, travail, jalon, enregistrement, permanent) que tout système peut comprendre et appliquer ## Questions ouvertes ### 1. Quelle est exactement la primitive ? Nous avons défendu un vocabulaire d'intention de mémoire. Mais est-ce un standard de métadonnées ? Un ensemble d'annotations ? Une API ? Un protocole ? Le vocabulaire doit être assez léger pour s'attacher à n'importe quel événement dans n'importe quel système, mais assez structuré pour que différents systèmes l'interprètent de manière cohérente. Quelle est la spécification minimale ? ### 2. Les événements de mémoire peuvent-ils être des objets ? La section 6 a présenté les deux côtés sans trancher. Si les événements de mémoire (commits, lots CRDT, entrées de registre) sont des entités au sens de la note 008, l'ontologie reste unifiée. Si la mémoire est une couche relationnelle séparée *à propos* des entités, le modèle est plus riche mais plus complexe. Peut-on concevoir le vocabulaire pour qu'il fonctionne dans les deux cas ? ### 3. Quels sont les défauts sociaux pour la mémoire entre espaces ? L'analogie du bol en céramique suggère qu'une partie de la mémoire voyage automatiquement (créateur, date approximative) et qu'une autre exige un partage explicite. Mais quelle est la liste réelle des défauts sociaux ? Varient-ils par culture, contexte ou type de relation ? L'axiome de la porte fermée de la note 010 donne le mécanisme. Les défauts sociaux donnent la politique. ### 4. Comment l'oubli se compose-t-il avec la permanence ? Si j'ancre un hash de document à Bitcoin puis veux exercer mon droit à l'effacement, le hash est permanent mais le document est supprimé. Est-ce un oubli suffisant ? Le hash prouve que *quelque chose* a existé, même si la chose a disparu. Est-ce une violation de la vie privée ou une trace raisonnable ? ### 5. Qui paie la permanence ? L'ancrage Bitcoin coûte de l'argent (frais de transaction). Le stockage coûte de l'argent. Si l'intention de mémoire inclut « rendre ceci permanent », quelqu'un paie. La permanence est-elle un service premium ? Un service public ? Le coût sert-il lui-même de filtre naturel : seules les choses qui valent la peine d'être payées sont retenues définitivement ? ### 6. Quel est le vocabulaire minimal viable ? Cinq niveaux (éphémère → permanent) sont peut-être trop nombreux. Ou trop peu. Quel est le plus petit ensemble de déclarations d'intention qui couvre la grande majorité des cas réels ? Peut-être trois : **brouillon**, **version**, **enregistrement**. Ou deux : **oubliable** et **permanent**, le reste étant implicite par contexte. ### 7. Où vit le vocabulaire ? Dans le fichier ? Dans le système de fichiers ? Dans l'application ? Dans un magasin de métadonnées sidecar ? Dans les propriétés de l'entité (note 008) ? La réponse varie probablement selon le niveau de permanence : les intentions éphémères vivent en RAM, les intentions permanentes on-chain, mais l'interface devrait paraître unifiée. --- ## Coda : la mémoire comme langue > **Résumé :** La mémoire n'est pas un seul système : c'est une architecture en couches où différents systèmes traitent différents niveaux de permanence. Le tissu conjonctif entre eux n'est pas une plateforme unifiée mais un vocabulaire : de simples déclarations d'intention que tout système peut comprendre. Le problème de granularité ne se résout pas par un système unique, mais en donnant aux personnes et à leur IA les mots pour décrire ce dont elles ont besoin. La mémoire a toujours été la plus abstraite des quatre primitives. Les personnes sont intuitives : vous savez ce qu'est une personne. Les espaces sont intuitifs : vous savez ce qu'est une pièce. Les objets sont intuitifs : vous savez ce qu'est une chose. La mémoire est plus difficile à pointer parce qu'elle n'est pas une chose : c'est l'histoire des choses. Cette recherche rend sa forme plus claire. La mémoire n'est pas un système. C'est une **architecture en couches** : CRDT en bas, contrôle de version au milieu, registres distribués et blockchains en haut, avec différents systèmes pour différents niveaux de permanence. Les couches existent. Elles marchent. Ce qui manque est le tissu conjonctif entre elles. Ce tissu conjonctif n'est pas une plateforme unifiée. C'est un **vocabulaire** : une petite langue partagée pour exprimer quel type de mémoire vous voulez. « Ceci est un brouillon. » « Ceci est un jalon. » « Ceci est permanent. » Des déclarations simples que n'importe quel système peut comprendre et appliquer. Le problème de granularité, la mémoire fragmentée entre systèmes déconnectés, ne se résout pas en construisant un système pour les gouverner tous. Il se résout en donnant aux personnes, et à leur IA, les mots pour décrire ce dont elles ont besoin. Une fois l'intention exprimable, la bonne couche peut répondre. Une fois que les couches entendent le même vocabulaire, elles peuvent se passer le relais. Une fois que le passage de relais marche, promotion et oubli deviennent naturels : non plus des cérémonies manuelles dans différents outils, mais des transitions fluides guidées par votre intention déclarée. Tout est un registre. Mais la réponse n'est pas un registre unique. C'est une langue pour choisir quel registre, et pour combien de temps. --- *Regent's Park · Note 011 · v2.1* *Contexte : 005 — Les quatre primitives · 005d — Mémoire · 008 — Ontologie des entités · 010 — Les espaces comme namespaces* 🌳