Dans l’article précédent, Anatomie d’un désordre, j’ai décrit mon chemin un peu chaotique pour commencer à structurer les éléments de connaissances accumulés au cours du temps. Cette initiative partait d’un besoin de centralisation : bouquins crayonnés, feuilles volantes, fiches bristol entre deux pages… et du constat partagé avec Cal Newport, mon thérapeute zéro, que la fragmentation de l’attention était une plaie.

J’ai donc commencé par un système de fichiers assez simples en Markdown, parce que je trouvais la syntaxe simple, versionné avec Git. J’y mettais mes notes de lectures un peu brutes, et un peu tout ce qui me passait par la tête.

Cette approche répondait à mon cahier des charges :

• Un système de fichiers ouverts ;
• En local sur mon ordinateur ;
• Utilisant la syntaxe Markdown ;
• Versionné avec Git ;
• Multi-supports.

Ma découverte d’Obsidian date de 2022. Je lisais alors pas mal de bouquins sur le Product management et Kubernetes, il fallait que je puisse centraliser ces notions pour rationaliser un peu mon parcours d’apprentissage. Cet outil, propriétaire mais ouvrant certaines interfaces à l’extérieur, mobilisait une communauté foisonnante de développeurs et de passionnés qui proposaient d’enrichir les fonctionnalités de base par des plugins, évidemment gratuits, qui pouvaient faire à peu près tout et n’importe quoi. Adieu Notion, adieu Trello.

Dans une série de trois billets, nous reprendrons nos trois profils :

• L’architecte, dont nous parlions précédemment, a une logique top-down, il conçoit d’abord ce dont il a besoin, une architecture, puis la remplit ensuite. C’est ce qui m’a toujours posé problème avec Notion : des pages dans des pages et une arborescence dans laquelle je finis par me perdre ;
• Le jardinier procède par émergence, il connecte des éléments entre eux et laisse place à la sérendipité. Le risque, sans structure sous-jacente est de partir dans tous les sens et d’obtenir à l’issue une big ball of mud, un gros plat de spaghettis sans aucune cohérence. C’est comme ça que je fonctionne.
• Le libraire, lui, collecte et construit un catalogue qui lui permette de retrouver facilement ses idées. Il tague, soigne les métadonnées, archive et classe. Le libraire peut retrouver ses idées facilement, mais un catalogue manque des liens transverses qui faciltent le processus créatif. C’est compensatoire.

Ce sont des catégories, les trois manières de faire sont à la fois justes et limitées : elles répondent à des besoins différents et à des moments différents du cycle de vie d’une note. J’ai mis un peu de temps à comprendre que j’avais besoin des trois : de l’architecte pour la gouvernance, du jardinier pour les liens et du libraire pour les données structurées. Obsidian est suffisamment ouvert pour tenir les trois ensemble et leur permettre de se déployer librement. Voyons comment quelques itérations ont permis de le mettre en pratique.

Partir de ce que je connais : un dépôt de code

L’apprentissage du code m’ayant apporté une autre structure intellectuelle que ce que mes études de philo avaient pu faire, ma première arborescence a donc ressemblé assez naturellement à un dépôt de code :

notes/
├── bin/             # Scripts bash de gestion du repo
├── src/             # Base de connaissance
│   ├── dev/         # Sources d'entrée principales (documents bruts, extracts Kindle)
│   ├── etc/         # Documentation de fonctionnement et templates
│   ├── home/        # Projets personnels
│   ├── media/       # Images intégrées aux notes
│   ├── notes/       # Les notes se mettent ici
│	└── .obsidian/   # Config Obsidian
├── .gitignore		 # Contient les fichiers que je ne veux pas commiter. 
├── Makefile         # Commandes de pilotage utiles
└── .prettierrc/     # Configuration du formatter Markdown lancé en pré-commit hook

L’environnement était assez familier : un. Makefile pour les commandes courantes, des fichiers de configuration, des pre-commit hooks qui lancent des scripts de formatage ou de nettoyage à chaque commit, les scripts de gestion (conversion vers docx ou pdf) dans bin et le vault Obsidian dans src avec sa config et ses plugins propres.

