Est-il sûr d'envoyer des fichiers sur Internet ?

Dernière mise à jour: 2026-08-06

« Est-ce sûr d'envoyer ce fichier ? » est une question raisonnable à se poser, qu'il s'agisse d'une déclaration d'impôts, d'un contrat, ou simplement de photos que vous préféreriez garder privées. Ce guide n'a pas pour but de vous détourner des outils courants — il s'agit d'expliquer clairement ce qui se passe réellement quand vous envoyez un fichier par e-mail, le déposez dans un dossier cloud, ou le transportez sur une clé USB, ce que les expressions « chiffré de bout en bout » et « divulgation nulle » promettent réellement, et ce qu'il faut vérifier avant de confier quelque chose d'important à n'importe quel outil.

Rien de tout cela ne nécessite de connaissances techniques. À la fin, vous saurez quelles questions poser — pour n'importe quelle méthode de transfert, y compris celle présentée ici.

Où les fichiers posent vraiment problème : les risques du quotidien

Les pièces jointes aux e-mails passent par les serveurs de votre fournisseur de messagerie et ceux du destinataire, et les deux analysent, indexent et sauvegardent couramment les messages pour le filtrage antispam et la reprise après sinistre — bien après que vous ayez oublié avoir envoyé ce fichier. Un e-mail transféré une seule fois, et le fichier se retrouve devant quelqu'un que vous n'aviez jamais prévu, sans aucun moyen de savoir si toutes les copies ont disparu.

Les liens de stockage cloud sont pratiques, mais un lien continue généralement de fonctionner jusqu'à ce que vous pensiez à le révoquer, et « toute personne disposant du lien » n'est privé que dans la mesure où l'URL est difficile à deviner — ce qu'un raccourcisseur de lien ou un transfert malencontreux peut annuler. Le fichier hérite aussi de la sécurité de tout le compte dans lequel il se trouve, pas seulement de ce partage précis.

Une clé USB paraît sûre parce qu'elle est hors ligne, mais c'est précisément là le problème : la plupart des clés ne sont pas chiffrées par défaut, donc une clé oubliée dans un sac d'ordinateur portable ou une voiture de location remet le contenu en clair à quiconque la trouve, sans aucun mot de passe requis.

Les sites de téléversement publics et gratuits résolvent le problème immédiat — faire passer un fichier de A à B — mais précisent rarement ce qui se passe ensuite : combien de temps il est conservé, s'il est analysé, qui pourrait tomber dessus par hasard, ou comment le site finance ses coûts (les hébergeurs de fichiers financés par la publicité ont un historique d'ajout de traceurs, voire pire).

E-mail : conservé et analysé par les serveurs de messagerie, facile à transférer au-delà de votre contrôle
Liens cloud : continuent de fonctionner jusqu'à révocation, et héritent de la sécurité de tout le compte
Clés USB : non chiffrées par défaut, faciles à perdre ou à oublier
Sites de téléversement gratuits : pratiques de conservation et d'analyse généralement peu claires

Ce que « chiffré de bout en bout » et « divulgation nulle » signifient réellement

De nombreux services disent « chiffré » alors qu'ils veulent simplement dire que la connexion à leur serveur est chiffrée — le HTTPS/TLS standard, la même icône de cadenas que celle de votre banque. C'est une vraie protection contre quelqu'un qui écouterait le réseau, mais elle s'arrête au serveur : une fois votre fichier arrivé, le service lui-même peut le lire, parce qu'il détient la clé. Beaucoup d'outils du quotidien s'arrêtent exactement là.

Le chiffrement de bout en bout signifie quelque chose de plus fort : le fichier est chiffré avant même de quitter votre appareil, avec une clé que seuls l'expéditeur et le destinataire possèdent. Le service qui le transporte — le serveur, le relais, tout ce qui se trouve entre les deux — ne possède jamais cette clé, et n'a donc jamais le contenu en clair, quoi qu'on lui demande.

La « divulgation nulle » est une idée voisine, généralement appliquée à ce qui est stocké plutôt qu'envoyé en direct : même des données posées tranquillement sur un serveur ont été chiffrées avec une clé que le serveur lui-même n'a jamais reçue, si bien que l'opérateur n'a aucun moyen de les lire, quelle que soit la durée pendant laquelle elles y restent.

« Chiffré » tout seul signifie souvent simplement du TLS jusqu'au serveur — le fournisseur peut toujours lire le fichier.
« Chiffré de bout en bout » signifie que seuls l'expéditeur et le destinataire détiennent la clé.
« Divulgation nulle » signifie que le serveur détient des données qu'il ne peut structurellement pas déchiffrer, même au repos.

Ce qu'il faut vraiment vérifier avant de faire confiance à un outil de transfert

Ce qu'il vous faut pour dérouler cette liste

Dix minutes et un navigateur. Les deux premiers points relèvent de la lecture, pas de l'audit.
Deux appareils pour les points en direct. Le troisième et le quatrième ne se font pas depuis une page marketing — c'est précisément ce qui les rend utiles.
Aucune expertise en sécurité. Chaque point ci-dessous est soit quelque chose que vous pouvez lire, soit quelque chose que vous pouvez voir se produire.

