Du scolaire au professionnel

Du MVC scolaire à l'architecture web professionnelle (partie 1 sur 2)
💡 Professionnel signifie : compréhensible, testable, extensible, structure sécurisée

Développement d'un mini-framework modulaire comme base de projet à long terme

Objectif :

Ce projet sert de référence architecturale pour le développement d'applications web évolutives. Il montre la transition progressive d'une structure MVC scolaire à une architecture web professionnelle et modulaire.
Le résultat final n'est pas un projet unique, mais un mini-framework léger qui :

sert de base stable pour n'importe quel projet web
permet une extensibilité à long terme
évite les refontes complètes ultérieures

« Construire une fois le bon châssis – ensuite, il suffit de remplacer les modules. »

Point de départ :

Pour démontrer ce concept de manière pratique, je travaille en deux phases avec des projets de démonstration existants :

Phase 1 : Comme point de départ, j'utilise mon projet DemoMVC – une implémentation MVC scolaire typique qui contient tous les concepts essentiels, mais qui ne présente pas encore une structure professionnelle.

Phase 2 : Dans la deuxième phase, j'utilise le projet Demologin, construit sur la même base DemoMVC, mais qui a déjà implémenté une fonctionnalité de connexion complète.

Étapes :

ÉTAPE	FOCUS	OBJECTIF	PHASE
1	MVC scolaire	Compréhension	1
2	Structure des dossiers	Sécurité & Vue d'ensemble	1
3	Bootstrap & Routeur	Décharge de l'index & Flux des requêtes	1
4	Configuration .htaccess	Sécurité d'accès (fondation)	1
(5)	Services & Classes	Structure & Testabilité (plus tard)	2
(6)	Mini-Framework	Évolutivité à long terme (plus tard)	2

👉 Chaque étape fonctionne de manière autonome
👉 Pas de moments « Tout recommencer »

Structure :

Objectif : Sécurité & Vue d'ensemble, sans refonte

Principe : Seul public/ est accessible publiquement – tout le reste est protégé.

Projet/
    ├─ app/
    │  ├─ config/
    │  ├─ control/
    │  ├─ helper/
    │  ├─ model/
    │  ├─ Router/
    │  ├─ service/
    │  ├─ view/
    │  └─ bootstrap.php
    │  └─ router.php
    │  └─ session.php
    ├─ doc/...
    ├─ public/    ← seul public
    │  ├─ css/
    │  └─ img/
    │  ├─ js/
    │  ├─ index.php    ← Point d'entrée unique
    ├─ sql/
    ├─ storage/
    │  ├─ logs/
    │  └─ upload/
    └─ README.md

Décharge de l'Index :

Problème :

Dans le MVC scolaire, index.php fait trop :

Routeur
Contrôleur
Porte de sécurité
Orchestrateur de flux de travail

👉 Single Point of Chaos

Objectif :

index.php devient :

Petit
Point de départ
pas de logique

Solution :

Externaliser le routeur
Logique Bootstrap centralisée
Préparation pour l'autoloading
Pipeline de requêtes claire

Pipeline de Requêtes

Requête
↓
public/index.php
↓
Bootstrap
↓
Routeur
↓
Contrôleur
↓
Service
↓
Vue / Réponse

Bootstrap :

Initialise :

Configuration
Session
Aide
Contrôleur & Service
Modèle & Vue

Routeur :

Tâches :

URL → Contrôleur / Action
Extraire les paramètres
Traiter les erreurs proprement

Mise en œuvre :

Créer : app/bootstrap.php
Déplacer les chemins d'importation de l'index vers le nouveau bootstrap
Déplacer le switch($page) dans le contrôleur dans une fonction intégrée
Déplacer le contenu du contrôleur dans le dossier Service et le répartir sur les nouveaux fichiers :

      App/services/
      │  ├─ AuthService.php
      │  ├─ UserService.php
      │  ├─ ProfileService.php
      │  ├─ SessionService.php
      │  └─ UploadService.php

Créer : app/Router/Router.php
Déplacer la vérification de la langue et des pages de session.php vers router.php

Accès sécurisé avec .htaccess (Architecture à deux fichiers)

Objectif : Protection multicouche avec séparation claire des tâches

Principe : Deux fichiers .htaccess travaillent ensemble pour une sécurité maximale

.htaccess de base (Racine) :

    # BASE/.HTACCESS (Répertoire racine)
    # Séparation des tâches : Redirection URL & Protection de base

    # PROTECTION DU FICHIER .HTACCESS
    RewriteRule ^\.htaccess$ - [F]

    <IfModule mod_rewrite.c>
        RewriteEngine On

        # RÉÉCRIRE TOUTES LES REQUÊTES VERS PUBLIC/
        RewriteCond %{REQUEST_URI} !/public/
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule ^(.*)$ public/$1 [QSA,L]

        # LIVRER DIRECTEMENT LES FICHIERS STATIQUES
        RewriteCond %{REQUEST_URI} !/public/
        RewriteCond %{REQUEST_FILENAME} !-f
        # TOUT LE RESTE VERS PUBLIC/INDEX.PHP
        RewriteRule ^(.*)$ public/index.php [QSA,L]
    </IfModule>

.htaccess public (Application) :

    # BASE/PUBLIC/.HTACCESS 
    # Séparation des tâches : Routage de l'application

    RewriteRule ^\.htaccess$ - [F]

    <IfModule mod_rewrite.c>
        RewriteEngine On

        # LIVRER DIRECTEMENT LES FICHIERS/RÉPERTOIRES EXISTANTS
        RewriteCond %{REQUEST_FILENAME} -f [OR]
        RewriteCond %{REQUEST_FILENAME} -d
        RewriteRule ^ - [L]

        # TOUT LE RESTE → INDEX.PHP (FRONT CONTROLLER)
        RewriteRule ^ index.php [L]
    </IfModule>

Pourquoi deux fichiers :

Sécurité multicouche : Double protection contre l'exploration de répertoires
Séparation des tâches : Racine gère l'accès, Public gère le routage
Débogage : Plus facile à tester et à maintenir
Flexibilité : Peut être adapté par environnement

Comment ils travaillent ensemble :

Étape 1 : .htaccess racine redirige toutes les requêtes vers public/
Étape 2 : .htaccess public vérifie si fichier/répertoire existe
Étape 3 : Les fichiers statiques sont livrés directement
Étape 4 : Tout le reste va à index.php (Front Controller)

👉 Avec la structure des dossiers, cela constitue la base de sécurité de l'ensemble du projet. Aucun fichier sensible n'est jamais accessible publiquement.