Checklist sécurité / privacy / RGPD minimum pour ton SaaS

Introduction : Pourquoi la compliance RGPD n'est pas optionnelle

Si ton app ou ton SaaS collecte des données d'utilisateurs européens — emails, noms, données d'usage, cookies analytics — tu es soumis au RGPD (Règlement Général sur la Protection des Données), même en tant que solopreneur ou startup de 2 personnes. Les sanctions vont jusqu'à 20 M€ ou 4 % du chiffre d'affaires annuel selon la CNIL, mais surtout, la non-conformité expose tes utilisateurs et détruit la confiance.

La bonne nouvelle : tu n'as pas besoin d'un Data Protection Officer (DPO) ni d'un cabinet juridique à 10 000 € pour être "minimum viable compliant". Cet article te donne une checklist actionnable en 12 étapes, pensée pour un indie dev qui veut lancer vite tout en respectant les bases légales. Chaque étape inclut ce qu'il faut faire concrètement, les outils low-cost ou gratuits à utiliser, et les erreurs courantes à éviter.

Checklist RGPD minimum viable : 12 étapes essentielles

1. Data mapping (cartographie des données)

Ce qu'il faut faire :

Liste toutes les données personnelles que tu collectes, où elles sont stockées, combien de temps tu les gardes, et avec qui tu les partages. C'est la base de toute stratégie RGPD. Sans cartographie, impossible de répondre aux demandes d'accès ou de suppression.

Données personnelles typiques d'un micro-SaaS ou app :

• Identité : nom, email, pseudo
• Connexion : mot de passe haché, tokens OAuth, adresse IP
• Usage : logs d'activité, événements analytics, historique d'achats
• Paiement : détails CB (si tu ne passes pas par Stripe ou PayPal, ce qui est rare)
• Tracking web : cookies analytics (Google Analytics, Plausible…), cookies de session

Outil recommandé :

Google Sheet simple avec colonnes : "Type de donnée", "Finalité", "Stockage (DB/service tiers)", "Durée de rétention", "Partage avec qui ?".

Erreur courante : Oublier les données collectées par des services tiers (analytics, support client type Intercom, email transactionnel type SendGrid). Tu restes responsable de leurs pratiques aussi.

2. Établir la base légale pour chaque traitement

Ce qu'il faut faire :

Le RGPD exige que chaque traitement de données ait une base légale. Les 3 principales pour un micro-SaaS :

1. Contrat : données nécessaires pour fournir ton service (email pour créer le compte, historique d'achats pour gérer l'abonnement)
2. Intérêt légitime : analytics d'usage pour améliorer le produit, logs de sécurité
3. Consentement : marketing (newsletter), cookies non essentiels (Google Analytics, pixels publicitaires)

Action concrète :

Dans ton data mapping (étape 1), ajoute une colonne "Base légale" et documente-la pour chaque type de données. La CNIL propose des guides sectoriels pour t'aider à choisir.

Erreur courante : Utiliser "consentement" pour tout. Le consentement doit être libre, spécifique, éclairé, univoque. Si tu bloques l'accès au service sans consentement aux cookies analytics, ce n'est pas légal. Utilise plutôt "intérêt légitime" pour les analytics essentiels.

3. Rédiger une Privacy Policy (Politique de confidentialité) claire

Ce qu'il faut faire :

Ta privacy policy doit expliquer en langage simple :

• Quelles données tu collectes et pourquoi
• Base légale pour chaque traitement
• Avec qui tu partages les données (sous-traitants : Stripe, AWS, Vercel, analytics…)
• Combien de temps tu gardes les données
• Comment les utilisateurs peuvent exercer leurs droits (accès, rectification, suppression, opposition)
• Contact pour les questions privacy (email dédié type privacy@tonsite.com)

Outils recommandés :

• Générateurs gratuits : Termly, iubenda (freemium), PrivacyPolicies.com
• Important : personnalise le template généré, ne copie-colle pas un texte générique qui ne correspond pas à tes pratiques réelles

Lien obligatoire :

Privacy policy accessible depuis toutes les pages (footer), formulaire d'inscription, et cookie banner.

4. Implémenter un cookie banner RGPD-compliant

Ce qu'il faut faire :

Si tu utilises des cookies non essentiels (analytics, publicité, tracking tiers), tu dois :

• Afficher un banner avant le dépôt des cookies
• Proposer "Accepter" ET "Refuser" (ou "Personnaliser") de manière équivalente (pas de dark pattern type bouton "Refuser" caché)
• Bloquer les scripts tiers (Google Analytics, Meta Pixel…) jusqu'à ce que l'utilisateur consente
• Permettre de retirer son consentement facilement (bouton "Gérer mes cookies" dans le footer)
• Enregistrer la preuve du consentement (date, heure, version du banner)

Outils recommandés (gratuits ou low-cost) :

• CookieYes : gratuit jusqu'à 100 pages vues/mois, auto-blocking des scripts
• Axeptio : français, design soigné, gratuit jusqu'à 10k vues/mois
• Tarteaucitron.js : open-source, auto-hébergé, gratuit mais demande un peu de dev