Le langage marketing d'un site web vaut moins que quelques questions concrètes :

Cherchez la réponse de l'éditeur à « pouvez-vous lire mes fichiers ? » dans son code source, pas sur sa page tarifs. S'il n'y a pas de source, c'est déjà une réponse.
```
https://github.com/relayium/relayium
```
Vérifiez la licence, et si le dépôt correspond bien à ce qui est déployé. Une affirmation que vous pouvez inspecter n'est pas du même ordre qu'une affirmation qu'on vous demande d'accepter.
Sur un transfert en cours, comparez le code de vérification affiché sur les deux écrans. C'est l'étape qui fait passer « chiffré de bout en bout » du statut de phrase à celui de garantie appliquée entre ces deux extrémités précises.
```
https://relayium.com/
```
Pendant ce transfert, ouvrez les outils de développement de votre navigateur et regardez le panneau réseau. Cherchez le contenu de votre fichier dans ce qui est envoyé. Ne pas l'y trouver est le but ; l'y trouver serait le résultat.
Vérifiez ce qui subsiste ensuite : si un lien expire de lui-même, et si le service pourrait encore ressortir le fichier plus tard si on le lui demandait.

Ce que réussir cette liste vous apprend réellement

Les deux premiers points ne coûtent rien et éliminent la plupart des outils en quelques minutes. Les trois derniers, aucune page d'accueil ne peut les simuler, parce que vous les voyez se produire sur vos deux propres appareils.

Rien de tout cela ne rend un outil digne de confiance dans l'absolu. Cela rend des affirmations précises vérifiables, et c'est le maximum que chacun puisse faire sans lire soi-même chaque ligne.

Est-il dit « chiffré » (ce qui pourrait n'être que du TLS) ou explicitement « chiffré de bout en bout » (seuls l'expéditeur et le destinataire détiennent la clé) ?
Existe-t-il un moyen de vérifier que la connexion n'a pas été altérée — un code que vous comparez vous-même, et pas seulement une icône de cadenas à laquelle il faut faire confiance ?
L'intégrité du fichier est-elle vérifiée, pour qu'un fichier corrompu ou modifié n'arrive pas silencieusement en paraissant intact ?
Le code est-il open source et auditable, ou ces affirmations ne sont-elles que du marketing à croire sur parole ?
L'envoi ou la réception exigent-ils de révéler plus d'identité que le transfert n'en a réellement besoin ?
Si quelque chose est stocké, a-t-il une durée de vie claire et limitée — une expiration ou une suppression après téléchargement — plutôt que de rester là indéfiniment ?

Comment Relayium répond à chacun de ces points

Pour un transfert en direct, avec les deux personnes en ligne en même temps, Relayium génère une nouvelle paire de clés X25519 sur chaque appareil et dérive une clé AES-256-GCM partagée qui n'existe qu'à l'intérieur des deux navigateurs — elle n'est jamais envoyée aux serveurs de Relayium eux-mêmes. Un court code de vérification facultatif (un SAS), affiché lorsque vous activez la vérification avancée — désactivée par défaut —, permet aux deux parties de confirmer que les clés n'ont pas été substituées par un serveur malhonnête au milieu, et le hachage SHA-256 de chaque fichier est vérifié de bout en bout, si bien qu'un transfert corrompu n'arrive pas en paraissant intact. Le détail exact de ce mécanisme est expliqué plus en profondeur dans « Comment Relayium chiffre vos fichiers de bout en bout », si vous voulez aller plus loin que cette page.

Quand le destinataire n'est pas encore en ligne, un lien de téléchargement stocké utilise un mécanisme réellement différent, à divulgation nulle : votre navigateur génère une clé AES-256-GCM aléatoire et l'utilise pour chiffrer les fichiers avant tout envoi. Cette clé n'est jamais envoyée au serveur — elle ne vit que dans le fragment d'URL du lien, la partie après le #, que les navigateurs ne transmettent jamais. Le serveur finit par détenir uniquement du texte chiffré qu'il n'a aucun moyen de déchiffrer, plus une expiration que vous choisissez : 1 heure, 1 jour, 3 jours, 7 jours, jusqu'à 14 jours selon votre offre, ou autodestruction après le premier téléchargement complet.

Entre réseaux, l'application navigateur Relayium utilise TURN par conception : le relais transporte du texte chiffré de bout en bout, mais ne reçoit jamais la clé et ne peut ni lire ni déchiffrer le fichier.

Rien de tout cela ne vous demande de croire une affirmation sur parole : le code client et serveur de Relayium est open source sous licence AGPL-3.0, et peut donc être lu et audité plutôt que simplement cru.

Les transferts sur le même réseau ne nécessitent aucun compte du tout.
Envoyer entre réseaux via un code d'appairage, ou créer un lien stocké, exige que l'expéditeur se connecte — le destinataire n'a jamais besoin de compte.

Le chiffrement n'est pas tout — quelques habitudes comptent encore

Un chiffrement solide protège un fichier en transit et au repos, mais il ne peut pas vous empêcher d'envoyer un lien à la mauvaise adresse — traitez un lien de partage comme le fichier lui-même, et ne le publiez pas quelque part de public.

