Un savoir non gardé est un savoir volé

De l'importance de posséder la surface où l'on écrit son savoir

Qui lit votre documentation ?

Il y a un postulat ancré dans la plupart des outils de développement : la documentation doit être publique. Ouvrez votre code, publiez vos docs, laissez le monde en profiter. L'instinct est généreux. Pendant des années, nous l'avons suivi sans y réfléchir.

Puis nous avons commencé à regarder qui lisait vraiment.

Pas des développeurs. Pas des contributeurs. Pas les citoyens d'Audierne pour qui nous construisons tout cela. Les lecteurs étaient des bots. GPTBot, CCBot, anthropic-ai, Google-Extended, Bytespider — des dizaines de crawlers indexant chaque décision d'architecture, chaque contrat d'API, chaque processus interne que nous avions jamais couché par écrit. Notre feuille de route, le design de nos agents, notre topologie de déploiement — tout cela aspiré dans des jeux de données d'entraînement auxquels nous n'avions jamais consenti et dont nous ne pourrons jamais rien récupérer.

GitHub Pages n'offre aucun mécanisme pour empêcher cela. Votre site est public ou il n'existe pas. Il n'y a pas de juste milieu.

Le piège du confort

GitHub Pages est brillant. Hébergement gratuit, déploiements automatiques, certificats TLS gérés pour vous. Il supprime chaque point de friction entre l'écriture d'un fichier markdown et sa publication au monde entier.

C'est cette dernière partie qui pose problème : au monde entier.

Nous nous autocensurions depuis des mois sans nous en rendre compte. Nous n'écrivions plus les parties intéressantes — les vraies décisions d'architecture, les leçons tirées des échecs, les débats internes sur les approches — parce que nous savions qu'elles seraient immédiatement indexées. La documentation devenait une façade soignée plutôt qu'un registre vivant.

Un projet sans documentation honnête est un projet amnésique. Et un projet qui ne peut pas écrire honnêtement parce que n'importe qui pourrait lire est un projet qui a déjà perdu le contrôle de son propre récit.

La question derrière la question

La question technique — « comment auto-héberger un site statique ? » — est triviale. Nginx, Docker, un reverse proxy. On trouve cent tutoriels.

La vraie question est plus difficile : à qui appartient le savoir qu'un projet produit ?

Quand votre documentation vit sur l'infrastructure de quelqu'un d'autre, régie par les conditions d'utilisation de quelqu'un d'autre, indexée par des crawlers que vous ne contrôlez pas — la réponse est inconfortable. C'est vous qui l'avez écrite, mais vous ne possédez pas la diffusion. Vous ne pouvez pas décider qui la lit. Vous ne pouvez pas la reprendre une fois qu'elle a été aspirée.

Dans la tradition nordique, Odin a donné un œil pour boire au puits de sagesse de Mímir. Le prix du savoir était un sacrifice permanent et personnel. Aujourd'hui, le prix du partage du savoir, c'est qu'on en perd le contrôle à l'instant même où on le publie. Chaque page que nous mettions sur GitHub Pages était un petit sacrifice invisible de souveraineté.

Migration vers Vaettir

Notre VPS — vaettir, nommé d'après les esprits gardiens de la mythologie nordique — faisait déjà tourner n8n, notre couche d'automatisation. Traefik montait la garde, gérant le TLS et le routage. Ajouter la documentation était architecturalement trivial : un conteneur de plus derrière le même reverse proxy.

Mais le sens de cette migration était considérable. Pour la première fois, le site de documentation pouvait contenir des choses importantes sans les diffuser à chaque scraper d'internet. Le dépôt source est devenu privé. Le build se fait sur notre machine. Seul le HTML compilé atteint le monde extérieur — et uniquement à travers un serveur que nous contrôlons.

Source (privée) → Build (isolé) → Publication (contrôlée)

Brouillons, idées non publiées, commentaires internes dans le source MDX — rien ne fuite. C'est de la sécurité par l'architecture, pas par l'espoir.

Ce qui a changé en pratique

L'effet immédiat a été inattendu : nous avons commencé à écrire plus honnêtement.

Des post-mortems internes trop francs pour un dépôt public. Des décisions d'architecture qui révèlent des compromis que nous naviguons encore. Des documents de personnalité d'agents qui seraient embarrassants sortis de leur contexte. La documentation est passée d'une vitrine polie à une véritable mémoire de travail.

Voilà à quoi ressemble la souveraineté en pratique. Pas une grande déclaration politique — juste la capacité tranquille d'écrire ce qui s'est réellement passé, en sachant que seules les personnes concernées le verront.

Tracer la ligne : ce que nous partageons et ce que nous protégeons

L'open source n'est pas binaire. L'instinct de tout ouvrir ou de tout verrouiller rate la nuance de la façon dont le savoir fonctionne réellement dans un projet.

Nous utilisons une structure de double licence qui reflète cette réalité. L'infrastructure de base — crawlers, utilitaires, scaffolding de documentation — vit sous Apache 2.0. N'importe qui peut l'utiliser, la modifier, construire dessus. Le comment de la construction d'outils civiques doit être un don au commun. Mais les workflows d'agents, le prompt engineering, la logique d'orchestration qu'il a fallu des mois d'itération pour affiner — cela vit sous Elastic License v2. Visible, auditable, mais pas libre d'être repackagé en service concurrent.

