Le parc de serveurs WordPress de l’agence tourne encore majoritairement sur MariaDB 10.6, une version LTS proche de sa fin de support à moyen terme. La question de la montée de version vers la branche 11 se pose désormais concrètement, avec un changement de schéma de numérotation qui a d’abord semé la confusion en interne : après la série 10.x, MariaDB est passé à un schéma de version annuel, la 11.4 étant la version LTS actuellement recommandée pour une mise en production stable, par opposition aux versions intermédiaires à support plus court destinées aux environnements de test.
Cet inventaire ne traite volontairement pas du réglage fin des performances (taille du buffer pool, ajustement des caches), déjà couvert par ailleurs sur ce blog, mais uniquement des changements de comportement qui touchent directement la compatibilité d’un WordPress existant lors de cette montée de version.
Le changement de schéma de version, une clarification bienvenue
Historiquement, MariaDB suivait une numérotation 10.x qui laissait penser à tort qu’il s’agissait de versions mineures d’une même génération. Depuis la version 11, MariaDB adopte un schéma de version annuel plus proche de celui d’autres projets open source, avec une version LTS désignée explicitement pour chaque cycle. Pour un parc de production, le choix logique reste de suivre les versions LTS (comme la 11.4) plutôt que les versions intermédiaires, pensées pour tester les nouveautés à venir sans garantie de support prolongé.
Modes SQL stricts et compatibilité des requêtes existantes
Le changement le plus susceptible de casser silencieusement un site WordPress existant concerne le comportement par défaut de certains modes SQL, en particulier autour de la gestion des valeurs invalides ou tronquées lors d’une insertion. Une requête qui, sur une ancienne version, insérait silencieusement une valeur tronquée ou une date invalide en la corrigeant de son propre chef, peut désormais être rejetée avec une erreur explicite si le mode strict est actif par défaut.
-- Vérifier le mode SQL actif après la montée de version
SELECT @@sql_mode;
-- Comportement à surveiller : une requête historiquement tolérée
INSERT INTO wp_postmeta (post_id, meta_key, meta_value)
VALUES (42, 'prix', 'abc123');
-- peut désormais échouer en mode strict si la colonne attend un type numériqueSur ce parc, l’essentiel des requêtes WordPress natives respecte déjà les bonnes pratiques et n’a montré aucun problème de compatibilité. Le risque réel se concentre sur les plugins tiers plus anciens, dont certaines requêtes personnalisées, écrites il y a plusieurs années, s’appuient implicitement sur la tolérance des anciens modes SQL pour fonctionner sans erreur.
La checklist de vérification avant bascule en production
- Cloner un environnement de test à partir d’une sauvegarde récente de la base de production.
- Monter la version MariaDB sur cet environnement de test isolé, jamais directement en production.
- Activer le mode
WP_DEBUG_LOGet parcourir manuellement les fonctionnalités les plus utilisées par le client (formulaires, panier, recherche). - Vérifier spécifiquement les plugins tiers les plus anciens du site, pas uniquement le cœur WordPress et le thème.
- Ne planifier la bascule en production qu’après une semaine de test sans erreur remontée sur l’environnement de pré-production.
Ce qui a réellement posé problème sur ce parc
| Composant testé | Résultat |
|---|---|
| Cœur WordPress | Aucune régression constatée |
| Thèmes actifs sur le parc | Aucune régression constatée |
| Un plugin de formulaire ancien, non maintenu depuis 2019 | Erreur d’insertion sur un champ numérique mal typé |
Ce plugin de formulaire, déjà repéré comme candidat au remplacement dans un projet plus large de nettoyage du parc de plugins, a montré une erreur d’insertion explicite en mode strict, là où l’ancienne version de MariaDB tolérait silencieusement une valeur mal typée. La correction a consisté à migrer ce site vers un plugin de formulaire activement maintenu plutôt qu’à contourner le mode strict, une rustine qui aurait reporté le problème plutôt que de le résoudre.
Un mode SQL plus strict qui révèle une erreur silencieuse ancienne n’est pas une régression de la nouvelle version de MariaDB : c’est souvent la preuve qu’un bug dormait dans le code depuis des années, invisible faute d’un moteur suffisamment rigoureux pour le signaler.
En résumé
La montée vers MariaDB 11, et en particulier vers la version LTS 11.4, se déroule sans accroc pour l’immense majorité d’un WordPress standard, cœur et thèmes compris. Le vrai risque de compatibilité se loge dans les plugins tiers anciens, dont certaines requêtes personnalisées comptaient implicitement sur la tolérance des anciens modes SQL. Une checklist de test rigoureuse sur un environnement isolé, plugin par plugin, reste la meilleure protection avant toute bascule en production.
