Des outils qui ne téléchargent jamais vos fichiers
Regarder le résumé vidéo
Un PDF, un clic, et vos données s’envolent
Il y a quelques mois, je devais compresser un PDF avant de l’envoyer par email. Rien de plus banal. J’ai tapé “compresser PDF en ligne” dans Google, cliqué sur le premier résultat, déposé mon fichier… et par réflexe, j’ai ouvert les DevTools de mon navigateur.
Mon PDF de 8 Mo venait de partir sur un serveur à l’autre bout du monde.
J’ai vérifié les conditions d’utilisation du service. En substance : “Nous supprimons vos fichiers sous 24 heures.” Sous 24 heures. Mon contrat, mon dossier médical, mon relevé bancaire, stocké pendant un jour entier sur l’infrastructure d’un tiers, sans que j’aie la moindre garantie sur ce qui en est fait.
Ce jour-là, j’ai décidé de construire autre chose.
Le problème : vos fichiers n’ont rien à faire sur un serveur
Regardez le fonctionnement de n’importe quel outil en ligne “gratuit”. Le schéma est toujours le même : vous déposez votre fichier, il est envoyé vers un bucket S3, traité par une fonction Lambda ou un serveur quelconque, puis le résultat vous est renvoyé. Votre fichier a transité par au moins deux systèmes que vous ne contrôlez pas.
Et ce service est gratuit. Alors comment gagne-t-il de l’argent ? Publicités ciblées, revente de données anonymisées, upselling vers une version premium… ou tout simplement en pariant que vous ne lirez pas les CGU.
Le plus absurde, c’est que pour la grande majorité de ces opérations, aucun serveur n’est nécessaire. Convertir une image JPEG en PNG, formater du JSON, encoder du texte en Base64 : ce sont des opérations purement calculatoires. Votre navigateur est parfaitement capable de les exécuter seul.
La question qui a tout déclenché
Pourquoi est-ce que la conversion d’un JPEG en PNG nécessiterait l’envoi de mon image sur un serveur distant ?
Pourquoi est-ce que le formatage d’un fichier JSON, une opération qu’un script de trois lignes peut faire, exigerait une connexion internet ?
La réponse est simple : ce n’est pas nécessaire. C’est juste plus facile à construire côté développeur, et plus rentable côté business, de tout centraliser sur un serveur. Vos fichiers ne transitent pas par un serveur parce que c’est indispensable. Ils y transitent parce que c’est le modèle par défaut de l’industrie.
J’ai voulu prouver qu’on pouvait faire autrement.
La décision : tout faire tourner dans le navigateur
J’ai choisi de construire Vault-Tools avec une contrainte absolue : zéro requête réseau pour le traitement de fichiers. Pas de serveur, pas d’API, pas de stockage distant. Chaque opération s’exécute entièrement dans votre navigateur.
Pour y arriver, j’ai utilisé Rust compilé en WebAssembly. Rust offre des performances proches du natif et un écosystème de bibliothèques (les “crates”) suffisamment riche pour couvrir la manipulation d’images, de PDF, de texte et de fichiers. Le tout est compilé en WebAssembly via wasm-pack, ce qui permet au code de tourner directement dans le navigateur, sans aucune dépendance serveur.
Le pipeline est simple : vous déposez un fichier, le JavaScript le lit en mémoire, passe les octets au module WebAssembly, celui-ci effectue le traitement et renvoie le résultat, puis le navigateur déclenche le téléchargement. À aucun moment vos données ne quittent votre machine.
Aujourd’hui, Vault-Tools propose plus de 45 outils (compression de PDF, conversion d’images, formatage JSON, génération de QR codes, et bien d’autres) tous fonctionnant selon ce principe.
Ce que ça a coûté
Je ne vais pas prétendre que ça a été simple. Construire des outils entièrement côté client avec Rust et WebAssembly, c’est s’engager dans une voie nettement plus exigeante que de déployer un backend classique.
La courbe d’apprentissage de Rust est réelle. Le borrow checker ne fait pas de cadeaux, et le débogage en WebAssembly est loin du confort d’un console.log. Chaque erreur de compilation est un message cryptique qui vous renvoie vers la documentation.
La taille des binaires Wasm nécessite une attention constante. Chaque crate ajoutée augmente le poids du module. Il faut optimiser, découper, sous-ensembler les polices de caractères, choisir ses dépendances avec parcimonie.
La compatibilité des crates n’est pas garantie. Certaines bibliothèques Rust ne compilent tout simplement pas vers wasm32-unknown-unknown. Pour les PDF par exemple, j’ai dû épingler lopdf à la version 0.35 ; les versions plus récentes ne compilent pas en WebAssembly.
Mais chaque difficulté technique est aussi une garantie pour l’utilisateur. Si c’est difficile à contourner côté développeur, c’est que le modèle de protection est solide.
Au-delà de la vie privée
Ce qui est frappant, c’est que cette approche “privacy-first” apporte des bénéfices que je n’avais pas anticipés au départ.
La vitesse. Pas de temps d’envoi, pas de file d’attente serveur, pas de temps de téléchargement du résultat. La compression d’un PDF de 10 Mo est quasi instantanée : le fichier ne quitte jamais votre RAM.
Le fonctionnement hors ligne. Une fois la page chargée, l’outil fonctionne même sans connexion internet. En avion, dans le métro, en zone blanche : tant que votre navigateur est ouvert, vous pouvez traiter vos fichiers.
Des limites selon l’outil. L’application web utilise des limites de fichier selon l’outil (environ 10 à 100 Mo par fichier), et chaque outil affiche sa limite exacte dans son interface.
Pas de compte, pas d’inscription. Pas besoin de donner votre email pour compresser trois images. Vous arrivez, vous utilisez l’outil, vous repartez.
Vérifiez vous-même
Je ne vous demande pas de me croire sur parole. Faites le test.
- Ouvrez n’importe quel outil sur Vault-Tools, par exemple la compression de PDF.
- Ouvrez les DevTools de votre navigateur (F12 ou Cmd+Option+I sur Mac) et allez dans l’onglet Network (Réseau).
- Déposez un fichier et lancez le traitement.
- Regardez l’onglet Network.
Vous verrez exactement zéro requête réseau pendant le traitement. Pas de POST vers une API. Pas d’envoi de fichier. Rien.
Votre fichier est entré dans le navigateur et n’en est jamais sorti. C’est aussi simple que ça.
La vie privée ne devrait pas être une fonctionnalité premium ou une case à cocher dans des conditions d’utilisation que personne ne lit. Elle devrait être le comportement par défaut. C’est le principe sur lequel j’ai construit Vault-Tools, et c’est le principe qui guide chaque nouvel outil que j’ajoute.
Vos fichiers vous appartiennent. Ils devraient le rester.