Données du sport-tech : la vraie question, qui détient les clés

La technologie sportive vend la même promesse depuis des années : plus de données, des réponses plus rapides, des décisions plus intelligentes. Les gros titres des études de marché qui arrivent chaque semaine s'appuient sur des taux de croissance et des sigles. La réalité de l'ingénierie est plus désordonnée. Deux documents de la pile de cette semaine méritent d'être lus ensemble, car ils décrivent deux façons opposées d'alimenter un agent d'IA avec les chiffres sur lesquels les organisations sportives affirment de plus en plus fonctionner.

Starburst a publié le 11 septembre une analyse de deux architectures pour l'analyse de données agentique. Le texte s'adresse aux équipes data d'entreprise, pas aux clubs ni aux ligues, mais l'exemple choisi est volontairement banal : un supermarché qui demande si la promotion sur les œufs de la semaine dernière a été rentable. Répondre suppose de savoir si la promotion a attiré des clients qui ne seraient pas venus autrement, si les nouveaux clients sont revenus, ce qui a été acheté dans la même transaction, où ces articles se trouvent dans le magasin et quel est leur niveau de rentabilité. C'est une chaîne de questions successives sur plus d'un jeu de données. Une organisation sportive affronte exactement la même forme de problème quand elle cherche à savoir pourquoi une campagne de sponsoring a fait bouger les ventes de billets.

Option 0 : envoyer les données au modèle

La première approche, que Starburst appelle option 0, consiste à extraire les tables pertinentes et à envoyer les données brutes à l'agent sous forme de fichier ou de flux direct, en laissant l'agent faire son propre traitement. L'entreprise est directe sur les compromis. Envoyer des téraoctets de données à un agent peut devenir prohibitif quand l'agent facture par élément de données reçu ou traité. Starburst affirme que les inconvénients de performance réduisent tellement l'intérêt pratique de cette option qu'elle n'est pas bonne, raison pour laquelle elle porte l'étiquette option 0 plutôt qu'option 1.

Pour les équipes sportives, l'arithmétique est de toute façon peu attrayante. Un seul match génère désormais des données de tracking, des événements issus de la vidéo, des registres de billetterie, des transactions de produits dérivés et de la télémétrie d'application. Or le nombre de personnes qui posent des questions sur ces données est faible. Payer à la ligne pour les transférer dans un modèle n'est pas une ligne budgétaire que la plupart des services d'analyse peuvent défendre.

La seconde approche est celle que Starburst recommande. Donner à l'agent un accès direct au système de base de données et le laisser écrire son propre SQL, en itérant au fur et à mesure qu'il affine son objectif. Le moteur de base de données fait ce pour quoi il est conçu, traiter des données locales avec des plans de requête optimisés, tandis que l'agent supervise et envoie des requêtes successives ou parallèles jusqu'à obtenir un résultat qui vaut la peine d'être renvoyé. Starburst reconnaît le défaut connu : les agents peuvent être bien plus exigeants que des humains et submerger une base de données de requêtes spéculatives pendant qu'ils travaillent.

L'industrie des bases de données se concentre désormais fortement sur la prise en charge des charges de travail agentiques, et les systèmes de bases de données modernes sont de plus en plus capables de gérer ce type de traitement de données scalable efficacement.

Voilà l'argument en une phrase, et c'est un argument de vente autant qu'un argument d'ingénierie. Starburst vend des systèmes de bases de données. Malgré cela, le point sur l'endroit où se trouve l'optimisation est difficile à contester : les agents progressent, mais ils ne sont pas près de traiter des téraoctets de données structurées aussi efficacement que des moteurs construits sur des décennies de recherche sur les requêtes.

À quoi ressemblent vraiment les outils

Deux projets open source de la pile de cette semaine montrent comment la tuyauterie s'assemble par le bas. Adaca Analytics, publié sur GitHub le 8 septembre sous licence MIT, reconstruit les anciens tableaux de bord Google Analytics au-dessus des données GA4. Les agrégations quotidiennes issues de l'API GA4 Data ou d'une exportation BigQuery atterrissent dans une base D1 que l'opérateur possède, tandis que les données temps réel restent chez Google. Six tableaux de bord sont fournis d'origine, chaque chiffre s'ouvre sur une page de détail avec sa propre tendance et ses ventilations, et l'ensemble tourne sur Cloudflare Workers derrière Cloudflare Access ou une authentification Basic intégrée. Il n'y a pas d'écran de connexion.

Plainoldanalytics, publié sur GitHub le 13 septembre, prend la route inverse : une analyse web greffée à l'intérieur d'une application Go. Elle est agnostique en matière de stockage, donc importer le paquet central n'entraîne jamais de backend, et des adaptateurs existent pour gin et chi. Le trafic est vidé sur disque environ une fois par seconde. Les opérateurs peuvent définir des propriétés clé et valeur par requête, exclure des routes de la journalisation ou enregistrer des chemins de route littéraux au lieu des paramètres de chemin.

Aucun des deux projets n'est un produit sportif. Les deux sont pertinents parce qu'ils montrent le glissement de l'hypothèse par défaut : les données restent là où l'opérateur les a mises, et la couche d'analyse est quelque chose qu'on exécute plutôt que quelque chose qu'on loue.

La question de la vie privée que personne ne mesure

DataZen, un client de base de données local-first publié sur Hacker News le 29 août, pose le problème directement : où vont mes données ? L'outil est distribué sous GPLv3, ne demande aucun compte et prend en charge PostgreSQL, MySQL, SQLite et Redis par défaut, avec des pilotes optionnels pour MongoDB, ClickHouse, DuckDB et SQL Server. Il inclut un serveur MCP intégré pour que des agents comme Claude, Cursor et Cline puissent interroger des bases de données via le Model Context Protocol, et il peut aussi agir comme client MCP. Les identifiants sont chiffrés en AES-256-GCM dans le trousseau du système d'exploitation, et le projet indique que seuls le schéma et le contexte de requête sont partagés avec le fournisseur d'IA configuré par l'utilisateur.

C'est cette dernière distinction que les organisations sportives devraient interroger. Le schéma et le contexte de requête ne sont pas la même chose que les données brutes, mais ce n'est pas rien non plus. Un schéma révèle ce qu'un club mesure : quels attributs de supporters il stocke, comment il segmente les acheteurs de billets, ce qu'il suit sur la charge de travail des joueurs. Dans un sport où les données de blessure et les négociations de contrat cohabitent avec la billetterie, les métadonnées sont sensibles commercialement à elles seules.

Le dossier ne nous dit pas ce qu'un club ou une ligue a réellement déployé, et les documents commerciaux qui sous-tendent les prévisions de marché ne prouvent pas l'adoption. Ce qu'il montre, en revanche, c'est une division. Un camp soutient que les agents doivent piloter la base de données et que les moteurs modernes peuvent absorber la charge. L'autre construit des outils qui gardent les données en local et n'envoient que le contexte vers l'extérieur. La technologie sportive héritera de la réponse que ses équipes data choisiront, et ce choix se fait maintenant, dans des dépôts open source plutôt que dans des communiqués de presse.