TypeScript pour débutants : 7 erreurs fatales et comment les éviter

Introduction : pourquoi TypeScript mord les débutants, ou comment ne pas faire échouer son premier projet

Avez-vous déjà eu l'impression que TypeScript est comme un professeur strict qui met des mauvaises notes pour chaque petit détail ? Si oui, bienvenue au club. Un débutant sur deux, en passant de JavaScript à TypeScript, commet les mêmes erreurs. Et c'est normal : TypeScript est vraiment plus difficile, il exige de la discipline et une compréhension des types.

Mais il y a une bonne nouvelle : la plupart des erreurs lors de l'apprentissage de TypeScript peuvent être prévues et évitées. Dans cet article, j'ai rassemblé les 7 pièges les plus fréquents dans lesquels tombent les développeurs débutants. Nous analyserons chaque erreur avec des exemples de code, expliquerons pourquoi c'est mauvais, et montrerons comment bien faire.

Si vous venez de commencer à apprendre TypeScript ou si vous avez déjà quelques bosses, cet article vous fera gagner des heures de débogage et de stress. C'est parti !

Erreur n°1 : Utilisation incontrôlée de any (source de tous les maux)

Ce que font les débutants

L'erreur la plus courante chez ceux qui apprennent TypeScript est d'écrire any partout. On se dit : « Bon, je n'ai pas précisé le type, mais le code fonctionne ! ».

// ❌ Mauvais : any tue tous les avantages de TypeScript\nfunction processData(data: any) {\n    console.log(data.name.toUpperCase());\n    return data.price * 2;\n}\n\nconst result = processData({ name: "ordinateur portable", price: 500 });\n// Ça marche... jusqu'à ce qu'on passe null\nprocessData(null); // Erreur à l'exécution !

Pourquoi c'est une erreur

any est un trou noir de TypeScript. Quand vous écrivez any, vous dites au compilateur : « Écarte-toi, je me débrouille ». Et il s'écarte. Vous perdez l'autocomplétion, la vérification des types et la protection contre les erreurs stupides. TypeScript redevient du JavaScript — avec tous ses défauts.

Comment corriger

Utilisez des types spécifiques. Si le type est inconnu à l'avance — unknown est votre ami. Il vous obligera à vérifier les données avant de les utiliser.

// ✅ Bon : types spécifiques et unknown\nfunction processData(data: { name: string; price: number }) {\n    console.log(data.name.toUpperCase());\n    return data.price * 2;\n}\n\n// Ou si le type est vraiment inconnu :\nfunction safeProcess(data: unknown) {\n    if (typeof data === 'object' && data !== null && 'name' in data) {\n        // Maintenant TypeScript sait que data est un objet avec un champ name\n        console.log((data as { name: string }).name);\n    }\n}

Conseil : Activez la règle no-explicit-any dans ESLint — elle vous empêchera d'utiliser any sans raison valable.

Erreur n°2 : Ignorer le mode strict (ou « pourquoi tout marche, mais pas comme prévu »)

Ce que font les débutants

Beaucoup de développeurs débutants, lors de l'apprentissage de TypeScript, désactivent le mode strict dans tsconfig.json ou ne l'activent pas du tout. Ils se disent : « ça ira, moins d'erreurs de compilation ».

// ❌ Mauvais : strict: false\n// tsconfig.json\n{\n    "compilerOptions": {\n        "strict": false, // Erreur !\n        "noImplicitAny": false,\n        "strictNullChecks": false\n    }\n}\n\n// Maintenant ce code se compile sans erreur :\nfunction greet(name: string | null) {\n    console.log(name.toUpperCase()); // Potentiel null !\n}\ngreet(null); // Runtime error : Cannot read properties of null

Pourquoi c'est une erreur

Sans le mode strict, TypeScript perd la moitié de sa puissance. Vous n'obtenez pas d'avertissements sur les potentiels null et undefined, vous ne vérifiez pas les types des arguments — et au final, vous attrapez des bugs en production.

Comment corriger

Activez toujours strict: true. Cela active toutes les vérifications strictes en une fois.

// ✅ Bon : strict: true\n{\n    "compilerOptions": {\n        "strict": true,\n        "target": "ES2020",\n        "module": "ESNext"\n    }\n}\n\n// Maintenant TypeScript vous oblige à gérer null :\nfunction g