La semaine dernière, un fondateur m'a dit : "On est conforme RGPD, on a mis un bandeau cookies." Son app stockait des données de santé en clair sur un serveur américain. Sans registre des traitements. Sans politique de confidentialité à jour.
Il ne mentait pas. Il pensait sincèrement être en règle. Et c'est le cas de 90% des startups que j'audite.
Le problème n'est pas la mauvaise volonté. C'est que les articles sur la conformité RGPD sont écrits par des juristes, pour des juristes. Vous lisez "principe de minimisation des données" ou "base légale du traitement" et vous décrochez. Normal.
Je suis CTO et auditeur technique. Pas juriste. Mon boulot, c'est d'analyser du code et de traduire ce charabia en décisions concrètes. Voici les 6 obligations RGPD, en langage de dirigeant.
Pourquoi vous n'y comprenez rien (et c'est pas votre faute)
Le RGPD fait 88 pages. 99 articles. Rédigé par des eurocrates pour d'autres eurocrates.
Le résultat : vous tapez "conformité RGPD" dans Google, vous tombez sur des articles qui vous parlent de "licéité du traitement", de "principe d'accountability" et de "privacy by design". Vous refermez l'onglet. Vous vous dites que vous verrez ça plus tard.
Sauf que "plus tard", ça arrive vite. Un grand compte vous demande votre registre des traitements avant de signer. Un utilisateur mécontent dépose une plainte CNIL. Un investisseur fait sa due diligence et découvre que vos CGU datent de 2019.
J'ai vu ces trois scénarios cette année. À chaque fois, le fondateur avait la même réaction : "Mais je pensais qu'on était conforme."
Être conforme, ce n'est pas avoir un bandeau cookies. C'est 6 choses précises.
Les 6 obligations RGPD, traduites en clair
1. Tenir un registre des traitements
Ce que dit le texte : documenter tous les traitements de données personnelles (article 30).
Ce que ça veut dire pour vous : vous devez avoir un document qui liste toutes les données personnelles que votre app collecte. Nom, email, adresse IP, géolocalisation, données de paiement — tout. Pour chaque donnée : pourquoi vous la collectez, combien de temps vous la gardez, qui y a accès.
Ce que ça coûte de ne pas le faire : c'est le premier document que la CNIL demande en cas de contrôle. Pas de registre = sanction quasi-automatique. Et c'est aussi ce qu'un grand compte vous demandera avant de signer un contrat B2B.
Un de mes clients développe un outil RH. Un groupe du CAC 40 lui demande son registre avant de finaliser un contrat à 120K€/an. Il n'en avait pas. Le deal est tombé à l'eau en 48h.
Le piège : un registre des traitements rempli "à la main" par quelqu'un qui n'a pas regardé votre code ne vaut rien. Il déclare ce que vous pensez faire, pas ce que votre app fait réellement.
2. Recueillir un consentement valide
Ce que dit le texte : obtenir le consentement libre, spécifique, éclairé et univoque (article 6 et 7).
Ce que ça veut dire pour vous : quand vous collectez des données qui ne sont pas strictement nécessaires au service (newsletter, analytics, marketing), l'utilisateur doit dire oui explicitement. Pas de case pré-cochée. Pas de "en continuant vous acceptez". Un vrai bouton, un vrai choix.
Ce que ça coûte de ne pas le faire : la CNIL a infligé 150 millions d'euros à Google et 60 millions à Facebook en 2022, justement pour ça. Pour une PME, les amendes sont plus modestes (5K-50K€) mais le signal est clair.
Point important : le consentement ne concerne pas tout. Pour exécuter un contrat (livrer une commande, fournir un service), vous n'avez pas besoin de consentement explicite. C'est la "base légale du contrat". Ne tombez pas dans l'excès inverse de tout demander — ça dégrade l'expérience utilisateur pour rien.
3. Répondre aux droits des personnes
Ce que dit le texte : droit d'accès, de rectification, d'effacement, de portabilité (articles 15 à 20).
Ce que ça veut dire pour vous : si un utilisateur vous demande "quelles données avez-vous sur moi ?", vous avez 30 jours pour répondre. S'il vous dit "supprimez tout", pareil. S'il veut récupérer ses données pour aller chez un concurrent, vous devez les fournir dans un format exploitable.
Ce que ça coûte de ne pas le faire : une plainte d'un seul utilisateur suffit à déclencher un contrôle CNIL. J'ai vu une startup de 15 personnes se faire contrôler parce qu'un ex-employé licencié a exercé son droit d'accès et n'a pas reçu de réponse dans les 30 jours. 25K€ d'amende, 6 mois de stress.
En pratique, ça veut dire que votre app doit permettre techniquement d'exporter et supprimer les données d'un utilisateur. Si c'est codé en dur et dispersé dans 15 tables sans lien, vous allez galérer le jour J.
4. Sécuriser les données
Ce que dit le texte : mesures techniques et organisationnelles appropriées (article 32).
Ce que ça veut dire pour vous : chiffrement des données sensibles, HTTPS partout, mots de passe hashés (pas en clair, pas en MD5), accès restreints, logs d'accès. Le minimum qu'un développeur compétent met en place.
Ce que ça coûte de ne pas le faire : en cas de fuite, l'amende est calculée sur votre degré de négligence. Si vous stockez des mots de passe en clair en 2026, c'est de la négligence caractérisée. La CNIL ne pardonne pas.
80% des problèmes de conformité RGPD que je trouve en audit sont des problèmes de sécurité dans le code. Pas des problèmes de documents manquants. Des tokens d'API en dur dans le frontend. Des données personnelles dans les logs. Des backups non chiffrées. C'est technique, mais c'est là que se joue la vraie conformité.
5. Notifier les violations en 72h
Ce que dit le texte : notification à la CNIL dans les 72 heures suivant la découverte d'une violation (article 33).
Ce que ça veut dire pour vous : si vos données fuitent (hack, erreur humaine, accès non autorisé), vous avez 3 jours pour prévenir la CNIL. Et si le risque est élevé pour les personnes concernées, vous devez aussi prévenir les utilisateurs.
Ce que ça coûte de ne pas le faire : cacher une fuite, c'est une circonstance aggravante. Uber a été condamné à 400 000€ en France — non pas pour la fuite elle-même, mais pour l'avoir cachée pendant un an.
Concrètement : vous avez besoin d'un système de monitoring qui vous alerte quand quelque chose d'anormal se passe. Et d'une procédure écrite qui dit "qui fait quoi" en cas de crise. Rien d'extraordinaire, mais il faut y avoir pensé avant.
6. Encadrer vos sous-traitants
Ce que dit le texte : contrat avec vos sous-traitants qui traite des données pour vous (article 28).
Ce que ça veut dire pour vous : votre hébergeur, votre outil d'emailing, votre CRM, votre outil analytics — tous ceux qui touchent aux données de vos utilisateurs sont vos "sous-traitants" au sens RGPD. Vous devez avoir un contrat (ou DPA — Data Processing Agreement) avec chacun.
Ce que ça coûte de ne pas le faire : si Mailchimp fuite les données de vos clients et que vous n'avez pas de DPA en place, c'est votre responsabilité. Pas celle de Mailchimp.
La bonne nouvelle : la plupart des gros outils (Stripe, AWS, Google Workspace) ont déjà des DPA disponibles. Il suffit de les signer. Le vrai problème, c'est les petits prestataires, les freelances qui accèdent à votre base, les outils installés en 5 minutes par un dev sans vérifier.
Le tableau récapitulatif
| # | Obligation | Ce que ça veut dire | Coût de la non-conformité |
|---|---|---|---|
| 1 | Registre des traitements | Lister toutes les données collectées, pourquoi, combien de temps | Contrats B2B perdus + premier document demandé par la CNIL |
| 2 | Consentement valide | Demander un vrai "oui" pour les données non essentielles | 5K-150M€ d'amende selon la taille |
| 3 | Droits des personnes | Répondre en 30 jours aux demandes d'accès/suppression | Une plainte = un contrôle potentiel |
| 4 | Sécurité des données | Chiffrement, accès restreints, pas de données en clair | Amende aggravée en cas de négligence |
| 5 | Notification 72h | Prévenir la CNIL en 3 jours si fuite | Circonstance aggravante si vous cachez |
| 6 | Encadrement sous-traitants | DPA avec chaque outil qui touche vos données | Responsable de la fuite de vos prestataires |
Votre app a ces failles ?
Registre, politique de confidentialité et rapport de conformité issus de votre code.
Obtenir ma conformité RGPDCe qui coûte vraiment cher, ce n'est pas l'amende
Les médias adorent parler des amendes à plusieurs millions. Ça fait des bons titres. Mais pour une startup de 10-50 personnes, le vrai risque n'est pas là.
Le vrai coût de la non-conformité :
Les deals B2B qui ne se signent pas. De plus en plus de grands comptes exigent un registre des traitements et une preuve de conformité avant de contractualiser. Pas de documents, pas de contrat. J'ai vu des startups perdre des deals à 6 chiffres pour ça.
La due diligence qui bloque une levée. Les fonds regardent la conformité RGPD pendant leur due diligence. Un trou béant sur ce sujet, c'est un red flag qui ralentit — ou tue — votre levée.
La refactorisation d'urgence. Une startup que j'ai auditée avait attendu 2 ans avant de s'occuper du RGPD. Résultat : l'architecture de données ne permettait pas de supprimer un utilisateur proprement, les données étaient éparpillées dans 12 tables sans lien logique. Mettre ça en conformité a coûté 4 fois ce que ça aurait coûté au départ.
Le RGPD n'est pas un sujet juridique. C'est un sujet d'architecture. Et plus vous attendez, plus c'est cher à corriger.
Comment savoir où vous en êtes
Six questions. Répondez honnêtement :
- Avez-vous un registre des traitements à jour (pas un template vierge) ?
- Vos formulaires demandent-ils un consentement explicite pour les données non essentielles ?
- Pouvez-vous techniquement exporter et supprimer toutes les données d'un utilisateur ?
- Les données sensibles sont-elles chiffrées au repos et en transit ?
- Avez-vous une procédure écrite en cas de fuite de données ?
- Avez-vous un DPA signé avec chaque prestataire qui accède aux données ?
Si vous avez répondu "non" ou "je ne sais pas" à 2 questions ou plus, vous n'êtes pas conforme. Pas de panique — c'est le cas de la majorité des startups. Mais maintenant, vous savez ce qu'il y a à faire.
Le point de départ : un audit RGPD technique qui regarde ce que votre code fait réellement, pas ce que vous pensez qu'il fait. C'est la différence entre un registre déclaratif (qui ne vaut rien en cas de contrôle) et un registre qui reflète la réalité de votre application.
Six obligations. Pas 99 articles. Commencez par là.