TypeScript 7 est sorti : faut-il migrer maintenant ou attendre 7.1 ?

TypeScript 7 n’est plus une promesse lointaine ni un prototype réservé aux curieux. Depuis le 8 juillet 2026, le nouveau compilateur natif est publié comme version stable et remplace progressivement l’implémentation historique en JavaScript. Les premiers résultats communiqués sont suffisamment importants pour rendre la migration tentante : compilation beaucoup plus rapide, consommation mémoire réduite et diagnostics disponibles plus tôt dans l’éditeur.

Pourtant, mettre à jour le package typescript ne revient pas encore à migrer sereinement tout un projet. La version 7.0 sait compiler et vérifier les types, mais elle ne fournit pas la nouvelle API programmatique dont dépendent de nombreux outils de lint, plugins de framework, générateurs de code ou environnements éditoriaux. La vraie question n’est donc pas de savoir si TypeScript 7 est stable, mais si votre chaîne de développement peut déjà fonctionner sans l’ancien moteur TypeScript.

Où en est réellement TypeScript 7 aujourd’hui ?

Microsoft a publié TypeScript 7.0 en version stable le 8 juillet 2026. Le package principal typescript distribue désormais le nouveau compilateur natif, développé en Go, ainsi qu’un serveur de langage reposant sur le protocole LSP. Cette réécriture ne cherche pas seulement à optimiser quelques fonctions : elle remplace l’architecture historique afin de mieux exploiter les processeurs modernes et le parallélisme.

La version 7.1 est déjà entrée en développement et ses versions quotidiennes sont proposées sous le canal typescript@next. Elle doit notamment apporter une nouvelle API programmatique, mais aucune date stable précise n’est annoncée au moment de cette publication. Microsoft évoque un rythme général de versions fonctionnelles tous les trois à quatre mois, ce qui constitue une cadence de travail et non une garantie de livraison pour chaque fonctionnalité.

Cette distinction est essentielle. TypeScript 7.0 est suffisamment stable pour compiler du code en production, mais il ne remplace pas encore TypeScript 6 dans tous les rôles qu’occupait le package historique. Un même projet peut utiliser le compilateur pour son typecheck, l’API TypeScript dans ESLint, un plugin pour analyser les composants et un script maison pour manipuler l’AST : chacune de ces couches possède son propre calendrier de migration.

TypeScript 6 reste ainsi une version de transition utile. Son rôle est de signaler les options obsolètes, d’introduire certains nouveaux comportements et de préparer les configurations avant le passage au moteur natif. Une équipe qui découvre encore des avertissements de dépréciation dans son tsconfig.json ne devrait pas les ignorer sous prétexte que TypeScript 7 promet de meilleures performances : elle doit d’abord remettre sa configuration à niveau.

Ce que la nouvelle architecture change dans un projet réel

Le principal changement visible est la vitesse, mais l’intérêt ne se limite pas à gagner quelques secondes lors d’une commande locale. Une vérification plus rapide modifie la fréquence à laquelle les développeurs acceptent de lancer le compilateur, le délai de retour dans l’éditeur et la manière dont la CI répartit ses ressources. Sur un gros projet, cela peut réduire une friction quotidienne qui avait fini par être considérée comme normale.

Il faut néanmoins séparer les mesures publiées par Microsoft des résultats observés sur son propre produit. Les chiffres officiels constituent un signal solide, notamment parce qu’ils portent sur plusieurs dépôts open source réels, mais ils ne remplacent pas un test effectué avec votre monorepo, vos références de projets et vos contraintes d’infrastructure.

Temps de compilation et vérification des types

Dans les benchmarks communiqués pour TypeScript 7, Microsoft mesure environ 11,9 fois d’accélération sur le dépôt de Visual Studio Code, 8,9 fois sur Sentry et 8,7 fois sur Playwright. Les autres exemples publiés restent généralement dans une plage de 8 à 12 fois pour une vérification complète. Ce sont des écarts suffisamment larges pour dépasser le simple confort local lorsqu’un projet consacre plusieurs minutes au contrôle des types.

Le nouveau compilateur peut paralléliser l’analyse grâce à plusieurs workers. TypeScript 7 introduit également des réglages comme --checkers et --builders, qui permettent d’ajuster la répartition du travail. Cette possibilité doit être utilisée avec discernement : multiplier les workers accélère certaines tâches, mais augmente aussi le nombre de processus actifs et la mémoire mobilisée.

