MySQL 8.4 LTS : ce que votre hébergeur WordPress doit assurer

La base de données est une composante discrète mais centrale d’un site WordPress. Articles, pages, comptes utilisateurs, réglages, commandes WooCommerce et métadonnées y sont stockés. Pourtant, lors du choix ou du renouvellement d’un hébergement, la version de MySQL est souvent moins examinée que le PHP, le stockage NVMe ou le CDN.

Cette situation mérite d’évoluer avec la fin du support Premier de MySQL 8.0, annoncée par Oracle pour avril 2026. MySQL 8.4 LTS, publié en 2024, constitue désormais la branche de support à long terme à considérer pour les environnements qui souhaitent privilégier la stabilité. Pour un propriétaire de site WordPress, l’enjeu n’est pas d’installer une version récente par principe : il faut surtout s’assurer que l’hébergeur planifie la transition, maîtrise les sauvegardes et fournit un chemin de migration testé.

Ce guide détaille les contrôles concrets à effectuer, que votre site soit sur un hébergement mutualisé, un VPS ou une offre WordPress managée.

Pourquoi la fin de cycle de MySQL 8.0 concerne les sites WordPress

MySQL 8.0 a été une version majeure très largement adoptée par les hébergeurs. Elle a apporté de nombreuses évolutions par rapport à MySQL 5.7, notamment sur l’optimiseur, les expressions de table communes, les fonctions de fenêtre et l’authentification. Mais toute version possède un cycle de maintenance.

Selon le calendrier de support à vie des produits Oracle, MySQL 8.0 arrive à la fin de son support Premier en avril 2026. Cela ne signifie pas que tous les serveurs MySQL 8.0 cesseront instantanément de fonctionner. Un site WordPress restera accessible tant que son infrastructure demeure opérationnelle. En revanche, la situation change sur plusieurs plans :

les correctifs de bogues et de sécurité ne suivent plus le même cycle de support standard ;
l’hébergeur doit décider s’il maintient MySQL 8.0, souscrit un support étendu ou organise une évolution vers une branche plus récente ;
les versions anciennes de PHP, des extensions ou des connecteurs de base de données peuvent devenir un frein à la migration ;
une mise à jour retardée augmente le volume de changements à absorber lors d’une future migration.

Pour WordPress, ce sujet compte parce que le CMS interroge MySQL à chaque chargement dynamique : connexion utilisateur, recherche interne, administration, publication, panier WooCommerce ou récupération de contenus. Une indisponibilité de la base, un échec d’authentification ou une requête devenue incompatible peut affecter tout le site.

Les prérequis officiels de WordPress recommandent MySQL 8.0 ou une version supérieure, ou MariaDB 10.6 ou une version supérieure. MySQL 8.4 entre donc dans le cadre recommandé. Cela ne veut pas dire que chaque extension WordPress a été validée individuellement sur cette version : l’écosystème est vaste, et les extensions les plus anciennes ou les développements sur mesure exigent une vérification spécifique.

La bonne question à poser n’est pas « Mon site est-il encore en MySQL 8.0 ? », mais « Quelle est la politique de mise à niveau de mon hébergeur, et puis-je tester mon site avant le basculement ? »

MySQL 8.4 LTS : comprendre ce que signifie réellement LTS

Oracle distingue les versions « Innovation » et les versions LTS, pour Long-Term Support. Les versions Innovation introduisent plus fréquemment des nouveautés. Les versions LTS sont destinées aux organisations qui recherchent un socle maintenu plus longtemps et un rythme de migration plus prévisible.

MySQL 8.4 est la première version LTS suivant MySQL 8.0 dans cette stratégie. Oracle prévoit pour MySQL 8.4 un support Premier jusqu’en avril 2032. Cette durée est particulièrement pertinente pour un hébergeur : elle lui permet de standardiser des plateformes, de documenter les procédures d’exploitation et de limiter les migrations de versions majeures trop rapprochées.

Pour un client WordPress, les bénéfices sont principalement indirects :

