Les développeurs balaient Make comme la version jouet de n8n. C’est une erreur déguisée en bon goût. Si la personne qui maintient votre pipeline est un profil ops, une assistante virtuelle ou un fondateur qui a écrit sa dernière ligne de code en 2014, un canvas visuel avec du mapping typé et un data store intégré n’est pas une limite — c’est la différence entre un système qu’on modifie et un système qu’on abandonne la semaine où vous partez en vacances. La question n’est jamais de savoir quel outil est le plus puissant. C’est de savoir qui va l’ouvrir un mardi matin.
Choisissez Make quand le goulot, c’est les gens, pas le débit
Make facture à l’opération : chaque module qui tourne sur chaque bundle est une ligne sur la facture. Ce seul fait devrait dicter toute votre conception. Sur un runner auto-hébergé, un appel HTTP de plus ne coûte presque rien, donc on devient négligent et on enrichit tout. Dans Make vous ne pouvez pas vous le permettre, et ça se révèle sain pour la prospection. Ça vous force à disqualifier avant d’enrichir, ce qui est de toute façon le bon ordre, et celui que la plupart des équipes prennent à l’envers.
L’autre raison de le choisir : les data stores, le duo itérateur et agrégateur, les routes de gestion d’erreurs sont des citoyens de première classe, pas des patterns que vous assemblez vous-même. L’historique d’exécution est lisible par un opérateur non technique. La planification, c’est deux clics. Pour un pipeline qui doit être compris par quelqu’un d’autre que son auteur, ça vaut plus cher que la flexibilité brute.
Scénario un : la collecte quotidienne
Un scheduler, réglé une fois par jour à une heure calme. Premier module : une requête HTTP sur /v1/stores/search avec votre clé API dans un header et la réponse parsée en JSON. Gardez les paramètres du filtre dans un unique module Set Variables tout en haut, pour que la personne qui les modifiera le mois prochain n’ait pas à fouiller les panneaux de mapping. Plateforme, pays, fourchette de nombre de produits, bande de trafic — c’est en général tout le filtre.
Appliquez ensuite le pattern compter d’abord. Demandez le total avant de demander les lignes, et posez un filtre sur la connexion : si le total passe sous votre plancher ou dépasse votre plafond, on dévie vers une branche qui vous notifie et s’arrête. Une opération dépensée, des centaines économisées. Le mode de défaillance que ça évite est discret et coûteux — un filtre qui ne matche presque plus rien parce qu’un code pays a changé, et qui tourne joyeusement chaque nuit en produisant un pipeline vide.
La pagination dans Make, c’est un repeater qui envoie des offsets au module HTTP, suivi d’un itérateur qui éclate le tableau renvoyé en bundles individuels. Donnez au repeater un maximum fixe. Les scénarios récursifs qui s’appellent eux-mêmes par webhook sont élégants et finiront par vous échapper à deux heures du matin ; un repeater plafonné, non. L’ennuyeux gagne ici, exactement comme partout ailleurs en opérations.
Le data store, c’est ce qui vous empêche d’écrire deux fois aux mêmes gens
Tous les pipelines no-code se cognent au même mur en semaine deux : les doublons. Make embarque des data stores — des tables clé-valeur à structure fixe — et vous devriez en créer un avec le domaine pour clé, plus des colonnes statut, score, date de première vue et date de dernier contact. Après l’itérateur, un module Get a record cherche le domaine et un filtre ne laisse passer que les bundles dont l’enregistrement est vide, ou dont la date de dernier contact dépasse votre délai de refroidissement.
Cette recherche coûte une opération par boutique, ce qui paraît cher jusqu’à ce que vous chiffriez l’alternative : un marchand qui reçoit votre troisième phrase d’accroche identique en six semaines, et une réputation de domaine que vous passerez le trimestre suivant à réparer. Traitez le data store comme votre source de vérité et recopiez-le vers un tableur pour que des humains le lisent, pas l’inverse. Les tableurs, c’est fait pour regarder ; les data stores, pour décider.
Le second usage du store, c’est l’état. Gardez-y un petit enregistrement avec la dernière page récupérée et la date de la dernière exécution réussie. C’est comme ça qu’un scénario quotidien reprend là où il s’est arrêté sans mémoire propre, et comme ça qu’on récupère proprement après une journée où le scénario était désactivé. L’état dans un store, jamais dans le canvas.
Scénario deux : l’enrichissement derrière un routeur
N’enrichissez pas dans la collecte. Un deuxième scénario, planifié une heure plus tard, sélectionne les lignes à l’état collecté et les éclate à travers un routeur. Chaque route tire les appels profonds dont elle a besoin — /v1/stores/:domain pour la fiche boutique, l’endpoint catalog pour les produits, l’endpoint trend pour l’historique — et un agrégateur fusionne les résultats en un seul bundle par boutique, pour que vous écriviez une fois au lieu de quatre.
Routez par plateforme, parce que le pitch diffère. Avec 58 549 boutiques WooCommerce et 50 002 boutiques Shopify dans la base, plus 16 501 sur PrestaShop et 15 477 sur JouwWeb, vous ne vous adressez pas à un marché — vous vous adressez à plusieurs marchés qui ont en commun de vendre en ligne. Une route WooCommerce peut s’appuyer sur les apps et les moyens de paiement détectés, puisque la prolifération de plugins est un problème réel et diagnosticable. Une route Shopify s’appuie sur la taille du catalogue et le thème. Une troisième route ramasse tout le reste et reçoit le traitement générique.
Placez les disqualifiants pas chers sur les filtres entre le routeur et les modules d’enrichissement, pas après eux. Pas d’email de contact, pas d’enrichissement. Nombre de produits sous votre seuil, pas d’enrichissement. Trafic sous le plancher, pas d’enrichissement. Chaque filtre que vous remontez d’un module supprime toutes les opérations en aval pour ce bundle, et ces économies se cumulent sur quelques milliers de lignes par nuit.
Scénario trois : le guetteur de signaux
L’endpoint trend porte environ 170 points mensuels par boutique, et des données de trafic existent sur 118 324 d’entre elles. Plutôt que de réenrichir toute votre liste, faites tourner un scénario hebdomadaire sur les boutiques que vous connaissez déjà, qui ne tire que le trend et le compare à la dernière valeur stockée. Routez les écarts. C’est le scénario le moins cher de la pile et il produit les meilleures phrases d’accroche que vous enverrez jamais.
Trois signaux méritent une alerte. Une baisse continue — trois mois consécutifs en repli — est un problème dont le marchand a déjà conscience et qu’il n’a probablement pas résolu. Un saut vers le haut signifie budget et urgence, ce qui est une tout autre conversation. Et une nouvelle mention en visibilité IA, suivie sur 118 363 boutiques, vous dit qu’une marque commence à ressortir dans les réponses des IA, ce à quoi la plupart des marchands n’ont pas encore réfléchi une seconde.
Une contrainte d’honnêteté, parce qu’elle détermine ce que vous écrirez ensuite : ce sont des données de recherche organique et de visibilité IA, pas des données publicitaires. Personne dans cette pile ne peut vous dire ce qu’une boutique dépense en publicité ni quelles créas elle diffuse, et quiconque prétend le contraire vous vend une supposition emballée dans une interface sûre d’elle. Ce que vous pouvez dire en vérité, c’est ce qu’a fait la courbe organique d’une boutique et quand elle a changé. C’est largement assez, et c’est vérifiable, ce que la supposition n’est pas.
Gestion d’erreurs : la bonne directive au bon endroit
Make vous donne des directives explicites — resume, rollback, ignore, break, commit — et la discipline consiste à attacher la bonne au bon module plutôt que la même partout. Pour un appel HTTP d’enrichissement, ignore avec une branche de log est en général correct : un domaine mort ne doit pas arrêter le lot. Pour une écriture dans votre data store, rollback, parce qu’une ligne à moitié écrite est pire qu’aucune ligne. Pour un lot qu’il ne faut vraiment pas perdre, break avec stockage des exécutions incomplètes, pour pouvoir corriger la cause et reprendre exactement les bundles en échec.
Réglez ensuite le nombre maximum d’erreurs consécutives, et ne désactivez la coupure automatique que si vous avez réellement du monitoring. Un scénario qui s’est éteint tout seul il y a onze jours est le bug le plus cher de l’automatisation no-code, parce que rien n’est cassé, rien n’alerte, et votre pipeline est simplement vide.
Le calcul des opérations, sans maquillage
Comptabilité approximative par lead pour le pipeline ci-dessus : la collecte amortie sur le lot, une recherche de dédoublonnage, un appel fiche, un appel catalogue, un appel trend, une fusion, une écriture, plus ce que coûte la branche de rédaction. Disons huit à douze opérations par lead qui survit jusqu’à votre boîte de réception. Multipliez par votre volume quotidien avant de choisir un plan, puis calculez combien vous pouvez en enlever en filtrant plus tôt.
L’optimisation la moins chère est toujours un filtre, jamais une montée de plan. Cent domaines disqualifiés par une condition bien placée, ce sont mille opérations que vous ne dépensez jamais. Les équipes qui se trompent là-dessus décrivent en général le problème comme un outil trop cher ; c’est presque toujours un pipeline qui ne trie rien.
Où Make s’arrête et où un humain commence
Même conclusion que pour toutes les autres piles : les scénarios construisent et scorent la liste, une personne valide l’envoi. La file de relecture n’est pas une surcharge, c’est votre boucle de calibrage. Cinq minutes chaque matin à lire des brouillons vous en diront plus sur la justesse de votre filtre qu’un mois de tableaux de bord de taux d’ouverture, parce que vous y verrez les boutiques qui n’auraient jamais dû passer.
Et connaissez votre condition de sortie. Le jour où vous vous surprenez à écrire deux cents lignes de JavaScript dans un module custom pour reformater un payload, Make a cessé d’être le bon outil pour cette étape. Déplacez cette étape-là dans un script ou un moteur de workflow, et gardez le reste là où votre équipe peut le maintenir. Reconnaître ce moment tôt est une vraie compétence opérationnelle, et presque personne ne la pratique.