Qu’est-ce que le répertoire `www` et `public_html` dans votre compte d’hébergement ?

Le répertoire `public_html` est la racine du document de votre site web — le dossier côté serveur à partir duquel votre serveur web (Apache, Nginx, LiteSpeed) lit et sert tous les fichiers accessibles au public lorsqu’un visiteur charge votre domaine. Le répertoire `www`, dans la plupart des environnements partagés et basés sur cPanel, est simplement un lien symbolique (symlink) pointant vers `public_html`, existant pour des raisons de compatibilité historique plutôt que comme emplacement de stockage indépendant.

Comprendre cette distinction n’est pas anodin. Mal placer des fichiers en dehors de `public_html`, mal configurer la racine du document, ou mal comprendre la relation de lien symbolique peut entraîner des déploiements défaillants, des erreurs 403 Forbidden, ou une exposition publique involontaire de fichiers de configuration sensibles.

Le rôle de `public_html` en tant que racine du document

Lorsqu’une requête HTTP atteint votre serveur, le démon du serveur web consulte sa configuration pour déterminer quel répertoire correspond au domaine demandé. Ce répertoire est appelé la racine du document. Sur pratiquement tous les environnements d’hébergement partagé et la plupart des configurations VPS Hosting exécutant cPanel ou des panneaux de contrôle similaires, cette racine du document est `public_html`.

Le chemin absolu sur un serveur cPanel typique ressemble à ceci :

“`

/home/username/public_html/

“`

Tout fichier placé dans ce répertoire devient accessible publiquement via votre domaine. La correspondance est directe :

Cette dernière ligne est cruciale. Les fichiers placés au-dessus de `public_html` dans l’arborescence des répertoires — directement dans `/home/username/` — sont invisibles pour le serveur web et ne peuvent pas être récupérés via HTTP. C’est l’emplacement correct pour les fichiers sensibles tels que les identifiants de base de données, les fichiers `.env` et les clés API que votre application lit au moment de l’exécution mais qui ne doivent jamais être servis publiquement.

Fichiers d’index par défaut et résolution des répertoires

Lorsqu’un visiteur demande une URL de répertoire (par exemple, `https://example.com/`), le serveur web recherche un fichier d’index par défaut dans ce répertoire. L’ordre de résolution standard dans la directive `DirectoryIndex` d’Apache est généralement :

“`

index.html > index.htm > index.php > index.cgi

“`

Si aucun de ces fichiers n’existe et que le listage des répertoires n’est pas explicitement désactivé, le serveur peut renvoyer une erreur 403 Forbidden ou exposer un listage de répertoire — un risque de sécurité important. Assurez-vous toujours qu’un fichier d’index valide existe ou que `Options -Indexes` est défini dans votre `.htaccess`.

Ce qu’est réellement le répertoire `www`

Le répertoire `www` est un lien symbolique POSIX, pas un vrai répertoire avec son propre inode et allocation de stockage. Vous pouvez le vérifier sur n’importe quel serveur basé sur Linux :

“`bash

ls -la ~/

“`

La sortie affichera quelque chose comme :

“`

lrwxrwxrwx 1 user user 10 Jan 15 09:22 www -> public_html

drwxr-xr-x 12 user user 4096 Jan 15 09:22 public_html

“`

Le `l` au début de la chaîne de permissions et la flèche `-> public_html` confirment qu’il s’agit d’un lien symbolique. Cela signifie :

• `www` et `public_html` partagent exactement les mêmes données d’inode
• Écrire un fichier dans `~/www/contact.html` est identique à l’écrire dans `~/public_html/contact.html`
• Supprimer `www` ne supprime pas `public_html` ni aucun de ses contenus
• Recréer le lien symbolique est trivial : `ln -s ~/public_html ~/www`

Pourquoi le lien symbolique `www` existe

Le lien symbolique `www` est un artefact hérité avec des racines pratiques. Dans les premiers environnements d’hébergement basés sur Unix, la convention était de stocker le contenu web dans un répertoire littéralement nommé `www` — reflétant le préfixe de sous-domaine `www.` qui est devenu omniprésent dans les années 1990. Lorsque cPanel a standardisé `public_html` comme nom de racine du document, le lien symbolique `www` a été conservé pour éviter de casser :

• Les anciens scripts de déploiement codés en dur pour écrire dans `~/www/`
• Les clients FTP et gestionnaires de fichiers qui attendaient un dossier `www`
• La documentation et les tutoriels référençant `www` comme cible de téléchargement

À toutes fins pratiques dans un environnement moderne, vous devriez traiter `public_html` comme l’emplacement canonique et ignorer complètement `www`.

