PHP 8 typé, PDO, sessions solides, structure claire : coder sans Laravel ni Symfony est un choix d'artisan, pas un retour en arrière. Mode d'emploi.

La phrase « Tu travailles sans framework ?? » sonne souvent comme « tu traverses l'Atlantique à la rame ?? ».
Sauf que le PHP de 2026 n'est pas celui de 2006 : typage strict, arrow functions, match, enums, attributs, JIT. Le langage a intégré ce que les frameworks compensaient. Reste à structurer, et ça, c'est le métier de dev, pas celui d'un vendor.

Ce que le PHP moderne offre nativement

  • Typage : declare(strict_types=1), types d'union, propriétés typées, enums. Ton IDE t'engueule avant la prod, comme un grand.
  • PDO + requêtes préparées : l'injection SQL est un problème résolu depuis quinze ans pour qui lit la doc (RTFM !).
  • password_hash() / password_verify() : l'état de l'art du hachage en deux fonctions, directement dans la lib standard. Ceux qui stockent du MD5 en 2026 le font par choix de vie.
  • Sessions, filtres, mbstring : le nécessaire est dans la boîte.

Un framework par-dessus tout ça apporte des conventions, pas la sécurité. Utiles en équipe de vingt ou dans une team avec un gros turn-over; mais en solo ou petite équipe, tes propres conventions sont plus légères et tu les comprends à 100 %.

La structure : le framework, c'est toi

Sans structure, le PHP artisanal devient vite du PHP archéologique. La mienne tient en peu de choses :

/public          ← seule racine exposée
  index.php      ← point d'entrée unique
  assets/
/src
  router.php
  db.php
  helpers.php
/templates
  layout.php
  pages/
  fragments/
/data
  app.db         ← SQLite, hors racine web

Un routeur minimal, c'est trente lignes : on mappe une URL vers un fichier de page, on refuse tout le reste. Pas de magie, la réponse est toujours : ligne 12, sous tes yeux.

$routes = [
  ''            => 'pages/accueil.php',
  'contact'     => 'pages/contact.php',
  'blog/{slug}' => 'pages/article.php',
];

Les templates sont du PHP. Un moteur de templates pour PHP, c'est un traducteur français-français (ou un manque de confiance flagrant pour le front-end Dev).

La sécurité, sans excuse

Pas de framework ne veut pas dire pas de règles. Les quatre non négociables :

  • Échapper toute sortie avec htmlspecialchars() : le XSS entre par l'oubli, pas par l'ignorance.
  • Requêtes préparées partout, zéro concaténation SQL.
  • Jeton CSRF sur chaque formulaire qui modifie quelque chose : un jeton en session, un champ caché, une comparaison hash_equals().
  • Cookies de session en HttpOnly, Secure, SameSite=Lax minimum.

C'est exactement ce qu'un framework fait, sans les 40 Mo autour. L'OWASP liste les risques ; aucun ne se soigne par l'ajout d'un vendor, tous se soignent par la rigueur.

Le gain réel : la durée de vie

Le code sans framework a une propriété magique : il vieillit à la vitesse de PHP, pas à la vitesse d'un écosystème. Pas de montée de version majeure qui casse l'API, pas de paquet abandonné qui bloque la mise à jour, pas de faille dans une dépendance de dépendance. Un site PHP artisanal de 2015 se met à jour vers PHP 8 en corrigeant trois dépréciations. Un projet framework de 2015... on se recroise dans six sprints.

j'ajoute HTMX pour l'interactivité (par philosophie) et SQLite pour les données, j'ai une stack complète qui se déploie par copie de fichiers et se comprend en entier. Chaque ligne du projet a une raison d'être que tu peux expliquer. Essaie d'expliquer chaque ligne de ton vendor et de ses dépendances.

Sans framework ne veut pas dire sans discipline : la discipline t'appartient. C'est plus exigeant au départ, et radicalement plus simple ensuite. L'artisanat, c'est ça : des outils simples, bien tenus, qui durent.

FAQ

Coder en PHP sans framework est-il sécurisé ?

Oui, si les fondamentaux sont appliqués : requêtes préparées, échappement des sorties, jetons CSRF, cookies durcis. La sécurité vient de la rigueur, pas du vendor.

Quels projets s'y prêtent le mieux ?

Sites vitrines, blogs, outils métier, petits SaaS : tout projet où une équipe réduite maîtrise l'ensemble du code.

Que perd-on sans framework ?

Les conventions partagées et l'écosystème de paquets. En grande équipe ou sur un projet très complexe, un framework redevient pertinent.

← Retour au playground