Linux fondamentaux 2026 – commandes, services, dépannage

Vous venez de louer un VPS, on vous a glissé une clé SSH, et vous voilà face à un prompt noir qui ne montre rien sauf votre nom suivi d’un dièse. Tout le reste — déployer une API, restaurer une base, comprendre pourquoi le serveur rame à 22 h — passe par cet écran. Ce guide vous donne le socle pratique pour cesser de copier-coller des commandes au hasard et commencer à raisonner comme un administrateur. Il couvre la ligne de commande, les permissions, les processus, les services systemd, le réseau, SSH, la lecture des logs avec journalctl, et une méthode de dépannage qui ne laisse rien au hasard.

Sommaire

• Pourquoi Linux reste central en 2026
• Choisir une distribution sans regret
• Anatomie d’une session shell
• Arborescence et permissions
• Processus, signaux, ressources
• Services avec systemd
• Couches réseau au quotidien
• SSH : la porte d’entrée
• Lire les logs avec journalctl
• Méthode de dépannage
• Tutoriels associés
• Erreurs fréquentes
• FAQ
• Ressources et références

Pourquoi Linux reste central en 2026

Le bilan d’usage est sans appel. Les enquêtes annuelles de la fondation Linux et l’enquête développeurs Stack Overflow 2024 placent Linux comme système majoritaire en production, avec une domination écrasante côté serveurs cloud et conteneurs. Toutes les images de base Docker officielles tournent sur un noyau Linux, Kubernetes orchestre des nœuds Linux, et même Windows Server expose désormais WSL pour permettre aux outils GNU de cohabiter avec Hyper-V. Pour un développeur qui veut maîtriser sa pile, contourner Linux signifie déléguer en aveugle à un PaaS la moindre micro-décision d’OS.

La réalité 2026 ajoute deux pressions nouvelles. D’un côté, la généralisation des architectures ARM dans le cloud — Ampere chez Oracle, Graviton chez AWS, Axion chez Google — oblige à comprendre la portabilité des binaires et le rôle des paquets multi-architecture. De l’autre, la pression sécurité ne faiblit pas : entre les règles d’audit CIS, les obligations sectorielles, et le besoin de durcir l’accès SSH face aux scanners automatisés, savoir lire un journal système est devenu une compétence quasi quotidienne.

Ce guide vise un public concret : développeurs juniors qui veulent dépasser le copier-coller, étudiants en BTS/Licence qui doivent rendre un projet déployé, freelances qui louent un VPS pour héberger un site WordPress ou une API Node, et administrateurs débutants qui héritent d’un serveur sans documentation. Aucun pré-requis autre qu’une console SSH ouverte et la patience d’expérimenter sur une machine non critique.

Choisir une distribution sans regret

Le marché serveur 2026 se concentre autour de quelques familles. Ubuntu 26.04 LTS « Resolute Raccoon », sortie le 23 avril 2026, supportée jusqu’en avril 2031, reste le choix par défaut chez la plupart des hébergeurs économiques car son écosystème de paquets .deb est immense et la documentation foisonne. Debian 13 « Trixie » publiée à l’été 2025 vise la même cible avec un cycle plus conservateur, plus stable mais avec des paquets parfois plus anciens. Du côté Red Hat, AlmaLinux 9 et Rocky Linux 9 ont remplacé CentOS 7 (fin de vie le 30 juin 2024) ; ils sont obligatoires si votre application réclame une compatibilité RHEL stricte ou si vous travaillez en environnement bancaire ou administratif.

Pour un premier serveur, Ubuntu 24.04 LTS reste un choix sûr — encore supportée jusqu’en avril 2029 — et Ubuntu 26.04 LTS prend la relève pour les nouveaux déploiements. Évitez les versions non-LTS sur un serveur de production : elles ne reçoivent que neuf mois de mises à jour de sécurité, ce qui force un cycle de migration trop fréquent.

La famille de distribution dicte trois choses : le gestionnaire de paquets (apt sur Debian/Ubuntu, dnf sur Alma/Rocky), l’emplacement de certains fichiers de configuration, et parfois la version par défaut des composants centraux comme le pare-feu (ufw côté Ubuntu, firewalld côté Alma). Tout le reste — le shell Bash, le noyau Linux, les commandes ls et grep, l’arborescence racine — est strictement identique. Apprenez les fondamentaux une fois, vous saurez les appliquer partout.

Anatomie d’une session shell

