Protocoles d'interaction communs

1) Pourquoi l'écosystème a-t-il des protocoles uniques

L'écosystème se compose d'opérateurs, de studios/RGS, d'agrégateurs, de PSP/APM, de fournisseurs KYC/AML, d'affiliés et de services d'analyse. Les protocoles d'interaction communs excluent le « zoo » des intégrations, accélèrent l'onbording, réduisent le coût du support et les risques d'incidents, et garantissent la compatibilité lors de l'échelle (horizontale, verticale et diagonale).

Objectifs : compatibilité hors boîte, SLO prédictible, sécurité des données, migrations reproductibles.

2) Couche de transport et formats

HTTP/2/3, gRPC - pour API synchrones à faible latence ; WebSocket - pour les événements/leaders en streaming ; WebRTC (SRTP/QUIC) - pour le contenu live audio/vidéo.

• JSON - API et webhooks B2B externes (lisibilité).
• Protobuf/Avro - bus intérieur/intégrations profondes (compression/évolution des circuits).
• Compression/binding : gzip/br pour JSON ; zstd pour Protobuf/Avro.
• Local/heure : ISO-8601 en UTC, les montants sont en unités monétaires minimales (integer).

3) Authentification, autorisation, confiance

OAuth2/OIDC pour les applications clients/partenaires (tokens short-lived, PKCE, scopes).
mTLS pour les S2S entre les zones de confiance ; JWS/HMAC - Signature des requêtes et des webhooks.
RBAC/ABAC : rôles et attributs (compétence, tenant, niveau de risque).
Clés et rotation : KMS/Vault, courte durée de vie, rotation automatique (y compris JWKS).
Egress Control, allow-list des domaines et ASN, DNSSEC/DoT/DoH dans les zones sensibles.
Tenant isolation : clés per-tenant, quotas, limites, namespace-s dans le pneu.

4) Contrats API (REST/gRPC) - canonique

Versioning : '/v {n} 'dans l'URI pour REST ;' package. vN'pour gRPC. L'évolution mineure est sans rupture ; breaking-change - via un nouveau major. Dépréciation par politique (voir § 12).
Idempotence : 'Idempotency-Key' sur POST/PUT/PATCH opérations monétaires/critiques ; enregistrement sur N heures.
Pagination : curseurs ('nextPageToken'), non 'offset/limit' ; tri consistance.
Limites : « 429 Too Many Requests » + titres de quotas (« X-RateLimit- »), jitter dans les retraits.
Erreurs : codes/sous-codes lisibles par machine, 'correlationId', carte des champs de validation.
Délais et retraits : retard exponentiel + jitter ; ne pas corriger les erreurs dangereuses.
Politique de compatibilité : immuabilité du sens des champs ; les nouveaux champs sont optionnels.

5) Modèle d'événement et pneumatique (EDA)

Registraire de schémas (Schema Registry) : contrat pour chaque événement, évolution avec compatibilité backward.

• `click`, `session`, `bet`/`spin`, `round_start`/`round_result`,
• `deposit`/`withdrawal`, `psp_auth`, `kyc_status`, `fraud_signal`,
• `reward_granted`, `leaderboard_update`, `feature_toggle`.
• Clés de lot : 'playerId', 'campagneId', 'tableId', 'operatorId' (sélection par domaine).
• Livraison : at-least-once avec idempotence d'affaires ; pour les totaux monétaires - saga/txn-outbox.
• Ordre : « ordre garanti à l'intérieur de la clé », clés croisées - par l'orchestration.
• Sémantique du temps : 'eventTime' + 'ingestTime' ; dedup par '(eventId' idempotencyKey) '.

6) Webhooks et garanties de livraison

Légende : JWS/HMAC avec « t » (timestamp) et « kid », la vérification de la fenêtre ± 5 minutes, contre la jouabilité est interdite.
Retrai : backoff avec jitter jusqu'à T minutes, correction des tentatives, réécriture uniquement à 5xx/timeout.
Idempotence : 'eventId' + signature du corps ; traitement « au moins une fois ».
Registre des événements de webhooks : rééchantillonnage de l'historique lors de la dissynchronisation.
Sécurité : mTLS dans la mesure du possible, allow-list IP/ASN, CSRF n'est pas applicable aux saucisses de serveur.

7) Données et vie privée (Privacy-by-Design)

Minimisation PII : Tokénisation des identifiants ('playerId'est pseudonyme), séparation des domaines de données.
Contrats de données : DPA/DPIA, objectifs, durées de conservation, flux transfrontaliers (pays Whitelist).
Politiques d'audit/de ligne : qui/quand/pourquoi ; logs immuables (WORM).
Règles de RG/éthique : interdiction des offers agressifs pour les segments vulnérables ; un cadre juridique clair.

8) Cohérence et transactions

Forte consistance - portefeuille/bilan/paiements.
Eventual - vitrines, leaders, télémétrie.
Sagas pour les transactions commerciales distribuées ; compensation pour les licenciements.
Exactly-once par sens d'affaires : clés idempotentes et manipulateurs déterministes.

9) Observabilité et SLO

Tracing : "traceId'de bout en bout, du click/webhook au paiement/récompense ; propagation (`W3C traceparent`).
Métriques : p50/p95/p99 API, lag courtier, CR paiements/CUS, leaders E2E.
Logs : structurés, sans PDn ; masquage des tokens/clés.
Feuilles SLO : login p95 ≤ 300-500 ms ; dépôt p95 ≤ 1. 5–2. 0 s ; taux/spin p95 ≤ 150-250 ms ; la livraison des événements ≥ 99. 9%.

