Migrer de Word vers Markdown : le guide complet
Migrer des documents de Word vers Markdown est en grande partie mécanique, mais les échecs sont prévisibles et peu coûteux à prévenir. Chacun d'eux remonte au fait de traiter la conversion comme une étape magique unique plutôt que comme un petit pipeline comportant quelques décisions.
Ce guide parcourt ces décisions dans l'ordre : combien vous migrez réellement, ce qui survit à la conversion et ce qui n'y survit pas, comment les notes de bas de page, les tableaux et les formules voyagent, et comment finir avec un fichier que votre site statique ou votre wiki accepte du premier coup.
Définissez le périmètre avant de convertir
Un seul document vivant et une archive de dix ans sont deux projets différents. Pour un document, l'objectif est une conversion fidèle que vous pouvez peaufiner à la main en un après-midi. Pour une archive, l'objectif devient la répétabilité : un même jeu d'options appliqué de façon cohérente, avec des humains qui vérifient un échantillon plutôt que chaque fichier.
Dans les deux cas, commencez par un échantillon. Convertissez deux ou trois documents représentatifs — ceux avec les pires tableaux et le plus de figures — et inspectez le résultat de près. L'échantillon vous indique quelles options comptent et combien de nettoyage le reste du lot demandera, avant de vous engager dans l'exécution complète.
Ce qui se convertit proprement, et ce qui ne se convertit pas
Les vrais styles de titre de Word deviennent des titres Markdown, les tableaux simples deviennent des tableaux, les notes de bas de page deviennent des notes de bas de page, et les images incorporées sont extraites en vrais fichiers. Le contenu qui vit dans le flux normal du document se transfère bien, et c'est l'essentiel de ce qu'est réellement un document typique.
Les exceptions se concentrent aux marges. La mise en forme appliquée directement, comme des lignes en gras qui font semblant d'être des titres, ne devient pas de la structure : appliquez d'abord de vrais styles de titre dans Word. Le suivi des modifications est converti comme si chaque modification était acceptée ; résolvez donc les révisions avant de convertir si le texte supprimé compte pour vous. Les commentaires, zones de texte et formes flottantes ne sont pas repris de manière fiable ; leur contenu doit être déplacé dans le flux principal ou capturé séparément.
Les notes de bas de page suivent
Les notes de bas de page Word sont l'une des bonnes surprises. Pandoc les lit et la sortie Markdown utilise une vraie syntaxe de notes : chaque appel dans le texte devient une référence entre crochets avec un accent circonflexe devant son numéro, et toutes les définitions se regroupent en fin de document, liées en retour à leurs appels.
Deux points méritent tout de même une vérification. Les notes qui se référencent entre elles, ou qui contiennent des tableaux ou des images, peuvent ressortir dans un ordre ou une forme différents de l'original. Et les notes de fin se convertissent de la même façon que les notes de bas de page, ce qui est en général exactement ce que vous voulez en Markdown.
Les tableaux et leurs limites
Activez l'option GFM lorsque la destination est GitHub, Obsidian ou la plupart des wikis : les tableaux simples se convertissent en tableaux à barres verticales (pipe tables) — une ligne d'en-tête, une ligne de séparation et une ligne par ligne. Ce format s'affiche partout et reste lisible en texte brut.
La limite est structurelle. Cellules fusionnées, cellules contenant plusieurs paragraphes et tableaux imbriqués n'ont pas de représentation en pipe table, et Pandoc retombe sur des dialectes Markdown que ces plateformes ignorent. La solution honnête est en amont : défusionnez et aplatissez les tableaux compliqués dans Word, ou acceptez que quelques tableaux demanderont une reprise manuelle après la migration.
Les mathématiques deviennent du LaTeX
Les équations saisies avec l'éditeur d'équations de Word sont stockées comme des mathématiques structurées, et Pandoc les convertit au lieu de les abandonner. La sortie Markdown enrobe les formules en ligne de délimiteurs à signe dollar et place les équations hors texte sur leurs propres lignes ; le format de sortie LaTeX émet des environnements mathématiques natifs pour les pipelines de rendu qui les attendent.
Après conversion, repérez les deux points faibles : les formules en ligne que Word affichait de façon ambiguë, et tout ce qui a été collé dans Word comme image il y a des années — c'est désormais une image, pas des mathématiques. Celles-là doivent être ressaisies, et le savoir avant le début de la migration garde le planning honnête.
Une stratégie d'images prévisible
Chaque image incorporée est extraite dans un dossier media à côté du fichier converti, avec les noms attribués par le paquet docx : image1.png et ses frères. Le Markdown référence ces chemins relatifs, et un téléchargement ZIP livre les deux ensemble, ce qui fait de chaque document converti une paire autonome.
Décidez avant l'exécution si les documents gardent leurs propres dossiers media ou fusionnent dans un dossier assets partagé. Les garder séparés est sûr et automatique ; fusionner exige de renommer avec des préfixes parlants et de mettre à jour les références en conséquence. Ce qu'il faut éviter, c'est de découvrir la collision après que plusieurs image1.png se sont déjà écrasés les uns les autres.
Front matter pour votre site statique
Les générateurs de sites statiques comme Hugo et Jekyll attendent un front matter YAML en tête de chaque fichier : title, author, date. Le convertisseur peut émettre ce bloc à partir des propriétés du document stockées dans le docx, si bien que les fichiers arrivent déjà porteurs de métadonnées au lieu d'avoir à les saisir après coup.
Cela ne fonctionne que si les propriétés sont réelles. Les fichiers Word convertis en masse depuis des formats plus anciens ont souvent un champ Title vide et un créateur qui est le compte d'un ancien employé. Passer dix minutes dans Word avant l'exécution, à remplir les informations de fichier de chaque document, fait la différence entre un front matter utile et des espaces réservés.
La passe de migration par lots
Une fois les options calibrées sur l'échantillon, l'exécution en masse se déroule sans incident. Ajoutez le dossier de fichiers docx au convertisseur de ce site, laissez la file traiter chacun avec son propre statut, puis téléchargez le ZIP. La sortie par lots donne à chaque document son propre sous-répertoire, si bien que les images d'un article ne peuvent jamais masquer celles d'un autre.
Conservez les docx originaux jusqu'à ce que la migration soit validée. Ils sont la source de vérité pour tout ce que la conversion a lissé ou laissé tomber, et relancer avec des options ajustées coûte toujours moins cher que reconstruire de mémoire un détail perdu.
Une checklist pour la migration terminée
Pour chaque document, vérifiez six choses : la hiérarchie des titres descend sans saut, chaque référence d'image se résout vers un fichier existant, les tableaux s'affichent sur la plateforme cible, les notes de bas de page apparaissent comme de vraies notes, les formules s'affichent là où elles doivent, et les champs du front matter sont remplis plutôt que vides.
Enfin, faites passer un document de bout en bout dans la destination réelle : compilez le site statique, prévisualisez la page du wiki, ouvrez la note dans Obsidian. Une migration est terminée quand le système cible rend les fichiers, pas quand le convertisseur annonce un succès. Cette dernière vérification prend quelques minutes et attrape tout ce que les contrôles au niveau fichier ont manqué.