Guide complet pour la mise à jour et le déploiement de la bibliothèque de facturation Google Play v7

Si vous travaillez avec des achats intégrés sur Android, vous devrez tôt ou tard faire face à la question suivante : Bibliothèque de facturation Google Play v7Il ne s'agit pas d'une simple mise à jour : elle inclut des modifications de l'API, de nouvelles fonctionnalités d'abonnement, des exigences pour la console et des échéances très claires fixées par Google. L'ignorer n'est plus envisageable si vous souhaitez continuer à publier ou à mettre à jour votre application sur Google Play sans mauvaises surprises.

Tout au long de cet article, vous verrez comment Mise à jour et implémentation de la bibliothèque de facturation Google Play v7 Étape par étape : découvrez les différences entre PBL 5 et 6, l’intégration des abonnements, des achats ponctuels, de RTDN, les tests avec Play Billing Lab et comment s’adapter aux écosystèmes comme .NET MAUI où le support officiel est limité. L’objectif ? Vous permettre, après cette lecture, de préparer votre migration en toute sérénité et sans dépenser un centime.

Présentation de la bibliothèque de facturation Google Play v7

La bibliothèque de facturation Google Play 7 introduit des améliorations significatives dans la gestion des factures. Paiements, abonnements et formules spécialesCependant, il est conçu pour faciliter la migration. Bonne nouvelle : la plupart des nouvelles API sont optionnelles. Il vous suffit de mettre à jour la dépendance, de modifier quelques références, et votre intégration de base fonctionnera toujours.

Cette version se concentre sur trois domaines clés : nouvelles options d'abonnement (comme les quotas virtuels), un meilleur soutien pour Achats en attente sur les forfaits prépayésDes modifications de l'API ont été apportées afin de corriger les éléments obsolètes des versions précédentes (PBL 5 et 6). De plus, Google a ajusté la gestion des erreurs et la manière de traiter les transactions en attente pour éviter les incohérences.

Pour commencer, dans le module de votre application, vous devez mettre à jour la dépendance dans votre fichier build.gradle:

dependencies {
    def billingVersion = "7.0.0"
    implementation "com.android.billingclient:billing:$billingVersion"
}

Une fois cela fait, il est temps d'examiner le code qui utilise les anciennes API. De nombreux appels sont liés à Proportionnement des abonnements et facturation alternative Ces éléments ont été renommés ou supprimés ; il est donc conseillé d’examiner attentivement toutes les références à BillingClient et BillingFlowParams avant de compiler et de télécharger quoi que ce soit sur la Play Console.

Stratégies de monétisation avec achats uniques et abonnements

Lorsque vous vendez des produits numériques au sein de votre application, il ne suffit pas de simplement copier-coller la boîte de dialogue d'achat et de s'en contenter : il faut concevoir une interface de vente. une expérience utilisateur fluide tout au long du cycle d'achatCela s'applique aussi bien aux produits individuels (consommables ou non) qu'aux abonnements. Plus le processus est fluide et naturel, plus les taux de conversion sont élevés et plus le taux d'annulation est faible.

Un parcours d'achat typique avec Play Billing, qu'il s'agisse d'un abonnement ou d'un article unique, suit généralement ces étapes bien définies dont votre système backend doit également avoir connaissance :

L'utilisateur explore les produits disponibles et en sélectionne un.
L'application lance le processus de facturation Google Play pour finaliser le paiement.
L'achat est terminé et votre application reçoit le résultat.
Votre serveur valide l'achat auprès de l'API Google Play Developer.
Le contenu ou le droit correspondant est accordé à l'utilisateur dans votre système.
Google est informé que l'achat a été traité (consommé ou pris en compte).

Dans le cas des produits consommables, il est vital que consommer le jeton au bon moment pour permettre des rachats sans encombre et aider Bloquer les achats accidentels sur Google PlayDans le cadre des abonnements, vous devez contrôler les renouvellements, les périodes de grâce, les suspensions et les annulations afin que l'utilisateur reçoive exactement ce pour quoi il a payé, et pas un jour de moins.

L'intégration dans l'application ne représente que la moitié du travail : votre serveur doit maintenir un registre fiable des droits et des statuts d'achatCeci est particulièrement important si vous proposez un accès multiplateforme ou si vous avez besoin de statistiques détaillées sur les revenus, la fidélisation et le taux de désabonnement. C'est là qu'interviennent les notifications développeurs en temps réel (RTDN), qui jouent le rôle de « boîte noire » du cycle de vie d'achat.

