Comment j’ai construit VillaSlot en 48 heures avec des agents IA

▶️ Voir la vidéo complète

Le support technique de Timely a mis quatre jours à me répondre. Plutôt que d’attendre davantage, j’ai construit VillaSlot, un SaaS adapté au fonctionnement de mes villas. La première version a été développée en 48 heures, avec un run autonome de 9 h 20 exécuté pendant la nuit.

Le résultat ne vient pas d’un gros prompt demandant à une IA de « faire un SaaS ». Il vient du cadrage, de la décomposition fonctionnelle et d’une boucle de qualité suffisamment stricte pour permettre aux agents de travailler plusieurs heures sans surveillance permanente.

Le problème métier à résoudre

Mes villas ont deux modes de réservation. Les voyageurs réservent des nuits, comme sur Airbnb. Les photographes, marques et organisateurs d’événements réservent des créneaux horaires. Ces deux logiques doivent partager le même calendrier afin d’éviter les conflits.

VillaSlot devait également gérer les acomptes et les soldes, puis envoyer les paiements vers les comptes Stripe des villas concernées. Le produit devait donc réunir plusieurs contraintes dans un seul flux :

réservations à la nuitée ;
créneaux horaires pour les shootings et les événements ;
calendrier commun et contrôle des disponibilités ;
acomptes et soldes ;
paiements vers des comptes Stripe externes.

VillaSlot remplace les workflows dont j’avais besoin dans Timely et Airbnb. Il ne remplace pas la marketplace ni l’acquisition apportée par Airbnb.

Le cadrage avant le code

J’ai commencé par un brainstorming avec Codex pour préciser le périmètre et les décisions produit. Ensuite, j’ai préparé le PRD, 20 user stories, leurs critères d’acceptation et un graphe de dépendances.

Le graphe était nécessaire : certaines stories dépendaient de l’authentification, d’autres du calendrier, des paiements ou de la gestion des villas. Lancer toutes les tâches dans le désordre aurait créé des reprises et des conflits inutiles.

J’ai également préparé 20 maquettes. Chaque agent disposait donc d’un résultat fonctionnel et visuel précis à atteindre.

Élément	Rôle dans le run
PRD	fixe le périmètre et les règles métier
User stories	découpe le produit en résultats vérifiables
Critères d’acceptation	définit ce qui valide chaque story
Graphe de dépendances	impose un ordre d’exécution cohérent
Maquettes	fournit la cible visuelle

Un run autonome de 9 h 20

Une fois le terrain préparé, j’ai lancé les agents pour la nuit. Ils ont enchaîné les stories pendant 9 h 20. L’objectif n’était pas de produire rapidement beaucoup de code, mais de terminer chaque story avec ses preuves.

Pour chaque story, le pipeline suivait la même boucle :

préciser le comportement attendu ;
écrire les tests avec une approche TDD ;
implémenter la fonctionnalité ;
lancer une review séparée ;
exécuter les tests unitaires et d’intégration ;
tester le parcours E2E dans Chrome ;
contrôler visuellement l’interface ;
corriger automatiquement jusqu’à validation.

Le lendemain, la première version fonctionnelle correspondant au périmètre cadré était livrée. Elle n’était pas figée pour autant. L’usage réel a fait émerger une dizaine de nouvelles stories dès le lendemain.

Pourquoi la QA devient plus importante avec les agents

Plus un run autonome est long, plus la QA doit être forte. Sans critères précis, tests et contrôle visuel, une erreur commise au début peut contaminer plusieurs heures de travail.

Le rôle du développeur évolue : il code moins directement certaines fonctionnalités, mais il doit mieux définir les contrats, les cas alternatifs et les preuves attendues. L’autonomie des agents dépend donc de la qualité du système de validation.

Le coût des tokens face au temps humain

Le projet a traité plus de quatre milliards de tokens, dont une très grande partie provenait des lectures de cache. Ce volume ne doit pas être confondu avec quatre milliards de nouveaux tokens facturés au tarif standard.

La bonne comparaison porte sur ce qui a été livré : 20 stories, leurs tests, leurs reviews, les parcours E2E et les corrections. Un volume élevé de tokens peut sembler excessif si l’on regarde uniquement la consommation. Il devient plus lisible lorsqu’on le compare au temps humain nécessaire pour développer, tester et revoir le même périmètre.

La méthode Killer SaaS cherche précisément cet équilibre : assez de préparation et de QA pour transformer de longues sessions agentiques en produit fonctionnel, plutôt qu’en accumulation de code fragile.

Découvre VillaSlot et regarde la démonstration complète du workflow.