Conversion de fichiers dans le navigateur et RGPD : pourquoi le côté client réduit votre responsabilité
Quand les fichiers sont convertis sur l'appareil de l'utilisateur et non sur vos serveurs, une grande partie de votre obligation de protection des données ne naît jamais.
Toute entreprise qui traite des fichiers clients — photos, scans, documents, tableurs — hérite de la même question : qu'arrive-t-il aux données dès qu'elles quittent l'appareil du client ? Avec un convertisseur classique avec envoi, la réponse est inconfortable. Le fichier voyage vers un serveur que vous contrôlez (ou louez), repose en stockage et est traité par une infrastructure dont vous êtes responsable au sens du RGPD.
La conversion côté client inverse ce modèle. Le fichier est lu, traité et réécrit entièrement dans le navigateur, de sorte qu'il n'entre jamais dans vos systèmes. Ce guide explique pourquoi cela compte pour le RGPD, quelles obligations se réduisent et où la technique aide vraiment — et où elle n'aide pas.
Le modèle par défaut : conversion côté serveur
La plupart des services de conversion fonctionnent ainsi :
- L'utilisateur sélectionne un fichier dans le navigateur.
- Le fichier est envoyé vers votre serveur ou une API tierce.
- Le serveur décode, convertit et stocke le résultat.
- L'utilisateur télécharge la sortie ; le serveur supprime les fichiers après une fenêtre de rétention.
Du point de vue du RGPD, c'est la voie coûteuse. Vous (ou votre sous-traitant) devenez destinataire de données personnelles, ce qui déclenche une chaîne d'obligations : base juridique, accord de traitement, mesures techniques et organisationnelles, délais de suppression, devoirs de notification et, pour les transferts internationaux, une analyse d'adéquation ou de garanties.
Rien de tout cela n'est impossible, mais c'est un travail réel et continu qui évolue avec chaque fichier accepté.
Ce que signifie vraiment la conversion côté client
Les navigateurs modernes apportent tout pour convertir des fichiers localement : l'API Canvas pour décoder et recoder des images, des Web Workers pour garder l'interface fluide et des bibliothèques WebAssembly pour les formats lourds comme HEIC, PDF ou OCR. Quand la conversion tourne ainsi :
- Le fichier n'est lu que par le navigateur, en mémoire.
- Il est décodé et recodé sur l'appareil de l'utilisateur.
- Rien n'est transmis sur le réseau.
- Le résultat est enregistré sur l'appareil de l'utilisateur.
Il n'y a pas de copie serveur à sécuriser, retenir ou supprimer, car aucune copie n'a été créée. C'est le modèle de FormatFlash, et la raison pour laquelle il peut affirmer honnêtement que les fichiers ne quittent jamais l'appareil de l'utilisateur.
Pourquoi cela compte sous le RGPD
Le RGPD repose sur la minimisation des données et leur maîtrise. Le traitement côté client s'y aligne par conception :
- Minimisation (art. 5.1.c) : vous ne recevez aucune copie, donc vous détenez le moins possible : rien.
- Protection des données dès la conception (art. 25) : l'architecture empêche la collecte plutôt que de la corriger après coup.
- Pas de transfert international : les données qui ne quittent pas l'appareil ne posent aucune question d'adéquation.
- Pas d'obligation de stockage : il n'y a rien à conserver, chiffrer ou supprimer.
Pour un DPO ou une équipe achats, l'effet pratique est qu'une section entière du registre des traitements peut être marquée « non applicable ».
Quelles obligations se réduisent
| Obligation | Conversion serveur | Conversion client |
|---|---|---|
| Accord de traitement (DPA) | nécessaire avec chaque sous-traitant | pas nécessaire pour la conversion |
| Base juridique du contenu | nécessaire | pas nécessaire : vous ne le recevez jamais |
| Calendrier de suppression | nécessaire | non applicable |
| Exposition à la notification de violation | fichiers à risque | aucune donnée de fichier à risque |
| Garanties de transfert international | souvent nécessaires | non applicables |
| MTO pour le stockage | nécessaires | non applicables |
Ce qui ne disparaît jamais, c'est votre responsabilité pour le code que vous publiez : si votre site charge de l'analyse, de la publicité ou de la journalisation d'erreurs, cela traite encore des données personnelles et nécessite une base juridique. La conversion côté client retire le contenu du fichier de l'équation ; elle ne retire pas le suivi.
Où la conversion côté client aide le plus
HEIC et envois de photos mobiles
Les photos iPhone arrivent en HEIC. Les convertir sur l'appareil de l'utilisateur signifie que vous n'ingérez jamais un format que votre backend ne supporte peut-être pas. Voir ce qu'est le HEIC et convertir HEIC en JPG sur iPhone.
Métadonnées EXIF et GPS
La recodification locale supprime par défaut les métadonnées EXIF et GPS. Pour les photos clients, c'est un vrai gain de minimisation — voir le guide de suppression EXIF et GPS.
OCR et documents scannés
Les scans de pièces d'identité, contrats ou formulaires sont parmi les fichiers les plus sensibles. Exécuter l'OCR localement les garde hors de vos serveurs — voir OCR sans envoi.
Ce que la conversion côté client ne résout pas
- Analyse et cookies : si vous utilisez Google Analytics, les règles de consentement s'appliquent toujours.
- Journaux du serveur : l'hébergement enregistre toujours des données techniques (IP, user agent).
- Entrée malveillante : le code client doit gérer des fichiers non fiables en sécurité.
- Vos propres points de collecte : si vous recevez le même fichier à part pour un autre but, ce traitement a besoin de sa propre base.
Comment évaluer un convertisseur pour la conformité
- Confirmez que l'outil traite les fichiers localement : surveillez l'onglet réseau pour les envois.
- Vérifiez que la politique de confidentialité dit que les fichiers ne quittent pas l'appareil.
- Assurez-vous qu'aucune API tierce ne reçoit le fichier pendant la conversion.
- Cherchez la gestion des métadonnées : une suppression EXIF/GPS par défaut est un plus.
- Demandez si un accord de traitement est même nécessaire : sans transfert, il ne l'est en général pas.
Questions fréquentes
La conversion côté client compte-t-elle comme traitement au sens du RGPD ?
Le traitement par l'utilisateur final sur son propre appareil à ses propres fins n'est pas un traitement par votre organisation, car vous ne recevez jamais les données. Reste votre responsabilité pour le code que vous publiez et pour les journaux techniques.
Ai-je encore besoin d'un accord de traitement ?
Si aucune donnée personnelle n'atteint un sous-traitant, il n'y a rien à régler. Un accord reste pertinent si vous transmettez des données à un hébergeur ou à un prestataire d'analyse.
La conversion dans le navigateur est-elle fiable pour le HEIC ?
Oui. Les navigateurs modernes décodent le HEIC localement via un décodeur WebAssembly.
Que deviennent les métadonnées EXIF et GPS ?
La recodification locale supprime par défaut EXIF et GPS, ce qui est déjà un avantage de minimisation.
Guides associés
- Pourquoi la conversion HEIC côté client importe
- Supprimer EXIF et GPS : le guide de conformité
- OCR sans envoi
- Intégration embed pour développeurs
Pour un convertisseur côté client concret et intégrable, voir FormatFlash Embed ou utilisez directement le convertisseur d'images gratuit.