Échelles typographiques mobile vs bureau
Un h1 de 51px mérite sa taille sur une page de bureau : il ancre la mise en page, établit la hiérarchie d’un coup d’œil et laisse malgré tout le premier paragraphe dans le champ de vision. Envoyez le même titre sur un téléphone de 375px de large et il cesse d’ancrer pour se mettre à dévorer — quatre mots s’enroulent sur trois lignes, le paragraphe d’ouverture passe sous la ligne de flottaison, et le lecteur se heurte à un mur de typographie d’affichage avant le moindre contenu réel.
Une échelle typographique responsive résout cela en aplatissant le haut, non en rétrécissant tout : le texte courant reste à 16px sur chaque écran, et le ratio baisse sur les petits — par exemple de 1,333 sur bureau à 1,2 sur mobile, ce qui ramène ce h1 de 51px à environ 33px sans que le texte courant ne bouge d’un pixel. Les deux échelles partagent une même base, un même jeu de paliers et un même jeu de noms de rôles ; seul le ratio diffère.
Cet article traite spécifiquement de la décision mobile vs bureau ; pour comprendre d’abord comment fonctionnent les échelles et les ratios, commencez par notre guide des échelles typographiques.
Pourquoi l’échelle de bureau ne peut-elle pas simplement rétrécir ?
Parce que le bas de l’échelle est fixé. Pour ramener un h1 de 51px à 33px par un redimensionnement uniforme, il faudrait tout multiplier par environ 0,65 — ce qui fait passer le texte courant de 16px à environ 10px. Or le texte courant est la seule taille qui n’a aucune marge de manœuvre sur mobile, pour deux raisons :
- Lisibilité. Le texte sur téléphone se lit à bout de bras, souvent en mouvement et en plein jour. 16px est un plancher largement adopté pour une lecture prolongée sur mobile ; en dessous, les tailles de police sur mobile poussent bien des lecteurs à zoomer par pincement.
- Un piège pratique qui mérite d’être connu. Safari sur iOS zoome sur toute la page lorsque l’utilisateur active un champ de formulaire dont la taille de police est inférieure à 16px. Une longue série de rapports de bugs du type « pourquoi ma page saute-t-elle quand je tape sur le champ e-mail » relève exactement de ce comportement ; garder les champs de saisie à 16px l’évite complètement.
La contrainte est donc asymétrique : le haut de l’échelle a de la marge pour bouger, le bas n’en a pas. Voilà pourquoi l’ajustement mobile est un aplatissement.
Il y a aussi une raison perceptuelle pour laquelle l’aplatissement fonctionne, au lieu de simplement faire tenir les choses : la hiérarchie se juge par rapport à son cadre, pas en pixels absolus. Sur une toile de 1440px de large, un h1 doit dominer son entourage pour l’organiser ; sur une toile de 375px, il rivalise avec bien moins, et environ deux fois la taille du texte courant se lit avec une autorité comparable à trois fois cette taille sur bureau. Une échelle typographique mobile est plus plate, pas plus petite — la même hiérarchie perçue, redérivée pour un cadre plus réduit.
Qu’est-ce qui change sur mobile — la base ou le ratio ?
Gardez la base, abaissez le ratio. La base reste à 16px car c’est le point fixé ; le ratio passe de 1,333 à quelque chose comme 1,2. Chaque rôle conserve son numéro de palier, et chaque palier se recalcule.
Une manœuvre équivalente consiste à garder un seul ratio et à plafonner les niveaux de titre à des paliers inférieurs : le h1 mobile utilise le palier 3 (38px) au lieu du palier 4 (51px), et chaque niveau en dessous suit le mouvement. Cela réutilise les tailles de bureau au lieu d’en calculer de nouvelles, ce que certaines équipes préfèrent pour un inventaire de tailles plus réduit — mais attention au plancher : décalez six rôles d’un palier vers le bas sur une échelle de cinq paliers et le titre le plus bas atterrit sur la taille du texte courant, si bien que le plafonnement s’accompagne généralement d’une fusion des rôles de titre les plus bas. Les deux approches aplatissent le haut ; l’exemple travaillé ci-dessous utilise la baisse du ratio, qui garde les six rôles distincts.
À quoi ressemblent les six mêmes rôles aux deux ratios ?
Base 16px dans les deux colonnes, tailles arrondies au pixel entier :
| Rôle | Palier | Bureau (ratio 1,333) | Mobile (ratio 1,2) |
|---|---|---|---|
| caption | −1 | 12px | 13px |
| body | 0 | 16px | 16px |
| lead / h4 | 1 | 21px | 19px |
| h3 | 2 | 28px | 23px |
| h2 | 3 | 38px | 28px |
| h1 | 4 | 51px | 33px |
Deux détails méritent un second regard. L’amplitude se comprime de 3,2× la taille du texte courant (51/16) à environ 2,1× (33/16) — la hiérarchie conserve son ordre mais baisse la voix. Et la ligne caption remonte : 16 ÷ 1,2 vaut 13,3, si bien que le plus petit texte grossit légèrement sur le petit écran. L’aplatissement rapproche les deux extrémités de la base, ce qu’un téléphone recherche — une caption de 12px est plus difficile à défendre à bout de bras qu’une de 13px.
Ouvrez l’échelle mobile dans Scale Composer — base 16, ratio 1,2 — et faites glisser le ratio vers le haut jusqu’à 1,333 pour voir la hiérarchie de bureau réémerger palier par palier.

