Styles d’impression pour une documentation qui ne vous embarrasse pas

À quoi ressemble une bonne impression (et ce qu’elle refuse de faire)

Le rendu imprimé est le critique le plus sévère que vous rencontrerez. Il supprime l’interactivité, réduit votre canevas à des dimensions fixes et pénalise tout ce qui dépend des états au survol, du positionnement fixe ou du « l’utilisateur fait juste défiler un peu ».
L’objectif n’est pas de faire ressembler le papier à votre site web. L’objectif est de faire en sorte que le papier se comporte comme du papier : prévisible, scannable, lisible et sans débris d’interface.

Une feuille de style d’impression réussie fait bien quatre choses :

• Réduit le bruit : masque la navigation, les champs de recherche, les « articles connexes » et tout ce qui sent les métriques d’engagement.
• Améliore la lisibilité : tailles de police raisonnables, marges, interlignage et contraste adaptés.
• Respecte la structure : les titres ne pendent pas en bas d’une page ; le code n’est pas tronqué ; les tableaux ne partent pas en vrille.
• Préserve le sens : les liens affichent leur destination ; les figures ont des légendes ; le code s’enroule sans mentir.

Point de vue : si vos docs sont opérationnellement pertinentes (runbooks, guides d’incident, procédures de conformité), le rendu imprimé n’est pas un « bonus ». C’est une composante de votre stratégie de disponibilité.

Blague #1 : le CSS d’impression, c’est comme les sauvegardes — tout le monde jure en avoir jusqu’au moment où il faut restaurer.

Encore une chose : « adapté à l’impression » ne signifie pas « colonne unique avec du texte minuscule ». Vous pouvez utiliser l’espace blanc. Le papier ne facture pas au pixel.

Faits intéressants et contexte historique

Considérez ces points comme des contraintes, pas des curiosités. Ce sont les contraintes qui donnent naissance au bon ingénierie.

Principes de base : l’impression est un produit séparé

1) Partir du contenu, pas de la mise en page

Lors de l’impression, le contenu devient l’interface. Le « design system » doit en grande partie disparaître. Votre feuille de style d’impression doit être construite autour du HTML sémantique :
les titres sont des titres, les listes sont des listes, le code est du code, les tableaux sont des tableaux. Si votre site est un amas de div, l’impression vous le fera payer. Ce n’est pas personnel. C’est la physique.

2) Supprimer tout ce qui change d’état

En‑têtes collants, accordéons, onglets, info‑bulles au survol, bannières de cookies — ce sont des patterns d’interface à états. L’impression est sans état. Si votre document imprimé dépend d’un clic « Développer », vous avez livré un runbook qui nécessite de l’électricité et de l’optimisme.

3) Faire de l’artefact imprimé une entité autonome

Les pages imprimées perdent le contexte du domaine. Le lecteur peut ne pas connaître le nom du site, le titre de la page ou la date de dernière mise à jour. Incluez suffisamment de métadonnées dans la zone de contenu — titre, version optionnelle, et peut‑être un petit pied de page — mais ne reconstruisez pas tout l’en‑tête.

4) Optimiser pour deux publics : humains et audits

Les humains veulent du texte lisible, du code qui s’enroule et pas de pages gaspillées. Les audits veulent des artefacts stables. Si votre rendu imprimé change à chaque modification d’un lien de nav, vous créez du churn sans bénéfice.

Une idée utile paraphrasée de John Allspaw : la stabilité vient du design de systèmes qui supposent que des défaillances vont se produire, puis réduisent le rayon d’impact quand elles arrivent.

Mise en page lisible : typographie, marges et structure

Marges : choisissez des chiffres ennuyeux

Utilisez des marges @page en pouces ou millimètres et restez conservateur. Les imprimantes ont des zones non imprimables ; les PDFs n’en ont pas, mais les utilisateurs impriment des PDFs sur des imprimantes qui en ont.
Si votre contenu touche le bord, il sera rogné. Pas « peut‑être ». Ça arrivera.

À faire : @page { margin: 0.6in; }. À ne pas faire : margin: 0 en espérant que l’imprimante soit moderne et indulgente.

Taille des polices : l’impression n’est pas Retina

Pour le corps de texte, 10.5–12pt est généralement adapté. Pour de la documentation technique dense, 11pt est un bon défaut. Pour le code, 8.5–10pt selon la longueur des lignes. Dès que vous réduisez pour « faire tenir plus », vos lecteurs se mettent à survoler au lieu de lire.

