Les outils PDF de navigateur sont-ils confidentiels ?

Ce que « dans le navigateur » veut dire au juste

Quand vous choisissez un fichier dans une page web, le navigateur ne l’envoie pas en ligne. Il remet à la page un objet File via l’API File : une référence vers des octets qui existent déjà sur votre disque. La page peut lire ces octets en mémoire et en faire ce qu’elle veut. Les envoyer à un serveur est un acte distinct et explicite — la page doit construire une requête réseau et transmettre les données intentionnellement.

Un site PDF classique envoie votre fichier, exécute un moteur sur un serveur et vous renvoie un résultat. Votre document quitte votre machine, atterrit sur un disque quelque part, et vous vous en remettez à une politique de conservation que vous ne pouvez pas inspecter. Un outil qui travaille dans le navigateur saute toutes ces étapes, parce que le travail a lieu dans le moteur JavaScript qui tourne déjà sur votre propre ordinateur.

Mais l’API File se contente de rendre le traitement local possible ; elle ne rend pas l’envoi impossible. Une page qui lit votre fichier localement puis l’expédie aussi vers un serveur reste du HTML parfaitement ordinaire. C’est pourquoi la suite de cet article parle de vérifier plutôt que de faire confiance.

Comment cela fonctionne sur iBuildPDF

Chaque outil du site suit les quatre mêmes étapes.

1. Lecture. Le fichier que vous avez sélectionné est lu dans un ArrayBuffer — un bloc d’octets bruts dans la mémoire de l’onglet.
2. Analyse ou rendu. Le travail structurel (fusion, division, rotation, modification des métadonnées, apposition de filigranes, numérotation des pages) est effectué avec pdf-lib 1.17.1, qui analyse le graphe d’objets du PDF et écrit un nouveau document. Tout ce qui nécessite de voir une page sous forme de pixels (miniatures de page, export en images, rastérisation) fait appel à Mozilla PDF.js 3.11.174 pour dessiner la page dans un canvas.
3. Production. Le document terminé est sérialisé en octets et encapsulé dans un Blob — toujours de la simple mémoire, à l’intérieur de l’onglet.
4. Téléchargement. La page appelle URL.createObjectURL() sur ce Blob, ce qui crée une URL blob: pointant vers les données en mémoire, et déclenche un téléchargement depuis celle-ci. Une URL blob: ne touche jamais le réseau ; c’est une référence vers quelque chose que l’onglet détient déjà.

Les deux bibliothèques sont chargées depuis un CDN public, à ces versions figées. C’est bien une requête réseau et vous la verrez — mais elle a lieu au chargement de la page, elle récupère du JavaScript, et elle ne transporte rien qui vous appartienne.

Rien de tout cela n’exige de compte. Les comptes n’existent que pour des commodités comme les favoris et les outils récents, et se connecter ne change rien au lieu où votre fichier est traité.

Comment le vérifier vous-même

Ne nous croyez pas sur parole. Deux vérifications tranchent la question, et aucune ne demande de bagage technique au-delà du fait de suivre les étapes.

Vérification n° 1 : observer le réseau

Ouvrez n’importe quel outil — compresser un PDF ou fusionner des PDF feront l’affaire. Appuyez sur F12 (ou Cmd+Option+I sur un Mac) pour ouvrir les outils de développement et sélectionnez l’onglet Réseau. Cochez Conserver le journal pour que rien ne soit effacé, puis rechargez la page.

Vous verrez le chargement initial : le document HTML, le CSS, le JavaScript propre au site, et les requêtes vers le CDN pour pdf-lib et pdf.js. Cliquez maintenant sur le bouton d’effacement pour vider la liste, et seulement ensuite choisissez votre fichier et lancez l’outil.

Ce que vous devriez voir une fois le traitement terminé, c’est rien, ou presque. Aucune requête n’apparaît dont la taille approche celle de votre document. Si une requête apparaissait, vous pourriez cliquer dessus et lire son onglet Charge utile pour voir exactement ce qui a été envoyé. Le téléchargement lui-même n’apparaîtra pas du tout comme une requête serveur, puisqu’il provient d’une URL blob:.

