Un bug en production coûte toujours plus cher qu'un bug attrapé pendant le développement. C'est une évidence, et pourtant beaucoup de sites web sont construits avec des outils qui laissent passer des erreurs évitables. Chez HWS, agence de développement web et mobile à Toulouse, nous avons fait un choix simple pour limiter ce risque : TypeScript. Deuxième volet de notre série « La stack HWS », cet article explique ce qu'est TypeScript, comment nous l'utilisons, et pourquoi ce choix protège directement votre investissement.
À quoi sert TypeScript ?
TypeScript est un langage de programmation créé par Microsoft. C'est une extension de JavaScript, le langage qui fait fonctionner tous les sites web. La différence tient en un mot : le typage.
Une image pour comprendre. En JavaScript classique, le code est comme un formulaire papier où chacun écrit ce qu'il veut dans chaque case : un nom dans la case téléphone, une date dans la case prix. L'erreur ne se voit qu'au moment où quelqu'un utilise le formulaire — c'est-à-dire quand votre client est déjà sur le site. TypeScript, lui, vérifie chaque case au moment où le développeur écrit le code. Si une fonction attend un prix et reçoit un texte, l'erreur est signalée immédiatement, avant même que le site soit mis en ligne.
Concrètement, TypeScript élimine toute une famille de bugs : les données mal branchées, les champs oubliés, les valeurs absentes. Ce sont précisément les erreurs les plus fréquentes sur un site web classique. Et comme la vérification est automatique, elle ne dépend ni de la vigilance ni de la fatigue du développeur : le code qui ne passe pas les contrôles ne part tout simplement pas en ligne.
Comment nous l'utilisons chez HWS
Sur tous nos projets sur-mesure
TypeScript fait partie, avec Next.js et PostgreSQL, de notre stack par défaut pour le développement de sites web sur-mesure. Ce n'est pas une option que nous facturons en plus : c'est notre façon normale d'écrire du code. Chaque projet qui sort de l'agence est typé de bout en bout, du formulaire de contact à la base de données.
Comme documentation vivante du code
Le typage a un second bénéfice, moins connu : il documente le code. Quand un développeur ouvre un fichier six mois après l'avoir écrit — ou quand un nouveau développeur rejoint le projet — les types lui disent exactement quelles données circulent et sous quelle forme. Pour vous, cela veut dire qu'un projet HWS n'est pas dépendant de la mémoire d'une seule personne. C'est un point que nous vérifions aussi quand nous reprenons le code d'une autre agence dans le cadre d'une maintenance de site web : un code non typé est presque toujours plus long, donc plus coûteux, à faire évoluer.
Comme filet de sécurité pour les évolutions
Un site web n'est jamais terminé : vous ajoutez une offre, un champ, une règle métier. Avec TypeScript, chaque modification est vérifiée contre tout le reste du code. Si un changement casse quelque chose ailleurs, le développeur le sait en quelques secondes, pas trois semaines plus tard via un e-mail de client mécontent. C'est ce qui nous permet de livrer vite, y compris dans notre méthode MVP en 15 jours, sans sacrifier la fiabilité.
Pourquoi ce choix (et ses limites)
Nous avons adopté TypeScript parce que le calcul est vite fait : quelques pour cent de temps d'écriture en plus, contre des heures de débogage en moins et des bugs qui n'atteignent jamais vos utilisateurs. C'est aussi devenu le standard de l'industrie : la grande majorité des projets web professionnels récents l'utilisent, ce qui garantit que votre code restera lisible et reprenable par d'autres développeurs pendant des années.
Les limites existent. TypeScript ne détecte pas tout : il vérifie la cohérence des données, pas la logique métier. Un calcul de TVA faux mais bien typé passera sans alerte — c'est le rôle des tests et de la relecture. Il ajoute aussi une petite couche de complexité : sur un script de dix lignes, il n'apporte rien. Enfin, mal utilisé (avec des types désactivés partout), il donne une fausse impression de sécurité. Le typage est une discipline, pas une baguette magique.
Un exemple concret : Nemo
Prenez Nemo, une plateforme web que nous avons développée pour les kinésithérapeutes. Techniquement, c'est une application React côté interface, avec Ruby on Rails et PostgreSQL côté serveur. Le front React y est typé : chaque donnée qui circule entre l'interface et le serveur — patients, exercices, programmes — a une forme définie et vérifiée.
Sur une plateforme de santé, ce n'est pas du confort de développeur. Une donnée mal branchée dans un formulaire de suivi patient, ce n'est pas un bug cosmétique. Le typage fait partie des garde-fous qui permettent à ce type de plateforme d'évoluer régulièrement sans régression sur l'existant.
Et pour votre projet ?
Vous n'avez pas besoin de savoir écrire du TypeScript. Mais quand vous choisissez un prestataire, vous avez le droit de demander comment il garantit la fiabilité de son code. Notre réponse tient dans cette stack typée, testée et documentée : elle coûte un peu de rigueur au quotidien, et elle économise des incidents en production. Si votre site actuel accumule les bugs à chaque évolution, ou si chaque petite modification prend des semaines par peur de tout casser, c'est peut-être le symptôme d'un code sans filet : parlons-en. Et pour la suite de la série, découvrez comment Sentry nous alerte des erreurs avant vos utilisateurs.
