Générateur de Table des Matières Markdown

Générez une table des matières depuis n'importe quel document Markdown. Styles de slug GitHub, GitLab, CommonMark, niveaux, puces et indentation configurables. Insertion propre dans la source.

Source Markdown

Clear

Paste

Open file

TOC Générée

Options

Niveau Minimum

Niveau Maximum

Style de Puce

Taille Indent

Style d'Anchor

Encadrer avec un heading

Ignorer les blocs de code

Retirer bold/italic/code dans les étiquettes TOC

Aperçu

Vous avez des commentaires ? Signalez des bugs, suggérez des fonctionnalités ou partagez vos idées — nous lisons tout

Générateur de Table des Matières Markdown

Analyse n'importe quel document Markdown et émet une Table des Matières navigable — formatée exactement comme l'attendent GitHub, GitLab ou votre générateur de site statique. Configurez les niveaux à inclure, le style de puce, l'indentation et la façon dont les slugs d'anchor sont générés. La sortie est du Markdown brut à coller en tête de votre README, ou à laisser l'outil l'injecter à la place d'un placeholder [TOC] / . Tout le traitement se fait dans votre navigateur ; le document ne quitte jamais l'appareil.

Qu'est-ce qu'une Table des Matières Markdown et où l'utiliser ?

Une TOC Markdown est une liste de liens qui pointent vers les headings du même document. Quand le document est rendu sur GitHub, GitLab, GitBook, MkDocs, Docusaurus, Jekyll, Hugo, Notion, Obsidian ou tout autre visualiseur Markdown qui ajoute des anchors aux headings, la TOC devient une carte navigable de la page.

Les lecteurs survolent la TOC pour trouver ce qu'ils cherchent sans scroller. Les mainteneurs s'en servent comme outil de revue structurelle — un coup d'œil révèle si la hiérarchie est cohérente.

Endroits courants où intégrer une TOC :

- Tête d'un long README.md, juste après la description du projet.
- Au-dessus de la section API dans la documentation technique.
- Dans un ADR (architecture decision record) avec beaucoup d'alternatives.
- Dans des comptes rendus de réunion ou design docs à multiples sections.

Comment le parser détecte-t-il les headings ?

Le parser gère les deux styles de heading supportés par Markdown :

1. ATX : 1 à 6 # en début de ligne, espace, texte du heading. Les # de fin optionnels sont retirés.

# Titre H1
## Section H2
### Sous-section H3

2. Setext : le texte sur une ligne, puis une ligne de = (H1) ou - (H2) en dessous. Le style setext est plus ancien et moins courant, mais valide.

Quand 'Ignorer les blocs de code' est activé (par défaut), le parser suit les blocs entourés de ``` ou ~~~ et les blocs indentés de 4 espaces, et ignore les lignes ressemblant à des headings à l'intérieur. Cela empêche 'comme du code Python : # comment' d'être pris pour un heading.

Un # sans espace après (`#hashtag`) n'est pas un heading, selon CommonMark. Les headings indentés de plus de 3 espaces ne sont pas reconnus non plus comme ATX — ils sont du texte de paragraphe.

Différence entre les styles de slug ?

Différents rendus Markdown convertissent le texte du heading en ID d'anchor légèrement différemment. Choisissez le style adapté à la cible :

- GitHub : minuscules, espaces → tirets, ponctuation supprimée, lettres Unicode conservées. 'Introduction!' → introduction ; 'API V2.0' → api-v20. Standard de facto sur GitHub, gists, GitLab, vue Markdown de Notion et de nombreux générateurs statiques (Eleventy, Astro).

- GitLab : similaire à GitHub mais autorise les underscores. 'two_words and three' → two_words-and-three.

- CommonMark / Pandoc : ASCII strict, retire chiffres et ponctuation en tête. '1. Background' → background. À utiliser pour Pandoc ou rendus CommonMark stricts.

- Texte simple (sans liens) : émet juste le texte sans anchor. Utile quand la cible ne supporte pas du tout les anchors (certaines apps de chat, email en texte brut).

Comment la dé-duplication d'anchors fonctionne ?

