Architecture PHP natif : pourquoi zéro framework ?

Le contexte

Quand j'ai décidé de reconstruire mon site vitrine, la question du framework s'est posée immédiatement. Laravel, Symfony, Slim — j'ai travaillé avec tous. Mais cette fois, le site est la démonstration de mes compétences. Utiliser un framework reviendrait à montrer les compétences de Taylor Otwell, pas les miennes.

La micro-architecture

Le pipeline est simple et transparent :

Request → Bootstrap → Middlewares → Router → Controller → Service → View → Response

Chaque composant est une classe PHP 8.2+ avec declare(strict_types=1), des propriétés readonly, et zéro magie. Le Router fait 60 lignes. La View engine en fait 80. Le tout tient dans ~2000 lignes de code applicatif.

Les avantages

• Performance : TTFB < 50ms en local, pas de bootstrap de framework à 15ms
• Compréhension totale : chaque ligne est la mienne, je sais exactement ce qui se passe
• Sécurité : pas de surface d'attaque framework, pas de CVE à surveiller
• Taille : zéro dépendance Composer en Phase 1

Les pièges

Le piège principal est de réinventer la roue inutilement. Il faut savoir quand s'arrêter. Mon Router gère des routes statiques et des paramètres nommés — pas de middleware pipeline complexe, pas de DI container, pas de service locator. Juste ce qu'il faut pour un site vitrine.

Conclusion

Pour un site vitrine de développeur, le zéro framework est un choix pertinent. Pour une application métier complexe, j'utiliserais Laravel ou Symfony sans hésiter. L'important est de choisir l'outil adapté au contexte — c'est ça, l'architecture logicielle.