Comment utiliser LINUX comme serveur web

Linux est un socle fiable pour héberger un site vitrine, un blog, une application métier ou une boutique en ligne. Mais « utiliser Linux comme serveur web » ne se résume pas à installer un logiciel : il faut relier un nom de domaine à une adresse IP, servir les fichiers ou l’application, chiffrer les échanges HTTPS et organiser la sécurité comme la maintenance.

Pour un projet professionnel, la solution la plus simple est généralement un VPS Linux chez un hébergeur, avec un serveur web tel que Nginx ou Apache. Vous conservez la maîtrise de l’environnement sans avoir à gérer le matériel physique, l’alimentation électrique ou la connexion Internet. Le serveur installé à domicile est utile pour apprendre ou tester, mais rarement adapté à une mise en production.

Comprendre les briques d’un site hébergé sous Linux

Avant toute installation, il est utile de distinguer les rôles. Un domaine, un hébergement et le DNS sont liés, mais ce ne sont pas le même service. Cette séparation permet aussi de changer d’hébergeur sans nécessairement perdre la gestion du nom de domaine.

Le navigateur d’un visiteur suit une chaîne simple : il interroge le DNS pour connaître l’IP de votre domaine, contacte cette IP en HTTP ou HTTPS, puis le serveur web retourne une page, un fichier ou la réponse de votre application.

Choisir l’architecture adaptée au niveau d’exigence

Linux est disponible via de nombreuses distributions. Pour un premier serveur, privilégiez une distribution disposant d’une documentation abondante, de mises à jour suivies et de paquets maintenus : Debian, Ubuntu Server LTS, Rocky Linux ou AlmaLinux sont des choix fréquents. Le bon choix est moins une question de performance qu’une question de maîtrise opérationnelle et de disponibilité des compétences.

VPS, hébergement mutualisé ou serveur interne : quelle option retenir ?

Un hébergement mutualisé sous Linux convient à un site simple lorsque vous ne voulez pas gérer le système. À l’inverse, un VPS offre un accès administrateur et la liberté d’installer votre pile technique, mais implique une vraie responsabilité de sécurité.

Pour un site statique ou une petite application, un serveur d’entrée de gamme peut suffire. Un CMS avec plusieurs extensions, une base de données et du trafic régulier demandera davantage de mémoire et une supervision plus attentive. Ne dimensionnez pas uniquement selon le nombre de visiteurs : la consommation dépend aussi du cache, des images, des traitements en arrière-plan et de la qualité du code.

Préparer le serveur Linux avant d’installer le site

La procédure ci-dessous prend Ubuntu Server ou Debian comme repère. Les principes sont identiques sur les autres distributions, mais les commandes et outils peuvent varier. Commencez par déployer une image système récente chez votre hébergeur et associez-lui une IP publique fixe si l’offre le permet.

Mettre le système à jour et créer un compte d’administration

Connectez-vous une première fois via SSH avec les identifiants fournis par l’hébergeur, puis appliquez les mises à jour :

sudo apt update && sudo apt upgrade -y

Évitez d’utiliser quotidiennement le compte root. Créez un utilisateur nominatif ou dédié à l’administration, donnez-lui les droits nécessaires via sudo, puis testez une nouvelle connexion SSH avant toute modification des accès existants.

L’authentification par clé SSH est préférable au mot de passe. Après avoir vérifié que la clé fonctionne, vous pourrez désactiver la connexion directe de root et, selon votre organisation, l’authentification par mot de passe. Cette étape doit être menée avec prudence : une erreur de configuration peut vous bloquer hors du serveur.

Fermer les ports inutiles dès le départ

Le serveur n’a pas à exposer tous ses services sur Internet. Autorisez seulement :

• le port SSH, généralement 22, pour l’administration ;
• le port 80 pour HTTP, nécessaire notamment à certaines validations de certificat ;
• le port 443 pour HTTPS.

Avec UFW sur Debian ou Ubuntu, la logique est par exemple d’autoriser SSH avant d’activer le pare-feu, puis d’ouvrir les profils Nginx. Vérifiez également le pare-feu réseau proposé par votre fournisseur cloud : il peut bloquer le trafic même si le pare-feu Linux est correctement réglé.

N’exposez pas une base de données, un panneau d’administration ou un outil de cache au public sans nécessité. Si plusieurs services communiquent sur le même serveur, faites-les écouter sur l’interface locale plutôt que sur toutes les interfaces réseau.

