Comment fonctionne le traitement local des fichiers dans un navigateur
Si rien n'est envoyé, qu'est-ce qui fait le travail, et où ?
Ce que « local » veut dire ici
Un convertisseur en ligne classique est un site doté d'un point d'envoi. Votre fichier est transmis à une machine que vous ne contrôlez pas, traité là-bas, conservé pendant un certain temps, puis remis à disposition en téléchargement. Le traitement local supprime le milieu de cette phrase : le code qui lit votre fichier s'exécute dans l'onglet de navigateur que vous avez déjà ouvert, sur votre propre processeur, et le résultat est écrit sur votre propre disque.
Le site, lui, est toujours récupéré par le réseau : le HTML, les feuilles de style, les scripts et les modules WebAssembly viennent tous d'un serveur, comme pour n'importe quelle page web. La différence tient au sens de circulation. Le code du programme descend ; votre fichier ne remonte pas.
Le navigateur contient déjà les pièces
| Fonction | Ce qu'elle apporte |
|---|---|
| API File et Blob | Lire les octets d'un fichier sélectionné ou déposé par l'utilisateur, sans envoi de formulaire |
| Web Workers | Exécuter les traitements lourds sur un thread d'arrière-plan pour que l'interface reste réactive |
| WebAssembly | Exécuter des bibliothèques de codecs compilées en C, C++ ou Rust à une vitesse proche du natif |
| Canvas et OffscreenCanvas | Décoder, dessiner, redimensionner et réencoder des images |
| WebCodecs | Atteindre les encodeurs et décodeurs vidéo à accélération matérielle du navigateur |
| WebGPU | Exécuter l'inférence de modèles et le travail parallèle sur les pixels au niveau du processeur graphique |
| File System Access | Écrire le résultat directement à l'emplacement choisi par l'utilisateur, là où c'est pris en charge |
Rien de tout cela n'a d'exotique. C'est la même plateforme qui fait tourner des tableurs, des outils de conception et des jeux dans un onglet. La seule décision inhabituelle, c'est de refuser d'y ajouter un serveur.
Le chemin que suit un fichier
- Vous choisissez un fichier. Le navigateur en remet une poignée à la page : pas une copie, une référence.
- La page lit les premiers octets pour identifier le vrai type du fichier d'après sa signature, plutôt que de se fier à l'extension.
- Elle estime la mémoire nécessaire à la tâche, et refuse ou met le travail en file d'attente si ce besoin dépasse ce que l'appareil peut fournir sans risque.
- Les octets sont transférés dans un Web Worker. Transférer un ArrayBuffer en cède la propriété au lieu de le copier, si bien qu'un gros fichier n'existe pas deux fois en mémoire.
- Dans le worker, un codec WebAssembly ou une API de la plateforme effectue le décodage et l'encodage proprement dits.
- Le résultat revient sous forme d'octets, est encapsulé dans un Blob, puis vous est proposé en téléchargement ou écrit à l'emplacement que vous choisissez.
- L'URL temporaire de ce Blob est révoquée et les tampons sont libérés.
Pourquoi WebAssembly est l'élément qui a tout changé
Les codecs image et vidéo représentent des décennies de C soigneusement optimisé. Les réécrire en JavaScript n'a jamais été réaliste. WebAssembly est un format binaire d'instructions portable que les navigateurs exécutent dans un bac à sable à une vitesse proche du code natif, ce qui permet de compiler ces bibliothèques existantes et de les livrer telles quelles au navigateur.
Le bac à sable compte autant que la vitesse. Un module WebAssembly n'a aucun accès implicite à votre système de fichiers, à votre réseau ou à vos autres onglets. Il ne voit que la mémoire que la page lui confie, et rien d'autre. Un codec malveillant, ou simplement bogué, ne peut pas aller lire ailleurs ce qu'on ne lui a pas donné.
Ce qui passe encore par le réseau, et pourquoi ce n'est pas votre fichier
Trois choses arrivent par le réseau : la page elle-même, le moteur de l'outil que vous avez ouvert et, pour la suppression d'arrière-plan, les poids du modèle. Ces trois éléments sont des ressources statiques appartenant à FileSlimmer, récupérées depuis l'origine de FileSlimmer avant que le moindre de vos octets ne soit lu. Ce sont des téléchargements, ils sont mis en cache, et après la première utilisation ils peuvent être servis depuis le cache du navigateur sans réseau du tout.
Tout ce qui suit ce point est local. Les moteurs ne reçoivent les octets des fichiers que par postMessage depuis la page ; on ne leur fournit jamais d'URL vers laquelle envoyer quoi que ce soit, et une politique de sécurité du contenu restreint les destinations auxquelles la page pourrait se connecter, même si du code essayait.
Les compromis, dits sans détour
| Critère | Dans votre navigateur | Sur un serveur |
|---|---|---|
| Où va votre fichier | Nulle part | Sur une machine que vous ne contrôlez pas |
| Vitesse | Ce dont votre appareil est capable | Ce que l'exploitant a payé |
| Très gros fichiers | Limités par la mémoire du navigateur | Limités par les quotas de l'exploitant |
| Fonctionne hors ligne | Oui, une fois le moteur mis en cache | Non |
| Formats exotiques | Seulement ce qui se compile en WebAssembly | Tout ce que l'exploitant installe |
| Lot de mille fichiers | Contraint par l'appareil | En général mieux adapté |
Le traitement local n'est pas meilleur en toutes circonstances. Il l'est quand le fichier est confidentiel, quand l'appareil en est capable et quand le travail tient en mémoire. Un serveur vaut mieux quand il faut traiter bien plus que ce qu'une seule machine peut contenir. Savoir dans quelle situation on se trouve est plus utile que de soutenir qu'une approche l'emporte partout.
Ce que cela ne prétend pas
Il s'agit d'une affirmation sur ce que fait cette application. Ce n'est pas une affirmation sur vos extensions de navigateur, qui peuvent lire le contenu de n'importe quelle page que vous ouvrez, ni sur votre système d'exploitation, qui peut inspecter n'importe quel fichier que vous manipulez, ni sur votre opérateur réseau, qui peut voir que vous avez visité un site. Tout cela échappe à n'importe quel site web, et un outil qui vous dit le contraire en fait trop.
L'affirmation est étroite et vérifiable : les fichiers que vous sélectionnez sont traités localement dans ce navigateur et ne sont pas envoyés par FileSlimmer. Le guide suivant explique comment le vérifier vous-même au lieu de le croire sur parole.
Outils pour cette tâche
Sources
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs