Un développeur réécrit PHP en Rust avec l'IA : 17 % des tests passent

Un score de 17,4 %. C'est le chiffre que le développeur Ekin Ertac affiche publiquement pour Phargo, son interpréteur PHP écrit intégralement en Rust, alors qu'il reconnaît lui-même ne jamais avoir écrit une ligne de Rust avant ce projet. Sur les 22 037 fichiers de test .phpt qui composent le test suite officiel de PHP, accumulés depuis trois décennies par l'équipe interne du langage, 3 844 passent aujourd'hui. Le code, lui, a été écrit presque entièrement par un agent IA.

L'histoire mérite qu'on s'y arrête, pas pour l'anecdote, mais parce qu'elle pose une question que tout développeur qui délègue du code à une IA devrait se poser : comment vérifier un travail qu'on est incapable de relire ?

Le principe : un humain qui ne comprend pas le code, un oracle qui ne triche pas

Le projet part d'un constat simple. Beaucoup de démonstrations de code généré par IA reposent sur une affirmation invérifiable : ça marche. Ertac s'inspire d'une approche différente, observée chez l'équipe du runtime JavaScript Bun : faire tourner le nouveau moteur contre une suite de tests réelle, écrite par des tiers, et ne jamais laisser l'IA juger elle-même son propre travail.

Le test suite officiel de PHP sert exactement ce rôle. Ce ne sont pas des tests que l'auteur du projet ou l'IA ont écrits pour se faire plaisir : ce sont les tests que l'équipe interne de PHP utilise depuis des années pour valider chaque comportement du langage, des calculs de dates avec changement d'heure jusqu'au formatage exact d'un float par var_dump(). Le score est recalculé automatiquement après chaque exécution et publié dans le dépôt. Un test passe ou ne passe pas, sans marge de négociation.

La boucle de travail décrite par Ertac tient en quatre étapes : l'IA analyse les échecs pour repérer le plus gros lot de tests cassés qu'elle peut corriger, elle implémente un correctif, elle relance le test suite complet (environ 22 000 tests, plusieurs minutes d'exécution), et le score sert de verdict. S'il monte, le commit est poussé. S'il baisse, l'humain redemande simplement de regarder à nouveau. Le rôle du développeur se résume à cadrer l'objectif et lire le tableau de bord, pas à relire le code Rust généré.

Un bug a menti pendant des semaines, et ce n'était pas l'IA

Le détail le plus instructif de ce retour d'expérience ne concerne pas l'IA, mais l'outillage de vérification lui-même. Pendant un temps, le taux de réussite a stagné alors que des tests visiblement simples continuaient d'échouer avec des sorties qui semblaient identiques à celles attendues. La cause : le dépôt de tests avait été récupéré avec des fins de ligne Windows (CRLF), et le comparateur du projet faisait une comparaison stricte octet par octet, alors que le lanceur de tests officiel de PHP normalise les fins de ligne avant de comparer. Une ligne de code de normalisation plus tard, des centaines de tests basculaient au vert d'un coup.

La leçon que retient Ertac est directe : le doute doit aussi porter sur l'instrument de mesure lui-même, pas seulement sur le code produit par l'IA. Depuis, chaque plateau suspect dans la courbe de progression déclenche la même question : est-ce le moteur qui est fautif, ou le tableau de bord qui ment ?

Des fonctions qui existent, s'exécutent, et ne font rien

Le test suite a surtout permis de débusquer une catégorie de bug particulièrement sournoise : des fonctions qui analysent correctement le code, s'exécutent sans erreur, mais ne produisent aucun effet réel. Le rapport en cite plusieurs, découvertes au fil des mois : la fonction clone était évaluée en NULL sur l'ensemble du moteur, ce qui cassait silencieusement toutes les dates DateTimeImmutable du projet ; unset() sur une clé de tableau ne faisait rigoureusement rien ; trim() ignorait l'argument de liste de caractères et se contentait de retirer les espaces ; les variables variables ($$variable) et les variables statiques de fonction n'existaient tout simplement pas ; spl_autoload_register() acceptait un autoloader sans jamais l'appeler ; et un catch (Throwable) n'attrapait rien du tout.

Chacun de ces bugs aurait survécu à une démonstration soignée, et probablement à une revue de code humaine si le relecteur ne maîtrisait pas Rust en profondeur. Aucun n'a survécu à 22 000 tests automatisés. C'est tout l'argument du projet : l'auteur ne peut pas auditer le code, alors il délègue l'audit à une suite de tests avec une exhaustivité qu'aucun humain ne tiendrait sur la durée.

WordPress tourne, mais 55 fois plus lentement

L'objectif final du projet était de faire tourner WordPress, un choix logique tant ce CMS accumule des décennies d'usages particuliers du langage. Le chemin a buté sur des cas limites très concrets : l'instruction goto (utilisée par le parseur HTML de WordPress), le paramètre par référence $count de str_replace, les échappements \xNN dans les classes de caractères regex, ou encore un bug de preg_split qui corrompait l'installation de la base de données en ignorant le drapeau PREG_SPLIT_DELIM_CAPTURE à l'intérieur de wpdb::prepare.

Le résultat, atteint après ce parcours : une installation WordPress fraîche se termine, la page d'accueil s'affiche depuis une base SQLite avec le thème réel et les permaliens, et /wp-admin/ se charge également sans erreur. En revanche, l'API REST reste non testée, et la page d'accueil met 7,1 secondes à répondre contre 126 millisecondes pour PHP natif, soit environ 55 fois plus lent. Le projet précise toutefois qu'une nouvelle machine virtuelle à bytecode, encore en cours d'intégration, obtient déjà des micro-benchmarks entre 1 et 3 fois la vitesse de PHP 8.5.

Notre lecture chez CZSyn

Ce projet ne prouve pas qu'une IA sait écrire un interpréteur de langage de manière fiable : elle a lu des milliers de lexers et de parseurs déjà publiés, ce n'est pas une surprise qu'elle en produise un qui fonctionne partiellement. Ce qu'il prouve, c'est autre chose, et c'est plus intéressant pour nous : un humain qui ne peut pas relire le code peut quand même garder un projet honnête, à condition de disposer d'un oracle de vérité externe, indépendant, et suffisamment exhaustif.

C'est exactement la limite que nous observons chez nos clients qui adoptent des agents de code sans changer leur méthode de validation. Un agent IA qui regarde son propre travail, ou qu'on valide sur une démonstration réalisée à la quatrième tentative, ne dit rien de la fiabilité réelle du résultat. Ce que ce projet illustre, c'est qu'un test suite tiers, exhaustif et automatisé, change complètement la donne : il transforme une confiance aveugle en un chiffre vérifiable, quitte à ce que ce chiffre soit inconfortable au début.

Pour une PME qui envisage de confier une migration technique (réécriture de module, portage d'API, modernisation de legacy) à un agent IA, la conclusion pratique est simple : le gain ne vient pas du modèle utilisé, mais de la qualité et de l'indépendance du harnais de test qui encadre l'agent. Sans cette discipline, 17 % de tests qui passent peut se travestir en ça marche dans une démonstration, alors que l'essentiel du comportement réel reste non couvert. Avec cette discipline, même un résultat partiel devient un chiffre exploitable, sur lequel on peut piloter un projet dans la durée.

Sources primaires

• Ekin Ertac, « I Don't Know Rust. My AI Is Rewriting PHP in It Anyway. », ekinertac.com.
• Documentation officielle, PHP Manual.
• Documentation officielle, Rust Language.