Le Markdown est-il un bon format pour un journal intime à long terme ?
Pour un journal axé sur le texte, le Markdown est un format pratique lorsque vous souhaitez des entrées qui restent lisibles en texte ordinaire et peuvent être ouvertes dans de nombreux types d'éditeurs. Ses limites sont importantes : le Markdown ne conserve pas les fonctionnalités propriétaires d'une application, ne stocke pas les médias par lui-même, ne crée pas de sauvegardes et ne protège pas les entrées par chiffrement. Un journal durable dépend donc autant de la manière dont vous organisez, exportez, copiez et restaurez périodiquement les fichiers que du format lui-même.
Ce que le Markdown préserve — et ce qu'il ne préserve pas
Le Markdown est du texte brut doté de conventions simples pour les titres, la mise en valeur, les listes, les liens et d'autres structures. Vous pouvez lire un fichier tel que `2026-09-27.md` dans un éditeur de texte basique, même si son application de rédaction d'origine n'est plus disponible. La [spécification CommonMark 0.31.2](https://spec.commonmark.org/0.31.2/) décrit une syntaxe Markdown définie et ses règles de rendu ; elle ne garantit pas que chaque programme interprétera chaque variante de Markdown de la même manière.
Cette distinction compte car le « Markdown » ne constitue pas un ensemble unique et universel de fonctionnalités. CommonMark couvre des structures familières comme les titres, les paragraphes, les listes, les liens et les images. Les applications peuvent ajouter une syntaxe pour les tableaux, les notes de bas de page, les cases à cocher, les encadrés d'avertissement ou d'autres fonctionnalités. Une autre application peut afficher cette syntaxe ajoutée de manière littérale, l'omettre ou lui appliquer un rendu différent. Si vous choisissez une application de journal, vérifiez si elle exporte les fichiers Markdown d'origine et comment elle gère le formatage spécifique à l'application.
La syntaxe des images en Markdown pointe vers un fichier image ; elle n'intègre ni ne conserve l'image au sein même du document texte. De même, les enregistrements audio doivent exister sous forme de fichiers séparés. Un lien dans une entrée peut être brisé si la pièce jointe est manquante, renommée ou stockée à un emplacement auquel la nouvelle application ne peut pas accéder. Conservez les pièces jointes aux côtés des entrées, utilisez des chemins relatifs stables lorsque vos outils les prennent en charge, et incluez une brève description dans l'entrée afin que le contexte reste compréhensible si un fichier média ne peut pas être ouvert.
Une structure simple de dossiers pour votre journal
Un dossier basé sur la date peut rester facile à explorer en dehors de l'application d'origine. Par exemple, placez `README.txt` ainsi que les dossiers `Entries/` et `Media/` à l'intérieur d'un dossier `Journal/`. Stockez une entrée datée sous `Entries/2026/2026-09-27.md` et sa photo sous `Media/2026-09-27-garden.jpg`. Le lien relatif entre cette entrée et la photo est `../../Media/2026-09-27-garden.jpg` ; le fichier doit être déplacé avec l'archive.
Une entrée pourrait commencer par `# 2026-09-27`, suivi d'une courte observation et d'un lien tel que `[le jardin après la pluie](../../Media/2026-09-27-garden.jpg)`.
`README.txt` peut expliquer l'organisation des dossiers, la convention de nommage des fichiers, la variante de Markdown, les noms des pièces jointes et toute extension éventuelle. Les [conseils d'archivage personnel de la Bibliothèque du Congrès](https://digitalpreservation.gov/personalarchiving/records.html) recommandent des noms descriptifs, une arborescence de dossiers claire et une brève description. Il s'agit de conseils généraux de conservation, et non d'une validation spécifique de Markdown.
Choisir délibérément le texte brut et indiquer l'encodage des caractères
Rédigez et exportez vos entrées en UTF-8 lorsque l'application propose un choix d'encodage. L'UTF-8 est une méthode standardisée d'encodage du texte Unicode ; la [spécification RFC 3629](https://www.rfc-editor.org/rfc/rfc3629.html) décrit sa relation avec Unicode et sa compatibilité avec les logiciels basés sur l'ASCII. Préciser l'encodage dans vos notes peut aider les futurs lecteurs à diagnostiquer des caractères brouillés, surtout si les entrées contiennent plusieurs langues, des lettres accentuées ou des symboles. Cela n'empêche pas la corruption de fichiers et ne garantit pas que chaque programme gérera le texte correctement.
Gardez des noms de fichiers simples et cohérents. Une date triable telle que `AAAA-MM-JJ` est une convention utile ; évitez de dépendre de l'organisation masquée ou des étiquettes d'une application particulière comme seul moyen d'identifier une entrée. Les étiquettes peuvent toujours être utiles à l'intérieur des fichiers, mais placez le contexte essentiel dans le texte ordinaire si vous voulez qu'il accompagne l'entrée partout.
Garder à l'esprit les fonctionnalités spécifiques à l'application
Avant de consacrer des années d'écriture à un flux de travail propre à une application, créez une entrée de test qui utilise ce dont vous avez réellement besoin : un titre, un lien, un tableau ou une case à cocher le cas échéant, ainsi qu'une photo ou une pièce jointe audio. Exportez-la, puis ouvrez les fichiers exportés dans un autre éditeur compatible Markdown et dans un éditeur de texte brut. Vérifiez que la formulation, les dates, les marqueurs de formatage et les références aux pièces jointes sont bien présents.
Si votre application utilise une syntaxe personnalisée, déterminez si cette fonctionnalité vaut le coût d'une future migration. Par exemple, un bloc d'avertissement spécifique à une application peut être visuellement pratique, mais un titre et un paragraphe standards sont plus faciles à interpréter ailleurs. Si vous conservez des extensions, documentez-les dans `README.txt` et conservez un export depuis l'application d'origine lorsque c'est possible. Considérez l'apparence générée et le texte sous-jacent comme deux éléments distincts à examiner.
Sauvegardes et confidentialité : deux exigences distinctes
Un format lisible ne constitue pas une stratégie de sauvegarde. Conservez au moins deux copies et stockez-les dans des endroits différents, par exemple sur un appareil local et sur un disque externe ou un autre lieu de stockage. Les [conseils de la Bibliothèque du Congrès pour les archives numériques personnelles](https://digitalpreservation.gov/personalarchiving/records.html) suggèrent de faire plusieurs copies, de les conserver dans des lieux distincts, de vérifier les fichiers au moins une fois par an et de faire de nouvelles copies si nécessaire. Ce sont des recommandations générales d'archivage personnel ; elles n'indiquent pas que le Markdown est particulièrement facile à préserver.
De même, les fichiers Markdown ne sont pas chiffrés simplement parce qu'ils sont en texte brut ou stockés dans un dossier. Demandez-vous qui peut avoir accès aux appareils, aux destinations de sauvegarde et aux éventuels services de synchronisation utilisés. Si vous recourez au chiffrement, assurez-vous de pouvoir récupérer la clé ou le mot de passe et testez l'ouverture d'une sauvegarde ; sinon, le chiffrement peut rendre inutilisable une copie pourtant conservée intacte. Équilibrez les mesures de confidentialité avec un plan de récupération que vous êtes réellement en mesure d'exécuter.
Effectuer un exercice de migration avant de faire confiance à l'archive
Un exercice de migration permet de vérifier si le journal peut quitter son application actuelle tout en restant parfaitement compréhensible. Vous pouvez le faire avec quelques entrées de test avant d'adopter un flux de travail, puis le répéter périodiquement avec une sauvegarde.
**Créez un jeu de test.** Incluez des entrées comportant du texte non anglais ou accentué, tous les types de mise en forme que vous utilisez, et au moins une image ou une pièce jointe audio. Incluez également une fonctionnalité spécifique à l'application si vous en dépendez.
**Exportez les fichiers.** Enregistrez les entrées en Markdown et les médias dans l'arborescence de dossiers que vous prévoyez de conserver. Lisez les notes d'exportation ou le fichier README et assurez-vous qu'ils précisent l'encodage, les extensions de syntaxe et la méthode de nommage des pièces jointes.
**Copiez le dossier ailleurs.** Utilisez un emplacement séparé, et pas simplement une autre vue de la bibliothèque de la même application. Conservez l'original jusqu'à ce que vous ayez vérifié la copie.
**Ouvrez la copie de manière indépendante.** Utilisez un autre éditeur ou un autre ordinateur si possible. Lisez le texte directement, inspectez les fichiers exportés et suivez chaque lien média. Confirmez que les caractères sont intacts et que les pièces jointes s'ouvrent bien.
**Essayez une restauration.** Importez ou ouvrez le dossier copié dans le nouvel outil envisagé, le cas échéant. Prenez note de tout formatage ou de toute fonctionnalité perdue. Si les fichiers sont chiffrés, vérifiez que vous pouvez déverrouiller la copie restaurée à l'aide des informations de récupération que vous avez enregistrées.
**Notez ce qui a fonctionné.** Mettez à jour `README.txt` avec les étapes d'exportation, les dépendances et toutes les fonctionnalités propres à l'application nécessitant une conversion. Répétez l'exercice après une mise à jour majeure de l'application et à intervalles réguliers, par exemple lors de la vérification annuelle des fichiers recommandée par la Bibliothèque du Congrès.
Une étape qui échoue est un indice utile : des pièces jointes manquantes indiquent une exportation incomplète ou un problème de chemin ; des caractères altérés invitent à vérifier l'encodage ; des encadrés ou des tableaux perdus peuvent signaler une extension propre à l'application. Corrigez le flux de travail et répétez l'exercice avant de considérer l'exportation comme une copie fiable.
Alors, le Markdown est-il un bon choix ?
Choisissez le Markdown si la majeure partie de votre journal est constituée de texte, si vous tenez à disposer de fichiers lisibles sans l'application d'origine, et si vous êtes prêt à organiser les pièces jointes et les sauvegardes séparément. Optez pour un flux de travail doté d'une procédure d'exportation testée si vous dépendez de médias enrichis, de mises en forme personnalisées ou de fonctionnalités stockées dans la base de données privée d'une application. Dans les deux cas, évaluez le système à l'aide d'un test simple : pouvez-vous trouver une entrée, lire son texte, comprendre sa structure et ouvrir ses pièces jointes depuis une copie indépendante ? Le Markdown facilite ce test pour le texte ; ce sont vos pratiques d'archivage globales qui feront la différence pour tout le reste.