Email chiffré vs transfert de fichiers chiffré : comparatif

L'email chiffré (PGP, S/MIME, ou des services comme ProtonMail) fonctionne bien pour les messages sensibles courts et les documents inférieurs à environ 25 Mo, le plafond de pièces jointes de Gmail que la plupart des serveurs de réception appliquent encore. Le transfert de fichiers chiffré (HexaTransfer, SwissTransfer, Tresorit Send) gère des charges utiles allant jusqu'à 10 Go ou plus, génère des liens de téléchargement à usage unique, et découple le fichier de la politique de conservation de votre boîte de réception. Choisissez l'email quand vous avez besoin d'une conversation en fil avec de petites pièces jointes. Choisissez le transfert de fichiers pour tout ce qui est volumineux, urgent, ou ne doit pas persister indéfiniment dans les archives de messagerie. Souvent, vous voudrez les deux.

Le mur de la taille dans l'email

SMTP a été conçu en 1982 pour des télégrammes ASCII 7 bits. Les pièces jointes se greffent via l'encodage base64 MIME, qui gonfle les données binaires d'environ 33 %. Cette vidéo de 20 Mo devient un email de 27 Mo. Gmail rejette les messages de plus de 25 Mo, Outlook.com plafonne à 20 Mo, et la plupart des serveurs Exchange d'entreprise fixent des limites entre 10 Mo et 35 Mo.

Heurter ce mur rend les options maladroites : découper le .zip en parties avec les volumes 7-Zip, uploader vers un service cloud et coller un lien (ce qui annule le chiffrement), ou changer d'outils. Les services de transfert de fichiers contournent tout cela — HexaTransfer déplace directement un .psd de 10 Go, WeTransfer gère 2 Go sur son niveau gratuit, et des outils d'entreprise dédiés comme Signiant peuvent pousser des téraoctets.

En quoi le chiffrement diffère réellement

PGP (RFC 4880) chiffre les corps de messages avec une clé de session AES-256 aléatoire, puis enveloppe cette clé avec la clé publique RSA-4096 ou Curve25519 du destinataire. S/MIME (RFC 8551) fait la même chose en utilisant des certificats X.509 émis par une AC. Les deux sont de bout en bout — votre fournisseur de messagerie ne stocke que du texte chiffré.

Le transfert de fichiers chiffré utilise typiquement un modèle différent. Le fichier est chiffré côté client avec AES-256-GCM, le serveur ne stocke que du texte chiffré, et la clé de déchiffrement réside dans un fragment d'URL (#key=...) qui n'atteint jamais le serveur. Pas de PKI, pas de toile de confiance, pas de serveurs de clés. La contrepartie : le chiffrement par email authentifie l'expéditeur cryptographiquement ; les liens de fichiers n'authentifient que celui qui détient l'URL.

Comparatif en un coup d'œil

| Fonctionnalité | Email chiffré (PGP/S-MIME) | Transfert de fichiers chiffré | |---|---|---| | Limite de taille typique | 25 Mo | 2 Go – 10 Go+ | | Authentification de l'expéditeur | Forte (signée) | Faible (par lien) | | Configuration de la clé du destinataire | Requise en amont | Aucune nécessaire | | Persistance | Indéfiniment dans la boîte de réception | 7 jours typiquement | | Métadonnées exposées | Ligne d'objet, en-têtes | Nom de fichier optionnel | | Fonctionne avec des destinataires non techniques | Rarement | Toujours | | Adéquation réglementaire | Email HIPAA (avec BAA) | RGPD Art. 32, HIPAA |

Persistance : archives de messagerie vs liens expirants

Un email chiffré réside dans ~/Mail/INBOX.mbox ou sur les serveurs de Gmail pendant des années. Si l'appareil du destinataire est ultérieurement compromis ou si sa clé privée PGP est exfiltrée, chaque message historique se déchiffre. La longue conservation est idéale pour les pistes d'audit et terrible pour le rayon d'explosion d'une violation.

