Outil Maquettes Live — Cahier des charges

Lemon Learning · v1 · 10 juin 2026 — duplication autonome du back-office pour démos, POC et prototypes par les équipes métier.

En une phrase. Un outil interne où n'importe quel collaborateur Lemon, sans compétence technique, crée en un clic une instance live isolée du back-office (stack complet + base de données dédiée), la pilote via une CLI web assistée par Claude Code, et la fait évoluer — chaque action étant versionnée automatiquement et réutilisable par les développeurs.

Convention de lecture : Décision = tranché par tes réponses · Proposition = à valider, je propose · Ouvert = à arbitrer.

1Contexte & objectif

Pourquoi cet outil, et ce qu'il doit permettre.

Aujourd'hui, monter un environnement de démonstration du back-office Lemon Learning dépend des équipes techniques. L'objectif est de supprimer cette dépendance : permettre aux équipes métier (commerce, CSM, produit, marketing) de créer en autonomie quasi immédiate une instance fonctionnelle pour préparer démonstrations, prototypes, POC ou environnements de présentation.

Principes directeurs

Autonomie : zéro intervention technique pour créer et utiliser une maquette.
Immédiateté : provisioning quasi instantané grâce à un pool d'instances préchauffées.
Crédibilité : chaque instance démarre avec des données réalistes (seed).
Simplicité « one-click » : créer un projet = un nom + un clic.
Réutilisabilité : le travail produit est versionné et récupérable par les développeurs.

2Architecture générale

Ce qu'est réellement une « instance », et comment elles cohabitent.

DécisionUne instance = un stack complet, pas un conteneur unique. Le back-office Lemon est composé de ~8 services câblés ensemble : reverse-proxy/TLS (Caddy), API+back-office PHP/Laravel, worker de jobs, PostgreSQL, Redis, Keycloak, lemonstats et l'antivirus (avapi).

DécisionTechnologie : Docker, avec orchestration Kubernetes si le besoin l'exige (montée en charge / multi-machines).

