VillaSlot : comment j’ai remplacé deux workflows SaaS en 48 heures

▶️ Voir la vidéo complète

Le support de Timely a mis quatre jours à me répondre. En deux jours, j’avais une première version de VillaSlot. Cette phrase résume bien le déclencheur, mais pas le travail réalisé derrière. Je n’ai pas envoyé « fais-moi un SaaS » à un agent avant d’aller dormir. J’ai préparé un produit que les agents pouvaient construire et vérifier sans improviser l’intention métier.

VillaSlot répond à un problème concret dans la gestion de mes villas. Les réservations à la nuitée vivaient dans un outil, les créneaux horaires pour les shootings et les événements dans un autre, et les paiements devaient arriver sur les bons comptes Stripe. J’ai réuni ces flux dans une seule application adaptée à mon fonctionnement.

Ce que VillaSlot remplace vraiment

VillaSlot ne prétend pas remplacer toute la marketplace Airbnb. Il ne fournit ni son audience, ni son acquisition, ni son réseau mondial. Il remplace les workflows directs dont j’ai besoin une fois que le client est là.

Cette limite est importante. Construire un outil métier ciblé est réaliste en 48 heures. Reproduire Airbnb, sa demande, sa confiance et ses opérations ne l’est pas.

Les 48 heures ont commencé avant le code

La vitesse venait du niveau de préparation. J’ai cadré le produit avec Codex, puis préparé un PRD, 20 user stories, leurs critères d’acceptation, un graphe de dépendances et 20 maquettes. Chaque agent recevait une portion bornée du produit avec un résultat observable.

Une user story ne disait pas seulement « ajouter les réservations ». Elle précisait le comportement attendu, les règles métier et la preuve nécessaire pour accepter le travail. Cette préparation évite qu’un agent invente les détails qui comptent : quel calendrier mettre à jour, quel compte Stripe utiliser, quand demander un acompte ou comment empêcher deux réservations incompatibles.

Le graphe de dépendances fixait aussi l’ordre. Une story qui dépend du modèle de réservation ou du paiement ne partait pas avant les fondations correspondantes. L’objectif n’était pas d’occuper le plus grand nombre d’agents possible. Il était de lancer le bon travail au bon moment.

Le run autonome de 9 h 20

Une fois le contrat de travail prêt, j’ai lancé un run autonome de 9 h 20 pendant la nuit. Le système a traité plus de quatre milliards de tokens avec Claude Code et Codex. Ce volume montre l’intensité du run, pas la qualité du résultat. La qualité venait de la boucle de preuve imposée à chaque story.

Le parcours suivait cette séquence :

1. sélectionner une user story dont les dépendances sont terminées ;
2. lire ses critères d’acceptation et définir les preuves attendues ;
3. écrire les tests avant ou avec l’implémentation ;
4. implémenter la fonctionnalité ;
5. faire relire le changement par une passe séparée ;
6. exécuter les tests unitaires et d’intégration ;
7. tester le parcours dans Chrome ;
8. contrôler le rendu visuel ;
9. corriger les défauts techniques ou fonctionnels, puis rejouer les preuves.

Une story validée libérait les suivantes dans le graphe. Un défaut reproductible repartait dans la boucle de correction. Une ambiguïté produit devait remonter à un humain au lieu d’être transformée en décision cachée dans le code.

Pourquoi les maquettes comptaient autant que les tests

Les tests automatisés peuvent confirmer qu’un calcul, une API ou une transition d’état fonctionne. Ils ne prouvent pas qu’un calendrier est lisible, qu’un bouton est placé au bon endroit ou que le parcours est compréhensible sur un écran réel.

Les 20 maquettes donnaient aux agents une cible visuelle. Le passage dans Chrome vérifiait ensuite l’application construite, pas seulement des composants isolés. Le contrôle visuel permettait de repérer les écarts de mise en page, les états vides incohérents et les actions impossibles à comprendre.

C’est aussi la raison pour laquelle je sépare la review de l’implémentation. L’agent qui vient d’écrire le code connaît trop bien son intention. Une passe distincte examine le diff et les preuves avec moins de contexte implicite. Elle peut encore se tromper, mais elle réduit les validations basées sur « ça devrait marcher ».

Ce que le lendemain a réellement livré

Au matin, la première version utilisable était là. Je l’ai ensuite confrontée à l’usage réel et ajouté une dizaine de stories. Ce deuxième temps compte autant que le premier : un run autonome peut exécuter un plan, mais l’usage révèle des besoins que le plan initial ne contenait pas.

Les 48 heures ne signifient donc pas que le produit était terminé pour toujours. Elles désignent le délai nécessaire pour passer d’un problème métier identifié à une première version fonctionnelle que je pouvais tester dans mes villas. La suite a été une boucle normale de produit : utiliser, observer, corriger et compléter.

Les limites d’un tel workflow

Cette méthode ne rend pas les agents autonomes par magie. Elle déplace une partie de l’effort vers la préparation et la vérification. Elle échoue vite si les critères sont vagues, si plusieurs stories partagent un environnement instable ou si les agents peuvent valider leur propre travail sans preuve indépendante.

Je garde plusieurs règles :

• les décisions produit ambiguës reviennent à un humain ;
• une sortie de terminal ne remplace pas un test fonctionnel ;
• un test vert ne remplace pas le contrôle visuel ;
• une review ne remplace pas l’usage réel ;
• le nombre de tokens ou d’agents n’est jamais un résultat métier.

Le gain ne vient pas d’un prompt géant. Il vient d’un contrat précis entre l’intention produit, l’implémentation et les preuves. Avec ce cadre, je peux laisser les agents travailler longtemps sans confondre activité et livraison.

▶️ Voir VillaSlot, le run et le workflow complet

Pour recevoir mes prochains retours terrain sur le développement agentique, rejoins The Agentic Dev.