Étude de cas

Une entreprise qu'on regarde travailler.

Château Tire-Bouchon n'existe pas. C'est un domaine viticole basque inventé pour montrer ce qu'on peut construire pour un métier physique : une map 3D du site où tout bouge selon les données, et le back-office complet qui tourne derrière.

Chiffres relevés dans le dépôt du projet le 10 novembre 2026.

12345

Le contexte

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 une activité qui se passe dans un lieu (un chai, un atelier, un dépôt), j'ai voulu partir du lieu.

Le domaine est fictif, avec ses employés, ses clients, ses cuvées et ses chiffres. L'humour reste dans les noms : la cuvée « Gueule de Bois Noble », le restaurant Le Piment Rieur, le transporteur Palette & Fils. Le logiciel, lui, est construit comme un vrai : base de données, droits, tests, documentation.

Le problème type d'un domaine viticole

Un domaine de vingt personnes vit avec des outils qui ne se parlent pas.

• Les commandes, le stock et les plannings vivent dans des fichiers Excel, chacun le sien.
• Au rush de fin d'année, une commande d'entreprise peut dormir dans une boîte mail jusqu'à ce que le client relance.
• Le stock de bouteilles se compte à peu près. Celui des matières sèches (bouchons, étiquettes, cartons) se découvre le jour où il manque.
• Les saisonniers des vendanges arrivent et repartent, avec leurs heures, leurs contrats et leurs badges.
• Personne n'a la vue d'ensemble : qui est là, ce qui part aujourd'hui, quelle cuve demande de l'attention.

La solution : une map et un back-office sur les mêmes données

La map n'est pas une maquette décorative. C'est une vue sur les mêmes tables que le back-office. Quand une commande avance dans le kanban, le dossier se déplace sur la map. Quand un employé badge sa pause, son personnage part au fronton. Chaque objet visible est cliquable et ouvre sa fiche, avec un bouton vers l'écran complet du back-office.

Le back-office couvre le reste du métier : clients et devis guidés, commandes, planning, stock et fournisseurs, RH (présence, congés, feuilles de temps, salaires, recrutement), factures et relances, messagerie, assistant IA, automatisations, rôles et journal d'audit. Chaque action courante se fait en un clic, avec un contenu pré-rempli qu'on relit plutôt qu'on écrit.

Les choix techniques

Next.js 15 et Supabase

L'application est un seul projet Next.js 15 (App Router, TypeScript strict). Les pages lisent les données côté serveur, avec la session de l'utilisateur. Supabase fournit Postgres, l'authentification, le stockage de fichiers et Realtime.

Les droits dans la base, pas dans l'écran

Chaque table a ses règles RLS (Row Level Security) : une personne ne lit que les lignes de son organisation, et seulement les modules que son rôle autorise. 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 donc pas contourner un droit.

Un journal d'événements partagé

Toute action écrit une ligne dans activity_events. La map s'abonne à ce journal et aux tables d'état par un seul canal Realtime filtré sur l'organisation. Les notifications, les compteurs et les animations en découlent. Les KPI sont des vues SQL : la map et le tableau de bord lisent la même définition.

React Three Fiber et de la géométrie procédurale

La scène est construite en React Three Fiber, sans aucun fichier de modèle 3D. Bâtiments, cuves, personnages et véhicules sortent de formes simples et de textures dessinées au canvas. Le plan du site est un JSON versionné en base, modifiable dans un éditeur intégré (glisser, tourner, lier un objet à un employé ou à une cuve, publier). Le mouvement passe par un moteur pur frame(dt), testé sans navigateur.

Une configuration par secteur

Le vocabulaire, les zones, les étapes d'un dossier, les KPI et le scénario de démo viennent d'un fichier de configuration validé par Zod, pas de textes codés dans les composants. Passer à un garage, c'est surtout écrire ce fichier et dessiner le plan.

Des tests à chaque couche

Vitest couvre les règles métier pures (TVA, arrondis, soldes de congés, alertes de budget) et, contre une base Supabase locale, les fonctions SQL et les règles RLS. Playwright pilote les parcours complets dans un vrai navigateur et refuse toute erreur dans la console.

Le code a été écrit avec des agents de code IA, sous ma direction : spécification, découpage en phases, revue et tests à chaque étape.

Les défis, et ce qui a marché

La performance de la scène

Le navigateur des tests automatiques n'a pas de carte graphique : il dessine la scène en logiciel, à environ une image par seconde. Les tests accélèrent donc l'horloge du scénario (?scenarioSpeed) et de la scène (?animationSpeed) au lieu de relâcher leurs contrôles. Sur une vraie carte graphique, la map tourne à 60 images par seconde (1440 × 900, Chromium sur une RTX 4070 Super de bureau). Pour tenir ce rythme : des géométries et des matériaux mis en cache par clé, les 40 barriques regroupées en deux maillages instanciés, un pas de temps plafonné à 50 ms.

La synchronisation en temps réel

Règle de départ : la base dit où se trouve chaque chose (zone, statut, étape), le navigateur anime le trajet et n'écrit jamais de position. Les tests mesurent le chemin Realtime sous les droits de l'utilisateur : entre 62 et 521 ms pour qu'une commande signée arrive, sur six mesures.

Un piège est apparu en route. Les comptes du personnel travaillaient dans l'organisation modèle que la démo publique copie. Le simulateur et leurs actions la modifiaient, et chaque visiteur recevait un domaine un peu différent. Le personnel a maintenant sa propre organisation, le modèle ne change plus que par les migrations, et un test vérifie qu'il reste identique après une simulation.

Les droits sur les salaires

Les salaires vivent dans une table à part, que seules la direction et les RH peuvent lire. Même pour elles, un montant ne s'affiche qu'après un clic, par une fonction qui vérifie le rôle et inscrit la consultation au journal d'audit. Les tests se connectent comme employé ou commerciale et vérifient que rien ne revient. Dans la démo publique, le visiteur voit des montants fictifs, floutés par défaut.

Ce qui changerait pour un vrai client

Ici, tout ce qui sort de l'application tourne en mode simulé, et l'écran le dit. Pour une vraie entreprise :

• Les vraies intégrations : mail, agenda et fichiers Google Workspace ou Microsoft 365, l'outil comptable, la badgeuse, la signature électronique. Chacune demande ses accès et ses tests.
• Les vraies données : reprise des fichiers Excel et des outils en place, plan des locaux dessiné dans l'éditeur, vocabulaire et étapes du métier.
• L'hébergement : un projet Supabase en région Paris, le site sur Vercel, des sauvegardes et une surveillance. Les données restent en Europe.
• La maintenance : mises à jour de sécurité, corrections, petites évolutions au fil des besoins, et quelqu'un à appeler quand quelque chose bloque.
• Des points encore ouverts dans la démo : la facture électronique n'est pas validée par un outil Factur-X officiel, et la performance sur un ordinateur portable reste à mesurer.

Une question sur votre propre activité ? Lire aussi à quoi ça sert pour une entreprise.