3 octobre 2026 · 8 min de lecture

Outil dans le navigateur ou avec envoi : coupez le Wi-Fi, vous verrez

Comment un site modifie votre fichier sans jamais le recevoir : canvas, WebAssembly, modèles d'IA locaux. Et le défi hors ligne qui prouve lequel vous utilisez.

« Rien n'est envoyé » sonne comme du marketing. L'hypothèse saine, c'est que ça veut dire « envoyé, puis supprimé, probablement ». Et pourtant ça peut être littéralement vrai — il vaut la peine de comprendre pourquoi, parce qu'une fois le mécanisme connu, vous pouvez le tester, et tester vaut toujours mieux que croire.

La méthode habituelle : envoyer, traiter, télécharger

Un outil en ligne classique est une façade légère boulonnée à un serveur. Vous choisissez un fichier, le navigateur expédie les octets sur le réseau, un programme sur une machine quelque part fait le travail, le résultat revient. Ça a de vrais avantages : le serveur peut être énorme, le logiciel peut être n'importe lequel, et un téléphone de 2017 obtient le même résultat qu'une station de travail.

Le coût est structurel. Une copie de votre fichier se trouve maintenant sur du matériel que vous ne contrôlez pas, pour la durée que fixent leur politique de conservation, leurs sauvegardes et leur définition de « temporaire ». La plupart des opérateurs sont corrects. Vous ne pouvez pas savoir lesquels.

L'autre méthode : votre navigateur est l'ordinateur

Un navigateur moderne est un véritable environnement d'exécution, pas une visionneuse de documents. Le code de la page peut lire un fichier que vous choisissez, le reconstruire et vous en rendre un nouveau, sans qu'un seul octet traverse le réseau. Les briques qui rendent ça possible :

• L'API File. Vous choisissez un fichier et la page obtient un accès en lecture à ces octets, sur votre propre disque. Choisir un fichier n'envoie rien nulle part.
• Le canvas. Dessinez une image dans un canvas et exportez-la : vous avez réencodé les pixels. C'est le redimensionnement et la baisse de qualité — et c'est pourquoi les métadonnées disparaissent, puisque le nouveau fichier est construit à partir de pixels, pas copié depuis l'ancien.
• WebAssembly. De vrais programmes compilés qui tournent dans l'onglet à une vitesse quasi native. C'est ainsi que ffmpeg — le moteur derrière presque tout le traitement vidéo — réencode de la vidéo dans un navigateur.
• ONNX Runtime et compagnie. Des réseaux de neurones téléchargés une fois et exécutés dans l'onglet. C'est comme ça que la suppression de fond marche sans serveur : le modèle fait son inférence sur votre appareil.
• Les Blob URL. Le fichier fini vous est remis comme un téléchargement généré localement. Pas d'aller-retour, puisqu'il n'y a jamais eu de voyage.

Voici la conséquence qui compte : le seul rôle du serveur est de livrer le code. Une fois la page chargée, le serveur n'a plus rien à voir avec le travail. C'est exactement pour ça que vous pouvez débrancher Internet et continuer.

Le défi

• Chargez la page entièrement. Laissez les modèles et les paquets WebAssembly finir de se télécharger.
• Déconnectez. Wi-Fi éteint, câble débranché.
• Utilisez l'outil sur un vrai fichier.
• Un résultat ? Il a été calculé sur votre appareil. Une page sans réseau ne peut pas consulter un serveur.

La version outils de développement est tout aussi décisive. Onglet Réseau, videz la liste, traitez un fichier. Vous verrez les ressources de la page, peut-être un fichier de modèle, peut-être un ping d'analytique. Sur un outil local, vous ne verrez pas de requête dont la charge a la taille de votre fichier. Apprenez cette forme une fois et vous pourrez auditer n'importe quel site en trente secondes, pour toujours.

Ce que le traitement local gagne, et ce qu'il coûte

Cette dernière ligne est la vraie frontière, pas une échappatoire. Aller chercher quelque chose sur un autre site, interroger une base de données, exécuter un modèle trop gros pour être téléchargé : rien de tout ça ne peut se passer dans votre onglet, par définition. Un outil qui doit contacter Internet pour vous est un outil serveur, et les bonnes intentions ne changent pas l'architecture.

Pourquoi votre grosse vidéo est lente, et pourquoi c'est le prix à payer

Réencoder de la vidéo est l'une des tâches les plus lourdes qu'un appareil grand public exécute. Dans un onglet, ça passe par WebAssembly sur votre propre processeur, sur un seul fil, avec un plafond de mémoire. Un clip 4K de dix minutes peut prendre de longues minutes sur un portable et manquer de mémoire sur un vieux téléphone. Rien n'a été envoyé, donc rien n'a été fait par une machine plus rapide que la vôtre. Coupez d'abord, choisissez une résolution raisonnable, gardez l'onglet au premier plan, utilisez un ordinateur portable si vous en avez un.

Comment Skrubly est réellement construit

Cinq outils sont entièrement locaux. Le nettoyeur de métadonnées lit et réécrit les fichiers dans l'onglet. Le compresseur utilise le canvas pour les images, une bibliothèque PDF pour les documents, et ffmpeg compilé en WebAssembly pour la vidéo. La suppression de fond télécharge un petit modèle de segmentation open source hébergé ici et l'exécute sur votre appareil. Le détecteur de texte IA et le vérificateur d'images IA analysent ce que vous leur donnez dans l'onglet. Pour les cinq : jamais envoyés, jamais stockés sur un serveur, et toujours fonctionnels réseau débranché.

Le téléchargeur TikTok est l'exception, et d'après la logique ci-dessus il ne peut pas en être autrement — aller chercher une vidéo sur TikTok est précisément ce que seul un serveur peut faire. Le lien que vous collez part sur notre serveur, qui demande à un prestataire tiers de trouver une version téléchargeable, et la vidéo est récupérée côté serveur. Ce qui voyage est une URL publique, pas un de vos fichiers.

Le site lui-même se comporte comme un site : financé par la publicité, cookies, statistiques agrégées, et données techniques courantes comme l'adresse IP, le navigateur et les pages visitées, comme le décrit la politique de confidentialité. L'affirmation ici est précise plutôt que large. C'est ce qui la rend testable.