Nindohost ou xneelo : quel hébergement WordPress pour un espace adhérents avec cache ?

Un seul cache public, deux comptes à séparer

Une association publie des actualités et des ressources ouvertes dans WordPress. Elle propose aussi un espace où chaque adhérent voit sa propre fiche et ses documents. L’équipe veut réduire les calculs nécessaires à l’affichage des actualités sans que le cache partage une réponse personnalisée. Ce scénario concerne le cache de pages HTML et les points d’accès qui renvoient le même type de données, sur un seul WordPress. Il ne compare ni les fonctions des extensions d’adhésion ni les performances brutes des serveurs.

Le risque apparaît lorsqu’une couche placée devant WordPress réutilise le corps d’une réponse calculée pour une session différente. Par exemple, le premier adhérent ouvre sa fiche ; si le cache se base seulement sur l’adresse et conserve cette réponse, l’adhérent suivant peut recevoir le premier contenu avant même que WordPress vérifie ses droits. Un écran correct lors du premier chargement ne suffit donc pas. L’ordre des visites et l’état du cache font partie du test.

Les deux forfaits examinés sont Plus Site de Nindohost au Maroc et Web Hosting Basic de xneelo en Afrique du Sud. Pour départager les offres, demandez qui peut exclure la page membre et ses routes associées, comment confirmer qu’elles passent jusqu’à WordPress et quelle personne peut désactiver le cache en urgence. Une offre peut convenir en laissant l’espace privé entièrement dynamique, même si le cache de pages publiques se limite à quelques adresses.

Réserver le cache partagé aux réponses publiques

Faites d’abord la liste des routes en fonction de ce qu’elles renvoient. Une actualité identique pour tous les visiteurs anonymes peut être mise en cache. La connexion, la déconnexion, la réinitialisation du mot de passe, le tableau de bord et les documents protégés doivent être examinés séparément. Ajoutez les routes de l’extension qui renvoient les données de profil, y compris les appels JSON visibles dans l’onglet Réseau. Un menu public peut charger un bloc personnalisé après l’affichage de la page ; le cache de ce second appel doit être contrôlé aussi.

Pour le premier déploiement, partez d’une règle simple : conserver seulement les réponses anonymes et publiques, éviter le cache de pages pour toute session connectée et exclure les URL sensibles. Si l’application produit une réponse privée, faites respecter ses directives de cache à chaque couche. Une exclusion fondée sur le chemin doit couvrir ses variantes réelles, y compris le chemin exact, les sous-pages et le mode d’accès que l’extension utilise avec des paramètres.

Vérifiez aussi les droits côté WordPress avec un visiteur anonyme, un adhérent et un compte non autorisé. Une exclusion de cache n’ajoute aucun contrôle d’accès. Si un document peut être ouvert anonymement par son adresse de fichier, corrigez d’abord la protection de la ressource. Pour la même raison, un rendu HTML qui masque un bouton ne prouve pas que l’API et l’adresse du téléchargement sont protégées.

Reproduire le risque en quelques requêtes locales

Le fichier ZIP contient une maquette Node.js sans dépendance, un mode d’emploi et le résultat attendu. La commande lance un serveur sur la boucle locale, fabrique des réponses fictives et l’arrête à la fin. Elle simule deux membres, Alice et Boris, un visiteur anonyme, une page publique et des routes privées. Les marqueurs sont inventés pour la recette. Le script n’installe pas WordPress, ne contacte pas les hébergeurs et n’envoie aucune donnée de production.

La première séquence crée volontairement un cache incorrect qui mémorise les réponses GET à partir du seul chemin, même quand elles sont privées. Après le passage d’Alice, Boris et le visiteur reçoivent le marqueur d’Alice sur la même route. Ce cas négatif sert à vérifier que le protocole détecte la fuite ; il ne reproduit pas une configuration de Nindohost ni de xneelo. Une seconde séquence démarre avec un cache vide et applique des conditions restrictives avant la lecture et l’écriture du cache.

La séquence corrigée demande deux fois l’actualité publique sans session et vérifie qu’elle est effectivement réutilisée. Elle demande ensuite la fiche des deux membres et teste l’accès anonyme. Elle vérifie aussi qu’un visiteur ne reçoit pas la réponse JSON réservée aux membres et qu’une réponse avec un cookie de session n’est pas stockée. Les indicateurs MISS, HIT et BYPASS appartiennent à la maquette. Sur un site réel, leurs équivalents dépendent de la couche active.

• Télécharger le ZIP « Exercice local de cache pour les adhérents » dans « Pour aller plus loin », puis l’extraire et exécuter node recette.mjs depuis le dossier obtenu.
• Comparer les résultats à attendu.json. La démonstration doit détecter la fuite dans le mode incorrect et vérifier l’isolation dans le mode corrigé.

Ce que montre la différence entre les deux séquences

