Comment fonctionne l'édition de PDF via navigateur (et pourquoi la confidentialité est importante)

Chaque fois que vous téléchargez un document sur un outil PDF en ligne, ce document est stocké sur des serveurs que vous ne contrôlez pas, traité par un logiciel que vous ne pouvez pas examiner, et entreposé par une entreprise qui applique ses propres politiques de conservation et de sécurité des données. Pendant un court laps de temps, l'infrastructure d'un tiers héberge vos contrats, déclarations fiscales, dossiers médicaux ou documents commerciaux confidentiels.

LuraPDF fonctionne différemment. Tout se passe dans l'onglet de votre navigateur, sur votre ordinateur, 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 que cela implique.

Le navigateur en tant que plateforme de traitement de documents

Les navigateurs modernes ne sont plus de simples moteurs de rendu HTML. Ce sont des environnements d'exécution d'applications complets avec :

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

Ces fonctionnalités combinées permettent de mettre en place un pipeline de traitement de documents complet qui aurait nécessité un serveur dorsal il y a cinq ans.

Les trois bibliothèques principales

LuraPDF repose 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 importante de la spécification PDF (ISO 32000), notamment :

• Création, modification et suppression de pages
• Incorporation de polices (polices standard 14 et polices TTF/OTF personnalisées)
• Intégration d'images (JPEG, PNG)
• Placement des annotations textuelles
• Création et manipulation des champs de formulaire
• Métadonnées du document (titre, auteur, date de création, etc.)
• Chiffrement PDF (AES-128 et AES-256)
• Gestion des tableaux de correspondance

Lors de la fusion de fichiers PDF, LuraPDF utilise pdf-lib pour lire l'arborescence des pages de chaque document, normaliser les ressources partagées et assembler un nouveau PDF. Lors de la compression, les images sont réencodées avec un facteur de qualité inférieur. Lors du chiffrement, le chiffrement AES-256 est appliqué au document via l'API Web Crypto.

pdf-lib fonctionne exclusivement avec des objets ArrayBuffer — des données binaires brutes stockées dans la mémoire du navigateur. Aucun appel réseau n'est effectué.

pdfjs-dist

