Audit RGPD

RGPD et site internet : 5 erreurs que je vois partout

18 août 20268 min de lecturergpd site internet
Partager :

"Mon site est conforme, on a le bandeau cookies."

J'entends cette phrase chaque semaine. La dernière fois, j'ai ouvert les outils développeur devant le fondateur. Google Analytics tournait déjà — avant même qu'il ait cliqué sur "Accepter". Son bandeau cookies était décoratif. Un autocollant "alarme" sur une maison sans serrure.

Si vous avez un site internet et que vous vous demandez s'il est conforme au RGPD, voici les 5 erreurs que je retrouve systématiquement quand j'audite des sites. Spoiler : la plupart se corrigent en moins d'une heure.

Le bandeau cookies qui ne bloque rien

C'est l'erreur numéro un. Et la plus traître, parce qu'elle donne l'illusion de la conformité.

Le scénario classique : vous installez Axeptio, Cookiebot ou Tarteaucitron. Beau bandeau, boutons "Accepter" et "Refuser", catégories de cookies bien rangées. Sauf que derrière, les scripts de tracking se chargent avant que le visiteur ait donné son consentement.

Le mois dernier, j'ai audité le site d'une startup SaaS B2B. Leur bandeau Axeptio était impeccable visuellement. J'ai ouvert l'onglet Réseau de Chrome DevTools. Trois requêtes partaient vers Google Analytics, une vers le pixel Facebook, une vers Hotjar. Tout ça au chargement de la page, avant toute interaction avec le bandeau.

Le bandeau affichait les bons boutons. Mais il ne bloquait aucun script. Juridiquement, c'est exactement comme ne pas avoir de bandeau du tout.

Comment vérifier vous-même : ouvrez votre site dans un navigateur en navigation privée. Avant de cliquer sur quoi que ce soit, appuyez sur F12, onglet Réseau. Si vous voyez des requêtes vers google-analytics.com, facebook.com ou d'autres services tiers — votre bandeau ne bloque rien. Le fix prend 15 à 30 minutes : il suffit de conditionner le chargement de chaque script au consentement. Votre outil CMP le permet, il faut juste le configurer correctement.

La politique de confidentialité copié-collé

Un fondateur m'a un jour montré sa politique de confidentialité avec fierté. "Je l'ai prise sur un générateur en ligne, c'est du solide."

J'ai lu le document. Il mentionnait une newsletter — le site n'en avait pas. Un système de paiement en ligne — le site ne vendait rien. Il indiquait que les données étaient hébergées en France — elles étaient sur AWS us-east-1, en Virginie.

En revanche, pas un mot sur Google Analytics, ni sur Intercom (le chat en bas à droite), ni sur Calendly (la prise de rendez-vous). Trois outils qui collectent des données personnelles à chaque utilisation.

Une politique de confidentialité, c'est un miroir de ce que fait réellement votre site avec les données de vos visiteurs. Si elle ne correspond pas à la réalité, elle ne vaut rien. Pire : en cas de contrôle, elle prouve que vous n'avez pas fait le travail.