Longueur des lignes : la tyrannie des 100 caractères

Les papiers et PDFs ne défilent pas. Gardez les paragraphes lisibles : évitez les lignes trop larges en utilisant des marges, pas des max‑width en pixels. En impression, une « largeur totale » est déjà contrainte. Laissez respirer.

Contraste : finissez avec le gris sur gris

Les styles d’impression doivent imposer un fort contraste. Beaucoup d’entreprises aiment le texte gris clair sur fond gris légèrement différent.
Puis quelqu’un l’imprime sur une imprimante bas de gamme, et votre encadré « note » devient un fantôme invisible. En impression, si c’est important, c’est en noir.

Titres : ne les laissez pas en suspens

Utilisez break-after: avoid (et le vieux fallback page-break-after: avoid) sur les titres. Protégez aussi le premier paragraphe après un titre en utilisant un conteneur, ou au moins évitez d’avoir un titre en dernière ligne d’une page sans contenu dessous.

Règle d’opinion : si un H2 s’imprime comme dernière ligne d’une page, votre feuille de style d’impression n’accomplit pas sa mission.

Masquer la navigation, le chrome et les déchets d’interface

Masquez par classe, pas par espoir

Vous avez besoin de sélecteurs explicites pour les éléments qui ne doivent pas s’imprimer. Créez une classe utilitaire comme .no-print et appliquez‑la à :
barres de navigation, pieds de page juridiques, barres latérales, boutons « modifier cette page », widgets de partage, sections de commentaires et bannières de cookies.

Privilégiez display: none en impression

Pour l’impression, display: none est votre ami. N’utilisez pas des astuces d’opacité. N’utilisez pas de positionnement hors écran. Certains moteurs d’impression calculent encore la mise en page pour des éléments masqués mais non supprimés, et vous aurez des zones blanches mystérieuses.

Les éléments fixes et collants mangent des pages

Un en‑tête fixe de 72px devient une taxe répétée sur chaque page imprimée si le navigateur décide de l’afficher sur chaque page. C’est comme transformer un runbook de 10 pages en 17 pages et faire pleurer votre imprimante de bureau.

Blague #2 : rien ne dit « entreprise » comme imprimer un guide de 40 pages où 12 pages sont juste l’en‑tête collant.

Liens, références et « réalité papier »

Rendez visibles les destinations des liens

Sur papier, « cliquez ici » est une performance artistique. Les styles d’impression doivent ajouter l’URL après les liens externes. Le pattern classique :
a[href^="http"]:after { content: " (" attr(href) ")"; }

Ne faites pas cela pour les liens internes d’ancrage ou les liens mailto sauf si vous voulez du bruit. Vous pouvez cibler sélectivement les protocoles externes.

Mais ne laissez pas les URLs détruire la mise en page

Certaines URLs sont longues, et certains systèmes génèrent des chaînes de requête héroïques. Il faut permettre l’habillage :
word-break: break-word et overflow-wrap: anywhere aident. Pour l’impression, l’objectif est « assez lisible pour retaper », pas « conserver la chaîne entière sur une ligne ».

Liens d’ancrage et tables des matières

Une table des matières à l’écran est utile ; une table imprimée est optionnelle. Si vous l’imprimez, assurez‑vous qu’elle ne vole pas la moitié de la première page. Si vos docs sont longues, une TOC courte peut aider — mais envisagez une « vue impression » qui réordonne le contenu plutôt que d’exporter la TOC du site telle quelle.

Blocs de code : habillage, débordement, fidélité au copier/coller

La dure vérité : le code n’aime pas le papier

Les sorties de terminal et les blocs de code sont faits pour défiler horizontalement. Le papier refuse. Vos choix sont :

• Enrouler les lignes et accepter que la fidélité du copier/coller ne soit pas l’objectif principal sur papier.
• Ne pas enrouler, mais alors vous devez vous assurer que le contenu n’est pas tronqué (souvent impossible).
• Fournir une variante adaptée à l’impression (recommandé) : enrouler par défaut, mais permettre aux lignes critiques d’être cassées manuellement avec des caractères de continuation ou des retours à la ligne explicites dans la source.

Enrouler les blocs pre en impression

Pour l’impression, utilisez white-space: pre-wrap sur pre et code. Ajoutez word-break: break-word. Cela évite le rognage et les caractères manquants.

