Créer une application de coaching de football sur Databricks

Les données de suivi constituent désormais le signal le plus riche dans le sport, mais le véritable défi consiste à transformer ces données en un outil que les entraîneurs peuvent réellement utiliser.

Un match moderne est capturé à 25 images par seconde (fps) à partir de 19 flux distincts : chaque joueur, le ballon et chaque événement, plusieurs fois par seconde. Pour un seul tournoi, cela représente 339 matchs et 51 millions de lignes de données de suivi. Pourtant, presque rien de tout cela n'est exploitable par la personne qui en a le plus besoin. Un entraîneur sur le banc ne peut pas lire un tableau de 51 millions de lignes. Coach's Corner comble cet écart, entièrement sur une seule plateforme.

Le défi n'est pas seulement une question d'échelle, mais aussi de timing et de cognition. Les entraîneurs prennent des décisions en quelques secondes, pas en minutes, alors que les flux de travail analytiques traditionnels supposent le contraire : traitement par lots (batch), tableaux de bord hors ligne et analyses d'après-match. Même lorsque des informations exploitables existent, elles sont enfouies derrière des outils qui nécessitent l'intervention d'un analyste pour les interpréter et les transmettre. Cela crée un goulot d'étranglement structurel où les données sont riches et les modèles sophistiqués, mais le décideur est pratiquement aveugle au moment crucial.

Découvrez Coach’s Corner, « La Pizarra »

La Pizarra (« le tableau noir ») est un banc technique d'équipe nationale qui fonctionne comme une Databricks App. Un entraîneur choisit un match et le rejoue en 2D ou 3D, faisant basculer la caméra d'un angle de diffusion à une vue tactique du dessus, avec une vitesse de lecture allant jusqu'à 8x. Superposées au replay se trouvent les analyses essentielles : cartes de tirs et d'xG, réseaux de passes, cartes de chaleur (heatmaps), coups de pied arrêtés, positionnement de l'équipe, contrôle du terrain, trajectoires du ballon et parcours des joueurs. Plusieurs outils avancés sont intégrés aux fonctionnalités de replay : une vue complète du classement, des analyses basées sur les événements, une signature de style « Scout » unique pour évaluer n'importe quelle équipe, et un Agent Tactique capable de générer des dossiers à la demande sur les prochains adversaires.

La vue du banc met l'intégralité du match entre les mains de l'entraîneur, permettant des transitions fluides entre les perspectives de diffusion et tactiques du dessus. Grâce à une lecture rapide 8x et à des superpositions automatiques pour les lignes de passe et les cartes de chaleur, les éléments tactiques tels que le contrôle du terrain et le positionnement de l'équipe deviennent des schémas concrets sur le terrain plutôt que des indicateurs abstraits.

La base technique de Coach's Corner a été dictée par un seul principe directeur : l'interface devait fonctionner comme une extension de l'instinct naturel de l'entraîneur plutôt que comme un instrument analytique complexe. Cela a nécessité une conception réduisant la charge d'interaction, privilégiant le contexte spatial aux graphiques traditionnels, et présentant chaque métrique comme un élément dynamique du jeu. En ancrant les informations directement sur le terrain de jeu, l'application élimine le besoin d'interprétation manuelle des données et fournit des analyses cruciales précisément au moment où elles sont le plus pertinentes.

Une seule plateforme, chaque étape

L'ingénierie des données de base se fait sous le capot. Les flux de suivi bruts arrivent au format NDJSON dans un Volume Unity Catalog, où Auto Loader les ingère de manière incrémentielle à l'aide du modèle Lakeflow Connect. À partir de là, les Spark Declarative Pipelines traitent les données à travers les niveaux bronze, silver et gold, en s'exécutant entièrement sans serveur (serverless) sur Photon avec 46 attentes de qualité des données nommées et appliquées. Les tables gold finales, y compris une table d'images de 51 millions de lignes, exploitent le clustering liquide pour permettre des temps de réponse aux requêtes de 1 à 3 secondes via DBSQL s'exécutant sur un petit entrepôt de données (warehouse). En consolidant tous les volumes, tables, modèles et index dans un seul Unity Catalog, l'architecture élimine le code d'intégration tiers et les systèmes de gouvernance secondaires.

