Connecter ses apps à Make : Gmail, Google Sheets, Notion

Le vrai pouvoir de Make tient en un mot : les connexions. Chaque application reliée démultiplie les automatisations possibles — et une fois le mécanisme compris pour trois outils, vous saurez brancher les 1 500 autres. Dans ce tutoriel complet : ce qu’est réellement une connexion, le fonctionnement d’OAuth (sans jargon), la mise en place détaillée pour Gmail, Google Sheets et Notion, comment connecter une app sans module dédié, le dépannage des erreurs courantes, et les règles de sécurité des professionnels.

Prérequis : un compte Make et l’interface en main (voir créer son compte Make) ainsi qu’un premier scénario construit (voir votre première automatisation). Durée : 20 minutes.

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.

Une connexion, c’est quoi exactement ?

Une connexion est un lien d’autorisation sécurisé entre Make et l’une de vos applications. Le point essentiel, et souvent mal compris : avec les services modernes, vous ne confiez jamais votre mot de passe à Make. Le standard OAuth fonctionne comme un badge d’accès d’immeuble : vous vous identifiez directement chez Google ou Notion, qui remet à Make un « badge » aux permissions limitées — badge que vous pouvez révoquer à tout moment, sans jamais changer votre mot de passe.

Connexion ou module : ne confondez pas

Deux notions reviennent sans cesse, et les distinguer vous évitera bien des confusions :

• Le module est l’action que vous posez sur le canvas : « Watch Emails », « Add a Row », « Send a Message ». C’est le verbe.
• La connexion est l’autorisation qui permet à ce module d’agir sur votre compte. C’est le passe-droit.

Un même compte Gmail (une connexion) peut donc alimenter dix modules différents (lire, envoyer, archiver…) dans autant de scénarios. Vous ne refaites jamais l’autorisation : vous la réutilisez.

Trouver une application dans le catalogue

Make référence plus de 1 500 applications, rangées par catégories. Dans un module, le champ de recherche suffit : tapez les premières lettres (« gmai… ») et l’app apparaît avec la liste de ses actions et déclencheurs disponibles.

Connecter Gmail, pas à pas

Prenons l’app la plus courante. Les gestes sont identiques pour la quasi-totalité des services Google et OAuth :

1. Dans un scénario, ajoutez un module Gmail (n’importe lequel), puis cliquez sur « Add » à côté de Connection.
2. Nommez la connexion explicitement — « Gmail pro — contact@ » — vous vous en féliciterez quand il y en aura six.
3. La fenêtre Google s’ouvre : choisissez le bon compte, lisez les autorisations demandées, puis validez.
4. De retour dans Make, la connexion apparaît en vert : elle est prête, et déjà réutilisable ailleurs.

Connecter Google Sheets

Le plus simple des trois. Ajoutez un module Google Sheets, créez la connexion (ou réutilisez celle de Google si elle couvre déjà Sheets), autorisez, c’est terminé. Vous pouvez désormais lire, ajouter, mettre à jour ou rechercher des lignes — le tableur devient la « base de données du pauvre » de vos automatisations, et c’est un compliment.

Un détail qui fait gagner du temps : Make lit les en-têtes de colonnes de votre feuille pour vous proposer le mapping. Soignez donc la première ligne de vos tableurs (des intitulés clairs : Expéditeur, Objet, Date), tout le reste en découle.

Connecter Notion (le cas particulier instructif)

Notion ajoute une étape que beaucoup ratent — et qui, une fois comprise, règle la majorité des soucis. Après avoir créé la connexion OAuth (mêmes gestes que ci-dessus), il faut partager explicitement chaque base de données avec l’intégration. Lors de l’autorisation, Notion vous demande de sélectionner les pages accessibles : cochez les bases concernées. Si plus tard un module Make « ne voit pas » une base, le remède est toujours le même.

Et pour une app sans module dédié ?

Vous tomberez un jour sur un outil qui n’a pas (encore) son module Make. Pas de panique : si cette application expose une API — et la plupart en ont une — le module universel HTTP permet de s’y connecter quand même. Le principe : vous générez une clé d’API chez l’éditeur de l’app, et vous la fournissez au module HTTP, qui parle alors directement à l’application.

C’est un cran plus technique (on y consacre un article entier dans le module Automatisation avancée), mais retenez dès maintenant le principe : l’absence de module n’est presque jamais un mur. La clé d’API joue ici le rôle du badge OAuth — à conserver précieusement, car elle ouvre votre compte.

