Valkey ou Redis : quel cache objet pour WordPress en 2026 ?

Pourquoi le cache objet est devenu indispensable sur WordPress

Sur un site WordPress, chaque affichage de page déclenche une série d’opérations : chargement des options, recherche de métadonnées, récupération de contenus, exécution d’extensions, contrôle des droits d’un utilisateur connecté et construction des requêtes SQL. Sans mécanisme persistant, une partie de ces données est redemandée à MySQL ou MariaDB à chaque requête HTTP.

Le cache objet répond à ce problème. WordPress possède nativement une API de cache, accessible notamment via les fonctions wp_cache_get(), wp_cache_set() et wp_cache_delete(). Par défaut, ce cache vit uniquement pendant l’exécution de la requête PHP : il est vidé dès que la page a été générée. Un cache objet persistant conserve au contraire les données en mémoire entre deux requêtes, dans un service tel que Redis ou Valkey.

Dans la pratique, il peut mémoriser des objets WordPress fréquemment sollicités : options, résultats de requêtes, métadonnées de publications, termes de taxonomies ou données calculées par une extension. Lorsqu’une donnée est déjà en mémoire, WordPress évite une lecture supplémentaire dans la base de données.

Ce mécanisme est particulièrement utile dans les situations suivantes :

• un site éditorial avec de nombreuses publications, catégories et requêtes répétées ;
• une boutique WooCommerce, où les parcours connectés et les données dynamiques limitent l’efficacité d’un simple cache de pages ;
• un espace membre, un LMS ou un extranet ;
• une administration WordPress sollicitée par plusieurs rédacteurs ;
• un site recevant des pics de trafic, notamment après une campagne e-mail, une publication virale ou un passage média.

Il ne faut toutefois pas confondre les couches de cache. Un CDN sert les fichiers statiques et parfois des pages HTML depuis des emplacements proches des visiteurs. Un cache de pages renvoie une page HTML déjà construite. OPcache conserve le bytecode PHP compilé. Le cache objet, lui, accélère les échanges entre PHP et les données applicatives. Ces couches sont complémentaires.

Un cache objet ne remplace pas non plus une base de données bien entretenue, une extension légère ou une configuration PHP adaptée. Avant de multiplier les optimisations, vérifiez les fondamentaux de votre plateforme avec notre guide des points à vérifier chez un hébergeur WordPress.

Redis et Valkey : une histoire de fork, de protocoles et de licences

Redis est depuis longtemps l’une des solutions en mémoire les plus utilisées dans l’écosystème web. Son modèle clé-valeur, sa faible latence et son vaste écosystème de clients ont favorisé son adoption par les hébergeurs, les applications PHP et les plateformes cloud. Sur WordPress, le terme « Redis » est même devenu une expression générique pour désigner un cache objet persistant.

Valkey est un projet distinct. Il a été lancé en 2024 comme un fork de Redis 7.2.4, sous l’égide de la Linux Foundation. Son code est distribué sous licence BSD à trois clauses. Le projet vise notamment à fournir une base open source gouvernée de manière communautaire et compatible avec les usages courants de Redis.

L’origine de ce fork est liée à l’évolution des licences de Redis. En 2024, Redis a abandonné la licence BSD pour ses nouvelles versions au profit de licences source-available. Redis a ensuite annoncé Redis 8 avec un modèle de licences incluant notamment l’AGPLv3, en plus de licences destinées à certains usages commerciaux. Le sujet est donc moins simple qu’une opposition entre un Redis « fermé » et un Valkey « ouvert » : il faut examiner la version proposée, la licence retenue et surtout les conditions de service de votre hébergeur.

Pour le propriétaire d’un site WordPress, cette différence juridique a généralement peu d’impact direct lorsque Redis ou Valkey est fourni comme un service managé. Elle compte davantage pour :

