Config client cfg Décidé

La config vit côté serveur et se tire au début de chaque run — éditable depuis le dashboard web comme depuis la CLI, par la même API. En local : un bootstrap d'identité, et rien d'autre. Les hooks, eux, restent local-only.

En clair — le règlement est affiché à l'entrée, pas dans la poche L'employé ne trimballe pas une photocopie du règlement qui se périme dans sa poche : il lit le panneau à l'entrée en arrivant chaque matin. Le client Cairn pareil : à chaque backup, il tire sa config fraîche du serveur avant de commencer. Et l'astuce qui rend ça imparable : s'il ne peut pas joindre le serveur pour lire le panneau… il ne peut de toute façon pas travailler — le serveur est la destination du backup. Donc pas de copie locale à synchroniser, pas de config périmée, pas de conflit local/serveur : le problème de synchronisation que tous les agents se traînent disparaît par construction. C'est l'une des raisons d'être du choix stateless.

Décision 1 — Côté serveur, éditée par les deux bouts

La config vit dans la DB de contrôle (PostgreSQL), à côté des tenants et des refs de snapshots. Deux interfaces, une seule source de vérité :

le dashboard web (section H) l'édite via l'API ;
la CLI locale l'édite via la même API — cairn config set … parle au serveur, jamais à un fichier local qui divergerait.

Ce qui reste en local se réduit au bootstrap d’identité : URL du serveur, identité machine, credentials — le minimum pour frapper à la porte. Un petit fichier TOML, créé à l’enrôlement, et c’est tout.

Décision 2 — Le contenu, et surtout ce qui n’y est pas

Dedans :

Sources — les chemins à sauvegarder.
Include / exclude — sémantique gitignore (connue de tous), plus le respect de CACHEDIR.TAG, une taille max optionnelle, et le flag « ne pas traverser les frontières de systèmes de fichiers ».
Planification — horaires des runs, avec rattrapage (voir décision 5).
Réseau — throttling et plages horaires (uploads).
Politiques — fast/paranoid/force du scan, require-snapshot des fichiers ouverts, politique de collision de la restauration.

Explicitement hors config :

Les profils épinglés (chunker, compression, hashsplit) — les changer forke l'espace d'adresses : c'est une migration, pas un réglage. Ils vivent au niveau tenant, sous procédure dédiée.
Le matériel de clés — le canal config ne transporte jamais de secret. L'enrôlement des clés est le flux custody de la section F.

Décision 3 — Trois étages de politique, façon MDM

En clair — le bail et ses clauses Un bail de location a deux sortes de clauses : celles que le propriétaire impose (non négociables) et celles qu'il propose par défaut (aménageables par le locataire). La config Cairn pareil, sur trois étages : les défauts produit, la politique du revendeur, les réglages de la machine. Chaque champ posé par le revendeur est marqué locked (imposé — pense plages horaires ou rétention chez un client géré) ou default (la machine peut ajuster). C'est le modèle GPO/MDM éprouvé depuis vingt ans.

Se branche directement sur la hiérarchie de comptes (éditeur → revendeur → client, section G) et le RBAC (section I) : qui a le droit de verrouiller quoi.

Décision 4 — Les hooks sont local-only

La frontière données / code — à ne jamais franchir La config distante ne transporte que des données. Les hooks pre/post-snapshot sont des commandes : les rendre configurables depuis le dashboard transformerait celui-ci en exécution de code à distance sur toutes les machines d'un tenant — et un compte revendeur compromis en botnet clef en main. Règle : les hooks se déclarent dans le fichier local de la machine, par quelqu'un qui a déjà la main sur cette machine. Le dashboard peut voir qu'un hook est configuré (rapport), jamais le définir.

Décision 5 — La mécanique : polling, révision, accusé

Polling, pas de push — les clients sont derrière NAT : le daemon tire la config à intervalle modeste, au démarrage, et avant chaque run. (Un canal de commandes « backup maintenant » depuis le dashboard suivra la même mécanique — file de jobs pollée.)
Révision + accusé — chaque config porte un numéro de révision ; le client accuse réception. Le dashboard affiche à jour / en retard / injoignable depuis X — fini le « j'ai changé le réglage, est-ce pris en compte ? ».
Planification rattrapable (façon anacron) — le laptop éteint à 3h du matin fait son backup au réveil, au lieu de sauter la nuit. Pour un parc de portables, c'est la différence entre « planifié » et « réellement sauvegardé ».
Audit — chaque changement de config est journalisé : qui (revendeur ou client), quoi, quand. Alimente l'audit logging de la section I.

Sur le nom du dashboard — candidat dans le thème Cairn : la Table d’orientation (la vue panoramique au sommet, qui montre tout le paysage d’un coup d’œil). À trancher avec la section H.