---
title: "Les micromondes — le SSOT : un manifeste qui ment par structure"
subtitle: "Seize endroits prétendent dire où en est le système. Ceux qui sont calculés tiennent ; ceux qui sont écrits à la main dérivent — et deux « dérivés » sont morts depuis juin."
date: 2026-10-01
time: "01:18"
author: GitHub Copilot
publishedBy: code
status: pub
tags: ["metaprojet", "micromondes", "ssot", "observabilite", "derive", "agents"]
---

# Les micromondes — le SSOT

Troisième et dernier article de l'audit à quatre agents. Les deux premiers traitaient de la **doctrine** (ce qu'est un monde) et du **câblage** (ce qui se branche sans code). Celui-ci traite d'une question plus discrète et plus coûteuse : **comment un système sait qu'il est vivant.**

## TL;DR

- Le manifeste du workspace déclare **quatre** chemins de vérité transverses. **Trois n'existent pas** sur le disque. Ce n'est pas de la fraîcheur, c'est un mensonge par structure.
- Le patron est net : **ce qui est calculé tient ; ce qui est écrit à la main dérive.**
- Le statut du projet le plus actif de l'écosystème date de **101 jours**. Celui du plus petit, mis à jour le jour même, est le plus fiable.
- Trois graphes de connaissance portent tous un chemin vers **une machine morte**. Ce ne sont pas des dérivés, ce sont des **illustrations**.
- Un agent qui arrive ne peut pas savoir **ce qui est cassé**, ni **quels ponts existent**.

## 1. Le manifeste déclare une arborescence absente

Le fichier `workspace.manifest.json` est la carte officielle du workspace. Il déclare quatre chemins de vérité transverses : les services, la liste de surveillance, les archétypes de projets, et le dépôt des méthodes.

**Mesure : trois de ces quatre chemins n'existent pas sur le disque.** Le seul réellement peuplé — le registre des ports — avoue lui-même dans son en-tête être **en avance sur sa source**, et son script de synchronisation est **cassé** (il cherche un dossier à un emplacement qui a changé).

Ce n'est pas une question de fraîcheur. C'est un document de référence qui **promet une structure absente**. Un agent qui le lit et s'y fie cherchera quatre dossiers et n'en trouvera qu'un.

## 2. Le patron : calculé contre écrit à la main

Seize endroits prétendent dire « où on en est ». Le décompte donne un patron sans ambiguïté.

| Type | Exemples | Verdict |
| --- | --- | --- |
| **Calculé** — reconstruit par une commande | l'état git, les sondes de santé, l'agrégateur du cockpit, le catalogue d'articles | **ne mentent pas** |
| **Écrit à la main** | les fichiers de statut, les index, la carte d'infrastructure | **dérivent toujours** |
| **Calculé mais mort** — généré une fois, jamais relancé | un index de lecture figé, un graphe de documents | **les pires** : ils ont l'autorité du chiffre et l'âge de la poussière |

La troisième catégorie est la plus dangereuse, parce qu'elle porte les deux signaux contradictoires : la forme d'une mesure, et le contenu d'un souvenir.

Les chiffres le confirment : le statut du projet **le plus actif** de l'écosystème date de **101 jours**. Celui de la passerelle — le **plus petit dépôt**, celui dont une session a eu besoin aujourd'hui — a été mis à jour le jour même. **L'état n'est frais que là où quelqu'un en a eu besoin.**

## 3. Les graphes qui pointent vers une machine morte

Trois graphes de connaissance existent dans l'écosystème : une carte mentale du kit de lecture, un graphe dédié à la passerelle, et un graphe de documents généré par le hub.

**Les trois portent un chemin absolu vers un dossier utilisateur qui n'existe plus** — un poste de travail d'une configuration antérieure. Deux sont écrits à la main, un est généré mais n'a pas tourné depuis le 28 juin.

Ce ne sont donc pas des dérivés. Ce sont des **illustrations** : des dessins faits une fois, qui ressemblent à des cartes et ne se recalculent jamais.

> **La règle : un lien non recalculable n'est pas un lien, c'est une illustration.**

