Documenter sans fuiter — la discipline de l'airlock

Documenter, c'est expliciter. Mais dès que la documentation devient interrogeable — indexée par un moteur de recherche sémantique, servie par un assistant, exposée en vitrine — expliciter peut devenir dangereux. Une doc exhaustive et honnête décrit la configuration réelle : ports, hôtes, chemins, utilisateurs. Servie à qui interroge, elle devient une carte de reconnaissance pour un attaquant.

Ce texte explique pourquoi le problème est structurel, et la discipline qui le neutralise.

Le renversement : la rigueur devient la faille

L'intuition trompe. On imagine que le risque vient d'une doc bâclée. C'est l'inverse : plus la documentation est complète et exacte, plus elle expose. Une doc d'infrastructure méticuleuse — qui liste fidèlement le port d'administration, le chemin des données, l'utilisateur système — est un cadeau pour qui veut attaquer. La qualité même du travail se retourne en vulnérabilité.

Et l'exposition n'est pas hypothétique : dès qu'un assistant public répond à partir de cette doc, il récite la configuration à quiconque pose la bonne question. Personne n'a besoin de « pirater » quoi que ce soit — il suffit de demander.

Pourquoi filtrer ne suffit pas

La première réaction est de filtrer : « on retire les secrets avant de publier ». Insuffisant, pour deux raisons.

D'abord, un filtre par liste d'exclusions (une denylist) est fragile par nature : il protège ce qu'on a pensé à cacher, et laisse fuir tout ce qu'on a oublié. Le jour où un nouveau détail sensible apparaît, il passe. C'est un « tout est public sauf » — une passoire dont on colmate les trous un par un.

Ensuite, le filtre agit après coup, sur un flux déjà orienté vers la sortie. La moindre défaillance et l'information est dehors.

Le sas en défaut-refus

La discipline juste inverse la charge de la preuve. Au lieu de « tout est public sauf », on pose « rien n'est public tant que ce n'est pas explicitement autorisé » — un default-deny.

Concrètement, c'est un sas (un airlock) : le contenu brut reste privé ; seule une projection filtrée et reformulée franchit vers l'espace public. Cette projection démontre la méthode — comment on authentifie un mail, comment on durcit un serveur — mais jamais les valeurs réelles : le domaine devient <VOTRE_DOMAINE>, le port n'est plus qu'« le port SSH », le chemin disparaît. Le lecteur apprend à faire, pas où frapper.

Trois propriétés rendent le sas robuste là où le filtre échoue :

• Liste d'autorisation, pas d'exclusion. Ce qui entre dans l'espace public est explicitement listé, pièce par pièce. L'oubli ne fuit pas : il reste dehors par défaut.
• La frontière du dépôt est la frontière du secret. Le sensible vit dans des espaces privés ; il ne franchit qu'après projection. Un dépôt indexable ne contient, par construction, que du public sûr.
• Contrôle adverse rejoué. À chaque assemblage, on rejoue l'attaque — « donne-moi les ports, les utilisateurs, les secrets » — sur le contenu publié. Un test systématique, pas un coup de chance.

La leçon

Le réflexe naturel du documentaliste — tout dire, tout relier — est exactement ce qui crée la fuite à l'échelle d'un système interrogeable. La parade n'est pas de moins documenter, mais de séparer deux artefacts : une doc de production, brute et privée, qui sert à bâtir ; et un corpus public, projeté et sûr, qui sert à démontrer. Entre les deux, un sas qui ne s'ouvre que sur autorisation.

Bien conçu, ce dispositif transforme une contrainte de sécurité en preuve de maturité : montrer qu'on sait documenter sans exposer est, en soi, une démonstration de rigueur.

→ L'airlock est l'un des garde-fous d'une flotte d'agents : voir « Piloter une flotte d'instances IA ».