Quand vous vous connectez en SSH, Bash démarre et affiche un prompt, généralement de la forme user@host:~$. Le caractère $ indique un utilisateur normal ; le caractère # indique l’utilisateur root. Cette distinction n’est pas cosmétique — toute commande tapée derrière un # s’exécute avec les pleins pouvoirs et peut détruire le système d’un caractère mal placé.

Une commande Linux suit un schéma stable : un nom de programme, des options courtes commençant par -, des options longues commençant par --, et des arguments positionnels. Par exemple ls -lh --time=mtime /var/log appelle ls, demande l’affichage long et lisible (-lh), trie par date de modification, et liste le répertoire /var/log. Trois réflexes valent leur poids en fer : terminer chaque commande inconnue par --help pour lister rapidement les options, ouvrir man nom_commande pour la page de manuel détaillée, et utiliser tldr nom_commande (à installer via apt install tldr ou dnf install tldr) pour des exemples concrets.

Le shell n’est pas qu’un lanceur. Il chaîne les commandes via le pipe | qui prend la sortie standard d’un programme pour la donner en entrée standard du suivant. La commande ps -ef | grep nginx | grep -v grep | wc -l compte ainsi le nombre exact de processus Nginx actifs : ps -ef liste tous les processus, le premier grep filtre ceux qui contiennent « nginx », le second exclut sa propre ligne, et wc -l compte les lignes restantes. Cette composition est l’idée centrale d’Unix telle que la formulait Doug McIlroy dans les années 70 : « écris des programmes qui font une chose et qui la font bien, écris-les pour qu’ils collaborent ».

Pour aller au-delà de la simple frappe, retenez trois éléments. Les redirections > (écrase un fichier) et >> (ajoute en fin) capturent la sortie ; 2>&1 mélange erreur standard et sortie standard, indispensable pour conserver les messages d’erreur dans un log. La complétion par tabulation, déclenchée par la touche Tab, complète noms de commandes, options et fichiers — toute saisie manuelle d’un chemin est une fausse bonne idée. Enfin l’historique : Ctrl-R ouvre une recherche incrémentale dans les commandes passées, ce qui évite de retaper la commande de déploiement complexe d’avant-hier. Le détail pas-à-pas est dans le tutoriel ligne de commande Linux.

Arborescence et permissions

Linux n’a pas de lettres de lecteur. Tout part de / et descend en arborescence unique. Les emplacements canoniques sont normalisés par la Filesystem Hierarchy Standard (FHS 3.0 publiée en 2015 par la Linux Foundation, encore en vigueur en 2026). À retenir : /etc contient les fichiers de configuration système, /var/log les journaux applicatifs hors-systemd, /home/user les données personnelles, /usr/bin les binaires installés par les paquets, /opt les logiciels tiers manuellement déposés, /tmp les fichiers temporaires effacés à chaque redémarrage. Une commande aussi simple que ls -la /etc | head -20 donne une idée du désordre maîtrisé qui règne dans la configuration d’un système moderne.

Le modèle de permissions Unix repose sur un triplet propriétaire / groupe / autres couplé à un triplet read / write / execute. La sortie de ls -l fichier.txt commence par dix caractères : un type de fichier suivi de neuf bits. Par exemple -rw-r--r-- signifie fichier régulier, lecture-écriture pour le propriétaire, lecture seule pour le groupe et pour les autres. La commande chmod modifie ces bits, soit en notation symbolique (chmod g+w fichier), soit en notation octale (chmod 644 fichier). La commande chown change le propriétaire, et sudo élève temporairement les droits pour une commande précise sans imposer une session root permanente.

Trois pièges piègent les débutants. Premier piège : le bit setuid sur un binaire (chmod u+s) le fait s’exécuter avec les droits du propriétaire, pas de l’appelant — un script setuid root est une porte ouverte si mal écrit. Deuxième piège : sudo rm -rf / a réellement détruit des serveurs en production, et la protection moderne de GNU coreutils (--no-preserve-root requis depuis 2006) ne sauve plus contre une faute de frappe sur une variable comme rm -rf "$VAR/" où $VAR est vide. Troisième piège : les Access Control Lists (ACL POSIX) accordent des droits supplémentaires invisibles dans ls -l ; c’est getfacl qui révèle la vérité. Le tutoriel détaillé est dans le tutoriel sur chmod, chown et sudo.

Processus, signaux, ressources

Tout ce qui s’exécute sur un serveur est un processus. Le noyau attribue à chacun un identifiant unique (PID) et une hiérarchie : chaque processus a un parent, et le PID 1 — historiquement init, désormais systemd sur la quasi-totalité des distributions modernes — est l’ancêtre de tous les autres. La commande ps -ef dresse la liste complète, ps auxf ajoute la consommation CPU/RAM et l’affiche en arborescence. Pour un suivi temps réel, top reste la référence ; htop apporte couleurs et raccourcis confortables (apt install htop) ; btop ajoute des graphiques ASCII pour les écrans larges.

