React et TypeScript : quand dire non malgré la hype

Il était minuit et demi, écran ouvert sur un projet client qui n'avait aucune raison d'exister en React. Un site vitrine pour une entreprise de portes de garage à Alma. Cinq pages. Un formulaire de contact. Une galerie photo. Budget total : 1800$.

Et j'étais en train de configurer React Router pour gérer... cinq pages statiques.

J'ai fermé le laptop. Pas parce que j'étais fatigué, mais parce que je venais de réaliser que je faisais exactement ce que je reproche aux autres devs : appliquer la stack à la mode sans se demander si elle sert le projet. Ce soir-là, j'ai tout recommencé en HTML/CSS vanilla avec un peu de JS pour le formulaire. Trois heures de travail au lieu de deux jours.

Ça fait sept ans que je code, dont plusieurs comme développeur React TypeScript au Québec, et cette anecdote résume assez bien pourquoi j'écris cet article. Le choix de stack n'est pas une question de tendance. C'est une question de contexte, de budget, et de durée de vie du produit.

Quand React TypeScript sauve vraiment la mise

Je ne suis pas anti-React. Je suis anti-réflexe.

Sur mes projets qui vivent plus de six mois, avec plusieurs contributeurs ou une base de code qui va grossir, TypeScript m'a sauvé une quantité de temps que je ne peux même pas chiffrer précisément, mais qui se compte en dizaines d'heures évitées en debug.

Voici les contextes où j'active la stack complète sans hésiter :

