Passer au terminal Unix reste un passage obligé pour quiconque veut faire plus que cliquer sur des boutons. Ce n’est pas un trip de puriste nostalgique, c’est juste l’outil le plus direct pour piloter un serveur, un conteneur, un poste de dev ou un homelab. Une poignée de commandes bien maîtrisées suffit déjà à naviguer dans un répertoire, éditer un fichier, diagnostiquer un plantage ou automatiser une tâche répétitive. Le plus gros frein n’est pas la technique, mais la peur de « casser quelque chose ». Pourtant, avec quelques réflexes de base et un peu de méthode, le shell devient très vite un allié plutôt qu’un monstre opaque.
Ce texte s’adresse à celles et ceux qui commencent à travailler sur Linux, BSD ou macOS côté Unix, que ce soit en formation, en reconversion ou parce qu’un collègue leur a balancé un accès SSH sans plus d’explication. L’objectif est simple : donner un socle solide sur les notions de ligne de commande, montrer comment lire une syntaxe, sécuriser les premières manipulations, et pointer les pièges qui font perdre du temps ou des données. Pour rendre tout ça concret, on suivra un personnage récurrent, Léo, admin débutant qui doit reprendre un petit serveur de fichiers et une machine de test. Ses galères sont très proches de ce que rencontrent la majorité des juniors en production.
En bref
- Comprendre le trio terminal / shell / bash pour enfin savoir ce que l’on ouvre quand on lance une console et qui exécute vraiment les commandes.
- Lire et écrire la syntaxe d’une commande Unix (options, arguments, aide intégrée) afin de sortir du copier-coller aveugle.
- Maîtriser les commandes de navigation et de fichiers (pwd, cd, ls, cp, mv, rm, mkdir…) sans se faire surprendre par une suppression irréversible.
- Gérer les permissions et sudo pour éviter à la fois les blocages « permission denied » et les erreurs faites en root.
- Utiliser grep, tail, head et compagnie pour lire efficacement logs et sorties de scripts, sans scroller comme sur un tableur.
- Découvrir les bons réflexes de productivité (history, alias, autocomplétion) qui transforment un terminal hostile en outil quotidien agréable.
Comprendre le terminal Unix, le shell et bash avant de lancer sa première commande
La première confusion chez les débutants vient souvent des mots. On parle de terminal, de shell, de bash, parfois de console, comme si tout désignait la même chose. En réalité, ce sont des couches différentes. Le terminal est l’interface visuelle : la fenêtre noire (ou blanche) qui affiche du texte et dans laquelle on tape. Le shell est le programme qui interprète ce texte et décide quoi exécuter. bash, zsh, fish ne sont que des variantes de ce shell, chacune avec ses petites particularités, mais toutes comprennent les bases Unix décrites ici.
Sur un poste Linux classique, ouvrir « Terminal » lance généralement bash ou zsh. Sur un serveur distant, on passe par SSH depuis un autre terminal, mais le principe reste le même : un programme shell lit la ligne que vous tapez, découpe la commande, les options, les arguments, et appelle les binaires correspondants. Comprendre ça évite beaucoup de mystique : une commande Linux n’est rien d’autre qu’un programme avec des paramètres, exactement comme un exécutable lancé via une icône, sauf que tout se passe en texte.
La forme générale ressemble à ceci : nom_commande [options] [arguments]. Si Léo tape ls -l /var/log, le shell appelle le programme ls, lui passe l’option -l (affichage détaillé) et l’argument /var/log (le répertoire à lister). Cette règle reste valable pour la quasi-totalité des outils Unix, du plus simple au plus avancé. Un réflexe très rentable consiste à tester systématiquement nom_commande –help pour afficher un résumé des options principales, ou man nom_commande pour lire la documentation plus complète directement dans le terminal.
L’autre notion clé est la sensibilité à la casse. Sous Unix, Fichier.txt, fichier.txt et FICHIER.TXT sont trois noms différents. C’est souvent la cause d’un « no such file or directory » incompréhensible pour quelqu’un qui vient de Windows. Léo l’a appris le jour où il a passé dix minutes à chercher pourquoi son script ne trouvait jamais « Backup.sh » alors que le fichier s’appelait en réalité « backup.sh ». Réfléchir au nom exact, et non à une variation approximative, fait partie du quotidien en ligne de commande.
Dernier point de base avant d’attaquer les cas concrets : le répertoire courant. À tout moment, le shell se trouve dans un dossier précis, et toutes les commandes relatives (sans chemin absolu) s’y rapportent. La commande pwd affiche ce chemin complet. Léo a pris l’habitude de la lancer régulièrement, surtout avant une suppression ou un déplacement, pour vérifier qu’il est bien au bon endroit. C’est une habitude simple, mais elle évite des erreurs coûteuses.
Lire rapidement l’aide des commandes Unix essentielles
Pour ne pas rester dépendant d’un tuto à chaque nouvelle commande, il faut apprendre à exploiter l’aide intégrée. Deux briques suffisent : –help et la commande man. Par exemple, ls –help affiche un condensé : options disponibles, exemples d’usage, comportement par défaut. C’est souvent suffisant pour comprendre comment l’adapter à un besoin précis. Léo s’en sert par réflexe dès qu’il voit une commande inconnue dans un script ou une documentation.
Pour aller plus loin, man ls ouvre la page de manuel dans un afficheur paginé. Les touches sont simples : flèches ou Entrée pour défiler, /mot pour chercher un terme, q pour quitter. Comprendre ces quelques commandes permet de décoder en autonomie la quasi-totalité des outils livrés avec un système Unix. On retrouve par exemple, dans man grep, toutes les options de recherche avancées très utilisées sur les logs.
Pour gagner du temps, certains admins regroupent les commandes les plus utiles dans un aide-mémoire ou un tableau. Voici un résumé de base, que Léo garde sous la main sur son premier projet :
| Commande | Usage principal | Exemple concret |
|---|---|---|
| pwd | Afficher le répertoire courant | Vérifier l’emplacement avant un rm |
| cd | Changer de répertoire | cd /var/log pour rejoindre les journaux |
| ls | Lister fichiers et dossiers | ls -la pour voir y compris les fichiers cachés |
| cp | Copier fichiers ou répertoires | cp config.cfg config.cfg.bak avant modif |
| mv | Déplacer ou renommer | mv script.sh /usr/local/bin/ |
| rm | Supprimer fichiers ou dossiers | rm -ri data/ pour une suppression guidée |
C’est souvent par ce genre de repères très concrets qu’un débutant se met rapidement à l’aise, avant même de connaître des dizaines d’options obscures. L’essentiel est de comprendre ce que l’on tape, pas de tout retenir par cœur.
Navigation dans l’arborescence Unix et manipulation de fichiers sans casse
Une fois le vocabulaire clarifié, la première vraie compétence à travailler consiste à se déplacer dans l’arborescence, créer des dossiers et manipuler un fichier sans peur. Sous Unix, tout repose sur des chemins. Le caractère / sert de séparateur et la racine du système s’appelle simplement /. Le chemin /home/leo/projets indique donc le dossier « projets », contenu dans « leo », lui-même sous « home », le tout partant de la racine.
Les commandes clefs sont assez peu nombreuses. pwd pour afficher l’emplacement actuel, cd pour se déplacer, ls pour lister le contenu. Léo a très vite adopté quelques variantes : cd .. pour remonter d’un niveau, cd – pour revenir au dossier précédent (pratique quand on navigue beaucoup entre deux chemins), et ls -lh pour voir à la fois les droits, la taille lisible et la date de modification.
Viennent ensuite la création et suppression de répertoires. mkdir logs crée un dossier « logs » dans le répertoire courant, mkdir -p /srv/app/data/archive crée toute une arborescence en une fois. Pour supprimer, rmdir fonctionne sur les dossiers vides. Dès que du contenu se trouve à l’intérieur, il faut combiner rm avec l’option récursive. C’est là que la prudence devient obligatoire.
L’erreur classique consiste à balancer un rm -rf * au mauvais endroit. Contrairement à une corbeille graphique, ici la suppression est immédiate. Sur un serveur, cela peut signifier des heures de restauration de sauvegarde, quand elles existent. Deux antidotes simples : préférer rm -ri au départ (confirmation interactive par élément) et vérifier systématiquement pwd avant toute suppression récursive. Léo a vécu une frayeur avec un rm -rf tmp lancé depuis le mauvais répertoire, heureusement sur une machine de test.
La copie et le déplacement suivent une logique comparable. cp fichier1 fichier2 duplique un fichier, cp -R dossier1 dossier2 clone un répertoire complet. Pour renommer ou déplacer, on utilise mv. Le réflexe sain consiste à créer une sauvegarde avant toute modification risquée : cp /etc/app.conf /etc/app.conf.bak. Cette copie prend quelques millisecondes mais sauve souvent une mise en production.
Lire et éditer des fichiers texte directement depuis le terminal
Dans un environnement Unix, la configuration passe presque toujours par des fichiers texte. Savoir les lire et les modifier sans sortir du terminal fait gagner un temps énorme. Trois commandes couvrent l’essentiel : cat, less et un éditeur comme nano ou vi. cat fichier.log affiche le contenu complet, ce qui convient pour les petits fichiers. Dès que la taille explose, less prend le relais : less /var/log/syslog permet de défiler, chercher un mot avec / et quitter avec q.
Pour éditer, nano reste souvent le plus accessible au début. Une simple commande nano /etc/monapp.conf ouvre le fichier, les commandes principales sont affichées en bas de l’écran (en anglais, mais vite mémorisables) : Ctrl+O pour enregistrer, Ctrl+X pour quitter. vi ou vim sont bien plus puissants, mais plus abrupts. Le choix importe peu au départ, le vrai enjeu est de prendre l’habitude d’éditer la configuration localement, faire une sauvegarde, puis relancer le service plutôt que de bricoler à distance via un éditeur graphique hasardeux.
Pour surveiller des fichiers qui bougent en temps réel, comme des logs d’application, la commande tail -f est un outil que tout admin finit par utiliser plusieurs fois par jour. Elle suit la fin du fichier en direct. Léo, par exemple, laisse tourner un tail -f /var/log/nginx/access.log dans un coin lorsqu’il teste une nouvelle configuration web. Pour aller plus loin sur ces usages, un tutoriel détaillé comme celui consacré à tailf et la surveillance en continu sous Linux donne des exemples concrets très parlants.
Dans ce volet manipulation et édition, un mot d’ordre se dégage : penser sauvegarde minimale avant chaque action destructive. Une simple duplication en .bak et un coup d’œil aux dernières lignes avec tail ou head permettent d’expérimenter sans angoisse permanente. C’est cette sécurité mentale qui permet ensuite de progresser vite.
Permissions Unix, sudo et gestion des utilisateurs sans se tirer une balle dans le pied
Vient ensuite l’un des sujets qui effraie le plus les débutants : la permission d’accès. Sous Unix, chaque fichier et chaque répertoire possède un propriétaire, un groupe, et un ensemble de droits pour trois catégories : propriétaire, groupe, autres. La sortie de ls -l l’affiche dans la première colonne, sous une forme comme -rwxr-x—. Les trois lettres se lisent par triplets : lecture (r), écriture (w), exécution (x).
Concrètement, un script shell marqué -rwxr-xr-x sera exécutable par tous, tandis qu’un -rw——- ne sera lisible et modifiable que par son propriétaire. Léo a compris la logique le jour où il a tenté de lancer un script fraichement créé sans lui donner le droit d’exécution : « permission denied » jusqu’à ce qu’il ajoute un chmod +x monscript.sh. Ce simple ajout bascule un fichier texte vers un programme exécutable par le système, dès lors qu’il se trouve dans un chemin accessible.
La commande chmod sert à ajuster ces droits. Elle peut travailler en mode symbolique (chmod u+x script.sh pour ajouter l’exécution à l’utilisateur, chmod g-w fichier pour retirer l’écriture au groupe) ou en mode numérique (comme chmod 640). Pour un débutant, le mode symbolique reste plus lisible. Le point important est de comprendre l’intention : qui doit pouvoir lire, qui doit pouvoir modifier, qui doit pouvoir exécuter. Donner des droits trop larges « pour que ça marche » finit souvent par poser des problèmes de sécurité.
La propriété des fichiers se gère avec chown. Par exemple, si une application tourne sous l’utilisateur « webapp », ses fichiers de configuration gagneront à lui appartenir plutôt qu’à root. Un chown webapp:webapp /etc/webapp.conf remet alors les choses au clair. Léo a découvert ce sujet quand un service refusait de démarrer car le compte système n’avait pas accès à son propre dossier de logs, resté propriété de root après une copie.
Au-dessus de ces mécanismes locaux, sudo et su gèrent le changement de contexte utilisateur. sudo, abrégé de « superuser do », permet à un utilisateur autorisé d’exécuter une commande avec les privilèges d’un autre, souvent root. Un sudo apt install ou sudo systemctl restart nginx ajoutent juste la dose de pouvoir nécessaire, le temps de cette commande. Le mot de passe demandé n’est pas celui de root, mais celui du compte courant, ce qui laisse une trace dans les logs et renforce le contrôle.
su, lui, ouvre une session complète sous un autre utilisateur. su – sans argument bascule purement et simplement en root, environnement inclus. Léo évite autant que possible de rester longtemps dans ce mode, car la moindre erreur de frappe peut devenir catastrophique. Une bonne pratique consiste à rester sous son compte, n’utiliser que sudo ponctuellement, et configurer le fichier sudoers avec parcimonie. Donner un accès sudo total à tout le monde est une fausse bonne idée dans une PME.
Créer, modifier et supprimer des comptes en restant propre
Dès qu’un serveur commence à être utilisé par plusieurs personnes, la gestion des comptes n’est plus facultative. Les commandes useradd, passwd et userdel constituent la base. useradd alice crée un nouveau compte « alice », passwd alice permet de définir son mot de passe, userdel alice supprime le compte une fois qu’elle a quitté l’équipe. Sur des distributions Debian ou Ubuntu, la commande adduser propose un assistant un peu plus convivial, avec création du répertoire personnel et questions interactives.
La vraie question n’est pas tant la syntaxe que la politique. Les comptes partagés du type « dev » ou « support » posent tôt ou tard des soucis de traçabilité. Léo a vu un petit service IT passer une journée à chercher qui avait effacé un répertoire de sauvegarde, chacun jurant ne pas avoir lancé la moindre commande dangereuse. Avec des comptes individuels et sudo configuré proprement, ce genre d’enquête devient beaucoup plus simple, car chaque action privilégiée laisse une entrée identifiée dans les logs.
Pour gérer des services, la solution propre reste l’usage d’utilisateurs systèmes dédiés, sans accès interactif. La création se fait avec des options spécifiques à useradd, mais la philosophie reste la même : cloisonner les droits, limiter l’impact d’un éventuel piratage, et éviter que tout le monde joue en permanence avec les clés de root. Comprendre cette logique dès les premiers pas évite les architectures « tout le monde est admin » qui vieillissent très mal.
En résumé, les permissions Unix peuvent paraître austères, mais elles suivent un modèle très cohérent. Une fois lue la sortie de ls -l et comprise la signification de quelques chmod et chown, on cesse de bricoler « jusqu’à ce que ça marche » pour enfin appliquer une politique claire. C’est un tournant important dans la progression sur système Unix.
Analyser des fichiers texte et des logs avec grep, head, tail et compagnie
Dès que l’on gère une application un peu sérieuse, la difficulté n’est plus de trouver un fichier, mais d’en extraire l’information utile. C’est là que l’écosystème Unix montre sa force : des petites commandes conçues pour faire une chose, mais la faire bien, que l’on compose entre elles. Pour qui administre un serveur web, une base de données ou un service métier, apprendre à filtrer des logs via grep ou à surveiller les erreurs avec tail devient plus rentable que n’importe quelle interface graphique tape-à-l’œil.
La commande grep sert à rechercher des lignes contenant un motif donné. Sa forme la plus simple ressemble à grep « ERROR » /var/log/app.log. Toutes les lignes qui contiennent le mot « ERROR » s’affichent. Pour Léo, cela a été la clé pour diagnostiquer des erreurs 500 sur une appli PHP : un coup de grep « PHP Fatal » /var/log/apache2/error.log et les causes apparaissaient clairement. Avec l’option -i, grep ignore la casse ; avec -r, il recherche dans un répertoire entier.
Les commandes head et tail permettent de consulter rapidement le début ou la fin d’un fichier. head -n 20 fichier.log affiche les 20 premières lignes, tail -n 50 fichier.log les 50 dernières. Combiné avec l’option -f, tail devient un outil de suivi en temps réel. Léo l’utilise par exemple pendant un déploiement : tail -f /var/log/app/app.log | grep -i error lui montre immédiatement toute erreur qui apparaît pendant que les utilisateurs testent la nouvelle version.
Une vraie différence se voit ici avec les approches « tout GUI ». Là où un outil graphique va charger plusieurs mégaoctets de log, obliger à scroller et à chercher manuellement, deux commandes en ligne de commande bien chaînées isolent exactement ce qui est pertinent. Un exemple classique dans les équipes Ops consiste à rechercher les accès suspects dans des logs web : grep -i « /wp-admin » access.log | awk ‘{print $1}’ | sort | uniq -c | sort -nr. Même sans tout maîtriser au départ, on voit l’idée : filtrer, extraire une colonne, compter, trier.
À ce stade, des commandes comme awk, sed ou cut commencent à devenir utiles. awk permet de manipuler des colonnes dans un fichier structuré, sed de faire des remplacements à la volée, cut d’extraire certains champs. Léo, par exemple, s’en est servi pour analyser un fichier CSV trop gros pour Excel, en sortant les lignes où une valeur dépassait un seuil puis en comptant le nombre de cas. Tout cela sans quitter le shell, et sans saturer sa machine avec un tableur peu optimisé.
Surveiller un service en continu sans outils exotiques
Pour le suivi en temps réel, beaucoup d’équipes s’appuient sur des solutions de monitoring complètes. Mais au quotidien, lors d’un debug rapide, un simple cocktail de commandes suffisamment bien pensé fait le travail. Léo a mis en place une petite routine pour surveiller son serveur d’application : une fenêtre avec htop pour la charge CPU et mémoire, une autre avec tail -f sur les logs d’erreur, et parfois une troisième avec des ping ou du curl vers des endpoints HTTP de santé.
Des commandes comme watch viennent compléter le tableau. watch -n 5 « df -h /srv » affiche toutes les cinq secondes l’espace disque d’une partition, ce qui permet de repérer une croissance anormale. watch -n 2 « systemctl status monservice | head -n 20 » donne une vue mise à jour sur l’état d’un service, sans avoir à relancer la commande. Là encore, rien de spectaculaire, mais une efficacité redoutable lorsqu’on sait exactement quoi surveiller.
Pour approfondir ces usages orientés supervision, les ressources spécialisées comme le guide sur la surveillance continue avec tailf sous Linux montrent comment adapter ces briques à différents scénarios : suivi d’un cron qui tourne mal, contrôle d’un script de sauvegarde, monitoring ponctuel d’un import de données massif. La logique reste toujours la même : lire un flux texte, l’analyser avec deux ou trois commandes Unix, garder ce qui compte.
Avec ces quelques outils, la perception du terminal change. On ne se contente plus d’obéir à des recettes trouvées sur un forum, on commence à dialoguer avec le système, à poser des questions précises, et à obtenir des réponses exploitables. C’est souvent là que beaucoup de techniciens se découvrent un goût durable pour le monde Unix.
Productivité en shell : history, alias, autocomplétion et premiers scripts bash
Une fois à l’aise avec la navigation, les fichiers et les logs, une nouvelle frustration apparaît : taper encore et encore les mêmes commandes. C’est le bon moment pour apprendre à se servir des fonctionnalités de productivité présentes dans tous les shells modernes. D’abord, l’historique. La commande history affiche la liste des commandes récentes, chaque ligne numérotée. Rejouer une ligne se fait simplement avec !numéro. Pour Léo, rejouer une requête complexe de grep ou un long rsync sans tout retaper est devenu un réflexe clé.
Les raccourcis clavier jouent aussi un rôle énorme. Tab sert à l’autocomplétion : on tape quelques lettres d’un nom de fichier ou d’une commande, on appuie sur Tab, le shell complète si l’ambiguïté est levée. Ctrl+C interrompt l’exécution d’une commande qui se bloque, Ctrl+R lance une recherche dans l’historique en écrivant une portion de la commande désirée. Ces petites astuces transforment concrètement la sensation de vitesse au quotidien.
Les alias permettent ensuite de donner un nom court à une commande plus longue. Par exemple, Léo s’est créé alias ll=’ls -lh’ et alias gs=’git status’. Depuis, il ne tape presque jamais les variantes complètes. Un alias ne dure normalement que le temps de la session, mais on peut les rendre permanents en les ajoutant dans le fichier de configuration du shell (par exemple ~/.bashrc pour bash). Pour revenir en arrière, un simple unalias ll efface la définition.
À ce stade, le pas suivant naturel consiste à regrouper plusieurs commandes dans un script bash. Il suffit de créer un fichier texte commençant par une ligne #!/bin/bash, d’y écrire des commandes comme on le ferait dans le terminal, puis de rendre le fichier exécutable avec chmod +x. Léo a par exemple créé un petit script deploy.sh qui enchaîne arrêt du service, copie de la nouvelle version, exécution des migrations et relance. Au lieu de répéter, risque d’oubli à chaque déploiement, il exécute un seul fichier bien testé.
Les scripts gagnent encore en puissance dès qu’on y ajoute des paramètres ($1, $2, etc.), des conditions if, des boucles for. À ce moment-là, on dépasse le simple statut d’« utilisateur du terminal » pour entrer dans l’automatisation. Beaucoup de tâches manuelles, du nettoyage de vieux logs à la génération de rapports, deviennent candidates à un script simple qui économise plusieurs heures par mois. C’est cette logique qui amène, plus tard, vers des langages comme Python ou des outils comme Ansible, mais le premier pas se joue clairement dans le shell.
Pour alimenter ces scripts, la commande echo joue souvent un rôle de test. On l’utilise pour afficher la valeur d’une variable, renseigner l’utilisateur (« Déploiement terminé »), ou construire rapidement un fichier de configuration. L’enchaînement echo « clé=valeur » >> config.env ajoute par exemple une ligne à un fichier existant. À petite dose, c’est un outil de mise au point très pratique, notamment pour ceux qui découvrent la logique des variables d’environnement.
L’expérience montre que la productivité en shell ne dépend pas d’une liste infinie de commandes exotiques, mais surtout de la capacité à combiner quelques briques simples : historique, alias, autocomplétion, scripts courts bien pensés. C’est ce qui différencie un débutant stressé à chaque ligne saisie d’un technicien qui pilote sereinement son environnement depuis son terminal.
Quelles sont les premières commandes Unix à apprendre pour débuter en terminal ?
Pour un démarrage solide, concentrez-vous sur quelques briques : pwd pour connaître votre répertoire courant, cd pour vous déplacer, ls pour lister les fichiers, cp et mv pour copier/déplacer, rm pour supprimer, mkdir et rmdir pour gérer les dossiers. Ajoutez rapidement cat, less, nano ou vi pour lire et modifier des fichiers, ainsi que grep, head et tail pour explorer les logs. Avec ce petit socle, la majorité des tâches simples en ligne de commande devient accessible.
Comment éviter de supprimer des fichiers importants avec rm sous Unix ?
Trois réflexes réduisent drastiquement le risque : vérifier systématiquement l’emplacement avec pwd avant une suppression, préférer rm -ri au début pour avoir une confirmation interactive, et créer des sauvegardes rapides avec cp fichier fichier.bak avant toute opération risquée. Évitez d’utiliser rm -rf à la racine d’un projet sans être certain de votre chemin, et bannissez les copier-coller hasardeux récupérés sur Internet sans les relire.
Quelle est la différence entre sudo et su en environnement Unix ?
sudo permet d’exécuter ponctuellement une commande avec des droits élevés, en général ceux de root, tout en restant sous votre compte habituel. su bascule complètement dans un autre compte pour la durée de la session, souvent root si aucun nom n’est donné. Pour la sécurité et la traçabilité, sudo reste préférable dans la plupart des contextes, car chaque action privilégiée est journalisée et rattachée à un utilisateur précis.
À quoi sert grep dans les logs et fichiers texte ?
grep recherche des lignes contenant un motif donné dans un ou plusieurs fichiers. C’est l’outil de base pour filtrer des logs ou des sorties de commandes. Par exemple, grep
Comment progresser rapidement en bash sans se perdre dans la théorie ?
La méthode la plus efficace reste la pratique guidée par les besoins réels. Utilisez le terminal pour vos tâches quotidiennes, même simples, exploitez systématiquement –help et man pour comprendre les commandes, puis commencez à écrire de petits scripts pour automatiser ce que vous répétez souvent. En parallèle, gardez sous la main un aide-mémoire et quelques ressources ciblées, par exemple des tutoriels spécialisés sur la supervision des logs ou l’écriture de scripts bash, afin d’ancrer progressivement les bons réflexes.
