Par AAora · Publié le 18 octobre 2026 · 7 min de lecture

Automatiser les relances clients avec n8n : workflow pas à pas

Cet article est un tutoriel. Le workflow décrit est un exemple pédagogique construit pour l'occasion : ce n'est pas le récit d'un projet client, et il ne contient aucun chiffre de résultat. Adaptez les noms de champs et les messages à votre contexte.

Quel problème ce workflow résout-il ?

Une facture arrive à échéance. Si elle n'est pas payée, il faut relancer le client : un premier rappel courtois, puis un second plus ferme. À la main, cela suppose de relire la liste des factures, de calculer les retards, d'écrire les emails et de noter ce qui a été envoyé. C'est exactement le genre de tâche qu'on repousse, puis qu'on oublie.

L'objectif ici est volontairement limité : détecter les factures échues, envoyer la bonne relance au bon moment, garder une trace, et vous prévenir. Rien de plus. Pas de décision automatique sur un litige, pas de menace de recouvrement : ces cas restent humains.

Quelle architecture adopter ?

Le workflow tient en sept étapes :

Schedule Trigger (chaque jour ouvré, 9 h)
  → Lecture des factures impayées (tableur, base SQL ou API de facturation)
  → Edit Fields : calcul du nombre de jours de retard
  → Switch : relance 2 (J+7) ? relance 1 (J+3) ? rien ?
  → Send Email : message correspondant
  → Mise à jour de la facture : niveau de relance + date
  → Notification : un seul résumé envoyé à vous

Pourquoi un déclencheur planifié plutôt qu'un nœud Wait par facture ? Un nœud Wait sait attendre plusieurs jours, mais chaque facture devient alors une exécution suspendue, difficile à auditer et à modifier. Avec un balayage quotidien, l'état vit dans vos données (le niveau de relance déjà envoyé), pas dans le workflow. Vous pouvez redémarrer n8n, corriger un message ou désactiver le workflow sans rien perdre.

Étape 1 : de quelles données avez-vous besoin ?

Le strict minimum, une ligne par facture :

Champ	Rôle
`id_facture`	Identifiant, cité dans l'email
`client_nom`	Formule d'appel
`client_email`	Destinataire
`montant_ttc`	Rappelé dans le message
`echeance`	Date d'échéance (AAAA-MM-JJ)
`statut`	`envoyee`, `payee` ou `litige`
`niveau_relance`	0, 1 ou 2 : combien de relances ont déjà été envoyées
`derniere_relance`	Date du dernier envoi

Le champ niveau_relance est celui qui protège des doublons. Sans lui, le workflow ne sait pas ce qu'il a déjà fait.

Étape 2 : comment déclencher le workflow ?

Ajoutez un nœud Schedule Trigger en mode expression cron :

0 9 * * 1-5

Soit 9 h, du lundi au vendredi. Réglez le fuseau dans les paramètres du workflow (Europe/Paris) : à défaut, n8n utilise celui de l'instance, qui n'est pas forcément le vôtre.

Étape 3 : comment lire les factures concernées ?

Filtrez le plus tôt possible, à la source. Avec une base PostgreSQL :

SELECT id_facture, client_nom, client_email, montant_ttc, echeance, niveau_relance
FROM factures
WHERE statut = 'envoyee'
  AND echeance < CURRENT_DATE
  AND niveau_relance < 2;

Avec Google Sheets, le nœud Get Row(s) accepte des filtres ; ajoutez ensuite un nœud Filter pour écarter les lignes qui ne conviennent pas. Les factures en litige ou déjà payee ne doivent jamais arriver jusqu'à l'envoi.

Étape 4 : comment calculer le retard ?

Dans un nœud Edit Fields, créez un champ numérique retard_jours avec cette expression :

{{ Math.floor($now.diff(DateTime.fromISO($json.echeance), 'days').days) }}

$now et DateTime sont des objets Luxon, disponibles dans les expressions n8n. Comparez des dates, pas des heures : une échéance stockée à minuit UTC peut sinon glisser d'un jour selon le fuseau.

Étape 5 : comment choisir entre J+3 et J+7 ?

