Le week-end avec sa propre application

J’ai offert un week-end à Hambourg à ma femme. Quand je lui ai demandé dans quelle mesure elle voulait participer à l’organisation, elle m’a répondu: pas du tout. Très bien. Je m’en occuperais.

J’ai donc ouvert Perplexity et je me suis mis au travail. Hôtel, restaurants à réserver, visites, déplacements, programme du samedi soir. Quelques heures plus tard, j’avais un document rempli de notes utiles — mais cela restait des notes. L’heure d’arrivée à l’hôtel. La sortie de métro la plus proche de l’entrée. L’heure de la réservation au restaurant. L’heure d’ouverture des portes du club de comédie. L’adresse de la salle de concert.

En le relisant, j’ai compris que ce serait un vrai casse-tête à utiliser pendant le voyage. Passer d’une note à une application cartographique, puis à une capture d’écran des horaires d’ouverture et à l’e-mail de confirmation du restaurant: rien ne s’emboîtait. Ce que je voulais vraiment, c’était une carte. Une seule carte, avec nos lieux, et les horaires associés aux bons repères.

Puis je me suis souvenu d’une chose: il me restait des crédits gratuits offerts dans le cadre d’une campagne marketing de Perplexity pour son outil informatique « agentique ». Je lui ai donc demandé de créer une petite application web pour mobile destinée au voyage — Android et iOS, un simple lien dans le navigateur, sans passer par une boutique d’applications. Vingt minutes plus tard, j’avais une première version fonctionnelle avec notre hôtel comme point de départ, tous les repères qui nous intéressaient et les horaires correspondants.

Ce guide porte sur ce que cette expérience m’a appris. Il parle moins de Hambourg que de ce que l’IA sait désormais faire, et de la limite qu’elle rencontre encore.

Les agents de recherche comprennent ce que vous cherchez réellement à faire

C’était la première surprise. La recherche générique assistée par IA existe depuis un moment; ce que j’ai remarqué cette fois, c’est que l’agent de recherche de Perplexity ne répondait pas seulement à mes questions, mais à la question derrière la question.

Je pouvais lui demander par exemple: « Trouvez des restaurants entre notre hôtel et la salle de concert qui sont ouverts après le spectacle. » Pas trois requêtes distinctes. Pas une liste de tous les restaurants du quartier. Précisément ceux qui correspondaient à l’endroit où nous serions réellement et au moment où nous y serions.

Quand je lui ai posé des questions sur le bus touristique à arrêts multiples, l’agent a relevé des contradictions dans les informations fournies par l’opérateur lui-même — une page indiquait un arrêt à une adresse, une autre laissait entendre autre chose — et a signalé le conflit au lieu de choisir une version et de faire semblant. C’est le genre de vérification qui demandait autrefois de garder trois onglets ouverts dans le navigateur.

La leçon: quand vous utilisez un agent de recherche pour quelque chose de réellement utile, traitez-le comme un assistant intelligent capable de garder l’ensemble du projet en tête. Ne décomposez pas vos besoins en requêtes de recherche. Décrivez simplement ce que vous cherchez à faire.

Le développement: vingt minutes pour une application fonctionnelle

La première version est arrivée à une vitesse presque gênante. J’ai décrit ce que je voulais — une carte pensée d’abord pour le mobile, avec notre hôtel comme point de départ, des repères pour chaque rendez-vous et réservation accompagnés des horaires, des zones accessibles à pied en surimpression, la prise en charge du GPS et des liens ouvrant Google Maps ou Apple Maps pour que nous puissions quand même nous orienter correctement si nécessaire.

L’agent a choisi une stack web statique — HTML, CSS, JavaScript, Leaflet pour la carte, des tuiles OpenStreetMap. Pas de backend, pas de base de données, pas d’authentification. Juste une URL à ouvrir sur nos téléphones. Vingt minutes après mon prompt initial, j’avais le lien.

Pensez une seconde à ce que cela signifie. Il y a trois ans, « créez-moi une application mobile sur mesure pour un week-end précis » aurait été un projet. Aujourd’hui, c’est un prompt. La compétence qui compte n’est plus « savez-vous coder? » C’est « savez-vous décrire clairement ce qu’il faut construire? »

