---
title: "Le compilateur AOT de Swoole devient TypePHP : du code à syntaxe PHP compilé en binaire natif, beta pour le 1er octobre"
description: "Le 18 juin 2026, l'équipe Swoole a officiellement renommé son compilateur PHP ahead-of-time en TypePHP, un langage compilé fortement typé distinct, à compatibilité syntaxique PHP totale, avec un moteur dual compile-statique / ZendVM-runtime, des types natifs Decimal / BigInt / BigFloat, quatre conteneurs fortement typés soutenus par le C++, la syntaxe d'appel de fonction uniforme, et des appels directs à l'ABI C++ vers des bibliothèques statiques C, C++, Rust et Go. Une beta est promise pour la Fête nationale chinoise (1er octobre 2026), suivie d'une release complète du code source. Nous décortiquons le design dual-engine, l'intégration à l'ABI C++, le compilateur auto-hébergé, ce qui change face à KPHP, HHVM, PeachPie et FrankenPHP, et la question ouverte que Roman Pronskiy a soulevée sur la limite où le langage cesse d'être du PHP."
date: 2026-06-18
image: "/images/heroes/2026-06-18--typephp-swoole-aot-native-binary-php.png"
author: lschvn
tags: ["runtimes", "tooling"]
tldr:
  - "Le compilateur ahead-of-time PHP de l'équipe Swoole a été renommé TypePHP et est livré comme un langage compilé fortement typé distinct, et non comme un PHP plus rapide. La beta est promise avant la Fête nationale chinoise le 1er octobre 2026, suivie d'une release complète du code source sur GitHub à swoole/aot-compiler. Le compte officiel WeChat de Swoole a publié l'annonce le 18 juin 2026, et Roman Pronskiy, responsable de PhpStorm chez JetBrains, a signalé le renommage dans un article X la même semaine."
  - "Le design phare de TypePHP est le double moteur : le programme principal est compilé en code machine natif, mais le runtime ZendVM est préservé à l'intérieur du binaire, de sorte que l'exécutable compilé peut charger des scripts `.php` ordinaires via `require`/`include` au runtime. Cela préserve la surface d'extensions PHP complète (curl, mysqli, PDO, Swoole, et les extensions C/C++ auto-écrites) et l'autoload Composer fonctionnant sans modification. La performance est rapportée comme dix à cent fois supérieure au PHP interprété, et le binaire produit ne peut pas être décompilé en source PHP."
  - "Trois nouvelles fonctionnalités linguistiques sont livrées au-delà du PHP : le BigInt, BigFloat et Decimal natifs pour le calcul scientifique et financier en précision exacte (donc `0.1 + 0.2` vaut exactement `0.3`) ; quatre conteneurs fortement typés (`std::array`, `std::vector`, `std::map`, `std::unordered_map`) qui remplacent le `array` universel ; et la syntaxe d'appel de fonction uniforme, qui permet d'appeler n'importe quelle fonction comme méthode sur n'importe quelle valeur, y compris les entiers et chaînes intégrés, et d'ajouter des méthodes d'extension aux types existants. Le compilateur lui-même est en cours d'auto-hébergement en TypePHP, à la manière dont le compilateur Go est écrit en Go."