N’utilisez pas white-space: normal pour le code. Cela écrase les espacements et corrompt les exemples. Vous voulez de l’enroulement, pas une re‑tokénisation.

Préserver les invites et repères

Si vos docs incluent des commandes, conservez les invites cohérentes. À l’impression, les invites aident les humains à distinguer ce qui est saisi de ce qui est sortie.
Mais ne transformez pas les invites en badges d’arrière‑plan énormes qui ne s’imprimeront pas.

Couleur et coloration syntaxique

Beaucoup de pipelines d’impression suppriment les arrière‑plans. La coloration syntaxique peut aussi perdre du contraste. En impression, préférez la simplicité :
texte noir, bord léger, peut‑être un fond gris clair si vous pouvez tolérer sa disparition.
Le code doit rester lisible sans couleur.

N’autorisez pas la coupure d’une ligne de code si possible

Utilisez break-inside: avoid sur pre. Ce n’est pas parfait sur tous les moteurs, mais réduit les pires cas.
Pour de longues sorties, la division est inévitable — assurez‑vous que vos commandes montrent le contexte et des points de reprise.

Tableaux, diagrammes et images sans larmes

Tableaux : soit adapter, soit repenser

Les tableaux larges sont la source numéro un des horreurs d’impression. Si votre tableau est plus large qu’une page, vous avez trois options :

• Rendre le tableau plus étroit en repensant le contenu (meilleure solution sur le long terme).
• Autoriser le tableau à envelopper les cellules de façon agressive (parfois acceptable pour du prose, catastrophique pour des identifiants).
• Imprimer le tableau en paysage (difficile dans l’impression navigateur ; possible avec une génération PDF dédiée).

Ne tentez pas de « réduire l’échelle » de toute la page pour faire tenir le tableau. Cela produit du texte minuscule et des humains en colère.

Images : supprimer les décoratives, garder les informatives

Les images décoratives ne devraient pas s’imprimer. Les images informatives doivent s’imprimer avec une résolution suffisante pour rester lisibles. Définissez :
img { max-width: 100%; height: auto; }

Si vous comptez sur des diagrammes codés par couleur, ajoutez des étiquettes. Les imprimantes ne sont pas tenues de reproduire votre palette de marque. Elles reproduisent souvent « le gris que ça donne aujourd’hui ».

SVG et filtres

Les filtres SVG complexes peuvent déclencher la rasterisation. Dans ce cas, le texte devient flou et non sélectionnable dans le PDF.
Si vos docs intègrent des diagrammes SVG avec flou/ombres, envisagez un SVG de secours pour le mode impression sans filtres.

Sauts de page, veuves, orphelines et éviter les coupures gênantes

Utilisez les propriétés modernes, gardez les anciens fallbacks

Préférez break-before, break-after et break-inside. Ajoutez les anciens page-break-* pour la compatibilité.
Les navigateurs varient, mais ces propriétés sont votre meilleure chance de contrôler la pagination.

Protégez les titres, les courtes listes et les définitions

Un titre en bas de page est un échec classique. Comme une liste de deux éléments séparée sur deux pages. Appliquez :

• h2, h3 { break-after: avoid; }
• pre, table, blockquote { break-inside: avoid; }
• li { break-inside: avoid; } (à utiliser avec prudence ; de longs listes forceront des espaces blancs gênants)

Orphelines et veuves : ça vaut encore le coup

orphans et widows ne sont pas parfaitement respectés partout, mais ils aident. Placez‑les sur les paragraphes et les éléments de liste.
Vous ne cherchez pas à composer un roman. Vous cherchez à éviter la « ligne isolée sur la page suivante ».

Impression en PDF dans les pipelines : reproductibilité et dérive

Dans de nombreuses organisations, « imprimer » signifie en réalité « générer un PDF pour distribution ». C’est acceptable — jusqu’à ce que ce soit utilisé dans un flux de conformité, un artefact de release, ou un pack de support.
Là, vous découvrez que votre sortie PDF change parce que le navigateur headless a été mis à jour, une police web n’a pas chargé, ou une règle CSS a été éliminée.

Épinglez votre moteur de rendu

Si vous générez des PDFs en CI, épinglez la version de Chromium (ou le tag du conteneur) et traitez‑la comme n’importe quelle dépendance.
Le « latest » non épinglé est la recette d’une reflow surprise la veille d’un audit.

Désactivez les dépendances instables

