Bien organiser un projet PHP « à la main » (sans framework) est formateur et utile pour les petits projets — et cela prépare la compréhension des frameworks qui formaliseront ces principes. Voici comment structurer proprement. Le problème à éviter : le « code spaghetti » — tout mélangé dans de gros fichiers (HTML, logique, requêtes de base, tout ensemble), du code dupliqué partout (le même en-tête copié dans chaque page), aucune structure. C'est illisible, non maintenable, source de bugs. La bonne organisation vise la SÉPARATION et la RÉUTILISATION. Les principes d'organisation : (1) SÉPARER en fichiers LOGIQUES. Divisez votre code selon les responsabilités : (a) la CONFIGURATION (paramètres, connexion à la base) dans un config.php ; (b) les FONCTIONS réutilisables dans des fichiers de fonctions (ou mieux, des classes — niveau 3) ; (c) les éléments d'INTERFACE communs (en-tête, menu, pied de page) dans header.php, footer.php ; (d) les PAGES (le contenu spécifique) dans leurs fichiers. On assemble par INCLUSIONS. (2) RÉUTILISER par inclusions. Le header, le footer, la config sont écrits UNE fois et INCLUS dans chaque page (require/include) — plus de duplication, une modification à un seul endroit. (3) SÉPARER la LOGIQUE et l'AFFICHAGE. Le principe clé (déjà vu en 0-3) : ne mélangez pas la logique (traitement, requêtes, calculs) et l'affichage (le HTML). Faites la logique d'abord (récupérer/traiter les données), l'affichage ensuite (le HTML avec les données préparées). Cela mène naturellement vers le pattern MVC (section 4-1). (4) Une STRUCTURE de DOSSIERS claire. Organisez les fichiers en dossiers par type/rôle : par exemple un dossier includes/ (config, fonctions, header/footer), un dossier pages/ ou la racine pour les pages, un dossier assets/ (CSS, JS, images), un dossier uploads/ (fichiers uploadés, sécurisé). Une arborescence logique rend le projet navigable. (5) Sécuriser la structure. Idéalement, placez les fichiers SENSIBLES (config avec les identifiants de base, fonctions) HORS de la racine web (le dossier accessible publiquement) — ainsi ils ne sont pas directement accessibles par URL. Sinon, protégez-les (par exemple, un config.php ne doit rien afficher s'il est appelé directement). Un point courant : le pattern du « point d'entrée unique » (un seul index.php qui route vers les bonnes pages) est plus sûr et propre que d'avoir des dizaines de fichiers PHP accessibles directement — c'est d'ailleurs ce que font les frameworks. (6) Nommer clairement fichiers et fonctions (documentation gratuite). (7) Gérer la configuration par environnement : les identifiants de base, secrets, dans un fichier de config séparé (idéalement hors du dépôt Git — comme les .env — pour ne pas versionner les secrets). Un exemple de structure simple : (1) config/ ou includes/ : config.php (paramètres, connexion base), fonctions.php, header.php, footer.php ; (2) les pages (index.php, produits.php, contact.php…) qui incluent la config, le header, font leur logique, affichent, incluent le footer ; (3) assets/ (CSS, JS, images) ; (4) uploads/ (fichiers uploadés, sécurisé). L'évolution vers les frameworks : cette organisation « à la main » enseigne les principes (séparation, réutilisation, structure) que les FRAMEWORKS (Laravel, Symfony, niveau 4) FORMALISENT et automatisent : ils imposent une structure claire (MVC), gèrent le routage (un point d'entrée unique), l'autoloading (charger les classes automatiquement — section 3-3), la configuration par environnement, la sécurité. Comprendre l'organisation manuelle vous fait apprécier et mieux utiliser les frameworks (vous comprenez ce qu'ils font pour vous). En résumé : organisez un projet PHP « à la main » en SÉPARANT le code en fichiers logiques (config, fonctions, header/footer, pages), en RÉUTILISANT par inclusions (pas de duplication), en SÉPARANT logique et affichage, avec une STRUCTURE de dossiers claire et SÉCURISÉE (fichiers sensibles protégés, idéalement point d'entrée unique). Nommez clairement, gérez la config par environnement (secrets hors dépôt). Cette organisation (séparation, réutilisation, structure) est le fondement d'un code maintenable, et prépare à comprendre les frameworks qui la formalisent. Évitez le code spaghetti dès le début : une bonne organisation, même manuelle, distingue un projet propre et évolutif d'un bricolage vite ingérable. C'est une compétence de structuration qui vaut au-delà de PHP.

