Abonnements RevenueCat : 16 cas limites et des nuits blanches

Quand j'ai décidé de monétiser TAMSIV, je savais qu'il me fallait un système d'abonnements solide. Trois tiers : Free, Pro et Team. RevenueCat s'est imposé — ils gèrent la complexité des stores pour toi. Enfin, en théorie.

L'architecture des tiers

Le plan Free donne accès aux fonctions de base avec des limites quotidiennes. Le Pro débloque tout : génération d'images IA, STT cloud Deepgram, mémos illimités. Le Team ajoute la couche collaborative : groupes hiérarchiques sur 6 niveaux, assignations, checklists.

Côté code, un fichier config/planLimits.ts centralise toutes les feature gates. Chaque fonctionnalité vérifie le plan actif avant de s'exécuter.

Les 16 cas limites des changements de plan

Un utilisateur peut upgrader, downgrader, changer de période (mensuel → annuel), ou combiner les deux. Chaque combinaison a un comportement différent. Un upgrade prend effet immédiatement avec prorata. Un downgrade est différé à la fin de la période.

J'ai compté 16 cas distincts. Pour chacun : moment d'activation, prorata éventuel, mise à jour des feature gates en temps réel, affichage correct. Trois jours de tests pour tout couvrir.

TTC, HT et obligations légales françaises

En France, on affiche les prix TTC pour les consommateurs. Les stores fournissent les prix localisés, mais il faut s'assurer que l'affichage respecte la législation. Mention "Prix TTC", lien vers les CGV, information sur le droit de rétractation.

Le PurchaseService

Tout passe par un singleton PurchaseService qui initialise RevenueCat, écoute les changements d'état, et expose le plan actif via un hook. Le service gère la restauration des achats et la synchronisation avec Supabase. Quand un utilisateur upgrade, les nouvelles fonctionnalités se débloquent instantanément.