Qu’est-ce qu’un PDF, vraiment ?

Quand on ouvre un PDF, on a souvent l’impression de voir un document "classique" : du texte, des titres, des paragraphes, des tableaux, des images.

C’est vrai pour l’œil humain.

Mais en dessous, un PDF n’est pas un fichier source de mise en page comme Word, Google Docs ou InDesign. Ce n’est pas un format pensé d’abord pour rééditer un document. C’est surtout un format pensé pour décrire de façon fiable ce qu’une page doit afficher.

Cette différence explique presque tout :

• pourquoi certains PDF se modifient facilement
• pourquoi d’autres semblent verrouillés
• pourquoi un texte peut être visible sans être bien extractible
• pourquoi un scan peut ressembler à un PDF normal tout en étant structurellement très différent

Un PDF est d’abord une description de pages

Le bon modèle mental est simple :

• un document source stocke une logique d’édition
• un PDF stocke surtout une logique de rendu

Autrement dit, un document source sait encore des choses comme :

• ceci est un paragraphe
• ceci est un style de titre
• ceci est une liste
• cette phrase se recompose si la page change

Un PDF, lui, cherche surtout à garantir que la page s’affichera correctement, au bon endroit, avec les bonnes formes, les bonnes images, les bonnes polices et les bonnes dimensions.

Il privilégie donc la fidélité visuelle beaucoup plus que l’éditabilité.

Comment un PDF est structuré

Sous le capot, un PDF est une collection d’objets reliés entre eux.

On y trouve notamment :

• des objets Page
• des dictionnaires de ressources
• des flux de contenu (content streams)
• des objets de police
• des images
• des annotations
• des formulaires
• des métadonnées
• une table de références croisées pour retrouver rapidement les objets

Concrètement, une page PDF ne dit pas forcément "voici un paragraphe".

Elle dit beaucoup plus souvent quelque chose qui ressemble à :

• utiliser telle police
• se placer à telle coordonnée
• dessiner tel glyphe
• déplacer le curseur
• afficher une autre séquence
• dessiner cette image à cet endroit

Le PDF décrit donc très bien comment peindre la page, mais beaucoup moins bien comment rééditer intelligemment son contenu.

Le texte visible n’est pas toujours du "vrai texte"

C’est sans doute le point le plus important.

Quand tu vois un mot dans un PDF, plusieurs réalités très différentes sont possibles.

Cas 1 : le PDF contient un vrai texte numérique

Dans le meilleur cas, le fichier stocke une vraie couche texte exploitable.

Cela permet généralement :

• de sélectionner les mots
• de rechercher dans le document
• de copier-coller du texte cohérent
• de cibler le contenu pour une édition ou une traduction

Ce sont les PDF les plus faciles à exploiter.

Cas 2 : le PDF affiche du texte, mais la reconstruction est mauvaise

Ici, le mot est visible à l’écran, mais le lien entre ce qui s’affiche et les caractères réels est dégradé.

Le PDF peut alors :

• afficher parfaitement le mot
• mais renvoyer un copier-coller incorrect
• ou produire une extraction confuse
• ou perdre des espaces, l’ordre de lecture, ou certains caractères

Visuellement, tout semble normal. Structurellement, c’est beaucoup moins propre.

Cas 3 : le texte a été converti en contours

Dans certains exports, les lettres ne sont plus stockées comme du texte, mais comme des formes vectorielles.

Pour un humain, cela ressemble toujours à du texte.

Pour un logiciel, ce ne sont déjà plus des caractères : ce sont des tracés.

À ce stade, la page peut être parfaitement nette tout en étant très mauvaise pour la recherche, l’extraction ou la réécriture ciblée.

Cas 4 : le texte est en réalité une image

Dans un scan papier, un fax, une photocopie numérisée ou une capture photo, la page entière peut n’être qu’une image.

Le "texte" est alors seulement contenu dans les pixels.

Le logiciel ne peut pas vraiment lire le document tant qu’une étape d’OCR n’a pas ajouté une couche texte exploitable.

Pourquoi certaines polices sont reconstructibles et d’autres non

Quand on dit qu’une police ou un texte est "reconstructible", il faut être précis.

En pratique, ce qu’on cherche souvent à reconstruire, ce n’est pas la police complète comme fichier source. On cherche surtout à reconstruire correctement le lien entre les glyphes dessinés et les caractères réels.

Et c’est là que beaucoup de PDF deviennent compliqués.

Polices embarquées

Un PDF peut embarquer la police directement dans le fichier. C’est très utile pour l’affichage fidèle.

Mais afficher correctement une police ne suffit pas toujours à rendre le texte bien extractible.

Le moteur d’affichage peut savoir dessiner le glyphe voulu sans que le document fournisse une correspondance propre entre ce glyphe et son caractère Unicode réel.

Polices subset

Très souvent, le PDF n’embarque pas la police complète, mais seulement un sous-ensemble des glyphes utilisés.

C’est ce qu’on appelle souvent une police subset.