Les uploads de fichiers (permettre à l'utilisateur d'envoyer un fichier) sont l'une des fonctionnalités les plus SENSIBLES en sécurité web, car un upload mal géré peut permettre à un attaquant d'exécuter du code malveillant sur votre serveur — comprendre les risques et les protections est essentiel. Pourquoi c'est si dangereux : quand vous permettez un upload, vous laissez un utilisateur DÉPOSER un fichier sur VOTRE serveur. Si vous ne contrôlez pas rigoureusement ce fichier, un attaquant peut : (1) Uploader un fichier PHP MALVEILLANT et l'EXÉCUTER. Le scénario le plus grave : un attaquant uploade un fichier .php contenant du code malveillant (un « webshell »), puis y accède via son URL → le serveur EXÉCUTE ce code PHP → l'attaquant prend le contrôle du serveur (lire/modifier des fichiers, accéder à la base, tout compromettre). C'est une faille CRITIQUE, aux conséquences catastrophiques. (2) Uploader des fichiers énormes pour saturer le disque/la mémoire (déni de service). (3) Uploader des fichiers au type trompeur (une image qui contient du code, un fichier au nom/type falsifié). (4) Écraser des fichiers existants (si le nom n'est pas contrôlé). Les protections ESSENTIELLES (à appliquer toutes) : (1) NE JAMAIS permettre l'exécution des fichiers uploadés. LE point crucial. Stockez les fichiers uploadés dans un dossier où l'exécution PHP est DÉSACTIVÉE (configuration du serveur), ou HORS de la racine web (inaccessibles directement par URL, servis via un script contrôlé). Ainsi, même si un attaquant uploade un fichier PHP, il ne pourra pas l'exécuter (le serveur ne l'exécutera pas, ou le fichier n'est pas accessible). C'est la protection la plus importante. (2) RENOMMER le fichier. Ne gardez JAMAIS le nom fourni par l'utilisateur tel quel (il peut contenir des caractères dangereux, tenter d'écraser des fichiers, ou avoir une extension trompeuse). Générez un nom SÛR (aléatoire, ou basé sur un identifiant) avec une extension contrôlée. (3) VÉRIFIER le TYPE réel du fichier. Ne vous fiez PAS à l'extension ni au type déclaré par le navigateur (falsifiables). Vérifiez le type RÉEL (le contenu) du fichier (par exemple, pour une image, vérifier que c'est bien une image via des fonctions dédiées). Limitez aux types AUTORISÉS (liste blanche : seulement les types que vous acceptez, pas une liste noire). (4) LIMITER la TAILLE. Imposez une taille maximale (côté PHP et configuration) pour éviter la saturation. (5) VALIDER l'extension (liste blanche des extensions autorisées) — mais l'extension seule ne suffit pas (vérifier aussi le type réel). (6) Contrôler le contenu si pertinent : pour certains types (images), s'assurer qu'il n'y a pas de code caché. (7) Gérer les erreurs d'upload ($_FILES contient un code d'erreur à vérifier). (8) Limiter les DROITS du dossier d'upload (pas d'exécution, droits minimaux). La démarche pour traiter un upload sûrement : (1) vérifier qu'il n'y a pas d'erreur d'upload ($_FILES['fichier']['error']) ; (2) vérifier la TAILLE (limite) ; (3) vérifier le TYPE RÉEL (liste blanche des types autorisés) ; (4) générer un NOUVEAU nom sûr (aléatoire) avec l'extension contrôlée ; (5) déplacer le fichier (move_uploaded_file()) vers un dossier SÉCURISÉ (sans exécution PHP, idéalement hors racine web) ; (6) stocker la référence (nom, chemin) en base si besoin. Une recommandation importante : en projet réel, utilisez les OUTILS ÉPROUVÉS des frameworks ou des bibliothèques dédiées pour gérer les uploads (Laravel, Symfony ont des systèmes de gestion de fichiers/uploads robustes qui appliquent les bonnes pratiques) — plutôt que de tout coder à la main (facile d'oublier une protection sur un sujet aussi critique). Et pour les fichiers publics servis en masse (images d'un site), on utilise souvent un stockage dédié (voire externe/cloud). En résumé : les uploads sont sensibles car un fichier malveillant uploadé et EXÉCUTABLE (un PHP) permettrait à un attaquant de prendre le contrôle du serveur — une faille critique. Les protections essentielles : empêcher l'EXÉCUTION des fichiers uploadés (dossier sans exécution PHP, hors racine web — LA protection clé), RENOMMER les fichiers (ne pas garder le nom utilisateur), VÉRIFIER le type réel (liste blanche, pas se fier à l'extension/type déclaré), LIMITER la taille, valider les extensions. Appliquez TOUTES ces protections (elles se complètent), et en production, privilégiez les outils éprouvés des frameworks. Les uploads mal gérés sont une source classique de compromissions graves — la rigueur est non négociable. Comme pour toute la sécurité web, le principe « ne jamais faire confiance aux entrées » s'applique pleinement : un fichier uploadé est une entrée utilisateur, donc potentiellement malveillante, à contrôler rigoureusement.