ToolBox Image — Pourquoi nous avons conçu ToolBox Image pour fonctionner entièrement dans votre navigateur

La plupart des outils de traitement d'images en ligne gratuits fonctionnent de la même manière : vous téléchargez un fichier sur leur serveur, le serveur le traite, et vous téléchargez le résultat. Ce modèle est simple à construire, mais il a des coûts cachés — votre vie privée, leurs factures de serveur, et des limites sur la taille des fichiers et le débit.

ToolBox Image adopte une approche différente. L'ensemble de l'application — décodage, encodage, compression, redimensionnement, conversion de format — s'exécute dans votre navigateur. Il n'y a pas de serveur pour télécharger. Vos images ne quittent jamais votre appareil. Cette architecture était un choix délibéré, et elle a façonné chaque décision que nous avons prise concernant le produit.

Pourquoi l'approche navigateur d'abord ?

L'alternative évidente est une architecture traditionnelle côté serveur. Vous téléchargez une image, le serveur la traite avec un outil comme ImageMagick ou Sharp, et renvoie le résultat. Cela fonctionne, mais crée un ensemble de problèmes difficiles à résoudre :

• Vie privée. Les utilisateurs doivent faire confiance au fait que vous ne stockerez, n'analyserez ou ne divulguerez pas leurs images. Pour les documents sensibles — images médicales, maquettes de design, photos personnelles — cette confiance est difficile à gagner.
• Coût. Chaque compression s'exécute sur votre infrastructure. Plus vous avez de succès, plus vous payez. Cela crée une pression pour limiter les tailles de fichiers, ajouter des files d'attente ou introduire des niveaux payants.
• Latence. Télécharger un fichier de 100 Mo sur une connexion lente prend des minutes avant même que le traitement ne commence. Pour les utilisateurs dans des régions avec une mauvaise connectivité, l'outil est effectivement inutilisable.
• Évolutivité. Un seul serveur peut gérer des dizaines de compressions simultanées. Mais des milliers ? Vous avez besoin de groupes d'auto-scaling, d'équilibreurs de charge, de points de terminaison CDN — tout cela ajoute de la complexité et du coût.

Le modèle basé sur le navigateur résout tout cela à la fois. Le traitement est gratuit (cycles CPU de l'utilisateur), privé (aucune donnée ne quitte l'appareil) et infiniment évolutif (chaque utilisateur apporte son propre matériel).

Comment ça marche : WebAssembly et Web Workers

Il y a dix ans, exécuter des codecs d'image dans le navigateur était impossible. Aujourd'hui, WebAssembly nous permet de compiler des bibliothèques C et Rust directement dans un format que le navigateur peut exécuter à une vitesse quasi-native. Nous compilons mozJPEG de Mozilla, libwebp de Google et l'encodeur AVIF libaom — tous écrits en C — en WebAssembly. Le navigateur les exécute aussi efficacement que s'ils étaient installés nativement.

Mais l'encodage monothread est lent pour les grands lots. C'est là que les Web Workers entrent en jeu. Chaque worker s'exécute sur un cœur CPU séparé, et nous créons autant de workers que l'appareil a de cœurs. Sur un ordinateur portable moderne avec 8 cœurs, cela signifie 8 images compressées simultanément. Un lot de 200 photos qui prendrait des minutes sur un seul thread se termine en secondes.

Ce que nous avons sacrifié

L'approche basée sur le navigateur n'est pas gratuite. Le compromis le plus important est la mémoire. L'onglet du navigateur a accès à la RAM de l'appareil, mais un seul onglet qui plante parce qu'une image a dépassé la mémoire disponible est une mauvaise expérience. Nous plafonnons les fichiers individuels à 100 Mo et les tailles de lots à 200 fichiers pour rester dans des limites sûres.

Nous avons également sacrifié les fonctionnalités côté serveur comme le stockage persistant, la livraison d'e-mails et les analyses. Il n'y a pas de base de données d'images compressées, pas de newsletter, pas d'enregistrement des formats préférés des utilisateurs. C'est philosophiquement cohérent avec notre position sur la vie privée, mais cela signifie que nous ne pouvons pas offrir des fonctionnalités comme "compressions récentes" ou "préréglages sauvegardés entre sessions".

Prochaines étapes

Le navigateur devient un environnement d'exécution légitime pour les applications sensibles aux performances. Alors que WebAssembly gagne le ramasse-miettes, le multithreading et le support SIMD, une plus grande partie de la pile applicative peut passer côté client. Nous explorons WebGPU pour un traitement des pixels encore plus rapide et l'API File System Access pour une intégration transparente des dossiers.

Pour l'instant, le compresseur est en ligne et traite des milliers d'images par jour — toutes restant là où elles doivent être.