Roadmap Forge¶

Accueil Retour

Cette roadmap est volontairement prudente. Elle décrit une trajectoire possible, sans transformer les idées futures en promesses immédiates.

État actuel — Forge 1.5.0 + développement post-1.5.0¶

Tag recommandé : v1.5.0

Forge 1.5.0 marque la fin du socle initial jusqu'à la Phase 4 RBAC. Forge 1.5.0 reste le dernier jalon et la version déclarée actuelle du projet. La branche de développement contient déjà les travaux post-1.5.0 de la Phase 4.5 Auth/User jusqu'à AUTH-ADMIN-ROLE-CLI-001 et la reprise de la Phase 5 jusqu'à CRUD-HTMX-003. Le prochain ticket fonctionnel de Phase 5 est REL-ORDERED-001.

Phase	Domaine	État
Phase 0	Stabilisation Forge 1.2.1	validée
Phase 1	Media v2 complet	validée côté serveur
Phase 2	Migrations SQL versionnées	validée et stabilisée en 1.4.0
Phase 3	Socle front léger : Tailwind, JS optionnel, i18n, templates	validée en 1.5.0
Phase 4	Permissions fines / RBAC	validée en 1.5.0
Phase 4.5	Auth/User avancée et sécurité moderne	validée côté socle post-1.5.0 : `AUTH-USER-001` à `AUTH-ADMIN-ROLE-CLI-001` terminés
Phase 5	Relations avancées et CRUD enrichi	ouverte : CRUD HTMX V1 terminé jusqu'à `CRUD-HTMX-003`, prochain ticket `REL-ORDERED-001`

Validation finale de référence pour Forge 1.5.0 :

pytest : 2422 passed, 1 skipped ;
python -m compileall -q . : OK ;
mkdocs build --strict : OK ;
git diff --check : OK.

Socle livré en Forge 1.5.0¶

Forge 1.5.0 fournit un socle MVC complet avec les briques suivantes.

Fondations¶

modèle canonique JSON vers projections SQL et Python générées ;
forge make:entity, forge build:model, forge db:init, forge db:apply ;
migrations SQL versionnées : migration:make, migration:status, migration:diff, migration:apply ;
forge make:crud : scaffolding CRUD lisible et non destructif ;
forge routes:list, forge doctor, forge deploy:init, forge deploy:check ;
CSRF automatique sur POST, PUT, PATCH, DELETE ;
method override POST vers PUT, PATCH, DELETE ;
flash + POST-Redirect-GET avec redirect_with_flash() ;
erreurs HTTP standardisées, dont 422 ;
transactions explicites et helper DB léger ;
url_for Jinja2 et redirect_to_route() ;
pagination standardisée avec Pagination ;
starter apps 1 à 4 générables automatiquement avec forge starter:build ;
déploiement Nginx + systemd documenté.

Formulaires¶

Form, Field et champs avancés : EmailField, PhoneField, UrlField, TextAreaField, SlugField, DateField, DateTimeField ;
Form.from_request() transmet request.body et request.files ;
ImageField et FileField ;
formats image acceptés par défaut : jpg, jpeg, png, webp ;
GIF refusé par défaut, car le pipeline de variantes n'est pas conçu pour les GIF animés ;
recherche q, pagination page, filtres simples et relationnels dans les listes CRUD.

Relations V1¶

relations.json V1 : déclaration many_to_one ;
génération SQL des clés étrangères ;
forge make:crud génère un <select> pour les champs FK déclarés dans relations.json ;
choix chargés depuis la table cible avec du SQL visible.

Média¶

save_upload, save_image, variantes thumbnail / medium via Pillow ;
Pillow >=10.0,<13 déclaré dans requirements.txt et pyproject.toml ;
attach_media_to_entity, get_cover_media, list_media_for_entity, delete_media, update_media_position, update_media_alt_text ;
forge make:crud génère la chaîne complète pour les entités avec déclaration media :
formulaire multipart ;
upload à la création ;
remplacement et suppression à l'édition ;
preview dans show et edit ;
suppression des médias liés à la destruction de l'entité ;
galerie multiple=true avec multi-upload, suppression individuelle, réorganisation par position et alt_text ;
route /media/<chemin> pour servir les fichiers.

Mail¶

Mailer ;
transports interchangeables : NullTransport, FakeTransport, ConsoleTransport, LogTransport, SmtpTransport ;
MailTemplateRenderer ;
MailLogger ;
table mail_log ;
commandes : forge mail:init, forge mail:test, forge mail:render, forge mail:doctor, forge mail:logs.

Phase 3 — Socle front léger¶

État : validée en Forge 1.5.0.

Objectif : préparer Forge à générer des interfaces modernes sans basculer vers une SPA lourde.

3.1 CSS officiel¶

Décision validée : Tailwind reste le CSS officiel de Forge.

Ticket	État	Décision
CSS-001	terminé	Tailwind clarifié comme CSS officiel
CSS-002	non retenu pour l'instant	pas de `forge css:init tailwind` nécessaire tant que Tailwind est déjà le standard du squelette
CSS-003	non retenu pour l'instant	pas de `forge css:init none` tant que le besoin réel n'est pas confirmé
CSS-004	couvert par la documentation front	remplacement manuel possible, hors génération standard

Règle confirmée : Bootstrap, Bulma, Foundation, DaisyUI, Flowbite et autres alternatives ne sont pas maintenus officiellement par Forge.

