Back to Articles

Conformité RGPD des sites web : ce qu'il faut réellement construire

La plupart des conseils RGPD que l'on trouve en ligne sont écrits pour des juristes, ou pour des gens qui achètent un générateur de politique. Très peu s'adressent à la personne qui doit ouvrir un éditeur et changer quelque chose.

Ce guide est du second type. Il parcourt ce que le règlement général sur la protection des données exige d'un site et des systèmes derrière lui, exprimé sous forme de choses que l'on construit, configure ou supprime. Nous faisons ce travail pour des entreprises opérant dans l'UE depuis l'entrée en application du règlement en 2018, et le schéma de ce qui déraille n'a pratiquement pas changé depuis.

Une précision d'emblée : le RGPD n'est pas devenu plus simple parce que de nouveaux règlements sont arrivés. Il est devenu plus important, car presque tout dans la vague actuelle de règles numériques européennes suppose que vos données personnelles sont déjà en ordre.

Commencez par un inventaire honnête des données

Presque tous les projets RGPD ratés dont nous avons hérité ont échoué au même endroit. L'équipe a écrit la politique d'abord et découvert les données ensuite.

Avant toute chose, cartographiez les données personnelles que votre site collecte réellement. Pas ce que dit la spécification produit. Ce qui se trouve dans la base, les journaux, la plateforme d'analytics, le CRM, l'outil de support, la pile d'automatisation marketing, le traqueur d'erreurs, les journaux du CDN et les scripts tiers présents sur la page.

En pratique, cela signifie :

  • Passer le schéma au peigne fin. Chaque colonne susceptible d'identifier une personne, seule ou combinée à une autre.
  • Lire l'onglet réseau sur un chargement de page réel. Chaque requête sortante vers un domaine que vous ne contrôlez pas est un transfert potentiel de données personnelles, car une adresse IP plus un user agent constituent une donnée personnelle.
  • Vérifier ce que capture votre traqueur d'erreurs. Les traces d'exécution contiennent régulièrement des adresses e-mail, des jetons et des corps de requête.
  • Vérifier la rétention des journaux. Des logs d'accès avec IP conservés indéfiniment sont l'un des constats les plus fréquents et l'un des plus faciles à corriger.

Consignez tout dans un registre des activités de traitement. L'article 30 l'exige de toute façon pour la plupart des organisations, et la version utile aux développeurs est un tableau avec le système, les données, la finalité, la base légale, la durée de conservation et les destinataires.

Choisissez une base légale par finalité, pas par système

L'article 6 offre six bases légales. L'erreur la plus fréquente est d'en choisir une pour tout le produit.

Vous avez presque certainement plusieurs finalités en parallèle. Exécuter une commande relève du contrat. Les contrôles antifraude relèvent généralement de l'intérêt légitime ou de l'obligation légale. Conserver les factures pendant la durée légale relève de l'obligation légale. L'e-mail marketing relève du consentement dans la plupart des États membres. L'analytique non essentielle relève du consentement, en raison des règles ePrivacy sur l'accès aux équipements terminaux plutôt que du RGPD lui-même.

Conséquence pratique : votre modèle de données doit savoir quelle finalité sert chaque enregistrement. Si vous ne pouvez pas séparer le profil marketing de l'enregistrement de commande, vous ne pouvez pas honorer une opposition marketing sans casser l'historique de commande. Cette séparation est une décision de schéma, et elle est douloureuse à rétrofiter.

Le consentement doit être réel, et il doit être enregistré

Si vous vous appuyez sur le consentement, il doit être libre, spécifique, éclairé et univoque, et vous devez pouvoir le démontrer plus tard.

Concrètement :

  • Rien de non essentiel ne se déclenche avant que l'utilisateur n'agisse. Cela inclut le script d'analytics, le pixel publicitaire, le widget de chat, la police chargée depuis un CDN tiers et le script de test A/B.
  • Refuser doit être aussi simple qu'accepter. Même niveau, même visibilité, même nombre de clics. Les régulateurs traitent toute autre configuration comme un dark pattern, et ils sont constants sur ce point.
  • Le consentement est par finalité. Un seul interrupteur couvrant « analytique, marketing et personnalisation » n'est pas spécifique.
  • Le retrait est aussi facile que l'octroi. Un lien permanent ou un bouton flottant, pas un e-mail au support.
  • Conservez la preuve : un horodatage, la chaîne de consentement ou l'état de chaque catégorie, la version de la bannière et le texte affiché à l'utilisateur. Sans la version, vous ne pouvez pas défendre un consentement vieux de deux ans.

