Donneespersonnelles.fr

Plateforme de veille en conformite numerique

Jeudi 2 juillet 2026
RGPD

Make et RGPD : guide de conformité 2026

Make (ex-Integromat) est-il conforme au RGPD ? Sous-traitant, DPA Celonis, résidence des données en UE, transferts et configuration recommandée.

Make (l’ex-Integromat) fait transiter par ses serveurs exactement le type de données que le RGPD encadre le plus strictement : e-mails de prospects, fiches clients, pièces jointes, parfois des données de santé ou bancaires. La bonne nouvelle, c’est que Make est l’un des rares outils d’automatisation à offrir une vraie résidence des données en Europe. La moins bonne, c’est que cet avantage ne dispense pas d’une analyse rigoureuse. Voici ce qu’il faut comprendre — et configurer.

Make est un sous-traitant au sens de l’article 28

Quand vous construisez un scénario qui lit votre CRM, enrichit une fiche et l’écrit dans un tableur, c’est vous qui décidez des finalités et des moyens du traitement. Vous êtes responsable de traitement au sens de l’Art. 4(7). Make, qui exécute techniquement ces opérations sur les données que vous lui confiez, agit comme sous-traitant au sens de l’Art. 4(8).

Cette qualification déclenche une obligation précise : vous devez disposer d’un contrat de sous-traitance conforme à l’Art. 28. Make met à disposition un Data Processing Agreement (DPA) qui s’intègre au DPA de Celonis Inc., sa société mère depuis le rachat d’Integromat en 2020. Ce DPA couvre les clauses de l’Art. 28(3) : confidentialité, sécurité, assistance, sort des données en fin de contrat, et recours à des sous-traitants ultérieurs. Vous pouvez le générer et le signer en self-service depuis votre compte.

Premier réflexe de conformité : récupérer ce DPA signé et le conserver. Sans lui, vous êtes en infraction sur l’Art. 28 dès la première donnée personnelle qui passe par un scénario.

L’atout différenciant : la résidence des données en UE

C’est ici que Make se distingue nettement de Zapier, son concurrent américain. Make propose de choisir la zone d’hébergement de votre organisation entre l’Europe (zones eu1/eu2, serveurs situés dans l’UE) et l’Amérique du Nord (us1/us2). Un compte créé sur la zone européenne stocke et exécute vos scénarios sur une infrastructure située dans l’UE.

Concrètement, pour une PME française, cela permet de garder les données « at rest » sur le sol européen — un argument fort face au transfert hors UE qui plombe la plupart des outils SaaS américains.

Deux pièges méritent toutefois votre attention :

Le choix de la zone se fait à l’inscription. Migrer d’une zone à l’autre n’est pas une simple case à cocher : en pratique, les utilisateurs déjà créés sur la zone us1 doivent recréer un compte sur la zone UE et reconstruire leurs scénarios. Vérifiez donc l’URL de votre tableau de bord (eu1.make.com ou eu2.make.com) avant d’industrialiser vos automatisations. Si vous êtes sur us1, vos données sont aux États-Unis.

La résidence des données n’efface pas toute analyse de transfert. L’entité contractante du DPA reste Celonis Inc., société américaine inscrite au Data Privacy Framework (DPF). Même avec un hébergement européen, l’éventualité d’un accès par la maison mère américaine (logique du CLOUD Act) doit être considérée. Pour les transferts vers des sous-traitants situés hors zone d’adéquation, Make s’appuie sur les clauses contractuelles types (CCT) de la décision (UE) 2021/914.

Sur le statut du DPF en 2026 : le Tribunal de l’Union a rejeté le recours Latombe le 3 septembre 2025, mais un pourvoi reste pendant devant la Cour de justice. Le DPF tient donc toujours, mais les CCT jouent le rôle de filet de sécurité — raison de plus pour privilégier la zone UE.

Le vrai angle mort : les connexions et les modules HTTP

L’erreur classique consiste à analyser Make isolément. Or un scénario Make est par nature une plomberie qui relie des dizaines d’applications tierces. Chaque « connexion » que vous créez (vers Gmail, Salesforce, un webhook, une API maison) fait sortir les données de Make vers un autre système — qui est lui-même soit un autre sous-traitant ultérieur, soit un responsable de traitement distinct.

Trois conséquences pratiques :

D’abord, la cartographie. La liste des sous-traitants ultérieurs publiée par Make ne couvre pas les applications que vous, vous décidez de connecter. Si votre scénario envoie des données vers un outil non conforme via un module HTTP, c’est votre responsabilité, pas celle de Make. Chaque application connectée doit figurer dans votre registre des activités de traitement avec sa propre base de sous-traitance.

Ensuite, la minimisation. Make permet de manipuler des « bundles » de données entiers très facilement — il est tentant de faire transiter l’intégralité d’une fiche client alors que seul l’e-mail est nécessaire. Le principe de minimisation de l’Art. 5(1)© impose de ne faire circuler que les champs utiles. Utilisez les modules de transformation pour filtrer les champs en amont.

