Une application SaaS est en panne quand le client ne peut plus faire le geste pour lequel il paie : se connecter, ouvrir son espace, enregistrer son travail. Une route interne qui répond 200 ne le garantit pas. Le monitoring utile rejoue ce parcours depuis l’extérieur, avec un compte prévu pour cela, et alerte quand le parcours casse.
Les routes machine se surveillent autrement, par des appels HTTP ciblés. Ce volet est décrit dans le monitoring d’une API. Les deux se complètent : l’API peut répondre pendant que la page de connexion renvoie une erreur, et la page peut s’afficher pendant qu’une route d’enregistrement échoue.
Ce qu’il faut voir échouer
Choisissez peu d’étapes, celles dont l’arrêt est une panne pour le client.
| Étape | Contrôle réaliste | Alerte si |
|---|---|---|
| Page de connexion | Requête sur l’URL, code 200, formulaire présent dans le HTML | 5xx, délai, ou formulaire absent |
| Après connexion | Page d’un compte de test | Redirection en boucle, 500, écran d’erreur |
| Action critique | Lecture d’une donnée de test, pas une écriture facturée | Contenu attendu absent |
| Dépendance externe | Fournisseur d’identité, paiement, e-mail | La fonction qui en dépend échoue |
La page de connexion est le minimum. Elle est publique, donc facile à contrôler sans secret. Vérifiez le code HTTP et la présence du formulaire. Une 200 qui affiche une page de maintenance, ou un fichier JavaScript manquant qui laisse un shell vide, n’est pas une connexion qui marche. Un mot stable du formulaire dans le HTML détecte une partie de ces cas. Il ne voit pas un script cassé qui empêche le clic : pour cela, il faut un contrôle qui exécute la page, ou un test de parcours lancé moins souvent.
Derrière l’authentification, utilisez un compte de test isolé. Pas le compte d’un client, pas un administrateur. Le mot de passe de la sonde est un secret d’exploitation, tournant, stocké comme les autres secrets, pas dans un canal d’équipe. Si le produit est multi-tenant, ce compte vit dans un tenant de test : les données qu’il lit ne sont pas celles d’un client, et un bug de la sonde ne modifie pas un dossier réel.
N’enregistrez pas une vraie facture, un vrai envoi d’e-mail ou une invitation client à chaque contrôle. Ces effets de bord transforment la surveillance en pollution. Une lecture d’un objet de test (« espace démo / projet témoin ») suffit pour savoir que l’application répond encore derrière la connexion.
Dépendances qui cassent le parcours sans casser la home
Le SaaS s’appuie souvent sur un fournisseur d’identité, un paiement, un e-mail transactionnel, un stockage de fichiers. La page marketing peut rester verte. Le bouton « Se connecter avec… » non. Incluez dans la surveillance le morceau que le client traverse : l’URL de connexion, et, si vous le pouvez sans effet de bord, le retour attendu.
Votre page de statut, celle que vous montrez aux clients, doit refléter ces contrôles. La recopier à la main le matin ne suffit pas le dimanche. Une page de statut qui reste verte pendant l’incident fait plus de tort que pas de page du tout. Inversez la dépendance : la sonde met à jour l’état, quelqu’un rédige le message si l’incident dure.
Les faux signaux sont plus fréquents sur un parcours authentifié que sur une home : jeton de test expiré, double authentification qui bloque la sonde, pare-feu qui refuse le centre de contrôle. Traitez-les comme des pannes de la sonde, tout de suite, sinon l’équipe cessera de croire le canal. Les réglages sont ceux des faux positifs.
Mettre la surveillance au niveau du produit
- Listez les trois gestes qu’un client ne peut pas perdre. Ignorez le blog et les pages marketing pour ce chantier-là : elles se surveillent comme un site, plus simplement.
- Créez le compte de test et la donnée de test. Documentez qui a le droit de faire tourner ce mot de passe.
- Contrôlez la page de connexion depuis l’extérieur, code et présence du formulaire. Le test d’URL sert à caler ce premier contrôle avant de le laisser tourner.
- Ajoutez le parcours authentifié seulement quand l’étape 3 est stable. Une sonde connectée qui échoue une fois sur deux n’apporte rien.
- Écrivez l’alerte avec l’étape en cause (« connexion » ou « espace démo »), pas un « SaaS down » qui oblige à tout retester.
Quand vous livrez une fonction nouvelle dont les clients dépendent, ajoutez une étape ou acceptez explicitement de ne pas la surveiller. Le health check historique, lui, ne se met pas à jour tout seul.