Comment fonctionne la compression côté client (et pourquoi elle est plus respectueuse de la vie privée)

Lorsque vous compressez une photo ou réduisez un PDF sur la plupart des sites web, votre fichier effectue un aller-retour : il est téléversé vers un serveur, traité dans un centre de données quelque part, et une version plus petite vous est renvoyée. Cela fonctionne, mais cela signifie qu’une copie de votre fichier privé réside brièvement sur un ordinateur que vous ne contrôlez pas. FileShrinking adopte une approche différente : chaque octet de la compression se déroule dans l’onglet de votre propre navigateur, et vos fichiers ne quittent jamais votre appareil. Cet article explique exactement comment c’est possible, quelles technologies du navigateur le rendent possible, et les compromis honnêtes que cela implique.

Deux façons de compresser un fichier sur le web

Le modèle traditionnel est côté serveur. Votre navigateur envoie le fichier original sur le réseau ; un backend exécutant un outil comme ImageMagick ou FFmpeg effectue le gros du travail ; le résultat est renvoyé en flux. La machine de l’utilisateur peine à peine, et le serveur peut être extrêmement puissant. Le prix à payer, ce sont la confidentialité et la confiance : vos données sont transmises, elles séjournent (même temporairement) sur le disque de quelqu’un d’autre, et vous devez vous fier à sa parole quant à ce qu’il en advient ensuite.

Le modèle plus récent est côté client. Les mêmes algorithmes de compression s’exécutent directement sur votre appareil, dans le navigateur, sans aucune étape de téléversement. Pendant des années, c’était peu pratique : JavaScript seul était trop lent pour exécuter un codec d’image ou de vidéo sérieux à une vitesse utilisable. Cela a changé lorsque les navigateurs ont acquis la capacité d’exécuter du code compilé, quasi natif, sur le web. Aujourd’hui, un ordinateur portable ou un téléphone modernes peuvent accomplir le travail qui nécessitait autrefois un serveur, et FileShrinking est entièrement construit sur ce modèle.

WebAssembly : de vrais codecs exécutés dans le navigateur

La technologie qui rend la compression côté client viable est WebAssembly(souvent abrégé en Wasm). C’est un format d’instructions binaires compact et de bas niveau que les navigateurs peuvent exécuter à des vitesses proches du code natif. Point crucial, il permet aux développeurs de prendre des codecs écrits en C, C++ ou Rust — et affinés pendant des décennies — et de les compiler pour qu’ils s’exécutent sur le web sans les réécrire en JavaScript.

C’est ainsi que les mêmes moteurs de compression éprouvés que vous trouveriez dans un logiciel de bureau professionnel se retrouvent dans un onglet de navigateur :

• MozJPEG pour un encodage JPEG de haute qualité qui tire le meilleur parti de chaque kilo-octet.
• OxiPNGpour l’optimisation PNG sans perte.
• libwebp et les encodeurs AVIF pour les formats modernes WebP et AVIF.
• FFmpeg, compilé en WebAssembly, pour le transcodage et la réduction de vidéos.

Pour une référence technique plus approfondie, la documentation WebAssembly de MDN est la source canonique sur le fonctionnement du format et les raisons de sa rapidité.

Web Workers : garder la page réactive

La compression est lourde sur le plan du calcul. Si vous exécutiez un transcodage vidéo sur le thread principal du navigateur, toute la page se figerait : les boutons cesseraient de répondre, le défilement saccaderait et les barres de progression se bloqueraient. Pour l’éviter, FileShrinking exécute le travail sur un thread distinct à l’aide des Web Workers.

Un Web Worker est un contexte JavaScript en arrière-plan qui s’exécute en parallèle de l’interface utilisateur. Le thread principal remet le fichier (et le codec Wasm) au worker, le worker traite la compression, et il renvoie le résultat terminé une fois achevé. Pendant ce temps, l’interface reste fluide et peut afficher la progression en temps réel. Le guide de MDN sur l’utilisation des Web Workers détaille le modèle de transmission de messages. Les données binaires volumineuses peuvent être déplacées entre les threads de manière efficace grâce aux objets transférables, de sorte que le fichier n’a pas à être copié octet par octet juste pour franchir la frontière entre les threads.

Lire et décoder les fichiers sans le réseau

