PDF sans couche de texte : comment le vérifier avant de créer une règle

Un PDF n'a pas de couche de texte quand les mots de la page n'ont jamais été encodés comme du texte — le fichier ne contient qu'une image de ces mots, et il n'y a donc rien qu'une règle, une barre de recherche ou un Ctrl+F puisse lire. C'est la cause la plus fréquente d'une règle de correspondance de contenu qui ne fait silencieusement rien : non pas une règle mal construite, mais un fichier sans rien en dessous de l'image à faire correspondre. Vous pouvez savoir en moins d'une minute, sur Mac comme sous Windows, à quel type de PDF vous avez affaire, avant même de commencer à construire une règle autour de lui. Ce guide couvre ce test, la marche à suivre quand un fichier échoue, et les autres formats et limites qui provoquent la même non-correspondance silencieuse, même sur un PDF tout à fait normal.

Pourquoi ma règle ne trouve-t-elle aucun texte dans mon PDF ?

Un PDF issu de Word, de Pages, ou d'une application de scan moderne transporte deux choses à la fois : l'image de la page que vous voyez, et une couche cachée de vrais caractères positionnés derrière elle. Cette couche cachée, c'est la couche de texte. C'est elle qu'un lecteur PDF utilise pour vous laisser sélectionner une phrase, ce que Ctrl+F recherche, et ce qu'une règle de correspondance de contenu lit.

Une page scannée ou une photo de document prise au téléphone ne contient que l'image. Personne n'a fait tourner de reconnaissance de texte dessus, donc il n'y a aucun caractère derrière l'image — seulement des pixels disposés pour ressembler à des lettres. À l'œil humain, une facture scannée et une facture « imprimée en PDF » peuvent sembler identiques. Pour un logiciel, l'une contient des mots et l'autre n'en contient aucun. C'est exactement ce qui piège les gens : le fichier ressemble à un document normal, s'ouvre sans problème, s'imprime sans problème, et ne correspond pourtant à aucune règle de contenu à moins que la règle n'exécute d'abord l'OCR, parce qu'il n'y a jamais eu de texte à faire correspondre.

Ce n'est pas une particularité de File Arbor — tout outil qui lit le contenu d'un fichier a besoin d'une couche de texte pour le lire, File Juggler et organize compris ; ceux qui gèrent les scans, Hazel 6 et, depuis la version 1.3.0, File Arbor Pro, exécutent d'abord l'OCR pour créer ce texte. Le forum d'assistance de Hazel chez Noodlesoft revient régulièrement sur ce sujet, avec des utilisateurs dont les règles ont « arrêté de lire » leurs PDF ; une couche de texte manquante, ou un index Spotlight désynchronisé, est l'explication qui revient le plus souvent dans ces échanges. Ce dernier cas, propre à Hazel, est traité en détail dans notre guide sur Contents Contain qui ne fonctionne pas — celui-ci se concentre sur la couche de texte elle-même, quel que soit l'outil qui la lit.

Le test de 60 secondes : ce PDF a-t-il une couche de texte ?

Avant de construire une règle autour du contenu d'un PDF, ouvrez le fichier et essayez de le lire comme le ferait une règle : en tentant de sélectionner ou de rechercher son texte. Si rien ne se sélectionne et que rien ne se trouve, il n'y a pas de couche de texte, et aucune règle de contenu ne correspondra à ce fichier à moins d'exécuter d'abord l'OCR — dans File Arbor Pro, en réglant la règle pour lire aussi les documents scannés (depuis la version 1.3.0).

Sur Mac

Ouvrez le PDF dans Aperçu. Cliquez-glissez sur une ligne de texte visible. Si des mots individuels se surlignent, le fichier a une couche de texte. Si rien ne se surligne, peu importe où vous glissez, il n'en a pas. En second test, appuyez sur Commande-F et recherchez un mot que vous voyez clairement sur la page — une vraie couche de texte le trouve instantanément ; un PDF composé uniquement d'une image ne trouve rien.

Sous Windows

