Plan de continuité d'activité

1) Objectif, domaine et principes

Objectif : assurer la continuité des services essentiels (dépôts, paris/jeux, conclusions, KYC/AML, sapport) en cas de défaillance et une récupération rapide sans violation des licences et des contrats.
Domaine : plateforme en ligne, circuit de paiement, antifrod/CUS, DWH/BI, sappport, fonctions opérationnelles et juridiques, principaux fournisseurs (PSP/KYC/cloud/CDN/studios/agrégateurs).
Principes : safety first, joueur avant tout, correctivité réglementaire, minimisation du RTO/RPO, modes de dégradation simples, probabilité et exercices réguliers.

2) BIA - analyse d'impact sur les entreprises

Identifiez les processus critiques, les entrées/sorties, les dépendances, les alternatives « manuelles » et les cibles RTO/RPO.

yaml process: payouts owner: head_of_payments criticality: tier1 dependencies: [psp1, psp2, bank_api, kyc_service, ledger_db]
rto: "4h"
rpo: "15m"
manual_workaround: "limited manual VIP payments when the PSP is completely unavailable"
max_tolerable_downtime: "8h"
legal_constraints: ["AML/KYC check before payout," "regulatory notification windows"]

3) Scénarios/menaces (Risk → Impact → Response)

Ceux-ci : chute de la région du nuage, panne OBD, perte de cluster, attaques DDoS, panne CDN.
Vendeurs : dégradation du PSP/KYC, rupture avec l'agrégateur de jeux, indisponibilité du dépistage antifrod/sanctions.
Cyber : compromission des comptes/clés, ransomware, fuite PII.
Processus/personnes : grèves/maladies, soins des professionnels clés, erreur de libération.
Géo/force majeure : coupures de communication/énergie, risques militaires/sanctions, blocages de domaines/trafic.

Pour chacun : déclencheurs, seuil d'escalade, mesures de contrôle, dégradation du service et modèles de communication.

4) Architecture et stratégies de durabilité

Active-active/active-standby par région ; infrastructure en code pour une montée rapide.
Modes de dégradation : read-only vitrines, désactivation des fournisseurs de jeux non critiques, limites de paiement, « uniquement des dépôts » avec des cassaouts retardés (si légalement autorisés), baisse de la fréquence d'analyse/ETL.
Gestion du trafic : Anycast CDN, géo-équilibrage, checks de santé, routage canarien.
Données : backaps PITR, journaux de changement, réplication interrégionale, intégrité cryptographique (hashi/WORM).
Clés/secrets : KMS indépendant par région, « break-glass » avec journal.
PSP/KYC multi-homing : faussaire automatique, routage par SLA/latence.

5) Structure de commande (Insident Command System)

Incident Commander (IC) est un point de décision unique.
Ops Lead (SRE/Platform) est une technique de stabilisation, de faussaire, de métrique.
Business Continuity Lead - Coordination des processus/procédures manuelles.
Comms Lead - notifications externes/internes (joueurs, partenaires, régulateurs).
Sécurité/DPO - cyberincidents/vie privée, fenêtres réglementaires.
Payments/KYC Leaders - scripts PSP/KYC.
Liaisons: Legal, Support, VIP/CRM, Data/BI.

Règle : un IC par incident, des canaux clairs et des logs de décision.

6) Plan de communication

Canaux : war-room (chat/pont), communications de secours (téléphone/radio/alt-messager), contacts PSP/KYC/banques préalablement vérifiés.
Modèles de messages externes : page de statut, réseaux sociaux, email/push ; le ton est les faits, le calendrier, les prochaines étapes.
Régulateurs et partenaires : adresses prédéfinies, notifications SLA ; formulation convenue.
Joueurs : ETA transparent, compensations/bonus (le cas échéant), FAQ pour la période de dégradation.

7) Plans d'exploitation (Runbooks)

7. 1 Feilover dans une autre région

yaml trigger: "loss of primary availability> = 5m, p95_latency>threshold"
steps:
- IC approves region_failover
- SRE: flip traffic via GSLB to secondary
- Data: verify replication lag < RPO
- Apps: switch env vars/secrets; warm caches
- QA: smoke tests; Business: announce status rollback: "switch-back on 60m stability"

7. 2 dégradations PSP

yaml trigger: "auth_rate_psp1 < baseline-3σ 15m"
steps:
- Payments: route X%→psp2, include limits
- Comms: banner at the checkout, status page
- Finance: reconciliation plan for T + 0
- Legal: notification log and SLA letter

7. 3 KYC fournisseur non disponible

yaml trigger: "kyc_sla_breach 30m"
steps:
- Risk: time limits of deposits/rates
- Ops: VIP/High-risk manual check
- Comms: KYC Time Increase Notice
- Vendor: escalation, protection switch

8) Récupération de l'informatique et des données (DR)

Catégories de systèmes : Tier-1 (plate-forme/paiement/CUS), Tier-2 (jeux/analyse), Tier-3 (interne).
Ordre de levage : set→sekrety/KMS→BD→kesh→API→front/CDN→integratsii→analitika.
Contrôles d'intégrité : montants de contrôle, vérification des journaux/réplication, rapprochement des transactions (reconciliation).
Tests DR : annuel complet (switch-over), trimestriel partiel ; fixation des RTO/RPO réels.

