L'effacement des types, ou la preuve qui s'évapore Type erasure, or the proof that evaporates

L'annotation a promis une forme. À l'exécution, il n'y a personne.The annotation promised a shape. At runtime, there's no one there.

Quatre lignes qui compilent, et plantent. Le réflexe, après le Vol 1, est de croire qu'un : User garantit un User. Il ne garantit rien à l'exécution — parce qu'à l'exécution, il n'existe plus. Les types prouvent à la compilation, puis s'effacent. C'est la faille fondamentale, et le cœur de la série.Four lines that compile, and crash. The reflex, after Vol 1, is to believe a : User guarantees a User. It guarantees nothing at runtime — because at runtime, it no longer exists. Types prove at compile time, then erase. That's the fundamental gap, and the heart of the series.

type User = { name: string; age: number };

const u: User = JSON.parse('null');   // ✓ compile sans une plainte
console.log(u.name);                  // 💥 Cannot read properties of null

// L'annotation : User a promis une forme.
// JSON.parse a rendu any. Personne n'a vérifié. À l'exécution, u vaut null.

On voudrait demander « es-tu un User ? ». Il n'y a personne à qui demander.You'd love to ask "are you a User?". There's no one to ask.

Le premier réflexe pour se protéger du plantage du chapitre 1 : tester le type à l'exécution. Sauf qu'aucune syntaxe ne le permet — parce qu'il n'y a rien à tester. Une interface ne produit aucun JavaScript : elle n'existe nulle part au runtime. Le code compilé ne contient que des valeurs.The first instinct to guard against chapter 1's crash: test the type at runtime. Except no syntax allows it — because there's nothing to test. An interface produces no JavaScript: it exists nowhere at runtime. The compiled code holds only values.

interface User { name: string; age: number }

function handle(x: unknown) {
  if (x is User) { /* ... */ }      // ✗ n'existe pas comme test runtime
  if (typeof x === User) { /* ... */ } // ✗ 'User' only refers to a type, but is being used as a value here
}
// Aucune de ces lignes ne compile : on ne peut pas INTERROGER un type.

Un type vit dans un univers parallèle, consultable seulement par le compilateur. On ne peut pas écrire x is User comme condition, ni mettre un type derrière typeof : un type n'est pas une valeur, et seules les valeurs survivent.A type lives in a parallel universe, readable only by the compiler. You can't write x is User as a condition, nor put a type after typeof: a type is not a value, and only values survive.

Ce qui est une valeur survit. Ce qui n'est qu'un type disparaît.What is a value survives. What is only a type disappears.

La ligne de partage est nette : tout ce qui existe aussi comme valeur JavaScript franchit la frontière ; tout ce qui n'existe que dans l'univers des types s'efface. C'est pour ça qu'instanceof marche (une classe est une fonction réelle) et que : Cat ne marche pas (une interface n'émet rien). L'enum, lui, triche : il produit un objet.The dividing line is sharp: anything that also exists as a JavaScript value crosses the boundary; anything that lives only in the type universe is erased. That's why instanceof works (a class is a real function) and : Cat doesn't (an interface emits nothing). The enum cheats: it produces an object.

class Dog { bark() {} }
const d: unknown = new Dog();
d instanceof Dog;          // ✓ marche — Dog est une vraie valeur JS (une fonction)

interface Cat { meow(): void }
// d instanceof Cat        // ✗ 'Cat' only refers to a type, but is being used as a value here

enum Color { Red, Green }
Object.values(Color);      // ✓ Color émet un vrai objet à l'exécution

typeof "x";                // ✓ "string"  — typeof JS, sur des valeurs
typeof d;                  // ✓ "object"  — incapable de dire "Dog" vs autre

Le type ne décide rien à l'exécution. Une valeur, si.The type decides nothing at runtime. A value does.

Deux usages du même malentendu. À gauche, on traite l'annotation comme une garantie sur des données venues du dehors — un as User sur une réponse réseau, et le crash est juste reporté. À droite, le bon réflexe : pour décider à l'exécution, on lit un champ qui existe vraiment dans la valeur — un discriminant.Two faces of the same misunderstanding. On one side, treating the annotation as a guarantee on data from outside — an as User on a network response, and the crash is merely deferred. On the other, the right reflex: to decide at runtime, read a field that genuinely exists in the value — a discriminant.

// Le type comme preuve — un vœu, pas une vérification
async function load(): Promise<User> {
  const res = await fetch('/api/user');
  return (await res.json()) as User;   // as = « crois-moi », rien n'est vérifié
}

const u = await load();
u.name.toUpperCase();   // 💥 si l'API a renvoyé autre chose, ça pète ici

Tout ce qui entre — réseau, JSON.parse, localStorage, process.env — arrive non typé. Le as User ne vérifie rien : il fait taire le compilateur. Le type a beau dire User, l'exécution a ce que l'API a vraiment renvoyé. Le crash n'est pas évité, il est déplacé plus loin — là où il est le plus dur à diagnostiquer.Everything that enters — network, JSON.parse, localStorage, process.env — arrives untyped. The as User checks nothing: it silences the compiler. The type may say User, but runtime has whatever the API actually returned. The crash isn't avoided, it's moved further out — where it's hardest to diagnose.