"Comment j'ai vibe-codé une application de transport en deux heures"
L'IA va-t-elle remplacer les développeurs ? Si la question n'est pas encore tranchée, les nombreux outils de vibe-coding font déjà gagner de nombreuses heures aux développeurs. Un concept nécessitant auparavant plusieurs jours de développement ne prend maintenant que quelques heures (voire quelques minutes pour les plus simples). Pour expérimenter les possibilités de l'IA, nous avons tenté de développer un système complet de monitoring visuel et d'alerting en cas d'anomalie sur la ligne P du Transilien (oui, c'est celle qui nous ramène chez nous). Le but ? Avoir un système visuel plus simple d'usage que les applications de transport habituelles (IDF Mobilité, Bonjour RATP) tout en ayant un système d'alerting personnalisé.
1. Le choix de l'IDE idéal
Pour nous lancer, nous avons choisi d'utiliser Cursor car l'IDE propose le meilleur modèle de software engineering du moment : Claude 4. Windsurf (désormais propriété d'OpenAI) ne propose pas le modèle dans ses abonnements (l'entreprise explique qu'Anthropic lui refuse l'accès).
2. Une première base de code avec Claude 4
Mais avant de lancer Cursor, nous avons fait générer à Claude 4 Opus via le chatbot d'Anthropic une première version de l'interface sans la partie backend. Le but étant d'avoir une base de code pour avancer ensuite dans Cursor. Nous avons uploadé le code sur un serveur distant (Serveur dédié Kimsufi chez OVH) pour pouvoir visualiser les futures modifications en direct dans le navigateur web.
Nous utilisons le prompt suivant avec Claude 4 :
Créez le code source complet et fonctionnel d'une interface web responsive pour un tableau d'affichage numérique des trains en temps réel, spécifiquement configuré pour présenter les départs de la ligne P du RER entre les gares d'Esbly et de Paris Gare de l'Est, en utilisant les technologies HTML5, CSS3 et JavaScript moderne pour garantir une compatibilité maximale et des performances optimales sur tous les appareils. L'interface doit afficher de manière claire et hiérarchisée les informations essentielles suivantes pour chaque train : l'heure de départ prévue, la destination finale, le numéro du train, le quai d'embarquement, ainsi que le statut en temps réel avec un système de codage couleur précis utilisant le vert (#28a745) pour les trains à l'heure, l'orange (#ffc107) pour les trains retardés avec indication du retard en minutes, et le rouge (#dc3545) pour les trains supprimés ou annulés. Le design doit respecter une esthétique épurée et moderne avec des cartes individuelles blanches (#ffffff) présentant des ombres portées subtiles pour créer de la profondeur, disposées sur un fond gris clair (#f8f9fa), organisées dans une grille responsive adaptative qui affiche deux colonnes sur les écrans de bureau et tablettes (min-width: 768px) et une colonne unique sur les appareils mobiles, avec des transitions fluides entre les breakpoints et une typographie lisible utilisant une police sans-serif système pour optimiser la lisibilité à distance. L'interface doit inclure un en-tête fixe affichant le nom de la ligne, l'heure actuelle mise à jour en temps réel, un indicateur de dernière mise à jour des données tout en intégrant des données d'exemple réalistes pour démontrer les différents états possibles et en prévoyant une structure modulaire permettant une extension future vers d'autres lignes de transport.
Nous avons ensuite retravaillé l'interface petit à petit avec Cursor et son assistant en mode "Agent". Ce mode permet au modèle d'agir en autonomie en modifiant le code, en ajoutant des fichiers et même en exécutant des commandes bash. L'agent a, par exemple, installé les dépendances manquantes en utilisant les commandes d'installation système UNIX (apt-get install). Il faut en revanche renseigner son mot de passe pour les commandes sudo (équivalent administrateur Unix).
3. Utilisation des LLM les plus performants et à moindre coût
Pour la partie backend (cœur du fonctionnement de l'application), nous avons utilisé l'API PRIM d'Ile-de-France Mobilités. Cette dernière fournit via différentes API toutes les données nécessaires au fonctionnement de l'application. Pour travailler la structure et le fonctionnement du code, nous avons préféré désactiver la sélection automatique du modèle par Cursor pour utiliser des modèles plus efficaces ou moins chers. Ainsi, pour les tâches complexes de génération de nouvelles fonctionnalités ou pour la partie backend du système, nous avons utilisé Claude 4 Sonnet Thinking (raisonnement). Le modèle d'Anthropic est parfait pour le software engineering et était alors en promotion (une requête étant égale à 0,8 crédit).
Pour la partie édition de code simple nous avons utilisé Claude 4 Sonnet en version classique sans le mode thinking. Le modèle était alors facturé 0,5 crédit. Enfin pour questionner la base de code sans modification (pour comprendre les différentes interactions entre les fichiers), nous avons utilisé Gemini 2.5 Flash qui (encore en juin 2025) ne consomme aucun crédit. Il est parfait pour générer la documentation de code. Nous avons ainsi pu interroger l'IA sur des fonctions additionnelles générées préalablement et comprendre leurs incidences sur le code métier principal.
4. Le testing et le débogage
Une fois le code fonctionnel, nous avons procédé, avec l'agent de Cursor, au testing et débogage généralisé de tout le code. Cursor a par exemple détecté un problème dans la filtration des données de l'API par notre système et l'a corrigé. Enfin nous avons fait factoriser le code et généré des tests unitaires et une documentation complète.
Le résultat final est visuellement simple mais fonctionnel. L'interface permet d'afficher les prochains trains de la ligne P au départ des gares choisies par nos soins et d'afficher les éventuelles suppressions ou retards de train. La partie alerting permet quant-à-elle d'alerter l'utilisateur de la suppression d'un train ou d'un retard dans une plage horaire donnée (7h-8h30 / 17h30-18h30 du lundi au jeudi). En cas de problèmes, le système envoie un SMS à l'utilisateur en utilisant l'API de Free mobile (l'utilisateur étant client) et un email en utilisant la librairie PHPMailer.
Le fichier index.php est le point d'entrée de l'application. Il charge config.php (paramètres), functions.php (fonctions utilitaires) et logic.php (logique métier). L'interface utilisateur utilise trois composants dans le dossier partials/ : header.php, controls.php et journey_card.php. Le système de monitoring comprend monitor.php et monitoring_config.php. Les dépendances sont gérées par Composer : Twilio SDK (non utilisé finalement) et PHPMailer pour les emails. Deux scripts de test valident les fonctionnalités : test_email_indep.php et test_monitor.php.
Tous ces éléments ont été créés progressivement grâce à des prompts simples avec l'IA, comme "Teste l'envoi de mail en utilisant PHPMailer" pour générer le test d'email, par exemple.
Le script de surveillance pour l'alerting est exécuté automatiquement grâce à une tâche cron en arrière-plan sur le serveur. Cette dernière s'exécute pendant les heures de surveillance souhaitées par l'utilisateur.
Les limites du vibe-coding
Pour réaliser cette interface et la partie alerting, nous avons mis environ deux heures. Sans l'assistance de Cursor, la tâche aurait pu demander entre un et plusieurs jours (nous ne sommes pas développeurs). Le gain de temps est véritablement là. Toutefois, l'exercice nous a montré les limites du vibe-coding. Parfois, le modèle peut générer du code buggé ou halluciner certaines fonctions. Il est alors indispensable de comprendre la structure du code pour appliquer des modifications ou revenir sur des commandes effectuées par l'IA. Sans notion de code, il apparaît pour l'heure impensable de développer une application complexe en quelques heures.
En revanche, Cursor, et plus généralement les IDE AI native, réduisent drastiquement le temps global de mise en production, au bénéfice de la productivité et de la créativité. Le développeur passe du rôle de simple exécutant à chef d'orchestre.