Vendredi, 18 h 40. Le site est livré, le DNS pointe, la page d'accueil s'affiche. Le client relit le devis, puis envoie un dernier message : « Et le RGPD, c'est bon ? ». La question tombe sur le développeur. Une bonne partie de la réponse est pourtant technique et se règle avant la mise en ligne : quels scripts se chargent, quand, quels champs les formulaires collectent, où vont les journaux, qui a un compte d'administration. Cet article rassemble ces points sous forme de liste à cocher, phase par phase, avec le texte qui fonde chaque point.
Avertissement : cet article est fourni à titre informatif et ne constitue pas un conseil juridique. Les textes cités sont ceux en vigueur à la date de rédaction ; pour une situation particulière, consultez un professionnel du droit.
Chaque phase renvoie à un article précis du règlement (UE) 2016/679 (RGPD) ou de la loi française.
Côté pratique, la CNIL publie un Guide RGPD du développeur, organisé en fiches thématiques (sécuriser les sites web et les serveurs, minimiser les données collectées, gérer les utilisateurs, maîtriser les bibliothèques et SDK, tester les applications, informer les personnes, entre autres), ouvert aux contributions sur GitHub. Les phases ci-dessous suivent à peu près cet ordre, ramené à ce qu'un intégrateur peut faire seul en une demi-journée.
Avant de parler consentement, il faut savoir ce que la page charge. Ouvrez l'onglet Réseau des outils de développement sur trois pages types, en navigation privée, sans cliquer sur le bandeau. Notez chaque domaine tiers contacté : gestionnaire de balises, polices hébergées à l'extérieur, carte interactive, lecteur vidéo intégré, module de chat, CDN, pixel publicitaire, outil de mesure d'audience. Chaque requête vers un tiers transmet au minimum l'adresse IP du visiteur, qui est un identifiant en ligne au sens de l'article 4, point 1, du RGPD (le considérant 30 cite expressément les adresses IP). La fiche « Maîtriser vos bibliothèques et vos SDK » du guide CNIL pose les deux questions utiles : quelles données sont envoyées à travers ces dépendances, et à quels destinataires.
| Point | Où vérifier | Fait |
|---|---|---|
| Liste de tous les domaines tiers appelés avant tout clic sur le bandeau | Onglet Réseau, filtre « tiers », profil de navigateur vierge | Oui / Non |
| Pour chaque tiers : quelle donnée part (IP, URL de page, identifiant, contenu de formulaire) | En-têtes et corps des requêtes ; documentation du fournisseur | Oui / Non |
| Polices, cartes, vidéos : version auto-hébergée ou façade cliquable possible ? | Sources du thème, réglages du CMS | Oui / Non |
| Bibliothèques maintenues et à jour (mises à jour de sécurité) | Fichier de dépendances, gestionnaire de paquets | Oui / Non |
Résultat de cette phase : un tableau des tiers, avec pour chacun « nécessaire au service » ou « non essentiel ». C'est la matière des phases 2 et 7.
L'article 82 de la loi Informatique et Libertés est clair sur l'ordre : information, puis consentement, puis accès au terminal. Un bandeau affiché pendant que le pixel se charge derrière ne respecte pas cet ordre. Le gestionnaire de balises ne doit déclencher aucune balise non essentielle tant que le signal de consentement n'existe pas, et les intégrations tierces (vidéo, carte, chat) doivent attendre le même signal ou être remplacées par une image cliquable qui ne charge rien avant le clic.
Deux nuances. La mesure d'audience peut être exemptée de consentement aux conditions décrites par la CNIL sur sa page « Cookies : solutions pour les outils de mesure d'audience » : finalité strictement limitée à la mesure d'audience pour le compte de l'éditeur, données statistiques anonymes uniquement, pas de recoupement avec d'autres traitements ni de suivi entre sites, durée de vie du traceur limitée (treize mois est cité comme exemple) et conservation des données pendant vingt-cinq mois au maximum. Et selon l'article 7, paragraphe 3, du RGPD, retirer son consentement doit être aussi simple que le donner : un lien permanent vers le gestionnaire de préférences, dans le pied de page, règle ce point.
| Point | Où vérifier | Fait |
|---|---|---|
| Aucun cookie ni requête non essentielle avant interaction avec le bandeau | Profil de navigateur neuf, onglet Réseau et Stockage, sans cliquer | Oui / Non |
| Le bouton « Refuser » est au même niveau que « Accepter » | Rendu du bandeau, mobile et bureau | Oui / Non |
| Après refus : encore aucune requête non essentielle, sur plusieurs pages | Même test, après clic sur « Refuser » | Oui / Non |
| Lien permanent pour modifier ou retirer le choix | Pied de page | Oui / Non |
| Preuve du consentement conservée (horodatage, version du bandeau, choix) | Réglages de la solution de gestion du consentement | Oui / Non |
Le test qui compte est le premier de ce tableau, avec un profil de navigateur vraiment vierge ; un profil déjà utilisé a souvent un consentement mémorisé.
Un formulaire de contact est le premier point de collecte du site. L'article 5, paragraphe 1, point c) demande des données limitées à ce qui est nécessaire ; la fiche CNIL « Minimiser les données collectées » le traduit simplement : si une donnée n'est pas nécessaire pour une catégorie de personnes, ne la collectez pas. L'article 13 demande que l'identité du responsable, les finalités, la base juridique, les destinataires et la durée de conservation soient fournis au moment de la collecte : une mention courte sous le bouton d'envoi, avec un lien vers la politique de confidentialité, répond à ce moment-là. Le considérant 32 du RGPD précise qu'il n'y a pas de consentement en cas de case cochée par défaut : la case « recevoir la newsletter » part décochée.
Deux pratiques qui ne sont pas imposées par un texte mais qui simplifient la vie du client : le double opt-in pour la newsletter, qui produit une preuve datée du consentement utile au regard de l'article 7, paragraphe 1 ; et un champ piège (honeypot) invisible plutôt qu'un captcha tiers, qui charge lui aussi un script externe et ramène à la phase 2.
| Point | Où vérifier | Fait |
|---|---|---|
| Chaque champ obligatoire a une raison ; les autres sont facultatifs ou supprimés | Définition du formulaire | Oui / Non |
| Mention d'information sous le formulaire, avec lien vers la politique | Rendu du formulaire | Oui / Non |
| Aucune case pré-cochée | Rendu du formulaire | Oui / Non |
| Newsletter : confirmation par e-mail avant inscription | Réglages de l'outil d'e-mailing | Oui / Non |
| Anti-spam sans script tiers si possible | Sources du formulaire | Oui / Non |
| Où sont stockées les soumissions et pendant combien de temps | Base du CMS, extension de formulaire, boîte e-mail | Oui / Non |
La fiche CNIL « Sécuriser vos sites web, vos applications et vos serveurs » demande de mettre en œuvre TLS 1.2 ou 1.3 sur tous les sites, de forcer HTTPS via HSTS, et d'utiliser les indicateurs Secure et HttpOnly sur les cookies. C'est la déclinaison concrète du chiffrement mentionné à l'article 32, paragraphe 1, point a). Les en-têtes de sécurité (politique de contenu, protection contre l'inclusion en cadre, type de contenu) relèvent des mesures appropriées au risque du même article ; ils restent une mesure défensive générique, à adapter au site.
| Point | Où vérifier | Fait |
|---|---|---|
| Toute URL en HTTP redirige vers HTTPS, y compris avec et sans « www » | Requêtes manuelles, onglet Réseau | Oui / Non |
| Aucun contenu mixte (image, script, police chargés en HTTP) | Console du navigateur | Oui / Non |
| En-tête HSTS présent | En-têtes de réponse | Oui / Non |
Cookies de session avec Secure, HttpOnly et un attribut SameSite | Onglet Stockage, en-têtes Set-Cookie | Oui / Non |
| En-têtes de sécurité définis et testés sans casser le site | Configuration du serveur web | Oui / Non |
| Renouvellement TLS automatique configuré | Hébergeur ou tâche planifiée | Oui / Non |
Les journaux du serveur web contiennent des adresses IP, donc des données personnelles. L'article 5, paragraphe 1, point e) limite la durée de conservation à ce qui est nécessaire. Pour les journaux de sécurité, la CNIL indique dans sa recommandation relative aux mesures de journalisation une durée comprise entre six mois et un an dans le cas général. Une rotation de journaux réglée sur cette fourchette, et notée, suffit pour un site vitrine ou une petite boutique.
Les sauvegardes relèvent de l'article 32, paragraphe 1, point c), mais une sauvegarde conservée indéfiniment contient les données que le site a effacées entre-temps. La fiche CNIL « Tester vos applications » est nette : pas de données réelles de production en développement et en test ; un jeu de données fictives, et une anonymisation de ce qui est importé. La préproduction copiée depuis la base réelle et accessible sans mot de passe est l'un des écarts les plus fréquents à la livraison.
| Point | Où vérifier | Fait |
|---|---|---|
| Rotation des journaux serveur réglée, durée notée dans le document de livraison | Configuration du serveur web ou de l'hébergeur | Oui / Non |
| Sauvegardes automatiques, restauration testée une fois | Panneau de l'hébergeur, outil de sauvegarde | Oui / Non |
| Durée de rétention des sauvegardes définie | Même endroit | Oui / Non |
| Préproduction sans données réelles, ou données anonymisées | Base de la préproduction | Oui / Non |
| Préproduction protégée (authentification, non indexée) | Accès direct à l'URL, en-tête X-Robots-Tag | Oui / Non |
La fiche CNIL « Gérer les utilisateurs » demande des identifiants uniques et propres à chaque individu, une authentification avant tout accès à des données personnelles, une authentification forte lorsque c'est possible, et des procédures écrites pour les arrivées et départs. La fiche sur la sécurisation des sites ajoute une politique de mots de passe propre aux administrateurs, changés au moins à chaque départ d'un administrateur, et un accès aux interfaces d'administration limité aux seules personnes habilitées. Ces mesures relèvent de l'article 32. Le point souvent oublié : le compte de l'agence, avec les droits les plus élevés, encore actif après la fin du contrat.
| Point | Où vérifier | Fait |
|---|---|---|
| Un compte nominatif par personne ; aucun compte « admin » partagé | Liste des utilisateurs du CMS et de l'hébergement | Oui / Non |
| Rôle minimal par compte (éditeur plutôt qu'administrateur) | Rôles du CMS | Oui / Non |
| Double authentification activée sur les comptes administrateurs | Extension ou réglage du CMS ; panneau de l'hébergeur | Oui / Non |
| Compte de l'agence supprimé ou désactivé à la remise, mots de passe changés | Liste des utilisateurs, accès FTP/SSH, panneau d'hébergement | Oui / Non |
| Clés d'API et secrets hors du dépôt de code, renouvelés à la livraison | Fichiers d'environnement, historique du dépôt | Oui / Non |
Reprenez le tableau de la phase 1 et ajoutez ce qui ne se voit pas dans le navigateur : hébergeur, e-mails transactionnels, outil d'e-mailing, sauvegarde externe, module de paiement. Chacun est un sous-traitant au sens de l'article 28 du RGPD. Le paragraphe 1 demande de ne faire appel qu'à des sous-traitants présentant des garanties suffisantes ; le paragraphe 3 demande un contrat écrit qui couvre notamment le traitement sur instruction documentée, la confidentialité, les mesures de sécurité de l'article 32, l'encadrement des sous-traitants ultérieurs, l'aide à l'exercice des droits et la suppression ou restitution des données en fin de contrat. Chez la plupart des fournisseurs en ligne, ce contrat existe déjà sous forme d'accord de traitement des données (DPA). Le développeur ne le négocie pas ; il s'assure qu'il existe, note où il se trouve et relève le lieu d'hébergement indiqué par le fournisseur.
| Point | Où vérifier | Fait |
|---|---|---|
| Liste complète des prestataires qui traitent des données (visibles et invisibles) | Tableau de la phase 1 + configuration serveur et CMS | Oui / Non |
| Pour chacun : accord de traitement des données trouvé et lien noté | Espace client ou documentation juridique du fournisseur | Oui / Non |
| Lieu d'hébergement des données relevé pour chacun | Même source | Oui / Non |
| Prestataires inutilisés supprimés (extension désactivée, compte fermé) | Extensions du CMS, comptes fournisseurs | Oui / Non |
La dernière phase ne se code pas. Elle consiste à écrire, en une page, ce qui a été réglé et ce qui reste au client. Le client est le responsable du traitement ; c'est à lui que l'article 25 s'adresse, et c'est lui qui répond aux demandes des personnes. Sans ce document, le travail des phases 1 à 7 est invisible pour le client.
Secure et HttpOnly, en-têtes de sécurité testés.La vérification gratuite Sitetals examine votre page d'accueil et signale, entre autres, l'absence d'une page de mentions légales ou de politique de confidentialité accessible, ainsi que les services tiers chargés par votre site. C'est un point de départ pour la relecture décrite ci-dessus, pas un substitut à celle-ci.
À lire également :
Sources : Règlement (UE) 2016/679, articles 4, 5, 7, 13, 25, 28 et 32, considérants 30 et 32 · Loi n° 78-17 du 6 janvier 1978, article 82 · CNIL, Guide RGPD du développeur (fiches Sécuriser vos sites web, Minimiser les données collectées, Gérer les utilisateurs, Maîtriser vos bibliothèques et vos SDK, Tester vos applications, Informer les personnes) · CNIL, recommandation relative aux mesures de journalisation · CNIL, Cookies : solutions pour les outils de mesure d'audience · Méthodologie Sitetals.
Rédaction Sitetals