# Launch Durée d'achat et limites du SDK de compte

Ce changement est uniquement pour le développement local et la validation ; Launch n'a pas été déployé et le paquet SDK n'a pas été publié. Le code source actuel dépend de l'accord d'autorisation du compte Licentivo et des mises à jour officielles du SDK associées, et ne peut pas être utilisé de manière interchangeable avec l'ancien serveur qui ne prend en charge que les clés de licence à long terme.

## Responsabilités

| Capacités | Parties responsables |
| --- | --- |
| Inscription, connexion, sécurité du compte, produits, commandes, paiements, remboursements | Launch |
| Devis de renouvellement/mise à niveau, cycle d'achat, et calculs du temps absolu de début et de fin | Launch |
| Exécution de mappage et vérification de politique pour les produits/politiques autorisés référencés par un package | Licentivo ; Launch fournissent des points d'entrée pour la sélection et l'inscription |
| Licences, permissions des fonctionnalités, quotas d'appareils, sessions autorisées, licences hors ligne | Licentivo et SDK officiel |
| Liste des appareils et désappariage à distance | Licentivo ; Launch transmettent les requêtes du compte actuel et affichent les résultats |
| Sauvegarde des identifiants de connexion, récupération de compte et point d'entrée de déconnexion | SDK Launch |

Les ordres de Launch, la durée d'achat et les indicateurs de synchronisation ne permettent pas d'accéder aux fonctionnalités protégées. Les clients doivent exécuter les opérations protégées via des interfaces en cours d'exécution comme `RunFeature` fournies par le SDK officiel.

Chaque produit Launch maintient une route stable de produit public Licentivo. Différents plans pour le même produit peuvent choisir différentes stratégies, mais vous ne pouvez pas passer à un autre produit distant ; le mappage est vérifié de manière sérielle via les verrous de ligne de base de données du produit commun. L'identité du client, la sortie du plan et les configurations d'accès SDK lisent la même liaison, et les brouillons ne peuvent pas changer le contexte du produit pour les clients ayant acheté. Cela ne vérifie que la cohérence des configurations d'accès et ne détermine pas les fonctionnalités ni l'autorisation des appareils. Quand l'ancienne base de données n'a pas de champs stables, la priorité est donnée à l'historique d'achat et de sortie, et si l'unicité ne peut pas être confirmée, `PRODUCT_MAPPING_CONFLICT` est retourné. Voir les détails dans [Mapping Concurrency Fix ](/fr/launch-documents/product-mapping-fix-2026-10-24/).

## Synchronisation de la période d'achat

Réutiliser les interfaces existantes ; pas de nouveaux faits de paiement, faits de remboursement ou services de devis :

- `POST /api/v1/launch/connections`, `PUT /connections/{id}` : Enregistrer la clé publique de signature d'identité, en se connectant séparément aux environnements de production et de test.
- `PUT /api/v1/launch/connections/{id}/plans/{plan}` : Enregistrer les références de version de plan Launch non répétables ainsi que les versions distantes de produits et de stratégies.
- `POST /api/v1/launch/connections/{id}/events` : Soumettre un instantané d'achat versionné complet.
- `GET /api/v1/launch/connections/{id}/events/{event}` : Confirmer le résultat du traitement.
- `POST /api/v1/launch/connections/{id}/events/{event}/retry` : Vérifier et réessayer l'événement original.

Les instantanés n'incluent que l'ID de l'événement, l'environnement, le type d'événement, la référence d'achat, la référence de compte anonyme, le produit Launch, la référence de version de plan, la version incrémentale et `valid_from` / `valid_until` absolus ; joindre l'ancien ID de licence pendant la migration. Les clés de paiement, les prix, les e-mails des clients ou les clés de licence à long terme ne sont pas envoyés. Les achats permanents de `valid_until` sont `null`, vérifiés par Licentivo pour voir s'ils correspondent à la stratégie.

Launch confirme le paiement, enregistre les périodes de couverture d'achat immuables, et sauvegarde les tâches de synchronisation dans la même transaction de base de données. Les délais sont calculés selon les cycles calendaires journaliers/mensuels/annuels ; les renouvellements utilisent l'ancre d'achat d'origine, et si le paiement est effectué après l'expiration, il commence à la date de paiement réelle. Les devis de mise à niveau et les périodes sont toujours calculés dans Launch.

Chaque changement envoie la valeur absolue complète. Réessayez en utilisant le même ID d'événement et le même contenu ; ne pas envoyer « ajouter N jours de plus ». La persistance des tâches, les connexions à distance et la progression du traitement ; les réponses perdues, les redémarrages de processus et les travailleurs concurrents ne vont pas cumuler les délais.

HTTP 202 signifie seulement que Licentivo a été reçu. Ce n'est que lorsque `applied` est reçu que la synchronisation est considérée comme terminée ; `pending` continue de requêter, `manual_review` et `stale` non confirmés restent en état de vérification en attente. Les erreurs réseau doivent être réessayées avec un temps d'attente progressif ; après que les échecs consécutifs ont atteint la limite, cela passe à une vérification manuelle.