Avec RTDN, vous pouvez réagir en quasi temps réel aux événements critiques : un nouvel achat, un échec de renouvellement, un abonnement entrant dans sa période de grâce ou un achat annulé. Cela vous permet d’élaborer des stratégies pour récupération des abonnés et prévention de la fraude, par exemple l'envoi automatique d'e-mails en cas d'échec de paiement ou les ajustements de droits si le client ne reçoit pas le message en raison de problèmes de réseau.

Notifications en temps réel pour les développeurs (RTDN) et Google Cloud Pub/Sub

Les RTDN utilisent Google Cloud Pub / Sub Il s'agit d'un système de messagerie en temps réel entre Google Play et votre système. Google Play publie des événements concernant un sujet Pub/Sub, et vous vous abonnez à ce sujet pour recevoir des notifications à chaque modification du statut d'un achat ou d'un abonnement.

Le fonctionnement de base est simple : Google Play envoie un message encodé en base64 au sujet Pub/Sub, votre abonné l’extrait, le décode et traite la notification. Dans le champ data Dans le message, vous trouverez un objet JSON Notification aux développeursqui comprend des informations telles que la version du message, le nom du package, l'heure de l'événement et des données spécifiques sur les achats ponctuels, les abonnements, les achats annulés ou les essais.

{
  "version": string,
  "packageName": string,
  "eventTimeMillis": long,
  "oneTimeProductNotification": OneTimeProductNotification,
  "subscriptionNotification": SubscriptionNotification,
  "voidedPurchaseNotification": VoidedPurchaseNotification,
  "testNotification": TestNotification
}

Grâce à ces messages, vous pouvez Maintenez la synchronisation de votre système dorsal même en cas de panne de l'appareil de l'utilisateur.Imaginez qu'un utilisateur effectue un achat, que Google Play le confirme, mais que l'appareil mobile perde la connexion avant que votre application ne reçoive la notification de la bibliothèque de facturation. Sans RTDN, vous ne le sauriez peut-être jamais. Avec Pub/Sub, votre serveur reçoit une notification distincte et peut accorder l'autorisation indépendamment du client.

Configuration Cloud Pub/Sub pour RTDN

Avant d'activer RTDN dans la console Google Play, vous devez préparer un projet dans Google Cloud Platform (GCP) Configurez ensuite le système de publication/abonnement. La procédure est relativement simple, mais il est préférable de la suivre attentivement pour éviter toute mauvaise surprise concernant les permissions ou les noms de ressources.

Création du sujet

Vous devez d'abord créer un Sujet Pub/Sub qui servira de point de publication sur Google Play. Depuis la console Google Cloud, sélectionnez votre projet, accédez à la section Pub/Sub et créez un nouveau sujet en suivant le guide officiel « Créer un sujet ». Le résultat aura un nom au format suivant :

projects/{project_id}/topics/{topic_name}

C’est ce nom complet que vous devrez coller dans la Play Console lorsque vous activerez les notifications.

Création d'abonnement

Pour lire les messages de cette discussion, vous avez besoin d'un Abonnement Pub/SubVous pouvez le configurer comme pousser comme tirerDans l'atelier de référence, nous travaillons avec l'abonnement par extraction, où votre serveur dorsal initie les requêtes pour récupérer les messages.

Consultez le guide d'abonnement Cloud Pub/Sub pour déterminer si le mode push ou pull convient le mieux à votre architecture. Une fois votre choix effectué, suivez la documentation « Ajouter un abonnement » et associez-le au sujet que vous avez créé précédemment. Dès lors, tous les messages publiés par Google Play dans ce sujet seront accessibles à votre abonné.

Autorisations pour Google Play de publier sur votre thème

Pub/Sub n'autorisera pas Google Play à publier quoi que ce soit sans votre autorisation explicite. compte de serviceDans la console Google Cloud, vous devez accéder aux paramètres des autorisations du sujet et ajouter le sujet principal :

[email protected]

Attribuez à ce compte le rôle de Éditeur Pub/Sub (Éditeur). Enregistrez les modifications et, à partir de ce moment, Google Play pourra envoyer des RTDN à votre thème sans problème d'autorisation.

