Ligne de commande Linux : tutoriel pas-à-pas 2026

📍 Article principal du programme : Linux fondamentaux 2026 — commandes, services, dépannage
Ce tutoriel fait partie du programme « Linux fondamentaux ». Pour la vue d’ensemble, lisez d’abord le guide principal.

Introduction

La ligne de commande Linux n’est pas un défi à passer puis à oublier. C’est l’interface naturelle d’un serveur en production, le seul outil disponible quand le terminal SSH est tout ce que vous avez, et l’environnement où vous gagnerez vos heures les plus rentables une fois la peur initiale dissipée. Ce tutoriel vous fait passer de « je tape des commandes que je copie-colle » à « je compose mes propres commandes en raisonnant ». Il suit un parcours en huit étapes, depuis la première frappe jusqu’aux pipelines composés que vous écrirez sans réfléchir au bout d’un mois de pratique.

Prérequis

• Un système Linux : Ubuntu 24.04/26.04 LTS, Debian 13, AlmaLinux 9 ou Rocky Linux 9. Une VM locale (Multipass, libvirt, VirtualBox) ou un VPS jetable convient.
• Un client SSH installé sur votre machine de travail (OpenSSH sur Linux/macOS/WSL, ou natif sur Windows 11).
• Niveau attendu : débutant. Aucune expérience préalable nécessaire.
• Temps estimé : 2 heures de lecture et de pratique.

Étape 1 — Comprendre ce que vous avez sous les yeux

Quand vous ouvrez un terminal Linux, vous lancez en réalité un programme appelé émulateur de terminal qui démarre lui-même un shell. Le shell par défaut sur la quasi-totalité des distributions serveur est Bash (Bourne Again Shell). C’est lui qui lit ce que vous tapez, l’interprète, et lance les programmes correspondants. Avant de taper une seule commande, prenez trente secondes pour décortiquer la ligne d’invite que vous voyez à l’écran.

malick@vps-paris:~/projets$

Ce prompt contient quatre informations utiles. malick est l’utilisateur connecté ; vps-paris est le nom d’hôte de la machine ; ~/projets est le répertoire courant (où le tilde ~ abrège votre répertoire personnel) ; et le $ final indique un utilisateur normal. Si vous voyez un # à la place du $, vous êtes connecté en root et chaque commande s’exécute avec les pleins pouvoirs. La commande whoami confirme l’utilisateur courant en cas de doute, hostname affiche le nom de machine, et pwd (« print working directory ») affiche le chemin absolu du répertoire courant.

Étape 2 — Naviguer dans l’arborescence

Une session shell a toujours un répertoire courant. Toutes les commandes qui prennent un nom de fichier sans chemin absolu cherchent à partir de là. Maîtriser le déplacement n’est donc pas optionnel : c’est ce qui distingue un débutant qui tape des chemins entiers d’un utilisateur efficace qui sait où il est.

pwd                          # affiche le répertoire courant
ls                           # liste son contenu
ls -la                       # liste tout, y compris fichiers cachés, en format long
cd /var/log                  # change vers /var/log
cd ~                         # retour au répertoire personnel
cd -                         # retour au répertoire précédent
cd ..                        # remonte d'un niveau

Après chaque cd, votre prompt affiche le nouveau répertoire. Si une erreur du type bash: cd: /chemin: No such file or directory apparaît, vous avez tapé un chemin inexistant — vérifiez l’orthographe avec la touche Tab, qui complète automatiquement les noms de fichiers existants. La commande ls -la mérite une attention particulière : elle affiche pour chaque entrée les permissions, le nombre de liens, le propriétaire, le groupe, la taille, la date de modification et le nom. Sur un serveur en production, c’est la commande qu’on tape par réflexe en arrivant dans un répertoire inconnu.

Étape 3 — Lire et chercher dans des fichiers

