Comment fonctionne EPG Doctor

Un guide de référence sur ce que fait ce système, ce que montre chaque onglet, comment les mécanismes clés fonctionnent, et où trouver chaque endpoint.

1. Vue d'ensemble

EPG Doctor lit un flux de programmation (EPG) — XML ou JSON, publié par un fournisseur de contenu — le normalise vers un format pivot commun, le diagnostique (titres manquants, horaires invalides, chevauchements...), puis conserve chaque relevé en base pour construire, dans le temps, une vraie vue analytique de la chaîne : tendances de programmation, taux de répétition, mix de catégories, charge publicitaire. Cette même donnée, une fois enrichie de tags IAB, est ensuite exposée à l'Ad Server via une API dédiée pour éclairer sa décision publicitaire.

Chaque étape est indépendante et consultable séparément — un check ponctuel n'exige pas d'avoir mémorisé la chaîne au préalable, et l'historique en base reste consultable même longtemps après le dernier check.

2. Les six onglets

3. Navigation et interface

Au-delà de 3 chaînes mémorisées, la grille horizontale de sélection laisse place à un bandeau latéral fixe (défilement sticky) — logo, nom, date de dernière analyse et date EPG maximale disponible pour chaque chaîne d'un coup d'œil. Une chaîne pas rafraîchie depuis plus de 24h est marquée d'une bordure orange à gauche ; la chaîne actuellement sélectionnée, d'une ligne or en bas. En dessous ou égal à 3 chaînes, la grille classique reste inchangée.

Le cartouche de chaîne (nom, fournisseur, lecteur vidéo) et la barre d'onglets restent visibles en sticky en haut de la page pendant le défilement d'un panneau long (Analyse notamment) — jamais besoin de remonter pour changer d'onglet ou vérifier quelle chaîne est affichée.

Sélecteur de langue (FR/EN) et bascule thème clair/sombre dans l'en-tête, appliqués immédiatement sans rechargement pour les parties déjà traduites de l'interface — ce chantier avance par tranches successives, certaines zones restent en français le temps d'être couvertes.

4. Comment un check fonctionne

Un check accepte trois familles de format, détectées automatiquement — pas besoin de préciser lequel :

• XMLTV générique — le format DTD standard, avec ses propres variations de terrain (identifiants multiples par balise selon la langue, icônes multiples, etc.), toutes gérées explicitement.
• XMLTV "Playout" — une variante distincte, reconnue à la présence de <subtitle> (sans tiret) plutôt que <sub-title>.
• OKAST JSON — le format natif de la plateforme de contenu.

Une fois normalisé vers un pivot commun, Doctor applique ses règles de qualité (titre manquant, horaire invalide, durée nulle, chevauchements) et calcule un rapport complet. Chaque programme de ce check est ensuite conservé en base — en ajout uniquement, jamais de mise à jour : un flux réanalysé plusieurs fois ne fusionne pas avec ses relevés précédents, ce qui rend possible de comparer deux relevés dans le temps pour détecter un vrai changement.

5. Comment l'ADN de la chaîne est calculé

Contrairement à un check ponctuel (une seule capture instantanée), l'ADN de la chaîne agrège l'historique conservé en base sur la fenêtre demandée. La bonne compréhension de ce mécanisme repose sur un point technique important : la base étant en ajout uniquement, un même programme réel peut avoir plusieurs lignes au fil des checks successifs — notamment quand son horaire est corrigé de quelques minutes entre deux relevés, ce qui arrive couramment sur un flux réel.

Pour ne jamais confondre une correction d'horaire avec un nouveau programme, chaque programme reçoit une identité persistante (un identifiant interne, tolérant à ce type de dérive) dès qu'il est vu pour la première fois. La lecture agrégée s'appuie sur cette identité en priorité — la version la plus récemment vérifiée de chaque programme, peu importe l'horaire exact où elle est tombée — avec un repli sur l'horaire exact pour les rares programmes dont l'identité n'a pas pu être résolue.

6. Mapping IAB : automatique, mots-clés, manuel

Chaque titre diffusé peut recevoir un ou plusieurs tags IAB (taxonomie IAB Content Taxonomy 3.1), utilisés par l'Ad Server pour contextualiser sa décision publicitaire. Trois mécanismes, dans l'ordre de priorité :

1. Mapping automatique par catégorie — la catégorie éditoriale du programme (déjà présente dans le flux source) est traduite vers un ou plusieurs codes IAB via une table de correspondance.
2. Règles mots-clés — utilisées uniquement quand un titre n'a aucune catégorie éditoriale exploitable : un mot-clé cherché dans le titre ou le sous-titre du programme (insensible à la casse) déclenche un mapping vers un code IAB donné. Gérables directement depuis l'onglet Analyse.
3. Ajustement manuel — un tag posé à la main sur un titre précis n'est jamais écrasé par un nouveau passage du mapping automatique.

L'onglet Analyse affiche un récapitulatif persistant (titres tagués, sans tag, catégories non mappées avec leur nombre de titres concernés) et un panneau de complétion manuelle pour traiter les titres restants directement, sans devoir les chercher un par un dans l'onglet Programmes.

7. Comment l'Ad Server consulte ces données

L'endpoint GET /v1/api/channels/context est le point de rencontre entre EPG Doctor et l'Ad Server — un snapshot des programmes, coupures publicitaires et tags IAB sur une fenêtre demandée, préchargé à l'avance par l'Ad Server, jamais appelé pendant une requête publicitaire en direct.

La réponse porte un ETag réel (calculé sur le contenu effectif — jamais sur l'heure de génération). Un appel suivant avec le même If-None-Match reçoit un 304 Not Modified si rien n'a changé — ce comportement est normal et attendu, pas une anomalie ; le journal d'audit (onglet API & MCP) permet de comparer directement les deux valeurs si un doute existe sur la fraîcheur d'une réponse.

L'authentification se fait par clé API dédiée (scope channels:read), gérée depuis l'onglet API & MCP — distincte des comptes internes utilisés pour se connecter à l'application elle-même.

Le journal d'audit lui-même (rétention 48h) se filtre par canal (REST/MCP), par statut (succès/erreur) et par recherche libre sur l'endpoint, avec une pagination par curseur — chaque page suivante repart du dernier horodatage affiché, jamais un simple décalage numérique qui pourrait sauter ou répéter des lignes sur une table alimentée en continu.

8. Référence des endpoints

9. Le système tourne-t-il ?

GET /admin/cron-log (clé maître) montre l'historique des rafraîchissements planifiés et du nettoyage de rétention. GET /admin/db-stats donne une vue d'ensemble de la base — volume, canaux distincts, bornes temporelles, couverture d'identité des programmes.

EPG Doctor — Europa Specials · Pour tout ce qui n'est pas couvert ici, contacte directement l'équipe technique.