Téléversez un fichier vers un convertisseur basé sur serveur et trois choses se produisent. Votre fichier voyage sur le réseau vers une adresse IP que vous ne contrôlez pas. Un processus sur ce serveur le décode. Ensuite, selon la politique de conservation du site, le fichier reste sur le disque pendant une durée allant de quelques minutes à indéfiniment.
Faites la même chose dans un onglet de navigateur et le fichier ne quitte jamais la RAM de votre machine. Le décodeur s'exécute dans un bac à sable WebAssembly que le moteur du navigateur applique. Le réseau n'est jamais touché.
Ce n'est pas une différence de politique. C'est une différence architecturale. Un convertisseur basé sur serveur peut promettre de supprimer vos fichiers ; un convertisseur basé sur navigateur ne peut pas les divulguer car il ne les reçoit jamais en premier lieu.
L'architecture
Quatre couches rendent possible la conversion côté client :
Couche 1 : Accès aux fichiers
Lorsque vous déposez un fichier dans un onglet de navigateur, le DragEvent ou <input type="file"> donne à JavaScript un objet File. Un File n'est pas le contenu du fichier. C'est une référence : un nom, une taille, un type MIME et une méthode (file.arrayBuffer()) qui lit les octets du disque vers la mémoire à la demande.
Tant que cette méthode n'est pas appelée, zéro octet n'a été déplacé. Le fichier reste sur votre système de fichiers. Le sélecteur de fichiers du navigateur est une boîte de dialogue au niveau du système d'exploitation ; la page web ne voit que l'objet File que l'utilisateur a explicitement sélectionné.
Couche 2 : Détection du format
Les premiers octets de tout fichier identifient son format de manière fiable. Un JPEG commence par FF D8 FF. Un PNG commence par 89 50 4E 47. Un fichier HEIC contient une boîte ftyp avec une marque heic ou heif à l'offset 8.
Lire l'en-tête d'un fichier (les 32 premiers octets, généralement) suffit pour confirmer ce qu'il est réellement, quelle que soit l'extension. Cette vérification s'exécute avant que tout décodeur ne touche aux données de pixels. Si l'en-tête ne correspond pas, le fichier est immédiatement rejeté. Pas de CPU gaspillé, pas de messages d'erreur confus au milieu d'un décodage.
Couche 3 : Décodage
Les octets bruts deviennent des pixels via un décodeur. Le décodeur utilisé dépend du format :
- JPEG, PNG, WebP, BMP : le navigateur fournit des décodeurs natifs pour ces formats.
createImageBitmap()transmet les octets compressés au codec de la plateforme (Windows Imaging Component sous Windows, Core Graphics sous macOS, Skia sous Linux/ChromeOS) et renvoie des données de pixels brutes. Ce chemin est rapide, accéléré matériellement lorsque le système d'exploitation le prend en charge, et ne nécessite aucun code supplémentaire. - HEIC : aucun navigateur sauf Safari ne fournit de décodeur HEIC natif. Notre convertisseur intègre libheif, une bibliothèque C, compilée en WebAssembly. Le binaire
.wasm(~1,2 Mo compressé) se télécharge une fois et se met en cache. Il décode les fichiers HEIF/HEIC en pixels RVB bruts entièrement dans le bac à sable WASM. - PDF : PDF.js (le moteur de rendu PDF de Mozilla) rend chaque page sur un canevas à la résolution demandée. Pas de rendu côté serveur. Le PDF ne quitte jamais le navigateur.
Chaque décodeur lit depuis la mémoire et écrit dans la mémoire. Aucun n'ouvre de sockets. Le bac à sable WASM en particulier ne peut pas faire de requêtes réseau : le navigateur n'expose pas d'API réseau aux modules WebAssembly. Même si le code C appelait socket(), le bac à sable l'intercepterait.
Couche 4 : Encodage
Les pixels bruts vont dans le contexte 2D d'un élément <canvas>. canvas.toBlob() ou canvas.toDataURL() appelle l'encodeur intégré du navigateur pour la sortie JPG, PNG ou WebP. L'encodeur est du code natif de la plateforme : le même chemin de code que celui utilisé par votre système d'exploitation pour enregistrer des captures d'écran.
La sortie est un Blob, un tampon d'octets en mémoire. Il est transmis à un lien de téléchargement ou empaqueté dans une archive ZIP construite en JavaScript. À aucun moment un seul octet ne touche un socket réseau.
Ce que le navigateur applique
Les pages web s'exécutent dans un bac à sable que le navigateur maintient au niveau du moteur. Ce n'est pas un accord de politesse. C'est imposé par l'isolation des processus :
Processus de rendu : le moteur JavaScript, le DOM et l'environnement d'exécution WASM vivent dans un processus isolé sans accès direct au système de fichiers ni au réseau. Il communique avec le monde extérieur par IPC vers le processus du navigateur.
Isolation de site : les navigateurs modernes placent chaque origine dans son propre processus de rendu. Vos fichiers sur file-convert-factory.org sont invisibles pour le JavaScript s'exécutant sur tout autre domaine.
Bac à sable WASM : les modules WebAssembly voient un tampon mémoire linéaire plat et rien d'autre. Pas d'API de système de fichiers, pas de fetch sauf s'il est explicitement importé depuis JavaScript, pas d'accès au DOM ou à d'autres API du navigateur. Le pire qu'un module WASM compromis pourrait faire est de corrompre sa propre mémoire et de planter l'onglet.
Un convertisseur basé sur serveur s'exécute comme un processus privilégié sur le système d'exploitation du serveur. Il peut lire et écrire sur le disque, ouvrir des connexions réseau et lancer des processus enfants. Le modèle de sécurité dépend de la compétence et des intentions de l'opérateur du serveur. Le bac à sable du navigateur dépend uniquement de la correction du moteur du navigateur, et les bacs à sable des navigateurs font partie des barrières de sécurité les plus rigoureusement auditées dans le logiciel.
Ce que les convertisseurs basés sur serveur promettent (et ne promettent pas)
Les convertisseurs basés sur serveur ne sont pas intrinsèquement malveillants. Beaucoup sont gérés par des équipes bien intentionnées. Le problème est structurel :
- L'étape de téléversement est une copie. Votre fichier existe maintenant à deux endroits. Vous contrôlez une copie. Quelqu'un d'autre contrôle l'autre.
- La suppression est une promesse. « Nous supprimons les fichiers après 24 heures » signifie faire confiance à la ligne de log, à la tâche cron, au système de sauvegarde et à chaque employé ayant accès au serveur. Rien de tout cela n'est vérifiable de l'extérieur.
- Les métadonnées voyagent avec le fichier. Les données EXIF de votre photo (coordonnées GPS, numéro de série de l'appareil photo, horodatage) font partie des octets du fichier. Si le fichier est téléversé, les métadonnées sont téléversées. Notre guide de confidentialité EXIF couvre exactement ce qui s'y trouve et comment les supprimer. En bref : chaque convertisseur sur ce site supprime les métadonnées car il décode les pixels et les ré-encode, abandonnant tout ce qui n'est pas des données d'image.
- HTTPS protège le tuyau, pas le point d'arrivée. TLS chiffre le téléversement en transit. Cela ne fait rien pour ce qui arrive au fichier après son arrivée.
La garantie de confidentialité d'un convertisseur basé sur navigateur est plus étroite mais plus forte. Elle dit : vos fichiers ne quittent pas votre appareil car il n'existe aucun chemin de code pour qu'ils le fassent. C'est vérifiable. Ouvrez l'onglet Réseau dans les DevTools pendant la conversion d'un fichier. Vous verrez le binaire WASM se charger une fois, puis rien. Zéro octet téléversé. Aucune requête vers /api/convert. Aucun trafic WebSocket. La conversion se produit entièrement dans le processus de rendu.
Vérifiez par vous-même
Vous n'avez pas besoin de croire qui que ce soit sur parole. Ouvrez Chrome DevTools (F12), passez à l'onglet Réseau et convertissez un fichier sur n'importe quelle page d'outil. La seule activité réseau que vous verrez :
- Le HTML, CSS et JavaScript de la page : chargés une fois lors de la première visite.
- Le binaire WASM (pour les convertisseurs HEIC) : chargé une fois, mis en cache ensuite.
- Les requêtes d'analyse (si vous ne les avez pas bloquées).
Aucune donnée de fichier ne quitte le navigateur. Le Content-Length de chaque requête se mesure en kilooctets, pas en mégaoctets. C'est vérifiable indépendamment par quiconque sait ouvrir les DevTools.
On ne peut pas en dire autant d'un service basé sur serveur. Vous téléversez le fichier, vous obtenez un résultat, et vous faites confiance au serveur pour l'avoir supprimé.
Outils connexes
Chaque convertisseur sur ce site suit cette architecture. Le pipeline (déposer, valider, décoder, encoder, télécharger) s'exécute de manière identique sur les 23 outils :
- HEIC vers JPG · HEIC vers PNG · HEIC vers WebP
- JPG vers PNG · JPG vers WebP · JPG vers ICO
- PNG vers JPG · PNG vers WebP · PNG vers ICO
- WebP vers JPG · WebP vers PNG · WebP vers ICO
- BMP vers JPG · BMP vers PNG · BMP vers WebP · BMP vers ICO
- PDF vers JPG · PDF vers PNG · PDF vers WebP
- Image vers texte (OCR) : même architecture côté client, exécute Tesseract dans WASM
Pour les détails techniques du bac à sable WASM, consultez notre explication WebAssembly. Pour un aperçu plus approfondi des métadonnées que vos photos contiennent, le guide de confidentialité EXIF explique comment les lire et les supprimer octet par octet.
