Si un groupe d'abonnements a plus d'une variante (par exemple « Standard » à 60 €/mois et « Premium » à 90 €/mois), un client peut changer de l'une à l'autre à tout moment — pas besoin d'annuler l'abonnement en cours et de racheter. Vous pouvez aussi changer la variante d'un client à sa place depuis l'admin. Dans l'application, le bouton qui fait cela s'intitule Changer de variante. Cet article explique exactement ce qui se passe selon la variante vers laquelle vous changez.
Qui peut changer de variante
Le client, depuis son propre profil. Il trouvera un bouton Changer de variante dans le détail de l'abonnement.
Le studio, depuis l'admin. Ouvrez le détail de l'abonnement du client et vous verrez le même bouton Changer de variante. Contrairement au client, vous voyez aussi les variantes archivées et masquées dans la liste, vous pouvez donc faire passer un client sur une variante qui n'est plus dans l'offre publique.
Quatre types de changement — chacun se comporte différemment
Ce que fait un changement dépend du type de changement dont il s'agit. Il y a quatre scénarios :
Type de changement | Exemple | Ce qui se passe aujourd'hui |
Montée en gamme (même intervalle, prix plus élevé) | Mensuel Standard 60 € → Mensuel Premium 90 € | Le client est prélevé de la différence au prorata pour les jours restants, tout de suite. Le cycle de facturation ne change pas. |
Rétrogradation programmée (même intervalle, prix plus bas) | Mensuel Premium 90 € → Mensuel Standard 60 € | Rien n'est prélevé aujourd'hui. Le changement s'applique automatiquement au prochain renouvellement régulier. Le client continue de payer l'ancien prix jusqu'à la fin de la période en cours. |
Changement d'intervalle (durée de période différente) | Mensuel 90 € → Annuel 900 € | Le cycle redémarre, Stripe prélève immédiatement le prix complet de la nouvelle période, et un nouveau cycle commence aujourd'hui. |
Même prix (variante différente, même montant) | Mensuel « Pro v1 » 75 € → Mensuel « Pro v2 » 75 € | Le changement se fait immédiatement sans paiement. Le cycle reste le même. |
Détails ci-dessous.
Quand un changement est possible
L'abonnement en cours doit être Actif (rarement aussi En attente de début, même si dans la version actuelle cela ne s'applique pratiquement jamais aux abonnements récurrents — ceux-ci démarrent dès qu'ils sont payés ; ce statut concerne surtout les abonnements ponctuels).
L'abonnement ne doit pas être en cours d'annulation. Si le client a cliqué sur « Annuler à la fin de la période », il doit d'abord revenir dessus (cliquer sur Garder le renouvellement) avant de pouvoir changer.
L'abonnement ne doit pas être en pause, non payé, ni à l'état « En attente de paiement » (une vérification 3D Secure non finalisée).
Au moins 24 heures doivent s'écouler entre deux changements de variante. Le compte à rebours démarre au dernier changement effectué par le client ou le studio — et le simple fait de programmer un changement compte aussi (Scénario B). Si un client réessaie trop tôt, il verra « La variante ne peut être changée qu'une fois toutes les 24 heures. Veuillez réessayer plus tard. » Attention à un malentendu courant : annuler un changement programmé n'est pas limité dans le temps (vous pouvez l'annuler quand vous voulez), mais un nouveau changement ensuite n'est possible que 24 heures après le dernier changement — et la programmation initiale compte dans ce délai. En revanche, l'application automatique d'une rétrogradation programmée au renouvellement ne pose pratiquement jamais problème, car la programmation a généralement plus de 24 heures à ce moment-là.
La variante cible doit être dans le même groupe. Vous ne pouvez pas changer entre groupes — pour faire passer un client dans un autre groupe, il doit annuler l'abonnement en cours et en acheter un nouveau.
La variante cible doit utiliser la même devise que l'actuelle. Si la variante cible est dans une devise différente (les variantes d'un même groupe partagent généralement une devise, mais dans de rares cas elles peuvent différer), Zenamu refuse le changement avec « Cet abonnement récurrent ne peut pas être modifié dans son état actuel. Le changement de variante n'est disponible que pour les abonnements récurrents actifs. » La raison est technique : la devise d'un abonnement récurrent existant ne peut pas être changée. Le seul contournement est d'annuler l'ancien abonnement et d'en acheter un nouveau dans la devise cible.
Chaque scénario en détail
Scénario A — Montée en gamme (même intervalle, prix plus élevé)
Exemple : Un client paie 60 €/mois pour « Standard » et en est au 15e jour d'une période de 30 jours. Il passe à « Premium » à 90 €/mois.
Ce qui se passe :
Stripe crée une facture avec deux lignes : un crédit pour la partie non utilisée de Standard (−30 € pour 15 jours sur 60 €) et le montant au prorata pour 15 jours de Premium (+45 € sur 90 €). Montant net dû : 15 €.
Stripe prélève les 15 € immédiatement sur la carte du client. Aucun crédit ne reste sur le compte du client — le crédit est consommé directement au sein de cette facture.
Le cycle de facturation NE change PAS. Le prochain paiement régulier (les 90 € complets) passe à la date d'origine, en suivant le calendrier initial plutôt qu'un mois après le changement.
Pendant le changement, le client voit tout le détail : la variante actuelle, la nouvelle variante, la différence au prorata due aujourd'hui, et la date du prochain paiement régulier.
Pourquoi seulement la différence au prorata et pas le nouveau prix complet ? Le client a déjà payé pour la période en cours, il n'y a donc aucune raison de prélever le nouveau prix en entier à nouveau. Le cycle continue simplement à sa date d'origine — le client n'a pas l'impression d'avoir « redémarré » la période et de devoir repayer la totalité tout de suite.
Et si le paiement ne peut pas être prélevé tout de suite ? Si la banque du client le refuse (fonds insuffisants, carte expirée, 3D Secure requis), Stripe ne confirme pas le paiement et le changement ne se fait pas. Le client voit une erreur générique indiquant que le paiement n'a pas pu être finalisé — sans la raison précise de la banque. Vous pouvez retrouver la raison dans le tableau de bord Stripe (sur la facture ou l'abonnement concerné). Le client doit alors corriger sa carte (via Gérer le moyen de paiement dans son profil — voir Comment un client achète un abonnement récurrent) et relancer le changement. Cette rigueur est volontaire : si Zenamu changeait la variante sans que Stripe confirme le paiement, la facturation finirait dans le désordre. (Stripe est configuré de façon à annuler lui-même tout le changement quand un paiement n'est pas confirmé.)
Scénario B — Rétrogradation programmée (même intervalle, prix plus bas)
Exemple : Un client paie 90 €/mois pour « Premium » et en est au 15e jour d'une période de 30 jours. Il passe à « Standard » à 60 €/mois.
Ce qui se passe :
Rien n'est prélevé tout de suite. Aucun paiement aujourd'hui, aucun crédit.
Le client continue de payer 90 € pour les 15 jours restants de la période en cours (déjà payée, encore en Premium).
À la prochaine date de renouvellement, Zenamu fait automatiquement passer la variante à Standard et Stripe prélève 60 € (et non 90 €).
Le client comme le studio voient un avis sur le changement programmé dans le détail de l'abonnement, avec la date à laquelle il prend effet.
Le client peut annuler le changement programmé (voir ci-dessous) avant cette date et revenir à Premium.
Pourquoi aucun crédit ? Le client a payé le prix complet (plus élevé) pour la période en cours, il a donc de quoi en profiter. Plutôt que de faire restituer la différence par Stripe sous forme de crédit qu'il faudrait ensuite appliquer sur les mois suivants, le système attend simplement le prochain renouvellement et prélève le nouveau prix (inférieur). C'est plus clair pour le client.
Scénario C — Changer l'intervalle de facturation
Exemple : Un client paie 90 € par mois et en est au 15e jour d'une période de 30 jours. Il passe à la variante annuelle à 900 €.
Ce qui se passe :
Stripe redémarre le cycle de facturation dès aujourd'hui.
Il crée une seule facture de 900 € (le tarif annuel) moins un crédit au prorata pour les 15 jours non utilisés du mois d'origine (environ −45 €). Le client est en réalité prélevé d'environ 855 € (le montant net). Si le nouveau montant est supérieur au crédit pour le reste non utilisé de l'ancienne période, le crédit est appliqué directement à cette facture — aucun solde ne reste. Si le crédit est plus élevé à l'inverse (généralement lors d'un passage de l'annuel au mensuel), le crédit restant demeure sur le compte du client et s'applique aux renouvellements à venir (voir le paragraphe suivant).
Le client continue de payer annuellement à partir de maintenant ; le prochain renouvellement est dans un an à compter d'aujourd'hui.
Le même principe s'applique dans l'autre sens (annuel → mensuel) : le cycle redémarre, et la facture nette est égale au nouveau prix moins le crédit au prorata pour la partie non utilisée de l'intervalle précédent. Si le client change peu après un paiement annuel, le crédit peut être conséquent — pas forcément « petit ».
Pourquoi le cycle redémarre dans ce cas : Le client a explicitement voulu un intervalle différent (par exemple passer à l'annuel pour un meilleur prix). Redémarrer le cycle correspond à ce que le client attend.
Même limite qu'une montée en gamme : Si la banque du client refuse le paiement ou exige un 3D Secure, le changement ne se fait pas. Le client met d'abord sa carte à jour, puis confirme à nouveau le changement.
Scénario D — Même prix, variante différente
Exemple : Un client paie 75 €/mois pour « Pro v1 » et passe à « Pro v2 » au même tarif de 75 €/mois.
Ce qui se passe :
La variante change immédiatement.
Aucun paiement, aucun crédit.
Le cycle reste le même : le prochain paiement est à la même date, pour le même montant.
En pratique, cela ne sert qu'occasionnellement, par exemple après avoir renommé une variante ou fait un petit changement cosmétique.
L'aperçu détaillé avant de confirmer
Avant que le client (ou le studio) clique sur le bouton Changer de variante pour confirmer (la confirmation dans la fenêtre), il voit un aperçu détaillé dans la fenêtre. Ce qu'il affiche dépend du type de changement :
Montée en gamme : « Vous serez prélevé de 15 € aujourd'hui (la différence au prorata). Le prochain paiement régulier de 90 € est le 15 mai 2026 (la date d'origine). »
Rétrogradation programmée : « Rien n'est prélevé aujourd'hui. La variante passe à Standard le 15 mai 2026 (la prochaine date de paiement). À partir de là, vous paierez 60 €/mois. »
Changement d'intervalle : « Vous serez prélevé de 855 € aujourd'hui (900 € moins un crédit de 45 € pour les 15 jours non utilisés). Le nouveau cycle annuel commence aujourd'hui — le prochain paiement de 900 € est dans un an à compter d'aujourd'hui. »
Même prix : « La variante change tout de suite, sans nouveau prélèvement. »
Si le client a un crédit (qui peut apparaître, par exemple, après un remboursement effectué sous forme de crédit plutôt que sur la carte) : le montant de l'aperçu en tient déjà compte. Donc si l'aperçu affiche « Vous serez prélevé de 10 € aujourd'hui », le client paie bien 10 € — peu importe qu'un crédit ait été appliqué « en coulisses ». Le client ne voit pas deux chiffres ; il ne voit que le montant final.
Si Stripe ne peut pas effectuer le calcul pour une raison quelconque (une brève panne, par exemple), le client voit « Impossible de charger le calcul du paiement. Veuillez réessayer dans un instant. Si le problème persiste, contactez le prestataire. » et le bouton Changer de variante est désactivé. Dans ce cas, patientez un instant et réessayez.
Un changement programmé — comment il s'affiche dans le détail de l'abonnement
Quand une rétrogradation programmée (Scénario B) est en vigueur, le client comme le studio voient un avis jaune/orange dans le détail de l'abonnement :
Changement de variante programmé Votre abonnement passera à la variante Standard le 15 mai 2026. La variante actuelle reste active jusque-là.
[Annuler le changement programmé]
Le bouton Annuler le changement programmé est disponible aussi bien pour le client que pour le studio. Une fois confirmé, Zenamu ramène tout à son état d'origine — aucun changement n'est appliqué, le client reste sur la variante actuelle et continue de payer le même prix.
Dans de rares cas, ceci peut se produire : Si quelqu'un a modifié manuellement le prix de l'abonnement directement dans le tableau de bord Stripe entre-temps, Zenamu détecte l'écart au moment où vous annulez le changement programmé. Le bouton refuse l'action dans ce cas. Ouvrez le tableau de bord Stripe depuis le profil du client, vérifiez le prix actuel de l'abonnement et rapprochez-le manuellement de ce que le client est censé avoir.
Important — comment fonctionne la limite de 24 heures après l'annulation d'un changement programmé : Annuler un changement programmé n'est pas limité dans le temps en soi — vous pouvez cliquer sur Annuler le changement programmé quand vous voulez. Mais un nouveau changement vers une autre variante n'est possible que 24 heures après le dernier changement effectué par le client ou le studio, et la programmation initiale du changement compte dans ce délai. En pratique, cela signifie : si vous programmez une rétrogradation puis l'annulez aussitôt, vous devrez quand même attendre avant de pouvoir changer à nouveau. Après une application automatique au renouvellement, en revanche, la limite ne s'applique pratiquement jamais, car la programmation a généralement plus de 24 heures.
Ce que le client et le studio voient pendant le changement
Dans le détail de l'abonnement, cliquez sur Changer de variante.
Une fenêtre s'ouvre avec la liste des variantes du même groupe. La variante actuelle est marquée « actuel ».
Le client ou le studio choisit la variante cible. La fenêtre charge l'aperçu détaillé décrit ci-dessus.
Une fois confirmé (le bouton Changer de variante dans la fenêtre), Zenamu affiche « Variante modifiée. » (pour les scénarios immédiats) ou « Le changement d'abonnement est prévu pour la prochaine période de facturation. » (pour une rétrogradation programmée).
Après le changement
Le client continue d'utiliser l'abonnement sans interruption — il n'y a aucune coupure dans son accès aux réservations.
Les limites de réservation appartiennent au groupe, pas à la variante. Si le groupe est réglé sur max 4 réservations par semaine, cela s'applique quelle que soit la variante.
Zenamu enregistre le changement en interne comme un événement Variante changée (l'intitulé que vous verrez dans l'activité du client et dans Stripe). Avec une rétrogradation programmée, deux enregistrements de ce type s'accumulent au fil du temps (tous deux intitulés Variante changée) : un quand vous programmez le changement, et un au prochain renouvellement, quand la rétrogradation prend réellement effet.
Le statut de l'abonnement se met à jour automatiquement dans l'application pour le client comme pour l'admin — pas besoin d'actualiser la page.
Cas particuliers
Et si le groupe n'a qu'une seule variante ?
Le bouton Changer de variante n'apparaît pas — ni pour le client, ni pour vous. Il n'y a rien entre quoi changer. Si vous voulez permettre au client de changer, ajoutez au moins une variante de plus au groupe.
Le studio fait passer un client sur une variante archivée ou masquée
Dans l'admin, la liste des variantes affiche aussi celles marquées Visible uniquement par les administrateurs ou Archivée. Vous pouvez y faire passer un client — par exemple, quand vous voulez le déplacer vers une ancienne variante qui conserve son prix. Le client ne peut pas voir une telle variante lui-même ; vous seul le pouvez.
Et si vous ajoutez une nouvelle variante au groupe ?
Les clients existants verront la nouvelle variante dans la liste quand ils cliqueront sur Changer de variante. Ils peuvent changer à tout moment — ils n'ont besoin de rien d'autre de votre part.
Et si vous masquez ou archivez une ancienne variante ?
Les clients existants y restent jusqu'à ce qu'ils en changent eux-mêmes (ou que vous les déplaciez). De leur point de vue, rien ne change — ils continuent de payer le prix d'origine. Masquer ou archiver n'affecte que les nouveaux achats : les nouveaux prospects ne verront pas la variante.
Attention — et si un client a une rétrogradation programmée et que vous archivez la variante entre-temps : L'archivage n'a aucun effet sur un changement programmé déjà en cours. Depuis le moment où il a été programmé, Stripe a le nouveau prix (inférieur) en mémoire et prélèvera exactement ce montant au client au prochain renouvellement. Après un renouvellement réussi, Zenamu fait aussi passer le client sur la variante archivée localement (vous verrez la variante « archivée » dans le détail de son abonnement) et enregistre le déplacement en interne.
Si vous voulez empêcher la rétrogradation de prendre effet, vous devez explicitement annuler le changement programmé pour chacun de ces clients avant le prochain renouvellement (le bouton Annuler le changement programmé dans le détail de l'abonnement). Archiver une variante n'est pas un « interrupteur » — son seul but est d'empêcher de nouveaux clients d'acheter la variante ; il n'a aucun effet rétroactif sur les changements programmés déjà en cours.
Et si le client a un crédit ?
Le changement de variante ne crée pas de crédit — une rétrogradation programmée (Scénario B) fonctionne différemment (pas de crédit, juste le nouveau prix dès le prochain renouvellement). Un client ne peut avoir un crédit que par :
Un changement d'intervalle (Scénario C) — un petit crédit pour la partie non utilisée de la période d'origine.
Des opérations manuelles dans Stripe (par exemple, le studio a remboursé un paiement sous forme de crédit plutôt que sur la carte).
S'il existe un crédit, il est appliqué automatiquement à l'une des prochaines transactions. Pour les détails, voir l'article 12 — Remboursements et paiements contestés.
Et si un client change juste avant la fin de la période de facturation ?
Avec une montée en gamme, la différence au prorata pour les jours restants est faible (disons 2 € pour les 2 derniers jours), le prélèvement immédiat est donc bas. Le client voit ce montant dans la fenêtre avant de confirmer.
Avec une rétrogradation programmée, peu importe — elle s'applique au prochain renouvellement quoi qu'il arrive.
Pour le studio — quand intervenir
Changer de variante est, dans la grande majorité des cas, une action du client. Depuis l'admin, cela vaut la peine d'y penser dans ces situations :
Un client vous demande de le faire passer sur une variante précise (par exemple, une réduction de prix convenue).
Vous archivez une ancienne variante et voulez déplacer des clients sur une nouvelle en masse (même là, il vaut mieux en parler d'abord au client et le laisser changer lui-même).
Un client ne peut pas ou ne veut pas utiliser son profil (une longue absence, par exemple) et vous gérez son compte manuellement.
Recommandation : Avant de changer la variante d'un client depuis l'admin, prévenez-le toujours à l'avance de ce qui va se passer — que nous prélèverons la différence au prorata immédiatement (une montée en gamme), que nous programmerons le changement pour le prochain renouvellement (une rétrogradation), ou que nous redémarrerons le cycle avec un paiement complet (un changement d'intervalle). Le client doit être informé du prélèvement à l'avance, même si Stripe lui envoie automatiquement un e-mail de confirmation.
Questions fréquentes
Un client n'arrête pas de changer tous les jours — pourquoi ça ne marche pas ? La limite de 24 heures empêche ce genre d'expérimentation. Après le dernier changement effectué par le client ou le studio, 24 heures doivent s'écouler avant qu'un autre changement soit possible. Programmer un changement compte aussi dans cette limite (Scénario B). Si un client réessaie trop tôt, Zenamu affiche « La variante ne peut être changée qu'une fois toutes les 24 heures. Veuillez réessayer plus tard. » À noter : même si vous annulez le changement programmé entre-temps (ce qui n'est pas limité dans le temps), un nouveau changement attend quand même 24 heures à compter de la programmation initiale. L'application automatique au renouvellement, en revanche, ne pose pratiquement jamais problème, car la programmation a généralement plus de 24 heures.
Puis-je créer un « pack » pour un client avec 3 variantes différentes en même temps ? Non — un client ne peut jamais avoir qu'une seule variante active dans un groupe. Si vous voulez plusieurs droits simultanés, créez plusieurs groupes (le client peut alors avoir une variante de chaque groupe).
Un client a changé de variante par erreur — il voulait seulement comparer les prix. Comment annuler ?
Si c'était une montée en gamme : revenir à la variante d'origine (moins chère) relève du Scénario B — rétrogradation programmée. Le client doit attendre 24 heures et relancer le retour ; le changement ne s'applique alors qu'à la prochaine date de renouvellement (il paie le prix plus élevé jusque-là). Aucun remboursement immédiat.
Si c'était un changement d'intervalle : revenir en arrière relève à nouveau du Scénario C — changement d'intervalle (le cycle redémarre, Stripe calcule l'ajustement au prorata). Le client peut le faire après la limite de 24 heures.
Si c'était une rétrogradation programmée : le client peut cliquer immédiatement sur Annuler le changement programmé dans le détail de l'abonnement et revenir à l'état d'origine. Pas d'attente, pas de paiement.
Un client me dit que Stripe l'a prélevé du montant complet après un changement de variante — est-ce normal ? Non, sauf s'il s'agissait d'un changement d'intervalle. Avec une montée en gamme (même intervalle, prix plus élevé), seule la différence au prorata pour les jours restants doit être prélevée, pas le nouveau prix complet. Si le client signale autre chose, vérifiez la facture précise dans le tableau de bord Stripe depuis son profil — vous verrez le détail exact des lignes (crédit pour les jours non utilisés + le nouveau montant au prorata). Stripe ne prélève le nouveau prix complet que pour un changement d'intervalle.
Quand exactement une rétrogradation programmée prend-elle effet ? À la prochaine date de renouvellement selon le cycle en cours. Si le cycle d'un client est le 15 du mois et qu'il a programmé une rétrogradation le 5 mai, le changement s'applique le 15 mai (le renouvellement suivant). Il peut voir la date dans l'avis du détail de l'abonnement.
Puis-je programmer une rétrogradation pour une date future de mon choix ? Non — une rétrogradation programmée prend toujours effet à la date du prochain renouvellement régulier. Vous ne pouvez pas définir une date à vous.
Articles liés
Gérer les abonnés existants — toutes les autres actions que vous pouvez effectuer sur un abonnement
Changer le prix pour les abonnés existants — quand vous voulez changer le prix de toute une variante, plutôt que de faire changer un client en particulier
Codes promo et abonnements récurrents — les réductions ne sont pas réappliquées lors d'un changement de variante
Quand un paiement échoue — ce qui se passe si un paiement échoue lors d'un renouvellement programmé