Les petits projets verront parfois une différence moins spectaculaire en valeur absolue. Passer de deux secondes à quelques centaines de millisecondes est agréable, mais ne justifie pas forcément une migration anticipée si le reste de la chaîne devient instable. À l’inverse, un monorepo qui attend plusieurs minutes avant d’afficher ses erreurs dispose d’un bénéfice potentiel beaucoup plus concret.

Consommation mémoire et expérience développeur

Microsoft publie également des réductions de mémoire comprises entre environ 6 et 26 % sur les dépôts présentés. Ce résultat est intéressant pour les machines de développement modestes, les environnements distants et les CI conteneurisées, mais il ne faut pas l’interpréter comme une baisse uniforme. La quantité de mémoire dépend fortement du graphe de dépendances, des références entre projets et du nombre de workers utilisés.

L’amélioration la plus perceptible peut venir du serveur de langage. Sur le dépôt Visual Studio Code utilisé comme exemple, le premier diagnostic apparaît en moins de 1,3 seconde avec TypeScript 7, contre environ 17,5 secondes auparavant. Un retour plus rapide réduit le temps pendant lequel l’éditeur semble ignorer une erreur après l’ouverture d’un projet ou un changement important de branche.

Cette évolution passe aussi par LSP, un protocole déjà utilisé par de nombreux éditeurs. Elle peut à terme rendre l’expérience plus homogène hors de Visual Studio Code, mais la présence du protocole ne garantit pas que toutes les extensions exploitent immédiatement le nouveau serveur. L’éditeur, son extension TypeScript et les éventuels plugins propres au framework doivent être inclus dans les essais.

Impact potentiel sur la CI

Une vérification TypeScript plus rapide peut raccourcir directement une étape de CI. Microsoft cite notamment Slack, qui aurait réduit une vérification de types d’environ 7 minutes 30 à 1 minute 15 lors de ses tests. Là encore, ce chiffre provient d’un retour communiqué par l’entreprise et relayé par Microsoft, pas d’un benchmark indépendant applicable à tous les projets.

Le gain sur la durée totale du pipeline dépend de ce qui entoure TypeScript. Lorsque les tests d’intégration, la construction des images, le bundling ou le déploiement occupent l’essentiel du temps, accélérer le typecheck ne suffit pas à diviser la facture globale. L’amélioration reste utile, mais elle doit être mesurée au niveau de chaque étape plutôt que résumée par un multiplicateur marketing.

Le parallélisme mérite une attention particulière sur les runners limités. Le produit du nombre de builders et de checkers peut créer davantage de concurrence que prévu avec les tests lancés en parallèle. TypeScript 7 propose un mode --singleThreaded pour les environnements contraints ou lorsqu’un orchestrateur externe répartit déjà les tâches. Le meilleur réglage n’est donc pas nécessairement celui qui mobilise tous les cœurs disponibles.

Les compatibilités qui doivent être vérifiées avant une migration

Un code qui passe sous TypeScript 6 sans avertissement important devrait généralement conserver les mêmes diagnostics avec TypeScript 7. Microsoft a précisément cherché à maintenir la compatibilité du système de types et de la ligne de commande. Les blocages les plus sérieux apparaissent aujourd’hui autour des outils qui ne se contentent pas d’exécuter tsc.

La première étape consiste à inventorier les dépendances qui importent directement typescript, utilisent un service de langage, parcourent un AST ou remplacent la vérification standard. Cette dépendance peut être visible dans le code du projet, mais aussi cachée dans un plugin, un loader, une extension ou une commande de framework.

Frameworks et outils de build

Un bundler qui utilise esbuild, SWC ou Babel pour retirer les annotations TypeScript peut continuer à produire du JavaScript sans demander au compilateur de vérifier les types. Cela ne signifie pas pour autant que la commande globale du framework accepte TypeScript 7. Le framework peut effectuer sa propre détection de version, charger une API interne ou lancer un contrôle distinct pendant le build.

Next.js illustre bien cette nuance. Au 12 juillet 2026, des versions stables récentes peuvent encore refuser TypeScript 7 parce qu’elles recherchent l’ancienne API JavaScript. Un backend expérimental utilisant directement la CLI a été intégré dans la branche canary de Next.js 16.3, mais cette expérimentation ne constitue pas encore une recommandation générale pour une production dépendante de la version stable.

Les environnements qui mélangent TypeScript avec un langage intégré demandent encore plus de prudence. Vue, Svelte, Astro, Angular ou MDX s’appuient souvent sur des outils capables de reconstruire virtuellement du code TypeScript à partir de leurs propres fichiers. Microsoft indique que ces intégrations ne pourront généralement pas exploiter pleinement TypeScript 7 avant la disponibilité et l’adoption de la nouvelle API.

