Chiffrement mobile pour le transfert : partage sécurisé en déplacement

Le chiffrement mobile de fichiers s'exécute dans Safari sur iOS et Chrome/Firefox sur Android en utilisant la Web Crypto API — le même appel crypto.subtle.encrypt que sur desktop. Les fichiers sélectionnés depuis la bibliothèque Photos ou l'application Fichiers sont chiffrés avec AES-256-GCM avant qu'un seul octet ne quitte le téléphone. Le travail lourd est la dérivation de clé PBKDF2, qui sur un iPhone 14 Pro termine 600 000 itérations en environ 350 ms. Pour un .mov de 500 Mo d'une vidéo récente, le vrai goulot d'étranglement est la bande passante d'envoi, pas le chiffrement. Les services de transfert conçus pour le mobile n'ont pas besoin d'applications natives — le navigateur a tout ce qu'il faut.

Pourquoi le navigateur bat les applications natives sur mobile

Les applications iOS et Android natives pour le transfert de fichiers (Dropbox, l'ancienne application WeTransfer) demandent des permissions étendues, restent en mémoire après usage, et affichent des publicités. Un flux basé sur le navigateur ne demande aucune installation, s'exécute une fois, et se ferme quand l'onglet se ferme. Plus important, le rejet par l'App Store d'Apple des applications véritablement zéro connaissance (l'odyssée de Cryptee en 2021 est documentée) fait que la livraison par navigateur est le seul moyen de garantir que la logique de chiffrement n'est pas silencieusement remplacée lors d'une mise à jour de l'App Store. Le même bundle JavaScript s'exécute partout, vérifiable contre des hashes SHA-384.

La Web Crypto API sur iOS et Android

Safari 17 sur iOS 17+ supporte complètement crypto.subtle : deriveKey, encrypt, decrypt, sign, verify. Chrome sur Android le supporte depuis la version 37 (2014). Les deux implémentations délèguent aux primitives natives de l'OS — CommonCrypto sur iOS, BoringSSL sur Android — donc la crypto est accélérée matériellement via les instructions AES d'ARM. Un fragment de 5 Mo se chiffre en environ 15 ms sur un Pixel 8. L'API n'expose pas le matériel de clé brut à JavaScript (les objets CryptoKey sont des handles opaques), ce qui protège contre les extensions malveillantes, même si les navigateurs mobiles en ont bien moins.

Gérer les gros fichiers sans saturer la mémoire

Safari mobile limite le tas JavaScript à environ 2 Go sur les iPhones avec 6 Go de RAM, moins sur les appareils anciens. Un schéma naïf « lire le fichier dans un ArrayBuffer, chiffrer, envoyer » plante sur tout ce qui dépasse 1 Go. Le flux est obligatoire. Utilisez File.slice() pour lire des fragments de 5 Mo, chiffrez chacun avec une sous-clé dérivée via HKDF, et envoyez via fetch() avec un corps ReadableStream. L'envoi progressif maintient le pic mémoire sous 50 Mo même pour des vidéos de 10 Go. Chrome sur Android supporte les requêtes fetch en flux depuis la version 105 ; Safari a ajouté le support complet en 17.4.

Considérations de batterie et de chaleur

AES-256-GCM est peu coûteux sur le matériel — les extensions Cryptographie d'ARMv8 le font tourner à presque la vitesse de la DRAM. 1 Go de chiffrement sur un iPhone 14 Pro consomme environ 2 % de batterie, principalement la radio pour l'envoi, pas le CPU. Là où les utilisateurs ressentent de la chaleur, c'est avec PBKDF2 à haute itération ; 1,2 million d'itérations (recommandation OWASP 2024) prend 700 ms et fait brièvement monter l'A17 à 90°C. Régler à 600 000 itérations équilibre sécurité et thermique. Argon2id avec m=32 Mo est plus doux sur les charges soutenues parce que la résistance mémoire est plus lente mais moins dense en énergie.

