Ouvrez les outils de développement de votre navigateur avec F12, passez à l'onglet Réseau et videz-le. Déposez ensuite votre fichier dans l'outil et démarrez le traitement. Observez les requêtes qui apparaissent : si aucune ne transporte votre fichier, et si la taille de chaque requête est bien inférieure au fichier, rien n'a été téléversé.
Deux autres tests le confirment. Coupez votre connexion après que l'outil s'est chargé une fois et réessayez : un outil local continue de fonctionner, un outil basé sur un serveur non. Regardez ensuite à quels domaines la page parle, car un téléversement de fichier est une requête vers un point de terminaison précis et sa taille est proportionnelle à votre document. Les sections ci-dessous donnent les étapes exactes, et les requêtes qui semblent alarmantes mais ne sont que du code ou du suivi de page. Aucune de ces vérifications ne nécessite de logiciel au-delà du navigateur que vous avez déjà ouvert.
Une promesse de confidentialité sur une page d'outil vaut exactement ce que vaut votre capacité à la vérifier. La bonne nouvelle est que la vérification est courte, ne nécessite aucun logiciel spécial et fonctionne sur n'importe quel navigateur. Vous ne cherchez pas une promesse. Vous cherchez une chose précise : une requête qui transporte votre fichier.
Compresseur d'image
Un sujet propre pour le test : chargez une image, observez le panneau, puis déconnectez-vous et compressez-en une autre. Rien n'est téléversé dans un cas comme dans l'autre.
Test un : observez les octets dans le panneau réseau
C'est la méthode principale, et elle prend environ une minute. Vous vérifiez si une requête transporte une charge utile à peu près de la taille de votre fichier.
- Ouvrez les outils de développement. Appuyez sur F12, ou utilisez le menu du navigateur et choisissez Outils de développement. Passez à l'onglet Réseau.
- Videz la liste. Cliquez sur le bouton d'effacement, généralement un cercle barré d'une ligne. Cela supprime les ressources de la page, seules restent donc les requêtes issues de l'action sur votre fichier.
- Activez Conserver le journal si vous voulez une vue complète. Il garde les requêtes visibles à travers un rechargement de page, ce qui aide lorsqu'un outil navigue ou rafraîchit en cours de traitement.
- Déposez votre fichier et lancez l'outil. Utilisez un fichier d'une taille distinctive, idéalement quelques mégaoctets, pour qu'une requête correspondante soit évidente.
- Observez la colonne de taille. Chaque requête est listée avec sa taille transférée. Lisez la plus volumineuse. Si la plus grosse requête est un script, une police ou un petit appel de suivi, le fichier n'a jamais bougé.
- Cliquez sur la requête la plus volumineuse et lisez ses détails. Les onglets En-têtes, Charge utile et Taille vous disent ce qui a été envoyé. Un véritable téléversement apparaît comme une requête dont la taille est à peu près celle de votre fichier.
Ce que vous cherchez a une signature précise. Un téléversement est généralement une requête POST vers un point de terminaison comme /upload ou /convert, et sa taille est proche de celle du fichier. Si la requête est un formulaire, le type de contenu est probablement multipart/form-data. Si le fichier est envoyé en octets bruts ou en base64, le type de contenu est celui du fichier lui-même, ou la charge utile est un corps JSON contenant les données. Dans les trois cas, la taille le trahit, c'est pourquoi la colonne de taille est celle à lire en premier.
Déverrouiller un PDF
Un cas sensible qui mérite d'être testé. Le PDF et le mot de passe sont tous deux lus dans l'onglet, le panneau ne montre donc aucune requête transportant l'un ou l'autre.
Test deux : déconnectez-vous et continuez à travailler
Le test hors ligne répond à une autre question, et il est plus difficile à falsifier. Si le traitement s'achève encore sans aucun réseau, alors aucun serveur ne peut être impliqué dans le travail.
- Chargez l'outil et traitez d'abord un fichier. Cela met en cache le moteur dont il a besoin, ce qui est un téléchargement normal de code et non votre fichier.
- Déconnectez-vous du réseau. Désactivez le Wi-Fi, débranchez le câble, ou utilisez le menu de limitation de débit des outils de développement et réglez-le sur Hors ligne.
- Traitez un autre fichier sans recharger la page. Ne rafraîchissez pas, car un rechargement doit récupérer la page elle-même et échouera pour des raisons qui n'ont rien à voir avec un téléversement.
- Observez le résultat. Un outil local produit son résultat. Un outil basé sur un serveur échoue, généralement avec une erreur réseau dans sa ligne d'état.
L'ordre de ces étapes est toute l'astuce. Si vous vous déconnectez d'abord et rechargez, vous testez la récupération de la page, pas le traitement. Et si vous n'avez jamais lancé l'outil avant de passer hors ligne, un échec peut simplement signifier que le moteur n'était pas encore en cache. Lancez une tâche en ligne, coupez la connexion, lancez une seconde tâche.
Test trois : regardez les domaines et la politique de sécurité
L'endroit où une page envoie des données est aussi révélateur que la quantité. Dans le panneau réseau, vous pouvez trier ou filtrer par domaine, et les domaines qu'un outil local touche sont banals : son propre hôte, un hôte de police ou de script, et éventuellement un fournisseur d'analyse. Un convertisseur qui tourne sur un serveur doit atteindre son propre point de terminaison de téléversement, et ce point de terminaison apparaît généralement sur le même domaine que le site.
Un signal plus strict est l'en-tête Content-Security-Policy, que vous pouvez lire dans l'onglet En-têtes de la requête du document principal. Une politique avec une directive connect-src serrée nomme les origines exactes que la page est autorisée à appeler, ce qui limite où un fichier pourrait aller même en théorie. Son absence ne prouve rien, car de nombreux sites n'en définissent tout simplement pas. Associez-la aux preuves réseau plutôt que de la traiter comme un test à elle seule.
Ce qui semble suspect mais ne l'est pas
La plupart des fausses alertes viennent de quatre types de requêtes. Les connaître vous évite de mal interpréter un résultat propre comme une fuite.
- Analyses et gestionnaires de balises. Une vue de page est signalée à un service de mesure, c'est pourquoi vous voyez un script provenant d'un domaine d'analyse. Il transporte le fait qu'une page s'est chargée, pas le contenu de votre document. Ce site charge Google Tag Manager, vous verrez donc exactement cette requête.
- Téléchargements du moteur au premier chargement. Un outil du navigateur récupère son moteur de traitement la première fois que vous l'utilisez. Cette requête est volumineuse, ce qui la fait ressembler à un téléversement, mais elle est identique pour chaque visiteur et ne change pas selon votre fichier. La taille reste constante tandis que votre entrée change.
- Polices et icônes. Les polices et les sprites d'icônes sont des fichiers séparés et apparaissent comme leurs propres requêtes. Elles font généralement quelques centaines de kilooctets au maximum.
- En-têtes d'isolation cross-origin. Certains outils WebAssembly nécessitent les en-têtes COOP et COEP pour le travail multithread. Les voir est un signe qu'un vrai moteur s'exécute dans la page, pas un signe que votre fichier circule. Les outils de ce site utilisent un moteur monothread et n'en ont pas besoin.
La ligne de démarcation est simple. Le code et les ressources de page ont des tailles qui restent identiques quel que soit ce que vous téléversez. Votre fichier a une taille qui n'apparaît sur le réseau que s'il est réellement envoyé. Comparez le total des octets transférés à la taille de votre entrée, et la réponse n'est pas ambiguë.
Où cette méthode a des limites
Les tests ci-dessus sont solides, et ils ne sont pas absolus. Être clair sur les lacunes est ce qui rend le reste de la page digne de confiance.
- Le découpage en morceaux masque les lignes individuelles, pas le total. Un outil pourrait diviser un fichier en de nombreuses petites requêtes. Additionner le total des octets transférés déjoue cela, c'est pourquoi la comparaison des tailles compte plus que n'importe quelle ligne isolée.
- Un service worker peut masquer un échec hors ligne. Si un site met en cache ses propres pages, un rechargement hors ligne peut encore fonctionner. Le test hors ligne n'est fiable que lorsque vous évitez de recharger et vous fiez à une tâche terminée.
- Le trafic peut être chiffré et opaque. En HTTPS, vous ne pouvez pas lire le contenu d'une requête, seulement sa taille et sa destination. La taille suffit à repérer un téléversement de fichier, mais elle ne vous dira pas ce que contient une petite requête.
- Local ne signifie pas automatiquement sûr. Le traitement dans l'onglet exclut un téléversement. Cela ne dit rien d'autres risques, comme une page qui lirait davantage de votre disque lors d'une étape ultérieure. Vérifiez l'affirmation précise qui est faite plutôt que de présumer un bon comportement partout.
- Certains outils ont réellement besoin d'un serveur. Les grands modèles de suppression d'arrière-plan ou d'amélioration générative ne tiennent pas dans un budget de téléchargement navigateur, et ces outils le disent. Le schéma honnête est une page qui vous indique quelles fonctionnalités téléversent et lesquelles ne le font pas, comme le fait la section Cloud AI ici.
Si vous voulez l'explication sous-jacente de la raison pour laquelle un onglet peut faire ce travail, le guide compagnon sur comment fonctionnent les outils de fichiers dans le navigateur parcourt les couches du moteur, de Canvas et de la File API. Si vous voulez juste un outil à tester, n'importe quelle page du répertoire d'outils fonctionne, et Fusionner un PDF est un bon second sujet car les tailles d'entrée et de sortie sont faciles à comparer.