L'analytique sportive dévore son propre pipeline de données

Apple a une application qui s'appelle Sports. C'est tout le nom. Slate l'a testée le 10 juin, au moment où la Coupe du monde commençait, et le verdict tient en une ligne : elle ne fait presque rien. Des noms d'équipes et des logos, des bilans, des horaires de matchs, des scores. Pas de fil d'actualités, pas de guide de diffusion, pas de défilement à la TikTok.

Cette critique est un contrepoint utile à la manière dont on vend d'ordinaire la technologie sportive. Les mêmes semaines ont produit une série d'outils de développement pour la plomberie analytique. C'est dans l'écart entre les deux histoires que se trouve le travail intéressant.

Ce qu'Apple a réellement livré

Le critique de Slate décrit un produit construit sur la soustraction. L'application ne contient aucun titre d'actualité et aucun guide de diffusion, même si l'on peut voir la chaîne d'un match en appuyant dessus. Les cotes de paris apparaissent par défaut sur le tableau des scores et se désactivent définitivement d'un seul interrupteur. La publicité est presque absente, avec parfois des promotions Apple TV en haut d'une page. L'utilisateur choisit les ligues et les équipes qui apparaissent sur la page d'accueil et dans la barre latérale. Les scores de ces équipes peuvent alimenter les Activités en direct sur l'écran verrouillé, ou pas.

L'affirmation de rapidité de cette critique est précise et vérifiable. L'auteur dit avoir dû désactiver les mises à jour automatiques des Pittsburgh Penguins pendant les séries éliminatoires de la Coupe Stanley : l'application faisait apparaître les actions avant son bouquet de streaming. Il rapporte la même expérience avec des matchs de NFL, de football universitaire et de basket universitaire. La couverture s'étend aux matchs de la Coupe du monde, à la MLS, à la NWSL et à une trentaine d'autres ligues de football, ainsi qu'au tennis masculin et féminin et au circuit LPGA. Derrière un appui, on trouve des feuilles de match basiques, des classements et des effectifs.

Apple a annoncé l'application à l'hiver 2024. Slate cite la formule d'un dirigeant d'Apple au lancement : l'entreprise a « créé Apple Sports pour donner aux fans de sport ce qu'ils veulent, une application qui offre un accès extrêmement rapide aux scores et aux statistiques ».

« Nous avons créé Apple Sports pour donner aux fans de sport ce qu'ils veulent, une application qui offre un accès extrêmement rapide aux scores et aux statistiques. »

C'est un problème de données déguisé en problème de design. Chaque score à l'écran est un flux, une correspondance entre ligues et équipes, et un budget de latence. Apple peut absorber ce coût. La plupart des organisations qui construisent quelque chose de comparable ne le peuvent pas. D'où la grappe de sorties de la même période, destinées à ceux qui doivent assembler le pipeline eux-mêmes.

Reconstruire l'ancien Analytics sur les données de GA4

Prenons adaca-analytics, publié sur GitHub le 8 septembre par Adaca, un cabinet de conseil en logiciel. C'est une couche de tableaux de bord auto-hébergée pour Google Analytics 4, qui tourne sur Cloudflare Workers. Des agrégations quotidiennes issues de l'API GA4 Data ou d'un export BigQuery atterrissent dans une base D1 que l'opérateur possède. Les données en temps réel restent chez Google. Le dépôt fournit six tableaux de bord prêts à l'emploi, plus un constructeur en quatre étapes pour les personnalisés. Chaque chiffre principal s'ouvre sur une page de détail avec sa propre tendance et ses ventilations, précalculées pour se charger en un seul aller-retour.

Les détails opérationnels comptent plus que la liste des fonctions. L'installation demande un compte de service Google avec un accès Lecteur sur la propriété GA4 et sa clé JSON. Le déploiement duplique le dépôt, provisionne D1 et KV, demande la clé et déploie le Worker avec sa tâche cron. Il n'y a pas d'authentification : le README vous dit donc de placer Cloudflare Access ou l'authentification basique intégrée devant. Le développement local passe par npm install, un fichier .dev.vars contenant le JSON du compte de service sur une ligne, la génération de types, une migration de base et un serveur de développement. L'intégration continue compte quatre portes : build, vérification de types, lint et tests. La licence est MIT.

L'argument, dans les mots du dépôt, est de restaurer une forme de produit que GA4 a déplacée : des tableaux de bord avec exploration descendante, des segments enregistrés, des liens de partage en lecture seule capables d'épingler un filtre, une comparaison avec la période précédente ou l'année dernière, des synthèses hebdomadaires et mensuelles, et des alertes de trafic par courriel ou Slack.

L'analytique comme middleware, pas comme plateforme