un horizon de maintenance plus long, utile pour les sites qui ne peuvent pas être testés chaque trimestre ;
un cadre de support plus clair pour les correctifs et les incidents liés au serveur de base de données ;
une réduction du risque de migration imposée dans l’urgence, à condition que l’hébergeur organise la bascule avant la fin effective de support de MySQL 8.0 ;
une meilleure cohérence avec un environnement moderne, notamment lorsque l’hébergement fait aussi évoluer PHP, OpenSSL et les outils de sauvegarde.

Il faut toutefois éviter une attente irréaliste : passer de MySQL 8.0 à MySQL 8.4 ne rend pas automatiquement un WordPress plus rapide. Les performances ressenties dépendent surtout de la qualité des requêtes, de la taille des tables, des index, du cache de pages, du cache objet, de PHP, du volume de trafic et des ressources allouées au serveur.

Un site lent à cause d’une extension qui déclenche des requêtes non indexées ne sera pas corrigé par le seul changement de version de MySQL. De même, une boutique WooCommerce avec une base volumineuse peut nécessiter une analyse ciblée des requêtes lentes et de ses tables. Pour ce travail, les outils comme Query Monitor, le journal des requêtes lentes MySQL lorsque l’hébergeur y donne accès, ou une solution d’observabilité peuvent être plus utiles qu’une simple montée de version.

Compatibilité WordPress : les points techniques à ne pas négliger

WordPress communique avec MySQL via l’extension MySQLi de PHP. Sur un hébergement classique, le propriétaire du site n’administre ni le binaire MySQL ni les bibliothèques clientes : ces éléments sont gérés par l’hébergeur. Cela explique pourquoi une migration de base ne doit jamais être réduite à un changement de numéro de version dans un tableau de bord.

La compatibilité est généralement bonne pour un WordPress à jour, utilisant un thème maintenu et des extensions régulièrement mises à jour. Cependant, plusieurs cas nécessitent une attention particulière.

Les extensions et thèmes anciens

Un code ancien peut contenir des requêtes SQL non conformes, s’appuyer sur des comportements historiques ou interroger directement certaines tables. Les extensions qui gèrent de gros volumes de données, des rapports, des réservations, un catalogue WooCommerce ou des recherches avancées sont prioritaires pour les tests.

Les requêtes réalisées avec $wpdb ou les API natives de WordPress sont habituellement plus simples à suivre que des requêtes construites manuellement. Cela ne dispense pas de tester les fonctionnalités métier : création de compte, formulaire de contact, paiement, recherche, import et export, tâches planifiées et envoi d’e-mails transactionnels.

L’authentification entre PHP et MySQL

MySQL 8.4 désactive par défaut le plugin d’authentification mysql_native_password, désormais déprécié. Cette évolution est importante si votre application, un script externe ou une ancienne bibliothèque cliente dépend explicitement de cette méthode. Les installations WordPress modernes s’appuient normalement sur des composants compatibles avec les mécanismes d’authentification actuels, mais votre hébergeur doit vérifier ce point avant une bascule globale.

Demandez-lui notamment si les comptes de base de données WordPress seront conservés, recréés ou modifiés, et quel mécanisme d’authentification sera appliqué. Un échec de connexion se manifeste souvent par le message WordPress « Erreur lors de l’établissement d’une connexion à la base de données » : ce problème est bloquant, même si les fichiers du site et le serveur web fonctionnent parfaitement.

Les environnements qui ne sont pas MySQL

MariaDB est souvent proposé à la place de MySQL, surtout en hébergement mutualisé. Bien que les deux systèmes partagent une histoire et une compatibilité importante avec WordPress, ils suivent désormais des trajectoires distinctes. MySQL 8.4 n’est donc pas une mise à niveau applicable à une instance MariaDB.

Avant de suivre un guide ou de contacter le support, identifiez le moteur réellement utilisé. phpMyAdmin, un panneau comme cPanel ou Plesk, ou la commande SELECT VERSION(); lorsque l’accès SQL est permis, permettent généralement de le voir. Pour approfondir ce choix d’architecture, consultez notre dossier sur MySQL, MariaDB et PostgreSQL pour WordPress.

Ce que votre hébergeur doit assurer avant la migration

La qualité d’une transition vers MySQL 8.4 dépend moins de l’utilisateur final que de l’exploitation menée par l’hébergeur. Un prestataire sérieux doit pouvoir répondre clairement aux questions suivantes, sans se contenter d’annoncer une « infrastructure toujours à jour ».

