Jmetire — un prototype pour éprouver une stack avant de la facturer
Comparateur de vols pour voyageurs flexibles, projet interne — France
En bref
Jmetire est un comparateur de vols pour voyageurs flexibles, construit en quatre jours. Ce n'est pas une commande client : c'est le terrain sur lequel nous avons mis en production Next.js 16, React 19, Tailwind CSS 4, Base UI et le backend réactif Convex avant de les proposer sur des projets facturés. Le prototype scanne huit aéroports français vers cent quinze destinations à partir de l'API Travelpayouts, note chaque offre sur cent, et trace la chaîne d'affiliation du clic jusqu'à la conversion. Il a aussi enseigné ce qu'une application temps réel coûte à faire tourner, et ce qu'il faut prévoir le jour où l'on décide d'éteindre son backend.
- Client
- jmetire
- Zone
- France
- Délai
- Prototype construit en 4 jours
Le problème à résoudre
Une agence qui livre en quelques jours doit connaître ses outils avant de les facturer. Une version majeure de framework, un backend réactif ou une bibliothèque de composants s'évaluent mal sur une documentation et une application de démonstration : ce qui coince apparaît en production, sur un domaine où les données arrivent vite, se périment et proviennent d'une API tierce qu'on ne maîtrise pas. La recherche de vols réunit ces contraintes, et quelques autres : volume d'écriture élevé, dépendance à un fournisseur externe, rémunération à la performance, et une interface qui doit rester lisible sur un téléphone. D'où ce projet interne, sans client, sans échéance commerciale et sans obligation de résultat — le seul contexte où l'on peut se permettre de découvrir qu'un choix était mauvais.
Ce que nous avons construit
Les décisions structurantes du projet Jmetire.
Un socle mis en production avant d'arriver chez un client
Next.js 16 avec ses paramètres de route devenus asynchrones, React 19, Tailwind CSS 4 configuré par thème plutôt que par fichier de configuration, et des composants d'interface bâtis sur Base UI au lieu de Radix. Chacun de ces choix a été poussé jusqu'au déploiement, sur sept écrans réels, plutôt qu'évalué sur un projet jetable. Les pièges rencontrés ici sont ceux qu'on ne rencontre plus sur un projet facturé.
Un backend réactif plutôt qu'une base de données classique
Le schéma compte treize tables, ses index et un index de recherche plein texte, et vit dans le même dépôt TypeScript que l'interface. Les écrans s'abonnent aux données au lieu de les redemander : une offre modifiée côté serveur remonte seule dans les listes ouvertes. C'était la question centrale du prototype — est-ce qu'un backend réactif tient un domaine à fort volume d'écriture sans devenir ingérable — et la réponse est nuancée, ce que détaille la foire aux questions plus bas.
Trois travaux planifiés, et personne aux commandes
Un premier passage interroge l'API Travelpayouts pour huit aéroports de départ français et retient les offres exploitables vers un catalogue de cent quinze destinations. Un deuxième retire les offres périmées toutes les six heures. Un troisième recalcule les statistiques de prix de chaque route. Le produit n'a pas d'interface d'administration : il se remplit et se nettoie tout seul, ce qui est la seule façon de tenir un catalogue périssable sans y consacrer du temps humain.
Un score d'opportunité plutôt qu'un tri par prix
Chaque offre reçoit une note sur cent qui combine l'écart au prix médian de la route, la distance au plancher observé, le délai avant le départ, le nombre d'escales, la durée rapportée à la moyenne de la ligne et quelques bonus mineurs. Trier par prix croissant remonte des trajets à trois escales que personne ne réserve ; la note remonte ce qui constitue réellement une bonne affaire. C'est le même problème que le classement d'un catalogue produit, transposé sur des données qui changent tous les jours.
Le rabais affiché seulement quand il est démontrable
La première version comparait chaque prix à une référence fabriquée, le prix courant multiplié par 1,6, ce qui produisait un pourcentage de réduction sur toutes les offres et n'en démontrait aucune. Elle a été remplacée par une médiane calculée sur jusqu'à mille relevés de la route sur douze mois, et le pourcentage ne s'affiche qu'au-delà de vingt échantillons. En dessous, le prix s'affiche sans rabais. C'est d'abord une exigence réglementaire, une réduction annoncée depuis une référence inventée étant une pratique commerciale trompeuse, mais c'est surtout la différence entre un chiffre et un argument.
La chaîne d'affiliation tracée de bout en bout
Un clic ne part pas directement chez le partenaire : il passe par une route interne qui génère un identifiant aléatoire, enregistre le clic avec sa route et son prix, puis redirige en transmettant cet identifiant. La conversion revient plus tard sur un point d'entrée dont la signature est vérifiée en HMAC SHA-256, par comparaison à temps constant, et se rattache au clic d'origine. Le sujet n'a rien de spécifique au voyage : c'est le schéma de tout produit rémunéré à la performance, où une conversion non rattachée est une recette perdue et une signature non vérifiée une porte ouverte.
Un compte utilisateur qui n'a pas été écrit à la main
L'authentification est déléguée à Clerk, et le cycle de vie des comptes redescend dans la base par un point d'entrée serveur dont la signature est vérifiée. Par-dessus, une couche de jeu : cinq niveaux, quatorze badges et un journal de points où chaque gain est écrit avec son motif plutôt que dans un compteur qu'on incrémente. Le coût réel de cette partie n'a pas été l'authentification mais l'habillage : un thème sombre impose de reprendre explicitement l'apparence de chaque composant fourni, sans quoi la moitié des écrans devient illisible.
Une application installable, éprouvée sur un usage mobile
Manifeste, service worker avec cache statique, cache d'exécution et page hors-ligne, trois raccourcis vers les écrans utiles et des abonnements aux notifications stockés côté serveur. Un comparateur de prix s'ouvre debout dans un couloir de gare, pas assis devant un écran : c'était le bon terrain pour vérifier ce qu'une application web installable apporte vraiment, et ce qu'elle ne remplace pas.
Ce que le prototype a coûté, et ce qu'on en a tiré
Un scan horaire sur huit aéroports interroge l'API et réécrit les mêmes documents des milliers de fois par jour, pour un résultat que l'utilisateur ne distingue pas d'un scan quotidien. Le poste principal d'une application temps réel n'est pas l'hébergement, c'est la fréquence de ses travaux planifiés — et c'est un arbitrage qui se tranche au cadrage, pas à la facture. Un audit de coûts a conduit à éteindre les déploiements du backend plutôt qu'à entretenir un prototype sans utilisateurs. Le site est resté en ligne : une frontière d'erreur bascule l'application en mode dégradé au premier échec, les requêtes sont mises en veille et les écrans repassent sur leurs données statiques, tandis que les pages qui n'ont rien à montrer sans backend affichent un état explicite plutôt qu'un chargement infini. La leçon est réutilisable telle quelle : une application branchée sur un service distant doit savoir quoi afficher quand ce service disparaît.
Stack technique
Depuis la livraison
Un projet de laboratoire se raconte avec ses détours, sinon il ne sert à rien. Voici les étapes qui comptent, y compris celles qui ont consisté à revenir sur une décision.
Premier jet
Thème, sept écrans et schéma de données complet, sur des données simulées. L'objectif du premier jour est de valider la forme du produit, pas de le brancher.
Authentification, carte et application installable
Comptes utilisateurs, couche de jeu, carte interactive, manifeste et service worker. Les écrans quittent les données simulées pour des requêtes réactives.
Mise en ligne sur son nom de domaine
Branchement de l'API Travelpayouts, premier travail planifié, mesure d'audience avec bandeau de consentement, pages légales et chaîne d'affiliation complète.
Le rabais devient démontrable
La référence fabriquée est remplacée par une médiane calculée sur douze mois de relevés, et le pourcentage disparaît des offres qui manquent d'historique.
Le statut du projet écrit noir sur blanc
Les mentions légales et le pied de page indiquent qu'il s'agit d'un projet de démonstration, conçu et édité par l'agence. Un prototype public qui ne dit pas ce qu'il est finit par tromper quelqu'un.
Audit de coûts
La fréquence de scan ressort comme le poste principal. Décision d'éteindre les déploiements du backend plutôt que d'entretenir un prototype qui n'a pas d'utilisateurs à servir.
Le site survit à l'extinction de son backend
Frontière d'erreur, requêtes mises en veille et retour aux données statiques. Le site reste consultable et la démonstration reste debout, backend éteint.
Questions fréquentes — Jmetire
Pour éprouver des outils avant de les facturer. Next.js 16, React 19, Tailwind CSS 4, Base UI et le backend Convex ont été mis en production sur jmetire avant d'être proposés sur des projets clients. Un framework s'évalue mal sur sa documentation : les problèmes apparaissent au déploiement, sous des données réelles. Le faire sur un projet interne signifie que le client ne paie pas notre apprentissage, et qu'un mauvais choix se corrige sans conséquence pour personne. C'est aussi pour cette raison que jmetire ne figure pas parmi les références commerciales du site : ce n'est pas une commande, et le présenter comme telle serait malhonnête.
Quatre jours ici, pour sept écrans, un backend, l'authentification, une application installable et l'intégration d'une API tierce. Mais un prototype n'est pas un produit : il n'a ni support, ni engagement de disponibilité, ni montée en charge éprouvée, ni sauvegardes. C'est précisément ce qui permet d'aller vite. Chez nous, un cadrage produit démarre à 1 200 € et une application sur mesure entre 3 000 et 6 000 € selon le périmètre — la différence de prix avec un prototype, c'est tout ce que le prototype n'a pas.
Cela dépend de ce que la réactivité apporte à l'utilisateur. Un backend réactif comme Convex donne gratuitement la mise à jour en direct des écrans, place les travaux planifiés et les fonctions serveur dans le même dépôt que l'interface, et type les données de bout en bout : le gain de temps est réel. La contrepartie l'est aussi — la facture suit le volume de lectures et d'écritures, et réécrire fréquemment les mêmes documents crée de la contention. À privilégier quand le direct est le produit, comme sur un tableau de bord ou une messagerie. Une base relationnelle reste plus simple et moins chère quand les données changent peu.
Moins que ce qu'on croit du côté de l'hébergement, davantage du côté des travaux planifiés. Sur jmetire, un scan horaire sur huit aéroports réécrivait les mêmes données des milliers de fois par jour pour un résultat que l'utilisateur n'aurait pas distingué d'un scan quotidien. La question à poser au cadrage n'est donc pas « à quelle fréquence peut-on rafraîchir » mais « à quelle fréquence l'utilisateur voit-il la différence ». Sur la plupart des applications métier, la réponse divise la facture d'infrastructure par dix.
Non, et le site ne prétend pas le contraire. Son backend est éteint depuis l'audit de coûts de juin 2026 : les écrans tournent sur un jeu de données figé, et les pages qui n'ont rien à montrer sans backend l'annoncent. Le site reste en ligne comme démonstration d'interface et de parcours, pas comme comparateur exploitable. C'est d'ailleurs la partie la plus utile du projet : voir comment une application se comporte quand le service dont elle dépend disparaît, avant que la question se pose sur un produit qui a des utilisateurs.
Ressources liées
Les pages et articles qui prolongent ce projet.
D'autres projets livrés
RE3DLINE
RE3DLINE est un atelier d'impression 3D installé à Guérande qui fabrique des objets de décoration en PLA biosourcé, à la commande. Nous avons construit sa boutique en ligne autour de son ERP Odoo, dans les deux sens : le catalogue est lu depuis l'ERP, et chaque commande payée y redescend en bon de commande sans ressaisie. La boutique a continué d'évoluer depuis : personnalisation des pièces pilotée depuis Odoo, récapitulatif de production envoyé chaque matin à l'atelier, livraison ouverte aux vingt-sept pays de l'Union européenne, version anglaise complète, et un journal de treize articles. Au 5 août 2026, cent sept références réparties en huit collections sont en ligne.
Pet-sitting, promenade de chiens, visites de chats, taxi animalierAnim'happy
Anim'happy est un service de pet-sitting professionnel installé à Pornichet, certifié ACACED et TAV. Nous avons livré en 5 jours un site vitrine et un back-office sur mesure : le planning des prestations, le fichier des clients et de leurs animaux, et les demandes du formulaire, consultables depuis un téléphone entre deux visites. Le site a continué de grandir depuis, avec une refonte en juillet 2026 qui l'a fait passer de 4 à 33 pages (une par service, une par commune, un blog, une FAQ) puis deux articles par semaine. Au relevé du 3 août 2026, 29 des 32 requêtes mesurées sont classées, dont 16 en première page, les clics Google ont été multipliés par 30 en un mois, et Gemini cite animhappy.com dans 83 % de ses réponses sur le pet-sitting local.
Un projet du même ordre ?
Premier rendez-vous gratuit et sans engagement, devis sous 24 heures.BecauseTimeCounts intervient partout en France.