PDF.js (https://mozilla.github.io/pdf.js/) est le moteur de rendu PDF de Mozilla, distribué sous le nom pdfjs-dist sur npm. Il alimente la visionneuse PDF intégrée à Firefox et a été testé sur des millions de fichiers PDF réels.

LuraPDF utilise pdfjs-dist pour :

• Rendu de page : Conversion des pages PDF en Canvas ImageData pour l’affichage
• Extraction de texte : Lecture des flux de contenu textuel des pages PDF
• Métadonnées de la page : Obtention des dimensions de la page, des valeurs de rotation et du type de contenu

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

Tesseract.js

Tesseract.js (https://tesseract.projectnaptha.com) est la version compilée en WebAssembly du moteur de reconnaissance optique de caractères Tesseract. Tesseract est un moteur OCR open source initialement développé par HP Labs (1985) et actuellement maintenu par Google. Il utilise un modèle de réseau neuronal LSTM (Long Short-Term Memory) pour la reconnaissance de caractères.

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

Le fichier binaire WASM de 22 Mo est chargé une seule fois et mis en cache par le navigateur. Le traitement OCR s'exécute sur le processeur via WebAssembly, et non sur le GPU. Le traitement est plus lent que l'OCR dans le cloud (qui utilise des clusters de GPU), mais la qualité du résultat est identique.

• Le contenu de vos documents ne quitte jamais votre appareil

Pour la numérisation de 20 pages : la reconnaissance optique de caractères (OCR) via navigateur prend environ 30 à 120 secondes. Un service cloud peut prendre de 2 à 5 secondes. Le compromis réside dans la protection de la vie privée face à la rapidité.

L'architecture : du fichier à la sortie

Voici ce qui se passe lorsque vous compressez un PDF avec LuraPDF :

1. Sélection de fichier : Vous faites glisser un PDF dans la zone de dépôt. L’API File du navigateur lit le fichier et le stocke dans un ArrayBuffer (octets bruts) en mémoire. Aucun transfert de fichier n’est effectué.

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

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

4. Énumération des images : La bibliothèque parcourt le contenu de la page pour trouver les objets XObject (images intégrées). La largeur, la hauteur, le type de compression et les données binaires de chaque image sont extraits.

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

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 enveloppés dans un objet Blob, une URL d'objet temporaire est créée ( URL.createObjectURL(blob) ), et un clic programmatique <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 : Garantir la réactivité de l’interface utilisateur

Le traitement des fichiers PDF sollicite beaucoup le processeur. L'exécuter sur le thread JavaScript principal bloquerait l'onglet du navigateur : il serait impossible de faire défiler, de cliquer ou de voir les mises à jour de progression pendant le traitement du fichier.

LuraPDF exécute tous les calculs lourds (OCR, analyse de PDF volumineux, réencodage d'images) dans des Web Workers — des threads JavaScript distincts s'exécutant en arrière-plan. Le thread principal gère l'interface utilisateur, affiche les barres de progression et communique avec les Web Workers par échange de messages (postMessage / onmessage).

Pendant l'exécution de la reconnaissance optique de caractères (OCR), un événement de progression est déclenché après le traitement de chaque page. Le processus envoie { page: 5, total: 20, confidence: 94 } au thread principal, qui met à jour la barre de progression. Votre interface utilisateur reste interactive tout au long du processus.

Gestion de la mémoire

La mémoire du navigateur est limitée. Un PDF de 200 Mo chargé en mémoire, traité et enregistré peut nécessiter entre 400 et 600 Mo de RAM (données originales + données Canvas intermédiaires + données de sortie). Sur les systèmes disposant d'une RAM limitée, cela peut entraîner une saturation de la mémoire.

Stratégies utilisées :

• Traitement des pages en flux continu : Pour les opérations multipages, les pages sont traitées et les éléments Canvas intermédiaires sont supprimés après utilisation.
• URL.revokeObjectURL() : Les URL des blobs temporaires sont révoquées après le téléchargement pour permettre le nettoyage de la mémoire.
• Arrêt des Web Workers : Les Web Workers sont arrêtés une fois leur tâche terminée afin de libérer la mémoire utilisée.

Pour les fichiers très volumineux (plus de 100 Mo), les navigateurs modernes les gèrent sans problème sur les systèmes dotés de 8 Go de RAM ou plus. Les systèmes plus anciens ou disposant de peu de mémoire peuvent rencontrer des difficultés avec les fichiers sources de plus de 100 Mo.

L'architecture de la confidentialité

Le modèle de sécurité est appliqué par la politique d'origine identique et l'architecture d'isolation du navigateur :

• Aucune requête HTTP : aucun appel d’API externe, aucune télémétrie, aucun appel d’analyse pendant le traitement des documents
• Exécution en mode sandbox : Les Web Workers ne peuvent pas effectuer d’appels réseau vers des origines externes.
• Aucun stockage persistant : les fichiers traités ne sont pas écrits dans le stockage du navigateur (localStorage, IndexedDB ou accès au système de fichiers).
• Mémoire limitée à l'onglet : Lorsque vous fermez l'onglet, tous les objets ArrayBuffer et Blob qui y sont associés sont supprimés par le ramasse-miettes.

Cette architecture est vérifiable : ouvrez l’onglet Réseau du navigateur dans les outils de développement pendant le traitement d’un fichier. Vous constaterez l’absence totale de requêtes durant cette opération.

Bibliothèques open source : inspectables, pas de boîte noire

Les trois bibliothèques principales — pdf-lib, pdfjs-dist et Tesseract.js — sont open source et leurs dépôts sont publics sur GitHub. Leurs implémentations sont accessibles à tous. Le code de traitement PDF exécuté par LuraPDF n'est pas une boîte noire propriétaire ; il s'agit d'un code public, utilisé par de vrais utilisateurs, avec des problèmes signalés et des contributions.

C'est essentiel pour la confiance. Lorsqu'un service cloud affirme « nous traitons et supprimons vos fichiers », vous vous fiez à sa parole. Avec LuraPDF, qui utilise des bibliothèques open source dans un environnement isolé du navigateur sans accès au réseau, vous pouvez vérifier cette affirmation en consultant l'onglet Réseau.

Compromis par rapport au traitement dans le cloud

Le modèle basé sur un navigateur présente de réels compromis qu'il convient d'aborder honnêtement :

Vitesse : Les services cloud disposent de clusters de GPU et d’une infrastructure dédiée. La reconnaissance optique de caractères (OCR) effectuée par navigateur sur un document volumineux prend 2 à 10 fois plus de temps qu’avec un service cloud équivalent. La compression est rapide car elle utilise directement l’API Canvas.

Limites de taille des fichiers : La mémoire du navigateur est la limite. Les fichiers très volumineux (> 300 Mo) peuvent atteindre cette limite sur certains systèmes. Les services cloud ne sont pas soumis à cette limitation.

Puissance de traitement : WASM fonctionne à 40–80 % de la vitesse du C++ natif. Les services cloud utilisent du code natif optimisé. Pour la plupart des documents, cette différence est imperceptible ; pour les tâches d’OCR de plus de 100 pages, elle est notable.

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

Pour le traitement quotidien des documents (compression, fusion, signature, conversion, rédaction), le modèle basé sur le navigateur est suffisamment rapide, respectueux de la vie privée par conception et ne nécessite aucun compte ni abonnement.

Foire aux questions

LuraPDF collecte-t-il des données de télémétrie ou d'utilisation ? LuraPDF utilise Google Analytics pour obtenir des statistiques globales sur le nombre de pages vues. Le traitement des documents ne génère aucun événement analytique. Le contenu de vos fichiers n'est jamais transmis.

Puis-je vérifier qu'aucun téléchargement n'a lieu ? Oui. Ouvrez les outils de développement (F12), cliquez sur l'onglet Réseau, filtrez par « XHR » ou « Récupérer ». Traitez un fichier. Vous ne devriez observer aucune requête réseau liée au document pendant le traitement.

Pourquoi la reconnaissance optique de caractères (OCR) est-elle si longue par rapport à d'autres services ? Tesseract.js, qui s'exécute dans un navigateur, utilise le processeur via WebAssembly. Les services OCR dans le cloud, quant à eux, s'appuient sur des clusters de GPU qui traitent les caractères beaucoup plus rapidement. En contrepartie, votre document reste toujours dans 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 libérée. Votre fichier d'origine 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 encore open source, mais le pipeline de traitement utilise exclusivement des composants open source.

Le passage au traitement de documents via navigateur n'est pas un gadget. Il s'agit d'un véritable choix architectural offrant des avantages tangibles en matière de confidentialité et de confiance, au détriment de la vitesse des opérations intensives. Pour les documents que vous préférez ne pas voir stockés sur le serveur d'un tiers, c'est le compromis idéal.