Comment fonctionnent les fichiers PDF

Un PDF est un graphe d’objets numérotés — pages, polices, images — dont les offsets en octets sont consignés dans une table de références croisées à la fin du fichier. Les lecteurs lisent le trailer, parcourent l’arborescence de pages et font le rendu. Endommagez les offsets, et un lecteur tolérant reconstruit la table en scannant ; un lecteur strict refuse le fichier.

100 % local

PDF ressemble à un format de description de pages — et c’en est un — mais, dessous, c’est une petite base de données : des objets numérotés dont chacun peut référencer tous les autres. Une police utilisée sur quarante pages n’est stockée qu’une fois, une image d’en-tête réutilisée n’est stockée qu’une fois, et les pages elles-mêmes sont des nœuds d’une arborescence qui dit quoi afficher, et dans quel ordre.

Le format est une norme ISO depuis 2008 (ISO 32000, révisée en 2017), et son modèle central n’a pas bougé depuis l’original de 1993 : un en-tête, un corps d’objets, une table de références croisées qui note où commence chaque objet, et un trailer qui pointe vers la racine. Deux décennies de fonctionnalités se sont empilées sans ébranler ces fondations — voilà pourquoi un lecteur d’aujourd’hui peut ouvrir un scan de 1998.

Comprendre la structure rapporte immédiatement : cela explique pourquoi les fichiers fusionnés continuent de fonctionner, pourquoi les pages supprimées persistent dans un fichier, pourquoi les lecteurs divergent sur les documents endommagés, et ce que fait réellement une réparation. Chaque outil lié ici — fusion, division — accomplit cette chirurgie d’objets localement, dans votre navigateur.

La fusion, c’est la leçon de structure rendue visible, car une fusion reconstruit le graphe d’objets : regardez l’outil Fusionner PDF combiner plusieurs fichiers, et vous verrez s’écrire de nouveaux nœuds d’arborescence de pages et se poser une table xref toute neuve.

L’extraction fait la même opération en sens inverse — décider de quels objets les pages conservées ont besoin — et l’outil Diviser PDF réécrit exactement ceux-ci dans un nouveau fichier avec sa propre table de références croisées, sans jamais toucher à vos originaux.

Un graphe d’objets numérotés

Un fichier PDF s’ouvre sur un en-tête tel que %PDF-1.7, puis n’est plus qu’une suite d’objets : des blocs qui commencent par un numéro, un numéro de génération et le mot-clé obj, portent du contenu, et se terminent par endobj. L’objet 1 peut être le catalogue, la racine du document ; l’objet 2, l’arborescence de pages ; l’objet 9, un flux de contenu renfermant les commandes de dessin d’une page. Tout objet peut en désigner un autre en écrivant son numéro et la lettre R — 12 0 R — ce qui constitue une référence indirecte.

L’indirection est tout le concept. Tout est référence, si bien que la structure est partagée plutôt que copiée : un seul catalogue, des dictionnaires de ressources partagés, et un document de 300 pages qui référence la même police intégrée à travers un objet unique. Cela fait aussi des PDF un vrai graphe — et c’est pourquoi les outils qui les manipulent pratiquent de la chirurgie de graphe, pas du traitement de texte.

Les deux premiers objets d'un PDF

1 0 obj
<< /Type /Catalog /Pages 2 0 R >>
endobj

2 0 obj
<< /Type /Pages
   /Kids [3 0 R]
   /Count 1 >>
endobj

Comment le graphe se résout

catalog (object 1)
└─ page tree (object 2)
   └─ page (object 3)

L’arborescence de pages

Les pages vivent dans une arborescence, pas dans une liste : un nœud racine de type Pages contient un tableau nommé Kids, dont les entrées sont des objets Page ou d’autres nœuds Pages s’emboîtant de la même façon. Chaque enfant porte une référence Parent vers le haut. Un lecteur trouve la page un en descendant du catalogue par la première branche — et comme les nœuds peuvent être des sous-arbres, insérer une section de 40 pages se résume à un nœud nouveau et à un tableau Kids modifié.

L’arborescence est aussi le royaume de l’héritage. MediaBox (la taille de la page), Rotate (ses rotations d’affichage de 90 degrés) et Resources (ses polices et ses images) peuvent être déclarés une seule fois sur un nœud Pages et se propagent à tout descendant qui ne les redéfinit pas. Un document dont toutes les pages sont en A4 déclare cette taille une seule fois à la racine — voilà pourquoi un objet page peut être si court.

