RGPD et outils no-code (Airtable, Notion, Zapier, Make) : ce qu'il faut verifier avant de connecter les donnees de vos clients
Publie le 05/11/2026 · Temps de lecture : 10 min
Un formulaire qui alimente automatiquement une base de donnees, qui declenche a son tour un email de bienvenue, puis ajoute le contact a une liste de diffusion : ce type de scenario, monte en quelques clics avec des outils comme Airtable, Notion, Zapier ou Make, sans ecrire une ligne de code, est devenu courant dans les TPE et PME. Chaque etape de la chaine traite pourtant des donnees personnelles, et chaque application ajoutee au scenario devient, au sens du RGPD, un nouveau sous-traitant avec lequel l'entreprise doit disposer d'un contrat conforme a l'article 28. Entre la simplicite d'usage de ces outils et les obligations qui en decoulent, l'ecart est souvent large, et largement ignore.
Sommaire
- 1. Un responsable de traitement reste responsable, meme sans ecrire de code
- 2. Reperer les sous-traitants caches dans un scenario d'automatisation
- 3. Ou sont hebergees les donnees et le sujet des transferts hors UE
- 4. Mettre a jour le registre des traitements et la politique de confidentialite
- 5. Limiter les donnees transmises a chaque etape
- 6. Securiser les cles API, webhooks et acces partages
- Questions frequentes
1. Un responsable de traitement reste responsable, meme sans ecrire de code
L'article 4 du RGPD distingue le « responsable du traitement » (l'entreprise qui decide pourquoi et comment les donnees sont traitees) du « sous-traitant » (toute entite qui traite des donnees pour le compte du responsable). Rien dans cette definition ne depend de la technique employee : qu'un outil soit code sur mesure par un developpeur ou assemble par glisser-deposer dans une interface no-code ne change rien a la qualification juridique du traitement qui en resulte.
L'article 28.1 du RGPD impose au responsable de traitement de ne faire appel qu'a des sous-traitants presentant des garanties suffisantes, et l'article 28.3 liste le contenu minimal du contrat qui doit les lier : objet et duree du traitement, nature et finalite, type de donnees et categories de personnes concernees, obligations et droits du responsable. En pratique, chaque application branchee dans un scenario d'automatisation declenche cette obligation, qu'elle soit utilisee pour le marketing, la facturation ou le simple archivage de formulaires.
2. Reperer les sous-traitants caches dans un scenario d'automatisation
Un scenario qui relie un formulaire de contact, une base de donnees type Airtable, un espace de travail Notion et un envoi de notification fait intervenir au minimum quatre entreprises distinctes, chacune avec ses propres conditions d'utilisation et, parfois, aucun contrat de sous-traitance clairement accessible. La plateforme d'automatisation elle-meme (Zapier, Make ou un equivalent) s'ajoute a la liste : elle fait transiter les donnees entre chaque etape, meme sans les stocker durablement, et constitue a ce titre un sous-traitant supplementaire.
L'article 28.2 du RGPD ajoute une regle souvent oubliee : un sous-traitant ne peut recourir a un autre sous-traitant (par exemple, un outil qui s'appuie lui-meme sur un service tiers d'envoi d'emails) qu'avec l'autorisation ecrite, prealable, specifique ou generale, du responsable du traitement. Dans les faits, cette autorisation generale est souvent deja donnee implicitement en acceptant les conditions d'utilisation de l'outil, mais encore faut-il les avoir lues pour savoir a quels sous-traitants ulterieurs on consent.
3. Ou sont hebergees les donnees et le sujet des transferts hors UE
Airtable, Notion et Zapier sont des societes americaines ; les donnees qui transitent par leurs services peuvent donc faire l'objet d'un transfert hors de l'Union europeenne, au sens des articles 44 a 49 du RGPD. Ce transfert n'est pas interdit, mais il doit s'appuyer sur un fondement juridique precis : une decision d'adequation, les clauses contractuelles types adoptees par la Commission europeenne en juin 2021, ou, pour les entreprises americaines qui s'y sont adherees, le cadre de protection des donnees UE-Etats-Unis (Data Privacy Framework), adopte par la Commission europeenne le 10 juillet 2023.
Avant de connecter un nouvel outil a un scenario, il vaut mieux consulter la page consacree a la protection des donnees ou au « trust center » de l'editeur : les fournisseurs serieux y precisent explicitement le fondement retenu pour les transferts internationaux. Notre guide sur les transferts de donnees hors UE detaille ces mecanismes plus en profondeur.
4. Mettre a jour le registre des traitements et la politique de confidentialite
Chaque automatisation qui fait circuler des donnees de clients ou de prospects doit se refleter dans le registre des traitements impose par l'article 30 du RGPD : finalite precise, categories de donnees concernees, destinataires (y compris les outils connectes), et duree de conservation a chaque etape. Un scenario jamais documente dans ce registre est un angle mort frequent lors d'un controle de la CNIL, car il revele un decalage entre ce que l'entreprise declare faire des donnees et ce qu'elle en fait reellement.
La politique de confidentialite du site, exigee par l'article 13 du RGPD, doit elle aussi mentionner les destinataires reels des donnees collectees. Ajouter un nouvel outil a un scenario sans mettre a jour ce document revient a informer les personnes concernees d'une liste de destinataires devenue incomplete.
5. Limiter les donnees transmises a chaque etape
L'article 5.1.c du RGPD pose le principe de minimisation : seules les donnees adequates, pertinentes et limitees a ce qui est necessaire pour la finalite poursuivie doivent etre traitees. Dans un scenario d'automatisation, il est tentant de transmettre l'integralite d'un enregistrement client (nom, adresse, telephone, historique d'achats) a chaque etape, meme quand seule une information precise est utile a l'etape suivante.
Un exemple frequent : une notification envoyee vers un outil de messagerie d'equipe a chaque nouvelle commande, qui transmet par defaut l'ensemble des champs du formulaire de commande plutot que le seul numero de commande et le montant. Chaque champ transmis sans necessite augmente le nombre d'endroits ou la donnee existe, et donc la surface d'exposition en cas de fuite chez l'un des outils connectes. La plupart des plateformes d'automatisation permettent de filtrer les champs transmis a chaque etape : une configuration a verifier systematiquement avant de valider un scenario.
6. Securiser les cles API, webhooks et acces partages
L'article 32 du RGPD impose de mettre en oeuvre des mesures techniques et organisationnelles adaptees au risque. Dans un scenario d'automatisation, ce risque prend une forme particuliere : un webhook (une URL qui recoit automatiquement des donnees) est souvent accessible a quiconque en connait l'adresse, sans authentification supplementaire. Une cle API partagee entre plusieurs comptes d'une meme equipe, rarement renouvelee, constitue un autre point de faiblesse classique.
Quelques reflexes limitent ce risque : restreindre les permissions de chaque cle API au strict necessaire (lecture seule quand c'est possible), renouveler ces cles periodiquement, et tenir une liste a jour des personnes ayant acces aux scenarios, en particulier dans une petite equipe ou les departs ne sont pas toujours suivis d'une revocation immediate des acces.
Documentez vos outils connectes sans y passer des heures
ConformiteFacile centralise votre registre des traitements et votre politique de confidentialite, et vous aide a suivre les sous-traitants ajoutes au fil de vos automatisations.
Mettre mon site en conformiteQuestions frequentes
Zapier ou Make sont-ils eux-memes des sous-traitants RGPD, ou seulement les applications qu'ils connectent ?
Les deux. La plateforme d'automatisation (Zapier, Make ou equivalent) traite elle-meme les donnees qui transitent par les scenarios, meme brievement, pour les acheminer d'une application a l'autre : elle est donc sous-traitante au sens de l'article 28 du RGPD, au meme titre que chacune des applications connectees qui recoit effectivement les donnees a l'autre bout du scenario.
Faut-il un contrat avec chaque outil connecte, meme un outil gratuit ou utilise ponctuellement ?
Oui. L'obligation de l'article 28 du RGPD ne depend pas du prix paye ni de la frequence d'utilisation, mais du fait qu'un outil traite des donnees personnelles pour le compte de l'entreprise. La plupart des editeurs serieux publient un contrat de sous-traitance standard (souvent appele DPA, Data Processing Addendum) accessible meme sur un plan gratuit, generalement dans les pages legales ou un centre de confiance du site.
Une petite entreprise doit-elle vraiment tenir un registre des traitements pour un simple scenario d'automatisation ?
L'article 30.5 du RGPD exempte les entreprises de moins de 250 salaries de tenir un registre, mais seulement si le traitement est occasionnel, ne presente pas de risque pour les droits des personnes et ne porte pas sur des donnees sensibles. Un scenario qui fait circuler regulierement des donnees de clients ou de prospects entre plusieurs outils ne remplit generalement aucune de ces trois conditions : le registre reste donc necessaire dans la plupart des cas concrets.
Que se passe-t-il si un outil connecte a mon scenario subit une fuite de donnees ?
L'article 33.2 du RGPD oblige tout sous-traitant a notifier l'entreprise responsable du traitement sans delai des qu'il a connaissance d'une violation de donnees. C'est ensuite a l'entreprise, en tant que responsable de traitement, d'evaluer si la CNIL doit etre notifiee dans les 72 heures et si les personnes concernees doivent etre informees. Mieux vaut verifier, avant toute connexion, que chaque outil s'engage contractuellement sur ce delai de notification.
A lire aussi
Decision automatisee et profilage (article 22 du RGPD) : ce qu'une TPE ou PME doit savoir
Lire
Achat ou location de fichiers de prospection : ce que le RGPD exige avant d'utiliser une base de contacts achetee
Lire