RGPD pour SaaS B2B français — checklist complète sans mythes

Le mythe de la complexité RGPD

Si vous lancez un SaaS en France, vous avez probablement croisé des agences proposant des audits RGPD à 3 000-15 000€. Pour 80% des SaaS B2B early-stage, c'est inutile.

Cet article distingue ce qui est obligatoire de ce qui est du conseil cher. Sans bullshit, sans recommander d'audit. Juste ce qu'il faut faire.

⚠️ Disclaimer : je ne suis pas avocat. Cet article est un guide opérationnel basé sur les textes CNIL et la pratique de SaaS B2B français. Pour les cas limites, consultez un DPO certifié.

Étape 1 — Identifier les données personnelles

Le RGPD s'applique aux "données à caractère personnel" : tout ce qui permet d'identifier une personne physique, directement ou indirectement.

Dans un SaaS B2B typique :

// Données personnelles
const personalData = {
  user: ["email", "name", "phone", "ipAddress"],
  customer: ["contactPerson", "contactEmail"],
  employee: ["fullName", "email", "salary", "address"],
  // Indirect mais quand même PII
  metadata: ["lastLoginAt", "userAgent", "sessionId"],
};
 
// PAS des données personnelles (B2B)
const notPersonal = {
  company: ["companyName", "siret", "vatNumber"],
  // ⚠️ sauf "EI" ou auto-entrepreneur où companyName = personne physique
  invoice: ["amount", "description", "issueDate"],
};

Piège classique : le SIRET d'une auto-entreprise est une donnée personnelle (identifie un individu). Le SIRET d'une SARL ne l'est pas.

Étape 2 — Les 7 obligations vraiment obligatoires

1. Une politique de confidentialité accessible

Page /politique-de-confidentialite listant :

• Quelles données vous collectez
• Pourquoi (finalité)
• Combien de temps vous les gardez (durée de conservation)
• Avec qui vous les partagez (sous-traitants)
• Comment les exporter / supprimer

Template minimal :

## Données collectées
 
Lors de votre utilisation de {App}, nous collectons :
 
- **Données d'identification** : email, nom, prénom (finalité : auth, support)
- **Données techniques** : IP, user-agent, logs (finalité : sécurité, debug)
- **Données business** : ce que vous saisissez dans l'app (finalité : exécution du contrat)
 
## Durée de conservation
 
- Compte actif : tant que vous utilisez le service
- Compte inactif : 3 ans après dernière connexion
- Logs techniques : 6 mois
- Données de facturation : 10 ans (obligation comptable)
 
## Vos droits
 
Vous pouvez demander à tout moment :
 
- L'accès à vos données (export JSON)
- La rectification
- La suppression
- La portabilité (export structuré)
 
Contact : dpo@yoursaas.com

2. Le consentement aux cookies non essentiels

// Pattern HeartCo — consent banner
const consentTypes = {
  essential: { required: true, default: true }, // session, CSRF
  analytics: { required: false, default: false }, // Vercel Analytics, Plausible
  marketing: { required: false, default: false }, // Meta Pixel, Google Ads
};

Ce que beaucoup ratent : les analytics ne sont PAS "essentiels". Plausible et Vercel Analytics doivent être désactivés par défaut, ou utiliser leur mode "cookieless" qui ne nécessite pas de consentement.

3. Le registre des activités de traitement

Article 30 RGPD. Un Google Doc ou un fichier compliance/registre-traitement.md dans votre repo suffit.

Contenu minimal pour chaque traitement :

## Authentification utilisateurs
 
- **Finalité** : permettre l'accès au service
- **Catégories de données** : email, mot de passe haché
- **Base légale** : exécution du contrat
- **Destinataires** : équipe HeartCo (admin only)
- **Sous-traitants** : Supabase (hébergement DB), Vercel (hébergement app)
- **Conservation** : 3 ans après dernière connexion
- **Transferts hors UE** : non

4. Le droit à l'export et à la suppression

Implémentation tRPC :

// src/server/api/routers/rgpd.ts
export const rgpdRouter = createTRPCRouter({
  exportMyData: protectedProcedure.mutation(async ({ ctx }) => {
    const userId = ctx.session.user.id;
 
    const data = {
      user: await ctx.db.user.findFirst({ where: { id: userId } }),
      organizations: await ctx.db.organization.findMany({
        where: { members: { some: { userId } } },
      }),
      invoices: await ctx.db.invoice.findMany({
        where: { createdById: userId },
      }),
      // ... toutes les tables liées à l'utilisateur
    };
 
    // Email Resend avec le JSON en pièce jointe
    await resend.emails.send({
      to: ctx.session.user.email,
      subject: "Vos données HeartCo",
      attachments: [
        {
          filename: "export.json",
          content: Buffer.from(JSON.stringify(data, null, 2)),
        },
      ],
      // ... template React Email
    });
 
    return { sent: true };
  }),
 
  deleteMyAccount: protectedProcedure
    .input(z.object({ confirmEmail: z.string().email() }))
    .mutation(async ({ ctx, input }) => {
      if (input.confirmEmail !== ctx.session.user.email) {
        throw new TRPCError({ code: "BAD_REQUEST" });
      }
 
      // Soft delete + anonymisation
      await ctx.db.user.update({
        where: { id: ctx.session.user.id },
        data: {
          email: `deleted-${ctx.session.user.id}@deleted.local`,
          name: "Utilisateur supprimé",
          deletedAt: new Date(),
        },
      });
    }),
});

