Si vous construisez un portail client, une application de réservation ou un petit CRM pour vos clients, la conformité RGPD devient vite une vraie question — même sans équipe juridique ni avocat interne. Ce guide décortique, en langage clair, ce que le RGPD exige réellement d'une application de petite entreprise, ce qui change quand vous construisez avec une plateforme no-code ou IA, et une checklist pratique que vous pouvez appliquer vous-même. C'est un panorama pédagogique, pas un avis juridique : pour les secteurs réglementés (santé, finance, données d'enfants) ou un traitement à plus grande échelle, parlez-en à un avocat ou à un délégué à la protection des données avant de publier.
Responsable vs sous-traitant : la distinction qui clarifie tout
Le RGPD repose sur une distinction simple mais souvent source de confusion. Le responsable du traitement décide pourquoi et comment les données personnelles sont traitées — c'est généralement vous, en tant qu'entrepreneur, quand vous collectez les noms, emails ou réservations de vos clients dans votre application. Un sous-traitant traite ces données pour le compte du responsable et selon ses instructions — c'est le cas de chaque outil que vous branchez : votre plateforme no-code/IA, votre hébergeur, votre base de données, votre outil d'emailing, votre prestataire de paiement. Cette distinction compte pour une raison très concrète : elle indique qui est responsable de quoi, et c'est pourquoi vous devriez exiger un contrat de sous-traitance (DPA) de chaque sous-traitant qui touche aux données de vos utilisateurs. Si un fournisseur ne peut pas produire de DPA sur demande, c'est un signal d'alerte.
- Responsable : vous, pour les données de vos clients finaux collectées via votre application.
- Sous-traitant : votre plateforme, votre hébergeur, votre outil d'emailing, votre prestataire de paiement — tout acteur qui traite les données uniquement sur vos instructions.
- Sous-traitant ultérieur : les propres prestataires d'un sous-traitant, par exemple l'hébergeur cloud derrière votre fournisseur de base de données.
Ce que la conformité RGPD attend concrètement d'une petite application no-code
Débarrassé du jargon juridique, l'essentiel des obligations de conformité RGPD pour une petite application no-code se résume à une liste courte et pratique. La CNIL propose un excellent guide pratique pour les TPE/PME.
- Une politique de confidentialité en langage clair : ce que vous collectez, pourquoi, pendant combien de temps, qui y a accès, et comment exercer ses droits.
- Une base légale pour chaque type de traitement : l'exécution du contrat pour honorer une réservation, le consentement pour les emails marketing ou les cookies non essentiels, l'intérêt légitime pour la sécurité de base et la lutte contre la fraude.
- Un consentement là où il est vraiment requis : une acceptation explicite pour les communications marketing et pour tout cookie ou traceur non essentiel.
- La minimisation des données : ne collecter que les champs réellement nécessaires pour rendre le service — résister au réflexe d'ajouter des champs « au cas où ».
- Les bases de la sécurité : connexions chiffrées (HTTPS), contrôle d'accès raisonnable, mots de passe hachés, sauvegardes régulières.
- Les droits des personnes : un moyen pour vos utilisateurs de demander l'accès, la rectification ou la suppression de leurs données, et de les recevoir dans un format portable.
- La conscience des obligations en cas de violation : en cas d'incident, vous pourriez devoir notifier votre autorité de contrôle et, dans certains cas, les utilisateurs concernés.
Les questions supplémentaires posées par une plateforme no-code ou IA
Construire sur une plateforme no-code ou IA ne vous décharge pas de vos obligations de responsable du traitement — cela ajoute une couche de questions sur votre fournisseur. Avant de confier des données clients réelles à une plateforme, posez-vous les questions suivantes.
- Où vivent physiquement les données — sur l'infrastructure de qui, dans quelle région ?
- Qui est le sous-traitant pour ces données, et publie-t-il la liste de ses propres sous-traitants ultérieurs ?
- Un contrat de sous-traitance (DPA) est-il disponible, et couvre-t-il réellement les données que vous allez stocker ?
- Pouvez-vous exporter votre schéma et vos données, et tout supprimer sur demande, sans dépendre du support du fournisseur ?
- L'IA sert-elle uniquement à écrire le code de votre application, ou voit-elle et conserve-t-elle aussi les données de production de vos utilisateurs finaux ?
- La plateforme s'interpose-t-elle de façon opaque entre vous et les données personnelles de vos clients, ou détenez-vous les clés de la base de données réelle ?
Choisir sa région et obtenir un DPA
Deux questions déterminent une grande partie de votre exposition au risque : où les données sont-elles stockées, et pouvez-vous obtenir un DPA signé pour cela. La plupart des fournisseurs sérieux de backend-as-a-service — Supabase en fait partie — publient un DPA standard que vous pouvez accepter directement, et vous laissent choisir la région d'hébergement de votre propre projet de base de données, y compris des régions dans l'UE. C'est important, car cela remet le choix de la juridiction entre vos mains plutôt que de le laisser au réglage par défaut d'une plateforme. Il vaut la peine de vérifier ce point pour chaque sous-traitant de votre stack — base de données, outil d'emailing, prestataire de paiement, outil d'analytics — pas seulement votre outil de création d'application.
Cookies et traceurs sur l'application ou le site que vous générez
Les règles sur les cookies sont plus simples qu'on ne le croit une fois qu'on sépare les deux catégories. Les cookies strictement nécessaires — ceux qui gardent un utilisateur connecté ou mémorisent un panier — ne nécessitent pas de consentement. Tout le reste, comme l'analytics, la publicité ou les pixels de réseaux sociaux, en nécessite généralement un, via une acceptation claire avant le dépôt du cookie. L'approche la plus simple pour une petite application : commencer avec uniquement des cookies strictement nécessaires, et n'ajouter un bandeau de consentement que le jour où vous ajoutez réellement un outil d'analytics ou de publicité qui en a besoin.
Une checklist pratique pour les types d'applications courants
Site vitrine ou portfolio : une page de politique de confidentialité en pied de page, un formulaire de contact qui indique ce qui advient des données soumises et pendant combien de temps, et un bandeau cookies uniquement si vous ajoutez de l'analytics ou de la publicité.
Application de réservation ou de rendez-vous : une base légale combinant l'exécution du contrat pour la réservation elle-même et le consentement pour les rappels marketing, en ne collectant que ce qui est nécessaire pour honorer la réservation (nom, contact, date), et en listant vos sous-traitants — synchronisation d'agenda, paiement, prestataire SMS ou email — dans votre politique de confidentialité.
Portail client ou petit CRM : un DPA en place avec chaque sous-traitant touchant aux dossiers clients, un accès basé sur les rôles pour que chaque membre de l'équipe ne voie que ce dont il a besoin, un moyen documenté d'exporter ou de supprimer définitivement le dossier d'un client, et une durée de conservation que vous appliquez réellement plutôt que de tout garder indéfiniment.
Où Cadrant se positionne : vous gardez les clés
Cadrant repose sur une architecture « apportez votre propre Supabase » : quand vous construisez une application, vous connectez votre propre organisation Supabase plutôt qu'une base de données que Cadrant hébergerait et contrôlerait pour vous. Cela a des conséquences RGPD directes. Vous choisissez vous-même votre projet Supabase et sa région d'hébergement. Supabase, en tant que sous-traitant de votre base de données, publie son propre DPA que vous acceptez directement avec eux. Vous restez le responsable des données de vos utilisateurs finaux — les personnes qui réservent, s'inscrivent ou remplissent des formulaires via votre application — et vous conservez à tout moment la capacité complète de consulter, exporter ou supprimer ces données depuis votre propre tableau de bord Supabase, indépendamment de Cadrant. C'est délibérément différent des plateformes où les données de vos clients reposent dans une base de données opaque, partagée et détenue par le fournisseur, que vous ne pouvez ni interroger ni exporter.
Par souci de transparence sur notre propre fonctionnement : Cadrant est édité par Convergence Lab, une société française, et la plateforme elle-même — pas les bases de données que vous connectez — est hébergée sur une infrastructure AWS qui n'est pas exclusivement située dans l'UE ; nous nous appuyons sur des garanties appropriées pour tout transfert hors de l'UE, et notre délégué à la protection des données est joignable à dpo@cadrant.ai pour toute question concernant la plateforme elle-même. Nous ne revendiquons pas de certification SOC 2 ou ISO 27001 à ce jour, et vous devriez accueillir avec scepticisme une telle revendication chez n'importe quel fournisseur tant que vous n'avez pas vu le certificat.
Comment Cadrant vous aide à rester conforme, concrètement
Vous pouvez demander en langage naturel les éléments qui soutiennent votre conformité : une page de politique de confidentialité, un bandeau de consentement aux cookies, un formulaire de contact qui explique ce qui est fait des données envoyées, ou une page de paramètres de compte où vos propres utilisateurs finaux peuvent demander leurs données ou leur suppression. Comme votre base de données vit dans votre propre projet Supabase, honorer une demande de suppression ou d'export est une action réelle et vérifiable — pas un ticket envoyé à un tiers. La conformité n'est jamais totalement automatique, mais partir d'une architecture où vous détenez les données rend chaque étape suivante beaucoup plus simple.