faq:
  - question: "Qu'est-ce que TypePHP ?"
    answer: "TypePHP est le nouveau nom du compilateur PHP ahead-of-time de l'équipe Swoole. Il est livré comme un langage compilé fortement typé distinct, dont la syntaxe reste compatible avec PHP, mais dont le runtime est du code machine natif accompagné d'un ZendVM embarqué. L'équipe Swoole a annoncé le renommage sur le compte officiel WeChat de Swoole le 18 juin 2026, et le dépôt GitHub est sur swoole/aot-compiler. Une beta binaire est promise pour la Fête nationale chinoise (1er octobre 2026), et la release complète du code source est prévue après cette date. L'ancien nom de produit, Swoole AOT, est en cours d'abandon."
  - question: "En quoi TypePHP diffère-t-il d'un PHP plus rapide ?"
    answer: "TypePHP n'est pas positionné comme un PHP plus rapide. C'est un langage compilé distinct qui utilise la syntaxe PHP et livre le ZendVM comme composant runtime, et non comme modèle d'exécution principal. Le programme principal est compilé en code machine natif, et le binaire compilé peut en plus charger des fichiers `.php` ordinaires au runtime via `require` et `include`, ce qui maintient la surface d'extensions PHP, l'autoload Composer, et le code d'extension C/C++ existants en état de marche. Pronskiy le formule sans détour dans son article X : plus TypePHP avance, moins il est du PHP, ce qui est la même trajectoire qu'a prise Facebook d'HipHop à Hack à HHVM."
  - question: "Mon code PHP existant va-t-il tourner sur TypePHP ?"
    answer: "Oui, dans le sens où TypePHP préserve la compatibilité syntaxique PHP totale et livre le ZendVM comme runtime de repli. L'exécutable compilé peut faire `require` ou `include` des fichiers `.php` ordinaires au runtime et les interpréter via le Zend embarqué, donc le même autoload Composer, la même pile d'extensions, et le même code d'extension C/C++ qui tourne sur PHP 8.x devraient tourner dans un binaire TypePHP sans modification. L'affirmation de l'équipe Swoole est une compatibilité à 100 % avec l'écosystème PHP, y compris les paquets Composer tiers et les extensions C/C++ auto-écrites. La nuance est que les fonctionnalités au niveau du langage qui n'existent pas en PHP (BigInt, conteneurs typés, UFCS) ne fonctionnent que dans le code qui cible le compilateur TypePHP."
  - question: "En quoi TypePHP diffère-t-il de KPHP, HHVM, PeachPie ou FrankenPHP ?"
    answer: "KPHP (VK, GPL-3.0, 1 500+ étoiles) est l'antériorité la plus proche : il compile un dialecte PHP vers C++ et livre des binaires natifs, mais il n'embarque pas le runtime Zend, donc des fichiers `.php` non modifiés ne peuvent pas être chargés au runtime. HHVM (Meta) a commencé comme un PHP plus rapide et a dérivé vers Hack, un langage distinct, ce qui est le récit édifiant que cite Pronskiy. PeachPie compile PHP vers .NET, avec un modèle de runtime différent. FrankenPHP (11 000+ étoiles, MIT) est un serveur d'applications PHP moderne écrit en Go qui peut livrer un binaire standalone, mais il embarque l'interpréteur PHP, pas un artefact compilé. Le différenciateur de TypePHP est le moteur dual : code machine statiquement compilé plus un Zend embarqué qui peut interpréter du PHP non modifié à la volée, avec l'accès à l'ABI C++ comme fonctionnalité de première classe."
  - question: "Puis-je appeler du code C, C++, Rust ou Go depuis TypePHP ?"
    answer: "Oui. TypePHP est construit directement sur l'ABI C++, et un programme TypePHP peut appeler dans des bibliothèques statiques `.a`/`.lib` et des bibliothèques dynamiques `.so`/`.dll` produites par C, C++, Rust et Go sans écrire d'extension PHP. Les exemples de référence dans le dépôt swoole/aot-compiler livrent un pont JNI qui appelle Java via `jni.h` et `libjvm.so` (Java 25), un jeu Tetris dont la couche graphique est implémentée en C++ contre SDL, et un hello world GUI Windows. Le mécanisme est un pattern de fichier stub : une classe C++ hérite de `Box`, un stub côté PHP déclare les fonctions C++, et le compilateur câble l'appel au moment de la compilation."
  - question: "Quelles sont les trois nouvelles fonctionnalités linguistiques de TypePHP ?"
    answer: "Premièrement, les types natifs BigInt, BigFloat et Decimal pour l'arithmétique en précision exacte. Avec `use decimal_types;`, `0.1 + 0.2` affiche `0.3` plutôt que le `0.30000000000000004` IEEE-754 que vous obtenez en PHP. Avec `use bigint_types;`, `2 ** 80` affiche `1208925819614629174706176` plutôt que de déborder vers un float. Deuxièmement, quatre conteneurs fortement typés : `std::array(type, size)`, `std::vector(type, [size])`, `std::map(ktype, vtype)`, et `std::unordered_map(ktype, vtype)`, qui remplacent le `array` universel du PHP par des structures typées soutenues par le C++. Troisièmement, la syntaxe d'appel de fonction uniforme, qui permet à n'importe quelle valeur de recevoir un appel de méthode contre n'importe quelle fonction (`$a = 2; $a->pow(80)->toString()->length();`) et permet au code utilisateur d'enregistrer des méthodes d'extension sur des types intégrés."
  - question: "TypePHP est-il réellement open source ?"
    answer: "Pas encore. Au 18 juin 2026, le dépôt swoole/aot-compiler sur GitHub contient un README et des projets d'exemple, et la page des releases héberge des binaires test closed-source pour Windows x86_64, Linux x86_64 et macOS arm64, actuellement en v0.2.3. L'équipe Swoole s'est engagée à téléverser le code source du compilateur après la beta du 1er octobre 2026. L'article X de Pronskiy soulève la question ouverte : le Swoole Compiler 3.2 existant est un produit commercial vendu via business.swoole.com, et une release open source de type MIT pour la ligne AOT n'a pas été confirmée."
  - question: "Que signifie « compilateur auto-hébergé » pour TypePHP ?"
    answer: "Cela signifie que le compilateur TypePHP est en cours d'écriture en TypePHP lui-même, dans la même tradition que le compilateur Go écrit en Go. Le premier compilateur TypePHP alpha a été compilé via Zend PHP, puis utilisé pour se compiler lui-même, et l'équipe Swoole rapporte que dans la v0.2.3 actuelle, le binaire compilé auto-hébergé et le binaire compilé par Zend PHP passent tous deux la suite complète de tests unitaires. L'auto-hébergement n'est pas qu'un point stylistique : c'est un stress test sur les nouvelles fonctionnalités linguistiques, parce que le compilateur exerce les conteneurs typés, l'arithmétique BigInt, l'UFCS, et les appels à l'ABI C++ en code de production plutôt que dans des exemples jouet."
---

Dans la matinée du 18 juin 2026 (heure de Pékin), le compte officiel WeChat de l'équipe Swoole a publié une annonce tenant en un écran : le projet de compilateur Swoole AOT a été formellement renommé **TypePHP**, un binaire beta est promis avant la Fête nationale chinoise le 1er octobre 2026, et le code source complet sera téléversé sur GitHub après cette date. La même semaine, Roman Pronskiy, responsable de PhpStorm chez JetBrains et membre du conseil de la PHP Foundation, a publié un article X intitulé *« Swoole AOT is officially becoming TypePHP »*, observant que l'équipe énonce désormais sans détour ce qu'elle n'avait fait qu'effleurer précédemment : il s'agit d'un langage compilé fortement typé distinct, et non d'un interpréteur PHP plus rapide. Les deux sources s'accordent sur les chiffres de une. Les questions intéressantes sont toutes dans le mécanisme, et il y a plus de mécanisme que ce que le post WeChat ou l'article X peuvent contenir.

