Make (Integromat) : guide pour les workflows marketing sans code

Make est une plateforme d’automatisation no-code qui relie des applications entre elles à travers des scénarios visuels : un déclencheur, une suite de modules, des règles de routage et de filtrage. Anciennement appelée Integromat, elle a pris le nom de Make en 2022. Pour une équipe marketing ou SEO, son intérêt tient à trois points : un éditeur visuel qui rend la logique lisible, un catalogue d’applications étendu (Google Search Console, Notion, Slack, LinkedIn, OpenAI, entre autres) et un contrôle fin des données qui transitent d’un outil à l’autre. Ce guide explique comment fonctionne un scénario, détaille trois cas d’usage marketing (veille, publication sur les réseaux sociaux, alertes SEO), les coûts et limites à anticiper, puis les critères pour choisir entre Make et n8n.

01Make (ex-Integromat) : ce qu’est l’outil et à qui il s’adresse

Make appartient à la famille des plateformes d’intégration et d’automatisation (iPaaS), aux côtés de Zapier et de n8n. Le principe est simple : quand un événement survient dans une application (nouvelle ligne dans un Google Sheet, formulaire soumis, article publié), Make exécute une série d’actions dans d’autres applications, sans que vous écriviez de code. Integromat est devenue Make en 2022, et la plateforme fait aujourd’hui partie de Celonis, éditeur de logiciels de process mining.

L’outil s’adresse aux profils marketing, growth, contenu et SEO qui veulent automatiser sans dépendre d’une équipe technique, mais qui acceptent de manipuler des structures de données : tableaux, objets JSON, mappage de champs entre deux applications. Make est plus exigeant que Zapier sur ce point, et moins que n8n dès qu’il faut écrire du code ou héberger soi-même l’outil. C’est souvent le bon compromis pour une équipe marketing qui a dépassé les automatisations linéaires mais ne dispose pas de développeur.

Il faut aussi savoir ce que Make ne fait pas. Ce n’est ni un CRM, ni un outil d’analyse, ni un entrepôt de données : il déplace et transforme des informations entre des outils qui, eux, les stockent et les exploitent. Si vos données de départ sont incomplètes ou mal structurées, Make les transportera telles quelles, plus vite. Un scénario n’améliore pas un processus mal défini : il le rend simplement plus rapide et plus difficile à corriger.

02Les briques d’un scénario Make

Comprendre ces briques évite la plupart des scénarios fragiles ou coûteux. Elles sont communes à tous les cas d’usage présentés plus bas.

Modules, déclencheurs et planification

Un scénario est une chaîne de modules. Le premier est le déclencheur : un module de surveillance qui interroge une application à intervalle régulier (par exemple les nouvelles lignes d’une feuille de calcul), un webhook qui reçoit des données instantanément, ou une simple planification (tous les lundis à 8 h). Sur l’offre gratuite, l’intervalle minimal entre deux exécutions planifiées est de 15 minutes ; les offres payantes permettent de descendre à la minute. Chaque module suivant exécute une action : lire, rechercher, créer, mettre à jour, supprimer ou transformer des données.

Routeurs, filtres, itérateurs et agrégateurs

• Filtre : condition placée entre deux modules. Si elle n’est pas remplie, l’exécution s’arrête pour ce lot de données. Exemple : ne traiter que les pages dont les clics ont nettement baissé.
• Routeur : divise le flux en plusieurs branches, chacune avec son propre filtre. Exemple : un article publié part vers LinkedIn s’il appartient à la catégorie « étude », vers la newsletter sinon.
• Itérateur : découpe un tableau en éléments traités un par un, comme chaque URL d’une liste ou chaque entrée d’un flux RSS.
• Agrégateur : réassemble des éléments en un seul paquet, par exemple pour envoyer un message récapitulatif au lieu de vingt notifications séparées.

La maîtrise du couple itérateur et agrégateur fait la différence entre un scénario qui envoie une alerte par ligne, vite ignorée, et un rapport lisible que l’équipe consulte réellement.

Gestion des erreurs et stockage de données

Make permet d’attacher à un module des gestionnaires d’erreurs (Skip, Resume, Commit, Rollback, Retry) : ignorer l’erreur, reprendre avec une valeur de secours, valider ou annuler les opérations déjà effectuées, ou relancer l’exécution plus tard. Les data stores offrent une petite base de données interne, utile pour mémoriser ce qui a déjà été traité et éviter les doublons : une URL déjà signalée, un article déjà publié, une alerte déjà envoyée. Sans cette mémoire, un scénario de veille renvoie les mêmes éléments à chaque exécution.