J’ai fait mieux qu’un opérateur existant en dix minutes

Cette partie m’a vraiment impressionné.

Le bus touristique à arrêts multiples s’est révélé être le moyen le plus efficace de parcourir la ville sans engloutir notre argent dans les taxis. J’ai cherché l’offre numérique de l’opérateur et j’ai trouvé… un simple site web. Des fichiers d’images statiques du plan de l’itinéraire, dont certains étaient visiblement coupés sur les bords. Pas de carte interactive. Pas d’application web. Pas d’application mobile. Rien que des images.

J’ai donc demandé à mon agent d’ajouter l’itinéraire du bus en surimpression sur ma propre carte: chaque arrêt sous forme de repère, le trajet dessiné comme une ligne, les horaires sur chaque arrêt et les sites à proximité pour que nous sachions où descendre. Dix minutes plus tard, mon application privée pour le week-end proposait une meilleure version du produit principal de cet opérateur que l’opérateur lui-même.

J’ai envisagé, à moitié sérieusement, de leur écrire. Puis j’ai réfléchi à ce que cela demanderait vraiment. C’est la leçon suivante.

Le coût des itérations (et où sont passés mes crédits gratuits)

La première version avait l’air superbe. Puis j’ai commencé à l’utiliser comme je le ferais vraiment.

Les repères étaient décalés de 200 mètres. Même l’hôtel se trouvait à quelques pâtés de maisons de son emplacement réel — l’agent avait utilisé des coordonnées approximatives, ce qui convient pour une capture d’écran et ne sert à rien quand vous marchez dans une ville en cherchant une porte d’entrée. Correction: passer à des coordonnées géocodées à partir de l’adresse et revérifier les repères importants.

Les liens « ouvrir dans Google Maps » lançaient directement le mode navigation, ce qui n’est pas le bon comportement: vous voulez d’abord voir le lieu, puis décider si vous souhaitez lancer l’itinéraire. Correction: remplacer le format d’URL /dir/ par /maps/search/.

J’apportais des modifications sur mon ordinateur portable. Elles apparaissaient sur ordinateur, mais pas sur mon téléphone, parce que celui-ci avait mis en cache les anciens fichiers JavaScript. Correction: ajouter une version aux URL des fichiers pour que le navigateur sache qu’il doit récupérer de nouvelles copies.

Sur mobile, le panneau inférieur contenant la liste des repères était pratiquement bloqué: impossible de le faire glisser vers le haut. Correction: gérer explicitement les gestes tactiles et ajouter un véritable conteneur de défilement.

Et les données des arrêts de bus restaient imprécises. J’ai fini par recouper les noms et les coordonnées des arrêts avec les données de l’opérateur officiel des transports publics, puis j’ai renvoyé la liste corrigée à l’agent.

Chacune de ces corrections a demandé un aller-retour avec l’agent. Et chaque aller-retour a consommé des crédits. À mi-chemin, j’ai épuisé mes crédits gratuits. J’avais trop avancé pour m’arrêter, alors j’en ai racheté. C’est un vrai coût, et il faut le dire: créer quelque chose de fonctionnel avec l’IA est rapide, mais transformer quelque chose qui fonctionne en quelque chose de bon demande toujours des itérations. Et les itérations ne sont pas gratuites.

La vraie leçon concerne les tests. Les vérifications sur ordinateur n’ont détecté aucun des problèmes propres au mobile. La seule façon de les trouver était d’utiliser réellement l’application sur un téléphone, dans une situation concrète, en me mettant à la place de la personne pour qui elle avait été créée. Il n’y a pas de raccourci. Le vrai travail, c’est de tester sur l’appareil réel.

Où le vibe coding cesse d’être magique

Pour un week-end, pour deux utilisateurs que je connais personnellement, pour un seul voyage — c’était le cas d’usage idéal. Une application jetable, une URL privée, un vrai problème réglé en un après-midi. Qu’elle ne soit pas traduite, n’accepte pas de paiements, ne gère pas dix mille utilisateurs simultanés, n’ait aucun moyen de recueillir les avis et ne survive pas sans accroc à une mise à jour du système d’exploitation du téléphone: rien de tout cela n’avait d’importance, parce que ce n’était pas nécessaire.