• les hébergeurs et fournisseurs cloud qui redistribuent ou opèrent le logiciel à grande échelle ;
• les agences qui standardisent leur infrastructure pour de nombreux clients ;
• les entreprises soumises à une politique stricte de conformité open source ;
• les équipes qui auto-hébergent leur cache sur un VPS, des conteneurs ou Kubernetes.

Sur le plan technique, Valkey conserve une forte compatibilité avec le protocole et les commandes historiquement associés à Redis. Une grande partie des bibliothèques clientes, dont celles utilisées dans PHP, peut donc communiquer avec un serveur Valkey sans modification du code applicatif. Cette proximité explique pourquoi certains prestataires peuvent proposer Valkey derrière une offre encore commercialement appelée « Redis » ou « cache Redis-compatible ».

Pour WordPress, le nom affiché dans le tableau de bord de l’hébergeur importe moins que la compatibilité réelle avec votre extension de cache, la qualité de l’exploitation et la capacité mémoire allouée.

Les différences techniques qui comptent réellement pour un site WordPress

Pour les usages classiques de cache objet WordPress, Redis et Valkey remplissent le même rôle : stocker rapidement des clés et leurs valeurs en mémoire. WordPress n’exploite pas, dans ce contexte, toutes les fonctions avancées que peuvent proposer ces moteurs. Il s’appuie surtout sur des opérations simples de lecture, d’écriture, de suppression et d’expiration.

La compatibilité est donc très élevée lorsque votre site utilise un client PHP courant et un drop-in de cache objet standard. Le drop-in est le fichier object-cache.php placé dans le répertoire wp-content : il remplace le cache non persistant de WordPress par un backend externe. La documentation officielle décrit le rôle de WP_Object_Cache dans le fonctionnement interne du CMS.

En revanche, une équivalence générale ne signifie pas qu’il faut ignorer les détails. Avant une migration ou un changement d’hébergeur, examinez les points suivants :

• La version du serveur : un fournisseur peut limiter les versions disponibles ou déployer son propre service managé.
• Le client PHP : l’extension PhpRedis, Predis et d’autres bibliothèques n’ont pas les mêmes performances ni les mêmes modes de connexion.
• Les fonctionnalités non standard : les modules, commandes très récentes ou fonctionnalités spécifiques d’un fournisseur demandent une validation particulière.
• La topologie : une instance unique, un service répliqué, un cluster ou une offre mutualisée ne se supervisent pas de la même façon.
• La politique d’éviction : lorsque la mémoire est pleine, le serveur doit savoir quelles clés supprimer ou s’il doit refuser les nouvelles écritures.

Dans un environnement WordPress conventionnel, le risque principal n’est pas que Valkey soit incompatible avec une fonction exotique de Redis. Il est plus souvent lié à une mémoire insuffisante, à un socket mal configuré, à un cache exposé sur Internet, à une extension de cache en doublon ou à un mauvais choix de politique d’éviction.

Un cache objet doit rester un composant jetable : si le service redémarre ou si son contenu est purgé, le site doit continuer à fonctionner. Il peut être moins rapide pendant le réchauffement du cache, mais il ne doit pas perdre de données métier critiques. Les commandes, commandes clients, sessions ou données de panier doivent donc être traitées avec prudence selon l’architecture de l’extension et de la boutique.

Compatibilité WordPress : extensions, drop-ins et hébergeurs

L’extension gratuite Redis Object Cache est très répandue pour connecter WordPress à un service compatible Redis. Elle s’appuie sur un drop-in et peut utiliser différents clients PHP selon l’environnement. Sa dénomination ne doit pas vous induire en erreur : lorsqu’un serveur Valkey expose les commandes attendues, la compatibilité applicative est souvent possible. Il reste indispensable de vérifier la documentation de l’extension, celle de l’hébergeur et les journaux après activation.