3.2 JavaScript optionnel¶

Décision validée : HTMX est le JS officiel recommandé, Alpine.js est le complément optionnel pour les petits états locaux.

Ticket	État	Résultat
FRONT-001	terminé	`static/js/app.js` ajouté comme point d'entrée applicatif
FRONT-002	terminé	`forge js:init htmx` ajouté
FRONT-003	terminé	`forge js:init alpine` ajouté
FRONT-004	terminé	`forge js:init htmx-alpine` ajouté
FRONT-005	terminé	`{% block scripts %}` présent dans les layouts
FRONT-006	terminé	usage HTMX documenté dans `docs/front.md`
FRONT-007	terminé	usage Alpine.js documenté dans `docs/front.md`

Règle confirmée : le HTML serveur reste la base. HTMX et Alpine améliorent l'expérience, mais ne remplacent pas MVC.

3.3 Internationalisation simple¶

État : terminé.

Ticket	État	Résultat
I18N-001	terminé	`core/i18n` créé
I18N-002	terminé	`translations/fr.json` ajouté
I18N-003	terminé	`trans(...)` côté Python
I18N-004	terminé	`trans(...)` injecté dans Jinja
I18N-005	terminé	langue par défaut configurée
I18N-006	terminé	fallback si clé ou langue manquante
I18N-007	terminé	`forge i18n:init` ajouté
I18N-008	terminé	`forge i18n:check` ajouté
I18N-009	terminé	`make:crud` utilise les clés i18n

À repousser : routes traduites, traduction automatique, stockage des traductions en base et interface graphique de traduction.

3.4 Templates publics/admin propres¶

État : terminé.

Ticket	État	Résultat
TPL-001	terminé	layouts `public.html` et `admin.html` séparés
TPL-002	terminé	composants Jinja de base ajoutés
TPL-003	terminé	boutons standardisés
TPL-004	terminé	messages flash standardisés
TPL-005	terminé	états vides dans les CRUD
TPL-006	terminé	confirmations de suppression natives côté HTML
TPL-007	terminé	composants documentés dans `docs/front.md`

Composants livrés :

mvc/views/components/
  alert.html
  badge.html
  button.html
  form_field.html
  pagination.html
  table.html

Règle confirmée : les composants restent de simples fragments Jinja lisibles. Ils ne deviennent pas une surcouche magique.

Phase 4 — Permissions fines / RBAC¶

État : validée en Forge 1.5.0.

Objectif : fournir un mécanisme générique d'autorisation sans imposer de modèle utilisateur au coeur de Forge.

Tickets réalisés¶

Ticket	État	Résultat
AUTH-RBAC-001	terminé	modèles génériques `Role` et `Permission`
AUTH-RBAC-002	terminé	décorateur serveur `@require_permission(...)`
AUTH-RBAC-003	terminé	helper Jinja `can(...)`
AUTH-RBAC-004	terminé	protection déclarative des routes CRUD générées via `rbac.permissions`
AUTH-RBAC-SEC-001	terminé	audit ciblé de la chaîne de confiance RBAC
AUTH-RBAC-DOC-001	terminé	documentation complète dans `docs/rbac.md`

Tests RBAC ajoutés¶

Fichier	Tests
`test_rbac_models.py`	30
`test_rbac_authorization.py`	24
`test_rbac_jinja.py`	23
`test_make_crud_rbac.py`	34
`test_rbac_security.py`	40
Total Phase 4	151

Fonctionnalités livrées¶

tables SQL roles, permissions, role_permissions ;
modèles Python Role et Permission ;
normalisation et validation RBAC ;
décorateur serveur @require_permission(...) ;
make_can(request) et helper Jinja can(...) ;
déclaration rbac.permissions dans les entités JSON ;
génération automatique des décorateurs dans make:crud ;
audit de chaîne de confiance RBAC ;
documentation docs/rbac.md.

Décision structurante¶

Le core RBAC ne crée pas de table user_roles. Cette table existe maintenant comme brique optionnelle Auth/User, afin de garder la séparation identité / autorisation.

Le core RBAC fournit le mécanisme d'autorisation :

Role ;
Permission ;
role_permissions ;
get_request_permissions(request) ;
has_permission(...) ;
@require_permission(...) ;
make_can(request) ;
can(...) côté Jinja.

Auth/User reste responsable de l'identité utilisateur. RBAC reste responsable des rôles, permissions et contrôles d'autorisation. Le chargement fiable des permissions depuis un utilisateur connecté est maintenant disponible via AUTH-USER-RBAC-002.

Règle confirmée : Forge ne doit pas imposer une table users, une table user_roles, un modèle User, ni une stratégie d'authentification unique. Ces briques restent optionnelles et explicitement documentées.

Phase 4.5 — Auth/User avancée et sécurité moderne¶

État : validée côté socle — AUTH-USER-001 à AUTH-ADMIN-ROLE-CLI-001 terminés. LEGAL-LICENSE-001 terminé. Phase 5 reprise avec REL-M2M-002.

Objectif : compléter le RBAC par une brique d'identité avancée, générique, optionnelle et sécurisée. Forge doit pouvoir savoir qui est connecté, gérer les procédures modernes de sécurité utilisateur, puis fournir une identité fiable au RBAC.