Le faux cache renvoie deux réponses qui n’auraient jamais dû sortir de la session d’Alice. Pour Boris et pour le visiteur sans cookie, le contenu reste marqué FICHE-ALICE et porte pourtant une directive de réponse privée. Cela illustre le danger d’une couche mal configurée qui ignore les instructions de l’application. Le statut 200 seul ne signale rien d’anormal à Boris. Il faut vérifier le corps de la réponse et, si possible, savoir quelle couche l’a servie.

Dans le mode corrigé, la seconde demande d’actualité anonyme reçoit un HIT. La demande connectée, même à cette même adresse, passe sans réutiliser la copie anonyme. Les demandes de fiche reçoivent deux contenus distincts ; le visiteur anonyme est refusé sur la fiche et sur l’API. Une adresse publique avec paramètre est contournée dans la maquette pour éviter d’introduire une clé de cache ambiguë. Ce choix conservateur ne fixe pas la politique de toutes les URL à paramètres d’un vrai site.

Le test vérifie aussi le cas d’une réponse qui pose un cookie alors qu’elle se déclare publique. Dans la maquette, elle n’est pas stockée et une deuxième requête reçoit de nouveau sa propre réponse. Une soumission de connexion est également traitée en dehors du cache. Le contrôle porte sur ces réponses HTTP et leurs marqueurs, sans chronométrage. Il ne vérifie ni l’authentification WordPress réelle, ni une extension de membres, ni un CDN.

Nindohost Plus Site : délimiter LiteSpeed dans WordPress

La page Plus Site annonce cPanel et LiteSpeed avec LSCache. La documentation de LiteSpeed décrit un réglage permettant de mettre des pages en cache privé pour les utilisateurs connectés. Pour ce scénario, l’équipe choisit de ne pas utiliser cette fonction au premier déploiement : les pages connectées restent dynamiques jusqu’à ce que les règles et les droits soient prouvés sur la copie. Cette décision ne désactive pas, à elle seule, un autre cache installé devant le site.

Sur une copie privée, ouvrez LiteSpeed Cache, puis Cache et l’onglet Cache. Vérifiez que le cache de page fonctionne avant de conclure sur sa portée. Réglez Cache Logged-in Users sur OFF. Dans l’onglet Excludes, utilisez Do Not Cache URIs pour les chemins réellement présents, par exemple une règle commençant par ^/membres/ si cette famille existe et une règle distincte pour l’adresse sans barre finale si elle sert du contenu. Ajoutez les routes de l’extension, ses téléchargements privés et les variantes qui ne redirigent pas. Ne reprenez pas les exemples d’URL sans regarder le site.

Si l’extension de membres utilise son propre cookie de session, repérez son nom dans la copie et appliquez l’exclusion Do Not Cache Cookies lorsque le parcours l’exige. Vérifiez qu’aucune règle ne force l’inclusion des URL privées. Purgez le cache de pages de l’extension avec sa boîte à outils, puis faites la recette en alternant les sessions. Le résultat attendu est un indice de cache sur une page publique anonyme et aucun corps personnalisé réutilisé. Si la couche n’est pas disponible ou si les libellés diffèrent, arrêtez l’activation et identifiez le composant réellement fourni.

xneelo Basic : commencer avec la couche que l’équipe contrôle

Basic est un forfait Web Hosting compatible avec WordPress. Le centre d’aide distingue l’usage d’une extension WordPress et Site Cache, le proxy de Web Accelerator. Son guide d’activation fixe Standard comme premier palier admissible pour Web Hosting. La diffusion concerne certains comptes et offres hébergés en Afrique du Sud. Elle ne couvre pas les forfaits hébergés en Allemagne. Demandez la confirmation d’accès pour le forfait et le lieu d’hébergement envisagés avant de changer de formule. Le prix de Basic couvre donc le parcours avec une extension de cache WordPress ou sans cache de page ; il ne faut pas y compter le proxy de xneelo.

Sur Basic, une voie à tester dans WordPress est WP Super Cache, cité dans l’aide de xneelo. Sur une copie, ouvrez Réglages puis WP Super Cache. Utilisez le mode simple et l’option qui exclut les utilisateurs reconnus. Dans les réglages avancés, renseignez les chaînes d’URL à exclure selon le menu de la version installée ; vérifiez que les chemins d’adhésion et les routes d’API sont effectivement écartés. Confirmez l’absence d’une autre couche de cache de pages qui contournerait ces réglages. Le test d’accueil intégré contrôle la réutilisation d’une page publique ; ajoutez vos propres tests à deux comptes.

Si vous envisagez Standard et que Site Cache est disponible sur le compte, identifiez son état dans le panneau Web Hosting, sur le domaine et sous Web Accelerator. L’aide de xneelo demande de retirer les extensions de cache de pages existantes avant l’activation et indique une extension Varnish recommandée. Contrôlez en préproduction la prise en charge des routes, des cookies et des réponses privées par ce montage. Pour ce portail, gardez le proxy hors service tant que ses exclusions d’URL, de session et de réponses privées ne sont pas établies et que le retour au serveur d’origine n’est pas préparé. Si vous ne pouvez pas prouver la séparation, conservez le site dynamique le temps de clarifier les réglages.

Comparer les montants sans inventer un renouvellement

