TypeScript en mode strict : pourquoi et comment

Le mode strict, je l’ai longtemps laissé de côté sur mes premiers projets TypeScript. Le code compilait, tout semblait fonctionner, alors pourquoi s’embêter avec des options qui ne font que rajouter des erreurs à corriger ? J’ai changé d’avis le jour où un `undefined` non géré a fait planter une fonction critique en prod, alors que TypeScript n’avait rien signalé à la compilation.

Cette option n’active pas une seule règle, mais tout un paquet de vérifications d’un coup. Les deux qui changent vraiment le quotidien :

• **`strictNullChecks`** — TypeScript oblige à gérer explicitement les cas `null` et `undefined`. Fini les accès à une propriété d’un objet qui, en théorie, « ne devrait jamais être vide ».
• **`noImplicitAny`** — chaque paramètre ou variable sans type explicite devient une erreur plutôt qu’un `any` silencieux. Ça oblige à réfléchir au typage au moment où on écrit le code, pas six mois plus tard en essayant de comprendre une fonction qu’on a oubliée.

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "ESNext",
    "strict": true,
    "noUncheckedIndexedAccess": true
  }
}

J’ajoute volontiers `noUncheckedIndexedAccess` en plus du strict standard : sans elle, TypeScript part du principe qu’un accès à un tableau (`arr[i]`) renvoie toujours une valeur, même hors limites. Avec, il force à vérifier avant d’utiliser le résultat.

Activer `strict` d’un coup sur un vieux projet fait souvent remonter des centaines d’erreurs et décourage avant même de commencer. Ce qui fonctionne mieux dans la pratique :

1. Activer `strictNullChecks` seul en premier — c’est celle qui rapporte le plus et qui casse le moins de choses. 2. Avancer fichier par fichier plutôt que de vouloir tout corriger d’un coup, en commençant par les modules les plus utilisés : le typage correct s’y propage naturellement au reste du code. 3. Remplacer les `any` restants par des types réels au fil des retouches, pas en une seule passe dédiée qui n’arrive jamais vraiment.

Le vrai gain n’est pas dans le nombre de bugs évités à la compilation, il est dans la confiance qu’on a en retouchant du code qu’on n’a pas écrit soi-même. Un refactoring qui aurait demandé de tout relire à la main devient un refactoring où le compilateur pointe directement les endroits cassés.