Ne surveillez pas seulement la page d’accueil. Une configuration complète couvre la page d’accueil, chaque parcours de conversion (connexion, inscription, paiement et recherche), les endpoints d’API dont dépendent vos applications, les callbacks de paiement et les webhooks, les tâches planifiées, les certificats SSL, l’enregistrement des domaines, les enregistrements DNS dont le MX, les serveurs sous-jacents et les services tiers sur lesquels vous vous appuyez. Le site d’une petite entreprise a besoin d’une poignée de vérifications ; une boutique ou un produit SaaS, de quelques dizaines. Commencez par ce qui rapporte de l’argent, puis ajoutez ce qui peut expirer ou tomber en panne sans bruit. Pour une vue d’ensemble, lisez comment une surveillance de disponibilité fiable aide votre site à performer.
Cette checklist passe en revue chaque élément, explique quoi vérifier et pourquoi, et se termine par des exemples de configuration pour un petit site, une boutique en ligne, un produit SaaS et une agence, ainsi qu’une convention de nommage qui garde l’ensemble lisible.
1. La page d’accueil
La page d’accueil est le premier moniteur qui vient à l’esprit, et c’est un bon choix : si elle est hors ligne, tout l’est. Mais elle est souvent servie par un CDN ou un cache de pages, et peut donc rester en ligne alors que l’application derrière elle est en panne. Surveillez-la avec une vérification HTTP(S) toutes les minutes et validez un contenu stable, comme le nom de l’entreprise dans le pied de page, pour qu’une page d’erreur en cache ne soit pas comptée comme en ligne. Passez ensuite aux pages qui vous en disent plus.
2. Les parcours de conversion
Ce sont les pages qui rapportent de l’argent ou fidélisent les clients, et elles dépendent de la base de données, des sessions et du code applicatif que la page d’accueil peut contourner :
Connexion : prouve que les sessions et la base des utilisateurs fonctionnent. Surveillez la page de connexion et vérifiez que le formulaire est bien présent.
Inscription ou création de compte : le point de départ de chaque nouveau client.
Panier et paiement : pour une boutique, les pages les plus importantes du site. Surveillez la page de paiement elle-même, pas seulement les fiches produits.
Recherche : souvent assurée par un service distinct, elle peut donc tomber seule. Surveillez une URL de résultats de recherche avec une requête qui renvoie toujours des résultats, et vérifiez qu’un résultat s’affiche.
Formulaires de réservation ou de contact, si c’est par là qu’arrivent vos prospects.
Vérifiez-les toutes les minutes. Pour la plupart des entreprises, un paiement en panne coûte plus cher à la minute que tout le reste de cette liste. La surveillance de disponibilité d’Uptimecheck prend en charge les méthodes et en-têtes personnalisés, et valide le code de statut, les mots-clés et le JSON de chaque page. Pour vérifier que la connexion ou le paiement fonctionne vraiment, et pas seulement qu’il se charge, un moniteur de parcours le parcourt étape par étape, éventuellement dans un vrai navigateur, avec des valeurs transmises d’une étape à l’autre et des secrets chiffrés.
3. Les endpoints d’API
Si vous avez une application mobile, un frontend monopage ou des intégrations partenaires, l’API est le produit. Surveillez :
Un endpoint de santé qui vérifie la base de données, le cache et le disque. Voir comment créer un endpoint de health check.
Le principal endpoint de lecture, avec l’en-tête de clé d’API qu’envoient vos clients.
Un endpoint d’écriture, avec une charge utile de test sans risque, si les écritures sont critiques.
Validez le corps de la réponse, pas seulement le code de statut : une API qui renvoie 200 avec un message d’erreur est quand même en panne. La surveillance d’API et la checklist de surveillance d’API vont plus loin.
4. Callbacks de paiement et webhooks
Les prestataires de paiement, les services de livraison et d’autres plateformes rappellent votre site pour confirmer les commandes et mettre à jour leur statut. Si l’endpoint de réception tombe en panne, les paiements peuvent aboutir sans que les commandes soient jamais marquées comme payées. Personne ne voit de page d’erreur, car aucun visiteur n’est impliqué.
En général, un moniteur ne peut pas envoyer de vrai callback, mais il peut vérifier que l’endpoint répond. Beaucoup de récepteurs de webhooks renvoient un code 4xx à une requête sans signature valide ; si c’est la réponse attendue, surveillez-la. Un 5xx ou un timeout signifie alors que le récepteur lui-même est en panne. Complétez avec les journaux de livraison du prestataire, qui montrent les callbacks échoués de son côté.
5. Tâches cron et traitements en arrière-plan
Les sauvegardes, imports, facturations, exports de flux, envois de newsletters et workers de files d’attente n’ont pas d’URL à vérifier. Ils échouent sans bruit. Donnez à chacun un heartbeat : la tâche appelle une URL unique quand elle se termine, et une alerte part si l’appel n’arrive pas à temps. Les offres Uptimecheck comptent les heartbeats séparément des moniteurs, ils n’empiètent donc pas sur vos vérifications de sites.
6. Certificats SSL
Un certificat expiré affiche à chaque visiteur un avertissement du navigateur en pleine page et bloque purement et simplement les clients d’API. Surveillez le certificat de chaque nom d’hôte que vous servez, y compris www, le sous-domaine de l’API, le domaine de la page de statut et les interfaces d’administration, et recevez des rappels plusieurs semaines avant l’expiration. Le renouvellement automatique rend l’expiration plus rare, pas impossible. Consultez la surveillance de l’expiration des certificats SSL pour les pannes les plus courantes.
7. Enregistrement des domaines
Quand l’enregistrement d’un domaine expire, le site, les e-mails et l’API qui en dépendent s’arrêtent tous en même temps. Les rappels du registrar partent souvent vers une ancienne adresse. Suivez la date d’expiration de chaque domaine que vous possédez, y compris les variantes par pays, les domaines de campagne et les anciens noms de marque qui redirigent encore.
8. Enregistrements DNS, dont le MX
Le DNS décide où vont le trafic et les e-mails. Surveillez les modifications de :
A et AAAA : d’où le site est chargé.
NS : qui contrôle la zone. Un changement ici mérite toujours un coup d’œil.
MX : qui reçoit vos e-mails, y compris les confirmations de commande et les réinitialisations de mot de passe.
TXT : SPF, DKIM et DMARC. Un enregistrement supprimé peut envoyer vos e-mails directement en spam. Le moniteur de domaine d’Uptimecheck vérifie aussi SPF, DKIM et DMARC deux fois par jour et indique comment corriger chaque problème, avec un enregistrement DNS prêt à coller quand il suffit à le résoudre ; voir la surveillance de l’authentification des e-mails.
CNAME et CAA : les alias de CDN et les autorités de certification autorisées à émettre des certificats pour le domaine.
Un changement inattendu est soit une erreur, soit une attaque. La surveillance DNS vous alerte avec l’ancienne et la nouvelle valeur. Si vous gérez votre propre serveur de messagerie, ajoutez aussi une vérification de port, par exemple SMTP sur le port 465.
9. Serveurs
Si vous gérez vos propres serveurs ou VPS, surveillez le CPU, la mémoire, le disque, le réseau et les redémarrages. Vous repérez ainsi les causes des pannes avant qu’elles ne deviennent des symptômes : un disque qui sera plein jeudi, une fuite de mémoire, un redémarrage après lequel un service ne s’est pas relancé. La surveillance des serveurs se trouve à côté de vos vérifications de disponibilité : la cause et le symptôme apparaissent sur le même écran. Avec un hébergement entièrement infogéré, vous pouvez souvent vous en passer et vous reposer sur l’hébergeur.
10. Dépendances tierces
Votre site dépend de services que vous ne gérez pas : prestataires de paiement, envoi d’e-mails, recherche, CMS headless, fournisseur d’authentification, CDN. Quand l’un d’eux tombe, votre site peut se charger alors que la fonctionnalité qui en dépend est cassée. Surveillez les endpoints publics sur lesquels vous vous appuyez, ou vos propres endpoints qui les sollicitent, pour pouvoir dire à un client en quelques minutes si le problème vient de chez vous ou d’en amont. Envoyez ces alertes sur un canal de moindre priorité, puisque vous ne pouvez pas les corriger vous-même.
La surveillance des services tiers d’Uptimecheck suit les pages de statut de 31 services comme Klarna, Swish, Shopify, Cloudflare et OpenAI, ou de toute page hébergée sur Statuspage, pour que leurs incidents s’affichent à côté de vos propres moniteurs.
11. Santé du site
Certains problèmes ne mettent jamais une page hors ligne : un lien cassé après une migration, une image chargée en HTTP simple, une page devenue plus lente après l’ajout d’un plugin. Une analyse quotidienne les repère. Le moniteur de santé du site d’Uptimecheck explore chaque jour votre site et son sitemap à la recherche de liens cassés et de contenu mixte, et mesure la vitesse des pages et les Core Web Vitals avec Google Lighthouse sur mobile et sur ordinateur.
Combien de moniteurs vous faut-il ?
Les configurations ci-dessous sont des exemples à adapter, pas des recettes figées :
Type de siteExemple de configurationSite de petite entreprise, comme fjordstudio.sePage d’accueil, page du formulaire de contact, SSL, domaine, DNS pour A et MX, un heartbeat pour la sauvegarde. Environ 3 moniteurs HTTP, plus les vérifications d’expiration et DNS.Boutique en ligne, comme northwind.shopPage d’accueil, une page catégorie, une fiche produit, panier, paiement, connexion, recherche, callback de paiement, endpoint de santé, SSL sur chaque nom d’hôte, domaine, DNS, heartbeats pour les sauvegardes, les exports de flux et les synchronisations de commandes, et les serveurs. Environ 10 à 15 moniteurs HTTP.Produit SaaS, comme lumenanalytics.ioSite marketing, connexion à l’application, inscription, santé de l’API, principaux endpoints de l’API, récepteur de webhooks, page de statut, SSL, domaines, DNS, heartbeats pour chaque worker et chaque tâche planifiée, et serveurs. Souvent 15 à 40 moniteurs.AgenceL’ensemble du petit site pour chaque client, plus le paiement et la connexion pour les boutiques clientes, regroupés par client. En général quelques moniteurs par client, multipliés par le nombre de clients.
Commencez par les parcours de conversion et les vérifications d’expiration, laissez tourner deux semaines, puis ajoutez ce qui vous a manqué lors du premier incident.
Conventions de nommage
Le nom d’un moniteur est la première chose qu’on lit dans une alerte en pleine nuit. Il doit répondre à « qu’est-ce qui est cassé, où, et à quel point » sans rien ouvrir :
[client or product] – [environment] – [what] – [check type]
Northwind – prod – Checkout – HTTPS
Northwind – prod – Payment callback – HTTPS
Northwind – prod – Nightly backup – heartbeat
Lumen – prod – API health – HTTPS
Lumen – staging – API health – HTTPS
Fjord Studio – prod – MX record – DNS
Utilisez le même ordre partout, pour que les alertes se parcourent et se trient facilement.
Nommez les choses comme l’équipe en parle, pas d’après les noms d’hôte internes.
Indiquez clairement les environnements, pour qu’une alerte de staging ne ressemble jamais à la production.
Pour les agences, commencez par le nom du client et regroupez les moniteurs par client dans des projets, pour que les moniteurs et les alertes de chaque client restent ensemble.
La checklist
Page d’accueil, avec validation du contenu.
Connexion, inscription, paiement et recherche.
Santé de l’API et principaux endpoints.
Callbacks de paiement et récepteurs de webhooks.
Un heartbeat pour chaque tâche planifiée qui compte.
Le SSL de chaque nom d’hôte et l’enregistrement de chaque domaine.
Enregistrements DNS : au minimum A, AAAA, NS, MX et TXT.
Les serveurs, si vous gérez les vôtres.
Les principaux services tiers, sur un canal de moindre priorité.
Santé du site : liens cassés, contenu mixte et vitesse des pages, analysés chaque jour.
Des noms clairs, et des alertes envoyées au responsable de chaque élément.
Uptimecheck couvre les sites web, les API, les parcours en plusieurs étapes, les heartbeats, le SSL, les domaines, le DNS, les serveurs, les services tiers et la santé du site dans un seul compte. Commencez un essai gratuit de 14 jours, sans carte bancaire.