HOP est un visualiseur de connexions musicales pour Scylfe en collaboration avec RTMKR. Son principe : prendre les featurings entre artistes — ces collaborations où deux univers se rencontrent le temps d’un titre — et en faire une carte interactive, explorable, vivante. Derrière une interface volontairement épurée se cache une architecture technique pensée pour la simplicité, la rapidité et l’évolutivité.
L’idée centrale de HOP est que chaque featuring crée un lien mesurable entre deux artistes. Ces liens, agrégés sur l’ensemble d’une discographie, forment un réseau. Et ce réseau, visualisé sous forme de graphe, révèle des structures invisibles à l’oreille : les pivots entre scènes, les artistes-ponts, les clusters stylistiques.
HOP propose trois modes d’exploration de ce réseau. L’Explorer affiche le graphe interactif d’un artiste et de ses collaborateurs. La Chaîne enchaîne automatiquement les featurings les uns après les autres, comme un zapping guidé par les connexions réelles. L’Index permet une navigation alphabétique vers n’importe quel artiste de la base.
La première question structurante était le stockage. Une base de données relationnelle (MySQL, PostgreSQL) aurait été le choix naturel pour gérer des relations entre entités. Nous avons délibérément écarté cette option pour trois raisons.
Un projet flat file se déploie en copiant des fichiers. Pas de serveur de base de données à configurer, pas de migrations à gérer, pas de credentials à sécuriser. Le projet entier — données comprises — tient dans un dossier. C’est un avantage concret pour la maintenance, les sauvegardes et les migrations d’hébergement.
Des données qui changent peu et souvent en lot
Les featurings ne se mettent pas à jour en temps réel. La base de HOP évolue par ajouts ponctuels — nouveaux artistes, nouvelles collaborations — et non par modifications continues. Ce pattern d’écriture en lot (batch) est exactement celui pour lequel le flat file excelle : on met à jour les CSV, on régénère le cache, et c’est tout.
Plutôt que d’interroger une base à chaque requête, HOP compile l’intégralité des données en un seul fichier JSON au moment de la mise à jour. Les lectures sont ensuite de simples accès fichier — quasi instantanés, sans connexion réseau interne, sans requête SQL à parser.
HOP : de la donnée brute au graphe interactif
- Les CSV comme source de vérité
Chaque fichier CSV contient des lignes au format : artiste, partenaire, titre, album, lien, détails. Un artiste peut apparaître dans plusieurs fichiers. La structure est intentionnellement simple pour faciliter la contribution et la mise à jour manuelle ou scriptée. - La compilation vers cache.json
À chaque modification d’un CSV, le moteur de cache recompile l’intégralité des données. La logique est symétrique : si A a collaboré avec B, alors B apparaît aussi dans les connexions de A. Cette symétrie est calculée à la compilation, pas à la lecture, ce qui évite toute redondance dans les CSV sources.
Le cache est invalidé intelligemment : une comparaison des timestamps entre les CSV et le fichier cache.json détermine si une recompilation est nécessaire. Si le cache est plus récent que tous les CSV, il est servi directement. - L’API locale
Le fichier cache.json est exposé via un endpoint PHP minimal qui supporte deux actions : la liste de tous les artistes, et les connexions d’un artiste donné. Les pages PHP qui tournent côté serveur lisent directement le cache sur le disque — sans aller-retour HTTP. Seul le navigateur passe par l’API pour les expansions dynamiques du graphe.
Le visualiseur : un graphe force-directed sur canvas HTML5
L’Explorer est le composant le plus complexe de HOP. Il repose sur un graphe force-directed dessiné sur un élément canvas HTML5, sans librairie externe de visualisation. Tout — physique, rendu, interactions — est écrit en JavaScript natif.
- La simulation physique : Chaque nœud est soumis à trois forces : une répulsion entre tous les nœuds (pour éviter les superpositions), une attraction le long des arêtes (pour regrouper les collaborateurs proches), et une légère attraction vers le centre (pour garder le graphe lisible). Ces forces sont calculées à chaque frame pendant les 400 premières itérations, puis le graphe se stabilise.
- Le rendu adaptatif : La taille de chaque nœud est proportionnelle à son degré — le nombre de connexions. La couleur va du gris clair (peu de featurings) au noir (beaucoup). Le nœud central est toujours noir et légèrement plus grand. Cette échelle visuelle permet de repérer instantanément les artistes-pivots dans le réseau.
- Le tracé du parcours utilisateur : Chaque nœud cliqué est ajouté à un chemin de navigation. Ce chemin est tracé par-dessus le graphe : en vert olive si une connexion réelle existe entre deux étapes consécutives, en bordeaux si l’utilisateur a sauté vers un artiste sans lien direct. Une façon immédiate de distinguer les traversées cohérentes des explorations libres.
- L’expansion progressive : Le graphe ne charge pas tout d’un coup. Il démarre avec les connexions de l’artiste central, puis s’étend à la demande : cliquer sur un nœud déclenche le fetch de ses propres connexions, qui sont intégrées dynamiquement au graphe existant. Les nouvelles positions sont initialisées autour du nœud parent et se stabilisent par la simulation physique.
La Chaîne : une expérience passive pilotée par les données
La Chaîne est le mode le plus simple de HOP, mais pas le moins intéressant. Elle tire un artiste éligible (ayant au moins trois partenaires distincts), choisit un featuring aléatoire parmi ceux non encore joués dans la session, affiche le titre et passe à l’artiste suivant après un délai configurable.
La session est gérée côté serveur via les sessions PHP. La page se recharge automatiquement via une balise meta refresh — un choix délibérément simple, sans WebSocket ni polling JavaScript. Le serveur est sans état entre les recharges : tout le contexte est dans la session.
La chaîne se termine quand tous les featurings disponibles pour l’artiste courant ont déjà été joués, ou quand elle boucle sur l’artiste de départ. Une nouvelle chaîne repart alors depuis un artiste aléatoire.
HOP est conçu pour être générique. La structure de données — artiste, partenaire, titre, album, lien — ne présuppose aucun genre musical. Ajouter une nouvelle scène revient à déposer de nouveaux CSV dans le dossier source et régénérer le cache. Pas de migration, pas de schéma à modifier.
L’objectif est d’étendre progressivement la base à d’autres genres et d’autres langues, tout en conservant la même interface et la même philosophie : pas d’algorithme, pas de recommandation opaque — juste les connexions réelles, rendues visibles.
