Éditeur Markdown

Écrivez en Markdown, prévisualisez instantanément. Support GFM complet.

Markdown
Prévisualisation

Guide complet : Maîtriser Markdown pour une écriture efficace

Pourquoi Markdown a révolutionné mon écriture

Après des années à rédiger de la documentation technique, des articles de blog, des README et des notes personnelles, Markdown est devenu mon format d'écriture par défaut. Créé par John Gruber en 2004 (avec l'aide d'Aaron Swartz), ce langage de balisage léger a transformé la façon dont les développeurs et rédacteurs techniques travaillent.

La philosophie de Markdown est élégante : le texte source doit être lisible tel quel, sans rendu. Un fichier Markdown ouvert dans le Bloc-notes reste compréhensible, contrairement à du HTML ou du LaTeX. Cette lisibilité native permet de se concentrer sur le contenu plutôt que sur le formatage.

Où Markdown est-il utilisé aujourd'hui ?

Markdown est devenu omniprésent dans l'écosystème du développement :

  • GitHub / GitLab / Bitbucket : README.md, CONTRIBUTING.md, documentation de projet, issues, pull requests, wikis
  • Documentation technique : MkDocs, Docusaurus, GitBook, Read the Docs, VuePress
  • Blogging : Jekyll, Hugo, Gatsby, Next.js, Ghost, DEV.to, Hashnode
  • Prise de notes : Obsidian, Notion, Bear, Typora, Joplin
  • Communication : Slack, Discord, Microsoft Teams, Reddit
  • CMS : WordPress (blocs), Strapi, Contentful, Sanity

Syntaxe de base : les fondamentaux

✨ Formatage du texte

**gras** ou __gras__ pour le gras. *italique* ou _italique_ pour l'italique. ~~barré~~ pour le barré. `code` pour le code inline. Combinables : ***gras et italique***.

📝 Titres et hiérarchie

# Titre 1, ## Titre 2, jusqu'à ###### Titre 6. L'espace après le # est important ! Les titres structurent le document et permettent la navigation. Alternative : soulignement avec === (H1) ou --- (H2).

📋 Listes à puces et numérotées

-, * ou + pour les puces. 1., 2., 3. pour les numérotées (les numéros n'ont pas besoin d'être corrects, Markdown recalcule). Indentez avec 2-4 espaces pour imbriquer.

🔗 Liens et images

[texte](url) pour les liens. [texte](url "titre") avec tooltip. ![alt text](image.png) pour les images. Les URLs peuvent être relatives (./docs/guide.md) ou absolues.

Syntaxe avancée : GFM et au-delà

GitHub Flavored Markdown (GFM) étend le Markdown standard avec des fonctionnalités très utiles :

  • Blocs de code avec coloration syntaxique : Trois backticks avec le nom du langage. ```javascript, ```python, ```sql. Supporte des centaines de langages grâce à des bibliothèques comme highlight.js ou Prism.
  • Tableaux : Créez des tableaux avec des pipes | et des tirets ---. Alignement avec :--- (gauche), :---: (centre), ---: (droite).
  • Listes de tâches : - [ ] pour une case vide, - [x] pour une case cochée. Très utile pour les TODO lists et les issues GitHub.
  • Liens automatiques : Les URLs sont automatiquement cliquables sans syntaxe spéciale.
  • Mentions : @username pour mentionner quelqu'un sur GitHub/GitLab.
  • Références : #123 pour lier une issue, SHA pour un commit.
  • Emoji : :rocket:, :smile:, :warning: (support variable selon les plateformes).
  • Notes de bas de page : [^1] dans le texte, [^1]: Explication en bas (support variable).

Blocs spéciaux et citations

  • Citations : Préfixez avec >. Peut être imbriqué (>>). Idéal pour citer du code ou des sources.
  • Ligne horizontale : Trois tirets ---, astérisques *** ou underscores ___ sur une ligne seule.
  • Code inline : Simples backticks `code`. Pour inclure un backtick littéral, utilisez doubles backticks.
  • Blocs de code indentés : 4 espaces au début de chaque ligne (alternative aux triple backticks).

Bonnes pratiques pour une documentation de qualité

  • Structure hiérarchique : Commencez par un seul H1, puis H2, H3... Ne sautez pas de niveaux.
  • Une ligne vide entre les blocs : Séparez paragraphes, listes et titres par une ligne vide pour la lisibilité et éviter les problèmes de parsing.
  • Alt text pour les images : Toujours fournir une description pour l'accessibilité et le SEO.
  • Liens relatifs dans les repos : Utilisez ./docs/file.md plutôt que des URLs absolues pour la portabilité.
  • Prévisualisation avant commit : Le rendu peut varier selon les plateformes. Testez !
  • Un README soigné : C'est la vitrine de votre projet. Incluez description, installation, usage, contribution.
  • Linter Markdown : Des outils comme markdownlint détectent les incohérences et erreurs de syntaxe.

Cet éditeur : fonctionnalités et traitement local

Notre éditeur Markdown utilise la bibliothèque marked.js pour le parsing et highlight.js pour la coloration syntaxique du code. Il supporte GFM complet : tableaux, listes de tâches, code highlighté, etc.

Tout le traitement est local : votre texte ne quitte jamais votre navigateur. Vous pouvez écrire des documents confidentiels en toute sécurité. Exportez en .md pour le source Markdown ou en .html pour un document standalone avec styles intégrés.

Questions fréquentes sur Markdown

Quelle est la différence entre Markdown standard et GFM (GitHub Flavored Markdown) ?

Le Markdown original de John Gruber (2004) était minimaliste : titres, listes, liens, images, code, citations. Pas de tableaux, pas de listes de tâches.

GFM (GitHub Flavored Markdown) ajoute des extensions majeures :

  • Tableaux avec syntaxe pipe |
  • Blocs de code avec triple backticks et nom du langage
  • Texte barré avec ~~texte~~
  • Listes de tâches - [ ] et - [x]
  • Liens automatiques (URLs cliquables sans syntaxe)
  • Mentions @user et références #issue

La plupart des plateformes modernes (GitHub, GitLab, Bitbucket, Notion, Slack) supportent GFM ou une variante similaire. Notre éditeur utilise GFM par défaut.

Comment faire un saut de ligne simple (sans nouveau paragraphe) ?

C'est une source fréquente de confusion ! En Markdown :

  • Un simple Entrée ne crée PAS de saut de ligne visible. Le texte continue sur la même ligne dans le rendu.
  • Deux espaces + Entrée créent un saut de ligne (<br>). C'est la méthode standard.
  • Une ligne vide crée un nouveau paragraphe (<p>) avec plus d'espacement.
  • HTML <br> fonctionne aussi si votre plateforme l'autorise.

Astuce : GFM avec l'option "breaks" (activée dans notre éditeur) convertit les simples Entrée en sauts de ligne, ce qui est plus intuitif.

Comment échapper les caractères spéciaux Markdown ?

Utilisez le backslash \ devant tout caractère spécial pour l'afficher littéralement :

  • \* → * (au lieu d'italique)
  • \# → # (au lieu d'un titre)
  • \[texte\] → [texte] (au lieu d'un lien)
  • \`code\` → `code` (au lieu de code inline)

Caractères nécessitant parfois un échappement : \ ` * _ { } [ ] ( ) # + - . ! |

