Comment déployer un site Joomla sans intervenir directement en production

Dans un audit technique, je préfère presque une page blanche immédiate à un formulaire cassé silencieusement. Une page blanche se voit. Un formulaire qui n’envoie plus rien peut rester invisible pendant plusieurs jours. C’est plus poli, mais beaucoup plus coûteux.

La sécurité entre aussi dans l’équation. Une mise en production mal maîtrisée peut rouvrir des droits fichiers, désactiver une protection, exposer un répertoire ou laisser une extension vulnérable en place. Pour ce sujet précis, mieux vaut compléter avec notre article sur les bonnes pratiques pour sécuriser un site Joomla.

Les différents environnements à prévoir

Pas besoin de transformer chaque site Joomla en plateforme DevOps avec quinze pipelines, trois acronymes et une réunion hebdomadaire pour nommer les branches. En revanche, il faut séparer les usages.

Un environnement sert à développer. Un autre à intégrer. Un autre à tester comme si l’on était en production. Et la production sert à produire. Dit comme ça, c’est presque trop simple. Dans la vraie vie, beaucoup de problèmes viennent du fait qu’on mélange tout.

1. L’environnement local ou développement

L’environnement local sert au travail technique. C’est là que l’on développe, corrige, teste rapidement, modifie une surcharge ou prépare une extension spécifique.

On y travaille notamment :

• les fichiers du template ;
• les surcharges Joomla ;
• les extensions développées sur mesure ;
• les scripts techniques ;
• les corrections de bugs reproductibles ;
• les essais qui n’ont aucune raison d’être faits sur le site public.

Le local n’a pas besoin d’être une copie parfaite de la production. Il doit surtout permettre de travailler proprement, de versionner et de ne pas tester sur le dos des utilisateurs.

2. L’environnement d’intégration

L’intégration devient utile dès que plusieurs personnes interviennent : développeur, agence, administrateur, intégrateur, prestataire SEO, équipe métier. Elle permet de vérifier que les modifications se combinent correctement avant de passer en préproduction.

C’est particulièrement utile pour les sites Joomla qui utilisent des développements spécifiques, des surcharges nombreuses, un template personnalisé ou des extensions connectées à d’autres services.

3. Le staging ou environnement de préproduction Joomla

Le staging est l’environnement qui doit ressembler le plus possible à la production. C’est lui qui permet de tester une livraison dans des conditions réalistes, sans exposer les visiteurs.

Un bon environnement de préproduction Joomla doit idéalement reprendre :

• la même version de PHP ;
• un moteur de base de données équivalent ;
• une configuration serveur proche ;
• les mêmes extensions Joomla ;
• le même template ;
• les mêmes surcharges ;
• une copie récente de la base, anonymisée si nécessaire ;
• un comportement proche pour le cache, les emails et les tâches planifiées.

C’est en staging que l’on teste les mises à jour, les formulaires, les emails, les droits, les menus, les pages multilingues, les performances visibles et les scénarios métier. Pour les contrôles plus larges avant publication, notre checklist technique avant mise en ligne peut servir de base complémentaire.

4. La production

La production ne sert pas à “voir si ça passe”. Elle sert à livrer une version déjà testée.

Le jour du déploiement, les gestes doivent être connus : sauvegarde, mise en maintenance si nécessaire, livraison des fichiers, opérations éventuelles sur la base, purge de cache, tests, surveillance, décision de conserver ou de revenir en arrière.

Un bon déploiement Joomla est presque ennuyeux. C’est exactement ce que l’on veut. Les grands frissons, on les garde pour autre chose.

Que faut-il versionner avec Git ?

Git n’est pas réservé aux grosses applications. Sur un site Joomla, il permet de savoir ce qui a changé, qui l’a changé, pourquoi, et comment revenir à une version précédente des fichiers. C’est déjà beaucoup.

Sans Git, on finit parfois avec des dossiers nommés template-new, template-old, template-final, template-final-vraiment-final. J’ai vu pire. Je n’en suis pas sorti grandi.

Les éléments Joomla à versionner

Dans un dépôt Git Joomla, on versionne principalement ce qui relève du code, de la configuration technique non sensible et de la documentation.

