Make iterator vs aggregator : la différence enfin claire

Si tu construis des scénarios Make depuis plus de deux semaines, tu as déjà eu cette frustration : tu reçois un tableau, tu veux le traiter ligne par ligne, mais le module suivant te renvoie une seule itération avec le premier élément seulement. Ou pire : tu boucles, tout fonctionne, mais tu envoies 47 emails au lieu d’un seul email récapitulatif. Le problème ? Tu n’as pas compris la différence entre iterator et aggregator. C’est probablement le concept le plus mal expliqué de la documentation officielle, et pourtant c’est la fondation de 80 % des scénarios Make sérieux.

Dans ce guide, je vais te montrer exactement quand utiliser l’un, quand utiliser l’autre, comment les combiner, et surtout les six erreurs classiques qui font exploser tes opérations Make (et ta facture mensuelle). À la fin, tu sauras lire un scénario Make comme une partition.

Comprendre la logique des bundles dans Make

Avant même de parler iterator ou aggregator, il faut comprendre un mot : bundle. Dans Make, un bundle est l’unité de base qui circule entre les modules. Imagine une chaîne de production : chaque bundle est un colis qui voyage de module en module. Chaque colis contient un ou plusieurs paquets (les variables).

Quand un module produit plusieurs bundles, Make exécute les modules suivants une fois par bundle. C’est ce qu’on appelle l’exécution en parallèle séquentiel : visuellement c’est une seule ligne, mais en réalité Make boucle. Si ton module Google Sheets “Search Rows” retourne 15 lignes, ce sont 15 bundles, et les modules suivants vont s’exécuter 15 fois.

Ce détail change tout. Beaucoup de débutants pensent qu’un tableau est forcément traité élément par élément automatiquement. Faux. Un module qui retourne un seul bundle contenant un tableau ne déclenche pas de boucle. Pour boucler sur ce tableau, il te faut un iterator.

À l’inverse, si tu as déjà 15 bundles et que tu veux les recombiner en un seul (pour envoyer un email récapitulatif, pour créer un seul fichier CSV, pour faire un seul appel API), il te faut un aggregator. Iterator décompose, aggregator recompose. C’est aussi simple que ça en théorie.

L’iterator : exploser un tableau en bundles

L’iterator est un module utilitaire situé dans la catégorie “Flow Control”. Il prend en entrée un bundle contenant un tableau, et produit autant de bundles que d’éléments dans le tableau. C’est exactement comme un forEach en JavaScript ou un for en Python.

Cas d’usage typique : tu reçois un webhook avec un payload qui contient {"orders": [...]} où orders est un tableau de 12 commandes. Sans iterator, tu peux accéder à 1.orders[1].customer_name mais pas itérer dessus. Avec iterator, tu configures le champ “Array” sur {{1.orders}} et boum, 12 bundles sortent avec chacun les propriétés customer_name, total, items, etc.

Erreurs classiques avec l’iterator :

• Cibler une variable qui n’est pas un tableau. Si tu pointes l’iterator sur un objet ou une chaîne, il te renverra zéro bundle ou une erreur “Array Expected”.
• Oublier que les opérations comptent. Un iterator qui produit 1000 bundles fait passer ton scénario à 1000 opérations sur les modules suivants. Sur le plan Core (10 000 ops/mois), un seul gros iterator peut bouffer 10 % de ton quota.
• Mettre un iterator alors qu’un mapping suffisait. Si tu veux juste afficher le premier élément d’un tableau, {{1.orders[1].total}} suffit. Pas besoin d’itérer.

Astuce pro : si ton tableau est imbriqué (response.data.results.items), accède-le directement dans l’iterator. Et si ta source ne retourne pas vraiment un tableau mais une chaîne JSON, passe d’abord par un module “Parse JSON”.

L’aggregator : recombiner des bundles en un seul

L’aggregator est l’opération inverse. Il prend plusieurs bundles en entrée et produit un seul bundle en sortie. Make propose plusieurs aggregators selon le format de sortie souhaité :