L'architecture a délibérément évité la fragmentation en résistant à la transition vers des microservices spécialisés. Plutôt que de diviser l'ingestion, la transformation, la mise à disposition (serving) et l'orchestration de l'AI en piles isolées et optimisées localement, le système est resté unifié sur une seule plateforme. Le fait de tout conserver au sein de Databricks a permis de troquer une certaine flexibilité théorique contre une cohérence opérationnelle : une couche de gouvernance unique, une traçabilité (lineage) cohérente et l'absence de désadaptation d'impédance entre les systèmes. Cela devient particulièrement important avec l'introduction de l'AI, car le coût de données non gouvernées ou incohérentes s'accumule rapidement.

Les Spark Declarative Pipelines redéfinissent la fiabilité en passant d'un modèle impératif à un modèle explicite. Au lieu de s'appuyer sur des tâches rigides avec des hypothèses intégrées, le système traite la qualité des données comme une priorité absolue en imposant des attentes formelles. Cette suite de 46 attentes répond à un double objectif : elle protège le pipeline en temps réel et garantit l'exactitude des données pour les consommateurs en aval, y compris le replay, les analyses et les agents d'AI.

Le schéma ci-dessous présente l'architecture qui alimente la vue du banc. En haut se trouvent les expériences avec lesquelles l'entraîneur interagit : replay, analyse, scout, classements et agents. Au milieu, chacune de ces expériences est soutenue par des couches gouvernées : Unity Catalog pour les données et les modèles, Lakehouse et Lakebase pour la mise à disposition (serving) analytique et transactionnelle, et Vector Search pour la recherche de similarité. En bas se trouve la réalité brute d'où tout part : flux de suivi à 25 fps, événements de match, profils des joueurs et compositions d'équipes, le tout arrivant dans un lac de données (lake) ouvert.

Des chemins de serving optimisés pour la vitesse et l'échelle

Pour garantir des performances optimales, l'application utilise deux chemins architecturaux distincts pour la récupération des données. Les replays de suivi à grande vitesse sont alimentés par Lakebase, qui synchronise les tables gold avec Postgres pour permettre des lectures d'images fenêtrées de l'ordre de la milliseconde. En permettant à l'horloge du navigateur de ne récupérer que les images essentielles plutôt que de parcourir des matchs entiers, le système maintient une expérience interactive fluide. À l'inverse, les analyses d'événements lourdes sont acheminées via l'API Statement Execution vers le SQL warehouse, ce qui permet de séparer les requêtes de calcul intensives du replay 3D réactif.

Cette bifurcation délibérée entre Lakebase et DBSQL répond à des modèles d'accès différents plutôt qu'à une simple question de vitesse brute. Les fonctions de replay exigent des lectures séquentielles et sensibles à la latence sur des segments de données spécifiques, tandis que les charges de travail analytiques sont souvent exploratoires et nécessitent de larges analyses de jeux de données. En isolant ces chemins, chaque charge de travail fonctionne dans son environnement idéal, empêchant les pics analytiques de dégrader l'expérience de replay ou d'imposer un surprovisionnement inutile.

La séparation entre Lakebase and DBSQL n'est pas seulement une question de performance, mais de modèles d'accès. Les charges de travail de replay sont hautement séquentielles et sensibles à la latence, nécessitant des lectures prévisibles en millisecondes sur des tranches de données étroites. Les requêtes analytiques, quant à elles, sont irrégulières et exploratoires, analysant souvent des portions plus importantes du jeu de données. Tenter d'unifier ces charges dans une seule couche de mise à disposition (serving) ralentirait le replay ou surprovisionnerait les analyses. Diviser les chemins permet à chaque charge de travail de fonctionner dans son environnement idéal, sans compromis.

Une couche de scouting AI, ancrée dans des données gouvernées

L'intelligence repose sur les mêmes données gouvernées, jamais à côté. Le chat Scout est soutenu par un véritable espace Genie qui convertit les questions en langage naturel de l'entraîneur en requêtes SQL gouvernées. Vector Search alimente la recherche de « joueurs similaires » sur un index de profils de joueurs. Le dossier de l'adversaire est géré par un agent : un superviseur Agent Bricks orchestre Genie, Vector Search et un modèle xG enregistré dans Unity Catalog, et appelle Claude sur Model Serving via la Unity AI Gateway pour des appels LLM gouvernés et observables. Chaque étape est tracée dans MLflow, et l'agent dispose toujours d'une solution de secours scénarisée déterministe, de sorte qu'il ne se retrouve jamais bloqué devant un public. Comme il lit le même catalogue que celui que l'entraîneur voit sur le tableau, les réponses restent cohérentes avec les données.

