TypeScript pour les débutants : pourquoi l'adopter en 2026

TypeScript n’est plus un choix d’équipe en 2026, c’est la valeur par défaut : Next.js, Deno et Bun le supportent nativement, et la plupart des bibliothèques livrent leurs types. La question utile n’est donc plus s’il faut l’adopter, mais ce qu’il apporte réellement, ce qu’il ne fera jamais, et comment y aller sans tout réécrire.

À retenir. TypeScript est du JavaScript avec des types vérifiés avant l’exécution. Une étude publiée à la conférence ICSE mesure qu’il détecte 15 % des bugs publics d’un projet JavaScript, et les auteurs précisent que ce chiffre sous-estime son effet réel. Il ne verra en revanche jamais une erreur de logique métier. La migration se fait fichier par fichier, sans arrêter le projet.

TypeScript, c’est quoi exactement ?

TypeScript est un sur-ensemble de JavaScript créé par Microsoft. Tout code JavaScript valide est du TypeScript valide, ce qui rend la migration progressive possible. Vous déclarez le type de vos variables, paramètres et retours, et le compilateur vérifie que le code respecte ces contrats avant qu’il ne tourne.

Un point qui surprend souvent : les types disparaîsent à la compilation. Le navigateur ne reçoit que du JavaScript, sans une ligne de plus. TypeScript est un outil d’écriture, pas un composant de votre site.

Le bug type, en dix lignes

Voici l’erreur la plus banale du web, celle qui passe la revue de code et casse la page en production.

function prixTTC(produit) {
  return produit.prixHT * 1.2;
}

// Ailleurs, six mois plus tard, quelqu'un renomme le champ
prixTTC({ prix_ht: 100 });
// -> NaN, affiche "NaN €" sur la fiche produit

type Produit = { prixHT: number };

function prixTTC(produit: Produit): number {
  return produit.prixHT * 1.2;
}

prixTTC({ prix_ht: 100 });
// Erreur signalée dans l'éditeur, avant même d'enregistrer

En JavaScript, cette faute ne se manifeste qu’au moment où un visiteur ouvre la fiche produit. En TypeScript, elle est signalée pendant que vous écrivez. C’est tout le bénéfice, et il se mesure.

Ce que ça rapporte, chiffré

Le chiffre le plus solide sur le sujet vient d’une étude de Zheng Gao, Christian Bird et Earl Barr, présentée à la conférence ICSE en 2017. Les auteurs ont repris des bugs réellement corrigés dans des projets JavaScript publics, ont annoté le code fautif, puis ont regardé si TypeScript et Flow les signalaient. Résultat : 15 % des bugs publics sont détectables par le seul typage (Gao, Bird et Barr, ICSE 2017, relevé le 1er septembre 2026).

La nuance est dans le mot « publics », et les auteurs la soulignent eux-mêmes : ces bugs avaient déjà survécu aux tests et à la relecture avant d’arriver en production. Le chiffre est donc conservateur, et sous-estime ce que le typage attrape pendant l’écriture, quand la majorité des erreurs se produisent et se corrigent sans jamais laisser de trace.

Les cinq bénéfices au quotidien

1. Les erreurs remontent avant l’exécution

Une faute de frappe sur un nom de propriété passe inaperçue en JavaScript jusqu’au plantage. TypeScript la signale dans l’éditeur, avant même de lancer l’application. Sur un site marchand, c’est la différence entre corriger en trente secondes et découvrir le problème par un client.

2. L’autocomplétion devient fiable

L’éditeur connaît la forme exacte de vos données. Il propose les bonnes méthodes, les bons paramètres, et refuse les mauvais. Le gain de temps est moins spectaculaire que la détection de bugs, mais il se cumule sur toutes les heures de la journée.

3. Le remaniement cesse d’être un pari

Renommer une fonction ou changer la forme d’un objet ? Le compilateur énumère tous les endroits impactés. C’est le bénéfice le plus sous-estimé : il rend possible des changements qu’on n’oserait pas faire autrement, et c’est ce qui empêche un projet de se figer.

4. Les types tiennent lieu de documentation

