Un ami m'a envoyé la nouvelle cette semaine avec un seul mot en commentaire : « enfin ? ». L'équipe Swoole a rendu open source TypePHP, un compilateur ahead-of-time qui prend du code d'apparence PHP, émet du C++ et te livre un binaire natif, et le tableau de benchmarks culmine autour de 150x par rapport à l'interpréteur. Ma réponse à son « enfin ? » est non, et aussi oui. Non, parce que ça ne rendra pas ton appli Symfony 150 fois plus rapide, et les mainteneurs n'ont jamais prétendu le contraire. Oui, parce qu'il vient de se passer quelque chose de discrètement important : la barrière pour écrire une extension PHP native est passée de « apprendre l'API C de Zend » à « lancer Composer ». C'est cette seconde histoire qui mérite les gros titres, et c'est celle que je veux défendre.

composer require --dev swoole/typephp
vendor/bin/tpc.php project.yml

D'abord, ce que c'est vraiment. TypePHP a commencé sa vie à l'intérieur de Swoole comme compilateur AOT interne, puis a été renommé quand l'équipe a admis ce qu'elle avait construit : un langage fortement typé qui se lit comme du PHP mais ne touche jamais aux opcodes de la ZendVM. L'histoire du bootstrap est le genre de détail dont raffolent les passionnés de compilateurs. Le compilateur est écrit en PHP, et le binaire tpc que tu exécutes, c'est le code source du compilateur passé dans une version antérieure de lui-même. Un compilateur PHP auto-hébergé ne figurait pas sur ma grille de bingo 2026, et je dis ça avec une vraie tendresse.

D'où viennent les gros chiffres ? Du refus de payer la taxe de flexibilité de PHP sur du code qui n'en a jamais eu besoin. Le PHP standard met chaque valeur dans une boîte pour que son type puisse changer en plein vol, ce qui est merveilleux quand tu colles une réponse d'API à un template et du pur surcoût quand tu additionnes soixante millions de flottants. Ajoute use native_types; en haut d'un fichier TypePHP et int, float et bool deviennent int64_t et double, si bien qu'une boucle serrée compile vers de l'arithmétique CPU toute simple. Les tableaux ont droit au même traitement : au lieu du hashmap à tout faire de PHP, tu peux prendre des conteneurs calqués sur std::vector, std::array et std::map, typés dès le départ. Les benchmarks publiés opposent PHP 8.4 à TypePHP compilé avec -O3, et même les mainteneurs préviennent que les résultats varieront selon ton CPU, ton compilateur et ta build de PHP. Très bien. Même si tu divises mentalement chaque chiffre par cinq, une boucle numérique chaude qui atterrit près du territoire du C++ écrit à la main, c'est un autre sport que le réglage d'opcache.

Maintenant, le moment où je dois être honnête avec toi, parce que le projet l'est aussi. TypePHP compile une tranche bien définie de PHP, pas PHP. Le code au niveau supérieur d'un fichier ne peut contenir que des déclarations, le mode binaire autonome exige un main() avec une signature fixe, et une longue liste d'astuces dynamiques, des variables variables à la plupart des acrobaties de réflexion, est rejetée par conception. L'équipe tient la liste complète des refus dans docs/INCOMPATIBLE_PHP_FEATURES.md, et lire ce fichier en regard de ta base de code est la première étape de toute évaluation. Ton appli Laravel ne compilera pas. Tes entités Doctrine ne compileront pas. Quiconque te dit le contraire n'a pas essayé.

Et voici le contre-argument que je prends au sérieux : on a déjà vu des dialectes PHP typés, et le souvenir pique encore. Hack a forké le langage, attiré une seule entreprise géante dans son orbite, et nous a laissé une décennie d'exemples de code incompatibles sur Stack Overflow. Un langage sous-ensemble risque de couper en deux les bibliothèques, les tutoriels et les viviers de recrutement. Ajoute la friction pratique : TypePHP veut PHP 8.4 ou 8.5 avec les en-têtes de dev, GCC 9 ou plus récent ou un Clang capable de C++17, CMake 3.24+, et la SAPI embed pour les builds binaires, et en plus il est distribué sous GPL-3.0, une licence que ton équipe juridique voudra lire avant que tu distribues un artefact compilé. C'est une vraie toolchain et une vraie conversation de licence, pas une case à cocher.

Alors pourquoi j'atterris quand même du côté optimiste ? À cause d'un seul drapeau : -m ext. TypePHP peut compiler ton module en extension PHP chargeable, et une couche de pont appelée PHPX permet au monde compilé d'appeler le monde Zend classique et de coexister avec lui, y compris via un simple require de fichiers .php ordinaires. Réfléchis à ce que ça remplace. Jusqu'ici, si ton scoreur de correspondance floue ou ton normaliseur de CSV mangeait 40 pour cent du CPU d'un worker, tes options étaient de le réécrire en extension C, de bricoler du FFI, ou d'extraire tout le boulot dans un sidecar Go en héritant d'un second déploiement. Maintenant, le pitch, c'est : garde la syntaxe PHP, ajoute des types, compile ce seul fichier, charge le .so, terminé. Le risque de fragmentation rétrécit beaucoup quand le dialecte vit aux marges de ton appli au lieu d'en remplacer le cœur.

Il y a aussi des à-côtés qui valent un coup d'œil. Les types à précision arbitraire arrivent piles incluses, avec bigInt sur GMP, bigFloat sur MPFR et decimal sur libmpdec, ce que quiconque a déjà fait des calculs d'argent en PHP saura apprécier. Des attributs comme #[Getter] et #[Constructor] génèrent du boilerplate typé à la compilation. Et la liste des cibles dépasse Linux, macOS et Windows sur x64 et ARM64 pour aller jusqu'à WASI 0.2 et au navigateur, même si aujourd'hui Linux x64 est le seul chemin que je qualifierais de prêt pour la production. Le numéro de version, 0.6.6, fait à lui seul un gros travail de gestion des attentes, et c'est tant mieux.

Ma position, donc : ignore le 150x, garde l'outil. TypePHP n'est pas un PHP plus rapide, c'est la première toolchain d'extensions qui parle notre langue, et je préférerais voir la communauté affûter ce cas d'usage plutôt que courir après le rêve de compiler des applis entières. Mais j'ai mes angles morts, et la plupart de mes chemins chauds ont vraiment la forme de requêtes SQL, alors dis-moi : quelle est la boucle en pur PHP de ton système en production qui brûle réellement du CPU, et est-ce que tu lui offrirais une toolchain C++ dans ta CI, ou est-ce que ce boulot doit vivre hors de PHP, peu importe à quel point la syntaxe te semble familière ?