MagicPlaylist
Une application Android native qui généré des playlists musicales à partir de morceaux de départ via les données de similarite Shazam, puis les exporté directement vers Spotify - construite avec Kotlin, Jetpack Compose et Material Design 3.
Lignes Kotlin
5,666
Code Android natif
Fichiers Source
46
Fichiers source Kotlin
Composants UI
22
Composants Compose réutilisables
Stratégies de Mapping
5
Chaine de fallback Shazam-vers-Spotify
Présentation du Projet
Ce qu'est MagicPlaylist et pourquoi il existe
MagicPlaylist est une application mobile Android native écrite en Kotlin qui généré automatiquement des playlists musicales à partir de morceaux choisis par l'utilisateur. L'application utilisé l'API non-officielle de Shazam pour decouvrir des morceaux similaires, puis exporté les playlists générées directement vers le compte Spotify de l'utilisateur.
Le concept est simple mais puissant : l'utilisateur saisit un ou plusieurs titrès de chansons qu'il aime, et l'application construit une playlist complète de morceaux similaires en explorant recursivement les relations de similarite musicale via Shazam, puis sauvegarde le résultat dans Spotify.
Ce projet a été réalisé dans le cadre du Mastere Expert en Ingenierie du Logiciel à l'ESIEA comme projet de formation. Il répond à un besoin réel des amateurs de musique : la difficulte de decouvrir de nouveaux morceaux correspondant à un style musical spécifique et de construire des playlists thematiques de qualité sans passer des heures a chercher manuellement.
B2C - Grand public, utilisateurs Spotify souhaitant enrichir leurs playlists et decouvrir de nouveaux artistes via une expérience mobile intuitive.
- Recherche de morceaux en temps réel avec auto-completion via l'API Shazam
- Sélection multi-seeds (1-50 morceaux) avec affichage des pochettes d'album
- Expansion BFS configurable : profondeur 1-3, jusqu'à 10 000 morceaux, déduplication
- Estimation predictive du nombre de morceaux et d'appels API avant génération
- Ecoûte de previews audio avec mode exclusif un seul morceau
- Export Spotify OAuth 2.0 avec chunking progressif a 3 niveaux
- Mapping Shazam-vers-Spotify a 5 stratégies (ISRC, exact, fuzzy Levenshtein)
Objectifs, Contexte et Risques
La vision stratégique derriere le projet
Le projet était guide par cinq objectifs mesurables :
Stack Android Moderne
SDK 36
Jetpack Compose, Material 3, MVVM, Kotlin 2.0.21
Intégration API
2 APIs
Shazam (non-officiel) + Spotify (officiel) avec gestion d'erreurs
Precision du Mapping
95%+
Correspondance Shazam-vers-Spotify via 5 stratégies de fallback
Échelle des Playlists
10K morceaux
Gerer de grandes playlists avec un budget max de 500 appels API
Vitesse de Dev
2 jours
Livraison complète avec développement assisté par IA
Ce projet a été réalisé dans le cadre du Mastere Expert en Ingenierie du Logiciel à l'ESIEA. Les choix technologiques étaient deliberement à la pointe : Kotlin 2.0.21, Compose BOM 2024.12, Android SDK 36 et AGP 8.13. Une décision architecturale clé a été d'utiliser directement l'API web non-officielle de Shazam plutôt qu'un wrapper payant (RapidAPI), apportant de la flexibilite mais aussi un risque de fragilité.
La proposition de valeur repose sur la qualité de la recommandation musicale - la pertinence des morceaux decouverts et la fiabilité du mapping Shazam-vers-Spotify. L'expérience utilisateur a été conçue avec des animations soignees, des designs en gradient, des confettis de celebration et un feedback de progression en temps réel pendant la génération.
Changements de l'API non-officielle Shazam
Probabilite elevee, impact critique. Aucun contrat d'API n'existe. Attenue par le spoofing de headers navigateur, mais intrinsequement fragile.
Rate Limiting (Shazam + Spotify)
Probabilite elevee, impact moyen. Attenue par chunking progressif 3 niveaux, backoff exponentiel et patterns circuit breaker.
Variabilite des Réponses Shazam
Probabilite moyenne. Certaines réponses Shazam ont des données incompletes. Attenue par gestion des champs manquants en fallback.
Taux de Mapping < 95%
Probabilite moyenne. Attenue par 5 stratégies de fallback (ISRC, exact, fuzzy, correspondance par durée).
Expiration des Tokens Spotify
Probabilite faible. Attenue par rafraichissement automatique et persistance des tokens.
Phases de Réalisation
Un parcours chronologique du processus de développement
- Mise en place du projet Android avec Gradle Kotlin DSL et SDK 36
- Architecture MVVM avec Jetpack Compose et StateFlow
- Theming Material 3 avec couleurs dynamiques
- Ecran d'accueil avec interface de recherche en temps réel
- Intégration de l'API Shazam non-officielle (recherche + similarite)
- Algorithme d'expansion BFS avec garde-fous mathematiques
- Moteur d'estimation predictive (morceaux attendus + budget API)
- Orchestration API asynchrone basée sur les coroutines
- Authentification OAuth 2.0 via Spotify Auth SDK 2.1.1
- Callback deep linking (magicplaylist://callback)
- Mapping Shazam-vers-Spotify a 5 stratégies (ISRC, exact, fuzzy Levenshtein)
- Chunking progressif 3 niveaux (20/10/1 morceaux par batch)
- Test scénario complet : 2 seeds -> 126 morceaux decouverts -> export Spotify
- 15 captures d'ecran documentant le parcours utilisateur complet
- 6 documents techniques (PRD, stratégie de mapping, chunking, expansion)
- Scripts de test beta en Python pour l'analyse des APIs
Équipe et Interactions
Le modèle de collaboration humain-IA
Taille de l'équipe : 1 personne + assistant IA
Le projet a été développé par Jose DA COSTA en tant que product owner, architecte fonctionnel, designer UI et responsable QA. Claude Code (Anthropic) a été utilisé intensivement comme assistant de pair-programming tout au long du développement.
Le modèle de collaboration suivait un cycle itératif : Jose spécifiait les exigences via ~80 prompts détaillés (71 Ko de CLAUDE_PROMPTS.md), validait les résultats sur l'emulateur, identifiait les bugs et orientait les corrections. Claude Code produisait l'implémentation, choisissait les patterns techniques, redigeait la documentation et corrigeait les problèmes signales.
- Vision produit et conception du parcours utilisateur complet
- Reverse-engineering de l'API Shazam (capture des commandes curl avec tous les headers)
- ~80 spécifications fonctionnelles détaillées via prompts structures
- Toutes les décisions UI/UX (degradees, couleurs, epaisseur des bordures, espacements)
- QA manuelle sur emulateur : identification de chaque bug (crashes, playlists vides, échecs d'auth)
- Standards non-negociables : anglais obligatoire, zero commentaire de code, Material 3, accèssibilité
- 100% des 5 666 lignes de Kotlin à travers 46 fichiers
- Implémentation de l'architecture MVVM avec StateFlow
- Les 6 documents techniques (PRD, stratégies, guidelines)
- Configuration Gradle Kotlin DSL et version catalog
- Résolution de bugs pour chaque problème signale
- Design de l'icone d'application (variantes SVG/XML note de musique)
Shazam (Apple)
Music data & similarity - Unofficial API
Spotify
Playlist destination - Official OAuth 2.0 API
ESIEA
Training institution - Master program context
Résultats et Impact
Résultats concrets pour le développeur et le projet
Développement Android natif avec le dernier stack Kotlin/Compose
Méthodologie de reverse-engineering d'API (consommation d'API non-officielle)
Workflow de développement assisté par IA : pair programming pilote par spécifications
Conception algorithmique avancée : exploration BFS avec contraintes mathematiques
Implémentation du flux OAuth 2.0 sur mobile avec deep linking
Patterns d'intégration API resilients : chunking, backoff, circuit breaker
Application Android fonctionnelle avec 12 fonctionnalités de la recherche à l'export Spotify
Scénario démontré : 2 seeds -> 126 morceaux decouverts -> 38 exportes vers Spotify
5 666 lignes de code Kotlin propre et bien structuré suivant MVVM
22 composants Compose UI réutilisables avec support d'accèssibilité
10 documents techniques couvrant architecture, stratégies et setup
15 captures d'ecran documentant le parcours utilisateur complet
2 seed tracks (Dennis Ferrer) - 126 tracks discovered - 38 exported to Spotify after retry
Les Lendemains du Projet
Ce qui s'est passe après la livraison
Le projet a été livré comme une application Android complète et fonctionnelle démontrant la découverte musicale et la génération de playlists de bout en bout. En tant que projet de formation dans le cadre du Mastere ESIEA, il a rempli son objectif principal : prouver la capacité à construire une application Android native de zero avec des technologies modernes.
L'absence de depot Git signifie qu'il n'y a pas d'historique de versions. L'application resté sur la machine de développement en tant qu'APK autonome. Aucun déploiement sur le Google Play Store n'a été prévu ni tente.
La dépendance à l'API non-officielle de Shazam représenté le plus gros risque à long terme. Tout changement dans la structure de l'API ou des headers casserait la fonctionnalité principale. Pour un scénario de production, une migration vers une API de recommandation musicale officielle (Spotify Recommendations, Last.fm) serait l'évolution naturelle.
Parcours associe
Experience professionnelle liee a cette realisation
Regard Critique
Une rétrospective honnete sur le projet
Produit fonctionnel de bout en bout démontré avec des captures d'ecran réelles
Stack technologique de pointe (Kotlin 2.0.21, SDK 36, Compose 2024.12)
Architecture MVVM propre avec séparation des responsabilites
Documentation technique riche depassant les standards habituels des projets de formation
Gestion avancée des erreurs : chunking 3 niveaux, mapping 5 stratégies, circuit breaker
Accèssibilité intégrée : composants dedies, cibles 48dp, contraste 4.5:1
Pas de Depot Git
Un .gitignore existe mais aucun depot n'a été initialise. Critique pour la traçabilité et la collaboration.
Pas de Tests Unitaires
Les dépendances de test sont presentes (JUnit, Espresso, Compose UI Test) mais zero fichier de test ecrit. L'algorithme BFS et le mapper meritent des tests approfondis.
Pas de Persistance Locale
Room est référence dans le version catalog mais pas active. Les playlists générées ne survivent pas à la fermeture de l'application.
Dépendance à une API Non-Officielle
L'API non-officielle de Shazam est fragile. Aucun fallback vers des sources de recommandation alternatives n'est implemente.
Injection de Dépendances Manquante
Hilt est dans le version catalog mais pas utilise. Les services sont vraisemblablement instancies manuellement.
L'IA accéléré mais ne remplace pas le jugement d'ingenieur : la décision de ne pas écrire de tests ou d'initialiser git resté la responsabilite du développeur.
La documentation en amont (PRD, documents de stratégie) a visiblement guide un développement cohérent et structure.
Le rate limiting doit être un souci architectural des le premier jour quand on depend d'APIs tierces, pas une correction après coup.
Competences mobilisees
Competences techniques et humaines appliquees
Competences techniques
Galerie d'images
Captures et visuels du projet