Comment fonctionne le traitement PDF côté client (dans le navigateur, sans téléversement)

« Fonctionne dans votre navigateur » est une affirmation que fait presque chaque site PDF quelque part dans son pied de page. La plupart téléversent quand même votre fichier. Voici ce qui doit réellement être vrai pour que cette affirmation tienne, et comment le vérifier vous-même en moins d’une minute.

L’architecture qui rend cela possible : WebAssembly

La vraie manipulation de PDF — fusionner des pages, réencoder des images, réécrire un flux chiffré — nécessite les mêmes bibliothèques bas niveau que les applications natives. Les navigateurs ne peuvent pas exécuter directement du C/C++/Rust, mais ils peuvent exécuter du WebAssembly (WASM) : ces bibliothèques compilées dans un format binaire que le navigateur exécute à une vitesse quasi native.

C’est la différence entre un outil côté client et un outil « basé navigateur » qui n’est en réalité qu’un formulaire de téléversement plus joli. Une page avec une zone glisser-déposer et une barre de progression peut très bien envoyer discrètement votre fichier en POST vers un serveur dès que vous le déposez. WASM est ce qui permet au traitement réel — pas seulement à l’interface — de se dérouler localement.

Pourquoi cela tourne dans un Web Worker, pas dans le thread principal

Décoder et réécrire un PDF de 100 pages représente un vrai travail processeur. Le faire sur le thread principal du navigateur figerait la page — pas de défilement, pas de clic, un avertissement « onglet ne répond pas » sur tout fichier volumineux. Un Web Worker exécute ce travail sur un thread d’arrière-plan à la place, pour que l’interface reste réactive et que vous obteniez une barre de progression en direct plutôt qu’un onglet figé. Les octets du fichier sont lus en mémoire, transmis au worker, traités, puis renvoyés — le tout dans votre processus navigateur. Rien dans ce flux ne nécessite ou ne bénéficie d’un serveur.

Ce que « pas de téléversement » exclut réellement

Si un outil est véritablement côté client, trois choses en découlent, et toutes trois sont vérifiables :

• Pas de point de téléversement. Il n’y a pas de /api/upload ou équivalent que l’outil pourrait appeler — parce qu’il n’y a rien de l’autre côté à appeler.
• Pas de délai de traitement lié à la taille du fichier et à la vitesse de connexion. Un fichier de 200 Mo sur une connexion lente est lent à téléverser ; un outil côté client avec le même fichier n’est limité que par le processeur de votre appareil, et démarre instantanément.
• Fonctionne hors ligne. Une fois que la page a été chargée une fois (et, pour une PWA, mise en cache par un service worker), l’outil continue de fonctionner sans aucune connexion internet — parce qu’il n’en a jamais eu besoin pour faire le travail.

Comment vérifier vous-même

Vous n’avez pas à croire une affirmation de confidentialité sur parole :

1. Ouvrez les outils de développement → onglet Réseau avant d’exécuter l’outil, puis traitez un fichier. Surveillez toute requête dont la taille de charge utile suit celle de votre fichier. Si rien de tel n’apparaît, le fichier n’a pas quitté le navigateur.
2. Coupez internet, puis réessayez l’outil (après que la page elle-même a été chargée). S’il fonctionne toujours, il n’y a pas de serveur dans la boucle.
3. Vérifiez le poids de la page, pas seulement l’affirmation. Un outil qui effectue un vrai travail localement chargera un moteur WASM — souvent un morceau chargé à la demande de plusieurs centaines de Ko à quelques Mo la première fois que vous utilisez cet outil précis — plutôt qu’un petit script qui se contente d’envoyer un formulaire.

C’est exactement ainsi qu’HivePDF est construit : chaque outil — fusionner, compresser, protéger, caviarder, signer, et le reste — s’exécute via un moteur WASM dédié à chaque tâche dans un Web Worker, sans point de téléversement derrière aucun d’entre eux. Pour un regard plus approfondi sur ce que cela signifie en pratique, voir les outils PDF en ligne sont-ils sûrs et la comparaison honnête d’architecture face aux outils basés serveur.