Pourquoi Make plutôt que Zapier pour un SaaS ?

Zapier est excellent pour les automatisations simples (A → B). Make brille pour les logiques complexes : - Branches conditionnelles : si la commande > 1 000 €, alerter l'équipe commerciale ; sinon, envoyer une confirmation automatique - Itérations : pour chaque ligne d'un tableau, faire X - Transformations de données : parser un JSON, extraire des champs, reformater des dates - Gestion d'erreurs : routes de repli si une étape échoue

Pour un SaaS, ces capacités sont souvent indispensables. Le prix est aussi compétitif : Make Pro à 16 $/mois vs Zapier Starter à 20 $/mois, avec des opérations beaucoup plus efficaces — Make compte les opérations différemment, ce qui revient moins cher pour les scénarios complexes multi-étapes.

Un avantage souvent cité par les équipes françaises : Make propose une interface disponible en plusieurs langues, une base d'utilisateurs européenne importante, et des templates orientés marché européen.

Workflow 1 : Onboarding email automatique

Déclencheur : Webhook Supabase (quand un nouvel utilisateur s'inscrit dans auth.users)

Scénario : 1. Supabase → Database Trigger → Nouvel utilisateur créé 2. Make reçoit le webhook avec email + user_id 3. Attendre 5 minutes (pour laisser l'utilisateur se connecter) 4. Envoyer email d'accueil via Brevo/SendGrid avec le prénom de l'utilisateur 5. Attendre 24h 6. Envoyer email "Avez-vous besoin d'aide ?" si l'utilisateur n'a pas complété son onboarding (vérifier dans Supabase si le champ onboarding_completed est false)

Ce workflow transforme un simple email de bienvenue en séquence d'onboarding adaptative. Pour un SaaS B2B français, personnalisez les emails avec le nom de l'entreprise (récupérable depuis le profil ou le domaine email). Les emails en français bien rédigés ont un taux d'ouverture significativement plus élevé que les templates génériques en anglais.

Workflow 2 : Notifications Slack pour les événements critiques

Cas d'usage : alerter votre équipe quand un client paie, annule, ou rencontre une erreur.

Scénario : 1. Webhook Stripe → Événement customer.subscription.created 2. Formater le message : "Nouveau client ! [Nom] vient de souscrire au plan [Plan] — [Montant]/mois" 3. Envoyer dans #nouveaux-clients sur Slack 4. Si le montant > 500 €/mois → aussi notifier le commercial responsable par DM

Événements Stripe utiles à monitorer : - customer.subscription.deleted : client churné → alerte dans #churn avec raison si disponible - invoice.payment_failed : paiement échoué → déclencher séquence de relance - customer.subscription.updated : upgrade ou downgrade → noter pour le suivi commercial

Ces alertes temps réel transforment votre gestion de la relation client — vous savez instantanément quand un client important annule, et pouvez réagir en quelques minutes plutôt que de découvrir le churn dans votre rapport mensuel.

Workflow 3 : Rapports hebdomadaires automatiques

Déclencheur : planification (tous les lundis à 8h)

Scénario : 1. Requête à Supabase : nouveaux utilisateurs de la semaine (COUNT WHERE created_at > now() - interval 7 days) 2. Requête Supabase : MRR (SUM des abonnements actifs) 3. Requête Supabase : churn de la semaine 4. Requête Stripe : revenu réalisé 5. Formatter un message récapitulatif avec les métriques clés 6. Envoyer dans #weekly-metrics sur Slack 7. Optionnel : créer une ligne dans Airtable ou Google Sheets pour tracker l'historique

Vous commencez chaque semaine avec les métriques clés sans ouvrir un seul dashboard. Pour les startups françaises qui suivent des métriques pour leurs investisseurs (notamment dans le cadre de reporting mensuel pour des fonds comme BPI France, Bpifrance ou des BA), ce workflow facilite considérablement la préparation des rapports.

Workflow 4 : Relance automatique des paiements échoués

Le problème : les paiements échoués (carte expirée, fonds insuffisants) représentent 10 à 15 % du churn involontaire. Sans relance, vous perdez des clients qui voulaient rester.

Scénario : 1. Webhook Stripe → invoice.payment_failed 2. Envoyer email "Votre paiement a échoué" avec lien vers le portail Stripe pour mettre à jour la carte 3. Attendre 3 jours 4. Si toujours impayé (vérifier dans Stripe) → second email plus urgent 5. Attendre 4 jours de plus 6. Si toujours impayé → email final "Votre compte sera suspendu dans 24h" 7. Si paiement réussi entre-temps → annuler la séquence et envoyer un email de confirmation

Ce workflow récupère typiquement 30 à 40 % des paiements échoués. Pour un SaaS avec 50 clients à 100 €/mois, c'est potentiellement 2 000 à 3 000 € de MRR récupéré par mois — pour un workflow qui prend 2 heures à mettre en place.

Workflow 5 : Support client intelligent avec IA

Déclencheur : nouvel email dans votre boîte support (ou nouveau ticket Intercom/Crisp)

Scénario avec IA : 1. Réception du ticket support 2. Appel à OpenAI : "Classifie ce ticket en : Bug, Question, Feature Request, Billing. Réponds en JSON." 3. Selon la classification : - Bug → Slack #bugs avec le texte du ticket + priorité auto-assignée - Billing → Transférer au responsable finance - Question → Chercher dans la base de connaissance (Supabase + pgvector) et répondre automatiquement si pertinent - Feature Request → Créer une carte dans Linear ou Notion 4. Mettre à jour le statut du ticket dans Intercom

Ce workflow réduit le temps de traitement moyen du support de 80 % pour les questions courantes. Pour les SaaS avec des clients en France, assurez-vous que vos réponses automatiques sont en français — les clients apprécient d'être adressés dans leur langue, et cela réduit les demandes de clarification.

Mise en place et bonnes pratiques

Commencer simple Ne construisez pas les 5 workflows d'un coup. Commencez par l'onboarding email (le plus impactant sur l'activation), puis ajoutez progressivement en fonction de vos besoins.

Gestion des erreurs Chaque scénario Make doit avoir une route d'erreur configurée. Si Supabase est down, Make doit : retenter 3 fois avec backoff exponentiel, alerter votre équipe dans Slack, ne pas perdre les données (stocker dans Make Data Store en attendant). Les erreurs non gérées sont la principale source de frustration avec les outils d'automatisation.

Tests Make a un mode "Run once" pour tester avec de vraies données sans activer le scénario complet. Utilisez-le avant d'activer en production. Créez des utilisateurs ou événements de test dédiés pour ne pas polluer vos vraies données.

Monitoring Make garde un historique de toutes les exécutions avec les données entrantes et sortantes de chaque étape. Consultez les logs quotidiennement pendant la première semaine après le lancement d'un nouveau scénario — les edge cases émergent toujours dans les premières 48 heures.