Les remboursements ne suppriment que la période de couverture pour la commande correspondante : rembourser une commande de mise à niveau restaure le package de base ; rembourser une commande de renouvellement supprime la partie étendue ; s'il reste des achats non remboursés, la synchronisation recalculera le résultat mais ne révoquera pas tous les achats. Une fois tous les achats remboursés, `entitlement.refunded` est envoyé. Les futurs rachats utilisent une nouvelle référence d'achat pour éviter de réactiver les licences distantes révoquées.

Les litiges ou rétrofacturations confirmés par le canal supprimés n'annulent également la couverture que pour la commande correspondante ; la commande affiche `reversed`, mais les changements réels de droits sont toujours traités après l'application du snapshot d'achat avec Licentivo. Les litiges en attente ne modifient pas l'enregistrement d'achat. Les avis de rétrofacturation en attente historiques peuvent être revérifiés et renvoyés via le canal original pour être restaurés.

Les remboursements inconnus passant par une vérification manuelle peuvent être restaurés par un administrateur en utilisant `POST /api/v1/admin/refunds/{id}/reconcile`. Les reçus doivent correspondre à la transaction originale, à la devise et au montant ; le numéro d'opération original et l'heure d'approbation ne peuvent pas être changés. Après avoir dépassé la fenêtre de réessai sécurisée, ne renvoyez pas aveuglément les demandes de fonds.

## Comptes et clients

1. Les clients utilisent `POST /api/v1/auth/login` pour établir une session de connexion réelle sur le bureau.
2. Le SDK Launch demande `POST /api/v1/software/products/{id}/identity`, en spécifiant `sandbox` ou `live`.
3. Launch émet une déclaration d'identité valide jusqu'à 120 secondes, en spécifiant le destinataire et le contexte du produit/achat, y compris la connexion réelle `sid` et la durée de validité de la connexion. La déclaration n'inclut pas les fonctionnalités, le quota de l'appareil ou les autorisations hors ligne.
4. Le SDK Launch ne transmet que `identity_token`, `launch_connection_id` et `environment` au SDK officiel en mémoire, tandis que `license_key` est vide.
5. Le SDK officiel appelle Licentivo avec `/api/v1/launch/exchange`, et Licentivo détermine l'autorisation et émet les identifiants de l'appareil ainsi que les licences de signature.

Les enregistrements de compte normaux Launch utilisent v2, ne sauvegardant que les sessions de compte et les infos de routage public, pas les assertions, les clés de licence ou les permissions d’autorisation. Lorsqu’on se déconnecte explicitement, il passe à une tâche privée v3 juste pour la révocation, qui ne peut pas être restaurée pour se reconnecter ; supprimez-la seulement après avoir confirmé que la session Launch a été révoquée. Les anciennes API `/credential` renvoient HTTP 410. Les clés publiques et les identifiants de produit peuvent être distribués avec l’appli, tandis que les clés de gestion restent sur le serveur.

## Déconnexion, arrêt, désassociation à distance

| Action | Action |
| --- | --- |
| Fermeture ordinaire / Détruit / Supprime | Garder les achats, les associations de périphériques et les comptes mémorisés activement lors de l’arrêt |
| Entrée compatible Déconnexion / Libérer le périphérique | Marquer le compte local comme déconnecté et appeler le SDK officiel pour se déconnecter, puis révoquer la session dans Launch ; les déconnexions de compte non confirmées conservent une tâche de sécurité |
| Lorsqu'il est impossible d'accéder à l'appareil, gérez-le dans Launch | Faites office de proxy pour la liste des appareils, les demandes de désactivation et le traitement des résultats pour Licentivo |

Se déconnecter du SDK officiel arrête immédiatement le processus d'utilisation de la licence, efface les identifiants en cours et révoque les liaisons à distance à l'aide d'un ticket de révocation dédié. En cas d'échec réseau, `.logout.json` du SDK doit être conservé, indiquant que la révocation à distance est en attente et ne signale pas le succès de la désactivation. Le SDK Launch ne supprime, ne parcourt, ne nettoie ni ne modifie le répertoire cache du SDK officiel ; les tickets de révocation en attente sont restaurés et traités une fois que le SDK officiel réinitialise le cache correspondant.

Les comptes Launch ont leurs propres états en attente indépendants lors de la déconnexion : en cas de panne réseau, d'annulation ou de réponses perdues, les enregistrements de sécurité nécessaires pour une nouvelle tentative ne sont pas supprimés ; se reconnecter, restaurer ou se déconnecter ne fait que renvoyer la révocation de session originale, et les tâches en attente ne peuvent pas être utilisées pour restaurer la connexion. Ils sont supprimés une fois la session terminée avec succès ou confirmée invalide via HTTP 401. La récupération inter-processus nécessite un stockage de sécurité persistant, car MemoryStore n’est valable que dans le processus en cours. Pour plus de détails, voir [Correctif et intégration de la reconnexion à la déconnexion ](/fr/launch-documents/logout-retry-fix-2026-10-24/).