Installer et configurer Nginx pour un premier site

Nginx est couramment choisi pour sa sobriété et sa capacité à servir efficacement des fichiers statiques ou à agir comme reverse proxy devant une application PHP, Python, Ruby, Java ou Node.js. Apache reste une excellente alternative, notamment dans des environnements historiques reposant sur .htaccess. Il faut toutefois éviter de multiplier les serveurs web sans raison : choisissez une pile et maîtrisez-la.

Sur Debian ou Ubuntu, l’installation de base de Nginx peut se faire ainsi :

sudo apt update
sudo apt install nginx -y
sudo systemctl enable --now nginx

Créez ensuite un répertoire réservé à votre site, par exemple /var/www/exemple.fr/public, et attribuez des droits cohérents au compte chargé des déploiements. Ne placez pas des secrets, sauvegardes SQL, fichiers de configuration applicative ou dépôts Git accessibles dans le répertoire public.

Créer un hôte virtuel par domaine

Chaque domaine ou sous-domaine doit avoir sa propre configuration Nginx, appelée bloc server. Un exemple minimal pour un site statique est le suivant :

server {
    listen 80;
    listen [::]:80;
    server_name exemple.fr www.exemple.fr;

    root /var/www/exemple.fr/public;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Enregistrez ce fichier dans le répertoire des sites disponibles de votre distribution, activez-le par un lien symbolique vers les sites activés, puis vérifiez la syntaxe avant de recharger Nginx :

sudo nginx -t
sudo systemctl reload nginx

Pour une application dynamique, Nginx ne doit pas forcément exécuter le code directement. Il transmet généralement les requêtes à un autre service : PHP-FPM pour PHP, Gunicorn ou uWSGI pour certaines applications Python, ou un processus applicatif Node.js. Ces services doivent être lancés par un gestionnaire adapté, redémarrés automatiquement et maintenus hors du mode développement.

Relier le domaine au serveur avec le DNS

Une fois l’IP publique connue, ajoutez les enregistrements DNS correspondant à votre projet. Pour le site principal, l’enregistrement le plus courant est un enregistrement A vers l’IPv4. Si vous utilisez IPv6, ajoutez aussi un enregistrement AAAA, mais seulement si votre serveur est effectivement configuré, filtré et supervisé en IPv6.

Le sous-domaine www peut pointer vers la même adresse ou être créé en CNAME vers le domaine principal selon la politique de votre prestataire DNS. Choisissez ensuite une version canonique — avec ou sans www — et redirigez l’autre vers celle-ci afin d’éviter les doublons techniques et SEO.

Les enregistrements e-mail, comme MX, SPF, DKIM ou DMARC, sont indépendants du site web. Ne les effacez jamais lors d’une refonte de zone DNS : une erreur à ce stade peut interrompre la réception ou l’envoi d’e-mails professionnels.

Faut-il installer son propre serveur de noms ?

Dans la quasi-totalité des cas, non. Utiliser les serveurs de noms fournis par un registrar, un hébergeur ou un spécialiste DNS est plus simple et souvent plus résilient. Ces plateformes offrent généralement une interface de gestion, des serveurs répartis géographiquement et des mécanismes de protection que vous devriez sinon construire vous-même.

Exploiter un DNS autoritatif interne se justifie pour une organisation ayant des exigences spécifiques, des compétences réseau et une architecture redondée. Il faut au minimum prévoir plusieurs serveurs de noms indépendants, sécuriser les transferts de zone, surveiller le service, gérer les correctifs et évaluer l’intérêt de DNSSEC. Configurer le résolveur DNS de votre serveur Linux ne transforme pas ce serveur en DNS autoritatif public pour votre domaine.

Migrer sans interruption : domaine, DNS et hébergement sont trois opérations distinctes

Un transfert de registrar change le gestionnaire administratif du domaine. Une modification de serveurs de noms déplace la zone DNS vers un autre fournisseur. Un changement d’enregistrement A ou AAAA redirige le trafic vers un nouveau serveur. Ces opérations peuvent être menées séparément.

Pour basculer un site avec un risque limité de coupure :

1. Reproduisez la configuration du site sur le nouveau serveur et testez-la avec une URL provisoire ou une résolution locale contrôlée.
2. Copiez intégralement la zone DNS chez le nouveau prestataire si vous changez de fournisseur DNS, y compris les enregistrements e-mail et de vérification.
3. Diminuez le TTL des enregistrements concernés suffisamment en amont, dans la limite acceptée par votre fournisseur.
4. Vérifiez que le nouveau serveur répond correctement en HTTP et en HTTPS, avec les bons redirections et certificats.
5. Modifiez l’enregistrement A/AAAA ou la délégation des serveurs de noms selon le scénario retenu.
6. Conservez l’ancienne infrastructure et surveillez les journaux pendant la période de propagation avant de la supprimer.

Activer HTTPS et gérer les certificats TLS

Un site professionnel doit être accessible en HTTPS, y compris s’il ne collecte pas de paiement. Le chiffrement protège les échanges, évite les alertes du navigateur et répond aux attentes des visiteurs comme des moteurs de recherche.

Let’s Encrypt permet d’obtenir des certificats gratuits, renouvelables automatiquement. Avec Nginx, un outil tel que Certbot peut demander le certificat et modifier la configuration. Le principe est simple : le domaine doit déjà résoudre vers le serveur, le port nécessaire à la validation doit être joignable, et Nginx doit connaître le nom de domaine déclaré.

Après l’émission du certificat, forcez la redirection de HTTP vers HTTPS et vérifiez les deux versions du domaine. Testez ensuite le renouvellement automatique prévu par votre environnement. Ne configurez pas HSTS de manière irréversible sans avoir vérifié la stabilité complète de HTTPS : ce mécanisme est utile, mais une configuration erronée peut compliquer les retours en arrière.

Déployer proprement et maintenir le serveur dans le temps

Copier des fichiers à la main peut dépanner, mais une procédure répétable réduit les erreurs. Pour un site simple, rsync depuis un poste sécurisé peut suffire. Pour une application métier, préférez un dépôt Git, un pipeline d’intégration et une procédure de déploiement documentée.

Une méthode robuste consiste à publier chaque version dans un répertoire de livraison daté, puis à faire pointer un lien symbolique current vers la version active. Le retour arrière devient alors plus rapide : on repointe le lien vers la version précédente après avoir identifié le problème. Les migrations de base de données exigent toutefois une attention particulière, car elles ne sont pas toujours réversibles.

Mettre en place le minimum opérationnel

Un serveur web en production n’est pas terminé après le premier déploiement. Prévoyez au minimum :

• des mises à jour système et applicatives planifiées ;
• une sauvegarde chiffrée, externalisée et testée par une restauration réelle ;
• la surveillance de l’espace disque, de la disponibilité HTTP, de l’expiration des certificats et des erreurs ;
• la rotation ou la centralisation des journaux Nginx et applicatifs ;
• une protection contre les tentatives de connexion répétées, par exemple avec Fail2ban lorsque cela est pertinent ;
• une documentation des accès, des domaines, des services démarrés et de la procédure de reprise.

Ne stockez pas les mots de passe, clés API ou secrets de production dans un dépôt Git public, dans le répertoire web ou dans un fichier de sauvegarde accessible. Limitez aussi les comptes ayant accès à la production : le principe du moindre privilège évite qu’une erreur de manipulation ne devienne un incident majeur.

Décider si l’auto-administration est réellement pertinente

Un serveur Linux apporte de la flexibilité, mais il ne remplace pas une décision d’architecture. Pour un site institutionnel sans besoin technique spécifique, un hébergement administré peut être plus rationnel : les équipes gagnent du temps et réduisent le risque opérationnel. Pour une application sur mesure, des besoins d’intégration ou un impératif de contrôle, le VPS administré en interne ou par un prestataire devient plus pertinent.

Évaluez le coût global, pas seulement le tarif mensuel du serveur : temps de configuration, mises à jour, surveillance, sauvegardes, gestion des incidents et compétences disponibles. Si le site traite des données personnelles, des commandes ou des documents sensibles, formalisez également les responsabilités, les accès, les durées de conservation des journaux et les mesures de sécurité attendues.

Un serveur web Linux bien administré est une base durable. La clé n’est pas d’accumuler les outils, mais de construire une chaîne simple : un DNS fiable, une configuration web claire, HTTPS, des déploiements reproductibles et une maintenance dont quelqu’un est explicitement responsable.