Erreur courante : Utiliser Google Analytics sans banner, ou avec un banner "Accepter" seulement. C'est non conforme et peut entraîner des amendes. Le guide CNIL sur les cookies est très clair là-dessus.

5. Configurer la rétention des données (data retention)

Ce qu'il faut faire :

Tu ne peux pas garder les données personnelles indéfiniment. Définis des durées de rétention raisonnables :

• Comptes actifs : tant que l'utilisateur a un compte actif
• Comptes inactifs : suppression après 12-24 mois sans activité (envoie un email de rappel avant)
• Logs / analytics : 6-12 mois maximum
• Données de paiement : selon obligations comptables (généralement 10 ans pour les factures, mais pas les détails CB → Stripe gère ça)

Action concrète :

Mets en place un cron job mensuel qui :

• Anonymise ou supprime les comptes inactifs > X mois
• Purge les logs analytics > Y mois

Outil :

Script backend simple (Node.js, Python…) ou feature de ton provider (ex. : PostgreSQL DELETE FROM users WHERE last_activity < NOW() - INTERVAL '24 months').

6. Gérer les demandes d'accès et de suppression (DSAR)

Ce qu'il faut faire :

Les utilisateurs ont le droit de :

• Accéder à leurs données (export complet)
• Rectifier des données incorrectes
• Supprimer leur compte et toutes leurs données ("droit à l'oubli")
• S'opposer à certains traitements (ex. : marketing)
• Portabilité : recevoir leurs données dans un format structuré (JSON, CSV)

Délai légal : 30 jours maximum selon le RGPD article 12.

Action concrète :

• Ajoute dans ton app un bouton "Télécharger mes données" (export JSON/CSV automatique)
• Ajoute un bouton "Supprimer mon compte" avec workflow de confirmation (email de validation, délai de grâce 7 jours, puis suppression définitive)
• Si tu reçois une demande par email, réponds vite et documente-la (trace écrite)

Erreur courante : Oublier de supprimer les données dans les backups. Anonymise les backups anciens ou documente que les backups sont purgés après X jours.

7. Sécuriser les données (encryption, accès, authentification)

Ce qu'il faut faire :

Le RGPD impose des mesures techniques et organisationnelles pour protéger les données.

Checklist technique minimum :