Décision : REL-M2M-001 est terminé. La Phase 4.5 Auth/User avancée est validée côté socle après correction des commandes CLI de rôles utilisateur. Forge a repris la Phase 5 avec REL-M2M-002.

Pourquoi cette phase devient prioritaire¶

Le RBAC répond à la question : qu'a le droit de faire l'utilisateur ?

L'authentification répond à la question : qui est l'utilisateur connecté ?

Pour une application comme Communes & Séjours, Forge aura besoin au minimum :

d'un administrateur ;
d'un propriétaire connecté ;
éventuellement d'un agent communal ou modérateur ;
d'un visiteur public non connecté pour les pages publiques et les demandes simples.

Sans brique Auth/User générique, Communes & Séjours serait obligé de bricoler l'identité utilisateur dans le starter. Ce serait contraire à la séparation framework / application.

Changement stratégique¶

La version précédente de la roadmap repoussait volontairement :

mot de passe oublié ;
vérification email ;
double authentification ;
OAuth / OIDC ;
interface complète de gestion utilisateurs.

Décision actualisée : ces fonctionnalités entrent maintenant dans la Phase 4.5 active, car Forge doit pouvoir générer des applications modernes avec une sécurité utilisateur sérieuse.

La règle reste stricte : ces fonctionnalités doivent arriver par tickets séparés, courts, testables et documentés.

Périmètre cible¶

Forge doit fournir une authentification avancée, explicite et testable :

contrat utilisateur minimal ;
table users optionnelle ;
hachage et vérification de mot de passe ;
login ;
logout ;
utilisateur courant ;
protection de routes par connexion obligatoire ;
vérification d'adresse email ;
procédure de mot de passe oublié ;
jetons sécurisés à usage unique ;
double authentification par TOTP ;
codes de récupération ;
OAuth / OpenID Connect optionnel ;
liaison contrôlée avec RBAC ;
table user_roles optionnelle ;
interface admin utilisateurs ;
journalisation des événements auth ;
protection anti-bruteforce minimale ;
documentation Auth/User/RBAC.

Tickets Auth/User avancés¶

Ticket	État	Objectif
AUTH-USER-001	terminé	Définir le contrat utilisateur minimal
AUTH-USER-002	terminé	Ajouter une table `users` optionnelle
AUTH-PASSWORD-001	terminé	Ajouter hachage et vérification de mot de passe
AUTH-SESSION-001	terminé	Ajouter login/logout/session utilisateur
AUTH-SESSION-002	terminé	Ajouter `current_user(request)`, `is_authenticated(request)` et `@login_required`
AUTH-TOKEN-001	terminé	Ajouter des jetons sécurisés génériques à usage limité
AUTH-EMAIL-001	terminé	Ajouter la vérification d'adresse email
AUTH-RESET-001	terminé	Ajouter la demande de mot de passe oublié
AUTH-RESET-002	terminé	Ajouter la réinitialisation effective du mot de passe
AUTH-MFA-001	terminé	Définir le contrat MFA et le stockage des facteurs
AUTH-MFA-002	terminé	Ajouter TOTP par application d'authentification
AUTH-MFA-003	terminé	Ajouter les codes de récupération
AUTH-MFA-004	terminé	Ajouter le challenge MFA à la connexion
AUTH-MFA-005	terminé	Ajouter la revalidation MFA pour actions sensibles
AUTH-OIDC-001	terminé	Définir le contrat fournisseur OAuth / OpenID Connect
AUTH-OIDC-002	terminé	Ajouter connexion OIDC avec `state`, `nonce` et PKCE
AUTH-OIDC-003	terminé	Associer compte local et compte OIDC externe
AUTH-USER-RBAC-001	terminé	Ajouter une table `user_roles` optionnelle
AUTH-USER-RBAC-002	terminé	Charger les permissions RBAC depuis l'utilisateur connecté
AUTH-USER-JINJA-001	terminé	Injecter l'utilisateur courant et l'état de connexion dans Jinja
AUTH-USER-CLI-001	terminé	Ajouter des diagnostics CLI Auth/User
AUTH-ADMIN-001	terminé	Ajouter une administration CLI utilisateurs minimale
AUTH-ADMIN-002	terminé	Ajouter activation/désactivation utilisateur
AUTH-USER-RBAC-AUDIT-001	terminé	Auditer le pont Auth/User ↔ RBAC
AUTH-USER-RBAC-ROUTE-001	terminé	Protéger les routes avec les permissions RBAC utilisateur
AUTH-ADMIN-003	terminé	Ajouter attribution des rôles utilisateur
AUTH-AUDIT-001	terminé	Journaliser les événements d'authentification
AUTH-RATE-LIMIT-001	terminé	Ajouter une protection anti-bruteforce minimale
AUTH-DOC-001	terminé	Documenter Auth avancée, User, MFA, OIDC et RBAC
AUTH-SECURITY-AUDIT-001	terminé	Faire un audit global de la chaîne Auth/User
AUTH-ADMIN-ROLE-CLI-001	terminé	Aligner les commandes CLI de rôles utilisateur avec `AUTH-ADMIN-003`, la documentation et les tests

Contrat utilisateur minimal envisagé¶

Structure cible prudente :

users
  id
  email
  password_hash
  is_active
  email_verified_at
  last_login_at
  created_at
  updated_at

À ce stade, Forge ne doit pas imposer :

