Exporter Obsidian vers Word : le guide complet 2026

Si vous vivez dans Obsidian, vous connaissez déjà le problème. Vous avez passé trois mois à construire une note de recherche bourrée de syntaxe propre à Obsidian — des choses comme :

[[Project Plan]]        → lien vers une autre note
![[diagram.png]]        → image intégrée
> [!note] Key insight   → bloc callout

Puis un collègue vous demande la version Word — et chacun de ces éléments non standard casse.

J'ai rencontré ce problème la première fois que j'ai dû livrer une enquête technique de 40 pages à un décideur qui refusait d'ouvrir Obsidian. Ce qui paraissait soigné dans le coffre est sorti sous forme d'un magma de crochets littéraux et de placeholders d'images orphelins dans Word. Après avoir galéré sur cette conversion — et plusieurs autres depuis —, j'ai fini par adopter un workflow qui tient la route. Ce guide le documente : l'étape de prétraitement que la plupart des gens sautent, les trois particularités d'Obsidian qui comptent vraiment, et quoi faire quand les images ou les callouts refusent de coopérer.

Pourquoi le Markdown d'Obsidian n'est pas portable (et ce qui casse)

Obsidian stocke les notes sous forme de fichiers .md en texte brut, d'où l'idée répandue que l'export vers Word est trivial. Il ne l'est pas — parce qu'Obsidian étend le Markdown standard avec des fonctionnalités qu'aucun convertisseur générique ne comprend.

Voici les quatre extensions responsables de presque tous les exports ratés :

Les convertisseurs Markdown standard — Pandoc, la plupart des outils en ligne — traitent [[...]] comme du texte littéral et ![[...]] comme un token non reconnu. La vue Obsidian que vous admirez dans l'application est un aperçu, pas la source. Cette distinction est la cause profonde de la plupart des frustrations du type « pourquoi mon export est cassé ».

Il y a aussi un problème plus subtil : les chemins des pièces jointes. Obsidian résout ![[image.png]] en fouillant votre coffre à la recherche d'un fichier correspondant, quel que soit le dossier. Le Markdown standard, lui, exige un chemin relatif explicite. Si votre coffre stocke les pièces jointes dans 99 Attachments/ et que votre note vit dans 10 Projects/, le lien de l'image doit être réécrit avant qu'un convertisseur puisse la retrouver.

Avant l'export : l'étape de prétraitement qui sauve la mise

Le plus gros gain de fiabilité de mon workflow est venu d'une passe de prétraitement de 5 minutes avant de lancer le moindre convertisseur. Sautez-la et vous passerez 30 minutes à nettoyer le fichier Word après coup.

Étape 1 : vérifiez vos réglages de pièces jointes

Ouvrez Settings → Files and links. Notez deux valeurs :

• Default location for new attachments — où atterrissent les nouvelles images/PDF
• New link format — comment Obsidian écrit les chemins (Shortest path when possible, Relative path to file ou Absolute path in vault)

Si c'est réglé sur Shortest path when possible (la valeur par défaut d'Obsidian), votre export cassera pour toute note dont les pièces jointes ne sont pas dans le même dossier. Avant d'exporter, basculez sur Relative path to file. Ce réglage ne s'applique qu'aux nouveaux liens — les liens existants conservent leur ancien format jusqu'à ce qu'on les réécrive. L'étape 2 ci-dessous s'en charge.

Étape 2 : convertissez les wikilinks en liens Markdown standard

Obsidian propose un interrupteur intégré : Settings → Files and links → Use [[Wikilinks]] → OFF. Quand c'est désactivé, les nouveaux liens sont écrits comme [Note Name](Note-Name.md). Mais ça ne concerne que les nouveaux liens.

Pour convertir les [[wikilinks]] existants dans une note, vous avez deux options :

