Chapitre 11
Exploitation : au quotidien, sur machine neuve, et les pièges
Objectifs du chapitre
- Connaître la boucle quotidienne — et constater qu'elle ne demande presque rien.
- Amorcer le vault sur une machine neuve, et savoir ce que cette vérification prouve.
- Mettre à jour un plugin, promouvoir un réglage, ajouter un type de note.
- Traiter la confidentialité d'un dépôt dont l'historique est permanent.
- Reconnaître les aspérités réelles de la plateforme Windows plus WSL.
1. La boucle quotidienne
- Ouvrir Obsidian. Obsidian Git tire les modifications distantes.
- Écrire : note du jour par Daily Notes, captures par
Ctrl+Maj+I, fiches par template. - Obsidian Git commite et pousse toutes les dix minutes. Rien à lancer.
C'est tout. L'outillage de la partie II ne sert pas au quotidien — et c'est le signe qu'il est bien conçu. Une infrastructure qu'on doit invoquer tous les jours est une infrastructure qui n'a pas fini son travail.
Ponctuellement, deux vérifications de quelques secondes :
$ uv run --project 90-meta/tooling 90-meta/tooling/vault.py doctor
0 probleme(s)
$ uv run --project 90-meta/tooling 90-meta/tooling/bootstrap.py doctor
0 ecart(s)Le premier après une session d'écriture nourrie, le second après avoir touché aux réglages d'Obsidian.
2. La machine neuve
$ git clone git@github.com:moi/vault.git && cd vault
$ uv run --project 90-meta/tooling 90-meta/tooling/bootstrap.py apply
40 fichiers ecrits dans .obsidian/Puis ouvrir le dossier comme vault dans Obsidian. Neuf plugins à leur version épinglée et vérifiée, réglages en place, raccourci actif.
Cette séquence est aussi le test d'acceptation de tout l'édifice, et il vaut la peine de le rejouer de temps en temps depuis un clone jetable :
$ cd /tmp && rm -rf verif && git clone ~/vault verif && cd verif
$ uv run --project 90-meta/tooling 90-meta/tooling/bootstrap.py apply
$ uv run --project 90-meta/tooling 90-meta/tooling/bootstrap.py doctor
0 ecart(s)
$ uv run --project 90-meta/tooling 90-meta/tooling/vault.py doctor
0 probleme(s)
$ uv run --project 90-meta/tooling pytest -q
148 passedCe que ça prouve : rien d'essentiel ne vit hors du dépôt. Une configuration oubliée sur ta machine se révèle ici, et nulle part ailleurs.
Prérequis réels : git, uv, un accès réseau à GitHub. Le troisième est le plus
fragile — derrière un proxy d'entreprise, apply échoue. Un mode hors ligne à
partir d'un cache de plugins était prévu au départ ; il n'a jamais été construit. C'est la
limite connue la plus sérieuse du dispositif.
3. Les opérations courantes
Mettre à jour un plugin
$ # dans 90-meta/manifest.yaml, supprimer version ET sha256 du plugin
$ uv run --project 90-meta/tooling 90-meta/tooling/bootstrap.py pin
dataview epingle en 0.5.71
$ uv run --project 90-meta/tooling 90-meta/tooling/bootstrap.py apply
$ git add 90-meta/manifest.yaml && git commit -m "chore: dataview 0.5.71"Supprimer les deux champs : pin saute toute entrée qui a déjà une
version et des empreintes. Changer le numéro sans effacer les empreintes produit un échec de
vérification à l'apply suivant — message clair, mais après coup.
Promouvoir un réglage fait à la souris
$ # après avoir réglé quelque chose dans Obsidian, Obsidian fermé
$ uv run --project 90-meta/tooling 90-meta/tooling/bootstrap.py doctor
plugins/dataview/data.json : different — ...
1 ecart(s)
$ uv run --project 90-meta/tooling 90-meta/tooling/bootstrap.py exportReporter le bloc concerné dans le manifeste, relancer doctor, commiter. Le
cycle complet prend une minute et laisse une trace datée de la décision.
Ajouter un plugin
Ajouter - id: … et repo: … au manifeste, lancer pin
puis apply. Si tu veux piloter ses réglages, configure-le dans Obsidian puis
export — c'est aussi le seul moyen d'obtenir la structure exacte de son
data.json, que sa documentation ne décrit généralement pas.
4. Confidentialité
Un vault professionnel poussé sur un dépôt distant pose une question qu'il vaut mieux trancher au début qu'après.
Trois faits qui ne dépendent d'aucun outillage :
- L'historique git est permanent. Supprimer une donnée déjà poussée exige
de réécrire l'historique (
git filter-repo), de forcer la mise à jour du distant, et de considérer la donnée comme divulguée si quelqu'un a pu cloner entre-temps. Effacer le fichier au commit suivant ne suffit pas :git log -pl'affiche toujours. - Le dépôt doit être privé dès sa création, et ne jamais devenir public. Un dépôt rendu privé après coup ne rattrape pas les clones déjà faits.
- Une architecture décrite en détail reste identifiable sans nom propre. Retirer les noms de clients ne suffit pas si le reste permet de reconnaître l'installation.
Le vault de référence a choisi l'anonymisation manuelle : pas de nom de client, pas de code affaire, pas d'adresse IP d'installation, pas d'extrait de code livrable. Un contrôle automatique — une liste de motifs interdits vérifiée avant chaque commit — avait été conçu puis écarté, pour une raison instructive.
Un tel contrôle ne peut pas être bloquant tant qu'Obsidian Git commite tout seul : le plugin n'exécute pas les hooks git (chapitre 7). Le rendre bloquant obligerait à désactiver l'auto-commit et à passer tous les commits par un script.
Le choix a donc été : garder le confort, assumer la discipline manuelle, et l'écrire dans les conventions plutôt que de laisser croire à une garantie inexistante. Ce qui compte n'est pas le choix retenu, c'est qu'il soit explicite.
5. Les pièges de plateforme
Ceux qui suivent viennent tous d'un usage réel sur Windows plus WSL2, avec le vault sur un disque NTFS.
Deux git pour un même dépôt
Un dépôt sur /mnt/c/… est accessible depuis le git Linux de WSL et depuis le
git Windows. Utiliser les deux, ou utiliser le git Linux pour une activité intense, a déjà
produit des .git corrompus — références et objets remplis de zéros.
La règle retenue : toujours le binaire Windows, y compris appelé depuis WSL, et pousser après chaque commit pour que le distant serve de filet.
$ alias git=/mnt/c/Users/moi/AppData/Local/Programs/Git/cmd/git.exeObsidian Git n'est pas concerné : il écrit depuis Windows avec sa propre implémentation, jamais à travers la couche WSL.
Les handles qui traînent
Fermer Obsidian ne libère pas instantanément .obsidian/. Un apply
lancé dans la foulée échoue sur le renommage, alors qu'aucun processus Obsidian n'apparaît
dans la liste des tâches. Trente secondes plus tard, la même commande passe.
Rien de grave grâce à la restauration du chapitre 9 — mais il faut le savoir pour ne pas conclure à une panne. Une reprise automatique sur le renommage réglerait la question ; elle n'a pas été écrite, faute de pouvoir reproduire l'échec à la demande.
Les fins de ligne
Obsidian écrit côté Windows, les scripts côté WSL. Sans précaution, chaque aller-retour
produit un diff de fins de ligne sur des fichiers dont le contenu n'a pas bougé. Un
.gitattributes avec * text=auto eol=lf, écrit par apply,
ferme le sujet.
Le service de synchronisation
Répété du chapitre 1 parce que c'est le piège le plus coûteux : aucun service de synchronisation ne doit surveiller le dossier du vault. Le vault de référence a été déplacé hors de OneDrive avant même la première ligne de code.
6. Ce que le dispositif ne fait pas
Un inventaire honnête vaut mieux qu'une promesse creuse.
| Limite | Conséquence |
|---|---|
| Pas de mode hors ligne | apply exige GitHub joignable. Derrière
un proxy, l'amorçage échoue. |
| Pas de contrôle de contenu bloquant | L'anonymisation repose sur la discipline. |
| Réglages non gérés | Kanban et Advanced Tables repartent de leurs défauts sur une machine neuve. |
| Un raccourci par commande | Le manifeste ne sait pas exprimer plusieurs
liaisons ; export le signale. |
| Aucune gestion de conflit | Deux machines désynchronisées produisent un conflit git ordinaire, à résoudre à la main. |
Aucune de ces limites n'est un oubli : chacune est un arbitrage, et chacune est écrite quelque part dans le vault. C'est peut-être le vrai enseignement du cours — la différence entre un système fiable et un système fragile tient moins à ce qu'il garantit qu'à la clarté avec laquelle il dit ce qu'il ne garantit pas.
Récapitulatif
- Au quotidien, l'outillage ne sert pas : Obsidian Git suffit. C'est le signe qu'il est à sa place.
- Machine neuve : cloner,
apply, ouvrir. La même séquence sur un clone jetable est le test d'acceptation de l'ensemble. - Mettre à jour un plugin : effacer
versionetsha256, puispin. - L'historique git est permanent : le dépôt est privé dès sa création, ou il ne l'est jamais vraiment.
- Un seul git sur un dépôt NTFS, et laisse retomber les handles avant de reconstruire.
- Les limites connues valent mieux écrites que supposées résolues.
Exercices
Exercice 1 — Le collègue et le proxy
Un collègue clone ton vault sur un poste d'entreprise où GitHub est bloqué.
apply échoue au premier plugin. Que peux-tu lui proposer aujourd'hui, et que
faudrait-il construire ?
Voir la solution
Aujourd'hui, trois contournements, du moins au plus lourd :
- Lui transmettre un
.obsidian/plugins/déjà construit depuis ta machine. Ça marche, et ça contourne complètement la vérification par empreinte — donc à réserver à quelqu'un à qui il fait confiance, ce qui est le cas ici. - Retirer temporairement les plugins du manifeste et travailler avec les seuls plugins cœur. Le vault reste utilisable : les notes sont du markdown, seules les vues Dataview s'affichent en code source.
- Faire ouvrir GitHub par l'informatique, ce qui est la vraie réponse mais pas la plus rapide.
Ce qu'il faudrait construire : l'option --from-cache <dir>
prévue par la spécification initiale. apply chercherait les actifs dans un
dossier local avant d'aller sur le réseau, en vérifiant les mêmes empreintes.
C'est le point qui distingue cette option du premier contournement : le cache est une source
d'octets, pas une dispense de contrôle. Un cache constitué sur une machine connectée devient
alors transportable sur clé USB.
Exercice 2 — Une fuite déjà poussée
Tu réalises qu'un commit d'il y a trois semaines contient une adresse IP d'installation et un nom de client, dans une note depuis modifiée. Le dépôt est privé, personne d'autre n'y a accès. Quelles options, et laquelle retiens-tu ?
Voir la solution
Option 1 — ne rien faire. Le dépôt est privé, l'accès est limité à toi. Le risque résiduel est celui d'une compromission du compte ou d'un changement de visibilité par erreur. Acceptable pour une IP privée, discutable pour un nom de client sous accord de confidentialité.
Option 2 — réécrire l'historique. git filter-repo pour
supprimer la chaîne des trois semaines de commits, puis push --force.
Faisable ici : dépôt privé, aucun autre clone, historique linéaire. C'est le moment le moins
cher pour le faire — dans un an, avec des centaines de commits et peut-être un second
clone, ce sera une opération à risque.
Option 3 — repartir d'un dépôt neuf, en n'important que l'arbre courant. Radical, on perd l'historique, mais imparable et sans manipulation délicate.
Ce qu'on retient : l'option 2, parce que le coût de la réécriture croît avec le temps et que la donnée est réellement sensible. Et surtout, on note la leçon — vérifier ce qu'on écrit avant le commit, puisque après, la seule option propre est chirurgicale.
Détail à ne pas oublier : après réécriture, le contenu reste accessible via les objets
non référencés et le reflog local pendant un temps, et le distant peut garder
des objets orphelins. Sur GitHub, un commit atteignable par son empreinte reste servi un
moment même sans référence — d'où l'intérêt de contacter le support pour un cas
sérieux.
Exercice 3 — Juger l'édifice
Avec le recul des onze chapitres : quelle partie de ce dispositif recommanderais-tu à quelqu'un qui débute avec Obsidian, et quelle partie lui déconseillerais-tu ?
Voir la solution
Il n'y a pas de réponse unique, mais une ligne de partage défendable.
À recommander tout de suite : l'arborescence plate, le front-matter normé, les templates, la capture, et git pour la synchronisation. Ces cinq choses coûtent une heure à mettre en place et changent l'usage dès la première semaine. Rien n'y est irréversible.
À déconseiller au début : le manifeste et son outillage. Ils résolvent un problème qu'on ne rencontre qu'après — quand on change de machine, quand on a assez de plugins pour ne plus se souvenir de leurs réglages, quand une reconstruction devient coûteuse. Construire cette infrastructure avant d'avoir le problème, c'est de la sophistication prématurée : on maintient un outil pour un besoin hypothétique.
Le signal qui indique le bon moment : le jour où tu hésites à toucher un réglage parce que tu crains de ne pas savoir le refaire. Ce jour-là, le manifeste devient rentable — pas avant.
Formulé autrement, et c'est peut-être ce qu'il faut retenir du cours entier : la partie I rend un vault agréable, la partie II le rend durable. Les deux n'ont pas la même urgence.