nom/prénom ;
avatar ;
profil métier ;
adresse ;
téléphone ;
rôle métier spécifique ;
logique propriétaire / commune / séjour.

Ces éléments appartiennent aux applications ou aux starters.

Fonctions cibles minimales¶

login_user(request, user)
logout_user(request)
current_user(request)
is_authenticated(request)
@login_required

Fonctions cibles avancées¶

verify_password(password, password_hash)
request_email_verification(user)
confirm_email_verification(token)
request_password_reset(email)
reset_password(token, new_password)
start_mfa_challenge(request, user)
verify_mfa_challenge(request, code)
generate_recovery_codes(user)
start_oidc_login(provider)
handle_oidc_callback(provider, request)

Ces fonctions sont des objectifs de phase, pas un seul ticket.

Règles¶

cette brique doit rester optionnelle ;
elle ne doit pas transformer Forge en application métier ;
elle ne doit pas imposer un modèle utilisateur riche à tous les projets ;
elle ne doit pas créer d'ORM ;
elle ne doit pas remplacer le RBAC générique déjà présent ;
elle doit fournir une identité fiable exploitable par le RBAC ;
elle doit sécuriser les procédures sensibles sans magie cachée ;
elle doit rester compatible avec le mail Forge existant ;
elle doit documenter clairement ce qui est activé par défaut et ce qui reste optionnel.

Fonctionnalités incluses maintenant dans la Phase 4.5¶

Sujet	Décision
Mot de passe oublié	inclus dans la Phase 4.5
Vérification email	incluse dans la Phase 4.5
Double authentification TOTP	incluse dans la Phase 4.5
Codes de récupération MFA	inclus dans la Phase 4.5
OAuth / OpenID Connect	inclus comme brique optionnelle
Interface admin utilisateurs	incluse après stabilisation des API internes
Journalisation auth	incluse
Anti-bruteforce minimal	inclus
Profils métiers avancés	dans les applications ou starters
Invitations utilisateurs	plus tard

Limites volontairement repoussées¶

Sujet	Décision
WebAuthn / passkeys	plus tard
SAML / SSO entreprise	plus tard
OAuth multi-provider avancé	plus tard
Politiques complexes par organisation	plus tard
Gestion utilisateurs multi-tenant	plus tard
Délégation d'administration avancée	plus tard
Invitations utilisateurs	plus tard
Profils métiers avancés	dans les applications ou starters

Découpage obligatoire¶

Même si Forge vise maintenant une Auth/User avancée, chaque ticket doit rester limité.

Interdiction explicite : ne pas créer dans un même ticket la table users, le login, le reset password, le MFA, l'OIDC, l'admin utilisateurs et le RBAC utilisateur.

Règle : une fonctionnalité de sécurité sensible doit être isolée, testée et documentée avant de passer à la suivante.

Phase 5 — Relations avancées et CRUD enrichi¶

État : ouverte, Phase 4.5 Auth/User validée côté socle, travaux many_to_many terminés en V1 et stabilisation du CRUD enrichi en cours.

Objectif : enrichir le CRUD et les relations sans rendre le générateur opaque.

Décision d'ordre : REL-M2M-001 à REL-PIVOT-001 sont terminés. CRUD-SEARCH-001 ajoute la recherche simple côté serveur dans les listes générées. CRUD-FILTER-AUDIT-001 conclut que les filtres simples et relationnels sont déjà couverts. CRUD-SORT-001 stabilise le tri simple sécurisé par allowlist. CRUD-PAGINATION-001 stabilise l'usage de la pagination core dans les listes CRUD. CRUD-EMPTY-AUDIT-001 conclut que le socle d'états vides existe déjà et CRUD-EMPTY-001 ajoute les messages contextuels côté serveur/Jinja. CRUD-RELATION-FIELD-AUDIT-001 conclut que les champs relationnels CRUD V1 sont déjà couverts. CRUD-HTMX-AUDIT-001 conclut que le support HTMX front est prêt et CRUD-HTMX-PARTIALS-001 ajoute les partials de liste nécessaires avant la recherche HTMX. Forge poursuit le CRUD enrichi par étapes prudentes.

5.1 Relations avancées¶

Ticket	État	Objectif
REL-M2M-001	terminé	Déclaration `many_to_many` dans `relations.json`
REL-M2M-002	terminé	Génération table pivot SQL
REL-M2M-003	terminé	Formulaire avec sélection multiple
REL-M2M-004	terminé	Affichage liste/show
REL-PIVOT-001	terminé	Pivot enrichi
REL-ORDERED-001	à venir	Relations ordonnées hors média si nécessaire

5.2 CRUD enrichi¶

Ticket	État	Objectif
CRUD-SEARCH-001	terminé	Recherche simple dans les listes CRUD
CRUD-FILTER-AUDIT-001	terminé	Audit des filtres CRUD existants
CRUD-FILTER-001	couvert	Filtres déclaratifs simples déjà présents via `list.filter=true` et `many_to_one`
CRUD-SORT-001	terminé	Tri de colonnes
CRUD-PAGINATION-001	terminé	Pagination côté serveur
CRUD-EMPTY-AUDIT-001	terminé	Audit des états vides CRUD existants
CRUD-EMPTY-001	terminé	États vides contextuels pour recherche et filtres
CRUD-RELATION-FIELD-AUDIT-001	terminé	Audit des champs relationnels CRUD existants
CRUD-RELATION-FIELD-001	couvert	Champs relationnels V1 déjà présents (`many_to_one`, `many_to_many` côté source)
CRUD-HTMX-AUDIT-001	terminé	Audit du support HTMX pour les CRUD générés
CRUD-HTMX-PARTIALS-001	terminé	Convention de fragments CRUD avant enrichissement HTMX
CRUD-HTMX-001	terminé	Recherche HTMX optionnelle
CRUD-HTMX-002	terminé	Pagination HTMX optionnelle
CRUD-HTMX-003	terminé	Suppression HTMX optionnelle