Avant de pouvoir compresser quoi que ce soit, le navigateur doit lire votre fichier en mémoire et le décoder. Cela repose sur une petite famille d’API web standard, dont aucune n’implique de serveur :

• Les API File et Blobreprésentent le fichier que vous sélectionnez ou glissez. Elles exposent les octets bruts sous la forme d’un ArrayBuffer sur lequel les codecs peuvent travailler directement, le tout en mémoire.
• createImageBitmap décode efficacement une image en une forme prête à être traitée, et peut le faire en dehors du thread principal.
• OffscreenCanvaspermet au navigateur de dessiner, de redimensionner et de réencoder des données d’image au sein d’un worker, sans jamais toucher la page visible.

Mis bout à bout, le pipeline ressemble à ceci : vous déposez un fichier, le navigateur lit ses octets localement, un worker le décode, le codec Wasm le réencode à la qualité que vous avez choisie, et un nouveau Blob vous est remis pour le téléchargement. À aucun moment le fichier ne voyage où que ce soit. Si les choix de qualité de cette étape de réencodage vous intriguent, notre guide sur la compression avec perte par rapport à la compression sans perte explique ce qui est réellement écarté et pourquoi.

Pourquoi c’est véritablement plus respectueux de la vie privée

L’avantage du modèle côté client en matière de confidentialité n’est pas un slogan marketing : c’est une conséquence directe de l’architecture. Parce que votre fichier n’est jamais lu qu’en mémoire locale et réencodé sur votre appareil :

• Rien n’est transmis.Il n’y a aucun téléversement, donc aucune copie de votre fichier en transit à intercepter, ni aucune copie au repos sur un serveur susceptible d’être compromise, vendue ou réquisitionnée par la justice.
• Cela fonctionne hors ligne.Une fois la page et ses codecs Wasm chargés, vous pouvez vous déconnecter entièrement d’internet et les outils continuent de fonctionner. C’est la preuve la plus simple qu’aucun téléversement n’a lieu : vous pouvez le constater vous-même dans l’onglet réseau de votre navigateur.
• Il n’y a rien à conserver.Lorsque vous fermez l’onglet, les données du fichier disparaissent de la mémoire. Il n’existe aucun journal serveur reliant vos documents à votre identité.

Et comme FileShrinking est entièrement open source sous licence MIT, vous n’avez pas à accepter ces affirmations sur parole. N’importe qui peut lire le code, confirmer qu’il n’existe aucun chemin de téléversement et vérifier exactement comment se comporte le pipeline de compression. La confidentialité vérifiable est la plus solide qui soit.

Les compromis honnêtes

La compression côté client n’est pas magique, et il est juste d’être transparent sur les domaines où le modèle serveur conserve encore des avantages :

• La vitesse sur les très gros travaux.Un centre de données peut consacrer bien plus de cœurs à une longue vidéo que n’en possède votre ordinateur portable. Pour la plupart des images et des clips courts, la différence est imperceptible, mais une vidéo de la durée d’un long métrage sera plus lente dans le navigateur que sur une ferme de serveurs.
• Les limites de mémoire.Tout se passe dans la RAM de votre appareil. Les fichiers extrêmement volumineux — par exemple, une vidéo de plusieurs gigaoctets sur un téléphone à faible mémoire — peuvent atteindre des plafonds de mémoire du navigateur qu’un serveur n’aurait pas.
• Le coût du premier chargement. Les codecs Wasm doivent être téléchargés la première fois que vous utilisez un outil. Ils sont ensuite mis en cache, de sorte que les visites suivantes sont instantanées, mais la toute première exécution paie un téléchargement unique.

Pour l’immense majorité des tâches quotidiennes — optimiser des photos pour le web, réduire un PDF à la taille d’un e-mail, comprimer un enregistrement d’écran — ces compromis en valent largement la peine, et vous obtenez la confidentialité gratuitement.

Constatez-le par vous-même

La meilleure façon de comprendre la compression côté client est de l’utiliser. Essayez le compresseur d’images, le compresseur de vidéos ou le compresseur de PDF, puis ouvrez les outils de développement de votre navigateur, observez l’onglet réseau et confirmez que rien n’est téléversé pendant que votre fichier rétrécit. Tout s’exécute localement, le code est ouvert à l’inspection de tous, et vos fichiers restent exactement là où ils doivent être : avec vous.