Activer RTDN dans Google Play Console

Une fois le système de publication/abonnement configuré, vous devez indiquer à la Play Console où envoyer les notifications. Dans votre application sur la Google Play Console, accédez à : Monétiser avec Play > Paramètres de monétisation et repérez la section des notifications en temps réel pour les développeurs.

Vous devrez alors :

Cochez la case pour activer les notifications en temps réel.
Saisissez le nom complet du sujet Pub/Sub dans le champ correspondant, en respectant le format. projects/{project_id}/topics/{topic_name}.
Envoyez un message de test à l'aide du bouton de test.

Le message de test est essentiel pour vérifier que le L'intégration est bien mise en œuvre.Si vous disposez d'un abonnement de type « pull », vous pouvez accéder à la console Cloud, sélectionner l'abonnement, cliquer sur « Afficher les messages » et extraire le message de test. N'oubliez pas de… ack de tout message que vous lisez afin d'éviter les réceptions répétées.

Pour les abonnements push, vérifiez que votre point de terminaison reçoit bien le message et renvoie un code HTTP valide. En cas de problème, la console affichera une erreur lors de la publication du test, généralement liée au nom du sujet ou aux autorisations du compte de service.

Abonnez-vous aux essais d'applications sur le Google Play Store

Créez un système d'abonnement Pub/Sub dans votre backend.

Le thème et l'abonnement étant prêts, il est temps de mettre en œuvre un abonné qui lit et traite les RTDNGoogle fournit des exemples dans plusieurs langages ; un cas typique en Java utilise les bibliothèques clientes Cloud Pub/Sub pour démarrer un Subscriber qui écoute les messages et appelle un MessageReceiver.

Le schéma général est toujours le même : vous récupérez le message, vous décodez le champ data Vous convertissez le base64 en texte, analysez le JSON et extrayez les champs pertinents (tels que packageName, oneTimeProductNotification o subscriptionNotification) et décider de la marche à suivre dans votre système. Après avoir traité la notification avec succès, vous devez Confirmez le message par un accusé de réception. pour que Pub/Sub ne le renvoie pas.

Le code d'exemple montre comment le récepteur affiche la version et le nom du paquet, mais dans une implémentation réelle, vous iriez plus loin : Vous valideriez l'achat, accordant ainsi le droit à l'utilisateur légitime.Vous mettriez à jour votre base de données et, si nécessaire, vous appelleriez l'API Play Developer pour consommer ou reconnaître l'achat.

Lier les notifications à l'utilisateur : en utilisant obfuscatedAccountId

Un problème courant lors de la gestion des achats depuis le serveur est de savoir à quel utilisateur appartient une notification RTDN spécifique. Pour cela, l'API du client de facturation permet d'associer un identifiant de compte obscurci lorsque vous lancez le processus d'achat : obfuscatedAccountId.

L'idée est d'utiliser un identifiant stable provenant de votre système (par exemple, l'identifiant interne de l'utilisateur), mais obscurci pour des raisons de confidentialité et de sécuritéCette valeur est associée à l'achat et apparaît ensuite dans les informations renvoyées par l'API Google Play Developer, de sorte que lorsque vous recevez le RTDN et vérifiez le jeton, vous savez sans équivoque à quel compte de votre base de données vous devez accorder le droit.

Du côté client, lors de la préparation du BillingFlowParamsIl vous suffit de constituer la liste des ProductDetailsParams et appeler setObfuscatedAccountId(obfuscatedAccountId) avant de lancer le flux. Cela ne change rien à l'expérience utilisateur visible, mais simplifie considérablement le processus. logique d'allocation des achats en backend et aide Google à détecter les fraudes.

Vérifiez les achats à l'aide de l'API Google Play Developer

Avant d'accorder des droits sur votre serveur, il est obligatoire de vérifier la légitimité de l'achat en appelant le API Google Play pour développeursIl ne suffit pas de se fier à ce que dit le client ou même le RTDN : vous devez valider le purchaseToken directement contre les points de terminaison officiels, et si nécessaire gérer les remboursements.

Dans le cas de produits uniques, vous utiliserez le point de terminaison purchases.products:getPour les abonnements, le chemin mène à travers purchases.subscriptionsv2:getLe débit recommandé est :

