Vibe-coding : une application d’alertes pour la ligne P créée en deux heures

Écrire une application web utile sans partir d’une page blanche, en formulant simplement son besoin à une intelligence artificielle : c’est la promesse du vibe-coding. L’expérience relatée ici l’applique à un cas très concret du quotidien francilien, le suivi des trains de la ligne P du Transilien. En environ deux heures, un tableau de départs et un mécanisme d’alertes ont été assemblés avec l’aide de plusieurs modèles d’IA.

Le résultat n’est pas présenté comme un remplacement des applications officielles de transport. Il s’agit plutôt d’un prototype ciblé, pensé pour visualiser rapidement les prochains trains et recevoir un signal en cas de retard ou de suppression sur des créneaux définis. Son intérêt tient autant à ce qu’il affiche qu’à la manière dont il a été réalisé : une succession d’instructions en langage naturel, de corrections et de vérifications, plutôt qu’un développement entièrement écrit à la main.

Le vibe-coding, une nouvelle façon de fabriquer du logiciel

Le terme vibe-coding désigne une approche de programmation assistée dans laquelle la personne décrit l’application souhaitée, évalue le résultat, puis demande des ajustements à un modèle de langage. Elle ne rédige pas nécessairement chaque fonction ni chaque ligne de code. L’IA propose une architecture, crée des fichiers, produit du code et peut aider à corriger des erreurs.

Cette méthode ne signifie pas que le logiciel apparaît par magie. Le développeur ou l’utilisateur garde la responsabilité de formuler précisément le besoin, de distinguer une réponse plausible d’une réponse correcte, puis de tester l’ensemble. Dans un projet de transport, une erreur de filtrage des données ou une mauvaise interprétation d’un état de circulation peut rendre l’information affichée peu utile.

Le gain de temps vient surtout de l’accélération des tâches répétitives : démarrer une interface, installer des bibliothèques, connecter un service externe, expliquer la structure d’un projet ou écrire des tests. En revanche, les choix importants restent humains : quelles données retenir, à quel moment alerter, quelles informations présenter en priorité et comment protéger l’accès aux services utilisés.

Un objectif précis : surveiller les départs de la ligne P

Le cahier des charges de départ était volontairement resserré. L’application devait prendre la forme d’un tableau d’affichage numérique consacré aux départs de la ligne P. L’interface devait présenter les éléments attendus par un voyageur : heure de départ, destination, numéro du train et informations de circulation disponibles.

L’affichage a été demandé sous une forme responsive, c’est-à-dire capable de s’adapter à la taille de l’écran. Sur un ordinateur ou une tablette, le tableau est organisé en deux colonnes. Sur un mobile, il bascule vers une colonne afin de rester lisible. Un système de codes visuels devait également permettre de différencier rapidement la situation des trains.

Cette précision dans la demande est décisive. Une consigne telle que « crée une appli de train » laisse à l’IA une marge d’interprétation énorme. À l’inverse, détailler les informations attendues, le comportement sur mobile et le rôle des alertes donne au modèle des contraintes qu’il peut traduire en composants d’interface et en logique applicative.

L’application vise aussi une personnalisation que ne couvrent pas toujours les tableaux généraux : prévenir l’utilisateur lorsqu’un train est supprimé ou retardé pendant des plages horaires qui l’intéressent. Les alertes prévues peuvent être expédiées par SMS via l’API de Free Mobile et par email avec PHPMailer.

De la première maquette aux modifications dans Cursor

La construction n’a pas commencé directement dans l’environnement de développement. Une première version de l’interface a été demandée à Claude 4 Opus, le chatbot d’Anthropic. Cette étape a fourni une base de code correspondant à l’écran souhaité : une interface web épurée, adaptée à plusieurs formats, avec les champs nécessaires à l’affichage des départs.

Cette première base a été hébergée sur un serveur distant afin de pouvoir être consultée et modifiée depuis un navigateur. Le projet a ensuite été repris dans Cursor, un environnement de développement intégrant des assistants IA. Le choix de l’outil compte ici parce qu’un éditeur de code ne se limite plus à colorer la syntaxe : il peut aussi lire un projet, proposer des modifications réparties dans plusieurs fichiers et expliquer ses choix.

Le mode « Agent » de Cursor a été utilisé pour effectuer des ajustements plus autonomes. Il peut modifier le code, ajouter des fichiers et préparer l’installation de dépendances nécessaires au projet au moyen de commandes Unix. Cette capacité réduit les allers-retours manuels, mais elle impose aussi de relire les changements proposés, notamment lorsqu’ils concernent la configuration d’un projet ou l’exécution de commandes.

Les données de transport et les alertes, le cœur utile de l’application

Une belle interface ne suffit pas à faire un outil de transport. L’étape déterminante consiste à la relier à des informations exploitables. Pour cela, le backend intègre l’API PRIM d’Île-de-France Mobilités, une plateforme donnant accès à des données utiles pour des services de mobilité.

Le rôle du backend est de récupérer les données, de les sélectionner, puis de les rendre compréhensibles dans le tableau. L’application doit notamment isoler les départs pertinents pour la ligne P, identifier les retards ou suppressions et appliquer les critères liés aux alertes demandées par l’utilisateur. C’est aussi là que les écueils deviennent visibles : les données d’une API ne se présentent pas toujours dans l’ordre ou le format attendu par une interface.

