Vibecoding : comment j'ai créé MyMediaPlayer pour l'Apple TV sans connaître Swift
En juin 2026, je n'avais jamais écrit une ligne de Swift. Quatre mois plus tard, MyMediaPlayer, mon lecteur audio pour Apple TV, est sur l'App Store, traduit en cinq langues. Je l'ai entièrement développé en « vibecoding », en dialoguant avec un agent d'IA. Voici mon retour d'expérience : ce qui marche, ce qu'il faut savoir avant de se lancer, et ce que l'IA ne fera pas à votre place.
Le point de départ : une app introuvable
Tout est parti d'un manque. Je voulais écouter ma bibliothèque musicale sur l'Apple TV, en Hi-Res : des albums en FLAC, en WAV et en DSD, certains en multicanal 5.1, rangés sur un NAS et sur un serveur Jellyfin (et Plex à l'occasion).
Sur l'App Store de l'Apple TV, aucune application ne réunissait l'ensemble : lecture réseau (UPnP, Samba, Jellyfin), fichiers Hi-Res et DSD, multicanal préservé et interface pensée pour la télécommande. Chacune faisait une partie du travail, aucune ne faisait tout.
Le multicanal a été la plus grosse déception. La plupart des apps de l'App Store Apple TV annoncent lire l'audio, la vidéo et le multicanal. En réalité, presque aucune ne lit un fichier audio multicanal seul, sans vidéo. Et quand elles y parviennent, les canaux ne sortent pas toujours dans le bon ordre, donc pas sur les bonnes enceintes.
Faute de trouver, j'ai décidé de la construire. Restait un détail : je ne connaissais rien à Swift.
Dix ans de C, zéro Swift
J'ai passé dix ans à développer en langage C. Pointeurs, gestion de la mémoire, compilation : je connais. Mais Swift, SwiftUI et la programmation objet m'étaient totalement étrangers.
En vibecoding, ce n'est pas un obstacle. J'ai travaillé avec Claude Code, l'agent de développement d'Anthropic, lancé directement dans le dossier du projet Xcode. Je décris le comportement voulu, l'agent écrit le code, je juge sur pièce, à l'écran de la télé ou dans le simulateur.
Le premier commit date de juin 2026. Quatre mois et près de 480 commits plus tard, la version 2.0 est sur l'App Store et les suivantes sont déjà en test. Mon expérience de développeur ne m'a pas servi à écrire du code. Elle m'a servi à tout le reste, et c'est le sujet de ce billet.
Des cycles courts, comme en agile
Ma pratique de l'agilité a été mon meilleur atout. J'ai l'habitude des cycles courts : une unité de travail petite, testable, validée avant de passer à la suivante. Le vibecoding fonctionne exactement ainsi.
Une demande à l'agent, c'est un changement visible et vérifiable. « Le mini-lecteur affiche le temps écoulé et le temps restant. » « Le focus reste sur la pochette après un appui long. » Je teste, je valide, je committe, puis je passe à la suite.
Comme pour un test unitaire, chaque étape a un critère de réussite clair. L'agent peut d'ailleurs vérifier une partie lui-même : il pilote le simulateur tvOS avec une télécommande virtuelle pour contrôler le déplacement du focus.
Il faut aller plus loin : demander à l'agent d'écrire des tests unitaires en même temps que le code. C'est la meilleure garantie de non-régression. En corrigeant un écran, un agent peut casser sans le voir une fonction ajoutée trois semaines plus tôt. Avec des tests relancés à chaque modification, la casse se voit tout de suite, avant le commit, et non dans les retours des testeurs.
À l'inverse, demander « refais l'écran d'accueil » d'un bloc mène au chaos. L'agent touche trop de choses à la fois, et on ne sait plus ce qui a cassé quoi. Découper finement, c'est garder la main.
Un socle technique minimum, indispensable
Le vibecoding ne dispense pas de comprendre. L'agent pose sans cesse des questions, et la qualité de l'app dépend directement de la qualité des réponses.
Quelques exemples tirés de MyMediaPlayer :
- API : Jellyfin et Plex exposent une API REST, UPnP passe par la découverte des appareils du réseau. Il faut savoir ce que sont une requête, une pagination, un jeton d'authentification.
- Cache et base de données : interroger le serveur à chaque ouverture, ou garder la bibliothèque en local ? Et quand la rafraîchir : à chaque lancement, toutes les heures, à la demande ?
- Optimisations : sur un gros serveur, tout charger d'un coup fige l'écran. Il a fallu paginer, afficher une progression, puis passer à une mise à jour incrémentale.
- Audio : AVPlayer pour les formats simples, AVAudioEngine pour le FLAC et le WAV multicanal. Sans comprendre la différence, impossible d'arbitrer.
L'agent propose souvent plusieurs options et demande laquelle retenir. Répondre « je ne sais pas, fais au mieux », c'est lui laisser des choix d'architecture qu'on paiera plus tard.
UX/UI : simple à l'écran, riche en dessous
L'agent sait produire une interface, mais il ne sait pas ce qui est agréable à utiliser avec une télécommande, assis dans son canapé. Des bases en UX/UI sont indispensables pour garder un écran simple tout en offrant beaucoup de fonctions.
Sur Apple TV, la grande difficulté s'appelle le focus. Ni souris ni écran tactile : la télécommande déplace une mise en évidence d'un élément à l'autre, et tvOS décide en partie où elle atterrit. Un élément mal placé, et le focus saute au mauvais endroit, reste bloqué ou se perd lors d'un balayage rapide.
Une bonne part des corrections de MyMediaPlayer porte sur ce point : garder le focus sur la pochette après un appui long, éviter qu'il passe par un menu au premier lancement, le stabiliser dans la grille en navigation rapide. L'agent peut vérifier certains parcours dans le simulateur, mais c'est à vous de décrire précisément où le focus doit aller, puis de juger sur l'Apple TV.
Dans MyMediaPlayer, les fonctions avancées se rangent derrière des gestes ou des menus discrets. Un appui long sur une pochette l'ajoute aux préférés, un autre réorganise les serveurs de l'accueil. Dans le lecteur plein écran, les réglages Affichage, Audio et Infos tiennent dans un bouton « … ».
La refonte de la version 2.0 est partie de maquettes, discutées écran par écran avant la moindre ligne de code. Ensuite, on itère : le mini-lecteur de la grille a connu une dizaine de variantes en une seule journée, jusqu'à trouver la bonne. Le coût d'un essai est si faible qu'on aurait tort de s'en priver.
Git, le filet de sécurité
Si je ne devais garder qu'un conseil, ce serait celui-ci : maîtrisez Git avant de vous lancer. Un agent peut modifier des dizaines de fichiers en une minute. Sans historique propre, une mauvaise piste devient vite un champ de ruines.
Ma règle : un commit par changement validé, avec un message clair. Près de 480 commits en quatre mois, ce sont autant de points de retour. Quand un essai ne convainc pas, on revient en arrière en une commande, sans regret.
Les branches permettent surtout de mener plusieurs chantiers de front. Au moment où j'écris :
- la 2.0 est sur l'App Store ;
- la 2.1, développée sur sa propre branche pour les grosses bibliothèques, a été fusionnée dans la branche principale ;
- la 2.2 avance sur une autre branche, et son deuxième build vient de partir en TestFlight.
Un bug remonté sur la version publiée se corrige ainsi sans embarquer le travail en cours. Les pistes expérimentales ont aussi leur branche, comme le décodage natif du DSD en 5.1 : si l'essai échoue, on l'abandonne, s'il réussit, on le fusionne.
Le chantier parallèle le plus large a été une seconde app. En plus du lecteur, j'ai développé MyMediaRemote, une télécommande sous iOS pour piloter MyMediaPlayer depuis l'iPhone, elle aussi entièrement en vibecoding. Elle dialogue avec un serveur intégré à l'app Apple TV depuis la version 1.2, et elle est aujourd'hui sur l'App Store.
L'agent manie Git très bien. Encore faut-il savoir quoi lui demander : quand committer, quand créer une branche, quand fusionner. Ces décisions restent les vôtres.
Un journal de projet, tenu à jour
Un agent d'IA repart presque de zéro à chaque nouvelle session. Le fichier de notes du projet devient donc sa mémoire, autant que la mienne.
Le mien, un simple fichier texte dans le dépôt, compte aujourd'hui 141 entrées datées. Chacune décrit ce qui a changé pour l'utilisateur, les problèmes rencontrés et la façon dont ils ont été résolus. En tête, une liste « Reste à faire » garde les chantiers ouverts. Les notes de version y ont aussi leur fichier, une par version, dans les cinq langues.
L'intérêt se voit sur les pièges. Un jour, l'étagère du Top Shelf restait vide sur mon Apple TV, alors que tout marchait dans le simulateur. La cause : sur l'appareil, une app tvOS ne peut écrire durablement que dans son dossier de caches, et le simulateur ne fait pas respecter cette règle. Une fois notée, l'erreur ne s'est jamais reproduite.
Je fais référence à ce journal tout au long du développement : « relis les notes avant de toucher au cache », « ajoute une entrée pour ce correctif ». C'est ce qui permet de tenir sur la durée.
Quelques testeurs et TestFlight
Le simulateur ne suffit pas, et mon salon non plus. Un petit groupe de testeurs, équipés de leur propre Apple TV, voit ce que je ne vois pas : d'autres serveurs, d'autres versions de Jellyfin ou de Plex, d'autres installations audio.
TestFlight rend la chose simple. Chaque build envoyé depuis Xcode apparaît dans App Store Connect, et les testeurs le reçoivent sur leur Apple TV. Pour les testeurs externes, Apple impose une rapide vérification du build avant la première diffusion.
Leurs retours alimentent directement le journal du projet et la branche en cours. C'est la boucle courte de l'agilité, étendue à de vrais utilisateurs.
La publication sur l'App Store, le plus déroutant
Paradoxalement, ce n'est pas le code qui m'a donné le plus de fil à retordre, mais la publication. Xcode et App Store Connect ont chacun leur logique, qu'il faut apprivoiser.
Côté Xcode : la signature, le numéro de version et le numéro de build, les archives à envoyer. Côté App Store Connect : la fiche de l'app, la politique de confidentialité, le questionnaire sur les données collectées, un site de support, les builds TestFlight, puis la soumission à la revue d'Apple.
Quelques leçons retenues :
- pour la première version, donner à Apple un moyen de tester l'app : un serveur accessible à distance et ses identifiants de connexion. Sans serveur, un lecteur réseau n'a rien à montrer à l'équipe de revue ;
- ne pas publier de captures d'écran où apparaissent des pochettes d'albums connus, protégées par le droit d'auteur : les miennes ne montrent que de faux albums ;
- une version approuvée est close : un nouveau build exige un nouveau numéro de version, pas seulement un nouveau numéro de build ;
- le texte promotionnel (170 caractères au plus) se modifie sans nouvelle version, contrairement à la description ;
- annoncer dans les notes une app compagnon pas encore disponible, ma télécommande iPhone MyMediaRemote, exposait à un refus : je l'ai tue jusqu'à sa sortie.
L'agent aide beaucoup ici aussi. Il rédige les notes de version et la politique de confidentialité, et explique les écrans d'App Store Connect. Mais c'est à vous de cliquer, et de comprendre ce que vous validez.
Captures d'écran et cinq langues
MyMediaPlayer est traduit en français, anglais, allemand, espagnol et italien. Chaque texte existe donc en cinq versions : l'interface, les notes de version, le texte promotionnel, la politique de confidentialité et les légendes des captures.
La traduction elle-même demande des choix. Les accroches vouvoient en français et en allemand, tutoient en espagnol et en italien, selon les usages de chaque langue.
Les captures ont été le plus gros morceau : 10 écrans par langue, soit 50 images pour la 2.0, chacune avec l'interface dans sa langue. Le contenu affiché vient d'un serveur Jellyfin de démonstration, rempli de faux albums. L'agent déroule ensuite le scénario dans le simulateur avec une télécommande virtuelle, puis un script compose les images avec leurs légendes.
Bien sûr, il a fallu régler des détails : des appuis trop rapides se perdent pendant un défilement, le focus tombe parfois au mauvais endroit. Mais la méthode est notée dans le journal du projet : la prochaine série ira bien plus vite.
En conclusion : l'IA code, vous pilotez
Quatre mois plus tard, je suis assez fier de moi. Non seulement j'ai réussi à faire l'app que je voulais, mais j'ai pu aller bien plus loin :
- un égaliseur graphique personnalisable jusqu'à 10 bandes, réglable bande par bande, avec préréglages ;
- des écrans de veille animés qui suivent la musique en temps réel, formes colorées et analyseur de spectre ;
- un disque qui tourne pendant la lecture, comme sur une platine ;
- la lecture jusqu'à 384 kHz / 24 bits, de la stéréo au 7.1.
Le vibecoding m'a permis tout cela dans un langage que je ne connaissais pas. Mais il ne remplace pas le métier : il le déplace. On écrit moins de code, on prend plus de décisions.
À qui veut se lancer, je conseillerais :
- découper le travail en petites unités testables, validées une à une, et faire écrire les tests unitaires en parallèle pour éviter les régressions ;
- garder assez de culture technique pour répondre aux questions de l'agent ;
- soigner l'UX, que l'agent ne jugera jamais à votre place ;
- maîtriser Git, branches et commits réguliers, pour pouvoir tout défaire ;
- tenir un journal du projet, mémoire commune entre vous et l'agent ;
- s'entourer de quelques testeurs via TestFlight ;
- prévoir du temps pour l'App Store, captures et traductions comprises.
MyMediaPlayer est disponible sur l'App Store de l'Apple TV, et sa télécommande MyMediaRemote sur celui de l'iPhone. Et la 2.2 est déjà entre les mains de mes testeurs.