Limites de temps de jeu

1) Pourquoi des limites de temps sont nécessaires

• le respect des exigences en matière de licence et d'éthique ;
• réduire les plaintes et les charjbacks ;
• des mesures durables de LTV par un comportement sain.

2) Types de restrictions (taxonomie recommandée)

Remarque : les limites de temps doivent être harmonisées avec les limites de dépôt/perte et de vérification de la réalité.

3) Politiques et règles d'application

La réduction des limites prend effet immédiatement.
Promotion - seulement après refroidissement (24-168 h ; consigner dans la politique).
Pause obligatoire lorsque le seuil de session est atteint (par exemple, 90 min) - la fenêtre est bloquée de 5 à 15 min avec le compte à rebours.
Couvre-feu : volontaire (par consentement) ou « par défaut » pour les profils à haut risque/normes régionales.
Journaux : Fixation immuable des installations/modifications/verrous (WORM).

4) Modèles UX sans techniques « sombres »

Principes : visibilité égale « Pause/Continuer », chiffres clairs (minutes/heures), TZ local, sans promo dans les fenêtres.

• Profil → « Auto-contrôle » → « Temps de jeu » : limites de session/jour/semaine + couvre-feu.
• Indicateur de progrès dans le jeu : « Aujourd'hui : 45 min sur 90 min ».
• Vérification de la réalité avec minuterie et net-result (pas de pression de retour).

• Onbording : "Sélectionnez les limites de temps. La réduction est immédiate, l'augmentation est après 48 heures (refroidissement)"
• Avant la pause : « Vous jouez 90 min Pour votre sécurité, une pause de 10 min Pendant la pause, les paris ne sont pas disponibles ».
• La limite journalière est atteinte : "La limite journalière de temps (120 min) est épuisée. Le jeu sera disponible demain à partir de 00h00 "
• Demande d'augmentation : "L'augmentation de la limite journalière à 180 min entrera en vigueur dans 48 heures. Voulez-vous confirmer ?"

5) Déclencheurs et escalades (échelle d'intervention)

1. Nuji doux (30-60 min) : rappel du temps/pause, boutons « Pause 15 min/Ajuster les limites ».
2. Conseils renforcés (limite de 80 %) : offre de délai/réduction des limites.
3. Pause obligatoire (100 % du seuil de session).
4. Verrouillage du temps lorsque la limite journalière/hebdomadaire est atteinte.
5. Offre d'auto-exclusion en cas de dépassement constant et autres signaux RG (chasing, sessions nocturnes).
6. Le contact de Sapport est un homme-en-circuit avec reason-codes.

6) Cas difficiles et comment les résoudre

Multi-appareils/onglets : comptez la fenêtre de jeu active ; Dédupliquez les sessions parallèles, utilisez les événements heartbeat.
Sessions de tournoi/vie : prévenez à l'avance, appliquez la « période grace » jusqu'à la fin du tirage, mais fixez une pause obligatoire immédiatement après.
AFC/inactivité : auto-pause et auto-logout après N minutes d'inactivité (ne pas débiter l'AFK pendant le « jeu »).
Multi-verticaux : limites individuelles par vertical + limite de compte « chapeau » totale.
Times/DST : Stockez les étiquettes dans UTC, affichez dans les localités du joueur ; la règle de période est par TZ local.
Disponibilité : contraste/polices, support des lecteurs d'écran, textes compréhensibles.

7) Communication avec d'autres outils RG

Reality Checks : montrent les progrès dans le temps, offrent une pause/temporisation/auto-exclusion.
Limites de dépôt/perte : lorsque le temps est épuisé - bloquer et les dépôts/taux.
L'auto-exclusion : avec le statut actif, aucun indice de jeu n'est affiché - seulement de l'information.

8) Architecture (référence)

Time Limits Service : garde les limites et les résidus, aggregate les événements heartbeat, compte les minutes actives.
Event Bus: `session. start`, `session. heartbeat`, `session. end`, `bet. placed`, `bet. settled`, `timeout. started/ended`.
Moteur politique : règles de refroidissement, pauses obligatoires, couvre-feux, escalade.
Gateway Guards : prédicats avant mise/dépôt (bloc à zéro heure).
UI/Notifications : centre d'autocontrôle, pop-ups, local.
Audit/WORM : journaux de modifications/verrous/interruptions immuables.

