Terminal, shell, TTY, PTY : la différence enfin expliquée simplement

Le 17 février 2026, le développeur Ahmad Awais, VP Developer Relations avec quinze ans d'expérience dans le domaine, publie un guide de référence de 40 minutes de lecture intitulé The Full Stack of Terminals Explained. Son sujet : démêler quatre mots que la plupart des développeurs emploient depuis des années sans jamais les avoir vraiment distingués, à savoir terminal, shell, TTY et console.

Ce n'est pas une querelle de vocabulaire. C'est le genre de confusion qui reste invisible jusqu'au jour où elle vous coûte une heure de débogage : un script qui perd ses couleurs une fois lancé depuis une CI, une tâche cron qui échoue sans raison apparente, un ssh mal utilisé qui empêche un éditeur de s'afficher correctement à distance. Comprendre qui fait quoi dans cette chaîne évite ces pièges, et change la façon dont vous lisez une erreur.

Pourquoi ces mots se confondent : une histoire de teletype

La confusion a une origine précise. Dans les années 1960, ces quatre mots désignaient tous le même objet : une machine à écrire électrique reliée à un ordinateur central par un fil, capable d'envoyer des caractères et d'en recevoir en retour. On l'appelait console parce que c'était le poste de contrôle de la machine, terminal parce que c'était le bout de la ligne, et TTY parce que c'était littéralement une teletypewriter. Trois noms pour un seul appareil.

Puis le matériel a disparu, remplacé par du logiciel, et chaque mot a dérivé lentement vers un sens propre. Ils se ressemblent encore aujourd'hui parce qu'ils ont grandi ensemble, et c'est précisément ce qui piège des générations de développeurs qui les emploient sans jamais s'être arrêtés dessus.

Console, terminal, shell : qui fait quoi exactement

La console est l'interface physique d'entrée-sortie d'une machine : clavier et écran branchés directement dessus. Sur un serveur, c'est l'accès direct auquel vous accédez sans passer par le réseau, celui que le noyau utilise pour afficher ses messages de panique quand tout le reste a planté. C'est le terminal de dernier recours, garanti de fonctionner même quand la carte réseau est morte.

Le terminal, lui, est ce que vous voyez à l'écran quand vous ouvrez iTerm2, Alacritty, kitty, GNOME Terminal ou Windows Terminal. Son travail se limite à l'affichage : il reçoit du texte, il l'affiche, il interprète les couleurs et le formatage via les séquences ANSI, il gère le défilement et le copier-coller. Ce qui surprend souvent les développeurs : le terminal ne comprend absolument rien à vos commandes. Il ignore ce qu'est git ou ls. C'est une surface d'affichage avec un clavier attaché, rien de plus.

Le shell est le programme qui tourne à l'intérieur du terminal et qui, lui, comprend vos commandes. Vous tapez git status, le terminal transmet ce texte au shell (bash, zsh, fish, PowerShell), le shell analyse la commande, retrouve le programme git sur le disque, lance le processus et récupère sa sortie pour la renvoyer vers le terminal. Le terminal affiche les pixels, le shell exécute la logique. Ce sont deux programmes totalement indépendants : n'importe quel terminal fonctionne avec n'importe quel shell, et vous pouvez changer l'un sans toucher l'autre.

TTY et PTY : la tuyauterie invisible du noyau

Le TTY est la partie la plus technique et la moins visible au quotidien. Sous Unix, c'est un fichier spécial du noyau qui relie le terminal au shell, un peu comme un tuyau typé. Tapez la commande tty dans votre terminal actuel et vous verrez apparaître quelque chose comme /dev/pts/1 ou /dev/ttys003 : c'est le fichier device de votre session en cours. Pour un usage quotidien, tty et terminal désignent la même chose. La différence ne compte vraiment que quand vous écrivez du code bas niveau ou que vous déboguez un problème de signaux.