ESLint et analyse statique

typescript-eslint ne se limite pas à lire le résultat de la commande tsc. Pour appliquer les règles nécessitant les informations de types, il charge TypeScript comme une bibliothèque et construit des programmes d’analyse. TypeScript 7.0 ne fournissant pas encore cette API, une simple mise à jour du compilateur peut provoquer un avertissement de version non prise en charge, une erreur d’installation ou un échec pendant le lint.

Le projet typescript-eslint prend officiellement en charge TypeScript 6 depuis sa version 8.58, mais le suivi de l’adaptation à TypeScript 7 reste distinct. Une équipe qui dépend fortement des règles typées ne doit donc pas désactiver son lint pour obtenir plus rapidement les performances du nouveau compilateur. Elle peut conserver TypeScript 6 pour l’analyse statique et utiliser TypeScript 7 uniquement pour une commande expérimentale de vérification.

Cette coexistence est explicitement envisagée par Microsoft. Le package TypeScript 6 peut être installé sous son nom de compatibilité @typescript/typescript6, tandis qu’un alias distinct expose TypeScript 7. Le dispositif demande un peu plus de discipline dans les scripts, mais il évite de transformer une migration de performance en régression de qualité.

Outils utilisant l’API TypeScript

Les dépendances les plus évidentes sont les outils fondés sur le compilateur : scripts utilisant ts.createProgram, transformations d’AST, générateurs de déclarations, analyseurs de dépendances ou applications basées sur ts-morph. Des plugins de bundler, outils de documentation, frameworks de test ou générateurs de clients peuvent également appeler cette API sans que l’équipe applicative le sache.

TypeScript 7.1 doit fournir une nouvelle API, mais « nouvelle » ne signifie pas nécessairement « remplaçable sans modification ». Les mainteneurs devront adapter leurs outils, publier des versions compatibles et parfois prendre en charge deux générations du compilateur pendant une période transitoire. Attendre la sortie de TypeScript 7.1 ne suffira donc pas automatiquement : il faudra encore vérifier que les dépendances importantes l’ont adoptée.

Les projets JavaScript fortement annotés en JSDoc méritent aussi un test spécifique. Le document officiel consacré aux différences connues du port natif signale plusieurs écarts intentionnels autour d’anciennes syntaxes Closure, de certains comportements JSDoc et de la génération de déclarations depuis du JavaScript. Ces cas sont moins fréquents dans une application TypeScript récente, mais peuvent concerner une base historique ou une bibliothèque publique.

Dans quels projets migrer dès maintenant ?

Une migration immédiate devient raisonnable lorsque TypeScript est utilisé comme un compilateur autonome, lancé explicitement par la CLI, sans outil critique dépendant de son API JavaScript. Le projet doit déjà fonctionner proprement sous TypeScript 6, disposer d’un tsconfig.json explicite et posséder des tests capables de détecter une différence de comportement dans les sorties générées.

Les candidats les plus intéressants sont les gros dépôts où la vérification des types constitue une friction mesurable. Un backend Node.js, une bibliothèque TypeScript ou un monorepo utilisant des références de projets peut obtenir un bénéfice quotidien important si son outillage ne charge pas directement le compilateur. Le passage peut également être progressif : une commande TypeScript 7 est ajoutée à la CI avant de remplacer la vérification existante.

Le contexte de maintenance compte autant que la compatibilité technique. Une équipe disponible pour examiner les diagnostics, ajuster les ressources de CI et suivre les versions correctives peut adopter plus tôt qu’un produit maintenu ponctuellement. La démarche rejoint les principes d’une maintenance d’application web ou SaaS : une dépendance structurante ne se met pas à jour uniquement parce qu’une nouvelle version apparaît, mais parce que son bénéfice et son risque sont compris.

Dans quels projets attendre TypeScript 7.1 ?

Attendre reste le choix le plus prudent lorsque le projet dépend d’une intégration profonde entre TypeScript et son framework. C’est notamment le cas d’une application Next.js qui doit rester sur une version stable et utiliser le contrôle de types intégré au build, ou d’un projet où MDX, Vue, Svelte, Astro ou Angular repose sur un service de langage spécialisé.

La même recommandation s’applique lorsque typescript-eslint avec informations de types constitue une barrière qualité importante. Remplacer ce contrôle par un lint partiel pendant plusieurs semaines ferait perdre davantage que les secondes gagnées à la compilation. Les scripts personnalisés utilisant l’API TypeScript, les transformations AST et les chaînes de génération de code sont également de bonnes raisons de patienter.