Règle : le CRUD HTML classique reste la base. HTMX est une amélioration optionnelle.

Phase 6 — Pages publiques génériques¶

État : en cours.

Objectif : générer des pages publiques propres, distinctes du CRUD admin.

Commandes cibles :

forge make:public-page accueil
forge make:public-list Hebergement
forge make:public-show Hebergement
forge make:public-form DemandeSejour

Ticket	Statut	Objectif
PUBLIC-PAGE-001	terminé	Générer une page publique simple
PUBLIC-LIST-001	terminé	Générer une liste publique
PUBLIC-SHOW-001	terminé	Générer une fiche publique
PUBLIC-FORM-001	terminé	Générer un formulaire public
PUBLIC-CONTACT-001	terminé	Générer une page contact
PUBLIC-TEMPLATES-001	terminé	Templates publics propres
PUBLIC-I18N-001	terminé	Compatibilité i18n
PUBLIC-MEDIA-001	terminé	Intégration média principale/galerie

Phase 7 — Workflow, statistiques et modules¶

État : en cours.

Objectif : ajouter des briques applicatives génériques sans coder le métier Communes & Séjours dans le core.

7.1 Workflow générique¶

Socle minimal terminé : statuts, transitions, helpers Jinja et documentation.

Ticket	État	Objectif
WORKFLOW-001	terminé	Statuts génériques
WORKFLOW-TRANSITIONS-001	terminé	Transitions autorisées
WORKFLOW-JINJA-001	terminé	Helpers d'affichage de statut
WORKFLOW-DOC-001	terminé	Documentation

7.2 Statistiques simples¶

Ticket	Objectif
STATS-001	Événements simples : `page_view`, `contact_click`, etc.
STATS-002	Table SQL générique
STATS-003	Helper Python de tracking
STATS-004	Affichage admin simple

7.3 Système de modules¶

Ticket	Objectif
MODULE-SYSTEM-001	Structure standard d'un module
MODULE-SYSTEM-002	`forge module:list`
MODULE-SYSTEM-003	`forge module:install`
MODULE-SYSTEM-004	Injection propre des routes
MODULE-SYSTEM-005	Installation entities/views/controllers/docs
MODULE-SYSTEM-DOC-001	Documentation du format `module.json`

Modules génériques envisagés : agenda, patrimoine, commerces, statistiques.

Règle : un module Forge ne doit pas être une boîte noire. Il doit copier ou générer du code lisible dans le projet.

Phase 8 — Starter Communes & Séjours¶

État : à venir, après les briques génériques.

Objectif : démonstrateur avancé, pas application codée dans le coeur.

Ticket	Objectif
STARTER-CS-001	Squelette starter Communes & Séjours
STARTER-CS-ENTITIES-001	Entités JSON
STARTER-CS-MEDIA-001	Hébergements avec médias
STARTER-CS-PUBLIC-001	Accueil + liste + fiche
STARTER-CS-FORM-001	Demande de séjour
STARTER-CS-MAIL-001	Notifications propriétaire/visiteur
STARTER-CS-I18N-001	Textes compatibles i18n
STARTER-CS-SEED-001	Fausses données de démo
STARTER-CS-DOC-001	Documentation d'installation

Le starter devra démontrer : page d'accueil attractive, liste d'hébergements, fiche hébergement, galerie média, formulaire de demande, mail/log de notification, back-office minimal et données de démonstration.

Phase 9 — Profils de projet¶

État : utile mais pas prioritaire.

Objectif : proposer plusieurs profils au moment de créer un projet.

forge new MonProjet --profile minimal
forge new MonProjet --profile standard
forge new MonProjet --profile dynamic
forge new MonProjet --profile multilingual

Profil	Contenu
minimal	Jinja + Tailwind, rien de plus
standard	Jinja + Tailwind + composants
dynamic	Jinja + Tailwind + HTMX
multilingual	Jinja + Tailwind + HTMX + i18n

Ticket	Objectif
PROFILE-001	Définir les profils officiels
PROFILE-002	Ajouter option `--profile` à `forge new`
PROFILE-003	Tests de génération
PROFILE-DOC-001	Documentation

À ne pas faire tout de suite. Ce sera utile quand CSS/JS/i18n/templates seront stabilisés.

Phase 10 — Forge Design¶

État : après socle stable.

Objectif : outil graphique séparé qui produit des templates Forge propres.

Forge Design doit produire :

HTML ;
Tailwind ;
fragments Jinja ;
composants ;
options HTMX ;
comportements Alpine simples ;
fichiers JSON de description.

Règle : Forge Design ne doit pas devenir un éditeur React/Vue. Il doit rester aligné avec Forge MVC serveur.

Phase 11 — Plateforme avancée¶

État : repoussée.

