Réalisations · Outils ·Projet personnel
Les factures impayéesse relancenttoutes seules
Relancer un client qui n'a pas payé prend du temps, et personne n'aime le faire. J'ai construit une automatisation qui s'en charge chaque matin : elle repère les factures en retard, choisit le bon ton selon l'ancienneté de l'impayé et envoie un seul mail par client, sans relancer deux fois pour la même facture.
- Cadre
- Projet personnel, testé sur les données fictives d'une PME
- Besoin
- Relancer les factures impayées sans y passer ses semaines, à partir d'une base clients et factures existante
- Outils
- n8n, TypeScript, Express, SQLite, Docker
- Temps
- Une dizaine d'heures
plusieurs h0 h
par semaine passées à relancer, pour 1 comme pour 100 clients
4 paliers
du rappel avant l'échéance à la mise en demeure
1 relance
par facture et par palier : la base refuse la deuxième
Le point de départ
Dans une petite entreprise, les relances de factures impayées se font souvent à la main : vérifier qui n'a pas payé, retrouver les montants, rédiger un mail plus ou moins ferme selon le retard. C'est long, répétitif et désagréable, alors on repousse, et l'argent rentre plus tard. Les informations existaient déjà, dans une base clients et factures : il restait à s'en servir pour relancer au bon moment, sans y penser.
Ce que j'ai mis en place
- J-3rappel avant l'échéance
- J+7rappel courtois
- J+15relance ferme
- J+30mise en demeure
- Un suivi des factures : pour chacune, le nombre de jours de retard est calculé à partir de la date d'échéance.
- Quatre paliers de relance, avec un ton qui monte : un rappel trois jours avant l'échéance, un rappel courtois à une semaine, une relance ferme à quinze jours, une mise en demeure au-delà d'un mois.
- Un seul mail par client, même s'il a plusieurs factures en retard, avec les coordonnées bancaires pour régler.
- Un suivi de chaque envoi : réussi ou en échec, il est inscrit dans l'historique, et une relance en échec repart le lendemain.
- Des relances suspendues pour un client en litige, en un réglage.
- Une page de suivi : la liste des factures, le total impayé et le retard de chacune, d'un coup d'œil.
Le point délicat : ne jamais relancer deux fois
Un oubli de relance se rattrape le lendemain. Un client relancé deux fois pour la même facture, lui, s'en souvient. J'ai donc fait de cette règle le cœur de l'outil : chaque relance envoyée est inscrite dans un historique, et c'est la base de données elle-même qui refuse une deuxième relance au même palier. Ce n'est pas au workflow de « penser » à filtrer.
Chaque envoi est suivi jusqu'au bout : réussi, il est consigné et ne repartira plus ; en échec, il est consigné comme tel et repart le lendemain. Le rappel avant l'échéance couvre aussi trois jours plutôt qu'un seul : si l'automatisation ne tourne pas un matin, il n'est pas perdu. Une limite reste assumée : si l'automatisation s'arrête dans l'instant qui sépare l'envoi de sa consignation, cette relance n'est pas inscrite et pourrait repartir le lendemain.
Au quotidien
Plus besoin de vérifier chaque matin qui n'a pas payé ni de rédiger les relances : elles partent seules, au bon palier, et prennent le même temps pour un client que pour cent. La page de suivi donne le total impayé d'un coup d'œil.
La suite
- Récupérer les factures directement depuis un logiciel de facturation.
- Envoyer chaque matin un récapitulatif à la comptabilité : les relances parties, à qui, et celles en échec.
- Voir et gérer dans la page de suivi les clients dont les relances sont suspendues.
- Rendre les paliers réglables, pour relancer à J+10 plutôt qu'à J+7 sans toucher au code.
Et pour une entreprise ?
Toute entreprise qui facture à échéance, artisan, cabinet ou PME de services, peut confier ses relances à un tel outil : elles partent seules, avec un ton adapté au retard, sans oublier personne ni relancer deux fois. Il se branche sur les données que vous avez déjà, et la même logique vaut pour d'autres relances : devis sans réponse, contrats à renouveler, documents manquants.
Le détail technique
- Partage des rôles : l'API (TypeScript, Express 5) décide qui relancer et à quel palier, n8n décide comment (regroupement, texte, envoi). Toutes les données restent côté API, aucune dans n8n.
- Base SQLite via le module intégré à Node 24, et TypeScript exécuté directement par Node : ni compilation, ni dépendance de base de données. Le tout tourne dans Docker.
- Retard calculé en jours entiers depuis l'échéance, dans le fuseau Europe/Paris. Paliers : J-3 de 3 à 1 jour avant l'échéance, rien de 0 à 6 jours de retard, J+7 de 7 à 14, J+15 de 15 à 29, J+30 au-delà.
- L'historique des envois a pour clé primaire le couple (facture, palier) : la base refuse le doublon. Un mail couvrant plusieurs factures est consigné en une seule transaction, et une consignation rejouée ne crée jamais de doublon.
- Consignation après l'envoi, selon la sortie du nœud mail : réussite ou échec. Une relance en échec repart à la passe suivante ; une relance envoyée et consignée, jamais.
- Modèles de mail en HTML compatible Gmail et Outlook : mise en page par tableaux, styles sur chaque balise, 600 px de large au maximum. Fragments communs pour l'en-tête, les coordonnées bancaires et la signature.
- Routes sensibles protégées par un jeton ; les adresses mail des clients ne sortent que par la route utilisée par n8n, jamais par la page de suivi.
- Jeu de démonstration aux dates relatives au jour d'exécution : plusieurs factures par client, retards de quelques jours à plus de trois mois, client en litige, factures réglées à temps ou en retard.
Contact
Un besoin similaire ?Parlons-en.
Décrivez votre situation en quelques lignes. Je vous réponds sous 48 h ouvrées.