Il y a une raison pour laquelle Squoosh peut compresser tes images avec des codecs qui rivalisent avec les applications de bureau — et ça n’a rien à voir avec la puissance du serveur. La compression se passe entièrement dans ton onglet de navigateur, grâce à une technologie appelée WebAssembly. Pas de téléchargement requis, pas de compte nécessaire, pas d’attente qu’un serveur distant traite ton fichier et te le renvoie.
Ça change ce que signifie « outil de navigateur gratuit ». Pour beaucoup d’entre eux.
Ce qu’est réellement WebAssembly
WebAssembly (abrégé Wasm) est un format d’instruction binaire qui tourne dans le navigateur à des vitesses bien plus proches du code natif que ce que JavaScript peut atteindre. La spécification WebAssembly est devenue un standard W3C en décembre 2019, mais le support des navigateurs est arrivé plus tôt — Chrome 57, Firefox 52, Safari 11 et Edge 16 ont tous livré le support Wasm en 2017.
La chose essentielle à comprendre : Wasm n’est pas un langage de programmation. C’est une cible de compilation. Tu écris du code en C, C++, Rust ou Go, tu le compiles en binaire .wasm, et tu l’envoies au navigateur. Le navigateur le fait tourner directement, sans interpréter JavaScript ni contacter un serveur.
La différence de performances est réelle. Les benchmarks montrent systématiquement que Wasm tourne 10 à 20 % plus lentement que le code natif équivalent — ce qui semble significatif jusqu’à ce qu’on compare avec JavaScript, où certaines opérations tournent 5 à 10 fois plus lentement que le natif. Pour le travail intensif en calcul (encodage d’images, traitement audio, cryptographie, requêtes de base de données), Wasm réduit l’écart entre ce qu’un navigateur peut faire et ce qu’une appli de bureau peut faire.
L’introduction en 2022 des instructions WebAssembly SIMD (Single Instruction, Multiple Data) a encore réduit cet écart. SIMD permet à Wasm d’utiliser les opérations vectorielles du CPU pour le traitement parallèle des données — la même optimisation qui rend les outils d’images de bureau rapides.
Pourquoi ça compte pour les outils qui ne nécessitent pas d’inscription
Voilà le lien que l’industrie a mis du temps à nommer explicitement : le traitement côté serveur est l’une des principales justifications pour exiger des comptes utilisateurs.
Quand un outil traite tes fichiers sur un serveur, le service a besoin de savoir à qui appartient quoi. Gestion des sessions, stockage de fichiers, files d’attente de tâches — tout ça nécessite une identité. Et une identité signifie des comptes, des e-mails et des mots de passe.
Quand le calcul se déplace vers le navigateur, cette dépendance disparaît. Ton fichier ne quitte jamais ta machine. Il n’y a pas de tâche à suivre, pas de coût serveur proportionnel à ton utilisation, pas besoin d’associer la requête à une identité quelconque.
« Le navigateur est l’OS » était autrefois un lieu commun de la Silicon Valley. Avec WebAssembly, c’est en train de devenir une déclaration littérale sur ce que ton navigateur peut réellement calculer.
Les outils construits sur Wasm peuvent offrir une expérience genuinement sans connexion, sans inscription, sans enregistrement parce qu’ils n’ont genuinement pas besoin de savoir qui tu es. Le calcul se passe sur ton matériel, dans ton navigateur, avec ton CPU qui fait le travail. Le serveur du développeur sert un fichier statique. C’est tout.
Des outils qui utilisent déjà ça — sans l’annoncer
La plupart des outils ci-dessous ne mentionnent pas « propulsé par WebAssembly » sur leur page d’accueil. Tu ne le saurais qu’en regardant l’onglet réseau dans les DevTools — les fichiers .wasm sont révélateurs. Mais ils valent d’être compris individuellement, parce que chacun montre une catégorie différente de travail qui a migré des serveurs vers les navigateurs.
Squoosh est le cas le plus visible. Google l’a construit spécifiquement pour démontrer ce que Wasm pouvait faire pour la compression d’images. Ouvre-le, dépose une image, et tu peux encoder avec MozJPEG, OxiPNG, WebP, AVIF ou JPEG XL — tout tournant localement. Ce sont des bibliothèques C/C++, compilées en Wasm, tournant dans ton onglet. Les mêmes codecs qu’utilisent les applis photo de bureau.
hat.sh chiffre et déchiffre des fichiers en utilisant libsodium — une bibliothèque C cryptographique bien auditée compilée en WebAssembly. Ton fichier n’atteint jamais aucun serveur. Quand tu chiffres quelque chose avec hat.sh, l’opération se passe en mémoire dans ton onglet de navigateur, et seule la sortie chiffrée touche jamais ton disque. C’est la bonne architecture pour les outils de chiffrement.
AudioMass est un éditeur audio waveform complet qui gère l’édition multi-pistes sans compte ni installation. La manipulation audio est genuinement intensive en calcul — filtrage, transposition, conversion de format nécessitent tous un traitement réel. Le fait que ça tourne de façon acceptable dans un onglet de navigateur est un résultat direct des performances activées par Wasm.
Datasette Lite va plus loin que la plupart. Il fait tourner un moteur de base de données SQLite complet — compilé en WebAssembly — dans ton navigateur. Tu peux charger un CSV ou un fichier SQLite et lancer des vraies requêtes SQL dessus sans que rien ne touche un serveur. Ça nécessitait autrefois soit un client de base de données de bureau, soit un service de base de données cloud avec un compte.
Une comparaison utile
Le pattern dans ces outils est cohérent :
| Catégorie de tâche | Ancien modèle (côté serveur) | Modèle Wasm (côté client) |
|---|---|---|
| Compression d’image | Upload → serveur encode → téléchargement | Le navigateur fait tourner le codec localement |
| Chiffrement de fichier | Envoi au serveur → le serveur chiffre → retour | Chiffrement en mémoire, jamais uploadé |
| Édition audio | Upload piste → traitement cloud → résultat | Web Audio + Wasm traitent dans l’onglet |
| Requêtes de base de données | BDD hébergée → compte → appels API | SQLite compilé en Wasm, local |
| Transformation de code | Serveur de build distant | Le compilateur tourne dans l’onglet du navigateur |
Le traitement côté serveur crée des raisons d’exiger des comptes. Le traitement Wasm côté navigateur supprime ces raisons.
L’angle vie privée qu’on néglige
Il y a une propriété de vie privée spécifique que les outils basés sur Wasm ont que les outils purement JavaScript n’ont souvent pas : le calcul intensif se passe dans un environnement sandboxé, sans effets de bord qui franchissent la frontière réseau.
Les MDN Web Docs sur WebAssembly décrivent clairement le modèle de sécurité : les modules Wasm tournent dans le même sandbox que JavaScript, sans permissions supplémentaires. Ils ne peuvent pas faire de requêtes réseau indépendamment, ne peuvent pas lire des fichiers arbitraires, et ne peuvent pas accéder au matériel sans interopérabilité JavaScript explicite.
Ça compte pour les utilisateurs d’outils sensibles à la vie privée. Quand hat.sh chiffre ton fichier, le module Wasm ne peut physiquement pas envoyer ce fichier sur le réseau — le module n’a pas d’accès réseau propre. JavaScript devrait explicitement l’uploader. Les outils open source peuvent être audités pour confirmer que ça n’arrive pas, parce que le code source est disponible.
CyberChef — l’outil de navigateur construit par le GCHQ pour les opérations d’encodage, décodage et cryptographiques — est une illustration utile de l’état actuel. Il gère des centaines d’opérations (base64, AES, hachages SHA, parsing binaire, conversion de format de données) sans aucune implication serveur.
Pas d’inscription. Pas d’enregistrement. Pas d’upload.
Ce que Wasm ne peut pas encore faire
WebAssembly a de vraies limites. Il n’a pas d’accès direct au DOM — Wasm et JavaScript communiquent toujours via un pont, ce qui ajoute de la surcharge pour les opérations lourdes en UI. L’accès au système de fichiers est limité à ce que l’API File System Access du navigateur permet. Et pour des opérations vraiment à grande échelle (entraîner des modèles ML sur de grands ensembles de données, traiter des centaines de gigaoctets), le calcul côté client rencontre encore des limites pratiques de mémoire.
Wasm n’a pas non plus de garbage collection intégré historiquement — bien que la proposition WebAssembly GC, qui a atteint la Phase 4 en 2023, change cela pour des langages comme Kotlin et OCaml.
Ces limites sont réelles, mais elles rétrécissent. La chaîne d’outils Wasm est plus mature qu’elle ne l’était il y a deux ans — Emscripten pour C/C++, wasm-pack pour Rust, et TinyGo pour Go ont tous des communautés actives et une bonne documentation.
Ce qui se passe vraiment dans la catégorie des outils sans connexion
Photopea gère les fichiers PSD, XCF et Sketch sans nécessiter de compte. Ce genre de parsing — lire des formats de fichiers binaires complexes, gérer la composition de calques, la gestion de l’espace colorimétrique — était historiquement une raison d’acheminer les fichiers via un serveur. Maintenant ça tourne dans un onglet de navigateur. Contrairement aux applis web qui nécessitent un abonnement Photoshop et un compte Adobe, Photopea se charge instantanément, gratuitement, sans inscription.
La contrainte était : si un outil de navigateur avait besoin de vraie puissance de calcul, il devait renvoyer chez lui. Wasm brise cette contrainte. Quand la contrainte disparaît, la justification du « tu as besoin d’un compte pour utiliser ça » s’affaiblit pour un plus large ensemble d’outils.
Rien de tout ça ne signifie que chaque outil deviendra un outil de navigateur gratuit sans connexion. Certaines applications nécessitent genuinement un état serveur persistant — collaboration en temps réel, synchronisation cloud entre appareils, ou inférence IA à grande échelle nécessitant des clusters GPU. Mais le plancher remonte. La catégorie des tâches qui peuvent être faites bien, gratuitement, sans inscription, dans un onglet de navigateur, est plus large qu’elle ne l’était en 2020.
La conséquence pratique : si tu choisis entre un outil qui nécessite un compte et une alternative basée sur le navigateur sans compte, l’option basée sur le navigateur est moins susceptible d’être un compromis sur les capacités qu’elle ne l’était il y a cinq ans. Dans beaucoup de catégories, c’est le meilleur outil. Wasm en est la principale raison.
D’autres outils gratuits de navigateur sans inscription arrivent. La technologie sous-jacente continue de s’accélérer, et l’outillage développeur continue de s’améliorer.
Trouve des outils qui fonctionnent sans connexion, sans compte requis, sur nologin.tools.