• Array Aggregator : recompose en un tableau (idéal pour renvoyer une réponse API)
• Text Aggregator : concatène en une chaîne de caractères avec un séparateur (parfait pour un email récapitulatif)
• Numeric Aggregator : fait une somme, moyenne, min, max
• Table Aggregator : produit un tableau HTML (utile pour les emails formatés)
• CSV Aggregator : produit une chaîne CSV
• JSON Aggregator : produit un objet JSON structuré

La configuration la plus importante de tout aggregator : le champ “Source Module”. Tu dois indiquer à quel module précédent l’aggregator se rattache. Make a besoin de savoir à partir d’où compter les bundles à grouper. Si ton scénario fait Webhook → Iterator → HTTP → Aggregator, le source module de l’aggregator doit être l’iterator (ou un module entre iterator et aggregator).

Combiner iterator et aggregator : le pattern de base

Le pattern le plus puissant de Make, celui qu’on retrouve dans 70 % des scénarios bien construits, c’est la combinaison iterator → traitement → aggregator. Exemple concret :

1. Tu reçois une commande Shopify avec 8 lignes de produits.
2. Tu mets un iterator sur line_items pour traiter chaque produit séparément.
3. Pour chaque produit, tu appelles ton ERP en HTTP pour vérifier le stock.
4. Tu agrèges les résultats en un tableau via un Array Aggregator.
5. Tu envoies un seul email récapitulatif au client.

Sans cette double étape, tu aurais soit zéro vérification (pas d’iterator) soit 8 emails au client (pas d’aggregator). C’est exactement ce genre de logique qu’on déploie quand on construit un système de 3 workflows interconnectés pour un e-commerce qui scale.

Visuellement dans Make, tu vois bien le “tunnel” se créer : entre l’iterator et l’aggregator, les modules sont parcourus N fois. Avant l’iterator et après l’aggregator, on est à 1 exécution. C’est cette respiration qui te permet d’optimiser tes opérations.

Six erreurs qui coûtent cher en opérations Make

J’audite régulièrement des comptes Make qui consomment trois fois trop d’opérations, et 90 % du temps c’est lié à une mauvaise utilisation d’iterator ou d’aggregator. Voici les pièges les plus fréquents.

1. Iterator suivi d’un module HTTP qui pourrait être batché

Si l’API que tu appelles accepte un payload batch (ex : POST /users/bulk-create), n’itère pas. Construis directement le tableau, fais un seul appel, parse la réponse. Tu passes de 200 opérations à 3.

2. Aggregator mal sourcé

Si tu sources ton aggregator sur le mauvais module, soit il agrège trop (toute l’historique du scénario), soit il agrège un seul bundle (rien à grouper). Vérifie toujours dans les paramètres avancés que “Source Module” pointe sur ton iterator.

3. Iterator sur un tableau vide

Make facture l’opération de l’iterator même si le tableau est vide. Toujours mettre un filter avant l’iterator du type length({{1.array}}) > 0. Bonus : le scénario est plus lisible.

4. Double iterator imbriqué non nécessaire

Si tu as deux iterators successifs, tu fais N × M opérations. Parfois c’est inévitable, mais souvent un seul iterator avec un mapping JSON plus malin suffit.

5. Aggregator inutile suivi d’un nouvel iterator

Un classique : tu agrèges en array, puis tu re-itères dessus. Si rien ne se passe entre les deux, tu peux supprimer les deux modules.

6. Pas de filter dans la boucle

Dans une boucle iterator, tu peux poser un filter au milieu (par exemple “ne traiter que les produits en stock”). C’est beaucoup plus efficace que de filtrer après l’aggregator.

Cas avancé : agrégation par groupe

Tu as 50 commandes appartenant à 15 clients différents, et tu veux envoyer un email par client avec ses commandes. Pattern :

1. Iterator sur les 50 commandes.
2. Array Aggregator avec le paramètre “Group by” réglé sur {{customer_id}}.
3. En sortie, tu obtiens 15 bundles, chacun contenant un tableau de commandes pour ce client.
4. Pour chaque bundle, tu envoies un email personnalisé.

