RGPD et automatisations : la checklist de conformité

Chaque fois qu’un scénario recopie un e-mail de prospect dans votre CRM, envoie un nom à une IA ou garde l’historique d’une exécution, il traite des données personnelles. Le RGPD s’applique donc à vos automatisations, qu’elles tournent dans Make, n8n ou ailleurs. Bonne nouvelle : pour une petite entreprise, la conformité tient en une liste de points concrets, que l’on vérifie une fois puis à chaque nouveau scénario. Voici la nôtre, en douze points, avec pour chacun ce qu’il faut faire dans vos outils.

Transparence : certains liens de cet article sont des liens partenaires. Si vous créez un compte via l’un d’eux, Flowmatic-Pro perçoit une commission, sans que cela change quoi que ce soit à votre prix. Nous ne recommandons que des outils que nous utilisons nous-mêmes.

Pourquoi vos automatisations sont concernées

Le RGPD (règlement général sur la protection des données) s’applique à tout traitement de données personnelles, c’est-à-dire toute opération sur une information qui permet d’identifier une personne : collecter, enregistrer, transmettre, consulter, effacer. Un nom, une adresse e-mail, un numéro de téléphone, une adresse IP, un historique d’achats : tout cela compte.

Or une automatisation fait exactement cela, en continu. Un formulaire rempli sur votre site déclenche un scénario qui copie les réponses dans un tableau, les transmet à votre outil d’e-mailing, les envoie parfois à une IA pour qualifier la demande, et garde une trace de chaque exécution dans l’historique de Make ou de n8n. Quatre traitements en une seconde.

La responsabilité, elle, reste la vôtre : vous êtes le responsable de traitement. Les outils que vous branchez agissent pour votre compte, en sous-traitants. C’est à vous de vérifier qu’ils sont fiables et que vos scénarios respectent les règles.

Qui est qui ? Les trois rôles à connaître

Trois rôles reviennent sans cesse dans le règlement. Le responsable de traitement, c’est vous : vous décidez pourquoi et comment les données sont utilisées. Les sous-traitants sont les outils et prestataires qui traitent les données pour votre compte : Make, n8n en version cloud, votre CRM, votre outil d’e-mailing, votre fournisseur d’IA. Les personnes concernées sont vos clients, prospects, salariés ou candidats, dont les données circulent. Si un prestataire monte vos scénarios pour vous, il intervient lui aussi comme sous-traitant, et un contrat doit le préciser.

Ce vocabulaire a une conséquence pratique : ce n’est pas parce qu’un outil est réputé sérieux que vous êtes dispensé de vérifier. C’est votre nom qui figure dans la politique de confidentialité, pas le sien.

Les six principes à garder en tête

Le règlement pose des principes généraux (article 5). Appliqués aux automatisations, ils se traduisent ainsi :

Gardez ce tableau sous les yeux en lisant la suite : chacun des douze points de la checklist découle d’un de ces principes.

Point 1 à 3 : cartographier vos flux

Point 1 — Lister vos scénarios qui touchent des personnes

Ouvrez Make ou n8n et parcourez vos scénarios actifs. Pour chacun, notez s’il manipule des données de clients, de prospects, de salariés ou de candidats. Dans une petite entreprise, c’est souvent la majorité : prospection, devis, facturation, avis, relances, support.

Point 2 — Décrire chaque flux en une ligne

Pour chaque scénario concerné, une ligne suffit : quelles données, d’où elles viennent, où elles vont, pourquoi. Par exemple : « Nom, e-mail et besoin du prospect, depuis le formulaire Tally, vers le CRM Notion et l’outil d’e-mailing, pour répondre à la demande et envoyer la séquence de bienvenue ».

Point 3 — Tenir votre registre des traitements

Ces lignes alimentent votre registre des activités de traitement (article 30). Les structures de moins de 250 personnes en sont dispensées seulement pour les traitements occasionnels et sans risque particulier ; la gestion des clients et des prospects, qui est permanente, doit donc y figurer. La CNIL propose un modèle de registre simple sur son site (cnil.fr).

Point 4 à 6 : vos outils sont des sous-traitants

Point 4 — Vérifier le contrat de sous-traitance de chaque outil

L’article 28 impose un contrat entre vous et chaque sous-traitant. Pour les outils en ligne, il prend la forme d’un accord de traitement des données (souvent appelé « DPA ») intégré aux conditions d’utilisation ou à signer dans votre espace client. Vérifiez qu’il existe pour chaque outil branché : plateforme d’automatisation, CRM, e-mailing, fournisseur d’IA, stockage.

Point 5 — Savoir où sont hébergées les données