Une deuxième sortie fait le pari architectural inverse. Plainoldanalytics, publié sur GitHub le 13 septembre, est une analytique web greffée sur les applications Go. Le README le présente comme proche dans l'esprit d'Umami, Plausible ou PostHog, mais intégré dans votre application plutôt qu'hébergé à côté. Le paquet central est indépendant du stockage et ne connaît aucun backend : l'importer n'en tire donc jamais un. Vous choisissez un paquet de stockage, ou vous implémentez l'interface Storage et la passez au constructeur.

L'usage est volontairement réduit. Un constructeur memory_store renvoie à la fois un Storage et le câblage, et un appel analytics.Middleware enveloppe un routeur existant. Le tableau de bord se monte sur le chemin de votre choix. Une balise script active la capture d'événements côté client, y compris l'enregistrement de session en option et des appels comme plainoldanalytics.track('signup', {plan: 'pro'}). Le trafic est vidé sur disque environ une fois par seconde, et un appel Close à l'arrêt vide le tampon. Des adaptateurs existent pour gin et chi. Le README montre comment limiter le middleware à un groupe de routes pour que le tableau de bord lui-même ne soit pas enregistré comme trafic.

Deux petits détails suggèrent que ce code a été écrit par quelqu'un qui a exploité de l'analytique en production. Les requêtes peuvent porter des propriétés clé/valeur sur lesquelles l'interface peut filtrer, et la propriété utilisateur reçoit un traitement particulier, affichant tout le trafic lié à cet utilisateur. Des routes peuvent être entièrement exclues de la journalisation. Les paramètres de chemin sont enregistrés tels quels, mais envelopper un gestionnaire avec UseRequestPath enregistre la route littérale à la place. Cela compte quand vous servez des fichiers sous un joker et ne voulez pas que chaque URL devienne sa propre ligne.

La question des agents en dessous de tout cela

Starburst a publié le 11 septembre une analyse de deux architectures pour l'analyse de données agentique. Elle nomme le problème autour duquel tournent les outils ci-dessus. Le scénario : une chaîne d'épiceries demande si la promotion sur les œufs de la semaine dernière a été rentable. La question ne peut pas être tranchée à partir des seules ventes d'œufs. Il faut des relances pour savoir si la promotion a attiré des clients qui ne seraient pas venus autrement, si les nouveaux clients sont revenus, ce qu'il y avait d'autre dans ces transactions, où ces articles se trouvent dans le magasin, et à quel point ils sont rentables.

Starburst expose deux manières pratiques d'alimenter un agent. La première, que l'auteur appelle « option 0 » et ne recommande explicitement pas hors circonstances inhabituelles, extrait les données brutes et les envoie à l'agent sous forme de fichiers ou par un tuyau direct, laissant l'agent faire le traitement lui-même. L'objection porte sur le coût et la performance : envoyer des téraoctets à quelque chose qui facture à l'élément de données coûte cher, et l'agent fait un travail qu'un moteur de base de données fait mieux.

La seconde donne à l'agent un accès direct à la base pour qu'il écrive son propre SQL et affine ses requêtes par itérations. La base fait ce pour quoi elle est optimisée, et l'agent supervise. Starburst note que la littérature signale un risque réel : les agents peuvent être bien plus exigeants que des utilisateurs humains et submerger un système de requêtes spéculatives en se rapprochant d'une réponse. L'auteur soutient cependant que le secteur se concentre désormais sur la prise en charge de ces charges de travail.

Il y a une limite dans l'article qui mérite d'être répétée. L'auteur écrit qu'il faudra du temps avant que les agents puissent traiter des téraoctets de données structurées au même niveau d'optimisation que les systèmes de bases de données du marché actuel, bâtis sur des décennies de recherche. D'ici là, la base garde le gros du travail.

Pourquoi c'est une histoire de sport

Le sport est le cas grand public le plus difficile pour cette pile. La valeur d'un score se dégrade en quelques secondes, et le public arrive par vagues : une phase de groupes de Coupe du monde, une série éliminatoire, un dimanche après-midi avec une douzaine de matchs en parallèle. Le critique de Slate souligne que l'application est assez rapide pour divulguer les résultats avant qu'un flux de streaming ne rattrape. Ce n'est pas une réussite d'interface. C'est un pipeline qui doit réconcilier des dizaines de ligues, les associer aux équipes choisies par un utilisateur, et pousser des mises à jour vers un écran verrouillé dans une fenêtre de latence.

Apple peut financer cela. Tous les autres qui exploitent un produit pour fans, un produit de paris ou une application de club l'assemblent à partir de pièces. Les pièces publiées en septembre sont franches sur les compromis : posséder la base et obtenir l'exploration descendante sans fournisseur, intégrer l'analytique dans son propre processus et se passer de plateforme, ou donner à l'agent l'accès aux requêtes en acceptant qu'il pose plus de questions qu'aucun analyste humain ne l'a jamais fait. L'application sans fonctions est la partie facile. Mettre le chiffre à l'écran avant le flux, voilà le produit.