Obsidian : le second cerveau taillé pour les développeurs
Nous avons tous le même problème : des notes éparpillées entre des fichiers texte, des signets oubliés, des bouts de documentation perdus dans Slack et des idées griffonnées quelque part qu’on ne retrouve jamais. En tant que développeur, la quantité d’informations techniques à retenir est colossale. Langages, frameworks, configurations serveur, commandes obscures qu’on utilise deux fois par an… Impossible de tout garder en tête.
C’est exactement là qu’intervient le concept de second cerveau : un système externe pour capturer, organiser et retrouver ses connaissances. Et parmi les outils disponibles, Obsidian se démarque nettement pour les profils techniques. Pas parce qu’il est à la mode, mais parce que sa philosophie colle parfaitement avec notre façon de travailler.
Sommaire
- C’est quoi Obsidian exactement
- Le second cerveau : pourquoi c’est pertinent pour un développeur
- Repenser le classement : les liens plutôt que les dossiers
- La vue graphe : visualiser ses connaissances
- Obsidian vs Notion : comparaison pragmatique
- Les plugins essentiels pour les développeurs
- Ce qui peut manquer
- Pour qui Obsidian est fait, et pour qui il ne l’est pas
C’est quoi Obsidian exactement
Obsidian est un éditeur de notes basé sur le Markdown. Jusque-là, rien de révolutionnaire. Ce qui change la donne, c’est son approche : vos notes sont de simples fichiers .md stockés en local sur votre machine, dans un dossier classique. Pas de base de données propriétaire, pas de cloud obligatoire, pas de format fermé.
Concrètement, votre vault (coffre-fort en anglais) est un répertoire sur votre disque. Vous pouvez l’ouvrir avec n’importe quel éditeur de texte, le versionner avec Git, le synchroniser comme vous voulez. Et c’est là que réside la vraie force du modèle : même si Obsidian disparaît demain, vos fichiers restent parfaitement lisibles. Tant que vous avez l’application, tout tourne en local sans aucune dépendance extérieure. Et au pire, sans l’application, vos fichiers .md sont du texte brut que vous pouvez ouvrir avec n’importe quel éditeur. Vous ne perdez jamais rien.
L’interface est sobre et rapide. On lance l’application, on écrit en Markdown, on crée des liens entre les notes avec la syntaxe [[nom de la note]], et c’est parti. Pas besoin de passer trois heures à configurer des bases de données ou des templates avant de commencer à écrire.