Quand ça coince : le dépannage express

Trois messages d’erreur reviennent sans cesse. Voici comment les lire et les corriger en moins d’une minute :

Gérer ses connexions comme un pro

• Nommez clairement : « Gmail pro », « Sheets compta », « Notion CRM » — jamais « Connection 3 ».
• Une connexion par usage : séparez les comptes perso et pro dès le départ.
• Auditez deux fois par an : onglet Connexions → supprimez celles que plus aucun scénario n’utilise.
• Vérifiez côté Google aussi : la page « Sécurité → Applications tierces » de votre compte Google liste tous les badges accordés.

Comprendre OAuth en trois minutes

Quand vous cliquez sur « Se connecter » et qu’une fenêtre Google s’ouvre, vous utilisez OAuth. C’est le mécanisme qui permet à un service d’agir en votre nom sans jamais connaître votre mot de passe. Comprendre son fonctionnement change la façon dont vous lisez les écrans d’autorisation — et vous évite d’accorder machinalement des droits que vous ne vouliez pas donner.

Ce qui se passe réellement

Make vous redirige vers Google. Vous vous authentifiez chez Google, sur le site de Google, avec vos identifiants Google — Make ne voit rien de tout cela. Google vous présente alors la liste des permissions demandées : « lire vos e-mails », « modifier vos feuilles de calcul ». Si vous acceptez, Google remet à Make un jeton : une longue chaîne de caractères qui vaut autorisation, mais qui ne permet pas de se connecter à votre compte autrement.

Trois conséquences pratiques découlent de ce mécanisme.

Changer votre mot de passe ne casse pas la connexion. Le jeton reste valable : il n’a jamais dépendu du mot de passe. C’est le contraire de l’intuition, et cela surprend tout le monde la première fois.

Vous pouvez révoquer sans changer quoi que ce soit. Dans la page de sécurité de votre compte Google, une section liste les applications tierces autorisées. Retirer Make là-bas coupe l’accès instantanément, sans toucher à votre mot de passe ni prévenir Make.

Le jeton a une portée limitée. Il ne donne que les droits affichés à l’écran d’autorisation. Un jeton accordé pour Google Sheets ne permet pas de lire vos e-mails, même si les deux comptes sont le même.

Lisez l’écran d’autorisation, une fois

Nous savons que personne ne le lit. Faites-le au moins la première fois pour chaque nouveau service : c’est le seul moment où l’on vous dit noir sur blanc ce que l’outil pourra faire. Si une ligne vous semble excessive au regard de ce que vous voulez automatiser, elle l’est probablement — et il existe presque toujours un module plus étroit qui demande moins.

Trois modèles d’autorisation, trois façons de connecter

Toutes les applications ne se connectent pas de la même manière. Il en existe trois familles, et savoir laquelle vous avez en face vous fait gagner un temps considérable au moment du dépannage.

Le modèle « compte entier »

C’est celui de Gmail, de Google Sheets, de Slack. Vous vous connectez avec votre compte, et l’autorisation couvre l’ensemble de ce que ce compte peut atteindre. Simple à mettre en place, mais large : si votre compte Google a accès à quarante fichiers partagés, la connexion aussi.

Le bon réflexe pour restreindre : créer un compte dédié à l’automatisation, et ne partager avec lui que les fichiers concernés. Le partage devient alors votre système de permissions.

Le modèle « ressource par ressource »

C’est celui de Notion, et il déroute beaucoup de débutants. Autoriser Make ne suffit pas : il faut ensuite, dans Notion, partager explicitement chaque base avec l’intégration. Une base non partagée reste invisible, sans le moindre message d’erreur — Make affiche simplement une liste vide.

C’est plus sûr, et c’est aussi la cause n°1 des « ma base n’apparaît pas ». Quand une liste est vide alors que la connexion est verte, la question à se poser est toujours : ai-je partagé cette ressource avec l’intégration ?

Le modèle « clé d’API »

Pas de fenêtre de connexion : le service vous donne une clé, vous la collez dans Make. C’est le modèle des outils techniques et de beaucoup de services professionnels. Il est plus brutal — la clé donne souvent tous les droits — mais il a un avantage : on peut en générer plusieurs, et en révoquer une sans toucher aux autres.

Quand il n’y a pas de bouton « Se connecter » : les clés d’API

