L'infrastructure de données du sport se reconstruit en silence : ce que montrent vraiment les 72 dernières heures
Le 30 septembre, Tigris a publié un post-mortem sur l'exécution de sa file de stockage objet dans FoundationDB et sur le transfert du travail asynchrone vers Kafka. Ce n'est pas un sujet sportif, mais il décrit la tuyauterie exacte qui transporte aujourd'hui les médias sportifs à fort volume. Il tombe la même semaine où l'on a signifié aux centres de données européens qu'ils ne peuvent plus garder secrètes leurs consommations d'eau et d'électricité.

Ce qui s'est publié de plus utile sur la technologie du sport ces 72 dernières heures n'a rien à voir avec le sport. Le 30 septembre, le fournisseur de stockage objet Tigris a publié un post-mortem d'ingénierie expliquant pourquoi il a sorti de FoundationDB les tâches asynchrones comme le ramasse-miettes pour les confier à Kafka. La raison concerne quiconque fait de l'analyse sportive : si un worker meurt en pleine tâche, la tâche meurt avec lui. « Une fois que le worker consomme une tâche, elle n'est plus dans la file et elle meurt avec lui », écrit l'entreprise.
Le sport n'est plus qu'un empilement de ces tâches. Flux de tracking, pipelines vidéo, règlement des paris, rendu des résumés. Rien de tout cela ne tolère un message perdu.
Tigris assume clairement le compromis. L'entreprise garde encore certaines files dans FoundationDB, car la base de données supprime le problème de double écriture. Mais l'ordonnancement « exige de nombreuses écritures et lectures, ce qui charge FoundationDB en lecture et entre directement en concurrence avec les requêtes des utilisateurs ». L'entreprise a implémenté l'article QuiCK d'Apple, le système de files derrière CloudKit, et le décrit comme « un système de files qui utilise la Record Layer de FoundationDB pour implémenter une file de messages fondée sur le temps ». Le texte est aussi étonnamment drôle à propos de Kafka, comparant son auto-hébergement au réveil en « vermine monstrueuse » pendant que tout le monde vous demande poliment de passer à autre chose.
Le lien avec le sport n'a rien de forcé. Les ligues et les diffuseurs promettent depuis dix ans une couverture nativement pilotée par les données, et le discours s'arrête d'ordinaire au tableau de bord. Ce qui compte en dessous, c'est l'orchestration : quels événements sont traités, dans quel ordre, et ce qui se passe quand un worker tombe à 3 heures du matin en plein match.
Les centres de données européens muets sur les chiffres
Le même jour, le média néerlandais NL Times a rapporté les résultats d'une enquête d'un an menée par Lighthouse Report avec Trouw et d'autres médias européens sur le reporting environnemental des centres de données. Le constat est net : aux Pays-Bas, moins d'un quart des grands centres de données publient des chiffres sur leur consommation d'électricité et d'eau potable.
Les chiffres derrière cet écart sont précis. Selon la Dutch Datacenter Association, les Pays-Bas comptaient 186 centres de données commerciaux d'une capacité de 500 kilowatts ou plus à la fin de l'année dernière. L'Agence néerlandaise pour les entreprises, qui collecte les données pour l'Union européenne, ne détient des dossiers que sur 104 d'entre eux. Des chiffres publics existent pour la consommation d'électricité de 44 centres et pour celle d'eau de 47. La directive européenne sur l'efficacité énergétique impose un reporting à ce seuil depuis trois ans.
Statistics Netherlands évalue la consommation électrique des centres de données néerlandais à 5,1 milliards de kilowattheures en 2024, soit 4,6 pour cent de la consommation nationale et près du double du niveau de cinq ans plus tôt. Le gestionnaire de réseau TenneT projette 10 à 15 pour cent en 2030. Le RVO a révélé cet été que le plus grand centre de données néerlandais de Microsoft représente à lui seul 1 pour cent de la consommation nationale d'électricité. Google, qui exploite deux grands centres de données dans le pays, ne publie pas ses chiffres.
Pour le sport, ce n'est pas abstrait. Le streaming, le tracking en temps réel et la vision par ordinateur reposent sur le même réseau et sur le même angle mort du reporting.
Interroger le lac de données sans le déplacer
Le 30 septembre également, AWS a annoncé qu'Aurora PostgreSQL peut désormais interroger directement des données Apache Iceberg et Parquet, via des tables externes, en utilisant le moteur de requête de DuckDB intégré à PostgreSQL. L'entreprise indique que la fonctionnalité est disponible en général sur Aurora PostgreSQL à partir des versions 17.11 et 18.6 dans toutes les régions commerciales et GovCloud, sans surcoût.
L'argument est la suppression de l'ETL. « Y accéder exigeait généralement des pipelines qui copient les données de votre lac vers Aurora, ce qui fait grimper les coûts et le travail d'ingénierie à mesure que les schémas évoluent », indique l'annonce. Pour une organisation sportive, c'est la différence entre un lac de données qui dort dans un entrepôt et un lac qu'un analyste peut réellement interroger pendant une saison.
Les clubs et les ligues promettent des écosystèmes sportifs nativement pilotés par les données lors de salons toute la semaine. Consultancy-me.com a couvert le 29 septembre un dirigeant de Pure Sports qui parlait exactement de cela à LEAP 2026, et SVG Europe a publié le même jour un article sur l'infrastructure pour médias à fort volume. Ni l'un ni l'autre n'est un lancement de produit. Tous deux décrivent un marché qui suppose que la couche de données fonctionne.
Elle fonctionne de mieux en mieux. C'est là l'histoire.
La couche de recherche bouge aussi
Le 29 septembre, les chercheurs Osayamen Jonathan Aimuyo, Swapnil Gandhi et Christos Kozyrakis ont soumis à arXiv un article décrivant Purlin, un cadre de communication qui sépare l'orchestration du chemin de données dans les collectifs GPU. L'article rapporte des accélérations de latence allant jusqu'à 5,14x et des gains de bande passante allant jusqu'à 4,50x sur sept collectifs sur des GPU A100, H200 et B200. Intégré à la pile de service SGLang, Purlin a amélioré le débit et l'interactivité du service LLM hors ligne de 1,13x en moyenne et jusqu'à 1,37x, et l'interactivité de l'inférence en ligne de 1,26x en moyenne et jusqu'à 2,85x, avec le gain le plus important en situation de surcharge.
Ce ne sont pas des benchmarks sportifs. Mais ces charges de travail ont la même forme que la génération automatisée de résumés, le tracking multicaméra et l'inférence tactique en temps réel, où la latence sous charge est tout le produit.
L'écart entre un gain d'interactivité de 2,85x dans un article et un système opérationnel au bord du terrain est énorme, et rien dans le dossier ne suggère que quelqu'un l'a comblé. La direction reste pourtant la même dans toutes les sources publiées cette semaine : le travail intéressant se fait sous l'interface, dans l'orchestration, les moteurs de requête et les collectifs réseau.
Ce que la semaine n'a pas tranché
Elle n'a pas tranché la vie privée. Le 30 septembre, 404 Media a rapporté que l'administration Trump utilise le programme High Intensity Drug Trafficking Area des années 1980 pour acheminer les données locales de lecteurs automatiques de plaques d'immatriculation de Flock, Axon et d'autres fournisseurs vers des centres de surveillance fédéraux, et parfois jusqu'au National License Plate Reader Program de la DEA. Les documents ont été obtenus par des demandes d'accès aux documents publics de Cris van Pelt, créateur de HaveIBeenFlocked.com. Jeramie Scott, de l'Electronic Privacy Information Center, a déclaré à 404 Media : « Si Flock vous met en colère, alors ceci devrait vous mettre en colère. »
Les enceintes sportives font partie de ce parc de caméras. Les parkings autour aussi.
Elle n'a pas tranché non plus les données de santé. Le Guardian a rapporté le 30 septembre que plus de 44 000 personnes ont déposé des objections formelles au titre de l'article 21 du RGPD britannique contre le traitement de leurs informations par la Federated Data Platform de NHS England, propulsée par Palantir. Les militants citent le travail de Palantir pour l'armée israélienne et pour l'application des lois d'immigration américaines. Palantir affirme que la plateforme aide à réduire les listes d'attente, citant 117 000 opérations supplémentaires, une baisse de 14,3 pour cent des retards de sortie pour les patients de longue durée et une amélioration de 5,6 pour cent du diagnostic du cancer sous 28 jours.
Et elle n'a pas tranché la question environnementale. L'enquête de Lighthouse Report a constaté que les centres de données européens refusent en grande partie de dire combien d'eau et d'électricité ils consomment, trois ans après le début de l'obligation de reporting.
Pris ensemble, ces 72 dernières heures décrivent un secteur de la technologie sportive dont la couche visible, les tableaux de bord, les graphiques de tracking, les commentaires par IA, tourne sur une couche invisible que l'on reconstruit dans des blogs d'ingénierie publics et des préprints arXiv. Ses coûts en ressources et en vie privée restent largement non divulgués. Ce n'est pas un scandale. C'est un problème de mesure, et c'est celui qu'il vaut la peine de surveiller.
Sources
6- 01We used a database as a message queue. Now we use Kafka.EN
- 02Most data centers refusing to say how much water, electricity they useEN
- 03Aurora PostgreSQL now supports querying of Apache Iceberg and Parquet dataEN
- 04Purlin: Separating Orchestration from the Datapath of CollectivesEN
- 05How Cities Are Forced to Funnel License Plate Data to a Massive Federal Surveillance ProgramEN
- 06More than 44,000 file legal objections to Palantir NHS platform handling their dataEN
Tous les chiffres et citations de ce texte proviennent des sources citées ci-dessous.
Les contenus ont été préparés par l'équipe de rédaction, assistée par l'IA.
Commentaires
0- Aucun commentaire — soyez le premier.