[koma] Indentation de la table des matières

Bonjour.

J’utilise la classe koma scrartcl. Mes sections sont non numérotées, via l’instruction \setcounter{secnumdepth}{0}. J’aimerais indenter les sous-sous-sections de ma table des matières. Voici un ECM :

\documentclass[12pt, a4paper, french, BCOR = 0pt, DIV =16, parskip=half,
%draft
]{scrartcl}
\usepackage[sfdefault]{plex-sans}
\usepackage{lipsum}
\usepackage{xcolor}
\usepackage{hyperref}
\hypersetup{
  colorlinks,
  linkcolor={red!20!black},
  citecolor={blue!30!black},
  urlcolor={blue!80!black}
}
\renewcommand{\familydefault}{\sfdefault}
\setcounter{secnumdepth}{0}
\setcounter{tocdepth}{\subsubsectiontocdepth}
\RedeclareSectionCommand[tocindent=30pt]{subsubsection}
\usepackage{babel}
\begin{document}
\tableofcontents
\section{Australie}
\subsection{Queensland}
\subsubsection{Brisbane}
\lipsum[1]
\subsubsection{Gold Coast}
\lipsum[2]
\subsection{Tasmanie}
\subsubsection{Hobart}
\lipsum[3]
\subsubsection{Launceston}
\lipsum[4]
\section{Brésil}
\subsection{Acre}
\subsubsection{Rio Branco}
\lipsum[5]
\subsubsection{Sena Madureira}
\lipsum[6]
\subsection{Rio Grande do Sul}
\subsubsection{Porto Alegre}
\lipsum[7]
\subsubsection{Bento Gonçalves}
\lipsum[8]
\end{document}

Par exemple, sur l’illustration suivante (qui correspond à l’ECM), j’aimerais que « Brisbane » et « Gold Coast » soit indentées, de manière à ce que le lecteur visualise leur appartenance au Queensland.

Suivant la doc de koma-script, j’ai rajouté l’instruction \RedeclareSectionCommand[tocindent=30pt]{subsubsection} mais ça n’a pas fonctionné. Comment obtenir le résultat désiré ?

Je reste avec ce problème, je n’avance pas. Si quelqu’un peut m’éclairer…

Je remplacerais \RedeclareSectionCommand[tocindent=30pt]{subsubsection} par

\usepackage{tocbasic}
\DeclareTOCStyleEntry[indent=1em]{default}{subsection}
\DeclareTOCStyleEntry[indent=2em]{default}{subsubsection}

Bonjour, avec TeX Live 2026 à jour, je ne constate pas le bug rapporté. Vous employez TeX Live ou MikTeX ?

Avec le code tel que publié, j’obtiens :

En commentant la ligne 17 (\RedeclareSectionCommand[tocindent=30pt]{subsubsection}) j’obtiens un décalage plus important (celui par défaut) :

Le soucis n’est manifestement pas au niveau de votre code, mais soit une vieille TeX Live, soit un bug avec MikTeX.

This is pdfTeX, Version 3.141592653-2.6-1.40.29 (TeX Live 2026)

et :

Document Class: scrartcl 2026/02/02 v3.49.2 KOMA-Script document class (article)

C’est effarant : avec pdflatex ça indente, mais avec lualatex non !

This is pdfTeX, Version 3.141592653-2.6-1.40.29 (TeX Live 2026) (preloaded format=pdflatex 2026.9.12)  21 SEP 2026 19:44
[...]
Document Class: scrartcl 2026/02/02 v3.49.2 KOMA-Script document class (article)

… mais :

This is LuaHBTeX, Version 1.24.0 (TeX Live 2026)  (format=lualatex 2026.9.12)  21 SEP 2026 19:48

Pourquoi ?

[EDIT] J’observe le même comportement avec la solution de Daniel Flipo ci-dessus : avec pdflatex ça indente, mais avec lualatex non.

Si on commente la ligne \usepackage{babel} (sachant que l’option french est chargée dans les options de la classe de document, mais c’est pas grave, ça sera simplement ignoré), l’indentation souhaitée est présente.

Ce qui oriente vers un problème relatif à babel-french, je suppose.

Par curiosité j’ai chargé TeX Live 2025, et dans ce cas, même avec babel-french on a l’indentation.

En rajoutant \listfiles dans le préambule, le fichier .log m’indique dans ce cas :

   babel.sty    2025/02/14 v25.4 The multilingual framework for pdfLaTeX, LuaLaTeX and XeLaTeX
  french.ldf    2024-07-25 v3.6c French support from the babel system
babel-french.tex

Revenant à TeX Live 2026, qui pose ce problème d’indentation, je remarque un warning dans le .log, que voici :

