Installer et configurer un serveur domestique : le tutoriel complet pour débutants

« Vous voulez installer un serveur à la maison ? Commencez par jeter un œil à votre placard. »

Voilà ce que je réponds à presque tous ceux qui me posent la question. Pas parce que c'est facile — ça ne l'est pas vraiment, au début — mais parce que c'est le point de départ le plus honnête que je connaisse. J'ai monté mon premier serveur domestique avec un vieux portable qui datait de 2012, dont la batterie gonflait et qu'il fallait laisser branché sur un chargeur maintenu par un élastique. Franchement, c'était moche. Mais ça a marché. Et depuis, j'ai dû en installer une bonne dizaine, pour moi et pour des proches.

Ce guide est celui que j'aurais aimé lire à l'époque. Il ne vous vend pas de matériel neuf. Il vous montre comment installer et configurer un serveur domestique proprement, avec des commandes exactes, des pièges identifiés, et une stratégie de sécurité qui tient la route.

Choisir le bon matériel sans se ruiner

La première erreur que j'ai commise, c'est d'avoir voulu du matériel « fait pour ». J'ai acheté un NAS entrée de gamme, et je l'ai regretté pendant deux ans : processeur anémique, interface propriétaire, et une extension impossible au-delà de deux disques. Bref.

Aujourd'hui, je conseille l'inverse : récupérez un ordinateur qui ne sert plus, ou achetez un mini PC. Un vieux PC de bureau avec un processeur Intel Core i3 ou i5 de génération 6 ou plus est largement suffisant pour du stockage, un serveur multimédia et quelques services Docker. La consommation électrique ? Comptez 30 à 50 watts pour un vieux portable, 10 à 15 watts pour un mini PC récent. Sur l'année, un mini PC consomme à peu près l'équivalent d'une box internet, et c'est un vrai argument — ça vous évitera de sursauter en ouvrant la facture EDF, croyez-moi.

Le seul point sur lequel je vous déconseille de faire l'économie, c'est le disque dur. Pas de vieux disque de 500 Go récupéré d'un PC de 2010 pour vos photos de famille. Prenez un disque neuf, ou deux si vous voulez un minimum de tolérance aux pannes.

Mini PC ou vieux portable : que choisir en 2026 ?

Les mini PC type Intel N100 ou équivalent ont un avantage décisif : ils sont silencieux, stables et sobres. J'en ai installé un chez mes parents pour faire de la sauvegarde familiale, et il tourne depuis dix-huit mois sans un seul redémarrage. Un vieux portable, lui, aura souvent un écran et un clavier intégrés (pratique pour le dépannage), mais une fiabilité moindre : c'est de l'électronique grand public qui a déjà vécu.

Mon conseil : si votre budget le permet, un mini PC d'entrée de gamme autour de 150 à 200 € avec un disque SSD de 256 Go pour le système, c'est le bonheur. Vous ajoutez un ou deux disques de stockage en SATA ou USB 3.0, et vous avez un serveur propre pour une fraction du prix d'un NAS.

Installer le système d'exploitation : Ubuntu Server, pas à pas

J'ai testé pas mal de distributions. Debian, Proxmox, TrueNAS... Elles ont toutes leurs qualités. Mais pour un premier serveur, Ubuntu Server reste le choix le plus pragmatique : une documentation immense, des paquets à jour, et une communauté qui a répondu à toutes mes questions avant même que je les pose.

Téléchargez l'image ISO officielle, puis créez une clé USB bootable. Sous Windows, Rufus fait très bien le travail. Sous Linux, la commande `dd` suffit :

sudo dd if=ubuntu.iso of=/dev/sdX bs=4M status=progress

(Remplacez `/dev/sdX` par le chemin réel de votre clé USB — vérifiez-le avec `lsblk`, ou vous risquez d'effacer un disque externe. Je parle d'expérience. C'est le genre d'erreur qu'on ne fait qu'une fois.)

Les options d'installation à ne pas rater

Pendant l'installation, deux écrans méritent toute votre attention :

1. Le nom d'utilisateur. Choisissez un nom simple, sans espaces ni accents. Vous allez le taper des centaines de fois dans des commandes SSH.
2. La case « Install OpenSSH server ». Cochez-la dès l'installation. Sans elle, vous devrez rebrancher un écran et un clavier pour activer SSH ensuite, et c'est une perte de temps inutile.