• Le template : fichiers PHP, CSS, JavaScript, assets sources, fichiers de structure.
• Les surcharges : overrides de composants, modules, layouts et vues.
• Les extensions développées sur mesure : composants, modules, plugins ou librairies spécifiques.
• Les fichiers de configuration non sensibles : exemples de configuration, paramètres génériques, fichiers de référence.
• Les scripts de déploiement : commandes, scripts shell, tâches de build ou procédures automatisées.
• La documentation technique : installation, dépendances, variables d’environnement, procédure de rollback.

Les éléments à ne pas mettre directement dans Git

Un dépôt Git n’est pas une benne. Certains fichiers n’ont rien à y faire, surtout si plusieurs personnes y ont accès.

• mots de passe ;
• clés API ;
• fichiers de configuration propres à la production ;
• fichiers de cache ;
• journaux d’erreurs ;
• médias volumineux ;
• sauvegardes complètes ;
• exports de base de données contenant des données personnelles.

Le cas sensible du fichier configuration.php

Le fichier configuration.php contient des informations propres à l’environnement : base de données, chemins serveur, paramètres SMTP, cache, parfois d’autres éléments sensibles. Il ne doit pas être versionné tel quel dans un dépôt partagé.

Une méthode plus propre consiste à versionner un fichier d’exemple, par exemple configuration.example.php, puis à gérer les vraies valeurs par environnement. Ce n’est pas très spectaculaire, mais c’est ce genre de détail qui évite de retrouver un mot de passe de production dans un dépôt. Et là, tout le monde dort mieux.

Versionner pour comprendre, pas pour collectionner

La règle est simple : versionnez ce que vous devez pouvoir relire, comparer, restaurer et déployer. Excluez ce qui est confidentiel, généré automatiquement, trop volumineux ou propre à un serveur.

Comment gérer la base de données et les fichiers médias ?

Voici le point qui différencie un vrai déploiement Joomla d’un simple transfert de fichiers.

Déployer du code est relativement simple. Déployer une base de données vivante, des utilisateurs, des commandes, des documents, des contenus modifiés par plusieurs personnes et des données d’extensions, c’est une autre histoire. Une histoire qui finit mal si l’on écrase la production avec une copie de préproduction sans réfléchir.

Les données qui changent en production

Avant de déployer, il faut identifier ce qui évolue en continu sur le site :

• articles et catégories modifiés par les contributeurs ;
• utilisateurs créés récemment ;
• commandes et paiements ;
• messages de formulaires ;
• inscriptions à une newsletter ;
• documents ajoutés dans un espace privé ;
• données d’extensions métier ;
• paramètres modifiés depuis l’administration ;
• logs utiles au diagnostic.

Sur un site vitrine peu édité, on peut parfois prévoir un gel éditorial court. Sur un site e-commerce, extranet ou portail métier, c’est beaucoup plus sensible. Perdre un article brouillon est désagréable. Perdre des commandes ou des comptes clients, c’est un autre sport.

Adapter la méthode au type de site Joomla

La synchronisation des fichiers médias

Les médias ne sont pas toujours adaptés à Git. Images, PDF, documents privés, fichiers générés, factures, exports : tout cela peut être volumineux, sensible ou mis à jour directement depuis l’administration Joomla.

Avant une mise en production, il faut vérifier :

• les images ajoutées depuis la dernière copie de staging ;
• les PDF et documents privés ;
• les droits d’accès aux dossiers ;
• les chemins utilisés dans les contenus ;
• les miniatures générées par des extensions ;
• les fichiers liés aux commandes, factures ou espaces clients.

Pour les sites marchands, la sauvegarde et la conservation des données transactionnelles demandent une vigilance particulière. Le sujet est détaillé dans notre article sur la sauvegarde automatique d’une boutique Joomla.

Les scripts de migration : utiles quand la base change

Quand une livraison modifie la structure des données, un script de migration vaut souvent mieux qu’une manipulation manuelle répétée. Il peut ajouter une colonne, convertir un format, corriger des chemins, ajuster des paramètres ou préparer une extension métier.

Un script de migration doit être testé en préproduction sur une copie récente. Il doit aussi être documenté : ce qu’il change, dans quel ordre, avec quels critères de succès et quelle stratégie de retour arrière.

La technologie n’est pas le sujet principal. Le sujet, c’est de savoir exactement ce que l’on modifie. Si personne ne sait ce que le script change, ce n’est pas un script de migration. C’est une incantation.