Une feuille de route et une communication anticipée

Demandez quelle version est actuellement utilisée, quelle version cible est prévue, et à quelle période la migration pourrait avoir lieu. Sur une plateforme mutualisée, l’hébergeur peut procéder par lots de comptes ou déplacer les clients vers de nouveaux serveurs. Sur un VPS infogéré, il peut proposer une opération planifiée. Sur un serveur administré par vos soins, la responsabilité est en grande partie la vôtre.

Une communication utile précise la fenêtre de maintenance éventuelle, les actions attendues du client, les services concernés et le canal de support en cas d’incident. Une modification de version majeure ne devrait pas être découverte après coup en consultant les journaux d’erreur WordPress.

Des sauvegardes restaurables, pas seulement annoncées

Une sauvegarde est la condition minimale d’une migration sûre. Elle doit inclure au moins la base de données et les fichiers WordPress, car restaurer uniquement les tables peut créer un décalage avec les extensions, les médias ou les fichiers de configuration.

Vérifiez quatre éléments :

la fréquence des sauvegardes proposées par l’hébergeur ;
la durée de rétention réellement incluse dans votre offre ;
la possibilité de restaurer une base précise ou un compte complet ;
la procédure de restauration et son éventuel coût.

Conservez également une copie indépendante avant toute opération. Selon les accès disponibles, un export avec phpMyAdmin, WP-CLI ou mysqldump peut être approprié. Il ne faut cependant pas télécharger un export SQL sans vérifier qu’il est complet et exploitable. Une restauration sur un environnement de test reste la meilleure validation.

Un environnement de préproduction

La préproduction, parfois appelée staging, est le meilleur filet de sécurité. Elle reproduit le site sur un sous-domaine ou un espace isolé afin de vérifier le comportement de WordPress avec la version cible de MySQL. Certains hébergeurs WordPress managés proposent cette fonction dans leur interface ; ailleurs, il faudra créer un sous-domaine, une base dédiée et une copie des fichiers.

Le staging doit idéalement utiliser une version de PHP comparable à celle de la production et le même type de configuration de serveur. Une copie de site testée sur une pile technique très différente offre une assurance limitée.

La checklist à envoyer au support de votre hébergeur

Voici une liste de questions directement utilisables dans un ticket. Elle permet d’obtenir des réponses concrètes et de comparer les politiques de plusieurs prestataires.

Quelle version et quelle édition de MySQL hébergent actuellement mon site ?
Quelle est votre date ou votre fenêtre prévisionnelle de migration vers MySQL 8.4 LTS ?
La migration implique-t-elle une indisponibilité, un changement de serveur ou une modification des identifiants de base de données ?
Proposez-vous un environnement de staging utilisant MySQL 8.4 avant le basculement de production ?
Effectuez-vous une sauvegarde complète immédiatement avant l’opération ? Quelle est la procédure de restauration ?
Contrôlez-vous la compatibilité de l’authentification des comptes MySQL avec les versions de PHP proposées ?
Les paramètres du serveur, notamment le jeu de caractères et la collation, seront-ils conservés ?
Disposez-vous d’un plan de retour arrière si une anomalie est constatée après la migration ?
Le support peut-il analyser les erreurs MySQL et les journaux applicatifs en cas de problème post-migration ?

Une réponse précise ne signifie pas que l’hébergeur doit vous communiquer son architecture interne dans les moindres détails. En revanche, il doit être capable d’expliquer les conséquences pour votre compte, les protections prévues et la marche à suivre. C’est un critère pertinent dans votre comparaison, au même titre que ceux présentés dans notre guide pour comparer les offres d’hébergement WordPress sans se laisser guider par le marketing.

Préparer la mise à niveau de sa base WordPress sans risque

Même lorsque l’hébergeur pilote la migration, le propriétaire du site doit préparer son application. L’objectif est de diminuer les inconnues et de disposer d’un point de retour fiable.

1. Mettre à jour ce qui doit l’être