Exception : dans les blocs de code (triple backticks ou indentés), aucun échappement n'est nécessaire — tout est affiché littéralement.

Puis-je utiliser du HTML dans mon Markdown ?

Oui, le HTML inline est généralement supporté dans Markdown. C'est utile pour des éléments que Markdown ne gère pas nativement :

  • <details><summary> pour les accordéons/spoilers
  • <kbd> pour styliser les touches clavier
  • <sup> et <sub> pour exposants et indices
  • <br> pour les sauts de ligne forcés
  • <img> avec attributs spécifiques (width, align)

Attention : certaines plateformes filtrent le HTML pour des raisons de sécurité. GitHub README supporte beaucoup de HTML, mais les commentaires d'issues en filtrent une partie. Testez toujours sur votre plateforme cible.

Comment créer une table des matières (TOC) automatique ?

Le Markdown standard ne supporte pas les tables des matières automatiques. Voici les options selon les plateformes :

  • GitHub : Pas de TOC automatique, mais créez des liens manuellement vers les titres : [Section](#section). GitHub génère des ancres automatiques pour chaque titre (minuscules, tirets pour espaces).
  • GitLab : Supporte [[_TOC_]] pour générer automatiquement une TOC.
  • MkDocs / VuePress / Docusaurus : Plugins dédiés pour la TOC.
  • VS Code : Extensions comme "Markdown All in One" génèrent des TOC.

Pour les gros documents, une TOC améliore significativement la navigation. Automatisez si possible !

Markdown, reStructuredText ou AsciiDoc : lequel choisir ?

Chaque format a ses forces :

  • Markdown : Simplicité, popularité immense, support universel. Idéal pour README, blogs, notes, documentation simple. Limitation : pas de fonctionnalités avancées natives (TOC, admonitions, références croisées).
  • reStructuredText (reST) : Standard pour la documentation Python (Sphinx). Références croisées, directives extensibles, TOC native. Plus complexe, moins répandu hors Python.
  • AsciiDoc : Plus puissant que Markdown, moins complexe que reST. Tableaux complexes, admonitions, includes. Populaire pour les livres techniques (O'Reilly).

Ma recommandation : Markdown pour 90% des cas. reST si vous faites de la documentation Python avec Sphinx. AsciiDoc pour des livres ou documentation très complexe.

Comment aligner du texte ou des images en Markdown ?

Le Markdown standard ne supporte pas l'alignement. Vous devez utiliser du HTML :

  • Centrer une image : <p align="center"><img src="..."></p>
  • Aligner à droite : <p align="right">Texte</p>
  • Tableaux : L'alignement des colonnes est supporté avec :--- (gauche), :---: (centre), ---: (droite)

Note : le support de align varie selon les plateformes. GitHub le supporte dans les README.

Mes données sont-elles sécurisées dans cet éditeur ?

Oui, absolument. Tout le traitement s'effectue dans votre navigateur :

  • Le parsing Markdown (marked.js) s'exécute côté client
  • La coloration syntaxique (highlight.js) est locale
  • Aucune donnée n'est envoyée à nos serveurs
  • Aucun stockage cloud ou synchronisation

Vous pouvez écrire des documents confidentiels en toute sécurité. Vérifiez l'onglet Réseau des DevTools : aucune requête n'est émise pendant l'édition. Une fois la page chargée, l'éditeur fonctionne même hors ligne.