Extraire le purchaseToken Extrait du message Pub/Sub.
Vérifiez votre base de données pour voir si vous l'avez déjà traité ; chaque jeton est unique au mondeElle est donc idéale comme clé primaire pour éviter les doublons.
S'il s'agit d'un nouveau produit, appelez l'API Google Play Developer avec le numéro de package, la référence (SKU) et le nom du produit. purchaseToken.
Vérifiez que la réponse indique un statut d'achat ACHETÉ (non en attente ni annulé).
Si tout correspond, enregistrez le jeton et accordez le droit correspondant à l'utilisateur associé.

Pour communiquer avec l'API Play Developer depuis Java, vous pouvez utiliser Éditeur Android, initialisé avec les informations d'identification du compte de service au format JSON. Vous configurez l'étendue AndroidPublisherScopes.ANDROIDPUBLISHERVous créez le client et appelez la méthode purchases().products().get(...)Si l'appel échoue en raison d'un problème temporaire de réseau ou de service, il est recommandé implémenter des nouvelles tentatives avec un délai exponentiel pour ne pas manquer l'événement.

Confirmez ou finalisez l'achat auprès du serveur

Une fois l'achat vérifié et l'autorisation accordée dans votre système, l'étape suivante consiste à informer Google que la transaction a été traitée avec succès. Pour les produits à article unique, deux options s'offrent à vous : consommer l'achat ou simplement la reconnaître.

Les produits consommables (par exemple, monnaie virtuelle, vies, etc.) doivent transiter par le point de terminaison. purchases.products:consumeCela marque le jeton comme utilisé et permet à l'utilisateur de racheter le même article sans problème. Pour les produits non consommables (comme le déblocage de la version premium à vie), vous devez appeler purchases.products:acknowledge, ce qui informe Google que l'utilisateur possède déjà le droit associé.

Les abonnements sont utilisés purchases.subscriptions:acknowledgeindiquant que l'abonnement a été traité avec succès et attribué à l'utilisateur. Si vous ne confirmez pas un achat dans un délai raisonnable, Google peut supposer qu'il y a un problème et annuler la transaction. Il est donc important que vous le fassiez. Le retour est effectué juste après l'octroi du droit.

Dans votre assistant AndroidPublisher, vous pouvez ajouter des méthodes comme executeProductPurchasesConsume y executeProductPurchasesAcknowledge qui appellent les points de terminaison correspondants. Il est également conseillé de mettre en place des mécanismes de nouvelle tentative en cas d'échecs ponctuels, afin d'éviter que le jeton ne se trouve dans un état intermédiaire dangereux.

Tests avancés avec Play Billing Lab

Un aspect souvent sous-estimé par les développeurs est la phase de test. Pour un lancement en toute confiance, il est indispensable de pouvoir simuler le fonctionnement du produit. erreurs réseau, réponses non standard et cas limitesC’est là qu’intervient Play Billing Lab, une application gratuite sur Google Play conçue spécifiquement pour tester les intégrations de la bibliothèque Play Billing.

Play Billing Lab comprend un simulateur de réponse ce qui permet de forcer différentes BillingResponseCode dans les appels de votre application à la bibliothèque de facturation. Ainsi, vous pouvez recréer des scénarios où, par exemple, le client ne peut pas finaliser son achat en raison d'un problème de réseau, mais où votre système traite correctement le RTDN et accorde finalement le droit d'achat sans intervention de l'utilisateur.

Pour que votre application puisse communiquer avec le simulateur, vous devez activer les tests de « remplacements de facturation » à l’aide des métadonnées dans le AndroidManifest.xml:

<manifest ... >
  <application ... >
    ...
    <meta-data
        android:name="com.google.android.play.largest_release_audience.NONPRODUCTION"
        android:value="" />
    <meta-data
        android:name="com.google.android.play.billingclient.enableBillingOverridesTesting"
        android:value="true" />
  </application>
</manifest>

Le label activer les substitutions de facturationTest Activez les tests de réponse simulée dans la bibliothèque de facturation. L'étiquette NONPRODUCTION indique que cette version ne doit pas être mise en production avec les modifications activées. Lors de la préparation de la version finale pour les utilisateurs, veillez à : Supprimez ces métadonnées ou utilisez un manifeste séparé.