Le PTY (pseudo-terminal) est un TTY simulé en logiciel, sans aucun matériel derrière. Chaque fois qu'un terminal n'est pas relié à un vrai clavier physique, comme dans une session SSH, un multiplexeur tmux, un conteneur Docker ou le terminal intégré de VS Code, le système crée une paire de PTY (un côté maître, un côté esclave) pour faire croire au programme en face qu'il parle à un vrai TTY. C'est ce mécanisme qui rend possible tout le travail à distance moderne, et c'est aussi lui qui explique pourquoi certains outils se comportent différemment selon qu'ils tournent en local ou derrière un SSH.

Voir tout ça en action : quelques commandes

Rien de tel que la pratique pour fixer ces définitions. Dans un terminal, essayez :

tty
echo $SHELL
ps -o pid,tty,comm
printf "\033[32mCeci est vert\033[0m\n"

La commande tty affiche votre fichier device courant. echo $SHELL affiche le shell configuré par défaut pour votre utilisateur. ps -o pid,tty,comm liste les processus avec le TTY auquel chacun est rattaché, souvent un ? pour les processus détachés comme les démons. Quant au printf avec la séquence \\033[32m, c'est un exemple concret d'échappement ANSI : une instruction que seul le terminal interprète pour afficher du texte en vert. Le shell se contente de transmettre la chaîne de caractères, c'est le terminal qui la traduit en couleur.

Ce que ça change concrètement dans votre travail

• En intégration continue. Un pipeline CI n'a pas de TTY attaché : de nombreux outils détectent son absence et désactivent automatiquement leurs couleurs ou leurs barres de progression interactives. Si un script attend une confirmation interactive en CI, il reste bloqué. Prévoyez toujours un flag non interactif, comme --yes ou --non-interactive, dans les scripts destinés à tourner en pipeline.
• Dans les tâches cron. Même logique : une tâche cron n'a pas de terminal contrôleur, et sa variable PATH est souvent réduite. Toute commande qui suppose un TTY, comme un prompt de mot de passe, échouera silencieusement. Redirigez systématiquement la sortie vers un fichier de log et testez vos scripts hors mode interactif avant de les planifier.
• En connexion SSH. ssh hote "commande" sans option n'alloue pas de PTY, ce qui suffit pour un script ponctuel. ssh -t force l'allocation d'un PTY, indispensable dès que vous ouvrez un éditeur, un sudo interactif ou un outil comme htop.
• Avec Docker. docker exec -it alloue un PTY interactif, tandis que docker exec seul exécute la commande sans terminal, ce qui casse tout outil qui dépend d'un TTY pour son affichage.

Notre lecture chez CZSyn

Chez CZSyn, cette distinction n'a rien de théorique : elle explique une bonne partie des incidents d'infrastructure qu'on nous demande de déboguer chez nos clients. Un script de déploiement qui fonctionne en local mais qui se bloque sur un serveur de CI, une tâche cron qui échoue sans rien écrire dans les logs, un tunnel SSH qui refuse d'afficher un éditeur : dans la majorité des cas, la cause profonde est un TTY absent ou un PTY mal alloué, pas un bug applicatif. Former une équipe technique à cette pile complète (terminal, shell, TTY, PTY) est un investissement rentable pour n'importe quelle PME qui automatise ses déploiements, car cela réduit nettement le temps passé à déboguer des incidents qui, sans ce vocabulaire précis, ressemblent à de la magie noire.

Le vrai gain n'est pas de retenir quatre définitions, mais d'obtenir une grille de lecture. Face à un comportement étrange en ligne de commande, la première question à se poser devient : est-ce le terminal, le shell, ou l'absence de TTY qui est en cause ? Cette seule question fait gagner un temps considérable, en local comme en production.

Sources primaires

• Ahmad Awais, « The Full Stack of Terminals Explained », 17 février 2026.
• Linux man-pages, tty(4).
• Linux man-pages, pty(7).
• GNU Project, Bash Reference Manual.