Mais je me suis surpris à imaginer l’e-mail adressé à l’opérateur de bus. Voici ce qu’il faudrait réellement pour transformer mon jouet de week-end en un produit qu’il pourrait proposer à ses clients:

• Il faudrait en assurer la maintenance — les arrêts, les itinéraires et les horaires changent.
• Il faudrait la sécuriser — elle serait accessible au public, traiterait des paiements et relèverait du RGPD.
• Il faudrait la traduire — Hambourg accueille des touristes du monde entier.
• Il faudrait permettre d’acheter des billets, de contacter l’assistance et de donner son avis.
• Il faudrait qu’elle fonctionne sur tous les téléphones, tous les navigateurs et toutes les tailles d’écran — pas seulement sur les deux appareils que j’avais testés. Chaque correction de bug pourrait en créer de nouveaux ailleurs.
• Il faudrait des outils d’analyse, un suivi des erreurs et un processus de mise en production.

C’est exactement là que s’arrête le vibe coding et que commence l’ingénierie logicielle. Il ne s’arrête pas à la première version fonctionnelle. Il s’arrête avec tout ce qui vient ensuite. Je fais toujours le même constat: l’IA vous amène à « cela fonctionne pour moi » en vingt minutes, puis à « cela fonctionne pour tout le monde, de manière fiable, pour toujours » en… eh bien, autant de temps qu’avant, à peu de chose près. L’agent est réellement utile pour ce second parcours aussi, mais il n’est plus le personnage principal. C’est vous.

Ce n’est pas un reproche. C’est le modèle mental le plus utile que j’aie trouvé pour décider quand miser sur des outils construits avec l’IA et quand prendre du recul. Si le nombre d’utilisateurs est faible et la durée de vie courte, développez-le en vibe coding. Si l’un ou l’autre augmente, vous vous engagez alors dans toute la rigueur de l’ingénierie logicielle — et mieux vaut le savoir dès le départ.

Ce que je referais

Même avec tous les crédits dépensés, c’était l’un des projets personnels les plus agréables que j’aie réalisés depuis longtemps. Voici ce que je referais de la même manière:

1. Commencer par la recherche, pas par le développement. L’heure passée à laisser l’agent planifier le voyage — rendez-vous, solutions de repli, quartiers, contradictions — a rendu la création de l’application toute simple. Passer directement à « créez-moi une application » aurait produit quelque chose de générique.
2. Faire le tri, puis construire. J’ai délibérément supprimé des repères. Pas tous les restaurants. Pas tous les sites touristiques. Seulement ceux qui nous intéressaient vraiment, plus quelques bonnes solutions de repli. La valeur de l’application venait de son périmètre plus étroit que celui de Google Maps, pas plus large.
3. Tester sur l’appareil que vous utiliserez réellement. Ça paraît évident. Ça ne l’était pas avant que je le fasse.
4. Accepter d’emblée le coût des itérations. Prévoyez du temps et, si vous utilisez des agents payants, des crédits. La première version est la partie facile.
5. Savoir quand s’arrêter. Je me suis surpris plusieurs fois à vouloir ajouter des fonctionnalités sans intérêt pour un seul week-end. Savoir se retenir est une compétence en soi.

Toute cette expérience illustre de manière simple et nette ce que l’IA change à la frontière entre utilisateur et créateur. Il y a cinq ans, « une application sur mesure pour notre week-end » n’était pas quelque chose qu’une personne ordinaire pouvait créer. Aujourd’hui, cela prend un après-midi. Et la question n’est plus « puis-je construire ça? » mais « est-ce que cela mérite le temps que je vais y consacrer, compte tenu de ce que je devrai ensuite maintenir? »

Pour un week-end à Hambourg, avec ma femme, sur une carte que j’ai créée moi-même? Cela en valait absolument la peine.

---

Si vous voulez voir ce que les agents IA peuvent faire dans un workflow plus général, le guide du pipeline de recherche explique comment j’utilise Perplexity et Claude ensemble au quotidien. Et si vous envisagez de créer quelque chose de plus durable qu’une application de week-end, le guide du site web gratuit présente la stack basée sur GitHub qui tient réellement la route à plus grande échelle.