Infomaniak ou Hostpoint pour vérifier une police WordPress après migration

La page s’ouvre et le navigateur affiche la police de secours

Un magazine déplace son WordPress vers une nouvelle adresse. Les titres et les menus restent lisibles. Sur la nouvelle adresse, leurs largeurs et leurs retours à la ligne changent, alors que la page est censée utiliser la même police. Dans l’onglet Réseau, le fichier de police apparaît avec un statut 200. Le navigateur peut avoir téléchargé les octets puis refusé de les utiliser, car la police vient d’une autre origine.

Le scénario suit une police publique déclarée par une règle CSS @font-face. L’origine d’un document est le triplet protocole, hôte et port. Un sous-domaine de fichiers peut donc constituer une autre origine, même si le domaine appartient à la même organisation. Les règles de chargement des polices demandent alors une autorisation CORS dans la réponse du serveur de fichiers. L’état de la police et les messages de la console donnent la preuve côté navigateur.

Le comparatif oppose Infomaniak Hébergement Web et Hostpoint Hébergement Web Standard. Les deux permettent de publier des fichiers WordPress et de les servir en HTTPS. Infomaniak documente l’en-tête d’autorisation et ses paramètres de serveur. Hostpoint documente les en-têtes dans Apache avec .htaccess. Le choix dépend surtout de l’endroit qui sert réellement la police et des droits de configuration sur cette route.

Tarifs et conditions des deux offres suisses

Infomaniak affiche son Hébergement Web à partir de 10,91 CHF par mois. Le tableau des caractéristiques précise que les prix sont hors TVA et que la facturation est annuelle par défaut. Le paiement trimestriel ou mensuel dépend du montant et de la configuration. Sur douze mois à ce repère, le calcul donne 130,92 CHF HT. Demandez le montant du prochain cycle sur le produit configuré. L’offre annonce 250 Go de stockage SSD et vingt sites inclus, avec des ressources mutualisées.

L’aide d’Infomaniak indique que le renouvellement automatique peut s’activer lors d’une commande ou d’un renouvellement avec un moyen de paiement pris en charge. Lorsqu’il est actif, la première tentative a lieu quatorze jours avant l’échéance. Vérifiez le statut du service, le moyen de paiement et la date. Si les polices restent sur un autre compte, prévoyez aussi l’échéance et les accès de celui-ci.

Hostpoint affiche Standard à 15,90 CHF par mois avec TVA incluse selon la page d’offres, soit 190,80 CHF TTC sur douze mois au même tarif. La formule annonce 100 Go de stockage Web, dix domaines et dix bases MariaDB. L’aide donne des durées de six, douze ou vingt-quatre mois pour l’hébergement Web. Elle indique une reconduction pour la même durée et une résiliation au plus tard trente jours avant l’échéance. Vérifiez le cycle proposé et le montant applicable au prochain contrat.

Les prix du 11 novembre 2026 sont exprimés dans la devise des offres. Les montants annualisés gardent la qualification fiscale de leur source. La correction d’une police ne dépend ni du volume de disque ni d’une promesse de débit. Utilisez les ressources pour évaluer le nombre de sites et la coexistence de la copie. Pour la police, vérifiez l’accès au dossier ou au serveur de fichiers qui répond à la requête.

Retrouver la police que le navigateur demande

Sur une copie privée, ouvrez une page où la police devrait s’appliquer. Dans les outils du navigateur, inspectez un titre ou une ligne de texte. Relevez la police calculée, puis la police effectivement rendue si le navigateur donne cette information. Filtrez le panneau Réseau sur les polices et identifiez l’adresse finale après redirection. Le lien peut venir d’une feuille de style du thème, d’une extension ou d’un fichier CSS généré.

Notez le poids, le format et la provenance de chaque variante utilisée. Une police normale peut charger tandis que l’italique ou le gras reste bloqué sur une ancienne adresse. Comparez au minimum deux variantes réellement utilisées et un texte représentatif. Les accents, la ponctuation et les caractères de navigation peuvent être répartis sur des fichiers ou des plages de caractères différents.

Relevez l’origine finale du document, l’en-tête Origin de la demande et les en-têtes reçus sur le fichier. Si le navigateur signale une politique de contenu, vérifiez la directive font-src du document. Si le message concerne CORS, vérifiez Access-Control-Allow-Origin sur la réponse de la police. Si le navigateur signale un format ou des octets invalides, comparez le fichier reçu à la source et vérifiez qu’une redirection n’a pas livré du HTML sous une adresse de police.