Pour tout ce qui est vraiment sensible, activez la vérification avancée et prenez les quelques secondes supplémentaires pour comparer le code de vérification à voix haute lors d'un appel, ou en personne, plutôt que de faire confiance au fait que deux écrans côte à côte qui correspondent n'aient pas tous deux été trompés.

Et aucun outil de transfert, aussi bien chiffré soit-il, ne protège un fichier déjà exposé sur un appareil compromis — un bon chiffrement suppose que les deux extrémités elles-mêmes sont dignes de confiance. Rien de tout cela n'est une raison de devenir paranoïaque à l'idée d'envoyer des fichiers ; il vaut simplement la peine de savoir ce que le chiffrement couvre, et ce qu'il ne couvre pas.

Quand une vérification ne donne pas de réponse nette

Trois endroits où l'on bloque. Dans chacun, le flou lui-même est instructif.

Ce sur quoi vous tombez, ce qu'il faut vérifier, ce que cela signifie

Le panneau réseau montre un gros envoi et vous ne pouvez pas dire ce qu'il contient.

https://relayium.com/   # developer tools, Network panel, during a transfer

C'est le résultat attendu, pas une impasse. Ce que vous cherchez, c'est l'absence de tout élément reconnaissable de votre fichier — un nom de fichier que vous avez choisi, une chaîne dont vous savez qu'elle est dans le document. Si vous pouvez lire votre propre contenu dans la charge utile, c'est cela le résultat, et il est décisif.

Il n'y a pas de code de vérification, le troisième point est donc impossible.

https://relayium.com/   # a stored link has no second live endpoint to compare against

Vous êtes sur un transfert par lien stocké et non sur un transfert en direct. Aucune seconde extrémité n'est en ligne pour la comparaison, la garantie a donc une autre forme : la clé vit dans le fragment du lien et n'atteint jamais le serveur. Comparez les codes sur les transferts en direct, et vérifiez l'expiration du lien sur les transferts stockés.

Le code est ouvert, mais vous ne lisez pas le langage dans lequel il est écrit.

https://github.com/relayium/relayium   # is the claim falsifiable at all

Vous n'avez pas à le lire. La question à laquelle ce point répond est de savoir si l'affirmation est seulement réfutable : y a-t-il un dépôt, correspond-il à ce qui est déployé, quelqu'un qui lit ce langage pourrait-il la contredire. Une affirmation que personne n'est en mesure de vérifier constitue elle-même le résultat.

Questions fréquentes

Est-il sûr d'envoyer un fichier sensible par e-mail ?

L'e-mail n'est pas conçu pour le transfert confidentiel de fichiers — les pièces jointes sont couramment conservées, analysées et sauvegardées par les serveurs de messagerie des deux côtés, et un message transféré peut mettre le fichier sous les yeux de personnes que vous n'aviez jamais prévues. C'est acceptable pour des fichiers peu sensibles ; pour quelque chose de sensible, un outil chiffré de bout en bout supprime cette exposition.

Que signifie réellement « divulgation nulle » ?

Que la partie qui stocke vos données n'a jamais reçu la clé pour les lire. Le chiffrement se fait sur votre appareil avant tout envoi, et la clé ne vit que là où le serveur ne la voit jamais — comme un fragment d'URL — si bien que ce qui se trouve sur le serveur est du texte chiffré qu'il ne peut structurellement pas déchiffrer, pas simplement des données qu'il promet de ne pas regarder.

Un fichier zip protégé par mot de passe suffit-il ?

C'est mieux que rien, mais le mot de passe voyage souvent par le même canal que le fichier — dans le même fil d'e-mails, par exemple —, ce qui annule la protection, et les implémentations du chiffrement zip varient beaucoup en solidité. Un outil construit autour du chiffrement de bout en bout supprime ce maillon faible en n'ayant jamais besoin d'un mot de passe partagé.

Relayium conserve-t-il une copie de mes fichiers ?

En mode temps réel, Relayium ne conserve aucune copie côté serveur ni aucun historique de transfert : sur le même LAN, WebRTC se connecte directement ; entre réseaux, les sessions navigateur utilisent TURN par conception pour transporter un texte chiffré de bout en bout que le relais ne peut ni lire ni déchiffrer. Pour un lien stocké, le serveur ne détient que du texte chiffré qu'il ne peut pas lire, jusqu'à ce que le lien expire ou soit téléchargé une fois si vous avez choisi l'autodestruction après lecture.

Ai-je besoin d'un compte pour envoyer ou recevoir un fichier ?

Sur le même réseau, aucun des deux côtés n'a besoin de compte. Envoyer entre réseaux via un code d'appairage, ou créer un lien stocké, exige que l'expéditeur se connecte — mais la personne qui reçoit n'a jamais besoin de compte, quel que soit le mode utilisé.

Curieux de savoir si un outil protège vraiment ce qu'il prétend ? Lancez un transfert, activez la vérification avancée et observez par vous-même le code de vérification et le lien à divulgation nulle.

Essayer Relayium maintenant