Joël Wurtz de JoliCode raconte comment il a construit rphp, une machine virtuelle PHP expérimentale en Rust, où les grands modèles de langage ont servi d'accélérateur plutôt que d'auteur. Un premier prototype a été généré en une seule journée à partir des connaissances du modèle. Il exécutait un sous-ensemble significatif de PHP, mais était extrêmement lent et implémentait une VM à pile, alors que PHP est une VM à registres — un écart qui peut modifier l'ordre de destruction des valeurs et le moment d'émission des erreurs, sur lesquels des bibliothèques existantes peuvent reposer.

L'objectif n'était délibérément pas de cloner le Zend Engine. Wurtz critique les réécritures comme celle de Bun pour leur recours massif aux blocs unsafe, ce qui selon lui vide le choix de Rust de son sens. Le projet visait plutôt à comprendre pourquoi PHP fonctionne comme il fonctionne et à concevoir une VM selon la philosophie de Rust : ownership, pas d'état global mutable, un minimum d'unsafe. La lecture des sources du Zend Engine avec l'IA comme partenaire de discussion a révélé que certaines optimisations reflètent des comportements de CPU anciens, tandis que PHP avait parfois déjà trouvé la meilleure solution il y a des années.

Deux idées d'architecture se distinguent. La VM est un objet autonome qui peut être instancié plusieurs fois par thread, ce qui simplifie les tests et l'intégration. Et un modèle de fork permet de cloner une VM préchargée et mise en pause avec une sémantique copy-on-write pour chaque requête : démarrer un kernel Symfony, mettre en cache des données coûteuses, appeler rphp_request_pause() — chaque requête repart de cet état chaud tout en restant isolée. Cela se situe entre le PHP classique par requête et le mode worker de FrankenPHP.

État actuel : environ 80 % des tests de compatibilité de base passent. L'exécution de PHP pur est 5 à 15 fois plus lente que le Zend Engine, mais le mode fork est environ 30 fois plus rapide que le mode classique de la VM — assez pour battre PHP avec FrankenPHP en mode classique sur l'application Symfony Demo, car l'état de l'application n'est pas reconstruit à chaque requête.

Le projet a pris environ un mois, avec un plan Claude Max 20x (environ 200 €) et les modèles Opus 4.8, Sonnet 4.6 et parfois Fable ; avec un pilotage constant, chacun des trois modèles aurait donné des résultats similaires selon Wurtz. Sa conclusion : l'IA a rarement raison du premier coup, produit parfois du code bâclé ou erroné qu'il faut vérifier, et ne remplace pas la compréhension — les contraintes strictes et déterministes de Rust en font un langage particulièrement adapté au travail assisté par IA, car les erreurs remontent automatiquement. Le code est sur GitHub : jolicode/rphp.