Outils PDF5 min de lecture
Traiter dans le navigateur : ce que « local » veut dire
Comment une application web peut traiter des fichiers dans le navigateur sans les envoyer, où sont les limites et comment vérifier soi-même.

Une responsable RH à Sion doit réunir en un dossier, pour la direction, cinq candidatures. CV, certificats, diplômes — tout en PDF, avec noms, dates de naissance et adresses. Elle trouve une application web qui promet de fusionner les fichiers « localement dans le navigateur ». Qu’est-ce que cela signifie, et comment le vérifier ?
« Local » est un mot qu’on lit sur beaucoup de sites. Il décrit une construction technique réelle, qui fonctionne bien. Il vaut la peine de comprendre ce qu’il recouvre — parce qu’on peut alors le vérifier.
Deux façons de traiter un fichier
Sur le serveur. Le fichier est téléversé, un ordinateur du prestataire le traite, le résultat revient. C’est la construction habituelle, et elle a des avantages : le serveur est souvent plus puissant que son propre appareil, et certaines conversions exigent des programmes indisponibles dans le navigateur. Le fichier quitte l’appareil, et ce qu’il en advient dépend du prestataire.
Dans le navigateur. L’application charge son code dans le navigateur, et le traitement a lieu là, sur son propre appareil. Le fichier est ouvert, traité et enregistré sans être transmis. Le serveur fournit l’outil, pas l’atelier.
Les deux constructions peuvent être réalisées avec soin ou avec négligence. La différence tient à l’endroit où se trouve le fichier pendant le travail.
Comment un navigateur peut lire des fichiers
Qu’un site puisse lire un fichier sur l’ordinateur ressemble d’abord à quelque chose qui ne devrait pas arriver. La base est la File API, un standard du W3C. MDN la décrit ainsi : avec la File API, un contenu web peut inviter l’utilisatrice à choisir des fichiers locaux puis lire leur contenu. Le choix se fait par un champ de sélection de fichier ou par glisser-déposer.
Le mot important est « inviter ». Un site ne peut pas accéder de lui-même aux fichiers ; il ne reçoit que ce que la personne choisit ou glisse dans la fenêtre. Ce qu’il fait ensuite du contenu — le traiter dans le navigateur ou l’envoyer à un serveur — dépend de son code.
Pourquoi cela suffit aujourd’hui même pour du travail lourd
Longtemps, le navigateur était trop lent pour des traitements exigeants. WebAssembly a changé la donne. MDN décrit WebAssembly comme un langage de bas niveau, proche de l’assembleur, qui offre des performances quasi natives pour le web et sert de cible de compilation à des langages comme C/C++, C# et Rust, de sorte que du code performant s’exécute directement dans le navigateur.
Concrètement, des bibliothèques qui fusionnent ou divisent des PDF ou convertissent des images peuvent être compilées pour tourner dans le navigateur. Ce qui exigeait un serveur peut aujourd’hui se faire sur un ordinateur portable ordinaire.
Ce qui se passe à la première visite
Même une application qui travaille dans le navigateur télécharge quelque chose : son propre code. À la première visite, le navigateur récupère la page, les scripts et, le cas échéant, les modules WebAssembly sur le serveur. C’est la boîte à outils, identique pour tous. Votre fichier n’en fait pas partie.
Cette distinction compte quand on observe ensuite l’activité réseau : le chargement de la page génère des requêtes, c’est normal. Ce qui est parlant, c’est ce qui se passe une fois le fichier choisi et traité.
Où sont les limites
Le traitement dans le navigateur n’est pas le bon choix pour toutes les tâches.
| Aspect | Dans le navigateur | Sur le serveur |
|---|---|---|
| Où est le fichier | Sur son propre appareil | Il est transmis |
| Performance | Dépend de son appareil | Dépend du serveur |
| Très gros fichiers | Peuvent pousser un appareil ancien à ses limites | En général sans problème |
| Éventail des fonctions | Limité à ce qui tourne dans un navigateur | Aussi des programmes qui ne tournent que sur serveur |
| Vérifiable | Avec les outils de développement du navigateur | Seulement via les indications du prestataire |
C’est pourquoi certaines applications proposent les deux : le traitement dans le navigateur pour les tâches qui y tournent de façon fiable, et sur le serveur pour le reste.
Comment vérifier soi-même
La dernière ligne du tableau est la plus intéressante. Qu’un fichier soit transmis ou non se vérifie avec des outils intégrés à tous les navigateurs courants. Google décrit le panneau Réseau des outils de développement de Chrome comme un outil qui enregistre toutes les requêtes d’une page, et le recommande pour s’assurer que les ressources sont téléchargées ou envoyées comme prévu.
En gros :
- Ouvrir l’application et afficher les outils de développement du navigateur (F12 dans Chrome et Edge ; dans Safari après avoir activé le menu Développement).
- Choisir l’onglet Réseau.
- Traiter un fichier dans l’application.
- Regarder si des requêtes de la taille approximative du fichier apparaissent pendant le traitement.
Un test plus simple : charger la page, couper la connexion Internet et lancer le traitement. S’il fonctionne toujours, il a lieu sur l’appareil.
Aussi pour les particuliers
Les mêmes questions se posent en privé, souvent avec des documents qui en disent plus sur une personne qu’une candidature : la copie de la pièce d’identité et l’extrait du registre des poursuites pour un appartement, le rapport médical pour l’assurance, les justificatifs fiscaux. Pour fusionner ou alléger ces fichiers, les deux mêmes tests — observer le réseau, couper la connexion — montrent si un outil tient ce qu’il promet.
Et lorsqu’une tâche n’est possible que sur un serveur, restent les questions du lieu et de la durée : dans quel pays se trouve le serveur, et combien de temps le fichier y reste-t-il ? Les réponses figurent, s’il y en a, dans les conditions de chaque service.
Pour la responsable RH
Pour le dossier de candidatures, trois questions s’appliquent à toute application web : où se fait le traitement ? Le fichier est-il transmis, et si oui, où et pour combien de temps ? Et peut-on observer l’un ou l’autre soi-même ?
Les outils PDF que nous développons combineront les deux constructions. Le traitement sur le serveur aura lieu en Suisse, en mémoire et sans qu’aucun fichier ne soit conservé. Pour certaines tâches comme fusionner, diviser ou ordonner des pages, un mode confidentiel fera tout le travail dans le navigateur — de façon vérifiable avec les outils de développement.
Sources
- 1.MDN: Verwenden von Dateien aus Webanwendungen (vérifié le 25 septembre 2026)
- 2.MDN: WebAssembly (vérifié le 25 septembre 2026)
- 3.W3C: File API (vérifié le 25 septembre 2026)
- 4.Chrome for Developers: Inspect network activity (vérifié le 25 septembre 2026)
Être informé au lancement
Cette idée est encore en préparation. Inscrivez-vous et nous vous écrirons une seule fois, lorsqu’elle deviendra une application. L’inscription est sans engagement – pas de newsletter, pas de publicité.
Voir l’idée