Politique de confidentialité : pourquoi la vôtre ment

La semaine dernière, j'audite le code d'une startup SaaS. Leur politique de confidentialité dit, mot pour mot : "Vos données personnelles ne sont jamais partagées avec des tiers." En 20 minutes d'analyse, je compte 5 services tiers qui reçoivent des données utilisateurs : Google Analytics, Hotjar, Sentry, Stripe, Intercom. La politique mentait. Le fondateur ne le savait même pas — il avait copié un template trouvé en ligne.

Sur mes 30 derniers audits de conformité RGPD, 28 politiques de confidentialité contenaient au moins une affirmation factuellement fausse. Pas par malhonnêteté. Par copier-coller.

Le copier-coller : la pire stratégie de conformité RGPD

Je comprends pourquoi tout le monde le fait. Vous lancez votre produit, vous avez 200 priorités, quelqu'un vous dit qu'il faut une politique de confidentialité. Vous trouvez un modèle en ligne, vous remplacez le nom de l'entreprise, et c'est réglé. 15 minutes. Prochaine tâche.

Le problème, c'est qu'une politique copiée décrit les traitements de quelqu'un d'autre. Pas les vôtres. Et quand elle affirme des choses qui ne correspondent pas à ce que fait votre application, ce n'est plus un oubli — c'est un mensonge documenté.

Un cas vécu. Un client avait dans sa politique : "Vous disposez d'un droit à la portabilité de vos données." Quand j'ai demandé comment un utilisateur pouvait exporter ses données, silence. Pas de bouton d'export, pas d'API, pas de procédure. Le droit existait dans le texte, pas dans le produit. En cas de contrôle CNIL, c'est une promesse non tenue, noir sur blanc.

Si votre politique vient d'un template, il y a de fortes chances qu'elle contienne les mêmes erreurs. Elles reviennent tellement souvent que j'ai fini par les cataloguer.

Si vous découvrez le RGPD, commencez par comprendre les 6 obligations concrètes — ça rend tout ce qui suit plus clair.

Les 5 mensonges que je retrouve dans quasi tous les audits

"Nous ne partageons pas vos données avec des tiers"

Le mensonge le plus répandu. Et le plus facile à démonter.

Votre site utilise Google Analytics ? Les données de navigation partent chez Google. Stripe pour le paiement ? Les données bancaires transitent par Stripe. Un chat Intercom ? Chaque conversation est stockée sur leurs serveurs. Sentry pour le monitoring ? Les erreurs — qui contiennent parfois des données utilisateurs — sont envoyées chez eux.

Chacun de ces outils est un tiers. Chacun reçoit des données personnelles.

La phrase honnête, c'est : "Nous partageons certaines données avec les prestataires suivants, pour les finalités suivantes : [liste]." Moins rassurant. Mais conforme.

"Vos données sont conservées pendant la durée nécessaire"

Cette formulation, je la trouve dans 8 audits sur 10. Elle ne veut rien dire.

Un audit récent : je regarde la base de données d'un client qui utilise cette phrase exacte. Des comptes "supprimés" par les utilisateurs sont toujours là. Certains depuis plus de 3 ans. Les données n'étaient jamais effacées — aucun mécanisme de purge dans le code. Rien. Le champ deleted_at était rempli, mais personne n'avait codé le job qui supprime réellement les lignes.

La CNIL attend des durées précises : données de compte conservées 3 ans après la dernière activité, logs de connexion 12 mois, données de facturation 10 ans (obligation légale). Ce niveau de détail-là. Pas du vague.

"Vous pouvez exercer vos droits à tout moment"

Droit d'accès, rectification, effacement, portabilité, opposition... La liste complète est souvent là, recopiée depuis un site officiel.

Combien de ces droits sont réellement exercables dans votre produit ?

Le droit à la portabilité suppose qu'un utilisateur puisse exporter toutes ses données dans un format exploitable. Sur les startups que j'audite, moins d'une sur cinq propose cette fonctionnalité. Le droit à l'effacement suppose que la suppression de compte efface vraiment toutes les données — pas juste un flag is_deleted = true pendant que tout reste en base.

Lister des droits que vous ne pouvez pas techniquement honorer, c'est exactement le décalage que la CNIL sanctionne.

"Notre DPO est joignable à dpo@entreprise.com"

Anecdote rapide. Je vois cette mention dans une politique. J'envoie un mail de test. Bounce. L'adresse n'a jamais été créée.

Un DPO n'est pas obligatoire pour toutes les entreprises — si votre activité principale n'est pas le traitement de données à grande échelle, vous n'en avez probablement pas besoin. Mais si votre politique en mentionne un, il doit exister et répondre aux emails. Sinon, vous affichez une garantie fictive.

