Le virage discret des données sportives : tableaux de bord auto-hébergés et agents qui écrivent leurs requêtes

En 2026, le bruit autour de la technologie sportive vient surtout des prévisions de marché et des annonces de sponsoring. L'outillage réel est plus discret. Il raconte une histoire plus précise : les équipes analytiques sortent leurs tableaux de bord des clouds de fournisseurs, donnent aux agents d'IA un accès direct aux bases de données, puis discutent la facture.

Deux sorties open source de septembre dessinent la première moitié de ce basculement. Toutes deux sont auto-hébergées. Toutes deux supposent que les données existent déjà quelque part. Ni l'une ni l'autre n'est un produit sportif au sens d'une application pour supporters.

Elles forment la plomberie sous les tableaux d'affichage.

Des tableaux de bord GA4 que vous hébergez vous-même

Le 8 septembre, un cabinet de conseil logiciel nommé Adaca a publié Adaca Analytics sur GitHub, sous licence MIT. C'est une couche de tableaux de bord auto-hébergée pour Google Analytics 4, qui tourne sur Cloudflare Workers, selon le dépôt du projet. La mécanique compte plus que l'argumentaire. Les agrégats quotidiens sont récupérés via l'API GA4 Data ou via un export BigQuery, et ils atterrissent dans une base D1 que l'exploitant possède, indique le README. Les données temps réel restent du côté de Google. Les tableaux de bord sont assemblés à partir de widgets configurables sur une grille. Six sont fournis d'origine, et un constructeur en quatre étapes permet de créer les personnalisés.

Le dépôt affirme que chaque chiffre se détaille : sources, pages et pays disposent chacun de pages de détail avec leur propre tendance et leurs ventilations, précalculées pour se charger en un seul aller-retour.

Il y a un filtre par tableau de bord, des segments enregistrés et des liens de partage en lecture seule qui peuvent figer un filtre. La comparaison se fait sur la période précédente, l'année dernière ou n'importe quelle fenêtre, avec un détail horaire pour le jour en cours et un compteur de visiteurs en direct. Des synthèses hebdomadaires et mensuelles ainsi que des alertes de trafic partent par e-mail ou Slack. L'installation est volontairement peu spectaculaire. Un exploitant crée un compte de service Google avec un accès Lecteur sur la propriété GA4, télécharge sa clé JSON et appuie sur Deploy to Cloudflare. Cela duplique le dépôt, provisionne D1 et KV, demande la clé et déploie le Worker avec son cron. Cloudflare Access ou une authentification Basic intégrée se place devant, car il n'y a pas de connexion. Ensuite la première reprise des données s'exécute sous vos yeux.

Pour les organisations sportives qui gèrent plusieurs propriétés à travers des ligues, des équipes ou des sites régionaux, l'argument est le contrôle : une base D1 qui vous appartient, pas de contrat analytique par siège, et la prise en charge de l'export BigQuery pour ceux qui envoient déjà GA4 vers un entrepôt.

La contrepartie est opérationnelle. S'auto-héberger signifie posséder le cron, la couche d'authentification et les migrations.

Un intergiciel analytique à l'intérieur de l'application

Cinq jours plus tard, le 13 septembre, un projet distinct nommé Plainoldanalytics est apparu sur GitHub. C'est une bibliothèque d'analyse web greffée aux applications Go, décrite dans son README comme proche dans l'esprit d'Umami, Plausible ou PostHog, mais intégrée à votre application plutôt qu'exécutée à côté. Le paquet central est agnostique en matière de stockage : l'importer n'entraîne jamais de backend. Les développeurs choisissent un paquet de stockage, comme un magasin en mémoire ou DuckDB, et obtiennent à la fois un Storage fonctionnel et le câblage Analytics en un seul appel de constructeur. Le trafic est vidé sur disque environ une fois par seconde, et un appel Close à l'arrêt vide tout ce qui reste en mémoire tampon.

La bibliothèque définit des propriétés clé et valeur sur chaque requête, que le tableau de bord intégré peut filtrer. Elle traite aussi à part une propriété utilisateur, pour que tout le trafic lié à un utilisateur apparaisse ensemble.

Les routes avec paramètres de chemin sont enregistrées comme paramètres par défaut, avec un wrapper UseRequestPath disponible quand la route littérale compte. Il existe un appel Exclude pour les routes qui ne doivent pas du tout être journalisées, plus des adaptateurs pour gin et chi, et un script optionnel d'enregistrement de session navigateur. Pour un club ou une fédération qui gère billetterie, adhésions ou services de contenu en Go, c'est la différence entre un script tiers sur chaque page et une ligne d'intergiciel dans le routeur. Aucun des deux projets n'est une plateforme d'analyse sportive. Tous deux retirent un fournisseur du chemin entre l'événement et le chiffre.

Le débat d'architecture : qui exécute la requête

La question plus difficile se situe au-dessus de l'outillage, et Starburst l'a abordée dans un billet de blog du 11 septembre intitulé « An Analysis of Two Architectures for Agentic Data Analysis ». La prémisse : les agents complètent ou remplacent de plus en plus l'analyse humaine des données. Ils prennent en charge des questions avec des questions de suivi et plusieurs tours d'analyse sur un ou plusieurs jeux de données. L'exemple travaillé de Starburst est une épicerie qui demande si la promotion sur les œufs de la semaine dernière a été rentable. Y répondre suppose de savoir si la vente a attiré des clients qui ne seraient pas venus autrement, si les nouveaux clients sont revenus, ce qu'il y avait d'autre dans le même panier, et quelle est la rentabilité de ces articles. Les questions sportives ont la même forme : l'opération de streaming a-t-elle apporté de nouveaux abonnés, sont-ils restés, qu'ont-ils acheté d'autre.

Le billet expose les options pour alimenter un agent en données. L'option 0 consiste à extraire les données brutes et à les envoyer.

Starburst la juge impraticable hors circonstances inhabituelles, car les agents facturés à l'élément de données peuvent rendre des téraoctets prohibitifs.

Ces inconvénients de l'option 0 réduisent son intérêt au point qu'elle n'est pas une bonne option en pratique. C'est pourquoi je l'appelle « option 0 » : ce n'est pas quelque chose que je recommanderais en dehors de circonstances inhabituelles précises.

L'option 1 consiste à donner à l'agent un accès direct à la base de données et à le laisser écrire son propre SQL, en itérant jusqu'à une conclusion. Le moteur de base de données gère la planification des requêtes ; l'agent ne fait que superviser. Starburst note que la littérature signale un risque réel : les agents peuvent être bien plus exigeants que les humains et submerger un système de requêtes spéculatives à mesure qu'ils affinent leur cible. La conclusion du billet est une division du travail. Il soutient qu'il faudra du temps avant que les agents traitent des téraoctets de données structurées avec le même niveau d'optimisation que les systèmes de bases de données d'élite construits sur des décennies de recherche. D'ici là, le moteur garde le gros du travail.

Ce que cela donne

Lus ensemble, les trois éléments pointent dans la même direction. La couche de collecte s'intègre à l'application. La couche de présentation migre vers une infrastructure que l'exploitant contrôle. Et la couche d'analyse est confiée à des agents qui interrogent directement les bases de données au lieu de recevoir des extraits. Rien de tout cela n'apparaît dans les prévisions de marché en une. C'est la partie de la technologie sportive qui décide si le chiffre à l'écran est juste, à quelle vitesse il arrive, et qui paie les tokens.