10) Productivité, quotas, protection contre les tempêtes

Rate limiting (token/leaky bucket) sur L7 et dans les politiques mesh.
Backpressure : files d'attente avant les aptrimes fragiles (PSP/KYC).
Outlier-ejection : « refroidissement » automatique des backends instables.
Circuit-breaker : fermeture du flux lorsque les seuils d'erreur/latence sont dépassés.
Fair-share : quotas par tenant/canal/région ; priorité des domaines critiques.

11) Compatibilité SDK et critères de test

Kit SDK : clients HTTP/gRPC, signature de requête, retraits avec gitter, idempotence, curseurs.
Tests contractuels : Postman/Newman/gRPC-conformance, simulateurs PSP/KYC/studios.
Matrice de compatibilité : versions API/SDK, schémas pris en charge, politiques de dépréciation.
Synthétiques : générateurs d'événements et de transactions, « boîtes noires » 24/7 pour surveiller.

12) Versioning et déportation (Change Management)

Grandes sorties tous les N mois, avec fenêtre parallèle ≥ 6-12 mois.
Modifications mineures - Ajout de champs/méthodes optionnels sans brisure.
Dépréciation : annonce → avertissements dans les titres/réponses → drapeau dans les métriques → désactivation comme prévu.
Migration des schémas d'événements : stratégie d'extension (add-only) + cartes proxy aux frontières.

13) Sécurité des protocoles

Zero Trust : mTLS partout, creds à courte durée de vie, principes du moindre privilège.
Secret-scoop : séparation des clés de lecture/écriture/administration.
Protection contre les répétitions : nonce/fenêtre temporelle dans les signatures ; interdiction de la surexploitation.
WAF/filtres de bot : protection contre le scrapage/clic-frod ; faible fausse positive.
Zones vendeuses : microsegmentation, VPC/namespace-s séparés, egress-allow-list.

14) Incidents et DR

Procédures de salle de guerre : bouton stop pour les domaines (contenu/PSP/KYC), RACI, SLA sur le paquet de trajets.
Scénarios DR : points d'entrée actif-actif (Anycast/GSLB), cut-over ≤ 60-90 s, exercice trimestriel.
RCA : modèles sans trouver les coupables, communication des L3↔L7, updates dans le protocole/SDK/Runbook.

15) Mesures du succès des protocoles

Compatibilité : proportion de partenaires ayant passé les tests de conformité ; temps d'onbording (TTO).
Fiabilité : intégrations uptime, p95 API/bus, proportion de webhooks réussis.
Sécurité : incidents PDn = 0, temps de rotation des clés, part du trafic mTLS.
Économie : cost per rps/txn/event, réduction Cost-to-Serve, temps de migration.
Produit : FTD/ARPU/LTV uplift de normalisation (moins de fuites de CUS/paiements).

16) Anti-modèles

La « forme libre » des événements : l'absence de schémas et de versions → la séparation des vitrines et des analyses.
Une seule passerelle L7 sans N + 1 : SPOF et une gorge étroite pour les webhooks/PSP.
Retrai sans limites/jitter : trafic-tempête, prise de transactions.
PDn brut dans l'échange : pas de tokenization/DPIA → les risques réglementaires.
Pagination offset : sauts/doublons sous charge.
Secrets « pour toujours » et IP statique sans contrôle egress.
Modifications de rupture sans fenêtre parallèle et adaptateurs.

17) Chèque de mise en œuvre

1. Accepter l'API canonique (versioning, idempotence, pagination, erreurs).
2. Entrez Schema Registry et la carte de domaine des tops/clés de lot.
3. Obliger mTLS + JWS/HMAC pour les S2S et les webhooks ; automatiser la rotation des clés/JWKS.
4. Configurer les limites/retrai/CB/outlier-ejection et les quotas per-tenant.
5. Développer le tracing/métriques/logs avec un seul 'traceId' ; Approuver les feuilles SLO.
6. Signer DPA/DPIA, activer la tokenisation et les politiques de stockage/élimination.
7. Créer un SDK et un jeu de configuration ; fixer une politique de dépréciation.
8. Organiser des exercices DR/chaos et des rituels de guerre ; « black start » sur l'ensemble minimum.
9. Mettez en place un catalogue de protocoles (portail partenaire) : spec, exemples, simulateurs, bac à sable.

18) La feuille de route de l'évolution

v1 (Foundation) : canonique REST/gRPC, schémas d'événements de base, signatures de webhooks, mTLS.
v2 (Intégration) : convoyeur de migration, tests de conformité, SDK, rule-engine pour les quotas/rétroactions.
v3 (Automation) : autoproduction sur SLI, self-service sandbox/simulateurs, adaptateurs entre les versions.
v4 (Networked Governance) : comité de protocole interpartisan, SLO/credit/penalti communs, PoP/edge politiques conjointes.

Résumé succinct

Les protocoles communs d'interopérabilité sont le « langage » de l'écosystème : API et contrats d'événements uniques, sécurité stricte (mTLS/JWS), idempotence et garanties de livraison, surveillance et SLO, migrations gérées et DR.Suivant le canon, les participants s'accroissent plus rapidement, moins souvent, plus facilement et plus prévisibles - tout en respectant la vie privée et les exigences des juridictions.