`public_html` vs `www` : Comparaison directe

Structure des répertoires dans `public_html`

Un répertoire `public_html` bien organisé sépare clairement les responsabilités. Voici une structure réaliste pour la production d’un site basé sur PHP ou une installation WordPress :

“`

public_html/

├── index.php

├── .htaccess

├── wp-config.php ← WordPress config (ideally moved one level up)

├── wp-content/

│ ├── themes/

│ ├── plugins/

│ └── uploads/

├── assets/

│ ├── css/

│ ├── js/

│ └── images/

└── sitemap.xml

“`

Note de sécurité critique : `wp-config.php` contient les identifiants de base de données. WordPress prend en charge le placement de ce fichier un répertoire au-dessus de `public_html` (`/home/username/wp-config.php`), où il est inaccessible via HTTP mais toujours lisible par PHP. Il s’agit d’une bonne pratique de renforcement que de nombreux administrateurs négligent.

Comment les sous-domaines et les domaines supplémentaires étendent cette structure

Lorsque vous créez un sous-domaine ou un domaine supplémentaire via les VPS Control Panels ou cPanel, le système d’hébergement crée une nouvelle racine du document — soit à l’intérieur de `public_html`, soit comme répertoire parallèle au même niveau.

Racines de document des sous-domaines

“`

/home/username/public_html/blog/ → blog.example.com

/home/username/public_html/shop/ → shop.example.com

“`

Ou, dans certaines configurations cPanel :

“`

/home/username/blog.example.com/ → blog.example.com

“`

Racines de document des domaines supplémentaires

“`

/home/username/public_html/newdomain/ → newdomain.com

“`

Ou comme répertoire frère de premier niveau :

“`

/home/username/newdomain.com/ → newdomain.com

“`

Le chemin exact dépend de la configuration de votre panneau d’hébergement. Vérifiez toujours la racine du document dans cPanel sous Domaines > Sous-domaines ou Domaines supplémentaires pour éviter de télécharger des fichiers au mauvais emplacement.

Différences de comportement selon les environnements d’hébergement

Hébergement partagé (cPanel)

Sur l’Hébergement Web Partagé avec cPanel, la structure est standardisée :

• Racine du document : `/home/username/public_html/`
• Lien symbolique `www` : présent par défaut
• Apache avec support `.htaccess` : activé
• Domaines multiples : chacun obtient son propre sous-répertoire ou dossier parallèle

VPS et serveurs dédiés

Sur un Serveur Dédié ou un VPS autogéré, la racine du document est entièrement définie par l’administrateur dans la configuration du serveur web. Conventions courantes :

Hôte virtuel Apache (`/etc/apache2/sites-available/example.com.conf`) :

“`apache

<VirtualHost *:80>

ServerName example.com

ServerAlias www.example.com

DocumentRoot /var/www/example.com/public_html

</VirtualHost>

“`

Bloc serveur Nginx (`/etc/nginx/sites-available/example.com`) :

“`nginx

server {

listen 80;

server_name example.com www.example.com;

root /var/www/example.com/public_html;

index index.php index.html;

}

“`

Dans ces environnements, `public_html` est une convention de nommage, pas une exigence technique. La racine du document peut être nommée n’importe comment — `/var/www/html/`, `/srv/www/`, `/opt/app/public/` — tant que la configuration du serveur web pointe vers elle. Le lien symbolique `www` n’existe généralement pas sauf si vous le créez manuellement.

VPS cPanel

Un VPS avec cPanel combine la flexibilité d’un VPS avec la structure `public_html` standardisée de l’hébergement partagé, ce qui en fait l’environnement le plus courant où `www` et `public_html` coexistent exactement comme décrit dans cet article.

Permissions de fichiers : une exigence souvent négligée

Des permissions incorrectes sont l’une des causes les plus fréquentes d’erreurs 403 Forbidden et d’échecs de déploiement. Le modèle de permissions standard pour les fichiers accessibles via le web :

Définissez les permissions de manière récursive avec :

“`bash

find ~/public_html -type d -exec chmod 755 {} ;

find ~/public_html -type f -exec chmod 644 {} ;

“`

Ne définissez jamais `777` sur un fichier ou répertoire dans un environnement de production. Cela accorde un accès en écriture à tous les utilisateurs du système et constitue un vecteur direct de compromission du serveur.

SSL, HTTPS et la racine du document