Package french.ldf Warning: You are relying on the legacy list code.
(french.ldf)                There is nothing wrong with this, just be aware
(french.ldf)                that new lists templates are available and will
(french.ldf)                become the default sooner or later.
(french.ldf)                Adding \DocumentMetadata{ ... } before the
(french.ldf)                \documentclass{} command, enables the new
(french.ldf)                lists templates. Give them a try!
(french.ldf)                Reported on input line 15.

Il est question de liste, et peut-être que la composition de la table des matières repose techniquement sur une liste. Je l’ignore, mais ça me semble plausible, au moins partiellement.

Or par rapport à la version 3.6, la documentation de babel-french n’indique qu’un léger changement relatif à une langue (acadian) pour la version 3.7.

Par contre, la version 4 est un gros changement, tandis que la compilation en pdflatex repose sur une version désormais figée, antérieure à la version 4.0.

En restant sous TeX Live 2026 et avec une compilation LuaLaTeX, mais en revenant à la classe article, ce qui nécessite de commenter les lignes suivantes :

\setcounter{tocdepth}{\subsubsectiontocdepth}
\RedeclareSectionCommand[tocindent=30pt]{subsubsection}

l’indentation est bien présente dans la table des matières.

Or, alors que la compilation du code d’origine en LuaLaTeX avec une version récente de babel-french génère un warning qui parle de liste et de \DocumentMetadata{ ... } qu’il faudrait ajouter, la documentation de la version 4.1 de babel-french indique que pour le moment \DocumentMetadata{ ... } est incompatible avec koma-script :

Ni les classes koma-script, ni la classe memoir ne sont, pour le moment (mai 2026), compatibles. Il convient de se passer de la commande \DocumentMetadata{…} si on veut les utiliser actuellement.

Peut-être que le bug n’est pas lié à ça, je n’en sais rien, mais il semble au moins y avoir une fragilité actuelle avec koma-script.

Certaines personnes apprécient koma-script, pour ma part je n’ai jamais compris comment son auteur peut produire une documentation avec du texte qui va à 5 millimètres du bord des pages, ce qui fait que je ne m’y suis jamais vraiment intéressé (c’est dommage, mais je trouve que son choix de design pour sa documentation ne fait pas très sérieux ; peut-être que je passe à côté d’un truc, et qu’en fait ce design est génial, je ne suis pas fermé à cette possibilité).

Peut-être ne suis-je pas le seul à ne pas employer koma-script, ce qui au final fait que le bug dont il est question ici a mis du temps à émerger, s’il y a bien un lien fort avec koma-script.

Bref pour résumer, l’épicentre du bug semble être autour de la version 4.0 (ou supérieur) de babel-french (ce qui immunise la compilation avec pdflatex), peut-être le tagging des PDF et la classe koma-script.

Il est probable que Daniel, qui est déjà intervenu, y verra plus clair.

Je ne réponds que sur koma-script, car le reste de vos remarques dépasse largement mes compétences.

L’empagement de la documentation de koma-script m’a également surpris, et cassé les pieds. Mais j’ai fini par comprendre qu’il n’est destiné qu’à une lecture sur écran, avec deux pages en vis-à-vis : si on affiche ainsi cette documentation, elle devient moins pénible à lire.

Et le package fonctionne très bien, je trouve les options assez intuitives, simples à mettre en œuvre.

Ok, mais le format PDF est sensé reproduire de façon électronique au plus près le format papier. Sinon, il fallait produire la documentation au format HTML…

Même un livre au format EPUB est affiché avec un minimum de marges (ici sur une tablette tactile), et pour comparaison, j’illustre avec le choix de l’auteur de koma-script :

Mais je ne suis pas convaincu par l’argument des deux pages en vis-à-vis, cela reste très pénible à lire (voir ci-dessous). Surtout qu’on nous explique par ailleurs que les lignes de texte ne doivent pas comporter plus de 60 à 75 caractères par ligne afin de faciliter la lecture… La première ligne du texte présenté ci-dessous comporte 91 caractères.

Et le package fonctionne très bien, je trouve les options assez intuitives, simples à mettre en œuvre.

Je ne mets pas cela en doute, bien que le package ne repose que sur un seul auteur, ce qui est une fragilité, surtout pour une classe de documents, je pense. C’est un peu dommage de placer une sorte de barrière à l’entrée de la découverte de ce package par ce design pas très consensuel.

Maintenant la question est : le bug rapporté sur ce sujet peut-il être facilement corrigé et si oui, comment ?

Bon, l’analyse de @quark_67 est tout à fait pertinente, c’est bien babel-french, à partir de la version 4.0 (applicable uniquement à lualatex) qui est fautive, plus précisément la nouvelle option TocPartNameFull. Il suffit d’ajouter \frenchsetup{TocPartNameFull=false} pour supprimer le problème.

Je vais revoir ça pour la prochaine version 4.1b en préparation, elle ne sortira qu’après LaTeX 2026-11-01 (donc en novembre probablement) car j’ai besoin des derniers développement des « templates » pour l’instant uniquement disponibles dans lualatex-dev.

1 « J'aime »