Les deux documents source lus ensemble donnent une image plus claire que l'un ou l'autre seul. Le post WeChat est l'annonce officielle et porte les affirmations techniques dans le cadrage de l'équipe. L'article de Pronskiy est la lecture venue de l'extérieur, écrite par la personne qui dirige l'IDE que la plupart des développeurs PHP utilisent, et inclut la correction de cadrage que le reste de l'industrie va entendre en premier : TypePHP est sur la même trajectoire que celle qu'a prise Facebook d'HipHop à Hack à HHVM, et la question qui mérite d'être posée en octobre n'est pas de savoir si le binaire tourne plus vite que PHP, mais si le langage est encore du PHP.

Avant d'aller plus loin, la correction de cadrage qui mérite d'être énoncée d'emblée : TypePHP n'est pas un nouveau JIT pour le moteur Zend, et ce n'est pas un successeur du runtime Swoole. Swoole à proprement parler est l'extension PHP asynchrone, basée sur les coroutines, qui a été le runtime haute performance de facto pour PHP en Chine depuis la dernière décennie, et il vit à swoole/swoole-src (18 890 étoiles, dernier push le 8 juin 2026). TypePHP vient d'une autre ligne de produits au sein de la même société, le Swoole Compiler, qui a été vendu commercialement depuis la branche 3.x comme outil de chiffrement et d'obfuscation d'opcodes PHP. La version 4.0 de ce compilateur est celle qui est renommée. Le compilateur est construit sur `swoole/phpx`, le wrapper C++ de l'équipe pour l'API du moteur Zend (856 étoiles, Apache-2.0, dernier push le 17 juin 2026), qui est la même bibliothèque qui a alimenté pendant des années le travail d'extension C++/PHP de l'entreprise. Le renommage n'est pas une histoire de runtime ; c'est une histoire de compilateur qui se trouve livrer un runtime comme couche de compatibilité.

## Le design double moteur

La décision architecturale la plus lourde de conséquences dans TypePHP est que le ZendVM n'est pas retiré. Il est livré à l'intérieur du binaire compilé comme runtime de repli. L'annonce WeChat l'indique directement : le programme principal est compilé en instructions machine natives de manière statique, mais l'exécutable peut toujours appeler `require` et `include` pour charger des scripts `.php` ordinaires au runtime, et ces scripts sont interprétés via le Zend embarqué. L'équipe Swoole appelle cela le « double moteur », et la conséquence immédiate est la compatibilité totale avec l'écosystème PHP. L'autoload Composer fonctionne, les extensions curl, mysqli et PDO fonctionnent, l'extension Swoole fonctionne, et toute extension C/C++ auto-écrite qui tourne contre PHP 8.x tourne à l'intérieur du binaire TypePHP sans recompilation.

C'est le choix de design qui distingue TypePHP de tout compilateur PHP-vers-natif antérieur. KPHP, le projet VK qui est l'analogue le plus proche, compile un dialecte PHP vers C++ et produit des binaires natifs, mais il n'embarque pas le runtime Zend, donc des fichiers `.php` non modifiés ne peuvent pas être chargés au runtime et la surface d'extensions est un sous-ensemble curated. TypePHP préserve la surface d'extensions complète parce qu'il n'essaie pas de retirer Zend. Le binaire compilé utilise simplement du code natif pour le chemin chaud et retombe sur l'interprétation quand il voit un fichier qu'il n'a pas compilé. L'équipe Swoole travaille sur cette architecture à double moteur depuis des années sous la marque AOT, et le renommage en TypePHP est en partie une reconnaissance que c'est désormais la propriété définitoire du projet, et non un détail d'implémentation transitoire.