Une arborescence de pages avec héritage

2 0 obj
<< /Type /Pages
   /Kids [3 0 R 4 0 R]
   /Count 2
   /MediaBox [0 0 595 842] >>
endobj

3 0 obj
<< /Type /Page
   /Parent 2 0 R
   /Contents 9 0 R >>
endobj

Ce que l'objet page 3 hérite

MediaBox  [0 0 595 842]   (A4, inherited)
Contents  9 0 R           (its own)

La table xref et le trailer

Vers la fin du fichier se trouve la table de références croisées : une ligne par objet, notant l’offset en octets où cet objet commence. Une entrée telle que 0000000123 00000 n indique qu’un objet démarre 123 octets après le début du fichier ; n le marque comme utilisé, f comme emplacement libre. Suit un dictionnaire trailer, dont l’entrée Root pointe vers le catalogue ; puis startxref note où commence la table elle-même, et le fichier se clôt par %%EOF.

L’objectif, c’est l’accès direct. Un lecteur qui veut la page 240 ne lit pas depuis le début ; il saute à la fin, suit startxref jusqu’à la table, et plonge directement vers les octets dont il a besoin. Tout, dans la structure de queue du format — y compris pourquoi ajouter des données en fin de fichier est sûr et les insérer au début ne l’est pas — découle de cette carte posée à l’arrière du territoire.

Élément	À quoi cela ressemble	Rôle
En-tête	%PDF-1.7	Marque de version, première ligne du fichier
Objet	12 0 obj … endobj	Un nœud de contenu numéroté
Référence indirecte	12 0 R	Un pointeur d’un objet vers un autre
Entrée xref	0000000123 00000 n	Offset en octets où un objet commence
Trailer	<< /Root 1 0 R >>	Pointe vers le catalogue ; la racine du document
startxref	startxref 12054	Offset en octets de la table xref elle-même
Marqueur EOF	%%EOF	Fin de la dernière section de mise à jour

Mises à jour incrémentales : ajouter à la fin, ne jamais réécrire

Quand un PDF est modifié — un formulaire rempli, une page supprimée — un rédacteur bien élevé ne réécrit pas le fichier. Il ajoute à la suite : les objets nouveaux et modifiés vont en fin de fichier, suivis d’une nouvelle table xref et d’un nouveau trailer décrivant l’état mis à jour, puis d’un autre %%EOF. Les octets d’origine restent intacts, et la nouvelle table remplace l’ancienne.

Ce concept est élégant pour l’archivage — et il explique trois phénomènes bien réels. Les documents signés se cassent quand un outil les réécrit, parce qu’une signature couvre des octets précis ; une mise à jour incrémentale peut préserver la validité, une réécriture non. Le contenu supprimé persiste : une page que vous avez retirée reste généralement dans le fichier, non référencée par la dernière table mais lisible par quiconque scanne. Et les fichiers grossissent à chaque enregistrement, puisque rien n’est récupéré avant une réécriture complète — ce que réalisent le nettoyage ou la linéarisation.

Pourquoi certains lecteurs réparent les fichiers cassés

La table xref est le mur porteur du format — et son point de rupture favori. Un fichier envoyé par e-mail en mode texte (ce qui corrompt les octets binaires), tronqué par un transfert échoué, ou écrit par un outil trop prompt à promettre peut se retrouver avec des offsets qui pointent au mauvais endroit. Quand le lecteur suit startxref et trouve n’importe quoi, le fichier est cassé — au sens propre.

Ce qui se passe ensuite relève d’un choix de politique, pas d’une exigence de la spécification. Les lecteurs tolérants déclenchent une reconstruction : ils scannent tout le fichier à la recherche de tout ce qui ressemble à un en-tête d’objet valide (un numéro, une génération, le mot-clé obj), rassemblent leurs trouvailles dans une table xref neuve, en mémoire, et ouvrent le document quand même. La récupération est lente sur les gros fichiers et peut mal juger des objets ambigus, mais elle fonctionne en général — voilà pourquoi Acrobat propose de réparer tandis que des lecteurs plus stricts refusent tout simplement. Tout ce qui réécrit un PDF lève l’ambiguïté en produisant une table propre, couvrant exactement les objets conservés.

Comportement du lecteur	Ce qu’il fait	Arbitrage
Strict	Refuse le fichier quand xref ou startxref est erroné	Rapide, honnête, inutile pour la récupération
Tolérant	Scanne les marqueurs obj et reconstruit une table en mémoire	Lent sur les gros fichiers ; peut trancher à l’aveugle en cas d’ambiguïté
Outils de réécriture	Écrivent une nouvelle table xref sur les objets conservés	Lève l’ambiguïté ; nouveau fichier, nouveaux offsets

