Comment nous construisons chaque statistique

Tout ce que nous affichons vient de trois sources que nous gardons auditables : l'API publique de Supercell (developer.brawlstars.com), le CDN Brawlify (cdn.brawlify.com), et notre propre base Supabase, qui persiste les combats et agrégats que l'API officielle ne révèle pas au-delà des 25 derniers matchs par joueur.

L'API Supercell est la source canonique pour les données structurelles — brawlers, gadgets, pouvoirs star, hypercharges, équipements et rotation des événements — mais elle laisse de côté des champs critiques comme les images, la rareté et les descriptions longues. Nous croisons ces champs avec le CDN Brawlify, qui fonctionne indépendamment et accuse parfois un retard d'un à trois jours sur Supercell. Quand un brawler nouveau apparaît sur l'API officielle sans encore exister chez Brawlify, nous gardons une carte locale de rareté (BRAWLER_RARITY_MAP) pour que sa page s'affiche correctement le jour du lancement.

Notre base stocke deux classes de lignes dans la table meta_stats : source=user (combats réels d'utilisateurs premium ayant activé la sync) et source=global (échantillonnage automatique des classements PRO). Toute statistique publique sur le site est calculée en filtrant par source=global, pour qu'aucune donnée personnelle d'un utilisateur ne fuite vers les pages publiques.

La couche « PRO » de BrawlVision est un ensemble d'agrégats calculés sur les combats récents des meilleurs joueurs du monde. Toutes les six heures, un cron (meta-poll) interroge les classements officiels de Supercell pour onze pays — ceux qui concentrent l'activité compétitive — et construit une pool dédoublonnée d'environ 2 100 joueurs uniques tirés de chaque top 200.

Sur cette pool nous appliquons un sampler probabiliste pour empêcher que les combinaisons (carte, mode) populaires écrasent le dataset et masquent les plus rares. La probabilité d'accepter un combat individuel est p = min(1, (minLive + 1) / (current + 1)), où minLive est le nombre de la combinaison la moins représentée et current celui de la combinaison du combat candidat. Les combinaisons sous-échantillonnées reçoivent plus de poids, les saturées arrêtent de croître.

Le cron itère jusqu'à META_POLL_MAX_DEPTH = 1 000 joueurs par exécution avec un budget souple de 270 secondes pour rester sous le maxDuration de 300 s de la fonction serverless. Chaque réponse inclut un bloc « adaptive » avec compteurs d'itérations, joueurs interrogés et nombres par mode, pour que tout comportement anormal du sampler reste observable en production.

Le Win Rate naïf (victoires divisées par parties) trompe quand il y a peu de parties. Un brawler avec 3 victoires et 0 défaite sur une carte nouvelle affiche un 100 % qui ne signifie rien. BrawlVision applique un lissage bayésien pour corriger cette distorsion et renvoyer un nombre comparable entre des brawlers aux échantillons très différents.

La formule est WR_bayésien = (victoires + α·μ) / (batailles + α). Le paramètre α pèse le nombre de parties imaginaires que nous ajoutons et μ est le résultat que nous leur attribuons. Nous utilisons α = 30, ce qui revient à ajouter 30 batailles préalables avant de regarder les données réelles.

Jusqu’en septembre 2026, ces parties imaginaires valaient 50 %, et c’était la mauvaise valeur. Notre table conserve une seule ligne par bataille, celle du joueur sondé, qui fait partie du top 200 de son pays et gagne 71,4 % de ses parties (61 400 victoires sur 85 970 batailles dans la fenêtre de 14 jours, mesuré le 7 septembre 2026). Rapprocher de 50 % des données centrées sur 71,4 % tirait vers le bas toute case comptant peu de parties, et plus l’échantillon était petit, plus elle était tirée. Aujourd’hui μ vaut 0,714, la base que nous avons mesurée.

Le poids de l’a priori décroît à mesure que l’échantillon grandit. Avec 1 000 batailles et 530 victoires, le résultat s’établit à (530 + 21,42) / 1 030 = 53,5 %, très proche des 53,0 % bruts. Avec 3 batailles et 3 victoires, il s’établit à 74,0 % au lieu du 100 % naïf. Le lissage ne pèse que lorsque l’échantillon est vraiment petit.

Le Win Rate que nous publions mélange deux choses. L’une est la qualité d’un brawler, l’autre les adversaires qu’il a rencontrés. Un brawler qui apparaît surtout dans des duels favorables ressort haut sans que cela dise grand-chose de son kit. La force corrigée sépare les deux et estime la fréquence à laquelle ce brawler gagnerait face à un adversaire de niveau moyen.

Le calcul est un modèle Bradley-Terry ajusté par MM sur la table des duels des 14 derniers jours. Chaque paire de brawlers est symétrisée avant d’entrer dans l’ajustement, parce que nos lignes sont toujours enregistrées du côté du joueur sondé et que ce côté part avec un avantage. Mesuré sur les paires comptant au moins 30 duels dans chaque sens, le Win Rate de A contre B ajouté à celui de B contre A donne une médiane de 138 %, là où une donnée symétrique donnerait 100 %. En comptant chaque duel une fois de chaque côté, cet avantage entre en faveur des deux et s’annule. Le résultat est publié comme le Win Rate attendu face au brawler médian de l’ajustement, sur cette échelle 50 % correspond donc à l’égalité.

Le chiffre corrige la composition des adversaires et l’avantage moyen de l’échantillonnage. Il ne corrige pas qui joue le brawler. Ni meta_stats ni meta_matchups ne conserve d’identifiant de joueur, il est donc impossible de retrancher le niveau de la personne qui joue avec les données dont nous disposons ; il faudrait enregistrer le classement du joueur sondé au moment de l’ingestion. C’est pour cela que les listes du site restent ordonnées par Win Rate observé et que la force figure à côté. Et c’est aussi pour cela que le Win Rate observé tourne autour de 72 % et non de 50 %. L’échantillon est constitué de parties de joueurs du top 200 de onze pays, qui gagnent près de 72 % de celles qu’ils jouent, si bien que sur cette échelle 72 % décrit un brawler ordinaire. Nous ne publions la force que des brawlers comptant au moins 400 duels enregistrés face à 20 adversaires différents ; en dessous, nous omettons le chiffre au lieu d’afficher un nombre qui ne tient pas.

Le Comfort Score est la métrique maison de BrawlVision pour répondre à la question « avec quel brawler joues-tu vraiment mieux que la moyenne ? ». Ce n'est pas un Win Rate brut : il combine trois composantes avec des poids 60/30/10 pour couvrir différentes dimensions de la performance personnelle.

La composante principale (60 %) est le WR du joueur avec ce brawler, lissé bayésiennement comme le meta global, pour qu'un brawler joué peu de fois ne fausse pas le classement. La composante intermédiaire (30 %) est l'écart entre ce WR personnel et le WR meta du brawler en général : un joueur à 55 % sur SHELLY quand le meta global est à 48 % gagne plus de comfort qu'un joueur à 55 % sur un brawler dont le meta est 53 %, parce que la progression relative est plus grande.

La composante finale (10 %) est la fréquence d'usage normalisée : à conditions égales, jouer un brawler 100 fois compte plus que 10, parce que la régularité est récompensée. Les formules exactes et les poids vivent dans src/lib/analytics/compute.ts et s'appliquent identiquement à chaque appel d'endpoint, pour que le classement reste reproductible.

Chaque brawler public porte un indicateur de tendance « +X,Y% » ou « −X,Y% » qui mesure comment son WR meta a changé sur les 7 derniers jours par rapport aux 7 précédents (fenêtre totale de 14 jours). Le calcul tourne sur source=global avec un minimum de MIN_BATTLES_PER_TREND_WINDOW = 3 combats dans chaque moitié de la fenêtre — si l'une des deux moitiés n'atteint pas le seuil, nous renvoyons null et l'UI cache la flèche au lieu d'inventer un nombre à faible signal.

La tendance est précalculée toutes les six heures dans une petite table (public.brawler_trends, une ligne par brawler) via un job pg_cron. Le faire dans la base — plutôt que dans la réponse de l'endpoint — évite de scanner des dizaines de milliers de lignes de la fenêtre de 14 jours à chaque rafraîchissement ISR. Si la table précalculée a plus de 12 heures ou est vide, l'endpoint bascule vers une route inline paginée sur meta_stats qui renvoie la même réponse à un coût plus élevé. La pagination est requise parce que PostgREST tronque silencieusement les requêtes non paginées à 1 000 lignes, ce qui avait fait retourner null à la majorité des brawlers pour fausse insuffisance d'échantillon.

La logique vit dupliquée par design : une version TypeScript dans src/lib/brawler-detail/trend.ts (route détail) et une version SQL dans supabase/migrations/022_*.sql (route bulk). Les deux utilisent le même seuil, la même fenêtre et le même filtre source=global. Si elles divergent un jour, la page individuelle d'un brawler et la page agrégée afficheraient des nombres différents pour le même brawler, donc tout changement est appliqué aux deux.

La fréquence à laquelle une donnée est rafraîchie influence comment la lire, alors nous la documentons explicitement. Les pages statiques (celle-ci comprise) utilisent ISR (Incremental Static Regeneration) avec une revalidation de 24 heures. Les pages avec données dynamiques mettent en cache la réponse de l'API jusqu'à ce que le job pertinent l'invalide.

Brawlers, gadgets et pouvoirs star se synchronisent depuis l'API Supercell avec un cache serveur de 24 heures. Le meta-poll (données PRO) tourne toutes les 6 heures et produit des lignes meta_stats fraîches. La précalcul des tendances 7 jours tourne en pg_cron à « 17 */6 * * * » (minute 17 de toutes les six heures) pour ne pas entrer en conflit avec le meta-poll. La rotation in-game des événements se rafraîchit toutes les 30 minutes.

Les combats individuels d'utilisateurs premium ayant activé la sync sont téléchargés juste après chaque match dans une fenêtre glissante via le cron de sync. Une fois en base, ils alimentent meta_stats avec source=user et servent aux analyses privées de la section profil ; ils n'apparaissent jamais dans des agrégats publics et ne se mélangent jamais à source=global.