Comment basculer d’une échelle à l’autre à un point de rupture ?
Deux définitions d’échelle, un seul jeu de noms. Le nom de rôle est l’API stable ; la valeur derrière lui permute au point de rupture. En propriétés personnalisées CSS :
:root {
--text-h1: 2.07rem; /* ≈ 33px — échelle mobile, ratio 1.2 */
--text-h2: 1.73rem; /* ≈ 28px */
}
@media (min-width: 768px) {
:root {
--text-h1: 3.16rem; /* ≈ 51px — échelle bureau, ratio 1.333 */
--text-h2: 2.37rem; /* ≈ 38px */
}
}
Les éléments référencent var(--text-h1) et ne savent jamais quelle échelle est
active — les composants ne changent pas, c’est la media query qui opère la
bascule. Le fonctionnement de @media est documenté sur MDN ;
la décision de conception restante, c’est où placer le point de rupture, et une
seule bascule quelque part dans la plage 600–900px est un point de départ
courant.
Ce sont les tokens qui rendent le dispositif à deux échelles propre plutôt
qu’astucieux. Le Scale Composer exporte chaque échelle sous forme de tokens
DTCG, de propriétés personnalisées CSS, d’un bloc @theme Tailwind v4, ou de
Figma Variables — les noms de rôles restent identiques d’un export à l’autre,
si bien que les définitions mobile et bureau ne diffèrent que par leurs valeurs.
Une bascule nette est-elle la seule option ?
Non — la typographie fluide est l’alternative en douceur : au lieu de deux échelles statiques et d’un point de rupture, les tailles s’interpolent continûment avec la largeur de la fenêtre d’affichage, si bien que le h1 passe de 33px à 51px progressivement plutôt que par sauts. Les compromis sont réellement différents — des transitions plus douces, mais il n’y a plus de réponse unique à « quelle taille fait le h1 ? » — et ce site traite la typographie fluide face aux points de rupture séparément. Pour un premier système, deux échelles statiques sont le point de départ le plus simple : plus faciles à raisonner, à tester et à transmettre à une équipe.
Trouvez votre propre ratio mobile
Les chiffres ci-dessus sont un point de départ, pas une loi — un produit à forte densité de texte pourrait aplatir moins (disons 1,25), un site éditorial davantage. Pour trouver votre valeur, observez l’effondrement se produire : faites glisser le ratio vers le bas de 1,333 vers 1,2 et repérez le moment où chaque titre cesse de se battre contre l’écran sans avoir encore cessé de l’ordonner, tandis que le texte courant reste planté à 16px sur tout le trajet. Partez de la version bureau des six mêmes rôles dans le Scale Composer.