Réseau cellulaire, Wi-Fi et fiabilité des envois

Les envois mobiles échouent. Un tunnel de métro, un ascenseur, un basculement de Wi-Fi vers LTE — n'importe lequel de ces événements tue un fetch() naïf. Le transfert mobile robuste utilise des envois reprenables avec accusé de réception au niveau fragment, des protocoles comme tus.io (spec tus 1.0, largement supportée) ou les envois multipart S3. Chaque fragment de 5 Mo s'envoie indépendamment ; un échec renvoie uniquement ce fragment. Le client stocke l'état des fragments dans IndexedDB pour qu'un rechargement d'onglet ou une éviction d'onglet iOS ne redémarre pas tout le job. SwissTransfer et HexaTransfer implémentent tous deux les envois reprenables ; le flux web mobile de WeTransfer ne le fait pas, ce qui explique pourquoi les envois de 2 Go en LTE échouent souvent là-bas.

Saisie au clavier et le problème d'UX du mot de passe

Taper un mot de passe robuste de 16 caractères sur un clavier téléphonique est pénible. Proposez des alternatives : scanner un QR code contenant le mot de passe depuis l'écran de l'expéditeur, coller depuis le gestionnaire de mots de passe natif (iOS remplit depuis le Keychain via les équivalents web de .well-known/apple-app-site-association), ou utiliser une passkey enregistrée lors d'un transfert précédent. Pour les cas ponctuels, utilisez la Web Share Target API pour laisser une application compagne (Signal, par exemple) injecter le mot de passe sans que l'utilisateur ait à le retaper.

Accessibilité et petits écrans

Un iPhone SE de 4,7 pouces ne convient pas à un éditeur de téléchargement de type drag-and-drop pour desktop. Les interfaces de chiffrement mobile doivent respecter le viewport : sélecteur de fichier plein écran, barres de progression visibles au-dessus du clavier virtuel, labels VoiceOver sur chaque bouton (role="progressbar" avec aria-valuenow pour l'accessibilité), et une cible tactile minimale de 44×44 points selon HIG Apple. Ne cachez pas les contrôles derrière des états hover — il n'y a pas de hover sur tactile. Testez avec le mode Économie d'énergie iOS, qui bride les timers en arrière-plan et casse les mises à jour de progression basées sur le polling.

Pièges de Safari iOS qui bloquent les envois

Safari sur iOS comporte des pièges. Les événements de progression d'envoi de l'API Fetch ne se déclenchent pas de façon fiable avant iOS 16.4. La File System Access API n'est pas supportée, donc vous ne pouvez pas streamer de gros fichiers depuis le stockage local comme Chrome le fait. Safari évince agressivement les onglets inactifs sous pression mémoire, ce qui tue les envois en cours. Mitigations : utilisez XMLHttpRequest avec des événements de progression comme repli (fonctionne toujours très bien), gardez l'onglet au premier plan pendant l'envoi, et avertissez l'utilisateur de ne pas verrouiller l'écran pour les gros fichiers. L'écran allumé consomme de la batterie mais évite l'éviction d'onglet.

La fragmentation d'appareils Android

Android couvre des appareils allant du Pixel 8 Pro aux téléphones à 80 € tournant sur Android Go. La Web Crypto fonctionne sur tous, mais les performances varient énormément — un MT6762 à 2 GHz prend 1,8 seconde pour 600 000 itérations PBKDF2 là où un téléphone de classe Apple M3 prend 200 ms. Détectez l'appareil via Device Memory API et Hardware Concurrency, adaptez le nombre d'itérations en conséquence (jusqu'à 300 000 pour les appareils Go), et avertissez les utilisateurs sur des connexions uniquement cellulaires que les envois supérieurs à 1 Go peuvent être peu fiables. Le bénéfice : le transfert chiffré fonctionne sur la majorité des téléphones dans le monde sans nécessiter un appareil haut de gamme.

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