--- title: "MagicPlaylist" description: "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." locale: "fr" canonical: "https://portfolio.josedacosta.info/fr/realisations/magicplaylist-android-music-discovery" source: "https://portfolio.josedacosta.info/fr/realisations/magicplaylist-android-music-discovery.md" html_source: "https://portfolio.josedacosta.info/fr/realisations/magicplaylist-android-music-discovery" author: "José DA COSTA" date: "2025" type: "achievement" slug: "magicplaylist-android-music-discovery" tags: ["Kotlin 2.0.21", "Android SDK 36", "Jetpack Compose", "Material Design 3", "Retrofit 2", "OkHttp 4", "Kotlin Coroutines", "Coil", "Spotify Auth SDK", "Gradle (Kotlin DSL)"] generated_at: "2026-04-23T15:44:05.052Z" --- # 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. **Date:** Septembre 2025 **Duration:** 2 jours (intensif) **Role:** Product Owner & Lead Developer **Technologies:** Kotlin 2.0.21, Android SDK 36, Jetpack Compose, Material Design 3, Retrofit 2, OkHttp 4, Kotlin Coroutines, Coil, Spotify Auth SDK, Gradle (Kotlin DSL) ### Key Metrics - Lignes Kotlin: **-** - Code Android natif - Fichiers Source: **-** - Fichiers source Kotlin - Composants UI: **-** - Composants Compose réutilisables - Stratégies de Mapping: **-** - Chaine de fallback Shazam-vers-Spotify ## Présentation du Projet _Ce qu'est MagicPlaylist et pourquoi il existe_ ### Target Users B2C - Grand public, utilisateurs Spotify souhaitant enrichir leurs playlists et decouvrir de nouveaux artistes via une expérience mobile intuitive. - **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. - 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) **Target Users:** Utilisateurs Cibles ## Objectifs, Contexte et Risques _La vision stratégique derriere le projet_ **Objectives Intro:** Le projet était guide par cinq objectifs mesurables : **Obj1 Label:** Stack Android Moderne **Obj1 Value:** SDK 36 **Obj1 Desc:** Jetpack Compose, Material 3, MVVM, Kotlin 2.0.21 **Obj2 Label:** Intégration API **Obj2 Value:** 2 APIs **Obj2 Desc:** Shazam (non-officiel) + Spotify (officiel) avec gestion d'erreurs **Obj3 Label:** Precision du Mapping **Obj3 Value:** 95%+ **Obj3 Desc:** Correspondance Shazam-vers-Spotify via 5 stratégies de fallback **Obj4 Label:** Échelle des Playlists **Obj4 Value:** 10K morceaux **Obj4 Desc:** Gerer de grandes playlists avec un budget max de 500 appels API **Obj5 Label:** Vitesse de Dev **Obj5 Value:** 2 jours **Obj5 Desc:** Livraison complète avec développement assisté par IA **Context Text:** 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é. **Stakes Text:** 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. **Risk1 Title:** Changements de l'API non-officielle Shazam **Risk1 Desc:** Probabilite elevee, impact critique. Aucun contrat d'API n'existe. Attenue par le spoofing de headers navigateur, mais intrinsequement fragile. **Risk2 Title:** Rate Limiting (Shazam + Spotify) **Risk2 Desc:** Probabilite elevee, impact moyen. Attenue par chunking progressif 3 niveaux, backoff exponentiel et patterns circuit breaker. **Risk3 Title:** Variabilite des Réponses Shazam **Risk3 Desc:** Probabilite moyenne. Certaines réponses Shazam ont des données incompletes. Attenue par gestion des champs manquants en fallback. **Risk4 Title:** Taux de Mapping < 95% **Risk4 Desc:** Probabilite moyenne. Attenue par 5 stratégies de fallback (ISRC, exact, fuzzy, correspondance par durée). **Risk5 Title:** Expiration des Tokens Spotify **Risk5 Desc:** Probabilite faible. Attenue par rafraichissement automatique et persistance des tokens. ## Phases de Réalisation _Un parcours chronologique du processus de développement_ **Phase1 Title:** Soclé Technique et UI de Base **Phase1 Period:** 8 sept. 2025 **Phase2 Title:** Intégration Shazam et Algorithme d'Expansion **Phase2 Period:** 8-9 sept. 2025 **Phase3 Title:** Intégration Spotify et Export **Phase3 Period:** 9 sept. 2025 **Phase4 Title:** Tests en Conditions Réelles et Documentation **Phase4 Period:** 9 sept. 2025 ## Équipe et Interactions _Le modèle de collaboration humain-IA_ - Le projet a été développé par **José 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 : José 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. **Team Size:** Taille de l'équipe : 1 personne + assistant IA **Jose Role:** José DA COSTA - Product Owner & QA **Ai Role:** Claude Code - Développeur Senior ## 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 ## 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. ## 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 - 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. **Improvement1 Title:** Pas de Depot Git **Improvement1 Desc:** Un .gitignore existe mais aucun depot n'a été initialise. Critique pour la traçabilité et la collaboration. **Improvement2 Title:** Pas de Tests Unitaires **Improvement2 Desc:** 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. **Improvement3 Title:** Pas de Persistance Locale **Improvement3 Desc:** 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. **Improvement4 Title:** Dépendance à une API Non-Officielle **Improvement4 Desc:** L'API non-officielle de Shazam est fragile. Aucun fallback vers des sources de recommandation alternatives n'est implemente. **Improvement5 Title:** Injection de Dépendances Manquante **Improvement5 Desc:** Hilt est dans le version catalog mais pas utilise. Les services sont vraisemblablement instancies manuellement.