Make et RGPD : valider les flux et les historiques

Un scénario Make peut lire un dossier, en conserver une copie de diagnostic et transmettre quelques champs à une autre application. Ces opérations doivent toutes entrer dans votre analyse. Choisir une organisation européenne est utile pour la localisation, mais ne suffit pas à valider les fournisseurs connectés, les accès et les durées de conservation.

Ce qu’il faut retenir

• Documentez chaque automatisation métier, ses données d’entrée et ses destinataires, pas seulement le nom « Make » dans une liste d’outils.
• La région se choisit à la création d’une organisation ; elle ne se modifie pas ensuite dans cette organisation.
• Le DPA public fait partie de l’accord ; l’exigence RGPD porte sur un contrat contraignant, pas sur une signature séparée systématique.
• L’historique d’exécution, les exécutions incomplètes et les bases de données internes appellent des vérifications distinctes.
• Un filtre placé après la réception des données ne réduit pas ce que Make a déjà reçu.

1. Conserver les bonnes pièces contractuelles

Le DPA Make publié le 3 mai 2024 prévoit son intégration à l’accord (§ 1), le traitement sur instructions (§ 2) et l’assistance aux droits (§ 8). Il organise aussi l’effacement ou la restitution sur demande à la fin du contrat (§ 3.3). Conservez la version applicable à votre souscription et ses annexes. DPA officiel Make.

Le MSA public Make consulté porte la mention mars 2026 et désigne Celonis, Inc. Le DPA envisage également le cas d’un contrat avec une entité de l’EEE (§ 7.2) : vérifiez donc votre propre commande, notamment pour une offre négociée, au lieu d’étendre le contrat en ligne à tous les clients. MSA publié, documents contractuels Make.

Pour les données traitées pour votre compte, vérifiez les garanties et clauses requises par l’Art. 28(1) et (3). Si vous intervenez vous-même pour un client, examinez votre autorisation de recourir à Make comme sous-traitant ultérieur. La cartographie de la chaîne de sous-traitance aide à distinguer ces situations.

2. Vérifier la région de chaque organisation

L’aide actuelle permet de choisir entre les États-Unis et l’Union européenne au niveau de l’organisation. Un même utilisateur peut créer plusieurs organisations. La localisation ne peut plus être changée après leur création : une migration doit donc être préparée vers une autre organisation, avec reprise des connexions et vérification des scénarios. Il n’est pas exact d’affirmer qu’il faut nécessairement recréer le compte utilisateur. Documentation des organisations.

La liste officielle applicable depuis le 12 décembre 2025 distingue les prestataires et leurs localisations. Elle mentionne notamment AWS et MongoDB avec des hébergements européens selon l’offre, mais aussi des services d’accompagnement ou d’IA hébergés hors UE. Les fonctions activées comptent donc autant que la région du scénario. Liste Make des sous-traitants.

Demandez un tableau des flux couvrant le support, les données de compte et les fonctions additionnelles. Pour les transferts, le DPA distingue les situations contractuelles et prévoit le DPF ou les CCT selon le cas (§ 7). Vérifiez le mécanisme effectivement applicable et le statut du destinataire ; une clause de secours ne vaut pas analyse préalable de tous les transferts.

Lorsque le flux repose sur un instrument de l’Art. 46, l’analyse d’impact du transfert doit apprécier la protection et les éventuelles mesures complémentaires. Elle n’est pas réservée aux gros volumes. La décision d’adéquation applicable répond à un autre régime. Explication CNIL de l’AITD. Notre modèle d’analyse d’impact du transfert peut servir à documenter les vérifications nécessaires.

3. Dessiner le scénario avant de le déployer

Exemple fictif : un formulaire interne transmet une demande de maintenance à un outil de suivi. L’objectif nécessite un identifiant, une description technique et un contact professionnel. Une pièce jointe contenant tout un dossier RH n’a pas à suivre ce trajet.

Vérifiez les champs reçus par Make, les transformations et les champs envoyés à chaque étape. Lorsque c’est possible, réduisez les données dès l’application source : un module de filtrage ultérieur intervient après leur réception. Cette démarche applique la minimisation de l’Art. 5(1)(c). Déterminez la base de l’Art. 6(1) d’après l’objectif métier, sans considérer l’automatisation comme une base légale. RGPD, Art. 5 et 6.

Une application que vous connectez avec votre propre compte n’est pas automatiquement un sous-traitant de Make. Vérifiez son contrat, son rôle et ses flux séparément. Pour un connecteur HTTP, identifiez le domaine destinataire et le propriétaire de l’API ; un nom de module rassurant ne garantit pas cette destination.

4. Maîtriser les copies et les reprises sur erreur

Le réglage Keep data confidential empêche, selon l’aide Make, de conserver le contenu traité dans les journaux d’exécution ; la trace du passage subsiste et le dépannage devient plus limité. Le réglage Store incomplete executions concerne, lui, la conservation des exécutions en échec pour leur reprise. Examinez les deux et vérifiez le résultat avec des données fictives. Réglages des scénarios.

Les data stores constituent un stockage interne supplémentaire. Ne les confondez pas avec le seul historique : attribuez à chacun un propriétaire, une finalité et une échéance de suppression. Présentation Make des data stores.

Avant de rejouer une exécution, vérifiez aussi si certaines actions ont déjà réussi. Une reprise qui crée deux comptes ou renvoie un document à un ancien destinataire peut produire un incident. Pour une demande d’effacement, cherchez les données dans les différentes copies et empêchez leur réimportation depuis la source. Conservez une preuve de l’exécution de l’effacement.

5. Autoriser l’IA et les accès de façon explicite

Distinguez une fonction IA fournie par Make d’un module utilisant le compte que vous détenez auprès d’un autre fournisseur. Vérifiez les entrées, les sorties, les historiques, les prestataires et les options de réutilisation du service précis. Une région UE choisie pour l’organisation ne démontre pas que tous les modèles appelés y traitent les données.

Limitez les droits des connexions à ce que le scénario doit accomplir. Attribuez un responsable capable de révoquer une connexion, de suspendre le scénario et de traiter un incident. Réexaminez les autorisations lorsqu’un prestataire externe quitte le projet. Les mesures de l’Art. 32(1) doivent couvrir les accès aux données et les effets des actions automatisées.

Fiche de validation du scénario

Réutilisez cette fiche pour une revue des changements du registre, par exemple lors de l’ajout d’un destinataire ou d’un module IA.

FAQ

Une organisation européenne garantit-elle tous les flux dans l’UE ?

Non. Examinez les fonctions complémentaires, les accès et les applications connectées. La région de l’organisation décrit une partie de l’architecture.

Faut-il signer un DPA séparé ?

Il faut un accord écrit contraignant conforme à l’Art. 28(3) et (9). Le DPA public Make prévoit son intégration au contrat : conservez cette preuve et vérifiez les conditions propres à votre souscription.

Le mode confidentiel supprime-t-il toutes les données du scénario ?

Il vise les contenus des journaux d’exécution décrits par Make. Contrôlez séparément les exécutions incomplètes, les data stores et les applications destinataires.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.