• HTTPS partout (certificat SSL/TLS gratuit via Let's Encrypt, Cloudflare, Vercel…)
• Mots de passe hachés (bcrypt, Argon2 — jamais en clair)
• Chiffrement des données sensibles au repos (base de données chiffrée, clés dans un secret manager type Doppler, Infisical)
• Authentification à deux facteurs (2FA) pour les comptes admin/team
• Contrôle d'accès : seuls les membres de l'équipe qui en ont besoin accèdent aux données utilisateurs (principe du moindre privilège)
• Backups chiffrés et testés régulièrement

Outils recommandés :

• Auth : Supabase Auth, Clerk, Auth0 (tous gèrent 2FA, OAuth, tokens sécurisés)
• Secrets : Doppler (gratuit pour petites équipes), Infisical (open-source)
• DB : PostgreSQL avec encryption at rest (proposé par défaut sur Supabase, Neon, AWS RDS…)

8. Signer des Data Processing Agreements (DPA) avec tes sous-traitants

Ce qu'il faut faire :

Chaque service tiers qui traite des données personnelles pour ton compte (Stripe, SendGrid, Vercel, analytics…) doit signer un DPA (Data Processing Agreement).

Bonne nouvelle : La plupart des SaaS sérieux proposent un DPA standard dans leurs conditions (cherche "DPA" ou "GDPR addendum" dans leur documentation).

Action concrète :

• Stripe, AWS, Vercel, Supabase, PostHog, Plausible → DPA disponible en ligne, parfois auto-signé via ton dashboard
• Liste tous tes sous-traitants dans ta privacy policy

Erreur courante : Utiliser un service tiers (ex. : outil analytics obscur, hébergeur hors UE sans garanties) sans vérifier s'il est RGPD-compliant. Tu restes responsable même si c'est lui qui collecte les données.

9. Décider si tu as besoin d'un DPO (Data Protection Officer)

Ce qu'il faut faire :

Tu dois nommer un DPO si :

• Tu es une autorité publique
• Ton activité principale implique un suivi régulier et systématique à grande échelle (ex. : adtech, surveillance)
• Tu traites des données sensibles à grande échelle (santé, religion, orientation sexuelle…)

Pour la plupart des micro-SaaS et apps mobiles standard : DPO non obligatoire selon la CNIL.

Alternative : Tu peux désigner un "responsable privacy" interne (toi-même au début) et indiquer un contact privacy dans ta policy. Si ton app grossit (> 100k users, levée de fonds, données sensibles), envisage un DPO externe (cabinets spécialisés proposent des forfaits à partir de 200 €/mois en part-time).

10. Mettre en place un registre des traitements

Ce qu'il faut faire :

Le RGPD demande un registre des activités de traitement (qui traite quoi, pourquoi, où, pour combien de temps).

Exemption pour petites structures :

Si tu as < 250 employés ET que tes traitements ne sont ni à risque ni réguliers, tu es exempté. Mais c'est une bonne pratique de le faire quand même (reprend ton data mapping de l'étape 1, c'est déjà 80 % du travail).

Template gratuit : La CNIL propose des modèles de registre en PDF/Excel sur son site.

11. Prévoir une procédure en cas de data breach (fuite de données)

Ce qu'il faut faire :

Si tu subis une fuite de données (hack, erreur de config qui expose une DB…), le RGPD impose de :

• Notifier l'autorité de contrôle (CNIL en France) sous 72h si la fuite présente un risque pour les droits et libertés des personnes
• Notifier les utilisateurs concernés si le risque est élevé (ex. : mots de passe en clair exposés, données bancaires…)

Action concrète :

Documente un plan de réponse incident simple :

1. Détection (alertes monitoring, rapport utilisateur)
2. Containment : isoler la faille, couper l'accès si nécessaire
3. Investigation : quelle donnée a fuité, combien d'users impactés
4. Notification : si risque, email CNIL + users sous 72h
5. Remédiation : patch, audit post-mortem, communication transparente

Erreur courante : Cacher une fuite ou tarder à notifier. Risque de sanction aggravée. La transparence est toujours la meilleure stratégie.

12. Tester et auditer régulièrement

Ce qu'il faut faire :

La compliance RGPD n'est pas "one-shot". Teste régulièrement :

• Ton cookie banner bloque-t-il bien les scripts avant consentement ? (test en navigation privée, vérifie dans les DevTools Network)
• Les demandes de suppression de compte fonctionnent-elles (données bien purgées de la DB et des backups) ?
• Tes DPA avec sous-traitants sont-ils à jour ?
• Ta privacy policy reflète-t-elle tes pratiques actuelles (nouveaux services tiers, nouvelles features) ?

Fréquence recommandée :

• Audit léger tous les 3 mois
• Audit complet + mise à jour docs tous les 6-12 mois

Outil recommandé :

Checklist récurrente dans Notion, Trello, ou Linear avec tâches assignées. Automatise les rappels pour ne rien oublier.

Outils & ressources pour aller plus loin

Générateurs de privacy policy & cookie banners

• Termly (freemium)
• iubenda (payant, très complet)
• CookieYes (gratuit jusqu'à 100 pages/mois)
• Axeptio (français, design soigné)

Templates & guides officiels

• CNIL (France) : guides sectoriels, modèles de registre, FAQ RGPD
• ICO (UK) : checklists pour small businesses (en anglais, très pédagogique)
• EDPB (European Data Protection Board) : guidelines officielles sur le consentement, les cookies, etc.

Conseillers / audits externes (si besoin)

• Cabinets DPO externalisés : 200-500 €/mois pour PME/startup
• Avocats spécialisés data privacy pour revue de ta privacy policy (budget ~1 000-2 000 € one-time)

Conclusion : compliance good enough pour lancer sereinement

Tu n'as pas besoin d'un budget juridique de 50 000 € pour être RGPD-compliant en tant que solo dev ou petite équipe. En appliquant cette checklist en 12 étapes — data mapping, bases légales, privacy policy, cookie banner, rétention, DSAR, sécurité, DPA, et procédure incident — tu couvres 90 % des obligations essentielles.

Le RGPD n'est pas un frein, c'est un cadre de confiance : des utilisateurs informés et protégés sont des utilisateurs plus engagés. Commence simple, documente au fur et à mesure, et ajuste quand ton produit grandit. L'essentiel est d'être transparent, réactif et de bonne foi. Les autorités de contrôle comme la CNIL sont généralement indulgentes avec les petites structures qui font des efforts.

Résumé : ce qu'il te faut vraiment pour être minimum viable compliant

• Privacy policy claire et à jour (générateur gratuit OK)
• Cookie banner avec opt-in/opt-out et script blocking (CookieYes, Axeptio…)
• Bouton "Supprimer mon compte" fonctionnel dans ton app
• HTTPS partout, mots de passe hachés, backups chiffrés
• DPA signés avec Stripe, AWS, analytics, email provider
• Contact privacy visible (email type privacy@tonsite.com)
• Plan de réponse incident documenté (même simple)

Avec ça, tu lances en toute légalité et tu dors tranquille. Le reste (DPO, registre exhaustif, audit annuel par un cabinet…) viendra si tu scales. En attendant, focus sur ton produit et tes users. La compliance RGPD, c'est avant tout du bon sens et du respect.

Les ressources officielles pour approfondir :

• Guide RGPD pour les startups par la CNIL
• Checklist GDPR par Termly
• Documentation cookies CNIL
• Templates DPA par iubenda

Lance, mesure, ajuste. La compliance vient en marchant.