# LÉZIDÉJOU — Architecture de la plateforme jeux et applications Version 3.0 — 11 août 2026 > **Note de renommage.** LÉZIDÉJOU est le nouveau nom de la plateforme précédemment documentée sous le nom ETBEUR. Les anciennes références à ETBEUR ne sont conservées dans ce document que lorsqu'elles sont nécessaires à la traçabilité du renommage ou qu'elles appartiennent à un nom propre ou à une URL historique. ## 1. Statut et hiérarchie documentaire Ce document définit la trajectoire technique à moyen et long terme. Il ne donne pas, à lui seul, l'autorisation d'implémenter une phase. La hiérarchie normative est la suivante : 1. `docs/implementation/phase-1-execplan.md` est le plan normatif et vivant de la phase 1 ; 2. le présent document définit la trajectoire d'architecture ; 3. `docs/reference/charte-graphique-structure-lezidejou.md` définit l'identité, les contenus et l'expérience publique ; 4. les fichiers `AGENTS.md` définissent les règles de travail et de sécurité, mais ne constituent pas une roadmap. En cas de contradiction pendant la phase 1, l'ExecPlan prévaut. Toute décision non couverte par l'ExecPlan doit être soumise à validation avant modification applicative. ## 2. Décision exécutive LÉZIDÉJOU est la marque ombrelle et le portail central. La trajectoire cible est un **monolithe modulaire Laravel 13 sur PHP 8.4** réunissant progressivement : - le portail éditorial ; - GoodGasoilPrice ; - Menu Planner ; - Belote Pro ; - Maths & Îles. LivraSign reste une application Laravel indépendante, avec son propre dépôt, sa base, son domaine, ses fichiers, ses secrets et son cycle de publication. La progression est volontaire : la phase 1 crée uniquement le portail et les domaines techniques qui lui sont réellement utiles. Elle n'intègre aucun code métier provenant des dépôts sous `sources/` et ne crée aucun module métier vide pour anticiper une migration future. ## 3. Principes structurants - Un seul dépôt applicatif central : `LEZIDEJOU-platform/`. - Les dépôts sous `sources/` restent des sources de référence en lecture seule jusqu'à leur phase de migration respective. - Les nouvelles expérimentations actives sont isolées sous `prototypes//` et ne sont créées ou modifiées que sur demande explicite. - `sources/` et `prototypes/` sont des notions techniques internes qui ne doivent pas être exposées comme catégories publiques. - Un module n'entre dans le monolithe central qu'avec son code métier réel, ses tests et un plan de migration validé. - Les visiteurs peuvent découvrir les projets et utiliser les expériences gratuites sans compte public. - Un compte LÉZIDÉJOU commun n'est introduit que lorsqu'une sauvegarde, une synchronisation ou une fonction personnelle le justifie. - Le seul accès authentifié de la phase 1 est l'administration Filament. - Filament est réservé aux administrateurs et protégé par TOTP obligatoire. - Le lancement doit rester compatible avec un hébergement Web OVHcloud simple. - Redis, Horizon, Docker, VPS, workers permanents, Stripe et microservices restent hors périmètre tant qu'un besoin mesuré ne les justifie pas. - Aucune infrastructure future ne doit être simulée dans le code avant d'être utile. - Aucun contenu, lien, logo, screenshot ou visuel fictif n'est présenté comme réel. - Aucun formulaire de contact, traqueur, outil analytique ou mécanisme de consentement n'est ajouté sans besoin validé. ## 4. Périmètre applicatif par horizon | Élément | Phase 1 | Trajectoire cible | Déploiement cible | |---|---|---|---| | Portail LÉZIDÉJOU | Pages éditoriales et administration | Cœur éditorial du monolithe | `lezidejou.fr` après validation du domaine | | Labo | Non implémenté | Catalogue de prototypes réels et accessibles | Portail, démonstration intégrée ou destination autonome selon chaque prototype | | GoodGasoilPrice | Fiche éditoriale uniquement | Module `FuelPrice` | Laravel central, route `/applications/prix-carburant` | | Menu Planner | Fiche éditoriale uniquement | Module `MenuPlanner` | Laravel central, route `/applications/menu-planner` | | Belote Pro | Fiche éditoriale uniquement | Module `Belote` | Laravel central, route `/jeux/belote-pro` | | Maths & Îles | Fiche éditoriale uniquement | Module `MathIslands` | Laravel central, route `/jeux/maths-iles` | | LivraSign | Fiche éditoriale, lien seulement si validé | Application indépendante | Domaine officiel propre, à confirmer | Les routes fonctionnelles de la table sont réservées ; elles ne doivent pas être implémentées pendant la phase 1. ## 5. Architecture du monolithe modulaire Architecture logique cible, à créer progressivement : ```text LÉZIDÉJOU — Laravel 13 ├── Core │ ├── Identity │ ├── Administration │ ├── Seo │ ├── Content │ └── Shared ├── Domain │ ├── Portal │ ├── FuelPrice # phase de migration ultérieure │ ├── MenuPlanner # phase de migration ultérieure │ ├── Belote # phase de migration ultérieure │ └── MathIslands # phase de migration ultérieure └── Frontend ├── Blade ├── Livewire # seulement lorsqu'un besoin réel le justifie └── React / TypeScript # circonscrit aux jeux migrés ``` Pendant la phase 1, seuls les domaines prévus par l'ExecPlan sont créés. Le schéma ci-dessus décrit une trajectoire, pas une arborescence à générer d'avance. ### Règles de dépendance 1. Un domaine ne lit ni n'écrit directement les tables d'un autre domaine. 2. Le partage passe par une interface ou un service central réellement utilisé. 3. Les routes, tables, événements et clés de configuration propres à un domaine sont préfixés. 4. Chaque domaine possède ses tests. 5. Une fonction ne rejoint le cœur partagé que si au moins deux domaines l'utilisent réellement. 6. Les contrôleurs restent fins et la validation est effectuée côté serveur. 7. Les composants frontend ne constituent jamais une frontière de sécurité. 8. Laravel n'impose pas cette organisation : elle doit rester simple, lisible et proportionnée. ## 6. Routes et navigation ### Routes éditoriales de la phase 1 ```text / /projets /projets/{slug} /projets/good-gasoil-price /projets/menu-planner /projets/belote-pro /projets/maths-iles /projets/livrasign /jeux /musique /boutique /a-propos /mentions-legales /confidentialite /contact # uniquement si une méthode publique est validée /admin ``` `/jeux` est une entrée directe vers les projets de type jeu. Elle ne devient un onglet principal que lorsque deux jeux publics et maintenus le justifient. ### Routes fonctionnelles réservées ```text /applications/prix-carburant /applications/menu-planner /jeux/belote-pro /jeux/maths-iles ``` Ces routes ne sont pas canoniques en phase 1 et ne doivent pas être créées avant l'intégration de leur métier. Les anciens scénarios de sous-domaines applicatifs ne sont plus la trajectoire retenue. ### Routes éditoriales futures du Labo ```text /labo /labo/{slug} ``` Ces routes sont documentées mais ne sont ni créées ni liées pendant la phase 1 initiale. Elles seront implémentées lorsqu'au moins un prototype réel, accessible et suffisamment présentable justifiera la rubrique. ### Navigation initiale - Projets - Musique - Boutique - À propos Le mot-symbole LÉZIDÉJOU renvoie vers l'accueil. LivraSign figure dans le catalogue des projets et non dans un onglet principal isolé. Les pages légales et le contact éventuel appartiennent à la navigation secondaire. La navigation cible pourra devenir `Projets`, `Labo`, `Musique`, `Boutique`, `À propos`. L'entrée `Labo` reste absente tant qu'aucun prototype publiable n'est disponible. ## 7. Phase 1 : socle publiable sans métier migré La phase 1 comprend : - le portail éditorial rendu côté serveur ; - un catalogue typé des cinq projets ; - les pages, routes et métadonnées réelles prévues par l'ExecPlan ; - l'identité visuelle ; - le SEO technique et l'accessibilité ; - une administration Filament réservée aux administrateurs ; - TOTP obligatoire et codes de récupération ; - la validation SQLite puis MySQL, ou MariaDB si ce moteur représentatif est explicitement retenu, prévue par l'ExecPlan ; - les tests, audits et documentation nécessaires. La phase 1 exclut explicitement : - toute copie ou intégration du métier des dépôts sources ; - les modules `FuelPrice`, `MenuPlanner`, `Belote` ou `MathIslands` vides ; - les routes fonctionnelles réservées ; - la création technique du Labo, ses routes, son modèle de données et ses prototypes ; - un compte public ; - paiements, Stripe, abonnements et droits premium ; - Redis, Horizon, workers permanents, Docker, VPS et microservices ; - analytics, trackers, pixels, cookies non essentiels et bannière de consentement ; - formulaire de contact sans méthode publique validée ; - déploiement et modification de production. ## 8. Identité, comptes et administration ### Phase 1 Le seul utilisateur authentifié est un administrateur Filament. L'accès au panel `/admin` exige : - un compte marqué administrateur ; - une authentification par session Laravel ; - un TOTP obligatoire, présenté sous la marque `LÉZIDÉJOU` ; - le secret TOTP et les codes de récupération chiffrés au repos ; - les champs sensibles masqués à la sérialisation ; - aucune inscription publique. ### Évolution future Lorsqu'une première fonction personnelle est prête, un compte commun pourra être ajouté : ```text Compte LÉZIDÉJOU └── User ├── Belote : statistiques et sauvegardes ├── Maths & Îles : profils enfants et progression └── Menu Planner : préférences, favoris, frigo et menus ``` Un enfant ne doit pas avoir besoin d'une adresse électronique. Les profils Maths & Îles appartiennent à un compte parent. Chaque donnée personnelle est rattachée à son propriétaire et protégée par une Policy avant ouverture publique. ## 9. Autorisation et sécurité - Gates pour une capacité globale, notamment l'accès au panel. - Policies pour les ressources appartenant à un utilisateur. - Validation serveur de la propriété et des entrées. - Aucun identifiant ou booléen reçu du navigateur n'est digne de confiance. - Un simple champ `is_admin` suffit tant qu'il n'existe qu'un rôle réel. - Aucun package de rôles n'est ajouté par anticipation. - Les contenus anonymes temporaires utilisent une session ou un identifiant non devinable et expirant. - Les secrets restent hors Git ; les clés existantes ne sont jamais remplacées silencieusement. ## 10. Monétisation future La logique métier ne dépendra pas directement d'un prestataire de paiement. Le domaine demandera un droit fonctionnel ; une couche dédiée décidera si ce droit existe. ```php $entitlements->has($user, 'belote.premium'); ``` Les modèles `products`, `orders`, `order_items` ou `entitlements` ne seront créés qu'au premier besoin payant validé. Stripe et Laravel Cashier restent hors périmètre jusqu'à validation du produit, du prix, de la fiscalité et du prestataire. Le serveur reste l'autorité pour les paiements, droits, statistiques officielles, classements et sauvegardes cloud. Un indicateur reçu par React ne protège aucune fonction à lui seul. ## 11. Choix techniques par horizon | Sujet | Phase 1 / lancement | Évolution si besoin mesuré | |---|---|---| | PHP | 8.4 | Version maintenue compatible | | Framework | Laravel 13 | Montée de version planifiée | | Pages éditoriales | Blade SSR | Maintien tant qu'adapté | | Administration | Filament 5 | Rôles plus fins si besoin réel | | Base | SQLite pour le bootstrap et les tests compatibles ; MySQL de référence, ou MariaDB explicitement retenu, pour la validation représentative | Service dédié si charge ou volume | | Sessions/cache | Base ou fichier selon validation | Redis si charge ou distribution | | Queue | `sync` par défaut | Base + worker, puis Redis/Horizon si nécessaire | | Frontend des jeux | Aucun métier en phase 1 | React/TypeScript lors des migrations | | Déploiement | Hébergement Web OVHcloud simple envisagé | Offre supérieure selon mesures | | Docker/VPS | Hors périmètre | Seulement si les contraintes l'exigent | Les caractéristiques exactes de l'offre OVHcloud, les versions PHP et MySQL ou MariaDB disponibles, SSH, CRON, sauvegardes et limites doivent être vérifiées au moment du choix et avant toute production. SQLite ne suffit pas à valider une compatibilité annoncée avec MySQL. Aucune page commerciale observée antérieurement ne vaut garantie contractuelle actuelle. ## 12. Trajectoire GoodGasoilPrice GoodGasoilPrice doit devenir le domaine `FuelPrice` du Laravel central, pas une application durablement déployée sur un sous-domaine indépendant. Avant migration et publication : - auditer le dépôt source sans le modifier ; - déplacer les accès `env()` vers la configuration ; - harmoniser TTL réel et date affichée ; - documenter les fournisseurs de données ; - conserver la dernière valeur valide et sa date en cas d'indisponibilité ; - tester les appels sortants depuis l'hébergement retenu ; - afficher un avertissement sur la nature informative de l'estimation ; - revoir périodiquement les paramètres fiscaux et réglementaires ; - rétablir et exécuter les tests pertinents. La route fonctionnelle cible est `/applications/prix-carburant`. Avant sa phase de migration, seule la fiche `/projets/good-gasoil-price` est prévue. ## 13. Trajectoire Menu Planner Menu Planner doit devenir le domaine `MenuPlanner` du Laravel central, pas une application durablement déployée sur un sous-domaine indépendant. ### Audit historique du 8 août 2026 Les éléments ci-dessous proviennent d'une inspection antérieure et ne constituent pas une vérification du 11 août 2026 : - archive observée sous Laravel 13, Livewire 4 et Filament 5 ; - base de développement SQLite ; - 36 classes PHP dans `app/`, 4 composants Livewire, 5 services métier, 4 ressources Filament et 46 déclarations de tests ; - tables métier relevées : `allergens`, `categories`, `ingredients`, `ingredient_allergen`, `recipes`, `category_recipe`, `recipe_ingredients`, `meal_plans`, `meal_plan_items` ; - absence alors constatée de connexion ou inscription publique ; - réussite des tests non démontrée dans l'environnement d'audit à cause d'extensions manquantes ; - build Vite non validé dans cet environnement. Ces constats devront être revérifiés en lecture seule au début de la phase de migration de Menu Planner. ### Principes de migration 1. Importer uniquement le métier et les migrations métier nécessaires. 2. Ne pas dupliquer les tables techniques `users`, `sessions`, `cache`, `jobs`, `job_batches` ou `failed_jobs`. 3. Réconcilier Composer, npm, Livewire, Filament, Tailwind et Vite avec le portail. 4. Préfixer routes, noms de routes et configuration. 5. Conserver une séparation claire entre le domaine et les autres modules. 6. Ajouter propriété et Policies avant toute donnée privée. 7. Exécuter les tests sur le moteur de production retenu. 8. Construire les assets depuis une installation propre. La route fonctionnelle cible est `/applications/menu-planner`. Avant cette migration, seule la fiche `/projets/menu-planner` est prévue. ## 14. Trajectoire Belote Pro Le moteur et l'interface pourront rester en React/TypeScript, intégrés au monolithe. Laravel apportera plus tard les services communs réellement nécessaires. Avant publication : - auditer et fiabiliser les règles de Belote et de Coinche ; - couvrir le moteur et les scores par des tests unitaires ; - séparer moteur, coups légaux, scores, annonces, enchères, IA et interface ; - permettre une partie immédiate sans compte ; - conserver d'abord une sauvegarde locale robuste. La route fonctionnelle cible est `/jeux/belote-pro`. Avant cette migration, seule la fiche `/projets/belote-pro` est prévue. ## 15. Trajectoire Maths & Îles Le gameplay pourra rester en React/TypeScript, intégré au monolithe. Les profils parents/enfants et la progression cloud viendront seulement avec un besoin validé. Avant publication : - corriger les erreurs TypeScript et retirer les dépendances obsolètes ; - valider build, lint, typecheck et tests ; - fiabiliser les sauvegardes locales et leurs migrations ; - améliorer les explications pédagogiques ; - modéliser la progression par compétence ; - vérifier le contenu contre les programmes scolaires applicables au moment de la publication. La route fonctionnelle cible est `/jeux/maths-iles`. Avant cette migration, seule la fiche `/projets/maths-iles` est prévue. ## 16. LivraSign reste indépendant LivraSign traite un domaine métier distinct et conserve : - son dépôt privé ; - son application Laravel ; - son domaine officiel, à confirmer avant publication du lien ; - sa base et ses fichiers ; - son `.env` et ses sauvegardes ; - son cycle de recette et de production. La fiche `/projets/livrasign` raconte le projet. Une fois le domaine officiel validé, elle redirige ou mène vers ce domaine sans reproduire le produit dans le monolithe. Le partage éventuel d'un abonnement OVHcloud ne signifie jamais partage de code, base, stockage, secrets ou cycle de déploiement. ## 17. Labo et cycle de maturation des prototypes ### Rôle Le Labo présente de véritables prototypes fonctionnels ou expérimentations en évaluation. Il ne s'agit ni d'une liste d'idées ni d'un catalogue de produits consolidés. - **Projets** : produits suffisamment consolidés, publiés et maintenus. - **Labo** : prototypes fonctionnels ou expérimentations encore en évaluation. - `sources/` : applications historiques privées de référence, en lecture seule. - `prototypes/` : emplacement local de développement des nouvelles expérimentations. Les deux derniers termes restent internes et ne sont pas affichés dans l'interface publique. ### Cycle de vie ```text idée interne → prototype → en test → validé → projet consolidé ``` Sorties alternatives : - `en_pause` : prototype conservé, temporairement non maintenu ; - `abandonne` : prototype retiré du Labo et archivé. Statuts documentaires : `prototype`, `en_test`, `valide`, `en_pause`, `abandonne`, `consolide`. Les libellés publics restent en français clair et n'exposent pas ces identifiants techniques. Le passage à `consolide` n'est jamais automatique. Il tient compte au minimum de l'utilité, des retours, de la stabilité, de la maintenabilité, du coût d'exploitation, de la compatibilité avec l'architecture, de la conformité juridique, de la sécurité et de la volonté réelle de maintenance. ### Destination après validation Deux trajectoires sont possibles, décidées prototype par prototype : 1. intégration comme module durable de `LEZIDEJOU-platform` si le prototype est compatible avec Laravel, le modèle de données, l'hébergement et le cycle du portail ; 2. application indépendante avec son dépôt, sa base, son domaine et son cycle de publication si son autonomie est justifiée. LivraSign reste le cas déjà décidé d'application indépendante. Après une migration, une seule version devient la référence active ; l'ancien dépôt expérimental est archivé ou marqué comme inactif. ### Accès public possible Sans imposer une solution prématurée, un prototype peut être : - intégré temporairement ou durablement au portail ; - autonome sur un domaine ou sous-domaine dédié ; - accessible sous forme de démonstration limitée depuis `/labo/{slug}`. La convention de travail `.lab.lezidejou.fr` reste à confirmer après validation du domaine canonique et de l'hébergement. Chaque fiche doit indiquer le nom, l'objectif, le statut, ce qui fonctionne, les limites, la dernière mise à jour et un lien ou une méthode de retour uniquement s'ils existent réellement et sont validés. Aucun prototype, lien, visuel, métrique ou comportement fictif n'est autorisé. La phase 1 doit seulement préserver la possibilité d'ajouter le Labo sans refonte majeure. Elle ne crée aucun modèle, contrôleur, route inactive, module vide ou fausse fiche pour l'anticiper. ## 18. Hébergement, qualité et exploitation Le lancement vise une offre Web OVHcloud gérée compatible avec Laravel, sous réserve de vérification avant production. Minimum attendu : - `APP_DEBUG=false` ; - HTTPS ; - secrets hors Git ; - sauvegardes testées par restauration ; - logs exploitables et séparés de LivraSign ; - rate limiting sur les endpoints sensibles ; - CSRF, cookies sécurisés et validation serveur ; - administration protégée par TOTP ; - mises à jour suivies ; - recette en `noindex` ; - conformité RGPD proportionnée aux données réellement collectées. Ne sont pas retenus au lancement : VPS autogéré, Docker en production, Redis, Horizon, workers permanents, microservices, Kubernetes et montée en charge horizontale. ## 19. Phasage de la trajectoire ### Phase 1 — Portail publiable - portail, pages éditoriales, SEO et accessibilité ; - catalogue des cinq projets ; - administration Filament avec TOTP ; - domaines techniques strictement nécessaires ; - aucun code métier issu de `sources/`. ### Activation ultérieure du Labo - sélectionner un premier prototype réel et présentable ; - décider son mode d'accès public et ses limites ; - créer alors seulement le catalogue, les routes et les composants nécessaires ; - publier `Labo` dans la navigation uniquement lorsque l'accès réel est disponible. ### Phase 2 — GoodGasoilPrice - audit de migration ; - intégration dans `FuelPrice` ; - publication de `/applications/prix-carburant` après validation. ### Phase 3 — Menu Planner - audit actualisé ; - import du métier et des migrations spécifiques ; - réconciliation frontend et administration ; - version anonyme utile avant fonctions personnelles. ### Phase 4 — Jeux - correction et tests de Belote Pro et Maths & Îles ; - intégration des builds ; - utilisation immédiate sans compte et sauvegarde locale. ### Phase 5 — Compte LÉZIDÉJOU utile - compte commun seulement avec une première fonction personnelle ; - relations de propriété, Policies, export et suppression des données ; - synchronisation locale/cloud explicitement définie. ### Phase 6 — Monétisation démontrée - offre et prix validés ; - modèle de produits et droits ; - choix du prestataire ; - webhooks idempotents et exigences fiscales adaptées. ### Phase 7 — Infrastructure avancée - uniquement à partir de limites mesurées : queues, Redis, workers, plateforme applicative, base dédiée ou extraction d'un domaine. ## 20. Décision finale > **LÉZIDÉJOU est le portail central et la future plateforme monolithique modulaire de GoodGasoilPrice, Menu Planner, Belote Pro et Maths & Îles. LivraSign reste indépendant. Les nouvelles expérimentations sont isolées sous `prototypes/` et pourront rejoindre un futur Labo public lorsqu'elles seront réelles et accessibles ; leur intégration au monolithe n'est jamais automatique. La phase 1 construit uniquement le portail éditorial, son administration et les domaines techniques utiles, sans métier migré, prototype, route Labo ni coquille vide.** ## 21. Informations à confirmer - domaine canonique final et redirections associées ; - domaine officiel LivraSign ; - textes, liens, logos, screenshots et licences réellement publiables ; - identité légale, responsable de publication et coordonnées ; - offre OVHcloud exacte, versions disponibles, limites, sauvegardes et restauration ; - état réel de chaque dépôt source au début de sa phase de migration ; - conformité réglementaire des données et contenus au moment de leur publication ; - premier prototype justifiant l'ouverture du Labo, son mode d'accès et sa trajectoire après validation. ## 22. Sources ### Sources projet - Dépôt GoodGasoilPrice : `https://github.com/Etbeur/GoodGasoilPrice`. - Dépôt Menu Planner : `https://github.com/Etbeur/menu-planner`. - Les segments `/Etbeur/` sont conservés car ils désignent le nom d'utilisateur GitHub existant, pas l'ancienne marque du portail. ### Documentation officielle vérifiée le 11 août 2026 - Laravel 13, notes de version et politique de support : https://laravel.com/docs/13.x/releases - Laravel 13, authentification : https://laravel.com/docs/13.x/authentication - Laravel 13, autorisation : https://laravel.com/docs/13.x/authorization - Laravel 13, casts chiffrés Eloquent : https://laravel.com/docs/13.x/eloquent-mutators#encrypted-casting - Laravel 13, sessions : https://laravel.com/docs/13.x/session - Laravel 13, cache : https://laravel.com/docs/13.x/cache - Laravel 13, queues : https://laravel.com/docs/13.x/queues - Laravel 13, Horizon : https://laravel.com/docs/13.x/horizon - Laravel 13, déploiement : https://laravel.com/docs/13.x/deployment - Filament 5, authentification multifacteur : https://filamentphp.com/docs/5.x/users/multi-factor-authentication - OVHcloud, configuration multisite : https://help.ovhcloud.com/csm/fr-web-hosting-multisites-configure-multisite?id=kb_article_view&sysparm_article=KB0052950 - OVHcloud, offres d'hébergement Web : https://www.ovhcloud.com/fr/web-hosting/ La documentation Laravel officielle confirme que Laravel 13 prend en charge PHP 8.3 à 8.5 ; PHP 8.4 demeure le choix explicite du projet. La documentation Filament 5 confirme l'authentification par application TOTP, les codes de récupération, la personnalisation du nom de marque et le caractère obligatoire de la MFA.