Outils locaux vs cloud : la vérité 2026 sur la confidentialité
Pourquoi la plupart des outils en ligne envoient discrètement tes fichiers sur leurs serveurs, ce qu'ils en gardent, et en quoi le traitement local via WebAssembly change la donne. Faits techniques et juridiques.
Quand tu envoies une photo, un PDF ou un fichier audio sur un « convertisseur de fichiers gratuit en ligne », que se passe-t-il vraiment ? En 2026, la réponse surprend souvent ceux qui tiennent à leur vie privée : la plupart de ces outils envoient discrètement ton fichier sur leurs serveurs, le traitent là-bas, et en gardent une copie, parfois pendant des heures, parfois indéfiniment.
Ce guide explique la différence technique entre traitement côté serveur et traitement côté client, pourquoi c’est important sur le plan juridique et personnel, et comment vérifier de quel type d’outil il s’agit.
Ce que « uploader » signifie vraiment
Quand tu visites un outil en ligne classique et que tu glisses un fichier dedans, voici ce qui se passe techniquement :
- Le navigateur ouvre une connexion TCP vers le serveur de l'outil.
- Les octets du fichier sont envoyés sur cette connexion (c'est la barre de progression d'upload).
- Le serveur reçoit les octets et les écrit sur disque (ou en mémoire).
- Le serveur exécute la conversion / compression / peu importe.
- Le serveur écrit le résultat sur disque.
- Le navigateur télécharge le résultat.
- Le serveur peut ou non supprimer l'original. C'est sa politique, ta confiance.
« Supprimé après 24 heures » est dur à auditer
Même les outils qui annoncent une rétention courte gardent souvent des logs, des métadonnées, des données dérivées ou des copies de sauvegarde. Vérifier tout cela exige un accès à l'infrastructure de l'outil, que tu n'as pas. La confiance sans vérification, ce n'est pas de la sécurité.
Ce que « traitement côté client » signifie vraiment
Entre 2020 et 2022, les navigateurs sont devenus assez puissants pour exécuter du traitement lourd en local via WebAssembly (WASM), un format binaire qui permet à des bibliothèques C/C++/Rust (comme libjpeg, ffmpeg, pdf-lib) de tourner à vitesse quasi native dans l’onglet du navigateur.
Flux côté serveur
- Ouverture de la page (~200 Ko)
- Glisser le fichier → octets uploadés
- Le serveur traite
- Octets téléchargés en retour
- Le serveur peut garder une copie
Aller-retour réseau requis pour chaque opération. Tu fais confiance à la politique de rétention de l'opérateur.
Flux côté client (WASM)
- Ouverture de la page → chargement du module WASM (~2 à 5 Mo)
- Glisser le fichier → lu en mémoire du navigateur
- WASM traite à l'intérieur de l'onglet
- Résultat généré en mémoire
- Enregistrer → le fichier va sur ton appareil
Zéro requête sortante avec un payload de fichier. Vérifie dans les DevTools.
Le fichier ne traverse jamais le réseau au-delà du chargement initial de la page.
Comment vérifier qu’un outil est bien local
Ne fais pas confiance au badge « 100 % privé ». Vérifie toi-même :
| Méthode | Ce que tu fais | Ce que tu cherches | Effort |
|---|---|---|---|
| DevTools Réseau | F12 → Réseau → glisser le fichier → traiter | Zéro POST/PUT sortant avec payload de fichier | 30 s |
| Mode avion | Charger la page, désactiver le Wi-Fi, traiter | L’outil fonctionne toujours après déconnexion | 60 s |
| Fermeture d’onglet | Traiter un fichier, fermer l’onglet, rouvrir | Pas de « fichiers récents », pas de trace côté serveur | 30 s |
Test DevTools Réseau en 5 étapes
- Ouvre l'outil dans Chrome / Firefox / Safari.
- Appuie sur
F12→ onglet Réseau. - Clique sur Effacer pour vider les requêtes passées.
- Glisse ton fichier et lance l'outil.
- Si tu vois
POST /api/uploadavecContent-Length: 5000000+, le fichier est parti sur un serveur. Un vrai outil local n'affiche rien de tel.
Pourquoi ça compte : 5 scénarios réels
Journaliste avec des enregistrements de source confidentielle
Tu as interviewé un lanceur d’alerte. L’enregistrement de sa voix contient des informations identifiantes qui pourraient le mettre en danger. Tu dois extraire l’audio d’un fichier vidéo. Une extraction côté serveur placerait l’enregistrement sur du matériel que tu ne contrôles pas, soumis à assignations, piratages ou menaces internes. L’extraction locale via DuneTools Extraire l’audio garde le fichier uniquement sur ton portable.
Professionnel de santé avec des documents patients
HIPAA aux États-Unis, RGPD en UE, équivalents ailleurs : les dossiers patients ne peuvent pas être transmis à des sous-traitants tiers sans garanties contractuelles spécifiques. Une infirmière qui essaierait de compresser un PDF de résultats de labo avant de l’e-mailer à un confrère violerait techniquement HIPAA si le compresseur upload sur un serveur tiers. La compression locale règle tout ça d’un coup.
Avocat avec des documents privilégiés
Le secret professionnel peut être levé quand on partage des documents privilégiés avec des tiers. Même dans les juridictions au privilège le plus fort, uploader un PDF privilégié sur un compresseur en ligne gratuit risque de lever ce privilège. Le traitement local évite entièrement le tiers.
Designer avant lancement
Tu conçois une nouvelle identité produit. Les fichiers du logo et les assets de marque sont confidentiels jusqu’au lancement. Uploader le logo sur un générateur de favicon, c’est qu’il se retrouve sur le matériel d’un autre avant la révélation publique. Concurrents, fuites, hackers, l’un de ces vecteurs peut briser la confidentialité avant lancement. La génération locale garde tout strictement en interne.
Quiconque a des photos personnelles
Ton téléphone contient 10 000 photos. Certaines sont familiales, certaines sont intimes, certaines sont des documents que tu as photographiés. Les uploader sur un « compresseur gratuit », c’est qu’elles existent hors de ton contrôle. Même avec la meilleure politique de confidentialité, des fuites arrivent, des employés abusent de leurs accès, des gouvernements assignent. Le traitement local fait que la photo n’a jamais quitté ton appareil.
L’angle juridique : RGPD, CCPA, HIPAA
| Réglementation | Région | Ce que déclenche le côté serveur | Impact du traitement local |
|---|---|---|---|
| RGPD | UE/EEE | Contrat de sous-traitance, notification 72 h, droits de suppression, minimisation | Hors champ, aucun tiers impliqué |
| CCPA / CPRA | Californie | Droit d’accès, suppression, opt-out de la vente | Hors champ |
| HIPAA | Santé US | Business Associate Agreement requis (rare pour les outils gratuits) | Conforme par conception |
| PIPEDA | Canada | Déclaration de transfert transfrontalier | Aucun transfert |
| LGPD | Brésil | Similaire au RGPD, supervision par autorité nationale | Hors champ |
Posture de conformité prête pour audit
Pour les organisations, « nous utilisons des outils de traitement local » est nettement plus facile à défendre en audit et en revue de conformité que « nous uploadons des fichiers sur divers services tiers ». La première phrase tient en une ligne, la seconde est un cauchemar de gestion du risque fournisseur.
L’angle performance
À contre-courant : le traitement local est souvent plus rapide.
| Charge de travail | Temps côté serveur | Temps local (WASM) | Gagnant |
|---|---|---|---|
| Compression image 5 Mo | 4 s upload + 1 s traitement + 1 s download = 6 s | 0,8 s dans le navigateur | Local |
| Extraction vidéo 100 Mo | 16 s up + 5 s + 16 s down = 37 s | 8 s | Local |
| Fusion PDF 50 Mo | 8 s up + 2 s + 8 s down = 18 s | 3 s | Local |
| Transcodage vidéo 1 Go | Souvent impossible côté client | n/a | Serveur |
| Upscale ML (gros modèle) | Possible côté serveur | n/a | Serveur |
Quand le côté serveur est vraiment nécessaire
Le local n’est pas toujours possible :
- Opérations qui exigent une RAM massive au-delà de ce que les navigateurs exposent (~4 Go max sur Chrome moderne, moins sur Safari mobile).
- Opérations basées sur du ML avec de gros modèles (poids de l’ordre du Go, trop lourds pour le navigateur).
- Opérations dépendantes du réseau (récupération d’URL avec auth, téléchargement vidéo depuis des sources avec cookies).
- Workflows multi-fichiers collaboratifs (deux personnes éditent le même doc, état serveur nécessaire).
Pour tout le reste, en 2026, le local devrait être le défaut.
Comment DuneTools est construit
Chaque utilitaire DuneTools tourne intégralement côté client via WebAssembly. Concrètement :
- Outils image :
mozjpeg.wasm,oxipng.wasm,libwebp.wasm,libavif.wasm, encodage/décodage de tous les formats d’image en local. - Outils PDF :
pdf-lib.wasm,pdfjs.wasm, lecture/écriture/manipulation complète du PDF sans serveur. - Outils audio :
lamejs.wasm(encodage MP3),ffmpeg.wasm(transcodage), traitement audio dans le navigateur. - Outils vidéo :
ffmpeg.wasmpour la mise en sourdine, l’extraction de frames, la conversion de format.
Tu peux vérifier chacun avec les méthodes ci-dessus. L’architecture est ouverte : inspecte l’onglet Réseau, fais des tests en mode avion, regarde les modules WASM dans l’onglet Sources des DevTools.
En résumé : dans le doute, va au local
En 2026, pour toute opération de fichier sous 2 Go, le traitement local devrait être ton défaut. Les bénéfices côté confidentialité sont réels (aucune donnée ne quitte ton appareil), les bénéfices juridiques sont réels (la plupart des réglementations ne s’appliquent pas si aucun tiers n’est impliqué), la performance est compétitive ou meilleure, et le coût est le même (la plupart des outils locaux sont gratuits, puisqu’il n’y a pas de serveur à financer).
Que tu utilises DuneTools ou un autre outil côté client, le principe est le même : tes fichiers, ton appareil, ta sortie. Pas besoin de cloud.