Château Tire-Bouchon
Château Tire-Bouchon est un domaine viticole basque (AOP Irouléguy) qui n'existe pas. Je l'ai construit pour montrer ce qu'un logiciel peut faire pour un métier physique : une map 3D du domaine où tout bouge selon les données, et le back-office complet derrière, sur une seule base Supabase.
Ouvrez la démo : vous recevez votre propre copie du domaine, sans compte. Les entreprises, les noms et les chiffres sont tous inventés. Les intégrations qui parleraient au monde extérieur tournent en mode simulé, et l'écran le dit.
Le défi
Beaucoup de logiciels de gestion se ressemblent : des listes, des formulaires, des onglets. Ils font le travail, mais on n'y voit pas l'entreprise. Pour un métier qui se passe dans un lieu (un chai, un atelier, un dépôt), j'ai voulu partir du lieu.
Un domaine comme celui-ci vit souvent avec des outils qui ne se parlent pas. Les commandes, le stock et les plannings vivent dans des fichiers Excel séparés. Les bouchons et les étiquettes manquent avant qu'on s'en rende compte. Les saisonniers des vendanges arrivent et repartent, avec leurs heures, leurs contrats et leurs badges. Et personne n'a la vue de la journée : qui est là, ce qui part aujourd'hui, quelle cuve demande de l'attention.
La solution
La map est une vue sur les mêmes tables que le back-office. Quand une commande avance dans le kanban, son colis avance sur la map. Quand une employée badge sa pause, son personnage part au fronton. Un clic sur un objet ouvre sa fiche, avec un lien vers l'écran complet du back-office.
Le back-office couvre le reste du métier : CRM, devis et commandes, stock, opérations, RH (badges, congés, feuilles de temps, salaires), finance avec les factures Factur-X (pas encore validées par un outil Factur-X officiel) et l'export FEC, messagerie, assistant IA et automatisations.
Les droits vivent dans la base. Chaque table a ses règles RLS (Row Level Security), et les écritures passent par des fonctions SQL qui vérifient le droit, appliquent la règle métier et écrivent l'événement dans la même transaction. Un écran mal codé ne peut pas contourner un droit. Les salaires sont dans une table à part, que seules la direction et les RH peuvent lire. La scène 3D est en React Three Fiber, avec de la géométrie procédurale : aucun fichier de modèle, chaque bâtiment, cuve ou personnage sort de formes simples.
J'ai écrit la spec, découpé le travail en phases, relu et testé chaque étape. Des agents de code IA ont écrit le code.
Résultats
Ces chiffres viennent du repo, comptés le 10 novembre 2026 : 30 migrations SQL rejouables, 70 tables Postgres, 238 règles RLS et 312 tests automatisés avec Vitest et Playwright. Sur une carte graphique de bureau (une RTX 4070 Super, Chromium en 1440 × 900), la map tourne à 60 images par seconde.
C'est une démo, pas un projet client. Elle prouve la construction et la méthode, pas un résultat business. La démo est en ligne : signez un devis, avancez une commande, dévoilez un salaire, le visiteur suivant retrouve un domaine propre. L'étude de cas complète est sur le site de la démo.
Fonctionnalités clés
- 01Une map 3D vivante : chaque objet est cliquable, et les données pilotent chaque animation
- 02Le back-office complet sur la même base : CRM, commandes, stock, RH, finance
- 03Les droits tenus par 238 règles RLS dans Postgres, pas par l'écran
- 04Une démo publique sans compte : chaque visiteur reçoit sa propre copie du domaine
Galerie
Disponible pour une nouvelle mission
Votre app, plus vite avec l'IA, et toujours à vous.
Plus de deux ans et demi de lead sur Odisei Play : une seule codebase sur iOS, Android et web, une release toutes les deux semaines, à deux développeurs, une designeuse et des agents IA. Ce rôle dans votre équipe, ou le setup IA qui rend ce rythme possible.