Fail-safe : en cas d'indisponibilité de Time Limits Service, appliquez un comportement « strict » - interdiction de paris/dépôts ou dernier solde fixé (configurer une politique).

9) Vie privée et données

Minimisation : stockez les minutes/états plutôt que la télémétrie comportementale détaillée.
DPIA pour le profilage basé sur le temps.
Transparence : dans la politique de RG, décrire le calcul, TZ, règles AFK, couvre-feu.
Retraite : unités de temps - 12-24 mois, journaux de blocage - selon les exigences de licence.

10) Métriques d'efficacité et SLO

Taux d'adaptation des limites de temps (objectif ≥30 -50 %).
Break Take Rate (proportion de pauses volontaires après le test de réalité).
Time-to-Enforce (avant le verrouillage à zéro heure) : <1-2 secondes.
Overtime Prevention : proportion de paris évités après épuisement du temps (près de 100 %).
Réduction Harm-Signal : réduction de 30 jours des longues séances nocturnes/« chasing ».
Taux complet par intrusion des notifications (garder bas).
System Availability (Time Limits): ≥99. 9 % avec des alertes de dégradation.

11) RACI (rôles)

12) Chèques-feuilles (opérations)

Avant le démarrage

• Les seuils de session/jour/semaine et les couvre-feux ont été définis.
• Une pause obligatoire et un refroidissement à la hausse ont été mis en œuvre.
• heartbeat et déduplication des sessions (multi-périphériques) sont configurés.
• Local, disponibilité, textes sans promo.
• L'audit WORM et les dashboards SLO/métriques sont inclus.
• Mené par la DPIA, mise à jour de la politique de RG.

En service

• Étalonnage hebdomadaire des seuils et fréquences de notification.
• Surveillance des faux blocs/faux allows et des plaintes d'intrusion.
• Valider les campagnes de suppression pour les joueurs ayant un solde de temps nul.

Incidents

• Plan de dégradation (read-only/dernier solde).
• Communications aux joueurs en cas d'échec, ajustements de temps par journal.

13) Exemples de scénarios

A. Limite de session de 90 min, pause obligatoire de 10 min

Le joueur a atteint 90 min → la fenêtre est bloquée, le minuteur 10 min, les boutons « Aide/Retrait ». Après la pause, le restart de la session.

B. Limite journalière de 120 min

Le joueur a joué 100 min le matin et 20 min le soir → bloc jusqu'à 00:00 TZ local. L'IU montre « disponible demain ».

C. Couvre-feu 02 : 00-06 : 00 (volontaire)

Si vous essayez de vous connecter : "La fenêtre de jeu est fermée jusqu'à 06:00. Vous pouvez configurer les exceptions, mais nous vous recommandons de déplacer le jeu pendant la journée"

14) Erreurs fréquentes et comment les éviter

Fenêtres intrusives toutes les 5-10 min → entrez le cap de fréquence et les seuils significatifs.
Il n'y a pas de refroidissement à l'augmentation → le risque réglementaire et le dommage aux joueurs.
Compte AFK comme « temps de jeu » → utilisez heartbeat et auto-pause.
La promo dans les fenêtres de pause est → interdite ; uniquement les options RG.
Ne comptez pas TZ/DST → gardez le calcul en UTC, UI en local.
L'absence de journaux ne → pas prouver la conformité.

15) Feuille de route pour la mise en œuvre (6 étapes)

1. La politique et la DPIA : définir les types de limites, les seuils, les couvre-feux, le refroidissement.
2. Architecture : Time Limits Service, heartbeat, guards, audit WORM.
3. Intégrations : liens vers Reality Checks, limites de dépôt/perte, auto-exclusion, CRM-suppression.
4. UX/contenu : centre d'autocontrôle, textes, localisation, disponibilité.
5. Observabilité : métriques d'efficacité et SLO, alertes, rapports RG.
6. Amélioration : A/B timing/formulation, calibrage des seuils, analyse des plaintes.

Total

Les limites de temps de jeu ne sont pas seulement un minuteur, mais un circuit d'auto-contrôle de bout en bout : seuils honnêtes, pauses obligatoires, technique correcte de suivi du temps, UX transparent sans promo, communication avec d'autres outils RG et observabilité stricte. Cette approche protège les acteurs, renforce la conformité et la réputation et améliore la durabilité du produit.