Pour optimiser les coûts et l’usage des modèles dans Cursor, la sélection automatique du modèle a été temporairement désactivée. Les tâches complexes du backend ont été confiées à Claude 4 Sonnet Thinking, tandis que Claude 4 Sonnet a servi pour des opérations de programmation plus simples. Gemini 2.5 Flash a, lui, été employé comme aide documentaire pour interroger l’organisation des fichiers sans consommer de crédits dans cette configuration.

Cette répartition illustre une pratique utile du développement assisté par IA : tous les modèles ne sont pas nécessaires à toutes les étapes. Employer le modèle le plus puissant pour chaque petite modification peut alourdir inutilement la facture et le temps d’attente. À l’inverse, réserver un modèle plus orienté raisonnement à une logique complexe peut faciliter le déblocage d’un problème.

Tester et déboguer : l’étape qui évite de confondre démonstration et outil fiable

L’application n’a pas été considérée comme terminée à la génération de la première interface. Une phase de test a permis de constater et de corriger des problèmes de filtrage dans les données obtenues via l’API. Avec l’assistance de Cursor, le code a été corrigé puis factorisé, c’est-à-dire réorganisé pour réduire les répétitions et rendre les éléments plus cohérents.

Des tests unitaires ont également été générés. Ils servent à vérifier séparément de petites unités de code, par exemple une fonction qui sélectionne les départs à afficher ou une règle qui détermine si une perturbation doit déclencher une alerte. Ils ne prouvent pas à eux seuls qu’un service est irréprochable, mais ils permettent de détecter des régressions lorsqu’une modification est apportée par la suite.

C’est une différence essentielle entre demander une maquette et construire une application : une page qui s’affiche n’est pas nécessairement capable de traiter correctement tous les cas réels. Pour un service s’appuyant sur des données de transport, il faut notamment vérifier les réponses vides, les informations incomplètes, les doublons, les erreurs réseau et les situations inattendues.

Ce que mesurent réellement ces deux heures de développement

Le chiffre de deux heures doit être lu pour ce qu’il décrit : le temps nécessaire, dans cette expérience, pour atteindre un résultat fonctionnel et visuellement abouti sur un périmètre précis. Sans l’assistance de Cursor et des modèles de langage, le même travail aurait demandé plusieurs jours, voire davantage, selon le niveau de maîtrise technique et les choix d’implémentation.

Ce résultat ne signifie pas qu’une application de transport grand public complète, maintenue dans la durée et prête à accueillir un grand nombre d’utilisateurs peut être fabriquée en deux heures. Un produit déployé à grande échelle exige des vérifications supplémentaires : disponibilité du serveur, gestion des erreurs, surveillance du fonctionnement, droits d’accès aux données, protection des clés d’API et qualité de l’envoi des emails ou des SMS.

Il faut aussi distinguer le temps de création visible du temps de préparation. Définir le besoin, comprendre les données disponibles, obtenir les accès nécessaires aux services externes et décider du contenu exact des alertes restent des activités qui ne disparaissent pas. L’IA accélère l’assemblage, mais elle ne remplace pas l’analyse du problème.

Le développeur devient l’orchestrateur du projet

L’expérience montre un déplacement du travail plutôt qu’une disparition de celui-ci. Au lieu d’écrire chaque détail de l’interface et de la logique applicative, la personne à l’origine du projet devient l’orchestratrice d’un ensemble de modèles et d’outils. Elle choisit le bon niveau de précision dans les requêtes, répartit les tâches, relit les propositions et demande des correctifs.

Cette nouvelle manière de travailler reste plus efficace lorsqu’elle s’appuie sur une compréhension minimale de la structure d’un projet. En cas d’erreur générée par l’IA, il faut pouvoir repérer le fichier concerné, comprendre les liens entre le frontend et le backend, puis évaluer si la correction proposée est pertinente. C’est précisément ce qui s’est produit lors des ajustements nécessaires sur le filtrage des données.

Pour une personne débutante, ces outils peuvent donc servir de formidable accélérateur d’apprentissage et de prototypage. Pour un développeur expérimenté, ils peuvent automatiser une partie du travail répétitif. Dans les deux cas, laisser l’IA modifier un projet sans contrôle expose au risque de conserver du code inutile, fragile ou mal adapté au besoin initial.

Ce qu’il faut surveiller avant de généraliser le vibe-coding

Le cas de cette application de ligne P met en évidence la force du vibe-coding : passer rapidement d’une idée concrète à un outil qui affiche des données et déclenche des notifications. Les interfaces de suivi personnel, les tableaux de bord, les petits services métier et les prototypes sont des terrains particulièrement favorables à cette approche.

La prochaine étape, pour les personnes qui voudraient reproduire cette méthode, est de ne pas réduire l’évaluation au seul aspect visuel. Il faut contrôler l’origine et la fraîcheur des données, lire les conditions d’utilisation des API, protéger les identifiants techniques, tester les scénarios d’échec et vérifier que les alertes arrivent bien au bon moment.

L’enjeu n’est donc pas de savoir si l’IA peut écrire du code, elle le peut déjà dans de nombreux cas. La question devient : comment la guider pour produire un logiciel compréhensible, vérifiable et réellement utile ? L’expérience de juin 2025 apporte une réponse pragmatique : avec un objectif très précis, des outils bien choisis et une phase de contrôle sérieuse, la création d’un premier service peut être considérablement accélérée.