WebSocket et Redis peuvent être utiles autour de WordPress lorsque le projet exige une mise à jour temps réel: notifications, tableau de bord, collaboration ou suivi d’un traitement long. Ils ne sont pas nécessaires pour la plupart des sites éditoriaux et ajoutent une infrastructure à maintenir.
Choisir le bon mécanisme
Un rafraîchissement périodique ou une tâche asynchrone suffit souvent. Utilisez une connexion persistante seulement si l’utilisateur doit recevoir une information presque immédiatement et que cette information ne peut pas être obtenue simplement au prochain chargement de page.
Architecture à séparer de WordPress
Gardez WordPress responsable du contenu et des droits, puis placez la diffusion temps réel dans un service séparé :
WordPress -> événement validé -> file ou Redis -> passerelle temps réel -> navigateur autoriséChaque étape doit vérifier l’identité, les droits et les données diffusées. N’envoyez jamais un événement contenant une information privée à tous les utilisateurs connectés.
Points de sécurité
- authentifier la connexion temps réel ;
- vérifier les autorisations côté serveur pour chaque canal ;
- limiter le débit et la taille des messages ;
- isoler Redis du réseau public ;
- journaliser les erreurs sans stocker de secrets ;
- prévoir la déconnexion et la reprise après incident.
Test de charge et de fiabilité
Testez le nombre réel de connexions, les reconnexions, un redémarrage Redis, une panne de passerelle et les permissions d’un utilisateur qui change de rôle. La boutique ou le site doit rester utilisable lorsque la fonction temps réel est indisponible.
Conclusion
Une fonction temps réel réussie est une fonction limitée, observable et dégradable. Commencez par un cas d’usage, un petit groupe d’utilisateurs et des métriques claires avant de généraliser l’architecture.
Pour aller plus loin
- Valkey ou Redis : choisir et tester le cache
- Performance WordPress : TTFB et INP
- Scanner de malwares WordPress