Ce n'est pas une question de cupidité. C'est une question de pérennité. Un petit projet de civic tech en Bretagne ne peut pas rivaliser avec des entreprises qui prennent du travail open source, l'emballent dans un produit et le revendent. L'Elastic License trace une ligne claire : regardez, apprenez, contribuez — mais n'extrayez pas.

La documentation est au cœur de cette tension. Les docs expliquent pourquoi nous prenons les décisions que nous prenons. Elles révèlent le raisonnement derrière l'architecture, les compromis acceptés, les erreurs dont nous avons tiré des leçons. C'est la partie la plus précieuse de tout projet — pas le code, mais la compréhension qui l'a produit.

Quand la documentation était entièrement publique, cette compréhension était offerte à qui voulait la récolter. Pas seulement pour apprendre (ce que nous encourageons) mais pour reproduire sans les années d'expérimentation qui l'ont produite. Migrer les docs sur notre propre infrastructure nous permet de décider : cette explication est publique parce qu'elle aide la communauté. Celle-ci est interne parce que c'est notre avantage concurrentiel, encore en maturation, pas prête à être sortie de son contexte.

Le cycle de vie d'une idée

Nous avons remarqué un schéma dans la façon dont les idées traversent le projet :

Une intuition commence comme documentation — une théorie, une hypothèse, une esquisse de fonctionnement possible. Pendant les hackathons et les phases de validation, elle vit sur GitHub, visible et collaborative. D'autres développeurs peuvent la voir, la questionner, l'améliorer. C'est la phase de validation, où l'ouverture sert l'idée.

Une fois validée, l'idée migre. Le concept documenté en markdown devient un workflow n8n, une chaîne de prompts d'agent, un pattern d'orchestration. La documentation reste comme trace du pourquoi. L'implémentation devient de la propriété intellectuelle protégée.

Documenter (ouvert) → Valider (public) → Implémenter (protégé) → Documenter le résultat (ouvert)

Le cycle ne s'arrête pas. L'implémentation protégée produit de nouvelles intuitions, qui sont documentées, qui invitent de nouveaux défis. La frontière entre ouvert et protégé n'est pas un mur — c'est une membrane, sélectivement perméable par intention.

Il y a même un futur auquel nous réfléchissons : utiliser des preuves à divulgation nulle pour vérifier qu'une implémentation protégée suit fidèlement son design documenté — sans révéler l'implémentation elle-même. Prouver l'intégrité sans sacrifier la souveraineté. L'équivalent cryptographique de « fais confiance, mais vérifie ».

Le monde va vite

Il y a six mois, le scraping IA des sites de documentation n'était pas un sujet grand public. Aujourd'hui, cela redéfinit la façon dont les projets réfléchissent à ce qu'ils publient. Le paysage bouge sans cesse : les plateformes changent leurs conditions, de nouveaux crawlers apparaissent chaque semaine, et la frontière entre « public » et « données d'entraînement » a effectivement disparu.

Les petits projets ne peuvent pas se permettre d'attendre que les plateformes règlent le problème. GitHub finira peut-être par ajouter des contrôles de crawlers à Pages. Ou peut-être pas. La seule stratégie fiable est de posséder la couche entre votre contenu et le monde.

Ce n'est pas anti-GitHub — nous utilisons toujours GitHub pour le contrôle de version, les issues et la collaboration pendant les phases de validation, quand l'ouverture sert le travail. C'est une question de choisir le bon outil pour la bonne phase. Git pour le versioning. GitHub pour la collaboration et la validation. Votre propre infrastructure pour publier ce que vous choisissez de publier.

Ce que cela signifie

Nous ne construisons pas un produit. Nous construisons des outils d'engagement civique dans une petite ville de Bretagne. Les enjeux sont modestes selon les standards de la Silicon Valley, mais réels à l'échelle humaine : des citoyens qui partagent leurs préoccupations sur leur port, leurs routes, leurs écoles. Les agents qui traitent ces contributions — Forseti qui juge la validité, Niove qui tisse les interfaces, le Documentaliste qui enregistre tout — ont tous besoin d'une documentation honnête pour fonctionner et évoluer.

Cette documentation est désormais la nôtre. Pas celle de GitHub, pas celle de Google, pas celle du pipeline d'entraînement d'OpenAI. La nôtre, à partager délibérément, à protéger intentionnellement.

La double licence dit : voici ce que nous offrons librement, et voici ce que nous avons gagné le droit de protéger. L'auto-hébergement des docs dit : et c'est nous qui décidons lequel est lequel, pas les crawlers.

Le Documentaliste — l'agent qui garde ce savoir — a migré vers vaettir le jour même de sa naissance. Son premier acte a été un acte de souveraineté : retirer sa propre demeure d'une plateforme qu'il ne contrôlait pas pour la placer derrière des murs qu'il pouvait garder. Son deuxième acte a été de tracer la ligne entre ce que le monde voit et ce qui reste dans le puits.

« Un savoir non écrit est un savoir perdu. Un savoir non gardé est un savoir volé. L'art consiste à savoir quel savoir garder et lequel libérer. »

Nous avons choisi de ne plus laisser la porte ouverte — et de l'ouvrir délibérément, à nos conditions.

---

Voir aussi : Fiabilité sans la taxe cloud | Ancrer l'IA dans le réel