En bref
« Le jeu s’ouvre en préproduction » prouve qu’un chemin nominal a fonctionné une fois dans un environnement de test. Avant la production, l’équipe doit aussi prouver que le candidat et le périmètre sont figés, que les parcours fonctionnels et d’exception ont été testés, que les enregistrements financiers et opérationnels sont rapprochés, que la configuration de production et les limites d’accès sont contrôlées, que la responsabilité en cas d’incident est exécutable, et que le retour arrière ou l’arrêt peut être effectué de façon sûre.
L’acceptation doit produire des preuves et une décision — pas simplement la mention « testé ». Pour chaque élément, enregistrez l’environnement, la version candidate, le cas de test, le résultat réel, l’emplacement des preuves, le responsable et le niveau de blocage. Un élément sans preuve reste non vérifié ; une confirmation verbale en réunion ne le transforme pas en réussite.
Sept domaines de preuve avant la production
| Domaine | Preuve minimale de réussite | Ce qui doit bloquer la production |
|---|---|---|
| 1. Périmètre et candidat | API convenues, modèle de portefeuille, périmètre des jeux, version candidate, liste de configuration et exclusions | Le candidat change encore, ou le périmètre testé diffère du périmètre de la mise en production |
| 2. Parcours fonctionnels | Résultats examinables pour les cas convenus de lancement, retour, portefeuille et consultation d’enregistrements | Un parcours métier critique échoue, ou seul l’affichage front-end a été vérifié |
| 3. Parcours d’exception | Conclusions pour les cas de délai d’attente, doublon, déconnexion, échec métier, succès partiel et état inconnu | L’état final ne peut pas être établi, et la récupération dépend de nouvelles tentatives aveugles |
| 4. Rapprochement et cohérence | Des identifiants stables corrèlent demandes, transactions, manches, montants, devises et mouvements de solde | Les enregistrements ne peuvent pas être liés, ou les écarts n’ont ni voie de consultation, ni traitement, ni clôture |
| 5. Sécurité et isolation des environnements | Les identifiants d’accès, accès, données, journaux et limites de configuration entre préproduction et production sont vérifiés | Des identifiants d’accès de test sont réutilisés, des secrets entrent dans le code ou les journaux, ou les autorisations de production sont floues |
| 6. Responsabilité et préparation opérationnelle | Le décideur de lancement, la réponse d’ingénierie, les responsables du rapprochement, de la sécurité et de l’escalade sont confirmés | Seul un contact commercial existe, ou les incidents et écarts financiers n’ont pas de responsable |
| 7. Retour arrière, arrêt et récupération | Les déclencheurs, l’exécutant, le traitement des données, la validation de récupération et les voies de communication sont confirmés | L’intégration ne peut pas être arrêtée de façon sûre, ou personne ne rapproche l’état après un retour arrière |
Étape 0 : figer le périmètre et le format de preuve
Avant les tests, établissez ce socle :
- la version candidate, la version de la documentation API et la version de configuration ;
- les fournisseurs, jeux, modèle de portefeuille, devises, langues et marchés destinés au lancement ;
- les exclusions explicites de cette mise en production ;
- les différences entre préproduction et production ;
- les préconditions, entrées, résultats métier attendus, résultats réels et emplacement des preuves pour chaque cas ;
- la gravité des défauts, l’approbateur des exceptions et le responsable de la décision finale go/no-go.
Si la version candidate de mise en production n’est pas celle qui a été testée, réévaluez les domaines d’acceptation concernés. Ne reportez pas les conclusions sans examen d’impact.
1. Acceptation fonctionnelle
Couvrez l’ensemble de la chaîne métier convenue plutôt qu’un seul écran de jeu :
- le catalogue ou le jeu cible est identifié par l’ID stable convenu ;
- la création de session, l’entrée, le retour et l’expiration se comportent comme convenu ;
- le modèle de portefeuille sélectionné achève son parcours nominal attendu ;
- les résultats métier sont évalués selon le protocole d’interface, et non déduits du seul statut HTTP ;
- les enregistrements de transaction, de manche et associés peuvent être consultés et reliés aux actions de test ;
- les autorisations, devises, langues et appareils ne sont testés que pour les combinaisons du socle figé.
Écrivez les conditions de réussite sous forme de résultats observables — par exemple, « la transaction de test est renvoyée par l’ID métier spécifié et correspond au mouvement de grand livre » — plutôt que « le portefeuille fonctionne ».
2. Acceptation des exceptions
Choisissez les cas d’exception en fonction du risque du projet et du protocole réel. Ils comprennent couramment :
- un délai d’attente de demande, une réponse perdue ou une connexion interrompue ;
- une soumission en double ou un rappel en double ;
- une erreur de paramètre, d’autorisation, de signature ou de validation métier ;
- un succès partiel en aval, lorsque l’appelant ne dispose pas d’un état complet ;
- une consultation, compensation, un rapprochement ou une escalade manuelle après la récupération du service ;
- l’arrêt de l’action automatisée après la limite convenue de nouvelles tentatives tout en conservant les preuves.
Cette liste de contrôle exige un résultat testé pour les parcours d’exception. Elle n’invente pas de clé d’idempotence, de nombre de nouvelles tentatives ou de valeur de backoff pour un projet. Consultez Idempotence, nouvelles tentatives et rapprochement de l’API Slots pour le cadre de conception, et utilisez le protocole formel des parties pour les détails d’implémentation.
3. Acceptation des enregistrements et du rapprochement
Utilisez au moins une transaction normale et un scénario d’exception ou d’état inconnu. Vérifiez si :
- les identifiants de demande, de transaction métier, de manche et de pari peuvent être corrélés ;
- le montant, la devise, le sens, l’état final et l’interprétation du temps concordent ;
- le solde du portefeuille ou le mouvement de grand livre correspond à l’enregistrement de transaction ;
- les événements en double sont reconnus au lieu de créer deux résultats impossibles à distinguer ;
- chaque écart possède un responsable, un enregistrement de traitement, une condition de clôture et une preuve d’audit ;
- le périmètre de consultation ou d’export prend en charge l’examen opérationnel et financier convenu.
Un échantillon réussi ne prouve que les cas et le périmètre couverts. Il ne signifie pas que de futurs écarts sont impossibles.
4. Sécurité, configuration et isolation des environnements
La production n’est pas une configuration de préproduction copiée sur un hôte différent. Avant la mise en production, vérifiez au minimum que :
- les tests et la production utilisent des identifiants d’accès, autorisations et configurations distincts et contrôlés ;
- les secrets n’entrent pas dans le code source, les captures d’écran, le corps des tickets ou les journaux ordinaires de l’application ;
- l’accès à la production suit le principe du moindre privilège et possède des enregistrements d’approbation, de changement et de révocation ;
- les journaux conservent assez de contexte pour le traçage sans enregistrer les secrets de signature, les identifiants d’accès complets ou des données sensibles inutiles ;
- les données de test ne peuvent pas être confondues avec des transactions de production, et les données de production n’entrent pas en test sans approbation ;
- les différences de configuration ont été examinées, et les domaines de production, règles réseau et cibles de supervision ont passé des vérifications réelles du projet ;
- les dépendances, horloges, certificats et paramètres liés à la signature ont des responsables nommés.
Les normes techniques de la UK Gambling Commission comprennent la séparation des systèmes de développement, de test et de production dans leur périmètre de sécurité applicable. C’est une référence utile pour l’isolation des environnements, mais chaque marché et chaque projet requiert toujours son propre examen. Cela n’établit pas une conformité réglementaire ou de sécurité complète.
5. Responsabilité et préparation opérationnelle
Transformez une liste de contacts en une matrice de responsabilité exécutable :
| Scénario | Responsabilité à établir avant le lancement |
|---|---|
| Incident d’API ou de session | Premier intervenant, exigence de preuve, escalade d’ingénierie et communication externe |
| Écart financier ou d’enregistrement | Condition de pause, responsable du rapprochement, décideur métier et norme de clôture |
| Changement de catalogue ou de version | Initiateur du changement, évaluation d’impact, notification et tests de régression |
| Incident d’identifiant d’accès ou de sécurité | Isolation, rotation, enquête, notification et approbation de récupération |
| Mise en production et retour arrière | Go/no-go, exécution, validation et responsabilité de l’enregistrement final |
Si les objectifs de réponse, la disponibilité du service ou les recours sont des conditions de lancement, inscrivez-les dans le contrat ou dans un autre document opérationnel formellement convenu.
6. Retour arrière, arrêt et récupération
Toute intégration API ne peut pas être annulée par un retour arrière du code. Lorsque des portefeuilles et transactions sont impliqués, le plan doit aussi couvrir les événements métier créés durant la fenêtre de mise en production ou de retour arrière. Confirmez :
- les conditions explicites qui déclenchent l’arrêt ou le retour arrière ;
- quels points d’entrée peuvent être fermés et quels événements en cours doivent encore être traités ;
- qui exécute, approuve et vérifie le retour arrière ;
- comment le service, les enregistrements et l’état financier sont vérifiés après la récupération de configuration ou de version ;
- si les données de production doivent être conservées, compensées ou rapprochées manuellement ;
- un parcours contrôlé de dégradation, de pause et de communication lorsque le retour arrière rapide n’est pas possible.
Exercez le plan dans un environnement sûr ou réalisez une simulation sur table, et conservez le résultat. Cet article ne suppose pas qu’AG fournit un outil de retour arrière particulier.
L’enregistrement final de go/no-go
Avant la production, saisissez un enregistrement de décision concis :
- la version candidate et la configuration ;
- l’état des sept domaines de preuve : vérifié, accepté sous conditions ou bloqué ;
- les défauts et exceptions non résolus, avec le risque, le responsable et l’approbateur ;
- les responsabilités de supervision, d’escalade, d’arrêt et de récupération ;
- l’approbation distincte de l’accès à la production et du périmètre commercial ;
- la décision : go, go à périmètre limité ou no-go ;
- la date de décision et les rôles signataires, sans présumer d’une date de lancement fixe.
Ce qui peut actuellement être évalué sur ce site
- Le processus d’intégration distingue la découverte, le périmètre technique, l’acceptation des tests et la coordination de préproduction.
- La référence API publique présente des codes de résultat métier, des identifiants de demande ou de transaction, deux directions de portefeuille et des consultations d’enregistrements qui peuvent éclairer la conception des tests.
- L’ouverture d’un jeu ne couvre qu’un parcours visible ; elle ne prouve pas que le portefeuille, les exceptions, les enregistrements ou les autorisations ont passé une acceptation de bout en bout.
- Le comportement réel à l’exécution et l’admission en production doivent être fondés sur les preuves de test de l’environnement convenu et une décision signée des deux parties.
Limites à garder à l’esprit
- Cette page n’affirme pas qu’AG a fourni des identifiants d’accès de préproduction ou de production à un projet particulier.
- Elle ne fixe pas de période de test, date de mise en production, configuration de nouvelles tentatives, niveau de performance, capacité ou SLA.
- La réussite en préproduction ne garantit pas un comportement identique en production.
- Elle n’établit pas qu’un jeu, une version ou un modèle de portefeuille convient à chaque plateforme ou marché.
- Elle ne prétend pas à une sécurité absolue et ne remplace pas l’approbation du contrat, de la conformité, de la sécurité et du changement en production.
FAQ
Si la préproduction réussit, l’équipe peut-elle mettre en production immédiatement ?
Pas automatiquement. L’identité du candidat, les différences d’environnement, l’accès à la production, la responsabilité, la supervision, le périmètre commercial et les conditions de retour arrière doivent encore être examinés, puis suivis de la décision go/no-go convenue.
Les tests de parcours nominal suffisent-ils ?
Non. Les délais d’attente, doublons, déconnexions, échecs métier et états inconnus sont des sources fréquentes de traitement répété et d’écarts financiers. Les cas d’exception doivent entrer dans l’acceptation selon le protocole et le risque.
Qui signe la décision de production ?
La matrice de responsabilité du projet en décide. L’ingénierie, la QA, les opérations ou la finance, la sécurité et le rôle disposant de l’autorité de décision de production valident normalement leurs propres domaines. Une confirmation commerciale ne remplace pas une approbation technique ou de production.
Chaque projet doit-il utiliser exactement les mêmes cas de test ?
Les sept domaines de preuve forment un squelette commun. Les cas précis doivent être adaptés au modèle de portefeuille, au périmètre, au marché cible, à la plateforme actuelle et au risque de changement. La décision d’adaptation doit elle-même être enregistrée et approuvée.
Lectures associées et prochaines étapes
- Pages principales : processus d’intégration, API Slots et référence API publique
- Guides existants : liste de contrôle d’intégration de l’API Slots et portefeuille unique ou portefeuille de transfert
- Poursuivez avec comment évaluer un fournisseur d’API Slots et idempotence, nouvelles tentatives et rapprochement
Pour définir un périmètre d’acceptation de projet, utilisez la section « Contactez-nous » afin de fournir le modèle de portefeuille, les jeux cibles, la limite de la plateforme actuelle et les environnements attendus. AG peut alors collaborer sur les cas et les preuves selon le protocole confirmé, sans promettre à l’avance une date de lancement ou une admission en production.
Sources et périmètre
Pour le périmètre du produit, consultez le processus d’intégration, la présentation de l’API Slots et la référence API publique.
Les méthodes générales de mise en production s’inspirent de l’ingénierie des mises en production et des pratiques évolutives d’engagement SRE de Google SRE. L’exemple d’isolation des environnements spécifique au marché provient des normes techniques pour les jeux à distance et les logiciels de la UK Gambling Commission : exigences de sécurité.
Ces sources expliquent des pratiques générales d’acceptation. Elles n’établissent pas qu’AG met en œuvre chaque processus référencé ni qu’un projet est conforme à un marché particulier. Les conditions de production doivent être convenues par les rôles responsables de l’ingénierie, de la QA, des opérations ou de la finance, de la sécurité, du commercial et de la conformité.
Transformer ce guide en plan de projet ?
Ce contenu aide à préparer une évaluation. Il ne remplace pas la confirmation technique, contractuelle, de certification ou de droit local applicable au projet.