Cas 003 : relance automatique des factures impayées dans une PME industrielle (DSO mesuré sur 12 mois)

TL;DR

• Client : PME industrielle de 32 salariés près de Roanne, sous-traitance mécanique, environ 180 000 EUR facturés par mois sur 90 clients actifs. Problème : DSO à 78 jours pour un contractuel de 30 jours fin de mois, et une gérante qui passait deux après-midi par semaine à relancer au téléphone.
• Stack livrée : n8n cloud + Sellsy (déjà en place) + Brevo + Slack. Setup 7 200 EUR en 4 semaines, exploitation 45 EUR par mois.
• Résultats à 12 mois : DSO moyen annuel 60 jours (78 au départ), environ 105 000 EUR de trésorerie libérée en permanence, environ 4 700 EUR d'agios économisés par an, temps de relance de la gérante passé de 7 heures à 1 heure par semaine.
• Trois incidents documentés sans maquillage : une mise en demeure envoyée à un client qui avait payé la veille, 9 jours de panne silencieuse après une mise à jour de l'API Sellsy, et un grand compte qui a exigé l'arrêt des relances automatiques.
• Anonymisé à la demande du client, chiffres réels conservés.

Pourquoi on publie ce cas

Dans notre guide sur l'automatisation des relances de factures, publié en mai, on évoquait ce déploiement en deux paragraphes : DSO de 78 à 61 jours en six semaines, 102 000 EUR de cash libéré. Plusieurs lecteurs nous ont posé la même question qu'après le cas 002 sur le support tier 1 : est-ce que ça a tenu ?

Réponse courte : oui, mais pas en ligne droite. Le DSO est remonté à 66 jours pendant l'été, un client a reçu une mise en demeure qu'il ne méritait pas, et le workflow a tourné dans le vide pendant 9 jours sans que personne ne s'en aperçoive. Voici le déroulé complet, mesuré sur 12 mois de production, échecs inclus. Même principe que sur nos deux premières études de cas : identité du client retirée, chiffres réels conservés.

Le contexte de départ

Le client est un sous-traitant mécanique de la région roannaise. 32 salariés, dont 26 en production. Environ 180 000 EUR facturés par mois, 90 clients actifs, un mix classique de l'industrie régionale : 4 donneurs d'ordre qui pèsent ensemble 35 pour cent du chiffre, une cinquantaine de PME récurrentes, et une queue de clients occasionnels.

L'état des lieux début 2025, au moment du cadrage :