Un processus vit, dort, se réveille, et peut être interrompu via les signaux. kill -SIGTERM PID demande poliment la terminaison ; le programme reçoit le signal et a la possibilité de fermer ses fichiers, vider ses tampons, prévenir ses clients. kill -SIGKILL PID (équivalent à kill -9) ne demande rien — le noyau coupe net. La règle d’or : commencer par SIGTERM, attendre quelques secondes, escalader vers SIGKILL uniquement si le processus refuse de mourir. SIGHUP sert traditionnellement à demander à un démon de relire sa configuration sans redémarrer.

Quand un serveur ralentit, l’observation des ressources passe par uptime (charge moyenne sur 1, 5, 15 minutes), free -h (mémoire libre et utilisée), df -h (disques), et surtout vmstat 1 ou iostat -xz 1 qui rafraîchissent chaque seconde et exposent les goulets d’étranglement réels. Brendan Gregg, longtemps responsable des performances chez Netflix et désormais Intel fellow, auteur du livre de référence Systems Performance, a popularisé dès 2012 la USE method (Utilization, Saturation, Errors) — un cadre toujours pertinent dix ans plus tard pour caractériser une saturation. Le tutoriel pas-à-pas est dans le tutoriel sur les processus et signaux.

Services avec systemd

Sur tout système Linux moderne — Ubuntu, Debian, Alma, Rocky, Fedora, openSUSE, Arch — c’est systemd qui gère le démarrage, l’arrêt et la supervision des services. Né en 2010 chez Red Hat sous l’impulsion de Lennart Poettering, systemd a progressivement remplacé SysV init et upstart. La version 260, publiée en mars 2026, retire d’ailleurs le support des scripts SysV historiques — un signal clair que l’écosystème est aujourd’hui homogène.

L’unité de base s’appelle un unit. Les types les plus courants sont les services (.service), les minuteurs (.timer) qui remplacent cron, les sockets (.socket) qui activent un service à la première connexion, les mounts qui montent automatiquement un système de fichiers, et les targets qui regroupent un état système (l’équivalent des anciens runlevels). La commande pivot est systemctl — systemctl status nginx affiche l’état, systemctl restart nginx redémarre, systemctl enable nginx active au démarrage, systemctl disable nginx désactive. Un service personnalisé se déclare dans /etc/systemd/system/mon-app.service avec une syntaxe INI lisible.

Trois directives valent la peine d’être retenues très tôt. Restart=on-failure relance automatiquement un démon qui plante, ce qui transforme une appli Node fragile en service quasi-résilient. User= et Group= isolent le service sous un compte non privilégié, première ligne de défense contre une compromission. ExecStartPre= permet d’exécuter une vérification (par exemple nginx -t) avant le démarrage effectif. Le tutoriel pas-à-pas, avec création d’un service Node.js complet, est dans le tutoriel systemd dédié.

Couches réseau au quotidien

Le diagnostic réseau est l’une des compétences les plus rentables d’un administrateur. Quand un site renvoie une erreur 502, la cause est rarement le code applicatif : c’est plus souvent un service tombé, un port fermé par le pare-feu, une résolution DNS cassée, ou un certificat TLS expiré. La méthode consiste à descendre couche par couche jusqu’à trouver la rupture.

Sur la couche locale, ip addr liste les interfaces et leurs adresses ; ip route montre la table de routage ; ss -tlnp liste les ports TCP en écoute avec le programme associé (la vieille commande netstat est dépréciée depuis Debian 8 et son remplacement officiel est ss du paquet iproute2). Côté pare-feu, ufw status verbose sur Ubuntu et firewall-cmd --list-all sur Alma donnent l’état effectif des règles.

Sur la couche distante, ping teste la connectivité ICMP, traceroute ou mtr remontent la chaîne de routeurs, dig +short example.com interroge le DNS sans fioritures, curl -v https://exemple.com capture l’échange HTTP complet avec la chaîne TLS. Pour les cas pénibles — paquets perdus, timeout intermittent — tcpdump -i eth0 port 443 capture le trafic brut, à inspecter ensuite dans Wireshark si nécessaire. Le tutoriel pas-à-pas est dans le tutoriel sur le débogage réseau.

SSH : la porte d’entrée