Sujet	Décision
Paiement	Trop tôt
Réservation avancée	Plus tard
Facturation	Plus tard
SaaS multi-tenant	Trop lourd maintenant
Marketplace plugins	Prématuré
API REST complète	Pas prioritaire
SPA React/Vue intégrée	Non, documentation à part
Routes traduites	Plus tard
Traduction automatique	Plus tard

Trajectoire post-roadmap¶

Ces phases ne remplacent pas la roadmap actuelle. Elles s'ajoutent après la stabilisation du socle complet. Leur objectif est de préparer Forge 2.0 puis Forge 2.x.

Phase 12 — Audit global Forge 2.0¶

État : à faire après les phases 5 à 11.

Ticket	Objectif
POST-ROADMAP-001	Audit global architecture Forge
POST-ROADMAP-002	Audit cohérence CLI
POST-ROADMAP-003	Audit cohérence documentation/tests
POST-ROADMAP-004	Audit non-écrasement du code utilisateur
POST-ROADMAP-005	Plan de stabilisation Forge 2.0

Cette phase n'ajoute pas de fonctionnalité. Elle simplifie, vérifie et stabilise.

Phase 13 — Expérience développeur et diagnostics¶

État : post-roadmap prioritaire.

Ticket	Objectif
DX-DOCTOR-001	Étendre `forge doctor` aux migrations, i18n, templates et modules
DX-PROJECT-CHECK-001	Ajouter `forge project:check`
DX-PROJECT-AUDIT-001	Ajouter `forge project:audit`
DX-ERRORS-001	Standardiser les messages d'erreur CLI
DX-HELP-001	Harmoniser les aides des commandes Forge
DX-RECOVERY-001	Ajouter des conseils de correction dans les erreurs fréquentes

Phase 14 — Sécurité et durcissement¶

État : post-roadmap prioritaire.

Ticket	Objectif
SECURITY-AUDIT-001	Audit sécurité complet du framework
SECURITY-CSRF-AUDIT-001	Vérifier CSRF sur les formulaires sensibles générés
SECURITY-HEADERS-001	Ajouter ou documenter des headers HTTP de sécurité simples
SECURITY-COOKIES-001	Documenter et tester les attributs de cookies utiles
SECURITY-UPLOADS-AUDIT-001	Réauditer uploads et médias après intégration front
SECURITY-RBAC-AUDIT-001	Vérifier cohérence RBAC/routes/templates après `AUTH-RBAC-SEC-001`
SECURITY-PROD-DOC-001	Renforcer la documentation de production

Phase 15 — Tests d'intégration et qualité globale¶

État : post-roadmap prioritaire.

Ticket	Objectif
E2E-CLI-001	Tester un cycle complet `forge new` -> entité -> migration -> CRUD
E2E-MARIADB-001	Tester les migrations sur MariaDB réelle en environnement contrôlé
E2E-STARTER-001	Tester la génération et l'exécution des starters
E2E-MODULE-001	Tester installation de module dans un projet généré
E2E-NON-OVERWRITE-001	Tester systématiquement la préservation du code utilisateur
QUALITY-COVERAGE-001	Identifier les zones non couvertes par tests

Phase 16 — Releases, compatibilité et politique de versions¶

État : post-roadmap nécessaire avant Forge 2.0.

Ticket	Objectif
RELEASE-POLICY-001	Définir la politique de versionnement
RELEASE-COMPAT-001	Documenter compatibilité Python/MariaDB/Node
RELEASE-DEPRECATION-001	Définir une politique de dépréciation
RELEASE-MIGRATION-GUIDE-001	Créer un guide de migration entre versions Forge
RELEASE-LTS-001	Évaluer une version LTS si Forge devient utilisé en production

Phase 17 — Documentation pédagogique avancée¶

État : post-roadmap prioritaire.

Ticket	Objectif
DOC-STRUCTURE-001	Réorganiser la documentation par parcours
DOC-15MIN-001	Ajouter un tutoriel "15 minutes avec Forge"
DOC-APP-COMPLETE-001	Ajouter un tutoriel application complète
DOC-DEPLOY-ADVANCED-001	Ajouter un parcours déploiement propre
DOC-MODULE-AUTHOR-001	Ajouter un guide créer un module
DOC-STARTER-AUTHOR-001	Ajouter un guide créer un starter
DOC-CONTRIBUTE-001	Ajouter un guide contribuer à Forge

Phase 18 — Maturation des modules et de Forge Design¶

État : après première version des modules et de Forge Design.

Ticket	Objectif
MODULE-DOCTOR-001	Ajouter `forge module:doctor`
MODULE-REMOVE-001	Étudier suppression prudente d'un module
MODULE-UPDATE-001	Étudier mise à jour contrôlée d'un module
MODULE-CONTRACT-001	Renforcer le contrat `module.json`
MODULE-TESTS-001	Ajouter tests de compatibilité module
DESIGN-PREVIEW-001	Prévisualisation de templates
DESIGN-EXPORT-001	Export propre vers projet Forge
DESIGN-COMPONENTS-001	Validation des composants
DESIGN-JINJA-001	Détection des variables Jinja manquantes
DESIGN-PUBLIC-PAGE-001	Création visuelle de pages publiques
DESIGN-FORM-001	Création visuelle de formulaires simples

Phase 19 — Performance mesurée¶

État : après stabilisation fonctionnelle.

