Compresser un fichier localement : ce qui se passe vraiment

« Traitement 100 % local » sonne comme un argument commercial. C'est en réalité une description technique assez précise, avec des mécanismes identifiables et des limites bien réelles. Voici les deux.

La phrase est devenue un argument de vente, donc suspecte. Elle recouvre pourtant quelque chose de très concret : un navigateur moderne sait décoder, transformer et ré-encoder une image, un PDF ou une vidéo sans jamais solliciter un serveur. Détaillons ce qui se passe réellement entre le moment où tu déposes un fichier et celui où tu récupères le résultat.

Le programme se déplace, pas le fichier

Il y a bien un transfert au départ, mais il va dans l'autre sens : la page et ses programmes de traitement sont téléchargés depuis le serveur jusqu'à ton navigateur. Ensuite, ces programmes s'exécutent chez toi, sur ton processeur et dans ta mémoire vive.

Le fichier que tu déposes, lui, ne prend jamais le chemin inverse. Il est lu depuis le disque par le navigateur, il devient une zone de mémoire dans l'onglet, et il y reste. C'est la différence structurelle avec un service classique, où le programme reste sur le serveur et où c'est le fichier qui voyage.

Les mécanismes qui font le travail

Trois briques standard du web suffisent à couvrir l'essentiel, et elles sont documentées publiquement — les références sont en sources.

Canvas est la surface de dessin du navigateur. Une image y est décodée puis ré-encodée à la qualité ou aux dimensions voulues. C'est exactement le mécanisme qu'utilise n'importe quelle page pour afficher et redimensionner une photo ; nous nous en servons pour produire le fichier de sortie.

WebAssembly permet d'exécuter dans l'onglet du code compilé, à une vitesse proche de celle d'un logiciel installé. C'est ce qui rend possible le traitement de formats que le navigateur ne gère pas nativement, y compris la compression vidéo.

Les workers sont des fils d'exécution séparés de l'interface. La lecture d'un PDF s'y déroule, ce qui évite que la page se fige pendant un traitement long. Rien n'en sort vers le réseau : un worker est une pièce à côté, pas une porte de sortie.

Le résultat final est assemblé en mémoire, puis publié sous une adresse interne au navigateur — une URL en blob:, valable uniquement dans ton onglet et pour la durée de la session. Le bouton de téléchargement pointe vers cette adresse-là. Rien n'est allé chercher le fichier ailleurs : il n'a jamais été ailleurs.

Où vivent tes fichiers pendant le traitement

En mémoire vive, et nulle part ailleurs. Pas de dépôt sur ton disque, pas d'écriture dans le stockage du navigateur, pas de base locale. Fermer l'onglet suffit à tout effacer : le système récupère la mémoire, l'adresse blob: cesse d'exister, et il ne reste que ce que tu as explicitement enregistré via le bouton de téléchargement.

C'est aussi pour cela qu'il n'y a pas d'historique, pas de « mes fichiers récents » et pas de reprise après fermeture. Ce n'est pas une fonctionnalité manquante : c'est la conséquence directe de ne rien conserver.

Ce que ça coûte : quatre contreparties réelles

Traiter localement a un prix, et le taire serait malhonnête.

La mémoire de ton appareil devient le plafond. Un serveur dimensionne ses machines ; ici, c'est ta machine. Une vidéo de plusieurs centaines de mégaoctets ou un PDF de milliers de pages se heurtent à cette limite, et un téléphone plus tôt qu'un ordinateur. Nos outils annoncent leurs bornes plutôt que d'échouer sans explication.

Le premier usage de la vidéo télécharge un moteur. Le programme de compression vidéo pèse une trentaine de mégaoctets. Il descend une fois, il est mis en cache par le navigateur, et il n'emporte rien : c'est du code qui arrive, pas un fichier qui part. Sur une connexion lente, l'attente est réelle, et nous l'annonçons avant de lancer l'opération.

La performance dépend de ton processeur. Un traitement qui prendrait quelques secondes sur un serveur puissant peut en prendre plusieurs dizaines sur un appareil d'entrée de gamme.

Rien ne fonctionne hors connexion. La page et ses programmes doivent être chargés depuis le réseau à chaque visite : nous n'installons aucun mécanisme de fonctionnement hors ligne. Une fois la page ouverte, le traitement n'a plus besoin du réseau — mais ce n'est pas la même chose qu'une application hors ligne, et nous ne le présenterons pas comme tel.

Deux observations à ta portée

Deux observations suffisent, et aucune ne demande de nous croire. La première est réseau : l'onglet Réseau du navigateur ne montre aucune requête sortante au poids de ton fichier pendant le traitement — le mode d'emploi complet est ici.

La seconde est physique : lance une compression un peu lourde et regarde l'activité processeur de ton appareil. Elle monte. Sur un ordinateur portable, le ventilateur peut se déclencher. C'est ta machine qui travaille, ce qui est difficile à simuler pour un service qui ferait le calcul ailleurs.

Ce que cela change du point de vue de la confidentialité, nous l'avons développé dans convertir un fichier sans le confier à personne, et le versant technique de la compression d'image est détaillé dans l'article compresser une image sans serveur.