SaaS ou sur site : choisir comment exécuter DYCRYPT

La manière dont votre application vérifie une licence DYCRYPT ne change pas avec le modèle de déploiement. Elle utilise toujours la clé publique du produit, l’identifiant attendu et le SDK Java, Node.js, Python ou C++.

Ce qui change, c’est l’équipe qui exploite la plateforme et l’endroit où résident vos clés de signature.

Choisissez le SaaS pour aller vite

DYCRYPT SaaS permet à votre équipe de créer une organisation, de définir les produits, d’émettre les licences et de réaliser l’intégration sans exploiter de déploiement de licences. C’est le moyen le plus rapide d’évaluer le parcours et de mettre une application standard en production.

Choisissez Sovereign pour les exigences sur site

DYCRYPT Sovereign s’exécute sur site lorsque la politique, la résidence des données, l’isolation réseau ou les contrôles de sécurité existants imposent que DYCRYPT reste dans votre environnement.

Sovereign peut signer via un HSM ou un jeton PKCS#11 existant. La clé privée reste sur l’équipement pendant que DYCRYPT demande la signature nécessaire. Enterprise reste l’option adaptée au développement, aux rôles et aux intégrations sur mesure.

Protéger les clés dans les deux modèles

Votre application reçoit uniquement la clé publique ou le certificat nécessaire à la vérification. DYCRYPT conserve les opérations de signature privées dans un périmètre protégé, séparé de la gestion quotidienne des produits et licences.

Choisissez le modèle adapté à vos contraintes opérationnelles, puis conservez le même contrat côté application : vérifier la signature, appliquer le produit et la liaison machine, gérer explicitement l’état de la licence et ne jamais placer de clé privée dans l’application.