SSH est le protocole de connexion à distance par défaut sur Linux. La version courante est OpenSSH 10.3, publiée le 2 avril 2026. Le client se résume à ssh user@adresse ; le serveur écoute généralement sur le port 22, déclaré dans /etc/ssh/sshd_config. Trois mécanismes authentifient l’utilisateur : mot de passe (à proscrire en production), clé publique (recommandé), certificat SSH (utilisé en environnement d’entreprise pour éviter de gérer des clés à la main).

La pratique de référence consiste à générer une paire de clés Ed25519 — ssh-keygen -t ed25519 -C "votre@email" — puis à pousser la clé publique vers le serveur via ssh-copy-id. Une fois la clé en place, on désactive l’authentification par mot de passe dans sshd_config en posant PasswordAuthentication no et PubkeyAuthentication yes, puis on recharge le service avec systemctl reload ssh (Debian/Ubuntu) ou systemctl reload sshd (Alma/Rocky). Une fois cette bascule effectuée, les scanners automatisés qui frappent en permanence le port 22 reçoivent des refus immédiats et ne peuvent plus tenter de mots de passe au hasard.

Trois fonctionnalités méritent d’être connues très tôt. La config client dans ~/.ssh/config permet de définir des alias (Host prod, HostName 1.2.3.4, User deploy) et de taper simplement ssh prod. Le tunnel ssh -L 5432:localhost:5432 prod redirige un port local vers une base PostgreSQL distante non exposée — outil quotidien pour debug. Enfin ssh-agent mémorise la phrase de passe d’une clé pendant la session, évitant de la retaper à chaque connexion. Le tutoriel pas-à-pas, avec hardening complet du serveur, est dans le tutoriel SSH dédié.

Lire les logs avec journalctl

Avant systemd, les logs étaient des fichiers texte éparpillés dans /var/log. Aujourd’hui le journal système est binaire, indexé, structuré, et s’interroge avec journalctl. La commande journalctl -u nginx -n 50 --no-pager affiche les 50 dernières lignes du service Nginx ; journalctl -u nginx -f suit en direct ; journalctl --since "2026-05-04 14:00" --until "2026-05-04 15:00" filtre par fenêtre temporelle ; journalctl -p err -b ne montre que les erreurs depuis le dernier démarrage.

La grande force de journalctl est la structure. Chaque entrée porte des champs (fields) que l’on peut filtrer : journalctl _SYSTEMD_UNIT=nginx.service _PID=1234 isole le journal d’un PID précis. La sortie JSON (--output=json) s’envoie facilement vers un système d’agrégation comme Loki ou Elasticsearch. Pour les applications qui logguent encore dans des fichiers texte, tail -F /var/log/auth.log reste utile, et logrotate (configuré dans /etc/logrotate.d/) gère la rotation et la compression pour éviter qu’un fichier ne sature le disque.

Sur un serveur sain, le journal doit rester lisible. Si journalctl -p warning -b | head -50 renvoie des centaines de lignes, c’est qu’un service mal configuré pollue ; corrigez la cause, ne masquez pas le symptôme. La taille du journal est plafonnée par SystemMaxUse= dans /etc/systemd/journald.conf, à ajuster sur les petites machines. Le tutoriel pas-à-pas est dans le tutoriel sur la lecture des logs.

Méthode de dépannage

Le bon administrateur ne devine pas. Il observe, hypothèse, teste, conclut. La méthode tient en cinq étapes. Premièrement, isoler le périmètre : le problème touche-t-il un service, une machine, un réseau, un utilisateur ? Une question simple comme « est-ce que ça marche depuis ailleurs ? » élimine la moitié des fausses pistes. Deuxièmement, lire les journaux : journalctl -u service -n 100 --no-pager avant toute autre action — neuf fois sur dix la cause y est inscrite en clair.

Troisièmement, vérifier les ressources : df -h pour le disque, free -h pour la mémoire, top pour le CPU. Un disque à 100 % gèle Postgres, MariaDB, Nginx, à peu près tout. La saturation mémoire déclenche le OOM killer du noyau qui tue le processus le plus gourmand sans préavis — la trace est dans journalctl -k | grep -i "out of memory". Quatrièmement, tester la couche immédiatement en dessous : si Nginx ne sert plus, le port est-il ouvert ? ss -tlnp | grep :443. Le démon est-il vivant ? systemctl status nginx. La configuration parse-t-elle ? nginx -t.

Cinquièmement, documenter au fil de l’eau dans un fichier incidents/2026-05-04-nginx-502.md avec horodatage, hypothèses, commandes lancées, résultats. Cette discipline évite de tourner en rond et constitue, à moyen terme, le meilleur capital opérationnel d’une équipe. Le tutoriel pas-à-pas avec un cas concret est dans le tutoriel sur le dépannage méthodique.

