Système de fichiers

Le rôle du système d’exploitation

Quand tu enregistres un fichier, tu ne décides pas où il est stocké physiquement sur le disque. C’est le système d’exploitation (OS) qui s’en charge. Il joue le rôle d’intermédiaire entre toi (ou tes programmes) et le matériel.

Concrètement, l’OS gère trois responsabilités liées aux fichiers :

L’organisation. L’OS maintient une arborescence de dossiers et de fichiers. Quand tu tapes ls ou que tu ouvres l’explorateur de fichiers, c’est l’OS qui te présente cette structure — le disque dur, lui, ne connaît que des blocs de données numérotés.

L’accès. L’OS contrôle qui a le droit de lire, modifier ou exécuter chaque fichier. Sans ce contrôle, n’importe quel programme pourrait modifier n’importe quel fichier du système.

Le stockage. L’OS décide comment les données sont réparties sur le disque, gère l’espace libre, et s’assure qu’un fichier supprimé libère bien son espace. Un fichier de 50 Mo peut être dispersé en dizaines de fragments sur le disque — l’OS te le présente comme un tout cohérent.

Analogie

L’OS est comme un bibliothécaire. Tu demandes un livre par son titre et son emplacement dans le catalogue (le chemin du fichier). Le bibliothécaire sait exactement sur quelle étagère, dans quelle rangée le livre se trouve physiquement. Tu n’as pas besoin de le savoir.

Les systèmes de fichiers

Pour organiser les données sur un disque, l’OS utilise un système de fichiers (filesystem). C’est le format qui définit comment les fichiers, les dossiers, les permissions et les métadonnées sont structurés sur le support de stockage.

Chaque OS a ses préférences :

Système de fichiers	OS principal	Caractéristiques
ext4	Linux	Le standard Linux actuel. Gère les permissions Unix, les liens symboliques, et supporte des fichiers très volumineux.
NTFS	Windows	Le standard Windows. Gère les permissions Windows (ACL), le chiffrement et la compression.
APFS	macOS	Le standard Apple moderne. Optimisé pour les disques SSD, avec snapshots et clonage rapide de fichiers.
FAT32	Universel	Ancien mais compatible partout. Limité à 4 Go par fichier. Utilisé sur les clés USB.
exFAT	Universel	Successeur de FAT32 sans la limite de 4 Go. Courant sur les cartes SD et disques externes.

Pourquoi c'est pertinent ?

Si tu as déjà eu un message d’erreur en copiant un gros fichier sur une clé USB, c’est probablement parce que la clé était formatée en FAT32 (limite de 4 Go par fichier). Le système de fichiers n’est pas qu’un détail technique — il détermine ce que tu peux faire avec tes fichiers.

En développement web, tu travailleras presque toujours sur ext4 (serveurs Linux) ou APFS/NTFS (ta machine locale). La différence la plus visible au quotidien : Linux distingue les majuscules et les minuscules dans les noms de fichiers (Style.css et style.css sont deux fichiers différents), alors que Windows et macOS ne les distinguent pas par défaut.

Piège classique en dev web

Tu crées composants/Header.jsx sur ton Mac, tu importes ./composants/header.jsx dans ton code. Ça fonctionne localement (macOS ignore la casse). Tu déploies sur un serveur Linux : erreur 404 — le fichier header.jsx n’existe pas, seul Header.jsx existe. Ce genre de bug est courant et frustrant.

---

Anatomie d’un fichier

Sous Linux, un fichier n’est pas juste son contenu. L’OS conserve un ensemble de métadonnées — des informations sur le fichier — qui permettent de l’identifier, de le protéger et de le gérer.

Le nom

Le nom d’un fichier sous Linux peut contenir presque n’importe quel caractère, mais en pratique on suit des conventions :

• Pas d’espaces. On utilise des tirets (mon-fichier.txt) ou des tirets bas (mon_fichier.txt).
• Pas de caractères spéciaux. Éviter & * ? ! @ # $ et les accents dans les noms de fichiers — ils compliquent les commandes et causent des problèmes de portabilité.
• La casse compte. index.html, Index.html et INDEX.HTML sont trois fichiers différents sous Linux.
• L’extension n’est pas magique. Sous Linux, l’extension (.html, .css, .js) est une convention pour les humains. Le système ne s’en sert pas pour déterminer le type du fichier — contrairement à Windows qui associe les extensions à des programmes.

Convention en dev web

Dans un projet web, on nomme presque toujours les fichiers en minuscules avec des tirets : mon-composant.jsx, reset-styles.css, api-utils.js. C’est la convention la plus portable entre les systèmes.

