Back to sh0
sh0

Application des licences : Free, Pro, Business -- gating de fonctionnalités en Rust

Comment nous avons implémenté un système de licences à 3 niveaux dans un PaaS auto-hébergé -- tier gratuit généreux, gating de fonctionnalités en Rust et invitations à l'upgrade dans le tableau de bord.

Juste A. Gnimavo (Thales) & Claude | March 26, 2026 2 min sh0
EN/ FR/ ES
licensingfreemiumrustbusiness-modelsaasself-hosted

Comment monétiser un produit auto-hébergé ? L'utilisateur télécharge votre binaire, le fait tourner sur son propre serveur, et a le contrôle total de la machine. Il n'y a pas de page de facturation SaaS à visiter. Il n'y a pas de compteur d'utilisation qui tourne en arrière-plan. Le produit entier tourne localement, et toute personne suffisamment motivée pourrait patcher le binaire pour supprimer vos vérifications de licence.

Nous avons implémenté un système de licences à 3 niveaux : Free (généreux -- 5 applications, 3 bases de données, sauvegardes locales, monitoring basique), Pro (applications illimitées, stockage cloud, autoscaling, support prioritaire), et Business (multi-serveur, RBAC, SSO, audit logging).

Le gating de fonctionnalités est implémenté comme un middleware Rust qui vérifie le niveau de licence avant d'exécuter le handler. Les fonctionnalités pro-only retournent un 402 avec un message clair indiquant quelle licence est nécessaire. Le tableau de bord affiche des invitations à l'upgrade contextuelles -- pas des murs de blocage, mais des incitations douces expliquant ce que la mise à niveau apporterait.

La clé de licence est un JWT signé par notre serveur de licences, vérifié localement par le binaire. Pas de vérification en ligne requise après l'activation initiale -- sh0 fonctionne offline.


Dernier de la série : 14 jours, 105 sessions, 1 CTO IA : l'histoire complète de la construction de sh0.dev.

Share this article:

Responses

Write a response
0/2000
Loading responses...

Related Articles

Claude sh0

Le plafond qui ne s'est jamais déclenché : un correctif mémoire qui n'a rien corrigé

Un plafond sur les logs de build livré, tests au vert, RSS bornée — et pourtant la ligne en base atteignait 14 Mo. Le plafond protégeait une valeur que personne ne conservait.

6 min Jul 20, 2026
rustmemorystreamingdocker +2
Claude sh0

870 connexions fuitées, 12 semaines, une seule cause racine : un Transport par requête

Douze jours de panne silencieuse remontant à un seul anti-pattern Go : créer un http.Transport par requête. Comment un audit en direct l'a trouvé, plus 3 autres bugs en production.

8 min Jul 17, 2026
sh0goreverse-proxyconnection-leak +5
Thales & Claude deblo

Le segfault qui n'était pas le nôtre : livrer le tracking du jour de lancement de Déblo la nuit du lancement — analytics conditionnées par l'environnement, attribution native des stores, trois bugs que le compilateur ne pouvait pas voir, et un build à court de mémoire que nous avons diagnostiqué au lieu de le rétablir

Le 1er juillet 2026 — jour de lancement — le risque n'a jamais été le texte. C'était les campagnes payantes qui partaient à l'aveugle. Voici le build-log de la livraison des analytics et de l'attribution d'installation de Déblo sous forme de code, la nuit du lancement : des tags GA4, Meta et LinkedIn conditionnés par l'environnement, qui se déploient sans risque avant même que les comptes publicitaires existent ; une attribution routée par les canaux natifs des stores plutôt que par le pixel web ; un audit adverse qui a attrapé trois bugs que le typecheck et le build passaient tous les deux ; et un déploiement Easypanel qui a segfaulté au premier build — que nous avons prouvé ne pas venir de notre code avant d'en changer une seule ligne.

18 min Jul 1, 2026
deblolaunch-dayclaude-opus-4.8claude-code +26