LWS ou o2switch pour vérifier la lecture d’un PDF WordPress après son remplacement

Le téléchargement est à jour, la reprise affiche encore l’ancienne édition

Une association publie un guide PDF sur WordPress. Elle remplace le fichier après avoir corrigé une annexe, en conservant son adresse. Le téléchargement intégral donne la bonne édition. Sur un poste qui avait commencé à lire le guide, le lecteur intégré affiche encore des pages anciennes ou signale un document illisible quand on saute à l’annexe. Il peut demander des plages d’octets au lieu de recharger le document d’un seul bloc.

Dans cette recette, la preuve de référence est le fichier source de la nouvelle édition. Comparez les réponses complètes et partielles de l’origine et de l’adresse publique. Une réponse partielle peut avoir la bonne longueur et la bonne position tout en contenant les octets de l’ancienne version. Le résultat attendu est une lecture cohérente de bout en bout, même si un cache a déjà servi l’ancienne édition.

Le comparatif oppose LWS Starter, proposé sur la page WordPress de LWS, à o2switch Grow. Les deux hébergeurs documentent des outils de diagnostic de cache. Le test porte sur un document public servi par une URL directe. Pour une extension qui contrôle l’accès aux téléchargements, les règles d’authentification et les éventuelles redirections doivent être vérifiées dans son propre parcours.

Tarifs, capacités et périmètre de la recette

LWS affiche Starter à 3,49 € HT par mois en promotion, avec 4,19 € TVA comprise pour le prix mensuel affiché, et une référence barrée de 5,99 €. Le barème explique le passage du tarif promotionnel au tarif standard à la fin de la première période. Sur douze mois à tarif constant, ces repères correspondent à 41,88 € HT et 71,88 € HT. Le montant et la durée facturés dépendent du bon de commande. L’aide indique une reconduction automatique activée par défaut à la commande, avec réglage par service.

Starter annonce 200 Go de stockage, dix sites et vingt-cinq adresses e-mail. Le quota global donne une indication de capacité pour conserver plusieurs éditions. Pour un document volumineux, vérifiez aussi le plafond applicable à un fichier et le mode de transfert. Les conditions du mutualisé LWS indiquent une taille unitaire maximale de 500 Mo. Ce plafond contractuel peut être supérieur à celui du téléversement par WordPress sur votre compte.

o2switch affiche Grow à 7 € HT par mois pour douze mois, soit 84 € HT, et le même repère pour un renouvellement d’un an. L’aide annonce huit threads CPU, 16 Go de mémoire, 16 Mo/s d’entrées-sorties et quatre sous-comptes « lunes » qui partagent les ressources du compte principal. La formule annonce de l’espace disque illimité. Cela ne fournit ni un débit de téléchargement garanti ni une mesure du comportement d’un fichier servi derrière un cache.

Vérifiez séparément la date et le mode de reconduction du domaine et de l’hébergement. Pour o2switch, la documentation explique comment sélectionner le renouvellement par prestation et précise que l’enregistrement de la carte peut l’activer à la commande. Les tarifs et ressources cités ont été relevés le 11 novembre 2026. Pour le choix, regardez surtout quel parcours permet d’observer le fichier au travers des couches qui le livreront au public.

Comparer des octets de la même représentation

Sur une copie privée autorisée, téléchargez la version complète de la nouvelle édition et calculez son empreinte SHA‑256. Relevez la longueur, le type de contenu et, s’il existe, l’ETag. Testez ensuite l’adresse publique prévue en notant les redirections vers l’adresse finale. La page WordPress qui contient le lecteur et le fichier PDF peuvent suivre des routes différentes. L’échantillon doit viser l’adresse réellement demandée par le lecteur.

Demandez deux plages courtes à des positions distinctes, par exemple les octets 0 à 1023 puis 8192 à 9215 sur un document assez grand. Demandez un encodage identité pour comparer les octets du fichier brut si le serveur accepte cette représentation. L’en-tête Content-Range d’une réponse 206 doit donner le début et la fin inclusifs, puis la taille totale. Vérifiez aussi que la longueur reçue correspond à l’intervalle et comparez les octets avec les mêmes positions dans la référence.

Un serveur peut ignorer Range et renvoyer le fichier entier en 200. Vérifiez alors le corps complet et observez si le lecteur sait reprendre ou doit tout télécharger. Un 416 est cohérent lorsqu’une plage commence au-delà de la fin. Un affichage correct de l’accueil ou l’annonce Accept-Ranges ne permet pas de déduire la réponse à une requête partielle sur le fichier.

