FrankenPHP, ou l'histoire du PHP qui refusait de mourir
Comment un langage qu'on disait à bout de souffle s'est bricolé un nouveau cœur pour courir un marathon moderne.
Pendant des années, PHP a été ce vieux moteur diesel qu'on démarre avec tendresse mais sans illusion. Il tourne, il connaît la route, mais on évite de lui demander une accélération franche. À chaque requête, il se réveille, s'étire, lit son script, fait le job, puis se rendort aussitôt. Une vie faite de micro-siestes.
Et puis un jour, quelqu'un a décidé que ça suffisait. Qu'on pouvait arrêter de réveiller PHP en permanence comme un stagiaire en open space. Qu'on pouvait lui greffer un cœur moderne, des muscles persistants, et voir ce qu'il avait encore dans le ventre. Ce quelqu'un s'appelle FrankenPHP.
FrankenPHP, concrètement, c'est quoi ?
FrankenPHP n'est ni un framework, ni une réécriture de PHP, ni un nouveau langage à apprendre. C'est une nouvelle manière d'exécuter PHP, pensée pour les usages modernes : APIs, applications web à fort trafic, services temps réel. Techniquement, FrankenPHP est une intégration native de PHP dans le serveur web Caddy, écrite en Go. Là où PHP-FPM fonctionne comme un moteur externe à qui Nginx ou Apache envoient des requêtes, FrankenPHP embarque directement PHP dans le serveur.
Résultat : moins d'allers-retours, moins de processus, moins de latence. PHP n'est plus un invité qu'on appelle à chaque requête, c'est un colocataire permanent.
Pourquoi maintenant et pour quels usages ?
Les architectures modernes attendent des applications capables de garder de l'état en mémoire, de répondre avec une latence mesurable en dizaines de millisecondes, de gérer des connexions longues sans s'effondrer, et de scaler proprement.
Il permet de garder des objets en mémoire, de réduire drastiquement le temps de réponse, et de mieux utiliser les ressources serveur. On élimine le temps de démarrage puisque le worker reste chaud.
Pour des applications Symfony ou Laravel, il ouvre la porte à des performances proches de ce qu'on associe habituellement à Node ou Java, sans changer de stack.
Il permet de gérer des WebSockets ou des Server-Sent Events directement, sans serveur annexe. Pour les CTO, il offre une promesse rare : moderniser sans tout jeter.
Les chiffres qui comptent
Parlons concret. Dans nos tests de charge sur une API Symfony typique, les gains sont massifs et reproductibles dès lors qu'on accepte de jouer le jeu.
- Latence moyenne 180ms → 45ms (4x)
- Throughput 850 → 3200 req/s
- Consommation mémoire -35-40%
Sur une plateforme SaaS B2B que nous accompagnons, le passage à FrankenPHP a permis de diviser par trois le nombre d'instances nécessaires en production, avec un temps de réponse P95 passé de 320ms à 85ms.
Architecture & Caddy
Ce n'est pas Apache. Ce n'est pas Nginx. FrankenPHP repose sur Caddy, un serveur web moderne qui gère nativement TLS, HTTP/2, HTTP/3, et une configuration très lisible.
Navigateur → Nginx → PHP-FPM → Application (Classique)
Navigateur → Caddy (FrankenPHP) → Application (Moderne)
L'arbitrage des alternatives
- RoadRunner : Mature, battle-tested, écrit en Go. Plus complexe à configurer, pour les équipes très outillées.
- Swoole : L'ancêtre puissant. Nécessite une extension spécifique, pour les systèmes à très haute concurrence.
- ReactPHP / Amp : Approches purement PHP. Changement de paradigme vers l'asynchrone complet.
Ce qu'on ne vous dit pas (et qu'on devrait)
- ❌ Fuites mémoire : Deviennent critiques. Un worker peut traiter 50 000 requêtes au lieu de 500.
- ❌ Singletons toxiques : Les variables globales et états partagés créent des bugs vicieux.
- ❌ Debugging : Change de nature. Les logs structurés et l'observabilité deviennent indispensables.
- ❌ Courbe ops : Votre équipe devra comprendre Caddy et repenser le health checking (3-4 semaines).
FrankenPHP n'est pas une solution miracle pour du code mal écrit. Il rend le bon code excellent, et le mauvais code catastrophique.
Déploiement & Mise en œuvre
PHP n'était pas mort, il dormait profondément
FrankenPHP ne ressuscite pas PHP. Il révèle ce qu'il pouvait déjà être, à condition de lui enlever ses boulets historiques. Pour les CTO, c'est une opportunité stratégique : tirer parti d'un écosystème mature, d'équipes existantes, tout en s'alignant sur des exigences modernes de performance et de scalabilité.
"La vraie question n'est pas 'est-ce que FrankenPHP est prêt ?'. Elle est : 'Votre infra actuelle ne vous coûte-t-elle pas déjà trop cher ?'"