Ticket	Objectif
PERF-BENCH-001	Ajouter benchmarks simples
PERF-ROUTING-001	Mesurer le routing
PERF-JINJA-001	Mesurer le rendu Jinja
PERF-I18N-001	Mesurer le chargement des traductions
PERF-CRUD-001	Mesurer pagination/recherche CRUD
PERF-MEDIA-001	Mesurer les accès médias
PERF-DOC-001	Documenter les limites connues

Phase 20 — API légère et usages JSON¶

État : post-2.0, à traiter prudemment.

Ticket	Objectif
API-JSON-001	Réponses JSON simples
API-CONTROLLER-001	Conventions de contrôleurs JSON
API-ROUTES-001	Routes API séparées
API-AUTH-001	Auth API minimale si nécessaire
API-DOC-001	Documentation API légère

Interdictions maintenues :

pas de SPA intégrée au core ;
pas de génération OpenAPI complète au départ ;
pas de transformation de Forge en framework API pur ;
React, Vue et Svelte restent documentés à part.

Priorités actualisées¶

P1 — Phase active immédiate¶

acter REL-M2M-001 comme terminé ;
acter AUTH-SECURITY-AUDIT-001 comme terminé ;
acter AUTH-ADMIN-ROLE-CLI-001 comme terminé ;
poursuivre avec CRUD-HTMX-001 et la Phase 5.

P2 — Briques applicatives génériques¶

Phase 5 : relations avancées et CRUD enrichi après Auth/User avancée ;
Phase 6 : pages publiques génériques ;
Phase 7 : workflow, statistiques et modules ;
Phase 8 : starter Communes & Séjours.

P3 — Outillage avancé¶

profils de projet ;
Forge Design ;
plateforme avancée repoussée.

P4 — Post-roadmap prioritaire¶

audit global Forge 2.0 ;
expérience développeur ;
sécurité ;
tests d'intégration ;
politique de release ;
documentation pédagogique.

P5 — Après Forge 2.0¶

maturation modules ;
maturation Forge Design ;
performance mesurée ;
API légère JSON.

P6 — Toujours repoussés ou hors core¶

ORM complet ;
paiement intégré au coeur ;
réservation avancée intégrée au coeur ;
SaaS multi-tenant ;
marketplace plugins ;
SPA React/Vue/Svelte intégrée ;
traduction automatique ;
routes traduites complexes ;
WebAuthn / passkeys ;
SAML / SSO entreprise ;
gestion utilisateurs multi-tenant ;
table user_roles imposée dans le core ; elle ne peut exister que comme option de la brique Auth/User avancée, jamais comme contrainte globale du framework.

Prochaine séquence conseillée — Phase 4.5 puis Phase 5¶

État actuel : Forge 1.5.0 reste le dernier jalon et la version déclarée actuelle. Les phases 0 à 4 sont validées. REL-M2M-001 est terminé et ouvre officiellement la Phase 5. La Phase 4.5 Auth/User avancée est validée côté socle jusqu'à AUTH-ADMIN-ROLE-CLI-001. REL-M2M-002 génère les tables pivot SQL, REL-M2M-003 ajoute les formulaires many_to_many côté source, REL-M2M-004 affiche les libellés liés dans list/show, REL-PIVOT-001 permet de déclarer des colonnes pivot supplémentaires, CRUD-SEARCH-001 ajoute la recherche simple q, CRUD-FILTER-AUDIT-001 confirme que les filtres déclaratifs simples sont déjà couverts, CRUD-SORT-001 stabilise le tri simple, CRUD-PAGINATION-001 stabilise la pagination serveur dans les listes CRUD, CRUD-EMPTY-AUDIT-001 confirme que les états vides existent déjà, CRUD-EMPTY-001 ajoute les messages contextuels, CRUD-RELATION-FIELD-AUDIT-001 confirme que les champs relationnels V1 sont déjà couverts, CRUD-HTMX-AUDIT-001 recommande une brique de partials avant HTMX, CRUD-HTMX-PARTIALS-001 ajoute ces partials, CRUD-HTMX-001 ajoute la recherche HTMX optionnelle, CRUD-HTMX-002 ajoute la pagination HTMX optionnelle et CRUD-HTMX-003 ajoute la suppression HTMX optionnelle. Le prochain ticket fonctionnel de Phase 5 est REL-ORDERED-001.

Séquence recommandée :

