Accueil › Blog › Prévisualiser un README Markdown
Vous venez d'écrire un README.md, une description de pull request ou une note technique en Markdown, et vous voulez être sûr que les tableaux, les cases à cocher et les blocs de code s'afficheront correctement — avant de faire un commit. Voici comment procéder en quelques secondes, sans installer d'extension ni ouvrir un compte.
Le Markdown a l'avantage d'être un format texte brut simple, mais c'est aussi son piège : une syntaxe légèrement incorrecte (une ligne de séparation de tableau mal comptée, un espace manquant après un #) ne provoque aucune erreur visible dans l'éditeur de code — le fichier reste un simple .txt tant qu'il n'est pas rendu. Le seul moyen de savoir si le résultat sera correct, c'est de le convertir en HTML et de regarder le rendu. Coller le contenu de votre README.md dans un éditeur qui affiche l'aperçu HTML instantanément, à côté du texte source, permet de repérer immédiatement ce genre de problème.
C'est particulièrement utile pour les fichiers README de projets open source, les descriptions de pull requests, les commentaires d'issues GitHub, ou les notes techniques internes rédigées en GitHub Flavored Markdown (GFM) — la variante utilisée par GitHub, GitLab et la plupart des outils de documentation.
C'est l'erreur la plus fréquente dans les README : une colonne en trop ou en moins dans la ligne de séparation par rapport à l'en-tête. Voici, à titre d'exemple, à quoi ressemble un tableau bien formé une fois rendu :
| Syntaxe Markdown | Rendu HTML |
|---|---|
# Titre | Titre de niveau 1 (h1) |
**gras** | gras |
| A | B | | Cellule de tableau (2 colonnes) |
- [ ] Tâche | Case à cocher non cochée |
``` js | Bloc de code avec coloration JS |
:) placé à gauche, à droite ou des deux côtés des tirets dans la ligne de séparation contrôle l'alignement de la colonne (gauche, droite ou centré) — un détail facile à rater sans aperçu visuel.- [ ] / - [x]) et les blocs de code délimités par trois backticks se vérifient de la même façon : on regarde le rendu, pas le texte brut, pour confirmer que les cases s'affichent et que la coloration syntaxique reste lisible.Dans un README typique, une section « À faire » utilise des listes de tâches pour suivre l'avancement d'un projet, et une section « Installation » contient souvent un bloc de code avec une balise de langage comme ```bash ou ```js. Un aperçu qui prend en charge la coloration syntaxique dérivée du thème (sans charger de bibliothèque externe) permet de vérifier, avant publication, que les mots-clés, chaînes et commentaires restent distincts visuellement — y compris en mode sombre.
[^1], un bon aperçu les regroupe automatiquement dans une section « Notes de bas de page » en bas de page, avec des liens aller-retour entre l'appel de note et sa définition.Une fois le rendu validé, il suffit de copier le HTML généré pour le coller dans un CMS, ou de télécharger le fichier .md et .html directement, sans jamais avoir envoyé le contenu à un serveur externe.
Collez votre README, importez un fichier .md, ou partez d'un modèle prêt à l'emploi — l'aperçu HTML se met à jour en direct, entièrement dans votre navigateur.
Essayer l'outil →| --- | --- |, et le nombre de colonnes doit être identique dans l'en-tête, la séparation et chaque ligne de données. Un aperçu en direct permet de repérer immédiatement l'erreur avant de publier.- [ ] pour une case vide ou - [x] pour une case cochée, en début de ligne. Un aperçu compatible GitHub Flavored Markdown (GFM) affichera ces lignes sous forme de cases à cocher cliquables, exactement comme GitHub les rendra dans votre dépôt.```js ou ```python. Dans un aperçu qui prend en charge la coloration syntaxique, mots-clés, chaînes et commentaires apparaissent immédiatement dans des couleurs distinctes, ce qui permet de vérifier la lisibilité avant de publier le fichier.