Pourquoi « s'exécute dans votre navigateur » compte vraiment pour la confidentialité de vos fichiers

La plupart des outils de fichiers en ligne fonctionnent de la même façon : votre fichier est téléversé vers un serveur quelque part, traité là-bas, puis le résultat vous est renvoyé — ce qui signifie qu'à un moment donné, votre fichier, dans son intégralité, s'est trouvé sur un ordinateur que vous ne contrôlez pas et dont vous ne pouvez rien vérifier. « S'exécute entièrement dans votre navigateur » décrit une architecture véritablement différente, pas seulement une façon plus aimable de décrire la même chose : le fichier ne quitte jamais l'appareil sur lequel il se trouvait au départ, car le vrai travail de compression, de conversion ou de modification s'effectue grâce aux capacités intégrées du navigateur lui-même, plutôt que d'être confié à un serveur distant. C'est une affirmation précise et techniquement vérifiable, pas une promesse vague, et cela vaut la peine de comprendre exactement ce qui la rend vraie, car la distinction entre « nous ne le téléversons pas » et « nous ne pouvons pas le téléverser parce qu'il n'existe aucune étape de téléversement dans le code » représente toute la différence entre une politique et une architecture.

Les navigateurs modernes exposent plusieurs capacités suffisamment puissantes pour effectuer un traitement de fichiers réel et substantiel sans jamais avoir besoin d'un serveur : l'API Canvas peut décoder, manipuler et réencoder directement des données d'image — redimensionner, recadrer, ajuster, recompresser — entièrement en JavaScript exécuté sur votre propre appareil. WebAssembly permet à des bibliothèques de traitement réellement complexes, y compris des codecs et des gestionnaires de format écrits à l'origine dans des langages comme le C ou le Rust pour leurs performances, de s'exécuter dans le navigateur à des vitesses proches du code natif, ce qui rend praticable, plutôt que douloureusement lente, la manipulation de PDF dans le navigateur ainsi que certains codecs d'image et audio. Les Web Workers exécutent ce traitement dans un fil distinct de celui de la page elle-même, ce qui explique pourquoi une opération lourde — compresser un grand lot d'images, par exemple — ne fige pas l'interface pendant son exécution. Aucune de ces technologies n'est exotique ou expérimentale ; ce sont des fonctionnalités de navigateur standard et largement prises en charge, ce qui rend justement la construction d'outils de fichiers réellement capables sans serveur de plus en plus praticable plutôt qu'un compromis.

La garantie précise est étroite mais bien réelle : les octets de votre fichier ne sont jamais transmis sur le réseau dans le cadre du travail effectué par l'outil. Ce n'est pas quelque chose qu'il faut croire sur parole — c'est directement observable via l'onglet Réseau des outils de développement de n'importe quel navigateur, qui affiche chaque requête effectuée par une page ; faire passer un fichier par un outil réellement basé sur le navigateur tout en observant ce panneau montrera qu'aucun téléversement du fichier n'a lieu, parce qu'il n'y en a réellement aucun. Un test plus direct consiste à se déconnecter complètement d'internet, une fois que la page de l'outil a fini de se charger, puis à vérifier que l'outil fonctionne toujours — un outil dépendant d'un serveur échoue immédiatement sans connexion, tandis qu'un outil réellement basé sur le navigateur continue de fonctionner, puisqu'il n'a jamais eu besoin du réseau pour l'étape de traitement.

Il vaut la peine d'être précis sur ce que cela couvre et ce que cela ne couvre pas : c'est une garantie portant spécifiquement sur le contenu du fichier, pas une affirmation générale selon laquelle absolument aucune activité réseau n'aurait jamais lieu sur la page — le chargement de la page elle-même, de ses scripts, ainsi que toute publicité ou tout outil d'analyse d'audience, constituent une activité réseau distincte, régie par ce que dit la politique de confidentialité d'un site à ce sujet, bien distincte de l'affirmation précise selon laquelle le fichier que vous traitez ne fait pas partie de ce trafic.

Toute opération utile sur un fichier ne peut pas réalistement s'exécuter entièrement dans un navigateur. Des fichiers extrêmement volumineux peuvent dépasser ce que la mémoire d'un onglet de navigateur peut confortablement contenir, certaines opérations dépendent d'une infrastructure ou de données côté serveur qui ne peuvent véritablement pas être reproduites côté client, et certains traitements sont assez lourds pour que les déléguer au matériel d'un serveur soit la seule option praticable. La façon honnête de gérer cet écart n'est pas de téléverser discrètement le fichier malgré tout tout en continuant à laisser entendre que rien n'est téléversé — c'est d'être explicite sur le modèle réellement utilisé par un outil donné, téléversé-puis-traité-puis-supprimé contre jamais-ne-quitte-l'appareil, afin que la distinction reste porteuse de sens plutôt que de devenir un langage marketing étiré pour couvrir les deux cas. Un outil qui a réellement besoin d'un traitement côté serveur devrait le dire clairement et décrire ce qu'il advient du fichier ensuite, plutôt que de laisser le mot « privé » finir silencieusement par désigner deux choses différentes selon l'outil qui se trouve devant vous à un moment donné.