C'est quoi MD001 (heading-increment) et pourquoi c'est important ?

**MD001** dit : les niveaux de titres doivent **monter d'un cran à la fois**. On passe de **H1 à H2 à H3**, pas de **H2 directement à H4**. Pourquoi c'est important : les **lecteurs d'écran** annoncent le niveau et les auditeurs se construisent un arbre mental de la page ; sauter un niveau, c'est comme sauter un numéro de chapitre. Cela casse aussi les **tables des matières auto-générées** qui attendent une hiérarchie régulière. Le correctif est trivial : soit on rétrograde le titre sauté, soit on promeut le suivant.

C'est quoi MD009 (no-trailing-spaces) et pourquoi ça existe ?

**MD009** signale les lignes qui se terminent par un ou plusieurs espaces invisibles. Ils se faufilent quand on colle depuis Word, Notion ou une appli de chat. En Markdown, **deux espaces de fin signifient explicitement « insère un saut de ligne ici »** (` \n`), ce qui **n'est presque jamais ce qu'on voulait**. Le renderer place alors un ` ` dur en plein milieu d'un paragraphe et on passe vingt minutes à se demander pourquoi le texte a l'air cassé. L'auto-fix les supprime ; si vous vouliez vraiment un saut de ligne, mettez plutôt une ligne vide.

C'est quoi MD040 (fenced-code-language) et est-ce vraiment nécessaire ?

**MD040** dit : chaque bloc de code fence (les triples backticks ```...```) doit avoir une **étiquette de langue** juste après la fence d'ouverture : ```js```, ```bash```, ```json```, ```tsx```. L'étiquette indique aux **syntax highlighters** (Prism sur GitHub, Shiki sur Astro, highlight.js ailleurs) comment colorer le code. Sans elle, votre code s'affiche en pavé gris monospace. Le correctif consiste à ajouter l'étiquette : même ```text``` vaut mieux que rien parce qu'il signale « c'est volontaire, laisse-le brut s'il te plaît ».

Quand utiliser « Recommended » vs « Strict » ?

**Recommended** active les règles qui attrapent les vrais problèmes : liens cassés, étiquettes de langue manquantes, marqueurs de liste incohérents, sauts de titre, sans pinaillage. **Strict** impose en plus une **longueur de ligne de 80 colonnes**, **pas de titres dupliqués où que ce soit dans le fichier** et un seul H1 en haut. Utilisez **Recommended** pour les **README, billets de blog, wikis internes**, partout où la longueur de ligne n'a pas d'importance et où les titres peuvent se répéter. Utilisez **Strict** pour la **documentation technique, les livres, les specs RFC**, partout où le retour à la ligne est imposé et la structure doit être unique. **Custom rules** active tout ce que markdownlint connaît ; à choisir quand vous voulez voir chaque remarque de style possible.

Pourquoi certains guides de style se soucient-ils de la longueur de ligne ?

**Trois raisons**, pas évidentes tant qu'on n'a pas vécu avec. **Un** : une ligne longue **diffuse mal** dans git ; changez un mot et tout le paragraphe apparaît modifié, au lieu d'une seule ligne. **Deux** : les terminaux et éditeurs côte à côte font typiquement **80 colonnes de large** ; le wrap dans l'éditeur déplace le saut visuel quand on redimensionne, ce qui distrait. **Trois** : beaucoup de **sorties imprimées** (générateurs PDF, man pages) wrap dur à 80 ; mieux vaut wrap sur une fin de phrase qu'en plein mot. Les sites de doc modernes avec wrap auto et coloration de prose s'en moquent, c'est pourquoi **Recommended désactive cette règle**.

Quelle différence entre -, * et + pour les puces ?