Les webfonts peuvent échouer. Les images distantes peuvent échouer. Les scripts externes peuvent échouer. Pour l’impression/PDF, utilisez des assets locaux ou inlinez le CSS critique.
L’artefact imprimé ne devrait pas dépendre de cinq CDN et d’un résolveur DNS qui ont une bonne journée.

Concevez pour une pagination déterministe

De petites différences de mise en page peuvent changer les sauts de page, et tout change (numéros de page référencés dans des SOP, par exemple).
Si vous avez besoin d’une pagination déterministe, envisagez de générer les PDFs depuis la source avec une chaîne d’outils paginée ou imposez un CSS stable et des polices épinglées.

Tâches pratiques : commandes, sorties, décisions

Le style d’impression échoue de deux façons : votre CSS est incorrect, ou votre pipeline vous ment sur ce qui est imprimé.
Voici des tâches réelles que j’utilise pour déboguer le rendu imprimé comme un SRE : vérifier les entrées, observer le comportement, et décider quoi changer.

Tâche 1 : Confirmer quel CSS est réellement déployé

cr0x@server:~$ curl -sS -D- https://docs.example.internal/article/runbook.html -o /tmp/runbook.html
HTTP/2 200
content-type: text/html; charset=utf-8
etag: "9b3b2e9a"
cache-control: max-age=300

Ce que signifie la sortie : Vous avez le HTML rendu et les en‑têtes de réponse. ETag et cache indiquent si vous voyez peut‑être du contenu obsolète.

Décision : Si le cache est agressif, purgez ou contournez‑le avant d’accuser le CSS.

Tâche 2 : Extraire les feuilles de style liées (vérification rapide)

cr0x@server:~$ grep -Eo 'href="[^"]+\.css[^"]*"' /tmp/runbook.html | head
href="/assets/site.css"
href="/assets/print.css"

Ce que signifie la sortie : La page inclut un CSS dédié à l’impression, pas seulement le CSS écran.

Décision : S’il n’y a pas de CSS d’impression, créez‑en un. S’il y en a un, récupérez‑le ensuite et vérifiez que c’est bien celui déployé.

Tâche 3 : Récupérer le CSS d’impression et vérifier qu’il contient des règles print

cr0x@server:~$ curl -sS https://docs.example.internal/assets/print.css | sed -n '1,80p'
@media print {
  .site-nav, .sidebar, .cookie-banner { display: none !important; }
  pre { white-space: pre-wrap; word-break: break-word; }
}

Ce que signifie la sortie : Il y a un bloc @media print et il fait le minimum.

Décision : Si les règles d’impression sont manquantes ou vides, vous dépendez du CSS écran. Arrêtez et corrigez cela d’abord.

Tâche 4 : Détecter un « display: none » accidentel sur le contenu principal

cr0x@server:~$ rg -n "display:\s*none" /tmp/runbook.html /tmp/print.css
/tmp/print.css:2:  .site-nav, .sidebar, .cookie-banner { display: none !important; }

Ce que signifie la sortie : Seule l’UI est masquée. Bien.

Décision : Si vous trouvez main, article ou votre wrapper de contenu caché, corrigez les sélecteurs (souvent une règle trop large comme div ou *).

Tâche 5 : Générer un PDF via Chromium headless pour reproduire les problèmes

cr0x@server:~$ chromium --headless --disable-gpu --print-to-pdf=/tmp/runbook.pdf https://docs.example.internal/article/runbook.html
[1229/102312.184556:INFO:headless_shell.cc(659)] Written to file /tmp/runbook.pdf.

Ce que signifie la sortie : Vous avez maintenant un artefact PDF reproductible depuis un moteur connu.

Décision : Si le PDF diffère de « Imprimer… » dans Chrome desktop, vous avez probablement une dérive d’environnement (polices, DPI, ou versions de Chromium différentes).

Tâche 6 : Vérifier si le PDF est du texte ou des images rasterisées

cr0x@server:~$ pdftotext /tmp/runbook.pdf - | head
Runbook: Storage Failover
Last updated: 2025-12-01

1. Preconditions
...

Ce que signifie la sortie : L’extraction de texte fonctionne ; le PDF est principalement du texte réel.

Décision : Si l’extraction ne donne rien ou du contenu corrompu, votre pipeline pourrait rasteriser. Réduisez les effets visuels et vérifiez les polices/SVG.

Tâche 7 : Inspecter les polices embarquées (le manque de polices provoque des reflows)