Ouvrez le PDF dans votre lecteur par défaut (Microsoft Edge s'en charge nativement sous Windows 10 et 11). Cliquez-glissez sur une ligne de texte, ou appuyez sur Ctrl+A pour tout sélectionner. Une couche de texte surligne des mots individuels ; une page composée uniquement d'une image ne sélectionne rien, ou dessine un seul cadre autour de l'image entière. Appuyez sur Ctrl+F et recherchez un mot de la page en second test — même logique que sur Mac : trouvé signifie couche de texte, introuvable signifie aucune.

Faites ce test sur un fichier représentatif avant de construire une règle autour de tout un dossier de documents similaires. Une simple page de garde scannée dans un lot par ailleurs composé de texte passera le test ; un dossier entier de sorties de scanner de bureau, en général, ne le passera pas — et il vaut mieux le savoir à l'avance plutôt qu'après qu'une règle n'ait silencieusement rien fait pendant une semaine.

PDF natif ou PDF scanné : quels outils exécutent réellement l'OCR ?

Un PDF natif et un PDF scanné peuvent être visuellement impossibles à distinguer et pourtant fonctionnellement opposés. Toute la différence tient à si une OCR — la reconnaissance optique de caractères — a un jour tourné sur le fichier, que ce soit à sa création (une application de scan qui reconnaît le texte au moment même du scan) ou après coup (une passe d'OCR séparée sur un fichier existant qui n'était qu'une image).

C'est ici que les outils diffèrent vraiment, et il vaut mieux le dire clairement plutôt qu'en note de bas de page : Hazel 6 exécute une reconnaissance de texte à la volée sur les PDF non océrisés, et il peut se voir fournir un mot de passe pour ouvrir un PDF chiffré, directement au moment de la vérification de la règle. File Arbor ne faisait ni l'un ni l'autre avant la version 1.3.0. Depuis, Pro exécute aussi l'OCR, quand une règle est réglée pour lire aussi les documents scannés : il lit la première et la dernière page d'un PDF scanné ou d'une photo (JPEG, PNG, TIFF), en 9 langues, à raison d'environ une seconde par page. Il n'y a toujours pas de champ pour un mot de passe, donc un PDF chiffré reste illisible.

Si vos PDF sont couramment chiffrés, l'option de mot de passe de Hazel est la raison concrète de le préférer à File Arbor — c'est vrai sur Mac, même pour quelqu'un qui préférerait autrement un outil multiplateforme. Pour les scans, les deux exécutent désormais l'OCR dans la règle. File Arbor Pro ne lit toutefois que la première et la dernière page ; si le texte dont vous avez besoin se trouve plus loin dans un long scan, faire tourner l'OCR une fois, à l'avance, sur les fichiers qui en ont besoin permet donc toujours à une règle de contenu File Arbor d'arriver au même résultat.

Que faire quand il n'y a pas de couche de texte ?

Rater le test de 60 secondes ne met pas fin à toute possibilité de correspondance de contenu pour ce fichier — cela signifie que vous avez deux options honnêtes, et aucune des deux n'est « attendre en espérant ».

Faites tourner l'OCR dessus. Depuis la version 1.3.0, File Arbor Pro peut le faire dans la règle : réglez la règle pour lire aussi les documents scannés, et elle lit la première et la dernière page de chaque scan. La même règle peut ensuite nommer le scan d'après une date ou un numéro qu'elle lit, comme le montre le guide pour renommer un PDF selon son contenu. Sinon, un outil d'OCR dédié, le logiciel fourni avec votre scanner, ou l'étape de reconnaissance intégrée à Adobe Acrobat peuvent ajouter une véritable couche de texte à un PDF composé uniquement d'une image. Une fois cela fait, le fichier passe le même test de sélection et de recherche, et une règle de contenu peut le lire comme n'importe quel autre PDF.

Ou renoncez à la correspondance de contenu pour ce fichier et faites correspondre autre chose. Une règle basée sur le nom du fichier, le dossier où il atterrit, ou sa date n'a besoin de lire aucun caractère à l'intérieur du fichier. Si un client envoie toujours ses reçus scannés sous la forme recu-scan-*.pdf, une règle basée sur le nom résout le problème sans aucune OCR — parfois, le correctif honnête est une règle plus simple, pas un outil plus complexe.

Les autres formats qui ne correspondent jamais, même avec une couche de texte

Une couche de texte manquante n'est pas la seule façon dont un fichier échoue silencieusement à correspondre. Dans File Arbor, aucun des éléments suivants ne déclenchera de condition de contenu, quel que soit leur contenu réel :

• Les feuilles de calcul XLSX. Les conditions de contenu ne lisent pas du tout les cellules d'un tableur.
• Les en-têtes, pieds de page et notes de bas de page d'un document Word. Seul le corps principal du texte d'un fichier DOCX est vérifié — un mot-clé présent uniquement dans un pied de page ou un en-tête ne correspondra pas.
• Les PDF chiffrés ou protégés par mot de passe. Ils ne peuvent pas être ouverts pour l'extraction de texte sans le mot de passe, et File Arbor n'a aucun champ pour en fournir un.

Rien de tout cela n'est propre à l'implémentation de File Arbor — cela reflète simplement ce qu'un moteur de règles peut extraire sans invite de mot de passe ni analyseur de tableur, pas un défaut à corriger plus tard.

Les plafonds qui provoquent une non-correspondance silencieuse sur un PDF normal

Même un PDF qui passe le test de 60 secondes avec une vraie couche de texte peut encore échouer à correspondre, parce que l'extraction de contenu dans File Arbor a des limites strictes : 32 Mo par fichier, les premiers 256 Ko de texte extrait, les 20 premières pages d'un PDF, et une fenêtre de traitement de 5 secondes par fichier.

Le plafond de pages est celui qui surprend le plus. Un contrat de 40 pages où le mot « résiliation » n'apparaît qu'à la page 25 ne correspondra à aucune règle qui le recherche — File Arbor ne lit jamais au-delà de la page 20, donc en ce qui concerne la règle, ce mot n'existe tout simplement pas dans le fichier. La même logique s'applique au plafond de 256 Ko sur les documents longs et denses en texte : l'extraction s'arrête là, même si le fichier continue au-delà. Ces limites ne sont pas arbitraires ; elles existent pour éviter qu'un fichier surdimensionné ne bloque tous les autres fichiers qui attendent derrière lui dans la file.

Quel correctif utiliser ?

« Le fichier ne se sélectionne ni ne se recherche du tout. » C'est un scan ou une photo sans couche de texte. Dans File Arbor Pro, réglez la règle pour lire aussi les documents scannés (depuis la version 1.3.0) ; sinon, faites-le d'abord passer par un logiciel d'OCR, ou classez-le par nom, dossier ou date plutôt que par contenu.

« Le texte se sélectionne bien, mais la règle ne correspond toujours pas. » Vérifiez si l'expression recherchée se trouve après la page 20, si le fichier dépasse 32 Mo, ou si la correspondance tombe après les premiers 256 Ko de texte extrait — n'importe laquelle de ces limites produit une non-correspondance silencieuse sur un PDF par ailleurs tout à fait normal.

« Le PDF est protégé par un mot de passe. » Ni File Arbor ni une simple règle de contenu ne peuvent l'ouvrir sans ce mot de passe. Sur Mac, Hazel peut recevoir le mot de passe directement dans la règle. Sinon, retirez la protection avant d'automatiser le fichier, si vous en avez la possibilité.

« C'est un tableur, ou la correspondance se trouve dans l'en-tête ou le pied de page d'un document Word. » Les conditions de contenu lisent le corps du texte d'un DOCX et la couche de texte d'un PDF — pas les cellules d'un tableur, ni les en-têtes, pieds de page ou notes de bas de page. Faites plutôt correspondre le nom du fichier ou le dossier.

« J'ai des centaines de fichiers scannés et pas le temps de les corriger un par un. » Laissez la règle exécuter l'OCR : File Arbor Pro le fait depuis la version 1.3.0, sous Windows et sur Mac, et Hazel 6 le fait sur Mac. Avec tout autre outil, faites-les d'abord passer par lots dans un logiciel d'OCR dédié, puis pointez votre règle vers le résultat océrisé.

FAQ

Que signifie l'absence de couche de texte dans un PDF ?

Cela signifie que les mots de la page n'ont jamais été encodés comme du texte, seulement comme une image de ces mots. Un PDF issu d'un scan ou d'une photo de téléphone stocke des pixels, pas des caractères, donc rien ne peut sélectionner, rechercher ou faire correspondre son texte tant que l'OCR ne l'a pas reconnu — la page peut sembler identique à un PDF normal tout en ne contenant aucun texte lisible en dessous.

Pourquoi ma règle ne trouve-t-elle pas de texte dans un PDF ?

Le plus souvent parce que le PDF n'a pas de couche de texte : c'est un scan ou une photo sans caractères à lire. Cela peut aussi arriver sur un PDF normal si la correspondance tombe hors des limites d'un outil, si le PDF est chiffré, ou si le fichier est un format qui n'est pas lu pour son contenu, comme un tableur ou l'en-tête d'un document Word.

Quelle est la différence entre un PDF consultable et un PDF scanné ?

Un PDF consultable possède une couche de texte sous-jacente, créée à l'export depuis un traitement de texte ou produite par OCR, si bien que ses mots peuvent être sélectionnés, recherchés et lus par un logiciel. Un PDF scanné est une image de la page, généralement issue d'un scanner ou d'une photo de téléphone, sans couche de texte, donc aucun de ses mots n'est lisible par un logiciel tant que l'OCR ne les a pas reconnus.

Comment vérifier si un PDF a une couche de texte avant de créer une règle ?

Ouvrez le PDF et essayez de sélectionner une ligne de texte, ou recherchez un mot visible sur la page. Sur Mac, utilisez l'outil de sélection d'Aperçu ou Commande-F ; sous Windows, utilisez la recherche de votre lecteur PDF ou cliquez-glissez pour sélectionner du texte. Si rien ne se surligne et que la recherche ne trouve rien, le fichier n'a pas de couche de texte.

File Arbor lit-il les PDF scannés comme Hazel ?

Oui, depuis la version 1.3.0, avec deux différences. File Arbor Pro exécute l'OCR sur les PDF scannés et les photos quand une règle est réglée pour lire aussi les documents scannés, mais il ne lit que la première et la dernière page. Et contrairement à Hazel 6, il ne peut pas ouvrir un PDF protégé par mot de passe, donc un PDF chiffré doit encore être déverrouillé avant qu'une règle de contenu de File Arbor puisse correspondre.

Une règle de contenu trouvera-t-elle du texte à la page 40 d'un PDF ?

Non. File Arbor ne lit que les 20 premières pages d'un PDF, avec les premiers 256 Ko de texte extrait, des fichiers jusqu'à 32 Mo, et une fenêtre de traitement de 5 secondes par fichier. Un mot-clé présent uniquement à la page 40 d'un document plus long ne correspondra pas, même si le PDF possède une couche de texte tout à fait normale.

Ce qu'il faut retenir

Un PDF sans couche de texte n'est pas une règle que vous avez mal écrite — c'est un fichier qui n'a rien à lire, et le test de 60 secondes de sélection et de recherche vous dit lequel des deux vous avez sous les yeux avant de perdre du temps à construire quoi que ce soit. Faites tourner l'OCR sur les fichiers qui en ont besoin — depuis la version 1.3.0, une règle File Arbor Pro peut le faire elle-même — ou classez-les par nom, dossier ou date. Pour le reste, vérifiez le format et les plafonds : pas de XLSX, pas d'en-têtes ni de pieds de page DOCX, pas de PDF chiffrés, et rien au-delà de 20 pages, 256 Ko ou 32 Mo.

C'est la même limite honnête que celle couverte dans notre guide sur le tri des fichiers par contenu — les règles de contenu orientent les fichiers selon ce qui est réellement lisible à l'intérieur, et rien n'est deviné. Si vos fichiers passent le test, téléchargez File Arbor et construisez la règle ; sinon, réglez la règle pour lire aussi les documents scannés (Pro), ou corrigez d'abord le fichier.