Un site international n’est pas un site local avec un menu de langues. Chaque locale est une URL, un texte attendu, et parfois un fuseau où la panne tombe en pleine journée. Le monitoring doit suivre ces trois écarts. Le fait de mesurer depuis plusieurs villes est un autre sujet : il est traité dans le guide du monitoring multi-localisations.
Une URL, une langue, une chaîne attendue
Listez les URL publiques, pas le sélecteur de langue. Selon le site, ce sera des dossiers (/fr/, /en/, /de/), des sous-domaines, ou des noms de domaine distincts. Chaque ligne a son contrat :
- le code HTTP attendu, en général 200 sur la page finale ;
- la redirection normale, par exemple
/vers/fr/pour le marché principal, et rien d’autre ; - une chaîne qui n’existe que dans cette langue. Le titre allemand ne doit pas apparaître comme preuve que la page française est bonne, et l’inverse non plus.
Le piège classique est le repli silencieux. La locale demandée n’existe plus, le CMS sert la langue par défaut, le code reste 200. Un contrôle sans chaîne de langue classe ça comme un succès. Un visiteur allemand lit du français, ou une page « translation missing ».
Choisissez une chaîne courte et stable : le libellé du bouton d’achat, le nom d’un menu, pas une phrase marketing qui change chaque semaine. Quand le texte légitime change, mettez à jour le contrôle le même jour, sinon vous fabriquez une fausse panne.
Fuseaux et fenêtres de maintenance
Une mise en maintenance annoncée « cette nuit » n’a de sens que si la nuit est celle du public. Notez trois horloges quand l’équipe et les clients ne partagent pas le même fuseau : l’heure de l’équipe qui déploie, l’heure du marché principal, l’heure du marché où la page est un tunnel de commande.
Le contrôle, lui, doit continuer pendant la fenêtre, mais l’alerte peut être tue si vous avez déclaré la maintenance. Sans cette déclaration, chaque 503 de la fenêtre ouvre un incident. Avec une fenêtre trop large, une vraie panne qui commence « pendant la maintenance » et qui continue après ne sonne pas. Tenez la fenêtre au créneau réel, en heures UTC dans l’outil pour éviter les ambiguïtés d’heure d’été.
Le certificat et le DNS sont souvent partagés par toutes les langues. Leur échec coupe tout le monde en même temps. Les contrôles de contenu, eux, peuvent échouer sur une seule locale : fichier de traduction absent, route non déployée, cache de langue mélangé. Gardez les alertes séparées par URL, sinon l’incident « site international » cache quelle langue est en cause.
Ce qui ne se confond pas avec une sonde étrangère
Placer un point de mesure à Singapour ne vérifie pas que /zh/ contient du chinois. Cela vérifie que, depuis ce réseau, la requête aboutit. Un site bilingue français-anglais hébergé en Europe peut être international par son contenu et n’avoir qu’un seul point de mesure au début. À l’inverse, un site uniquement français servi par un CDN mondial a un sujet de sondes, pas un sujet de langues.
Les balises hreflang et la cohérence des canoniques se contrôlent dans le HTML et dans Search Console. Elles n’entrent pas dans le critère de disponibilité. Une page peut être parfaitement disponible et mal déclarée aux moteurs, ou l’inverse.
Si une locale a un paiement ou un prix dans une devise, ajoutez cette URL au même titre qu’une page de commande locale : le monitoring d’une page précise s’applique à chaque marché, pas seulement à l’accueil du pays d’origine.
SiteGarde peut suivre ces URL une par une, avec un contenu attendu différent. Le choix des lieux de mesure, quand vous en avez plusieurs, se règle à part. Ne le substituez pas à la liste des langues.