cr0x@server:~$ pdffonts /tmp/runbook.pdf | head
name                                 type              encoding         emb sub uni object ID
AAAAAA+Inter-Regular                  TrueType          WinAnsi          yes yes yes      12  0
AAAAAA+Inter-SemiBold                 TrueType          WinAnsi          yes yes yes      13  0

Ce que signifie la sortie : Les polices sont embarquées et subsetées. C’est bon pour la portabilité et la stabilité de la mise en page.

Décision : Si les polices ne sont pas embarquées, attendez‑vous à des dérives de mise en page selon les machines. Embarquez ou utilisez des polices système en mode impression.

Tâche 8 : Vérifier le nombre de pages et repérer les régressions de pages blanches

cr0x@server:~$ pdfinfo /tmp/runbook.pdf | egrep 'Pages|Page size'
Pages:           14
Page size:       612 x 792 pts (letter)

Ce que signifie la sortie : Vous avez 14 pages au format Letter. C’est une métrique de référence stable à suivre en CI.

Décision : Si le nombre de pages augmente soudainement (par ex. 14 → 19), suspectez des éléments fixes/collants, des sauts de page forcés ou un changement de police.

Tâche 9 : Valider que les longues lignes de code s’enroulent (et ne sont pas coupées)

cr0x@server:~$ pdftotext /tmp/runbook.pdf - | rg -n "cr0x@server:~\$" | head
42:cr0x@server:~$ zpool status -v pool0
77:cr0x@server:~$ journalctl -u nginx --since "1 hour ago"

Ce que signifie la sortie : Les commandes apparaissent dans le texte extrait, ce qui implique qu’elles n’ont pas été coupées à droite de la page.

Décision : Si le texte extrait manque pour des commandes longues, revoyez l’enroulement des pre et les marges.

Tâche 10 : Confirmer que le média print est appliqué (débogage via CSS)

cr0x@server:~$ node -e 'const fs=require("fs"); const css=fs.readFileSync("/tmp/print.css","utf8"); console.log(/@media\s+print/.test(css)?"has print media":"missing print media");'
has print media

Ce que signifie la sortie : Votre CSS contient des règles pour le média print.

Décision : Si c’est absent, votre bundler peut le supprimer. Corrigez la configuration du pipeline de build.

Tâche 11 : Identifier les éléments « dépendants des arrière‑plans » non imprimables