Vous arrivez sur l’écran de connexion et Make vous demande une « API Key », un « Token » ou un couple identifiant/secret. Pas de panique : c’est plus simple que la fenêtre OAuth, seulement moins guidé.

Où trouver la clé

Elle est toujours au même endroit, à quelques mots près : dans les réglages du service, une section « API », « Développeurs », « Intégrations » ou « Jetons d’accès ». Vous y générez une nouvelle clé, vous lui donnez un nom explicite — mettez « Make » plutôt que « test1 » — et vous la copiez.

Le point critique : elle ne s’affiche qu’une fois

La plupart des services n’affichent la clé complète qu’au moment de sa création. Ensuite, ils n’en montrent que les derniers caractères. Si vous fermez la fenêtre sans copier, il faut en générer une nouvelle. Collez-la donc directement dans Make, dans la foulée : c’est le seul endroit où elle doit finir.

Ce qu’il ne faut jamais faire d’une clé d’API

Ne l’envoyez jamais par e-mail ni par messagerie, même à vous-même : une clé qui traîne dans une boîte de réception est une clé exposée. Ne la stockez pas dans un document partagé. Et ne la réutilisez pas pour un autre outil : une clé par usage, c’est ce qui vous permettra de couper un accès sans casser les autres.

Si vous pensez qu’une clé a fuité, la marche à suivre est toujours la même et elle prend deux minutes : générez-en une nouvelle dans le service, remplacez-la dans la connexion Make, puis révoquez l’ancienne. Dans cet ordre : en révoquant d’abord, vous cassez vos scénarios entre les deux opérations.

Le principe du moindre privilège, appliqué concrètement

La règle de sécurité tient en une phrase : une connexion ne doit pouvoir faire que ce dont vos scénarios ont besoin. Elle paraît théorique ; elle se traduit par quatre gestes très concrets.

Choisir le module le plus étroit

Beaucoup de services proposent plusieurs niveaux d’accès. Quand Make vous laisse le choix entre une portée « lecture seule » et une portée complète, prenez la lecture seule si votre scénario ne fait que lire. Vous pourrez toujours créer une seconde connexion en écriture le jour où vous en aurez besoin.

Créer un compte de service

Pour les usages sérieux, ouvrez un compte dédié — automatisation@votredomaine.fr — et partagez-lui uniquement les ressources concernées. Trois bénéfices immédiats : la portée est naturellement limitée, vous voyez dans les historiques ce qui a été fait par l’automatisation plutôt que par vous, et le départ d’un collaborateur ne casse rien.

Séparer les environnements

Une connexion pour les tests, une autre pour la production. Cela vous évite le scénario classique : un essai qui écrit dans le vrai fichier client parce que la connexion était la même et que le fichier a été sélectionné trop vite.

Faire le ménage deux fois par an

Ouvrez la liste de vos connexions et supprimez celles qui ne servent plus. Une connexion inutilisée ne coûte rien, mais elle reste une porte ouverte — et une porte dont vous avez oublié l’existence. Le même ménage se fait côté service, dans la page des applications autorisées : vous y trouverez souvent des accès accordés il y a deux ans à des outils que vous n’utilisez plus.

Ce qui casse une connexion, et quand cela arrive

Une connexion qui fonctionne depuis six mois peut tomber du jour au lendemain. Voici les causes réelles, par fréquence décroissante, et ce qu’elles ont de reconnaissable.

La révocation manuelle. Quelqu’un — souvent vous — a retiré l’autorisation dans les réglages du service. Symptôme : tous les scénarios utilisant cette connexion tombent en même temps, avec une erreur d’authentification. C’est la cause la plus fréquente et la plus facile à corriger : il suffit de reconnecter.

Le retrait du partage. Spécifique au modèle « ressource par ressource ». Symptôme : un seul scénario tombe, ou pire, il ne tombe pas mais ne trouve plus rien. C’est le cas le plus sournois, parce qu’un scénario qui traite zéro paquet ressemble à un scénario qui fonctionne.

L’expiration du jeton. Certains services imposent une durée de vie, souvent de plusieurs mois. Symptôme : une panne à date fixe, sans que rien n’ait changé de votre côté.

Le changement de plan chez le fournisseur. L’accès à l’API est parfois réservé aux formules payantes. Symptôme : la connexion existe, mais chaque appel renvoie une erreur de droits.

