Site Monitoring est le plus récent modèle de projet intégré d'OpenTechnologyApp — un endroit pour enregistrer ce que fait un site public : quand il tombe en panne, combien de trafic il reçoit, et qui écrit via le formulaire de contact. Ce sont délibérément trois files, ce qui correspond exactement au plafond du niveau gratuit — c'est donc l'un des deux seuls modèles intégrés (avec IT Device Audit) que vous pouvez installer sans mise à niveau.
Ce qui est suivi
| File | Ce qui s'y trouve |
|---|---|
| Incidents | Pannes et dégradations — code de statut, durée d'indisponibilité, sévérité, pages concernées |
| Traffic Snapshots | Visites, visiteurs uniques, page la plus consultée et source de trafic pour une période (heure/jour/semaine/mois) |
| Form Submissions | Messages entrants du formulaire de contact, avec l'e-mail de l'expéditeur et une catégorie |
La partie honnête : ce qui est automatique et ce qui ne l'est pas
Ce n'est pas un service de surveillance — rien ici ne surveille votre site à votre place. C'est un endroit pour enregistrer des signaux, et aujourd'hui exactement une des trois files se remplit toute seule :
| File | Comment elle se remplit | Automatique ? |
|---|---|---|
| Form Submissions | Un webhook entrant depuis le formulaire de contact de votre site | Oui — c'est la seule connexion en direct, testée contractuellement |
| Traffic Snapshots | Vous exécutez ou planifiez une extraction depuis votre fournisseur d'analytique | Non — vous décidez de la cadence |
| Incidents | Vous, quand quelque chose casse réellement | Non, volontairement — aucun vérificateur de disponibilité n'est préinstallé |
Si vous connectez ceci spécifiquement au formulaire de contact d'OpenTechnologyBlog, le câblage existe déjà des deux côtés — voir SITE_MONITORING_CONNECTION.md pour la configuration d'environ 10 minutes. Bon à savoir avant de commencer : la notification par e-mail déjà en place sur le formulaire continue de fonctionner après connexion du webhook — vous obtenez un élément de file et un e-mail, pas l'un à la place de l'autre.
Tout le reste — chiffres de trafic, enregistrements d'incidents — est une saisie manuelle, à moins que vous ne construisiez votre propre intégration. Ce n'est pas une lacune à découvrir ; c'est le périmètre réel et annoncé du modèle : trois files où pointer des choses, pas une pile de surveillance.
Deux automatisations, trois playbooks
Les automatisations sont volontairement minimalistes : un incident de sévérité critique passe en priorité urgente, et un incident résolu se marque lui-même comme terminé. Pas de chaînes d'escalade, pas de règles de notification — celles-ci sont à construire vous-même une fois que vous vous en servez pour de vrai.
Trois playbooks sont fournis :
- Outage Response — confirmer depuis un second point de vue, enregistrer le code de statut et les pages concernées, identifier la couche défaillante (hôte, DNS, build, amont), appliquer ou escalader le correctif, enregistrer la durée totale d'indisponibilité
- Weekly Traffic Review — enregistrer les visites et la page la plus consultée pour la période, comparer avec la période précédente, noter tout changement important et sa cause probable
- Form Submission Triage — confirmer que ce n'est pas du spam, router par catégorie ou répondre directement, clôturer l'élément ou le convertir en travail suivi
Comment l'obtenir
Nouveau projet → Site Monitoring depuis le sélecteur de modèles sur opentechnologyapp.com — disponible sur tous les plans, y compris Free. Supprimez les cinq éléments d'exemple une fois orienté ; ils servent à montrer la forme de chaque file, et chacun porte example.test comme site pour être facilement repérable.