Interprété vs compilé

Le problème de base : un ordinateur ne comprend pas votre code

Il faut partir d'un fait qu'on oublie vite : un processeur ne comprend qu'un seul langage, le binaire , des suites de 0 et de 1 qui correspondent à des instructions électriques précâblées dans le silicium. Rien de ce que vous écrivez en Python, en JavaScript, en C ou en Java n'est directement compréhensible par la machine.

Il faut donc, à un moment ou à un autre, traduire votre code source  lisible par un humain en instructions que le processeur peut exécuter. C'est cette étape de traduction qui distingue un langage "compilé" d'un langage "interprété". La différence ne porte pas sur le langage en tant que tel, mais sur la manière dont on l'exécute.

La compilation : traduire une fois, exécuter ensuite

Avec un langage compilé  C, C++, Rust, Go  un programme spécial appelé compilateur lit l'intégralité de votre code source avant toute exécution, et le traduit en code machine natif, stocké dans un fichier exécutable (.exe sous Windows, binaire ELF sous Linux, etc.).

Ce processus se déroule en plusieurs étapes :

●        Analyse du code source (syntaxe, types, erreurs)

●        Traduction en une représentation intermédiaire

●        Optimisations (suppression de code inutile, réorganisation des calculs, etc.)

●        Génération du code machine final, spécifique au processeur cible

Une fois ce travail terminé, vous obtenez un fichier exécutable autonome. Quand vous le lancez, le processeur exécute directement les instructions binaires, sans repasser par aucune étape de traduction. C'est ce qui rend les langages compilés généralement très rapides à l'exécution : tout le travail d'analyse a été fait à l'avance, une bonne fois pour toutes.

La contrepartie : si vous changez une ligne de code, il faut recompiler tout ou partie du programme avant de pouvoir le tester. Et un exécutable compilé pour Windows ne fonctionnera pas sur macOS ou Linux sans recompilation, puisque le code machine généré dépend du système et du processeur cible.

L'interprétation : traduire au fur et à mesure

Avec un langage interprété  Python, JavaScript, Ruby, PHP il n'y a pas d'étape de compilation préalable en code machine. Un autre programme, l'interpréteur, lit votre code source ligne par ligne (ou instruction par instruction) et l'exécute au fur et à mesure, en le traduisant "à la volée".

Concrètement, quand vous lancez un script Python, l'interpréteur Python lit la première instruction, l'exécute, passe à la suivante, l'exécute, et ainsi de suite. Il n'y a pas de fichier exécutable autonome généré : vous avez besoin de l'interpréteur à chaque exécution.

L'avantage est immédiat : pas de compilation à attendre, vous modifiez votre code et vous le relancez directement. C'est ce qui rend les langages interprétés particulièrement agréables pour prototyper, apprendre, ou itérer rapidement. La contrepartie, c'est une exécution généralement plus lente, puisque le travail de traduction se refait à chaque lancement, voire à chaque ligne.

La réalité est plus nuancée : le mythe du "pur"

Voici ce qu'on vous dit rarement : il n'existe presque plus de langage purement interprété ou purement compilé dans l'industrie moderne. La distinction binaire enseignée en cours est une simplification pédagogique.

Python, par exemple, compile en réalité votre code source en un langage intermédiaire appelé bytecode (les fameux fichiers .pyc), qui est ensuite exécuté par une machine virtuelle. Ce n'est pas de la compilation en code machine natif, mais ce n'est pas non plus une interprétation ligne par ligne du code source brut.

Java pousse cette logique plus loin : votre code est compilé en bytecode, qui tourne ensuite sur la machine virtuelle Java (JVM). Cette JVM utilise une technique appelée compilation JIT (Just-In-Time) : elle repère les portions de code exécutées très souvent et les compile en code machine natif en cours d'exécution, pour accélérer les prochains passages. JavaScript moderne, via des moteurs comme V8 (Chrome, Node.js), fonctionne exactement sur ce même principe hybride.

Autrement dit : la frontière entre "interprété" et "compilé" n'est pas une ligne nette, mais un spectre. La plupart des langages modernes combinent les deux approches pour tirer le meilleur des deux mondes.

Pourquoi c'est important à comprendre

Ce n'est pas qu'une curiosité théorique. Comprendre cette mécanique change concrètement votre manière de raisonner en tant que développeur :

●        Vous comprenez pourquoi certaines erreurs n'apparaissent qu'à l'exécution en Python (l'interpréteur ne vérifie pas tout à l'avance), alors qu'en C, beaucoup d'erreurs bloquent la compilation avant même de lancer le programme.

●        Vous comprenez pourquoi un exécutable C ne "tourne" pas tel quel sur une autre machine, alors qu'un script Python, lui, s'exécute partout où Python est installé.

●        Vous comprenez mieux les choix d'architecture : pourquoi une entreprise choisit Go pour un service critique à haute performance, et Python pour un script d'automatisation rapide à écrire.

●        Vous arrêtez de penser qu'un langage est "lent" ou "rapide" dans l'absolu ,c'est le mode d'exécution, pas le langage en soi, qui détermine une grande partie de la performance.

En résumé

Compilé : le code source est entièrement traduit en code machine avant l'exécution, ce qui donne un programme rapide mais dépendant de la plateforme cible.

Interprété : le code est lu et exécuté au fur et à mesure par un interpréteur, ce qui donne plus de souplesse mais moins de performance brute.

Hybride (la réalité de la majorité des langages modernes) : une combinaison des deux, avec bytecode et compilation à la volée, pour concilier flexibilité de développement et performance à l'exécution.

La prochaine fois que quelqu'un vous dira "Python est un langage interprété", vous saurez que c'est vrai  mais seulement à moitié.