Le relevé du 10 novembre 2026 montre Plus Site à 79 MAD par mois affichés, avec 119 MAD barrés et une mention de lancement. Les deux montants n’établissent ni la durée de cette remise ni le prix de la prochaine échéance. Le cycle facturé et la base de taxe ne sont pas établis sur la carte. Les conditions décrivent une pro forma de renouvellement générée quinze jours avant l’échéance ; cette information ne transforme pas la référence barrée en prix de renouvellement.

xneelo Basic affiche 99 ZAR par mois, TVA comprise au barème public. La documentation des paiements depuis un compte bancaire hors Afrique du Sud prévoit un règlement annuel. Douze fois le prix public donne un repère de 1 188 ZAR pour Basic. Standard est affiché à 149 ZAR, soit 1 788 ZAR sur douze mois à barème constant hors domaine. Site Cache est annoncé sans supplément pendant la diffusion limitée pour les comptes admissibles. Demandez si vous y avez accès et quel prix s’appliquera après cette phase. La grille ne montre pas de prix d’appel distinct pour ces paliers. Les conditions prévoient la possibilité de modifier les tarifs ; le renouvellement n’est donc pas garanti à ces montants.

Pour comparer les budgets, demandez les deux échéances pour un même périmètre : hébergement, éventuelle couche de cache, domaine et taxes. Ne classez pas deux montants libellés en MAD et ZAR par leur seule valeur numérique. Si votre équipe doit tenir un budget dans une autre devise, notez le taux effectivement proposé par son moyen de paiement et les frais, au moment où elle décidera. Aucun paiement, panier ni change n’a été vérifié ici.

Rejouer la recette sur une copie de votre portail

Préparez deux utilisateurs fictifs avec le même rôle d’adhérent et des données de profil différentes, puis une session sans connexion. Le même rôle rend le test plus exigeant : un cache partagé par rôle ne doit pas suffire à distinguer leurs fiches individuelles. Utilisez des profils de navigateur séparés. Plusieurs fenêtres privées d’un même navigateur peuvent partager les cookies. Placez un marqueur distinct et inoffensif dans chaque fiche et dans la réponse d’API si votre portail l’utilise.

Commencez avec le cache désactivé pour prouver que les accès se comportent comme prévu. Activez ensuite une seule couche de cache de pages sur la copie et purgez-la. Sans vous connecter, chargez deux fois la même page d’actualité, puis ouvrez l’URL identique de la fiche avec Alice, Boris et le visiteur dans cet ordre. Purgez et recommencez en inversant les deux membres. Contrôlez les redirections, la page après déconnexion et les ressources privées ouvertes par un lien direct. Retenez le résultat attendu pour chaque étape, y compris le refus du visiteur.

Dans les outils réseau du navigateur, notez le statut, la réponse affichée, les directives de cache et les indices propres à la couche active. Ne transmettez pas les cookies, jetons ou corps privés dans le rapport ; relevez seulement la présence d’un marqueur fictif. Si vous testez un CDN devant le serveur, répétez depuis l’adresse publique de la copie. Une réussite observée en accédant directement à l’origine ne prouve pas la séparation quand le proxy est dans le trajet.

Garder un retour rapide et choisir le bon forfait

À la première réponse étrangère à la session, interrompez l’essai. Désactivez la couche de cache de pages concernée et purgez les réponses déjà produites dans les couches qui peuvent encore les servir. Pour LiteSpeed, la documentation indique que désactiver Enable Cache arrête le cache de page et efface ses copies. Pour WP Super Cache, désactivez le cache dans ses réglages et videz les fichiers mis en cache avec l’interface, sans supprimer les fichiers de contenu. Rejouez ensuite la fiche et les liens privés sans cache.

Si vous avez activé le proxy de xneelo sur un autre palier, le guide indique le retrait dans Web Hosting, sur le domaine, puis Web Accelerator et Site Cache. Préparez à l’avance la destination d’origine et les réglages DNS de retour. Quand xneelo gère la zone, son guide indique que le retrait réoriente les enregistrements vers le serveur ; si elle est ailleurs, le responsable de la zone doit faire pointer les enregistrements du site vers le serveur d’origine avant de désactiver le proxy, selon le guide de xneelo. Vérifiez HTTPS et les réponses des deux comptes après propagation. L’assistance annoncée ne garantit ni le réglage d’une extension tierce ni un délai de reprise.

Plus Site est le choix à examiner si l’équipe veut contrôler LSCache depuis WordPress et obtenir par écrit le cycle et le prix de renouvellement. Basic est une piste si elle préfère tester un cache de pages dans WordPress sans payer un palier pour le proxy. Si aucune couche ne permet de reproduire l’isolation, gardez les réponses d’adhésion dynamiques et revenez au cache public seulement lorsque la recette passe. Pour ce portail, une économie sur le prix ou une page publique plus rapide ne remplace pas la séparation des sessions.

Pour aller plus loin

• Consulter la fiche Nindohost
• Consulter la fiche xneelo
• Identifier la couche de cache qui sert une ancienne réponse
• Exercice local de cache pour les adhérents (ZIP)