Si aucune requête de police ne part, vérifiez d’abord que la déclaration CSS est chargée, qu’elle correspond au poids demandé et qu’un élément l’utilise effectivement. Ouvrez ensuite la console pour voir si la politique du document a bloqué la demande avant son envoi. Une autorisation sur le serveur de fichiers ne règle pas un blocage de la page. Quand la requête part, enregistrez le type et l’empreinte du fichier reçu, puis comparez-les à une copie locale dont vous connaissez l’origine. Cela évite de traiter une page d’erreur renvoyée en 200 comme une police.

Choisir l’adresse de la police avant de modifier les en-têtes

Si le thème ou l’extension peut charger la police depuis le même hôte que la page, faites d’abord cet essai sur la copie. Importez une police dont le site détient les droits de diffusion. Sur un site qui utilise la Bibliothèque de polices de WordPress, vérifiez les variantes installées et réassociez-les aux styles concernés. Sur un thème qui les déclare dans une feuille CSS, relevez le chemin de cette feuille et l’adresse calculée pour la police. Un chemin relatif se résout depuis la feuille de style.

Quand un autre hôte doit continuer de servir la police, configurez l’autorisation sur la réponse du fichier. L’en-tête Access-Control-Allow-Origin doit viser l’origine exacte du document pour le parcours testé. Conservez le protocole et le port éventuel, puis vérifiez la valeur sur l’adresse finale. Un en-tête dans la réponse de la page WordPress ne corrige pas à lui seul la réponse du fichier hébergé ailleurs.

Si le serveur décide de l’autorisation d’après l’en-tête Origin, le standard Fetch prévoit de signaler cette variation aux caches avec Vary: Origin. Si une seule origine est autorisée par une valeur statique, vérifiez que cette valeur reste identique sur la route réelle. Limitez la règle au dossier ou aux fichiers publics qui en ont besoin. Vérifiez aussi qu’une couche intermédiaire n’ajoute pas une deuxième valeur concurrente.

Infomaniak. Identifier la couche qui sert la police

Le tableau d’Infomaniak annonce Apache, FTP et SSH pour l’Hébergement Web. L’aide explique comment créer un fichier .htaccess et décrit Access-Control-Allow-Origin dans une réponse PHP. Si votre URL de police est traitée par PHP, placez la règle dans le traitement qui sert réellement cette réponse. Si le serveur envoie directement un fichier statique, cherchez le réglage de ce dossier ou du CDN. Un réglage exécuté uniquement par PHP peut être absent de cette réponse statique.

Sur une copie, relevez le nom du site, le dossier et l’adresse finale de la police. Vérifiez que vous disposez des droits sur cet emplacement avant de changer un fichier de configuration. Si Apache et mod_headers prennent en charge le réglage sur ce dossier, l’exemple joint permet de tester une autorisation limitée à un fichier et à une origine. Gardez le fichier précédent et vérifiez que l’en-tête apparaît sur la réponse du fichier, puis que le navigateur utilise la police.

Si les polices restent sur un service externe que l’équipe ne peut pas configurer, faites une recette sur une copie autorisée de la police servie depuis le site. Rejouez les pages qui utilisent cette variante et vérifiez l’adresse observée dans le navigateur. Cette voie réduit la dépendance à la configuration du serveur de fichiers. Elle reste conditionnée au droit de redistribuer la police et à la disponibilité des variantes utilisées.

Hostpoint. Tester la règle Apache au niveau du fichier

Le guide Hostpoint sur les en-têtes HTTP décrit une configuration .htaccess avec mod_headers. Il indique que ce fichier peut être édité depuis l’explorateur du panneau ou avec les accès aux fichiers. Sur la copie, ouvrez le dossier qui sert les polices. Conservez son réglage actuel, puis essayez une règle limitée à un fichier test. La page Standard ne constitue pas une preuve de prise en compte d’une règle sur un domaine ou une route donnés.

Vérifiez la réponse HTTP avec l’origine attendue, puis rejouez le chargement dans le navigateur. Si le fichier passe par une redirection ou un service qui répond avant Apache, observez la réponse finale et cherchez où appliquer la règle. Lorsqu’une réponse 500 apparaît après modification du fichier, remettez le réglage initial et vérifiez à nouveau le dossier et les directives disponibles.

