Convertir un essai en licence payante sans réinstallation

L”essai a fait son travail : quelqu”un a installé votre logiciel, l”a utilisé et a décidé de payer. La conversion qui suit devrait être le moment le plus facile de toute la relation — et trop souvent c”est le plus maladroit : elle exige une nouvelle clé par e-mail, une ressaisie, parfois une réinstallation, et à l”occasion la découverte que son travail d”essai a disparu. Rien de tout cela n”est nécessaire. Un essai et une licence payante sont le même genre de chose — une concession signée de droits — donc convertir l”un en l”autre est un changement d”attributs, pas un remplacement.

Mettez la clé à niveau sur place

Le modèle le plus propre n”émet aucune nouvelle clé. La clé d”essai que le client a déjà activée devient sa licence payante. Sur le serveur, quand le paiement réussit, vous changez le niveau de cette licence du niveau d”essai au niveau payant et prolongez ou supprimez son expiration :

// On a successful payment for a customer who is already on a trial key:
await licenses.Upgrade(trialKey, new UpgradeRequest
{
    Tier     = "pro",      // trial tier → paid tier
    ExpiryUtc = null,      // perpetual; or a renewal date for a subscription
    Seats    = seatsPaid,  // bump the seat count if the plan includes more
});

Rien sur la machine du client ne change. La clé dans son app est la même chaîne ; seul ce que cette clé signifie a changé, côté serveur. Comparé à l”émission d”une nouvelle clé, cela supprime un e-mail, un copier-coller et toute une catégorie de tickets de support « je n”ai jamais reçu ma clé ».

Si votre facturation est automatisée, cette mise à niveau est exactement ce qu”un webhook de fulfillment devrait faire sur un événement paid pour une commande liée à un essai existant, de façon idempotente, avec pour clé la référence de commande.

Rafraîchissez les droits en cache

C”est ici que la conversion sur place semble souvent cassée : le client paie, rouvre l”app, et elle dit toujours « Essai — 0 jour restant ». La mise à niveau a fonctionné ; l”app lit un cache périmé.

Les SDK de licences mettent en cache une lease signée pour que l”app valide hors ligne entre les check-ins. Cette lease en cache a été émise quand la clé était un essai, elle porte donc encore le niveau et l”expiration d”essai. Le correctif est de forcer une nouvelle validation après la conversion plutôt que de faire confiance au cache :

// After the user completes payment (or on app resume), re-validate ONLINE.
var info = await client.ActivateAsync(key);     // re-activate pulls a fresh lease
// or: await client.ValidateOnlineAsync(key);

if (info.Status == LicenseStatus.Valid && !info.IsTrial)
{
    ApplyEntitlements(info.Entitlements);  // paid tier's flags + limits now apply
    ShowStatus("Licensed");                // trial banner gone
}

La nouvelle lease porte les droits du niveau payant, remplaçant la lease d”essai en cache. Donnez à l”utilisateur une action évidente « J”ai acheté — rafraîchir ma licence », et revalidez aussi au prochain lancement, afin que même un utilisateur qui ferme l”app avant de rafraîchir soit mis à niveau automatiquement la fois suivante.

Concevez l’expiration pour que payer restaure simplement

La conversion n”est pas toujours le jour même. Beaucoup de clients essaient, laissent expirer, et reviennent des semaines plus tard. Ce que votre app fait à l”expiration décide si ce retour est une mise à niveau en un clic ou une impasse.

La règle : l”expiration dégrade, elle ne détruit jamais. Quand un essai se termine, repliez vers un mode lecture seule ou gratuit et laissez tout le travail de l”utilisateur en place. Alors le retour est trivial : il paie, la clé se met à niveau, l”app revalide, et les fonctionnalités se rallument sur des données qui l”attendaient. Si à la place vous effacez des projets ou le verrouillez hors de ses propres fichiers à l”expiration, vous avez supprimé la raison la plus forte qu”il avait d”acheter, et transformé « cliquer pour mettre à niveau » en « tout recommencer ». Un essai qui expire en lecture seule convertit ; un essai qui expire en porte verrouillée, non.

C”est aussi pourquoi échouer en fermé pour les licences devrait vouloir dire « désactiver les fonctionnalités payantes », pas « désactiver l”app ». Le client dans la fenêtre de conversion est votre meilleur prospect ; la pire chose à faire est de prendre ses données en otage.

Quelques détails qui paient

• Un essai par client. Liez l”essai à un e-mail ou à un appareil pour qu”un essai expiré ne puisse pas simplement redémarrer gratuitement. À la conversion, cette même identité relie la licence payante à l”essai — c”est ainsi que vous mesurez le taux d”essai-vers-payant plus tard.
• Reportez le contexte. Comme c”est la même installation et la même clé, les réglages, projets et préférences survivent automatiquement. Ne réinitialisez rien à la mise à niveau ; tout l”intérêt est la continuité.
• Rendez « déjà payé ? » évident. Une seule action visible qui revalide transforme un « ça dit toujours essai » déroutant en un problème résolu sans aller-retour avec le support.
• Gérez le cas expiré-puis-payé explicitement. Si l”essai a déjà expiré, la mise à niveau peut devoir réactiver la clé sur la machine actuelle ; assurez-vous que ce chemin rafraîchit aussi la lease.

Émettre un essai est la façon dont vous gagnez la chance de convertir. Bien convertir est un travail plus discret — mettre à niveau sur place, rafraîchir la lease, protéger les données — mais c”est la différence entre un client qui clique une fois et un qui se demande où est passée sa clé. Traitez l”essai et la licence payante comme le même objet dans deux états, et la mise à niveau devient ce qu”elle devrait être : presque invisible.