Une fois la configuration terminée, depuis l'application Play Billing Lab, connectez-vous avec un compte de testeur de licence, activez l'option « Simuler la réponse de la bibliothèque Play Billing » et sélectionnez les codes d'erreur à renvoyer pour chaque API (par exemple, une erreur spécifique dans consumeAsyncIl vous suffit ensuite d'ouvrir votre application et d'exécuter le flux que vous souhaitez tester : le simulateur renverra les réponses configurées et vous pourrez vérifier que votre logique de nouvelle tentative, votre gestion des erreurs et RTDN se comportent comme prévu.

Principaux changements apportés à l'API lors de la migration vers Play Billing Library 7

Au-delà de RTDN et des tests, la migration vers PBL 7 implique de prendre en compte certains points spécifiques de l'API. Pour les utilisateurs de PBL 5 ou 6, il est conseillé de consulter les changements les plus importants afin de garantir une compilation sans problème et la cohérence de la logique métier.

Premièrement, les API liées à Mode de proration Les options de modification d'abonnement ont été supprimées. Désormais, voici ce qui est utilisé : Mode de remplacement pour gérer les changements de forfait (mises à niveau, rétrogradations, etc.). Si vous utilisez encore des méthodes comme setReplaceProrationMode o setReplaceSkusProrationModeVous devrez les migrer vers les nouvelles variantes de setSubscriptionReplacementMode et adapter la logique en fonction de la documentation mise à jour.

L'API a également été supprimée. launchPriceConfirmationFlowqui était déjà considérée comme obsolète. Pour gérer les modifications de prix des abonnements, veuillez vous référer aux nouvelles procédures et recommandations du guide de modification des prix, qui détaille la manière d'informer correctement l'utilisateur et de gérer son consentement.

Un autre point important est le API de facturation alternativesLes méthodes BillingClient.Builder.enableAlternativeBilling, AlternativeBillingListener y AlternativeChoiceDetails ont disparu au profit d'une nomenclature plus uniforme : vous devez désormais utiliser BillingClient.Builder.enableUserChoiceBilling() junto a UserChoiceBillingListener y UserChoiceDetailsSelon Google lui-même, il s'agit essentiellement d'un changement de nom sans modification du comportement, dans un contexte marqué par des accords tels que Google et Epic Games s'accordent sur l'ouverture d'Android.

