Programmation · Concepts · Compilateur
C’est quoi un compilateur ?
Vous écrivez un programme dans un langage que vous savez lire : des mots, de l’indentation, des noms qui ont du sens. Le processeur de votre machine n’y comprend rien — il exécute des instructions binaires brutes. L’outil qui fait le pont, c’est le compilateur. Ce guide explique ce qu’est un compilateur, les étapes qu’il traverse, en quoi il diffère d’un interpréteur, et où se place un compilateur comme GHC quand vous écrivez du Haskell.
La définition courte
Un compilateur est un programme qui traduit du code source écrit dans un langage vers une autre forme — le plus souvent le code machine qu’un ordinateur peut exécuter directement. Vous lui donnez les fichiers texte que vous avez écrits, et il produit un exécutable (ou un format intermédiaire) que la machine, ou un runtime, peut faire tourner. La traduction se fait une fois, en amont, et le résultat s’exécute seul, sans que le compilateur soit présent.
Comment fonctionne un compilateur, étape par étape
Un compilateur ne traduit pas d’un seul coup. Il enchaîne un pipeline d’étapes, chacune passant son résultat à la suivante :
- Analyse lexicale (tokenisation) : le texte source est découpé en petites unités — mots-clés, noms, nombres, symboles — appelées jetons.
- Analyse syntaxique : les jetons sont organisés en un arbre qui reflète la structure du programme, selon la grammaire du langage.
- Analyse sémantique : le compilateur vérifie que le programme a du sens — noms définis, types cohérents, règles du langage respectées. C’est là que beaucoup de vos erreurs sont détectées.
- Optimisation : le compilateur réécrit le programme en un équivalent plus rapide ou plus petit sans changer ce qu’il fait.
- Génération de code : il émet enfin la sortie cible — code machine, ou une représentation intermédiaire qu’un autre outil terminera.
Si une étape trouve un problème, vous obtenez une erreur de compilation et aucun programme n’est produit. C’est le marché du compilateur : il refuse de construire du code cassé, donc toute une classe d’erreurs est attrapée avant même que le programme tourne.

Compilateur vs interpréteur
L’autre approche courante est l’interpréteur, qui lit votre code source et l’exécute directement, ligne par ligne, à chaque exécution — aucun exécutable séparé n’est construit en amont. Un compilateur traduit tout le programme une fois, au départ, vers une forme que la machine exécute seule.
La différence pratique : les programmes compilés démarrent et tournent en général plus vite, car la traduction et l’optimisation ont déjà eu lieu, et les erreurs apparaissent à la compilation. Les programmes interprétés sont plus rapides à tester et plus souples, mais refont le travail de traduction à chaque exécution. Beaucoup de chaînes d’outils réelles mélangent les deux — elles compilent vers une forme intermédiaire puis l’exécutent sur une machine virtuelle.
Où se placent GHC et Haskell
Quand vous écrivez du Haskell, le compilateur que vous utilisez est GHC (le Glasgow Haskell Compiler). Il lit vos fichiers source .hs, les vérifie de type rigoureusement, optimise le résultat, et produit un exécutable natif que vous pouvez lancer seul. Le système de types fort de Haskell fait que l’étape d’analyse sémantique de GHC travaille beaucoup pour vous : beaucoup de bugs sont signalés en erreurs de compilation au lieu de planter à l’exécution. Pour le tour complet de son usage, voyez notre guide du compilateur GHC et comment installer Haskell avec GHCup.
Les commandes que vous croisez vraiment
- Compiler un seul fichier : un outil comme
ghc Main.hslit votre source et produit un exécutable. - Construire un projet : des outils de build comme Cabal ou Stack pilotent le compilateur sur de nombreux fichiers et dépendances pour vous.
- Vérifier les types sans build complet : beaucoup de compilateurs offrent un mode plus rapide qui cherche les erreurs sans produire de binaire.
La plupart du temps, vous n’appelez pas le compilateur à la main — votre outil de build ou votre éditeur le fait et vous montre les erreurs. Mais savoir ce qu’il fait dessous rend ces erreurs bien plus faciles à lire.
Les compromis honnêtes
Les compilateurs ajoutent une étape : vous changez le code, vous attendez le build, puis vous exécutez. Sur un gros projet, cette attente peut se sentir, d’où l’importance des compilateurs rapides et des builds incrémentaux. Le gain est réel : erreurs attrapées tôt, sortie optimisée, et un exécutable unique livrable sans livrer votre chaîne d’outils. Pour un langage fortement typé comme Haskell, cette vérification en amont fait une grande part de l’attrait — le compilateur est un filet de sécurité, pas seulement un traducteur.
Questions fréquentes
C’est quoi un compilateur, simplement ?
Un compilateur est un programme qui traduit le code source que vous écrivez en une forme que l’ordinateur peut exécuter — le plus souvent du code machine. Vous lui donnez vos fichiers texte et il produit un exécutable qui tourne seul, sans que le compilateur soit présent. La traduction se fait une fois, en amont.
Quelle différence entre un compilateur et un interpréteur ?
Un compilateur traduit tout votre programme une fois, en amont, vers une forme exécutable, donc le résultat démarre et tourne vite. Un interpréteur lit et exécute votre code source directement à chaque exécution, sans étape de build séparée. Les programmes compilés sont en général plus rapides ; les interprétés sont plus rapides à tester et plus souples.
Quelles sont les étapes d’un compilateur ?
Un compilateur enchaîne généralement l’analyse lexicale (découpe du texte en jetons), l’analyse syntaxique (construction d’un arbre de structure), l’analyse sémantique (vérification des noms et des types), l’optimisation (rendre le programme plus rapide ou plus petit) et la génération de code (émission du code machine final ou d’une forme intermédiaire). Une erreur à n’importe quelle étape arrête le build.
GHC est-il un compilateur ?
Oui. GHC, le Glasgow Haskell Compiler, est le compilateur standard de Haskell. Il lit vos fichiers source .hs, les vérifie de type et les optimise, et produit un exécutable natif que vous pouvez lancer seul. Le système de types fort de Haskell fait que GHC attrape beaucoup de bugs en erreurs de compilation avant même que le programme tourne.
Une machine Linux pour compiler et exécuter votre code
Compiler un vrai projet — construire GHC, vérifier les types d’une grosse base Haskell, puis lancer l’exécutable — est bien plus simple sur une vraie machine Linux que sur un portable. Un serveur cloud vous donne un accès root pour installer une chaîne de compilation et construire votre app dans un environnement propre. Infomaniak — fournisseur suisse respectueux de la vie privée — propose des serveurs cloud que vous configurez et atteignez en SSH.
Voir Infomaniak Cloud →Lien affilié — il soutient ces guides gratuits.
Parcourez d’autres explications claires dans notre index des guides.