Des solutions commerciales ou incluses dans des plateformes managées peuvent aussi gérer le cache objet à leur manière. Certaines intègrent un service et un plugin préconfiguré ; d’autres demandent de renseigner l’hôte, le port, le mot de passe ou le chemin d’un socket Unix. Une offre d’hébergement peut également limiter le nombre de connexions, la mémoire disponible ou l’accès à certaines commandes d’administration.

Voici une méthode fiable avant d’activer un cache objet chez votre hébergeur :

• demandez si le service est Redis, Valkey ou simplement compatible avec le protocole Redis ;
• vérifiez si l’accès se fait par socket Unix ou par réseau TCP, et si une authentification est imposée ;
• identifiez la mémoire réellement allouée à votre instance, plutôt que de vous contenter d’une mention marketing « Redis inclus » ;
• contrôlez si le service est isolé par compte ou partagé entre plusieurs clients ;
• vérifiez la présence d’une supervision, de sauvegardes éventuelles et d’un support technique capable de diagnostiquer un incident ;
• activez un seul drop-in de cache objet à la fois.

Le dernier point est essentiel. Installer simultanément plusieurs plugins qui créent ou modifient object-cache.php produit des comportements imprévisibles. Lors d’un changement d’extension, désactivez proprement l’ancien drop-in, sauvegardez votre configuration et testez le site connecté comme déconnecté.

Les hébergeurs WordPress managés activent parfois un cache objet sans laisser l’utilisateur choisir l’implémentation. Ce n’est pas forcément un défaut : une solution opérée, surveillée et correctement dimensionnée est souvent préférable à un Redis installé sans maintenance sur un VPS. Pour comparer les niveaux de service, consultez aussi notre analyse hébergement WordPress managé ou mutualisé.

Bien configurer un cache Valkey ou Redis sans fragiliser le site

La configuration la plus rapide n’est pas toujours la plus sûre. Redis et Valkey sont des services réseau puissants : une instance accessible publiquement sans contrôle d’accès constitue un risque sérieux. Sur un serveur que vous administrez, limitez l’écoute au réseau privé ou à l’hôte local, activez l’authentification lorsque c’est approprié et appliquez les mécanismes de chiffrement pris en charge par votre architecture. Ne publiez jamais un port de cache sur Internet « pour faire fonctionner WordPress ».

Sur un hébergement mutualisé ou managé, privilégiez les identifiants et endpoints fournis par le prestataire. Évitez de modifier des paramètres globaux du service si vous ne maîtrisez pas leurs conséquences. Une instance partagée exige notamment une isolation correcte des préfixes de clés entre les sites ; les offres managées sérieuses s’en chargent généralement au niveau du service.

La mémoire doit être surveillée. Un cache plein peut évincer des données anciennes, refuser des écritures ou dégrader fortement les temps de réponse, selon la politique configurée. Pour un cache objet dédié et non critique, des politiques qui autorisent l’éviction de clés, comme allkeys-lru ou allkeys-lfu lorsqu’elles sont disponibles et adaptées à votre serveur, sont souvent plus tolérantes qu’un mode qui refuse toute écriture une fois la limite atteinte. Ce choix doit néanmoins être validé avec la documentation de votre offre.

Surveillez au minimum :

• l’utilisation mémoire et les évictions ;
• le taux de clés expirées ;
• les erreurs de connexion depuis PHP ;
• la latence observée côté application ;
• les erreurs affichées dans les journaux WordPress et PHP.

Ne vous fiez pas uniquement à un score de performance généré après avoir activé un plugin. Comparez le comportement avant et après : temps de réponse sur des pages non mises en cache, utilisation CPU, charge de la base de données et fluidité de l’administration. Les pages publiques déjà servies intégralement par un CDN ou un cache HTML peuvent peu changer, tandis qu’un tableau de bord ou un parcours utilisateur connecté peut tirer un bénéfice plus net.

Quel choix selon votre trafic et votre type d’hébergement ?

