Packages, entitlements et add-ons : le plan n’est pas une étiquette

Un package n’est pas seulement une étiquette posée sur une organisation. Il décide quels modules sont disponibles, quelles features sont activées, quels quotas s’appliquent, et ce qui se passe quand un tenant atteint une limite. Si cette logique vivait dans des if éparpillés, chaque changement de tarif demanderait une petite cérémonie et un déploiement.

Le moteur de packages

ReVend stocke les plans, modules, features et limites comme de la donnée. Des helpers runtime lisent le package actif du tenant et décident si les routes, les actions et les mutations soumises à quota sont autorisées. La page publique de tarifs lit dans le même catalogue, si bien que le discours commercial et le comportement de l’app ne sont pas secrètement entretenus par deux systèmes météo différents.

Quatre paliers et un sandbox

Le catalogue livre quatre paliers : free pour les enchérisseurs auction-only, starter pour les opérations Core plus la consultation et les bids en auction, professional qui ajoute Market, le flow escrow vendeur, l’API, les webhooks et la publication en auction, et enterprise avec les contrôles auction avancés et des conditions sur mesure. Un indicateur sandbox séparé sur une organisation abaisse la limite de débit API sans changer de palier, pour qu’une intégration se construise contre de vrais endpoints sans vrai volume. Les paliers sont des lignes, pas des branches de code ; un cinquième serait un INSERT.

Entitlements

Les entitlements couvrent l’accès aux modules, les sous-features et les limites numériques comme les utilisateurs, le stockage et le volume API. Le stockage, par exemple, est de 0 Go en free, 5 Go en starter, 25 Go en professional et illimité en enterprise, sauf si un admin plateforme fixe un quota par tenant. Les downgrades ne suppriment pas les données du tenant ; ils bloquent les nouvelles actions au-delà de la limite et expliquent ce qui a changé. Le tenant voit tout cela sur /settings/billing : le package, les modules dedans et dehors, l’usage en direct face aux limites, et — quand un module verrouillé l’y a envoyé via ?upgrade=... — quel module ou quelle feature a déclenché la visite. Une explication, pas un passage en caisse.

De l’air sans changer de plan

Entre « au-dessus de la limite » et « nouveau contrat signé » il y a généralement une conversation, et la plateforme a deux outils pour cet intervalle. Une période de grâce laisse un tenant travailler pendant qu’une discussion de facturation ou de package se déroule ; un override temporaire de limite lève une limite précise jusqu’à un moment choisi, avec une note qui dit pourquoi. Les deux se posent depuis le détail de l’organisation dans Admin, et les deux sont censés être assez temporaires pour ne pas désorienter le support de demain. « Override temporaire de la limite d’assets pendant le nettoyage d’import du go-live, valable jusqu’au quinze, revue de package planifiée » est une bonne note. « Besoin de plus » n’en est pas une.

Contrôle côté Admin

Les platform owners et le staff gèrent la matrice depuis /admin/platform/plans ; les platform viewers la voient en lecture seule. Les packages peuvent être créés, modifiés, dupliqués et archivés, avec un indicateur public qui décide si la page de tarifs les affiche et un indicateur featured pour la carte qui reçoit la mise en avant. La matrice des modules active les modules par package ; la matrice des features bascule les features modifiables, ouvre une boîte de dialogue de limite pour les features de type limite (une valeur ou illimité) et décide si une feature apparaît sur la carte de tarif et dans le comparatif. Les features standard sont protégées contre une bascule directe. Les changements sont sensibles côté audit, parce qu’un seul interrupteur peut faire passer un tenant de « tout marche normalement » à « pourquoi Market a-t-il disparu ? ». La souplesse tarifaire n’est utile que si elle laisse des traces.