cr0x@server:~$ rg -n "background-color|color:\s*#(7|8|9|a|b|c|d|e|f){3,6}" /tmp/print.css | head
14:  .callout { border-left: 4px solid #333; background-color: #f6f6f6; }

Ce que signifie la sortie : Vous utilisez une couleur de fond pour les encadrés. C’est acceptable, mais ne la laissez pas porter le sens.

Décision : Ajoutez des bordures, des étiquettes ou de la typographie pour que le callout reste évident lorsque les fonds ne s’impriment pas.

Tâche 12 : Vérifier les sauts de page forcés qui créent des pages blanches

cr0x@server:~$ rg -n "page-break-before|page-break-after|break-before|break-after" /tmp/print.css
22:  h1 { break-before: page; }

Ce que signifie la sortie : Quelque chose force un saut de page avant h1. Cela peut créer une page blanche au début dans certains moteurs.

Décision : Supprimez‑le ou scindez‑le finement (par ex. seulement en mode « paquet d’impression »). Mesurez le nombre de pages à nouveau.

Tâche 13 : Vérifier que les éléments de nav/sidebar disparaissent vraiment dans le PDF imprimé

cr0x@server:~$ pdftotext /tmp/runbook.pdf - | rg -n "Search|Sign in|Subscribe|Cookie" | head

Ce que signifie la sortie : Aucune phrase d’UI évidente dans l’artefact imprimé.

Décision : Si du texte d’UI apparaît, vos sélecteurs ne correspondent pas au DOM en production. Ajoutez des classes stables (.site-nav, .cookie-banner) et évitez le CSS fragile comme nav > ul > li.

Tâche 14 : Confirmer que le même rendu fonctionne sur A4 et Letter (vérification dérive taille page)

cr0x@server:~$ chromium --headless --disable-gpu --print-to-pdf=/tmp/runbook-a4.pdf --virtual-time-budget=10000 --run-all-compositor-stages-before-draw https://docs.example.internal/article/runbook.html
[1229/102409.918211:INFO:headless_shell.cc(659)] Written to file /tmp/runbook-a4.pdf.

Ce que signifie la sortie : Vous avez un PDF supplémentaire pour comparer. (Le contrôle de taille de page de Chromium est limité ; beaucoup d’équipes utilisent des outils séparés pour A4/Letter.)

Décision : Si les différences A4 vs Letter provoquent du contenu rogné, augmentez les marges et arrêtez d’utiliser des largeurs fixes.

Tâche 15 : Détecter les régressions CSS en CI en épinglant un budget de nombre de pages

cr0x@server:~$ pdfinfo /tmp/runbook.pdf | awk -F': *' '/Pages/ {print $2}'
14

Ce que signifie la sortie : Un nombre unique que vous pouvez comparer entre builds.

Décision : Si le nombre de pages change de façon inattendue après un changement CSS, traitez‑le comme une régression et inspectez le diff, pas seulement le HTML.

Feuille de diagnostic rapide

Quand le rendu imprimé est incorrect, ne commencez pas par « bidouiller le CSS jusqu’à ce que ça ait l’air mieux ».
C’est ainsi que vous obtenez une feuille de style d’impression de mille lignes en laquelle personne n’a confiance.
Diagnostiquez comme un opérateur : vérifiez les quelques éléments qui cassent habituellement en premier.

Première étape : la feuille de style d’impression est‑elle appliquée ?

• Ouvrez l’aperçu avant impression et vérifiez que la nav/la sidebar disparaît.
• Si ce n’est pas le cas, votre @media print ne se charge pas, est supprimé, ou vos sélecteurs ne correspondent pas au DOM.

Deuxième : Combattez‑vous le positionnement fixe/collant ?

• Symptômes : en‑têtes répétés, espace blanc gaspillé, contenu repoussé vers le bas, explosion du nombre de pages.
• Correction : en impression, réglez les conteneurs fixed/sticky en position: static et cachez le chrome redondant.

Troisième : Les blocs de code sont‑ils coupés ou mal enroulés ?

• Symptômes : caractères manquants à droite, commandes tronquées, ou un bloc de code occupant cinq pages avec des mots cassés.
• Correction : pre { white-space: pre-wrap; word-break: break-word; } et assurez‑vous que les marges ne sont pas nulles.

Quatrième : Les liens sont‑ils utiles sur papier ?

• Symptômes : « cliquez ici » partout, références impossibles à suivre.
• Correction : ajoutez les URLs externes avec attr(href) ; évitez pour les ancres internes.

Cinquième : Les sauts de page sabotent‑ils la lisibilité ?

• Symptômes : titres seuls en bas de page ; tableaux coupés ; éléments de liste séparés de leurs puces.
• Correction : break-inside: avoid sur les blocs ; break-after: avoid sur les titres ; ajustez widows/orphans.

Astuce opérationnelle : capturez un PDF « connu‑bon » et différez‑le chaque fois que vous modifiez le CSS. Les humains sont mauvais pour repérer des reflows subtils dans l’aperçu d’impression.

Erreurs courantes (symptômes → cause → correction)

1) Symptôme : les pages imprimées incluent la nav, la recherche et la bannière de cookies

Cause : pas de feuille de style d’impression, ou les sélecteurs ciblent une ancienne structure DOM modifiée lors d’une refonte.

Correction : introduisez des classes stables (.site-nav, .cookie-banner, .sidebar) et cachez‑les dans @media print avec display: none !important.

2) Symptôme : grands espaces vides, surtout en haut de chaque page

Cause : en‑tête fixe/collant conservé à l’impression ; le navigateur le répète par page ou lui réserve de l’espace.

Correction : en impression, mettez le conteneur d’en‑tête en position: static !important ou cachez‑le entièrement. Déplacez les métadonnées essentielles dans le corps de l’article.

3) Symptôme : le code ou les tableaux sont coupés à droite

Cause : white-space: pre sans enroulement, plus marges insuffisantes ou largeurs fixes.

Correction : utilisez pre-wrap pour l’impression et supprimez les largeurs fixes. Augmentez légèrement les marges @page.

4) Symptôme : le code s’enroule mais devient illisible « salade de mots »

Cause : utilisation de white-space: normal ou d’une césure agressive qui casse les tokens.

Correction : conservez white-space: pre-wrap et préférez word-break: break-word. Évitez la césure pour les blocs de code.

5) Symptôme : le PDF contient du texte non sélectionnable, ou il est flou