Un contrôle de bon sens utile : notez la taille de votre fichier, puis triez le panneau Réseau par sa colonne Taille. Un envoi y serait impossible à dissimuler.

Vérification n° 2 : débrancher

C’est le test le plus probant, car il ne dépend d’aucune interprétation. Chargez la page de l’outil et attendez qu’elle soit entièrement chargée. Coupez ensuite votre Wi-Fi, ou réglez la liste de limitation du panneau Réseau sur Hors ligne.

Utilisez maintenant l’outil. Choisissez un fichier, traitez-le, téléchargez le résultat. Cela fonctionne. Un outil qui aurait eu besoin d’un serveur n’aurait pas pu produire ce fichier, puisqu’il n’y avait aucun serveur à joindre.

La seule chose à respecter, c’est l’ordre : les bibliothèques doivent se trouver dans le cache du navigateur avant que vous ne passiez hors ligne, puisqu’elles sont récupérées au chargement de la page. Chargez d’abord, déconnectez ensuite, traitez enfin.

Ce contre quoi cela ne vous protège pas

Le traitement local est une propriété réelle, avec des limites réelles. Quatre d’entre elles comptent.

• C’est une propriété de la mise en œuvre, pas des navigateurs. Rien dans la plateforme web n’empêche une page d’envoyer un fichier qu’elle a lu. « Cela s’exécute dans le navigateur » est une affirmation sur ce que fait le JavaScript d’un site donné, et la seule raison d’y croire est de l’avoir vérifié — d’où la section ci-dessus.
• Les statistiques d’usage ne sont pas le contenu des fichiers. Le site peut enregistrer qu’un outil a été utilisé. Il n’enregistre ni le fichier, ni son nom, ni sa taille, ni rien qui en soit tiré, parce que ces données n’atteignent jamais, au départ, la couche analytique de la page.
• Votre appareil est la frontière de confiance. Une extension de navigateur autorisée à lire le contenu des pages, ou une machine compromise, se situent à l’intérieur de cette frontière, et aucune page web ne peut rien y faire. Si un document est assez sensible pour vous inquiéter, l’état de la machine sur laquelle vous l’ouvrez compte davantage que le site dans lequel vous l’ouvrez.
• La mémoire est le plafond. Comme tout se passe dans un seul onglet de navigateur, les documents très volumineux sont limités par la RAM disponible plutôt que par une limite d’envoi. Nous expliquons où se situe réellement cette frontière dans quelle taille de PDF un navigateur peut traiter.

Quand un serveur est réellement nécessaire

Certaines tâches ne peuvent honnêtement pas être faites dans un onglet. Convertir un PDF en fichier Word, Excel ou PowerPoint modifiable suppose de reconstruire un modèle de document — paragraphes, styles, tableaux — à partir d’un format qui ne fait qu’enregistrer où placer des marques sur une page. Cela demande des moteurs d’analyse de mise en page qui n’existent pas en JavaScript de navigateur. La reconnaissance optique de caractères relève du même constat. iBuildPDF ne fait pas d’OCR du tout ; il n’existe aucun outil de ce type sur le site.

Si un fichier part vers un serveur, son parcours change de nature. Il est transmis, écrit sur un support de stockage, lu par un processus de traitement, puis conservé jusqu’à ce que quelque chose le supprime. Chaque étape est un endroit où une copie peut survivre au-delà de ce que vous imaginez, et aucune n’est visible pour vous.

Les convertisseurs PDF↔Word, PDF↔Excel et PDF↔PowerPoint d’iBuildPDF sont annoncés comme à venir et sont désactivés. C’est délibéré : un convertisseur qui ne peut pas s’exécuter localement n’est pas livré en douce avec un envoi de fichier à la clé. Quand ces outils seront activés, ils dépendront d’un serveur, et la page le dira.

Tout le reste — les 31 outils en ligne, y compris le caviardage, la suppression des métadonnées et l’extraction de texte — s’exécute localement dès aujourd’hui. Le détail technique complet figure sur la page de référence sur la confidentialité des fichiers.