Pour le reste, les options par défaut conviennent parfaitement. Vous n'avez pas besoin de LVM, de chiffrement de disque complet ou de configurations réseau avancées pour démarrer.

Première connexion et mise à jour du système

Une fois Ubuntu installé, débranchez l'écran et le clavier, branchez le serveur sur votre réseau en Ethernet, et connectez-vous depuis votre ordinateur principal :

ssh utilisateur@ip-du-serveur

Pour trouver l'adresse IP de votre serveur, regardez la liste des clients de votre box internet, ou utilisez `ip a` sur le serveur si vous avez encore un écran branché. C'est le genre de détail qui semble évident une fois qu'on le sait, mais qui bloque pendant vingt minutes quand on débute.

Ensuite, mettez le système à jour :

sudo apt update && sudo apt upgrade -y

Répétez cette commande toutes les semaines environ. J'ai automatisé ça avec un service systemd qui lance la mise à jour à 4 h du matin. Sur mon premier serveur, je ne l'ai pas fait pendant trois mois. Résultat : une faille de sécurité connue dans un service exposé, et une grosse frayeur en lisant les logs. Ne faites pas comme moi.

Activer le pare-feu UFW dès la première minute

Ubuntu installe `ufw` mais ne l'active pas par défaut. C'est une erreur. Configurez-le immédiatement :

sudo ufw allow OpenSSH

sudo ufw enable

sudo ufw status

Cet ordre est important : autorisez SSH avant d'activer le pare-feu, sinon vous vous enfermez dehors. `ufw` n'autorise que les connexions que vous avez explicitement ouvertes. Tout le reste est bloqué. C'est votre première ligne de défense, et elle vous évitera 90 % des problèmes.

Sécuriser l'accès SSH : clés plutôt que mots de passe

Le jour où j'ai vu mon premier serveur se faire attaquer en force brute, j'ai compris. Des connexions SSH tentées depuis des adresses IP du monde entier, toutes les quelques secondes. C'est un bruit de fond constant sur internet, et le mot de passe, même compliqué, finit par céder si vous laissez la porte ouverte assez longtemps.

La solution est simple : désactivez l'authentification par mot de passe et utilisez des clés SSH.

Sur votre ordinateur, générez une paire de clés si vous n'en avez pas :

ssh-keygen -t ed25519 -C "serveur-domestique"

Copiez la clé publique sur le serveur avec `ssh-copy-id utilisateur@ip-du-serveur`. Ensuite, dans `/etc/ssh/sshd_config`, modifiez ces lignes :

PasswordAuthentication no

PubkeyAuthentication yes

Redémarrez le service SSH avec `sudo systemctl restart sshd`. Testez la connexion dans un nouveau terminal AVANT de fermer la session existante. Si quelque chose cloche, vous pourrez toujours revenir par l'ancienne session. C'est le genre de précaution qui semble exagérée — jusqu'au jour où elle vous sauve.

Installer ses premiers services : Docker, le couteau suisse

Pour le stockage, j'utilise exclusivement Docker depuis trois ans. Pas parce que c'est tendance, mais parce que ça simplifie tout : l'installation, les mises à jour, et la suppression des services devenus inutiles.

Installez Docker avec le dépôt officiel :

curl -fsSL https://get.docker.com | sh

sudo usermod -aG docker utilisateur

Déconnectez-vous et reconnectez-vous pour que le groupe `docker` soit actif. Vérifiez avec `docker run hello-world`. Si ça affiche un message de bienvenue, tout est prêt.

Un exemple concret : un serveur de stockage et un serveur multimédia

