Un fondateur m'a montré son dossier de conformité RGPD. 5 000 euros. Beau classeur. Politique de confidentialité impeccable, registre des traitements détaillé. J'ai ouvert le code de son app. Le registre disait "données chiffrées au repos". La base de données ? Pas un octet de chiffrement. Il listait 4 sous-traitants. Le code en utilisait 9.
Ce fondateur n'est pas incompétent. Il a fait ce qu'on lui a dit : il a payé un DPO, qui a posé des questions, noté les réponses, et produit de beaux documents. Personne n'a vérifié si ces réponses correspondaient à la réalité. Son audit RGPD était un château de cartes.
L'audit RGPD est devenu le nouveau "il faut que tu fasses ça". Un investisseur te le demande, un client B2B l'exige, ton avocat t'en parle. Mais quand tu poses la question "c'est quoi exactement ?", personne ne fait la même réponse. Voici la mienne.
Un audit RGPD, c'est quoi concrètement ?
C'est un état des lieux de ce que fait votre application avec les données personnelles de vos utilisateurs. Quelles données vous collectez, où elles vont, combien de temps vous les gardez, qui y a accès, et si tout ça est conforme au règlement européen.
À la sortie, vous obtenez des documents :
- Le registre des traitements — la cartographie de toutes les données personnelles que vous manipulez. C'est le premier document que la CNIL demande en cas de contrôle.
- La politique de confidentialité — le texte qui explique à vos utilisateurs ce que vous faites de leurs données.
- La politique cookies — idem pour les cookies et traceurs.
- Un rapport de conformité — la liste de ce qui va et ce qui ne va pas, avec les corrections à apporter.
Jusque-là, ça paraît simple. La confusion commence quand on se demande comment cet état des lieux est réalisé. Et c'est là que la différence entre un audit RGPD à 5 000 € et un à 129 € prend tout son sens.
Audit juridique vs audit technique : la distinction que personne ne fait
L'approche DPO : un questionnaire déclaratif
La majorité des "audits RGPD" sur le marché fonctionnent comme ça : un DPO (délégué à la protection des données) ou un cabinet juridique vous envoie un questionnaire. "Est-ce que vous chiffrez les données ?" — vous répondez oui. "Combien de sous-traitants traitent des données personnelles ?" — vous listez ceux que vous connaissez. "Quelle est votre durée de conservation ?" — vous donnez un chiffre.
Le DPO compile vos réponses, produit le registre, rédige la politique de confidentialité, et vous facture entre 2 000 et 5 000 euros.
Le problème : c'est déclaratif. Le DPO note ce que vous dites, pas ce qui existe dans votre code. C'est comme auditer un restaurant en demandant au patron s'il respecte les normes d'hygiène, sans jamais passer en cuisine.
Le fondateur dont je parlais en intro ? Son DPO avait inscrit "durée de conservation : 3 ans" dans le registre. J'ai regardé son code : aucun mécanisme de suppression automatique. Des comptes utilisateurs de 2019 encore en base avec toutes leurs données. La durée de conservation, ce n'est pas une ligne dans un document — c'est du code qui s'exécute. Ou pas.
L'approche technique : regarder le code
L'autre méthode — celle que je pratique — consiste à analyser directement le code source et l'infrastructure. Pas de questionnaire. Je regarde ce que l'application fait réellement.
Concrètement : quels SDK et services tiers sont intégrés (analytics, tracking, CRM, paiement), quelles données transitent vers chacun, comment le consentement est géré — est-ce que le bandeau cookies bloque vraiment les scripts avant acceptation ? —, comment les données sont stockées et protégées.
Le résultat est factuel. Le registre des traitements liste les traitements réels, pas ceux que vous pensez avoir.
Un cas concret : un fondateur me dit "on utilise Google Analytics et Stripe, c'est tout." J'ouvre le code de son app — générée avec Lovable. Je trouve Google Analytics et Stripe, mais aussi Sentry (monitoring d'erreurs, envoie des données techniques à un serveur US), Mixpanel (analytics comportemental), Hotjar (enregistrement de sessions), et un SDK Intercom (chat, stocke l'email et l'historique). 3 sous-traitants déclarés. 7 réels. Dont 4 qui envoient des données personnelles aux États-Unis sans que le fondateur le sache. C'est exactement le type de décalage qu'un audit de code révèle et qu'un questionnaire ne détectera jamais.
Combien coûte un audit RGPD — les vrais chiffres
Les fourchettes qu'on trouve en ligne — "entre 3 000 et 7 000 euros" — correspondent à l'audit DPO classique. C'est le prix du marché pour un cabinet juridique. Pour un grand groupe avec un DPO dédié et des centaines de traitements, ça monte à 15 000-25 000 euros.
Mais pour une startup ou une PME avec une application web ? Il y a d'autres options.
| Audit DPO classique | Audit technique spécialisé | Pack conformité haussaire.fr | |
|---|---|---|---|
| Méthode | Questionnaire déclaratif | Analyse du code source | Analyse du code source |
| Prix | 2 000 – 5 000 € | 1 500 – 3 000 € | 129 € |
| Délai | 2 – 8 semaines | 1 – 2 semaines | 4 jours ouvrés |
| Registre des traitements | Basé sur vos déclarations | Basé sur le code réel | Basé sur le code réel |
| Politique de confidentialité | Oui (template juridique) | Rarement incluse | Oui, générée depuis le code |
| Fiabilité du registre | Dépend de vos réponses | Élevée | Élevée |
| Idéal pour | ETI, grandes entreprises | Startups/PME tech | Startups/PME tech |
Mon dernier client sur le pack conformité avait une app React avec une API Node.js. J'ai identifié 7 traitements de données personnelles et 11 sous-traitants — dont 3 qu'il ignorait complètement, des SDK analytics intégrés automatiquement par l'outil de génération de code. Quatre documents livrés en 4 jours. 129 euros. Le même travail chez un DPO : minimum 2 000 euros. Et moins fiable, parce que le DPO n'aurait jamais vu ces SDK cachés.
Je ne dis pas que l'audit DPO est inutile. Pour une entreprise de 200 salariés avec des processus RH complexes, des sous-traitants multiples et des traitements papier, un DPO apporte une valeur que l'audit technique seul ne couvre pas. Mais pour une startup dont le produit est une application web — et c'est la majorité des cas que je traite — l'approche technique est plus fiable et considérablement moins chère.
Votre app a ces failles ?
Registre, politique de confidentialité et rapport de conformité issus de votre code.
Obtenir ma conformité RGPDLes documents que la CNIL attend vraiment
En cas de contrôle, la CNIL va vous demander principalement deux choses : votre registre des traitements et votre politique de confidentialité. Pas 47 documents, pas un audit de 200 pages. Deux documents.
Le registre, c'est la colonne vertébrale. Il liste chaque traitement de données personnelles : quelles données, pourquoi, sur quelle base légale, combien de temps, qui y accède, quels sous-traitants sont impliqués. Si ce registre est faux — ou pire, si vous n'en avez pas — vous êtes en infraction à l'article 30 du RGPD.
La politique de confidentialité, c'est ce que vos utilisateurs voient sur votre site. Elle doit refléter fidèlement le registre. Si votre politique dit "nous n'utilisons que des cookies strictement nécessaires" et que votre code charge Facebook Pixel et Hotjar avant le consentement, vous avez un problème.
Un fondateur m'a dit : "On a une politique de confidentialité sur le site, on est bons." J'ai regardé. La politique listait Google Analytics. Le code utilisait aussi Facebook Pixel, Hotjar et Intercom — aucun mentionné. Le bandeau cookies était purement décoratif : les scripts se chargeaient avant que l'utilisateur ne clique quoi que ce soit. Trois violations en une seule page.
Le kit complet pour être tranquille : registre des traitements, politique de confidentialité, politique cookies. Tous les trois cohérents entre eux et avec ce que fait réellement votre code. C'est ce que je livre dans le pack conformité RGPD.
Ce qu'un audit RGPD change concrètement
Soyons honnêtes : la plupart des startups ne se font pas contrôler par la CNIL. Les amendes à 4% du CA, c'est pour les gros. Non ?
Pas exactement.
Le scénario réaliste pour une startup : un utilisateur mécontent dépose une plainte sur le site de la CNIL. Ça prend 5 minutes. La CNIL vous écrit. Vous devez prouver votre conformité. Pas de registre. Pas de politique de confidentialité à jour. La CNIL vous met en demeure — et publie la mise en demeure sur son site.
Une mise en demeure publique, ça tue une levée de fonds. Ça fait capoter un deal B2B. Ça crée un résultat Google avec votre nom de boîte, "RGPD" et "CNIL" dans le titre. Pour longtemps.
Le vrai coût de la non-conformité, ce n'est pas l'amende. C'est le coût d'opportunité — le deal que vous ne signerez pas parce que votre prospect a googlé votre boîte.
Après un audit, vous savez exactement où vous en êtes. Vous avez les documents qui prouvent votre conformité. Et surtout, vous avez un registre qui correspond à ce que fait réellement votre application — pas à ce que vous croyez qu'elle fait.
J'ai vu des fondateurs découvrir lors de l'audit que leur app envoyait des données personnelles à des serveurs américains sans aucune base légale. D'autres qui ne savaient pas que leur outil de chat embarquait un traceur publicitaire. Ce n'est pas de la mauvaise volonté — c'est qu'entre le code généré par IA, les plugins et les SDK tiers, personne ne maîtrise vraiment la chaîne complète. L'audit RGPD, c'est le moment où vous reprenez le contrôle.
Un audit RGPD, ça peut être un classeur à 5 000 euros qui prend la poussière dans un Drive. Ou un état des lieux fiable de ce que fait votre application, livré en 4 jours pour 129 euros.
La différence tient à la méthode : déclaratif ou technique. Ce que vous pensez faire, ou ce que votre code fait réellement.
Si votre application collecte des données personnelles — et elle en collecte — le moment de vérifier, c'est maintenant. Pas parce qu'un avocat vous l'a dit. Parce que c'est la seule façon de savoir. Obtenir ma conformité RGPD →