VillaSlot et ShipSaaS : l’architecture qui permet aux agents IA de livrer sans produire du code spaghetti
Mike Codeur
Voir la masterclass complète de 50 minutes
Neuf heures de run autonome, puis une question légitime
VillaSlot a été construit pendant un run autonome de neuf heures. Vingt user stories ont été traitées dans cette séquence. La première vidéo montrait surtout la vitesse d’exécution : un agent peut prendre un périmètre conséquent, avancer pendant plusieurs heures et produire une application qui fonctionne.
Une réaction est revenue chez plusieurs développeurs : « C’est du vibe code. » La critique mérite mieux qu’une réponse défensive. Une interface qui tourne ne dit rien, à elle seule, sur la structure du projet, la sécurité des accès ou la capacité à modifier le produit six mois plus tard. Il faut ouvrir le capot.
La vitesse ne prouve pas la qualité
Un agent rapide peut écrire du bon code comme du mauvais code. La durée du run ne permet pas de trancher. La qualité se juge dans les choix d’architecture, les frontières entre responsabilités, les tests et les contrôles appliqués avant de considérer une story comme terminée.
ShipSaaS fournit un cadre Full Stack déjà organisé. L’agent n’a pas à réinventer la forme générale de l’application à chaque user story. Il doit travailler dans des limites connues. Ces limites réduisent les décisions improvisées, rendent les changements plus faciles à relire et donnent aux tests des points d’entrée stables.
Une architecture multitenant pensée dès la base
VillaSlot est une application multitenant. Plusieurs organisations utilisent le même produit, tout en conservant des espaces et des données séparés. Cette contrainte change la manière de concevoir presque chaque opération. Une requête valide ne doit pas seulement venir d’un utilisateur authentifié. Elle doit aussi être exécutée dans le contexte de la bonne organisation.
Authentification, utilisateurs et organisations
L’authentification établit l’identité de la personne qui effectue une action. Cette identité est ensuite reliée à un utilisateur applicatif et à une organisation. L’organisation devient une frontière fonctionnelle pour les lectures et les écritures.
Cette distinction évite un raccourci dangereux : considérer qu’être connecté suffit pour accéder à une ressource. Dans un SaaS multitenant, l’application doit vérifier le contexte organisationnel à chaque endroit pertinent. Un identifiant de ressource transmis par l’interface ne constitue jamais une autorisation.
L’isolation des données n’est pas un filtre d’interface
Masquer un élément dans l’interface ne protège aucune donnée. L’isolation doit être appliquée côté serveur, au moment où l’opération est validée et où la persistance est interrogée. Le contexte d’organisation accompagne donc le parcours de la requête.
Trois couches avec des responsabilités distinctes
ShipSaaS sépare le système en trois couches : Présentation, Services et Persistance. Les noms sont classiques. Leur application concrète fait la différence.
Présentation
La couche Présentation gère ce que l’utilisateur voit et déclenche les actions. Elle collecte les entrées, affiche les états utiles et transmet une intention au serveur. Elle ne doit pas décider seule des règles métier ni construire un accès direct à la base de données.
Services
La couche Services porte les cas d’usage. Elle reçoit une demande, vérifie les conditions nécessaires, applique les règles métier et orchestre les opérations. C’est également là que le contexte authentifié et l’appartenance à une organisation prennent leur sens opérationnel.
Persistance
La couche Persistance s’occupe de lire et d’écrire les données. Elle encapsule la manière dont le stockage est interrogé et renvoie des résultats exploitables aux services. Elle ne doit pas décider de l’expérience utilisateur.
Le parcours d’un cas d’usage, de l’écran à la base
Prenons le parcours générique d’une action effectuée dans VillaSlot. L’utilisateur déclenche une opération depuis l’interface. La couche Présentation collecte les données nécessaires et envoie la demande. Le serveur identifie l’utilisateur authentifié, retrouve son contexte d’organisation, puis transmet une commande structurée à la couche Services.
Le service contrôle les préconditions et les règles métier. Il ne fait pas confiance à l’identifiant reçu comme preuve d’accès. Il combine la ressource demandée avec le contexte de l’organisation, puis appelle la Persistance. Celle-ci exécute une lecture ou une écriture limitée à ce périmètre. Le résultat remonte ensuite vers le service, qui le transforme en réponse utile, puis vers la Présentation, qui met l’écran à jour.
Donner des règles aux agents, pas seulement une tâche
Un agent de code ne doit pas recevoir uniquement une user story. Il lui faut les conventions du projet, les limites architecturales et une définition vérifiable de « terminé ». Sinon, il optimise naturellement pour le résultat le plus visible : faire passer le scénario principal.
Les règles imposent notamment de respecter les couches, de réutiliser les chemins existants, de préserver le contexte multitenant et de ne pas contourner l’authentification. Elles demandent aussi de traiter les erreurs et de vérifier l’effet réel d’un changement. L’objectif n’est pas de brider l’agent. Il s’agit de réduire l’espace où une solution rapide peut devenir incohérente avec le reste du système.
La boucle de livraison qui encadre chaque story
La production ne s’arrête pas quand le code compile ou quand l’écran semble correct. La boucle part des critères d’acceptation. Ils transforment la demande en comportements observables et évitent qu’un agent déclare la tâche terminée sur une interprétation vague.
Vient ensuite le TDD : écrire ou adapter les tests, constater le besoin, implémenter le comportement attendu, puis nettoyer sans casser la preuve. Une review séparée examine le changement avec un autre regard. Cette séparation compte, car l’auteur d’une solution, humain ou agent, voit plus facilement ce qu’il voulait écrire que ce qu’il a réellement écrit.
Les tests automatisés sont alors exécutés. Le parcours est aussi vérifié en E2E dans Chrome, afin de contrôler l’intégration réelle entre l’interface, le serveur et les données. Un contrôle visuel complète cette étape. Un test fonctionnel peut réussir alors que l’écran est tronqué, illisible ou incohérent.
Si un problème apparaît, l’agent ne se contente pas de le signaler. La boucle d’auto-fix le renvoie vers le changement, puis les vérifications sont relancées. Le chemin complet est donc : critères, TDD, review séparée, tests, E2E Chrome, contrôle visuel, correction automatique, puis nouvelle validation.
Ce que cette méthode ne garantit pas
Aucune architecture ne rend un agent infaillible. Les règles peuvent être incomplètes, les tests peuvent oublier un cas et une review peut manquer un défaut. Une base bien structurée demande aussi de l’entretien à mesure que le produit évolue.
Le run autonome de neuf heures ne remplace donc ni la responsabilité technique ni les décisions produit. Il montre qu’un agent peut exécuter vite lorsqu’il travaille dans un système qui rend les bons chemins plus évidents et les écarts détectables. Il faut toujours surveiller les frontières d’autorisation, enrichir les tests et remettre en cause les choix qui ne tiennent plus.
Ouvrir l’architecture plutôt que débattre sur une étiquette
Qualifier VillaSlot de « vibe code » ne permet pas d’évaluer le résultat. Les questions utiles sont concrètes : les responsabilités sont-elles séparées ? Le contexte d’organisation suit-il chaque opération ? Les données d’un tenant sont-elles isolées ? Les stories passent-elles par une boucle de preuve et de correction ?
La première vidéo montrait la vitesse. Cette masterclass montre les mécanismes qui empêchent cette vitesse de produire un amas de code fragile. ShipSaaS apporte le cadre Full Stack, VillaSlot met ce cadre à l’épreuve sur un vrai produit, et les agents avancent avec des règles contrôlables.