Vous avez choisi votre CMS. WordPress ou Joomla, peu importe. Vous avez même réussi à le faire tourner sur votre machine, et là, le mur : comment est-ce que ce truc atterrit sur un vrai serveur, avec un vrai nom de domaine, et une vraie URL qui ne ressemble pas à 192.168.1.42/wordpress ?
C'est la question qu'on me pose le plus souvent quand j'aide quelqu'un à lancer son premier site. Et c'est précisément le point que la plupart des guides sautent. Ils vous expliquent ce qu'est un CMS (merci, on avait compris), comparent les fonctionnalités, puis s'arrêtent net au moment où ça devient intéressant. Le déploiement, la vraie mise en ligne, celle qui demande de toucher à un terminal, une base de données et un fichier de config, reste dans l'ombre.
Je vais vous raconter comment je m'y prends, sans rien omettre. Y compris les deux fois où j'ai tout cassé et où j'ai dû recommencer à zéro.
Points clés à retenir
- Un CMS ne se déploie pas « en un clic » — sauf si vous acceptez de dépendre entièrement de votre hébergeur.
- WordPress et Joomla ont des prérequis serveur différents : PHP, MySQL/MariaDB, extensions. Les ignorer, c'est se condamner à une page blanche.
- La méthode la plus fiable : build en local, migration vers le serveur de production, puis bascule DNS.
- Le certificat SSL et la redirection HTTPS ne sont pas optionnels en 2026, même pour un blog personnel.
- Un déploiement propre prend 2 à 4 heures la première fois. La deuxième, trente minutes.
Le mot-clé ici, c'est déployer. Pas « installer », pas « créer ». Déployer implique un mouvement : du local vers le distant, du brouillon vers le public. C'est cette étape que je vais détailler.
Déployer un site web avec un CMS : la partie que tout le monde zappe
Quand j'ai lancé mon premier site sous Joomla, je pensais naïvement qu'il suffisait de cliquer sur « Installer » dans le panneau de l'hébergeur. Techniquement, c'était vrai. Le site était en ligne vingt minutes plus tard. Mais le lendemain matin, j'avais une page blanche, une erreur 500 et aucune idée de ce qui s'était passé.
La raison ? J'avais utilisé la version PHP par défaut du serveur, qui était trop ancienne pour la version de Joomla que j'avais déployée. Le CMS avait installé sans broncher, puis s'était arrêté net dès qu'il avait essayé d'exécuter une fonctionnalité moderne.
Franchement, ce genre de chose arrive à tout le monde. Et ça n'a rien à voir avec le choix du CMS. Ça a à voir avec la préparation en amont.
Les prérequis techniques qu'on ne vous dit jamais
Avant de déployer quoi que ce soit, vérifiez trois choses auprès de votre hébergeur. Pas après. Avant.
- La version de PHP. WordPress exige au minimum PHP 7.4, et la version recommandée en 2026 tourne autour de PHP 8.2 ou 8.3. Joomla 5, de son côté, ne supporte plus du tout les versions antérieures à PHP 8.1. Si votre hébergeur propose encore du 7.2 par défaut, changez d'hébergeur.
- Le serveur de base de données. MySQL 5.7 minimum pour WordPress, MariaDB 10.4 ou plus pour Joomla 5. Les versions antérieures provoquent des erreurs silencieuses.
- Les extensions PHP obligatoires. mysqli, curl, gd, mbstring, xml, zip. Certains hébergeurs bas de gamme les désactivent pour économiser des ressources.
Un point qu'on oublie souvent : Joomla est plus exigeant que WordPress sur les prérequis serveur, mais il est moins gourmand en ressources une fois installé. Sur un hébergement mutualisé à 3 euros par mois, Joomla tourne souvent mieux qu'un WordPress chargé de quinze extensions.
Faut-il déployer en local d'abord, ou directement sur le serveur ?
Ça dépend de votre tolérance au risque.
Déployer directement sur le serveur de production, c'est rapide. Vous créez la base de données via le panneau de l'hébergeur, vous uploadez les fichiers, vous lancez l'installateur dans le navigateur, et c'est parti. J'ai fait ça pendant des années sur des sites simples. Ça marche. Mais dès que vous voulez tester une extension, modifier un thème, changer la structure des URL, vous le faites en direct, sur un site que des gens consultent. Une erreur de manipulation, et votre site tombe pendant que vous cherchez la cause.
La méthode que je recommande maintenant, et que j'aurais dû adopter dès le début : construire en local, déployer une fois que tout fonctionne.
Concrètement, vous installez votre CMS sur votre machine, via un environnement comme LocalWP (pour WordPress) ou XAMPP (qui fonctionne pour les deux). Vous travaillez tranquillement, vous cassez des choses, vous réparez. Quand le site vous convient, vous migrez.
La migration elle-même repose sur trois briques : les fichiers, la base de données, et la configuration.
- Exporter la base locale en fichier .sql, via phpMyAdmin ou en ligne de commande avec
mysqldump. - Uploader les fichiers par FTP ou SFTP dans le répertoire public de votre hébergement.
- Importer la base dans la base de données que vous avez créée chez l'hébergeur, puis éditer le fichier de configuration (
wp-config.phppour WordPress,configuration.phppour Joomla) pour pointer vers les bons identifiants.
Le piège classique, celui qui m'a coûté une soirée entière la première fois : les URL stockées dans la base de données. Votre site local répond à localhost/monsite, mais en production, il doit répondre à monsite.com. Si vous ne remplacez pas ces chaînes dans la base, tous vos liens pointent vers localhost. Il existe des scripts de recherche-remplacement, ou vous pouvez le faire manuellement dans phpMyAdmin. Ne sautez pas cette étape.
Joomla vs WordPress : ce qui change vraiment au déploiement
On lit partout que WordPress est plus simple que Joomla. Dans la pratique, au moment du déploiement, la différence est marginale. Les deux vous demandent un serveur compatible, une base de données et un fichier de configuration à éditer. Ce qui change, c'est la quantité d'aide disponible quand ça coince.
WordPress a une communauté plus large. Quand votre site plante après une mise à jour, vous trouvez une réponse en dix minutes sur un forum. Joomla a une communauté plus petite mais techniquement solide. La réponse est souvent meilleure, mais elle prend deux heures à arriver.
Un autre point : le système de templates. WordPress utilise un thème que vous pouvez remplacer à tout moment sans perdre votre contenu. Joomla a une structure un peu plus rigide — les templates sont liés à des positions de modules, et changer de template peut casser la mise en page. Sur un site en production, cette différence se ressent.
| Critère | WordPress | Joomla |
|---|---|---|
| Version PHP minimale | 7.4 (8.2 recommandé) | 8.1 (8.3 recommandé) |
| Base de données | MySQL 5.7+ ou MariaDB 10.3+ | MySQL 8.0+ ou MariaDB 10.4+ |
| Fichier de configuration à éditer | wp-config.php | configuration.php |
| Migration local → production | Simple, outils nombreux | Simple, mais moins documenté |
| Communauté d'entraide | Très large | Plus restreinte, plus technique |
| Gourmandise en ressources | Modérée à élevée selon extensions | Modérée |
Mon avis, et je l'assume : pour un premier déploiement, prenez WordPress. Pas parce qu'il est meilleur, mais parce que quand vous serez bloqué à 23 h avec une page blanche, vous trouverez plus vite quelqu'un qui a vécu exactement la même chose. Une fois que vous maîtrisez le processus, Joomla devient un excellent choix, notamment pour les sites avec une structure de contenu complexe.
La mise en production : DNS, SSL et redirections
Vos fichiers sont en ligne, votre base est importée, votre site répond à l'adresse IP du serveur. Il reste trois étapes que les tutoriels expédient souvent en une ligne, alors qu'elles méritent qu'on s'y attarde.
Pointer le domaine vers le serveur
Chez votre registrar (là où vous avez acheté le nom de domaine), vous devez modifier les enregistrements DNS. Concrètement, un enregistrement A qui pointe vers l'adresse IP de votre hébergement. Si vous utilisez un sous-domaine, c'est un enregistrement CNAME.
La propagation DNS prend entre quelques minutes et 24 heures. C'est frustrant, mais il n'y a rien à faire à part attendre. Si votre site n'est pas accessible immédiatement, ce n'est pas forcément une erreur de configuration.
Le certificat SSL, non négociable
En 2026, un site sans HTTPS est signalé comme « non sécurisé » par tous les navigateurs. Pour un blog personnel, c'est déjà pénalisant. Pour un site marchand, c'est éliminatoire : Google Chrome affiche un avertissement rouge avant même que le visiteur voie votre page.
La bonne nouvelle : la plupart des hébergeurs proposent Let's Encrypt gratuitement. Vous l'activez depuis leur panneau, ça prend deux clics. Vérifiez ensuite que le CMS est bien configuré pour utiliser HTTPS. Sur WordPress, l'URL du site dans les réglages doit commencer par https://, sinon vous aurez des avertissements de contenu mixte.
Redirection et canonicalisation
Un détail qui m'a valu trois semaines de confusion sur mes statistiques de visites : monsite.com et www.monsite.com sont considérés comme deux sites différents par les moteurs de recherche. Il faut choisir l'un et rediriger l'autre.
La redirection se fait au niveau du serveur, dans un fichier .htaccess (Apache) ou dans la configuration Nginx. Un simple bloc de règles suffit, et la plupart des hébergeurs mutualisés proposent une option dans leur panneau pour activer la redirection automatiquement.
Je sais, c'est fastidieux. Mais un site déployé sans cette étape, c'est comme un magasin avec deux entrées qui mènent à deux comptoirs différents. Les clients se perdent.
Les erreurs qui m'ont coûté le plus cher
Deux erreurs, concrètement, qui m'ont fait perdre du temps et, une fois, des données.
La première : j'ai déployé un site sans activer les sauvegardes automatiques chez l'hébergeur. Trois mois plus tard, une mise à jour d'extension a corrompu la base. J'avais bien un export vieux de six semaines. J'ai perdu six semaines de commentaires et d'articles. Depuis, j'active les sauvegardes quotidiennes avant de toucher au moindre fichier.
La seconde : sur un site Joomla en production, j'ai voulu tester un template directement sur le serveur. Mauvaise idée. Le template a écrasé les positions de modules existantes, et j'ai mis une journée à reconstituer l'affichage. Aujourd'hui, je garde systématiquement une copie locale du site en état de marche, et je ne modifie jamais un template en production sans sauvegarde préalable.
Ces erreurs sont banales. C'est un peu le prix d'entrée. Mais elles m'ont appris une chose : le déploiement n'est pas un événement ponctuel, c'est un cycle. On déploie, on met à jour, on migre, on redéploie. Chaque mise à jour majeure d'un CMS est un mini-déploiement qui peut casser le site. Prévoyez-le.
Combien de temps ça prend, vraiment
La première fois, comptez une demi-journée. Trois à quatre heures si tout se passe bien, une journée entière si vous rencontrez un obstacle. Les obstacles les plus fréquents : mauvais prérequis PHP, base de données mal configurée, chemins absolus dans la base de données.
La deuxième fois, trente à quarante-cinq minutes. Une fois que vous avez compris la logique, c'est répétitif.
La troisième fois, vous scripterez le processus et il prendra dix minutes. C'est à ce moment-là que vous comprendrez pourquoi les développeurs parlent de « déploiement continu » et pourquoi c'est considéré comme une compétence à part entière. Déployer un site, c'est un savoir-faire qui s'acquiert.
Après le premier déploiement, le vrai travail commence
Un site en ligne n'est pas un site terminé. C'est un site qui a commencé à vivre. Vous allez découvrir les lenteurs que vous n'aviez pas remarquées en local, les erreurs 404 sur des liens que vous croyiez valides, les formulaires de contact qui n'envoient rien parce que le serveur mail n'est pas configuré.
C'est normal. Le déploiement n'est pas la ligne d'arrivée, c'est la rampe de lancement. Et une fois que vous aurez fait ce trajet deux ou trois fois, vous ne le verrez plus comme un obstacle technique. Vous le verrez comme une étape parmi d'autres, celle qui relie votre travail à ses lecteurs.
Ce qui reste, au fond, c'est une question de méthode. WordPress ou Joomla, local ou direct, mutualisé ou VPS — les variables changent, la logique reste la même : préparer, tester, déployer, surveiller. La première fois, on apprend. La deuxième, on maîtrise. La troisième, on oublie qu'on a un jour eu peur d'un fichier configuration.php.