Dans l’onglet Réseau, enregistrez l’URL finale, les en-têtes et la chronologie des requêtes après avoir sauté vers une page tardive. Si le lecteur récupère toujours le fichier entier, vérifiez la présence de la nouvelle édition dans le document affiché. Un second essai dans une session qui avait déjà ouvert l’ancienne version permet d’observer la reprise avec un état antérieur. Faites aussi l’essai dans une session neuve pour distinguer un état du navigateur d’une réponse périmée servie à plusieurs visiteurs.

Vérifier le validateur avant de reprendre la lecture

Relevez l’ETag de l’ancienne édition avant le changement, si le serveur en fournit un. Dans une requête Range, If-Range indique que le client souhaite une plage de cette édition. Utilisez un ETag fort pour ce test. Une valeur préfixée par W/ est faible et ne convient pas à If-Range. Si le validateur correspond à la nouvelle édition, une réponse 206 peut poursuivre la lecture avec ses octets. Si le validateur a changé, la réponse complète de la nouvelle édition permet de recommencer avec une seule représentation.

Le standard HTTP permet à un cache de combiner des plages qui partagent le même validateur fort. Après le remplacement d’un fichier sous la même adresse, comparez les validateurs et le corps des plages. Des fichiers de même longueur peuvent avoir des contenus différents. Si vous retrouvez le même ETag pour des corps différents, signalez cette incohérence avec deux empreintes et les heures du relevé.

Pour un PDF de recette assez petit, téléchargez toutes les plages consécutives et reconstituez le fichier. Une suite de 206 peut sembler correcte alors que l’un des fragments est périmé. Comparez l’empreinte de la reconstitution à celle du fichier d’origine. Avec un document volumineux, échantillonnez une plage au début et des plages couvrant une partie modifiée. Notez la couverture du test et contrôlez aussi l’ouverture de l’annexe depuis le lecteur réellement utilisé.

Isoler la route et le cache chez LWS

Sur LWS Panel, l’aide indique Optimisation et performance, puis LWSCache (Varnish). Elle documente le vidage du cache et une désactivation temporaire. Sur une copie réservée à la recette, relevez les en-têtes de la même URL avant et après avoir modifié ce seul réglage. Utilisez le nom qui présente le bon certificat et le même chemin de fichier. Si le document passe aussi par un CDN, relevez son rôle avant de conclure sur le cache de l’hébergeur.

Testez ensuite la nouvelle édition en accès direct et dans la page WordPress. Si l’accès direct rend les bons octets et que le lecteur demande encore l’ancien chemin, corrigez le lien ou la page qui contient ce lecteur. Si le chemin demandé est correct et que les plages sont anciennes, conservez les en-têtes et les empreintes avant de vider le cache. Après la purge, répétez les mêmes requêtes deux fois pour observer le premier accès et un accès ultérieur.

Starter annonce WordPress Manager. La page WordPress présente le clonage et le staging parmi ses outils. Vérifiez qu’une copie de recette peut atteindre les mêmes couches de livraison que le futur nom public. Réactivez ensuite le réglage du cache utilisé pour le site et relancez le contrôle. Si la copie privée utilise un autre chemin de cache, refaites un test ciblé sur l’adresse publique lorsque la publication de l’édition est autorisée.

Distinguer les outils o2switch utilisés par le domaine

Chez o2switch, identifiez dans cPanel l’outil effectivement actif. Si c’est XtremCache, le guide décrit une vérification sur une URL, un vidage de cache par domaine et une désactivation temporaire sans changement d’IP. Il distingue cette désactivation de la remise à zéro, qui change l’adresse du domaine. Pour diagnostiquer un fichier, commencez par une recette sur le domaine d’essai et comparez la même plage avec le cache actif puis temporairement désactivé.

Si le domaine utilise LiteSpeed LSCache via l’outil WebADC, suivez son parcours spécifique. La documentation indique que l’activation peut changer l’adresse IP, que l’outil cPanel ne s’applique pas aux sous-domaines et que la combinaison avec Cloudflare n’est pas prise en charge. Évitez de modifier l’activation sur un domaine public juste pour effectuer un test de plage. Notez l’adresse effectivement utilisée, vérifiez les en-têtes et planifiez les changements d’architecture séparément.

