TypeScript 7.0 disponible : le compilateur réécrit en Go promet des builds 10 fois plus rapides
Le 8 juillet 2026, Microsoft a rendu disponible en version stable TypeScript 7.0, l'une des évolutions les plus profondes de l'histoire du langage. Il ne s'agit pas d'ajouter quelques types utilitaires ou une syntaxe supplémentaire, mais de remplacer intégralement le cœur de l'outil : le compilateur, jusque-là écrit en TypeScript lui-même, a été réécrit en Go. Résultat annoncé et désormais mesuré sur de vrais projets, une vérification de types « environ dix fois plus rapide ». Pour les équipes qui vivent au quotidien avec des temps de compilation et une latence d'éditeur devenus douloureux sur les grosses bases de code, c'est la nouveauté la plus concrète de l'année.
Un chantier baptisé « Corsa », piloté par Anders Hejlsberg
L'histoire de ce projet remonte au printemps 2025, lorsque Microsoft a dévoilé son intention de porter TypeScript vers un langage compilé natif, sous le nom de code « Corsa ». À la tête de l'effort, on retrouve Anders Hejlsberg, l'architecte historique de TypeScript, également concepteur de C# et de Turbo Pascal avant lui. Le choix du langage Go n'a rien d'anodin : sa gestion mémoire, sa concurrence native et sa proximité structurelle avec le code existant permettaient un portage méthodique plutôt qu'une réécriture risquée. L'équipe a d'ailleurs insisté sur ce point : la logique de vérification de types reste structurellement identique à celle de la version 6, ce qui limite considérablement le risque de régressions de comportement.
Après une première préversion publique, une bêta officielle le 21 avril 2026 puis une release candidate mi-juin, la version 7.0 stable est donc arrivée début juillet. Entre-temps, le compilateur a été éprouvé sur des bases de code de plusieurs millions de lignes chez Microsoft, mais aussi chez Bloomberg, Canva, Figma, Google, Slack ou Vercel, qui rapportaient dès la bêta avoir « rogné la majeure partie de leurs temps de build ». Le code source de ce nouveau compilateur est ouvert et disponible dans le dépôt microsoft/typescript-go sur GitHub.
Des chiffres qui parlent d'eux-mêmes
Le gain le plus spectaculaire concerne la vérification de types complète. Sur la base de code de Visual Studio Code — une référence connue de tous les développeurs —, le temps de type-check passe de 125,7 secondes avec TypeScript 6 à 10,6 secondes avec TypeScript 7, soit une accélération de près de douze fois. Sur le projet Sentry, on tombe de 139,8 à 15,7 secondes. Ces mesures ne sont pas des cas isolés triés sur le volet : elles reflètent une tendance observée sur la plupart des grands dépôts, avec un facteur d'accélération qui gravite autour de dix selon la nature du projet.
La consommation mémoire diminue elle aussi, dans une fourchette de 6 à 26 % selon les projets. C'est moins spectaculaire qu'un facteur dix, mais loin d'être anecdotique sur une chaîne d'intégration continue où plusieurs vérifications tournent en parallèle. Le nouveau compilateur exploite d'ailleurs le parallélisme de façon native : un drapeau --checkers (quatre workers par défaut) répartit la vérification de types sur plusieurs cœurs, tandis qu'un drapeau --builders accélère la construction des monorepos composés de nombreux sous-projets. Un mode --singleThreaded reste disponible pour le débogage.
L'éditeur aussi devient plus réactif
Réduire les temps de build est utile, mais ce n'est pas là que se joue l'essentiel du confort quotidien. Le véritable point de bascule, c'est le serveur de langage — la brique qui alimente l'autocomplétion, le survol des types, le « aller à la définition » et le signalement d'erreurs directement dans l'éditeur. En portant cette brique en Go, TypeScript 7 réduit drastiquement le temps de chargement initial d'un projet et la latence des interactions. Concrètement, sur une base volumineuse, ouvrir un fichier et obtenir des suggestions pertinentes cesse de s'accompagner de plusieurs secondes d'attente, ce qui change la nature même du travail. Pendant la phase de préversion, ces capacités étaient distribuées via le paquet @typescript/native-preview et une extension dédiée pour VS Code ; avec la version stable, le binaire tsc standard est désormais le compilateur natif, sans commande tsgo séparée.
Une montée de version qui impose quelques ruptures
Passer à TypeScript 7 n'est pas totalement indolore, et c'est assumé. L'équipe a profité de cette version majeure pour faire le ménage dans des réglages hérités. Le mode strict devient activé par défaut, l'auto-découverte des types (types: []) n'est plus implicite, et la racine des sources (rootDir) doit désormais être configurée explicitement. Côté cibles de compilation, le support d'ES5 disparaît, tout comme les anciens formats de modules AMD, UMD et SystemJS, ainsi que la résolution de modules « classique ». Autrement dit, les projets modernes déjà en strict et ciblant des modules ES actuels migreront quasiment sans effort, tandis que les bases anciennes devront prévoir un chantier de mise à niveau ciblé. C'est un arbitrage raisonnable : la performance d'un compilateur natif se paie par l'abandon d'un long héritage de compatibilité que peu d'équipes exploitent encore.
Pourquoi c'est une vraie bonne nouvelle pour les équipes
Il est tentant de réduire cette annonce à une prouesse d'ingénierie réservée aux mainteneurs de très grosses bases de code. Ce serait passer à côté de l'essentiel. Les temps de compilation et la latence de l'éditeur sont une taxe invisible prélevée sur chaque développeur, à chaque instant de la journée. Quand une vérification de types complète tombe de deux minutes à dix secondes, ce n'est pas seulement un tableau de benchmarks qui s'améliore : c'est la boucle de rétroaction du développeur qui se resserre, l'intégration continue qui coûte moins cher en temps machine, et une friction quotidienne qui disparaît. Pour une agence comme la nôtre, qui construit ses applications en TypeScript sur des projets menés sous Next.js ou Astro, ce type de gain se traduit directement en cycles de livraison plus courts et en confort de travail retrouvé.
Ce virage confirme aussi une tendance de fond de l'outillage web : après le moteur Oxide de Tailwind écrit en Rust, après les runtimes JavaScript qui misent sur des langages systèmes, c'est au tour du compilateur TypeScript de quitter le monde interprété pour gagner en vitesse brute. Le choix du langage Go plutôt que de Rust a d'ailleurs suscité des débats nourris dans la communauté, l'équipe justifiant sa décision par la proximité du modèle mémoire avec le code d'origine et la fluidité du portage. Quel que soit le camp, le message est clair : en 2026, la performance de l'outillage n'est plus un détail mais un critère de conception de premier plan.
Pour les équipes déjà à jour et en configuration moderne, la recommandation est simple : tester TypeScript 7 sur une branche dédiée dès que possible, car le retour sur investissement est immédiat et le risque de régression, faible. Pour les projets plus anciens, l'occasion est belle de planifier une modernisation qui, au-delà de la vitesse, améliorera la rigueur du typage. Dans les deux cas, la trajectoire est désormais tracée : le compilateur historique en JavaScript vit ses derniers mois de service, et l'écosystème entier va progressivement basculer vers cette fondation native. La documentation officielle et les guides de migration sont disponibles sur le site de TypeScript.
