La salle depuis laquelle votre équipe exploite le casino.
Pas un panneau d’administration greffé sur une API. L’espace de travail où l’exploitation se passe réellement.
Callisto Operator OS est le backoffice livré avec la plateforme : les joueurs et leur argent, les marques et leurs réglages, les paiements en attente de revue, les jeux et les bonus, le marketing, les rapports, les tickets de support et l’administration de la plateforme — un espace de travail, un jeu de permissions, une piste d’audit.
Des écrans, pas une liste de fonctionnalités.
Les images ci-dessous montrent le produit tel qu’il est livré. Rien n’a été dessiné pour un site web.
Tableau de bord d’exploitation
Les chiffres sur lesquels un opérateur ouvre sa journée — dépôts, retraits, GGR, inscriptions et les alertes qui attendent quelqu’un — limités à la marque et à la période choisies, et retenus pour la visite suivante.
Gestion des joueurs
Un joueur, tout ce qui le concerne : soldes de ses wallets, historique des transactions et des jeux, statut KYC et documents, limites de jeu responsable, bonus, notes et le journal de toutes les interventions du personnel sur le compte.
Paiements et prestataires
Dépôts et retraits sous forme de file d’attente plutôt que de rapport : ce qui attend une approbation, ce qui est retenu et pourquoi, quel prestataire l’a traité, et les écritures manuelles quand une correction s’impose — chacune signée par la personne qui l’a faite.
Site Builder
La vitrine de chaque marque — mises en page, identité visuelle, pages publiées, contenus légaux et configuration analytique — éditée avec un aperçu en direct et publiée par skin, sans déploiement.
Support
Deux niveaux au même endroit : les joueurs écrivent à leur marque, les opérateurs écrivent à la plateforme. Tickets en fil, pièces jointes, notes internes que le joueur ne voit jamais, et un numéro de ticket qui survit à la conversation.
Tous les domaines de la plateforme, au même endroit.
Le backoffice n’est pas un sous-ensemble de la plateforme dont les parties intéressantes se vendraient à part. Si un service existe, ses écrans sont ici.
Joueurs et marques
- Recherche joueurs, fiches et soldes
- Revue KYC et files documentaires
- Limites de jeu responsable et interventions
- Clients, marques et réglages par skin
- Pays, devises et langues
Argent
- Revue des dépôts et des retraits
- Prestataires de paiement par marque
- Ajustements manuels, signés
- Relevés, factures et facturation
- Commissions agents et affiliés
Produit
- Jeux, fournisseurs et configuration du lobby
- Campagnes de bonus, tours gratuits et conditions de mise
- Pools de jackpots progressifs
- Campagnes marketing, segments et parcours
- Site Builder et Content Studio
Contrôle
- Rapports et tableaux de bord avec export CSV
- Alertes de risque et dossiers de conformité
- Tickets de support, les deux niveaux
- Utilisateurs, rôles et permissions
- Journal d’audit de chaque action
Des permissions qui descendent jusqu’à un bouton.
Un backoffice de casino détient de l’argent, des données joueurs et les contrôles qu’un régulateur examine. L’accès n’est donc pas un intitulé de poste : c’est un ensemble de permissions accordées, et la trace de qui les a accordées.
Les rôles sont faits de permissions unitaires
Un rôle est un ensemble nommé de permissions plutôt qu’un palier figé : un vérificateur de paiements autorisé à approuver les retraits jusqu’à un seuil et à ne rien lire d’autre est un rôle que vous définissez, pas une demande d’évolution.
Limité aux marques sur lesquelles la personne travaille
L’accès est borné par client et par skin. Qui s’occupe d’une marque ne voit ni les joueurs, ni les paiements, ni les rapports d’une autre ; un utilisateur au niveau plateforme voit au-delà parce qu’une permission le dit, non par accident.
Chaque action est consignée
Qui a approuvé le retrait, qui a changé la limite, qui a rouvert le dossier — avec un horodatage, dans un journal inaltérable. Un statut qui bouge sans personne pour l’assumer est précisément ce que la piste d’audit existe pour empêcher.
La politique de session et de mot de passe est la vôtre
Règles de mot de passe, double authentification, durée de session et délai d’inactivité sont des paramètres de plateforme plutôt que des hypothèses figées dans le code, parce que la bonne réponse varie selon le marché et l’opérateur.
Configurez une fois. Surchargez là où il faut.
Les réglages descendent de la plateforme vers chaque client puis vers ses skins : la plateforme porte les valeurs de base, le client les adapte, et un skin hérite de tout ce qu’il n’a pas besoin de changer. Le niveau défini le plus étroit l’emporte — c’est ce qui fait d’une deuxième marque un travail de configuration plutôt qu’un second déploiement, et ce qui empêche un marché strict d’hériter des réglages plus souples d’un autre.
Questions sur le backoffice.
Ce que demandent les équipes d’exploitation quand ce sont elles qui y passeront leurs journées.
Inclus. Callisto Operator OS est livré avec la plateforme, en code source, et c’est le même espace de travail que nous utilisons — pas une version de démonstration allégée. Il n’y a pas de licence par poste dans l’architecture, ni de module retenu comme option payante.
Oui, et c’est tout l’intérêt de recevoir le code. Le backoffice est une application React qui parle à la plateforme via un BFF documenté ; vos ingénieurs peuvent modifier un écran, ajouter une colonne ou construire un écran dont seule votre exploitation a besoin. Rien ici n’est compilé derrière une vérification de licence.
C’est le cas normal, pas l’exception. Utilisateurs, rôles et données sont bornés par client et par skin : un groupe peut exploiter plusieurs marques depuis un espace unique tandis que le personnel de chaque marque ne voit que la sienne. Les réglages descendent plateforme → client → skin, donc une nouvelle marque part de valeurs saines et ne surcharge que ce qui diffère.
Les changements d’état avec la personne qui les a faits : approbations et refus de paiement, ajustements manuels, modifications de limites et de politiques, décisions KYC, décisions sur les dossiers et réouvertures, changements de rôles et de permissions. Le journal est inaltérable et, là où cela compte le plus, écrit dans la même transaction que le changement qu’il décrit — un statut ne peut donc pas bouger sans que la trace bouge avec lui.
C’est conçu pour un bureau. Les écrans sont denses volontairement : une file de paiements et une fiche joueur sont des tableaux, et réduire un tableau à un téléphone le rend moins lisible plutôt que plus portable. C’est utilisable sur tablette ; l’exploitation pour laquelle c’est conçu se fait devant un écran.
Plus longtemps qu’une démo ne le laisse croire et moins qu’une plateforme de cette taille ne le suggère, parce que les écrans sont cohérents : mêmes filtres, même comportement de tableau, même forme de page de détail d’un domaine à l’autre. La façon honnête d’en juger est une démonstration sur vos propres données, et nous préférons la faire plutôt qu’écrire un chiffre ici.
Regardez-le avec les gens qui l’utiliseront.
Amenez votre responsable d’exploitation, votre vérificateur de paiements et la personne qui répond à votre régulateur. Une démonstration sur de vrais écrans tranche en une heure ce qu’une liste de fonctionnalités discute pendant une semaine.
Nous répondons sous un jour, le plus souvent le jour même.