Les données qui quittent l’Union européenne doivent être encadrées : pays reconnu comme adéquat, entreprise américaine certifiée au Data Privacy Framework (le cadre UE–États-Unis adopté en 2023), ou clauses contractuelles types. Pour vos outils d’automatisation, regardez la zone d’hébergement choisie à l’inscription (Make propose des zones européennes) ou optez pour n8n auto-hébergé sur un serveur en Europe, qui vous laisse la main sur l’endroit où tout est stocké.

Point 6 — Limiter ce que chaque outil reçoit

C’est la minimisation appliquée au quotidien. Un scénario qui envoie un prospect vers votre outil d’e-mailing n’a besoin que de l’e-mail, du prénom et du segment ; pas du numéro de téléphone ni des notes commerciales. Dans Make comme dans n8n, un module de préparation (Set / Edit Fields dans n8n, « Set variable » ou un simple mappage dans Make) permet de ne transmettre que les champs utiles.

Point 7 à 9 : journaux, copies et durées de conservation

C’est l’angle mort le plus fréquent. Vos outils d’automatisation conservent une copie des données de chaque exécution, pour vous permettre de déboguer. Utile, mais ces copies sont des données personnelles comme les autres.

Point 7 — Régler l’historique des exécutions

Dans n8n, les paramètres du workflow permettent de choisir si l’on enregistre les exécutions réussies, échouées ou manuelles. Pour un scénario qui traite des données sensibles et fonctionne bien, ne garder que les exécutions en échec est souvent le bon compromis. En auto-hébergement, les variables EXECUTIONS_DATA_PRUNE et EXECUTIONS_DATA_MAX_AGE purgent automatiquement les exécutions au-delà d’une durée que vous fixez. Dans Make, l’option « Data is confidential » des réglages du scénario évite que le contenu des exécutions soit conservé et affiché.

Point 8 — Traquer les copies intermédiaires

Tableurs de transit, magasins de données (data stores), fichiers déposés dans un dossier partagé, pièces jointes dans une boîte mail d’alerte : chaque étape intermédiaire est une copie. Listez-les, et prévoyez leur nettoyage, par exemple un scénario planifié qui supprime chaque semaine les lignes traitées depuis plus de trente jours.

Point 9 — Fixer une durée de conservation par type de donnée

Ces durées sont des repères issus des recommandations de la CNIL ; adaptez-les à votre situation, et écrivez celles que vous retenez dans votre registre. Pour les sauvegardes de vos instances n8n, appliquez la même logique que dans notre guide pour sauvegarder et restaurer n8n : chiffrées, datées, et supprimées au-delà de la durée utile.

Point 10 à 12 : les droits des personnes

Point 10 — Informer au moment de la collecte

Sous chaque formulaire, une phrase courte renvoie vers votre politique de confidentialité, qui indique les finalités, les destinataires (vos outils) et les durées. Si vous construisez vos formulaires avec Tally et une automatisation, ajoutez-la directement dans le formulaire.

Point 11 — Pouvoir répondre à une demande d’accès ou d’effacement

Toute personne peut demander ce que vous savez d’elle, ou la suppression de ses données. Vous avez un mois pour répondre. Sans cartographie, c’est une chasse au trésor dans six outils ; avec elle, un scénario peut même faire le travail : à partir d’une adresse e-mail, il interroge chaque outil, rassemble ce qu’il trouve, puis supprime après votre validation.

Point 12 — Respecter l’opposition et la désinscription

Un désabonnement de la newsletter doit se propager partout : outil d’e-mailing, CRM, séquences de relance. Un scénario de « liste d’opposition » qui met à jour tous les outils à la fois évite qu’un désinscrit reçoive encore une relance commerciale trois semaines plus tard.

Et la sécurité ? Accès, identifiants et départs

Le RGPD exige des mesures de sécurité « appropriées » (article 32). Pour une petite structure qui automatise, elles se résument à quelques habitudes, qui protègent autant vos données que celles de vos clients :

• Un compte par personne sur Make, n8n et chaque outil branché, jamais d’identifiant partagé. Vous savez ainsi qui a modifié quoi.
• Les identifiants rangés dans le coffre de l’outil (les « connexions » de Make, les « credentials » de n8n), jamais collés en clair dans un module ou une note.
• Une connexion par usage, avec les droits minimaux : une clé en lecture seule pour un scénario qui ne fait que lire.
• La double authentification activée sur tous les comptes qui donnent accès à des données clients.
• Une procédure de départ : quand un collaborateur ou un prestataire s’en va, ses accès sont retirés et les connexions qu’il avait créées sont transférées ou renouvelées.

Ces points sont détaillés, avec les réglages de chaque outil, dans notre guide pour sécuriser vos automatisations. Ils prennent une heure à mettre en place, et évitent la plupart des incidents que l’on rencontre dans les petites entreprises : une clé oubliée dans un scénario partagé, un ancien prestataire qui a toujours accès, un mot de passe commun jamais changé.

Le cas particulier de l’intelligence artificielle

