Dernière mise à jour: 2026-07-09
« 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 « connaissance 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.
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 d'upload public 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).
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 prévu détiennent jamais. 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 « connaissance 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.
Le langage marketing d'un site web vaut moins que quelques questions concrètes :
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 affiché à l'écran (un SAS) 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, à connaissance 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 chiffré qu'il n'a aucun moyen de déchiffrer, plus une expiration que vous choisissez : 1 heure, 1 jour, 3 jours, 7 jours, ou effacement après le premier téléchargement complet.
Quand une connexion directe entre deux appareils n'est pas possible, le flux chiffré bascule vers un relais TURN plutôt que d'échouer — et ce relais aussi ne voit toujours que du chiffré, jamais un fichier lisible.
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 MIT, et peut donc être lu et audité plutôt que simplement cru.
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, prenez les quelques secondes supplémentaires pour comparer un 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.
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 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 chiffré qu'il ne peut structurellement pas déchiffrer, pas simplement des données qu'il promet de ne pas regarder.
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é.
En mode temps réel, non — le fichier circule directement entre les deux navigateurs et rien n'est stocké. Pour un lien stocké, le serveur ne détient que du 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'effacement après premier téléchargement.
Sur le même réseau, aucun des deux côtés n'a besoin de compte. Envoyer entre réseaux via un code de jumelage, 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 et observez par vous-même le code de vérification et le lien à connaissance nulle.
Essayer Relayium maintenant