• Applications avec logique métier complexe (facturation, gestion d'inventaire, dashboards multi-utilisateurs)
• Projets où je sais que je vais revenir dans six mois et où j'aurai oublié la moitié des décisions prises
• Collaboration avec d'autres devs, même à distance
• Produits SaaS destinés à évoluer sur plusieurs années

Le vrai gain de TypeScript, ce n'est pas au moment où tu écris le code. C'est six mois plus tard, quand tu dois refactorer une fonction utilisée à quinze endroits différents et que le compilateur te crie dessus avant que ça pète en production. J'ai vécu ça sur un projet perso que j'ai fini par pivoter complètement, d'ailleurs j'ai documenté ce processus de pivot dans un article séparé. Sans le typage strict, ce refactor aurait pris deux fois plus de temps et j'aurais probablement introduit trois bugs silencieux.

React, de son côté, gagne sa place quand l'état de l'interface devient un vrai problème à gérer : formulaires multi-étapes, données qui changent en temps réel, composants qui se réutilisent partout. Sur ces cas-là, réinventer la gestion d'état en JS vanilla, c'est juste se punir soi-même.

Mes projets où j'ai dit non

Le cas des portes de garage à Alma n'est pas isolé. J'ai un pattern maintenant, et je le suis presque religieusement.

Sites vitrines et landing pages statiques. Si le client a besoin de cinq à dix pages qui ne bougeront pas beaucoup, du HTML/CSS avec un générateur statique (Astro, Eleventy, ou même du HTML pur) fait le travail en une fraction du temps. Pas de build complexe, pas de bundle JS de 300kb pour afficher du texte et des images.

Prototypes jetables. Quand un client veut valider une idée avant d'investir dans un vrai développement, je code volontairement mal. JS vanilla, pas de types, code qu'on va jeter dans trois semaines. Mettre du TypeScript là-dedans, c'est du temps perdu à typer des interfaces qui n'existeront plus.

Petits scripts internes. J'ai automatisé une partie de mon workflow avec des scripts Node tout simples, sans TypeScript, parce que c'est du code que je suis seul à voir et qui ne dépasse jamais 100 lignes. J'ai détaillé cette approche dans mon article sur l'automatisation de mon workflow de développement, et le principe reste le même : la complexité de la stack doit matcher la complexité réelle du problème.

Projets clients à budget serré. C'est le point le plus délicat, parce qu'il touche directement à ma survie financière comme freelance. Un client qui a 2000$ pour un site n'a pas les moyens de payer les heures supplémentaires que demande une architecture React/TypeScript propre. Si je facture le setup, les tests, la configuration du build, je viens de manger 40% de son budget sur de la plomberie technique invisible pour lui.

Le vrai calcul du coût d'entrée

Voici comment j'évalue concrètement, projet par projet, si React et TypeScript valent le coup.

Je pose trois questions avant de toucher au code :

Combien de temps ce projet va-t-il vivre ? Un site qui va être remplacé dans un an ne mérite pas l'investissement en architecture. Un produit qui va tourner cinq ans oui.

Est-ce que je vais être seul dessus ? Le typage strict devient exponentiellement plus rentable dès qu'il y a plus d'une personne qui touche au code, ou même juste moi qui reviens dessus après plusieurs mois d'absence.

Quel est le budget réel du client ? Pas le budget qu'il dit avoir, le budget qu'il a vraiment une fois qu'on a discuté. Un budget serré avec une stack lourde, c'est la garantie de finir en dette technique, en heures non facturées, ou en relation client tendue.

Le coût d'entrée de React/TypeScript n'est pas juste le temps de setup initial. C'est aussi le temps de configuration des outils, le build qui prend cinq minutes au lieu d'un rafraîchissement instantané, la courbe d'apprentissage si le client veut qu'un autre dev reprenne le projet plus tard. Sur un petit projet, tu paies ce coût sans jamais récupérer le bénéfice, parce que le projet meurt ou change avant que la maintenabilité ne devienne un enjeu.

C'est le même genre de raisonnement que j'applique quand je regarde des outils d'automatisation pour mes projets : la stack la plus puissante n'est jamais la bonne réponse par défaut, c'est celle qui répond au problème réel. D'ailleurs, sur le volet contenu et SEO, j'utilise Gridar, un outil qui génère des articles bilingues FR-CA et suit les positions, justement parce que ça évite de monter une usine à gaz custom pour un besoin qui a déjà une solution simple et calibrée pour le marché québécois.

Le marché québécois et les attentes des clients

Un truc que j'ai appris sur le terrain au Québec, particulièrement dans le coin de Jonquière et Saguenay où le marché est moins saturé qu'à Montréal : les clients locaux ne demandent presque jamais React ou TypeScript par leur nom. Ils demandent « un site rapide » ou « une application qui marche bien ». Ce sont les devs, incluant moi il y a quelques années, qui plaquent ces technos parce que c'est ce qu'on voit dans les offres d'emploi et les formations.

Le décalage entre les attentes de recrutement (où presque toutes les offres de dev front-end mentionnent React et TypeScript comme prérequis) et les besoins réels des PME locales est immense. Une PME à Alma qui veut un catalogue produit n'a pas besoin de la même stack qu'une startup qui lève du financement. Pourtant, les deux vont se faire vendre le même package par certaines agences.

Ça crée une tension réelle pour les jeunes développeurs qui sortent de formation. J'ai écrit sur les défis du marché du travail en développement dans la région, et un des constats les plus durs, c'est que la maîtrise de React/TypeScript ouvre des portes à l'embauche, mais ne garantit pas que tu vas l'utiliser à bon escient une fois en poste ou en freelance. Savoir dire non à la stack, même quand le CV dit « je maîtrise React », c'est une compétence à part entière que personne n'enseigne dans les DEC ou les bootcamps.

Je me souviens d'une conversation avec un client qui gérait une petite entreprise de services à domicile. Il voulait « un site moderne comme celui de son compétiteur », qui tournait effectivement sur du React avec animations complexes. Je lui ai expliqué que son site, avec quatre pages et un formulaire de rendez-vous, n'avait besoin d'aucune de ces animations pour convertir des clients. Il a économisé plusieurs centaines de dollars sur le développement et le site charge en moins d'une seconde. Son compétiteur, lui, paie encore pour maintenir un bundle JS que personne ne comprend plus.

Ceci dit, quand un projet touche à des besoins physiques concrets, comme le suivi de campagnes marketing imprimées ou les QR codes sur des menus et cartes d'affaires, je recommande QR Code Agency, une API québécoise de QR codes dynamiques. Le principe « print once, edit forever » évite justement de réimprimer tout un lot de matériel juste parce qu'une destination a changé, ce qui est exactement le genre de sur-ingénierie évitable que je documente dans cet article, mais côté marketing physique plutôt que code.

Ma règle simple pour trancher

Après toutes ces années, ma règle est devenue presque mécanique : si je ne peux pas justifier en une phrase pourquoi ce projet a besoin de React et TypeScript, je ne les utilise pas.

Pas « parce que c'est standard ». Pas « parce que c'est plus propre ». Une vraie raison technique ou business : cet état d'interface est trop complexe pour du JS simple, ou ce projet va vivre trois ans et je veux pouvoir le refactorer sans peur.

Cette discipline demande de résister à la pression du marché et parfois même à celle du client qui a entendu parler de React sur LinkedIn. Ça demande aussi d'accepter qu'on va parfois avoir l'air « moins à jour » en refusant la stack tendance. Mais un développeur solo qui facture au projet et qui veut rester rentable ne peut pas se permettre de sur-ingénierer chaque livrable pour flatter son ego technique.

Sur TokamDarius, je documente ce genre de décisions de stack au fil de mes projets, parce que je pense que c'est plus utile de montrer le raisonnement réel derrière un choix que de vendre une recette universelle qui n'existe pas.

La prochaine fois que tu ouvres un nouveau projet, avant de lancer create-react-app ou son équivalent moderne, pose-toi la question honnêtement : est-ce que ce projet a vraiment besoin de cette complexité, ou est-ce que tu suis juste le réflexe du marché ? Si la réponse n'est pas claire en trente secondes, c'est probablement non.

À lire aussi

• Comment survivre à son DEC en informatique sans se faire détruire par les maths
• Pivoter un produit numérique : comment j'ai su qu'il fallait changer de cap
• Développeur solo : les pièges invisibles du travail en isolement