Principes de privacy by design pour les outils de transfert

Le privacy by design dans un outil de transfert de fichiers signifie que la configuration par défaut protège déjà les données personnelles sans que l'utilisateur n'ait à toucher un seul paramètre. L'article 25 du RGPD codifie deux variantes : la protection des données dès la conception (article 25(1)) exige que vous intégriez des mesures techniques appropriées dans le produit dès la phase de planification, et la protection des données par défaut (article 25(2)) exige que la configuration prête à l'emploi traite uniquement ce qui est nécessaire, ne partage qu'avec ceux qui en ont besoin, et ne conserve que le temps requis. Pour un outil de transfert, cela se traduit par un chiffrement côté client activé par défaut, une expiration inférieure à 30 jours, une collecte de métadonnées minimale et une révocation en un clic.

Les sept principes de Cavoukian appliqués aux transferts

Le cadre d'Ann Cavoukian des années 1990 — proactif et non réactif, vie privée par défaut, intégré à la conception, fonctionnalité totale, sécurité de bout en bout, visibilité et transparence, respect de la vie privée des utilisateurs — se transpose directement dans l'architecture de transfert de fichiers. Proactif : détection des algorithmes faibles dans le code avant déploiement via une analyse SAST automatisée. Par défaut : AES-256-GCM activé sans possibilité de désactivation. Intégré : le chiffrement intervient dans le pipeline d'envoi, pas comme étape séparée. Fonctionnalité totale : les fichiers chiffrés prennent toujours en charge les aperçus via déchiffrement côté client. De bout en bout : la plateforme ne traite jamais le texte en clair. Visibilité : publication de la spécification de chiffrement. Respect : donner aux utilisateurs le contrôle sur la conservation et l'expiration.

Article 25(1) : obligations lors de la phase de conception

L'article 25(1) exige des mesures « tant au moment de la détermination des moyens du traitement qu'au moment du traitement lui-même ». Cela signifie que les obligations de protection des données s'appliquent dès la conception de l'architecture, sans les ajouter a posteriori. Choisissez un protocole de transport (HTTPS avec TLS 1.3), une suite de chiffrement (AES-256-GCM ou XChaCha20-Poly1305), une fonction de dérivation de clé (PBKDF2-SHA-256 à 600 000 itérations ou Argon2id), et une région de stockage (UE) avant d'écrire la première ligne de code. Documentez ces choix dans un registre de décisions d'architecture pour que les futurs ingénieurs comprennent les contraintes.

Article 25(2) : obligations de configuration par défaut

L'article 25(2) précise quatre valeurs par défaut : limiter la quantité de données personnelles collectées, limiter le traitement, limiter la durée de conservation, et limiter l'accessibilité. Pour un outil de transfert, cela se concrétise ainsi : ne demandez que les adresses e-mail de l'expéditeur et du destinataire (pas le nom complet, le téléphone, l'adresse) ; traitez le fichier une seule fois et supprimez ; conservez 7 jours et non indéfiniment ; restreignez l'accès aux destinataires spécifiques, et non via une URL publique indexée par les moteurs de recherche. Comparez avec les liens de partage publics de WeTransfer Free — pratiques, mais non conformes à l'article 25(2) sans garanties supplémentaires.

Minimisation des données dans le flux d'envoi

Le formulaire d'envoi de l'expéditeur est là où la minimisation commence. Mauvaise conception : demander le nom de l'expéditeur, l'entreprise, le téléphone, le nom du destinataire, l'entreprise du destinataire, le message. Chaque champ est un point de données personnelles stocké et analysé. Bonne conception : e-mail uniquement, champ de message optionnel, aucun pixel de suivi. SwissTransfer et HexaTransfer mettent tous deux en œuvre des formulaires minimaux ; WeTransfer et Dropbox Transfer collectent davantage. Supprimez les métadonnées EXIF des images côté serveur si la suppression côté client n'est pas disponible. Ne journalisez pas les noms de fichiers s'ils contiennent des données personnelles — hachez-les pour la piste d'audit et conservez le mapping côté serveur uniquement.

Chiffrement activé par défaut, sans excuses de performance

