Cloudflare et RGPD : flux et réglages à vérifier

Cloudflare peut fournir le DNS d’un domaine, relayer ses requêtes web, filtrer des attaques ou exécuter du code. Ces fonctions ne donnent pas accès aux mêmes données. Pour évaluer votre usage, commencez par le chemin réel d’une requête et les produits activés, puis examinez le contrat et les réglages associés.

Distinguer DNS et proxy web

Selon la documentation du statut DNS, un enregistrement en mode « DNS only » renvoie vers le serveur d’origine ; il ne fait pas, à lui seul, transiter les requêtes HTTP ou HTTPS par le proxy Cloudflare. Un enregistrement proxifié fait intervenir ce proxy dans le trafic web.

Le recours au DNS reste un traitement à examiner. Mais décrire systématiquement Cloudflare comme destinataire de tous les formulaires du site serait inexact. À l’inverse, un proxy qui termine la connexion TLS peut traiter des informations que la seule résolution DNS ne reçoit pas.

Dressez la liste des noms d’hôtes : site public, espace client, API, dépôt de documents et console d’administration. Pour chacun, relevez le mode DNS, les fonctions WAF, le cache, les Workers, les journaux et les autres produits activés. Ajoutez les chemins sensibles, même s’ils partagent le domaine du site public.

Qualifier les rôles et relire le DPA

Le DPA Cloudflare, version consultée datée du 3 avril 2026, prévoit la sous-traitance des données personnelles du client pour les services couverts. Il traite notamment des incidents, des sous-traitants ultérieurs, des audits et des transferts. Le §4.4 prévoit une information préalable sur les changements de sous-traitants et un délai d’objection de dix jours à compter de la notification.

Vérifiez son incorporation au contrat de votre compte, l’entité cocontractante et les produits couverts. Inscrivez le suivi des notifications dans une boîte effectivement surveillée. Une objection ne se résout pas simplement en désactivant un email : elle peut conduire à examiner les solutions contractuelles pour le service concerné.

Pour les traitements propres au fournisseur, la qualification exige une analyse distincte. La CNIL, le 28 mai 2026, distingue fourniture du service, amélioration et sécurité selon les décisions réellement prises. Un même prestataire ne reçoit donc pas un rôle unique pour toutes ses opérations. Utilisez la grille de l’article 28 pour le périmètre sous-traité.

Localiser trois ensembles différents

La Data Localization Suite est présentée comme une option payante de l’offre Enterprise. Elle comporte plusieurs mécanismes : Regional Services pour le déchiffrement et le traitement HTTPS, Customer Metadata Boundary pour certaines métadonnées et journaux, Geo Key Manager pour la localisation des clés privées.

Cette distinction évite une erreur fréquente : choisir une région pour un élément ne localise pas automatiquement tous les autres. De même, Keyless SSL permet de conserver la clé privée sur un serveur de clés du client ; cela ne signifie pas que Cloudflare ne traite jamais le trafic déchiffré.

Avant de signer un engagement interne « données traitées exclusivement en Europe », demandez la couverture exacte : contenu des requêtes, données stockées, métadonnées, clés, assistance et opérations de chaque produit. Le RGPD n’impose pas, de manière générale, l’achat d’une option de résidence européenne. Le niveau de garanties dépend des traitements et des contraintes effectivement applicables.

Vérifier la compatibilité, pas seulement le nom de l’option

La matrice de compatibilité distingue les produits et les composants de localisation. Elle indique notamment que Workers AI n’est pas couvert par Regional Services. La page des limites précise aussi que les sous-requêtes émises par Workers ne bénéficient pas de cette régionalisation.

Ces restrictions ne permettent pas de conclure que tout usage serait illicite ; elles empêchent de promettre une couverture technique inexistante. Faites examiner chaque combinaison par l’équipe qui administre le compte. Les exports Logpush demandent également de choisir et de sécuriser leur destination.

Exemple hypothétique : une API est régionalisée, mais un Worker envoie ensuite certaines données à un service tiers. Le contrôle doit suivre ce second flux. Une capture d’écran de la région de l’API ne constitue pas une preuve suffisante de sa destination finale.

Notre méthode de cartographie de la chaîne de sous-traitance permet d’associer un destinataire et une garantie à chaque étape.

Contrôler cache et journaux sur les pages privées

La documentation du cache par défaut indique que certains en-têtes de l’origine empêchent normalement la mise en cache, tout en signalant les effets possibles de règles qui les remplacent. Une configuration personnalisée mérite donc une vérification indépendante du comportement par défaut.

Pour un espace client, examinez les réponses personnalisées, les documents téléchargeables et les règles de cache. Utilisez deux comptes fictifs distincts pour vérifier qu’un contenu propre au premier n’est pas restitué au second. Ce contrôle relève de l’exploitation du site ; il ne demande pas d’utiliser de véritables dossiers clients.

Évitez aussi les noms, adresses email, identifiants secrets et informations de santé dans les URL. Ces éléments peuvent se retrouver dans plusieurs journaux et outils d’analyse. Définissez les champs réellement nécessaires à l’investigation, les accès aux logs et une durée justifiée. Les Art. 5(1)(c), 5(1)(e) et 32(1) du RGPD fondent ces exigences de minimisation, de conservation et de sécurité.

Documenter les transferts et la décision

Le DPA prévoit des mécanismes pour les transferts concernés, dont les clauses contractuelles types et le recours au cadre d’adéquation lorsqu’il est applicable. Une mention contractuelle ne remplace pas la vérification de l’entité, de la certification active et des données couvertes. Si vous utilisez les clauses types, examinez les conditions du transfert et les mesures complémentaires nécessaires ; notre modèle d’analyse d’impact du transfert structure cette démarche.

Une réponse prestataire imprécise doit rester un point à résoudre dans le dossier, selon la méthode d’audit des preuves manquantes.

Ce qu’il faut retenir

• Le DNS seul et le proxy web n’ont pas le même périmètre.
• Distinguez les données de trafic, les métadonnées et les clés.
• Vérifiez les limites de localisation produit par produit.
• Les règles de cache, les journaux et les flux sortants comptent autant que le contrat.

FAQ

Faut-il Data Localization Suite pour respecter le RGPD ?

Il n’existe pas d’obligation générale d’acheter cette option. Votre décision doit reposer sur les données, les risques, les transferts et les éventuelles contraintes sectorielles.

Le chiffrement HTTPS empêche-t-il tout accès du proxy ?

Non lorsque le proxy termine la connexion TLS pour fournir ses services. Il faut examiner le traitement effectif et les garanties du fournisseur.

Une région européenne couvre-t-elle aussi tous les Workers ?

Pas par simple déduction. Consultez la matrice de compatibilité et les limites, notamment pour les sous-requêtes et les produits associés.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.