La procédure avant mise en production

Une mise en production Joomla doit suivre une procédure. Même courte. Même pour une “petite mise à jour”. Surtout pour une petite mise à jour, d’ailleurs, parce que c’est souvent là que l’on baisse la garde.

Voici une checklist opérationnelle à adapter selon la criticité du site.

Cette checklist ne remplace pas une recette complète avant lancement. Elle la complète. Pour une vision plus générale des contrôles avant ouverture ou remise en ligne d’un site, consultez aussi notre checklist technique avant mise en ligne.

Contrôler les extensions avant de livrer

Les extensions Joomla sont souvent le point sensible d’un déploiement. Formulaire, e-commerce, paiement, SEO, cache, sécurité, multilingue, recherche interne, page builder, connecteur CRM : chaque extension peut avoir son propre cycle de mise à jour, ses dépendances et ses petites surprises.

Avant une mise en production, vérifiez :

• la version installée ;
• la compatibilité avec la version cible de Joomla ;
• la compatibilité avec la version PHP ;
• l’état de maintenance de l’éditeur ;
• les notes de version ;
• les changements de configuration ;
• les impacts sur la base de données ;
• les dépendances éventuelles avec d’autres plugins.

Une extension critique non maintenue n’est pas un détail. C’est une dette technique avec une date d’échéance inconnue. Et les dettes techniques, elles ont une passion : se rappeler à vous quand le planning est déjà plein.

Tester la restauration, pas seulement la sauvegarde

Une sauvegarde qui n’a jamais été restaurée ressemble à une assurance dont personne n’a lu le contrat. Elle rassure, jusqu’au moment où l’on doit vraiment l’utiliser.

Avant une mise en production importante, il faut savoir :

• où se trouve la sauvegarde ;
• ce qu’elle contient exactement ;
• combien de temps prend une restauration ;
• qui peut la lancer ;
• quelles données peuvent être perdues en cas de retour arrière ;
• comment vérifier que la restauration est correcte.

Comment organiser un plan de rollback ?

Un plan de rollback, ou plan de retour arrière, définit comment revenir à l’état précédent si le déploiement échoue. Ce n’est pas pessimiste. C’est professionnel.

Le rollback ne doit pas être imaginé pendant que le site affiche une erreur 500 et que trois personnes demandent “on fait quoi ?”. À ce moment-là, la documentation a rarement le bon goût de s’écrire toute seule.

Définir les conditions qui déclenchent le retour arrière

Avant la livraison, il faut décider ce qui déclenche un rollback :

• site inaccessible ;
• administration Joomla inaccessible ;
• formulaires critiques hors service ;
• paiement impossible ;
• erreurs PHP bloquantes ;
• régression majeure sur mobile ;
• perte d’accès pour les utilisateurs connectés ;
• erreurs sur des pages stratégiques ;
• temps de correction supérieur au délai acceptable.

Sans critères, on perd du temps à hésiter. On corrige un peu, on vide le cache, on recharge, on tente une autre piste. Pendant ce temps, la production reste instable. Ce n’est pas une procédure, c’est une partie de pêche.

Restaurer les fichiers

La restauration des fichiers peut passer par Git, une archive, une sauvegarde hébergeur ou un outil de déploiement. L’important est de savoir quelle version restaurer.

Avec Git, il est utile de taguer l’état de production avant déploiement. Un tag comme prod-avant-deploiement-2026-07-12 est moins poétique qu’un nom de branche créatif, mais beaucoup plus pratique quand il faut revenir vite.

Restaurer la base de données sans perdre les données récentes

La base de données est souvent le vrai sujet du rollback. Restaurer une base complète peut supprimer des données créées après le déploiement : commandes, comptes, messages, inscriptions, contenus.

Pour un site actif, il faut prévoir une stratégie :

• mise en maintenance courte pendant l’opération ;
• export des tables critiques avant rollback ;
• conservation des commandes ou formulaires reçus ;
• journalisation des actions réalisées ;
• décision claire sur les données acceptables ou non à perdre.

Sur un site vitrine, la restauration peut être assez simple. Sur un site e-commerce ou extranet, elle demande un vrai arbitrage métier. Le bouton magique “tout remettre comme avant sans perdre ce qui s’est passé depuis” n’existe pas toujours. C’est contrariant, mais autant le savoir avant.