Lorsque vous installez un Certificat SSL sur votre domaine, le certificat est lié au nom de domaine, pas à un répertoire spécifique. Cependant, la configuration de l’hôte virtuel HTTPS doit pointer vers la même racine du document `public_html` que la configuration HTTP. Une incompatibilité — où HTTP sert depuis un répertoire et HTTPS depuis un autre — produit un comportement incohérent notoirement difficile à diagnostiquer.

Si vous utilisez Let’s Encrypt via Certbot, le processus de vérification du défi ACME place des fichiers temporaires dans `public_html/.well-known/acme-challenge/`. Assurez-vous que ce chemin n’est pas bloqué par des règles `.htaccess` ou des blocs `location` Nginx qui refusent l’accès aux répertoires cachés (ceux commençant par `.`).

Liste de contrôle des points clés pratiques

Avant de télécharger votre site :

• Confirmez le chemin exact de la racine du document dans votre panneau d’hébergement — ne supposez pas qu’il s’agit toujours de `/home/username/public_html/`
• Vérifiez que `www` est un lien symbolique, pas un répertoire séparé, pour éviter la gestion de fichiers en double
• Déplacez les fichiers de configuration sensibles (`.env`, identifiants de base de données) au-dessus de `public_html`

Lors du déploiement :

• Définissez les permissions des répertoires à `755` et les permissions des fichiers à `644`
• Assurez-vous qu’un `index.html` ou `index.php` existe à la racine du document pour empêcher le listage des répertoires
• Désactivez `Options Indexes` dans `.htaccess` comme mesure de défense en profondeur

Pour les configurations multi-domaines :

• Confirmez la racine du document pour chaque sous-domaine et domaine supplémentaire individuellement
• Ne supposez pas que tous les domaines partagent le même `public_html`

Sur les environnements VPS et dédiés :

• Définissez la racine du document explicitement dans votre configuration d’hôte virtuel ou de bloc serveur
• Le lien symbolique `www` n’existe pas par défaut — créez-le uniquement si des scripts hérités l’exigent
• Redémarrez le serveur web après tout changement de configuration : `systemctl reload apache2` ou `systemctl reload nginx`

Pour le renforcement de la sécurité :

• Ne stockez jamais les clés API, les fichiers `.env` ou les configurations de base de données dans `public_html`
• Auditez `public_html` périodiquement pour détecter les fichiers inattendus, en particulier dans les répertoires `uploads/`
• Assurez-vous que votre hôte virtuel SSL pointe vers la même racine du document que la configuration HTTP

Foire aux questions

Que se passe-t-il si je supprime le répertoire `www` ?

Si `www` est un lien symbolique (ce qu’il est dans pratiquement tous les environnements cPanel), le supprimer n’a aucun effet sur votre site web ou ses fichiers. Votre site continue de fonctionner normalement car le contenu réel se trouve dans `public_html`. Vous pouvez recréer le lien symbolique à tout moment avec `ln -s ~/public_html ~/www`.

Puis-je renommer `public_html` en autre chose ?

Sur l’hébergement partagé, non — le panneau de contrôle est codé en dur pour utiliser `public_html` comme racine du document. Sur un VPS autogéré ou un serveur dédié, vous pouvez nommer la racine du document comme vous le souhaitez, à condition de mettre à jour la configuration du serveur web (`DocumentRoot` dans Apache, `root` dans Nginx) en conséquence.

Pourquoi est-ce que j’obtiens une erreur 403 Forbidden même si mes fichiers sont dans `public_html` ?

Les causes les plus courantes sont des permissions de fichiers incorrectes (les fichiers ont besoin d’au moins `644`, les répertoires ont besoin de `755`), un fichier d’index manquant avec le listage des répertoires désactivé, ou une règle `.htaccess` bloquant l’accès. Consultez le journal d’erreurs du serveur web (`/var/log/apache2/error.log` ou `/var/log/nginx/error.log`) pour la raison spécifique.

Où dois-je stocker les fichiers que PHP doit lire mais qui ne doivent pas être accessibles publiquement ?

Placez-les dans un répertoire au-dessus de `public_html`, tel que `/home/username/private/` ou directement dans `/home/username/`. PHP peut lire des fichiers n’importe où sur le système de fichiers que l’utilisateur du serveur web a la permission d’accéder, mais le serveur web ne servira pas les fichiers en dehors de la racine du document via HTTP.

Le sous-domaine `www` fonctionne-t-il différemment du domaine sans www au niveau du serveur ?

Non. `www.example.com` et `example.com` sont tous deux résolus vers la même racine du document via la configuration DNS et les paramètres d’hôte virtuel. Le répertoire `www` sur le système de fichiers est sans rapport avec le sous-domaine DNS `www.` — ce sont des concepts distincts qui partagent simplement les mêmes trois lettres.