Réponse directe
Automatiser les relances de paiement avec n8n réduit les délais de traitement, évite les oublis et fiabilise le suivi client grâce à des envois contrôlés, conditionnels et traçables.
Points clés
- Centralise les impayés via API ou webhook
- Envoie d’e-mails ou SMS conditionnels selon la date d’échéance
- Relances personnalisées avec champs dynamiques (nom, montant)
- Suivi des statuts dans CRM ou base Airtable
- Compatible avec Crisp, Stripe, Quickbooks et autres
Contexte : pourquoi s’y intéresse
Dans beaucoup de PME, les relances sont manuelles et sources d’erreurs. Une facture oubliée, un mauvais ton, ou trop tard envoyé : les pertes s'accumulent. Automatiser permet de standardiser et tracer.
Définition (simple)
Une relance de paiement automatisée déclenche l’envoi d’un message (mail, Slack, SMS) lorsqu’une facture atteint une certaine condition d’échéance, via des scénarios construits dans un outil comme n8n.
Automatiser les relances de paiement : guide pas à pas
1) Diagnostic (quoi automatiser en priorité)
Commencez par lister les sources d’impayés les plus courantes : abonnements sur Stripe, factures manuelles depuis Quickbooks, échéances dans un Google Sheet. Identifiez celles à haut volume et forte charge manuelle.
2) Design du workflow (fiabilité, erreurs, relance)
Construisez un scénario dans n8n déclenché chaque jour (Cron node). Requêtez les factures en statut “en retard” via HTTP Request ou Intégration dédiée. Ajoutez un noeud IF pour vérifier la date d’échéance. Utilisez “Set” pour formater le message de relance avec le montant ({{ $json.amount_due }}) et la société ({{ $json.customer_name }}).
Ajoutez un retry via le node Error Trigger si l’envoi échoue côté SMTP (code 5xx). Pensez à logguer chaque tentative dans une base (Airtable, PostgreSQL, Notion).
3) Intégrations (API, webhooks, outils)
- Stripe → relances abonnements échus
- Quickbooks / Pennylane / Tiime → factures client
- SMTP (Sendinblue / Mailersend) ou webhook vers Twilio (SMS)
- CRM type Hubspot pour annoter les relances envoyées
4) Sécurité & conformité (RGPD, accès, logs)
Stockez uniquement les champs nécessaires (montant, client, email). Activez l’historique n8n si activé sur votre instance. Isolez les credentials SMTP/API dans les variables sécurisées. Tracez chaque envoi avec timestamp et ID de facture. Limitez l’accès à cette automatisation via RBAC si vous êtes plusieurs à éditer.
5) Exploitation (monitoring, maintenance, évolutions)
Mettez un Slack webhook de notification en cas d’erreur critique. Ajoutez un tag “envoyé_à_3_relances” si le client ne paie toujours pas après 3 tentatives pour basculer vers un scénario de coupure d’accès (si SaaS). Planifiez une review mensuelle via cron + export CSV des logs.
Retour terrain (scénario réaliste)
Une agence B2B utilisant Stripe et Notion déclenchait manuellement ses relances. Ils ont migré vers n8n avec Cron journalier, HTTP à Stripe, logique IF sur “paid=false” et délai >7 jours, envoi SMTP avec Sendinblue. Contraintes : pas de dev interne, besoin de logs exportables, instabilité ponctuelle de SMTP (géré via retry + Slack alertes).
Bloc signature (unique du jour)
Décision d’architecture : webhook vs polling API
| Option | Avantages | Limitations | Quand choisir |
|---|---|---|---|
| Webhook Stripe | Réactivité, push natif de l’événement | Complexité initiale, nécessite serveur | Paiements en temps réel |
| Cron + API GET | Simplicité, pas besoin de serveur | Moins réactif, plus de requêtes redondantes | TPE/PME sans infra dédiée |
Choisir webhook si vous disposez déjà d’un serveur ou hébergement n8n sur instance dédiée. Sinon, pour une logique simple “une fois par jour”, le polling suffit largement.
Exemples concrets (sans chiffres inventés)
- Cron → HTTP vers Quickbooks → IF “due_date < today AND status == unpaid” → Send Email → Log dans Notion
- Webhook Stripe paiement échoué → Wait 3 jours → Send SMS → Flag client dans Airtable
- Cron → Requête Airtable “statut facture” → Format email HTML personnalisé → SMTP → Slack erreur si code != 200
Modèles rapides (copier-coller)
- Condition IF (n8n) :
{{$jmespath($json, 'due_date') < $now && $json.status === 'unpaid'}} - Sujet d’e-mail personnalisé :
Relance - Facture #{{$json.invoice_number}} en attente
Erreurs fréquentes (et comment les éviter)
- Déclencher trop tôt (fix : ajouter un délai “Wait” de 2 jours post-échéance)
- Relancer des factures déjà payées (fix : filtre “status != paid” avant l’envoi)
- Ignorer les erreurs SMTP (fix : node Error Trigger + Slack webhook sur échecs)
Checklist actionnable
- Identifier la source centrale de vos factures (Stripe, Excel, ERP...)
- Définir la logique de condition de relance (jours après échéance, statut)
- Construire et tester le scénario n8n avec jeux de données
- Sécuriser API keys + configurer RBAC
- Ajouter logs, tags, et monitoring Slack
Besoin d'aide pour automatiser vos relances de paiement ?
Réservez un appel gratuit avec notre équipe pour discuter de vos besoins en automatisation.
Réserver un appel gratuit
FAQ
Comment connecter Stripe à n8n pour récupérer les paiements échoués ?
Utilisez le node Stripe dans n8n ou un webhook sur l’événement invoice.payment_failed. Vérifiez les métadonnées du client pour retrouver le contact.
Peut-on relancer par SMS au lieu d’e-mail ?
Oui, en utilisant un webhook vers Twilio ou Octopush. Il faut gérer le format du numéro et les limitations réglementaires.
Comment éviter de relancer un client qui a déjà payé entre-temps ?
Filtrez par statut à chaque traitement. Ajoutez une vérification active avant chaque envoi via un deuxième appel API ou champ “paid_at”.
Où stocker les logs de relance pour audit RGPD ?
Base Airtable, table Notion ou base PostgreSQL dédiée avec uniquement invoice_id, timestamp, canal, succès/échec.
Comment tester le scénario n8n sans envoyer d’e-mails réels ?
Utilisez un “fake SMTP” comme Mailtrap ou un environnement bac à sable dans Sendinblue. Activez un flag “is_test = true” pour filtrer les cas.
