Comment fonctionne la conversion de fichiers dans le navigateur

Quand vous entendez "votre fichier ne quitte jamais votre navigateur", cela peut ressembler à un argument marketing. Ce n'est pas le cas. C'est une description technique précise du fonctionnement des navigateurs modernes, grâce à des API web qui ont mûri au cours de la dernière décennie.

Étape 1 : lecture du fichier — la File API

Quand vous sélectionnez ou déposez un fichier, la File API du navigateur donne à JavaScript accès à celui-ci sous forme d'objet File — une référence au fichier sur votre disque local. Le navigateur le charge en mémoire via FileReader ou la méthode file.arrayBuffer().

Il s'agit d'une lecture locale. Aucune requête réseau n'est effectuée. Les données du fichier entrent dans la mémoire (RAM) du navigateur, exactement comme si vous l'ouvriez dans une application de bureau.

Point clé : la lecture d'un fichier via la File API est identique à l'ouverture d'un fichier depuis le disque dans une application de bureau. Les données ne touchent jamais le réseau.

Étape 2 : traitement — WebAssembly, Canvas et JavaScript

Une fois le fichier en mémoire, la logique de conversion s'exécute. Différents types de conversions utilisent différentes technologies :

Opérations PDF (fusion, découpe, rotation) — pdf-lib via JavaScript

pdf-lib est une bibliothèque JavaScript pure qui analyse, crée et modifie des fichiers PDF. Elle s'exécute entièrement dans le moteur JavaScript. Les opérations comme la fusion, la rotation ou la découpe se font comme des transformations de tableaux en mémoire.

Rendu PDF (PDF vers images) — pdfjs-dist via WebAssembly

Le rendu d'une page PDF en image matricielle est plus intensif. PDF.js (le renderer open-source de Mozilla) est compilé en WebAssembly — un format d'instructions binaires qui s'exécute à vitesse quasi-native dans le navigateur.

Opérations sur les images (compression, redimensionnement, conversion) — Canvas API

La Canvas API HTML5 donne à JavaScript un accès direct à un tampon de pixels. Pour redimensionner une image, le navigateur la dessine sur un canvas aux dimensions cibles. Pour la compresser, canvas.toBlob() encode les pixels en JPEG ou WebP.

Étape 3 : maintenir la réactivité de l'interface — Web Workers

JavaScript est monothread par défaut. Traiter un PDF de 50 Mo dans le thread principal fige votre onglet. Pour éviter cela, le travail intensif est déchargé vers un Web Worker — un thread d'arrière-plan indépendant du thread UI principal.

Le worker reçoit les données du fichier, effectue la conversion et renvoie le résultat. Les Web Workers sont isolés : ils ne peuvent pas accéder au DOM, aux cookies ni au réseau sans permission explicite.

Étape 4 : téléchargement du résultat

Une fois le traitement terminé, le résultat est un Blob en mémoire — un bloc de données binaires dans la RAM du navigateur. Le navigateur crée une URL temporaire pointant vers ce Blob (URL.createObjectURL) et déclenche un téléchargement. Le fichier va directement de la mémoire vers votre disque local.

Et les limites de performances ?

Le traitement côté navigateur est limité par la RAM et le CPU disponibles sur votre appareil. Les navigateurs modernes gèrent confortablement des fichiers jusqu'à plusieurs centaines de mégaoctets.

• Un PDF de 100 pages fait typiquement 5–15 Mo — traité en quelques secondes
• Une photo de 20 Mpx représente environ 60 Mo non compressés en mémoire — géré facilement
• Un lot de 50 images est traité séquentiellement, chacune rapidement

La garantie du bac à sable

Tout code s'exécutant sur une page web — y compris les modules WebAssembly — opère dans le bac à sable de sécurité du navigateur. Le code ne peut pas accéder à votre système de fichiers au-delà de ce que vous accordez explicitement, ni effectuer de requêtes réseau sans que le JavaScript de la page les initie.

Vous pouvez vérifier qu'aucune requête réseau n'est effectuée pendant une conversion en ouvrant les DevTools (F12), en allant dans l'onglet Réseau et en observant pendant que vous convertissez un fichier.

Transparence open source

Les bibliothèques principales utilisées par converteo.app sont open source et auditables :

• pdf-lib — licence MIT, auditable sur GitHub
• PDF.js — Apache 2.0, développé par Mozilla
• libheif/libde265 — décodage HEIC, LGPL

Questions fréquentes

Le navigateur doit-il télécharger la bibliothèque de conversion ?

Oui — une seule fois. Les modules JavaScript et WebAssembly sont téléchargés lors de votre première visite et mis en cache. Ce téléchargement concerne le code de la bibliothèque, pas votre fichier.

Que devient mon fichier quand je ferme l'onglet ?

Le navigateur libère la mémoire utilisée par votre fichier. À moins d'avoir sauvegardé le résultat, aucune trace du fichier original ni de sa version convertie ne subsiste.

Le JavaScript du site pourrait-il secrètement télécharger mon fichier ?

En principe, tout JavaScript s'exécutant sur une page pourrait effectuer une requête réseau. Pour converteo.app, vous pouvez ouvrir l'onglet Réseau et vérifier en temps réel qu'aucun téléchargement de fichier n'a lieu. Vous pouvez aussi utiliser uBlock Origin pour bloquer toutes les requêtes sortantes — la conversion fonctionnera quand même.

WebAssembly est-il sécurisé ?

WebAssembly s'exécute dans le même bac à sable de sécurité que JavaScript. Il ne peut pas accéder au système de fichiers, au réseau ni au système d'exploitation directement. Il est standardisé par le W3C depuis 2019.