Quand deux headings ont le même texte, les slugs entreraient en collision et seul le premier lien marcherait. L'outil suit chaque slug émis dans la TOC courante et ajoute `-1`, `-2`, etc. aux doublons :

## Exemples
### Setup → setup
## Autre sujet
### Setup → setup-1
### Setup → setup-2

Cela correspond au comportement réel de GitHub pour les headings répétés. GitLab utilise le même schéma. Pandoc supprime le doublon sauf si vous activez le même suffixe via `pandoc --slugify`.

Si vous modifiez la source et régénérez, les suffixes sont assignés à nouveau selon le nouvel ordre du document. Enregistrez le fichier avec la TOC insérée pour avoir des URLs stables entre les exécutions.

Pourquoi l'outil saute parfois le H1 ?

Le Niveau Minimum par défaut est H2. C'est la convention la plus courante : le premier H1 est le titre du document lui-même, et la TOC décrit les sections à l'intérieur.

Vous répéteriez le titre en incluant H1, donc la plupart des projets démarrent la TOC à H2.

Si votre document utilise H1 pour les sections (pas de titre global), réglez le Niveau Minimum sur H1.

Le Niveau Maximum contrôle la profondeur. H2–H3 donne une vue plate. H2–H4 ajoute le sous-niveau. H2–H6 donne la hiérarchie complète — utile pour les docs techniques longues mais peut devenir bruyant.

Que fait 'Insérer dans la source' ?

Trois comportements selon la source :

1. Si le document contient un placeholder [TOC], il le remplace. Convention Pandoc / Python-Markdown / WordPress.
2. Si un commentaire HTML  est présent, il le remplace. Convention doctoc / markdown-toc-cli.
3. Sinon, il insère la TOC juste après le premier H1 (ou en haut s'il n'y en a pas), séparée par des lignes blanches.

C'est une exécution manuelle — l'outil ne suit pas le document ni ne met à jour la TOC automatiquement quand vous modifiez les headings. Pour une maintenance automatisée, utilisez doctoc (paquet npm) ou un pre-commit hook qui exécute cette logique à la sauvegarde.

La TOC insérée est du Markdown brut — pas de wrapper HTML sauf si vous cochez 'Encadrer avec un heading', qui ajoute une ligne `## Table des Matières` au-dessus de la liste.

Fonctionne-t-il avec des headings non anglais ?

Oui. Les générateurs de slug préservent les lettres et chiffres Unicode — 'Câu hỏi thường gặp', 'Préférences', 'Configuración', '常见问题' produisent tous des slugs compatibles GitHub valides.

GitHub conserve les caractères Unicode dans le slug ; le fragment d'URL les contiendra encodés en octets %XX quand le lien est suivi. Les navigateurs gèrent cela de manière transparente.

Si vous passez en CommonMark, les règles sont plus strictes — les lettres Unicode hors [a-z0-9] sont retirées. Pour les documents multilingues sur GitHub, GitLab ou Notion, préférez GitHub ou GitLab.

Le texte bidirectionnel (arabe, hébreu) fonctionne pour le texte visible comme pour le slug. La TOC se lit de gauche à droite en source mais s'affiche correctement dans les navigateurs gérant le bidi.

Comparé à doctoc ou markdown-toc ?

doctoc et markdown-toc sont des CLI qui modifient vos fichiers Markdown en place. Parfaits pour les repos — lancez-les dans un pre-commit hook ou CI et vous avez des TOCs toujours à jour dans le contrôle de version.

Cette page est l'inverse : une version navigateur, sans installation, de la même fonctionnalité. Compromis :

- Usage ponctuel rapide, pas d'installation Node/npm, aucune permission.
- Plusieurs styles de slug dans une seule UI ; doctoc n'émet que le style GitHub.
- Le bouton 'Insérer dans la source' est une écriture unique dans la textarea — vous copiez/sauvez le fichier ensuite.
- Tout le traitement est local — le contenu n'est pas téléversé.
- Pour une maintenance continue de repo, doctoc ou markdown-toc restent la bonne réponse ; pour une génération manuelle occasionnelle, c'est plus rapide.

Le parser gère les blocs avec barrière, les headings setext et l'Unicode de manière comparable à ces CLI.