Une grande partie du travail d’administration consiste à lire des fichiers texte : configurations dans /etc, journaux dans /var/log, scripts dans /usr/local/bin. Il existe trois familles d’outils selon le contexte. Pour un fichier court qu’on veut voir entièrement, cat fichier.conf dump le contenu à l’écran. Pour un fichier long, less fichier.conf ouvre une vue paginable où Espace avance, b recule, / cherche, q quitte. Pour ne voir que les premières ou dernières lignes, head -n 20 fichier et tail -n 20 fichier sont les bons outils ; tail -F /var/log/syslog suit en direct un fichier qui s’écrit, indispensable pour observer un service qui tourne.

cat /etc/os-release                    # voir quelle distribution exacte tourne
less /etc/ssh/sshd_config              # lire la conf SSH paginé
head -n 50 /var/log/auth.log           # 50 premières lignes
tail -F /var/log/nginx/access.log      # suivre les requêtes Nginx en direct
grep -i "error" /var/log/syslog        # chercher "error" sans tenir compte de la casse
grep -rn "TODO" /opt/mon-app/          # chercher récursivement avec numéros de ligne

grep est l’outil de recherche par excellence. L’option -i ignore la casse, -n affiche le numéro de ligne, -r descend dans les sous-répertoires, -v inverse le filtre. Un usage très courant : pour trouver pourquoi Nginx renvoie des 502, on tape grep -i "error\|warn" /var/log/nginx/error.log | tail -100. Quand vous lancez tail -F, le programme reste actif jusqu’à ce que vous appuyez sur Ctrl-C — c’est attendu, c’est même le but.

Étape 4 — Composer avec les pipes

Le pipe | est la mécanique centrale d’Unix. Il prend la sortie standard d’une commande et la donne en entrée standard de la suivante, ce qui permet d’enchaîner des outils simples pour résoudre des problèmes complexes sans écrire un seul script. Cette idée date des années 70, et elle reste la raison principale pour laquelle Linux est aussi efficace en ligne de commande.

# Trouver les 5 plus gros fichiers d'un répertoire
du -ah /var/log | sort -rh | head -n 5

# Compter combien de connexions SSH ont échoué aujourd'hui
grep "Failed password" /var/log/auth.log | grep "$(date +%b\ %d)" | wc -l

# Lister les processus qui consomment le plus de RAM
ps -eo pid,user,%mem,command --sort=-%mem | head -n 10

# Extraire les adresses IP qui appellent une URL précise
grep "POST /api/login" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

Lisez chaque pipeline de gauche à droite comme une phrase. Le premier exemple liste les fichiers avec leur taille humaine, trie par taille décroissante (-r reverse, -h human-readable), garde les 5 premiers. Le deuxième compte (wc -l) les lignes qui contiennent à la fois « Failed password » et la date du jour. Cette composition — un outil par maillon, chaque maillon faisant une chose — est un investissement intellectuel qui paie pendant des années. awk, sort, uniq, cut, tr, sed sont les six outils à ajouter ensuite à votre vocabulaire.

Étape 5 — Créer, copier, déplacer, supprimer

La gestion concrète des fichiers se fait avec une demi-douzaine de commandes que vous taperez chaque jour. Elles partagent toutes une convention simple : la source vient d’abord, la destination ensuite, et l’option -r active le mode récursif quand on travaille sur des répertoires.

mkdir -p /opt/mon-app/data           # crée le chemin complet sans erreur si déjà existant
touch fichier.txt                    # crée un fichier vide ou met à jour la date
cp source.txt destination.txt        # copie un fichier
cp -r src/ backup-src/               # copie un répertoire entier
mv ancien.txt nouveau.txt            # renomme ou déplace
rm fichier.txt                       # supprime un fichier
rm -rf vieux-projet/                 # supprime un répertoire récursivement (DANGEREUX)

La commande rm ne demande pas confirmation et n’envoie rien dans une corbeille — la suppression est immédiate et définitive. Trois habitudes valent leur poids en données récupérées. Premièrement, créer un alias alias rm='rm -i' dans votre ~/.bashrc qui force la confirmation. Deuxièmement, ne jamais utiliser de variable non vérifiée dans une commande de suppression : rm -rf "$DIR/" avec $DIR vide est l’erreur classique qui efface tout sous la racine. Troisièmement, cp -i et mv -i demandent confirmation avant d’écraser un fichier existant — mêmes habitudes pour mêmes raisons.

