Sécurité

Conçu pour qu'il n'y ait rien à perdre sur nos serveurs

Dernière mise à jour le 20 août 2026

En résumé

FileTransferX déplace les fichiers directement entre deux navigateurs plutôt que de les envoyer chez nous. Le seul rôle de notre serveur est d'aider deux appareils à se trouver — il ne reçoit, ne stocke ni ne lit jamais vos fichiers. Les connexions sont chiffrées de bout en bout, les codes d'association ont une durée de vie courte et un usage unique, et fermer l'onglet met fin à la session immédiatement. Cette page explique précisément ce que cela signifie, point par point.

Les fichiers sont transférés de navigateur à navigateur

Lors d'un transfert, les données du fichier circulent directement entre le navigateur qui envoie et celui qui reçoit, sur une connexion que chaque navigateur négocie et chiffre de bout en bout par lui-même — les données de fichier qu'elle contient ne sont pas lisibles par un serveur intermédiaire, que celui-ci relaie le trafic ou non. L'infrastructure de FileTransferX n'intervient que pour aider les deux navigateurs à s'entendre sur la façon de se connecter ; elle n'est pas un destinataire des données du fichier.

FileTransferX ne stocke pas les fichiers envoyés

Il n'y a pas d'étape d'envoi préalable. Les fichiers sont lus et envoyés par petits fragments directement depuis l'appareil de l'expéditeur vers celui du destinataire, et FileTransferX n'écrit jamais ces fragments dans une base de données ou un espace de stockage de notre côté — y compris pendant un transfert relayé, où le relais ne fait que transmettre des octets chiffrés qu'il ne peut pas déchiffrer. Une fois un fragment livré, il ne reste rien à conserver, sauvegarder, ni divulguer accidentellement plus tard, car il n'a jamais été enregistré ailleurs que sur les deux appareils concernés.

Ce que notre serveur peut et ne peut pas voir

Le rôle de notre serveur est étroit : mettre en relation deux navigateurs pour qu'ils puissent ouvrir une connexion directe. Ce rôle limité définit une frontière stricte sur ce à quoi il est exposé.

Peut voir

  • Qu’une session d’association existe, identifiée uniquement par un code de transfert à durée de vie courte.
  • Les messages de configuration de connexion que deux navigateurs échangent pour se relier, ainsi que les informations d’adresse réseau nécessaires pour trouver un chemin entre eux.
  • Les horodatages — quand une session a été créée, quand deux appareils se sont connectés, et quand elle s’est terminée.

Ne peut pas voir

  • Les noms de fichiers, types de fichiers, miniatures, ou tout contenu de fichier — les fichiers ne transitent jamais par notre serveur sous une forme lisible.
  • Le contenu de votre transfert, même quand un relais l’achemine — ce chemin transporte des données chiffrées qu’il ne peut pas déchiffrer.
  • Qui vous êtes — il n’y a ni comptes, ni identifiants, ni informations personnelles liées à une session.
  • Le moindre historique après la fin d’une session — rien concernant un transfert terminé ou abandonné n’est conservé.

Quelles informations sont temporairement échangées

Associer deux appareils nécessite qu'une petite quantité de données de configuration transite par notre serveur. Aucune n'est une donnée de fichier, et aucune ne survit à la session à laquelle elle appartient.

Quand une session expire

Un code de transfert est lié à une seule tentative d'association. Il cesse de fonctionner dès qu'un appareil récepteur s'y associe avec succès, s'il reste inutilisé pendant une courte période, ou une fois que le transfert pour lequel il a été créé se termine, est annulé, ou se déconnecte. Il n'existe aucun stockage de session à long terme derrière tout cela — une session expirée ou terminée ne laisse simplement rien derrière elle « à expirer » plus tard. Si vous devez renvoyer quelque chose, démarrer une nouvelle session génère un code inédit.

Pourquoi fermer le navigateur met fin au transfert

La connexion entre les deux appareils et toute donnée de fichier en cours de transfert n'existent que dans la mémoire propre des onglets émetteur et récepteur — il n'y a pas de tâche en arrière-plan sur un serveur qui fait avancer le transfert. Fermer, actualiser, ou quitter l'onglet met fin à cette connexion immédiatement, ce qui arrête le transfert sur-le- champ. Ce n'est pas tant une limitation qu'une conséquence directe de l'absence de stockage de fichiers : rien n'étant conservé côté serveur, il n'y a rien à partir de quoi reprendre un transfert une fois le navigateur qui déplaçait les données disparu.

Connexion directe ou relayée

FileTransferX tente toujours une connexion directe en premier. Certains réseaux — pare-feux d'entreprise stricts, certains opérateurs mobiles — bloquent ce chemin d'emblée, d'où l'existence d'une solution de secours pour que les transferts fonctionnent partout.

Appareil A
Connexion directe
Appareil B

Si une connexion directe ne peut pas être établie

Appareil A
Relais sécurisé
Appareil B
Connexion directe

Les données circulent en ligne droite entre les deux navigateurs. Aucun tiers ne se trouve sur le chemin des données, donc rien entre les appareils ne pourrait voir, enregistrer ou intercepter le transfert, même en théorie.

Relais sécurisé

Utilisé seulement quand un chemin direct ne peut pas être établi. Un relais transmet les mêmes données chiffrées entre les deux appareils sans les déchiffrer — il déplace des octets chiffrés, pas des fichiers lisibles.

Vous avez trouvé une faille de sécurité ?

Si vous pensez avoir découvert une vulnérabilité dans FileTransferX, merci de nous la signaler directement plutôt que de la divulguer publiquement ; nous reviendrons vers vous dès que possible.

Écrivez-nous