Un produit critique, réglementé ou simplement difficile à tester peut choisir de ne pas être parmi les premiers adoptants. TypeScript 7.0 est stable, mais son nouvel environnement natif vient d’entrer dans sa première période d’utilisation générale. Attendre quelques versions correctives, l’arrivée de l’API 7.1 et les retours des dépendances réduit le nombre de variables modifiées simultanément.

Cela ne signifie pas qu’il faut ignorer TypeScript 7 jusqu’à une date inconnue. La bonne préparation consiste à migrer d’abord vers TypeScript 6, traiter ses dépréciations, retirer les options qui deviennent des erreurs en version 7 et rendre la configuration explicite. La publication de TypeScript 6 présente précisément cette version comme le pont vers le nouveau compilateur.

Comment tester TypeScript 7 sans fragiliser la production

Le test doit commencer sur une branche dédiée avec une mesure de référence. Il faut enregistrer la durée et la mémoire de la vérification TypeScript 6, mais aussi les diagnostics produits, les fichiers de déclaration éventuels et le comportement de la CI. Sans ce point de comparaison, il est facile de retenir uniquement un temps de compilation flatteur tout en manquant une différence de sortie ou un outil devenu silencieux.

Microsoft propose de conserver TypeScript 6 sous le package @typescript/typescript6 et d’installer TypeScript 7 sous un alias séparé, par exemple @typescript/native. Les scripts doivent nommer clairement les deux vérifications et les versions doivent être verrouillées dans le fichier de dépendances. Cette organisation permet de lancer TypeScript 7 en parallèle sans modifier immédiatement la commande utilisée par la production.

La comparaison doit porter sur davantage qu’un build réussi. Il faut confronter les diagnostics TypeScript 6 et 7, tester les projets référencés, la génération des déclarations, le mode watch, l’ouverture du dépôt dans les éditeurs utilisés et les commandes de lint. Les builds de production, tests unitaires et tests d’intégration doivent ensuite tourner avec les mêmes artefacts qu’avant la migration.

Dans la CI, la commande TypeScript 7 peut d’abord être non bloquante. Après plusieurs exécutions stables, elle devient obligatoire tout en conservant temporairement le contrôle TypeScript 6, puis remplace celui-ci uniquement lorsque les résultats sont équivalents. Cette progression est plus fiable qu’une bascule unique et suit la même logique qu’une refonte d’application web existante : isoler les changements, comparer les comportements et prévoir un retour arrière simple.

Les performances doivent enfin être observées dans les conditions réelles. Un ordinateur local haut de gamme ne représente pas nécessairement un runner à deux cœurs limité en mémoire, et un premier lancement sans cache ne raconte pas la même histoire qu’une compilation incrémentale. La décision doit reposer sur plusieurs exécutions et sur la durée globale du pipeline, pas uniquement sur le meilleur résultat obtenu.

Ce que je recommande aujourd’hui

Au 12 juillet 2026, je ne conseillerais pas une migration générale et immédiate de tous les projets vers TypeScript 7. Je recommanderais en revanche de le tester dès maintenant sur les dépôts où la vérification des types prend du temps, à condition que la CLI soit clairement séparée du lint, du framework et des outils qui dépendent de l’API TypeScript.

Pour une bibliothèque, un backend ou un monorepo utilisant principalement tsc, l’adoption peut déjà être pertinente après un test de parité sérieux. Pour une application Next.js stable, un projet MDX, une chaîne reposant sur typescript-eslint typé ou des scripts utilisant l’AST, le meilleur choix est généralement de rester temporairement sur TypeScript 6 tout en préparant la configuration et en suivant TypeScript 7.1.

Le bon compromis tient en trois verbes : préparer maintenant, tester en parallèle, adopter sélectivement. Attendre sans examiner le sujet reporte simplement les dépréciations ; migrer partout dès la première semaine déplace le risque vers les outils les moins visibles. TypeScript 7 apporte une amélioration architecturale réelle, mais sa valeur apparaît lorsque la migration accélère le développement sans affaiblir les contrôles qui sécurisent le produit.

Pour un projet applicatif où la compilation, la dette technique et les dépendances commencent à ralentir les évolutions, la page Application web & SaaS présente l’approche Websual pour reprendre ou construire un socle technique durable. L’objectif n’est pas d’utiliser la version la plus récente à tout prix, mais de choisir une architecture que l’équipe peut réellement maintenir.