Édition PDF dans le navigateur — fonctionnement et vie privée

Chaque fois que vous téléversez un document vers un outil PDF en ligne, ce document existe sur des serveurs que vous ne contrôlez pas, traité par un logiciel que vous ne pouvez pas inspecter, stocké par une entreprise qui a ses propres politiques de conservation des données et sa propre posture de sécurité. Pendant un moment, l'infrastructure d'un tiers détient vos contrats, déclarations fiscales, dossiers médicaux ou documents professionnels confidentiels.

LuraPDF fonctionne différemment. Tout se passe dans votre onglet de navigateur, sur votre matériel, avec la gestion de la mémoire de votre système d'exploitation. Cet article explique l'architecture technique qui rend cela possible et les compromis d'ingénierie impliqués.

Le navigateur comme plateforme de traitement documentaire

Les navigateurs modernes ne sont plus de simples moteurs de rendu HTML. Ce sont des environnements d'exécution d'applications complètes dotés de :

• Moteur JavaScript (V8 dans Chrome, SpiderMonkey dans Firefox) : exécute du code à une vitesse proche du natif
• WebAssembly (WASM) : exécute du code C/C++ compilé à une vitesse proche du natif dans un environnement isolé
• Canvas API : permet la manipulation d'images au niveau du pixel
• File System Access API : permet de lire des fichiers locaux sans téléversement
• Web Workers : exécute des calculs sur des threads en arrière-plan sans bloquer l'interface
• ArrayBuffer / Blob : gère les données binaires brutes (comme les octets d'un PDF) en mémoire

Ces capacités réunies permettent un pipeline de traitement documentaire complet qui aurait nécessité un serveur back-end il y a cinq ans.

Les trois bibliothèques principales

LuraPDF est construit sur trois bibliothèques open source fondamentales :

pdf-lib

pdf-lib est une bibliothèque TypeScript permettant de créer et de modifier des documents PDF dans n'importe quel environnement JavaScript. Elle implémente une part substantielle de la spécification PDF (ISO 32000), notamment :

• Création, modification et suppression de pages
• Intégration de polices (les 14 polices standard et les polices TTF/OTF personnalisées)
• Intégration d'images (JPEG, PNG)
• Placement d'annotations textuelles
• Création et manipulation de champs de formulaire
• Métadonnées du document (titre, auteur, date de création, etc.)
• Protection du document par mot de passe
• Gestion de la table de références croisées

Lorsque LuraPDF fusionne des PDF, il utilise pdf-lib pour lire l'arborescence des pages de chaque document, normaliser les ressources partagées et assembler un nouveau PDF. Lorsqu'il compresse, il réencode les objets image avec des facteurs de qualité inférieurs. Lorsqu'il protège un fichier par mot de passe, il dérive une clé à partir de votre mot de passe et écrit un document chiffré en utilisant le gestionnaire de sécurité standard PDF, compris par tous les lecteurs.

pdf-lib opère entièrement sur des objets ArrayBuffer — des données binaires brutes en mémoire du navigateur. Aucun appel réseau n'est effectué.

pdfjs-dist

PDF.js est le moteur de rendu PDF de Mozilla, distribué sous le nom pdfjs-dist sur npm. C'est le moteur qui alimente le lecteur PDF intégré de Firefox, testé sur des millions de PDF réels.

LuraPDF utilise pdfjs-dist pour :

• Le rendu des pages : conversion des pages PDF en ImageData Canvas pour l'affichage
• L'extraction de texte : lecture des flux de contenu textuel des pages PDF
• Les métadonnées de page : récupération des dimensions, valeurs de rotation et type de contenu des pages

Lorsque vous voyez votre PDF rendu dans l'interface LuraPDF — l'aperçu visuel des pages — c'est pdfjs-dist qui effectue le rendu de chaque page sur un élément HTML Canvas.

Tesseract.js

Tesseract.js est la version compilée en WebAssembly de Tesseract OCR. Tesseract est un moteur OCR open source développé à l'origine par HP Labs (1985) et actuellement maintenu par Google. Il utilise un modèle de réseau de neurones LSTM (Long Short-Term Memory) pour la reconnaissance de caractères.

L'exécution de Tesseract via WebAssembly dans le navigateur signifie que :

• Le binaire WASM de 22 MB est chargé une fois et mis en cache par le navigateur
• Le traitement OCR s'exécute sur CPU via WebAssembly, pas sur GPU
• Le traitement est plus lent que l'OCR cloud (qui utilise des clusters GPU) mais produit la même qualité de résultat
• Le contenu de votre document ne quitte jamais votre appareil

Pour un document de 20 pages numérisées : l'OCR navigateur prend environ 30 à 120 secondes. Un service cloud pourrait prendre 2 à 5 secondes. Le compromis est vie privée contre vitesse.

L'architecture : du fichier au résultat

Voici ce qui se passe lorsque vous compressez, par exemple, un PDF dans LuraPDF :

1. Sélection du fichier : vous faites glisser un PDF sur la zone de dépôt. L'API File du navigateur lit le fichier dans un ArrayBuffer — des octets bruts en mémoire du navigateur. Aucun téléversement n'a lieu.

2. Validation : une vérification rapide que les octets magiques %PDF apparaissent au début de l'ArrayBuffer.

3. Chargement : la méthode PDFDocument.load() de pdf-lib analyse la table de références croisées, lit l'arborescence d'objets et construit une représentation en mémoire du document.

4. Énumération des images : la bibliothèque parcourt les flux de contenu des pages pour trouver les XObjects image (images incorporées). La largeur, la hauteur, le type de compression et les données en octets de chaque image sont extraits.

5. Réencodage : pour chaque image, les données de pixels bruts sont dessinées sur un élément HTML Canvas, puis réexportées avec un facteur de qualité JPEG inférieur via canvas.toBlob('image/jpeg', quality). L'objet image original est remplacé par la version encodée plus petite.

6. Sérialisation du document : la méthode save() de pdf-lib sérialise le document modifié en octets. Les flux d'objets sont compressés avec DEFLATE.

7. Téléchargement : les octets sont encapsulés dans un objet Blob, une URL d'objet temporaire est créée (URL.createObjectURL(blob)), et un clic programmatique sur <a> déclenche le mécanisme de téléchargement du navigateur.

Total des données transmises à un serveur externe : zéro octet.

Web Workers : maintenir l'interface réactive

Le traitement PDF est gourmand en CPU. L'exécuter sur le thread JavaScript principal bloquerait l'onglet du navigateur — vous ne pourriez plus défiler, cliquer ni voir les mises à jour de progression pendant le traitement du fichier.

LuraPDF exécute tous les calculs intensifs (OCR, analyse de grands PDF, réencodage d'images) dans des Web Workers — des threads JavaScript séparés qui s'exécutent en arrière-plan. Le thread principal gère l'interface, affiche les barres de progression et communique avec le worker via des messages (postMessage / onmessage).

Lors de l'exécution de l'OCR, un événement de progression se déclenche après le traitement de chaque page. Le worker envoie { page: 5, total: 20, confidence: 94 } au thread principal, qui met à jour la barre de progression. Votre interface reste interactive tout au long du processus.

Gestion de la mémoire

La mémoire du navigateur est limitée. Un PDF de 200 MB chargé en mémoire, traité et sauvegardé peut nécessiter 400 à 600 MB de RAM (octets originaux + données Canvas intermédiaires + octets de sortie). Sur les systèmes disposant de peu de RAM, cela peut déclencher une pression mémoire.

Stratégies utilisées :

• Traitement des pages en flux : pour les opérations multi-pages, les pages sont traitées et les éléments Canvas intermédiaires sont supprimés après utilisation
• URL.revokeObjectURL() : les URL de blob temporaires sont révoquées après le téléchargement pour permettre au ramasse-miettes d'agir
• Arrêt des workers : les Web Workers sont arrêtés après avoir accompli leur tâche afin de libérer la mémoire qu'ils utilisaient

Pour les très grands fichiers (>100 MB), les navigateurs modernes gèrent cela sans problème sur les systèmes disposant de 8+ GB de RAM. Les systèmes plus anciens ou à mémoire limitée peuvent avoir des difficultés avec des fichiers source de 100+ MB.

L'architecture de confidentialité

Le modèle de sécurité est imposé par la politique de même origine du navigateur et son architecture d'isolation :

• Pas de requêtes HTTP : pas d'appels API externes, pas de télémétrie, pas d'appels analytiques pendant le traitement des documents
• Exécution isolée : les Web Workers ne peuvent pas effectuer d'appels réseau vers des origines externes
• Pas de stockage persistant : les fichiers traités ne sont pas écrits dans le stockage du navigateur (localStorage, IndexedDB ou File System Access)
• Mémoire limitée à l'onglet : lorsque vous fermez l'onglet, tous les ArrayBuffers et objets Blob associés sont récupérés par le ramasse-miettes

Cette architecture est vérifiable : ouvrez l'onglet Réseau des DevTools du navigateur pendant le traitement d'un fichier. Vous verrez zéro requête pendant l'opération de traitement.

Bibliothèques open source : inspectables, pas des boîtes noires

Les trois bibliothèques principales — pdf-lib, pdfjs-dist et Tesseract.js — sont open source avec des dépôts publics sur GitHub. Les implémentations sont inspectables par n'importe qui. Le code de traitement PDF qui s'exécute dans LuraPDF n'est pas une boîte noire propriétaire ; c'est du code public avec de vrais utilisateurs, des issues et des contributions.

Cela compte pour la confiance. Lorsqu'un service cloud affirme « nous traitons et supprimons vos fichiers », vous prenez leur parole. Lorsque LuraPDF utilise des bibliothèques open source dans un sandbox de navigateur sans appels réseau, vous pouvez vérifier cette affirmation en observant l'onglet réseau.

Compromis par rapport au traitement cloud

Le modèle basé sur le navigateur présente de vrais compromis qu'il convient d'énoncer honnêtement :

Vitesse : les services cloud disposent de clusters GPU et d'une infrastructure dédiée. L'OCR navigateur sur un document volumineux prend 2 à 10 fois plus longtemps que son équivalent cloud. La compression est rapide car elle utilise directement l'API Canvas.

Limites de taille de fichier : la mémoire du navigateur est la contrainte. Les très grands fichiers (>300 MB) peuvent atteindre les limites de mémoire sur certains systèmes. Les services cloud n'ont pas cette contrainte.

Puissance de traitement : WASM s'exécute à 40 à 80 % de la vitesse du C++ natif. Les services cloud exécutent du code natif optimisé. Pour la plupart des documents, cette différence est imperceptible ; pour les tâches OCR de 100+ pages, elle est notable.

Fonctionnalités : certaines fonctionnalités PDF avancées (vérification de conformité PDF/X, gestion professionnelle des couleurs, flux de travail CMYK) nécessitent des outils serveur spécialisés. Le traitement basé sur le navigateur couvre 95 % des cas.

Pour le traitement documentaire quotidien — compression, fusion, signature, conversion, caviardage — le modèle basé sur le navigateur est suffisamment rapide, privé par conception, et ne nécessite ni compte ni abonnement.

Questions fréquentes

LuraPDF collecte-t-il des données de télémétrie ou d'utilisation ? LuraPDF utilise Google Analytics pour des statistiques agrégées de pages vues. Les opérations de traitement de documents ne génèrent aucun événement analytique. Le contenu de vos fichiers n'est jamais transmis.

Puis-je vérifier qu'aucun téléversement n'a lieu ? Oui. Ouvrez les Outils de développement (F12), cliquez sur l'onglet Réseau, filtrez par « XHR » ou « Fetch ». Traitez un fichier. Observez zéro requête réseau liée au document pendant le traitement.

Pourquoi l'OCR prend-il autant de temps par rapport à d'autres services ? Tesseract.js basé sur le navigateur s'exécute sur CPU via WebAssembly. Les services OCR cloud s'exécutent sur des clusters GPU qui traitent les caractères des ordres de grandeur plus rapidement. Le compromis est que votre document ne quitte jamais votre navigateur.

Que se passe-t-il si je ferme l'onglet pendant le traitement ? Le traitement s'arrête immédiatement. La mémoire de l'onglet du navigateur est récupérée par le ramasse-miettes. Votre fichier original sur le disque reste inchangé.

Le code est-il open source ? Les bibliothèques de traitement principales (pdf-lib, pdfjs-dist, Tesseract.js) sont open source. Le code d'interface de LuraPDF n'est pas actuellement open source, mais le pipeline de traitement n'utilise que des composants open source.

Le passage au traitement documentaire basé sur le navigateur n'est pas un gadget. C'est un vrai choix architectural avec des avantages mesurables en termes de confidentialité et de confiance — au prix de la vitesse pour les opérations intensives. Pour les documents que vous préféreriez ne pas voir exister sur le serveur de quelqu'un d'autre, c'est le bon compromis.