Linéarisation et sous-ensembles de polices

Deux raffinements complètent le tableau. Un PDF linéarisé — commercialisé sous le nom Fast Web View — voit ses objets réordonnés physiquement pour que ceux de la page un arrivent en premier, plus une table d’indices qui permet au lecteur de commencer le rendu avant que le reste n’arrive. Rien ne change dans la logique du document ; seul l’agencement sur disque change — voilà pourquoi la linéarisation est une réécriture complète, et pourquoi elle réduit le temps du premier affichage sur les connexions lentes et les serveurs à byte-serving.

Les polices suivent la même philosophie de partage : une police intégrée est un objet unique, référencé par chaque page qui l’utilise, et les rédacteurs bien élevés n’intègrent que les glyphes réellement employés — un sous-ensemble. Un rapport de 40 pages transporte souvent quelques dizaines de kilo-octets de données de police au lieu de mégaoctets. Le prix à payer : l’extraction de texte dépend de la table ToUnicode du sous-ensemble ; sans elle, les lecteurs affichent les glyphes à la perfection, tandis que le copier-coller produit du charabia.

Questions fréquentes

Mon PDF est-il envoyé quand je le fusionne ou le divise ici ?

Non. L’analyse, la chirurgie de l’arborescence de pages et la réécriture xref se déroulent toutes dans votre onglet de navigateur ; le fichier ne quitte jamais votre machine. Vérifiez-le dans les DevTools : ouvrez le panneau Network, fusionnez deux fichiers, et constatez que la liste des requêtes reste vide. La Content-Security-Policy du site bloque aussi les connexions sortantes des scripts de la page.

Pourquoi mon PDF a-t-il grossi après que j’ai supprimé des pages ?

Parce qu’un éditeur bien élevé ajoute à la suite au lieu de réécrire : la nouvelle table xref marque les pages comme parties, mais leurs objets restent dans le fichier, non référencés et non récupérés. Le contenu retiré peut aussi rester récupérable à partir des anciens octets — bon à savoir si le document a un jour été sensible. C’est une réécriture complète qui réduit réellement la taille du fichier.

Peut-on réparer un PDF corrompu ?

Souvent. La plupart des dégâts tiennent à une table xref cassée ou à un pointeur startxref erroné, et les lecteurs tolérants reconstruisent la table en scannant les en-têtes d’objets valides. Ce qui ne peut être récupéré, c’est ce que le scan ne peut pas trouver : les objets écrasés par une corruption binaire ou tronqués en plein corps ont tout simplement disparu. Voilà pourquoi une réparation donne parfois un document partiel — la limite honnête du scan.

Pourquoi le copier-coller produit-il du charabia sur certains PDF ?

Le texte est dessiné avec des codes de glyphes, pas avec des lettres, et retrouver les lettres dépend d’une table ToUnicode livrée avec la police intégrée. Les polices en sous-ensemble dépourvues d’une bonne table s’affichent à merveille mais collent du non-sens, et les pages scannées n’ont pas de texte du tout tant que l’OCR n’en invente pas. Si un PDF colle mal, le rendu, lui, est bon — c’est la correspondance glyphe-caractère qui manque.

Qu’est-ce qu’un PDF linéarisé, et en ai-je besoin ?

La linéarisation (Fast Web View) réordonne le fichier pour que les objets de la page un viennent en premier et ajoute une table d’indices, qui laisse les lecteurs démarrer le rendu avant que tout le fichier ne soit arrivé. Elle change la livraison, pas le contenu. Cela compte quand des PDF sont servis sur des réseaux avec byte-serving ; ouvert localement, le fichier ne change rien de visible, même si cela produit au passage un fichier propre, entièrement réécrit.

Pourquoi le même PDF s’affiche-t-il différemment selon le lecteur ?

ISO 32000 ménage une latitude délibérée : substitution de police quand une police intégrée manque, traitement des structures endommagées propre à chaque lecteur, valeurs par défaut de la gestion des couleurs et rendu de la transparence. Un PDF avec ses sous-ensembles intégrés et sans dégât s’affiche presque à l’identique partout ; l’écart apparaît quand les fichiers dépendent de polices locales ou portent des problèmes structurels que chaque lecteur résout à sa manière.

Équipe ToolsByUs · Comment nous vérifions nos outils