Récupérer les paiements d'abonnement échoués (dunning) : comment garder les clients dont la carte n'est pas passée

Vous avez un client qui vous paie mois après mois, qui est content et n'a aucune intention de partir. Et pourtant, ce mois-ci son abonnement apparaît comme « annulé ». Pas parce qu'il a décidé d'arrêter, mais parce que sa carte a expiré, qu'il a manqué de fonds une journée ou que sa banque a bloqué le prélèvement récurrent. Cela s'appelle l'attrition involontaire, et c'est de loin la façon la plus frustrante de perdre du chiffre d'affaires : vous perdez des gens qui voulaient rester.

La bonne nouvelle, c'est que presque tous ces paiements peuvent être récupérés si vous avez un système de dunning. Ce n'est pas de la magie, et cela ne veut pas dire harceler vos clients par e-mail. Cela veut dire relancer le paiement aux bons moments, communiquer clairement et poliment, et rendre la mise à jour de la carte extrêmement simple. Dans cet article, je vous montre exactement comment ça marche et quoi demander à votre développeur.

Attrition involontaire vs. volontaire : ne confondez pas les deux

Avant tout, séparez deux choses complètement différentes.

Attrition volontaire = le client veut vraiment partir : il clique sur « annuler », il n'a plus besoin du service. Ici, la solution, c'est votre produit et votre offre, pas le dunning.

Attrition involontaire = le client serait resté, mais le paiement a échoué pour des raisons techniques. C'est là qu'intervient le dunning.

Les raisons typiques d'un prélèvement récurrent échoué :

• carte expirée (la plus fréquente ; les cartes sont renouvelées tous les quelques années)
• fonds insuffisants le jour du prélèvement
• la banque a marqué la transaction comme suspecte et l'a bloquée
• une limite de paiement en ligne ou une carte désactivée
• une authentification SCA/3-D Secure requise et non effectuée

Si vous traitez les deux de la même façon, soit vous agacez des gens qui partaient de toute façon, soit vous renoncez à un revenu parfaitement récupérable. La première décision est de mesurer ces deux pertes séparément, sinon vous ne savez pas ce que vous réparez.

Relances intelligentes : le moment compte plus que le nombre

La clé du dunning, ce n'est pas de relancer dix fois d'affilée ; c'est de relancer aux moments où le paiement a des chances de passer.

Deux principes qui font la différence :

• Espacez les tentatives sur plusieurs jours, pas sur des heures. Si la cause est « fonds insuffisants », il est logique de relancer quelques jours plus tard, une fois le client payé, pas dix minutes après.
• Distinguez les refus « soft » des refus « hard ». Un refus soft (fonds insuffisants, limite temporaire) mérite une relance. Un refus hard (carte clôturée, compte inexistant, transaction bloquée définitivement) ne se résout pas par une relance, seulement en demandant une nouvelle carte.

La plupart des plateformes sérieuses (Stripe, par exemple) proposent des relances automatiques avec une logique selon le type de refus. L'important est de ne pas laisser les réglages sur « défaut » sans savoir ce qu'ils font : un schéma de quatre tentatives étalé sur deux à trois semaines capte le mieux les cartes renouvelées et les salaires arrivés entre-temps.

Card updater et SCA : récupérer des paiements sans que le client bouge le petit doigt

La récupération la plus élégante est celle où le client n'apprend même jamais qu'il y a eu un problème.

Un card updater (account updater) est un service des réseaux Visa/Mastercard : quand la carte d'un client est renouvelée, le nouveau numéro et la nouvelle date d'expiration parviennent automatiquement à votre processeur. Le paiement passe sans que personne ne resaisisse quoi que ce soit. Cela vaut la peine de l'activer, car il résout en silence la cause d'échec la plus fréquente : la carte expirée.

Ensuite, il y a le SCA / 3-D Secure. Dans l'UE, les paiements récurrents doivent être configurés correctement pour ne pas exiger d'authentification à chaque prélèvement. Si le premier paiement est enregistré correctement (avec un mandat pour les paiements futurs), les prélèvements suivants passent généralement sans que la banque demande de code. Mal configuré, la banque exige une authentification chaque mois, le client ne voit même pas la demande, et le paiement échoue. C'est un réglage technique, mais c'est la différence entre un abonnement stable et un abonnement qui « saute » au hasard.

La séquence de dunning : des e-mails et messages qui récupèrent vraiment

Quand les relances automatiques échouent, la communication avec le client prend le relais. Le ton compte énormément ici : ce n'est pas une mise en demeure, c'est un service que vous lui rendez.

Une séquence qui fonctionne :

• Jour 0, au premier échec : un e-mail calme, « nous n'avons pas pu traiter votre paiement, cela arrive souvent, vous pouvez mettre à jour votre carte ici ». Un seul bouton clair vers la page de paiement.
• À la deuxième ou troisième tentative échouée : un rappel court, éventuellement aussi un SMS ou WhatsApp si vous avez le consentement, car ils sont lus plus vite qu'un e-mail.
• Avant la suspension : un message qui dit clairement ce qui se passe et quand (« l'accès s'arrête le X si le paiement ne passe pas »).

Quelques règles de bon sens :

• Faites en sorte que la mise à jour de la carte prenne moins d'une minute, sans connexion compliquée.
• Ne blâmez pas le client et n'utilisez pas un ton de recouvrement.
• Offrez une période de grâce avec accès actif, ne coupez pas le service d'emblée. Un client qui garde l'accès régularise bien plus souvent qu'un client déjà bloqué.

Ce qu'il faut demander quand vous construisez ou externalisez le système

Le dunning n'est pas un plugin qu'on coche ; c'est un petit système : logique de relance, intégration au processeur, modèles de messages, une page de mise à jour de carte et un tableau de bord où vous voyez ce qui a été récupéré.

Une courte check-list à demander à celui qui construit votre plateforme :

• relances automatiques avec distinction soft/hard decline
• account updater activé chez le processeur
• SCA correctement configuré pour les paiements récurrents
• une séquence e-mail/SMS au ton humain et à un seul appel à l'action
• une page de réactivation de carte simple, adaptée au mobile
• un rapport séparé pour l'attrition involontaire vs. volontaire

Chez MPO Web Studio, nous construisons exactement ce type de flux pour les sites et applications à abonnement, nous livrons à distance dans tout le pays, et nous vous montrons d'abord une démo préconstruite, pour que vous voyiez le rendu avant de payer quoi que ce soit. Si vous avez un abonnement qui « perd » des clients sur des paiements échoués, écrivez-nous sur WhatsApp et nous regarderons ensemble où fuit le revenu et ce qui peut être récupéré sans tout reconstruire.