L'affirmation de performance, dix à cent fois supérieure au PHP, concerne la partie compilée du programme. Parce que la sortie compilée est en instructions machine natives sans interpréteur dans la boucle, le chemin type-spécialisé, inlinable, à prédiction de branchement d'une boucle serrée sera aussi rapide que le code C++ équivalent. La partie interprétée, quand le programme choisit de charger un script `.php` au runtime, tourne à la vitesse PHP standard, mais l'équipe Swoole argue que l'essentiel du travail dans une application typique peut être compilé à l'avance, avec les parties dynamiques réservées à la petite surface qui a réellement besoin d'être dynamique (chargement de plugins, scripts de configuration, paquets Composer tiers qui n'ont pas été recompilés). Pour une application pleinement recompilée, le double moteur est invisible. Pour une application partiellement compilée qui charge encore des plugins dynamiques, le moteur est un filet de sécurité, pas une régression.

Il y a une affirmation connexe qui mérite d'être prise au sérieux en ses propres termes : le binaire compilé ne peut pas être décompilé en code source PHP. Le post WeChat l'indique explicitement comme fonctionnalité, cadrée autour du déploiement de logiciels commerciaux. La visibilité du source PHP a toujours été un point de friction pour les vendeurs qui veulent distribuer des applications closed-source, et le Swoole Compiler 3.2 existant vend précisément du chiffrement d'opcodes et de l'obfuscation de flux de contrôle pour combler cet écart. TypePHP ne chiffre pas les opcodes ; il produit du code machine, qui est intrinsèquement plus difficile à rétro-concevoir que du bytecode. Le cadrage IP-commercial du projet n'est pas une note de bas de page ; c'est l'une des deux ou trois raisons pour lesquelles l'équipe Swoole a investi des années dans la ligne de compilateur.

## Les trois nouvelles fonctionnalités linguistiques

TypePHP est décrit comme étant à compatibilité syntaxique PHP, mais le langage n'est pas un sous-ensemble strict de PHP. L'équipe Swoole a ajouté trois zones de fonctionnalités qui n'existent pas en PHP 8.x, et chacune d'elles est un vrai changement ergonomique ou de performance pour le code écrit contre TypePHP, et non une ligne marketing.

La première fonctionnalité est l'arithmétique native en précision exacte. Les floats PHP sont des doubles IEEE-754, et l'exemple canonique de la perte de précision est `0.1 + 0.2` qui s'évalue en `0.30000000000000004`. Dans TypePHP, importer `decimal_types` fait du littéral float par défaut un `Decimal` plutôt qu'un `float`, et `0.1 + 0.2` affiche `0.3` exactement. Importer `bigint_types` fait la chose analogue pour les littéraux entiers, donc `2 ** 80` s'évalue en `1208925819614629174706176` plutôt que de déborder en float comme il le ferait en PHP. Le type BigFloat est le troisième membre de la même famille. Le post WeChat présente ceux-ci comme la réponse aux cas d'usage de calcul scientifique et financier où l'erreur en virgule flottante est inacceptable ; l'implémentation pratique semble être un commutateur au niveau du littéral configurable plutôt qu'un remplacement en gros du type float, ce qui laisse la porte ouverte au code qui a réellement besoin du chemin IEEE-754.

```php
use decimal_types;

function main() {
    $v1 = 0.1;
    $v2 = 0.2;
    // TypePHP : 0.3. PHP : 0.30000000000000004.
    echo $v1 + $v2;
}
```

La deuxième fonctionnalité est quatre conteneurs fortement typés. Le `array` PHP est universel : il est à la fois une liste et un map, les clés et les valeurs sont non typées, et la même structure doit servir tous les cas d'usage de collection. TypePHP remplace cela par `std::array(type, size)` pour les tableaux de taille fixe, `std::vector(type, [size])` pour les tableaux dynamiques, `std::map(ktype, vtype)` pour les maps ordonnées soutenues par un arbre rouge-noir, et `std::unordered_map(ktype, vtype)` pour les maps de hachage non ordonnées. Les noms et les implémentations sous-jacentes sont des appels directs dans la bibliothèque standard C++, qui est la même stratégie que celle qu'ont utilisée Phlex et d'autres projets de langage système pour obtenir une performance déterministe et une disposition mémoire prévisible. Les conteneurs de la bibliothèque standard C++ sont aussi la raison pour laquelle l'équipe Swoole peut livrer un compilateur auto-hébergé : les conteneurs typés ne sont pas une structure de données custom avec un modèle mémoire custom, ils sont une fine couche au-dessus de `std::vector` et amis, et le compilateur est assez petit pour être écrit en TypePHP lui-même.

```php
// Clé : string. Valeur : stdClass.
$map = std::map(complex_types::type_string, stdClass::class);
$map["key"] = new stdClass;
$map["key"]->data = "hello";
```

La troisième fonctionnalité est la syntaxe d'appel de fonction uniforme, abrégée UFCS, plus les méthodes d'extension. L'exemple WeChat est la façon la plus propre de voir l'idée. Avec UFCS, n'importe quelle valeur peut recevoir un appel de méthode contre n'importe quelle fonction :

```php
$a = 2;
// 2^80, vers string, puis longueur de cette string.
echo $a->pow(80)->toString()->length();

$b = "hello world!";
// Split, puis vérifier si la liste résultante contient "world".
$b->split(' ')->contains("world");
```

En PHP standard, appeler `pow(2, 80)` retourne un int (ou un float en cas de débordement), `toString()` n'est pas une méthode, et `length()` n'est pas une méthode sur une string. Dans TypePHP, le compilateur résout `$a->pow(80)` vers `pow($a, 80)`, `$a->pow(80)->toString()` vers `toString(pow($a, 80))`, et ainsi de suite, en chaînant les appels. C'est une fonctionnalité qui existe en D, Nim, et (avec des caveats) Rust, et l'effet pratique est qu'ajouter de nouvelles méthodes à des types existants ne nécessite pas d'étendre la bibliothèque standard, parce que n'importe quelle fonction définie par l'utilisateur peut être appelée comme méthode. La fonctionnalité compagne, les méthodes d'extension, permet à l'utilisateur de déclarer `function int_to_bytes(int $num): string` et ensuite d'appeler `$value->toBytes()` sur un entier, le compilateur dispatchant vers la méthode d'extension quand le type correspond. Le post WeChat inclut l'exemple travaillé :

```php
function int_to_bytes(int $num): string {
    return ($num / 1024) . 'Kb';
}

$value = 92160;
// Le compilateur matche int_to_bytes, affiche "90Kb".
echo $value->toBytes();

var_dump($value->toBytes()->equals('90Kb'));
```

Les trois fonctionnalités ensemble sont le design de langage qui fait que TypePHP ressemble moins à un dialecte PHP et davantage à un petit langage fortement typé qui se trouve partager la syntaxe de surface de PHP. C'est aussi la question que pose Pronskiy, et c'est celle qui va dominer le discours autour du projet en octobre.

## L'ABI C++ comme fonctionnalité de première classe

La décision de construire le compilateur sur l'ABI C++, plutôt que sur un modèle d'extension PHP, est le deuxième choix architectural qui change la nature du projet TypePHP. Le post WeChat pose le point directement : un programme TypePHP n'a pas besoin d'être enveloppé dans une extension C/C++ pour appeler du code natif. Il peut lier contre des bibliothèques statiques `.a` et `.lib`, et charger des bibliothèques dynamiques `.so` et `.dll`, produites par C, C++, Rust et Go, sans code glue au-delà d'une déclaration stub. Le compilateur câble l'appel au moment de la compilation, et le binaire résultant appelle le code natif à travers la convention d'appel C++ standard.

Les exemples de référence dans le dépôt `swoole/aot-compiler` démontrent à quoi cela ressemble en pratique. Le répertoire `examples/jni` contient un pont JNI complet : le côté C++ inclut `<jni.h>` et `<phpx.h>`, lie contre `-ljvm`, et expose un petit ensemble de fonctions `jni_init`, `jni_find_class`, `jni_new_object`, `jni_call`, `jni_get`, `jni_set` au côté PHP. Le côté PHP instancie un objet Java `Hello`, appelle une méthode `greet` dessus, lit et écrit les champs `name` et `age` via l'API de réflexion JNI, et affiche les résultats. Le `project.yml` de l'exemple liste les chemins d'inclusion JDK 25 et le flag `-Wl,-rpath` qui pointe vers la bibliothèque partagée JVM. L'exemple compile et tourne contre une installation OpenJDK non modifiée.

Le répertoire `examples/tetris-sdl` va plus loin. La logique du jeu, état du plateau, rotation des pièces, suppression des lignes, score, détection de fin de partie, est implémentée en TypePHP, et les appels graphiques SDL sont implémentés en C++ contre le fichier source `cpp-src/tetris.cc`. Le côté C++ définit une classe `TetrisBox` qui hérite de `Box` (la classe de base C++ dans `phpx` pour les objets exposés à PHP), et le côté PHP détient une référence `mixed $game` qui pointe vers une instance `TetrisBox`. La couche C++ gère la fenêtre SDL, la boucle de rendu, la gestion des événements clavier, et le rendu UTF-8 pour la documentation en chinois. Un fichier `tetris.stub.php` déclare les fonctions et types C++ pour que le compilateur TypePHP puisse résoudre les appels. Le répertoire `examples/win32-hello` fait l'équivalent pour l'API Win32 : un hello world console, un hello world GUI avec une classe de fenêtre et une boucle de messages, et une troisième variante qui démontre la couche de configuration Windows du projet. Le répertoire `examples/tetris-win32` est le port Windows natif de l'exemple Tetris SDL.

Le pattern est le même dans les quatre cas. Le côté C++ implémente le code spécifique à la plateforme ou critique en performance, le côté TypePHP implémente la logique applicative, et le fichier stub est le contrat entre les deux. Il n'y a pas d'extension PHP impliquée. L'étape de compilation est `php bin/compiler.php build examples/tetris-sdl` (ou l'équivalent contre le `bin/compiler.php` livré avec le binaire closed-source), et la sortie est un `.exe` Windows qui peut être double-cliqué. C'est le même pattern architectural que celui qu'utilise Flutter pour exposer les APIs de plateforme, et le même pattern qui permet à une application Rust d'appeler une bibliothèque C via `extern "C"`. La nouveauté est de le faire depuis du code source à syntaxe PHP, avec la convention d'appel côté PHP résolue par le compilateur, et avec le runtime Zend livré aux côtés du code compilé pour le repli.

