Aller au contenu
HexaTransfer
Retour au blog
Transfert de fichiers

Transférer des fichiers projet en toute sécurité : chiffré

Transférez des fichiers de projet en toute sécurité à votre équipe. Le chiffrement de bout en bout protège vos données pendant le transit.

Un transfert de fichiers projet sécurisé signifie que les fichiers sont illisibles par quiconque en dehors de l'expéditeur et du destinataire — y compris le service de transfert lui-même. Le mécanisme qui garantit cela est le chiffrement de bout en bout avec AES-256-GCM, la clé étant dérivée d'un mot de passe que les deux parties conviennent séparément du lien. L'upload chiffre dans le navigateur ; le téléchargement déchiffre dans le navigateur. Le serveur ne stocke que du texte chiffré. Slack, les pièces jointes e-mail et le stockage cloud ordinaire n'atteignent pas ce niveau. Pour des fichiers projet contenant des spécifications produit, du code non publié ou des données client sous NDA, un lien de transfert zéro connaissance est le canal minimum acceptable.

Ce qui rend un transfert « sécurisé » de façon concrète

« Sécurisé » est un mot dont les entreprises abusent. Voici la checklist avec les précisions :

  • Chiffrement en transit : TLS 1.3 (RFC 8446) avec des suites de chiffrement modernes (TLS_AES_256_GCM_SHA384). Standard sur chaque navigateur et serveur majeur depuis 2018.
  • Chiffrement au repos : AES-256 sur la couche de stockage, clés tournées. Chaque fournisseur sérieux le fait.
  • Chiffrement de bout en bout (E2EE) : la clé en clair n'existe jamais sur le serveur. C'est la partie difficile — la plupart des services « sécurisés » la sautent.
  • Chiffrement authentifié : AES-256-GCM (NIST SP 800-38D) produit un texte chiffré et un tag de 128 bits. Toute altération est détectable au déchiffrement.
  • Dérivation de clé robuste : PBKDF2-HMAC-SHA256 avec 600 000+ itérations (recommandations OWASP 2023) ou Argon2id.
  • Absence de fuite de métadonnées : les noms de fichiers et les tailles ne sont pas exposés au serveur au-delà du strict nécessaire.
  • Expiration et révocation : les liens s'auto-suppriment ; l'expéditeur peut révoquer avant l'expiration.

La plupart des outils d'entreprise cochent les deux premiers critères. Très peu cochent les sept.

Pourquoi Slack, l'e-mail et OneDrive ne suffisent pas

L'offre gratuite de Slack compresse les pièces jointes, plafonne à 1 Go par fichier sur les offres payantes, et stocke tout sur AWS avec Slack détenteur des clés de déchiffrement. Un administrateur Slack — ou toute personne ayant accès à l'export de votre espace de travail — peut lire chaque fichier jamais uploadé. Acceptable pour un document marketing public ; inacceptable pour une data room de M&A.

L'e-mail (SMTP + TLS) est chiffré saut par saut, ce qui signifie que chaque serveur de messagerie en chemin déchiffre et rechiffre. S/MIME et PGP sont de bout en bout, mais exigent une gestion de certificats et de clés que 99 % des équipes ne mettent jamais en place.

OneDrive, Google Drive et Dropbox chiffrent au repos. Le fournisseur détient les clés. Une ordonnance judiciaire valide, un administrateur malhonnête ou un service de gestion de clés compromis expose chaque fichier.

Chiffrement de bout en bout, étape par étape

Voici ce qui se passe lorsque vous uploadez une archive projet vers un service de transfert E2EE bien conçu :

  1. Vous saisissez un mot de passe dans le navigateur. Le service dérive une clé de 256 bits avec PBKDF2-HMAC-SHA256, en utilisant un sel aléatoire de 128 bits et 600 000 itérations. Le mot de passe ne quitte jamais le navigateur.
  2. Le fichier est découpé en morceaux de 5 Mo. Chaque morceau reçoit un IV (nonce) frais de 96 bits.
  3. Chaque morceau est chiffré en AES-256-GCM. Résultat : texte chiffré + tag d'authentification de 128 bits par morceau.
  4. Les morceaux chiffrés s'uploadent vers le serveur en TLS 1.3. Le serveur voit des octets chiffrés, l'IV et le tag. Jamais la clé, jamais le mot de passe.
  5. Le service retourne une URL. Vous partagez l'URL sur un canal (e-mail, Slack) et le mot de passe sur un autre (SMS, appel téléphonique, coffre partagé d'un gestionnaire de mots de passe).
  6. Le destinataire ouvre l'URL, saisit le mot de passe, le navigateur re-dérive la même clé (le sel est transmis avec le texte chiffré), déchiffre chaque morceau et reconstitue le fichier.

Si le serveur est compromis demain, l'attaquant obtient du texte chiffré et des sels — inutilisables sans le mot de passe. C'est du zéro connaissance par construction.

