Chapitre 9/12 • 15 min de lecture

Bonnes pratiques

Construire un scénario Make qui tourne, c'est 20% du travail. Le rendre robuste, documenté et maintenable sur 3 ans, c'est les 80% restants. Voici les règles.

⏱️ En bref : 10 règles éprouvées : convention de nommage, error handlers obligatoires, monitoring actif, documentation inline, versioning, tests avant production, économie d'opérations, sécurité des données, audit trimestriel, et principe KISS (Keep It Simple).

Pourquoi ces bonnes pratiques comptent

Un scénario Make.com mal conçu, c'est une bombe à retardement. Il fonctionne 3 mois, puis un matin il plante. Personne ne se souvient de ce qu'il fait ni comment le réparer. Les processus commerciaux tombent en panne, les clients sont impactés, et vous payez 800€ à un freelance pour débugger 40 scénarios anonymes.

Les règles ci-dessous évitent ce scénario. Elles viennent de 50+ déploiements Make chez des PME B2B françaises.

Les 10 règles Lab0 pour Make.com

1. Convention de nommage stricte

Chaque scénario suit un template de nom :

[PROJECT] - [TRIGGER] - [ACTION] - [VERSION]

Exemples :

  • "PIPEDRIVE - Deal Gagné - Facture Dolibarr + Email - v2"
  • "FORM - Callback - Enrichissement Clay + Pipedrive - v1"
  • "SLACK - Erreur critique - Notification équipe RevOps - v1"

C'est la base. Sans ça, après 30 scénarios vous ne savez plus qui fait quoi.

2. Error handlers obligatoires

Chaque module critique (API call, DB write) doit avoir un error handler :

  • Retry : 3 tentatives avec délai croissant (30s, 1min, 5min)
  • Resume : continuer le scénario en ignorant l'erreur si non-bloquante
  • Break : arrêter proprement et notifier l'équipe

3. Monitoring actif

Les scénarios critiques (ceux qui bloquent le business s'ils échouent) doivent avoir :

  • Notification Slack/email en cas d'échec
  • Vérification hebdomadaire manuelle du nombre d'exécutions (doit être stable)
  • Alerte si 0 exécution en 48h (signe de trigger cassé)

4. Documentation inline

Utiliser les notes dans Make (clic droit sur un module → Add note) pour documenter :

  • L'objectif du scénario (1 phrase en haut)
  • Les cas limites gérés
  • Les dépendances externes
  • Le nom du propriétaire

5. Versioning

Avant toute modification significative d'un scénario en production, cloner (Clone) le scénario avec incrément de version. Modifier sur la copie. Tester. Si OK, désactiver l'ancien et activer le nouveau. Si problème, rollback immédiat en réactivant l'ancien.

6. Tests avant production

Un nouveau scénario ne passe en production qu'après :

  • Test manuel du déclenchement (Run once)
  • Test avec data réelle mais compte test (pas le CRM production)
  • Validation visuelle de chaque module
  • Test avec data corrompue (champ manquant, format inattendu)

7. Économie d'opérations

Make facture à l'opération. Optimiser :

  • Préférer les webhooks (gratuit en trigger) au polling (1 op par scan)
  • Utiliser les filtres intelligents (arrêter le scénario tôt si conditions non remplies)
  • Éviter les boucles inutiles (itérer sur 1000 items quand on n'a besoin que du premier, c'est 1000 ops)
  • Grouper les actions (1 update batch vaut mieux que 50 updates unitaires)

8. Sécurité des données

  • Jamais de credentials (API keys, passwords) en dur dans les modules. Utiliser les connexions Make ou les variables d'environnement.
  • Limiter les permissions des API keys au strict minimum (principe du moindre privilège)
  • Pour les données sensibles (RGPD), utiliser le "Data stores" crypté de Make plutôt que des Google Sheets

9. Audit trimestriel

Tous les 3 mois, passer 1h à :

  • Lister tous les scénarios actifs
  • Identifier ceux qui n'ont pas tourné depuis 30 jours (candidats suppression)
  • Vérifier que chacun a un propriétaire identifié
  • Mesurer la consommation d'ops et optimiser les plus gourmands

10. KISS (Keep It Simple)

La tentation avec Make c'est de construire des monstres à 40 modules qui font 15 choses. Mauvaise idée : impossible à débugger, impossible à documenter, impossible à transmettre. Règle : 1 scénario = 1 objectif. Si vous dépassez 15 modules dans un scénario, découpez en sous-scénarios (un scénario peut en appeler un autre via webhook interne).

Checklist déploiement d'un nouveau scénario

  • ☐ Nom suivant la convention
  • ☐ Note de description ajoutée
  • ☐ Propriétaire identifié
  • ☐ Error handlers sur modules critiques
  • ☐ Test "Run once" OK
  • ☐ Test avec cas limite OK
  • ☐ Notification d'erreur configurée
  • ☐ Documentation externe rédigée (1 paragraphe minimum)
  • ☐ Consommation d'ops estimée
  • ☐ Activé en production
  • ☐ Monitoring activé pour les 7 premiers jours

💡 Retour d'expérience Lab0

Chez nos clients qui suivent ces règles, on observe : -70% de temps de maintenance, -90% de scénarios cassés, +300% de confiance dans l'automatisation. Le temps investi en documentation au démarrage est largement rentabilisé.

⚠️ Signal d'alarme — le "scénario zombie"

Un scénario qui tourne mais dont plus personne ne sait ce qu'il fait ni s'il est vraiment utile. À chaque audit trimestriel, identifiez-les. Soit vous les documentez (propriétaire, objectif), soit vous les désactivez. Un Make propre = un Make sous contrôle.

🔴 Cas réel — la catastrophe évitée

Un client nous a contacté paniqué : 150 emails de facturation envoyés en double aux clients. Cause : un scénario Make créé par un ex-stagiaire, sans error handler, qui s'est relancé en boucle sur une erreur Dolibarr. Temps de diagnostic : 3h. Dégât d'image : conséquent. Avec un error handler basique + monitoring, le problème aurait été détecté en 5 minutes.

📚 Pour aller plus loin

Pour un audit de votre stack Make actuelle ou un déploiement accompagné, prenez contact avec Lab0. Voir aussi notre guide intégrations CRM + Make.