Lokali : une marketplace complète
en 25 heures de travail.
Dont un tiers de code.

Faire circuler le matériel qui dort, à l'échelle d'une île

À La Réunion, le neuf coûte cher et l'offre de location professionnelle est limitée. Une perceuse, un échafaudage, une remorque ou un paddle passent l'essentiel de l'année dans un garage. Lokali met ce matériel en location entre voisins, commune par commune.

Le principe produit tient en une phrase : le propriétaire garde la main. Il accepte ou refuse chaque demande, il fixe lui-même la valeur de son objet et le montant de la caution, il rend son annonce indisponible quand il en a besoin. L'argent ne part qu'après son accord et ne lui est versé qu'après restitution constatée. Rien de tout cela n'est trivial à implémenter.

Écrire le code n'est plus ce qui coûte cher

Une marketplace avec paiement, caution, machine à états et back-office d'arbitrage, c'est un projet que nous aurions chiffré autour de deux mois il y a trois ans. Cette estimation n'est pas sortie d'un tableur, elle vient de dix ans à livrer ce type de produit.

Nous l'avons livré en deux semaines et 25 heures de travail. Ce n'est pas parce que nous avons demandé à une IA de « faire une marketplace ». C'est parce que le code, aujourd'hui, n'est plus le goulot d'étranglement. Le goulot s'est déplacé, et il est là où il a toujours dû être : savoir exactement quoi construire, et le faire valider par le client avant d'écrire une ligne.

C'est aussi ce qui sépare ce projet du vibe coding. Générer un écran qui a l'air juste prend dix minutes. Générer un système où la caution ne peut jamais dépasser la valeur déclarée, où un dommage laisse quand même le prix dû au propriétaire, et où huit statuts s'enchaînent sans jamais se contredire, ça demande d'avoir écrit ces règles avant.

Huit étapes, dans cet ordre, sans en sauter une

1. 1

   Devis détaillé et prototype cliquable · en amont

   Avant toute chose, un devis ligne à ligne et un prototype pour que le client se projette. Pas de cahier des charges de cinquante pages : un objet qu'on ouvre dans un navigateur et qu'on manipule.

2. 2

   Réunion de lancement et spécifications fonctionnelles · 1 réunion

   Une réunion pour trancher le flux de location, les cautions Stripe, la vérification par SMS, le calendrier et les notifications. Les spécifications fonctionnelles V1 sortent dans la foulée.

3. 3

   31 écrans en HTML statique · 3 jours

   19 écrans du site public, 12 écrans de back-office, plus la maquette des 11 emails transactionnels. Statiques, un fichier par écran, ouvrables sans rien installer. Objectif : faire valider le flux et le contenu, pas la technique. Trois vagues de retours client intégrées en trois jours.

   

   

4. 4

   Dossier de validation : 113 règles, une par une · en continu

   C'est la pièce maîtresse. Un outil où chaque écran s'affiche en iframe à côté de ses règles fonctionnelles. Le client valide, refuse ou commente chaque règle avec l'écran sous les yeux. À la fin : 113 règles traitées sur 113, aucune en attente, exportées en Markdown. Plus personne ne peut dire « ce n'est pas ce que j'avais demandé ».

   

5. 5

   PRD avec la méthode BMAD · 1 journée

   Le Markdown de validation devient un PRD structuré : 50 exigences fonctionnelles numérotées, les parcours utilisateurs, une machine à états de 8 statuts et 10 transitions, et la liste explicite de ce qui est écarté de la V1. Ce qui est hors périmètre est écrit noir sur blanc, c'est ce qui évite l'avenant surprise.

6. 6

   19 epics et des tickets GitHub générés depuis Claude · la même journée

   Découpage en 19 epics, chaque exigence dans un et un seul epic, avec un contrôle de couverture. Règle de rédaction : un ticket référence l'écran et l'exigence, il ne les recopie jamais. Un ticket qui recopie une règle devient faux le jour où la règle change, sans que personne ne le voie.

7. 7

   Architecture, puis développement assisté · 1/2 journée d'architecture

   Édouard fige d'abord le modèle de données, le typage des dates, l'emplacement de la machine à états et la forme de l'API. Une demi-journée qui évite douze décisions de modélisation incohérentes prises ticket par ticket. Ensuite seulement, l'IA code, sur des tickets qui référencent des specs validées. Tests API et tests navigateur automatisés dans la foulée.