Enfin, un nouveau code d'erreur est saisi. ERREUR_RÉSEAU en BillingResultet les significations et conditions de SERVICE_TIMEOUT et SERVICE_UNAVAILABLESi vous disposez d'une logique de gestion des erreurs personnalisée (par exemple, décider quand afficher un message à l'utilisateur, quand réessayer silencieusement, etc.), il est conseillé de la revoir afin de prendre en compte ces nouvelles nuances.

Transactions en attente et absence d'identifiant de commande jusqu'à l'achat

Un changement subtil dans PBL 7 est que la bibliothèque ne génère plus de Numéro de commande pour les achats en attente. Dans ces cas, le orderId Elle ne sera disponible qu'une fois l'achat validé. Cela concerne particulièrement les processus où l'identifiant de commande a été utilisé comme référence principale dès le départ.

Google recommande de s'appuyer sur Jeton d'achat pour vos archives et rapprochementsau moins pendant la durée de la transaction. Si vous constatez qu'un achat a disparu de Play, vérifiez Que faire si l'achat disparaît ?.

Si vous n'avez pas encore travaillé avec des soldes impayés, consultez le guide d'intégration et la documentation de la bibliothèque de facturation sur gestion du cycle de vie des achatsVous y trouverez les différents états, comment réagir à chacun d'eux et comment les RTDN s'intègrent dans ce puzzle.

Nouvelles fonctionnalités optionnelles de PBL 7 : versements virtuels et paiements anticipés

Parmi les nouvelles fonctionnalités « intéressantes » de PBL 7, on trouve : abonnements virtuels (Abonnements à paiement échelonné virtuel) et prise en charge étendue des achats en attente pour les abonnements prépayés. Ces fonctionnalités ne sont pas obligatoires, mais elles peuvent vous offrir une plus grande flexibilité pour adapter votre modèle commercial aux différents marchés.

Les paiements virtuels permettent à un utilisateur de payer un abonnement à plus long terme en petits paiements périodiquesAu lieu d'un paiement unique et important, Google explique que, pour la facturation des développeurs, vous continuez à recevoir des paiements mensuels dans le cadre d'un abonnement annuel. En cas de défaut de paiement, ni vous ni Google ne tenterez de recouvrer les mensualités impayées. De ce fait, son utilisation est très similaire à celle d'un abonnement mensuel classique, du moins dans un premier temps.

Pour l'instant, ces frais d'abonnement ne sont disponibles que dans Brésil, France, Italie et EspagneGoogle recommande de consulter régulièrement la Play Console pour connaître les nouveaux pays pris en charge. La configuration s'effectue via ProductDetails.InstallmentPlanDetails et en suivant le guide spécifique pour les intégrer à votre application.

Parallèlement, le soutien est renforcé. Achats en attente pour les abonnements prépayésVous pouvez désormais proposer des modèles où l'utilisateur initie l'achat dans l'application et finalise le paiement ultérieurement par d'autres moyens. La bibliothèque de facturation gère correctement ce flux. L'activation s'effectue par appel. enablePendingPurchases() lors de l'initialisation de BillingClient et, plus particulièrement pour les forfaits prépayés, en utilisant PendingPurchasesParams.Builder.enablePrepaidPlans().

Périodes d'amortissement pour Play Billing Library 5 et 6

Avec le lancement de PBL 7, Google a fixé des dates précises pour le retrait du support pour les versions 5 et 6Si vous êtes encore dans l'un d'eux, vous devez marquer le calendrier en rouge :

La bibliothèque de facturation Google Play 5 sera officiellement abandonnée le 31 août 2024 pour les nouvelles applications et mises à jour. Il est possible de demander une prolongation jusqu'au 1er novembre 2024, mais il est déconseillé de compter sur cette solution à long terme.
La bibliothèque de facturation Google Play 6 peut être utilisée pour publier de nouvelles applications jusqu'au 1er août 2025 et pour mettre à jour les applications existantes jusqu'au 1er novembre 2025.

Après cette date, si vous n'avez pas migré au moins vers la version 6 ou idéalement vers la version 7, vous devrez effectuer une mise à jour vers la dernière version. Version 7Les mises à jour seront bloquées sur la Play Console. Votre application continuera de fonctionner sur les appareils des utilisateurs, mais elle sera immobilisée : vous ne pourrez ni corriger les bugs ni ajouter de nouvelles fonctionnalités nécessitant une publication sur le Play Store.

Le cas de .NET MAUI et ses limitations actuelles

Si vous travaillez avec .NET MAUI et les abonnements sur Android, vous avez probablement déjà lu ou constaté que ce n'est pas si simple. De nombreux projets utilisent Plugin.InAppBilling par James Montemagno, mais le plugin est archivé et n'est plus maintenu ; il ne sera donc pas mis à jour pour prendre en charge Billing Library 7. Parallèlement, le package officiel Xamarin.Android.Google.BillingClient Il est resté ancré à l'écosystème Xamarin.Android et n'est pas directement compatible avec .NET MAUI.

La conséquence pratique est que La PlayStation avertit Votre application n'utilise pas la bibliothèque de facturation 7.0.0 ou une version ultérieure, ce qui bloque les mises à jour si vous continuez à utiliser des versions antérieures. Certains développeurs ont opté pour des solutions radicales, comme la désactivation temporaire des abonnements pour pouvoir mettre en ligne une nouvelle version, mais il est évident que cette solution n'est pas viable si votre modèle économique repose sur cette monétisation.

Dans ce contexte, de nombreuses équipes envisagent des alternatives telles que SDK tiers Ces services prennent déjà en charge PBL 7 et proposent une API multiplateforme plus stable (par exemple, des solutions de gestion d'abonnements avec des SDK pour Android, iOS et d'autres plateformes). Ils gèrent généralement les migrations de versions de la bibliothèque de facturation et offrent une interface stable, ce qui réduit considérablement la charge lors de chaque nouvelle suppression de fonctionnalité par Google.

En attendant que Microsoft et l'équipe MAUI proposent une solution Package officiel mis à jour et entièrement compatible Avec Billing Library 7, plusieurs options s'offrent à vous : implémenter votre propre liaison avec la bibliothèque de facturation native, utiliser un service tiers ou repenser l'intégration des achats dans votre projet MAUI. Dans tous les cas, il est préférable de ne pas attendre la dernière minute, car les délais de Play sont fixes.