TypeScript est mon langage principal. Au fil des années, il a cessé d’être un simple choix technique pour devenir un ensemble de principes. Pas des règles de guide de style, mais des habitudes qui déterminent si une base de code reste agréable à modifier après deux ans et l’arrivée de trois nouveaux développeurs.
L’honnêteté avant le confort. Le mode strict est activé dès le premier commit. any est un signal de bug, pas un type ; si la forme m’est réellement inconnue, j’utilise unknown puis je la précise. Un type mensonger — un cast as pour faire taire le compilateur — est pire que l’absence de type, car tout le code en aval lui fera confiance. Quand le compilateur se plaint, il a généralement raison : il faut corriger les données, pas l’annotation.
Rendre les états impossibles impossibles. Au lieu de trois indicateurs isLoading, isError et data susceptibles de se contredire, j’utilise une union discriminée : idle, loading, success avec les données, error avec une cause. Même principe pour le domaine : une commande payée possède un paymentId, une commande impayée non. Un switch avec vérification exhaustive via never transforme un cas oublié, potentiellement incident de production, en soulignement rouge dans l’éditeur.
Faire confiance à l’intérieur, vérifier aux frontières. Les types disparaissent à l’exécution : tout ce qui franchit une frontière — corps HTTP, webhook, formulaire, localStorage ou réponse d’un LLM — est analysé avec Zod ou un schéma similaire, dont on déduit le type. Une source de vérité unique évite tout écart entre ce que nous validons et ce que nous croyons. Dans l’application, les données typées circulent sans vérification défensive à chaque ligne.
Partager des contrats, pas des suppositions. Dans un produit full-stack, les types d’API sont générés ou partagés via OpenAPI, GraphQL Codegen, Prisma ou un paquet commun. Ainsi, renommer un champ fait échouer le build, pas le paiement. La lisibilité prime sur l’ingéniosité : une interface simple comprise en dix secondes par une nouvelle recrue vaut mieux qu’un type conditionnel à cinq niveaux censé prouver que j’ai lu le manuel. Les generics servent à la réutilisation, pas à frimer.
Les types ne remplacent ni les tests, ni les revues, ni la réflexion ; ils réduisent le coût des trois. Voilà la vraie valeur d’un développeur TypeScript : non pas connaître chaque utility type, mais laisser un code que la personne suivante pourra modifier en confiance. Si votre base déborde de any et que l’équipe craint le refactoring, envoyez-moi le module que personne ne veut toucher. Je vous dirai comment je le typerais et ce que cela permettrait de détecter.
Donnez à votre prochain produit quelqu’un qui reste.
Prêt à commencer ? Écrivez-moi — je peux démarrer immédiatement et rester dans la durée. Des collaborations à long terme, pas une passation après deux semaines. Discutons de votre projet, de vos exigences et de la meilleure façon d’avancer.