1. Manuel pour les petits exports — Cmd/Ctrl+F dans la note, repérez chaque [[, réécrivez. Viable pour une note de 5 pages.
2. Plugin communautaire pour les gros coffres — ouvrez Settings → Community plugins et cherchez des termes comme « link converter » ou « markdown links ». Plusieurs plugins de l'écosystème convertissent en masse les wikilinks (et les pièces jointes intégrées ![[...]]) vers la syntaxe Markdown standard, soit sur le fichier courant, soit sur un dossier entier. Prenez-en un récemment mis à jour et avec un nombre d'installations qui inspire confiance.

Après la réécriture, vos pièces jointes intégrées ressembleront à ![image.png](path/to/image.png). Vérifiez la sortie — si votre dossier de pièces jointes contient des espaces, encodez-les en URL (My%20Vault/attachment.png) ou le convertisseur laissera tomber l'image en silence.

Étape 3 : décidez quoi faire des callouts

Les callouts Obsidian (> [!note], > [!warning], etc.) sont précieux dans le coffre mais n'ont aucun équivalent dans Word. Vous avez trois options, classées par effort :

• Accepter la dégradation — ils seront rendus comme de simples citations. Le type de callout (note/warning/tip) est perdu, mais le contenu survit. Acceptable pour la plupart des livrables.
• Réécrire les plus importants — remplacez > [!warning] Critical par > **⚠️ Critical :** avant d'exporter. Lisible des deux côtés.
• Post-traiter dans Word — convertissez les citations en encadrés stylisés via les styles rapides de Word. Ça ne vaut le coup que pour les livrables très soignés.

J'utilise l'option 2 pour tout ce qui fait moins de 20 pages et l'option 1 pour le reste.

Étape 4 : exportez les blocs Dataview en contenu statique

Si votre note contient des requêtes Dataview, elles s'exportent sous forme de code de la requête, pas de tableau résultat. Avant d'exporter, exécutez la requête dans Obsidian, copiez la sortie rendue, et collez-la en tableau Markdown statique à la place du bloc de code. Oui, c'est manuel. Non, il n'y a pas de contournement propre — Dataview rend côté client, donc le fichier source ne contient pas les données.

Le workflow d'export en quatre étapes

Une fois le prétraitement fait, la conversion elle-même est simple.

1. Copiez la note (n'exportez pas sur place)

Dupliquez votre note cible et ses pièces jointes dans un dossier temporaire en dehors du coffre. Vous ne voulez pas que les modifications de prétraitement (réécritures de liens, substitutions de callouts) polluent votre coffre principal. Je garde un dossier _export-staging/ sur mon bureau pour ça.

2. Aplatissez les chemins des pièces jointes

Déplacez toutes les images référencées dans le même dossier que le fichier .md et mettez à jour les liens pour qu'ils soient de simples noms de fichiers : ![diagram](diagram.png) plutôt que ![diagram](../../99 Attachments/diagram.png). La plupart des convertisseurs galèrent avec les chemins qui remontent dans l'arborescence.

3. Lancez le convertisseur

Uploadez le fichier .md prétraité sur le convertisseur Markdown vers Word de MarkFlow. Il gère le GitHub Flavored Markdown (GFM) — y compris tableaux, listes de tâches et notes de bas de page — ce qui couvre toutes les fonctionnalités standard produites par Obsidian après prétraitement. Les images sont intégrées inline, les blocs de code conservent leur coloration syntaxique, et les titres sont mappés sur les styles de titres Word pour que le volet de navigation fonctionne dans le DOCX de sortie.

Si la note contient des maths LaTeX ($E=mc^2$ ou $$...$$), confirmez que le convertisseur choisi les préserve comme équations Word plutôt que de les aplatir en texte brut. Pour les notes truffées de formules — journaux de recherche, brouillons académiques —, c'est la fonctionnalité qui fait la différence. Si Word n'est pas la cible finale et que vous voulez juste un fichier partageable, convertir du Markdown en PDF contourne entièrement les caprices de rendu des équations de Word.

4. Finalisez dans Word

Ouvrez le DOCX et appliquez un modèle Word si vous en avez un. Les styles de titres issus du Markdown se mappent proprement sur les Titre 1/2/3 intégrés de Word, donc restyler le document entier est une opération en un clic via Design → Document Formatting. Vérifiez trois choses avant d'envoyer :

• Table des matières — insérez-en une via References → Table of Contents pour vérifier que tous les titres ont bien été captés
• Taille des images — Obsidian affiche les images à leur taille naturelle, Word peut les gonfler. Tout sélectionner et redimensionner si nécessaire
• Hyperliens — les liens externes doivent être actifs ; les [[wikilinks]] internes doivent être soit résolus, soit supprimés

Cas particuliers propres à Obsidian

Quelques scénarios reviennent assez souvent pour mériter d'être traités individuellement.

Notes quotidiennes et templates

Si vous exportez une note quotidienne qui utilise {{date}} ou des variables Templater, l'export a lieu après qu'Obsidian les a substituées — le .md exporté contient donc la vraie date, pas le placeholder. Aucun traitement spécial nécessaire. L'exception : si vous exportez depuis le système de fichiers sans ouvrir la note dans Obsidian, les templates non résolus passeront au travers. Ouvrez la note d'abord, laissez Obsidian la rendre, puis exportez.

Fichiers canvas

Les fichiers canvas d'Obsidian (.canvas) sont du JSON, pas du Markdown, et aucun convertisseur Markdown n'y touchera. Pour les canvas, l'option qui marche est de prendre une capture d'écran du canvas au niveau de zoom voulu, de l'enregistrer en PNG, puis d'intégrer cette image dans une note Markdown « enveloppe » que vous exportez. Certains plugins communautaires proposent aussi une fonction « exporter canvas en image » si vous en avez besoin suffisamment souvent pour justifier l'installation.

Diagrammes Mermaid

Les blocs de code délimités taggués mermaid sont rendus comme diagrammes dans Obsidian. La plupart des convertisseurs Markdown vers Word en ligne soit les rendent comme images (bien), soit les laissent en code brut (pas bien). MarkFlow rend Mermaid en SVG inline avant conversion, ce que Word affiche comme une image éditable. Si votre convertisseur cible ne supporte pas Mermaid, le repli consiste à exporter le diagramme en PNG depuis la vue Obsidian et à remplacer le bloc de code par une image standard.

Notes de bas de page

Bonne nouvelle — la syntaxe de notes de bas de page d'Obsidian ([^1] et la définition [^1]: texte) est du GFM standard et se convertit proprement vers la fonction de notes de bas de page intégrée de Word. Aucun prétraitement nécessaire.

Tags et frontmatter

Le frontmatter YAML (blocs --- en tête de note) est généralement retiré par les convertisseurs. Si le frontmatter contient des infos utiles au lecteur (auteur, date, statut), déplacez-le dans le corps sous forme de paragraphe standard avant d'exporter. Les tags inline comme #project/research survivent généralement en texte brut — ce qui est acceptable dans la plupart des cas, gênant dans d'autres. Faites un rechercher-remplacer pour les supprimer si le document Word sera lu par des non-utilisateurs d'Obsidian.

Quand la conversion manuelle bat l'automatisation

Je vais être honnête : pour une unique note de 2-3 pages avec peu de mise en forme, le workflow le plus rapide reste copier depuis la vue lecture d'Obsidian et coller dans Word. La vue lecture d'Obsidian rend du HTML, et Word colle le HTML comme contenu formaté avec une fidélité étonnante. Les tableaux passent, le gras/italique survit, les titres se mappent sur les styles de titres Word.

Cette approche « coller depuis la vue lecture » échoue sur trois points :

1. Les images — elles sont collées sous forme de références liées aux fichiers de votre coffre, qui cassent dès que le fichier quitte votre machine
2. Les blocs de code — la coloration syntaxique disparaît, la police à chasse fixe est incohérente
3. Les callouts et Mermaid — même casse qu'un export standard

Donc : notes courtes sans code ni images → collez. Tout ce qui est plus long ou technique → le workflow en 4 étapes ci-dessus.

Dépannage : que faire quand ça casse

Voici les modes de défaillance que je vois le plus souvent. Pour une référence plus large, le guide de dépannage de la conversion Markdown couvre en détail 15 problèmes de conversion courants.

Des images manquent dans le fichier Word. Dans environ 80 % des problèmes d'images cassées, c'est un souci de chemin. Vérifiez la source .md — les chemins de pièces jointes sont-ils de simples noms de fichiers (image.png) ou des chemins complexes (../../99 Attachments/My Folder/image.png) ? Aplatissez-les.

Les tableaux sortent comme une bouillie d'une seule ligne. Votre source utilise l'ancien format de tableaux d'Obsidian ou a des pipes incohérents. Ouvrez le .md dans un éditeur de texte brut et assurez-vous que chaque ligne a le même nombre de pipes. La ligne de séparation d'en-tête doit correspondre : | --- | --- |.

Les blocs de code perdent la coloration de leur langage. Vérifiez que vos délimiteurs incluent un tag de langage (par ex. python, js, bash) juste après les triples backticks d'ouverture. Les convertisseurs utilisent ce tag pour appliquer la coloration syntaxique ; les blocs non étiquetés retombent en texte brut.

Les wikilinks s'affichent encore comme [[Note Name]] après export. Le prétraitement n'a pas tourné, ou n'a pas couvert ce fichier. Confirmez que Use [[Wikilinks]] est désactivé dans les réglages, puis relancez le plugin de conversion installé à l'étape 2 sur ce fichier précis — la plupart d'entre eux permettent de se limiter à une seule note plutôt qu'à tout le coffre.

Les formules mathématiques apparaissent en LaTeX brut. Le convertisseur ne gère pas le rendu des maths. Changez de convertisseur, ou faites une capture d'écran de l'équation rendue dans Obsidian et intégrez-la comme image — moche mais fiable.

Un workflow réaliste pour les équipes

Si vous êtes le seul utilisateur d'Obsidian dans une équipe qui a besoin de fichiers Word, mettez en place un processus reproductible plutôt qu'un script d'export ponctuel. La version que j'utilise sur les projets collaboratifs :

1. Gardez un dossier dédié Exports/ dans le coffre pour les notes destinées à Word
2. Dans ce dossier, utilisez des liens Markdown standard dès le départ ([text](note.md)) au lieu de wikilinks — ça économise le prétraitement
3. Lancez une conversion groupée hebdomadaire pour les notes qui ont changé
4. Stockez les DOCX de sortie sur un lecteur partagé, pas dans le coffre

L'idée est de séparer votre espace de réflexion (le coffre principal avec toute sa puissance propre à Obsidian) de votre espace de livraison (le dossier Exports/ qui parle Markdown standard). Refactoriser vers cette séparation m'a pris une heure la première fois et me fait gagner des heures chaque mois depuis.

Si vous arrivez ici par l'autre bout — vous écrivez en Markdown et voulez poser les bases correctement —, le guide comment écrire en Markdown couvre les fondamentaux qui rendent tout export plus fluide. Et pour un regard rapproché sur le côté conversion du pipeline, le guide complet Markdown vers Word détaille les fonctionnalités de convertisseur qui comptent pour les documents complexes.

Pour finir

La vraie force d'Obsidian, ce sont ses fonctionnalités non standard — les wikilinks, les callouts, les requêtes dynamiques qui donnent vie à un coffre. Exporter vers Word, c'est renoncer à la majorité de ça. L'astuce, c'est d'arrêter de lutter : acceptez que la version Word sera une représentation aplatie, prétraitez en conséquence, et utilisez les outils de style de Word pour reconstruire le soin là où ça compte.

Une fois que l'habitude du prétraitement s'installe, tout le pipeline prend environ cinq minutes par note. C'est la différence entre « je ferai ça plus tard » et envoyer le document aujourd'hui.