03Cas d’usage marketing : veille, réseaux sociaux, alertes SEO

Trois familles de scénarios couvrent la majorité des besoins d’une équipe marketing. Pour chacune, la logique est décrite module par module, à adapter à vos outils et à vos volumes.

Veille automatisée vers Notion

1. Déclencheur : module RSS qui surveille les flux de vos sources (blogs spécialisés, médias, pages d’actualité des outils que vous utilisez).
2. Filtre : mots-clés à inclure (marques, concurrents, thématiques suivies) et à exclure.
3. Dédoublonnage : vérification dans un data store que l’URL n’a pas déjà été traitée.
4. Résumé : module OpenAI ou d’un autre fournisseur de LLM, avec une consigne courte : trois lignes de résumé, une catégorie, un niveau d’impact estimé.
5. Stockage : création d’une page dans une base Notion avec titre, lien, date, résumé et catégorie.
6. Diffusion : agrégateur hebdomadaire qui envoie un récapitulatif dans Slack ou par email.

Appliqué à la veille SEO, ce scénario gagne à partir des sources officielles : le flux du blog Google Search Central pour les annonces et les changements de documentation, et le flux du Google Search Status Dashboard pour les mises à jour de classement et les incidents. Ajoutez-y les blogs et changelogs des outils que vous utilisez (Search Console, crawler, outil de backlinks), puis quelques médias spécialisés. Dans le scénario, un routeur sépare deux familles : les annonces à traiter rapidement (mise à jour de classement, incident d’indexation, changement de documentation), envoyées dans un canal d’alerte, et le reste, stocké dans la base Notion pour le récapitulatif hebdomadaire. Avant de l’activer, estimez sa consommation avec la méthode présentée plus bas pour savoir s’il reste compatible avec l’offre gratuite.

Publication et diffusion sur les réseaux sociaux

Make relie votre CMS ou votre calendrier éditorial aux réseaux sociaux. À la publication d’un article (flux RSS, webhook WordPress ou ligne passée au statut « prêt » dans un tableau), le scénario récupère le titre, l’image et l’URL, génère éventuellement une proposition de texte avec un LLM, puis la dépose en brouillon ou la publie sur LinkedIn. Gardez une validation humaine : un statut « validé » dans le tableau éditorial, contrôlé par un filtre, évite de diffuser un texte généré sans relecture. Ajoutez des paramètres UTM aux liens pour mesurer dans GA4 le trafic issu de chaque réseau et de chaque format.

Alertes SEO avec Google Search Console et Ahrefs

L’application Google Search Console de Make compte sept modules, dont l’exécution d’un rapport de performances, l’inspection d’une URL, la liste et la soumission des sitemaps, ainsi qu’un module d’appel libre à l’API. De quoi construire des alertes utiles :

• Baisse de clics : chaque lundi, le scénario compare les clics des sept derniers jours à la période précédente, page par page, filtre les baisses significatives et envoie la liste agrégée dans Slack.
• Indexation : pour une liste d’URL stratégiques stockée dans un Google Sheet, un itérateur lance l’inspection d’URL et signale celles qui ne sont pas indexées. L’inspection est soumise à un quota côté Google, 2 000 requêtes par jour et par propriété : réservez-la à vos pages clés.
• Sitemaps : vérification que le sitemap principal a été lu récemment et ne remonte pas d’erreurs.

Soignez le format du message final : c’est lui qui détermine si l’alerte sera lue. Un bon récapitulatif tient en quelques lignes : la période comparée, les cinq pages dont les clics ont le plus baissé avec l’écart constaté, les URL stratégiques non indexées et un lien vers le tableau de bord complet. Au-delà, l’équipe cesse de lire. Côté IA, les rapports « performances IA générative » de Search Console, déployés dans le monde le 31 août 2026, ne fournissent que des impressions, sans clics ni requêtes. L’aide Search Console décrit un export de ces données sans mentionner d’accès par l’API : consultez la documentation de l’API avant de bâtir un scénario Make sur ce rapport, et prévoyez à défaut un export manuel mensuel.

Côté Ahrefs, le module HTTP de Make permet d’appeler directement l’API v3 avec votre clé. Chaque requête consomme des unités API, avec un minimum de 50 unités par requête selon la documentation Ahrefs : limitez la fréquence et le nombre de lignes demandées, par exemple un suivi hebdomadaire des domaines référents perdus plutôt qu’un appel quotidien sur l’ensemble du profil de liens.

04Crédits, coûts et limites à anticiper