Envoyer des données à un modèle d’IA, c’est les transmettre à un sous-traitant de plus. Les mêmes règles s’appliquent, avec trois précautions supplémentaires :

• Vérifiez l’usage des données par le fournisseur : les offres professionnelles et les accès par API des grands fournisseurs précisent en général que vos données ne servent pas à entraîner leurs modèles. Lisez-le dans leurs conditions, ne le supposez pas.
• Pseudonymisez quand c’est possible : pour classer un message, l’IA n’a pas besoin du nom ni de l’adresse de son auteur. Remplacez-les par un identifiant avant l’envoi.
• Gardez l’humain dans la boucle pour tout ce qui engage : l’IA propose, une personne valide.

Notre guide IA + Make / n8n détaille ces usages. Pour les cas les plus sensibles, un modèle hébergé chez vous, branché à un n8n auto-hébergé, garde toutes les données sur votre infrastructure.

Documenter un scénario : le modèle de fiche

La meilleure protection, et la plus simple, est une fiche par scénario. Elle sert à la fois de page du registre, de mode d’emploi pour l’équipe et de point de départ en cas d’incident. Voici le modèle que nous utilisons, à coller dans la description du scénario ou dans votre base Notion :

Mettez-la à jour à chaque modification importante, et datez-la. Au bout de quelques mois, l’ensemble des fiches devient votre registre, sans travail supplémentaire. C’est aussi un atout commercial : un client professionnel qui vous demande comment vous traitez ses données reçoit une réponse précise le jour même.

Un dernier conseil : conservez les fiches des scénarios désactivés, avec leur date d’arrêt. En cas de question sur une donnée ancienne, vous saurez d’où elle venait et quand son traitement a cessé.

La checklist complète, à copier

Recopiez ce tableau dans votre outil de gestion et passez chaque scénario au crible. Un point non validé n’empêche pas le scénario de tourner, mais doit être corrigé dans le mois.

Exemple : auditer un scénario de prospection

Prenons un scénario courant, que nous avons décrit dans notre guide pour automatiser sa prospection de freelance : un formulaire de contact alimente un CRM, une IA qualifie la demande, un e-mail de bienvenue part et une relance est programmée. Voici l’audit, point par point (exemple construit pour illustrer la méthode) :

Cinq corrections, une heure de travail, et le même scénario rend exactement le même service. C’est le message principal de cette checklist : la conformité se joue dans les réglages et le mappage des champs, rarement dans l’abandon d’une automatisation.

Si une fuite survient : les bons réflexes

Une clé d’API qui fuite, un tableau partagé par erreur en accès public, un scénario qui envoie des données au mauvais destinataire : ce sont des violations de données. Le RGPD impose de les documenter en interne et, si elles présentent un risque pour les personnes, de les notifier à la CNIL dans les 72 heures après en avoir pris connaissance (article 33).

1. Couper : désactiver le scénario, révoquer la clé ou le partage en cause.
2. Mesurer : quelles données, combien de personnes, depuis quand — l’historique des exécutions sert enfin à quelque chose.
3. Documenter : consigner l’incident, même mineur, dans un registre des violations.
4. Notifier si nécessaire, et informer les personnes si le risque est élevé.
5. Corriger la cause, puis réactiver.

Une alerte sur les échecs de scénarios, comme celle décrite dans gérer les erreurs de ses automatisations, permet souvent de repérer ces situations dès les premières minutes.

Les erreurs les plus fréquentes

1. Oublier l’historique des exécutions, qui contient des copies de toutes les données passées par le scénario.
2. Partager un seul compte entre plusieurs personnes : impossible de savoir qui a fait quoi.
3. Coller une clé d’API dans un champ de texte au lieu d’utiliser les identifiants chiffrés de l’outil.
4. Envoyer la fiche entière à chaque outil par facilité de mappage.
5. Croire que l’auto-hébergement suffit : il règle la localisation, pas la minimisation ni les durées.
6. Laisser des scénarios orphelins tourner après le départ de celui qui les a créés.

Votre plan d’action en une journée

1. Matin : listez vos scénarios et écrivez une ligne par flux (points 1 et 2).
2. Reportez ces lignes dans votre registre et vérifiez les accords de traitement de vos outils (points 3 à 5).
3. Après-midi : réglez l’historique des exécutions et supprimez les copies inutiles (points 7 et 8).
4. Revoyez le mappage des champs envoyés à chaque outil, IA comprise (point 6).
5. Fixez vos durées de conservation et programmez les scénarios de nettoyage (point 9).
6. Terminez par l’information sous vos formulaires et le scénario de désinscription (points 10 à 12).

Questions fréquentes

👉 Pour aller plus loin : sécuriser vos automatisations, choisir entre n8n en cloud ou auto-hébergé et sauvegarder et restaurer n8n.