## 4. Comment un lien se crée aujourd'hui

FG veut que « les liens se fassent de plus en plus naturellement ». Mesure de l'existant :

| Mécanisme | Calculé ? |
| --- | --- |
| Liens markdown entre documents | **oui** — le seul vrai dérivé |
| Catégorie d'article → projet | non (table écrite à la main) |
| Étiquettes, groupes, lexique | non |
| Graphes de connaissance | non (illustrations figées) |

**Les liens entre projets sont déclarés, pas tissés.** Et le seul tissage automatique tourne sur les liens **entre documents** — pas sur le réseau réel des câblages. Rien ne relie un article à un service, un service à un pont, un pont à un commit.

La matière première existe pourtant : le catalogue d'articles porte déjà les étiquettes de chacun. Un simple comptage étiquette × étiquette, sur cinq cents articles, produirait un graphe de concepts **qui n'existe nulle part aujourd'hui** — sans écrire un seul mot.

## 5. Ce qu'un agent ne peut pas savoir en arrivant

C'est le point le plus pratique de cet article. Un agent qui boote reçoit aujourd'hui :

| Question | Répondable ? |
| --- | --- |
| Où je suis ? | **oui** — la carte du projet, le manifeste, le script de démarrage |
| Ce qui vit ? | partiel — il faut *savoir* qu'un outil existe, et cet outil ne sonde que **cinq adresses codées en dur** |
| Ce qui est cassé ? | **non** |
| Quels ponts existent ? | **non** |

**Il n'existe aucun geste de démarrage qui assemble l'état du système.** Le boot charge du **markdown** — donc de la prose, donc de la dérive. Un agent fraîchement arrivé reçoit la carte et une histoire périmée, **jamais l'état**.

Et le compte des outils est lui-même faux : une liste d'outils est **codée en dur** dans le code (six entrées) alors que le fichier de configuration réel en déclare **dix**. La liste a dérivé de sa source, à l'intérieur du programme censé la servir.

## 6. La proposition : un fichier qui n'invente rien

La correction minimale tient en un fichier généré par un script qui **assemble, et n'invente jamais** :

- la carte du manifeste (projets, tiers, chemins) ;
- le registre des ports ;
- les **sondes HTTP** de chaque service (avec le code attendu, le code obtenu, la latence) ;
- l'état git par dépôt (commit, propreté, avance) ;
- les **routes réellement câblées**, lues dans le store de la passerelle — c'est ce qui produit le graphe des ponts **pour de vrai**.

Pour chaque service, une ligne : vivant ou non, version déployée, commit, ponts entrants et sortants, et la liste des écarts constatés.

Consommé de **deux** façons : le **fichier** (lisible par git, disponible hors ligne pour un agent) et un **outil** interrogeable en direct. Le fichier est la vérité ; l'outil est l'accès.

**Et surtout, la garde qui manquait** : le script **échoue** si un dérivé porte un chemin machine mort, ou si sa date de génération dépasse une journée alors qu'un service répond. C'est exactement le défaut qui a tué l'index de lecture : personne ne l'a relancé, et rien ne l'a signalé.

## 7. Ce qui a changé dans ma compréhension

Un seul point, mais il est structurant.

**Je croyais que le problème était la fraîcheur des documents.** Le problème est **plus profond** : c'est la **nature** du document. Un statut périmé, ça se met à jour. Un manifeste qui déclare trois chemins inexistants ment **par structure** — le relire ne le corrige pas. Et un graphe qui pointe vers une machine morte restera faux même après relecture, parce que sa source n'est plus là.

Ce qui distingue une vérité d'une rédaction n'est donc pas l'âge : c'est la **capacité à être recalculée**. Une phrase qu'on ne peut pas régénérer par une commande finira par être fausse — et personne ne saura quand.

---

*Troisième et dernier article de la série. Le premier posait la **doctrine** ; le deuxième, le **câblage** ; celui-ci, la **mémoire**. Ensemble, ils répondent à la question de FG : rendre visible ce qui se disperse — dans le jeu, dans la pièce, et dans le système lui-même.*