SportEquipement - Application de suivi de matériel sportif avec Vibe Coding

Bonjour à tous,

Pour ceux qui me connaissent, vous savez que je fais un peu de vélo. Et comme tout cycliste moderne, j'utilise Strava. C'est l'outil de référence pour suivre ses sorties, comparer ses segments et analyser sa forme. Strava propose bien une fonctionnalité de "Suivi d'équipement" (pour savoir combien de kilomètres ont vos chaussures ou votre cadre), mais... c'est sommaire.

Si la version Web permet d'ajouter des composants (chaîne, cassette, etc.), l'application mobile a tout simplement "oublié" cette fonctionnalité.

J'ai eu quelques problèmes avec ma chaîne qui s'use en 2 000 km ou des plaquettes de frein à changer. Bref j'avais envie d'avoir des stats un peu précises sur le suivi de mon matériel. De la même manière je cours régulièrement et je voulais savoir quand mes baskets atteignaient leur durée de vie maximale (ça, ça marche bien sur Strava).

Pour améliorer ce suivi j'ai décidé de créer ma propre solution : SportEquipement.

SportEquipement : C'est quoi ?

L'idée est simple : une application mobile, connectée à Strava et à Android Health Connect, qui récupère mes activités et incrémente l'usure de chaque composant défini.