L'application n'a rien de théorique ici. En septembre 2025, l'autorité française a infligé le même jour 325 millions d'euros d'amende à Google et 150 millions à Shein pour des pratiques liées aux cookies. Les deux affaires portaient sur la mécanique plutôt que sur le texte de la politique : des cookies déposés avant toute interaction, et des boutons de refus qui ne refusaient pas réellement.

Les règles bougent aussi. La proposition Digital Omnibus ferait basculer le consentement aux équipements terminaux dans le RGPD lui-même et rendrait les signaux navigateur contraignants. Nous avons détaillé ce que cela changerait dans le consentement aux cookies après le Digital Omnibus.

Construisez tôt la mécanique des droits des personnes

Les articles 15 à 22 donnent aux personnes le droit d'accès, de rectification, d'effacement, de limitation, de portabilité et d'opposition. Vous avez un mois pour répondre, extensible à trois dans les cas complexes.

Les équipes traitent d'abord les premières demandes à la main, ce qui fonctionne jusqu'au jour où cela ne fonctionne plus. Ce qu'il vous faut, bien avant l'arrivée du volume :

Un résolveur capable de retrouver une personne à travers les systèmes. À partir d'une adresse e-mail, tout renvoyer : le compte, les commandes, les tickets de support, le profil marketing, l'identifiant analytique, les journaux. Si un humain doit se souvenir qu'il existe une plateforme d'avis tierce détenant des données, quelqu'un finira par l'oublier.

Un chemin de suppression respectant les obligations de conservation. L'effacement n'est pas absolu. Les factures doivent généralement survivre pour des raisons fiscales. Ce qu'il faut, c'est une suppression logique avec suppression physique par finalité, afin de retirer le profil marketing tout en conservant l'écriture comptable, et afin que cette écriture expire elle-même à échéance.

Un export portable. Structuré, couramment utilisé, lisible par machine. Du JSON convient. Un PDF d'une page HTML rendue, non.

Un indicateur d'opposition que tout le système lit. S'opposer au profilage doit réellement arrêter le profilage, y compris dans le traitement par lots qui tourne à trois heures du matin et ne vérifie pas l'indicateur.

La conservation est un travail, pas une ligne de politique

La limitation de la conservation est le principe le plus souvent violé par des systèmes par ailleurs bien conçus, parce que supprimer exige que quelqu'un écrive et planifie une tâche que personne ne réclame.

Donnez à chaque catégorie de données une durée de vie définie, puis implémentez-la. Journaux d'accès, sessions, paniers abandonnés, inscriptions non vérifiées, tickets clos, anciennes sauvegardes et données analytiques brutes ont toutes besoin d'une expiration. Les sauvegardes méritent une attention particulière : si votre processus de restauration ressuscite des données supprimées, votre effacement est incomplet. La réponse habituelle est une rotation documentée avec âge maximal, plus une réapplication des suppressions après toute restauration.

Transferts, sous-traitants ultérieurs et localisation réelle de votre pile

Les transferts hors EEE nécessitent un mécanisme juridique, généralement le cadre de protection des données UE-États-Unis pour les destinataires américains certifiés, ou des clauses contractuelles types accompagnées d'une analyse d'impact du transfert ailleurs.

L'angle technique est plus simple que l'angle juridique : sachez où se trouvent physiquement vos données. Cela veut dire la région cloud de chaque service, l'emplacement de vos sauvegardes, la région de votre base managée, la configuration des points de présence du CDN et, surtout, le modèle de support de chaque outil SaaS que vous utilisez. Un fournisseur hébergé à Francfort dont l'équipe de support accède à la production depuis hors EEE reste un transfert.

Nous recommandons généralement de garder les données personnelles dans des régions européennes quand rien de solide ne s'y oppose. Cela supprime toute une catégorie de discussions, et l'écart de coût est en général négligeable.

Tenez une liste de sous-traitants ultérieurs et gardez-la à jour. L'article 28 exige un contrat écrit avec chacun, et cette liste est aussi ce que vos clients demanderont en audit.

La sécurité par défaut, exprimée en configuration