Délai légal : un mois maximum pour répondre. Pour un SaaS, automatisez : 1 clic dans /dashboard/parametres/rgpd et l'utilisateur reçoit son export par email en < 5 minutes.

5. La sécurité des données (Article 32)

// Mesures techniques minimales
const securityMeasures = {
  encryption: {
    inTransit: "TLS 1.3 (Vercel par défaut)",
    atRest: "AES-256 (Supabase par défaut)",
    passwords: "bcrypt rounds >= 12",
  },
  access: {
    multiTenant: "Prisma $extends auto-scope",
    rbac: "Matrix de permissions",
    audit: "Log de toutes les actions admin",
  },
  backup: {
    frequency: "quotidien",
    retention: "30 jours",
    location: "UE (Supabase)",
  },
};

6. Les contrats sous-traitants (DPA)

Article 28 RGPD. Pour chaque sous-traitant qui traite des données pour vous, vous devez signer un Data Processing Agreement.

Sous-traitants typiques d'un SaaS et leurs DPA :

7. La notification de violation (Article 33)

Si une violation de données survient, vous avez 72h pour notifier la CNIL via notifications.cnil.fr.

Préparez un template d'incident-response :

# Incident #X — Date
 
## Faits
 
- Quoi : description de la fuite
- Quand : timestamp détection
- Combien : nombre de personnes concernées
- Quelles données : email + ... (pas mot de passe haché si bcrypt)
 
## Actions immédiates
 
- Patch déployé : SHA + heure
- Tokens révoqués / sessions invalidées
- Communication utilisateurs : email + statut page
 
## Mesures correctives
 
- Test ajouté : ...
- Process modifié : ...

Ce qui n'est PAS obligatoire (mais qu'on vous vendra)

❌ DPO certifié — Seulement obligatoire si vous traitez des données sensibles à grande échelle (santé, justice, surveillance). Pour 99% des SaaS B2B, vous pouvez désigner un référent RGPD interne.

❌ Audit RGPD 5 000€ — Inutile en early-stage. Faites votre auto-évaluation avec la check-list CNIL (gratuite).

❌ Hébergement HDS — Seulement si vous traitez des données de santé.

❌ ISO 27001 — Pas une obligation RGPD. C'est de la certification qui rassure les grands comptes, pas une exigence légale.

Le scénario CNIL

Si la CNIL contrôle votre SaaS :

1. Vous recevez un courrier officiel ou un email
2. Vous avez ~30 jours pour répondre avec votre documentation
3. La CNIL apprécie en fonction de votre bonne foi et de votre proportionnalité

Ce qui vous protège :

• Un registre de traitement à jour (même en markdown dans Git)
• Une politique de confidentialité claire
• Le droit à l'export et suppression implémentés
• Les DPA des sous-traitants signés
• Une notification d'incident < 72h (si applicable)

Vous n'avez PAS besoin d'une certification ISO, d'un audit externe, ou d'un DPO à 80k€/an pour être en règle. Vous avez besoin d'être organisé.

Checklist condensée

• Politique de confidentialité publiée à /politique-de-confidentialite
• Bandeau cookies avec consentement granulaire (essentiels par défaut, autres opt-in)
• Registre de traitement à jour (compliance/registre.md dans le repo)
• Bouton "Exporter mes données" dans le dashboard utilisateur
• Bouton "Supprimer mon compte" avec confirmation email
• DPA signés avec tous les sous-traitants
• Conservation des logs limitée (6 mois max pour les logs techniques)
• TLS partout (Vercel le fait), bcrypt rounds >=12
• Multi-tenant isolation auditable (tests Vitest)
• Template d'incident-response prêt
• Contact dpo@ ou rgpd@ actif

Conclusion

Le RGPD pour un SaaS B2B français, c'est 2 jours de setup correct, pas 6 mois de paperasse. Une fois en place, ça se maintient en 1h/mois.

Dans HeartCo, ces patterns sont câblés par défaut : page /politique-de-confidentialite éditable, route /dashboard/parametres/rgpd avec export+delete, multi-tenant auto-scopé, cookies bannière conforme. Vous arrivez en production en règle.