Pour un premier serveur, deux services feront 90 % du travail : Samba pour le stockage accessible depuis Windows, macOS ou Linux, et Plex (ou Jellyfin, si vous préférez l'open source) pour la vidéo.

Voici un `docker-compose.yml` qui résume l'essentiel :

version: "3.8"

services:

samba:

image: dperson/samba

container_name: samba

ports:

- "445:445"

volumes:

• /mnt/media:/media
• /mnt/data:/data

command: "-u monutilisateur;monmotdepasse -s 'media;/media;yes;no;no;monutilisateur'"

restart: unless-stopped

plex:

image: plexinc/pms-docker

container_name: plex

environment:

• PLEX_CLAIM=claim-token
• PUID=1000
• PGID=1000

volumes:

• /opt/plex/config:/config
• /mnt/media:/data/media

ports:

- "32400:32400"

restart: unless-stopped

Quelques remarques que j'aurais aimé entendre plus tôt :

• Les volumes sont la clé. Tout ce qui doit survivre à la suppression du conteneur (configurations, données) doit être monté depuis le système hôte. Sur mon premier essai, j'avais tout laissé dans le conteneur. À la première mise à jour, tout a disparu. J'ai passé une soirée entière à reconstruire la configuration.
• Le mot de passe Samba dans la commande n'est pas idéal. Pour un usage domestique, c'est acceptable ; pour un usage plus sérieux, utilisez un fichier d'environnement avec `env_file`.

Sauvegarder sans y penser : rsync et BorgBackup

Un serveur sans sauvegarde, c'est une bombe à retardement. Mon disque principal a rendu l'âme au bout de deux ans et demi, sans prévenir. J'avais des sauvegardes, et je n'ai perdu que les données de la semaine. Sans elles, j'aurais perdu dix ans de photos.

La règle que j'applique maintenant : sauvegarde automatique, quotidienne, vers un second support.

La méthode simple avec rsync

Pour un volume raisonnable de données (jusqu'à quelques centaines de Go), rsync suffit :

rsync -avz --delete /mnt/data/ utilisateur@machine-externe:/mnt/backup/data/

L'option `--delete` supprime sur la destination les fichiers supprimés à la source. Attention : si vous vous trompez de sens, vous effacez la sauvegarde. Vérifiez toujours avec `--dry-run` d'abord. J'ai failli effacer six mois de sauvegardes familiales avec un mauvais sens de commande. Le `--dry-run` est devenu une habitude systématique depuis.

Automatisez avec une tâche cron :

sudo crontab -e

Ajoutez la ligne suivante pour une sauvegarde quotidienne à 2 h du matin :

0 2 * rsync -avz --delete /mnt/data/ utilisateur@machine-externe:/mnt/backup/data/ >> /var/log/backup.log 2>&1

BorgBackup pour les snapshots versionnés

rsync fait une copie miroir. Si une attaque par ransomware chiffre vos fichiers, elle chiffrera aussi la copie miroir. BorgBackup, lui, garde des versions successives de vos fichiers. Vous pouvez remonter le temps.

sudo apt install borgbackup

borg init --encryption=repokey utilisateur@machine-externe:/mnt/backup/borg-repo

Puis une sauvegarde avec compression :

borg create --stats --compression lz4 utilisateur@machine-externe:/mnt/backup/borg-repo::serveur-{now} /mnt/data

borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6 utilisateur@machine-externe:/mnt/backup/borg-repo

La commande `prune` supprime les anciennes sauvegardes selon la règle : 7 par jour, 4 par semaine, 6 par mois. Testez la restauration au moins une fois. Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde, c'est une hypothèse.

Accéder à son serveur depuis l'extérieur : le VPN, pas le port-forwarding

C'est la question qu'on me pose le plus : « Comment je fais pour accéder à mes fichiers quand je suis en déplacement ? »

La tentation est d'ouvrir un port sur votre box internet et de rediriger vers votre serveur. C'est ce que j'ai fait au début. Résultat : des tentatives de connexion en continu, et une inquiétude permanente. Ne faites pas ça.

La solution propre, c'est WireGuard, un VPN qui crée un tunnel sécurisé entre votre téléphone ou votre ordinateur portable et votre serveur. Installé en une dizaine de minutes, il vous donne un accès complet à votre réseau domestique comme si vous y étiez.

Sur le serveur :

sudo apt install wireguard

Configurez une interface minimale dans `/etc/wireguard/wg0.conf` :

[Interface]

Address = 10.0.0.1/24

ListenPort = 51820

PrivateKey = votre_cle_privee

[Peer]

PublicKey = cle_publique_du_client

AllowedIPs = 10.0.0.2/32

Générez les clés avec `wg genkey` et `wg pubkey`, puis activez WireGuard :

sudo systemctl enable wg-quick@wg0

sudo systemctl start wg-quick@wg0

Sur votre box internet, ouvrez une seule redirection de port : le port UDP 51820 vers l'adresse de votre serveur. C'est le seul port à ouvrir, et c'est beaucoup plus sûr que d'exposer Samba ou Plex directement sur internet.

Et si votre adresse IP change ? Le DDNS

Les box internet du grand public changent souvent d'adresse IP publique. Un jour, votre serveur est accessible à l'adresse 81.67.12.34, le lendemain à 82.15.9.77. La solution s'appelle le DDNS : un service qui associe un nom de domaine (ex. `monserveur.duckdns.org`) à votre adresse IP et la met à jour automatiquement.

La plupart des box intègrent un client DDNS dans leur interface. Vous créez un compte sur un service gratuit comme DuckDNS ou FreeDNS, vous récupérez un jeton, et vous le collez dans la configuration de votre box. Une fois en place, vous n'y pensez plus jamais — jusqu'au jour où votre adresse change, et où vous constatez que ça marche toujours.

Dépanner comme un professionnel : les commandes qui sauvent

Même bien configuré, un serveur domestique finit par poser problème. Les trois commandes qui m'ont le plus sauvé :

• `journalctl -u service-name -f` pour suivre les logs d'un service en temps réel. C'est le premier réflexe à avoir quand un service ne démarre pas.
• `df -h` pour vérifier l'espace disque. Un disque plein est la cause la plus fréquente des pannes que j'ai rencontrées.
• `netstat -tulpn` pour voir quels ports sont ouverts et quels processus les écoutent. Indispensable pour vérifier que votre pare-feu fait son travail.

Et surtout : documentez ce que vous faites. J'ai créé un simple fichier texte dans le répertoire personnel de mon serveur, avec les commandes importantes, les mots de passe (dans un fichier chiffré avec `age`, pas en clair), et les dates de mise à jour. Le jour où votre serveur plante à 23 h un dimanche soir, vous serez content d'avoir ce pense-bête.

Quelques erreurs que j'aimerais que vous évitiez

J'ai fait à peu près toutes les erreurs possibles. Voici les trois qui ont le plus coûté :

1. Ne pas activer le pare-feu immédiatement. J'ai laissé mon premier serveur exposé avec tous les ports ouverts pendant trois jours. Les logs montraient des tentatives de connexion de la Chine, de la Russie et du Brésil. Rien n'est arrivé, mais c'est la loterie.
2. Sauvegarder sur le même disque physique. J'avais fait une partition dédiée aux sauvegardes sur le même disque que les données. Le disque est mort, les deux partitions ont disparu ensemble. La sauvegarde doit être sur un support séparé, idéalement dans un autre bâtiment.
3. Mettre à jour sans lire les notes de version. Une mise à jour de Docker Compose a modifié la syntaxe des fichiers, et tous mes services ont cessé de fonctionner à 3 h du matin. Lisez les notes de version avant de lancer `apt upgrade` sur un système qui ne tourne pas en local.

Pour aller plus loin : Proxmox, la virtualisation pour vrais projets

Si vous vous prenez au jeu, la prochaine étape logique est Proxmox VE, un hyperviseur qui transforme votre serveur en plateforme de virtualisation. Vous pouvez y faire tourner plusieurs machines virtuelles ou conteneurs indépendants : un pour votre stockage, un pour votre serveur multimédia, un pour vos expérimentations.

J'y suis passé au bout d'un an, quand j'ai voulu tester des services sans risquer de casser le serveur principal. Avec Proxmox, je crée un conteneur, j'installe un service, je le teste, et je le détruis si ça ne me plaît pas. Le serveur principal n'est jamais affecté.

Le coût en ressources est minime pour un usage domestique : un processeur moderne et 16 Go de RAM suffisent pour faire tourner cinq à six conteneurs légers. L'installation est similaire à celle d'Ubuntu, et l'interface web est en français.

Installer un serveur domestique, c'est un peu comme apprendre à cuisiner : les premiers essais sont brouillons, mais chaque échec vous apprend quelque chose, et au bout de quelques mois, vous avez un outil qui sert toute la maison. Le jour où vous retrouverez une photo de vacances perdue depuis cinq ans, ou où votre famille vous demandera pourquoi la box ne plante plus jamais, vous comprendrez pourquoi ça valait la peine. Et vous n'aurez plus qu'une envie : recommencer, en mieux, avec un deuxième serveur.