Cette fonctionnalité “Group by” est sous-documentée mais transformatrice. Elle te permet de faire en 3 modules ce qui prendrait 8 modules autrement, et de diviser tes opérations par 3 ou 4.

Quand utiliser un Text Aggregator plutôt qu’un Array

Le Text Aggregator est ton meilleur ami pour les emails et les notifications Slack. Plutôt que d’envoyer un tableau brut, tu construis directement une chaîne formatée :

• Item Format : ce que tu veux pour chaque ligne (ex : - {{name}} : {{price}}€)
• Separator : entre chaque ligne (généralement \n pour un retour à la ligne)

Résultat : tu passes ton aggregator dans le corps de ton email, et tu obtiens une liste à puces propre. Pas besoin de boucler côté HTML, pas besoin de template engine externe.

Performance et coût : ce qu’il faut surveiller

Sur le plan Core de Make (10€/mois, 10 000 opérations), un mauvais design iterator/aggregator peut multiplier ta consommation par 10. Quelques règles d’or :

• Compte les opérations à blanc. Lance ton scénario une fois, regarde la facture en bas à droite. Si tu vois 300 ops pour un trigger qui devrait coûter 10, tu as un problème.
• Mets toujours un filter avant l’iterator pour ne pas itérer sur des tableaux vides ou non pertinents.
• Utilise les routes et les filters plutôt que des branches conditionnelles dans une boucle, car les filters ne consomment pas d’opérations (contrairement à un module Router).
• Préfère les appels API batchés à des iterators quand l’API le permet (Airtable, Notion, Google Sheets le supportent presque tous).

Si tu construis un scénario qui doit tourner 1000 fois par jour, chaque opération économisée représente 30 000 ops par mois. Sur un plan Pro à 16€, tu peux vite saturer ton forfait si ton design est inefficace.

Debug : reconnaître les erreurs typiques

Quand un scénario plante, regarde toujours d’abord le compteur de bundles à la sortie de chaque module. Si tu attendais 20 bundles et que tu en as 1, ton iterator a échoué (probablement parce que tu lui as passé une chaîne au lieu d’un tableau). Si tu attendais 1 bundle et que tu en as 20, tu as oublié l’aggregator.

Autre piège : l’erreur “DataError: Function ‘map’ finished with error”. Elle apparaît souvent quand tu utilises map() dans un mapping et que le tableau cible n’est pas accessible. C’est généralement un signe qu’il fallait un iterator dans ton scénario.

Pour finir, n’oublie pas l’option “Allow incomplete data” dans les paramètres avancés de chaque module. Activée, elle permet à l’iterator de continuer même si certains bundles ont des erreurs : utile pour ne pas faire planter tout le scénario à cause d’une ligne pourrie.

Conclusion : iterator pour exploser, aggregator pour recoller

Retiens cette image : iterator = ouvrir un colis, aggregator = refermer le colis. Si tu ouvres un colis, tu dois (presque) toujours le refermer avant la fin du scénario. Si tu ne fermes jamais, tu envoies N notifications. Si tu fermes sans avoir ouvert, tu n’agrèges qu’un seul élément (et tu te demandes pourquoi ton aggregator ne fait rien).

Avec ces deux modules bien maîtrisés, tu peux construire 90 % des automatisations professionnelles sans jamais toucher au code. Le reste, c’est de la configuration, des filters et des routes. Pour aller plus loin, je te conseille de pratiquer sur trois scénarios différents : un avec un seul iterator, un avec une combinaison iterator-aggregator, et un avec un Group by. Tu verras, ça devient un réflexe.

Si tu veux qu’on construise ensemble un scénario Make robuste pour ton activité, réserve un audit d’automatisation gratuit. On regarde tes process actuels, on identifie les goulots, et tu repars avec un plan d’action concret. Et si tu hésites encore entre les outils, va lire le comparatif n8n vs Make vs Zapier 2026 avant de te lancer.