• DSO à 78 jours, pour des conditions contractuelles à 30 jours fin de mois (soit environ 45 jours calendaires réels d'échéance moyenne). En clair : 33 jours de retard moyen au delà de l'échéance.
• Environ 470 000 EUR d'encours clients en permanence, dont 160 000 EUR échus.
• La gérante, qui assure aussi le commercial, passait deux après-midi par semaine à relancer : extraction Sellsy le lundi, appels et mails les mardi et jeudi après-midi. Environ 7 heures hebdomadaires, les bonnes semaines.
• Aucune traçabilité des relances : tout était dans sa tête et dans son historique d'appels.
• Une ligne de trésorerie court terme tirée presque en permanence, à environ 4,5 pour cent.

Un détail qui dit tout : le plus gros retardataire du portefeuille était aussi le plus ancien client de l'entreprise, un donneur d'ordre historique. Personne n'osait le relancer fermement. Son retard moyen : 51 jours au delà de l'échéance. On retrouvera ce client plus loin, ce n'est pas un hasard.

Ce profil n'a rien d'exceptionnel. Selon l'étude Altares du premier semestre 2025, le retard de paiement moyen en France a atteint 14,1 jours, un record depuis la sortie du Covid, et moins d'une entreprise sur deux (45 pour cent) règle ses fournisseurs à l'échéance. La Coface mesurait en 2025 que 86 pour cent des entreprises françaises sont confrontées à des retards de paiement. Et le rapport 2024 de l'Observatoire des délais de paiement (Banque de France) chiffre le manque à gagner : sans ces retards, les PME françaises auraient disposé de 15 milliards d'euros de trésorerie supplémentaire en 2024.

La différence entre une statistique nationale et une PME de 32 personnes, c'est que la statistique ne dépose pas le bilan. La Banque de France estime qu'environ un quart des défaillances d'entreprises sont liées à des problèmes de trésorerie, et 2025 a été une année record avec près de 70 000 procédures collectives selon le bilan Altares. Ce client n'en était pas là, mais sa ligne court terme tirée en continu était un signal que sa banque commençait à regarder de près.

Phase 1 : cadrage (2 semaines, sans écrire une ligne de workflow)

Comme sur tous nos projets, les deux premières semaines n'ont produit aucun code. Elles ont produit trois choses plus utiles.

L'autopsie de l'encours

On a exporté 14 mois de factures depuis Sellsy (environ 1 600 lignes) et croisé avec les dates de paiement réelles. Trois constats ont réorienté le projet :

1. Le retard était concentré, pas diffus. Les 5 plus gros retardataires représentaient 58 pour cent des jours de retard pondérés par les montants. Le problème n'était pas "90 clients qui paient mal", mais "5 clients qui paient très mal et 85 qui paient à peu près".
2. Les petits clients oubliés payaient en fait correctement quand on les relançait. Leur retard venait surtout de factures perdues ou de simples oublis, résolus par un seul rappel. La gérante, elle, concentrait ses appels sur les gros montants et laissait filer les petits, ce qui est rationnel à court terme et coûteux à long terme.
3. Environ 11 pour cent des "retards" n'en étaient pas. C'étaient des paiements reçus mais non rapprochés dans Sellsy, parce que le rapprochement bancaire était fait par l'expert-comptable avec 2 à 3 semaines de décalage. Ce point précis nous a fait frôler la catastrophe en semaine 5, on y revient.

La segmentation, signée avant le build

Trois typologies, trois séquences, validées par écrit avec la gérante :

• Donneurs d'ordre stratégiques (4 comptes) : aucune relance automatique avant J+15. Première relance en mail nominatif signé de la gérante (rédigé par le workflow, envoyé après validation en un clic dans Slack). Escalation téléphonique humaine à J+30.
• PME récurrentes (environ 50 comptes) : séquence complète automatisée. Rappel courtois à J+0 (jour d'échéance), relance ferme à J+15 avec mention des pénalités légales, mise en demeure formelle à J+30, escalation humaine à J+45.
• Clients occasionnels : même séquence, mais démarrant à J-5 avec un pré-rappel avant échéance, parce que l'analyse montrait que c'était la population qui "oubliait" le plus.

Les métriques, contractualisées

Trois cibles posées avant le build : DSO sous 65 jours à 3 mois, zéro plainte client liée à une relance injustifiée, et un rapport hebdomadaire automatique dans Slack que la gérante lit en moins de 5 minutes. Spoiler : la deuxième cible n'a pas tenu.

Phase 2 : build (4 semaines, 7 200 EUR)

Le détail technique complet du pattern est dans le guide relances, on ne le recopie pas ici. L'essentiel de l'architecture :

• n8n cloud comme moteur : un workflow quotidien qui interroge l'API Sellsy à 7h30, calcule l'âge de chaque facture ouverte, et déclenche les actions selon la séquence du segment.
• Brevo pour l'envoi des relances mail (meilleure délivrabilité qu'un envoi SMTP direct, et tracking d'ouverture utile pour les escalations : un client qui a ouvert trois relances sans payer ne reçoit pas le même appel qu'un client qui ne les a jamais ouvertes).
• Slack pour la supervision : validation en un clic des relances "donneurs d'ordre", alertes sur les mises en demeure avant envoi, et le rapport du lundi matin (encours total, top 10 retardataires, relances envoyées, paiements reçus la semaine passée).
• Stop automatique : tout paiement enregistré dans Sellsy, tout paiement partiel, ou toute réponse du client à un mail de relance suspend la séquence et crée une tâche humaine.

Coût : 7 200 EUR de forfait setup (cadrage compris), 45 EUR par mois d'exploitation (n8n cloud + Brevo). Sellsy était déjà payé. Pas de retainer sur ce projet : la gérante voulait un système qu'elle possède, on a formé sa responsable administrative à la maintenance de premier niveau (2 demi-journées).

Quatre semaines de build dont une en "shadow mode" : le workflow calculait tout et écrivait dans Slack ce qu'il aurait envoyé, sans rien envoyer. Cette semaine a permis de corriger 7 cas tordus (avoirs partiels, factures en devise, un client facturé sur deux entités juridiques) avant le moindre mail réel.

Les résultats sur 12 mois

La courbe de DSO, sans lissage

Deux lectures honnêtes de ce tableau. La première : la baisse rapide des six premières semaines venait surtout du stock de vieilles créances que personne ne relançait, c'est le gain facile. La deuxième : le vrai test était l'été, et le système a tenu sans qu'on y touche. Le DSO est remonté (les comptabilités clientes ferment en août, aucun workflow n'y peut rien), puis est redescendu seul en septembre parce que les séquences ont continué à tourner pendant que la gérante était, pour la première fois depuis des années, réellement en vacances.