En lisant une fonction, on sait ce qu’elle attend et ce qu’elle rend. Contrairement à un commentaire, cette documentation ne peut pas devenir fausse sans que le compilateur proteste.

5. Le contrat entre développeurs devient explicite

En équipe, ou simplement entre vous et le prestataire qui reprendra le projet dans deux ans, les types disent ce qui était attendu. C’est du temps de reprise économisé, donc de l’argent.

Ce que TypeScript ne fera jamais

C’est la partie que les articles enthousiastes oublient, et c’est celle qui évite les mauvaises surprises.

La cinquième ligne est le piège classique. Écrire qu’une API renvoie un nombre ne l’oblige pas à en renvoyer un : le type est une promesse que vous faites au compilateur, pas une vérification de ce qui arrive vraiment sur le réseau. Aux frontières du programme, il faut valider à l’exécution.

Les types de base en cinq minutes

Sept types couvrent l’essentiel du quotidien :

• `string` : chaînes de caractères
• `number` : entiers et décimaux, sans distinction
• `boolean` : vrai ou faux
• `string[]` : un tableau de chaînes
• `interface` ou `type` : la forme d’un objet
• `any` : désactive le typage. Chaque `any` est un trou dans le filet, et ils se multiplient si personne ne les compte.
• `unknown` : la bonne réponse quand on ignore le type. Il force à vérifier avant d’utiliser, là où `any` laisse tout passer.

Migrer sans arrêter le projet

Une migration TypeScript ne se fait pas en une fois, et il ne faut surtout pas essayer. Quatre étapes, dans cet ordre :

1. Renommez les fichiers, `.js` vers `.ts`, `.jsx` vers `.tsx`. Le projet compile encore, avec des avertissements.
2. Laissez le mode strict désactivé au départ. L’activer trop tôt produit des centaines d’erreurs et fait abandonner la migration.
3. Typez uniquement le code neuf. L’existant qui fonctionne peut attendre.
4. Éliminez les `any` au fil des passages, en commençant par ceux qui touchent l’argent ou les données clients.

L’écosystème en 2026

React expose ses types nativement, Next.js part en TypeScript par défaut, Deno et Bun l’exécutent sans étape de compilation séparée, et Node.js l’accepte désormais directement pour la plupart des cas. C’est devenu la voie normale plutôt que l’option à activer. Le comparatif des meta-frameworks détaille ce que chacun apporte par ailleurs.

Ce que ça change si vous payez le développement

Vous ne verrez jamais TypeScript sur votre site : il disparaît à la compilation. Ce que vous verrez, c’est le coût de la reprise. Un projet typé se relit plus vite par un prestataire qui ne l’a pas écrit, parce que la forme des données est écrite dans le code au lieu d’être devinée. Sur un audit de reprise, l’écart se compte en jours.

La contrepartie honnête : une base typée demande un peu plus de temps à écrire au départ. Sur un site vitrine de quelques pages, l’écart est négligeable. Sur une application appelée à vivre plusieurs années, il est remboursé au premier remaniement.

Questions fréquentes

TypeScript ralentit-il le site livré ?

Non, pas d’un octet. Les types sont retirés à la compilation et le navigateur ne reçoit que du JavaScript. Le seul coût est côté développement, sur la durée de compilation.

Faut-il tout typer dès le premier jour ?

Non, et c’est la principale cause d’abandon. Le mode strict activé dès le départ sur un projet existant produit un mur d’erreurs décourageant. Mieux vaut avancer fichier par fichier, en commençant par ce qui touche les paiements et les données clients.

Mon site vitrine a-t-il besoin de TypeScript ?

Besoin, non. Un site de cinq pages sans logique métier fonctionne très bien sans. L’intérêt apparaît dès qu’il y a des formulaires, des paiements, des comptes, ou simplement l’intention de faire vivre le projet plusieurs années.

En résumé

TypeScript attrape une classe d’erreurs précise, celle des données qui n’ont pas la forme attendue, et la recherche chiffre ce gain à au moins 15 % des bugs qui atteignent la production. Il ne remplace ni les tests, ni la relecture, ni la validation des données venues de l’extérieur. Adopté progressivement, il coûte quelques jours et se rembourse au premier remaniement sérieux.