L'article 32 demande des mesures techniques et organisationnelles appropriées. C'est volontairement vague, mais le socle pour un site en 2026 ne se négocie pas :

  • TLS partout, HSTS activé, aucun contenu mixte.
  • Mots de passe hachés avec une fonction moderne à coût mémoire, et authentification multifacteur disponible pour les comptes détenant des données personnelles.
  • Chiffrement au repos pour les bases et les sauvegardes.
  • Accès aux données personnelles de production limité par rôle et journalisé, avec des revues qui ont réellement lieu.
  • Pseudonymisation quand c'est possible : hacher l'identifiant dans l'analytique, garder la table de correspondance séparée et à accès restreint.
  • Une restauration testée, pas seulement une sauvegarde.

La protection des données dès la conception et par défaut, à l'article 25, signifie que l'option la plus protectrice est celle que l'on obtient sans rien faire. Case newsletter décochée. Visibilité du profil privée. Champs facultatifs facultatifs.

La notification de violation a besoin d'un runbook

Soixante-douze heures entre la prise de connaissance et la notification à l'autorité de contrôle, ce n'est pas long, surtout si la violation est découverte un vendredi soir. Notez que la proposition Digital Omnibus porterait ce délai à quatre-vingt-seize heures, mais ce n'est pas encore le droit.

Préparez à l'avance : qui déclare un incident, qui évalue si des données personnelles sont concernées, qui contacte le régulateur, ce que contient la notification, et comment vous informez les personnes concernées si le risque est élevé. Rédigez-le en runbook avec des rôles nommés, et répétez-le une fois. La première utilisation ne devrait pas être la première lecture.

La surface du site elle-même

Une partie du RGPD est visible sur la page, et il vaut la peine de soigner ces détails, car ce sont eux qui font l'objet de signalements.

Votre politique de confidentialité doit indiquer l'identité et le contact du responsable de traitement, les finalités et bases légales, les destinataires et catégories de destinataires, les mécanismes de transfert, les durées de conservation, la liste complète des droits y compris celui de réclamation auprès d'une autorité de contrôle, et l'existence d'une décision automatisée. Écrivez dans une langue qu'une personne ordinaire peut suivre. Les notices en couches, avec une version courte renvoyant au détail, fonctionnent mieux qu'un mur de texte.

Les formulaires ne devraient collecter que le nécessaire. Chaque champ est une justification que vous devrez peut-être fournir. Si la case de consentement marketing est dans la même soumission que la commande, elle doit être décochée séparément et rédigée séparément.

Les intégrations tierces sont l'échec silencieux. YouTube en mode confidentialité renforcée, cartes derrière un espace réservé à charger au clic, polices auto-hébergées plutôt que tirées d'un CDN tiers. Chacun de ces changements est petit et supprime un constat.

Ce que nous voyons le plus souvent échouer

Après suffisamment d'audits, la même courte liste revient :

  1. L'analytique qui charge avant le consentement, généralement parce qu'un gestionnaire de balises a été configuré par le marketing et jamais revu par l'ingénierie.
  2. Des boutons de refus qui déclenchent quand même le consentement, à cause du comportement par défaut d'un script tiers.
  3. Aucune tâche de rétention, sur aucune table.
  4. Un effacement qui oublie les sauvegardes, les journaux et le CRM.
  5. Une politique de confidentialité décrivant un flux de données modifié il y a dix-huit mois.
  6. Des listes de sous-traitants qui s'arrêtent aux trois prestataires évidents.
  7. Des enregistrements de consentement sans la version du texte affiché.

Aucun de ces points n'est difficile. C'est simplement du travail que personne n'a assigné.

Se faire aider

Si vous voulez un second regard sur un site existant, nous réalisons des audits RGPD techniques qui produisent un backlog priorisé plutôt qu'un rapport : quoi corriger, dans quel ordre, avec une estimation en face de chaque point. Si vous construisez du neuf, il est nettement moins coûteux de poser correctement le modèle de données et l'architecture de consentement dès le départ.

Nous couvrons aussi la surface plus large de la conformité européenne, dont l'accessibilité et l'entrée sur le marché européen. Écrivez-nous à office@c9group.dev.

Nous construisons du logiciel. Nous ne donnons pas d'avis juridique, et l'interprétation d'une exigence précise appartient à vos conseils. Ce que nous pouvons faire, c'est garantir que le système fait ce que vos conseils disent qu'il doit faire.