La compilation

On dit sans arrêt qu'un code « compile » ou qu'une erreur est « de compilation ». Mais compiler, ça veut dire quoi exactement ? C'est l'une des idées les plus fondamentales de la programmation, et la comprendre éclaire tout le reste (typage, transpilation, langages interprétés).

# Du code lisible au code exécutable

Un processeur ne comprend qu'une seule chose : du code machine, des instructions binaires (des 0 et des 1). Personne n'écrit directement là-dedans. On écrit dans des langages de haut niveau - C#, Java, C++ - pensés pour l'humain.

Entre les deux, il faut donc une traduction. C'est le rôle de la compilation.

# Qu'est-ce que compiler ?

Un compilateur est le programme qui fait cette traduction. Il lit tout ton code, le vérifie, puis produit un artefact exécutable (un .exe, un binaire...). Une fois cet artefact produit, le programme tourne tout seul, sans avoir besoin du code source ni du compilateur.

Code source (C#)  ──[ compilateur ]──►  Exécutable  ──►  La machine exécute
   monfichier.cs                          monprog.exe

Code source (C#)  ──[ compilateur ]──►  Exécutable  ──►  La machine exécute

   monfichier.cs                          monprog.exe

C'est une étape séparée et préalable : d'abord on compile (le build), ensuite on exécute.

# Les erreurs de compilation

Puisque la traduction se fait avant l'exécution, le compilateur peut refuser de traduire s'il détecte un problème. C'est une sécurité énorme : le programme ne démarre même pas tant que ces erreurs ne sont pas corrigées.

Forme f = new Forme();  // ❌ Erreur de compilation :
                        //    impossible d'instancier une classe abstraite

Forme f = new Forme();  // ❌ Erreur de compilation :

                        //    impossible d'instancier une classe abstraite

Le compilateur attrape ici deux grandes familles d'erreurs :

• la syntaxe (une accolade oubliée, un mot-clé mal écrit) ;
• les types, dans les langages typés statiquement (passer un texte là où un nombre est attendu).

Une erreur de compilation, c'est une erreur découverte gratuitement, avant que le programme n'ait fait quoi que ce soit.

# « À la compilation » vs « à l'exécution »

Ces deux expressions reviennent partout, et opposent deux moments dans la vie d'un programme :

Retiens cet axe : c'est la clé pour comprendre le typage. Un type vérifié « à la compilation » t'empêche d'écrire le bug ; un bug « à l'exécution » ne se révèle qu'en faisant tourner le code, souvent trop tard.

# Nuance : le bytecode, un intermédiaire

Tous les langages « compilés » ne produisent pas directement du code machine. C# et Java compilent d'abord vers un format intermédiaire (le bytecode, appelé IL en .NET) : un langage à mi-chemin, ni tout à fait humain ni tout à fait machine.

Ce bytecode est ensuite exécuté par une machine virtuelle (le runtime .NET, la JVM pour Java), qui le traduit en code machine au dernier moment. C'est ce qui rend ces langages portables : le même bytecode tourne sur Windows, Linux ou macOS, tant qu'il y a le bon runtime. On retrouve cette idée du côté des langages interprétés.

# À retenir

• Compiler = traduire tout le code source en code exécutable, avant de lancer le programme.
• Le compilateur peut refuser de compiler : ce sont les erreurs de compilation (syntaxe, types), attrapées avant l'exécution.
• Compile-time vs runtime : l'axe central. Ce qui est vérifié à la compilation ne peut plus casser à l'exécution.
• Beaucoup de langages compilent vers du bytecode exécuté par une machine virtuelle, gage de portabilité.

À lire ensuite : Les langages interprétés, l'autre grande façon d'exécuter du code.