Quand la donnée maîtresse entre en jeu - Un référentiel consolidé, illustré
Mis à jour :
06/2026 –
Objectif
Ce modèle propose un référentiel football consolidé à but didactique. Il illustre, sur un domaine concret et universel, les principaux mécanismes d’un projet MDM consolidé : collecte de données depuis des API publiques, normalisation en Python, contrôle qualité, dédoublonnage, et diffusion vers des applications consommatrices.
Ce n’est qu’un exemple : la structure et les techniques mises en œuvre se transposent directement à tout référentiel tiers (clients, fournisseurs, produits) dans un contexte réel.
Ce que le modèle démontre
- Collecte depuis des API publiques : les ligues, équipes et joueurs sont chargés depuis des sources ouvertes via le service 0 – tools > football_init_all. Le chargement est idempotent : rejouer le service ne crée pas de doublons.
- Normalisation en Python : les hooks de pré-intégration normalisent les noms, les dates et les valeurs avant toute règle qualité ou dédoublonnage.
- Redressement d’adresses mondial (asynchrone) : les adresses de stades sont géocodées via une API externe à bande passante limitée. Le traitement est asynchrone (SLA configurable) ; Phoenix gère la file d’attente et la réconciliation des résultats.
- Personnalisation d’écrans : les vues de saisie et de consultation sont adaptées par entité (disposition, visibilité des champs, ordres d’affichage).
- Dédoublonnage différencié par entité : seuils et algorithmes distincts selon que l’on rapproche des ligues, des équipes ou des joueurs.
Modèle de données
Le modèle s’articule autour de trois entités principales reliées entre elles :
- League : compétition ou championnat. Porte le pays d’appartenance, la saison courante, l’année de création et les médias (badge, logo).
- Team : club de football. Lié à une ligue, enrichi de l’adresse complète du stade (géocodée de façon asynchrone), des coordonnées GPS et des médias.
- Player : joueur. Lié à une équipe, portant l’identité (prénom, nom, date de naissance, nationalité), les caractéristiques physiques (taille, poids), la position, le côté préférentiel, la valeur de marché et la photo.
Une entité de jonction complète le modèle :
- TV Rights : droits de diffusion d’une ligue pour un pays et une chaîne TV donnés, avec période de validité (start/end year).
Cinq listes de valeurs centralisées garantissent la cohérence : Country, TV Channel, Position, Side, Gender.
Une entité technique Cache stocke les résultats intermédiaires des appels d’interfaces externes.
Règles qualité embarquées
Des contrôles opérationnels sont livrés sur les entités principales :
- Année de création / saison : format
/d{4}/imposé sur creation_year pour League et Team. - URLs : les champs website, badge, logo, photo et news RSS sont validés par une expression régulière HTTP/HTTPS.
- Champs obligatoires : name (League, Team), first_name + last_name + birthdate (Player), code (toutes les LOV).
- Date de naissance : préprocessée au format ISO (
toDate(yyyy-MM-dd)) avant validation. - Clé de dédoublonnage calculée : le champ calc_dup_key (Player) est construit automatiquement en combinant prénom, nom et date de naissance.
Règles de dédoublonnage
Chaque entité principale dispose de ses propres paramètres :
- League : rapprochement sur le nom — algorithme Levenshtein — coefficient 1. Seuil : 90 %.
- Team : rapprochement sur le nom — algorithme Levenshtein — coefficient 1. Seuil : 90 %.
- Player : rapprochement sur calc_dup_key (Levenshtein, coef 1) et birthdate (exact, coef 1). Seuil : 95 %. La condition de données désactive le dédoublonnage si la clé calculée est absente.
- TV Rights : rapprochement exact sur la paire (league, country) — coefficients 1 chacun. Seuil : 99 %.
- LOV : rapprochement exact sur le code — coefficient 1 — seuil 99 %.
Traçabilité
Toutes les modifications, pour toutes les sources, sont tracées nativement par défaut sur l’ensemble des entités (tracability: true).
Préalables techniques
- Version Phoenix minimale : 7.1.0.
- Importer le projet dans Phoenix.
- Créer et configurer le support de données football_db (schéma dédié sur une base supportée par la plateforme).
- Générer le projet, puis livrer sur l’environnement cible.
- Lancer le service 0 – tools > football_init_all pour initialiser (ou ré-initialiser de façon idempotente) le jeu de données depuis les API publiques. Ce service peut être planifié pour maintenir les données à jour : il ne supprime pas les données existantes et reste sans effet de bord en cas de relance.
- Planifier le service football_openstreetmap_batch (par exemple toutes les minutes) pour traiter la file de géocodage des adresses de stades. Ce service est indispensable pour afficher la carte des équipes : tant qu’il n’a pas été exécuté au moins une fois, les coordonnées GPS ne sont pas disponibles.
Pour quel projet ?
Ce référentiel est un point d’entrée idéal pour :
- Découvrir le MDM consolidé sans données sensibles, sur un périmètre ludique et universel.
- Explorer la normalisation Python dans les hooks de pré-intégration.
- Comprendre la gestion asynchrone d’API tierces à SLA (géocodage, enrichissement).
- Voir concrètement le dédoublonnage multi-entités avec des algorithmes différents selon la nature de la donnée.
- Servir de base à une formation ou à une démonstration client sur la plateforme Phoenix.
