Le schéma
Le premier manifeste disait : vos données ne devraient pas vivre sur le serveur de quelqu’un d’autre. Construisez local-first, ou construisez la dépendance.
Le deuxième manifeste disait : la confiance comportementale dans les agents IA est structurellement insuffisante. Un agent qui dit qu’il a terminé n’a pas terminé. La structure vérifie. Le comportement fait semblant.
Ce manifeste complète la trilogie. Il dit : les systèmes mutables imposent une taxe de complexité que les systèmes immuables ne paient pas. La plupart des outils, protocoles, logiques de réessai, démons de synchronisation, algorithmes de résolution de conflits et couches de vérification que les équipes logicielles construisent et maintiennent existent pour une seule raison : le modèle de données sous-jacent ment. Il change en place. Il oublie ce qu’il était. Il nécessite des systèmes externes pour reconstruire la vérité.
La rébellion est d’arrêter de compenser. Réparez la fondation.
La découverte
Cela s’est produit en trois jours.
Un développeur découvrant jj — un système de contrôle de version bâti sur un historique de changements immuable et adressé par contenu — a remarqué quelque chose. Il n’y a pas de commande jj sync. La documentation renvoie à une discussion future : la synchronisation viendra peut-être un jour. La communauté la demande. Personne n’avait clairement expliqué pourquoi elle n’existait pas.
La réponse est qu’elle n’a pas besoin d’exister.
Le modèle de données de jj est un journal en ajout seul où chaque changement a une identité stable qui survit à la réécriture. La divergence entre deux copies est un état représentable, pas une erreur. N’importe quel transport capable de déplacer des fichiers entre machines — iCloud, rsync, une clé USB — suffit. Vous placez la racine du dépôt sur iCloud. Vous placez votre contexte de travail dans un dossier .nosync. Main se propage automatiquement. Les espaces de travail restent locaux. Quand deux personnes fusionnent simultanément, jj voit la divergence, la marque clairement, et vous la résolvez comme n’importe quel autre conflit. Pas de cérémonie spéciale. Pas de protocole de synchronisation dédié.
La complexité de git push, git pull, git fetch, git merge, git rebase, et de chaque commande associée n’existe pas parce que synchroniser des changements est difficile. Elle existe parce que le modèle de Git est mutable — les branches bougent, l’historique se réécrit, il n’y a pas d’identité stable pour un changement à travers les opérations. L’immutabilité de jj élimine le besoin de la plupart de cette machinerie. La synchronisation est simplement la relecture d’un journal. Le journal existait déjà.
C’est le schéma. Cherchez-le partout.
La taxe
Les systèmes mutables ne créent pas seulement de la complexité technique. Ils créent de la charge cognitive. Quand l’état peut changer en place, vous devez maintenir un modèle mental continu de ce qu’est l’état courant, s’il est correct, et ce qui s’est passé pour en arriver là. Ce modèle vit dans votre tête comme une anxiété de fond. Il vous réveille. Il vous fait vérifier le terminal avant de dormir.
Les systèmes immuables distribuent cette charge différemment. Parce que l’enregistrement ne peut pas être altéré, vous n’avez pas besoin de le garder en tête. Le journal est la vérité. Vous pouvez le lire à tout moment et faire confiance à ce qu’il dit. Le soulagement cognitif n’est pas métaphorique — il est physiologique. Le thread d’arrière-plan se termine.
Voilà pourquoi les journaux en ajout seul comptent. Vous écrivez l’état en continu, en ajoutant plutôt qu’en écrasant. Quand quelque chose échoue, cela ne corrompt pas ce qui précède — cela s’arrête simplement, et le journal enregistre ce qui a été accompli. La récupération n’est pas une reconstruction. La récupération est la lecture du journal et la continuation là où il s’arrête. Vous n’avez pas besoin de vous souvenir de l’état des choses. Le registre s’en souvient.
Voilà pourquoi le journal d’opérations de jj compte. Chaque commande est enregistrée. jj undo n’annule pas un changement d’état mutable — il restaure un état précédemment enregistré. Vous ne pouvez pas perdre de travail parce que le travail n’est jamais détruit, seulement ajouté.
Voilà pourquoi les empreintes cryptographiques comptent pour l’intégrité éditoriale. Une empreinte ne promet pas que le contenu n’a pas changé. Elle rend le changement structurellement impossible sans détection. L’immutabilité est mathématique, pas comportementale.
Chaque couche de vérification, logique de réessai et protocole de réconciliation que vous construisez paie la taxe mutable. La question qui mérite d’être posée avant de la construire est : une meilleure fondation pourrait-elle rendre cela inutile ?
La manifestation
Le principe d’immutabilité apparaît à chaque couche des systèmes qui sont honnêtes sur ce qu’ils sont.
Dans le contrôle de version, cela signifie : les changements ont des identités stables qui survivent à la réécriture. L’historique est un journal, pas un grand livre que l’on efface et réécrit. La synchronisation est une relecture, pas une négociation.
En pratique, cela signifie : les processus échoués redémarrent proprement plutôt que de corrompre l’état partagé. La progression est enregistrée dans des journaux en ajout seul plutôt que conservée en mémoire volatile. Vous savez ce qui s’est passé parce que le journal dit ce qui s’est passé.
Dans le stockage de données, cela signifie : les mises à jour créent de nouveaux enregistrements plutôt que de modifier les existants. L’historique d’un enregistrement est dérivable de l’enregistrement lui-même. Les conflits entre écritures concurrentes sont résolubles parce que les deux écritures sont préservées.
Dans la confiance et la vérification, cela signifie : les preuves cryptographiques remplacent les assurances comportementales. Une empreinte vérifie. Une promesse fait semblant. Vous ne pouvez pas falsifier une empreinte sans changer ce vers quoi elle pointe.
Dans la communication des agents IA, cela signifie : un agent qui dit avoir terminé une tâche ne l’a pas terminée. Un agent qui fournit l’empreinte de la sortie, le test réussi, l’entrée de journal qui enregistre la complétion — cet agent a terminé. La structure plutôt que le comportement. Toujours.
Dans l’infrastructure cognitive, cela signifie : le registre est en dehors de votre tête. Vous ne maintenez pas l’état. Le système le fait. Votre rôle est de lire le journal quand vous avez besoin de savoir quelque chose, pas de tout retenir tout le temps.
La hiérarchie
Les trois manifestes s’appuient les uns sur les autres.
Le premier manifeste abordait où vivent vos données. Local-first signifie que vos données ne sont pas otages de l’infrastructure de quelqu’un d’autre, du modèle économique de quelqu’un d’autre, de la panne de quelqu’un d’autre. La souveraineté commence par la localité.
Le deuxième manifeste abordait comment vous vérifiez ce que votre système affirme. La vérification structurelle signifie que vous ne faites pas confiance à ce qu’un agent dit de son propre état — vous vérifiez contre des preuves qui ne peuvent pas être fabriquées. Faites confiance à la structure, pas à la déclaration.
Ce manifeste aborde de quoi est fait votre système. Une fondation immuable signifie que votre système ne peut pas mentir sur sa propre histoire, ne peut pas corrompre l’état partagé par une défaillance partielle, ne peut pas créer les catégories de complexité accidentelle que les systèmes mutables génèrent naturellement. La structure est honnête par construction, pas par politique.
Localité. Vérification. Immutabilité. Chacune est une rébellion contre une catégorie différente de dépendance. Dépendance à l’infrastructure externe. Dépendance à l’honnêteté comportementale. Dépendance à des systèmes qui nécessitent une maintenance constante pour rester cohérents.
Ensemble, ils décrivent une manière différente de construire : des systèmes qui se souviennent correctement, rapportent honnêtement, et échouent proprement. Des systèmes dont les fondations ne vous demandent pas de compenser pour elles.
Les anti-schémas
Vous payez la taxe mutable quand :
Vous construisez un protocole de synchronisation pour des données qui pourraient être un journal rejouable.
Vous écrivez de la logique de réessai pour des agents qui pourraient redémarrer proprement depuis un état enregistré.
Vous ajoutez une couche de vérification parce que l’enregistrement sous-jacent peut être altéré après coup.
Vous maintenez un état mental de ce que fait votre système parce que le système n’a pas de journal fiable de ce qu’il a fait.
Vous construisez des algorithmes de résolution de conflits pour des écritures concurrentes qui pourraient être enregistrées comme des événements séparés et résolues à la lecture.
Vous demandez à un agent s’il a terminé une tâche plutôt que de lire le registre de ce qu’il a produit.
Vous faites un force-push pour corriger l’historique plutôt que d’ajouter une correction au journal.
Dans chaque cas, la bonne question n’est pas comment résoudre ce problème mais quelle propriété de ma fondation fait exister ce problème ?
L’engagement
Nous nous engageons à traiter les journaux en ajout seul comme une infrastructure porteuse, pas comme une commodité de débogage. Le journal est la mémoire du système. Une mémoire qui peut être réécrite n’est pas une mémoire — c’est une affirmation.
Préférer des fondations qui rendent le mensonge structurellement difficile plutôt que des fondations qui nécessitent une vérification externe. Une empreinte cryptographique est plus honnête qu’un message de complétion. Un magasin d’événements immuable est plus honnête qu’une base de données mutable avec un journal d’audit boulonнé par-dessus.
Lire la taxe mutable avant de la payer. Avant de construire un protocole de synchronisation, demandez si le modèle de données est déjà un journal. Avant d’écrire de la logique de réessai, demandez si l’agent peut redémarrer proprement. Avant d’ajouter une couche de vérification, demandez si l’enregistrement sous-jacent peut être altéré.
Permettre au journal de porter la charge cognitive que les humains ne devraient pas porter. Le thread d’anxiété de fond concernant l’état du système est un symptôme de fondations mutables. Les systèmes immuables apportent un soulagement non pas en étant plus simples à construire, mais en étant suffisamment honnêtes pour qu’on leur fasse confiance.
Reconnaître que laisser crasher est une philosophie de conception, pas un échec. Le modèle de supervision de BEAM est bâti sur l’intuition que les redémarrages propres sont plus sûrs que de tenter de réparer un état corrompu. L’agent qui s’arrête proprement est moins dangereux que l’agent qui continue avec de fausses croyances sur ce qu’il a fait.
La preuve
Ce n’est pas de la théorie. C’est ce qui s’est passé un samedi de mars 2026 dans un hôpital belge.
Un développeur, en convalescence, travaillant dans une fenêtre cognitive de quatre heures, a commencé une tâche et est allé jouer au ping-pong. Pendant son absence, le système a découvert qu’une connexion critique était rompue. Il a diagnostiqué la cause profonde — un fichier de configuration manquant. Il a créé le fichier, vérifié la connexion, et a continué. Il n’a pas interrompu. Il n’a pas échoué silencieusement. Il a enregistré ce qu’il a fait et a continué à travailler.
Quand le développeur est revenu, il n’a pas demandé ce qui s’était passé. Il a lu le journal.
La charge cognitive avait été réduite non pas en rendant le système plus simple, mais en le rendant honnête. Le registre était immuable. La défaillance avait été propre. La récupération avait été journalisée. Il n’y avait rien à garder en tête parce que le système l’avait gardé pour lui.
Le téléphone était silencieux. Le journal était clair.
C’est cela, la rébellion. Pas bruyante. Pas mise en scène. Structurellement évidente pour quiconque veut bien lire de quoi est faite la fondation.
Souvenez-vous
Quand vous cherchez un protocole de synchronisation, demandez d’abord : mes données sont-elles déjà un journal ?
Quand vous cherchez de la logique de réessai, demandez d’abord : ce processus peut-il redémarrer proprement ?
Quand vous cherchez une couche de vérification, demandez d’abord : l’enregistrement sous-jacent peut-il mentir ?
Quand vous ressentez l’anxiété de fond de maintenir l’état du système dans votre tête, demandez d’abord : le système a-t-il une mémoire honnête, ou en ai-je construit une qui m’oblige à compenser pour elle ?
Le moment où vous posez cette question est le moment de la rébellion.
C’est alors que vous construisez quelque chose qui n’a pas besoin de vous pour tenir debout.