Monter un serveur local sous Linux avec LAMPP, c’est un peu l’équivalent du studio de répétition pour un groupe de rock : un espace à toi, isolé d’Internet, où tu peux casser des choses sans traumatiser des utilisateurs. Avec un empilement Linux + Apache + MariaDB/MySQL + PHP bien configuré, tu peux tester un site WordPress, une appli maison ou un intranet complet, sans toucher à un serveur de production. L’autre bénéfice, souvent sous-estimé, c’est la compréhension fine de ce qui se passe derrière les boutons « Installer automatiquement » des hébergeurs : quand tu sais comment ton serveur web répond, d’où vient la base de données ou comment PHP-FPM gère les scripts, tu débugges plus vite et tu dors mieux.
Ce guide se concentre sur un cas très courant en 2026 : un serveur LAMPP sous Debian ou Ubuntu, pensé pour le développement local, mais suffisamment propre pour pouvoir être la base d’un futur serveur de préproduction. Il va être question d’installation pas à pas, de configuration d’Apache pour accueillir plusieurs sites, de réglages PHP pour éviter les bugs absurdes, et de sécurisation minimale de MariaDB. On suivra un fil conducteur concret, celui de Samir, dev web qui veut faire tourner un WordPress, un Nextcloud et une petite API PHP sur sa machine Linux, sans Docker ni solution clé en main. L’idée n’est pas de théoriser, mais de montrer comment un stack LAMPP devient un vrai outil de travail au quotidien.
En bref
- LAMPP désigne un empilement Linux + Apache + MariaDB/MySQL + PHP pour faire tourner un serveur local de développement.
- Sur Debian 13 ou Ubuntu, l’installation d’Apache, PHP 8.4 et MariaDB se fait via apt, avec quelques commandes ciblées.
- La configuration d’Apache repose sur les VirtualHost, les modules (rewrite, ssl, http2, etc.) et une arborescence claire dans /etc/apache2.
- PHP-FPM est à privilégier par rapport au module Apache classique pour un serveur web réactif et plus simple à faire évoluer.
- MariaDB remplace avantageusement MySQL dans la plupart des projets PHP classiques, surtout en développement local.
- Un bon serveur local ne se limite pas à « ça marche » : un minimum de sécurité, de logs et de structure permet de préparer la future mise en ligne.
LAMPP sous Linux : comprendre l’empilement avant de lancer la première commande
Avant de copier-coller une seule commande d’installation, ça vaut la peine de clarifier ce qu’est vraiment LAMPP sur Linux. Le mot circule partout, mais il recouvre plusieurs réalités : parfois on parle de LAMP, parfois de XAMPP, parfois d’un « serveur local » flou lancé en deux clics. Ici, l’objectif est clair : utiliser les paquets natifs de Debian/Ubuntu pour assembler un environnement complet autour de Linux, Apache, MariaDB et PHP, au service du développement local.
Dans ce contexte, Linux joue le rôle de socle : Debian 13, Ubuntu 24.04 ou une autre dérivée. C’est lui qui fournit le gestionnaire de paquets, la gestion des services systemd, les permissions de fichiers, le pare-feu, bref tout ce qui fait qu’un serveur web tient debout. Apache, lui, est la brique qui écoutera sur le port 80 ou 443, recevra les requêtes HTTP et décidera si le contenu à renvoyer est un simple fichier statique ou un script PHP qui devra être interprété. Au milieu, MariaDB ou MySQL stocke les données de tes applis : utilisateurs, contenus, sessions, commandes, peu importe la nature du projet.
La brique qui fait souvent le plus débat, c’est PHP. En 2026, sur Debian 13, la version par défaut est PHP 8.4, avec un moteur bien plus rapide et strict que ce qu’on connaissait à l’époque de PHP 5.6 ou 7.0. Pour un serveur local moderne, rester sur une vieille version juste « parce que mon ancien hébergeur la supporte encore » n’a pas trop de sens : mieux vaut développer sur une version récente, quitte à adapter quelques fonctions dépréciées lorsque tu déploies. En revanche, si tu dois maintenir une vieille appli, il reste possible d’ajouter un dépôt spécifique et d’installer un binaire plus ancien à côté.
Samir, notre dev fil rouge, part d’une Debian 13 fraîchement installée dans une VM. Son besoin est typique : un WordPress vitrine, un Nextcloud pour partager des fichiers avec sa petite équipe, et une API PHP maison pour un projet d’école. Sur le papier, c’est trois projets, mais en dessous, c’est la même recette : Apache avec plusieurs VirtualHost, un moteur PHP bien configuré, une instance MariaDB avec des bases séparées. Ce qui change, ce sont les réglages de chaque appli, pas la base LAMPP.
La grande question qui revient souvent est celle du périmètre : jusqu’où faut-il pousser la configuration en développement local ? À mes yeux, un bon compromis consiste à reproduire les grands principes de production, sans tomber dans l’excès : HTTPS activé (même avec des certificats autosignés), séparation claire des dossiers de sites, gestion minimale des logs, et quelques habitudes de sécurité. Si tu veux aller plus loin sur la partie protection des données, un détour par un guide dédié comme ce contenu sur la cybersécurité pour débuter aide à prendre les bons réflexes.
Un dernier point avant de passer à l’installation : ne confonds pas LAMPP « à la main » et les solutions empaquetées type XAMPP. Les suites toutes prêtes rendent service pour des tests rapides, mais elles t’éloignent de la réalité d’un serveur Linux en production. Pour Samir, qui veut comprendre ce qui se passe quand son WordPress rame, construire le stack LAMPP pièce par pièce est un investissement plus rentable. En local, comme en musique, répéter avec le même matériel que sur scène évite les mauvaises surprises.
Installation pas à pas de LAMPP sur Debian ou Ubuntu pour un serveur local de dev
Samir commence par le début : disposer d’un Linux propre, avec les dépôts à jour. Sur Debian ou Ubuntu, la première commande à lancer dans un terminal reste un classique.
sudo apt update
Ça rafraîchit la liste des paquets disponibles. Derrière, l’installation d’Apache se résume à un paquet principal, apache2, qui contient le serveur web et une configuration par défaut déjà fonctionnelle.
sudo apt install -y apache2
Dès la fin de l’installation, Apache est lancé et activé au démarrage. La commande suivante sert surtout à vérifier et forcer ce comportement.
sudo systemctl enable apache2
Samir récupère ensuite l’adresse IP de sa machine avec un simple ip address, puis tape cette IP dans son navigateur, sur son poste principal : il tombe sur la page « Apache2 Debian Default Page ». À ce stade, son serveur local existe déjà, mais il ne fait qu’afficher une page statique depuis /var/www/html.
Côté PHP, il a deux choix. Soit il installe le module Apache intégré (libapache2-mod-php) pour aller au plus vite, soit il passe directement par PHP-FPM. Pour un poste de dev, PHP-FPM reste un meilleur pari, notamment si plusieurs projets tournent en parallèle.
Pour aller vers FPM, il installe d’abord le moteur.
sudo apt install php8.4-fpm
Ensuite, il active les modules Apache nécessaires pour déléguer les scripts PHP à PHP-FPM.
sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.4-fpm
sudo systemctl restart apache2
Un petit php -v lui confirme la version installée, avec PHP 8.4.x, le Zend Engine et OPcache activé. Ce simple contrôle évite pas mal de malentendus, en particulier lorsque plusieurs versions cohabitent ou qu’un ancien paquet traîne sur la machine.
Pour compléter le stack, Samir installe MariaDB. Là encore, apt fait le gros du travail.
sudo apt-get install -y mariadb-server
Une commande de plus et le service se lance automatiquement à chaque démarrage du système.
sudo systemctl enable –now mariadb
La partie délicate commence avec le script de sécurisation de MariaDB. Même sur un serveur local, prendre la mauvaise habitude de laisser un root sans mot de passe ou des utilisateurs anonymes n’est pas une bonne idée. Le script accompagne la configuration point par point.
sudo mariadb-secure-installation
Samir définit un mot de passe root, désactive l’accès root distant, supprime la base de test et les comptes anonymes. Au passage, il découvre que la console MariaDB se récupère avec sudo mariadb -u root -p et que les bases déjà présentes se listent avec un simple SHOW DATABASES;. Quelques minutes suffisent pour valider que son SGBD répond correctement.
Pour y voir plus clair, voici un tableau récapitulatif des paquets et commandes de base qu’il vient de passer.
| Composant | Paquet principal | Commande d’installation | Commande de vérification |
|---|---|---|---|
| Apache | apache2 | sudo apt install -y apache2 | apache2ctl -v |
| PHP (FPM) | php8.4-fpm | sudo apt install php8.4-fpm | php -v |
| Modules PHP | php8.4-mysql, php8.4-curl, etc. | sudo apt install php8.4-{mysql,curl,gd,zip,mcrypt} | php -m |
| MariaDB | mariadb-server | sudo apt-get install -y mariadb-server | mariadb -V |
À ce stade, le serveur local LAMPP tient debout, mais PHP n’est pas encore relié à Apache pour traiter les fichiers .php de façon explicite. Samir crée un fichier /var/www/html/phpinfo.php avec le code suivant :
<?php
phpinfo();
?>
En allant sur http://ip-du-serveur/phpinfo.php, il obtient une longue page violette avec toutes les informations du moteur PHP. C’est un bon test, mais pas un outil à laisser ouvert en permanence, car cette page divulgue énormément de détails sur la configuration. La pratique raisonnable consiste à la garder uniquement le temps du réglage, puis à la supprimer.
Cette première étape donne une base saine. La suite logique consiste à passer d’un Apache « monosite » basique à un serveur web qui gère plusieurs projets avec des VirtualHost bien rangés. C’est là que Samir va vraiment sentir la différence entre un bricolage local et un environnement de développement prêt à accueillir plusieurs applis.
Configuration d’Apache pour plusieurs projets LAMPP sur un même serveur local
Le cœur d’un bon serveur web de développement, c’est l’organisation. Apache possède une structure de configuration assez claire, encore faut-il la comprendre. Sur Debian, le fichier principal se trouve dans /etc/apache2/apache2.conf. Il charge ensuite des bouts de configuration répartis dans d’autres dossiers, dont deux très importants pour Samir : /etc/apache2/sites-available/ et /etc/apache2/sites-enabled/.
Le principe est simple : dans sites-available, on place les fichiers de configuration de tous les sites possibles. Dans sites-enabled, on ne retrouve que des liens symboliques vers ceux qui sont réellement actifs. Par défaut, un seul fichier est présent, 000-default.conf, qui pointe vers /var/www/html sur le port 80. Pour accueillir WordPress, Nextcloud et l’API, Samir décide de créer trois VirtualHost séparés, avec chacun son dossier racine.
Un premier exemple pour WordPress, via un fichier /etc/apache2/sites-available/wordpress.local.conf :
<VirtualHost *:80>
ServerName wordpress.local
DocumentRoot /var/www/wordpress
<Directory /var/www/wordpress>
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
La directive AllowOverride All autorise WordPress à utiliser un fichier .htaccess pour gérer ses propres règles de réécriture d’URL, à condition que le module rewrite soit activé. Samir s’assure donc d’activer les bons modules Apache.
sudo a2enmod rewrite deflate headers ssl http2
sudo systemctl restart apache2
rewrite gère les URLs propres, deflate la compression gzip, headers le contrôle fin des entêtes HTTP, ssl le HTTPS, et http2 le protocole HTTP/2. Même en local, tester un site en HTTP/2 et HTTPS permet de se rapprocher du comportement futur en production. Samir sait que certains plugins WordPress ou certaines libs JavaScript ne réagissent pas pareil selon les protocoles.
Une fois le fichier de VirtualHost écrit, il l’active avec :
sudo a2ensite wordpress.local.conf
sudo systemctl restart apache2
La même logique s’appliquera pour Nextcloud et l’API, avec des noms différents et éventuellement des ports distincts pour éviter les confusions. L’astuce qui change la vie, surtout en équipe, consiste à garder une convention claire pour les noms (par exemple *.local) et à documenter rapidement cette convention dans un petit fichier à la racine du projet ou dans un outil type diagramme Draw.io pour visualiser l’architecture.
Pour relier PHP-FPM à ces VirtualHost, Samir ajoute un bloc FilesMatch dans chaque configuration.
<FilesMatch .php$>
SetHandler « proxy:unix:/run/php/php8.4-fpm.sock|fcgi://localhost/ »
</FilesMatch>
Ce bloc indique à Apache que tout fichier se terminant par .php doit être envoyé au socket Unix de PHP-FPM, qui se trouve ici dans /run/php/php8.4-fpm.sock. Si une prochaine version de PHP arrive (8.5 par exemple), il suffira de modifier cette ligne dans les VirtualHost concernés ou de passer par un alias de socket plus générique.
Au fil de ses expérimentations, Samir découvre aussi un autre outil pratique : a2dissite. Si un projet casse toute la configuration ou s’il veut isoler temporairement un site, il peut désactiver son VirtualHost sans supprimer le fichier.
sudo a2dissite wordpress.local.conf
sudo systemctl reload apache2
Le rechargement Apache à la place du redémarrage évite une coupure brutale des connexions en cours. En développement local ce n’est pas dramatique, mais prendre cette habitude aide quand on basculera sur un vrai serveur distant.
Pour y voir plus clair, Samir dresse une petite checklist pour chaque nouveau projet hébergé sur son LAMPP :
- Créer un dossier dédié dans /var/www/nom-du-projet, avec les bons droits.
- Écrire un VirtualHost dans /etc/apache2/sites-available/ avec ServerName, DocumentRoot et bloc Directory.
- Ajouter le bloc FilesMatch pour lier PHP-FPM, si le site utilise PHP.
- Activer le site avec a2ensite, recharger Apache et tester avec un simple index.php.
- Éventuellement configurer un certificat TLS local si besoin d’HTTPS.
Une fois cette mécanique acquise, héberger plusieurs projets simultanément sur le même serveur local n’a plus rien de magique. C’est juste une question de rigueur dans la configuration Apache.
Affiner PHP et MariaDB dans LAMPP pour un développement local confortable
Une fois Apache proprement configuré, Samir se rend vite compte que le confort au quotidien vient de deux zones souvent négligées : les réglages de PHP et la structure de MariaDB. Un serveur local qui plante sur un upload de 5 Mo ou qui affiche des erreurs blanches incompréhensibles n’encourage pas le debug.
Côté PHP, le fichier de configuration principal dépend de FPM, souvent dans /etc/php/8.4/fpm/php.ini. Les premiers réglages utiles concernent les erreurs. En développement local, masquer les warnings n’a aucun intérêt. Samir ajuste donc :
display_errors = On
display_startup_errors = On
error_reporting = E_ALL
Il paramètre aussi les limites d’upload et la taille maximale de POST pour correspondre à ses cas d’usage. Pour un WordPress qui doit accepter des images de plusieurs Mo, rester sur les valeurs par défaut crée vite des blocages.
upload_max_filesize = 32M
post_max_size = 32M
Après ces changements, un redémarrage de PHP-FPM s’impose.
sudo systemctl restart php8.4-fpm
Côté extensions, Samir a déjà installé php8.4-mysql pour dialoguer avec MariaDB, mais certains projets exigeront php8.4-gd pour manipuler des images, php8.4-curl pour consommer des API ou php8.4-zip pour gérer des archives. Installer des modules au fil des besoins reste une bonne approche, à condition de garder la liste à jour dans un fichier README ou un script d’installation.
Sur MariaDB, l’idée est de ne pas tout faire tourner avec le compte root. Samir se connecte une nouvelle fois à la console.
sudo mariadb -u root -p
Pour son WordPress local, il crée une base et un utilisateur dédiés.
CREATE DATABASE wp_local CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER ‘wp_user’@’localhost’ IDENTIFIED BY ‘motdepasse-solide’;
GRANT ALL PRIVILEGES ON wp_local.* TO ‘wp_user’@’localhost’;
FLUSH PRIVILEGES;
Cette discipline peut sembler exagérée sur un serveur local, mais elle a deux avantages. D’abord, elle force à réfléchir aux permissions réelles de chaque projet. Ensuite, elle facilite la migration vers un serveur de préproduction ou de production, où cette séparation sera obligatoire. Pour un autre projet, par exemple un Nextcloud, la même logique s’applique avec une base et un compte propres.
Un autre point important concerne la version de MariaDB. Sur Debian 13, Samir voit avec un simple mariadb -V qu’il tourne sur la branche 11.x. Tant que ses applis restent dans l’écosystème PHP classique (WordPress, Drupal, Laravel, etc.), la compatibilité ne pose pas de souci. Pour des stacks plus exotiques ou des besoins cloud spécifiques, certains choisiront encore MySQL Server, mais pour un serveur local de dev, MariaDB reste un choix solide et pratique.
Quand Samir commence à réfléchir au déploiement de WordPress sur un Debian remote, il tombe sur un tutoriel qui détaille la procédure et les bonnes pratiques autour de ce CMS. Le guide sur WordPress et Debian lui sert alors de référence pour rapprocher au mieux son environnement local de ce qui tournera ensuite sur Internet. Résultat : moins d’écarts inattendus au moment de migrer.
Au final, ce duo PHP/MariaDB représente la partie vivante de LAMPP. Bien réglés, ils donnent un serveur local fluide, qui remonte des erreurs explicites et supporte sans broncher les tests de charge modestes d’un développeur. Mal réglés, ils se transforment en boîte noire où les requêtes expirent en silence. Dans un cadre de dev, choisir la première option ne coûte presque rien.
Du serveur local LAMPP au quotidien du développement web sous Linux
Une fois la pile LAMPP bien installée et configurée, la vraie question devient : comment l’utiliser dans le flux de travail d’un projet web moderne sous Linux ? Samir a désormais trois sites fonctionnels sur son serveur local et commence à intégrer ce setup dans sa routine de développement.
Pour WordPress, il synchronise régulièrement sa base et ses fichiers avec un dépôt Git (sans les dossiers volumineux de cache ni les uploads bruts). Pour Nextcloud, son usage reste plus personnel, mais le serveur local lui sert de labo pour tester les mises à jour avant de les appliquer à l’instance de l’équipe. Quant à l’API PHP, elle sera consommée par un front en JavaScript, mais tout tourne en local, sur la même machine Linux, ce qui réduit les latences et simplifie le debug réseau.
Dans ce genre de configuration, un outil de prise de main distante comme TeamViewer ou RustDesk peut s’avérer utile, surtout si le serveur local est une machine dédiée posée dans un coin. Les tutoriels disponibles sur des outils comme TeamViewer en usage gratuit ou RustDesk donnent des repères pour gérer ce type de situation sans multiplier les écrans. Samir choisit finalement une simple connexion SSH avec port forwarding, mais l’idée reste la même : accéder au serveur web local sans être physiquement devant la machine.
Un autre point qui change la donne, c’est la gestion des environnements. Au lieu d’avoir un seul LAMPP pour tous ses projets, Samir commence à cloisonner : une VM Debian par gros projet, ou au moins des VirtualHost nettement séparés, des bases nommées de façon explicite et des ports différenciés pour certains tests. Cela évite les collisions de dépendances ou les conflits de version PHP, même si Debian 13 reste plutôt souple de ce côté-là grâce à ses paquets.
En travaillant avec cette approche, Samir se rend compte qu’il gagne du temps à chaque nouvelle fonctionnalité testée. Un plugin WordPress douteux à essayer ? Il le branche sur le site de dev en local, observe les logs d’Apache dans /var/log/apache2 et les erreurs PHP, ajuste si besoin, puis seulement ensuite l’installe sur la version de préproduction. Son serveur local LAMPP devient un terrain d’expérimentation contrôlé, qui lui permet de dire « oui » à plus de demandes de tests, sans mettre en danger un environnement réel.
Cette façon de travailler se marie bien avec d’autres pratiques modernes : containers, orchestrateurs, intégration continue. Par exemple, certains projets tournent sous Docker avec un stack nginx + PHP-FPM + MariaDB, tandis que LAMPP reste la base simple pour des tests rapides ou pour comprendre un bug spécifique. Le tutoriel dédié à WordPress sous Docker avec MariaDB et Nginx montre un autre angle, mais l’esprit reste le même : Linux comme socle, moteur PHP, base SQL et serveur web qui distribue le tout.
En résumé, un serveur local LAMPP bien pensé ne se résume pas à une démonstration technique : c’est un compagnon de route qui structure le développement, aide à anticiper les problèmes de production et donne confiance au moment de livrer. Une fois qu’on y a goûté sérieusement, coder directement sur le FTP d’un hébergeur paraît aussi anachronique qu’écrire un roman dans l’interface d’un formulaire web sans sauvegarde.
Quelle différence entre LAMPP, LAMP et XAMPP sur Linux ?
LAMP désigne la pile Linux + Apache + MariaDB/MySQL + PHP installée via les paquets natifs de la distribution. LAMPP est parfois utilisé pour insister sur le côté pack complet sur un serveur local, mais techniquement on parle du même empilement. XAMPP, lui, est un package précompilé qui embarque Apache, MariaDB, PHP et d’autres outils dans un bundle indépendant du système. Pour un usage pédagogique et proche de la production sous Linux, installer LAMP/LAMPP avec apt reste plus intéressant que XAMPP, qui masque une partie de la configuration réelle du serveur.
Pourquoi privilégier PHP-FPM à libapache2-mod-php sur un serveur local ?
PHP-FPM sépare le moteur PHP du processus Apache, ce qui améliore souvent la gestion des ressources, la stabilité et la flexibilité. Même en développement local, cette approche prépare mieux au monde réel, où PHP-FPM est de plus en plus la norme. Le module libapache2-mod-php est plus simple à mettre en place, mais mélange les rôles dans le même processus et complique l’évolution vers d’autres architectures (Nginx, containers, etc.). Pour des sites à faible trafic, il fonctionne encore, mais PHP-FPM offre un terrain d’apprentissage plus pertinent en 2026.
Est-ce utile de sécuriser MariaDB sur un serveur de développement local ?
Oui, au moins sur les points de base. Définir un mot de passe root, supprimer les comptes anonymes et désactiver l’accès root distant via le script mariadb-secure-installation prend quelques minutes et évite de prendre de mauvaises habitudes. Même en local, des services exposés par erreur, des sauvegardes mal gérées ou des partages non maîtrisés peuvent ouvrir des portes inutiles. S’habituer à travailler avec des comptes dédiés par base rend aussi la migration vers des environnements plus sensibles beaucoup plus simple.
Comment vérifier rapidement que PHP est bien relié à Apache dans LAMPP ?
La méthode la plus directe consiste à créer un fichier phpinfo.php dans le DocumentRoot du site, contenant simplement , puis à y accéder via le navigateur. Si la page d’informations PHP s’affiche, la liaison Apache/PHP est correcte. En revanche, si le code brut apparaît ou si un téléchargement se lance, cela signifie qu’Apache ne passe pas le fichier au moteur PHP. Dans ce cas, il faut vérifier le bloc FilesMatch lié à PHP-FPM ou la présence du module PHP pour Apache, selon la méthode choisie.
Peut-on utiliser LAMPP pour héberger un site en production définitive ?
Techniquement, oui, mais ce n’est pas conseillé de reprendre tel quel une configuration de développement pour de la production. Un serveur destiné à être exposé sur Internet demande des réglages supplémentaires : durcissement de la configuration Apache, gestion fine des permissions de fichiers, mises à jour suivies, pare-feu configuré, sauvegardes testées, monitoring, etc. LAMPP sert surtout de base pour comprendre et tester. Rien n’empêche ensuite d’adapter ces connaissances à un serveur de production plus strictement sécurisé et supervisé.