Le second cerveau : pourquoi c’est pertinent pour un développeur
Le concept de second cerveau, popularisé par Tiago Forte, repose sur une idée simple : externaliser sa mémoire dans un système fiable et interrogeable. Au lieu de compter sur sa mémoire pour retenir une commande Docker, une config Nginx ou les subtilités d’une requête SQL, on les capture dans un système qu’on peut fouiller instantanément.
Pour un développeur, c’est particulièrement puissant parce que notre métier consiste à jongler entre des dizaines de technologies. Personnellement je vous conseille de voir votre second cerveau comme une documentation vivante. Pas un wiki figé qu’on met à jour une fois par trimestre, mais un espace organique où chaque note peut se connecter à une autre.
Prenons un exemple concret. Vous tombez sur un problème de performance MySQL. Vous creusez, vous trouvez la solution, vous la notez dans Obsidian. Trois mois plus tard, vous travaillez sur l’optimisation d’une API et vous tombez sur cette note en cherchant autre chose. Vous créez un lien. Six mois après, vous rédigez un article sur les bonnes pratiques SQL et vous avez déjà toute une toile de notes interconnectées sur le sujet. C’est ça, un second cerveau : une base de connaissances qui grandit et se structure au fil du temps.
Repenser le classement : les liens plutôt que les dossiers
C’est un changement de paradigme qui déstabilise au début. Dans un système classique, on passe un temps fou à se demander “je range cette note où ?”. Est-ce que ma note sur l’optimisation MySQL va dans le dossier “Base de données”, “Performance” ou “Projet X” ? Avec Obsidian, cette question perd de son importance.
Le vrai classement se fait par les liens entre les notes, pas par l’arborescence de dossiers. Une note sur l’optimisation MySQL peut être liée à votre fiche projet, à votre note sur les index SQL, et à votre checklist de performance. Elle existe dans plusieurs contextes à la fois sans avoir besoin d’être dupliquée. C’est la vue graphe qui révèle ces relations, pas l’explorateur de fichiers.
Cela ne veut pas dire qu’il faut abandonner toute structure de dossiers. En pratique, une organisation de base reste utile pour s’y retrouver. Voici un exemple d’architecture de vault qui fonctionne bien :
- 01_INBOX : point d’entrée de toutes les nouvelles notes, à trier ensuite
- 02_RESSOURCES : documentation technique, références, fiches outils
- 03_PROJECT : notes liées à des projets en cours
- 04_PERMANENT : notes mûries, retravaillées, qui constituent le cœur du second cerveau
- 05_MOC : Maps of Content, des notes d’index qui regroupent des liens thématiques
- 06_ARCHIVES : projets terminés, notes obsolètes
- 07_TEMPLATE : modèles de notes réutilisables
- 08_ASSETS : images, pièces jointes, fichiers annexes
- 09_READWISE : notes importées depuis vos lectures (si vous utilisez Readwise)
Le tout chapeauté par une note 00_Index qui sert de point d’entrée vers les MOC principaux.
L’idée c’est que les dossiers servent de grandes zones de travail, mais c’est le réseau de liens et les MOC (Maps of Content) qui assurent la vraie navigation. Une note dans 04_PERMANENT peut être reliée à trois projets dans 03_PROJECT et référencée dans deux MOC différents. Le dossier devient secondaire, le lien devient primaire.
La vue graphe : visualiser ses connaissances
C’est probablement la fonctionnalité la plus impressionnante d’Obsidian et celle qui donne tout son sens au concept de second cerveau. La vue graphe affiche toutes vos notes sous forme de nœuds reliés entre eux par des traits. Chaque lien [[interne]] que vous créez dessine une connexion visible.
Maintenant que nous avons vu comment les notes se connectent individuellement, imaginez le résultat avec des centaines de notes. La vue graphe révèle des clusters thématiques : vous voyez émerger des groupes autour de vos sujets principaux. Un cluster Docker, un cluster sécurité, un cluster JavaScript… Et surtout, vous repérez les ponts entre ces clusters, ces notes qui font le lien entre deux domaines que vous n’aviez pas consciemment associés.
Pour un développeur, cette visualisation est précieuse pour plusieurs raisons :
- Elle identifie les zones de connaissance denses et les zones vides, ce qui aide à orienter sa veille technique.
- Elle met en lumière les connexions transversales entre des technologies différentes.
- Elle révèle les notes orphelines, ces fichiers isolés qu’on a créés sans jamais les relier au reste.
- Elle donne une vue d’ensemble de son expertise technique d’un seul coup d’œil.
La vue graphe supporte aussi les filtres et la coloration par dossier ou par tag, ce qui permet de se concentrer sur un sous-ensemble de notes quand le vault grossit.
Exemple concret : cartographie applicative et réseau
La vue graphe peut servir de cartographie légère pour documenter une infrastructure. Imaginons que vous créez une note par composant de votre stack : une note [[API Gateway]], une note [[Service Auth]], une note [[Service Paiement]], une note [[PostgreSQL Production]], une note [[Redis Cache]]. Dans chaque note, vous décrivez le composant et vous liez les notes entre elles selon les dépendances : l’API Gateway appelle le Service Auth, le Service Paiement tape dans PostgreSQL, le Redis Cache est utilisé par les deux services.
Le même principe fonctionne pour une cartographie réseau : une note par serveur, par VLAN ou par service. Vous notez les IP, les ports exposés, les règles firewall, et vous reliez le tout. La vue graphe vous montre alors d’un coup d’œil quel serveur communique avec quel autre et vous repérez rapidement un service isolé ou un point de convergence critique.
Il faut être honnête : pour une cartographie complète et maintenue en production, des outils dédiés comme Netbox, DrawIO ou des solutions d’ITSM feront un meilleur travail. Mais pour une documentation personnelle rapide, un mapping mental de votre infra ou la compréhension d’un nouveau SI quand vous arrivez sur un projet, Obsidian et sa vue graphe sont redoutablement efficaces. Le ratio effort/valeur est imbattable.
Obsidian vs Notion : comparaison pragmatique
Impossible de parler d’Obsidian sans évoquer Notion. Les deux outils sont souvent comparés, mais ils répondent à des philosophies radicalement différentes.
| Critère | Obsidian | Notion |
|---|---|---|
| Stockage | Local (fichiers .md) | Cloud (propriétaire) |
| Format | Markdown standard | Format propriétaire |
| Hors-ligne | Natif, toujours disponible | Limité, dépend du cache |
| Vitesse | Très rapide | Peut être lent sur gros espaces |
| Versioning Git | Natif (ce sont des fichiers) | Impossible |
| Collaboration | Possible mais limitée | Excellente |
| Courbe d'apprentissage | Modérée | Faible |
| Personnalisation | Totale (CSS, plugins JS) | Limitée aux blocs natifs |
| Propriété des données | Totale | Chez Notion |
Notion excelle pour le travail collaboratif et la gestion de projet en équipe. Il faut être honnête là-dessus. Si vous cherchez un espace partagé avec votre équipe pour gérer des sprints ou un wiki d’entreprise, Notion fait très bien le travail.
Mais pour un usage personnel de base de connaissances technique, Obsidian gagne sur quasiment tous les critères qui comptent pour un développeur : rapidité, hors-ligne, Git, Markdown pur, et surtout la certitude que vos données ne dépendent de personne. Le jour où Notion change ses tarifs, son API ou ferme boutique, vos données sont coincées. Avec Obsidian, ce problème n’existe pas.
Et la collaboration avec Obsidian ?
La collaboration est possible mais il faut être lucide : ce n’est pas le point fort d’Obsidian. Vous pouvez partager un vault via Google Drive, Dropbox ou un dépôt Git partagé. Ça fonctionne, mais ce n’est pas toujours simple. Avec un partage cloud type Drive, les conflits de fichiers peuvent arriver si deux personnes éditent la même note en même temps. Avec Git, c’est plus propre grâce à la gestion des merges, mais ça suppose que tous les collaborateurs soient à l’aise avec Git.
Pour un usage en binôme ou en petite équipe technique, le partage via Git reste la meilleure option. Pour de la vraie collaboration temps réel avec des profils non-techniques, il vaut mieux garder Notion ou un autre outil collaboratif à côté.
Les plugins essentiels pour les développeurs
La force d’Obsidian réside aussi dans son écosystème de plugins communautaires. Il en existe des centaines, mais voici ceux qui font la différence pour un profil technique.
Dataview
Dataview transforme votre vault en une base de données interrogeable. Vous écrivez des requêtes en pseudo-SQL directement dans vos notes pour afficher des tableaux dynamiques. Par exemple, lister toutes vos notes taguées #bug créées ce mois-ci, ou afficher un tableau de vos projets en cours avec leur statut. Pour quelqu’un qui pense en SQL, c’est naturel.
Git (Obsidian Git)
Ce plugin automatise les commits et pushs de votre vault vers un dépôt Git. Vous configurez un intervalle (toutes les 10 minutes par exemple), et votre vault est versionné automatiquement. Historique complet, branches, diff… Tout ce qu’on aime avec Git, appliqué à ses notes. Cela dit, le plugin n’est pas obligatoire : vous pouvez très bien gérer vos commits manuellement en ligne de commande ou via un script cron. Le plugin ajoute simplement le confort de l’automatisation dans l’interface.
Templater
Templater va plus loin que le système de templates natif, ce qui permet d’automatiser la création de notes avec des dates dynamiques etc. Idéal pour standardiser ses notes de debug, ses comptes-rendus de veille ou ses fiches projet.
Calendar et Periodic Notes
Calendar affiche un calendrier dans la barre latérale qui permet de naviguer rapidement entre vos notes quotidiennes. Couplé à Periodic Notes, vous pouvez mettre en place un système de journaling technique : une note par jour, par semaine ou par mois, générée automatiquement depuis un template. Pratique pour garder une trace de ce qu’on a fait, débugué ou appris chaque jour.
Les plugins du quotidien
Quelques plugins plus discrets mais qui améliorent le confort au quotidien : Copy Button for Code Blocks ajoute un bouton de copie sur chaque bloc de code (indispensable quand on documente des commandes), Editor Syntax Highlight améliore la coloration syntaxique dans l’éditeur, Sliding Panes permet d’afficher plusieurs notes côte à côte en panneaux glissants pour comparer ou croiser des informations, Tracker permet de suivre des données au fil du temps (habitudes, métriques, objectifs), et Advanced Tables rend l’écriture de tableaux Markdown supportable avec la navigation par tabulation et le formatage automatique.
Si vous utilisez Readwise pour centraliser vos highlights de lecture, le plugin Readwise Official synchronise automatiquement vos annotations dans votre vault, prêtes à être liées au reste de vos notes.
Ce qui peut manquer
Obsidian n’est pas parfait et il y a des points qui peuvent manquer selon votre usage. La recherche et remplacement globale sur l’ensemble du vault est basique comparée à ce que propose un IDE. Le support mobile fonctionne mais reste moins fluide que sur desktop, surtout avec un vault volumineux. Il n’y a pas de tableaux de bord natifs comme dans Notion : il faut passer par Dataview pour obtenir quelque chose d’approchant, ce qui demande un temps d’apprentissage.
Le partage de notes vers l’extérieur n’est pas simple non plus. Si vous voulez publier une note en ligne, il faut soit payer pour Obsidian Publish, soit mettre en place un pipeline d’export (vers Jekyll, Hugo ou autre). Pas insurmontable, mais c’est du travail en plus.
Enfin, la gestion des pièces jointes et images peut vite devenir désordonnée si on ne configure pas un dossier dédié dès le départ (comme le dossier 08_ASSETS mentionné plus haut). Par défaut, Obsidian colle les images à la racine du vault, ce qui devient vite le bazar.
Pour qui Obsidian est fait, et pour qui il ne l’est pas
Il faut éviter de tomber dans le piège du “c’est l’outil parfait pour tout le monde”. Obsidian a ses limites et il vaut mieux les connaître avant de migrer toutes ses notes.
Obsidian est fait pour vous si :
- Vous êtes à l’aise avec le Markdown.
- Vous voulez garder le contrôle total sur vos données.
- Vous cherchez un espace de notes personnel, pas un outil collaboratif.
- Vous aimez personnaliser vos outils (CSS, plugins, raccourcis).
- Vous avez besoin de travailler hors-ligne régulièrement.
Obsidian n’est probablement pas pour vous si :
- Vous avez besoin de collaboration en temps réel avec une équipe.
- Vous ne voulez pas toucher au Markdown.
- Vous cherchez un outil clé en main sans configuration.
- Vous avez besoin de bases de données relationnelles complexes (Notion fait mieux ici).
Personnellement, après plus de trois ans d’utilisation, le plus gros avantage reste la pérennité. Mes notes d’il y a plusieurs années sont toujours là, toujours lisibles, toujours connectées. Aucun changement de tarif, aucune migration forcée, aucune fonctionnalité supprimée du jour au lendemain. Pour un second cerveau, la durabilité est un critère fondamental.
Obsidian ne va pas transformer votre façon de travailler du jour au lendemain. Il faut accepter de construire son vault progressivement, note après note, lien après lien. Mais une fois que la masse critique est atteinte et que la vue graphe commence à dessiner les contours de votre expertise, l’outil devient indispensable. Le meilleur moment pour commencer, c’est maintenant. Créez un vault, prenez votre première note technique, et laissez votre second cerveau grandir avec vous.
comments powered by Disqus