Les dossiers Obsidian étaient eux-mêmes structurés par type de documents. Un plugin me permettait de récupérer en un tournemain tout ce que j’avais surligné dans ma liseuse, des milliers de citations que je pensais perdues ou inutiles. J’y ajoutais des articles, des notes de lecture brutes (qui passaient de mes fiches Bristol à ce dossier).

De PARA vers IRPERDAPS

Après la lecture du bouquin de Tiago Forte ¹, très intéressante parce qu’elle fonctionne par intentions opérationnelles plutôt que par catégories statiques, j’ai un peu revu ma copie. Forte définit ces quatre catégories aussi utiles pour trier des papiers que des fichiers numériques :

| Dossiers PARA         | Intention                                                            |
| :-------------------- | :------------------------------------------------------------------- |
| `Projets`             | Un début et une fin : actions à court terme, livrables avec échéance |
| `Areas / Engagements` | Rôles et responsabilités sans durée définie, ex : professionnel      |
| `Ressources`          | Sujets d'intérêt continu, non actionnables, utiles plus tard         |
| `Archives`            | Éléments inactifs des trois catégories                               |

PARA trie par utilité et pas par thématique. Une présentation sur le DevOps ne sera pas mise dans un sous-dossier quelconque, mais directement rattachée à un projet en cours là où elle servira à quelque chose. Inutilisée, elle terminera naturellement sa course dans les Archives. Si j’en ai besoin, un petit Cmd + O m’y renverra en quelques mots-clés et trois secondes où qu’elle soit dans la base de connaissance.

Les catégories sont de plus haut niveau par rapport à l’itération précédente, plus facilement compréhensibles sans doute par d’autres, même si cette base n’a pas vocation à être partagée.

Au fur et à mesure, j’ai rajouté de nouvelles catégories à mon système pour avoir finalement une arborescence comme ceci, qui est l’arborescence par défaut maintenant de tous mes systèmes d’information :

notes
├── docs                    # Documentation générale du dépôt, c'est ce qui est versionné avec Git
├── scripts                 # Les différents scripts de gestion du vault en Bash ou Python
├── vault
│   ├── .obsidian/          # Config Obsidian
│   ├── 00-Inbox            # Une zone de capture brute et de transit de l'information à 15 jours max
│   ├── 10-Projets          # Voir le tableau PARA ci-dessus
│   ├── 20-Engagements      # Plutôt qu'Areas, qui est trop générique, selon moi, et prête à confusion
│   ├── 30-Ressources       # Voir supra
│   ├── 40-Daily            # Notes du jour / tâches quotidiennes et suivi, parfois redondant avec le bullet journal
│   ├── 90-Archives         # Voir supra
│   ├── 98-Private          # Données sensibles chiffrées avec le plugin git-crypt
│	├── 99-System           # Infrastructure technique, documentation,
│	|	├── medias          # Images intégrées aux notes
│	│	├── schemas         # Structure des frontmatter par catégorie avec typage
│	│	├── templates       # Templates divers et variés
│	│── AGENTS.md           # Coucou l'IA !

Les dossiers sont à présent numérotés pour conserver un ordre quel que soit le changement de titre. Toutes les notes par défaut arrivent dans 00-Inbox et y restent jusqu’à ce qu’elles aient atteint un certain niveau de maturité. Ensuite, elles vont soit dans 10-Projets, 20-Engagements ou 30-Ressources. J’ai utilisé pendant un temps 40-Daily, qui m’a servi un moment de pense-bête, mais mon bullet journal papier est plus utile pour moi, cette section est tombée en deshérence et je n’ai pas encore décidé de ce que j’allais en faire. La supprimer ou l’archiver, sûrement.

Forte a appelé son système “PARA”, le mien répond au nom barbare d’IPERDAPS (Inbox, Projets, Engagements, Ressources, Daily, Archives, Private, System). Mes 50 centimes à la commu 2nd Brain.

Gouvernance : contenir l’entropie

Aujourd’hui, le dossier 30-Ressources contient plus de 1000 notes, l’ensemble du vault, plus de 2000. Le syndrome de Diogène, la passion cumularde, la névrose de la collection guettent.