Make décompte l’usage en crédits. Selon sa page tarifs, chaque action de module, comme l’ajout d’une ligne dans Google Sheets ou la récupération de données Gmail, compte pour un crédit. Les modules d’IA peuvent en consommer davantage, et l’exécution de code via la Code App est facturée au temps : 2 crédits par seconde d’exécution. L’offre gratuite inclut jusqu’à 1 000 crédits par mois, deux scénarios actifs au maximum et un intervalle minimal de 15 minutes. Les offres payantes (Core, Pro, Teams, Enterprise) autorisent une planification à la minute.

Estimez la consommation avant de construire. Un scénario dont cinq modules traitent chacun 50 éléments par jour consomme environ 5 × 50 × 30 = 7 500 crédits par mois, déclencheur non compris. Trois leviers réduisent cette consommation :

• placer les filtres le plus tôt possible, pour que les éléments inutiles ne traversent pas toute la chaîne ;
• agréger avant d’envoyer, pour remplacer vingt actions par une seule ;
• adapter la fréquence au besoin réel : une veille n’a pas besoin de tourner toutes les quinze minutes.

Deux limites structurelles sont à garder en tête. D’une part, un scénario dépend des API des applications connectées : quand l’une d’elles évolue, un module peut cesser de fonctionner, d’où l’importance des notifications d’erreur. D’autre part, les données transitent par l’infrastructure de Make : si elles contiennent des données personnelles, vérifiez la région d’hébergement de votre organisation et les engagements contractuels de traitement avec votre DPO.

05Make ou n8n : critères de choix

Les deux outils couvrent des besoins proches, et la question « lequel est le meilleur » n’a pas de réponse universelle. Les différences qui pèsent réellement dans la décision :

• Hébergement : n8n peut être auto-hébergé sur votre propre serveur, alors que Make est proposé en SaaS. Pour des données sensibles ou des volumes importants, ce point est souvent décisif.
• Code : n8n intègre des nœuds de code au cœur des workflows ; Make propose une Code App facturée au temps d’exécution.
• Modèle de coût : Make compte chaque action de module, alors que n8n facture ses offres cloud à l’exécution, quel que soit le nombre d’étapes du workflow. Un scénario long et fréquent coûte donc proportionnellement plus cher sur Make.
• Profil de l’équipe : Make convient bien à une équipe marketing autonome qui veut un éditeur visuel structuré ; n8n prend l’avantage dès que les workflows intègrent de la logique métier, des agents IA ou des appels API complexes.

Pour aller plus loin, le comparatif n8n, Make et Zapier pour choisir son outil d’automatisation détaille les critères un par un, y compris les cas où la simplicité de Zapier l’emporte. Si vous envisagez des workflows plus techniques, la page dédiée à l’automatisation avec n8n présente l’approche retenue pour les projets SEO et marketing.

06Bonnes pratiques pour des workflows fiables

• Cartographier avant de construire : décrivez le processus actuel, ses étapes, ses données et ses exceptions. La méthode est détaillée dans l’article sur la façon de cartographier et optimiser ses processus avant de les automatiser.
• Un scénario, une responsabilité : mieux vaut trois scénarios courts qu’un seul qui fait tout et devient impossible à déboguer.
• Nommer et documenter : nom explicite pour chaque scénario et chaque module, propriétaire désigné, objectif, applications connectées et consommation estimée.
• Tester sur un petit jeu de données : exécution unique sur quelques éléments, vérification du résultat dans l’application cible, puis activation.
• Prévoir les erreurs : gestionnaire d’erreur sur les modules critiques et notification dans un canal suivi.
• Utiliser des connexions d’équipe : évitez de brancher les scénarios sur le compte personnel d’un collaborateur, qui peut partir ou changer de mot de passe.
• Faire une revue trimestrielle : désactivez les scénarios qui ne servent plus et vérifiez que la consommation de crédits reste cohérente avec la valeur produite.

Dernier point, souvent négligé : la sécurité des connexions. Chaque application branchée sur Make dispose d’un accès à vos données, parfois en écriture. Limitez les droits accordés au strict nécessaire, supprimez les connexions inutilisées et conservez une liste des scénarios qui manipulent des données clients ou des accès sensibles (CMS, CRM, régie publicitaire).

Pour démarrer, choisissez un processus répétitif, bien délimité et mesurable, comme la veille ou le récapitulatif hebdomadaire Search Console. Un premier scénario simple, documenté et suivi apporte plus qu’une automatisation ambitieuse que personne ne sait maintenir.