Grow annonce quatre « lunes », des comptes cPanel distincts qui se partagent les ressources. Vous pouvez préparer une copie à l’écart de la production. Si elle utilise un sous-domaine ou une autre route de cache, son résultat valide les fichiers et les liens de la copie. Pour vérifier la livraison réelle, faites aussi le test de plage sur le nom qui servira le document aux visiteurs.

Publier l’édition à une nouvelle adresse et garder un retour possible

Donnez à la nouvelle édition un nom de fichier distinct, par exemple guide-2026-11.pdf. Déposez-la, puis ouvrez son adresse publique et vérifiez les plages avant de modifier la page WordPress. Une adresse par édition évite de réutiliser une entrée de cache créée pour d’autres octets. Un paramètre ajouté à la même URL peut être ignoré ou normalisé par un intermédiaire selon sa configuration. Vérifiez le comportement réel si vous utilisez cette voie.

Remplacez le lien dans le bouton, le bloc Fichier et les éventuels lecteurs intégrés qui devaient viser l’édition actuelle. Vérifiez ensuite la page en visiteur et dans une session qui avait déjà ouvert l’ancienne édition. Un cache de page peut encore servir un lien ancien alors que le fichier versionné est correct. Si vous avez besoin d’une adresse stable pour communiquer, pointez depuis une page stable vers le fichier de l’édition actuelle et contrôlez la date affichée.

Conservez une référence de la version précédente et le lien publié avant modification. En cas de régression, rétablissez ce lien si l’ancienne édition peut encore être diffusée. Si une correction réglementaire ou éditoriale impose son retrait, convenez du traitement des anciennes adresses et des caches avec le responsable du site. Vérifiez les redirections et la version lue après chaque correction.

Rejouer les réponses avant d’intervenir sur le site

Le ZIP démarre un serveur HTTP sur l’adresse de boucle locale. Il fabrique deux éditions binaires de même taille et injecte une plage ancienne à l’adresse publique. Le téléchargement complet donne la nouvelle édition. Le deuxième 206 présente pourtant un intervalle et une longueur corrects pour des octets périmés. Le script compare les empreintes de chaque plage puis celle du fichier reconstitué.

Le test relance la reprise avec le validateur actuel, puis avec celui de l’ancienne version. Il observe un 206 pour la bonne plage et un 200 complet lorsque le validateur a changé. Il vérifie aussi le 416 d’une plage hors fichier et un parcours qui ignore Range et renvoie le fichier entier. Avec l’adresse versionnée, les quatre plages reconstituent la référence.

Pour appliquer le même contrôle à une copie autorisée, utilisez le panneau Réseau du navigateur ou une requête HTTP qui enregistre les en-têtes et le corps séparément. Sous Windows, par exemple, utilisez curl.exe avec les options -D pour le fichier d’en-têtes, -o pour les octets, et -H pour définir Range et Accept-Encoding. Comparez la plage à celle du fichier téléchargé par un canal de référence. Le banc travaille sur des octets fictifs. Le rendu du PDF et le comportement du cache restent à vérifier sur le parcours réel.

Choisir selon la route que l’équipe peut vérifier

LWS Starter convient si l’équipe utilise LWS Panel et peut répéter le même relevé avant et après le réglage de LWSCache. Les 200 Go donnent un repère pour conserver les éditions utiles. Confirmez la durée de promotion, le plafond applicable au fichier et le mode de publication sur le compte. Une simple purge du cache de page doit être suivie du contrôle de l’URL du PDF.

o2switch Grow convient si l’équipe travaille dans cPanel et peut identifier le cache du domaine et la portée de ses réglages. La désactivation temporaire d’XtremCache facilite une comparaison à route constante lorsque cet outil est actif. Si le site utilise WebADC, prenez en compte les contraintes de domaine et de CDN documentées avant toute modification. Les ressources partagées des lunes doivent aussi entrer dans le planning de la recette.

Validez la mise à jour quand la page pointe vers la bonne édition, que les plages observées contiennent les octets attendus et que le lecteur peut atteindre la section modifiée. Gardez les empreintes, l’ETag s’il existe, les horaires et les URL finales. Si une divergence persiste, laissez le lien validé en place le temps d’isoler la couche fautive et conservez les traces avant de purger.

• Télécharger et identifier la version de référence.
• Comparer l’entier et les plages sur la route finale.
• Vérifier le comportement de reprise avec un validateur fort.
• Tester le lecteur sur la page WordPress et contrôler le lien de retour.

Pour aller plus loin

• Lire la fiche LWS
• Lire la fiche o2switch
• Comparer les outils de performance WordPress
• Télécharger l’exercice de lecture par plages