AES-256-GCM dans les navigateurs modernes via l'API Web Crypto tourne à environ 200-500 Mo/s sur un ordinateur portable de 2020. Un fichier de 100 Mo se chiffre en bien moins d'une seconde. XChaCha20-Poly1305 de libsodium est tout aussi rapide. L'argument des performances pour justifier un chiffrement optionnel est caduque. Utilisez des clés par fichier dérivées d'un secret détenu par l'utilisateur — un mot de passe ou une clé aléatoire intégrée dans le fragment d'URL (après le #, afin que les serveurs ne la voient jamais). Référez-vous à l'architecture de Firefox Send de 2017-2019 pour un modèle éprouvé : le fragment d'URL portait la clé, le serveur ne voyait que des données chiffrées.

Pseudonymisation autant que possible

L'article 4(5) définit la pseudonymisation. Conformément au considérant 28, elle est encouragée tout au long du règlement. Pour les transferts de fichiers, la pseudonymisation signifie remplacer les identifiants directs dans les métadonnées système : expediteur@entreprise.com devient un hachage SHA-256 dans le journal d'audit, la table de correspondance étant stockée séparément sous des contrôles d'accès plus stricts. Idem pour les destinataires. Si un attaquant compromet le journal d'audit seul, il ne voit que des hachages, pas un graphe de contacts. La table de correspondance — plus petite et dans un coffre séparé — est protégée par des clés et des politiques d'accès différentes.

Transparence par la publication de l'architecture

L'article 25 n'impose pas l'open source, mais la transparence est un principe fondamental du privacy by design. Publiez : la spécification de chiffrement (algorithme, KDF, itérations, longueur du tag d'authentification), le schéma de flux de données, la liste des sous-traitants ultérieurs avec leurs juridictions, le calendrier de conservation, le délai de notification des violations, et le schéma du journal d'audit. Proton, Tresorit et HexaTransfer publient tous des livres blancs techniques. Les affirmations cryptographiques invérifiables — le vague « chiffrement de niveau militaire » — sont des signaux d'alerte. Si le prestataire ne nomme pas l'algorithme, supposez que la sécurité est faible.

Le contrôle utilisateur comme valeur par défaut, pas comme fonctionnalité premium

Le privacy by design déraille lorsque les contrôles sont réservés aux offres payantes. Les liens protégés par mot de passe ne devraient pas coûter plus cher. Les limites de téléchargement ne devraient pas être premium. La révocation des liens ne devrait pas nécessiter de contacter le support. La posture minimale de confidentialité — expiration, mot de passe, révocation, notifications de téléchargement — devrait être gratuite, les offres payantes ajoutant de l'échelle (stockage, gestion d'équipe) ou de la commodité (liens personnalisés, conservation prolongée). C'est à la fois une posture RGPD et une posture commerciale : les utilisateurs font confiance aux produits qui leur donnent le contrôle sans barrière tarifaire.

Une journalisation qui respecte le principe

Les journaux d'audit sont eux-mêmes des données personnelles. Une journalisation excessive crée une nouvelle surface de violation. Une journalisation insuffisante empêche de satisfaire à l'article 33 ou de démontrer la conformité au titre de l'article 5(2). L'équilibre : journalisez le type d'événement, l'horodatage, le hachage de l'identifiant du fichier, le hachage de l'identifiant de l'acteur, le résultat. Ne journalisez pas les adresses IP complètes — tronquez à /24 (IPv4) ou /64 (IPv6). Ne journalisez pas les user agents en intégralité — extrayez la famille de navigateur et la version majeure. Conservez pour la durée minimale nécessaire à la sécurité et à la conformité (généralement six mois), puis supprimez. Chiffrez le pipeline de journalisation de bout en bout ; l'accès aux journaux devient lui-même un événement.

Tester la posture avant le lancement

Réalisez un audit des flux de données avec un ingénieur récemment arrivé qui n'a pas participé au développement. Demandez : pour chaque système, quelles données personnelles transitent ? Où sont-elles stockées ? Combien de temps ? Qui peut y accéder ? Comment l'accès est-il journalisé ? Comment les données sont-elles supprimées ? Comparez les réponses aux engagements de l'article 25 documentés dans la DPIA. Testez la pénétration de l'architecture déclarée — le serveur ne voit-il vraiment que des données chiffrées ? La clé dans le fragment d'URL est-elle vraiment absente des journaux ? Les services avec des affirmations de privacy by design fragiles échouent rapidement à ces tests. Ceux avec des bases solides — l'expiration à 7 jours d'HexaTransfer avec AES-256-GCM côté client — résistent, car l'architecture fait ce que la documentation décrit.

Intégrez la confidentialité dès la conception ; ne la greffez pas après coup. Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.