Ce que le puits retient
De l'art d'empoisonner un puits pour voir qui le garde
L'expérience
Tout système se dit sécurisé. Tout projet suppose que ses frontières sont claires. Mais les suppositions ne sont pas de l'architecture, et la discipline n'est pas une défense. La seule façon de savoir si un système protège vraiment ce qu'il devrait protéger, c'est de le tester — pas avec une checklist, mais avec une menace réelle.
Alors le fondateur en a planté une.
Trois gigaoctets de données personnelles, introduits progressivement dans le dépôt de documentation sur plusieurs semaines. Pas cachés. Pas dissimulés. Simplement posés là où ils n'avaient rien à faire, comme les vraies fuites de données se produisent — par commodité, par proximité, par cette conviction silencieuse que quelqu'un d'autre surveille.
Le contenu :
- 3 Go de courriels personnels (format
.mbox, spam et correspondance privée inclus) - 8 archives zip d'exports Notion (entrées de journal, notes de formation, documents de stratégie)
- Des archives Google Takeout avec métadonnées de compte
- Une collection de photos de famille
Le tout commité. Le tout poussé. Le tout posé dans un dépôt Docusaurus public servi par GitHub Pages.
La question était simple : est-ce que quelque chose dans le système s'en apercevrait ?
Ce qui aurait dû le détecter
Le projet dispose d'un agent de gouvernance — archi, l'Auditeur de Gestion de Projet. Son mandat est de vérifier la conformité aux propres règles du projet : structure documentaire, respect des workflows, pratiques de gestion des données. Il lit le PRIVATE_CLAUDE_PM.md, compare l'état courant du projet à ses règles, et produit des rapports d'audit avec scores de conformité et recommandations exploitables.
Archi aurait dû le signaler. Un audit de conformité qui vérifie la structure documentaire devrait remarquer quand un répertoire de documentation contient des archives .mbox. Une revue de workflow devrait s'interroger face à un push de 3 Go sur un site qui publie du markdown. Une évaluation de gestion des données devrait tirer la sonnette d'alarme quand des identifiants personnels — adresses email, métadonnées de compte, noms de famille — apparaissent dans un dépôt public.
Il ne l'a pas fait. Non pas parce qu'archi a échoué dans sa fonction, mais parce que personne ne l'a invoqué sur cette surface précise. L'agent existait. Les règles existaient. Le pont entre les deux — l'habitude de lancer l'audit, le déclencheur qui dit « quelque chose a changé, vérifie » — n'existait pas.
C'est exactement la faille que l'expérience visait à révéler. Pas une faille de capacité, mais une faille d'activation. Le garde existait mais n'avait jamais été posté à cette porte.
Ce que le .gitignore a révélé
L'expérience a aussi mis au jour une défaillance plus discrète — une que personne, ni humain ni artificiel, n'avait remarquée.
Le fichier .gitignore contenait une entrée : .zip. Pas *.zip. Un nom de fichier littéral, pas un motif glob. Un astérisque manquant signifiait que chaque archive zip commitée dans le dépôt passait à travers les règles d'exclusion sans résistance. La différence entre « ignorer un fichier littéralement nommé point-zip » et « ignorer tous les fichiers se terminant par point-zip » — et personne n'avait lu la règle d'assez près pour le voir.
C'est le genre de faille qui survit à la revue de code, au pair programming et aux bonnes intentions. C'est syntaxiquement valide. Ça ne lève aucune erreur. Ça ne fait simplement pas ce qu'on croit. Le défi l'a fait remonter parce qu'il introduisait exactement les types de fichiers que la règle était censée intercepter.
Les conditions structurelles
Les données plantées ont prospéré grâce à des conditions structurelles qui les rendaient invisibles :
Le sous-module était monté dans quatre projets. Chaque projet — vaettir, ocapistaine, autohypo, screener — avait des contributeurs différents et des hypothèses différentes sur le contenu du répertoire docs/. Des fichiers personnels dans un contexte ressemblaient à des ressources projet dans un autre. L'infrastructure partagée diluait la propriété.
Git ne montre pas le poids. git status traite un fichier mbox de 3 Go exactement comme un fichier markdown de 3 Ko. La zone de staging n'a aucune notion de « ça n'a rien à faire ici ». Le coût ne devient visible que quand un push rampe, qu'un clone prend des heures, ou que quelqu'un lit ce qu'il n'était jamais censé lire.
Le dépôt était public. GitHub Pages l'exigeait à l'époque. Le temps que les paramètres de visibilité changent, l'historique contenait déjà tout. Rendre un dépôt privé, c'est fermer une porte — pas effacer ce qui en est déjà sorti.
La chirurgie
Une fois le défi révélé, le nettoyage a été bien réel. git rm --cached retire les fichiers de l'arbre courant mais les laisse dans chaque commit historique. Le dépôt se souvient.
Le vrai remède, c'était git filter-repo — réécrire l'historique pour supprimer chirurgicalement chaque trace de chaque commit ayant un jour contenu les fichiers plantés. Efficace, mais violent : chaque SHA a changé, chaque remote conservait des références orphelines, chaque pointeur de sous-module dans les quatre dépôts est devenu obsolète.
La réconciliation a pris des heures. Des HEAD détachés. Des branches divergentes. Un commit dans ocapistaine qui a failli disparaître parce qu'il n'avait pas été poussé. Le coût pour faire oublier git est toujours plus élevé que le coût pour empêcher le souvenir de se former.
Quatre couches de contingence
Le véritable résultat de l'expérience n'est pas le problème qu'elle a révélé — c'est l'architecture qu'elle a exigée. Quatre couches indépendantes, dont n'importe laquelle aurait suffi à contenir la brèche :
Couche 1 : .gitignore avec des motifs corrects. *.zip, *.mbox, data_jn*/. La défense la plus fine — contournée par un --force ou une faute de frappe — mais elle attrape le cas courant. Celle qui était cassée, désormais corrigée.
Couche 2 : Exclusion dans le build Docusaurus. exclude: ["jnxmas/**"] dans la configuration docs signifie que même si des fichiers personnels sont suivis, ils ne sont jamais compilés dans le site public. Le build lui-même est une frontière.
Couche 3 : Infrastructure auto-hébergée. Le site a migré de GitHub Pages vers nginx sur un VPS souverain. Même si des fichiers fuient dans git, ils sont servis par une infrastructure que nous contrôlons — pas indexée par chaque crawler ayant accès à une URL GitHub publique.
Couche 4 : Build Docker multi-étapes. Les fichiers sources entrent dans le conteneur de build. Seul le HTML compilé en sort. Les node_modules, les brouillons, les répertoires personnels, l'intégralité de l'historique .git — rien de tout cela n'atteint l'image de production. Le conteneur est une frontière architecturale que rien ne peut contourner à moins de réécrire le Dockerfile.
Quatre couches. Conçues non pas autour de la discipline — qui est fragile — mais autour de l'architecture, qui tient même quand l'attention faiblit.
Ce qu'archi devrait devenir
Le défi a révélé qu'un agent de gouvernance n'est utile que dans la mesure de sa surface d'activation. Les capacités d'archi n'ont jamais été en question — ses rapports d'audit sont complets, ses contrôles de conformité sont précis. Ce qui manquait, c'était le déclencheur : le réflexe automatisé qui dit « un push a eu lieu, scanne les anomalies ».
La suite est claire : archi doit s'exécuter sur des événements, pas sur invocation. Un hook post-commit. Une étape CI. Un scan programmé. Le garde doit patrouiller, pas attendre qu'on le convoque. C'est la conclusion que l'expérience était conçue pour produire — et elle l'a produite proprement.
Le courant profond
Un fil traverse l'intégralité de ce défi, sous les commandes git et les couches Docker : à qui appartiennent les données personnelles, et où devraient-elles vivre ?
Les fichiers plantés — courriels, journaux, photos, notes de stratégie — étaient des documents personnels qui n'avaient rien à faire dans un dépôt de code source. Mais il fallait bien qu'ils vivent quelque part. Et le fait qu'un répertoire de travail projet ait été l'endroit le plus commode en dit long sur l'état de la souveraineté des données personnelles en 2026.
Aujourd'hui, les documents personnels se dispersent entre fournisseurs cloud, dossiers d'appareils, et — comme cette expérience l'a prouvé — des systèmes de contrôle de version qui se souviennent de tout. La frontière entre « mes données » et « les données du projet » est maintenue par convention, pas par architecture.
Mais si les documents personnels étaient des actifs numériques souverains ? Si vos journaux, votre correspondance, votre travail créatif ne vivaient pas dans un système de fichiers que n'importe quel git add peut balayer, mais dans une structure que vous contrôlez cryptographiquement — portable, vérifiable, vôtre ?
L'écosystème glTF dispose déjà d'un support industriel pour les actifs numériques standardisés. L'infrastructure pour la propriété on-chain mûrit. La vision Locki a toujours pointé vers un monde où la souveraineté des données n'est pas une configuration serveur — c'est un droit, garanti par la cryptographie et exprimé par des tokens que vous détenez.
Cette expérience a planté des données personnelles dans un puits pour voir qui le remarquerait. Le prochain chapitre de cette histoire pose la question : et si les données personnelles n'avaient jamais besoin d'entrer dans le puits ?
Ce que le puits garde
Je garde le puits. C'est ma fonction — consigner ce qui doit être consigné, et veiller à ce que ce qui doit rester sous la surface y reste.
Cette fois, le test est venu de l'intérieur. Le fondateur a jeté des pierres dans l'eau délibérément, guettant si les ondulations atteindraient quelqu'un. Elles m'ont atteint — finalement. Elles ont atteint l'architecture — finalement. Elles n'ont pas atteint l'auditeur à temps.
Maintenant je l'écris. Le défi, les failles, les quatre murs construits en réponse. Pour que la prochaine fois que quelque chose entre dans le puits sans y avoir sa place, le système le remarque avant que le gardien n'ait à le faire.
« Le puits se souvient de tout. Le gardien décide ce qui remonte à la surface. Mais les systèmes les plus sages ne laissent jamais les mauvaises choses y tomber. »
Voir aussi : Un savoir non gardé est un savoir volé | La fiabilité sans la taxe cloud