L’emplacement

Chaque fichier a un emplacement unique dans l’arborescence, exprimé par son chemin absolu :

/home/labex/projet-web/css/style.css

Ce chemin se décompose ainsi :

Segment	Rôle
/	La racine du système
home/	Dossier contenant les dossiers personnels
labex/	Ton dossier personnel
projet-web/	Un dossier de projet
css/	Un sous-dossier
style.css	Le fichier

Deux fichiers peuvent avoir le même nom s’ils sont dans des dossiers différents. C’est le chemin complet qui les distingue.

Le type

La commande ls -l affiche un caractère au tout début de chaque ligne qui indique le type :

Caractère	Type	Description
-	Fichier ordinaire	Un fichier contenant des données (texte, image, code…)
d	Dossier (directory)	Un conteneur pour d’autres fichiers et dossiers
l	Lien symbolique	Un raccourci vers un autre fichier ou dossier

Il existe d’autres types (fichiers spéciaux, sockets, etc.), mais ces trois sont ceux que tu rencontreras au quotidien.

La taille

La taille d’un fichier est exprimée en octets. Pour la rendre lisible, on peut utiliser :

ls -lh

L’option -h (human-readable) convertit les tailles en Ko, Mo, Go :

-rw-r--r-- 1 labex labex  2.4K  mars 22 10:30 style.css
-rw-r--r-- 1 labex labex  1.1M  mars 22 10:31 image.png

Les dates

Linux enregistre trois dates pour chaque fichier :

Date	Signification	Affichée par
Modification (mtime)	Dernière modification du contenu	ls -l (par défaut)
Accès (atime)	Dernière lecture du fichier	ls -lu
Changement (ctime)	Dernier changement des métadonnées (permissions, nom…)	ls -lc

En pratique, c’est la date de modification qui t’intéresse le plus souvent.

---

Dossiers et inodes

Dans Linux, un dossier est lui-même un type particulier de fichier. Pour le système de fichiers, il n’existe pas de séparation fondamentale entre « fichier » et « dossier » : ce sont des objets ayant des rôles différents dans l’organisation des données.

En interne, le système associe chaque fichier et chaque dossier à une structure appelée inode. L’inode contient toutes les métadonnées d’une ressource : type, taille, permissions, dates, emplacement sur le disque. Le nom du fichier, lui, n’est pas dans l’inode — il est stocké dans le dossier parent.

Un dossier est donc essentiellement un fichier spécial qui contient une liste de noms associés à des inodes.

Le compteur de liens dans ls -l

Le chiffre après les permissions dans ls -l est le nombre de liens qui pointent vers le même inode :

drwxr-xr-x 2 labex labex 4096 mars 22 08:00 css

Un dossier vide affiche 2 parce que deux noms pointent vers son inode : son propre nom (css) et l’entrée . à l’intérieur du dossier (qui signifie « moi-même »). Chaque sous-dossier ajouté augmente ce compteur de 1, à cause de l’entrée .. du sous-dossier qui pointe vers le parent.

---

Lire la sortie de ls -l

Quand tu tapes ls -l, chaque ligne affiche une quantité dense d’information. Voici comment la décoder.

Exemple

ls -l

drwxr-xr-x 2 labex labex 4096 mars 22 08:00 css
-rw-r--r-- 1 labex labex  245 mars 22 10:30 index.html
lrwxrwxrwx 1 labex labex    9 mars 22 11:00 styles -> css/style.css

Décomposition

Prenons la deuxième ligne :

-rw-r--r-- 1 labex labex 245 mars 22 10:30 index.html

Segment	Valeur	Signification
Type	-	Fichier ordinaire
Permissions propriétaire	rw-	Lecture + écriture
Permissions groupe	r--	Lecture seule
Permissions autres	r--	Lecture seule
Nombre de liens	1	Un seul lien pointe vers l’inode de ce fichier
Propriétaire	labex	L’utilisateur qui possède le fichier
Groupe	labex	Le groupe associé au fichier
Taille	245	245 octets
Date	mars 22 10:30	Dernière modification
Nom	index.html	Le nom du fichier

---

Les fichiers cachés

Sous Linux, tout fichier ou dossier dont le nom commence par un point (.) est caché. Il n’apparaît pas avec ls, seulement avec ls -a.

ls -a

.  ..  .git  .env  .gitignore  index.html  css/

Les fichiers cachés courants en développement web :

