Qu’est-ce que WebAssembly ?
WebAssembly (Wasm) est un format d’instructions binaires conçu comme cible de compilation portable pour des langages comme C, C++ et Rust. Il permet d’exécuter du code dans le navigateur à une vitesse proche du natif. Devenu recommandation du W3C en 2019, il est pris en charge par tous les grands navigateurs : Chrome, Firefox, Safari et Edge.
Pour le traitement de fichiers, cela veut dire que des tâches lourdes comme l’édition de PDF, la compression d’images ou la reconnaissance de texte par OCR peuvent se faire entièrement dans le navigateur, sans passer par un serveur. Des applications web comme Photopea et Figma s’appuient sur WebAssembly. Les outils locaux d’Allin PDF reposent sur la même plateforme : des bibliothèques JavaScript et WebAssembly exécutées dans des Web Workers, pour que la page reste fluide pendant que votre fichier est traité sur votre appareil.
Comment pdf-lib, PDF.js et Tesseract.js traitent les fichiers dans le navigateur
Les outils locaux d’Allin PDF reposent sur trois bibliothèques open source. Elles ne sont pas toutes en WebAssembly, mais toutes tournent sur votre appareil :
pdf-lib : manipuler des PDF dans le navigateur
pdf-lib est une bibliothèque JavaScript (TypeScript) qui crée et modifie des documents PDF entièrement côté client. Elle fusionne, divise et réorganise les pages, insère du texte et intègre des images sans aucun appel serveur. pdf-lib est écrite en JavaScript pur, pas en WebAssembly. Les moteurs JavaScript actuels la compilent en code machine rapide, et son exécution dans un Web Worker évite que les gros traitements ne figent la page.
PDF.js : afficher les pages PDF
PDF.js est le moteur PDF de Mozilla, celui intégré à Firefox. Il analyse et dessine les pages d’un PDF, ce dont ont besoin des outils comme PDF en image. Il est écrit principalement en JavaScript, et ses versions récentes utilisent WebAssembly pour certains décodeurs d’images.
Tesseract.js : l’OCR sans serveur
Tesseract.js est le portage en WebAssembly du moteur OCR Tesseract. Le moteur peut être entraîné pour de nombreuses langues ; l’OCR gratuit d’Allin PDF en propose cinq : anglais, chinois simplifié, chinois traditionnel, japonais et coréen. Le français n’en fait pas partie, si bien que les accents et la cédille sont souvent mal lus. Pour un texte en français, l’OCR par IA de l’offre Pro est plus adapté. Les données de langue se téléchargent à la première utilisation, puis la reconnaissance se fait dans l’onglet du navigateur, sans envoi de votre image ou de votre PDF.
Performances : WebAssembly face aux applications natives
Le traitement dans le navigateur est-il plus lent qu’un logiciel de bureau ? Pour un usage courant des PDF, la différence passe généralement inaperçue. La vitesse réelle dépend de votre appareil, de votre navigateur et du fichier lui-même. Le tableau indique ce qui fait le travail dans Allin PDF et ce qui influence la vitesse :
| Opération | Ce qui fait le travail | Où cela s’exécute | Ce qui influence la vitesse |
|---|---|---|---|
| Compresser un PDF | pdf-lib et réencodage des images | Votre navigateur | Nombre et taille des images, niveau de compression |
| Fusionner des PDF (2 à 20 fichiers) | pdf-lib (pages copiées telles quelles) | Votre navigateur | Taille totale et nombre de pages |
| OCR d’une page | Tesseract.js (WebAssembly) | Votre navigateur | Résolution de l’image, processeur, premier téléchargement de la langue |
| Chiffrer un PDF (AES-256) | Chiffrement du PDF dans le navigateur | Votre navigateur | Taille du fichier |
| Rendu PDF en image | PDF.js | Votre navigateur | Nombre de pages, résolution de sortie |
En règle générale, WebAssembly reste un peu plus lent que le même code compilé en natif, et l’écart se réduit à mesure que les navigateurs améliorent leurs compilateurs Wasm. Pour un PDF classique, la taille du fichier, la part d’images et la mémoire de votre appareil comptent davantage.
Modèle de sécurité : pourquoi la sandbox compte
WebAssembly offre de solides garanties de sécurité grâce à son modèle d’exécution isolée :
- Isolation de la mémoire : le code Wasm travaille dans sa propre mémoire linéaire, séparée du reste du navigateur. Il n’a accès ni aux autres onglets, ni aux cookies, ni aux ressources du système.
- Aucun accès direct au système : Wasm ne peut pas, de lui-même, lire vos fichiers, accéder au réseau ou appeler les API du système d’exploitation. Il n’utilise que ce que le JavaScript de la page lui transmet explicitement.
- Politique de même origine : les modules Wasm suivent les mêmes règles que JavaScript, donc pas d’accès aux données d’une autre origine sans en-têtes CORS.
- Validation avant exécution : chaque binaire Wasm est validé avant de s’exécuter, ce qui bloque le code malformé et évite bon nombre d’erreurs mémoire fréquentes dans les programmes natifs.
L’avenir des outils dans le navigateur
WebAssembly continue d’évoluer, et ses fonctions récentes ou à venir réduisent encore l’écart avec les applications natives :
- WASI (WebAssembly System Interface) : une interface système standard pour les E/S de fichiers et le réseau, surtout destinée à exécuter Wasm hors du navigateur
- Threads et SIMD : le Wasm multithread avec instructions SIMD accélère le traitement parallèle des gros fichiers
- Ramasse-miettes (GC) : la prise en charge intégrée du GC permet de compiler efficacement vers Wasm des langages comme Java, Kotlin et Dart
- Modèle de composants : il permet d’assembler des modules Wasm écrits dans différents langages en une seule application
La tendance est nette : de plus en plus d’applications de bureau passent dans le navigateur. Pour les fichiers sensibles, comme les PDF, les documents et les images, les outils locaux dans le navigateur allient bien vitesse, confidentialité et simplicité.
Questions fréquentes
WebAssembly fonctionne-t-il sur les navigateurs mobiles ?
Oui. WebAssembly est pris en charge par Chrome pour Android, Safari sur iOS et Firefox pour Android. Les mobiles disposent de moins de puissance et de mémoire qu’un ordinateur, donc les gros fichiers prennent plus de temps, mais les tâches courantes comme compresser ou fusionner des PDF fonctionnent bien sur les smartphones actuels.
WebAssembly peut-il accéder à mes fichiers sans autorisation ?
Non. WebAssembly n’a pas d’accès direct à votre système de fichiers. C’est vous qui choisissez les fichiers, via le sélecteur ou par glisser-déposer. Le code Wasm ne traite que les données que vous lui fournissez ; il ne peut ni parcourir ni lire les autres fichiers de votre appareil.
WebAssembly va-t-il remplacer JavaScript ?
Non. WebAssembly complète JavaScript. JavaScript reste le meilleur choix pour l’interface, la manipulation du DOM et la logique applicative. Wasm prend en charge les calculs intensifs (compression, analyse, OCR) où une vitesse quasi native compte. La plupart des applications web modernes utilisent les deux.