Le blog

RGPD23 juillet 2026 · 6 min de lecture

Fuite de données : la règle des 72h de la CNIL en clair

Ta base a fuité ? Tu as 72h pour notifier la CNIL (article 33 RGPD). Ce qui compte comme violation, quand le délai démarre, comment notifier, et ce que tu risques si tu ne le fais pas.

Fuite de données : la règle des 72h de la CNIL en clair

Ta base Supabase était ouverte. Quelqu'un a pu la lire. À partir du moment où tu l'apprends, la loi te donne 72 heures pour prévenir la CNIL. C'est l'article 33 du RGPD, et il s'applique à toi comme à n'importe quelle entreprise, quelle que soit ta taille.

Ça a l'air violent dit comme ça. En vrai, la procédure est plus simple qu'elle en a l'air, et la connaître à l'avance t'évite de paniquer le jour où ça arrive. Sur les apps que je scanne, la base ouverte est de loin la fuite la plus courante : environ 70 % des apps Lovable que je passe au scanner ont le verrou de leur base désactivé. Voilà ce qui compte comme fuite, quand les 72 heures démarrent vraiment, comment notifier, et ce qui se passe si tu ne le fais pas.

C'est quoi une violation de données, au juste

Une violation de données, ce n'est pas seulement un hacker qui force une porte. C'est, au sens de la loi, toute perte de maîtrise sur des données personnelles : une fuite, une destruction, une modification, ou un accès non autorisé.

Le piège, c'est le mot « accès ». Beaucoup pensent qu'il faut une preuve que quelqu'un a volé les données. Faux. Si ta base d'emails était lisible par n'importe qui pendant deux semaines, tu as perdu la maîtrise de ces données. Le fait que tu n'aies pas de preuve d'un vol ne t'exonère pas : tu ne peux pas prouver que personne n'a regardé non plus.

Une base Supabase avec le RLS désactivé, exposée via une clé publique, coche exactement cette case. Les données étaient accessibles sans autorisation. C'est une violation, même sans incident spectaculaire.

Quand est-ce que les 72 heures commencent ?

Pas au moment de la fuite. Au moment où tu en prends connaissance. La loi parle du moment où tu as « connaissance » de la violation, pas du moment où elle s'est produite.

Concrètement : ta base était ouverte depuis un mois, tu le découvres un mardi à 14h en lançant un scan ou en regardant tes logs. Ton compteur démarre là, mardi 14h. Tu as jusqu'au vendredi 14h pour notifier la CNIL. Et ce sont des heures calendaires, pas des heures ouvrées : le week-end compte.

Si tu dépasses les 72 heures, tu peux quand même notifier, mais tu dois expliquer pourquoi tu es en retard. Mieux vaut une notification tardive et honnête que pas de notification du tout.

Comment notifier la CNIL, concrètement

La CNIL met à disposition un téléservice de notification sur son site. Tu remplis un formulaire en ligne, tu n'as pas besoin d'un avocat pour ça. Ce qu'elle te demande, en clair :

  • Ce qui s'est passé. La nature de la violation (une base laissée accessible, par exemple).
  • Les données concernées. Quels types (emails, mots de passe, données de paiement) et environ combien de personnes.
  • Les conséquences probables pour les personnes concernées.
  • Ce que tu as fait pour corriger et limiter les dégâts (fermé la base, régénéré les clés, etc.).

Si tu n'as pas tout de suite toutes les infos, tu peux notifier en deux temps : une première notification pour tenir le délai, puis un complément quand tu en sais plus. La CNIL préfère ça à un silence.

Un conseil de terrain : avant de notifier, ferme la fuite. Une notification qui dit « la base est toujours ouverte » ne joue pas en ta faveur. Vérifie et referme d'abord ton RLS, puis tu déclares.

Quand tu dois aussi prévenir tes utilisateurs

Il y a une deuxième obligation, souvent oubliée : l'article 34. Si la fuite présente un « risque élevé » pour les personnes, tu dois aussi les prévenir elles, directement, et sans délai injustifié.