Désigner la personne qui décide

Un rollback doit avoir un responsable de décision : développeur, chef de projet, DSI, responsable métier ou direction selon le contexte.

Cette personne doit connaître :

• les fonctions critiques du site ;
• le temps maximal acceptable d’indisponibilité ;
• les impacts métier ;
• les risques de perte de données ;
• les personnes à prévenir ;
• le moment où l’on arrête de corriger pour revenir en arrière.

La décision ne doit pas dépendre de l’optimisme du développeur à 23 h 40. L’optimisme, c’est agréable. Ce n’est pas un plan de continuité.

Les tests à effectuer après le déploiement

Une fois la mise en production terminée, il ne suffit pas de regarder la page d’accueil et de déclarer victoire. Beaucoup de problèmes Joomla apparaissent ailleurs : administration, formulaires, modules conditionnels, langues, emails, paiement, logs.

Il faut tester comme un visiteur, comme un administrateur, comme un client et comme un technicien. Oui, ça fait plusieurs casquettes. Non, la casquette “ça a l’air bon” ne suffit pas.

Les performances doivent aussi être surveillées après une livraison, surtout si le template, le cache, les extensions ou la version PHP ont changé. Pour ce volet, notre article sur l’audit de performance Joomla complète utilement cette procédure.

Surveiller après la livraison

Les premières minutes ne disent pas tout. Certaines erreurs apparaissent après expiration du cache, lors d’une tâche planifiée, au moment d’un paiement réel ou après l’action d’un utilisateur connecté.

Après un déploiement sensible, surveillez :

• les logs d’erreurs ;
• les formulaires reçus ;
• les transactions ;
• les alertes de monitoring ;
• les retours utilisateurs ;
• les statistiques de trafic et de conversion ;
• les éventuelles erreurs remontées dans Search Console.

Exemple de procédure pour une mise à jour majeure de Joomla

Prenons un cas concret : préparer une mise à jour majeure de Joomla 5.4 vers Joomla 6. L’objectif ici n’est pas de détailler toute la migration. Pour cela, nous avons déjà un article dédié : Passer de Joomla 5.4 à Joomla 6.0 : checklist avant mise à jour.

Ici, ce qui nous intéresse, c’est l’organisation de la livraison. Une mise à jour majeure touche souvent plus que le noyau Joomla : extensions, template, surcharges, PHP, base de données, comportements dépréciés, tâches automatisées. Si le site a vécu longtemps sans documentation, on commence par faire l’inventaire. Si personne ne sait comment c’est câblé, ce n’est pas une architecture. C’est une devinette.

1. Cadrer le périmètre

• version Joomla actuelle ;
• version cible ;
• version PHP et base de données ;
• liste des extensions installées ;
• liste des extensions critiques ;
• template et framework utilisés ;
• surcharges personnalisées ;
• fonctions métier à tester ;
• connexions externes : CRM, paiement, newsletter, API, SSO.

2. Créer ou actualiser la préproduction

On crée un staging avec une copie récente du site. Les données personnelles doivent être traitées avec prudence : anonymisation, restriction d’accès, désactivation des emails sortants, blocage de l’indexation.

Avant toute mise à jour, on vérifie que la préproduction fonctionne déjà correctement. Sinon, on risque de confondre un problème de copie avec un problème de migration.

3. Jouer la mise à jour en staging

La mise à jour majeure est testée en préproduction. On surveille :

• les messages de pré-mise à jour ;
• les extensions incompatibles ;
• les erreurs PHP ;
• les comportements du template ;
• les surcharges ;
• les formulaires ;
• les pages multilingues ;
• les droits utilisateurs ;
• les fonctions métier spécifiques.

Joomla documente les changements entre versions, notamment pour les développeurs et les mainteneurs de sites avec code spécifique. Les notes de migration officielles indiquent les changements de code et les incompatibilités à anticiper entre Joomla 5.4 et 6.0.

4. Corriger, versionner, rejouer

Si des erreurs sont trouvées, on corrige en local ou en intégration, on versionne dans Git, puis on rejoue le scénario en staging. Le but est de rendre la procédure répétable.

Une correction faite directement sur la préproduction sans être versionnée a toutes les chances d’être oubliée au moment de livrer. Et une correction oubliée a une patience remarquable : elle attend tranquillement le passage en production pour se rappeler à vous.

