Comment sécuriser ses scénarios Make ?
Sécuriser un scénario Make consiste à limiter l'accès aux connexions et aux clés API, activer l'authentification à deux facteurs sur les comptes, restreindre les rôles de son équipe et imposer une validation avant toute action sensible. Un scénario mal protégé peut exposer des données clients ou déclencher une action irréversible sans contrôle humain.
Un scénario Make sécurisé limite l'accès à ses connexions, protège les comptes avec la double authentification, restreint les rôles de l'équipe au strict nécessaire et impose un contrôle humain avant toute action sensible ou irréversible.
Pourquoi la sécurité d'un scénario Make mérite-t-elle autant d'attention ?
Un scénario Make n'est pas un simple document de travail : c'est un programme qui s'exécute automatiquement, avec des accès réels à votre CRM, votre boîte mail, votre comptabilité ou votre boutique en ligne. Chaque connexion ajoutée est une porte ouverte vers un outil métier.
Le risque n'est pas hypothétique. Une clé API partagée par erreur dans une capture d'écran, un scénario laissé accessible à toute une équipe sans distinction de rôle, ou une action de suppression déclenchée sans validation peuvent avoir des conséquences bien réelles : données exposées, envois en double, factures erronées.
Les clés API et jetons qui relient Make à vos outils métier.
L'accès à votre organisation Make : qui peut se connecter, et comment.
Ce que le scénario a le droit de faire seul, et ce qui exige une validation.
Comment protéger ses connexions et ses clés API ?
Chaque module Make (CRM, messagerie, base de données) se connecte via une clé API ou un jeton d'autorisation. C'est le maillon le plus sensible d'un scénario : une clé mal protégée équivaut à laisser une clé physique de votre bureau sous le paillasson.
- Créer une clé dédiée par usageUne clé API par scénario ou par intégration plutôt qu'une clé unique réutilisée partout, pour limiter l'impact d'une fuite.
- Ne jamais coller une clé en clair dans un moduleUtiliser le champ de connexion prévu par Make, qui masque la valeur, plutôt qu'un champ texte visible par tous les éditeurs.
- Restreindre les scopes de la cléQuand l'outil connecté le permet, générer une clé en lecture seule ou limitée aux actions réellement nécessaires.
- Renommer et documenter chaque connexionUn nom clair (« CRM - lecture leads ») évite qu'un collaborateur réutilise une connexion pour un autre usage sans le savoir.
- Faire tourner ses clés régulièrementRégénérer les clés API sensibles à intervalle régulier, en particulier après le départ d'un collaborateur qui y avait accès.
La documentation développeur de Make rappelle que les paramètres de type « mot de passe » masquent la valeur d'une clé dès qu'elle est saisie dans une connexion, ce qui évite qu'un tiers ayant accès au scénario puisse la lire ou la copier.
Comment sécuriser l'accès aux comptes Make ?
Avant même de parler de connexions, la première protection reste l'accès au compte Make lui-même. Un mot de passe seul, même solide, ne suffit plus à protéger un outil connecté à autant de données métier.
Make propose l'authentification à deux facteurs via une application dédiée (Google Authenticator, Authy, 1Password ou équivalent), avec des codes de récupération à conserver en lieu sûr en cas de perte du téléphone. La documentation officielle sur la double authentification détaille l'activation pas à pas, et les organisations de type Enterprise peuvent même l'imposer à tous les membres.
Sur un compte Free ou Core sans cette contrainte imposée, activer la 2FA reste une décision individuelle : autant ne pas attendre un incident pour le faire.
Comment gérer les accès quand on travaille à plusieurs sur Make ?
Dès qu'une deuxième personne intervient sur vos scénarios, la question n'est plus seulement technique : elle devient organisationnelle. Make structure les comptes en organisations et en équipes, avec des rôles qui déterminent qui peut voir, modifier ou publier un scénario.
La documentation Make sur les équipes et les organisations précise que les scénarios, connexions et webhooks appartiennent à une équipe précise : un collaborateur n'a accès qu'aux ressources de l'équipe à laquelle il est rattaché, pas à l'ensemble de l'organisation par défaut.
Quelles données faut-il éviter de faire transiter dans un scénario ?
Un scénario Make manipule des données à chaque exécution, et ces données transitent aussi dans l'historique d'exécution, consultable par toute personne ayant accès au scénario. Certaines informations n'ont simplement rien à y faire.
Numéros de carte bancaire en clair, mots de passe, pièces d'identité : ces données ne devraient jamais transiter telles quelles dans un scénario, même si l'outil connecté les traite par ailleurs de façon sécurisée.
Le guide de la sécurité des données personnelles de la CNIL rappelle le principe de minimisation : ne collecter et ne faire circuler que les données strictement nécessaires au traitement. Pour un scénario Make, cela signifie filtrer les champs transmis d'un module à l'autre plutôt que de faire suivre l'intégralité d'un enregistrement client par réflexe.
Comment sécurisons-nous nos scénarios chez Amari Agency ?
Voici un exemple représentatif de notre méthode, sans donnée client ni promesse de résultat garantie.
Une connexion dédiée par client, jamais de clé mutualisée
Sur nos projets d'automatisation, chaque client dispose de ses propres connexions Make, séparées de celles des autres dossiers. Les actions qui touchent à l'argent (facturation, remboursement) ou à la suppression de données passent systématiquement par une étape de validation avant exécution, que le scénario tourne sur Make ou sur n8n.
Que faire en cas de clé API compromise ?
Même avec de bonnes pratiques, un incident peut survenir : dépôt de code public contenant une clé, poste de travail compromis, ancien collaborateur ayant conservé un accès. La rapidité de réaction compte plus que la perfection du diagnostic.
- Révoquer la clé immédiatementDans l'outil connecté (CRM, banque, messagerie), désactiver la clé suspectée avant de chercher à comprendre l'origine de la fuite.
- Générer une nouvelle clé et mettre à jour la connexionRemplacer la clé dans le module Make concerné, sans toucher aux autres connexions non affectées.
- Vérifier l'historique d'exécutionRepérer une activité inhabituelle sur la période où la clé a pu être exposée : volumes anormaux, horaires atypiques.
- Informer les personnes concernées si nécessaireSi des données personnelles ont pu être exposées, une notification peut être exigée par le RGPD selon la gravité de l'incident.
Quels contenus lire ensuite ?
Ces ressources complètent ce guide sans cibler la même requête :
Questions fréquentes sur la sécurité de Make
Make est-il sécurisé pour un usage professionnel ?
Make applique des mesures de sécurité standards côté infrastructure, mais la sécurité réelle d'un scénario dépend surtout de vos propres réglages : connexions dédiées, double authentification et rôles d'équipe bien répartis.
Faut-il activer la double authentification sur tous les comptes Make ?
Oui, c'est la protection la plus simple à mettre en place. Elle empêche qu'un mot de passe volé suffise à accéder à vos scénarios et aux connexions qu'ils contiennent.
Peut-on partager un compte Make entre plusieurs collaborateurs ?
Ce n'est pas recommandé. Un compte partagé empêche de savoir qui a modifié ou déclenché un scénario, ce qui complique l'investigation en cas d'erreur ou d'incident de sécurité.
Comment savoir si une clé API a été compromise ?
Surveillez l'historique d'exécution de vos scénarios et les journaux d'activité de l'outil connecté : un volume d'appels inhabituel ou des actions à des horaires atypiques sont des signaux à vérifier rapidement.
Un scénario Make peut-il traiter des données bancaires en toute sécurité ?
Il vaut mieux éviter de faire transiter des numéros de carte en clair dans un scénario. Privilégiez les jetons fournis par votre prestataire de paiement, qui ne donnent jamais accès au numéro complet.