Pas de TypeScript à lemlist.
Et j’ai passé plus de 10 ans à coder en C++, je n’ai pas peur des types.
Mais notre priorité chez lemlist, c’est simple :
livrer de la valeur rapidement à nos utilisateurs.
Et TypeScript ne nous aide pas à le faire.
Est-ce que TS permet de détecter des erreurs à la compilation ?
Oui.
Mais dans notre expérience, ça couvre quoi ? 1 à 2 % des bugs.
Le reste, ce sont :
– des bugs métier,
– des problèmes d’intégration,
– des effets de bord non couverts par le typage.
Et pendant ce temps-là…
On passe des heures à écrire, maintenir et refactorer des types.
TypeScript est un bon outil, dans le bon contexte :
– pour des juniors à encadrer,
– pour des projets énormes,
– pour de la banque ou de la santé, où le bug coûte très cher.
Mais dans une équipe de devs confirmés, alignés, qui bossent avec des conventions claires et des revues de code solides…
JS pur est plus rapide, plus souple, plus efficace.
Je préfère un code utile à un code “beau”.
Je vois un avantage à TS dans l’onboarding de nouveaux profils, même confirmés, qui gagnent du temps dans la compréhension du code etc…
Comment vous gérer ça ?
résumé des arguments en faveur de TS
Une équipe senior ne devrait pas trouver TS complexe
Vrai : on peut l’utiliser. Mais le temps passé à typer dépasse la valeur gagnée, donc on shippe moins vite.
Indispensable pour les gros refactors
On découpe petit et on teste ; les refactors massifs sont rares, TS apporte peu.
Les IDE sont plus performants
Code clair + conventions + tests couvrants suffisent pour renames et extractions.
L’IA comprend mieux avec des types
Cursor lit déjà très bien le JS nu, la clarté prime sur le typage.
TS garantit la robustesse
Nos tests fonctionnels sur les parcours critiques attrapent les vrais bugs plus vite.
Si TS te fait réellement livrer plus vite, garde-le, dans notre contexte, JS pur offre le meilleur ROI.