unknown vs any en TypeScript : que choisir en 2025 ?

Introduction : pourquoi ce sujet a explosé sur Stack Overflow ?

\n

Si vous avez déjà écrit du TypeScript, vous avez sûrement été confronté au dilemme : unknown ou any ? Cette question, qui a rassemblé des milliers de vues sur Stack Overflow, reste d'actualité en 2025. Il semble que les deux types permettent de stocker n'importe quoi — alors quelle est la différence ?

\n\n

Imaginez que vous construisez une maison. any est une porte grande ouverte à tous, y compris aux cambrioleurs. unknown est une porte avec une serrure et un œilleton : vous vérifiez d'abord qui arrive, puis vous laissez entrer. Dans cet article, nous allons comprendre pourquoi unknown est devenu le standard de sécurité en TypeScript, et pourquoi any est un mal parfois justifié.

\n\n

Nous ne nous contenterons pas de répéter la documentation. Nous montrerons des cas concrets de la pratique en 2025, analyserons les meilleures pratiques et donnerons un algorithme de choix clair. C'est parti !

\n\n

Qu'est-ce que any et pourquoi tout le monde le craint ?

\n\n

any est le type le plus "flexible" de TypeScript. Il dit littéralement au compilateur : "Désactive le système de types, je sais ce que je fais". Cela ressemble à un super-pouvoir, mais en réalité c'est une bombe à retardement.

\n\n

Exemple : comment any casse les types

\n

function processUser(user: any) {\n    console.log(user.name.toUpperCase()); // Erreur à l'exécution si user est null\n}\n\nprocessUser(null); // TypeError: Cannot read property 'toUpperCase' of null

\n\n

Le compilateur TypeScript ne vous avertira même pas de cela ! any désactive toutes les vérifications, et l'erreur n'apparaîtra qu'en production. En 2025, alors que les projets deviennent plus complexes, cette approche mène au chaos.

\n\n

Quand any est-il quand même utile ?

\n

\n
• Migration depuis JavaScript : lorsque vous réécrivez un ancien projet, any est une béquille temporaire.
\n
• Données dynamiques : par exemple, les réponses d'API externes dont la structure change.
\n
• Tests : dans les mocks, il est parfois plus simple d'utiliser any que de décrire des types complexes.
\n

\n\n

Mais rappelez-vous : any est comme une carte de crédit avec une limite infinie. Pratique, jusqu'à ce que la facture arrive.

\n\n

Unknown : un gardien strict à l'entrée

\n\n

unknown est apparu dans TypeScript 3.0 comme une alternative sécurisée à any. Il peut également contenir n'importe quelle valeur, mais interdit de l'utiliser sans vérification explicite. C'est un type-conteneur qui exige une vérification.

\n\n

Exemple : unknown en action

\n

function processUser(user: unknown) {\n    // Erreur de compilation ! La propriété 'name' n'existe pas sur le type 'unknown'\n    // console.log(user.name.toUpperCase()); \n    \n    // Une vérification est nécessaire\n    if (user && typeof user === 'object' && 'name' in user) {\n        const typedUser = user as { name: string };\n        console.log(typedUser.name.toUpperCase()); // Tout va bien\n    }\n}\n\nprocessUser({ name: "Alice" }); // ALICE\nprocessUser(null); // Rien ne plante

\n\n

Vous avez remarqué la différence ? unknown ne vous laisse pas vous tirer une balle dans le pied. Vous devez vérifier le type avant de l'utiliser. C'est ce qu'on appelle le typage sécurisé.

\n\n

Comparaison any vs unknown dans un tableau

\n\n

Pour consolider le sujet, regardons les différences clés :

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Critère	any	unknown
Attribution de n'importe quelle valeur	✅ Oui	✅ Oui
Accès aux propriétés sans vérification	✅ Oui	❌ Non
Attribution à un autre type	✅ N'importe lequel	❌ Uniquement any ou unknown
Protection contre les erreurs à l'exécution	❌ Non	✅ Oui (nécessite une vérification)

\n\n

Comme vous le voyez, unknown l'emporte