8. 8

   Cahier de recette déroulé cas par cas · 1 journée

   Les règles de validation se convertissent en cahier de recette sans effort de rédaction : elles étaient déjà des critères d'acceptation. 150 cas exécutés, 140 conformes, 10 en échec. Neuf défauts sur dix portaient sur ce que l'application dit, pas sur ce qu'elle fait. Quatre tickets de correction, puis mise en production.

Où sont passées les 25 heures

C'est le renversement que peu d'agences assument publiquement. Le poste le plus lourd d'un projet livré avec l'IA, ce n'est pas la production de code. C'est le travail humain de cadrage : comprendre le métier, écrire des règles sans ambiguïté, et obtenir un accord explicite du client sur chacune. Ce travail-là ne se délègue pas à un modèle.

Ce que contient réellement la V1

Pour que les 25 heures veuillent dire quelque chose, il faut savoir ce qu'il y a dedans :

• Parcours de location complet : demande, acceptation ou refus du propriétaire, expiration automatique, refus automatique par chevauchement, bascules à l'heure de retrait.
• Paiement et caution par Stripe : empreinte bancaire à la demande, débit à l'acceptation, prélèvement de caution arbitré par l'administrateur en cas de litige.
• Cagnotte virtuelle et virements SEPA : les gains vivent en base, réutilisables pour louer ou versés par fichier SEPA groupé généré depuis le back-office.
• Litiges arbitrés à la main : deux familles de litige, gel de la location, prélèvement partiel, clôture avec arbitrage du prix suspendu.
• Vérification du numéro par SMS via Brevo, bloquante pour publier ou louer.
• Back-office d'exploitation en 12 écrans : utilisateurs, annonces, catégories, réservations, cautions, litiges, virements, tableau de bord.
• Déploiement continu sur CapRover, avec un environnement de développement séparé de la production.

Le code appartient au client, comme sur tous nos projets. Les CGU, CGV utilisateurs et CGV professionnels ont été rédigées et certifiées par l'avocate de Lokali en parallèle du développement.

Ce que l'IA n'a pas décidé toute seule

La question qu'on nous pose toujours : si l'IA a écrit le code, qu'est-ce qui garantit qu'il tient ? La réponse est dans les décisions d'architecture prises en amont, et elle est vérifiable ligne à ligne dans le dépôt.

Et surtout, six choix que personne ne prend en écrivant un prompt :

• Montants en centimes, arithmétique entière, jamais de flottant. Un seul endroit dans tout le code calcule la commission, et les devis une fois gelés ne sont jamais recalculés.
• Anti-chevauchement garanti par la base de données. La double réservation est refusée par PostgreSQL lui-même. Ce n'est pas au code applicatif de la deviner en relisant juste avant d'écrire, avec la course qui va avec.
• Idempotence des paiements garantie par construction. Chaque opération est tracée en base avant d'être envoyée, de sorte qu'un incident réseau ne peut produire ni double débit, ni échec silencieux.
• Les dates de location sont des jours calendaires, jamais converties en UTC. Les instants dérivés sont calculés une seule fois et gelés. Les tests temporels tournent à l'heure de La Réunion, parce qu'un bug de fuseau ne se voit pas quand on teste en UTC.
• Stockage privé et accès temporaire. Aucune photo n'est servie depuis un espace public : chaque consultation passe par une autorisation à durée limitée. Le type réel des fichiers est contrôlé côté serveur, jamais déduit de ce que le navigateur annonce.
• Journalisation avec masquage systématique des données sensibles, limitation de débit, en-têtes de sécurité et protection CSRF sur toutes les écritures.

Chaque transition de la machine à états est une méthode transactionnelle qui écrit son propre événement d'historique. Les emails partent toujours après validation de la transaction, jamais à l'intérieur, pour qu'un rollback n'envoie pas un message annonçant quelque chose qui n'a pas eu lieu. Ce sont ces règles-là qui font la différence entre un produit et une démo, et aucune ne s'improvise au moment de générer le code.

Trois enseignements transposables

Pour aller plus loin