Si la police est maintenant chargée dans la copie, rejouez l’essai sur le parcours qui sera réellement servi au public. Une copie test peut utiliser une origine différente. Une règle limitée à cette origine doit être adaptée et vérifiée avant l’ouverture. Les journaux d’accès et d’erreur documentés dans le panneau aident à corréler une réponse serveur, tandis que le navigateur reste la preuve de chargement et de rendu.

Comparer une page neuve et une page déjà en cache

Après correction, ouvrez d’abord la page avec une session qui ne possède ni son ancien CSS ni la police en cache. Relevez l’adresse de la feuille CSS, de la police et l’en-tête retourné. Ouvrez ensuite la même page avec une session qui a déjà chargé l’ancienne version. Si les deux résultats diffèrent, comparez les adresses et le contenu du CSS. Une ancienne feuille peut encore pointer vers le nom de fichiers précédent.

Vérifiez aussi le site avec le nom effectivement affiché après redirection. La variante avec www, l’adresse sans www et la préproduction peuvent constituer des origines différentes. Une autorisation réglée pour l’une ne prouve pas la présence de la police sur l’autre. Consignez les origines que le site sert réellement et testez chaque variante nécessaire avant de clore la migration.

Si le navigateur charge la police mais continue d’afficher une autre famille sur un élément, inspectez les règles de style et le poids appliqué. La famille peut avoir été chargée pour une autre partie de la page. Contrôlez deux pages représentatives et les zones dont la largeur avait changé. Gardez une capture de la police effectivement rendue, avec le nom de la variante et l’adresse du fichier.

Rejouer les cinq cas dans un navigateur local

Le ZIP contient une vraie police Barlow et démarre deux serveurs HTTP locaux. Ils utilisent le même hôte et deux ports, ce qui crée deux origines. Chrome charge une page avec cinq déclarations @font-face. Le script interroge l’état de chargement et relève séparément les en-têtes et l’empreinte du fichier. Les quatre réponses qui contiennent la police valide transportent les mêmes octets.

La police de même origine et la police dont l’en-tête autorise l’origine exacte sont chargées. Le navigateur refuse une réponse 200 sans en-tête et une autre qui vise une origine différente. Le dernier cas répond aussi 200 avec la bonne autorisation, mais contient des octets invalides. Il échoue à son tour. Le résultat permet d’isoler le défaut sans changer le thème ni l’hébergement.

Le ZIP a été extrait et rejoué sous Chrome en mode sans fenêtre. Les requêtes et les décisions du navigateur sont réelles. Les serveurs, noms d’essai et règles sont locaux. Utilisez la fiche jointe pour répéter les observations sur une copie WordPress. Le résultat à vérifier sur le site est la police réellement rendue, avec le fichier et la variante attendus.

Choisir selon les accès au serveur de fichiers

Infomaniak Hébergement Web convient si l’équipe gère la page et son dossier de ressources dans le Manager, ou si elle peut configurer la réponse du service externe qui sert les polices. Le volume de stockage et le nombre de sites donnent de la place pour la coexistence de la copie et du site public. Vérifiez le chemin exact et la couche qui répond avant de retenir un réglage d’en-tête.

Hostpoint Standard convient si l’équipe veut contrôler le fichier de configuration et les journaux du site depuis le panneau ou l’accès aux fichiers. Vérifiez la durée de contrat retenue, le quota et l’application du réglage sur le chemin public. Si un service externe assure la diffusion, ses en-têtes déterminent le résultat indépendamment de l’hébergement de la page.

Validez la migration quand le navigateur charge les fichiers attendus, que les variantes utilisées sont correctes et que la page garde sa mise en forme sur les origines publiques prévues. Gardez les adresses, les en-têtes et le réglage précédent pour le retour. Si une variante reste en échec, conservez le parcours déjà validé et corrigez le fichier, son origine ou la règle qui décide de sa remise.

• Relever la police rendue et l’adresse finale de chaque variante.
• Comparer l’origine de la page et l’en-tête de la réponse du fichier.
• Vérifier le chargement dans une session neuve et une session ayant déjà ouvert le site.
• Conserver le réglage initial et la preuve de chargement.

Pour aller plus loin

• Lire la fiche Infomaniak
• Lire la fiche Hostpoint
• Comparer les outils de performance WordPress
• Télécharger l’exercice de diagnostic des polices (ZIP)