Le log de la CI affichait 77.8s pour la vérification de types, et plus personne dans l'équipe ne levait même les yeux. Ce chiffre, c'est celui des 1.5 million de lignes de VS Code avec l'ancien compilateur JavaScript. Avec TypeScript 7.0, le portage natif que Microsoft a lancé en mars 2025 sous le nom de Project Corsa, le même travail se termine en 7.5s. J'ai lu une douzaine d'avis à chaud sur les raisons du choix de Go plutôt que Rust. Voici ma position, un brin à contre-courant : le débat sur le langage est ce qu'il y a de moins intéressant dans cette version, et ce que les développeurs PHP devraient étudier, ce sont les petites lignes sur ce qui n'a pas été livré.

Rendons d'abord à César ce qui lui revient, parce que c'est mérité. Le raisonnement derrière Go était d'une sobriété rafraîchissante. L'équipe voulait un portage qui se comporte exactement comme l'ancien compilateur, bizarreries comprises, alors elle a traduit le code existant fichier par fichier au lieu de le repenser. Un compilateur, c'est un enchevêtrement de nœuds qui pointent vers leurs parents, leurs enfants et leurs déclarations, et un langage à ramasse-miettes avec de simples pointeurs permet à ce graphe de survivre intact au déménagement. Ajoute le parallélisme à mémoire partagée pour le parsing et la vérification, ce qu'un unique thread Node n'a jamais offert, et tu obtiens la fourchette annoncée de 8x à 12x sur les gros projets. TypeORM a vu un gain de 13.5x. date-fns, avec ses 104K lignes, a obtenu 9.5x. Ce sont de vraies heures rendues à de vraies personnes.

Passons maintenant aux petites lignes. TypeScript 7.0 n'a pas d'API programmatique stable : elle est prévue pour la 7.1. D'ici là, tout ce qui dialogue directement avec le compilateur reste sur TypeScript 6, et la liste comprend typescript-eslint ainsi que l'outillage de templates pour Vue, Svelte, Astro, MDX et Angular. Les dépréciations sont aussi devenues des erreurs bloquantes, et le mode strict est activé par défaut. Une bonne partie de l'écosystème regarde donc le gain de vitesse depuis l'autre côté de la vitre.

C'est là que je commence à penser à notre propre maison. L'analyse statique PHP est écrite en PHP, et sa valeur n'a jamais tenu au seul moteur. Elle tient à la couche d'extensions : les plugins qui connaissent les frameworks et apprennent à un analyseur ce que renvoie une façade, ce qu'hydrate une méthode de repository, quelle propriété magique existe vraiment. La moitié des boîtes PHP que je connais ne feraient pas d'analyse statique du tout sans ces plugins, parce que sur une base de code bâtie sur un framework, les résultats bruts sont surtout du bruit. Chaque fois que quelqu'un lance l'idée d'une réécriture native de nos analyseurs, et il y a toujours quelqu'un, c'est la slide de benchmark qui récolte les applaudissements, alors que c'est l'API de plugins qui décide si quelqu'un peut réellement migrer.

L'objection la plus solide mérite d'être écoutée honnêtement. La vitesse change les comportements. Quand une analyse complète prend quatre-vingt-dix secondes, on la lance en CI et nulle part ailleurs ; quand elle en prend neuf, on la lance à chaque sauvegarde, et les bugs qu'elle attrape passent de la pull request à l'éditeur, ce qui vaut plus que n'importe quel plugin. On pourrait soutenir que Microsoft a fait le bon choix en livrant d'abord le cœur rapide et en laissant les intégrations rattraper leur retard, puisque tout attendre aurait repoussé le gain pour la majorité qui se contente de lancer tsc. Je pense que c'est juste pour TypeScript, avec les effectifs de Microsoft et une 7.1 déjà au calendrier. Je suis beaucoup moins sûr que ça se transpose à un écosystème comme le nôtre, où les analyseurs sont maintenus par une poignée de personnes et les plugins par une foule éparpillée de bénévoles qui ne peuvent pas encaisser une API cassée au rythme imposé par quelqu'un d'autre.

Alors si je conseillais un auteur d'outil PHP tenté par la voie native, j'inverserais l'ordre choisi par TypeScript. Je lui dirais de définir et de figer d'abord le contrat d'extension, dans l'implémentation actuelle, et seulement ensuite de remplacer le moteur en dessous. L'approche du portage fidèle adoptée par l'équipe TypeScript va d'ailleurs dans ce sens : si le nouveau code reproduit l'ancienne structure ligne à ligne, la frontière que touchent les plugins peut la reproduire elle aussi. Et garde en tête tout ce que PHP lui-même nous a déjà offert gratuitement. Une bonne partie des gains qui exigeaient autrefois de quitter le langage viennent maintenant d'un moteur plus rapide et de l'exécution du travail dans des processus parallèles, ce que nos analyseurs font déjà.

Rien de tout ça ne m'empêche d'être impressionné par les chiffres. Voir une vérification d'une minute se réduire au temps qu'il faut pour changer d'onglet, c'est grisant, et j'avoue avoir chronométré un projet TypeScript au boulot par pure curiosité. Mais un outil n'est jamais plus rapide que le maillon le plus lent de ton vrai workflow, et si ton étape de lint est bloquée en version 6, l'horloge de ta CI n'a pas beaucoup bougé.

Alors voilà ce que j'aimerais savoir, surtout si tu maintiens des plugins d'analyseur ou si tu en dépends beaucoup : si une réécriture native de ton analyseur statique PHP te promettait une vitesse multipliée par dix mais laissait tes extensions de framework cassées pendant six mois, tu migrerais dès le premier jour, ou tu attendrais l'API ?