En trésorerie : 18 jours de DSO sur 180 000 EUR facturés mensuellement représentent environ 105 000 EUR de cash supplémentaire permanent sur le compte. La ligne court terme n'a plus été tirée à partir du mois 4, soit environ 4 700 EUR d'agios économisés en année pleine. Et le point que la gérante cite en premier : l'achat d'un centre d'usinage d'occasion au mois 8, autofinancé, sans dossier bancaire.

Le temps humain

La gérante est passée d'environ 7 heures de relance par semaine à environ 1 heure : lecture du rapport du lundi, validation des relances donneurs d'ordre, et les appels d'escalation à J+45 (3 à 5 par mois). Les deux après-midi récupérées sont parties en prospection. Le portefeuille est passé de 90 à 96 clients actifs sur l'année. On se gardera d'attribuer ces 6 nouveaux clients au workflow : la causalité est invérifiable, et c'est exactement le genre d'attribution flatteuse qu'on reproche aux études de cas du marché. Disons que le temps commercial existait à nouveau, ce qui est une condition nécessaire et non suffisante.

Les créances sauvées

Deux dossiers méritent une mention. Un client occasionnel en difficulté a payé 6 400 EUR en trois fois après la mise en demeure de J+30, puis a déposé le bilan au mois 10 : sans la séquence, cette créance passait en perte sèche derrière les créanciers privilégiés. Un second dossier de 3 400 EUR a été réglé in extremis dans des circonstances similaires. Estimation prudente : environ 9 800 EUR sauvés. On dit prudente parce qu'on ne saura jamais ce que la relance manuelle aurait donné, mais l'historique pré-projet (deux pertes sèches de 5 200 et 7 800 EUR les deux années précédentes, sans relance structurée) donne une base de comparaison raisonnable.

Les trois incidents qu'on a payés

Incident 1 : la mise en demeure envoyée à tort (semaine 5)

Le risque identifié au cadrage s'est matérialisé exactement comme prévu, ce qui ne nous a pas empêchés de le prendre. Un client PME récurrent a payé par virement un mercredi. Le rapprochement Sellsy n'étant fait que 2 à 3 semaines plus tard par le cabinet comptable, la facture restait "ouverte" dans l'API. Le jeudi à 7h30, le workflow a franchi le palier J+30 : mise en demeure formelle, partie automatiquement.

Le client a appelé la gérante dans l'heure, vexé, à juste titre. L'appel d'excuse a calmé les choses (le client est toujours là), mais la confiance dans le système a pris un coup en interne, ce qui est le vrai coût de ce genre d'incident.