REL-M2M-001 — Déclaration many_to_many dans relations.json — terminé ;
AUTH-USER-001 — Contrat utilisateur minimal — terminé ;
AUTH-USER-002 — Table users optionnelle — terminé ;
AUTH-PASSWORD-001 — Hachage et vérification de mot de passe — terminé ;
AUTH-SESSION-001 — Login/logout/session utilisateur — terminé ;
AUTH-SESSION-002 — current_user(request), is_authenticated(request) et @login_required — terminé ;
AUTH-TOKEN-001 — Jetons sécurisés génériques — terminé ;
AUTH-EMAIL-001 — Vérification d'adresse email — terminé ;
AUTH-RESET-001 — Demande de mot de passe oublié — terminé ;
AUTH-RESET-002 — Réinitialisation effective du mot de passe — terminé ;
AUTH-MFA-001 — Contrat MFA et stockage des facteurs — terminé ;
AUTH-MFA-002 — TOTP par application d'authentification — terminé ;
AUTH-MFA-003 — Codes de récupération — terminé ;
AUTH-MFA-004 — Challenge MFA à la connexion — terminé ;
AUTH-MFA-005 — Revalidation MFA pour actions sensibles — terminé ;
AUTH-OIDC-001 — Contrat fournisseur OAuth / OpenID Connect — terminé ;
AUTH-OIDC-002 — Connexion OIDC avec state, nonce et PKCE — terminé ;
AUTH-OIDC-003 — Association compte local / compte OIDC externe — terminé ;
AUTH-USER-RBAC-001 — Table user_roles optionnelle — terminé ;
AUTH-USER-RBAC-002 — Permissions RBAC chargées depuis l'utilisateur connecté — terminé ;
AUTH-USER-JINJA-001 — Utilisateur courant et état de connexion dans Jinja — terminé ;
AUTH-USER-CLI-001 — Diagnostics CLI Auth/User — terminé ;
AUTH-ADMIN-001 — Administration CLI utilisateurs minimale — terminé ;
AUTH-ADMIN-002 — Activation/désactivation utilisateur et reset password CLI — terminé ;
AUTH-USER-RBAC-AUDIT-001 — Audit du pont Auth/User ↔ RBAC — terminé ;
AUTH-USER-RBAC-ROUTE-001 — Protection serveur via permissions RBAC utilisateur — terminé ;
AUTH-ADMIN-003 — Attribution des rôles utilisateur — terminé ;
AUTH-AUDIT-001 — Journalisation des événements auth — terminé ;
AUTH-RATE-LIMIT-001 — Protection anti-bruteforce minimale — terminé ;
AUTH-DOC-001 — Documentation Auth avancée — terminé ;
AUTH-SECURITY-AUDIT-001 — Audit global Auth/User — terminé ;
AUTH-ADMIN-ROLE-CLI-001 — Cohérence commandes CLI de rôles utilisateur — terminé ;
REL-M2M-002 — Génération prudente de la table pivot SQL — terminé ;
REL-M2M-003 — Formulaire avec sélection multiple — terminé ;
REL-M2M-004 — Affichage liste/show — terminé ;
REL-PIVOT-001 — Pivot enrichi — terminé ;
REL-ORDERED-001 — Relations ordonnées hors média si nécessaire — à venir ;
CRUD-SEARCH-001 — Recherche simple dans les listes CRUD — terminé ;
CRUD-FILTER-AUDIT-001 — Audit des filtres CRUD — terminé ;
CRUD-FILTER-001 — Filtres déclaratifs — couvert par l'existant ;
CRUD-SORT-001 — Tri de colonnes — terminé ;
CRUD-PAGINATION-001 — Pagination côté serveur si elle doit être renforcée — terminé ;
CRUD-EMPTY-AUDIT-001 — Audit des états vides CRUD — terminé ;
CRUD-EMPTY-001 — États vides contextuels pour recherche et filtres — terminé ;
CRUD-RELATION-FIELD-AUDIT-001 — Audit des champs relationnels CRUD — terminé ;
CRUD-RELATION-FIELD-001 — Champs relationnels propres — couvert par l'existant ;
CRUD-HTMX-AUDIT-001 — Audit du support HTMX CRUD — terminé ;
CRUD-HTMX-PARTIALS-001 — Convention de fragments CRUD avant enrichissement HTMX — terminé ;
CRUD-HTMX-001 — Recherche HTMX optionnelle seulement après validation du CRUD classique — terminé ;
CRUD-HTMX-002 — Pagination HTMX optionnelle — terminé ;
CRUD-HTMX-003 — Suppression HTMX optionnelle — terminé.

Règle de démarrage : traiter Auth/User avancée avant toute extension relationnelle ou CRUD plus large. Le CRUD HTML classique reste la base. HTMX reste une amélioration optionnelle.

Conclusion actualisée¶

La roadmap bascule maintenant clairement après Forge 1.5.0.

Acquis validés :

socle stabilisé ;
média serveur ;
migrations SQL versionnées ;
socle front léger ;
i18n simple ;
templates publics/admin ;
RBAC générique sans modèle utilisateur imposé ;
REL-M2M-001 terminé pour ouvrir les relations avancées.

Ajustement stratégique : l'authentification devient une brique indispensable pour construire proprement des applications réelles comme Communes & Séjours. Elle doit rester optionnelle et générique, mais elle devient maintenant une brique avancée de sécurité moderne : email verification, reset password, MFA, OIDC, administration utilisateurs, audit et anti-bruteforce sont intégrés à la Phase 4.5.

Prochaine priorité de Phase 5 : traiter REL-ORDERED-001.

Décision finale : Forge reste le moteur. Communes & Séjours reste la démonstration commerciale du moteur. Les futures améliorations doivent rendre Forge plus explicite, plus testable, plus générique et plus maîtrisable. Si une proposition rend Forge plus magique, plus spécialisée, plus grosse ou plus difficile à expliquer, elle doit être refusée, réduite ou repoussée.

Formule de continuité¶

Forge doit rester :

petit dans son cœur ;
riche par ses briques ;
clair dans ses générateurs ;
fortement documenté ;
très testé.

Cette formule sert de garde-fou pour les phases suivantes : Auth avancée, relations enrichies, pages publiques, modules, starters et Forge Design. Une fonctionnalité peut être ambitieuse, mais elle ne doit pas alourdir inutilement le cœur du framework ni rendre son fonctionnement opaque.