Cause : rasterisation due à des effets CSS lourds, des filtres SVG complexes ou des particularités du moteur d’impression.

Correction : supprimez ombres/filtres en impression, simplifiez les SVG et vérifiez avec pdftotext que l’extraction de texte fonctionne.

6) Symptôme : titres orphelins, listes coupées de façon maladroite

Cause : absence de règles de pagination ; dépendre des valeurs par défaut du navigateur ; blocs de contenu non protégés contre les sauts.

Correction : appliquez break-after: avoid aux titres et break-inside: avoid aux blocs critiques. Utilisez widows/orphans comme garde‑fous.

7) Symptôme : « Imprimer en PDF » diffère de « Imprimer » sur desktop

Cause : versions de Chromium différentes, polices installées différentes, tailles de page par défaut différentes, ou assets manquants en headless.

Correction : épinglez les versions du moteur de rendu et embarquez les polices (ou utilisez des polices système). Générez les PDFs dans un conteneur contrôlé.

8) Symptôme : des diagrammes ou icônes manquent à l’impression

Cause : assets bloqués par CSP, restrictions cross‑origin en mode headless, ou réglage utilisateur « ne pas imprimer les arrière‑plans ».

Correction : ne transmettez pas d’information uniquement par des images de fond ; inlinez les SVG critiques ; assurez‑vous que les diagrammes sont de véritables <img> ou des <svg> inline.

Listes de contrôle / plan étape par étape

Étape par étape : construire une feuille de style d’impression qui survit en production

1. Inventaire de ce qui doit s’imprimer.

   Titre, dernière mise à jour, titres, texte principal, blocs de code, tableaux importants, et un pied de page minimal (optionnel). Tout le reste commence par « non ».

2. Ajouter @media print avec des resets fermes.

   Forcer le texte en noir, supprimer fonds et ombres, normaliser les marges et définir une taille de police d’impression.

3. Masquer l’UI avec des classes stables.

   Ajouter .no-print et l’appliquer à nav/recherche/sidebar/bannière de cookies/widgets de partage. Puis cacher ces sélecteurs en impression.

4. Corriger le positionnement.

   En impression, les éléments fixed/sticky doivent devenir statiques ou disparaître. Testez le nombre de pages avant et après.

5. Rendre les liens utilisables.

   Ajouter les destinations des URLs externes. Ne pas les ajouter pour les ancres internes afin de réduire le bruit.

6. Faire en sorte que le code s’enroule en toute sécurité.

   pre-wrap + break-word + bordures. Vérifier que les longues commandes ne sont pas coupées.

7. Contrôler les sauts de page.

   Protéger titres, tableaux et blocs de code contre la séparation. Ajouter des valeurs widows/orphans par défaut.

8. Tester sur A4 et Letter.

   Au moins une fois. Votre entreprise internationale vous remerciera discrètement (la plus haute forme de gratitude).

9. Automatiser la génération de PDF en CI.

   Épinglez la version du navigateur. Stockez un artefact de référence. Alertez sur de gros diffs (nombre de pages + vérifications visuelles).

10. Écrire un « test d’acceptation impression ».

    Une petite checklist : nav cachée, code qui s’enroule, pas de contenu coupé, liens affichant leurs destinations, pas de page blanche au début.

Checklist d’acceptation rapide (humaine)

• La première page commence par le titre, pas par un espace vide ou une barre de nav.
• Pas de bannière de cookies, pas de champ de recherche, pas de « s’abonner », pas de widget de chat.
• Les blocs de code s’enroulent et restent lisibles ; rien de coupé à droite.
• Les titres ne sont pas séparés de leur premier paragraphe.
• Les liens indiquent où ils mènent (au moins pour les références externes).
• Les tableaux tiennent ou ont un comportement d’enveloppement clairement acceptable.
• Le document s’imprime en A4 et Letter sans perte critique.

Checklist d’acceptation rapide (CI)

• Générer un PDF depuis un navigateur headless épinglé.
• Extraire le texte avec pdftotext ; échouer si vide.
• Enregistrer le nombre de pages avec pdfinfo ; alerter en cas de grosses variations.
• Eventuellement scanner le texte extrait pour des chaînes d’UI (« Search », « Cookie », « Subscribe »).

Trois mini‑histoires d’entreprise issues du terrain

FAQ

1) Dois‑je créer un fichier print.css séparé ou garder les règles d’impression dans la feuille principale ?