Protéger le canal du mot de passe

Le chiffrement le plus robuste échoue si le mot de passe voyage dans le même e-mail que le lien. Canaux séparés :

  • Lien par e-mail, mot de passe par SMS
  • Lien en DM Slack, mot de passe via Signal
  • Lien dans l'outil de gestion de projet, mot de passe dans un coffre partagé 1Password
  • Pour les enjeux élevés : lien en ligne, mot de passe par appel téléphonique

Pour les équipes, utilisez un gestionnaire de mots de passe (1Password, Bitwarden, Keeper) avec des coffres partagés limités au projet. Le mot de passe y réside ; les membres y accèdent en rejoignant le coffre ; personne ne le colle dans un e-mail.

Types de fichiers projet et ce qu'ils contiennent

| Fichier | Contenu typique | Pourquoi le chiffrement est important | | --- | --- | --- | | Sauvegarde .fig Figma | Interface non publiée, marques | Risque de fuite concurrentielle | | Modèle .rvt Revit | Plans de bâtiment, adresse client | Implications de sécurité physique | | Master .psd Photoshop | Créatif de campagne avant lancement | Risque réputationnel pour la marque | | Brouillon de contrat .docx | Tarification, conditions, parties | Responsabilité pour violation de NDA | | Code source .zip | Algorithmes propriétaires | Vol de propriété intellectuelle | | Imagerie médicale .dicom | Données de santé patient | Violation HIPAA / RGPD | | Export client .csv | Données personnelles (PII) | RGPD art. 32 déclenché |

Un service de transfert qui peut lire le fichier fait partie intégrante du risque. Le E2EE retire le service du modèle de menace.

Rétention et cycle de vie du projet

Alignez l'expiration du transfert sur les jalons du projet. Pour un livrable de sprint de deux semaines, une expiration à 14 jours est parfaite — le fichier disparaît à la fin du sprint. Pour un rapport client trimestriel, 30 jours. Pour une data room de M&A au long cours, utilisez un VDR (Virtual Data Room) dédié comme Intralinks ou Firmex, pas un lien de transfert généraliste.

Après expiration, vérifiez si quoi que ce soit a été renvoyé. Si le même fichier projet circule à travers cinq transferts distincts, il vaut mieux le placer dans un espace de travail chiffré partagé (Tresorit, Proton Drive, ou un Nextcloud auto-hébergé avec chiffrement côté serveur).

Pistes d'audit pour les équipes réglementées

Les équipes soumises à ISO 27001, SOC 2 Type II ou RGPD doivent journaliser qui a envoyé quoi, quand, et quand le téléchargement a eu lieu. Un bon service de transfert expose :

  • Identité de l'expéditeur (ou horodatage d'upload + adresse IP si anonyme)
  • Horodatage(s) de téléchargement du destinataire
  • Horodatage d'expiration et de suppression
  • Webhook au téléchargement, envoyé par e-mail ou posté sur Slack

HexaTransfer journalise ces événements sans stocker le contenu en clair du fichier. La piste d'audit confirme la livraison sans compromettre la propriété zéro connaissance.

Comparaison de transfert sécurisé adapté aux équipes

| Service | Chiffrement E2E | Mot de passe sur le lien | Expiration | Webhook téléchargement | Taille max (gratuit) | | --- | --- | --- | --- | --- | --- | | Upload de fichier Slack | Non | Non | Rétention du workspace | Non | 1 Go | | Lien Google Drive | Non | Optionnel | Manuelle | Non | Quota 15 Go | | Tresorit Send | Oui (assisté serveur) | Oui | Jusqu'à 7 jours | Oui | 5 Go gratuit | | WeTransfer Pro | Non | Oui | Jusqu'à 365 jours | Oui | 20 Go | | HexaTransfer | Oui (AES-256-GCM dans le navigateur) | Oui | Configurable | Oui | 10 Go |

Un dernier point : ne rechiffrez pas ce qui est déjà chiffré

Si le fichier source est un .asc chiffré GPG ou un .7z avec AES-256 déjà intégré, ajouter une couche de chiffrement côté navigateur est redondant et n'apporte aucune sécurité supplémentaire. Choisissez une couche, exécutez-la correctement, communiquez la clé hors bande, passez à la suite.

Le transfert sécurisé relève du modèle de menace, pas du discours marketing. Le E2EE place le contrôle là où il doit être — chez les deux personnes qui doivent pouvoir lire le fichier.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.

Envoyez vos fichiers volumineux en toute sécurité avec le chiffrement de bout en bout

Transférez des fichiers jusqu'à 10 Go gratuitement avec le chiffrement de bout en bout. Aucun compte requis. Vos fichiers sont chiffrés dans votre navigateur avant l'envoi — personne d'autre ne peut les lire.

Envoyer un fichier