Tutoriels associés

Pour creuser chacun des sujets traités ici, le programme de tutoriels pas-à-pas associés couvre :

• Ligne de commande Linux : tutoriel pas-à-pas — shell, redirections, pipes, historique, complétion
• Permissions Linux : chmod, chown, sudo, ACL — modèle Unix, octal, sticky bit, setuid, ACL POSIX
• Processus Linux : ps, top, htop, kill, signaux — observation, terminaison, OOM killer, USE method
• systemd : créer et superviser un service — unit files, Restart, sandboxing, drop-ins
• SSH : clés, config, tunnels et hardening — Ed25519, sshd_config, tunneling, agent
• journalctl : lire et exploiter les logs — filtres, sortie JSON, retention, journald
• Réseau Linux : ip, ss, dig, curl, tcpdump — diagnostic couche par couche, pare-feu, DNS
• Dépannage Linux méthodique : du symptôme à la cause — méthode en 5 étapes, étude de cas réels

Erreurs fréquentes

FAQ

Faut-il apprendre Bash ou Zsh en 2026 ?
Apprenez Bash — c’est le shell par défaut de la quasi-totalité des serveurs et toutes les ressources de référence (man pages, scripts d’installation officiels, documentations) supposent Bash. Zsh est confortable en station de travail mais n’apporte rien d’essentiel sur un serveur de production.

Quelle distribution choisir pour un premier VPS ?
Ubuntu 24.04 LTS ou 26.04 LTS pour un débutant : la documentation est massive, l’écosystème de paquets immense, la durée de support longue. Debian 13 si vous préférez une base plus stable et minimaliste. Évitez les distributions exotiques tant que vous n’êtes pas à l’aise avec les commandes de base.

Faut-il toujours utiliser sudo ?
Non. Réservez sudo aux opérations qui modifient le système (installation de paquets, édition de /etc, contrôle des services). Le travail courant — édition de scripts, lecture de logs avec accès en lecture, compilation — se fait avec un compte normal. Une session sudo -i permanente expose à des erreurs catastrophiques.

Comment garder un serveur à jour sans casser la production ?
Activez les mises à jour de sécurité automatiques (unattended-upgrades sur Debian/Ubuntu, dnf-automatic sur Alma/Rocky) en n’autorisant que les correctifs de sécurité, pas les montées de version majeures. Les mises à jour majeures (do-release-upgrade, dnf system-upgrade) se font sur fenêtre planifiée, après sauvegarde et sur un environnement de pré-production identique.

Comment se former sans casser mon serveur de production ?
Lancez une machine virtuelle locale (Multipass, libvirt, VirtualBox) ou un VPS dédié à 3-5 € par mois (Hetzner, Scaleway, OVH) que vous traitez comme jetable. Toutes les commandes destructrices se testent là d’abord. Snapshots et instantanés permettent de revenir en arrière en quelques secondes.

Quels livres lire sur le même thème ?
The Linux Command Line de William Shotts (LinuxCommand.org, gratuit en PDF) couvre la ligne de commande à fond. How Linux Works de Brian Ward (No Starch Press) explique l’intérieur du système. Systems Performance de Brendan Gregg (2e édition 2020) est la référence sur l’observation et l’optimisation.

Les commandes vues ici fonctionnent-elles dans WSL ?
Oui pour la grande majorité — WSL 2 exécute un vrai noyau Linux et la plupart des commandes apt, ls, grep, journalctl, systemctl (depuis WSL 2 avec systemd activé) se comportent comme sur un serveur. Quelques outils bas-niveau qui touchent au matériel (iotop, certaines options de ip) ont un comportement dégradé sous WSL.

Ressources et références

• Filesystem Hierarchy Standard 3.0 — refspecs.linuxfoundation.org/fhs.shtml
• Documentation Ubuntu Server — documentation.ubuntu.com/server/
• Documentation Debian — debian.org/doc
• systemd — pages de manuel et journal de versions sur systemd.io
• OpenSSH — notes de version openssh.org/releasenotes.html
• Brendan Gregg — méthodes de performance brendangregg.com/usemethod.html
• The Linux Command Line, William Shotts — linuxcommand.org/tlcl.php
• Pages de manuel en ligne — man7.org/linux/man-pages/
• tldr pages, exemples concis — tldr.sh

Mots-clés associés : linux fondamentaux, apprendre linux serveur, ligne de commande linux, systemd services, journalctl, ssh hardening, dépannage linux.