9) Personnes, bureaux et logistique

Remote-ready : PC portables/modems redondants, accès via SSO/MFA, accès « rouge » pour IC.
Lieux alternatifs : bureaux de secours/espaces de coworking, listes de laissez-passer, plan d'évacuation.
Rotation des postes : matrice des compétences, duplication des rôles clés, plan de remplacement.
Fournisseurs critiques de communications/énergie : contacts, SLA, générateurs/UPS (si pertinent).

10) Vendeurs et chaîne d'approvisionnement

Exigences BCP/DR dans les contrats : RTO/RPO, tests obligatoires, droit d'audit et exercices conjoints.
Registre des sous-processeurs : contacts, plans de sortie, confirmation de la suppression/exportation des données lors de l'offboarding.
Revues trimestrielles Tier-1 : incidents, protocoles de RD, statut des certificats, SLA.

11) Formation, exercices et tests

Tabletop une fois par trimestre : PSP/KYC/cloud/cyber scripts.
Exercices : DR partiels/complets ; DDoS/commutation CDN ; « kill-switch » SDK des fournisseurs.
Exercice de communication : Communiqué de presse/Mises à jour du statut/Lettres réglementaires.
Rétrospectives : temps, RCA, CAPA, mise à jour des runbooks et BIA.

12) Métriques (KPI/KRI)

RTO/RPO fait (selon Tier-1) : correspond à des objectifs ≥ 95 %.
MTTD/MTTR : tendance à la baisse ; Le MTTR des incidents critiques ≤ ciblé.
Succès du faussaire : aucune perte de données/commandes/paris, ≤ X min de dégradation.
Coverage par exercice : ≥ 2 tests DR complets/an + 4 tabletop.
Communications : temps jusqu'à la première mise à jour ≤ 15 min, taux de mise à jour selon la politique.
Résidence Vendor : proportion de Tier-1 avec des tests DR confirmés pour 12 mois - 100 %.

13) RACI (agrandi)

14) Chèques-feuilles

14. 1 Ready-to-Failover

• Contacts actuels IC/fournisseurs/régulateurs
• Santé de réplication, backup PITR régulier
• Vérifié « kill-switch » pour SDK/webhooks
• Gestionnaire de trafic (GSLB/CDN) avec checks de santé vérifiés
• Modèles de statut/lettres et droits de publication
• Runbooks et accès (SSO/MFA) vérifiés mensuellement

14. 2 Au moment de l'incident

• Désigné IC, ouvert war-room, début des logs de solutions
• Classification (P1/P2), choix du scénario et dégradation
• Technicité (faussaire/limites/coupures)
• Première mise à jour publique ≤ 15 minutes
• Avis de réglementation/partenariat sur les SLA
• Saisie d'artefacts pour le post-mortem

14. 3 Après l'incident

• Post mortem avec RCA et CAPA
• Mis à jour par BIA/seuils/procédures de routine
• Formation/Retest des fictions, Rapport aux bordous
• Vérification financière/ce rapprochement (reconnaissance)

15) Modèles (fragments)

15. 1 Carte de scénario

yaml scenario: "Region outage: cloud-eu1"
triggers: ["error_rate>5%", "loss of quorum", "cdn health fail"]
degradation: ["disable live-casino", "payments=psp2 only", "payouts=VIP manual"]
rto_target: "30m"
rpo_target: "15m"
contacts: {cloud: "...", isp: "...", regulator: "..."}
comms_templates: ["status_page_v1", "partner_notice_v2"]

15. 2 Message à la page d'état

[UTC + 02] We are seeing the degradation of payments through PSP # 1. Transactions are automatically routed through an alternative provider. Player funds are safe. The next update is in 15 minutes.

16) Gestion des documents et des versions

Versioning BCP/Runbooks dans le référentiel, change-log, propriétaire du document.
Calendrier de révision (trimestriel pour Tier-1), contrôle de la disponibilité des copies hors ligne.
Stockage d'artefacts d'exercices/incidents et de mesures d'efficacité.

17) Feuille de route pour la mise en œuvre (6-8 semaines)

Semaines 1 à 2 : EIA et processus critiques, objectifs de RTO/RPO, liste des scénarios et des propriétaires.
Semaines 3-4 : architecture de la durabilité et des modes de dégradation, runbooks, modèles de communication, contacts.
Semaines 5 à 6 : intégration avec les fournisseurs (PSP/KYC/nuage), exercices pilotes (tabletop + DR partiel), ajustements.
Semaines 7 à 8 : test complet de RD (si possible), lancement du cycle d'exercice trimestriel, rapport de bord et trousse de réglementation (si nécessaire).

18) Sections wiki connexes

Registre des risques, Incidents et fuites, tests DR/BCP, TPRM et SLA, ISO 27001/27701, SOC 2, PCI DSS, IGA/RBAC/Least Privilège, Politique de logs/WORM - pour une boucle unique de stabilité et de probabilité.

TL; DR

Efficace BCP = BIA→RTO/RPO→stsenarii et degradatsii→multi - fournisseur/multi-région + Commission de l'incident clair, communications et exercices. Gardez le document en vie, testez régulièrement - et même un gros échec n'arrêtera pas l'entreprise et ne frappera pas les licences.