Enfin, les modules IA. Make intègre des modules d’IA (AI Toolkit, connecteurs OpenAI, Anthropic, etc.). Dès qu’un scénario envoie des données personnelles à un grand modèle de langage, vous ajoutez un sous-traitant ultérieur, souvent américain, et un traitement à documenter — voire une analyse d’impact si les données sont sensibles. Ne branchez jamais de données de l’Art. 9 (santé, opinions, biométrie) dans un module IA sans base légale et sans évaluation préalable.

Logs d’exécution, data stores et durée de conservation

Make conserve un historique d’exécution de vos scénarios (les « execution logs »), qui contient une copie des données ayant transité. Les « data stores » natifs de Make permettent par ailleurs de stocker durablement des enregistrements. Ces deux mécanismes sont des traitements à part entière au regard de la durée de conservation de l’Art. 5(1)(e).

Recommandations concrètes : limitez la rétention des logs au strict nécessaire au débogage, désactivez la journalisation détaillée sur les scénarios qui manipulent des données sensibles, et purgez régulièrement les data stores. En cas de demande de droit d’effacement, n’oubliez pas que la donnée peut subsister dans les logs d’exécution et les data stores, pas seulement dans l’application de destination.

Sécurité et bases légales

Côté sécurité (Art. 32), Make/Celonis revendique les certifications SOC 2 Type II, SOC 3 et une conformité ISO 27001, avec chiffrement en transit et au repos. La part de sécurité qui vous incombe est surtout organisationnelle : activez l’authentification à deux facteurs sur les comptes, gérez finement les droits des membres d’équipe (un scénario mal partagé expose toutes les données qu’il manipule), et ne stockez jamais d’identifiants en clair dans les champs d’un scénario.

Côté base légale, Make n’en crée aucune : c’est le traitement métier sous-jacent qui en porte une. Un scénario qui envoie un e-mail de prospection devra reposer sur le consentement ou l’intérêt légitime selon le contexte ; un scénario de synchronisation RH reposera sur l’exécution du contrat ou une obligation légale. Et n’oubliez pas l’information des personnes : si Make est l’un de vos sous-traitants structurants, mentionnez la catégorie de prestataire dans votre politique de confidentialité au titre de l’Art. 13.

Cartographier ainsi chaque outil — sa qualification, son DPA, ses sous-traitants ultérieurs, ses transferts — vers un registre vivant est exactement le type de travail que Legiscope automatise.

Ce qu’il faut retenir

  • Make est un sous-traitant (Art. 28) : récupérez et conservez le DPA Celonis signé en self-service avant toute mise en production.
  • Choisissez la zone UE à l’inscription (eu1/eu2) : c’est le principal avantage de Make sur Zapier, mais la migration depuis us1 impose en pratique de recréer un compte.
  • La résidence UE ne supprime pas l’analyse de transfert : l’entité contractante reste Celonis Inc. (US, DPF + CCT) ; gardez les CCT comme filet de sécurité.
  • Les connexions et modules HTTP/IA sont l’angle mort : chaque application que vous branchez est votre responsabilité, pas celle de Make. Documentez-les dans votre registre.
  • Maîtrisez logs et data stores : ils conservent une copie des données et relèvent de la durée de conservation et du droit à l’effacement.

FAQ

Make est-il conforme au RGPD ?

Make fournit les outils nécessaires à la conformité (DPA conforme à l’Art. 28, résidence des données en UE, CCT, certifications de sécurité), mais la conformité d’un scénario dépend de votre configuration : zone d’hébergement choisie, applications connectées, minimisation des données et bases légales des traitements automatisés.

Make ou Zapier : lequel est meilleur pour le RGPD ?

Make a un avantage net sur la localisation des données, puisqu’il propose une zone d’hébergement européenne quand Zapier stocke par défaut aux États-Unis. Dans les deux cas, l’éditeur reste rattaché à une entité américaine (Celonis Inc. pour Make), donc l’analyse des transferts et des sous-traitants ultérieurs demeure nécessaire.

Où sont stockées les données traitées par Make ?

Cela dépend de la zone de votre organisation, choisie à l’inscription. Les zones eu1/eu2 hébergent les données dans l’Union européenne ; les zones us1/us2 aux États-Unis. Vérifiez l’URL de votre tableau de bord pour le savoir, et privilégiez une zone UE pour un usage européen.

Faut-il signer un contrat de sous-traitance avec Make ?

Oui. Dès que vos scénarios traitent des données personnelles, l’Art. 28 impose un contrat de sous-traitance. Make permet de générer et signer ce DPA (intégré au DPA de Celonis Inc.) directement depuis votre compte ; conservez-en une copie dans votre documentation de conformité.