Pour un petit site vitrine avec peu de contenus, des visiteurs surtout anonymes et un cache de pages efficace, Redis ou Valkey ne sont pas toujours prioritaires. Un bon hébergement, une version PHP maintenue, OPcache, des images optimisées et un cache HTML correctement réglé apporteront souvent un résultat plus visible. Notre dossier consacré à l’optimisation de WordPress sur son hébergement détaille cette approche globale.

Pour un blog actif, un média ou un site institutionnel riche en contenus, le cache objet devient intéressant dès que les requêtes vers la base de données se répètent et que l’administration ralentit. Dans ce cas, Valkey est un choix rationnel si votre hébergeur le propose officiellement, garantit sa compatibilité et assure son exploitation. Sa licence BSD et son intégration croissante dans l’infrastructure cloud peuvent aussi rassurer les équipes qui privilégient une base open source communautaire.

Pour une boutique WooCommerce, un site de réservation, un espace membre ou une plateforme e-learning, la question ne se réduit pas au nom du moteur. La priorité est la fiabilité : mémoire suffisante, faible latence réseau, isolation, supervision et support compétent. Redis reste parfaitement pertinent lorsque c’est le service nativement fourni et maintenu par votre plateforme. Une migration vers Valkey n’a d’intérêt que si elle répond à un besoin précis de coût, de gouvernance, de conformité ou de disponibilité chez votre fournisseur.

Pour un VPS auto-administré, Valkey constitue une option solide si vous souhaitez un logiciel sous licence BSD et une compatibilité étendue avec l’écosystème Redis historique. Mais il faut alors assumer les tâches d’exploitation : mises à jour, limitation réseau, monitoring, gestion mémoire et procédure de restauration. À l’inverse, une instance Redis ou Valkey managée peut libérer du temps, à condition de bien comprendre ses limites contractuelles.

Tester une migration de Redis vers Valkey, ou l’inverse

Comme le cache objet WordPress est censé être reconstructible, un changement de moteur est généralement plus simple qu’une migration de base de données. Il ne faut pourtant pas intervenir directement en production sans validation. Préparez un environnement de préproduction représentatif, avec la même version de WordPress, les mêmes extensions critiques et une configuration PHP comparable.

Commencez par relever la configuration actuelle : méthode de connexion, préfixe, base logique éventuelle, plugin actif et paramètres de cache. Déployez ensuite la nouvelle instance avec un espace de clés propre. Ne pointez pas deux environnements différents vers le même cache sans isolation volontaire et maîtrisée.

Après avoir activé le nouveau backend, videz le cache objet, parcourez les pages publiques, connectez-vous avec plusieurs profils et réalisez les actions métier importantes : ajout au panier, paiement en environnement de test, publication d’un article, recherche, formulaires et tâches planifiées. Vérifiez enfin les logs PHP, les erreurs WordPress et l’absence d’objets obsolètes.

Prévoyez un retour arrière simple : conserver temporairement les paramètres de l’ancienne instance et savoir désactiver le drop-in. Une migration réussie ne se mesure pas seulement au fait que le site reste accessible ; elle doit préserver les fonctionnalités dynamiques et ne générer ni erreurs intermittentes ni surcharge de la base de données.

Conclusion : privilégier le service le mieux exploité

En 2026, Valkey et Redis peuvent tous deux fournir un excellent cache objet à WordPress. Pour l’immense majorité des sites, leur compatibilité avec les usages classiques du CMS est plus importante que leur différence de nom. Valkey se distingue par son origine communautaire et sa licence BSD, tandis que Redis conserve un écosystème historique considérable et des offres managées très répandues.

Le meilleur choix est donc celui que votre hébergeur peut opérer de façon fiable, sécurisée et documentée, avec une mémoire adaptée à votre activité. Avant de changer de moteur, identifiez votre véritable goulot d’étranglement, testez l’intégration avec votre extension de cache et comparez les conditions techniques de l’offre. Si vous envisagez aussi de revoir votre plateforme, notre comparatif des hébergeurs WordPress vous aidera à évaluer les services de cache au-delà des promesses marketing.