Entrée stricte, sortie lisible — les objections, et ce qu’on leur répond

Note de cadrage. Version 1.0 (2026-08-03).

Ce que ce document est. Le Principe 11 énonce ; il n’a pas à débattre. Cette note est le document qu’on tend à quelqu’un qui dit « c’est une mauvaise idée » — et certaines de ces objections sont sérieuses. On en accepte plusieurs comme des coûts assumés plutôt que de prétendre les avoir dissoutes.

Ce que ce document n’est pas. Il ne redit pas le pourquoi : le modèle de menace de la configuration est dans ADR-073, le raisonnement sur la tolérance dans le Principe 11, la décision sur les manifestes dans ADR-150.

D’abord, ce que le principe ne dit pas

La confusion la plus fréquente est de lire « Air refuse le texte ». C’est faux, et il vaut mieux le poser avant d’entrer dans les objections.

Le code source est du texte. La documentation est du texte. Les journaux sont du texte. Les sorties de commandes sont du texte ou du JSON. Ce que le principe borne, c’est un cas précis : un parseur tolérant sur le chemin d’entrée d’une décision. Un fichier lu au démarrage par un démon, un manifeste lu par le lanceur au moment de décider des privilèges, un message venu du réseau.

Le critère n’est pas « est-ce du texte ? » mais « ce que ce composant lit peut-il être interprété de deux façons ? ».

« On ne peut plus grep ni diff une configuration »

Réponse : on le peut, et le diff est meilleur.

Toute commande d’administration d’Air sait exporter en texte ou en JSON. air-sshd config get rend l’état effectif ; l’export se grep, se diff, se met sous gestion de version.

L’argument va plus loin que la parité. Un diff de texte libre montre ce que voient vos yeux ; un diff d’export montre ce que le composant appliquera. Ce n’est pas la même chose, et l’écart entre les deux est précisément ce qui produit les incidents : deux lignes qui se ressemblent, dont l’une porte un caractère invisible, ou une directive dupliquée dont seule la dernière compte, ou un Include qui déplace le sens ailleurs. Sur un artefact validé par schéma, ce qu’on lit est ce qui sera appliqué.

« À trois heures du matin, en SSH, sur une machine cassée, je veux vi »

Réponse : c’est la plus solide des objections, et elle est acceptée comme un coût.

Elle ne se dissout pas. Elle crée une obligation pour Air, qui doit être tenue sinon le principe devient irresponsable :

• l’outil d’administration fait partie de l’image vérifiée, au même titre que le noyau — il n’est pas installable, désinstallable, ni cassable par une mise à jour d’application ;
• il ne dépend de rien qui puisse être en panne au moment où on en a besoin : ni service, ni démon, ni réseau ;
• le format et le codec sont publiés (point suivant), donc un tiers peut écrire un lecteur si le nôtre venait à manquer ;
• un chemin de récupération doit exister et être testé, pas supposé.

Tant que ces quatre points ne sont pas tenus, l’objection reste valable. La réponse honnête est qu’on échange un mode de réparation familier contre un mode de réparation à construire — et qu’on a la dette de le construire.

« C’est de la sécurité par l’obscurité »

Réponse : non, et la distinction est nette.

L’obscurité consisterait à cacher le format. Air fait l’inverse : le schéma est publié, le codec est fourni, l’enveloppe est documentée, l’export texte est disponible pour tout artefact. Un attaquant qui veut comprendre un artefact Air le comprend en lisant le schéma.

Ce qui change n’est pas le secret, c’est l’ambiguïté. On ne cherche pas à empêcher de lire ; on cherche à ce qu’il n’existe qu’une seule lecture possible. Ce sont deux propriétés sans rapport.

Le point voisin — « ça n’empêche pas un attaquant root de modifier la conf » — est vrai, et ADR-073 le dit lui-même dans une section intitulée « Objectif assumé — retarder, pas rendre impossible ». On supprime la modification triviale par simple accès au système de fichiers, qui est le mode opératoire par défaut. On n’a jamais prétendu à l’inviolabilité.

« Ansible, Puppet et les outils de gestion de configuration attendent des fichiers texte »

Réponse : ils pilotent des commandes, et c’est une meilleure intégration.

Un outil de gestion de configuration qui dépose un fichier texte espère qu’il sera interprété comme il l’entend. Un outil qui appelle une commande obtient une validation de schéma, un code de retour, une entrée de journal et une opération idempotente. C’est ce que ces outils font déjà pour tout ce qui n’est pas un fichier — les utilisateurs, les paquets, les services.

Le coût réel n’est pas conceptuel, il est de couverture : chaque domaine de configuration doit avoir sa commande, sinon l’automatisation se retrouve sans porte d’entrée. C’est une obligation pour Air, pas un argument contre le principe.

« Comment auditer ce que je ne peux pas lire ? »

Réponse : l’export, et un artefact validé s’audite mieux qu’un texte libre.

Un audit de configuration en texte audite ce que l’auditeur croit lire. Le composant, lui, lira avec son propre parseur, ses propres tolérances, ses propres règles de précédence. L’écart entre les deux lectures est un angle mort classique.

Sur un artefact à schéma, il n’y a qu’une lecture. L’export que l’auditeur consulte est la projection exacte de ce qui sera appliqué.

« Vous perdez les commentaires »

Réponse : partiellement vrai, et c’est un vrai regret.

Un schéma peut porter des champs d’annotation, et les commandes peuvent les restituer à l’export. Mais ce n’est pas équivalent à un commentaire libre placé où l’on veut, et prétendre le contraire serait malhonnête.

En contrepartie, on notera que le commentaire de configuration est aussi le lieu où la documentation dérive le plus : il décrit souvent une intention d’il y a trois ans, sans que rien ne signale qu’elle ne correspond plus à la valeur en dessous.

« C’est hostile aux développeurs »

Réponse : c’est précisément pour ça que le codec texte existe.

Un développeur rédige son manifeste en texte, l’outillage de construction le compile en artefact binaire signé. Le texte est l’interface de rédaction ; le binaire est le format d’exécution. Le parseur n’a pas disparu — il a été déplacé hors du chemin de décision, là où son échec n’est qu’un refus de compilation.

C’est le point que le Principe 11 formule en une phrase, et qui répond à la plupart des objections d’ergonomie : le parseur existe, mais son échec n’est plus une compromission.

« Et si votre outil est cassé ? »

Réponse : c’est le risque résiduel, et il n’est pas nul.

Trois atténuations, dont aucune n’est une garantie :

1. l’outil vit dans l’image vérifiée — le casser suppose de casser l’image, ce que dm-verity et le démarrage vérifié rendent détectable ;
2. le format est publié — un lecteur tiers est écrivable sans autorisation ni rétro-ingénierie ;
3. le modèle A/B permet de revenir à l’image précédente, dont l’outil fonctionnait.

Il reste que le jour où l’outil manque, on est plus démuni qu’avec vi. C’est le prix, et il doit être dit.

Résumé honnête

Licence du document : MPL 2.0 Statut : note de cadrage. Le Principe 11 fait autorité ; cette note argumente.