La limite de débit. Ce n’est pas une rupture, mais cela y ressemble : le service refuse temporairement les appels parce que vous en faites trop. Symptôme : des erreurs intermittentes, aux heures de pointe seulement. Le bon réflexe n’est pas de reconnecter, mais d’espacer les appels ou de poser un gestionnaire « Retry ».

Le réflexe qui coupe court au diagnostic

Avant toute chose, ouvrez la connexion dans Make et cliquez sur « Verify ». Le service répond, ou pas. Si la vérification passe, le problème est ailleurs — dans votre mapping, votre filtre ou vos droits sur une ressource précise. Si elle échoue, vous savez que vous cherchez du côté de l’autorisation. Trente secondes qui vous font gagner une demi-heure.

Connexions et travail à plusieurs

La question arrive dès qu’une deuxième personne touche aux scénarios, et elle a une réponse claire.

Une connexion appartient à l’organisation Make, pas à la personne qui l’a créée. Concrètement, un collègue qui ouvre votre scénario peut le faire tourner avec votre connexion, donc écrire dans votre Drive et envoyer des e-mails depuis votre adresse — sans jamais avoir eu vos identifiants.

Ce n’est ni un défaut ni une faille : c’est le fonctionnement normal, et c’est ce qui permet à une automatisation de survivre à vos vacances. Mais cela impose deux règles.

Ne connectez jamais un compte personnel pour un usage professionnel partagé. Votre boîte mail personnelle n’a rien à faire dans un scénario d’équipe. Le compte de service évoqué plus haut règle la question définitivement.

Anticipez les départs. Le jour où la personne qui avait connecté son compte quitte l’entreprise et que son compte est fermé, tous les scénarios qui en dépendaient s’arrêtent. Faites l’inventaire une fois par an : quelle connexion appartient à qui, et que se passe-t-il si cette personne part demain ? Cinq minutes d’inventaire valent mieux qu’une semaine d’arrêt en pleine saison.

Déplacer un scénario vers un autre compte

Vous changez d’adresse professionnelle, vous passez d’un compte personnel à un compte d’entreprise, ou vous confiez la maintenance à quelqu’un d’autre. La bascule est simple si vous la faites dans le bon ordre.

1. Créez la nouvelle connexion à côté de l’ancienne. Ne supprimez rien : dans Make, plusieurs connexions vers le même service coexistent sans problème. Nommez-les clairement pour ne pas les confondre.

2. Assurez-vous que le nouveau compte a bien les accès. Partagez les fichiers, les bases et les dossiers concernés avec lui avant de basculer. C’est l’étape que l’on oublie, et elle produit un scénario vert qui ne trouve rien.

3. Changez la connexion module par module. Chaque module a son propre sélecteur de connexion : il faut les passer un par un. Profitez-en pour vérifier que la ressource sélectionnée est toujours la bonne : changer de compte remet parfois le choix du fichier à zéro.

4. Testez avec « Run once » avant de réactiver. Un essai à vide sur une destination de test coûte deux opérations et vous évite d’écrire trois cents lignes au mauvais endroit.

5. Supprimez l’ancienne connexion en dernier. Une fois que tout tourne depuis quelques jours. Make vous préviendra si un scénario l’utilise encore : c’est votre filet de sécurité, ne le retirez pas trop tôt.

La check-list de la connexion réussie

Gardez cette liste sous la main : elle couvre les six vérifications qui séparent une connexion qui tiendra deux ans d’une connexion qu’il faudra reprendre dans quinze jours.

Le bon compte. Vérifiez, dans la fenêtre d’autorisation, l’adresse affichée en haut. Un navigateur connecté à trois comptes Google propose le dernier utilisé, pas celui que vous vouliez. C’est l’erreur la plus bête et la plus fréquente : on s’en aperçoit trois semaines plus tard, quand les e-mails partent de la mauvaise adresse.

Un nom explicite. Renommez la connexion immédiatement après l’avoir créée. « Google Sheets — comptabilité 2026 » vous parlera encore dans un an ; « My Google Restricted connection » ne vous a jamais rien dit.

Le partage de la ressource. Pour tout service du modèle « ressource par ressource », partagez la base, le dossier ou le fichier avant de revenir dans Make. Sinon la liste sera vide et vous chercherez du côté de la connexion, qui n’y est pour rien.