La bibliothèque phpx qui rend tout cela possible mérite d'être connue en ses propres termes. `swoole/phpx` est un wrapper C++ pour l'API du moteur Zend qui est présent dans l'écosystème Swoole depuis 2017 (il précède le compilateur AOT de plusieurs années), et c'est ce qui rend l'intégration C++ ergonomique. Sans phpx, le code C++ qui expose une classe à PHP devrait gérer manuellement le comptage de références Zend, la coercition de type, et la danse de pile d'appels, ce qui est exactement la friction qui a historiquement fait du développement d'extension PHP une activité de spécialiste. Avec phpx, le code C++ se lit comme du C++ normal qui se trouve interagir avec des objets de style PHP. La classe `Box` du compilateur AOT est une primitive phpx, et la ligne `using namespace php;` de l'exemple JNI est ce qui fait que le côté C++ se sent comme un pair du côté PHP. La même bibliothèque est ce sur quoi l'extension Swoole existante est construite, et le compilateur AOT est l'extension naturelle de l'investissement de l'équipe dans l'interop C++/PHP.

## Comment TypePHP se compare à KPHP, HHVM, PeachPie, FrankenPHP et RoadRunner

L'écosystème PHP a connu une demi-douzaine de tentatives sérieuses pour rendre le langage plus rapide, et TypePHP est la plus récente. Chacun des projets antérieurs a fait un compromis différent, et le compromis que fait TypePHP est le plus ambitieux et le plus risqué.