Les demandes de dissociation à distance transportent `activation_id` et `expected_generation` renvoyés depuis la liste originale, et les nouvelles tentatives réutilisent `operation_id`. Launch ne compte pas les tentatives de dissociation, ni n'approuve ou n'exécute à lui seul la file d'attente de dissociation, et il ne retente pas automatiquement les anciennes opérations après les mises à jour de génération. Les tentatives restantes, les permissions de libération, les audits et les résultats finaux proviennent tous de Licentivo.

La récupération de compte via `Restore` nécessite une vérification en ligne du compte et l'obtention d'une nouvelle assertion d'identité ; Launch ne choisira pas la libération hors ligne tout seul si le service de compte échoue. Les applis qui ont besoin d'un démarrage hors ligne doivent s'intégrer selon le contrat de récupération de l'SDK officiel ; la signature, la validité hors ligne et les vérifications de l'horloge sont toujours gérées par l'SDK officiel.

## Révocation d'identité côté serveur

Interface pour connecter Licentivo V39, pas besoin de faits commerciaux ni d'interfaces de devis :

- `POST /api/v1/launch/connections/{id}/session-revocations` : révoque les anciennes connexions pour le `sid` ou le compte spécifié, et retourne un reçu pour la soumission synchronisée.
- `GET /api/v1/launch/connections/{id}/session-revocations/{event_id}` : récupère le résultat soumis de l'événement original et récupère les requêtes avec des réponses perdues.

La déconnexion normale sur le bureau ou la déconnexion forcée d'une session spécifique utilise `scope=session` ; le changement de mot de passe, la réinitialisation du mot de passe, le changement d'email, la désactivation des comptes, ou les modifications de rôle du personnel du site web qui invalident toutes les sessions utilisent `scope=account`. La déconnexion normale de session sur le site web n'affecte pas le logiciel client. Launch notifie seulement que l'identité est invalide ; les sessions autorisées à distance, les identifiants en cours d’exécution et la libération de l'appareil sont gérés par Licentivo, sans modifier les périodes d'achat ni consommer le quota de désactivation maintenu par Launch.

L'invalidation de session locale et la mise en file d'attente des notifications sont effectuées dans la même transaction. Les files d'attente bloquent les connexions et environnements existants à ce moment-là, en utilisant le même ID d'événement, l'identifiant anonyme du compte, et en réessayant la requête originale ; les connexions créées plus tard ne reçoivent pas les révocations de compte historiques. D'abord, vérifiez le reçu original, et ne le renvoyez que s'il n'existe pas ; chaque environnement conserve les résultats séparément, et l'achèvement n'est affiché que lorsque tous les reçus de succès correspondants sont reçus. La réessay automatique se fait après une déconnexion réseau, et les conflits de crédentiel/contrat nécessitent une vérification manuelle. Les administrateurs peuvent voir les notifications et réessayer depuis la page de tâche de synchronisation ; les réessais ne génèrent pas de nouveaux événements de révocation.

La révocation à l’échelle du compte utilise comme limite le `revoked_before` reçu initialement par Licentivo. Les nouvelles connexions de bureau et assertions d’identité sont suspendues tant que la notification reste en attente. Après sa confirmation, l’`auth_time` de la connexion réelle doit être strictement postérieur à la seconde limite de tous les accusés de réception d’environnement. Une connexion effectuée pendant la même seconde peut être réauthentifiée plus tard ; actualiser `iat` ou l’assertion d’identité ne permet pas de réutiliser l’ancienne connexion. La connexion au site reste disponible pour la récupération. La réactivation du compte impose également une nouvelle connexion et ne restaure pas les anciennes sessions.

## Migration des anciennes données

Les achats dont le lien avec une ancienne licence a été confirmé utilisent `entitlement.migrated`. Seul l’ID de l’ancienne licence est envoyé ; l’ancienne clé n’est ni lue ni distribuée. Après confirmation de la migration par Licentivo, un instantané indépendant portant une nouvelle version synchronise la période commerciale et l’état actuels. Les anciens résultats d’émission non confirmés et les autorisations incompatibles exigent une vérification manuelle ; les anciennes commandes de gestion ne sont pas rejouées automatiquement.

La déconnexion normale du SDK, la dissociation distante d’un appareil et la révocation d’identité côté serveur utilisent les interfaces existantes. La désactivation distante reste limitée par la durée des autorisations hors ligne déjà signées par le SDK officiel ; Launch ne garantit pas de révocation immédiate sur un appareil déconnecté.

<!-- account-store-ownership-2026-10-24 -->

La déconnexion du compte utilise une file sécurisée indépendante, un résumé de déconnexion de la session locale et une coordination entre processus. Une ancienne instance traite uniquement sa propre connexion. Après une panne de stockage, la récupération transmet d’abord la révocation du compte en attente, sans obtenir d’identité ni démarrer l’autorisation. Licentivo continue de décider des fonctionnalités, des autorisations hors ligne, des générations d’appareil et des quotas de dissociation. Voir [le correctif et les vérifications des deux systèmes](/fr/launch-documents/account-store-fix-2026-10-24/).