Avant de cloner le site ou de migrer, mettez à jour WordPress, les extensions et le thème actif après avoir réalisé une sauvegarde. Supprimez les extensions et thèmes inutilisés si vous êtes certain de ne plus en avoir besoin. Moins l’installation contient de code abandonné, plus le diagnostic sera simple.

Cette étape inclut PHP : une version de PHP maintenue et compatible avec vos extensions réduit les risques de problème côté connecteur MySQL. Ne changez pas simultanément trop de paramètres sans test. Si vous devez mettre à niveau PHP et MySQL, testez l’ensemble sur la préproduction afin de pouvoir identifier l’origine d’une erreur.

2. Contrôler l’intégrité et le volume de la base

Depuis phpMyAdmin ou un accès SSH, examinez la taille de la base et les tables les plus volumineuses. Sur WordPress, les tables wp_posts, wp_postmeta, wp_options, ainsi que les tables créées par WooCommerce ou des extensions de cache, peuvent représenter une part importante du volume.

Une base très volumineuse rallonge les opérations de copie et de restauration. Un grand nombre de données transitoires, de révisions ou de métadonnées inutilisées peut aussi compliquer les investigations. N’effectuez toutefois pas de nettoyage automatique agressif juste avant une migration : toute suppression doit être comprise, sauvegardée et testée.

3. Tester les parcours critiques sur staging

Après avoir importé une copie récente de la base sur l’environnement de test, parcourez méthodiquement les fonctionnalités importantes. Pour un site vitrine, cela peut inclure le formulaire de contact, le moteur de recherche, la connexion à l’administration et les pages construites avec votre éditeur. Pour WooCommerce, testez un panier, un paiement dans un environnement approprié, la création d’une commande, les e-mails et l’accès au compte client.

Activez temporairement les journaux WordPress si nécessaire, sans exposer les erreurs aux visiteurs. Consultez également les logs PHP et les éventuels journaux de la base mis à disposition par l’hébergeur. Des erreurs de syntaxe SQL, d’accès refusé ou de jeu de caractères doivent être corrigées avant la production.

Le jour du basculement : réduire les risques opérationnels

Lorsqu’une migration nécessite une fenêtre définie, évitez les modifications importantes du contenu pendant l’opération. Pour une boutique active, le sujet est plus sensible : une commande créée après l’export de la base mais avant le basculement peut ne pas se retrouver sur la nouvelle instance si aucune synchronisation n’est prévue.

Convenez avec l’hébergeur d’un déroulé adapté au niveau de criticité du site. Cela peut passer par une courte maintenance, une bascule planifiée à faible trafic ou une méthode de réplication administrée par le prestataire. Le choix dépend de l’architecture, du volume de données et des outils disponibles.

Après le changement, vérifiez immédiatement :

l’affichage des pages publiques et des médias ;
la connexion à /wp-admin/ ;
les formulaires et les principaux parcours de conversion ;
les tâches planifiées WordPress ;
les journaux d’erreurs ;
les performances observées et les éventuelles erreurs de connexion à la base.

Gardez la sauvegarde pré-migration disponible durant toute la période définie avec l’hébergeur. Une restauration n’est pas toujours la meilleure réponse à un incident, notamment lorsque de nouvelles commandes ou contenus ont été créés entre-temps, mais elle reste un élément indispensable du plan de continuité.

MySQL 8.4 LTS, un indicateur de maturité de l’hébergement

MySQL 8.4 LTS ne doit pas être envisagé comme un argument commercial isolé. Pour WordPress, son intérêt réside dans la visibilité qu’il apporte sur le cycle de maintenance. Avec la fin du support Premier de MySQL 8.0, un hébergeur fiable doit pouvoir expliquer sa stratégie, proposer des sauvegardes réellement restaurables, permettre des tests et accompagner les incidents éventuels.

Avant de subir une mise à jour de base de données, identifiez votre moteur actuel, demandez le calendrier de votre prestataire et testez votre site sur une préproduction lorsque cela est possible. Ces vérifications prennent peu de temps face au coût potentiel d’une interruption ou d’une boutique indisponible. Si votre hébergeur ne peut pas y répondre clairement, c’est aussi l’occasion de réévaluer si son niveau d’accompagnement correspond encore aux besoins de votre WordPress.