**Aucune sémantique** : tous les renderers Markdown les traitent à l'identique. La règle **MD004 (ul-style)** dit juste : **choisissez-en un et tenez-vous-y dans le fichier**. Les marqueurs mélangés sont déroutants dans un long fichier parce que l'œil lit un changement de marqueur comme « une nouvelle section démarre ici ». La convention par défaut dans la plupart des projets est le **`-` (tiret)** parce qu'il est sur tous les claviers et que la plupart des guides de style (Prettier, Airbnb, doc Vercel) le standardisent. **`*` (astérisque)** est le défaut historique de Markdown ; **`+` (plus)** est rare et mieux à éviter.

Titres ATX vs Setext, quelle différence ?

Deux façons d'écrire des titres en Markdown. **Style ATX** : `# Heading` (signes dièses avant le texte). **Style Setext** : `Heading\n=======` (soulignement à la ligne suivante). MD003 (heading-style) garantit que votre fichier utilise **un style cohérent partout**. **Presque tous les projets modernes utilisent ATX** parce que (1) ça marche pour les **six niveaux**, alors que Setext ne marche que pour H1 et H2 ; (2) c'est **plus facile à grep** que la forme avec soulignement ; (3) les éditeurs le complètent automatiquement. **Setext** est correct mais surtout vu dans les vieilles man pages et configs emacs. Choisissez ATX sauf bonne raison contraire.

Quelles erreurs sont « auto-corrigeables » et lesquelles non ?

**Auto-corrigeables** (badge clé verte) : ce que le linter peut réécrire sans deviner, comme les espaces de fin, les tabulations dures, le saut de ligne final manquant, plusieurs lignes vides ramenées à une, la normalisation du marqueur de liste, du style de titres, des espaces d'un titre ATX. **Non auto-corrigeables** : tout ce qui demande votre jugement, comme ajouter une **étiquette de langue** à un bloc de code (seul vous savez si c'est bash, shell ou sh), corriger un **niveau de titre sauté** (lequel changer ?), ajouter un **texte alt à une image**. L'outil les signale et vous les corrigez à la main.

Comment faire tourner les mêmes règles en CI ou dans un pre-commit hook ?

Le moteur exact se trouve sur **npm** sous le nom `markdownlint-cli` (ou son cousin plus rapide `markdownlint-cli2`). Installez-le avec `npm i -D markdownlint-cli2`, mettez un `.markdownlint.json` à la racine de votre repo avec les règles que vous avez choisies ici, puis lancez `markdownlint-cli2 "**/*.md"` en CI. Pour le **pre-commit**, déposez la même commande dans un hook [[husky||outil Node.js populaire qui installe les hooks git via package.json]] ou dans une config `pre-commit` : chaque commit est linté, chaque PR affiche une croix rouge quand quelqu'un glisse. Les codes de règle de cet outil correspondent exactement, donc ce qui passe ici passera en CI.

Linter Markdown - gratuit

Un linter pour votre Markdown, avec des explications lisibles

Markdown a l'air simple jusqu'au moment où votre README, votre site de documentation ou votre billet de blog commence à paraître incohérent : marqueurs de listes mélangés (style de puces), espaces de fin de ligne, niveaux de titres qui sautent une marche (niveaux de titres), blocs de code fences sans étiquette de langue. Un renderer affichera quand même la page, mais le résultat est négligé et le bruit dans les diffs est énorme.

Cet outil fait tourner le même moteur que la CLI `markdownlint` (markdownlint) sur votre texte. Vous obtenez une liste numérotée d'erreurs, chacune avec son code de règle (`MD009`, `MD040`, ...), une description en une ligne, et là où c'est auto-corrigeable, un aperçu du correctif. Cliquez sur une ligne, la zone de texte défile jusqu'à elle.

Quatre presets couvrent les choix courants : Recommended (le défaut, raisonnable pour tout projet), GitHub (compatible GFM), Strict (lignes à 80 colonnes plus pas de titres dupliqués), Custom rules (tout activé). Activez Fix mode pour voir le texte nettoyé et le copier en un clic.

Mode d'emploi

