Une nouvelle version de WordPress ou de PrestaShop est disponible. Une notification apparaît dans l’administration du site et, en quelques clics, la mise à jour peut être lancée. Cette simplicité apparente laisse souvent penser que l’opération se résume à installer une version plus récente du CMS avant de reprendre le cours normal de l’activité.
Sur un site personnel ou un projet peu personnalisé, cette perception n’est pas toujours fausse. Sur un site professionnel, en revanche, elle est rarement suffisante.
Un site web ne se limite pas au CMS qui le fait fonctionner. Il repose sur un ensemble de composants qui évoluent chacun à leur rythme : thème graphique, modules ou plugins, version de PHP, base de données, bibliothèques tierces, serveur web et, très souvent, développements spécifiques réalisés pour répondre aux besoins de l’entreprise. Dans le cas d’un site e-commerce, viennent encore s’ajouter les connexions avec les solutions de paiement, les transporteurs, les ERP, les logiciels de facturation ou les outils de gestion des stocks.
Mettre à jour WordPress ou PrestaShop consiste donc à faire évoluer un écosystème complet. Le bouton « Mettre à jour » n’en représente que la partie visible.
Pourquoi une nouvelle version est-elle publiée ?
Les annonces officielles mettent naturellement en avant les nouveautés les plus visibles. Une nouvelle fonctionnalité, une amélioration de l’interface ou une évolution du back-office constituent des arguments faciles à présenter.
Pourtant, une grande partie du travail réalisé par les équipes de développement reste invisible.
Une mise à jour peut notamment intégrer :
- des correctifs de sécurité ;
- des corrections de bugs ;
- des améliorations de performances ;
- des adaptations destinées à maintenir la compatibilité avec les nouvelles versions de PHP ;
- des modifications internes de l’architecture du CMS ;
- la suppression de mécanismes devenus obsolètes.
Ces évolutions n’ont pas toutes le même impact sur un projet existant. Certaines ne modifieront rien pour l’utilisateur final. D’autres pourront nécessiter une adaptation du thème, d’un module ou d’un développement spécifique — sachant que tous les modules ne se valent pas en termes de fiabilité et de maintenance, comme nous l’évoquons dans notre article sur les plugins WordPress indispensables (et ceux à éviter).
Avant d’envisager une mise à jour, la première question n’est donc pas « quelle est la nouvelle version ? », mais « pourquoi cette version a-t-elle été publiée ? ».
Toutes les mises à jour ne se gèrent pas de la même manière
Le mot « mise à jour » donne l’impression qu’il s’agit toujours de la même opération. En pratique, les situations sont très différentes.
Une version destinée à corriger une vulnérabilité critique n’a pas les mêmes enjeux qu’une version introduisant une nouvelle fonctionnalité ou modifiant certains mécanismes internes du CMS. Une mise à jour de maintenance ne demande pas non plus la même préparation qu’un changement de version majeure.
C’est la raison pour laquelle nous commençons systématiquement par analyser les informations publiées par l’éditeur. Les notes de version, les changelogs techniques et les éventuels bulletins de sécurité permettent de comprendre la nature des changements apportés et d’identifier les éléments susceptibles d’avoir un impact sur le projet.
Cette phase est peu visible pour le client. Pourtant, elle conditionne toute la suite de l’intervention. Elle permet de déterminer si une mise à jour peut être réalisée immédiatement, si des vérifications supplémentaires sont nécessaires ou si certaines extensions doivent d’abord être adaptées.
Le travail commence donc bien avant l’installation de la nouvelle version.
La sécurité ne concerne pas uniquement le cœur du CMS
Lorsqu’une vulnérabilité est annoncée, l’attention se porte généralement sur WordPress ou PrestaShop. En réalité, les extensions représentent une part importante des failles publiées chaque année.
Un plugin WordPress ou un module PrestaShop peut présenter une vulnérabilité permettant un accès non autorisé, une élévation de privilèges ou l’exécution de code. Le CMS lui-même peut être parfaitement à jour, tandis qu’une seule extension suffit à exposer le site.
La situation est encore plus délicate lorsque cette extension intervient dans un processus critique : paiement en ligne, authentification, gestion des commandes, synchronisation avec un ERP ou communication avec un transporteur.
Lors d’une maintenance, nous ne vérifions donc pas uniquement la version du CMS. Nous examinons également les modules installés, leur état de maintenance, leur historique de mises à jour et les éventuels avis de sécurité publiés par leurs éditeurs.
Être à jour ne signifie pas uniquement utiliser la dernière version de WordPress ou de PrestaShop. Cela signifie également maintenir l’ensemble des composants qui gravitent autour du CMS. D’autres obligations pèsent d’ailleurs sur les sites professionnels et dépassent le seul cadre de la sécurité, notamment en matière d’accessibilité : nous les détaillons dans notre article sur l’EAA et l’accessibilité web.
Le rôle de PHP est souvent sous-estimé
Un site WordPress ou PrestaShop ne fonctionne pas seul. Il dépend notamment de PHP, qui possède lui aussi son propre cycle de vie.
Chaque version de PHP bénéficie d’une période de support limitée. Lorsqu’elle arrive à son terme, elle ne reçoit plus de correctifs de sécurité. Continuer à l’utiliser revient donc à faire fonctionner le site sur un composant qui n’est plus maintenu.
À l’inverse, adopter une version récente de PHP peut révéler des incompatibilités dans des modules anciens ou dans des développements spécifiques réalisés plusieurs années auparavant.
Lorsqu’une mise à jour est préparée, nous vérifions donc également :
- la version de PHP ;
- les prérequis techniques de la nouvelle version du CMS ;
- les contraintes des modules installés ;
- la compatibilité des développements spécifiques.
Une mise à jour réussie dépend autant de l’environnement technique que du CMS lui-même.
Pourquoi deux sites identiques en apparence demandent-ils des interventions différentes ?
Deux entreprises peuvent utiliser exactement la même version de PrestaShop ou de WordPress sans que leur maintenance représente la même charge de travail.
La différence se trouve dans l’historique du projet.
Au fil des années, un site évolue. Des modules sont ajoutés, un thème est personnalisé, une connexion avec un logiciel métier est développée, un tunnel de commande est adapté ou une fonctionnalité spécifique est créée pour répondre à un besoin particulier.
Toutes ces évolutions fonctionnent généralement sans difficulté tant que l’environnement technique reste stable.
En revanche, lorsqu’il faut faire évoluer le CMS, chacune de ces adaptations doit être prise en compte.
Avant une intervention importante, nous cherchons donc à identifier :
- les développements spécifiques réalisés sur le projet ;
- les modules essentiels au fonctionnement de l’activité ;
- les connexions avec les applications tierces ;
- les éventuelles modifications apportées au thème ;
- les dépendances techniques qui pourraient être affectées par la mise à jour.
Ce travail explique pourquoi deux mises à jour apparemment identiques peuvent nécessiter des temps d’intervention très différents.
Pourquoi repousser les mises à jour complique souvent la situation
Il est fréquent d’entendre qu’un site fonctionne parfaitement et qu’il n’y a donc aucune raison d’y toucher.
Cette logique est compréhensible. Tant que le site répond aux besoins de l’entreprise, une intervention peut sembler inutile.
Le problème est que l’environnement technique continue d’évoluer.
Pendant plusieurs années, de nouvelles versions du CMS sont publiées, PHP évolue, certains modules disparaissent, d’autres changent de modèle économique ou cessent d’être maintenus. Les navigateurs, les protocoles de sécurité et les services externes poursuivent eux aussi leur évolution.
Lorsqu’une intervention devient finalement indispensable, il ne s’agit plus simplement d’installer la dernière version disponible.
Il faut parfois :
- remplacer un module abandonné ;
- adapter un développement spécifique ;
- effectuer plusieurs montées de version successives ;
- revoir certaines intégrations avec des applications tierces.
Une maintenance régulière permet précisément d’éviter cette accumulation.
Une sauvegarde est indispensable, mais elle ne remplace pas la préparation
Avant toute intervention importante, une sauvegarde complète est indispensable.
Elle constitue un filet de sécurité en cas de problème majeur. Pour autant, elle ne règle pas toutes les difficultés.
Encore faut-il qu’elle soit exploitable, que la procédure de restauration soit maîtrisée et que les conséquences d’un retour en arrière soient connues.
Sur une boutique en ligne, une restauration peut avoir un impact sur les commandes enregistrées entre la sauvegarde et la remise en ligne. Les synchronisations avec les logiciels de gestion, les paiements ou les mouvements de stock doivent également être pris en compte.
La sauvegarde fait donc partie du processus, mais elle ne remplace ni l’analyse préalable ni les vérifications réalisées avant la mise en production.
Pourquoi utiliser un environnement de préproduction ?
Lorsqu’une mise à jour présente un niveau de risque important, intervenir directement sur le site public n’est généralement pas la meilleure approche.
Nous privilégions alors un environnement de préproduction, c’est-à-dire une copie du site permettant de reproduire les principales conditions de fonctionnement.
Cette étape permet notamment de vérifier :
- le comportement du thème ;
- la compatibilité des modules ou plugins ;
- les développements spécifiques ;
- les formulaires ;
- le tunnel de commande ;
- les paiements ;
- les échanges avec les applications externes.
Tous les problèmes ne peuvent pas être reproduits en préproduction. En revanche, cette phase permet d’en identifier une grande partie avant qu’ils n’affectent les utilisateurs ou les clients. C’est notamment cette rigueur de test que nous appliquons systématiquement dans nos projets de création de boutiques en ligne.
Le travail ne s’arrête pas une fois la mise à jour installée
L’installation de la nouvelle version ne marque pas la fin de l’intervention.
Un contrôle fonctionnel est ensuite nécessaire afin de vérifier que le site continue à remplir son rôle.
Pour un site vitrine, cela peut concerner les formulaires, les espaces privés, les fonctionnalités de recherche ou les développements spécifiques.
Pour une boutique en ligne, les vérifications portent généralement sur :
- le panier ;
- le tunnel de commande ;
- les moyens de paiement ;
- les transporteurs ;
- les comptes clients ;
- les e-mails transactionnels ;
- les synchronisations avec les outils métiers.
Les journaux d’erreurs sont également analysés afin d’identifier d’éventuels problèmes qui ne seraient pas encore visibles pour les utilisateurs.
L’objectif n’est pas uniquement de constater que la page d’accueil s’affiche correctement, mais de s’assurer que l’ensemble des fonctionnalités critiques reste opérationnel.
Faut-il installer chaque mise à jour dès sa publication ?
Il n’existe pas de réponse unique.
Une vulnérabilité de sécurité importante peut justifier une intervention rapide. À l’inverse, une nouvelle version majeure peut nécessiter quelques jours d’analyse afin de laisser le temps aux éditeurs de modules de publier leurs propres mises à jour ou de confirmer la compatibilité de leurs extensions.
Le bon choix dépend du contexte technique du projet, de son niveau de personnalisation et des risques liés à l’interruption éventuelle de certains services.
L’objectif n’est donc ni de tout installer immédiatement, ni de repousser systématiquement les mises à jour. Il s’agit d’intervenir au moment opportun, avec une connaissance précise des conséquences possibles.
Conclusion
Une mise à jour de WordPress ou de PrestaShop ne se résume pas à l’installation d’une nouvelle version.
Elle implique d’analyser les évolutions publiées, de comprendre les enjeux de sécurité, de tenir compte de l’environnement technique, de vérifier la compatibilité des extensions, d’anticiper les impacts des développements spécifiques et de contrôler le fonctionnement du site après l’intervention.
Le clic qui lance la mise à jour est probablement l’étape la plus simple de l’opération. Le véritable travail consiste surtout à faire évoluer un projet parfois construit depuis plusieurs années, sans compromettre sa stabilité, sa sécurité ou son activité — une expertise que nous mettons au service de nos clients depuis vingt ans.