5. Préparer la fenêtre de production

Avant le jour J, on prépare :

• la sauvegarde complète ;
• le tag Git de la version actuelle ;
• les fichiers à livrer ;
• les commandes ou scripts à exécuter ;
• les tests post-déploiement ;
• le plan de rollback ;
• les personnes disponibles ;
• le message éventuel de maintenance ;
• le canal de décision en cas d’incident.

6. Déployer, tester, décider

Le jour du déploiement, l’équipe suit la procédure. Si les tests critiques passent, la version reste en production. Si un point bloquant apparaît et dépasse le délai accepté, le rollback est déclenché.

Le succès d’une mise à jour majeure Joomla ne se mesure pas uniquement au message “mise à jour terminée”. Il se mesure au fait que les visiteurs, administrateurs, formulaires, contenus, paiements et fonctions métier continuent de fonctionner après livraison.

Notre méthode pour sécuriser un déploiement Joomla

Chez TooNetCreation, nous abordons un déploiement Joomla comme un sujet d’architecture et d’exploitation, pas comme une simple opération de transfert de fichiers.

Avant de toucher à la production, nous cherchons à comprendre le site : son historique, ses extensions, ses surcharges, son hébergement, ses dépendances, ses contributeurs, ses données sensibles et ses fonctions critiques. Un site Joomla ancien peut très bien tourner correctement. Mais s’il n’est pas documenté, pas sauvegardé proprement et pas testé hors production, il repose souvent sur une dette technique. Et une dette technique, ça ne disparaît pas parce qu’on évite de la regarder.

Selon le contexte, notre accompagnement peut couvrir :

• la mise en place d’un environnement de préproduction Joomla ;
• la structuration d’un dépôt Git ;
• l’audit des extensions et surcharges ;
• la préparation d’une mise à jour majeure ;
• la documentation de la procédure de livraison ;
• la stratégie de sauvegarde et de restauration ;
• la définition du plan de rollback ;
• les tests post-déploiement ;
• la maintenance corrective et préventive.

Un déploiement bien préparé ne rend pas le site invincible. Il permet surtout de réduire les risques, de savoir quoi faire si quelque chose casse, et d’éviter les décisions improvisées en production.

Vous préparez une mise à jour Joomla, une refonte technique ou une livraison sensible sur un site métier ? Nous pouvons auditer l’existant, sécuriser la procédure et vous aider à déployer sans travailler directement sur le fil de la production.

Parler de votre procédure de déploiement Joomla

FAQ sur le déploiement Joomla

Faut-il toujours un environnement de staging pour Joomla ?

Pour un site professionnel, oui. Même léger, un environnement de préproduction permet de tester les mises à jour, extensions, formulaires, surcharges et changements serveur sans exposer les visiteurs. Pour un petit site peu critique, le staging peut rester simple, mais il doit exister.

Peut-on gérer un site Joomla avec Git ?

Oui. Git est utile pour versionner le template, les surcharges, les extensions spécifiques, les scripts et la documentation technique. En revanche, il ne faut pas y stocker les mots de passe, sauvegardes, fichiers de cache, logs ou médias volumineux.

Pourquoi la base de données complique-t-elle les déploiements Joomla ?

Parce qu’elle contient des données vivantes : contenus, utilisateurs, commandes, formulaires, paramètres d’extensions. Remplacer la base de production par celle de préproduction peut supprimer des données récentes. La méthode dépend donc du type de site et de son activité.

Qu’est-ce qu’un rollback Joomla ?

Un rollback est un retour arrière après un déploiement problématique. Il peut concerner les fichiers, la base de données ou les deux. Il doit être préparé avant la mise en production, avec des critères de déclenchement et une personne responsable de la décision.

Une sauvegarde suffit-elle avant une mise à jour Joomla ?

Non. La sauvegarde est indispensable, mais elle ne remplace pas les tests en staging, la vérification des extensions, le contrôle des surcharges et le plan de retour arrière. Une sauvegarde doit aussi être restaurable, sinon elle reste théorique.

Faut-il mettre le site Joomla en maintenance pendant un déploiement ?

Pas toujours. Pour un changement de fichiers simple, ce n’est pas forcément nécessaire. Pour une mise à jour majeure, une modification de base de données ou un site transactionnel, une courte fenêtre de maintenance peut éviter des incohérences.