Migrer de clés de licence maison vers Keyright sans rien casser pour vos clients

Tout système de licences maison commence de la même façon : un week-end, un GUID, une somme de contrôle, peut-être un petit « chiffrement » XOR, et une vérification qui renvoie true. Il part en prod, il marche, puis il devient discrètement une pièce porteuse. Des années plus tard, vous voulez de vrais sièges, l”activation en ligne, la révocation et un portail client — et vous butez sur la question qui arrête net la plupart des équipes : comment faire passer des milliers de clients qui exécutent déjà des clés sur le terrain vers un vrai système, sans jour de bascule, sans e-mail de réactivation en masse, et sans une semaine de tickets de support ?

C”est possible, et aucun client n”a besoin de s”en apercevoir. L”astuce est de traiter la migration comme une fenêtre de transition plutôt qu”un interrupteur, et de faire lire les deux formats au client pendant que vous réémettez discrètement de vraies licences par en dessous. Cet article est le plan concret.

À retenir : Migrez derrière une seule interface. Publiez un client qui valide d”abord la nouvelle licence signée et retombe sur votre clé héritée, émettez une licence signée pour chaque client existant à partir de vos propres enregistrements, livrez-la comme n”importe quelle mise à jour, et laissez chaque app basculer d”elle-même en silence au prochain démarrage. Gardez le repli hérité pendant un cycle de renouvellement, puis supprimez-le. Aucune réactivation, aucun jour de bascule.

Étape 1 — Inventoriez ce que vos clés actuelles encodent réellement

Avant de pouvoir mapper l”ancien vers le nouveau, vous devez savoir exactement ce que signifie votre clé artisanale. La plupart des schémas maison font passer en douce une quantité surprenante d”état dans une chaîne ou un enregistrement voisin. Écrivez-le explicitement :

• Identité — quel client, quel e-mail ou identifiant de commande.
• Portée — produit, édition/niveau, et tout interrupteur de fonctionnalité que vous avez basculé à la main.
• Durée de vie — perpétuelle, ou une date d”expiration (et où cette date vit-elle vraiment : dans la clé, dans un fichier de config, dans votre base de données ?).
• Quantité — nombre de sièges, si vous les avez jamais fait respecter (la plupart des systèmes maison ne le font pas, ce qui est souvent la raison de votre migration).

Cet inventaire est la spécification de la migration. Chaque champ devient un claim de la licence signée que vous allez émettre. Si un fait n”est pas récupérable depuis vos enregistrements, décidez sa valeur par défaut maintenant — par exemple, « les clients hérités inconnus reçoivent un terme d”un an daté de la migration » — plutôt que de découvrir le trou en plein déploiement.

Étape 2 — Comprenez pourquoi vous devez réémettre (et qui paie)

Une clé maison est vérifiée par une logique à l”intérieur de votre app : l”app décide qu”une clé est valide en regardant sa forme. C”est la faiblesse structurelle que corrige une licence signée — l”autorité se déplace vers une clé privée qui ne part jamais (nous expliquons pourquoi dans l”anatomie d”une clé de licence signée). La conséquence pour la migration est simple : vos anciennes clés ne peuvent pas être importées telles quelles, car rien ne les a signées. Vous devez frapper une vraie licence signée pour chaque client.

Le recadrage important : c”est vous qui les émettez, pas vos clients. Personne ne colle rien. Vous traduisez votre inventaire en licences signées en masse et vous les livrez. Le travail unique est d”écrire le mapping une fois ; le coût par client est nul.

Étape 3 — Dressez Keyright et émettez en masse depuis vos enregistrements

Pointez votre processus d”émission vers votre table de clients existante. Pour chaque enregistrement actif, émettez une licence signée portant les claims de l”Étape 1. Depuis un script ou un travail nocturne, c”est un appel par client contre l”API d”administration :

POST /v1/licenses
Authorization: Bearer <jeton-admin>
Content-Type: application/json

{
  "product":   "acme-suite",
  "tier":      "pro",
  "licensee":  "commandes+8831@client.example",
  "expiresAt": "2027-01-31",
  "seats":     3,
  "entitlements": { "export": "true", "max-projects": "25" },
  "externalId": "cle-heritee:4F2A-9C11-...",
  "idempotencyKey": "cle-heritee:4F2A-9C11-..."
}

Deux champs rendent un rattrapage en masse sûr à rejouer. externalId enregistre quelle clé héritée cette licence remplace, vous avez donc une piste d”audit et pouvez réconcilier plus tard. idempotencyKey signifie qu”exécuter le travail de migration deux fois ne frappe pas de licences en double : la seconde tentative renvoie la licence déjà émise. Vous allez l”exécuter plus d”une fois (un lot échoue à mi-chemin, un enregistrement manquait un champ), alors intégrez l”idempotence dès la première ligne. La même discipline compte quand vous automatisez la livraison de licences avec des webhooks pour vos ventes nouvelles.