Les liens de transfert de fichiers expirent généralement. HexaTransfer supprime les transferts après 7 jours. SwissTransfer plafonne à 30 jours. SendGB offre de 24 heures à 30 jours. Une fois le délai écoulé, le texte chiffré est purgé et la clé de déchiffrement devient inutile — même si l'URL fuit des années plus tard, il n'y a rien à déverrouiller. Cela correspond parfaitement aux principes de minimisation des données de l'Article 5(1)(e) du RGPD et explique pourquoi les workflows juridiques et de santé préfèrent de plus en plus les services de transfert pour les divulgations ponctuelles.

La friction côté destinataire

Le problème d'utilisabilité de PGP est légendaire. Une étude Carnegie Mellon de 2015 a révélé que 10 participants sur 10 ont échoué à envoyer un email chiffré correctement au premier essai. Deux décennies après que Phil Zimmermann a publié PGP, le destinataire doit encore générer une paire de clés, la publier quelque part, vérifier les empreintes, et configurer Thunderbird ou GPG Suite. S/MIME est légèrement meilleur dans les environnements d'entreprise qui distribuent automatiquement les certificats via Active Directory.

Les transferts de fichiers réduisent cela à : cliquez sur un lien, tapez éventuellement un mot de passe. Le destinataire n'a besoin d'aucune configuration préalable. C'est pourquoi les outils de transfert de fichiers chiffrés l'emportent dans les scénarios face aux clients — un comptable envoyant des relevés fiscaux à un client, un radiologue transmettant des études DICOM à un médecin référent, un avocat livrant des bundles de documents de procédure en .pdf.

Là où ils se chevauchent : les petits documents sensibles

Un contrat signé, un passeport scanné, un résultat d'analyse médicale de 2 Mo — ceux-ci se trouvent dans la zone ambiguë. Les deux méthodes fonctionnent. L'email l'emporte si vous avez besoin d'un enregistrement durable lié à un fil de conversation (« comme nous en avons discuté mardi... »). Le transfert de fichiers l'emporte si vous avez besoin que le document disparaisse après la livraison, si le destinataire est hors de votre cercle PGP, ou si vous voulez un accusé de réception confirmant que le fichier a bien été récupéré.

Certaines équipes utilisent un workflow mixte : ProtonMail ou Tutanota pour les échanges en fil sous 25 Mo, et un service de transfert dédié pour tout ce qui est plus volumineux ou doit expirer. Les deux laissent le fournisseur avec uniquement du texte chiffré, ce qui satisfait proprement HIPAA 45 CFR 164.312(e)(1) et PCI DSS 4.0 Exigence 4.2.1 pour les données en transit.

Conformité et lignes de conservation

Les réglementations imposent rarement un outil spécifique — elles imposent des résultats. L'Article 32 du RGPD exige des « mesures techniques appropriées » pour les données personnelles. La Règle de Sécurité HIPAA impose le chiffrement des ePHI au repos et en mouvement. PCI DSS 4.0 bloque les PAN non chiffrés dans les canaux de messagerie. Toute solution E2EE, email ou transfert de fichiers, peut satisfaire ces exigences si configurée correctement et soutenue par un accord de partenariat commercial signé (pour HIPAA) ou un avenant de traitement des données (pour le RGPD).

La différence pratique est la posture de conservation. Les systèmes de messagerie stockent par défaut indéfiniment ; les systèmes de transfert de fichiers suppriment par défaut. Pour les demandes de droit à l'effacement au titre de l'Article 17 du RGPD, le modèle de transfert de fichiers est strictement plus simple — les données ont déjà disparu au moment où une demande arrive.

Choisir le bon outil selon la situation

Utilisez l'email chiffré pour les conversations continues avec des contacts connus, les petites pièces jointes, et les communications juridiquement significatives où une piste d'audit signée compte. Utilisez le transfert de fichiers chiffré pour les envois volumineux ponctuels, les documents sensibles à des destinataires non techniques, les fichiers qui doivent s'autodétruire, et tout ce qui rebondirait sur une limite de 25 Mo. Les deux sont complémentaires, pas concurrents.

Pour la partie transfert de fichiers de ce workflow : essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.