Un risque élevé, c'est par exemple des mots de passe, des données bancaires, des données de santé, ou tout ce qui peut servir à usurper une identité ou à arnaquer quelqu'un. Une simple liste d'emails, c'est un risque plus faible, mais dès qu'il y a du sensible, tu préviens les gens.

C'est la partie qui fait mal à l'ego, parce qu'il faut écrire à tes propres utilisateurs pour leur dire que leurs données ont fuité. Mais c'est aussi ce qui fait la différence entre un fondateur qui assume et un fondateur qui se planque. Les gens pardonnent une fuite gérée honnêtement. Ils ne pardonnent pas d'apprendre par ailleurs que tu leur as caché.

Ce que ça change si tu ne notifies pas

Ne pas notifier une violation qu'on aurait dû notifier est, en soi, un manquement sanctionnable. Autrement dit : tu peux être sanctionné non pas pour la fuite, mais pour l'avoir cachée.

Et le calcul « je me tais, personne ne le saura » est mauvais. Une base ouverte, ça se voit de l'extérieur, par n'importe qui, y compris par la personne qui décidera de porter plainte. Le jour où la CNIL est saisie, avoir notifié dans les délais joue clairement en ta faveur. L'avoir dissimulé joue contre toi. J'ai détaillé le risque de sanction pour une petite structure dans une petite app peut-elle vraiment être sanctionnée.

FAQ

Dois-je notifier même si personne n'a rien volé ?

En général, oui. Le critère, ce n'est pas la preuve d'un vol, c'est la perte de maîtrise sur les données. Si elles ont été accessibles sans autorisation, la violation existe. La seule exception : si la violation n'est « pas susceptible d'engendrer un risque » pour les personnes, tu peux ne pas notifier, mais tu dois pouvoir le justifier. Dans le doute, une base d'emails ouverte se notifie.

Et si je corrige la fuite en une heure ?

Corriger vite est excellent, ça réduit le risque et ça joue en ta faveur. Mais ça ne supprime pas forcément l'obligation : si les données ont été exposées, la violation a eu lieu, même brièvement. Tu évalues le risque réel. Si la base contenait des données sensibles ou est restée ouverte un moment, tu notifies quand même.

72 heures ouvrées ou calendaires ?

Calendaires. Le compteur ne s'arrête pas le week-end ni les jours fériés. Une fuite découverte un vendredi soir se notifie avant le lundi soir. C'est pour ça qu'il vaut mieux connaître la procédure avant d'en avoir besoin.

Comment savoir si ma base a été exposée ?

Tu peux le vérifier toi-même avec les DevTools en deux minutes. Colmate, lui, repère que ton app utilise Supabase avec une clé publique exposée côté client et te signale l'exposition probable à vérifier. Il ne va jamais lire ta base pour te le prouver : la confirmation, c'est toi qui la fais.

Le meilleur plan, c'est de ne pas en arriver là

La règle des 72 heures, c'est le plan B. Le plan A, c'est de fermer la base avant qu'elle ne fuite. Tout ce chapitre légal disparaît si ton RLS est activé et tes secrets rangés côté serveur.

Colmate te dit en trente secondes ce que ton app expose : clés dans le navigateur, code source servi en clair, en-têtes manquants, et si ta base Supabase présente le profil d'une exposition à vérifier. Le tout depuis l'URL publique, en lecture seule, sans jamais toucher à tes données ni à ton code. Pour comprendre le fond de la faille de base, commence par RLS désactivé : pourquoi ta base est lisible, et pour la vue d'ensemble de tes obligations, par le RGPD pour ton app no-code.

Scanne ton app maintenant, c'est gratuit. Autant fermer la porte avant de devoir remplir un formulaire pour dire qu'elle était ouverte.

B

Benjamin Mabily

Fondateur de Colmate

Je scanne des apps vibe-codées au quotidien et je raconte ce que je trouve : clés oubliées dans le code, bases ouvertes, ce que ça veut dire côté RGPD. Colmate est né de ces trouvailles.

LinkedIn

À lire ensuite