Faire ou acheter

Faire son licensing soi-même : ce que ça coûte vraiment

Construire une couche de licensing de zéro, c'est faisable. La question est de savoir si ça vaut le temps. Voici le détail concret de chaque brique à maintenir, avec des estimations honnêtes sur chacune.

Démarrer gratuitement avec Paperkey Lire la spec d'intégration

Ce que vous devez construire (et faire tourner)

Chaque ligne est un système que vous possédez de bout en bout si vous faites le vôtre. La colonne Paperkey montre ce que la version managée vous donne dès le premier jour.

  • Génération de clés, format, rotation

    Construire vous-même
    Écrire un générateur, choisir un schéma de préfixes, gérer la rotation sans invalider les clés live. Format CSPRNG, stocker des hashs (jamais les clés en clair). Prévoir un chemin de migration pour les anciens formats. 2 à 4 jours.
    Avec Paperkey
    Clés préfixées par namespace prêtes à l'emploi. Stockage par hash imposé. La rotation est un seul appel API.

  • Rate limiting

    Construire vous-même
    Limiteur par IP sur validate, limiteur par clé sur activation, limite plus stricte sur les endpoints d'auth. Redis ou in-memory selon l'infra. Gérer les burst, les 429, les headers Retry-After. 1 à 2 jours.
    Avec Paperkey
    Rate limits par IP et par clé livrés par défaut. Les endpoints auth ont un budget séparé plus serré.

  • Edge cases d'activation (machine swap, réinstall, seat limits)

    Construire vous-même
    Tracker les fingerprints par licence, gérer le ticket "l'utilisateur a réinstallé son OS", décider combien de machines par siège. Implémenter la désactivation, l'application du cap et la grace period. 3 à 6 jours ; charge de support continue.
    Avec Paperkey
    Cap de sièges, slots de fingerprint par machine, endpoint de désactivation et grace period intégrés. Les tickets edge case viennent chez nous.

  • Signature de webhooks (HMAC, retries, dedup)

    Construire vous-même
    HMAC-SHA-256 par delivery, clé d'idempotence dans le header, queue de retry avec backoff, auto-pause après N échecs, log par delivery, timeout 5 secondes. 2 à 3 jours pour le faire correctement ; difficile à tester.
    Avec Paperkey
    Webhooks signés HMAC-SHA-256, auto-pause après 10 échecs consécutifs, log par delivery, id de dedup sur chaque event.

  • Fingerprinting (multi-plateforme)

    Construire vous-même
    Identifiant stable après réinstallation d'OS, différent sur chaque plateforme (macOS, Windows, Linux, CI). Gérer le bypass CI pour que les pipelines de build ne consomment pas d'activations. 2 à 4 jours ; edge cases qui remontent en production.
    Avec Paperkey
    Le SDK gère le hashing. Mode CI intégré. Fonctionne sur macOS, Windows, Linux.

  • Audit log

    Construire vous-même
    Log d'events append-only, politique de rétention, export (CSV ou JSON), recherche par clé ou par client. Suppression en cascade à la suppression du compte pour rester RGPD-clean. 2 à 3 jours.
    Avec Paperkey
    Chaque activation, désactivation, révocation et delivery de webhook est loggé. Exportable. Suppression en cascade à la suppression du compte.

  • Grace period offline

    Construire vous-même
    Cache côté SDK du dernier verdict positif, TTL configurable, blocage dur sur les négatifs autoritaires (révoqué, expiré). Recette Electron/desktop documentée. 1 à 2 jours ; scénarios offline difficiles à tester en CI.
    Avec Paperkey
    Fenêtre de grace de 72 h par défaut, blocage dur sur la révocation et l'expiration. Recette Electron documentée. TTL configurable.

  • Interface de gestion (dashboard)

    Construire vous-même
    CRUD produits, licences, activations. Recherche, filtres, bouton révoquer, vue audit log. Auth-gated, RBAC. Dialogues de confirmation accessibles. Réalistement 5 à 10 jours pour un outil interne utilisable.
    Avec Paperkey
    Dashboard complet livré avec Paperkey. Recherche de licences, vue activations, config webhooks, audit log, révocation en un clic.

  • Maintenance SDK (multi-langage)

    Construire vous-même
    TypeScript pour votre app web. Python si vous avez un CLI. Go si vous avez un client backend. Même vérifieur HMAC, test vector cross-langue, changelog, semver, releases npm + PyPI + Packagist. Pour toujours.
    Avec Paperkey
    SDK TypeScript, Python, PHP sous MIT. Publiés et maintenus. Même surface, même vérifieur HMAC, test vector cross-langue.

Quand le fait-maison suffit

  • Produit unique, plateforme unique : si vous avez une seule app et un seul endpoint de validation, un contrôle de clé côté serveur simple est un point de départ raisonnable.

  • Pas de besoin offline : si votre app est toujours en ligne et que vous n'avez pas besoin d'une grace period, la surface de licensing se réduit sensiblement.

  • Pas de webhooks, pas de multi-seat : si vous n'avez pas besoin de notifier des systèmes aval et que chaque licence est mono-siège, les edge cases d'activation disparaissent.

  • Prototype ou outil interne : si l'app n'est pas encore client-facing, la version DIY peut vous faire gagner du temps avant d'investir dans une infrastructure solide.

Questions fréquentes

Paperkey est-il comparable à une couche de licensing maison ?

Sur le périmètre managé, oui. Paperkey fait ce que vous devriez construire : génération de clés, activation, validation, rate limiting, webhooks signés, audit log, dashboard. Le SDK est MIT, l'API est documentée OpenAPI 3.1 et toute la stack est self-hostable. Si vous voulez l'inspecter, la source est publique.

J'ai déjà commencé à construire le mien. Est-ce que je peux migrer ?

Vous pouvez migrer progressivement. Une réserve honnête : Paperkey génère les clés de licence, l'API de création ne prend pas une clé que vous fournissez. Pour conserver les clés que vos utilisateurs ont déjà, self-hostez et importez-les directement dans votre Postgres. Sur le managé, vous émettez de nouvelles clés Paperkey et les déployez à la prochaine mise à jour.

Puis-je self-host si je ne veux pas de dépendance SaaS ?

Oui. Le monorepo complet est MIT. Un seul Docker compose, un seul Postgres, aucun phone-home. Vous obtenez la même API et le même SDK que la version managée. Voir SELFHOST.md.

Où la version maison se plante-t-elle le plus souvent ?

Sur les edge cases : machine swap à la réinstallation, pipelines CI qui consomment des activations, dedup webhook après un échec transitoire, rotation de clés sans invalider les installs live. Chaque problème est soluble isolément, mais ensemble ils s'accumulent.

Combien de temps prend l'intégration avec Paperkey ?

Trois lignes de SDK pour valider. La spec OpenAPI et le llms-full.txt permettent à Claude ou Cursor de lire l'API et d'écrire l'intégration pour vous. La plupart des intégrations prennent moins d'une heure.

Commencez avec la version prête à l'emploi.

Free tier (100 licences actives). Sans carte. Si vous en avez besoin de plus, ou si vous voulez le contrôle total, self-hostez le monorepo MIT.

Démarrer gratuitement Lire la spec d'intégration

Vous hésitez encore ?

Lisez le quickstart de 5 minutes. Ou sautez-le : le SDK a des valeurs par défaut sensées et le dashboard se comprend tout seul.

Ouvrir la doc Ou démarrer gratuitement →