Abonnements Stripe : les cas limites qu'on oublie toujours
Impayés, changement de plan en cours de mois, remboursements partiels : ce que j'ai appris en développant la facturation d'une plateforme SaaS.
Brancher Stripe pour encaisser un abonnement mensuel prend une journée. Gérer correctement tout ce qui peut arriver ensuite à cet abonnement — voilà le vrai travail. En développant la facturation de RésaLoto, ma plateforme SaaS pour les associations, j'ai dressé la liste des cas que presque tous les cahiers des charges oublient.
L'impayé n'est pas un événement, c'est un processus
Une carte expire, un plafond est atteint : environ 5 à 10 % des prélèvements récurrents échouent. Stripe relance automatiquement (les « smart retries »), mais votre application doit décider quoi faire entre-temps : l'utilisateur garde-t-il l'accès pendant les relances ? Pendant combien de jours ? Reçoit-il un email — et lequel ? Si tout échoue, l'abonnement passe-t-il en plan gratuit ou le compte est-il suspendu ? Aucune de ces réponses n'est technique : ce sont des décisions produit, à écrire noir sur blanc au cadrage.
Le changement de plan en cours de mois
Un client Pro passe Premium le 12 du mois : il a payé un mois de Pro, en a consommé douze jours. Stripe sait calculer le prorata — mais il faut choisir une politique : facturer la différence immédiatement, l'ajouter à la prochaine facture, ou créditer le solde. Et le passage inverse (Premium vers Pro) soulève la question qui fâche : rembourse-t-on la différence ? Sur RésaLoto, le choix a été : montée de gamme immédiate avec prorata facturé, descente de gamme appliquée à la fin de la période payée. Simple à comprendre, zéro remboursement à gérer.
Les remboursements partiels et les litiges
Un remboursement partiel est simple côté Stripe, mais votre comptabilité et vos factures doivent suivre : une facture émise ne se modifie pas, elle s'accompagne d'un avoir. Quant aux litiges (le client conteste le prélèvement auprès de sa banque), ils arrivent même aux services irréprochables : chaque contestation coûte des frais fixes et exige une réponse documentée sous quelques jours. Conserver la trace des connexions et de l'usage du service n'est pas du zèle — c'est votre dossier de défense.
Les webhooks, ou la source de vérité
Dernier point, le plus technique : l'état d'un abonnement vit chez Stripe, pas dans votre base. Paiement réussi, échec, annulation, fin d'essai — tout arrive par webhooks, qu'il faut traiter de façon idempotente (le même événement peut arriver deux fois) et dans le bon ordre. La règle que je m'impose : la base locale n'est qu'un cache de l'état Stripe, jamais l'inverse. Le jour où les deux divergent, c'est Stripe qui a raison.
La leçon
Si vous faites développer une application avec abonnements, exigez que ces cas figurent dans le cadrage : impayés, prorata, remboursements, litiges, webhooks. C'est la différence entre une facturation qui tient trois ans et une qui explose au premier client qui change d'avis un 12 du mois.