Étape 6 — Maîtriser l’historique et la complétion

Une session productive est une session où vous tapez chaque commande au plus une fois. L’historique Bash, conservé dans ~/.bash_history, mémorise les 1000 dernières commandes par défaut. La touche ↑ remonte ligne par ligne ; mais le vrai gain vient de Ctrl-R, qui ouvre une recherche incrémentale : tapez quelques lettres et la dernière commande correspondante apparaît, appuyez à nouveau sur Ctrl-R pour remonter plus loin.

history | tail -20                  # voir les 20 dernières commandes
!42                                 # rejouer la commande numéro 42 de l'historique
!!                                  # rejouer la dernière commande
sudo !!                             # rejouer la dernière commande avec sudo
!ssh                                # rejouer la dernière commande qui commence par ssh

La complétion par tabulation est l’autre levier. Tapez system puis Tab deux fois : Bash liste tous les exécutables dont le nom commence par « system ». Idem pour les fichiers. Sur Ubuntu et Debian, le paquet bash-completion ajoute la complétion intelligente des options pour les commandes courantes : tapez systemctl restart puis Tab, et la liste des services s’affiche. Si la complétion d’options ne fonctionne pas, installez le paquet : sudo apt install bash-completion puis ouvrez une nouvelle session.

Étape 7 — Variables, environnement, alias

Bash gère deux espaces de variables. Les variables locales n’existent que dans le shell courant ; les variables d’environnement sont héritées par les programmes lancés depuis le shell. La distinction est cruciale parce qu’un programme — Python, Node, Nginx — ne voit que les secondes.

VAR=hello                            # variable locale
echo $VAR                            # affiche : hello
export DATABASE_URL=postgres://...   # variable d'environnement
env | grep DATABASE                  # liste les variables qui contiennent DATABASE
echo $PATH                           # le chemin de recherche des exécutables
unset VAR                            # supprime une variable

Pour rendre une variable persistante, ajoutez la ligne export dans votre ~/.bashrc (chargé à chaque session interactive) ou ~/.profile (chargé à la connexion). Les alias suivent le même principe — alias ll='ls -lah' dans le ~/.bashrc crée un raccourci permanent. Après modification, source ~/.bashrc applique les changements sans devoir redémarrer la session. La variable $PATH mérite une attention particulière : c’est elle qui dit à Bash où chercher un exécutable. Quand vous tapez nginx, Bash parcourt chaque répertoire listé dans $PATH et lance le premier exécutable trouvé. which nginx et type nginx diagnostiquent rapidement quel binaire est effectivement appelé.

Étape 8 — Vérification et bonnes habitudes

À ce stade, vous savez naviguer, lire, chercher, composer des pipelines, manipuler des fichiers, utiliser l’historique, et exporter des variables. Pour valider que tout fonctionne, lancez la séquence suivante sur votre machine de test : elle exécute en chaîne tout ce que nous avons vu et confirme que votre environnement est prêt.

