Pourquoi nous avons construit nos outils PDF pour qu'ils tournent dans votre navigateur
Un regard honnête sur le compromis confidentialité/performance des outils PDF basés sur WASM — et pourquoi envoyer des fichiers pour des opérations simples est un mauvais défaut.
Tous les grands outils PDF en ligne — iLovePDF, Smallpdf, Sejda, PDF24 — fonctionnent pareil : vous envoyez votre fichier, leurs serveurs le traitent, vous téléchargez le résultat. Ça marche. C’est aussi un défaut étrange que personne ne questionne.
Nous faisons les choses différemment. Chaque outil gratuit sur RectoPDF s’exécute entièrement dans votre navigateur. Pas d’envoi, pas de traitement côté serveur, pas de « nous avons supprimé votre fichier après 30 minutes ». Il n’y a rien à supprimer parce qu’il n’y a rien à recevoir.
Ce post explique pourquoi nous avons fait ce choix, ce que ça vous coûte (oui, il y a des compromis), et ce que vous obtenez vraiment.
Le coût caché du modèle d’envoi
Quand vous envoyez un PDF à un outil « gratuit en ligne », plusieurs choses se passent :
- Votre fichier voyage sur le réseau. S’il est sensible — un contrat, une facture médicale, un rapport interne — il est maintenant en vol, puis brièvement sur le disque de quelqu’un d’autre.
- Le serveur le traite. Ce serveur a des journaux. Il a des dumps de crash. Il a des sauvegardes. La « politique de suppression » ne s’applique généralement qu’à la copie primaire.
- Vous faites implicitement confiance aux affirmations de l’opérateur. La plupart sont réputés. Certains ont eu des fuites. La garantie de confidentialité est au mieux « promesse ».
Pour les outils gratuits, « gratuit » signifie presque toujours votre fichier va bien mais la trace de données pas forcément. Vous faites confiance à la promesse d’un fournisseur. Avec les petits opérateurs, cette promesse n’est qu’à un changement de configuration ou une fuite près d’être fausse.
Pour un PDF public et non sensible, rien de tout cela ne compte. Pour un document RH, un contrat, un relevé financier, ou tout ce que vous préféreriez garder privé — ça compte beaucoup. Et la facilité du « bon je vais juste l’envoyer vite » est celle de normaliser lentement l’envoi de documents privés aux serveurs d’inconnus.
Ce qui a changé : les navigateurs sont devenus puissants
La raison pour laquelle personne ne faisait ça en 2015 est que les navigateurs ne pouvaient pas. La manipulation PDF nécessite :
- Un parseur/sérialiseur du format PDF (kilooctets de code, mais précis).
- Des bibliothèques de compression (Flate, LZW, JPEG).
- Pour certains outils : la cryptographie (AES, MD5, dérivation de clé).
- Pour certains outils : le décodage/encodage d’images (PNG, JPEG, JP2, TIFF).
Tout cela nécessitait du code natif sur un serveur. Vers 2020, deux choses ont convergé :
- WebAssembly a mûri. Du code natif compilé en WebAssembly tourne à une vitesse quasi native dans les onglets de navigateur.
- Des bibliothèques PDF matures existent désormais pour JavaScript comme pour WebAssembly, produisant des sorties propres et conformes aux standards.
Soudain, les mêmes opérations qu’un serveur faisait pouvaient se faire dans votre onglet. Il n’y a plus de raison technique d’envoyer — seulement l’inertie.
Ce que vous perdez (et ne perdez pas)
Ce que vous perdez :
- La synchronisation multi-appareils. Si vous avez besoin d’un outil pour « traiter un PDF sur votre téléphone et télécharger sur votre ordinateur portable », ça nécessite un serveur. La plupart des opérations PDF n’en ont pas besoin.
- Les très gros fichiers. La mémoire du navigateur est limitée — un PDF d’1 Go ne s’ouvrira pas dans un onglet. Pour les documents bureautiques typiques (1–50 Mo), ce n’est pas une vraie limite.
- Les opérations que nous n’avons pas encore construites. L’OCR, par exemple, a besoin de modèles qui ne tiennent pas dans un petit module WASM. On y arrivera.
Ce que vous ne perdez pas :
- La performance. Le code compilé en WebAssembly est à peu près aussi rapide que le natif. Notre compresseur PDF traite un PDF de 50 Mo riche en images en 3–5 secondes — comparable aux outils côté serveur, moins l’aller-retour réseau.
- La fonctionnalité. Fusionner, diviser, compresser, pivoter, organiser, image-en-PDF, Word-en-PDF, PDF-en-Word, protéger par mot de passe, déverrouiller — tout dans le navigateur.
- La qualité du format. Nous utilisons les mêmes bibliothèques que les outils côté serveur. Les PDF de sortie sont conformes à la spec. Ils s’ouvrent dans n’importe quel lecteur.
Le modèle mental
Traitez les outils dans le navigateur comme une application de bureau : ils traitent vos fichiers sur votre ordinateur. Le site web n’est qu’un canal de distribution plus pratique qu’installer un logiciel. Pas de compte. Pas d’envoi. Pas de liste de diffusion. Pas d’« essai expire dans 7 jours ».
Quand quelque chose a besoin d’un serveur — un PDF trop gros pour le navigateur, une intégration avec le stockage cloud, un travail de calcul long — c’est ce que nous construirons comme outils Pro. Mais « fusionner trois PDF » n’a pas besoin d’un serveur. Donc il n’en a pas.
Outils à essayer maintenant
- Fusionner PDF — combinez des fichiers localement, réorganisez par glisser.
- Diviser PDF — cliquez sur les pages pour extraire ou diviser en fichiers séparés.
- Compresser PDF — réduisez les PDF riches en images.
- JPG en PDF — regroupez des images en un seul PDF, avec contrôles d’orientation et de marge.
- Protéger PDF — protection par mot de passe AES-128 qui s’exécute dans votre onglet.
Tous gratuits, tous privés par construction. Les données ne quittent pas parce qu’elles ne vont nulle part.