Aujourd’hui, les développeurs écrivent davantage de nouveau code en TypeScript qu’en JavaScript. C’est ce que montre notamment la dernière étude State of JS, dans laquelle 67% des répondants déclarent écrire plus de TypeScript que de JavaScript. Cette dynamique se retrouve également dans le panorama de JetBrains, qui classe TypeScript parmi les trois langages phares de son Language Promise Index, aux côtés de Rust et Python.
Le code existant sur le web reste toutefois majoritairement écrit en JavaScript, et il n’existe aucun projet visant à le remplacer intégralement. JavaScript demeure le langage d’exécution du web, tandis que TypeScript s’impose comme un langage d’écriture.
Entre 2012 et 2026, TypeScript est ainsi passé d’un projet initié par Microsoft à un standard industriel, intégré nativement par les principaux IDE et adopté par l’ensemble des frameworks majeurs de l’écosystème JavaScript.
Un projet qui passe sur TypeScript ne fait pas de bruit.
Pas de billet de blog avec des infographies, pas de post LinkedIn aux centaines de commentaires.
Dans cet article, on revient sur les chiffres qui expliquent comment ce choix est devenu quasi systématique dans de nombreuses équipes.
Pourquoi tout le monde a migré vers TypeScript ?
En 2015, Google annonce rapidement l’abandon d’AtScript au profit de TypeScript, et la convergence des deux projets. Dans la foulée, l’équipe Angular annonce la réécriture complète du framework en TypeScript. TypeScript cesse d’être perçu comme un projet porté uniquement par Microsoft pour devenir un socle partagé par l’écosystème JavaScript.
TypeScript peut prévenir 15% des bugs qui arrivent en production.
En 2017, Microsoft Research, la division Recherche de Microsoft, a mené une étude sur le code open-source. Ils ont analysé la part de bugs qui ont été corrigés sur du JavaScript pour voir si un système de type comme Flow ou TypeScript les aurait prévenu.
C’est du code qui était le plus souvent en production, il avait donc passé les tests, la revue de code. La réponse est 15%.
15% des bugs correspondaient à des erreurs de typage ou des accès à `null` ou `undefined`. Ce sont souvent des cas limites ou des hypothèses sur le schéma de donnée contextuel au code écrit qui mènent à ces erreurs.
Et en 2025, les systèmes de types corrigent 94% des erreurs dans le code écrit par une IA.
L’étude « Type-Constrained Code Generation with Language Models » (Mündler, He, et al., 2025) s’est penchée sur les erreurs de compilation produit par des modèles comme CodeLLama 34B ou DeepSeek Coder qui sont ouverts. Seulement 6% des échecs de compilation étaient provoqués par une erreur de syntaxe. Par contre, 94% des erreurs proviennent d’échecs de vérification de type.
Le créateur de TypeScript, Anders Hejlsberg explique dans la Github Octoverse que les systèmes de types sont déterministes. Cela permet d’encadrer correctement des LLMs qui ne le sont pas.
Les frameworks poussent TypeScript par défaut.
Quand Angular a adopté Typescript, c’était un précurseur.
Mais aujourd’hui dans un projet Next.js ou NestJS, TypeScript n’est plus l’alternative, il est le choix par défaut. Et surtout, ça ne coûte rien de l’utiliser.
Le code JavaScript que vous avez déjà est du code TypeScript valide. Donc intégrer à votre chaîne de build logiciel la transpilation de TypeScript ne coûte rien et vous permet de bénéficier des types qui sont explicités dans le framework.
Comment adopter TypeScript dans vos projets ?
TypeScript n’est pas forcément une étape de build supplémentaire. Il est fort probable que votre projet ait déjà un transpilateur de JS. Sur Angular c’est déjà TypeScript qui est obligatoire, vous avez peut-être SWC sur Next.js ou esbuild avec Vite. Si votre projet est ancien, il a sûrement `babel`.
Le plus souvent, TypeScript tourne en parallèle pour vérifier les types uniquement, et SWC va transpiler vos fichiers `.ts/.tsx` en `.js`.
Côté backend, Deno et Bun sont nativement en Typescript.
Et encore une fois pas de “Big bang migration”. Tout votre code JavaScript est du code TypeScript valide.
Avant de commencer, il faut configurer la strictness
Vous allez devoir vous mettre d’accord sur la `tsconfig` la strictness.
Une configuration stricte va vous obliger à expliciter beaucoup de code tout de suite.
Par exemple, si j’ajoute un type sur un objet du modèle, une configuration stricte va m’obliger à typer tous les fichiers `.ts` qui l’utilisent. Et je vous conseille de ne pas activer le checkJs qui forcerait alors tous les fichiers .js à suivre le nouveau type.
Par contre, une configuration moins stricte est la garantie d’avoir à réécrire tout le code Typescript d’un coup dès que vous pousserez le curseur vers le haut. La bonne réponse est donc : le plus strict possible sans exploser le build à J+7.
Comment va se passer la migration vers TypeScript ?
Maintenant que le tsconfig est implémenté dans le build, il est aussi configuré dans l’IDE.
TypeScript est supporté nativement par VS Code et WebStorm, l’IDE va le lire comme une source de vérité.
Le code n’a pas changé, c’est le même qu’hier. Si un développeur frontend tombe pour la première fois sur fichier `tsx` ou `.ts` il ne sera pas désorienté. Le code est similaire à JavaScript, il y a des types en plus. Et on ressent une décharge cognitive à ne pas avoir à remonter tout le code pour trouver le type.
Par la suite, vous transformerez chaque fichier .js en .ts au fur et à mesure des nouvelles fonctionnalités. L’IDE va vous aider. En renommant simplement le fichier, d’un coup il y a des erreurs qui vont apparaître. Et VSCode propose une solution le plus souvent avec un CMD + `.`. Mais on sait que vous allez utiliser Github Copilot pour ça.
Et au fils des commit, vous verrez sur Github votre repository passer de Javascript à Typescript.
Pièges et bonnes pratiques lors de l’adoption de systèmes de type.
Le principal piège c’est de faire taire le compilateur.
Oui, TypeScript va obliger à vérifier tous les type option. Et on va avoir envie de faire un `!` pour faire taire le warning. Et on peut aussi utiliser `as any` ou `as Foo` à outrance.
À court terme, le code va partir en production plus vite. Mais les bugs en production vont commencer à tous être liés à ces bouts de code-là. Et assez rapidement on se met à les chasser.
Une autre erreur serait de croire que TypeScript remplace les tests. Et les tests eux-même ne remplacent pas du TDD. Donc continuez à le pratiquer et à écrire vos tests avant le code.
Les bons élèves peuvent également sur-typer leur code. On a vite fait de se retrouver avec un objet central avec un type super générique. On veut faire émerger les types par le code. Si votre code est un arbre, les premiers objets à typer sont les feuilles.
L’écueil aussi serait d’avoir un tsconfig en dev qui n’est pas le même qu’au build. C’est la meilleure recette pour frustrer pas mal de gens dans l’équipe.
TypeScript n’est pas qu’un effet de mode.
Vous l’aurez compris, TypeScript est vraiment efficace quand il s’agit d’industrialiser un projet. Et même si c’est un side-project que vous vibecodez le soir, TypeScript va vous aider dès le premier jour.
Et n’ayez pas peur du temps d’apprentissage. D’ici quelques jours vous serez familiez avec tous les mots clés et vous aurez un bon score sur le QCM WeLoveDevs concernant TypeScript.
