Du PDF scanné à l'audiolivre : pourquoi c'est compliqué et comment nous l'avons résolu

Cinq secondes de silence

Une lectrice du Chili s'est inscrite, a envoyé un PDF de 74 pages d'un roman pour enfants — "¿Quién le tiene miedo a Demetrio Latov?" d'Angeles Durini — et a cliqué sur Générer l'audiolivre. Quinze secondes plus tard, un e-mail est arrivé : "Votre audiolivre est prêt."

En réalité, non. Le fichier durait 5,6 secondes. Il ne contenait rien.

C'est le genre de bug que l'on ne détecte qu'en production, parce que les PDF de test que nous utilisions contenaient du texte intégré. Le sien, non. Le livre avait été scanné, page par page, en 2012 avec Adobe Acrobat Pro — et chaque page était stockée sous forme d'image. Pour notre pipeline, le PDF était composé de 74 pages blanches.

Pourquoi les PDF scannés cassent les pipelines d'audiolivres

Un PDF peut transporter du texte de deux manières complètement différentes :

• PDF texte — les mots sont stockés sous forme de véritables caractères avec leur police et leur position. N'importe quelle bibliothèque (pypdf, pdfminer, pypdfium2) peut les extraire en millisecondes.
• PDF image (scans) — les pages sont des images JPEG ou TIFF intégrées dans l'enveloppe PDF. Pour une bibliothèque d'extraction de texte, ces pages ne contiennent aucun caractère.

Tout ce qui provient d'un scanner à plat, de l'appareil photo d'un smartphone ou d'un vieux projet de numérisation (pensez à Google Books, archive.org, aux rééditions du domaine public, aux livres pour enfants d'occasion) appartient généralement à la seconde catégorie. À l'œil nu, ils sont identiques. Pour un logiciel, ils sont radicalement différents.

En examinant le fichier en échec, notre parseur PDF avait renvoyé exactement 17 caractères de charabia — des octets de contrôle, pas des lettres — pour l'intégralité du livre de 74 pages. Notre pipeline avait ensuite consciencieusement envoyé ces 17 octets à la synthèse vocale, ce qui avait produit 5 secondes de bafouillage. Puis il avait envoyé un e-mail à la lectrice pour lui annoncer que son audiolivre était prêt.

Ce que nous avons construit

La solution est conceptuellement simple : détecter quand un PDF n'a pas de texte exploitable, puis appliquer l'OCR à chaque page. L'implémentation comporte quelques éléments qu'il vaut la peine de décrire.

1. Un détecteur de texte clairsemé

Avant de lancer l'OCR à chaque envoi, nous vérifions le résultat de l'extraction native. Si l'ensemble du PDF renvoie moins de 200 caractères, ou si la moyenne est inférieure à 30 caractères par page sur 4 pages ou plus, nous le traitons comme un scan et basculons sur l'OCR. Les PDF texte ordinaires — plus de 90 % des cas — ne déclenchent jamais le chemin lent.

2. pypdfium2 + tesseract (du tout-Apache 2.0)

Nous rendons chaque page avec pypdfium2 (un wrapper Python autour du moteur PDFium de Google, sous Apache 2.0) à une échelle de 2,5× — soit environ 180 DPI, suffisant pour une reconnaissance de caractères fiable. Chaque image passe ensuite par tesseract avec un modèle multilingue chargé : eng+spa+por+fra+deu+pol+ita+tur. Tesseract détermine la langue réelle à partir de la forme des glyphes.

Nous avons délibérément abandonné PyMuPDF — la bibliothèque PDF Python la plus populaire — parce que sa licence AGPL est gênante pour un service hébergé. Le passage à pypdfium2 nous a pris un après-midi et a totalement éliminé le risque juridique. À savoir si vous développez quoi que ce soit en lien avec le PDF pour un produit commercial.

3. Détection automatique de la langue

Le livre de la lectrice était en espagnol, mais la langue de son interface était l'anglais — donc avant notre correctif, même si l'OCR avait fonctionné, le pipeline aurait synthétisé du texte espagnol avec une voix anglaise (robotique, mal prononcée). Désormais, la détection de la langue elle-même utilise le texte issu de l'OCR. Après 3 pages d'échantillon, langdetect classe le contenu et choisit la bonne voix — en l'occurrence, l'espagnol d'Amérique latine.

4. Un échec honnête

Si l'OCR récupère tout de même moins de 100 caractères (PDF purement décoratifs, fichiers cassés), nous renvoyons désormais une erreur claire au lieu de générer du silence : "Ce PDF ne contient pas de texte exploitable. Veuillez envoyer un fichier EPUB, TXT ou un PDF basé sur du texte." La tâche d'audiolivre est marquée comme échouée, aucun e-mail n'est envoyé, aucun crédit n'est facturé.

Le résultat

Nous avons relancé le PDF de la lectrice dans le pipeline reconstruit. Cinq minutes d'OCR ont extrait 144 710 caractères d'espagnol propre à partir de ses 74 pages scannées. Le pipeline les a ensuite découpés en 1 127 segments et a produit un audiolivre de 2 heures 43 minutes avec synchronisation lecture-audio — surlignage mot à mot lié à l'audio. Nous lui avons écrit en espagnol, à nos frais, en nous excusant pour le premier essai.

L'ensemble de la régénération a pris environ 90 minutes de temps réel : à peu près 5 minutes pour l'OCR, 80 minutes pour la synthèse vocale, et quelques minutes pour la normalisation audio (EBU R128) et la finalisation M4A. C'est plus lent qu'un PDF texte — mais ça fonctionne. Avant, ça ne fonctionnait pas du tout.

Ce que cela signifie si vous avez une étagère pleine de scans

Si vous accumulez des livres scannés — vieilles rééditions, romans épuisés, numérisations du domaine public depuis archive.org, vos propres scans du livre de recettes de votre grand-mère — ils ne sont plus prisonniers du papier. Envoyez-les. Nous nous chargeons de l'OCR.

Pour l'instant, nous faisons de l'OCR dans 12 langues : anglais, espagnol, portugais, français, allemand, polonais, italien, turc, arabe, japonais, coréen, hindi. L'audiolivre lui-même peut être généré dans n'importe laquelle de 23 langues vocales. Si votre livre scanné est dans une langue que nous ne reconnaissons pas encore via l'OCR, envoyez-nous un mot — ajouter un pack linguistique tesseract ne prend que quelques minutes.

Un mot sur la licence commerciale

L'ensemble de la pile OCR que nous utilisons — tesseract, pypdfium2, pytesseract — est sous Apache 2.0. Cela compte si vous construisez quelque chose de similaire : PyMuPDF est la solution de facilité pour le rendu PDF en Python, mais sa licence AGPL vous oblige à ouvrir le code source de toute votre application SaaS si vous l'utilisez en production. pypdfium2 + tesseract vous offrent les mêmes capacités sans aucune obligation de licence en retour.

Le bug qui nous a rendus meilleurs

La plupart des bugs en production sont attrapés en phase de test. Pas celui-ci, parce que l'hypothèse — "les PDF contiennent du texte" — tenait pour tous les fichiers de développement que nous avions jamais utilisés. Il a fallu une vraie lectrice du Chili, dans sa première heure sur la plateforme, pour le faire émerger.

Alors merci, lectrices et lecteurs réels. Vous trouvez les bugs que nous ne pouvons pas trouver.