Pour la première version, je voulais aussi qu'elle soit "Local First". L'application tourne entièrement sur le téléphone. Pas de serveur, application open source, et mes données restent chez moi. (Bon, j'ajouterai peut-être dans un futur un serveur pour synchroniser mes différents appareils et sécuriser les tokens Strava, mais chaque chose en son temps).

L'application est d'ailleurs disponible sur le Play Store et le code source est sur mon Gitea perso.

Quelques écrans

Cet écran montre la liste des équipements qui ont été ajoutés. On peut voir l'état d'usure de chaque équipement et si l'équipement est usé ou un de ces composants est usé on a une alerte visuelle.

Sur l'écran détail d'un équipement, on y voit les informations détaillées de l'équipement mais aussi la liste des composants et l'usure des composants.

Un composant peut être usé par le kilométrage (ex: chaîne, pneu) ou par le temps (ex: liquide de frein).

Sur l'écran d'activité on récupère la liste des activités synchronisées depuis Strava ou Health Connect (pour l'instant une fois par jour). On peut créer des activités manuellement aussi si besoin. C'est l'ajout ou la suppression d'une activité qui impacte l'usure des équipements.

Les activités sont rattachées aux équipements via des types d'activités (l'équipement est attaché à un type d'activité, et l'activité aussi).

Mais si je vous écris aujourd'hui, ce n'est pas seulement pour vous présenter l'outil. C'est surtout pour vous raconter comment je l'ai développé. J'ai voulu tester le fameux "Vibe Coding".

Développement en Vibe Coding

Je souhaitais développer mon application rapidement. Je voulais également avoir ce que les agents IA avaient dans leurs neurones. En effet, j'ai une licence Github Copilot que j'utilisais principalement en mode auto-completion de code, un peu pour discuter, et parfois pour modifier du code sur un projet déjà existant. J'ai déjà "Vibe Codé" des scripts sans impact dont le but était de faire des exécutions one-shot.

Sur ce projet, je me suis dit :

Je ne suis plus développeur, je suis le chef de projet et le product owner. Je décris la fonctionnalité que je veux, et l'IA code pour moi. Je teste et si ça ne compile pas ou si ça ne marche pas comme je veux je fais un retour au developpeur à l'IA.

A la fin je regarderai le code généré et je verrai ce que l'IA vaut.

J'ai donc commencé à mettre différents types d'instructions :

• Expert en Kotlin et développement Android
• Agent expert en UI/UX
• Expert en documentation technique

Ces différents experts sont inspirés de prompts trouvés sur Internet et adaptés, modifiés et/ou générés à l'aide de Github Copilot également.

Ensuite j'ai décrit mon projet en quelques lignes dans le prompt. Je lui ai demandé de me faire un plan, puis de le développer.

Les deux premières semaines ont été grisantes. J'ai développé 80% du logiciel en un temps record. Je regardais l'IA coder, je cliquais sur le bouton continuer ou approuver (les outils MCP, le build, ...) et je jouais aux jeux vidéo pendant ce temps.

Pour info les MCP c'est "Model Context Protocol", cela permet à Github Copilot d'accéder à des outils comme l'execution des commandes, la recherche sur internet, ...

Ma routine était simple : je demandais une fonctionnalité, l'IA générait le code, je compilais (pendant ce temps je faisais autre chose : jeux vidéos, un autre programme ...). Une fois terminé, je lançais android studio, je compilais, je testais.

Si ça marchait, je passais à la fonctionnalité suivante. Si ça ne marchait pas, je donnais un retour à l'IA en lui expliquant le problème (erreur de compilation, bug, comportement non conforme) et c'était reparti pour un tour.

Régulièrement je devais réinitialiser la conversation, je demandais donc à l'IA de mettre à jour le plan pour reprendre dans une nouvelle conversation. Généralement, je faisais cela quand l'IA commençait à faire n'importe quoi (oubli de ce sur quoi on travaillait initialement, pataugeait dans la semoule, ...). Les prémisses du pétage de plombs de l'IA passaient souvent par un passage du français à l'anglais dans les réponses. La signification était probablement la perte du contexte initial et des instructions de démarrage.

Au début, Copilot m'a pondu une architecture logicielle complexe, découpée en couches bien distinctes. Sur le papier, c'était beau (ça vient des instructions expert en développement kotlin qui demande une Clean architecture avec une séparation : Domain, Data, Feature, Core).

De mon coté, pour un projet perso, si j'avais dû développer le projet moi-même de zéro, j'aurais probablement fait beaucoup plus simple et direct. Probablement une application avec des vues, une couche service et une couche DAO dans le même projet. Mais là, c'était l'IA qui gérait l'architecture, donc je laissais faire. J'avançais à l'aveugle.

Et là, c'est le drame

Au bout de deux semaines, patatras. Je reçois une notification : je n'ai plus de crédits GitHub Copilot pour les requêtes premium. Panne sèche.

J'ai bien tenté de reprendre avec un GPT4.1 ou GPT4o qui sont inclus en illimité, mais quand on a testé Gemini 3 ou Claude Sonnet 4.... qu'est que GPT4 est con....

Je me retrouve seul face à mon IDE, sans l'aide de copilot. J'étais le 15 du mois et il me restait 2 semaines avant le renouvellement. Je me suis dit :

Bon, c'est l'occasion de regarder un peu ce qu'il m'a écrit en détail et de faire une revue de code.

J'ai ouvert les fichiers. Et là... j'ai eu du sang qui m'a coulé des yeux, la cervelle qui m'est sortie par les oreilles ...

Le MCD (Modèle Conceptuel de Données) était inutilement complexe. Il y avait de la duplication de code partout. Pour faire la même chose, l'IA avait parfois utilisé trois méthodes différentes à trois endroits du code, sans aucune cohérence globale. Il y avait du code mort, des variables inutilisées, des détours techniques incompréhensibles.

C'était fonctionnel, oui. Mais c'était sale. Très sale.

J'ai donc commencé à lister tous les problèmes architecturaux que j'ai vus dans le code (et attention il y en a probablement d'autres). La suppression du code mort, je l'ai faite moi-même car à chaque fois l'IA n'était pas capable de le détecter si je ne lui donne pas le nom de la méthode.

Le grand nettoyage

Dès que mes crédits ont été renouvelés, j'ai voulu tout nettoyer et donner à l'IA l'ensemble de ma revue de code. Optimiste, j'ai donné le grand listing de tout ce qui n'allait pas et de demander à l'IA une correction globale.

Échec total. C'était trop pour elle. Elle se perdait dans les corrections, me disait que tout était fait, mais seule une partie était terminée....

J'ai dû changer de stratégie. J'ai repris mon "Vibe Coding", mais cette fois-ci pour réparer les dégâts, problème par problème, couche par couche (domaine, puis data, puis feature, puis core).

Puis je suis repassé en mode petite itération pour terminer les dernières fonctionnalités, corriger les derniers bugs. Et j'ai parfois dû mettre les mains dans le cambouis moi-même pour corriger des problèmes que l'IA n'arrivait pas à résoudre.

Résultat des courses : j'avais fait 80% du projet (le prototype sale) en 2 semaines. Il m'a fallu un mois entier pour faire les 20% restants et nettoyer la base de code pour la rendre un peu plus propre.

Conclusion

Aujourd'hui, l'application est sur le store Google, elle fonctionne bien, et elle répond à mon besoin initial.

Mais je ressors de cette expérience avec un sentiment mitigé. J'ai un étrange détachement vis-à-vis de ce projet.

J'ai l'impression d'avoir codé avec un stagiaire qui a de très bonnes connaissances théoriques sur l'architecture logicielle mais qui sans contrôle te crée une dette technique immense. Par contre il a l'avantage d'écrire très vite. Ce projet qui a été fait en un mois - un mois et demi, m'aurait pris beaucoup plus de temps (sachant que je ne développe en perso que le soir et le week-end).

D'habitude, quand je code un logiciel, c'est mon "bébé". Je connais chaque ligne, chaque astuce, chaque défaut. Là... j'ai l'impression que ce n'est pas mon projet. Je me sens comme le Chef de Projet ou le client qui a passé commande.

Pour les petits scripts, les projets utilitaires, l'intelligence artificielle est super pratique. Elle permet de construire rapidement un prototype fonctionnel. Mais sans maîtrise, le code n'est pas maintenable dans le temps (même par l'IA elle-même). Et je ne parle pas non plus des problématiques de sécurité, si j'avais un serveur sur cette application.

Pour les projets de passionnés, ceux qu'on fait "pour l'art" ou pour le plaisir d'apprendre, je ne suis pas sûr de réitérer l'expérience aussi poussée. J'aime développer et c'est important pour moi de toucher la ligne de code.

J'ai aussi une autre inquiétude par rapport à l'avenir du métier de développeur. Un bon développeur pour l'instant est toujours nécessaire pour superviser l'intelligence artificielle.

Mais les juniors qui arrivent sur le marché du travail vont-ils apprendre les bonnes pratiques de développement s'ils se reposent trop sur l'IA pour coder à leur place ? Est-ce que les juniors vont trouver du travail, même s'ils sont compétents ?

Actuellement un développeur qui n'utilise pas l'IA risque de se retrouver à un moment dépassé sur le marché du travail. Ce que j'aimais avec le développement c'est qu'avant n'importe qui pouvait faire du développement avec n'importe quel PC. Il y avait un coût d'apprentissage, tout le monde n'est pas fait pour faire du développement, mais c'était accessible financièrement aux personnes motivées.

Maintenant, il faut soit une très grosse carte graphique (et même là ce ne sont pas des modèles ultra performants), ou un abonnement payant. Il y a quelques versions gratuites mais elles sont là pour attirer. L'IA rend le développement plus accessible au niveau apprentissage, mais moins accessible financièrement et surtout dépendant d'un fournisseur.