Tous les logiciels que j’ai utilisés dans ma vingtaine ont disparu.
Pas seulement les entreprises — ça, c’est banal. Les formats aussi. Les bibliothèques, les catalogues, les projets. Il me reste des dossiers que je ne peux plus ouvrir, et je sais exactement ce qu’il y a dedans parce que je m’en souviens, pas parce que je peux les lire.
L’idée qui a réorganisé ma façon de construire tient en trois mots, empruntés à Steph Ango : file over app. Le fichier plutôt que l’application.
Ce n’est pas une préférence technique. C’est une position sur la durée.
Ce qu’Obsidian m’a fait comprendre
Obsidian n’est pas magique. C’est un éditeur qui ouvre un dossier de fichiers markdown. Il n’y a pas de base de données, pas de format propriétaire, pas de compte. Mes notes sont des .txt avec une extension différente.
La première fois, j’ai trouvé ça pauvre. J’avais utilisé des outils plus impressionnants.
Puis j’ai réalisé ce que ça impliquait : si je supprime Obsidian, je perds une interface, pas mon travail. Mes notes s’ouvrent dans TextEdit. Elles se cherchent avec grep. Elles se versionnent avec git. Elles se lisent dans quinze ans par n’importe quel outil qui sait afficher du texte.
L’application est devenue une lentille. Le fichier est la chose.
Une fois qu’on a vu ça, on ne peut plus revenir en arrière — et on commence à regarder tous ses autres outils avec suspicion.
Ce que ça a permis sans que je le prévoie
Le vault a cessé d’être un endroit où j’écris pour devenir le substrat de tout le reste.
Mes projets s’y gèrent : une note par projet, un axe status, un axe maturity, et un tableau qui se génère tout seul à partir de ça. Pas d’outil de gestion de projet — des fichiers avec des propriétés.
Mon système de design y vit aussi, et c’est là que ça devient étrange. Dans mes notes, une clé de frontmatter est le nom d’une variable CSS. Écrire font-header: Inter Variable dans l’entête d’une note change son rendu. La typographie devient une donnée du fichier, pas une configuration de l’application.
Et le dépôt de code lui-même s’ouvre comme un vault. Obsidian n’affiche que les .md, donc on navigue la documentation et jamais le bruit du code. Chaque projet a son README, la racine les agrège, et une case à cocher écrite dans n’importe lequel remonte dans le tableau de bord.
Aucune de ces choses n’était planifiée. Elles sont devenues possibles parce que la matière de base était ouverte.
Le jardin : publier sans posséder
Vient ensuite le problème évident. Je voulais publier. Publier veut dire un serveur, une base de données, un service — exactement ce que je venais de fuir.
C’est la tension que Standard Garden devait résoudre, et la réponse tient dans une phrase du README du vault :
Le Standard l’organise ; le Garden le publie. Ni l’un ni l’autre ne le possède.
Concrètement : mes notes vivent sur mon Mac. Le jardin en reçoit des copies quand je publie. Si le service ferme demain matin, je ne perds rien — je perds une vitrine, pas une archive. Le sens de la flèche est ce qui compte : le vault écrit vers le jardin, jamais l’inverse comme unique source.
C’est un service hébergé, avec des comptes, des domaines personnalisés, un abonnement. Un logiciel comme service, avec toute l’ironie que ça suppose après ce que je viens d’écrire.
La différence n’est pas dans l’architecture technique. Elle est dans ce qui arrive quand il disparaît. Un service qui héberge votre seule copie vous tient. Un service qui publie une copie de ce que vous possédez déjà ne vous tient pas. Le code est le même ; le rapport de force est inversé.
Les photos, là où c’était le plus difficile
Le texte est facile : c’est déjà un format ouvert. Les photos, non.
Un RAW est binaire. Il n’y a pas d’équivalent markdown. Et surtout, l’essentiel du travail d’un photographe n’est pas dans le fichier — il est dans ce qu’on a dit à propos du fichier : le tri, les notes, les mots-clés, les retouches, les sélections. Quinze ans de ce travail vivaient dans un catalogue binaire que je ne peux ni lire ni réparer.
Reveal applique la même règle avec les moyens disponibles.
Les originaux ne sont jamais modifiés. Les métadonnées vivent dans des sidecars .xmp — un fichier texte à côté de chaque photo, au format standard, lisible par Lightroom, darktable, immich et par n’importe quel outil dans quinze ans. Et l’index de l’application est jetable : je peux le supprimer, il se reconstruit à partir des dossiers, et rien n’est perdu.
La règle est écrite dans le README avant la première ligne de code : le dossier sur le disque est la vérité, pas l’état interne de l’application.
C’est le cas le plus dur, et c’est celui qui prouve le principe. Si ça tient pour des photos, ça tient partout.
Ce que ça coûte
Il faut être honnête, sinon ce n’est qu’un slogan.
C’est plus lent. Une base de données répond en microsecondes à des questions qu’un dossier de fichiers exige de parcourir. J’ai dû construire des index — et ensuite construire la discipline de les traiter comme jetables.
Il n’y a pas de transactions. Écrire trois fichiers qui doivent changer ensemble n’est pas atomique. Un plantage au mauvais moment laisse un état incohérent, et c’est à moi de le rattraper.
La synchronisation devient mon problème. Pas de résolution de conflits offerte, pas de collaboration en temps réel. Un fichier modifié à deux endroits est un fichier que je dois réconcilier.
Et la recherche est moins bonne. Beaucoup moins bonne qu’un moteur qui indexe des colonnes typées.
Ce sont de vrais coûts. Je les paie chaque semaine, en connaissance de cause.
Pourquoi je les paie quand même
Parce que le calcul n’est pas celui qu’on croit.
La question n’est pas quel outil est le meilleur aujourd’hui. C’est que reste-t-il quand cet outil n’existe plus. Sur cinq ans, la différence est négligeable. Sur quinze, c’est la seule chose qui compte — et j’ai maintenant assez d’années derrière moi pour avoir vu la deuxième échéance arriver.
Il y a aussi une conséquence que je n’attendais pas, et qui est peut-être la vraie raison.
Quand la donnée est ouverte, les outils deviennent bon marché à écrire. Un plugin Obsidian, un moteur de publication, une application photo : ils n’ont pas eu à définir un format, à migrer un schéma, à négocier avec un existant. Ils lisent des fichiers et écrivent des fichiers. Trois systèmes qui n’ont rien en commun se parlent parce qu’ils partagent le sol.
Le fichier n’est pas seulement ce qui survit à l’application. C’est ce qui permet d’en écrire d’autres.
Tout est visible : Standard, Reveal, et Standard Garden. L’expression « file over app » vient de Steph Ango — son essai est ici.
Francis Fontaine est photographe et développeur à Québec. Il construit des systèmes modulaires pour le web (stnd.build) et pour le monde physique, et pense que la meilleure technologie est celle qui disparaît dans le quotidien.