Ce qu'elle doit contenir :

  • La liste exacte des données collectées par votre site (pas celles d'un template)
  • Pourquoi vous les collectez (la "base légale" en jargon RGPD — pour vous, c'est la justification)
  • Combien de temps vous les conservez
  • À qui vous les transmettez — chaque outil tiers est un destinataire
  • Les droits de vos utilisateurs : suppression, accès, rectification, et comment les exercer

Si vous n'êtes pas sûr de ce que votre site collecte réellement, un audit RGPD technique le révèle en analysant votre code — pas en vous posant des questions.

Les formulaires sans aucune mention

Votre site a un formulaire de contact ? Il demande le nom, l'email, peut-être le téléphone et le nom de l'entreprise. Il y a un bouton "Envoyer". Point.

Problème : l'article 13 du RGPD impose d'informer la personne au moment de la collecte. Pas ailleurs, pas dans un document qu'il faut aller chercher — directement sous le formulaire.

Concrètement, chaque formulaire doit indiquer :

  • Pourquoi vous collectez ces données
  • Combien de temps vous les conservez
  • Comment l'utilisateur peut demander leur suppression

En pratique, ça tient en deux lignes : "Ces données sont collectées pour répondre à votre demande et conservées 12 mois. Suppression sur simple demande à contact@votresite.fr."

Ce n'est pas une formalité. J'audite des dizaines de sites par an. Je trouve cette mention sous un formulaire sur deux au mieux. Formulaires de contact, d'inscription newsletter, de demande de devis — personne n'y pense. C'est pourtant l'un des premiers points que la CNIL vérifie lors d'un contrôle, parce que c'est facilement vérifiable de l'extérieur, sans même avoir accès au code.

Google Fonts et les ressources chargées depuis l'extérieur

Celle-là est moins connue. Et c'est dommage, parce que le risque est réel et le correctif prend 20 minutes.

Si votre site utilise Google Fonts — et statistiquement, il y a de bonnes chances — il charge les polices depuis fonts.googleapis.com. À chaque visite, le navigateur de votre utilisateur envoie une requête aux serveurs de Google. Cette requête contient l'adresse IP du visiteur. Résultat : Google reçoit l'IP de chaque personne qui visite votre site, sans consentement.

En janvier 2022, le tribunal de Munich (LG München) a condamné un site pour exactement ce cas de figure. 100 € de dommages par visiteur concerné. L'affaire a fait jurisprudence en Europe. Depuis, des cabinets envoient des mises en demeure en série aux sites qui chargent Google Fonts en externe — c'est devenu un business.

La solution : téléchargez les polices et hébergez-les sur votre propre serveur. Plus aucune requête vers Google, plus aucun transfert d'IP. Des outils comme google-webfonts-helper rendent l'opération quasi automatique.

Et Google Fonts n'est pas le seul concerné. Vérifiez si votre site charge des ressources depuis des CDN externes : jQuery, Bootstrap, Font Awesome... Chaque ressource externe, c'est une IP transmise à un serveur tiers sans consentement. Le principe est le même.

Votre app a ces failles ?

Registre, politique de confidentialité et rapport de conformité issus de votre code.

Obtenir ma conformité RGPD

Les outils tiers non déclarés

Faites l'exercice maintenant. Listez tous les outils que votre site utilise. Pas seulement ceux que vous avez choisis consciemment. Tous.

Le chat en bas à droite — Intercom, Crisp, Drift. La prise de rendez-vous — Calendly, Cal.com. Les formulaires — Typeform, Tally. L'analytics — Google Analytics, Plausible. Le tracking comportemental — Hotjar, FullStory. La newsletter — Mailchimp, Brevo. Le CRM — HubSpot, Pipedrive.

Chacun de ces outils est un "sous-traitant" au sens du RGPD. Chacun doit être :

  1. Mentionné dans votre politique de confidentialité avec les données qu'il reçoit
  2. Couvert par un DPA (Data Processing Agreement) — le contrat qui encadre le traitement des données
  3. Inscrit dans votre registre des traitements

La dernière startup que j'ai auditée utilisait 11 outils tiers qui recevaient des données personnelles. Leur politique de confidentialité en mentionnait 3. Les 8 autres ? Fantômes. Invisibles dans la documentation, bien visibles dans le code.

Le problème est double. D'abord, vos utilisateurs ne savent pas que leurs données partent chez Hotjar ou HubSpot. Ensuite, en cas de contrôle, un registre incomplet est la preuve que vous n'avez pas cartographié vos traitements — c'est l'obligation de base du RGPD.

Si vous ne savez pas combien d'outils tiers votre site utilise, vous ne savez probablement pas non plus combien coûterait une vraie mise en conformité.

Auto-diagnostic : votre site est-il conforme ?

Avant de faire appel à qui que ce soit, vous pouvez vérifier vous-même les 5 points ci-dessus. Prenez 10 minutes.

Bandeau cookies

  • Mon site a un bandeau cookies
  • Les scripts tiers ne se chargent PAS avant le clic sur "Accepter" (vérifiable dans l'onglet Réseau)
  • Le bouton "Refuser" est aussi visible que le bouton "Accepter"

Politique de confidentialité

  • Elle existe et est accessible depuis toutes les pages
  • Elle liste les données réellement collectées (pas un template générique)
  • Elle mentionne tous les outils tiers utilisés
  • Elle indique les durées de conservation

Formulaires

  • Chaque formulaire a une mention indiquant la finalité de la collecte
  • Un lien vers la politique de confidentialité est présent

Ressources externes

  • Les polices sont hébergées localement (pas de requête vers fonts.googleapis.com)
  • Les librairies JS/CSS sont hébergées localement

Outils tiers

  • J'ai la liste complète de tous les outils tiers utilisés sur mon site
  • Chacun est mentionné dans ma politique de confidentialité
  • J'ai signé un DPA avec chacun

Si vous avez coché toutes les cases, vous êtes dans le top 10% des sites que j'audite. S'il vous manque plus de 4 points, votre site a les mêmes lacunes que la grande majorité — et ce sont des lacunes qui se corrigent.

Ce que ça coûte de ne rien faire

Ces 5 erreurs ne sont pas théoriques. Un contrôle CNIL déclenché par une plainte utilisateur — et une simple plainte suffit — c'est 2 à 4 semaines de mobilisation pour constituer un dossier en urgence. Un prospect B2B qui demande votre registre des traitements et constate qu'il est incomplet, c'est un deal perdu. La jurisprudence Google Fonts, c'est 100 € par visiteur concerné.

Chaque erreur de cette liste se corrige en moins d'une heure. Mais il faut d'abord les identifier. Et c'est rarement en se posant des questions à soi-même qu'on trouve les vrais problèmes — c'est en regardant ce que le code fait réellement.

Si vous voulez savoir exactement où en est votre site, un audit RGPD technique analyse votre code et vos flux de données, et vous livre un registre des traitements qui reflète la réalité — pas un questionnaire déclaratif.

MH

Marc Haussaire

Ingénieur INSA · 15+ ans d'expérience

Cofondateur et ex-CTO de Lilo.org (800 000 utilisateurs), j'ai scalé des infrastructures à 100 millions de requêtes par mois. Aujourd'hui, j'audite le code et la conformité RGPD des applications — en particulier celles générées par l'IA.

Obtenir ma conformité RGPD