Le test « Verify ». Un clic, une réponse. Faites-le tout de suite, tant que le contexte est frais : si quelque chose cloche, vous savez exactement ce que vous venez de faire.

Un module d’essai. Exécutez un module en lecture seule — lister les fichiers, lire une ligne — avant de construire quoi que ce soit. Une connexion valide qui ne voit aucune donnée est un cas courant, et il vaut mieux le découvrir maintenant.

Une note. Dans les notes du scénario, écrivez quel compte est utilisé et pourquoi. Le jour où quelqu’un d’autre reprendra le dossier — ou le jour où vous l’aurez oublié — cette ligne vaudra une heure de recherche.

Ces six points prennent trois minutes à la création et vous épargnent l’essentiel des pannes que nous voyons en audit. Une connexion bien posée est une connexion dont vous n’entendrez plus jamais parler : c’est exactement l’objectif.

FAQ — vos questions fréquentes

Que se passe-t-il si je change mon mot de passe Google ?

Rien : le badge OAuth de Make reste valable, car il ne dépend pas de votre mot de passe. C’est tout l’intérêt du mécanisme. En revanche, révoquer l’accès (depuis Google ou Make) coupe immédiatement la connexion.

Combien de connexions puis-je créer ?

Autant que nécessaire, sur tous les plans, y compris gratuit. La seule limite pratique est la lisibilité : d’où l’importance d’un nommage discipliné et d’un audit régulier.

Une app sans module Make peut-elle quand même être connectée ?

Souvent oui, via le module HTTP et la clé d’API de l’application. C’est un cran plus technique, mais cela signifie qu’aucune app dotée d’une API n’est réellement hors de portée — le module Automatisation avancée y consacre un article entier.

Make peut-il lire TOUS mes e-mails avec une connexion Gmail ?

Make ne lit que ce que vos scénarios demandent (le dossier surveillé, les messages correspondant aux critères). Le badge OAuth définit le périmètre technique maximal, vos scénarios définissent l’usage réel — et l’historique d’exécutions en garde la trace.

Faut-il recréer la connexion sur chaque nouveau scénario ?

Non, jamais. Une connexion est globale à votre compte Make : vous la sélectionnez dans une liste déroulante à chaque nouveau module. C’est tout l’intérêt — une autorisation, des usages illimités.

Puis-je connecter deux comptes Gmail différents ?

Oui, autant que vous voulez. Chaque connexion est indépendante ; nommez-les explicitement (« Gmail — contact@ », « Gmail — perso ») car par défaut Make les appelle toutes « Google Restricted » et vous ne les distinguerez plus au bout de trois. Le sélecteur de connexion apparaît dans chaque module : un même scénario peut lire dans une boîte et écrire depuis une autre.

Ma connexion est verte mais mon scénario ne trouve rien. Pourquoi ?

Dans neuf cas sur dix, la connexion fonctionne mais le compte connecté n’a pas accès à la ressource visée : une base Notion non partagée avec l’intégration, un fichier Drive appartenant à quelqu’un d’autre, un dossier auquel le compte de service n’a pas été invité. Vérifiez les droits côté service, pas côté Make : une autorisation valide et un accès à la donnée sont deux choses différentes.

Est-ce que Make conserve mes mots de passe ?

Non, et c’est tout l’intérêt d’OAuth : vous saisissez votre mot de passe sur le site du service, jamais sur Make, qui ne reçoit qu’un jeton d’accès révocable. Pour les connexions par clé d’API, Make stocke la clé de façon chiffrée ; elle n’est plus affichée en clair une fois enregistrée. Dans les deux cas, vous gardez la main : révoquer côté service coupe l’accès immédiatement.

Faut-il refaire la connexion après chaque mise à jour du service ?

Non dans la grande majorité des cas. La reconnexion n’est nécessaire que lorsque le fournisseur modifie les permissions demandées — Make affiche alors un avertissement explicite sur la connexion concernée. Si aucun avertissement n’apparaît et que vos scénarios tournent, il n’y a rien à faire : une connexion qui fonctionne n’a pas besoin d’entretien.

En résumé

Une connexion = un badge sécurisé, créé une fois, réutilisé partout, révocable toujours. Gmail et Sheets se branchent en deux clics, Notion demande le partage explicite des bases, et le module HTTP ouvre la porte à tout le reste. Vos outils sont reliés — il ne reste qu’à comprendre ce que tout cela coûte (spoiler : très peu, bien géré).