FondamentauxDébutantSérie : Fondamentaux

Les langages interprétés

Exécuter du code directement, sans étape de compilation préalable : ce qu'est un interpréteur, en quoi ça diffère d'un langage compilé, et pourquoi la frontière est en réalité floue (le JIT).

Par Baptiste Vidal

2 min de lecture

Mis à jour il y a 2 semaines

fondamentauxinterprétéinterpréteurjavascriptjit

Les langages interprétés

On a vu ce qu'est la compilation : traduire tout le code en exécutable, avant de le lancer. Il existe une autre façon de faire tourner du code, sans cette étape préalable : l'interprétation. C'est notamment celle de JavaScript.

# Exécuter sans compiler d'abord

Un interpréteur lit et exécute le code source directement, au fur et à mesure, au moment où on le lance.

Pas d'étape de build, pas d'exécutable produit à l'avance. On donne le fichier source à un programme - l'interpréteur - et il l'exécute ligne après ligne.

Code source (JS)  ──►  [ interpréteur ]  ──►  exécution immédiate
   script.js              (le moteur JS)         ligne par ligne

Code source (JS)  ──►  [ interpréteur ]  ──►  exécution immédiate

   script.js              (le moteur JS)         ligne par ligne

C'est exactement ce qui se passe quand un navigateur charge une page : il reçoit ton fichier .js et son moteur JavaScript (V8 dans Chrome) l'exécute tel quel. Aucun .exe n'a été fabriqué.

# Compilé vs interprété

	Compilé	Interprété
Traduction	Tout, une fois, avant l'exécution	Au fur et à mesure, pendant l'exécution
Artefact	Un exécutable réutilisable	Aucun : on relance la source
Erreurs	Attrapées à la compilation, avant de lancer	Découvertes à l'exécution, quand la ligne s'exécute
Vitesse	Généralement plus rapide à l'exécution	Plus souple, démarrage immédiat

Ça explique un comportement typique de JavaScript : une faute de type ne bloque rien à l'avance. Le code suivant se lance sans broncher, et ne casse (ou ne renvoie n'importe quoi) qu'au moment où la ligne fautive s'exécute :

function prix(quantite, prixUnitaire) {
  return quantite * prixUnitaire;
}
prix("3€", 10); // NaN, découvert seulement à l'exécution

function prix(quantite, prixUnitaire) {

  return quantite * prixUnitaire;

prix("3€", 10); // NaN, découvert seulement à l'exécution

C'est précisément ce que TypeScript vient corriger, en rajoutant une vérification avant l'exécution.

# La réalité : ce n'est pas si binaire (le JIT)

En pratique, la frontière « compilé / interprété » est floue. Les moteurs modernes ne se contentent pas d'interpréter bêtement.

Le moteur JavaScript V8, par exemple, fait de la compilation à la volée (Just-In-Time, ou JIT) : il commence par interpréter, repère le code exécuté souvent (« chaud »), puis le compile en code machine pendant l'exécution pour l'accélérer. À l'inverse, .NET compile ton C# en bytecode... qui est lui aussi JIT-compilé à l'exécution.

Autrement dit : « compilé » et « interprété » ne sont pas deux camps étanches, mais deux points sur un spectre. Ce qui distingue vraiment les langages, c'est quand la traduction a lieu, et combien en est faite à l'avance.

# À retenir

Un langage interprété est exécuté directement par un interpréteur, sans build préalable ni exécutable.
Conséquence : les erreurs (dont les erreurs de type) apparaissent à l'exécution, pas avant.
La distinction compilé/interprété est un spectre, pas un mur : le JIT compile du code à la volée pendant l'exécution.

À lire ensuite : Compilation vs interprétation, la synthèse et où se situe chaque langage.