DécisionChaque instance est immuable : figée à la version stable du code au moment de sa création. Pas de mise à jour silencieuse qui casserait une démo en cours (voir §8 pour l'exception « tickbox »).

Isolation

Chaque projet est isolé à trois niveaux :

Applicatif : son propre stack de conteneurs, son propre sous-domaine.
Base de données : chaque instance a sa DB dédiée (jamais partagée).
Session CLI / Claude Code : exécution confinée au seul projet concerné.

DécisionFrontière de confiance : un collaborateur peut se connecter à n'importe quelle instance et tout y casser (c'est assumé, l'archivage est le filet de sécurité). En revanche, une session ne peut modifier que le projet auquel elle est rattachée — jamais les autres, ni le serveur hôte.

Orchestration — trajectoire proposée

PropositionDémarrer simple, complexifier seulement si la charge l'impose :

Phase 1 — Docker Compose scripté sur une machine unique : un projet compose par instance, piloté par un petit service de contrôle. Couvre les ~60 projets cibles (voir §11).
Phase 2 — Kubernetes uniquement quand on dépasse une machine (HA, > ~70-80 instances, ou besoin de self-healing).

Rationale : K8s sur une seule machine pour 60 démos est de la complexité prématurée. On garde l'option ouverte sans la payer trop tôt.

Schéma des flux

Du clic « créer » jusqu'au code versionné — chemin d'une maquette.

👤 Collaborateurs Lemon

Tout le monde, tous les droits — actions nominatives et loggées.

▼SSO Google

🖥️ Interface d'admin control-plane

Vue de tous les projets · création one-click · statut des instances · logs · alertes.

▼« Créer un projet » + nom

⚙️ Orchestrateur

Attribue une instance prête · reconstitue le pool en arrière-plan · surveille les états.

▼pioche une instance

🔥 Pool — 4 instances préchauffées

Alimenté en continu par :

⟵ images Docker pré-pull ⟵ DB clonée du « gold » anonymisé (TEMPLATE) ⟵ realm Keycloak pré-importé

▼attribution instantanée

📦 Instance active — stack isolé & immuable

frontbackjobsdbrediskeycloakstatsavapi

Deux accès :

🌐 Maquette web — SSO Keycloak ⌨️ CLI web (ttyd) ⟶ 🤖 Claude Code (jail projet)

▼auto-commit invisible après chaque modif

🔁 Versioning — forge isolée

1 dépôt par projet, commits automatiques. Passerelle « promouvoir vers GitLab Lemon » à la demande d'un dev.

En transverse : l'Observabilité (§10) branche sur le control-plane (statut/logs/alertes) ; la Sécurité (§9) est le jail qui entoure chaque session et le réseau de chaque stack.

3Cycle de vie des projets

Création instantanée, pool préchauffé, archivage, suppression.

Création

L'utilisateur clique sur « Créer un projet », saisit un nom. Le système attribue alors une instance disponible du pool, branche la base seed, génère les accès et rend l'environnement accessible en quelques secondes.

Pool d'instances préchauffées

Décision4 instances d'avance en permanence, déjà branchées sur la dernière version stable et sur une DB seed dédiée, prêtes à être attribuées instantanément. Dès qu'une est consommée, une nouvelle se recrée en arrière-plan pour maintenir le stock.

PropositionPour que la reconstitution du pool soit quasi-gratuite : images Docker pré-pull + DB clonée par CREATE DATABASE … TEMPLATE (ou snapshot de volume copy-on-write) + realm Keycloak pré-importé. Un nouveau stack rejoint le pool en ~20-60 s.

Expiration & archivage

DécisionUn projet est archivé automatiquement au bout d'1 an et demi sans modification, ou plus tôt si le nombre de projets explose.

DécisionLes archives sont supprimées automatiquement lorsque l'espace disque dépasse un seuil défini (purge des plus anciennes d'abord). L'archivage libère la RAM/CPU (stack éteint) ; l'archive ne conserve que la DB + le code versionné, compressés.

Le dimensionnement disque et la taille d'une instance (qui pilotent ce seuil) sont calculés en §11.

États d'un projet

pool (préchauffé) → actif → archivé (éteint, RAM libérée) → supprimé (purge disque)

4Interface d'administration

Authentification, vue des projets, droits, accès.

DécisionAccès via la SSO Google de Lemon Learning. Tout collaborateur authentifié a automatiquement accès, sans provisioning manuel des comptes.

Vue des projets

Depuis l'écran principal, tout utilisateur voit l'ensemble des projets : nom, créateur, statut de l'instance (voir §10), et un accès direct à l'environnement et à la session de travail.

Droits

DécisionPas de quotas, pas de rôles. Tout le monde voit tout et peut tout faire sur l'interface d'admin des instances. Le garde-fou n'est pas la permission mais la traçabilité : chaque action est loggée et nominative. La suppression n'est jamais directe — il faut d'abord archiver.

Sélection de projet — interface

PropositionRéutiliser le menu déclenchable par m dans tmux déjà en place sur dev0203.com pour basculer entre projets — rapide et éprouvé. À remplacer par une UI web plus propre, plus « user-friendly » et sécurisée si elle apporte un vrai gain pour des profils non techniques (le menu tmux peut rebuter un non-dev). À arbitrer après un premier test utilisateur.

5Environnement de travail : CLI web + Claude Code

Comment l'utilisateur pilote et modifie sa maquette.

DécisionChaque projet expose un lien vers une interface de type CLI dans le navigateur (HTML, hébergée sur le serveur), permettant d'exécuter des commandes et de piloter l'instance live. Une session Claude Code (hébergée sur le serveur) y est associée, avec proposition de bascule/continuité vers elle.

Technologie