Collez votre Markdown dans la grande zone de texte à gauche. Un petit exemple avec des erreurs volontaires est chargé par défaut pour que l'outil ait tout de suite quelque chose à montrer.
Choisissez un preset en haut : Recommended pour presque tous les projets, GitHub quand votre fichier va sur GitHub ou GitLab, Strict pour la doc technique qui veut toutes les règles plus les lignes à 80 colonnes, Custom rules pour activer toutes les vérifications disponibles.
Cliquez sur « Run lint ». Le panneau de droite se remplit d'une liste numérotée d'erreurs. Chacune affiche le code de règle (par exemple `MD040`), une courte description, l'extrait concerné et un badge « auto-fix » si markdownlint peut la corriger pour vous.
Cliquez sur n'importe quelle ligne d'erreur pour sauter à cette ligne dans la zone de texte. La ligne est sélectionnée pour pouvoir l'éditer directement. Utile pour traiter des dizaines d'erreurs sans faire défiler manuellement.
Activez « Fix mode » pour voir la sortie nettoyée à la place de votre entrée brute. Toutes les erreurs auto-corrigeables sont appliquées. Les structurelles (style des titres, étiquettes de langue, erreurs de contenu) sont à corriger à la main.
Cliquez sur « Copier » pour récupérer soit votre entrée brute, soit la sortie nettoyée (selon Fix mode). C'est la chaîne à recoller dans votre README ou doc.
Lisez la FAQ ci-dessous si vous voulez savoir ce que signifie une règle précise ou quel preset correspond à la convention de votre équipe. Chaque code de règle pointe vers une explication courte en français clair.

Quand c'est utile

Six situations concrètes où un linter Markdown fait gagner un vrai temps :

Vérification finale d'un README avant push. Vous avez écrit 300 lignes, utilisé `-` pour les puces dans la première moitié et `*` dans la seconde, trois de vos blocs de code n'ont pas d'étiquette de langue : le syntax highlighter de GitHub les affiche en monochrome. Lint, fix, push.
Mise en route d'un site de doc (Astro, Hugo, Docusaurus, MkDocs). Le générateur enveloppe chaque page dans une mise en page. Un mauvais Markdown se traduit par des tableaux mal alignés, des ancres cassées et une hiérarchie de titres incohérente dans la sidebar. Linter avant d'ajouter les pages capture tout ça.
Revue de code d'une PR d'un collègue. Il a collé du Markdown depuis Notion, qui adore émettre des espaces de fin de ligne et des guillemets typographiques. Lint, collez la liste dans le commentaire de la PR, « voici 12 choses à corriger ».
Nettoyage d'un tutoriel avant publication sur Medium ou dev.to. Les deux plateformes ont leurs propres bizarreries Markdown. Faire tourner le preset strict en local d'abord élimine le jeu de devinettes du « qu'est-ce qui s'affiche où ».
Migration depuis une autre plateforme. Vous avez exporté des billets de WordPress, Ghost ou Substack en Markdown. Ils sont pleins de wrappers `<div>` HTML inline, d'URL brutes qui devraient être auto-linkées, et de titres qui démarrent en H2. Le linter les repère tous.
Mise en place d'un pre-commit hook en CI. Les mêmes règles utilisées ici partent dans un fichier de config de votre repo : vous obtenez une coche verte sur vos runs CI et un commentaire bienveillant sur chaque PR qui les enfreint.

Questions et réponses

Il lit votre Markdown et vérifie chaque ligne par rapport à une liste de règles, comme un correcteur orthographique pour la mise en forme. Il ne change pas le sens de votre texte, il se contente de signaler les endroits où le style est incohérent ou où un renderer produira probablement une sortie surprenante. Exemples de ce qu'il attrape : un titre sans espace après le `#` (`#Hello` au lieu de `# Hello`), des puces qui basculent entre `-` et `*` à mi-parcours, un bloc de code sans étiquette de langue, un saut de niveau de H2 directement à H4. Chaque erreur arrive avec un code de règle comme `MD009` à consulter si vous voulez la version longue.

Un linter pour votre Markdown, avec des explications lisibles