Dans la vue scout ci-dessous, l'entraîneur ne rédige pas de requêtes ; il pose des questions comme il le ferait dans les vestiaires. Genie prend la question « Poser des questions sur l'xG par rapport à l'xBA » et la transforme discrètement en SQL gouverné, en utilisant les mêmes données de suivi et d'événements qui alimentent le banc. La réponse n'est pas une réponse LLM générique ; elle est ancrée dans les tables et modèles exacts enregistrés dans Unity Catalog, de sorte que le récit du scout correspond aux chiffres que l'analyste verrait.

L'un des problèmes les plus difficiles de l'AI appliquée n'est pas de générer des réponses, mais de s'assurer qu'elles sont traçables et défendables. Dans un contexte d'entraînement, une information erronée ou invérifiable est pire que pas d'information du tout. En ancrant chaque interaction d'AI dans Unity Catalog et en acheminant tous les appels de modèles via la Unity AI Gateway, chaque réponse est liée à des données gouvernées et à des chemins d'exécution observables. Cela permet aux entraîneurs et aux analystes de faire confiance non seulement aux résultats, mais aussi au processus qui les sous-tend.

L'architecture de l'agent reflète également un parti pris pour le déterminisme. Bien que le LLM fournisse la synthèse et le récit, les étapes critiques telles que la récupération des données, le calcul des métriques et la recherche de similarité sont gérées par des systèmes structurés comme Genie et Vector Search. Cette approche hybride évite la fragilité des systèmes entièrement génératifs tout en permettant une interaction flexible et naturelle.

Pourquoi c'est important

Bien que Coach’s Corner trouve ses racines dans le sport, son architecture répond à un défi universel : le « fossé d'utilisabilité » des données à haute fréquence. La plupart des organisations possèdent des volumes massifs de données qui restent silencieux sur le plan opérationnel, faute de système pour traduire les entrées brutes en décisions immédiates. Ce projet prouve qu'en unifiant l'ingestion, la transformation et l'AI au sein d'un cadre de gouvernance unique, la friction entre les données et l'action est éliminée.

L'impact ne se limite pas à des tableaux de bord plus rapides, mais réside dans un véritable changement dans la prise de décision. Lorsque les insights peuvent être générés, validés et transmis au sein du même système en quelques secondes, le rôle des données évolue : elles ne servent plus seulement à l'analyse rétrospective, mais participent activement à la prise de décision. C'est toute la différence entre observer le jeu et l'influencer.

La vue des agents ci-dessous illustre parfaitement ce modèle : à partir des données de suivi et des événements de match, l'agent superviseur extrait la signature de style d'une équipe, recherche des matchs similaires, appelle un modèle xG, puis demande à un LLM de synthétiser le tout dans un dossier. L'entraîneur ne voit rien de cette orchestration ; il voit simplement un bouton « Générer un dossier pour le Brésil », une trace de raisonnement qu'il peut inspecter s'il le souhaite, et un rapport enregistré qui s'intègre à sa stratégie de match.

Initialement conçu comme une application axée sur le sport, Coach's Corner est devenu un modèle de référence pour les systèmes modernes de données et d'AI dans le secteur du divertissement en direct. En stockant les données brutes une seule fois et en les affinant via des pipelines fiables, le système garantit que les informations sont distribuées via le chemin optimal pour chaque charge de travail spécifique. Ce processus transforme les entrées brutes en une intelligence gouvernée et exploitable, disponible au moment précis de la décision. Le principal enseignement de cette initiative est clair : lorsque la gestion des données, le serving et l'AI sont unifiés sur une seule plateforme, les insights se transforment en actions immédiates.

Vous voulez créer un projet similaire ? Explorez la documentation de Databricks Apps pour déployer votre propre application de données du début à la fin, découvrez comment Lakebase apporte un serving Postgres en quelques millisecondes au lakehouse, et apprenez comment Genie et Agent Bricks ajoutent une intelligence en langage naturel gouvernée à vos données, le tout sous un seul Unity Catalog.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original