Passer de JavaScript à TypeScript : ce que ça change dans ton code de tous les jours

Le bug qui n'existe qu'à l'exécution

JavaScript est un langage à typage dynamique. Une variable peut contenir n'importe quoi, et changer de nature en cours de route : une chaîne devient un nombre, un objet devient undefined, sans que l'interpréteur bronche. Cette souplesse fait le charme du langage pour bricoler vite, et elle repousse une catégorie entière d'erreurs jusqu'au dernier moment.

Prends une fonction toute simple qui calcule un montant :

// JavaScript
function total(quantite, prixUnitaire) {
  return quantite * prixUnitaire;
}
 
total(3, 10);      // 30
total("3", 10);    // 30 aussi, par coercition silencieuse
total(3);          // NaN, personne ne t'a prevenu

Rien ici ne plante à l'écriture. Le NaN se propage, un affichage devient bizarre, un total part faux dans une base de données, et la cause se trouve à dix fichiers de l'endroit où le symptôme apparaît. Les tests attrapent une partie de ces cas, mais uniquement les chemins auxquels tu as pensé le jour où tu as écrit les tests. Une suite de tests bien construite aide énormément sur ce terrain, un sujet développé dans l'article sur les tests fiables et comment écrire des tests utiles, et elle ne remplace pas une vérification systématique de la forme des données.

Ce que TypeScript ajoute, et ce qu'il n'ajoute pas

TypeScript, c'est JavaScript plus une couche de types vérifiée avant l'exécution. Le mot important est superset : tout code JavaScript valide est déjà du TypeScript valide. Tu ne repars pas de zéro, tu ajoutes des annotations sur ce qui existe. Un vérificateur de types lit ton code, compare ce que tu déclares avec ce que tu fais, et souligne les contradictions directement dans l'éditeur.

Une confusion courante mérite d'être levée tout de suite : ces types disparaissent à la compilation. Le navigateur et le serveur n'exécutent jamais de TypeScript, ils exécutent du JavaScript ordinaire d'où les annotations ont été retirées. Historiquement, un outil appelé tsc transforme les fichiers .ts en .js. Aujourd'hui, Node.js sait exécuter un fichier TypeScript directement en supprimant les types au vol, sans étape de build visible.

Le point à retenir, pour le quotidien : tu n'annotes pas tout. TypeScript devine énormément de choses par inférence. Si tu écris const prix = 10, il sait déjà que prix est un nombre. Tu annotes surtout aux frontières : les paramètres de fonction, les valeurs de retour quand elles ne sont pas évidentes, la forme des données qui entrent dans ton système.

Le point de départ tient en peu de choses au quotidien. Tu ajoutes un fichier tsconfig.json à la racine, tu renommes tes fichiers en .ts, et l'éditeur se met à souligner les incohérences pendant la frappe. VS Code gère TypeScript sans extension à installer, l'analyse tourne en arrière-plan et remonte les erreurs dans l'onglet des problèmes au fil de l'écriture. Ta première journée en TypeScript ressemble donc beaucoup à ta journée JavaScript habituelle, avec un correcteur en plus qui attire ton attention avant que le code ne parte en production. C'est cette proximité avec ce que tu fais déjà qui rend la bascule progressive plutôt que brutale.

Il y a un effet secondaire que personne ne mentionne dans les tutoriels et qui devient vite le bénéfice numéro un : ton éditeur passe de spectateur passif à assistant qui connaît ton code. L'autocomplétion propose les bons champs, le renommage d'une variable met à jour tous ses usages sans risque, et sauter à la définition d'une fonction devient fiable parce que l'outil sait exactement quelle forme circule.

Ce qui change, ligne par ligne

Les paramètres de fonction ont une forme

Reprends la fonction du début. En TypeScript, tu annonces ce que chaque paramètre accepte et ce que la fonction renvoie :

function total(quantite: number, prixUnitaire: number): number {
  return quantite * prixUnitaire;
}
 
total("3", 10);
// Erreur soulignee en rouge dans l'editeur :
// Argument of type 'string' is not assignable to
// parameter of type 'number'.
 
total(3);
// Erreur : Expected 2 arguments, but got 1.

Les deux appels fautifs sont barrés avant l'exécution. Tu vois le trait rouge sous "3" au moment où tu tapes, pas trois semaines plus tard dans un log de production.

Les objets ont un contrat

La plus grosse source de bugs silencieux en JavaScript, ce sont les objets dont on suppose la forme. Une interface pose ce contrat noir sur blanc :

interface Utilisateur {
  id: number;
  nom: string;
  email: string;
}
 
function afficher(u: Utilisateur) {
  return u.non.toUpperCase();
  // Erreur : Property 'non' does not exist on
  // type 'Utilisateur'. Did you mean 'nom'?
}

La faute de frappe u.non au lieu de u.nom est repérée immédiatement, avec une suggestion de correction. En JavaScript pur, cette ligne aurait renvoyé undefined, puis planté une ligne plus loin sur le .toUpperCase().

null et undefined arrêtent de surprendre

Avec l'option strictNullChecks activée, TypeScript refuse que tu utilises une valeur potentiellement absente sans l'avoir vérifiée. Un champ optionnel se marque avec un point d'interrogation :