Mode d'emploi

Collez votre Markdown dans la grande zone de texte à gauche. Un petit exemple avec des erreurs volontaires est chargé par défaut pour que l'outil ait tout de suite quelque chose à montrer.

Choisissez un preset en haut : Recommended pour presque tous les projets, GitHub quand votre fichier va sur GitHub ou GitLab, Strict pour la doc technique qui veut toutes les règles plus les lignes à 80 colonnes, Custom rules pour activer toutes les vérifications disponibles.

Cliquez sur « Run lint ». Le panneau de droite se remplit d'une liste numérotée d'erreurs. Chacune affiche le code de règle (par exemple `MD040`), une courte description, l'extrait concerné et un badge « auto-fix » si markdownlint peut la corriger pour vous.

Cliquez sur n'importe quelle ligne d'erreur pour sauter à cette ligne dans la zone de texte. La ligne est sélectionnée pour pouvoir l'éditer directement. Utile pour traiter des dizaines d'erreurs sans faire défiler manuellement.

Activez « Fix mode » pour voir la sortie nettoyée à la place de votre entrée brute. Toutes les erreurs auto-corrigeables sont appliquées. Les structurelles (style des titres, étiquettes de langue, erreurs de contenu) sont à corriger à la main.

Cliquez sur « Copier » pour récupérer soit votre entrée brute, soit la sortie nettoyée (selon Fix mode). C'est la chaîne à recoller dans votre README ou doc.

Lisez la FAQ ci-dessous si vous voulez savoir ce que signifie une règle précise ou quel preset correspond à la convention de votre équipe. Chaque code de règle pointe vers une explication courte en français clair.

Quand c'est utile

Six situations concrètes où un linter Markdown fait gagner un vrai temps :

Vérification finale d'un README avant push. Vous avez écrit 300 lignes, utilisé `-` pour les puces dans la première moitié et `*` dans la seconde, trois de vos blocs de code n'ont pas d'étiquette de langue : le syntax highlighter de GitHub les affiche en monochrome. Lint, fix, push.
Mise en route d'un site de doc (Astro, Hugo, Docusaurus, MkDocs). Le générateur enveloppe chaque page dans une mise en page. Un mauvais Markdown se traduit par des tableaux mal alignés, des ancres cassées et une hiérarchie de titres incohérente dans la sidebar. Linter avant d'ajouter les pages capture tout ça.
Revue de code d'une PR d'un collègue. Il a collé du Markdown depuis Notion, qui adore émettre des espaces de fin de ligne et des guillemets typographiques. Lint, collez la liste dans le commentaire de la PR, « voici 12 choses à corriger ».
Nettoyage d'un tutoriel avant publication sur Medium ou dev.to. Les deux plateformes ont leurs propres bizarreries Markdown. Faire tourner le preset strict en local d'abord élimine le jeu de devinettes du « qu'est-ce qui s'affiche où ».
Migration depuis une autre plateforme. Vous avez exporté des billets de WordPress, Ghost ou Substack en Markdown. Ils sont pleins de wrappers `<div>` HTML inline, d'URL brutes qui devraient être auto-linkées, et de titres qui démarrent en H2. Le linter les repère tous.
Mise en place d'un pre-commit hook en CI. Les mêmes règles utilisées ici partent dans un fichier de config de votre repo : vous obtenez une coche verte sur vos runs CI et un commentaire bienveillant sur chaque PR qui les enfreint.

Questions et réponses

Linter Markdown

Un linter pour votre Markdown, avec des explications lisibles

Mode d'emploi

Quand c'est utile

Questions et réponses

Outils similaires

Convertisseur HTML ↔ Markdown

DOCX vers Markdown

Testeur regex

Formateur JSON

Linter Markdown

Un linter pour votre Markdown, avec des explications lisibles

Mode d'emploi

Quand c'est utile

Questions et réponses

Outils similaires

Convertisseur HTML ↔ Markdown

DOCX vers Markdown

Testeur regex

Formateur JSON