**KPHP** ([VKCOM/kphp](https://github.com/VKCOM/kphp), 1 515 étoiles, GPL-3.0, dernier push le 18 juin 2026) est l'antériorité la plus proche. KPHP compile un dialecte PHP vers C++, puis passe le C++ à travers un compilateur système pour produire un binaire natif. Le programme résultant est dramatiquement plus rapide que le PHP interprété, et le projet a été production-grade à l'échelle de VK pendant des années. Le compromis que fait KPHP est le même que celui que fait tout compilateur PHP-vers-C++ : il n'embarque pas le runtime Zend, il ne supporte pas la surface d'extensions PHP complète, et le dialecte est un sous-ensemble strict de PHP avec des annotations de typage. Le code qui tourne sur KPHP est un programme KPHP, et le code qui ne l'est pas n'est pas portable. Le GitHub de KPHP est activement maintenu, et le projet reste la preuve la plus forte qu'un PHP compilé est techniquement viable à l'échelle. Le différenciateur de TypePHP face à KPHP est le double moteur et l'intégration à l'ABI C++, deux choses que KPHP n'a explicitement pas.

**HHVM** ([facebook/hhvm](https://github.com/facebook/hhvm), 18 632 étoiles, licence NOASSERTION, dernier push le 18 juin 2026) est le récit édifiant qu'invoque Pronskiy. HHVM a commencé comme le compilateur HipHop, un projet interne de Facebook pour rendre PHP plus rapide, et a fini comme le runtime de Hack, un langage distinct qui a forké la syntaxe PHP de manière incompatible. La communauté PHP a passé une décennie à débattre pour savoir si Hack était encore du PHP, et la réponse pratique est non : le système de types, la bibliothèque standard, et les extensions linguistiques sont tous séparés. Le projet HHVM est toujours maintenu, mais son cas d'usage principal est maintenant de faire tourner du code Hack existant chez Meta, et non de faire tourner du code PHP de la communauté élargie. Le point de Pronskiy est que la trajectoire du « PHP rapide » au « langage distinct » est un chemin bien balisé, et que TypePHP est sur la partie précoce de ce chemin. Le renommage de « Swoole AOT » en « TypePHP » est, dans sa lecture, le moment où le projet s'engage sur le fork de langage.

**PeachPie** ([peachpiecompiler/peachpie](https://github.com/peachpiecompiler/peachpie), 2 480 étoiles, Apache-2.0, dernier push le 9 juin 2026) compile PHP vers .NET, avec le runtime hébergé sur CoreCLR. L'avantage est l'accès complet à l'écosystème .NET, le désavantage est le même problème de dialecte que KPHP, plus une dépendance runtime à .NET. PeachPie est la meilleure option pour les organisations qui sont déjà dans des shops .NET et veulent consommer des bibliothèques PHP, mais ce n'est pas un candidat pour l'accélération générale de PHP. TypePHP et PeachPie ne sont pas des concurrents directs ; ils ciblent des stacks de déploiement différents.

**FrankenPHP** ([php/frankenphp](https://github.com/php/frankenphp), 11 156 étoiles, MIT, dernier push le 15 juin 2026) est le serveur d'applications PHP moderne, écrit en Go au-dessus de Caddy. FrankenPHP embarque l'interpréteur PHP, supporte la fonctionnalité HTTP early-hints, et peut être packagé en binaire standalone qui contient PHP et l'application ensemble. Les gains de performance sur PHP-FPM sont substantiels, et l'histoire opérationnelle est bien plus simple que de faire tourner PHP derrière nginx. FrankenPHP n'est pas un compilateur ; c'est un serveur. La comparaison avec TypePHP est « runtime plus rapide » contre « binaire compilé », et les deux résolvent des problèmes différents. FrankenPHP est ce vers quoi vous vous tournez quand vous voulez déployer des applications PHP existantes plus vite ; TypePHP est ce vers quoi vous vous tournez quand vous voulez écrire du nouveau code dans un langage fortement typé qui ressemble à PHP.

**RoadRunner** ([roadrunner-server/roadrunner](https://github.com/roadrunner-server/roadrunner), 8 472 étoiles, MIT, dernier push le 17 juin 2026) est un serveur d'applications PHP et un gestionnaire de processus écrit en Go. RoadRunner conserve PHP-FPM comme processus worker mais remplace le serveur web front-end par un binaire Go qui gère les requêtes, les fichiers statiques, et les WebSockets nativement. L'architecture est hybride : PHP est interprété, Go est compilé, et la frontière est bien définie. RoadRunner est l'analogue le plus proche en esprit du double moteur de TypePHP, sauf que la frontière dans RoadRunner est entre deux processus, et non entre deux modèles d'exécution à l'intérieur du même binaire.

Les différenciateurs qui rendent TypePHP distinct de tous ceux-ci : le double moteur, l'ABI C++ comme fonctionnalité de première classe, les conteneurs typés, les types BigInt/BigFloat/Decimal, l'UFCS, et le compilateur auto-hébergé. Le double moteur est le seul qui nécessite un runtime Zend embarqué, et l'intégration à l'ABI C++ est la seule qui traite l'interop native comme une capacité primaire plutôt qu'une API d'extension. Les autres fonctionnalités (Decimal, conteneurs typés, UFCS) sont indépendantes de la question de la syntaxe PHP, et elles seraient précieuses dans n'importe quel langage. La question à laquelle TypePHP devra répondre en octobre est de savoir si les fonctionnalités linguistiques sont le propos, ou si la syntaxe PHP est le propos. L'annonce actuelle suggère que les fonctionnalités linguistiques sont le propos et que la syntaxe PHP est la surface, ce qui place le projet du côté du fork de langage dans la dichotomie de Pronskiy.

## L'état de la release mi-juin 2026

À la date de l'annonce, TypePHP est dans un état pré-beta. Le dépôt `swoole/aot-compiler` sur GitHub a été créé le 11 mai 2026, la release v0.1.0 a été livrée le même jour avec un binaire Windows x86_64 (43 Mo), un binaire Linux x86_64 (726 Ko), et un binaire macOS arm64 (1,6 Mo). La release v0.2.3 du 15 juin 2026 a livré des binaires Windows (52 Mo) et Linux (2 Mo) mis à jour. Les assets de release sont des binaires pré-construits closed-source ; le dépôt lui-même ne contient que le README et les projets d'exemple. Le README décrit le projet comme la ligne de produit commerciale Swoole Compiler : la version 3.2, le produit commercial existant, « chiffre et obfuscate le bytecode opcode PHP, en employant obfuscation de flux de contrôle, instructions parasites, obfuscation de variables, obfuscation de noms de fonctions, protection par machine virtuelle, aplanissement de code, optimisation SCCP, et autres techniques pour compiler le code source PHP en bytecode binaire chiffré ». La version 4.0 est le nouveau compilateur AOT, décrit comme « compile le code PHP directement en instructions binaires, produisant des exécutables natifs ou des bibliothèques dynamiques pour des plateformes telles que Windows, Linux, et macOS ». Le lien de documentation dans le README pointe vers `doc.swoole.com/@aot-compiler/`, qui retourne un 404 au moment de l'écriture (la page renvoie « 知识管理 404 文档不存在或已被删除 », une page 404 en chinois), ce qui suggère que la documentation est en cours de migration en parallèle du renommage.

Les binaires v0.1.0 et v0.2.3 sont les « versions de test » que le post WeChat invite les lecteurs à télécharger. L'affirmation de l'équipe Swoole est que dans la v0.2.3, à la fois le compilateur auto-hébergé et le compilateur compilé par Zend PHP passent la suite complète de tests unitaires, ce qui est le jalon qui leur permet de promettre une beta en octobre. Les cinq commits visibles sur la branche `main` sont datés entre le 11 et le 19 mai 2026, avec des messages de commit axés sur le support d'extension JNI, le scaffold initial, et le README. La cadence de release entre v0.1.0 (11 mai) et v0.2.3 (15 juin) implique une période de développement assez active, mais l'absence de commits sur `main` depuis le 19 mai suggère que le travail post-renommage est fait sur une branche feature ou dans un miroir privé qui sera rendu public après la release source.

La question de l'open source est celle que Pronskiy a signalée. Le post WeChat utilise la phrase « 全面开源 » (entièrement open-sourcé) pour la release post-Fête nationale, mais le Swoole Compiler existant est un produit commercial, et le README du dépôt `swoole/aot-compiler` lie explicitement vers `business.swoole.com/compiler.html`, la page de vente commerciale. Le post WeChat lui-même se termine par une invitation à ajouter le compte WeChat « 识沃客服 » (service client Twosee) pour la discussion développeur, qui est le canal commercial go-to-market de l'entreprise. La lecture raisonnable est que la release open source sera une édition communautaire, avec un produit commercial séparé assis dessus pour le déploiement en production, le chiffrement, et le support, le même modèle que HHVM a utilisé quand il a été open-sourcé. La formulation exacte de Pronskiy dans son article X est que « open source ne signifie pas gratuit, mais je suppose que c'est l'implication », ce qui est le bon niveau d'incertitude à conserver jusqu'en octobre.

## La critique de Pronskiy et la question du fork de langage

Le cadrage de Roman Pronskiy est la lecture que le reste de l'industrie va recevoir en premier, parce que Pronskiy est le responsable de PhpStorm chez JetBrains, l'IDE que la plupart des développeurs PHP professionnels utilisent, et membre du conseil de la PHP Foundation, le non-profit qui finance les personnes qui maintiennent le langage lui-même en vie. Ce n'est pas un observateur neutre, mais c'est aussi l'observateur neutre le mieux informé qui n'est pas dans l'équipe Swoole. Son article X cadre le renommage en trois phrases qui méritent d'être lues comme un tout : « Alors que les generics échouent au vote, voici une continuation de l'histoire du compilateur Swoole AOT (j'en ai écrit plus tôt). Il est maintenant officiellement renommé TypePHP. Ils l'ont mentionné brièvement la dernière fois, mais maintenant ils le disent ouvertement : c'est un langage compilé fortement typé distinct. » La première phrase est celle qu'on sous-estime. La RFC PHP pour les generics dans le langage lui-même était en train d'échouer au vote au moment même où TypePHP était annoncé, ce qui est le genre de coïncidence de timing que l'équipe Swoole n'avait pas besoin d'orchestrer mais dont elle a bénéficié. La deuxième phrase est l'information. La troisième phrase est le cadrage.

Sa section « what else is cool » est la lecture positive. Les trois fonctionnalités qu'il met en avant, Decimal natif, conteneurs typés, UFCS, sont exactement les fonctionnalités avec lesquelles l'équipe Swoole ouvre le bal, et la réaction de Pronskiy (« Whaaaat?! You could do that all along?? ») est la réaction que l'équipe espère. L'UFCS en particulier est le genre de fonctionnalité qui enchante les développeurs la première fois qu'ils la voient et qui devient ensuite un outil vers lequel ils se tournent automatiquement, et le comparse de méthode d'extension est la partie qui rend la fonctionnalité composable avec du code existant.

Son « mais » est la lecture à laquelle l'industrie va prêter attention. Pronskiy trace la ligne directement : « Plus ça va, moins c'est du PHP. On a déjà vu ça : Facebook a fait du "PHP rapide" → ça s'est transformé en Hack → un langage séparé → l'écosystème s'est divisé → et te voici. » C'est l'argument central, et c'est l'argument qui sera fait par chaque mainteneur de framework PHP, chaque hébergeur, et chaque développeur qui a déjà décidé que PHP est une contrainte non négociable sur sa stack. L'équipe Swoole est en position de devoir répondre à cet argument, et la réponse devra être plus substantielle que « nous avons un double moteur ».

Il y a deux façons dont la réponse peut aller. La première est que le double moteur tient : chaque application PHP continue de tourner à l'intérieur d'un binaire TypePHP, et les fonctionnalités linguistiques sont des extensions opt-in qui ne cassent jamais la compatibilité PHP. L'affirmation énoncée par l'équipe Swoole d'une compatibilité à 100 % avec l'écosystème PHP est le pari, et la v0.2.3 avec le compilateur auto-hébergé qui passe les tests unitaires est la première preuve que le pari est sur les rails. La seconde est que les fonctionnalités linguistiques deviennent le défaut et que la compatibilité PHP devient le mode legacy, comme Hack est passé de « PHP avec annotations de type » à « un langage distinct qui se trouve être analysable comme PHP ». Le renommage de « Swoole AOT » en « TypePHP » est le signal précoce que la deuxième voie est au moins plausible, parce que l'équipe ne cadre plus le projet comme un compilateur pour PHP, mais comme un langage à part entière.

La release d'octobre sera le point d'inflexion. Si le code source est publié sous une licence permissive (MIT, Apache-2.0, ou similaire), si la documentation décrit TypePHP comme un langage séparé et le Swoole AOT existant comme le shim de compatibilité, et si les fonctionnalités linguistiques sont présentées comme primaires plutôt qu'opt-in, le projet est sur la voie du fork de langage. Si la source est publiée sous une licence source-available, si la documentation maintient TypePHP dans le cadrage de l'écosystème PHP, et si les fonctionnalités linguistiques sont présentées comme des extensions opt-in, le projet est sur la voie de la couche de compatibilité. Les releases binaires et le post WeChat penchent tous deux vers la voie du fork de langage. Les termes de licence réels, quand ils apparaîtront, confirmeront dans quel sens l'équipe s'engage.

## Ce qu'il faut surveiller

Le signal suivant est la release du code source sur le dépôt `swoole/aot-compiler`. L'équipe Swoole s'est engagée à téléverser la source « 国庆节后 » (après la Fête nationale, qui est le 1er octobre 2026), et les termes de licence attachés à ce téléversement sont le point de données le plus important. Une licence permissive (MIT, Apache-2.0, BSD) signale que l'équipe s'engage sur la voie du fork de langage avec l'écosystème PHP existant comme cible de migration. Une licence source-available (la BSL, la SSPL, la Business Source License, ou une licence commerciale custom Swoole) signale que l'équipe s'engage sur la voie du fork de langage avec un produit commercial assis dessus, comme HashiCorp et Elastic l'ont fait.

Le deuxième signal est la documentation à `doc.swoole.com/@aot-compiler/`, qui retourne un 404 au moment de l'écriture. Quand la documentation sera en ligne, la façon dont le projet est cadré confirmera ou contredira le cadrage fork de langage du post WeChat. Regardez spécifiquement si la documentation appelle le projet un « compilateur pour PHP » ou un « langage compilé à compatibilité syntaxique PHP », et si les fonctionnalités linguistiques (Decimal, conteneurs typés, UFCS) sont présentées comme centrales ou comme extensions opt-in.

Le troisième signal est la bibliothèque `phpx`. Le wrapper C++ de l'équipe Swoole pour l'API Zend est sous licence Apache-2.0 depuis 2017, et c'est le fondement de l'intégration à l'ABI C++ du compilateur AOT. Si le compilateur AOT est publié sous une licence permissive mais que la bibliothèque phpx est déplacée vers une licence différente, ou si phpx est forké en un projet séparé pour la communauté open source, c'est un signal sur la frontière entre les produits open source et commerciaux. Le dépôt `swoole/phpx` actuel a 856 étoiles et est activement maintenu, et les wrappers C++ qu'il fournit sont exactement les wrappers dont un développeur tiers aurait besoin pour construire son propre pont C++/TypePHP.

Le quatrième signal est la réaction plus large de la communauté PHP. La PHP Foundation n'a pas encore publié de déclaration sur le renommage, et le silence est en soi un signal. La Foundation finance les personnes qui maintiennent le langage PHP lui-même, et un langage compilé distinct qui utilise la syntaxe PHP est un développement compétitif pour le récit de la Foundation d'un PHP comme langage unique en évolution. La réponse de la Foundation, quand elle viendra, clarifiera si la Foundation voit TypePHP comme un ajout sain à l'écosystème PHP (comme Swoole à proprement parler a été traité pendant des années) ou comme un fork qui doit être soit absorbé soit mis en opposition. L'article de Pronskiy est une lecture ; la réponse éventuelle de la Foundation sera l'institutionnelle.

Le cinquième signal est l'adoption dans la communauté PHP chinoise. Le post du compte officiel WeChat est le premier mouvement ; l'invitation au service client à la fin est le deuxième. L'équipe Swoole a un réseau profond dans la communauté PHP chinoise à travers le runtime Swoole existant, les membres chinois de la PHP Foundation, et le circuit de conférences PHP-China au sens large. Si la beta d'octobre arrive et que la communauté PHP chinoise l'adopte comme elle a adopté Swoole en 2014, le projet a une vraie base. Si la communauté le traite comme une curiosité et attend de voir si les fonctionnalités linguistiques survivent aux problèmes de compatibilité inévitables, le projet a le même avenir que KPHP : techniquement excellent, adoption de niche, maintenance à long terme par l'équipe d'origine.

Le dernier signal est la performance du compilateur en conditions réelles. L'affirmation « dix à cent fois plus rapide que PHP » est le chiffre phare, et il n'a pas encore été vérifié indépendamment. Les propres benchmarks de l'équipe Swoole, présumément à venir avec la release source, fixeront la baseline. Les benchmarks indépendants venant de l'extérieur de l'équipe, en particulier sur les charges applicatives web typiques (gestion de requêtes, requêtes base de données, sérialisation JSON, rendu de templates), détermineront si l'histoire de performance tient en production. Le double moteur complique l'histoire de benchmark, parce que le même binaire peut être configuré pour tourner en mode pleinement compilé, en mode pleinement interprété, ou en hybride des deux, et la performance relative des trois modes est le chiffre que l'écosystème utilisera pour prendre la décision build-vs-buy.

La release d'octobre est la date. D'ici là, la chose la plus utile qu'un développeur PHP puisse faire est de télécharger le binaire v0.2.3, de compiler l'exemple `examples/tetris-sdl` ou `examples/jni` contre, et de se former une lecture personnelle sur la question de savoir si les fonctionnalités linguistiques valent le compromis. L'équipe Swoole a rendu la version de test disponible précisément pour amorcer ces lectures précoces, et le discours autour du projet en octobre sera façonné par ce que trouveront les adopteurs précoces.