D’un Obsidian Vault à un document de travail DeMinds

Un Obsidian Vault est rarement un seul fichier Markdown. Il s’agit le plus souvent d’un espace de travail structuré, composé de dossiers, d’une note d’accueil, de Wiki Links, de pièces jointes et d’habitudes d’écriture. Lorsque DeMinds ouvre ce type de contenu, il ne cherche pas à prendre le contrôle de tout le Vault ni à devenir un autre Obsidian.

Plus précisément, DeMinds fait ceci : il transforme le contenu du Vault explicitement sélectionné par l’utilisateur en un document de travail Markdown lisible, modifiable, prévisualisable et exportable.

1. Détecter d’abord l’entrée, au lieu d’ouvrir README à l’aveugle

Un Markdown Package classique utilise souvent README.md, index.md ou un fichier Markdown portant le nom du package comme point d’entrée. Un Obsidian Vault possède souvent une note d’accueil dédiée, comme Home/Home.md, et cette note peut être référencée par .obsidian/app.json ou par le réglage d’un plugin Homepage.

DeMinds donne la priorité à ces signaux d’accueil propres à Obsidian. Ainsi, lorsqu’un utilisateur ouvre un Vault, l’entrée recommandée se rapproche du chemin de lecture prévu dans le Vault, au lieu d’être dominée par hasard par un README.md situé à la racine.

L’objectif n’est pas d’importer automatiquement tout le Vault. L’objectif est d’aider l’utilisateur à commencer au bon endroit.

2. Laisser l’utilisateur choisir explicitement ce qu’il veut ouvrir

Chaque fichier Markdown d’un Obsidian Vault peut avoir un rôle différent : note d’accueil, note d’index, brouillon, modèle, page d’archive ou note quotidienne. DeMinds ne suit pas récursivement tous les Wiki Links et ne concatène pas automatiquement tout le Vault en un long document.

L’utilisateur choisit un ou plusieurs documents Markdown dans Document Chooser :

• Une sélection unique ouvre ce document comme document de travail
• Plusieurs sélections génèrent un nouveau baseline selon l’ordre choisi ou selon la structure du Vault
• L’annulation ne crée aucun espace de travail et n’écrit aucun snapshot

Cette conception maintient une frontière claire : DeMinds peut lire un Vault, mais il n’indexe pas tout le Vault ; il crée un document de travail, mais il ne réécrit pas le dossier Obsidian d’origine sur place.

3. Préserver la structure du Vault au lieu d’aplatir toutes les notes

Lorsque l’utilisateur sélectionne plusieurs documents, DeMinds peut générer le document de travail selon la structure du Vault. Par exemple, Areas/Research/Methods/Literature Review.md ne devrait pas devenir un simple élément dans une liste plate. Sa position dans le Vault porte du sens.

C’est important pour la lecture. Dans de nombreux Obsidian Vaults, la structure des dossiers fait partie de l’organisation des connaissances. Des répertoires comme Product, Package, Obsidian et Scenarios ne sont pas de simples conteneurs ; ils expriment un contexte et des limites de contenu.

Un document normalisé par DeMinds doit garder cette structure visible, tout en faisant converger les contenus sélectionnés vers un seul document de travail Markdown lisible à la fois dans la Mind Map et dans Markdown Preview.

4. Traiter Wiki Link et Wiki Embed de façon statique

Les éléments Obsidian [[Wiki Link]] et ![[Wiki Embed]] sont centraux dans l’expérience de lecture d’un Vault. DeMinds, toutefois, n’exécute pas les plugins Obsidian et ne développe pas tout le graphe de liens.

À la place, DeMinds utilise une normalisation statique :

• Un Wiki Link pointant vers une note sélectionnée et résolue sans ambiguïté peut devenir un lien interne dans le document de travail
• Un Wiki Link non sélectionné, manquant ou ambigu devient un texte lisible
• Les Wiki Embeds d’images sont convertis en références d’image Markdown standard
• Les embeds de notes ne sont pas développés récursivement ; ils restent des références lisibles

Cette approche garde le contenu lisible, la structure maîtrisée et le résultat exporté sous forme de Markdown ordinaire, plutôt que sous forme d’un état dépendant de l’exécution d’Obsidian.

5. Les chemins de ressources doivent rester cohérents

Les Markdown Packages et les Obsidian Vaults contiennent souvent des ressources portant le même nom. Deux dossiers différents peuvent contenir chacun un a.png ; un document peut référencer images/a.png, tandis qu’un autre référence assets/a.png.

Si les ressources sont fusionnées uniquement par nom de fichier, les images peuvent facilement pointer vers le mauvais fichier. DeMinds a donc besoin d’une fermeture de ressources fondée sur les chemins : il conserve uniquement les ressources directement référencées par les documents sélectionnés, réellement disponibles et situées dans une limite sûre.

Dans un baseline fusionné, les références de ressources sont réécrites vers des chemins relatifs explicables et exportables. Le Markdown Package exporté reste ainsi cohérent et peut être consulté et maintenu en dehors de DeMinds.

6. La prise en charge de Markdown Package est la base

La prise en charge d’un Obsidian Vault n’est pas une capacité isolée. Elle s’appuie sur les capacités Markdown Package de DeMinds : recommandation d’entrée, Document Chooser, fusion de plusieurs documents, fermeture de ressources et export préservant les chemins.

Un Markdown Package classique convient généralement mieux à une fusion ordonnée. Un Obsidian Vault convient généralement mieux à la structure du Vault. Les deux suivent le même principe de fond : générer un document de travail autour de la sélection explicite de l’utilisateur, au lieu de copier tout le package.

7. La valeur de DeMinds : transformer une structure en document de travail

DeMinds ne cherche pas à remplacer Obsidian ni à recréer dans l’application toutes les fonctions d’une base de connaissances. Il convient mieux à ce flux de travail :

1. Extraire d’Obsidian, d’une page web, d’une conversation AI ou d’un Markdown Package le contenu sur lequel continuer à travailler
2. Le normaliser en document de travail Markdown
3. Examiner sa structure dans une Mind Map
4. Le lire dans Markdown Preview
5. Continuer à l’éditer, l’organiser et l’exporter

Pour des actifs de connaissance à long terme, la valeur est claire : le contenu reste en Markdown, la structure peut être visualisée sous forme de Mind Map, les chemins de ressources restent portables et le résultat n’est pas enfermé dans un seul outil.

8. Un cas typique : nettoyer des conversations AI

De nombreuses conversations AI sont utiles au moment de leur création, mais deviennent difficiles à maintenir lorsqu’elles sont conservées sous forme de longs textes. DeMinds peut transformer ce type de contenu en Markdown structuré, puis l’aider à entrer dans un flux de connaissances plus durable.

Ce processus suit la même logique que le traitement d’un Obsidian Vault. DeMinds se soucie moins de l’outil d’origine que de la possibilité de transformer le contenu en Markdown structuré lisible, modifiable et portable.

Conclusion

« D’un Obsidian Vault à un document de travail DeMinds » n’est pas une migration complète, ni un remplacement d’Obsidian.

C’est un flux de lecture structuré : DeMinds détecte l’entrée, laisse l’utilisateur choisir le contenu, préserve la structure du Vault, traite les liens et les pièces jointes de façon statique, puis génère un document Markdown sur lequel il est possible de continuer à travailler.

C’est la position centrale de DeMinds : un espace de travail local-first Markdown + Mind Map qui garde les actifs de connaissance lisibles, modifiables et portables.