interface Utilisateur {
  id: number;
  nom: string;
  email?: string;   // le ? = peut etre absent
}
 
function contacter(u: Utilisateur) {
  return u.email.toLowerCase();
  // Erreur : 'u.email' is possibly 'undefined'.
}
 
// La version qui compile :
function contacter(u: Utilisateur) {
  if (!u.email) return null;
  return u.email.toLowerCase();
}

Cette contrainte agace au début, puis elle devient l'une des raisons pour lesquelles on ne veut plus revenir en arrière. Le fameux Cannot read properties of undefined, celui de l'accroche, devient une erreur que le compilateur t'oblige à traiter avant qu'elle n'atteigne un utilisateur.

Les valeurs possibles sont listées

Un type union restreint une variable à un ensemble fini de valeurs. Fini le statut mal orthographié qui traîne dans une condition :

type Statut = "brouillon" | "publie" | "archive";
 
function badge(statut: Statut) {
  // ...
}
 
badge("publie");    // ok
badge("publier");   // Erreur : Argument of type
// '"publier"' is not assignable to parameter of
// type 'Statut'.

L'éditeur te propose même les trois valeurs autorisées en autocomplétion dès que tu ouvres la parenthèse. Ce genre de détail change le rythme de travail : tu passes moins de temps à vérifier dans un autre fichier quelles valeurs une fonction attend, l'information est là, sous le curseur. Ces mécanismes (interfaces, unions, generics) forment le cœur de la formation TypeScript pour les développeurs JavaScript, qui part précisément de ce qu'on connaît déjà en JS pour y greffer le typage progressivement.

Le code se met à se documenter tout seul

Un bénéfice absent des tutoriels et qui pèse lourd sur la durée : les types remplacent une partie de la documentation que personne ne tient à jour. Quand tu ouvres un fichier écrit par quelqu'un d'autre, la signature d'une fonction annonce déjà ce qu'elle attend et ce qu'elle rend, sans avoir à la lire en entier ni à reconstituer son comportement à partir d'un nom de variable un peu vague.

Le refactoring change encore plus. Modifie la signature d'une fonction utilisée à quarante endroits, et le compilateur te dresse la liste exacte des appels à corriger, un trait rouge sur chacun. En JavaScript, la même opération repose sur une recherche texte et sur ta mémoire, et un oubli ne se révèle qu'au prochain passage dans ce chemin de code, parfois des mois plus tard. Renommer une propriété d'objet, extraire une fonction, déplacer un module deviennent des opérations mécaniques que l'éditeur pilote au lieu de te laisser avancer à l'aveugle.

Sur une équipe, l'effet se cumule. Une revue de code passe moins de temps à traquer des détails de forme, déjà attrapés par le compilateur, et se concentre sur ce qui mérite un regard humain : la logique et les choix de conception. Une personne qui arrive sur le projet lit les types pour comprendre les entités métier avant même de lancer l'application. Tout cela suppose une base JavaScript solide, celle que travaille la formation JavaScript avancé : async, POO et patterns modernes, et le typage vient s'appuyer dessus plutôt que la contourner.

Les pièges quand on débute

Le passage se fait rarement sans quelques réflexes contre-productifs. En voici les plus fréquents, avec ce qu'il faut faire à la place.

Mettre any partout. Quand une erreur de type résiste, la tentation est de taper : any pour faire taire le compilateur. Ce mot-clé désactive toute vérification sur la valeur concernée, tu réécris du JavaScript déguisé et tu perds l'essentiel du bénéfice. Mon avis tranché sur le sujet : traite chaque any comme une dette à rembourser, et quand tu ignores réellement la forme d'une valeur, utilise unknown, qui t'oblige à vérifier son type avant de l'utiliser.

Forcer la main avec as. L'assertion valeur as Utilisateur dit au compilateur « fais-moi confiance, c'est un Utilisateur ». S'il ne l'est pas, tu as juste caché le bug sous le tapis et il ressortira à l'exécution. Réserve as aux cas rares où tu en sais réellement plus que l'outil.

Laisser le mode permissif. Active strict dès la première ligne de ton tsconfig.json. Sans ce réglage, strictNullChecks et noImplicitAny restent éteints, et tu paies le coût de TypeScript sans en toucher les dividendes. Depuis la version 6.0, ce mode strict est d'ailleurs activé par défaut sur les nouveaux projets.

Croire que les types protègent au runtime. Une méprise qui coûte cher : les types de TypeScript n'existent plus à l'exécution, ils ne valident donc rien de ce qui vient de l'extérieur. Une réponse d'API, un formulaire, un JSON.parse() peuvent parfaitement renvoyer une forme qui ne correspond pas à ce que tu as annoté. Il faut valider ces données à la frontière avec du vrai code, une bibliothèque comme Zod par exemple. Ce point rejoint plusieurs des failles de sécurité qu'on retrouve dans presque tous les projets juniors, où une donnée externe non vérifiée devient un vecteur d'attaque.

Fabriquer des types trop alambiqués. TypeScript permet une gymnastique de types impressionnante, avec des types conditionnels imbriqués sur cinq niveaux. Sur un vrai projet, un type que ton collègue ne comprend pas en dix secondes est un problème. Reste sur des interfaces lisibles tant que le besoin ne justifie pas plus.

Questions fréquentes