cd ~ && \
mkdir -p test-cli/{a,b,c} && \
for i in 1 2 3 4 5; do echo "ligne $i" > test-cli/a/file-$i.txt; done && \
ls -la test-cli/a/ && \
grep -rn "ligne 3" test-cli/ && \
du -sh test-cli/* | sort -h && \
rm -rf test-cli && \
echo "✓ tout va bien"

La sortie attendue se termine par la ligne ✓ tout va bien. Si vous lisez ce message, votre shell, vos commandes de base, vos pipelines et votre suppression récursive fonctionnent comme prévu. Pour la suite, prenez l’habitude de tout tester sur une machine jetable avant la production, de lire man commande dès qu’une option vous échappe, et de copier vos commandes utiles dans un fichier ~/Documents/cheatsheet.md que vous étofferez avec l’expérience.

Erreurs fréquentes

Tutoriels associés

• Permissions Linux : chmod, chown, sudo
• Processus Linux : ps, top, htop, kill, signaux

À lire ensuite

• 🔝 Retour au guide principal : Linux fondamentaux 2026
• The Linux Command Line, William Shotts — linuxcommand.org/tlcl.php (PDF gratuit)
• Pages de manuel en ligne — man7.org
• Exemples concis — tldr.sh
• Bash Reference Manual GNU — gnu.org/software/bash/manual/

FAQ

Quelle est la différence entre sh et bash ?
sh désigne historiquement le Bourne Shell, un shell minimal défini par POSIX. Sur Ubuntu et Debian, /bin/sh pointe vers Dash, un shell très léger conçu pour la rapidité de démarrage des scripts d’init. Bash est un sur-ensemble qui ajoute tableaux, expansions, complétion, alias, et bien d’autres fonctionnalités. Pour des scripts portables, ciblez sh ; pour vos scripts d’admin internes, ciblez bash.

Pourquoi ma commande fonctionne en interactif et pas dans un script ?
Trois causes classiques. Premièrement, le shebang : un script doit commencer par #!/bin/bash et non #!/bin/sh si vous utilisez des fonctionnalités Bash. Deuxièmement, l’environnement : un script ne charge pas ~/.bashrc par défaut, donc vos alias et variables interactives ne sont pas disponibles. Troisièmement, le mode strict : ajoutez set -euo pipefail en tête de chaque script pour repérer les erreurs au lieu de les ignorer.

Comment éviter de retaper mon mot de passe sudo en boucle ?
Le ticket sudo a une durée de validité de 5 minutes par défaut sur Ubuntu et Debian. Vous pouvez l’allonger en éditant /etc/sudoers via sudo visudo et en ajoutant Defaults timestamp_timeout=30. Pour une session d’admin intensive, l’option propre est sudo -i qui ouvre un shell root, à fermer dès la fin du travail.

Faut-il apprendre vim, nano ou autre chose ?
Apprenez nano aujourd’hui — c’est l’éditeur installé par défaut sur la quasi-totalité des serveurs et il est utilisable en 30 secondes. Apprenez vim dans les six prochains mois : il est universellement disponible (même sur les conteneurs minimalistes) et sa courbe d’apprentissage est rentable au-delà de la première semaine. Le tutoriel intégré se lance avec vimtutor.

Le terminal affiche des caractères bizarres, que faire ?
Vérifiez d’abord la locale avec locale. Sur un serveur fraîchement provisionné, elle est parfois positionnée sur POSIX, ce qui casse l’affichage UTF-8. La correction : sudo locale-gen fr_FR.UTF-8 puis sudo update-locale LANG=fr_FR.UTF-8, et reconnectez-vous. Si le problème vient de votre client SSH (PuTTY, Terminal Windows), forcez l’encodage UTF-8 dans ses préférences.

Comment exécuter une commande qui prend du temps sans rester bloqué dans le terminal ?
Trois solutions selon le contexte. Pour une commande ponctuelle, nohup commande & détache le processus et redirige sa sortie dans nohup.out ; vous pouvez fermer la session SSH sans tuer la commande. Pour un travail récurrent ou plus lourd, ouvrez une session tmux (sudo apt install tmux puis tmux new -s travail) qui survit à la déconnexion ; vous la retrouvez avec tmux attach -t travail. Pour une commande qui doit s’exécuter à heure fixe, c’est cron ou un timer systemd qui prend le relais — sujet abordé dans un autre tutoriel du programme.

Comment savoir si une commande dangereuse va casser quelque chose avant de la lancer ?
Quatre garde-fous valent la peine d’être pris très tôt. Premièrement, lire la page de manuel : man rm, man rsync, man dd détaillent les options destructives et les protections. Deuxièmement, lancer la commande en mode simulation quand elle existe : rsync --dry-run, find ... -print avant find ... -delete. Troisièmement, s’entraîner sur une machine jetable identique à la production avant de toucher à la production. Quatrièmement, tenir un journal des commandes destructives lancées en production avec leur résultat — c’est la meilleure assurance contre les répétitions d’erreur.