Contexte
Signal très fort. Plusieurs utilisateurs veulent revenir en V1 (frustration sur d'autres bugs) mais le bouton de désactivation de la V2 renvoie une erreur générique. Les utilisateurs se retrouvent bloqués sur la version qu'ils ne veulent plus utiliser, ce qui amplifie le mécontentement et alimente le churn.
Reports
- D-4652 — "Quand on essaie de désactiver la V2 : message d'erreur : une erreur s'est produite"
- D-4476 — "Comment revenir à la V1 ?? trop de dysfonctionnements sur la V2, je ne vois pas comment revenir"
- D-4313 (signal associé) — "J'ai déjà des bugs avec l'ancienne version, serait-il possible que quelqu'un réponde au moins à mes demandes ?" → utilisateur prêt à partir
Reproduction
- Activer la V2
- Aller dans les paramètres / menu de bascule de version
- Cliquer "Désactiver la V2" (ou "Revenir à l'ancienne version")
- Observer : message d'erreur générique "une erreur s'est produite"
Attendu
Bascule effective vers la V1, sans erreur.
Pistes d'investigation
- Vérifier l'endpoint d'opt-out (status code, payload renvoyé)
- Vérifier la mise à jour du flag utilisateur côté API et la propagation côté front
- Vérifier les logs Sentry sur la route de désactivation
- Reproduire avec un compte test en V2 active
Impact
🔴 Critique pour la perception V2. Un utilisateur qui veut sortir et ne peut pas voit son expérience se dégrader sur tous les autres bugs cumulés. Risque direct de churn / désabonnement. À traiter en priorité même si la V2 a d'autres bugs en parallèle — c'est la soupape de sécurité du rollout.