Lorsqu’un SaaS propose plusieurs offres, la tentation est grande de gérer chaque différence avec une condition dans le code : si le client a l’offre avancée, afficher cette option ; sinon, la masquer. Cette approche fonctionne au début, mais devient fragile lorsque s’ajoutent les changements d’abonnement, les options, les essais temporaires et les exceptions commerciales. La question n’est alors plus de savoir quel bouton afficher, mais quelles capacités un compte possède, qui peut les utiliser et sous quelles conditions.
Un modèle clair sépare les décisions commerciales des règles appliquées par le produit. Il devient ainsi plus simple de modifier l’offre, de tester une transition et de garantir un comportement cohérent dans l’interface, l’API et les tâches internes. Ce guide propose des critères pour concevoir ce modèle et repérer les situations où le modèle actuel devrait être simplifié.
L’offre ne devrait pas dicter directement les règles de l’application
Une offre est une manière de présenter et de vendre un ensemble de services. Elle peut regrouper des capacités et des quotas, mais ne devrait pas être l’unique référence pour décider de chaque opération. Si l’application vérifie constamment si un compte appartient à l’offre « Pro », la logique se retrouve liée à des noms commerciaux susceptibles de changer alors que la capacité, elle, demeure.
Il est préférable de traduire l’abonnement en un ensemble explicite de droits effectifs. Un compte peut, par exemple, disposer de l’exportation, d’un nombre maximal de projets et de l’accès à une intégration. Le produit évalue ces droits, et non l’étiquette marketing. Ainsi, modifier le nom ou la composition d’une offre n’oblige pas à revoir toutes les parties de l’application qui la mentionnent.
Ce découplage facilite aussi la gestion des offres particulières. Deux comptes associés à des offres différentes peuvent partager une capacité ; deux comptes ayant la même offre peuvent différer parce que l’un a souscrit une option. La solution n’est pas d’ajouter des conditions supplémentaires, mais de représenter explicitement le résultat dont le produit a besoin.
Distinguer fonctionnalités, quotas et autorisations
Avant de choisir une architecture, distinguez quatre notions souvent confondues :
- Offre : proposition commerciale attribuée à un compte, assortie de conditions et d’une période de validité.
- Fonctionnalité activée : capacité disponible pour le compte, comme l’exportation de données ou l’utilisation d’une intégration.
- Quota d’utilisation : quantité maximale ou enveloppe applicable à une ressource, comme les utilisateurs, les projets ou le stockage.
- Autorisation : action qu’une personne donnée peut effectuer au sein du compte, selon son rôle ou sa configuration.
Une fonctionnalité peut être incluse dans l’abonnement sans être accessible à tous les utilisateurs. À l’inverse, une personne peut être autorisée à gérer des projets alors que le compte a atteint son quota. L’autorisation d’une opération peut donc nécessiter de vérifier à la fois le droit du compte, l’autorisation individuelle et l’état de la ressource.
Précisez également la signification de chaque quota. « Jusqu’à 10 projets » peut désigner des projets actifs, des projets créés pendant une période ou le nombre total de projets existants. Définissez la date de réinitialisation du compteur, le comportement lorsque le maximum est atteint et le traitement des données qui dépassent le quota après un changement d’offre. Si ces règles restent implicites, l’équipe finira par prendre des décisions différentes dans les écrans et les processus.
Où représenter les règles
Le bon emplacement dépend de la complexité et des personnes qui doivent pouvoir modifier l’offre. Pour un produit comprenant peu d’offres et évoluant rarement, une configuration versionnée avec l’application peut suffire. Cette solution est simple à examiner et à tester, à condition que les règles ne soient pas reproduites en de nombreux endroits.
Lorsque les équipes commerciales doivent ajuster la composition des offres sans déployer de code, il peut être pertinent d’enregistrer le catalogue et les attributions dans une source de données administrable. Cette approche crée de nouvelles responsabilités : contrôler les personnes autorisées à modifier la configuration, valider les changements et conserver un historique permettant de savoir quelles règles s’appliquaient à une date donnée. La modification dynamique n’est pas un avantage si chaque changement risque de placer des comptes dans un état incohérent.
Une troisième option consiste à laisser le système d’abonnement enregistrer les produits, les périodes et les options, tandis que le produit conserve une représentation interne des droits effectifs. Évitez que chaque écran consulte directement le système de facturation : cela crée un couplage entre les composants et peut produire des résultats différents en cas de retard ou d’échec de synchronisation. Déterminez quelle source fait autorité pour chaque donnée et comment l’autre est mise à jour.
Quelle que soit l’option retenue, évitez de mettre en œuvre indépendamment la même règle dans l’interface, l’API et les processus en arrière-plan. Centralisez l’évaluation des accès dans une couche réutilisable et documentez son fonctionnement. L’interface peut indiquer à l’utilisateur qu’une option n’est pas disponible, mais l’API doit vérifier l’opération à nouveau : masquer un bouton ne constitue pas une autorisation.
Gérer les changements, les transitions et les options
Un abonnement évolue au fil du temps. Il peut comporter une date d’effet ultérieure, une période d’essai, un renouvellement en attente ou une résiliation programmée. Enregistrez l’état et les dates pertinentes, puis définissez les droits applicables avant et après la transition. Évitez de fonder la décision uniquement sur une étiquette actuelle lorsque le compte a déjà convenu d’un changement futur.
Pour chaque changement d’offre, répondez explicitement aux questions suivantes :
- Quand le changement prend-il effet : immédiatement, à la fin de la période ou à une date convenue ?
- Que deviennent les ressources qui dépassent le nouveau quota ?
- La création d’éléments est-elle bloquée, d’autres actions sont-elles limitées ou une intervention est-elle nécessaire ?
- Comment l’état est-il communiqué à l’administrateur du compte ?
Ne supprimez ni ne modifiez automatiquement des données en réaction générique à une réduction d’offre. Décidez quelles actions doivent être limitées et comment rétablir un fonctionnement normal. Lorsqu’une fonctionnalité fait l’objet d’une souscription distincte, représentez l’option comme un droit indépendant, avec sa propre période de validité si nécessaire. Il n’est ainsi pas nécessaire de créer une nouvelle offre pour chaque combinaison.
Des exceptions client explicites, limitées et révisables
Les exceptions peuvent être légitimes : projet pilote, compensation ou besoin contractuel. Le risque apparaît lorsqu’elles sont implémentées sous forme de conditions particulières dispersées dans le code ou de modifications manuelles sans responsable ni date de révision.
Pour chaque exception, consignez le client ou le compte concerné, la capacité ou le quota modifié, le motif, la personne qui l’a approuvée et sa durée de validité. Si elle est temporaire, définissez dès le départ son échéance et le comportement prévu à cette date. Sans date de fin, une exception peut devenir une partie permanente du produit, sans que personne se souvienne de sa raison d’être.
Avant d’ajouter une exception, vérifiez si elle révèle un besoin plus général du produit. Si plusieurs comptes ont besoin de la même option, mieux vaut peut-être la proposer comme telle. Si une règle découle d’une obligation contractuelle, gardez-la identifiable et distincte de la logique générale. L’équipe doit pouvoir expliquer et examiner l’état d’un compte sans rechercher des conditions éparpillées.
Tests, diagnostic et migration
Testez non seulement l’attribution initiale, mais aussi les changements d’état et leurs conséquences. Au minimum, couvrez une capacité activée et une autre indisponible, un quota juste avant et juste après son seuil, un changement d’offre programmé, une option qui arrive à expiration et une exception échue. Vérifiez la même décision dans l’interface, l’API et les processus internes qui créent ou modifient des ressources.
Enregistrez suffisamment d’informations pour comprendre pourquoi une opération a été autorisée ou refusée : compte, droit évalué, quota pertinent et résultat. Évitez d’inclure des données sensibles inutiles. Le message compréhensible par l’utilisateur peut différer du détail technique, mais les deux doivent correspondre à la même décision effective.
Certains signes indiquent que le modèle doit être revu : de nombreuses vérifications fondées sur le nom de l’offre, des écarts entre l’interface et l’API, des exceptions sans responsable, des quotas dont personne ne sait préciser la signification ou des changements commerciaux qui imposent de modifier de nombreuses parties du produit. Pour migrer, commencez par inventorier les règles existantes ; définissez ensuite des droits et des quotas portant des noms stables, centralisez leur évaluation et comparez les résultats au comportement actuel sur des cas représentatifs. Procédez par étapes et conservez un mécanisme permettant de détecter les écarts avant de supprimer l’ancienne logique.
En pratique, modélisez ce que le produit autorise, et non le nom donné à chaque offre par l’équipe commerciale. Les offres et la facturation peuvent évoluer ; les capacités effectives, les quotas et les autorisations doivent rester compréhensibles, vérifiables et cohérents sur tous les points d’accès.