Fichier	Rôle
.git/	Dossier de versionnement Git
.gitignore	Liste des fichiers à exclure de Git
.env	Variables d’environnement (clés API, mots de passe)
.vscode/	Configuration de l’éditeur VS Code
.prettierrc	Configuration du formateur de code
.eslintrc	Configuration du linter JavaScript
node_modules/	(Pas caché mais souvent dans .gitignore)

Pourquoi cacher ces fichiers ?

Ce sont des fichiers de configuration ou d’outillage. Les cacher évite de polluer la vue quand on travaille sur le contenu du projet. Ils restent accessibles — ils ne sont pas protégés, juste masqués visuellement.

---

Naviguer dans l’arborescence

L’arborescence Linux peut contenir des milliers de dossiers. Au quotidien, tu te déplaces dans cette structure avec quelques commandes de base.

Se repérer et se déplacer

pwd                  # où suis-je ?
cd dossier           # entrer dans un dossier
cd ..                # remonter d'un niveau
cd ~                 # retourner au dossier personnel
cd /                 # aller à la racine

Deux façons de décrire un emplacement :

	Chemin relatif	Chemin absolu
Point de départ	Le dossier courant	La racine /
Exemple	cd ../js	cd /home/labex/projet/js
Avantage	Court à écrire	Fonctionne de n’importe où

En pratique, on utilise les chemins relatifs pour les déplacements courts (« le dossier juste à côté ») et les chemins absolus quand on doit accéder à un emplacement précis sans ambiguïté.

Le problème des chemins longs

Dans un projet réel, les chemins peuvent devenir longs et répétitifs :

cd /var/www/mon-application/shared/assets/images
cd /home/labex/projets/client-xyz/frontend/src/components

Taper ces chemins régulièrement est fastidieux et source d’erreurs. C’est ici que les liens symboliques deviennent utiles.

Raccourcir un chemin avec un lien symbolique

Un lien symbolique (symlink) est un fichier spécial qui pointe vers un autre fichier ou dossier. C’est un raccourci intégré au système de fichiers — les programmes qui ouvrent le lien accèdent directement à la cible.

ln -s cible nom-du-lien

Par exemple, au lieu de taper le chemin complet à chaque fois :

# Créer un raccourci vers un dossier profondément imbriqué
ln -s /var/www/mon-application/shared/assets/images ~/images-app

# Maintenant, pour y accéder :
cd ~/images-app

Avec ls -l, un lien symbolique est identifiable par le l au début et la flèche -> :

lrwxrwxrwx 1 labex labex 45 mars 22 11:00 images-app -> /var/www/mon-application/shared/assets/images

Supprimer un lien symbolique

rm mon-lien

Supprimer un lien ne supprime pas la cible. Seul le raccourci est retiré.

Lien cassé

Si la cible est supprimée ou déplacée, le lien existe encore mais pointe dans le vide. On parle de lien cassé (broken symlink). Toute tentative d’ouvrir le lien produit une erreur « No such file or directory ».

Les symlinks en développement web

node_modules/.bin/

Quand tu installes un outil comme eslint ou vite avec npm, le binaire exécutable est placé dans node_modules/.bin/ sous forme de lien symbolique :

node_modules/.bin/vite -> ../vite/bin/vite.js

C’est ce qui permet à npx vite de fonctionner sans installer l’outil globalement.

Configuration de serveur web

Sur un serveur Linux avec Nginx, les sites disponibles et les sites actifs sont gérés par des symlinks :

# Activer un site
ln -s /etc/nginx/sites-available/mon-site.conf /etc/nginx/sites-enabled/

# Désactiver un site (supprime le lien, pas la configuration)
rm /etc/nginx/sites-enabled/mon-site.conf

La configuration reste dans sites-available/. Le lien dans sites-enabled/ dit à Nginx « ce site est actif ». Pour désactiver un site, on supprime le lien — la configuration est préservée.

Pour aller plus loin : npm link

Si tu développes deux projets en parallèle — par exemple une bibliothèque et une application qui l’utilise — npm link crée un lien symbolique dans node_modules/ qui pointe vers ta copie locale de la bibliothèque. Chaque modification est immédiatement visible sans rien réinstaller.

cd ma-bibliotheque
npm link

cd ../mon-application
npm link ma-bibliotheque

Pour aller plus loin : lien symbolique vs lien physique

Linux offre aussi des liens physiques (hard links), créés avec ln sans -s. Un lien physique pointe directement vers les données sur le disque (l’inode), pas vers un chemin. Si la cible est supprimée, les données restent accessibles via le lien physique — contrairement au lien symbolique qui devient cassé.

En contrepartie, un lien physique ne peut pas cibler un dossier et ne peut pas traverser des disques différents. En développement web, on utilise presque exclusivement les liens symboliques.