Pendant des années, j’ai résisté à TypeScript. Pas par ignorance — je savais ce que c’était. Mais à chaque fois que j’essayais de m’y mettre, je butais sur la même chose : l’impression d’ajouter de la friction pour rien. Mon JavaScript fonctionnait. Mes projets tournaient. Et je n’avais pas envie de passer des heures à annoter des types sur du code qui marchait déjà.
Puis j’ai commencé Nomisora, une application de facturation pour thérapeutes, et j’ai décidé de démarrer en TypeScript strict dès le premier commit. Quelques semaines plus tard, même chose pour Oranexa, un CRM pour commerces de détail. Deux SaaS de zéro, en solo, avec TypeScript.
Aujourd’hui, si quelqu’un me propose de démarrer un projet en JavaScript pur, je décline poliment.
Ce n’est pas de l’enthousiasme de converti. C’est une observation concrète de ce que ça change dans le quotidien d’un développeur qui travaille seul sur des projets critiques.
L’argument qui m’avait convaincu (à tort) de rester en JavaScript
Mon raisonnement de l’époque tenait en une phrase : “TypeScript ralentit le développement”. Et dans un sens, ce n’est pas complètement faux. Au démarrage d’un projet, quand on pose les premières briques, annoter les types prend du temps.
Mais c’est une vision à très court terme. Ce que je n’avais pas mesuré, c’est le coût du JavaScript pur sur la durée — sur un projet qu’on maintient, qu’on fait évoluer, et sur lequel on revient après plusieurs semaines d’absence.
TypeScript ne ralentit pas le développement. Il déplace le coût vers le début, là où il est le moins cher à payer.
Ce qui change réellement
Les bugs détectés à l’écriture, pas en production
C’est le bénéfice le plus immédiat et le plus spectaculaire.
En JavaScript, passer une valeur du mauvais type à une fonction, c’est une erreur silencieuse. L’application s’exécute, quelque chose se passe de travers, et on passe deux heures à remonter la trace jusqu’à la source. En TypeScript, c’est une ligne rouge dans l’IDE. Immédiatement.
Un exemple concret qui m’est arrivé sur Nomisora : une fonction qui calculait le montant TTC d’une facture attendait un number en paramètre. À un endroit dans le code, je lui passais la valeur directement depuis un champ de formulaire — donc une string. En JavaScript, ça aurait produit une concaténation silencieuse plutôt qu’une addition. La facture aurait été fausse, et je ne l’aurais découvert qu’en testant le flux complet.
TypeScript a marqué l’erreur avant que j’appuie sur Cmd+S.
Sur deux projets SaaS en production, j’estime avoir évité une dizaine de bugs de ce type — chacun aurait coûté entre deux et quatre heures de debug. Ce calcul justifie TypeScript à lui seul.
La navigation dans le code devient intuitive
Sur un projet de 50 fichiers ou plus, la mémoire ne suffit plus. On oublie ce que contient tel objet, quelle signature a telle fonction, ce que retourne tel endpoint.
Avec TypeScript, l’IDE sait. Quand je tape invoice., j’ai immédiatement la liste de toutes les propriétés disponibles avec leurs types. Quand j’appelle une fonction, je vois ses paramètres et ce qu’elle retourne sans ouvrir son fichier. Cmd+clic sur n’importe quelle référence m’emmène directement à la définition.
Ce n’est pas un luxe. Sur Oranexa, qui gère des stocks, des ventes et de la génération de contenu IA dans le même projet, cette navigation est devenue indispensable. Sans elle, j’aurais passé une fraction non négligeable de mon temps à chercher où quelque chose est défini plutôt qu’à construire.
Le refactoring devient moins risqué
Renommer une propriété ou modifier la signature d’une fonction, c’est l’opération la plus dangereuse en JavaScript. On fait le changement, on espère que les tests couvrent tout (ils ne le font jamais à 100%), et on croise les doigts.
En TypeScript, renommer la propriété totalAmount en totalHT sur mon type Invoice fait apparaître instantanément toutes les lignes du projet qui utilisent l’ancienne propriété. Je peux les corriger une par une, avec la certitude que quand le compilateur est satisfait, je n’ai rien cassé structurellement.
Sur Nomisora, j’ai fait une refonte significative du modèle de données des factures après deux mois de développement. En JavaScript, j’aurais repoussé ça parce que trop risqué. En TypeScript, ça m’a pris une demi-journée, sans régression.
Les types comme documentation vivante
En JavaScript, la documentation d’une fonction ressemble souvent à ça : un commentaire JSDoc qu’on a écrit au départ, qui ne correspond plus tout à fait à la réalité six mois plus tard, et que personne ne pense à mettre à jour.
En TypeScript, la signature d’une fonction est sa documentation. Une fonction createInvoice(client: Client, lines: InvoiceLine[]): Promise<Invoice> dit exactement ce qu’elle attend et ce qu’elle retourne. Cette documentation ne peut pas devenir obsolète — si le code change, TypeScript force la signature à changer avec lui.
Sur mes deux projets, je n’écris quasiment plus de commentaires JSDoc. Les types font ce travail mieux, et automatiquement.
La maintenance sur le long terme
Voilà ce que je n’avais pas anticipé avant d’adopter TypeScript : ce qu’il change quand on revient sur un projet après trois mois d’absence.
En JavaScript, rouvrir un vieux projet ressemble à explorer une maison dans le noir. On sait qu’il y a des meubles, mais on ne sait plus où. On relit le code lentement, on reconstitue le contexte, on hésite avant de modifier quoi que ce soit.
En TypeScript, les types sont le plan de la maison. En quelques minutes, je comprends comment les données circulent, ce que chaque module consomme et produit, quelles sont les invariants du système. Je peux reprendre un chantier là où je l’avais laissé sans devoir tout relire.
C’est particulièrement critique pour un développeur solo qui jongle entre plusieurs projets. Je ne peux pas me permettre de passer une demi-journée à me réorienter à chaque fois que je passe de Nomisora à Oranexa.
Les vraies limites — parce que soyons honnêtes
TypeScript n’est pas parfait, et les ignorer serait malhonnête.
La courbe d’apprentissage initiale est réelle. Si vous venez de JavaScript pur, comptez deux à trois semaines pour être vraiment à l’aise avec le système de types. Ce n’est pas long, mais c’est un investissement réel que vous devez planifier.
Certains types complexes peuvent devenir eux-mêmes complexes à écrire. Les types génériques imbriqués, les types conditionnels, les manipulations de types avancées — tout ça peut rapidement devenir du code difficile à lire et à maintenir. Ma règle : si un type devient plus compliqué que le code qu’il décrit, quelque chose ne va pas dans la conception.
L’écosystème JavaScript reste plus large. Certains packages tiers n’ont pas de définitions de types, ou ont des types incomplets. C’est de moins en moins fréquent — la communauté TypeScript est très active — mais ça arrive encore. On peut s’en sortir avec les déclarations declare module, mais c’est un contournement, pas une solution.
Ce que je recommande concrètement
Activez le mode strict dès le départ. La configuration strict: true dans tsconfig.json active toute une série de vérifications supplémentaires qui font la différence entre un TypeScript “soft” qui vous laisse passer n’importe quoi avec quelques any et un TypeScript qui vous protège vraiment.
Laissez TypeScript inférer quand il peut. L’erreur classique des débutants est de tout annoter explicitement. Ce n’est pas nécessaire — TypeScript est très bon pour déduire les types. Annoter const count: number = 0 est redondant. Annotez aux frontières : les paramètres de fonctions, les retours de fonctions publiques, les données qui viennent de l’extérieur.
Utilisez Zod pour les données externes. TypeScript vérifie les types à la compilation — il ne peut pas vérifier ce qui arrive au runtime depuis une API, un formulaire ou une base de données. Zod est complémentaire : il valide les données à la frontière de votre application et génère des types TypeScript à partir des schémas. Sur Nomisora et Oranexa, toutes les entrées API passent par Zod avant d’être traitées.
FAQ
Est-ce que TypeScript ralentit le développement ?
À court terme, légèrement. Au démarrage d’un projet, annoter les types prend du temps. Mais sur un projet de plus de quelques semaines, TypeScript accélère le développement net : moins de bugs à chasser, navigation plus rapide, refactoring moins risqué. Le seuil de rentabilité se situe assez tôt — de l’ordre de quelques semaines sur un projet actif.
Faut-il migrer un projet JavaScript existant ?
Cela dépend de la taille et de l’état du projet. Pour un petit projet stable qu’on ne fait presque plus évoluer, la migration n’a peut-être pas de sens. Pour un projet actif, en développement ou qu’on prévoit de faire évoluer significativement, la réponse est oui — mais faites-le progressivement. TypeScript permet de migrer fichier par fichier avec le flag allowJs. On commence par les modules les plus critiques, pas par tout refactoriser d’un coup.
TypeScript est-il utile pour de petits projets ?
Oui, mais avec une nuance. Pour un script de 100 lignes ou une landing page simple, le rapport effort/bénéfice est faible. Pour une application web avec plusieurs pages, des appels API, de la logique métier — même “petite” — TypeScript apporte rapidement de la valeur. La taille n’est pas le seul critère : la complexité du domaine et la durée de vie prévue comptent autant.
C’est quoi la différence entre TypeScript et les types JSDoc ?
JSDoc permet d’annoter du JavaScript avec des commentaires de types que certains IDE comprennent. C’est une solution de compromis : on garde du JavaScript mais on ajoute des indications de types. TypeScript va beaucoup plus loin — c’est un langage à part entière avec un compilateur qui vérifie activement la cohérence de vos types et refuse de compiler si quelque chose ne va pas. Les types JSDoc sont une documentation assistée. TypeScript est une vérification automatisée.
Conclusion
Je ne suis pas en train de vous vendre TypeScript comme la solution à tous les problèmes du développement web. Ce n’est pas le cas. C’est un outil, avec ses forces et ses limites.
Mais après deux ans à construire des SaaS en production avec TypeScript strict, je peux vous dire une chose avec certitude : je ne retournerais pas en JavaScript pur sur un projet sérieux. Pas parce que TypeScript est “mieux” dans l’absolu, mais parce que ce qu’il m’apporte — bugs détectés tôt, navigation fluide, refactoring sans peur, documentation intégrée — a un impact direct sur la qualité de ce que je livre et sur la vitesse à laquelle je peux travailler.
Pour un développeur solo qui construit des produits critiques, c’est devenu indispensable.
Vous démarrez un projet web et vous vous demandez si TypeScript est adapté à votre cas ? Parlons-en