Application desktop Tauri, Angular et Python qui corrige les tags d'une bibliothèque musicale de DJ à partir de Beatport et Bandcamp. Elle est distribuée à une dizaine de DJs. L'utilisateur tranche les cas ambigus, aucun fichier n'est modifié avant sa confirmation et tout reste restaurable. En production.
Personnel
Équipe
1 personne
Mode
Remote
Durée
2 mois
Contexte
Techno Tagger corrige les tags d'une bibliothèque musicale de DJ. L'application extrait les morceaux d'une playlist, puis réécrit leurs métadonnées, pochette comprise. Les données viennent de Beatport et Bandcamp, les plateformes de référence de la musique électronique. SoundCloud sert au rattrapage manuel. Les trois sources passent par mon API Techno Scraper.
Elle règle les défauts les plus fréquents : pochettes absentes, mentions parasites dans les titres, conventions qui changent d'une source à l'autre.
Elle remplace une CLI Python que j'étais seul à pouvoir utiliser. Il fallait éditer du code avant chaque usage. Elle n'avait qu'une source (Beatport), ne traitait que le MP3 et ne pouvait pas être partagée.
Objectif : permettre à des amis DJ d'installer et d'utiliser l'outil sans jamais ouvrir un terminal.
Mon rôle : conception, développement et distribution, seul.
Réalisations marquantes
Distribuer l'app à une dizaine de DJs qui ne sont pas développeurs
Les utilisateurs ne sont pas développeurs et n'ont aucun environnement de développement sur leur machine.
Solutions :
Un installeur Windows est publié automatiquement à chaque release.
Une mise à jour signée est proposée au lancement et s'installe en un clic.
Au démarrage, l'app vérifie que son interface et son moteur sont à la même version. En cas d'écart, elle affiche un écran qui explique quoi faire plutôt qu'une interface vide.
Antivirus : une application non signée les déclenche facilement. L'installeur passe sans aucune alerte. Windows Defender signalait le moteur à tort : je l'ai déclaré à Microsoft, qui a retiré la détection.
Ne jamais corrompre une bibliothèque musicale
Réécrire les tags et renommer des centaines de fichiers, c'est le point de non-retour du run. Un crash en plein milieu ne doit pas laisser une bibliothèque à moitié renommée. Une source qui fournit peu d'informations ne doit pas non plus effacer ce que le fichier contenait déjà.
Solutions :
Aucun fichier n'est touché avant la confirmation de l'utilisateur.
Avant la première écriture, les tags d'origine sont sauvegardés et chaque renommage est noté. Un morceau ou un run entier se restaure en un clic pendant 30 jours.
Un champ que la source ne fournit pas ne modifie jamais le tag existant.
Un run interrompu reprend là où il s'était arrêté, sans refaire les recherches déjà faites.
Détail d'un morceau avant et après le tagging, champ par champ
Laisser l'utilisateur trancher sans bloquer le run
Quand le bon candidat n'est pas certain, c'est l'utilisateur qui choisit parmi une liste de correspondances plausibles. L'ancienne CLI demandait une confirmation au clavier, morceau par morceau, sans montrer les candidats côte à côte.
Solutions :
Une modale affiche les candidats avec leur score, pendant que les recherches continuent en arrière-plan. L'utilisateur arbitre au fil de l'eau ou garde tout pour la fin.
Quand Beatport ne propose que des candidats incertains, Bandcamp n'est interrogé que si l'utilisateur les refuse, dans la même fenêtre. On évite ainsi de doubler les appels pour rien.
Si rien ne convient, l'utilisateur colle l'URL de la bonne fiche Beatport, Bandcamp ou SoundCloud.
Modale d'arbitrage entre deux candidats Beatport ambigus
Ne valider automatiquement que les correspondances sûres
Une correspondance validée à tort écrit des tags faux sans que rien ne le signale. Les cas piégeux sont connus :
un nom de fichier réduit à des mentions parasites ;
un remix confondu avec la version originale ;
plusieurs versions d'un même titre.
Solutions :
Si le nettoyage ne laisse rien d'exploitable, aucune recherche n'est lancée : le morceau passe directement au rattrapage.
Les mentions de version et de collaboration (remix, featuring) sont conservées pendant le nettoyage.
Au moindre écart de version entre la recherche et le candidat, par exemple « Pt. 1 » contre « Pt. 2 », la validation automatique est bloquée et le choix revient à l'utilisateur.
Une app desktop sans serveur, avec le métier en Python
Je voulais garder le métier en Python, dont les bibliothèques audio sont les plus abouties. Il ne fallait ni le réécrire en Rust, ni embarquer un navigateur entier comme le ferait Electron.
Solutions :
Tauri fournit la fenêtre, Angular l'interface et un moteur Python lancé à côté porte tout le métier.
Les deux échangent par un protocole de messages, testable sans lancer l'interface. Presque rien n'est écrit en Rust.
Un mode de packaging choisi sur mesure fait démarrer le moteur en 335 ms au lieu de 2,3 s.
Centraliser le nettoyage des titres dans la gateway
Au début, l'app nettoyait elle-même les titres renvoyés par l'API. D'autres de mes projets faisaient le même travail, chacun à sa façon, sans voir les champs structurés des sources.
Solutions : j'ai déplacé le nettoyage dans la gateway, la seule à voir ces champs. L'app compare les candidats tels qu'ils arrivent et son code de matching s'est allégé.
Remonter les erreurs sans données personnelles
Un chemin de fichier contient le nom d'utilisateur Windows. Un nom de fichier contient l'artiste et le titre. Envoyer les crashs tels quels, c'était exposer la bibliothèque des utilisateurs à un service tiers.
Solutions :
La remontée d'erreurs ne garde que les crashs techniques.
Les chemins et les messages sont masqués, et les données restent hébergées en région EU.
Un test vérifie le contenu réellement envoyé.
Pour améliorer le matching, l'utilisateur partage un rapport par un geste explicite, après l'avoir relu.
Résultats
Une dizaine de DJs de mon entourage utilisent l'app, installée et mise à jour automatiquement
Huit semaines entre le premier commit et la version 1.0
Quatre formats pris en charge (MP3, WAV, AIFF et FLAC) contre le seul MP3 auparavant
Deux sources enchaînées automatiquement (Beatport puis Bandcamp) au lieu d'une seule
Aucun fichier modifié avant confirmation : tout reste restaurable pendant 30 jours
Moteur démarré en 335 ms au lieu de 2,3 s
Plus de 2 200 tests, typage strict et lint bloquants en CI
Coût nul : services gratuits et une API hébergée sur un VPS déjà en place
Apprentissages
Livrer une première application desktop de bout en bout : Tauri, packaging Windows, mise à jour signée
Nettoyer la donnée là où l'information existe, plutôt que dans chaque application qui la consomme
Enregistrer une décision avant d'agir : un crash devient inoffensif et la reprise devient triviale
Ce qui casse en distribution ne se voit pas en développement : il faut tester sur l'application installée, chez quelqu'un d'autre
Mieux vaut demander à l'utilisateur que valider en silence un résultat douteux : un plantage se voit, des tags faux passent inaperçus
Passer d'un design system et d'une maquette à une interface fidèle
Évolutions prévues
Compatibilité étendue avec Rekordbox (WAV, remixeur, date de sortie complète)
Édition manuelle des tags quand aucune source ne convient
Un agent IA en renfort du matching, désactivé par défaut, pour trancher les cas ambigus