Un abonnement qui se renouvelle sans histoire, c'est le rêve de tout éditeur. Le cauchemar, c'est le lundi matin où trois clients ont une carte expirée, un quatrième a été prélevé deux fois et le cinquième a conservé son accès alors qu'il n'a plus payé depuis un mois. Personne ne vous prévient de cette partie-là quand on parle de « mettre en place le paiement par abonnement ».
En bref
La facturation récurrente d'un SaaS ne se résume pas à brancher un bouton de paiement. Il faut gérer les renouvellements, les paiements échoués, les relances, l'accès au logiciel et la TVA. Un prestataire de paiement comme Stripe couvre l'encaissement, mais la logique d'accès reste à construire dans votre application.
Encaisser le premier paiement est la partie facile
Je donne mon verdict tout de suite : dans un SaaS, encaisser le premier paiement est la partie facile. Les documentations des prestataires sont bien faites, un développeur sérieux branche un formulaire de paiement en quelques jours. Le vrai travail commence au deuxième mois, quand l'argent doit rentrer tout seul et que votre logiciel doit réagir à ce qui se passe.
Concrètement, un abonnement est une machine à états. Il est en essai, actif, en retard de paiement, impayé, en pause ou résilié. Chaque état doit avoir une conséquence dans votre application : accès complet, accès limité, message d'alerte, blocage. Si cette traduction n'est pas écrite noir sur blanc dans le cahier des charges (voir à ce sujet notre article sur le cahier des charges d'une application métier), elle sera décidée en urgence par un développeur, un soir de week-end, au moment du premier incident.
Nous éditons nos propres SaaS (Simply Spa, Simply Resa, Postwa, Geko), et c'est précisément sur ce terrain que l'expérience s'acquiert. Sur Simply Resa, nous avons eu à corriger un double prélèvement. Je ne détaille pas le cas, mais la leçon est restée : tout traitement lié à un paiement doit pouvoir être rejoué sans conséquence, et c'est un principe que nous appliquons dès la conception.
Ce que le prestataire de paiement fait pour vous, et ce qu'il ne fait pas
Prenons l'exemple de Stripe Billing, la solution la plus répandue chez les éditeurs. D'après la présentation officielle de Stripe Billing, la plateforme gère les essais gratuits ou payants, les prorata, le portail client où chacun gère son abonnement et ses factures, la TVA dans plus de 90 pays, ainsi que des relances automatiques de paiements échoués. Stripe affirme récupérer en moyenne 55 % des paiements qui avaient échoué. C'est un chiffre annoncé par l'éditeur lui-même, à lire comme un ordre de grandeur et non comme une garantie.
Ce que Stripe ne fait pas, c'est décider à votre place ce que devient l'accès au logiciel. La documentation est claire sur ce point : la plupart des événements d'un abonnement arrivent de façon asynchrone, et votre application doit écouter des notifications (les « webhooks ») pour réagir. D'après la documentation Stripe sur les webhooks d'abonnement, il faut notamment traiter la facture payée, l'échec de paiement, l'authentification requise et la fin de l'abonnement.
Un détail de cette documentation mérite d'être retenu, parce qu'il évite une erreur classique : après réception d'une facture payée, il faut vérifier que l'abonnement est bien à l'état actif avant de prolonger l'accès du client. Une facture payée ne suffit pas toujours à rendre l'abonnement actif. Beaucoup d'intégrations « maison » prolongent l'accès sur le seul signal de paiement et se retrouvent avec des clients actifs sans l'être vraiment.
Les quatre moments où un abonnement casse
Que se passe-t-il quand un paiement échoue ?
C'est le cas le plus fréquent, et le plus mal traité. Une carte expire, un plafond est atteint, une banque refuse sans explication. Le prestataire retente selon un calendrier. Pour Stripe, la fonction Smart Retries choisit les meilleurs moments pour réessayer, et le réglage recommandé par défaut est de 8 tentatives sur 2 semaines, d'après la documentation sur les relances de paiement. Certains refus sont définitifs (carte perdue ou volée par exemple) : dans ce cas, aucune relance n'aboutira sans nouveau moyen de paiement.
Pendant ce temps, l'abonnement passe en retard de paiement. Votre application doit alors prévenir le client, lui proposer de mettre à jour sa carte en un clic, et décider combien de temps l'accès reste ouvert. C'est une décision commerciale, pas technique, et elle se prend avant le développement.
Et si la banque demande une validation ?
Depuis la directive européenne sur les services de paiement, certains paiements exigent une authentification forte du client. Pour un abonnement par carte, GoCardless explique que l'authentification s'applique au minimum à la mise en place initiale du paiement récurrent, la question des débits suivants restant débattue selon les régulateurs. Pour le prélèvement SEPA, le même article précise que cette exigence ne s'applique pas aux paiements encaissés via leur service, puisqu'ils sont initiés par le bénéficiaire.
Ce que cela change pour vous : le premier paiement doit être conçu pour que le client puisse valider auprès de sa banque sans perdre sa commande, et votre logiciel doit savoir relancer le client quand une action est demandée plus tard.
Comment gérer l'essai gratuit ?
L'essai est une mine d'ennuis discrets. À la fin de la période, soit le client a enregistré un moyen de paiement et le premier prélèvement part, soit il n'en a pas et l'abonnement doit se mettre en pause ou se clôturer. Stripe envoie une notification trois jours avant la fin de l'essai, ce qui permet d'écrire au client à temps. Si votre application ne s'en sert pas, vous découvrirez la conversion ratée après coup.
Et quand le client veut changer d'offre ou partir ?
Passer d'une offre à une autre en cours de mois, ajouter un utilisateur, résilier : ce sont des cas qui paraissent annexes et qui génèrent pourtant des demandes de support. Le prorata, c'est-à-dire le calcul au jour près de ce que le client doit, est géré par le prestataire. Mais l'écran qui l'explique au client, lui, vous appartient. Un client qui ne comprend pas sa facture contacte le support, ou résilie.
Carte, prélèvement SEPA ou facturation maison : le tableau de décision
| Option | Ce qu'elle règle | Ce qui reste à votre charge | Pour qui |
|---|---|---|---|
| Stripe Billing (carte, SEPA) | Encaissement, relances, TVA, portail client, essais | Lien avec l'accès au logiciel, messages clients, rapprochement comptable | La majorité des éditeurs de SaaS destinés aux TPE et PME |
| Prélèvement SEPA via un acteur spécialisé | Mandats, prélèvements, pas d'authentification forte à gérer | Gestion des rejets, des délais, des relances | Abonnements B2B à montant stable, clientèle qui préfère le prélèvement |
| Facturation développée en interne | Un contrôle total | Tout : relances, TVA, conformité, sécurité, comptabilité | Cas très particuliers (tarification inhabituelle), rarement justifié |
Mon avis, sans détour : pour un SaaS destiné à des artisans et des commerces, partir sur une plateforme de facturation existante est presque toujours la bonne décision. Reconstruire soi-même le calcul des prorata et la TVA coûte cher en temps et en risques, et ne donne aucun avantage à votre client. La valeur de votre logiciel se joue ailleurs, dans ses fonctionnalités.
L'erreur que je vois le plus souvent
Faire confiance à la page de retour après paiement. Le client paie, il est redirigé vers votre site, et l'application active son compte sur ce seul signal. Or le client peut fermer l'onglet, perdre sa connexion ou revenir par un autre chemin. La documentation de Stripe insiste sur les notifications serveur précisément pour cette raison : c'est le prestataire qui vous dit ce qui s'est réellement passé, pas le navigateur du client.
Autre point : si votre serveur ne répond pas correctement aux notifications, Stripe retente pendant plusieurs jours, et retarde la finalisation des factures en attendant. Un serveur en panne un week-end n'est donc pas qu'un problème technique : il peut décaler vos encaissements.
Ce que nous avons décidé de ne pas faire, volontairement
Sur Simply Resa, nous avons étudié une architecture plus ambitieuse de paiement pour nos clients établissements, puis nous avons décidé avec mon associé de reporter ce chantier après la livraison du module hôtel et de la caisse. Ce n'est pas un échec, c'est un arbitrage : une refonte de paiement touche à l'argent des autres, et on ne la lance pas en même temps que deux gros modules.
Pour la caisse, nous avons aussi choisi de ne pas fabriquer nous-mêmes les tickets et factures certifiés. Nous passons par un outil dédié et nous ne gardons qu'une référence dans notre base. Ce réflexe vaut pour tout éditeur : ce qui touche à la conformité comptable et fiscale se délègue à des outils qui ont cette conformité pour métier. Pour valider ce point sur votre propre produit, un expert-comptable reste le bon interlocuteur.
Les questions à poser avant de commencer
Avant de coder quoi que ce soit, sept sujets doivent être tranchés par écrit : combien de temps l'accès reste ouvert après un échec, ce qui se passe à la fin d'un essai, comment un client change de carte, comment il résilie, qui reçoit les alertes d'échec, comment les factures arrivent en comptabilité, et comment on teste tout cela sans vrais clients. Le dernier point est sous-estimé : les prestataires proposent un mode test avec des cartes fictives, utilisez-le jusqu'à avoir simulé un échec, une relance réussie, une résiliation et une carte expirée.
Si vous hésitez encore sur la forme que doit prendre votre logiciel, notre page sur le développement de SaaS sur mesure explique comment nous cadrons un projet, et l'article sur la transformation d'un outil interne en SaaS détaille les autres chantiers qui accompagnent la facturation. Pour un premier produit bien cadré, comptez environ 1 mois de développement, la facturation récurrente faisant partie des points à planifier dès le départ et non en fin de projet. Pour les entreprises de l'Oise qui veulent discuter d'un projet, nos logiciels sur mesure à Beauvais sont présentés en détail.
La facturation récurrente d'un SaaS se prépare avant le premier prélèvement. Si vous avez un projet d'abonnement, parlons-en sur la page contact, nous regarderons ensemble les états de vos abonnements et ce que votre logiciel doit en faire.
Questions fréquentes
Faut-il choisir Stripe pour la facturation récurrente d'un SaaS ?
Pour la plupart des SaaS destinés aux TPE et PME, c'est un choix cohérent : encaissement, relances, TVA et portail client sont déjà couverts. Le prélèvement SEPA via un acteur spécialisé reste pertinent pour des montants stables en B2B. Le choix se fait sur la clientèle visée et le mode de paiement qu'elle préfère.
Que faire quand le paiement d'un abonné échoue ?
Laisser le prestataire retenter selon un calendrier, prévenir le client rapidement, lui permettre de changer de carte en un clic et décider d'avance combien de temps l'accès reste ouvert. Sans cette règle écrite, chaque cas devient une négociation au cas par cas.
Peut-on se passer de webhooks ?
Non. D'après la documentation de Stripe, la plupart des événements d'un abonnement sont asynchrones. Sans écoute des notifications, votre application ne sait pas qu'un paiement a échoué, qu'une authentification est demandée ou qu'un abonnement a pris fin.
La facturation récurrente demande-t-elle un expert-comptable ?
Pour la TVA, la comptabilisation des abonnements et les factures conformes, oui, au moins pour valider le principe retenu avant la mise en production. Le développeur construit le mécanisme, mais les règles comptables relèvent de votre expert-comptable.