PropositionRéutiliser le ttyd déjà déployé (ttyd.dev0203.com) comme terminal web, un par projet, avec Claude Code lancé dedans. Rester ouvert à mieux si une option plus propre/sécurisée émerge. La continuité « CLI → session » est gratuite : même conteneur, même workdir, dossier de session Claude persisté sur volume.

Expérience CLI sur mesure

Indications de lancement affichées dans la CLI (ex. « tape claude pour démarrer… »), adaptées à un public non technique.
Proposition Raccourci « mode dangereux » confiné : équivalent du lancement permissif, mais limité au projet en cours (écriture/exécution interdites hors du projet, sauf consultation de docs externes autorisée).
Crédits restants affichés dans l'interface si possible (consommation Claude visible par l'utilisateur).

Fichier mémoire de la session (`CLAUDE.md` par instance)

DécisionChaque instance embarque un fichier mémoire complet qui cadre le comportement de Claude Code :

reprend les bonnes pratiques de code de Pierre / Lemon ;
masque tous les détails techniques dans les réponses (sauf demande explicite contraire de l'utilisateur) ;
garantit des réponses compréhensibles par un non-technicien ;
respecte les guidelines, frameworks et la gate SonarQube de Lemon Learning ;
fait elle-même les choix techniques (peut poser des questions de haut niveau, jamais des questions techniques), en s'appuyant sur des guidelines pour rester cohérente d'une session à l'autre.

Effet recherché : l'utilisateur métier décrit un besoin en langage naturel ; la session tranche le « comment » seule, dans le respect des standards Lemon, et ne renvoie que du compréhensible.

Collaboration

DécisionCollaboration ouverte : plusieurs utilisateurs peuvent travailler sur un même projet ; tout le monde accède aux sessions de tous les projets. Pas de système de partage dédié nécessaire (l'accès est déjà universel). Pas d'historique des commandes CLI.

6Versioning & reprise par les développeurs

Tracer chaque changement sans bruit, et permettre aux devs de récupérer le code.

DécisionUn versioning GitLab est mis en place. Les commits se font automatiquement et en continu, de façon invisible pour l'utilisateur. Les développeurs reprendront ce code, en tout ou partie, à un moment — il faut donc un bon accès pour eux. Mélanger ces commits au GitLab produit de Lemon génèrerait trop de bruit.

PropositionForge isolée, dédiée aux maquettes.

Un namespace/groupe GitLab séparé (ex. groupe maquettes-live, idéalement une instance GitLab auto-hébergée sur le serveur — ou Gitea, plus léger — pour ne jamais polluer l'historique du dépôt produit).
Un dépôt par projet/instance. Un watcher commit + push après chaque modification de Claude Code, avec messages auto-générés. L'utilisateur ne voit rien.
Reprise par les devs : accès en lecture au groupe maquettes-live ; ils parcourent l'historique complet d'un projet et récupèrent ce qui les intéresse.
Passerelle « promouvoir vers le GitLab Lemon » : une action génère une branche/patch (ou MR) vers le vrai dépôt produit, à la demande — le bruit ne traverse que sur décision explicite d'un dev.

7Données : seed & anonymisation

D'où viennent les données de démo, et comment elles restent sûres.

DécisionUne seed unique a priori, mais versionnable (pour la maintenabilité dans le temps). Chaque instance a sa propre base, isolée. La seed est maintenue par l'admin serveur.

DécisionL'utilisateur ne peut pas « réinitialiser » son environnement, mais peut l'archiver. Si c'est simple à implémenter, il peut revenir sur d'anciennes versions (rollback léger).

Source & anonymisation

PropositionPartir du dump de production anonymisé (le mécanisme bin/db-anon existe déjà) pour obtenir une seed crédible, puis appliquer un traitement d'anonymisation automatique remplaçant par des données réalistes :

une liste de sociétés américaines + une liste de ~300 prénoms/noms américains, réinjectés par intervalles sur les enregistrements ;
objectif : si l'on se faisait hacker, aucune donnée client réelle ne fuiterait — tout en gardant une démo crédible.

Ce « gold » anonymisé devient le template Postgres cloné à chaque création (voir §3).

8Déploiement du code & mises à jour

Quelle version, et comment les instances suivent (ou non) le code.

OuvertBranche/version de référence pour « dernière version stable » : à confirmer (dernier tag de release vs master). Les instances étant immuables, une instance est épinglée à cette version au moment de sa création.

Mise à jour des instances

DécisionInstances non déployées (pool, non encore attribuées) : mises à jour automatiquement vers la dernière version stable.

DécisionInstances déployées (attribuées à un projet) : une case à cocher « Mettre à jour automatiquement l'instance », modifiable à tout moment. Accompagnée d'un texte pour/contre :

✅ Pour	⚠️ Contre
Bénéficie des derniers correctifs/fonctionnalités ; démo « à jour »	Risque de casser une démo stabilisée ; migrations DB à rejouer ; perte de reproductibilité

Par défaut décochée (cohérent avec l'immuabilité).

DécisionMigrations de base de données : l'interface propose plusieurs choix (ex. rejouer les migrations, conserver la version actuelle de la DB, repartir de la seed) au moment d'une mise à jour.

9🔒 Sécurité

Le point le plus sensible : donner un shell assisté par IA à des non-techniciens.

Le risque central. Une CLI web + Claude Code = capacité d'exécuter des commandes. Sans confinement, c'est une porte vers le serveur hôte, les autres projets et les secrets. Tout le modèle de sécurité repose donc sur le confinement par projet et la traçabilité, pas sur des permissions fines (il n'y en a pas — voir §4).

9.1 — Authentification (deux plans distincts)

DécisionOutil d'admin (liste des projets, création) → SSO Google Lemon Learning.

DécisionAccès aux environnements/maquettes → SSO via Keycloak. Pas d'exposition publique anonyme.

9.2 — Confinement des sessions

DécisionUne session (CLI / Claude Code) ne peut modifier que son propre projet. Le créateur peut se connecter à toute instance et tout y casser — mais jamais déborder vers un autre projet ou le host.

PropositionMise en œuvre par jail conteneur : utilisateur non-root, pas d'accès au socket Docker, réseau restreint au seul stack du projet, aucun accès aux secrets de prod ni aux clés d'infra. Le « mode dangereux » (§5) reste borné à ce périmètre, avec une seule exception : la consultation de docs externes.

9.3 — Protection des données

DécisionAnonymisation systématique de la seed (sociétés + noms US réalistes par intervalles, §7). Aucune donnée client réelle ne réside dans une maquette → une compromission ne fuite rien d'exploitable.

9.4 — Traçabilité & réversibilité

DécisionToutes les actions de l'interface d'admin sont loggées et nominatives. La suppression exige un archivage préalable (pas de destruction directe). Le versioning Git automatique (§6) conserve l'historique complet → tout est rejouable / auditable.

Surface Auth Confinement ───────────────────────────────────────────── Outil d'admin SSO Google tous droits, tout loggé Maquette (web) Keycloak SSO, non public Session CLI/IA héritée projet jail : projet courant uniquement (+ docs externes en lecture)

10Observabilité

Voir l'état, lire les logs, être alerté.

DécisionStatut de chaque instance visible dans l'interface (running / arrêtée / en provisioning / en erreur). Pas d'historique de métriques — un état courant, pas du time-series.

DécisionLogs accessibles depuis l'interface.

DécisionAlertes en cas d'échec de provisioning (le pool doit toujours se reconstituer ; tout échec doit remonter).

11Dimensionnement & coûts

Taille d'une instance · RAM/CPU comparées · machine pour ~60 projets.

11.1 — Taille disque d'une instance calcul demandé

Poste	Estimation	Note
Base PostgreSQL (clone du gold anonymisé)	~3 Go	copie complète ; réductible via volume copy-on-write
Copie de code éditable (pour Claude Code)	~1–2 Go	dépôt + dépendances ; mutualisable en read-only + overlay
Stockage média (library/image/vidéo)	~0,5 Go	seed surtout partagée en lecture seule, delta par instance faible
Couches conteneurs + logs + données Keycloak/Redis	~0,5 Go	images de base mutualisées (hors décompte)
Total par instance (planification)	≈ 5–6 Go	fourchette 4–8 Go — à confirmer par mesure réelle d'un stack
Archive (DB dump + code, compressés)	~2–3 Go	la DB compresse bien

60 actifs × 6 Go ≈ 360 Go + archives jusqu'au seuil de purge images de base partagées ≈ 10–20 Go

→ Un disque NVMe ≥ 1 To (idéalement 2×1 To) loge confortablement 60 instances actives + un volant d'archives. C'est ce volant qui déclenche la purge automatique (§3).

11.2 — RAM par instance & choix de la machine tableau demandé

Deux régimes selon qu'on mutualise ou non les services non critiques pour la démo (antivirus avapi ~1 Go, Keycloak ~0,5 Go, lemonstats) :

Stack complet ≈ 2,5 Go/instance Stack densifié (avapi/keycloak/stats partagés) ≈ ~1 Go/instance

RAM machine	Instances en stack complet (~2,5 Go)	Instances densifiées (~1 Go)	Verdict pour 60
64 Go	~22	~50	❌ insuffisant
128 Go	~48	~115	⚠️ OK seulement si densifié
★ 192 Go	~70	~180	✅ 60 stacks complets + marge
256 Go	~95	~240	✅ confort total + croissance

CPU : 60 démos majoritairement inactives, pics PHP à l'affichage → un EPYC 24–32 c / 48–64 t absorbe largement. La RAM est la contrainte limitante, pas le CPU.

« 60 projets simultanés sur une machine, est-ce réaliste ? »

Oui, sur un seul Dedibox correctement dimensionné :

En stack complet → machine 192–256 Go (EPYC 24c+, 2×1 To NVMe). C'est disponible chez Dedibox pour ~230–320 €/mois HT.
En stack densifié → 128 Go suffit (~180–230 €/mois), au prix d'un effort d'ingénierie (mutualiser avapi/keycloak/stats).

Au-delà de ~70–80 instances, ou pour de la haute dispo, c'est le moment de passer en multi-machines + Kubernetes (§2, phase 2).

PropositionCible recommandée : un Dedibox Core EPYC 192–256 Go, 2×1 To NVMe (~230–320 €/mois HT) pour héberger 60 instances en stack complet, RAM toujours prête (pool de 4 inclus). Soit ~4–5 €/instance/mois. À comparer : sur un cloud usage-based (type Railway), 60 stacks toujours allumés coûteraient un ordre de grandeur au-dessus.

12Questions ouvertes restantes

Le minimum encore à trancher pour figer le CDC.

Version de référence du code « stable » : dernier tag de release ou master ? (§8)
Forge isolée : GitLab auto-hébergé dédié, groupe séparé sur le GitLab existant, ou Gitea léger ? (§6)
UI de sélection de projet : on garde le menu tmux m, ou on investit dans une UI web dédiée pour les non-techs ? (§4)
Seuil de purge disque des archives : à fixer une fois la taille réelle d'instance mesurée (§11.1).
Stack complet vs densifié : accepte-t-on l'effort de mutualisation (avapi/keycloak) pour tenir sur 128 Go, ou on prend direct 192–256 Go ? (§11.2)
Affichage des crédits Claude : faisabilité technique à confirmer côté API/quota (§5).

Sources : code ~/projects/lemon-learning/back (docker-compose, bin/db-anon, Makefile) · infra devbox-infra (Traefik, cloudflared, ttyd) · réponses de Pierre (10 juin 2026). Les valeurs de taille/RAM sont des ordres de grandeur à valider par mesure d'un stack réel.
CDC v1 — Maquettes Live · Lemon Learning.