Un nœud Switch avec deux règles, dans cet ordre (par défaut, le Switch s'arrête à la première règle qui correspond) :

retard_jours >= 7 et niveau_relance < 2 → sortie « relance 2 »
retard_jours >= 3 et niveau_relance < 1 → sortie « relance 1 »

Tout le reste est ignoré. Deux détails comptent. D'abord, on teste >= et non == : si le workflow n'a pas tourné pendant un week-end ou une panne, la relance part le jour suivant au lieu d'être perdue. Ensuite, la règle sur niveau_relance empêche qu'une facture reçoive la même relance deux jours de suite.

Étape 6 : que contient l'email ?

Utilisez le nœud Send Email (SMTP) depuis une adresse dédiée à la facturation, ou le nœud Gmail si vous passez par OAuth. Un modèle sobre :

Objet : Facture {{ $json.id_facture }} : échéance dépassée

Bonjour {{ $json.client_nom }},

Sauf erreur de notre part, la facture {{ $json.id_facture }} d'un montant de
{{ $json.montant_ttc }} € est arrivée à échéance le {{ $json.echeance }} et
n'apparaît pas comme réglée.

Si le paiement a déjà été effectué, merci de ne pas tenir compte de ce message.
Dans le cas contraire, pourriez-vous nous indiquer la date de règlement prévue ?

Cordialement,

Pour la relance 2, gardez le même socle et changez le ton et l'objet. Mettez toujours une adresse de réponse lue par un humain.

Étape 7 : comment mettre à jour le statut ?

Connectez un nœud de mise à jour à la sortie réussie du nœud d'envoi. Il écrit niveau_relance (1 ou 2) et derniere_relance avec l'expression {{ $now.toISODate() }}.

L'ordre envoi puis mise à jour a un coût : si la mise à jour échoue après l'envoi, la même relance repartira le lendemain. L'ordre inverse (marquer d'abord, envoyer ensuite) a le défaut opposé : une relance marquée mais jamais partie. Pour une relance de facture, un doublon occasionnel est moins grave qu'une relance silencieusement perdue. Gardez donc l'envoi en premier, et faites en sorte qu'un échec de mise à jour déclenche une alerte (voir plus bas).

Étape 8 : comment être prévenu sans être noyé ?

Un nœud Aggregate regroupe les éléments traités, puis un seul message récapitule la journée : nombre de relances envoyées, factures concernées, échecs éventuels. Par email, Slack ou Telegram, au choix. Un message par facture devient vite du bruit que l'on cesse de lire.

Comment gérer les erreurs ?

Un workflow qui échoue en silence est pire qu'une tâche manuelle, parce que plus personne ne la surveille. Quelques réglages suffisent :

Un workflow d'erreur. Créez un second workflow qui commence par un nœud Error Trigger et vous envoie le nom du workflow, le nœud en cause et le lien de l'exécution. Associez-le dans les paramètres du premier, champ Error Workflow.
Des nouvelles tentatives. Dans les paramètres des nœuds qui font des appels réseau (lecture d'API, envoi d'email), activez Retry On Fail avec trois essais et quelques secondes entre chaque.
Un mauvais email ne bloque pas les autres. Sur le nœud d'envoi, réglez On Error sur « Continue (using error output) » et dirigez la sortie d'erreur vers une branche qui note l'échec dans une colonne dédiée, sans toucher à niveau_relance.
Un mode test. Avant la mise en production, remplacez le destinataire par votre propre adresse et lancez le workflow à la main sur des données épinglées (pin data). Vérifiez chaque sortie du Switch.

Pensez enfin aux cas limites : le client a payé hier soir mais le tableur n'est pas à jour (la source de vérité doit l'être avant 9 h), l'adresse email est vide ou invalide, la facture est en litige. Chacun mérite soit un filtre, soit une branche d'erreur.

Que vérifier côté RGPD ?

Ceci n'est pas un avis juridique ; faites valider le dispositif par la personne qui vous conseille sur ce sujet. Les points techniques à regarder :

Minimisation. Le tableau ci-dessus ne contient que ce qui sert à relancer : nom, email, numéro, montant, échéance. N'ajoutez pas d'historique d'échanges ni de champs « au cas où ».
Information des personnes. La relance d'un impayé s'inscrit dans la relation commerciale, mais votre politique de confidentialité doit le mentionner, avec la durée de conservation.
Les exécutions n8n contiennent des données personnelles. Par défaut, n8n garde les données des exécutions. Réglez la rétention avec les variables d'environnement EXECUTIONS_DATA_PRUNE=true et EXECUTIONS_DATA_MAX_AGE (en heures), et envisagez EXECUTIONS_DATA_SAVE_ON_SUCCESS=none si vous n'avez pas besoin de rejouer les exécutions réussies.
Accès et identifiants. Utilisez un compte d'envoi dédié plutôt que votre boîte principale, avec les droits minimaux. Les secrets restent dans les credentials de n8n, jamais en clair dans un nœud. Révoquez les accès OAuth dont vous ne vous servez plus.
Hébergement et sous-traitants. Avec n8n auto-hébergé, les données restent sur un serveur que vous choisissez. Avec un service tiers (Make, Google, un fournisseur d'email), ce sont des sous-traitants à inscrire dans votre registre, avec leur contrat de sous-traitance.
La facture elle-même. Entre professionnels, les pénalités de retard et l'indemnité forfaitaire de recouvrement doivent figurer sur la facture. Vérifiez les mentions avec votre comptable.

Quelles sont les limites de cet exemple ?

Il reste volontairement simple. Il ne gère ni les paiements partiels, ni les avoirs, ni les devises multiples ; il relance par email uniquement ; et il ne fait aucun rapprochement bancaire : le statut payee doit venir de votre outil de comptabilité ou de vous. Testez-le sur une poignée de factures avant de le brancher sur toute la base.

Et ensuite ?

Le même squelette (déclencheur, filtre, état dans les données, action, mise à jour, notification) sert à bien d'autres tâches : suivi de leads qui n'ont pas reçu de réponse, rappels de rendez-vous, relances de devis. Si vous voulez qu'on le mette en place sur vos outils, avec la gestion d'erreurs et la documentation qui vont avec, voyez le service automatisation n8n ou contactez AAora.