Pour éviter que ce “data lake” ne se transforme en “data swamp” (marécage), il faut poser des règles strictes. Le problème est entre le clavier et la chaise, d’abord, c’est à dire dans une certaine hygiène personnelle de traitement de la donnée qui repose sur un pipeline : les nouvelles notes entrent dans 00-Inbox et ne doivent pas y rester trop longtemps, ensuite elles tombent dans 10-Projets ou 30-Ressources. Celles qu’il faut supprimer partent dans 90-Archives ou dans la poubelle.

Le premier facteur de désordre est d’avoir un dossier 00-Inbox jamais rangé. Grâce à des outils de Libraire, notamment le plugin Dataview qui permet de traiter les notes comme une base de données, j’ai mis une durée limite dans l’Inbox que j’estime raisonnable à 15 jours. Au délà, elles tombent dans la section “Notes stagnantes” de mon dashboard system/001 - Maintenance ²

Le second facteur, ce sont les liens morts, c’est à dire les liens sémantiques créés dans le corps des notes qui ne renvoient à aucun fichier physique. Ils peuvent indiquer plusieurs choses : une erreur de saisie, une note à créer ou une MoC (cf. notre prochain article sur le jardinier) à créer³.

Le troisième facteur concerne les notes orphelines, soit les notes qui ne sont reliées à rien, soit parce qu’elle explorent une nouvelle thématique, soit parce que les liens n’ont pas été saisis. Un LLM peut être assez performant pour lui donner des bons liens si la note est à la fois complète, sémantiquement claire, et bien structurée⁴

Une bonne “mémoire” demande une bonne architecture et une infrastructure souple. Ce qui marche pour moi, ce sont :

• Des règles strictes sur la forme, qui correspondent à chacun, cohérente sur le plan sémantique ;
• Des règles de gestion qui accompagnent la donnée au long de son cycle de vie, de la collecte à l’archivage ou la suppression ;
• Une dynamique de tri : ce qui définit la mémoire, c’est ce qu’elle oublie et, surtout, ce qu’elle choisit de garder.

La tentation de l’architecte, c’est de concevoir une superstructure et d’y consacrer tout son temps jusqu’à créer une coquille parfaite, mais vide. Ou lorsqu’elle est pleine, qu’elle soit inopérante parce qu’inadaptée, trop lourde, ou débordée de toute part par le réel, l’à peu près. Que la maintenance de cette structure devienne tellement lourde, marteau pour tuer une mouche ou usine à gaz, qu’elle finit par tuer son objet. L’architecte qui conçoit une maison fait un jour face à une réalité physique : l’édifice tient debout ou non ; celui qui joue avec des abstractions n’a rien de tangible pour le guider !

---

Références

• Cal Newport, Deep Work, qui remet l’attention au centre en en déplorant la fragmentation,
• Tiago Forte, The PARA Method, qui propose un système très opérationnel de structuraton d’un système d’information,
• Sonke Ahrens, How to Take Smart Notes, qui vulgarise la méthode “Zettelkasten” et son funnel de prise de notes,
• Eliott Meunier, qui avec Arrêtez d’oublier ce que vous lisez est la meilleure porte d’entrée francophone sur ce sujet.

---

TABLE default(date, default(created, file.ctime)) as "Date de capture"
FROM "00-Inbox"
WHERE default(date, default(created, file.ctime)) < date(today) - dur(15 days)
SORT default(date, default(created, file.ctime)) ASC

TABLE length(rows) AS "Citations"
FROM ""
FLATTEN file.outlinks AS out
WHERE !out.file AND !contains(meta(out).path, "/")
GROUP BY out
SORT length(rows) DESC
LIMIT 20

TABLE file.folder as "Dossier"
FROM "30-Ressources"
WHERE length(file.inlinks) = 0
AND file.name != this.file.name

Footnotes

1. Tiago Forte, The PARA Method: Simplify, Organize, and Master Your Digital Life ↩

2. Requête Dataview pour les notes stagnantes ↩

3. Requête Dataview pour les liens fantômes ↩

4. Requête Dataview pour les notes orphelines ↩