Mode AUTO : la résolution sans humain
Pour les événements sportifs majeurs, on utilise des API externes fiables : API Sports, football-data.org, ESPN API, et d'autres sources de confiance selon la discipline.
Quand un match se termine, l'API nous renvoie le résultat. Notre système calcule un score de confiance sur ce résultat (en croisant plusieurs sources si possible). Si la confiance est ≥ 95%, la résolution est automatique. Pas d'intervention humaine.
Exemples :
- Real Madrid vs Barcelone : API Sports renvoie « Real Madrid 2-1 Barcelone ». Score de confiance 99% (source officielle La Liga). Résolution automatique.
- Lakers vs Celtics : ESPN API renvoie « Lakers 112-108 Celtics ». Score 98%. Résolution automatique.
Délai typique : moins d'une minute après la fin du match. Le délai est principalement le temps que l'API rafraîchisse ses données.
Mode SEMI-AUTO : suggestion + validation admin
Pour les events où la confiance automatique est insuffisante (entre 70% et 95%), ou pour les sujets non sportifs (politique, crypto, culture), on utilise le mode semi-auto.
L'algorithme propose une résolution basée sur les meilleures sources disponibles. Un admin Ktkarena valide avant publication. Le processus :
- L'événement passe en statut FETCHING dès la fin de la deadline.
- L'algorithme cherche le résultat sur les sources configurées.
- Le statut passe à SUGGESTED avec une suggestion à l'admin.
- L'admin vérifie en quelques minutes (ou quelques heures pour les cas complexes).
- Le statut passe à MANUALLY_RESOLVED (avec validation admin) ou AUTO_RESOLVED si l'admin accepte tel quel.
Délai typique : 5 minutes à 4 heures selon la complexité.
Exemples :
- Élection présidentielle française : sources multiples (Le Monde, AFP, Conseil Constitutionnel). L'admin valide après confirmation finale.
- Cours du Bitcoin à un moment T : sources CoinGecko + Binance. L'admin vérifie le timestamp exact.
Mode MANUEL : saisie admin avec preuves
Pour les events sans source externe vérifiable automatiquement, c'est l'admin qui saisit le résultat à la main, avec preuves jointes archivées.
Ces preuves peuvent être :
- Capture d'écran officielle du résultat.
- Lien vers le communiqué officiel.
- Photo du document de référence.
- Article de presse de source fiable.
Les preuves sont archivées définitivement dans la base de données. En cas de litige, elles sont consultables. Types de litiges valides.
Délai typique : 24h à 7 jours selon la complexité.
Exemples :
- Concours Miss Cameroun : pas d'API. L'admin attend la communication officielle du concours et saisit le résultat avec photo officielle.
- Match amateur local : l'admin se base sur les comptes Facebook officiels du club ou un communiqué.
Cycle de vie d'un event : de DRAFT à RESOLVED
Avant même la résolution, chaque event suit un cycle de vie complet :
Cycle de vie d'un event : DRAFT (création par l'admin) → OPEN (paris ouverts) → POOL_PHASE (verrou temporaire, calcul du pool mutualisé pour les résidus non matchés) → CLOSED (paris fermés, attente résolution) → RESOLVED (résultat publié, gains distribués).
Cette phase atomique calcule en fin d'event qui rentre dans le pool mutualisé et qui est remboursé selon ses préférences. Tu reçois une notification dès qu'elle se termine.
La machine à états : PENDING → RESOLVED
Chaque événement passe par cette séquence d'états :
PENDING (avant deadline)
↓
FETCHING (récupération du résultat)
↓
SUGGESTED (résultat proposé)
↓
↓ → AUTO_RESOLVED (confidence ≥ 95%, auto-publié)
↓ → MANUALLY_RESOLVED (admin a validé)
↓ → DISPUTED (contestation en cours)
↓ → CANCELLED (event annulé pour cause externe)Tu peux suivre l'état de tes paris en temps réel dans l'app. Statut affiché de manière transparente avec timestamp à chaque transition.