React + TypeScript : mon stack par défaut, sans exception

3h12 du matin. Le projet en prod depuis deux semaines. Le client m'écrit sur Slack : « le bouton export ne fait rien depuis ce matin, c'est urgent, on a une démo à 9h. »

Je me lève, j'ouvre le laptop, je pull le code. Erreur silencieuse dans la console : Cannot read property 'map' of undefined. Quelqu'un (moi, deux semaines plus tôt, à 23h un vendredi) avait changé la forme de la réponse API sans toucher au composant qui la consommait. Le composant s'attendait à un tableau. L'API renvoyait maintenant un objet avec une clé items. Rien n'a crashé au build. Rien n'a crashé en dev. Juste un écran blanc en prod, devant le client, à 9h le lendemain matin si je réglais pas ça avant.

Ça, c'était avant que je bascule tout mon stack sur React TypeScript. Depuis, ce genre de bug, je ne l'ai plus. Pas « je l'ai moins ». Plus.

Le bug qui n'existe plus

Le typage statique front-end change une chose précise : il déplace l'erreur du 3h du matin en prod vers la ligne rouge dans ton éditeur, au moment où tu écris le code.

Dans l'exemple du dessus, si le composant avait été typé avec une interface Item[] en prop, et que je change l'API pour renvoyer { items: Item[] }, TypeScript me hurle dessus instantanément. Pas de build qui passe silencieusement. Pas de déploiement qui a l'air correct. Une ligne rouge, dans VS Code, avant même que je commit.

J'ai un autre exemple, plus bête encore. Un composant <UserCard user={user} /> où user pouvait être null pendant le chargement. En JS pur, ça compile, ça tourne, et ça crash seulement si l'utilisateur ouvre la page pendant que les données chargent encore. Un bug qui apparaît une fois sur dix, impossible à reproduire de façon fiable, le genre qui te fait douter de ta santé mentale pendant un après-midi. Avec TypeScript, le type User | null te force à gérer le cas avant même de pouvoir déployer. Le compilateur ne te laisse pas le choix.

C'est ça, la vraie valeur. Pas « TypeScript c'est plus propre » ou « c'est du bon code ». C'est que des classes entières de bugs deviennent impossibles à écrire, point.

Ma config de départ, copier-coller

J'avais écrit un article sur le fait de savoir dire non à la hype et de ne pas adopter chaque nouvel outil qui sort. React et TypeScript, dans ma tête, ce n'est plus une hype. C'est devenu la base, le point de départ non négociable. La nuance, c'est qu'ici j'assume complètement pourquoi ce duo gagne, systématiquement, sur chaque projet que je lance.

Voici le setup que je reproduis, littéralement, sur chaque nouveau projet depuis deux ans :

npm create vite@latest mon-projet -- --template react-ts
cd mon-projet
npm install

Trois lignes. Vite avec le template react-ts configure TypeScript automatiquement, avec tsconfig.json prêt à l'emploi. Pas besoin de bricoler Babel, pas besoin de comprendre les 40 options de configuration TypeScript avant de pouvoir écrire une ligne de code.

Après ça, j'ajoute toujours les mêmes trois dépendances :

• ESLint + @typescript-eslint : pour attraper les erreurs de style et les patterns dangereux avant même que TypeScript s'en mêle.
• Zod : pour valider les réponses API à la frontière du système, là où TypeScript ne peut rien faire parce que les données viennent de l'extérieur.
• React Query (TanStack Query) : parce que la gestion d'état serveur typée m'a évité plus de crashs que n'importe quel autre outil de mon stack.

Zod, en particulier, c'est le complément que je recommande à tout le monde. TypeScript te protège au moment de la compilation. Mais une API externe peut te renvoyer n'importe quoi à l'exécution, un champ manquant, un type différent, une valeur null là où tu attendais une string. Zod valide la donnée réelle qui arrive et la fait correspondre à ton type. Les deux ensemble, c'est la seule combinaison qui m'a jamais donné confiance en prod.

Ce setup, je le note dans mon carnet de bord technique à chaque fois que je l'ajuste, pour ne pas réinventer la roue au prochain projet.

Là où TypeScript freine vraiment

Je ne vais pas vendre TypeScript comme une solution magique sans coût. Il y a un coût, et il est réel.

Le setup initial prend plus de temps. Sur un prototype jetable, un truc que je code en trois heures un dimanche pour tester une idée, typer chaque prop et chaque réponse API ralentit clairement le rythme. J'ai déjà passé vingt minutes à typer correctement une réponse API imbriquée sur trois niveaux, pour un prototype que j'ai jeté à la poubelle deux jours plus tard parce que l'idée ne tenait pas.