Le correctif, livré en intervention corrective (600 EUR, la seule de l'année) : un nœud de vérification qui interroge l'API Qonto en lecture avant tout envoi de palier J+30 ou supérieur, et cherche un virement entrant au montant de la facture (à 2 pour cent près) sur les 10 derniers jours. Si un paiement probable est détecté, la relance est suspendue et une tâche de vérification part dans Slack. Depuis : zéro récidive en 10 mois, et 14 suspensions justifiées. La leçon générale est dans le guide : la fiabilité d'un workflow de relance est exactement celle de votre rapprochement bancaire, et si vous ne pouvez pas accélérer le rapprochement, il faut donner au workflow un moyen de regarder le compte en banque directement.

Incident 2 : 9 jours de panne silencieuse (mois 6)

Une mise à jour de l'API Sellsy a modifié le format d'un champ de statut. Le workflow ne plantait pas : il interprétait toutes les factures comme "payées" et concluait sereinement qu'il n'y avait personne à relancer. Pas d'erreur, pas d'alerte. Le rapport du lundi affichait "0 relance envoyée", ce qui arrivait parfois les bonnes semaines, donc personne ne s'est inquiété. Pendant 9 jours.

C'est la responsable administrative qui a tiqué sur le deuxième lundi consécutif à zéro. Le correctif tient en deux mécanismes qu'on installe désormais partout : un heartbeat (le workflow écrit chaque jour dans Slack le nombre de factures ouvertes analysées, un chiffre qui ne doit jamais être nul ou aberrant) et une alerte d'incohérence si le nombre de factures "payées" varie de plus de 30 pour cent d'un jour à l'autre. Coût de l'incident : impossible à chiffrer précisément, probablement 2 à 3 jours de DSO sur le mois concerné. La leçon, déjà apprise sur le cas 002 avec le webhook Crisp et visiblement pas assez : un système qui échoue en silence est plus dangereux qu'un système qui plante bruyamment.

Incident 3 : le donneur d'ordre qui a dit stop (mois 4)

Le client historique évoqué plus haut, celui que personne n'osait relancer, a reçu ses premières relances structurées de l'histoire de la relation. Il a payé plus vite pendant deux mois. Puis son service achats a demandé formellement l'arrêt des relances automatiques et, dans le même courrier, une renégociation à 60 jours fin de mois.

On raconte cet épisode parce qu'il illustre une limite structurelle de l'automatisation : le workflow n'a pas créé ce problème, il l'a rendu visible. Ce client se finançait sur le dos de son sous-traitant depuis des années, et la relance polie mais systématique a forcé une conversation commerciale que tout le monde évitait. L'issue, négociée par la gérante sans nous : 45 jours fin de mois contractuels (au lieu de 30), en échange d'un engagement de volume sur 2026, et le compte est sorti de la séquence automatique au profit d'un point mensuel humain. Le DSO du compte s'est dégradé sur le papier, la relation s'est assainie, et la gérante considère l'échange gagnant. Un consultant en automatisation qui vous promet que l'outil règle ce genre de situation vous ment : l'outil met le sujet sur la table, c'est déjà beaucoup.

Le bilan économique complet

Sur les seuls gains définitifs mesurables (agios + créances sauvées, environ 14 500 EUR), le projet est remboursé en année 1. Le cash libéré, lui, n'est pas un gain au sens comptable : c'est de la trésorerie qui appartenait déjà à l'entreprise. Mais c'est lui qui a changé la situation stratégique du client : machine autofinancée, banque rassurée, et une gérante qui ne commence plus ses semaines par l'angoisse de l'encours. Sur la grille de lecture complète de ce type de calcul, voir notre article sur le ROI de l'automatisation en 3 cas chiffrés.

À qui ce cas se transpose, et à qui il ne se transpose pas

Ce déploiement se transpose bien si vous cochez ces cases : 40 factures sortantes par mois ou plus, un outil de facturation avec une API exploitable (Sellsy, Pennylane, Tiime, Qonto), des conditions de paiement à peu près standardisées, et un dirigeant prêt à laisser partir des relances écrites sans tout relire (avec la période de validation humaine des premières semaines, non négociable chez nous).

Il se transpose mal dans trois situations qu'on a apprises à reconnaître en cadrage. Si votre facturation passe par des portails fournisseurs imposés par les donneurs d'ordre (Coupa, Ariba, Chorus Pro pour le public), la relance mail classique rate sa cible, il faut traiter le statut dans le portail, c'est un autre projet. Si votre rapprochement bancaire a structurellement plusieurs semaines de retard et que vous ne pouvez ni l'accélérer ni donner un accès bancaire en lecture au workflow, vous enverrez des relances à des clients qui ont payé, et le coût relationnel dépassera le gain. Et si votre encours est concentré sur 2 ou 3 donneurs d'ordre qui représentent plus de la moitié du chiffre, votre problème est commercial et se règle en rendez-vous, pas en séquence mail : l'incident 3 ci-dessus en est la démonstration grandeur nature.

Pour le pattern technique détaillé (paliers, segmentation, garde-fous, choix d'outils), le guide complet reste la référence. Et si vous vous demandez par où commencer l'automatisation de vos ops au sens large, on a écrit un point de départ structuré.

L'obligation de facturation électronique de septembre 2026 va d'ailleurs rebattre légèrement les cartes sur ce sujet, plutôt en bien : les statuts de réception horodatés par les plateformes agréées rendront le déclenchement des séquences plus fiable. Ce client y sera prêt sans rien changer à son workflow, Sellsy gérant la partie plateforme. C'était un critère du cadrage initial, pas un coup de chance.

Ce qu'on referait différemment

Trois choses. On brancherait la vérification bancaire Qonto dès le jour 1 au lieu d'attendre l'incident : le risque était identifié au cadrage, on a accepté de vivre avec pour tenir le budget, c'était une fausse économie de 600 EUR. On installerait le heartbeat de monitoring dès le départ, leçon désormais gravée dans notre checklist de mise en production après deux projets qui nous l'ont apprise chacun à leur manière. Et on préparerait la gérante plus tôt à la conversation avec le donneur d'ordre historique : on savait dès l'autopsie de l'encours que la relance systématique allait provoquer cette discussion, on aurait pu la transformer en stratégie négociée au lieu de la subir au mois 4.

Le reste, on le garde : le cadrage de deux semaines sans code, le shadow mode, la segmentation signée avant le build, et le refus du retainer quand le client peut maintenir lui-même. Un système de relance n'a pas besoin d'être intelligent. Il a besoin d'être fiable, poli, et de ne jamais s'arrêter sans prévenir.