Étape 4 — Publiez un client qui lit les deux formats

C”est le cœur d”une migration sans casse. Mettez les deux vérifications derrière une seule interface, essayez d”abord la licence signée, et ne retombez sur la clé héritée que lorsqu”aucune nouvelle licence n”est présente :

public sealed class CompositeLicenseSource
{
    private readonly KeyrightClient _keyright;
    private readonly LegacyKeyReader _legacy;

    public LicenseState Resolve()
    {
        // Préfère la vraie licence. Validate() est hors ligne et ne lève jamais :
        // une licence absente/expirée/révoquée échoue en fermé vers Free.
        LicenseInfo info = _keyright.Validate();
        if (info.IsValid)
            return LicenseState.FromKeyright(info);

        // Pas encore de licence signée — honore la clé héritée pendant la transition.
        if (_legacy.TryRead(out var legacyKey) && _legacy.IsAccepted(legacyKey))
            return LicenseState.FromLegacy(legacyKey);

        return LicenseState.Unlicensed; // échoue en fermé, comme toujours
    }
}

L”ordre compte : en vérifiant Keyright d”abord, un client qui a reçu sa licence signée cesse immédiatement de dépendre du chemin hérité, même si l”ancienne clé traîne encore sur le disque. Le repli porte les traînards. Chaque point d”appel interroge CompositeLicenseSource plutôt que de toucher l”un ou l”autre lecteur directement, donc quand vous supprimerez le repli plus tard, ce sera un changement d”un seul fichier. L”ensemble reste hors ligne d”abord et échoue en fermé — exactement les propriétés que votre vérification maison n”a sans doute jamais eues.

Étape 5 — Livrez, basculez et retirez

Maintenant la migration tourne d”elle-même. Livrez chaque licence signée comme vous livrez n”importe quelle mise à jour — empaquetée avec la prochaine version, récupérée au premier démarrage, ou par e-mail — et le client à double lecture la récupère et abandonne en silence le chemin hérité. Séquencez pour réduire le risque :

1. Basculez d”abord les ventes nouvelles. Reliez le checkout pour qu”il émette des licences signées, afin que chaque nouveau client naisse sur le nouveau système et ne touche jamais le format hérité.
2. Rattrapez les clients existants par lots. Exécutez le travail idempotent de l”Étape 3 sur votre table, les actifs les plus anciens d”abord, à l”affût des trous de mapping.
3. Gardez le repli pendant un cycle de renouvellement complet. Les clients lents à mettre à jour et les isolés (air-gapped) n”ont pas encore vu leur nouvelle licence ; le chemin hérité les maintient en marche jusqu”à ce qu”ils la voient. Ne précipitez pas ça.
4. Supprimez le repli. Une fois que les renouvellements ou la télémétrie anonyme de mise à jour montrent que le format hérité est quasi inutilisé, retirez LegacyKeyReader dans une version de routine. La migration est terminée, et le seul code restant est le vrai.

À aucun moment il n”y a eu de jour de bascule, de réactivation forcée, ni d”e-mail « veuillez ressaisir votre clé » — les trois choses qui transforment une migration en incendie de support.

Les mises en garde honnêtes

Deux choses à voir en face. D”abord, le repli hérité est, par définition, aussi faible que l”était votre ancien schéma — traitez donc la fenêtre de transition comme une échéance, pas un état permanent, et ne la gardez qu”aussi longtemps que la longue traîne en a vraiment besoin. Ensuite, tout fait client que vous ne pouvez pas récupérer depuis vos enregistrements devient une supposition ; décidez ces valeurs par défaut en amont (Étape 1) pour que les trous soient une politique délibérée, pas une surprise. Ni l”une ni l”autre n”est une raison de tarder — ce sont des raisons de cadrer la fenêtre et d”écrire le mapping avec soin.

Où Keyright s”inscrit

Keyright est bâti exactement pour ce mouvement : il émet les fichiers de licence hors ligne signés et les baux d”activation en ligne de courte durée que votre schéma maison n”a jamais eus, fait respecter sièges et node-locking côté serveur, porte droits (entitlements) et niveaux pour qu”un seul binaire déverrouille selon le plan, et vous donne un portail client hébergé plus des SDK pour .NET, Node, Python et Java qui échouent en fermé par conception. L”API d”administration et les champs externalId/idempotence sont là précisément pour qu”un rattrapage en masse depuis vos anciens enregistrements soit sûr à rejouer. Exécutez-le sur notre cloud géré ou auto-hébergé dans votre propre réseau — le même format signé dans les deux cas.

Commencez sur le plan gratuit et modélisez votre migration de bout en bout avant de payer un centime — voir les plans, ou lisez le guide de démarrage. Si vous pesez encore l”idée de bouger tout court, notre comparatif construire vs acheter détaille ce que vous cessez de maintenir le jour où vous basculez.