Profile picture of Mika F
Mika F
CTO at lemlist / lempire - building the best place for devs
Follow me
Generated by linktime
June 10, 2025
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”.
Stay updated
Subscribe to receive my future LinkedIn posts in your mailbox.

By clicking "Subscribe", you agree to receive emails from linktime.co.
You can unsubscribe at any time.

214 Likes
June 10, 2025
Discussion about this post
Profile picture of Zakaria E.
Zakaria E.
Développeur IA | Développeur Full Stack | ISV Succès | Spécialiste DevOps
2 months ago
Mika F En un besoin a haut niveau est considéré afin de contrôler le type .Mais parfois ,les erreurs lint sont liées uniquement au TS , le JS est compilé .On peut liee des facteurs ,A savoir les fichiers (.ts.config ,.eslint.rc,…) ,La chaine des versions du bibliotheques (stable ,preview or early access ). Cepandant ,Typescript garde le controle du type au niveau du compilation d’une facon hiérarchique .Ce qui la caractérise d’autres langues de programmation.
Profile picture of Amin N.
Amin N.
Directeur Pédagogique Ingénierie du Web
2 months ago
Là où il faut être pragmatique c'est si ton client achète du temps ou s'il achète une intelligence métier. Dans le premier tu vas avoir besoin de «ship fast, fail fast» sinon tu te fais éjecter par un autre concurrent qui n'aura pas en barrière d'entrée sur le marché la problématique métier, qui aura plus de moyen financier, humain et matériel. Le coût de résolution de bug idiot comme oublier de renommer une variable après une refactorisation est plus faible que celui d'attendre qu'un autre concurrent sorte la même fonctionnalité plus vite. Dans ce cas là pas question d'utiliser TypeScript. Dans l'autre c'est le métier qui est clairement identifié et que tu maîtrise via un ou plusieurs homme (avec un grand H) clé qui sécurisent la compétence et que les clients viennent acheter, une expertise dans le domaine qui est difficilement reproductible par la concurrence et qui créé la barrière à l'entrée du marché. Dans ce cas là hors de question d'utiliser un langage qui peut amener un humain à faire des erreurs, TypeScript (ou un autre langage typé comme Java) est à privilégier. Le rôle du CTO sera d'utiliser les meilleurs outils au bon moment, il n'y en a pas un qui fait tout mieux.
Profile picture of El Bouyousfi AFTISS
El Bouyousfi AFTISS
développeur .Net cloud Azure
2 months ago
« Dans une équipe de dev confirmés » , j’ai l’impression qu’il n’y a plus de dev junior nulle part. Je trouve ça bizarre et inquiétant au niveau macro.
Tout le monde vibe code avec l’IA. Et dans 6 à 12 mois, tout le monde paiera pour réparer les dégâts. Aujourd’hui, c’est cool de trouver un pb à régler, builder vite, faire du cash. Aucun pb avec ça. Tu copies une feature d’un concurrent, tu balances trois prompts dans ton outil AI préféré, tu obtiens du code “qui marche”. T’as même pas besoin de comprendre ce que ça fait : ça rend bien, ça compile, go en prod. Et profite. Mais tu sais quoi ? Dans 6 mois, tu vas payer un freelance senior pour tout recoder. Pourquoi ? Parce que ce code-là, personne ne veut le maintenir. Parce qu’il n’a aucune structure. Parce qu’il n’est pas pensé pour durer. Parce que ton “MVP” est devenu ton produit… et qu’il commence à te ralentir. Pendant ce temps-là, on nous vend du rêve avec des chiffres magiques : « 40 % du code chez Google est généré par l’IA. » Très bien. Mais ce sont les mêmes boîtes qui ont intérêt à entretenir le fantasme de la révolution no-code-for-everything. La réalité ? Les meilleurs devs n’utilisent pas l’IA tant que ça. Un senior écrit du code à peine 20% de son temps. Le reste, c’est de l’architecture, des choix produits, de la simplification, de la communication, des compromis techniques. Alors même si tu gagnes 40 % de vitesse sur l’écriture brute, l’impact global reste marginal. Mais bon, c’est moins sexy à raconter que “l’IA va remplacer les devs”. Le vibe coding fera bientôt partie des dettes techniques les plus chères des startups. Et ce ne sera pas l’IA qui les sauvera. Ce seront les développeurs que tout le monde a sous-estimés… parce qu’ils prenaient leur temps pour bien faire.
103 comments
July 15, 2025