📖 Manuel

Make Scenario Builder

Étape 1 — Cadrage du scénario

Questions à poser avant de toucher l'éditeur :

Estimation rapide des opérations :

opérations = nb_exécutions × nb_modules_actifs × taille_collection_moyenne
Exemple : 500 leads/jour × 6 modules × 1 = 3 000 ops/jour → ~90 k/mois (plan Core suffit)

Étape 2 — Trigger

Polling (Watch)

• Intervalle minimum : 1 min (plan payant), 15 min (Free).
• Configurer Max results : commencer à 10, augmenter en production.
• Cocher Process all cycles pour ne pas sauter de lots en cas de retard.

Webhook instant

URL générée : https://hook.eu2.make.com/xxxxxxxxxxxx
Header recommandé : X-Secret-Token: <votre_token>

• Cliquer Redéfinir la structure de données après le premier appel test pour inférer automatiquement le schéma.
• Toujours répondre avec un Webhook Response (200 + corps JSON) sinon l'appelant retente.

{ "status": "ok", "received": true }

Étape 3 — Mapping et transformations

Fonctions utiles copiables dans le panneau de mapping :

# Date ISO → format lisible
{{formatDate(1.created_at; "DD/MM/YYYY HH:mm"; "UTC")}}

# Valeur par défaut si vide
{{ifempty(1.email; "no-reply@example.com")}}

# Extraction de domaine email
{{replace(1.email; "/^.*@/"; "")}}

# Parsing JSON embarqué
{{parseJSON(1.metadata)}}

# Troncature de texte
{{substring(1.description; 0; 255)}}

Règle : mapper à partir des sorties du module précédent (panneau gauche) plutôt que taper en dur — les valeurs hardcodées cassent silencieusement si le schéma source change.

Étape 4 — Routers et filtres

Structure type à 3 routes :

[Trigger]
    └─ [Router]
         ├── Route A  (filtre : 1.status = "new")       → créer dans CRM
         ├── Route B  (filtre : 1.status = "updated")   → mettre à jour CRM
         └── Route C  (fallback — aucun filtre)          → log dans Slack #alertes

• Ordre des routes : la plus restrictive en premier, fallback en dernier.
• Opérateurs disponibles : Equal, Contains, Matches pattern (regex), Exists.
• Activer Stop processing routes after first match si les routes sont mutuellement exclusives (économise des opérations).

Étape 5 — Iterator / Aggregator

Pattern standard pour traiter un tableau :

[Module qui renvoie un tableau]
    → [Iterator]          ← décompose chaque élément
        → [Traitement par élément]
            → [Array Aggregator]   ← reconstruit le tableau
                → [Suite du scénario]

Configuration Array Aggregator :

• Source module : pointer sur l'Iterator (pas sur le module de traitement).
• Aggregated fields : sélectionner uniquement les champs nécessaires.
• Résultat disponible comme {{n.array}} dans le module suivant.

Attention : chaque itération consomme autant d'opérations que de modules dans la boucle.

Étape 6 — Data Stores

Cas d'usage : mémoriser un état entre exécutions (IDs déjà traités, compteurs, cache).

# Schéma minimal pour déduplication
Champ : record_id  (Text, clé unique)
Champ : processed_at  (Date)

# Logique dans le scénario
[Search a record] → existe ? 
    Oui → skip (Router vers rien)
    Non → [traitement] → [Add/Replace a record]

Quota : 1 Data Store par scénario sur Free, illimité sur payant. Taille max : 1 MB (Free) / variable (payant).

Étape 7 — Gestion des erreurs

Notification d'erreur standard (Slack) :

Message : ⚠️ Scénario {{scenarioName}} — erreur module {{moduleName}}
Détail : {{error.message}}
Lien : https://www.make.com/en/dashboard

Activer Incomplete executions dans les paramètres du scénario → les exécutions échouées sont rejouables manuellement depuis l'onglet dédié.

Étape 8 — Déploiement et monitoring

Checklist avant activation :

• [ ] Run once testé avec données réelles
• [ ] Chaque module validé individuellement (icône verte)
• [ ] Error handler posé sur chaque module HTTP / API externe
• [ ] Scénario nommé : [Domaine] — [Source] → [Destination] — [env]
• [ ] Notes ajoutées sur les modules complexes (clic droit → Add note)
• [ ] Connexions nommées explicitement (pas "Ma connexion 1")

Surveillance opérations :

Dashboard → Organization → Usage
Alerte recommandée : poser un scénario de monitoring qui envoie un email
si ops restantes < 20% du quota mensuel.

Anti-patterns et pièges fréquents

Bonnes pratiques 2026

• Blueprints : exporter chaque scénario en JSON (trois points → Export Blueprint) et le versionner dans git — Make ne versionne pas nativement.
• Environnements : utiliser des équipes séparées (ou des connexions nommées prod / staging) pour isoler les environnements.
• Rate limiting API : ajouter un module Sleep (Tools → Sleep, 1-2 s) dans les boucles qui appellent des API avec quotas stricts.
• Sous-scénarios : découper les scénarios > 20 modules en sous-scénarios appelés via Run a scenario — gain en lisibilité et réutilisabilité.
• MCP / AI modules : Make expose désormais des modules OpenAI, Anthropic et HuggingFace natifs — préférer ces modules aux appels HTTP bruts pour les intégrations IA.