Surveillance de site web : tester les parcours qui comptent pour votre PME

Votre site affiche sa page d’accueil. Pourtant, le bouton de prise de rendez-vous reste bloqué ou le catalogue ne renvoie aucun résultat. Une surveillance limitée à « la page répond » peut laisser passer ces incidents.

Pour une PME, le bon point de départ consiste à choisir quelques actions importantes, définir leur résultat attendu et désigner la personne qui interviendra. Voici une méthode de cadrage à discuter avec votre prestataire. Les situations proposées sont fictives et doivent être adaptées à votre activité.

1. Choisir les parcours à surveiller

Listez d’abord ce qu’un visiteur doit pouvoir accomplir : consulter une offre, rechercher une référence, ouvrir un document public ou commencer une réservation. Classez ces parcours selon l’effet d’un blocage sur votre activité.

Pour démarrer, nous proposons de retenir deux ou trois parcours clairement décrits. Par exemple : « Depuis la page Services, accéder à la demande de rendez-vous et afficher les créneaux disponibles. » Cette formulation permet de vérifier une suite d’étapes, plutôt qu’une URL isolée.

Écrivez aussi la limite du test. Va-t-il seulement ouvrir le calendrier ou réserver un créneau ? Une réservation automatique peut immobiliser une disponibilité réelle. Cette différence doit être décidée avant toute programmation.

2. Vérifier la réponse technique et le contenu attendu

Un contrôle de disponibilité envoie régulièrement une requête vers une adresse et examine la réponse. Google Cloud documente notamment des vérifications HTTP, HTTPS et TCP, ainsi que des tests plus élaborés exécutant une suite d’étapes. Source : présentation de la surveillance synthétique Google Cloud.

Demandez un critère de succès explicite : code HTTP attendu, contenu caractéristique et délai maximal adapté au service. Recevoir un code 200 ne suffit pas si la réponse contient une page d’erreur présentée comme normale. Le livre Google SRE décrit précisément ce cas d’échec avec un statut apparemment réussi. Source : Monitoring Distributed Systems.

Attention au périmètre de l’outil : les contrôles de disponibilité Google Cloud ne chargent pas les ressources de la page et n’exécutent pas son JavaScript. Leur résultat ne prouve donc pas qu’un calendrier interactif fonctionne dans un navigateur. Source : création de contrôles publics Google Cloud.

3. Ajouter un test de parcours dans un navigateur

Pour un parcours interactif, prévoyez un scénario reproduisant les actions utiles : ouvrir la page, choisir un service, afficher le calendrier, puis vérifier qu’un résultat compréhensible apparaît. Adaptez la vérification aux situations normales, notamment lorsqu’aucun créneau n’est disponible.

Playwright recommande de tester le comportement visible par l’utilisateur et d’isoler les tests pour éviter qu’ils dépendent des sessions ou des données laissées par les précédents. Ses recommandations privilégient aussi les repères proches de l’interface, comme le rôle ou le libellé d’un bouton. Source : bonnes pratiques Playwright.

Demandez une preuve en cas d’échec : étape concernée, heure et capture utile. Limitez les informations enregistrées. Le rapport doit permettre de comprendre « le calendrier ne s’ouvre plus » sans diffuser le contenu d’un vrai dossier client.

Gardez un scénario court. Un test qui traverse dix fonctions sans rapport devient plus difficile à interpréter et à maintenir.

4. Encadrer les effets des tests

Un test automatique peut créer une demande, envoyer un email ou déclencher une relance. Avant de surveiller un parcours complet, faites l’inventaire de ces conséquences avec les personnes qui exploitent les outils concernés.

Notre recommandation : valider d’abord le scénario dans un environnement de test, avec des données fictives. Pour la production, prévoir un compte dédié aux droits limités, des destinataires de test et une identification claire des enregistrements générés. Définir leur nettoyage sans risquer de supprimer de vraies demandes.

Si ces protections ne sont pas disponibles, surveillez les étapes sans effet externe et organisez une vérification complète encadrée. Indiquez alors la limite dans le suivi : l’ouverture du formulaire ne confirme pas l’enregistrement de la demande.

Un paiement, une signature ou une réservation réelle demandent un dispositif spécifique. N’ajoutez pas ces actions à un scénario récurrent simplement pour obtenir un indicateur vert.

5. Préparer une alerte qui aide à agir

Chaque contrôle doit avoir un responsable, un remplaçant et une consigne de première intervention. Vérifiez que les notifications arrivent sur un canal effectivement suivi, y compris lorsque le site ou sa messagerie rencontre un problème.

Le livre Google SRE insiste sur des alertes simples, compréhensibles et peu bruyantes. Des notifications trop fréquentes peuvent masquer les incidents importants. Source : principes de surveillance Google SRE.

Définissez avec le prestataire quand prévenir : dès un échec confirmé, après plusieurs observations concordantes ou lorsqu’un délai métier est dépassé. Le choix dépend du parcours ; attendre plusieurs contrôles augmente aussi le délai de détection.

Exemple de message à adapter : « Prise de rendez-vous : calendrier inaccessible depuis 09 h 12. Échec à l’étape d’affichage. Responsable : support web. Consigne : vérifier le parcours puis consulter les erreurs de l’application. » Cet exemple illustre le contenu attendu, sans décrire un incident réel.

6. Tester la surveillance elle-même

Avant de considérer le dispositif opérationnel, simulez un échec dans un cadre isolé. Vérifiez que le contrôle échoue, que l’alerte arrive et qu’une personne sait quoi faire. Répétez ensuite le scénario avec le service rétabli.

Ajoutez une vérification de la dernière exécution : un contrôle qui ne tourne plus ne doit pas conserver indéfiniment un ancien résultat rassurant. Documentez les horaires de maintenance et les pauses prévues, avec une date de reprise.

Après une modification du site, relisez le scénario. Un libellé changé peut nécessiter d’adapter le test ; un bouton réellement cassé demande une correction du site. Ne désactivez pas automatiquement un contrôle parce qu’il devient gênant.

Le livrable à demander à votre prestataire

Avant la mise en service, demandez une fiche contenant :

• les parcours couverts et les étapes exclues ;
• le résultat attendu et la fréquence de chaque contrôle ;
• les données et les comptes utilisés ;
• les effets possibles des tests et leurs protections ;
• les destinataires des alertes et la procédure d’intervention ;
• la preuve d’un échec détecté, puis d’un retour au fonctionnement normal.

Cette fiche permet d’évaluer concrètement la couverture obtenue. Aucun scénario ne représente tous les visiteurs, navigateurs ou incidents possibles : complétez-le avec les retours du support et les journaux techniques utiles.

Vous souhaitez cadrer la surveillance de votre site ? Décrivez votre parcours prioritaire à KADRI AI, avec les outils concernés et les étapes dont votre équipe dépend.

Sources officielles

• Google Cloud : présentation de la surveillance synthétique
• Google Cloud : création de contrôles de disponibilité publics
• Playwright : bonnes pratiques de test
• Google SRE : Monitoring Distributed Systems

Sources consultées le 12 octobre 2026. Les recommandations de méthode sont celles de KADRI AI ; les fonctionnalités citées restent à vérifier dans les outils et versions retenus.