Les types génériques peuvent devenir un cauchemar. J'ai un souvenir précis d'un composant de formulaire réutilisable où j'essayais de typer correctement un onChange générique qui devait fonctionner avec des string, des number et des objets custom. J'ai passé plus de temps à faire plaisir au compilateur qu'à faire fonctionner la logique métier. À un moment, j'ai lâché et mis un any temporaire, avec un commentaire // TODO: fix this properly. Ce commentaire est resté six mois dans le code.

Les librairies mal typées te font perdre un après-midi. Certains packages npm ont des types communautaires (@types/xxx) qui ne correspondent pas exactement à la vraie API du package. Résultat : tu débogues une erreur TypeScript qui n'a rien à voir avec ton code, mais avec une déclaration de type fausse écrite par quelqu'un d'autre.

Malgré ça, j'accepte ce coût sans hésiter, pour une raison simple : le coût du typage se paie une fois, au début. Le coût de l'absence de typage se paie à chaque modification, pour toujours.

Un projet JS pur devient de plus en plus fragile avec le temps. Chaque ajout de feature augmente le risque de casser quelque chose ailleurs, silencieusement. Un projet TypeScript devient au contraire plus solide avec le temps, parce que le compilateur t'avertit à chaque changement qui casse un contrat existant entre deux morceaux de code. J'ai vécu les deux scénarios sur des vrais projets, et la différence de stress à six mois d'écart n'est pas comparable.

Pourquoi je ne reviens plus en arrière

Il y a un projet précis qui a scellé ma décision. Un dashboard client avec une dizaine de composants qui se passaient des props les uns aux autres, sur trois niveaux de profondeur. Une modification simple, ajouter un champ status à un objet Order, a nécessité de toucher à quatre composants différents.

En JS pur, j'aurais fait la modification dans le composant du haut, oublié de mettre à jour un des trois autres, et découvert le bug seulement en testant manuellement, ou pire, seulement quand un utilisateur l'aurait signalé. Avec TypeScript, j'ai changé l'interface Order à un seul endroit, et le compilateur m'a listé immédiatement les quatre composants qui devaient être ajustés, avec la ligne exacte. Cinq minutes de travail, zéro test manuel requis, zéro doute.

C'est cette expérience, répétée une dizaine de fois sur différents projets, qui m'a fait passer de « TypeScript c'est correct » à « je ne lance plus rien sans ça, sauf exception vraiment marginale ». Pour un dev solo qui n'a personne pour relire son code avant un commit, le compilateur devient littéralement ton reviewer permanent. C'est le seul collègue qui ne dort jamais et qui ne se fatigue pas de te signaler tes erreurs.

D'ailleurs, ce niveau de confiance dans le code compte double quand tu travailles seul, sans équipe pour rattraper tes erreurs. J'en parle un peu dans mon article sur les pièges invisibles du travail en isolement : quand personne ne relit ton code, le typage statique devient ta seule ligne de défense réelle contre toi-même.

Si tu es développeur React TypeScript au Québec et que tu hésites encore à franchir le pas sur un projet qui vise la prod, mon conseil est direct : commence maintenant, sur le prochain projet, pas sur celui d'après. Chaque projet en JS pur que tu lances aujourd'hui, c'est une dette technique que tu vas payer avec intérêts dans six mois. Je le sais parce que je l'ai fait, et parce que la facture a fini par arriver, sous la forme d'un message Slack un matin à 3h.

Sur TokamDarius, je documente ce genre de décision de stack en continu, avec les vraies erreurs qui vont avec, pas la version marketing. Si tu construis en solo et que tu veux gagner du temps sur tes prochains setups, mon conseil reste le même : arrête de te demander si TypeScript en vaut le coup, et pose-toi plutôt la question de combien de temps tu vas perdre le jour où un bug silencieux passe en prod sans lui.

Action concrète pour demain matin : ouvre ton dernier projet React en JS pur, cherche un composant qui reçoit plus de trois props, et pose-toi la question honnête de ce qui se passe si une de ces props arrive undefined. Si tu ne sais pas répondre avec certitude, tu viens de trouver ton premier candidat pour une migration vers TypeScript.

À lire aussi

• Comment j'automatise mon workflow de développement web (et ce que je garde manuel)
• Mon carnet de bord technique : ce que j'y note chaque jour
• Optimiser les performances d'une API FastAPI : Guide des meilleures pratiques