Visuellement, c’est efficace : le fichier est plus léger, l’apparence reste fidèle.

Mais pour la reconstruction, cela peut compliquer les choses :

• les noms de glyphes peuvent être partiels
• certains caractères n’existent plus qu’en version minimale
• l’encodage interne peut être très spécifique au document

Tables de correspondance et ToUnicode

Le point clé est souvent la présence d’une bonne table de correspondance entre les codes internes du PDF et les vrais caractères Unicode.

Quand cette correspondance existe et qu’elle est correcte, l’extraction est généralement bien meilleure.

Quand elle manque, est incomplète, ou a été mal générée, le PDF peut :

• s’afficher correctement
• mais extraire du texte erroné
• confondre certains caractères
• casser les ligatures
• perdre des accents
• sortir des suites de symboles incohérents

Autrement dit : un PDF peut afficher juste sans savoir expliquer proprement ce qu’il affiche.

Texte converti en contours

Là, la reconstruction devient encore plus difficile.

Si les lettres sont devenues des formes vectorielles, il n’y a parfois plus de texte à reconstruire du tout. Il faut alors inférer le contenu à partir de la géométrie ou repasser par une logique proche de l’OCR.

Pourquoi modifier un PDF est plus difficile qu’on ne l’imagine

Beaucoup de gens imaginent qu’éditer un PDF consiste à "ouvrir un document figé".

En réalité, le problème est souvent beaucoup moins sémantique et beaucoup plus géométrique.

Un PDF conserve parfois :

• des glyphes positionnés un par un
• des morceaux de texte séparés
• un ordre de lecture imparfait
• des blocs sans structure de paragraphe
• des espacements seulement implicites

Il ne conserve pas toujours clairement :

• les paragraphes originaux
• les styles logiques
• les relations entre colonnes
• le reflow
• la structure éditoriale de haut niveau

Un paragraphe visible peut ainsi être, sous le capot, une série de petites instructions placées à des coordonnées précises.

Pour afficher, cela suffit.

Pour rééditer proprement, c’est beaucoup plus fragile.

Pourquoi deux PDF presque identiques à l’écran peuvent réagir très différemment

C’est une conséquence directe de tout ce qui précède.

Deux fichiers peuvent afficher exactement la même phrase au même endroit :

• l’un avec une vraie couche texte exploitable
• l’autre avec des glyphes mal mappés
• un troisième avec du texte converti en contours
• un quatrième avec une simple image de page

Pour un utilisateur, ces quatre pages "se ressemblent".

Pour un moteur d’édition, ce sont quatre situations complètement différentes.

Et c’est pour cela qu’un PDF peut être :

• facile à rechercher
• difficile à copier
• possible à traduire
• mais pénible à corriger caractère par caractère

ou même impossible à modifier sans étape supplémentaire.

Où intervient l’OCR

L’OCR ne recrée pas magiquement le document source d’origine.

Il ne retransforme pas un scan en fichier Word propre, ni en maquette InDesign intacte.

Son rôle est plus précis : ajouter une couche texte exploitable à un document qui n’en a pas, ou pas assez.

C’est essentiel pour :

• les scans papier
• les fax
• les archives numérisées
• les documents image-only

L’OCR améliore donc surtout la lisibilité machine du document. Il ne restaure pas toute la structure éditoriale perdue à l’export ou au scan.

Ce que cela change pour les outils d’édition

En pratique, le bon workflow dépend du type réel de PDF.

Si le PDF possède déjà une bonne couche texte

L’édition IA est souvent la meilleure option.

C’est le bon cas pour AI Edit quand il faut :

• corriger une phrase
• réécrire un passage
• mettre à jour un nom, une date ou une clause
• traduire un contenu

Si tu veux surtout ajouter un élément visuel

L’objectif n’est plus de reconstruire le texte, mais de placer quelque chose sur la page.

Dans ce cas, Manual Edit est plus adapté pour :

• une signature
• une annotation
• un surlignage visuel
• un repère dessiné

Si le document est essentiellement image-only

Il faut d’abord le rendre lisible par le logiciel.

C’est là que PDF OCR intervient, en ajoutant une couche texte searchable invisible sans modifier l’apparence visible du document.

Le bon modèle mental à retenir

Un PDF n’est pas "un Word figé".

C’est une représentation finale de pages.

Plus cette représentation conserve une couche texte propre, des correspondances correctes et une structure exploitable, plus le document est récupérable.

Plus elle perd cette information au profit d’images, de contours ou d’encodages opaques, plus l’édition devient difficile.

La version courte est donc :

• le PDF est excellent pour préserver l’apparence
• il est variable pour préserver la structure éditable
• afficher correctement ne veut pas dire extraire correctement
• voir du texte ne veut pas dire disposer d’un vrai texte exploitable
• l’OCR aide à récupérer une couche texte, mais ne ressuscite pas tout le document source

Et c’est précisément pour cela que certains PDF se modifient très bien, tandis que d’autres demandent de l’OCR, des ajustements manuels, ou une approche beaucoup plus prudente.