Les deux fonctionnent. Si vous générez des PDFs en CI, je préfère regrouper les règles d’impression dans le CSS principal pour éviter les problèmes d’ordre de chargement. Si vous gardez un fichier séparé, assurez‑vous qu’il se charge de façon déterministe et suffisamment tôt pour l’impression headless.

2) Pourquoi l’aperçu avant impression diffère‑t‑il entre Chrome et Firefox ?

Différents moteurs d’impression, différents paramètres par défaut et différents niveaux de support des fonctionnalités paginées. Utilisez l’aperçu dans les deux si votre audience est large, et validez avec une chaîne headless si vous générez des PDFs.

3) Comment empêcher mon en‑tête sticky de se répéter sur chaque page imprimée ?

Dans @media print, définissez le conteneur sticky en position: static !important ou cachez‑le. Supprimez aussi les paddings/marges supérieurs qui compensaient l’en‑tête à l’écran.

4) Dois‑je imprimer le pied de page du site avec des liens juridiques et des icônes sociales ?

Non. Si vous avez besoin de texte légal, incluez un pied de page minimal pertinent. Les icônes sociales sur papier confessent juste que personne n’a réfléchi.

5) Quelle est la meilleure façon d’afficher les URLs à l’impression sans rendre les pages moches ?

Ajoutez les URLs uniquement pour les liens externes et réduisez la taille de police. Si les URLs sont trop longues, autorisez l’enroulement. N’ajoutez pas pour les ancres internes sauf si vous générez un rapport formel avec des IDs de référence.

6) Mes blocs de code s’enroulent, mais l’indentation devient bizarre. Que faire ?

L’enroulement conserve les espaces avec pre-wrap, mais les longues lignes peuvent visuellement « pendre » sans indentation. Envisagez un style d’indentation suspendue en impression, ou cassez manuellement les longues commandes dans la source avec des continuations de ligne lorsque c’est approprié.

7) Puis‑je forcer l’impression en paysage pour les tableaux larges ?

Le support de l’orientation par page dans les navigateurs est incohérent. Si vous devez le faire de façon fiable, utilisez une chaîne de génération PDF contrôlée qui prend en charge les templates de page et les règles d’orientation, ou repensez le tableau pour l’impression.

8) Pourquoi mes couleurs d’arrière‑plan disparaissent à l’impression ?

Beaucoup de navigateurs désactivent l’impression des fonds par défaut pour économiser l’encre. Ne comptez pas sur les fonds pour transmettre du sens. Utilisez des bordures, des étiquettes et du texte à fort contraste.

9) Comment empêcher un tableau de se séparer sur plusieurs pages ?

Appliquez break-inside: avoid (et page-break-inside: avoid) au tableau ou aux lignes, mais sachez que les très grands tableaux se scinderont quand même. Pour les tableaux critiques, envisagez de les convertir en sections ou plusieurs petits tableaux.

10) Que dois‑je tester automatiquement si je ne peux faire qu’un seul contrôle CI d’impression ?

Générez un PDF avec un navigateur headless épinglé, lancez pdftotext pour confirmer qu’il n’est pas rasterisé, et enregistrez le nombre de pages pour détecter les régressions.

Conclusion : prochaines étapes à réaliser cette semaine

Le style d’impression est ingrat. C’est précisément pourquoi il mord les équipes : personne ne l’ouvre tant qu’un client, un auditeur ou un ingénieur d’astreinte ne force pas la situation.
La correction n’est pas compliquée, mais elle exige de traiter le rendu imprimé comme un artefact réel avec des tests réels.

1. Créez ou nettoyez un bloc dédié @media print qui masque l’UI et normalise la typographie.
2. Faites en sorte que les blocs de code s’enroulent à l’impression et vérifiez que les longues commandes ne sont pas coupées.
3. Ajoutez les URLs externes après le texte des liens afin que les lecteurs papier puissent suivre les références.
4. Ajoutez des règles de pagination basiques pour protéger titres, code et tableaux des coupures inesthétiques.
5. Si vous générez des PDFs, épinglez la version du navigateur et ajoutez un contrôle CI minimal : génération PDF + extraction de texte + suivi du nombre de pages.

Faites ces cinq choses et vos documents imprimés cesseront d’être un risque. Ils ne seront pas beaux. Ils seront utilisables. Les systèmes de production fonctionnent grâce à l’utilisabilité.