"Seuls les cookies essentiels sont déposés par défaut"

Votre bandeau dit que seuls les cookies techniques sont actifs avant consentement. Sauf que Google Analytics se charge au démarrage de la page. Le pixel Facebook se déclenche au chargement. Hotjar enregistre la session avant tout clic.

La CNIL a des outils de scan automatisé qui visitent votre site et listent tout ce qui se charge avant consentement. Si votre bandeau promet une chose et que votre code en fait une autre, ils le voient. Les cookies restent le premier motif de sanction en 2024, avec des amendes entre 5 000 et 100 000 € pour des PME.

Ce que la CNIL vérifie (et ce n'est pas votre texte)

Beaucoup de fondateurs pensent que la conformité RGPD, c'est avoir les bons documents. La politique, le registre, le bandeau. Tant que les papiers sont en ordre, c'est bon.

Sauf que la CNIL ne se contente plus de lire vos documents. Elle compare ce que vous dites avec ce que vous faites.

Ses équipes techniques scannent votre site. Elles regardent les requêtes réseau, les cookies déposés, les appels à des services tiers. Elles vérifient si des données partent hors Union Européenne. Elles testent si votre formulaire de désinscription fonctionne. Elles envoient un mail au DPO indiqué.

Et les contrôles ne ciblent pas que les grands groupes. En 2024, plus d'un tiers des contrôles CNIL concernaient des PME et startups. Le déclencheur le plus courant : une plainte d'un utilisateur mécontent, d'un ex-employé ou d'un concurrent.

Le paradoxe : une politique de confidentialité copiée peut vous mettre dans une situation pire que de ne pas en avoir du tout. Parce qu'elle constitue un engagement écrit. Si votre politique dit "nous ne transférons pas de données hors UE" et que votre hébergeur est AWS us-east-1, c'est un mensonge documenté que la CNIL peut utiliser contre vous.

Comment avoir une politique qui ne ment pas

La seule façon d'écrire une politique honnête, c'est de partir de ce que fait réellement votre application. Pas d'un template juridique. De votre code.

Ça commence par lister tous les services tiers intégrés dans votre app : analytics, paiement, emailing, monitoring, support, publicité. Chacun est un sous-traitant qui reçoit des données personnelles, et chacun doit apparaître dans votre politique.

Ensuite, il faut identifier les données réellement collectées. Pas celles que vous pensez collecter — celles que vos formulaires, vos bases de données et vos logs contiennent effectivement. Puis définir des durées de conservation concrètes pour chaque type de donnée. Et vérifier que chaque droit listé dans la politique est techniquement exercable dans votre produit.

C'est un travail technique. Un fondateur non-technique ne peut pas le faire seul — ça demande de lire du code, d'analyser des flux de données, de vérifier des configurations serveur. C'est pour ça que la politique de confidentialité devrait être générée à partir du code, pas rédigée à partir d'un modèle.

Votre politique ment-elle ? 7 questions à poser

Envoyez ces questions à votre équipe technique ou votre prestataire. Si vous obtenez "non" ou "je ne sais pas" à plus de deux, votre politique contient probablement des affirmations fausses.

• Tous les services tiers qui reçoivent des données utilisateurs sont-ils listés dans la politique ?
• Les durées de conservation sont-elles chiffrées — pas "durée nécessaire" mais "12 mois", "3 ans" ?
• Chaque droit mentionné (portabilité, effacement, accès) est-il techniquement exercable dans le produit ?
• L'adresse email de contact indiquée reçoit-elle réellement les emails ?
• Le bandeau cookies bloque-t-il effectivement les trackers avant le consentement ?
• Les transferts de données hors UE sont-ils mentionnés si votre hébergeur ou vos outils sont américains ?
• La politique a-t-elle été mise à jour depuis le dernier ajout d'un service tiers ?

Ce que j'en retiens après 30+ audits

La politique de confidentialité n'est pas un document qu'on rédige une fois et qu'on oublie. C'est le reflet de ce que fait votre application avec les données de vos utilisateurs. Si vous ne savez pas ce que fait votre code, vous ne pouvez pas écrire une politique honnête.

Le template copié-collé, c'est comme signer un contrat sans le lire — sauf que c'est vous qui l'avez écrit et publié. Et c'est la CNIL qui le lira.

Si vous voulez une politique qui reflète votre réalité technique, c'est ce que produit un audit de conformité RGPD : on part de votre code, on identifie les vrais traitements, et on génère les documents qui correspondent à ce que fait réellement votre application.