Outre la lecture des données de Google, SaaSMaestro peut visiter lui-même vos sites pour détecter des problèmes dont Google ne vous informe pas. Les vérifications se trouvent sous Santé des sites dans Paramètres → votre espace de travail → Connexions de données. Chacune est un service distinct, désactivé tant qu’un propriétaire ou un admin ne l’active pas dans sa boîte de dialogue, où il choisit aussi les sites concernés. Rien à installer.
Les vérifications proviennent de nos serveurs à l’adresse 35.214.110.192. Si votre site est protégé par un pare-feu, Cloudflare ou un plugin de sécurité, ajoutez d’abord cette adresse à la liste blanche. Voir Ajouter notre adresse IP à la liste blanche.
Les services
| Service | Fréquence | Ce qui est examiné |
|---|---|---|
| Surveillance de disponibilité | Toutes les 15 minutes | Si la page d’accueil répond, confirmé depuis d’autres régions avant qu’une panne soit déclarée, plus des vérifications quotidiennes de la balise Google, de robots.txt, du sitemap et des pages, et un rapport mensuel. |
| Surveillance des certificats SSL | Hebdomadaire | Quand le certificat expire, qui l’a émis, et si les visiteurs obtiennent réellement HTTPS. |
| Surveillance des domaines | Hebdomadaire | Quand l’enregistrement du domaine expire, le registraire, et les blocages du registre. |
| DNS et sécurité des e-mails | Quotidien | Changements de serveurs de noms et de serveurs de messagerie, et enregistrements SPF, DMARC et DKIM. |
| Liste noire et malware | Quotidien | La liste Web Risk de Google des sites dangereux et la liste de malware URLhaus d’abuse.ch. |
| En-têtes de sécurité | Hebdomadaire | Six en-têtes de sécurité courants, notés de A à F, et fichiers chargés en HTTP simple. |
| Performance en laboratoire | Hebdomadaire | Un test PageSpeed Insights de la page d’accueil mobile, avec son score au fil du temps. |
| Core Web Vitals | Quotidien | Vitesse réelle des visiteurs issue du Chrome UX Report, lue lors des vérifications quotidiennes de la Surveillance de disponibilité une fois sa clé d’API définie. |
| Vérifications des pages clés | Toutes les 5, 15 ou 60 minutes | Les pages que vous choisissez, comme les tarifs ou l’inscription, doivent se charger et contenir le texte indiqué. |
| Surveillance des heartbeats | Aussi souvent que vous le définissez | Vos propres tâches cron, sauvegardes et workers appellent une adresse privée ; vous êtes alerté lorsque l’un d’eux se tait. |
Lorsqu’un nouveau site est ajouté, les services déjà activés pour l’espace de travail vous sont proposés. Les avertissements des vérifications SSL, de domaine, DNS, de liste noire, d’en-têtes de sécurité et de performance sont envoyés par e-mail aux propriétaires et admins sous le nom « Alertes de problèmes critiques » dès qu’une vérification les détecte, une seule fois chacun, et à tout canal de discussion qui les accepte.
Disponibilité
La page d’accueil de chaque site est vérifiée toutes les 15 minutes. Un site n’est considéré comme indisponible qu’après deux vérifications échouées d’affilée, ce qui évite les fausses alertes dues à une seule réponse lente. Les réponses comme « non autorisé » ou « trop de requêtes » comptent comme en ligne, car le serveur répond.
Avant qu’un second échec soit déclaré comme une panne, des serveurs d’autres régions chargent aussi le site. Si la plupart y parviennent, le problème se situe entre notre serveur principal et le site, comme une panne réseau ou une règle de pare-feu, et aucune panne n’est donc déclarée. La boîte de dialogue Surveillance de disponibilité liste les régions utilisées.
Lorsqu’un site tombe, les propriétaires et admins reçoivent immédiatement un e-mail d’indisponibilité (au plus une fois par panne et par semaine), et un problème critique est créé jusqu’à son rétablissement. Le 1er de chaque mois, ils reçoivent aussi un rapport de disponibilité mensuel avec la disponibilité et les pannes de chaque site sur le mois précédent ; chacun peut le désactiver pour soi sous Notifications.
Vérifications quotidiennes
Ces vérifications s’exécutent avec la Surveillance de disponibilité, une fois par jour pour chaque site concerné.
| Vérification | Ce qui est examiné |
|---|---|
| Balise Google | Si la page d’accueil contient la balise GA4 de ce site, un autre ID GA4, Google Tag Manager, ou rien. |
| robots.txt | S’il existe, s’il a changé et s’il bloque tous les moteurs de recherche. |
| Sitemap | Le nombre d’URL qu’il répertorie, en lisant jusqu’à 10 sitemaps enfants. |
| Core Web Vitals | La vitesse vécue par les vrais visiteurs, d’après le Chrome UX Report : Largest Contentful Paint, Interaction to Next Paint et Cumulative Layout Shift. Nécessite une clé API Chrome UX Report, à définir dans l’encadré Core Web Vitals de l’onglet Connexions de données de l’espace de travail. |
| Statut dans l’index Google | Pour les sites liés à Search Console, si chaque page surveillée est dans l’index de Google, d’après l’API URL Inspection. |
| Liens internes (chaque semaine) | Jusqu’à 40 liens vers votre propre site depuis les pages surveillées sont suivis, et ceux qui répondent 404, 410 ou une erreur serveur sont listés. |
Un site qui charge sa balise Google via un outil de consentement ou Tag Manager peut afficher « Google Tag Manager détecté » ou « Introuvable » alors que le suivi fonctionne. Consultez le rapport Temps réel de GA4 pour en être sûr.
Certificats SSL
Une fois par semaine, nos serveurs lisent le certificat servi par chaque site : sa date d’expiration et son émetteur. À moins de huit jours de l’expiration, ou tant que HTTPS est absent, ils vérifient chaque jour, afin qu’un renouvellement soit constaté avant que quiconque soit prévenu. Vous êtes prévenu une semaine avant l’expiration du certificat, de nouveau la veille, puis une fois qu’il a expiré. Il apparaît comme un problème sur la page du site à partir de 14 jours avant.
Elles vérifient aussi que les visiteurs obtiennent HTTPS : vous êtes prévenu lorsque le site ne répond qu’en HTTP simple, ou lorsque le HTTP simple sert le site sans rediriger vers HTTPS. Ces avertissements se répètent chaque semaine jusqu’à correction.
Enregistrement du domaine
Une fois par semaine, le domaine enregistré (example.com pour shop.example.com) est consulté auprès de son registre via RDAP, ou WHOIS lorsque le registre n’a pas de RDAP. À moins d’un mois de l’expiration, il est consulté chaque jour. Vous êtes prévenu un mois, une semaine et un jour avant l’expiration de l’enregistrement, puis une fois celui-ci expiré. Vous êtes aussi alerté immédiatement si le registre bloque le domaine, ce qui empêche le site et les e-mails de fonctionner, ou s’il a expiré et est sur le point d’être supprimé.
DNS et sécurité des e-mails
Une fois par jour, les enregistrements DNS du domaine sont consultés via DNS-over-HTTPS, afin que les résultats correspondent à ce que voit le reste d’Internet. Un changement de serveurs de noms ou de serveurs de messagerie déclenche immédiatement une alerte et reste affiché sur la page du site pendant une semaine, car c’est à cela que ressemblent un domaine détourné ou une migration ratée.
Pour les domaines qui reçoivent des e-mails, la vérification signale aussi un enregistrement SPF manquant, plusieurs enregistrements SPF, un enregistrement SPF qui autorise n’importe qui à envoyer (+all) et un enregistrement DMARC manquant. DKIM ne peut pas être listé : il est donc recherché chaque semaine parmi les sélecteurs courants des services de messagerie, et n’est affiché que s’il est trouvé.
Listes noires et malware
Une fois par jour, chaque site est recherché dans la liste Web Risk de Google, qui fait afficher aux visiteurs par Chrome et d’autres navigateurs une page d’avertissement rouge au lieu du site, et dans la liste URLhaus d’abuse.ch des téléchargements de malware. L’un ou l’autre signifie généralement que le site a été piraté, et vous êtes alerté immédiatement.
Cette vérification nécessite une clé d’API Google Web Risk, une clé d’authentification URLhaus, ou les deux, enregistrées dans sa boîte de dialogue. Sans l’une ni l’autre, elle ne s’exécute pas. L’API Safe Browsing gratuite de Google n’est pas autorisée pour un usage commercial, c’est pourquoi l’API payante Web Risk est utilisée.
En-têtes de sécurité et contenu mixte
Une fois par semaine, la page d’accueil est chargée en HTTPS et évaluée sur six en-têtes : Strict-Transport-Security (HSTS), Content-Security-Policy, X-Content-Type-Options, X-Frame-Options (ou frame-ancestors de CSP), Referrer-Policy et Permissions-Policy. Les six donnent un A, cinq un B, et ainsi de suite. Vous êtes prévenu lorsque HSTS est absent ou que moins de quatre en-têtes sont envoyés.
La page est aussi analysée pour y trouver des fichiers chargés en HTTP simple. Les scripts, styles et frames chargés ainsi sont bloqués par les navigateurs et peuvent casser la page ; les images et médias font perdre le cadenas. Seul le HTML tel que servi est vérifié, les fichiers ajoutés ensuite par des scripts ne sont donc pas vus.
Performance en laboratoire
Une fois par semaine, PageSpeed Insights de Google teste la page d’accueil mobile de chaque site sur un téléphone simulé et lui attribue un score sur 100, avec ses temps de chargement, de blocage et de décalage de mise en page. Les 12 derniers scores hebdomadaires sont conservés. Vous êtes prévenu lorsque le score est inférieur à 50, ou baisse de 15 points ou plus par rapport au test précédent, souvent avant que les Core Web Vitals des vrais visiteurs ne suivent. Il utilise la même clé d’API Google que les Core Web Vitals, avec l’API PageSpeed Insights activée pour son projet. Le test s’exécute depuis les serveurs de Google, pas depuis les nôtres.
Vérifications des pages clés
Ajoutez les pages les plus importantes, comme les tarifs, l’inscription ou le paiement, avec le texte que chacune doit contenir, et choisissez de les vérifier toutes les 5, 15 ou 60 minutes. Une page échoue lorsqu’elle ne se charge pas, répond par une erreur ou ne contient plus le texte, ce qui permet de repérer une page cassée qui répond pourtant « 200 OK ». Le texte est recherché dans la page telle que notre serveur la reçoit, avant l’exécution de tout script.
Après deux échecs d’affilée, les propriétaires et admins reçoivent un e-mail d’indisponibilité, les canaux de discussion sont prévenus et un problème critique est créé. Ils sont de nouveau informés lorsque la page refonctionne.
Heartbeats
Chaque heartbeat reçoit une adresse privée, comme https://saasmaestro.com/hooks/heartbeat/…. Faites-la appeler par l’une de vos tâches à chaque exécution, par exemple en ajoutant curl -fsS et l’adresse à la fin d’une ligne cron. Les requêtes GET, POST et HEAD comptent toutes.
Choisissez la fréquence attendue d’un ping, de toutes les 5 minutes à une fois par semaine, ainsi qu’un délai de grâce pour les tâches longues. Si aucun ping n’arrive dans l’intervalle plus le délai de grâce, les propriétaires et admins reçoivent un e-mail d’indisponibilité, les canaux de discussion sont prévenus et un problème critique est créé ; ils sont de nouveau informés quand le ping revient. Un heartbeat n’est pas surveillé tant que son premier ping n’est pas arrivé.
Pages surveillées et notes automatiques
SaaSMaestro surveille la page d’accueil et les cinq pages d’atterrissage les plus visitées. Quand le statut, le titre, la meta description, la directive robots ou l’adresse canonical d’une page change, ou que robots.txt change, une note de chronologie est ajoutée automatiquement et marquée « Détecté automatiquement ». De même quand une page sort de l’index de Google. Ainsi, une variation de trafic inattendue arrive souvent avec son explication déjà sur le graphique.
Où le voir
La zone de chaque service sous Connexions de données indique sa dernière exécution et le nombre de sites qui demandent de l’attention ; son icône d’horloge ouvre les résultats récents. La page de chaque site comporte une section Santé des sites avec les derniers résultats. Les anomalies apparaissent aussi dans les problèmes ; voir Vérifications et gravité des problèmes.