Comment j’ai créé un workflow n8n pour automatiser la surveillance de sites web

Quand on parle de maintenance de site web, beaucoup de personnes pensent d’abord aux mises à jour, aux sauvegardes ou à la sécurité. C’est évidemment indispensable. Mais, dans la réalité, cela ne suffit pas toujours à garantir un service de qualité. Un site peut être parfaitement à jour, correctement sauvegardé et malgré tout devenir inaccessible à cause d’un incident serveur, d’un problème DNS, d’un certificat SSL défaillant ou d’un simple timeout réseau.

C’est précisément pour cette raison que j’ai créé mon dernier workflow n8n : mettre en place un monitoring de sites web automatisé qui complète mes offres de maintenance WordPress avec une brique de supervision simple, fiable et directement exploitable. Mon besoin de départ est né dans un contexte WordPress, mais le fonctionnement du workflow ne dépend pas du CMS. Tant qu’un site répond sur une URL, il peut être surveillé de la même manière.

L’idée n’était pas de construire une usine à gaz ni de reproduire une plateforme de monitoring complète. Mon objectif était plus pragmatique : détecter rapidement les vraies indisponibilités, éviter les alertes inutiles, prévenir les bonnes personnes et garder une mémoire d’état d’une exécution à l’autre. En d’autres termes, je voulais une solution assez légère pour rester maintenable, mais suffisamment robuste pour renforcer une prestation de maintenance proactive.

TL;DR

J’ai conçu un workflow n8n qui surveille automatiquement une liste de sites web à intervalles réguliers. Il effectue un premier contrôle HTTP, puis lance une seconde vérification quelques secondes plus tard en cas d’échec afin de limiter les faux positifs. Ensuite, il compare le résultat avec l’état précédent mémorisé dans une Data Table n8n. En fonction du changement détecté, il envoie une alerte email au contact du site, une notification Telegram à l’administrateur et un rapport récapitulatif global. Je l’ai d’abord pensé pour renforcer mes offres de maintenance WordPress, mais il fonctionne avec n’importe quel site web, quelle que soit sa technologie.

1. Pourquoi j’ai créé ce workflow dans le cadre de ma maintenance WordPress

1.1. Aller au-delà des mises à jour et des sauvegardes

Dans une offre de maintenance WordPress, les mises à jour du cœur, des extensions, du thème ou les sauvegardes planifiées sont les briques les plus visibles. Pourtant, du point de vue du client, la vraie question est souvent beaucoup plus simple : est-ce que mon site est accessible quand un visiteur veut l’ouvrir ?

C’est là que la logique de maintenance proactive prend tout son sens. Une maintenance sérieuse ne consiste pas seulement à intervenir quand on vous signale un problème. Elle doit aussi permettre de détecter rapidement un incident avant même qu’il ne remonte par email, par téléphone ou par une baisse brutale de conversions.

En pratique, j’avais besoin d’un mécanisme qui me permette de vérifier automatiquement la disponibilité d’un site sans dépendre d’une surveillance manuelle. C’est ce besoin très concret qui m’a poussé à créer ce workflow.

1.2. Détecter plus vite les incidents qui comptent vraiment

Un site WordPress peut devenir indisponible pour des raisons très différentes. Parfois, le problème vient du serveur web. Dans d’autres cas, il peut s’agir d’une erreur DNS, d’un certificat SSL mal renouvelé, d’une surcharge passagère, d’une mauvaise configuration, voire d’un incident externe totalement indépendant de WordPress lui-même.

Autrement dit, se limiter à la couche applicative n’est pas suffisant. Il fallait une supervision de sites web capable de signaler qu’un site ne répond plus correctement, quelle qu’en soit la cause immédiate. L’objectif n’était pas de diagnostiquer tout l’incident dans le workflow, mais au moins de détecter vite qu’il existe vraiment.

1.3. Un workflow pensé pour WordPress, mais utile à tout site web

Même si mon besoin initial est lié à mes prestations WordPress, j’ai volontairement conçu ce système pour qu’il reste agnostique sur le plan technique. Le workflow ne demande pas si le site tourne sous WordPress, Laravel, Shopify, Symfony, Next.js ou toute autre technologie. Il réalise simplement un contrôle HTTP sur l’URL à surveiller et interprète la réponse.

C’est un point important, car cela évite de l’enfermer dans un seul usage. Aujourd’hui, il renforce naturellement une offre de maintenance WordPress. Mais il peut tout aussi bien servir à surveiller un site vitrine, un site e-commerce, un extranet, une landing page ou un service web plus spécifique.

2. Ce que ce workflow n8n fait concrètement

2.1. Vérifier automatiquement une liste de sites

Le cœur du système repose sur une Data Table n8n dans laquelle je stocke la liste des sites à monitorer. Chaque ligne contient les informations utiles :

• Le nom du site.
• Son URL.
• Le contact associé.
• Son email.
• Et plusieurs champs qui servent à mémoriser le dernier état connu.

Ce choix a deux avantages. D’abord, il centralise les données au même endroit que l’automatisation. Ensuite, il rend le workflow très simple à étendre : pour ajouter un nouveau site, il suffit de créer une nouvelle ligne dans la table, sans modifier toute la logique.

On est donc sur un workflow de monitoring réellement multi-sites, avec une gestion assez souple pour un contexte de maintenance ou de suivi de portefeuille client.

2.2. Détecter uniquement les vrais changements d’état

Ce que je trouve le plus intéressant dans ce workflow, ce n’est pas seulement qu’il teste si un site répond. C’est surtout qu’il compare l’état actuel avec l’état précédent. Cette nuance change beaucoup de choses.

Un site indisponible depuis déjà une heure ne doit pas forcément déclencher une nouvelle alerte à chaque exécution. En revanche, un site qui passe de disponible à indisponible mérite d’être signalé immédiatement. De la même manière, un site qui redevient accessible doit être identifié comme un retour à la normale.

Le workflow raisonne donc en termes de détection de changement d’état. Il classe les événements en trois catégories simples :

• Pas de changement ;
• Passage de up vers down ;
• Passage de down vers up.

C’est cette logique qui rend les notifications beaucoup plus pertinentes.

2.3. Prévenir les bonnes personnes au bon moment

J’ai aussi séparé les notifications selon leur utilité.

Quand un site devient nouvellement indisponible, le workflow peut envoyer un email au contact associé au site concerné. En parallèle, une notification Telegram est transmise à l’administrateur pour permettre une réaction rapide côté exploitation.

Ensuite, lorsqu’il y a eu au moins un changement d’état durant l’exécution, un email de synthèse centralisé est généré. Cela permet de garder un suivi d’incidents global sans être noyé sous des dizaines de messages isolés.

Enfin, en cas de reprise de service, un email de rétablissement est envoyé au contact. J’ai opté pour cette logique car elle ferme proprement la boucle côté communication.

3. L’architecture générale du workflow

3.1. Déclenchement planifié et configuration centralisée

Le workflow démarre sur un déclencheur planifié. Dans sa configuration actuelle, il s’exécute toutes les cinq minutes. Ce rythme me semble être un bon compromis entre réactivité et charge raisonnable, notamment pour une surveillance multi-sites standard.

J’ai aussi prévu un nœud de configuration centralisé qui regroupe des constantes comme le chat_id Telegram ou le délai maximal d’attente des requêtes HTTP. Ce détail peut paraître mineur, mais il améliore beaucoup la lisibilité et la maintenance. On évite de disperser des paramètres critiques à plusieurs endroits dans le canvas.

3.2. Lecture des sites et première vérification HTTP

Après l’initialisation, le workflow lit toutes les entrées de la Data Table. Il travaille ensuite site par site pour lancer une première requête HTTP. Cette étape constitue la base de la surveillance automatisée.

Je demande une réponse complète et je fais en sorte que le nœud HTTP ne casse pas toute l’exécution en cas d’erreur. C’est essentiel, car un incident réseau sur un site ne doit pas empêcher la surveillance des autres.

Le résultat brut est ensuite normalisé dans un objet de travail plus propre. On y retrouve à la fois les données métier du site et les informations techniques issues de la vérification, comme le statut détecté ou un éventuel message d’erreur.

3.3. Seconde tentative, décision, notifications et mise à jour

Si le premier test renvoie un code HTTP 2xx, le workflow considère immédiatement que le site est disponible. En revanche, si le résultat sort de cette plage ou si aucune réponse exploitable n’est obtenue, il attend quelques secondes avant de relancer exactement le même test.

Une fois l’état final déterminé, le workflow passe dans sa partie décisionnelle. Il compare le statut courant avec le dernier statut mémorisé, décide s’il s’agit d’un événement significatif, prépare les contenus des notifications, met à jour la Data Table, puis envoie les messages nécessaires.

J’apprécie particulièrement cette séparation entre collecte, décision, notification et persistance. Elle rend l’ensemble beaucoup plus facile à comprendre et à faire évoluer.

4. Le point clé : limiter les faux positifs avec une double vérification

4.1. Pourquoi un simple échec HTTP ne suffit pas toujours

Dans un système de supervision technique, l’un des pièges les plus fréquents consiste à considérer qu’un premier échec équivaut automatiquement à une panne réelle. En pratique, ce n’est pas toujours vrai.

Il peut s’agir d’une micro-coupure réseau, d’un timeout isolé, d’une latence momentanée, d’un problème passager côté hébergeur ou d’un incident intermédiaire très bref. Si l’on déclenche une alerte dès le premier échec, on augmente fortement le bruit opérationnel.

Et plus il y a de bruit, moins les alertes sont prises au sérieux. Pour moi, c’était justement une erreur à éviter.

4.2. L’intérêt d’attendre quelques secondes avant de retester

C’est pour cela que j’ai intégré une double vérification. Lorsqu’un site échoue au premier contrôle, le workflow attend cinq secondes puis refait le test. Ce n’est pas une mécanique complexe, mais elle change énormément la qualité des résultats.

Si le second test réussit, l’incident est considéré comme transitoire. Il n’y a pas de changement d’état retenu et donc pas d’alerte inutile. Si le second test échoue lui aussi, l’indisponibilité devient beaucoup plus crédible et peut alors être traitée comme un vrai événement.

En d’autres termes, je préfère une alerte légèrement confirmée à une avalanche de messages parasites.

4.3. Ce que cette logique change dans la qualité des alertes

Cette approche améliore la fiabilité perçue du système. Quand une alerte sort, il y a déjà eu une petite phase de validation. Cela renforce la confiance dans le workflow et réduit la fatigue liée aux notifications.

Dans le cadre d’une maintenance WordPress ou d’une prestation de suivi, c’est très utile. Vous montrez que votre dispositif de surveillance ne se contente pas de réagir de façon binaire, mais qu’il cherche à distinguer un vrai incident d’un simple aléa réseau.

5. Comment le workflow décide qu’un site est down, up ou inchangé

5.1. Les codes HTTP interprétés simplement

J’ai volontairement gardé une logique lisible. Lorsqu’un site renvoie un code HTTP 2xx, il est considéré comme disponible. Lorsqu’il renvoie un code 4xx ou 5xx, il est considéré comme indisponible. Et lorsqu’aucune réponse HTTP exploitable n’est obtenue, le workflow utilise un statut technique 0 pour représenter ce cas.

Ce 0 n’est évidemment pas un vrai code de statut HTTP. C’est une valeur de substitution utile pour traiter de manière homogène un échec DNS, un timeout, une erreur SSL ou une connexion impossible.

J’ai adopté cette approche car elle permet de conserver une logique métier très claire sans devoir multiplier les cas particuliers dans tout le workflow.

En savoir plus : Les codes de réponse HTTP

5.2. La mémoire d’état stockée dans la Data Table

Pour savoir si un changement a eu lieu, il faut une mémoire. C’est le rôle des champs persistés dans la Data Table, notamment last_status_code, error_date_start et error_date_end.

• last_status_code sert de référence pour l’exécution suivante.
• error_date_start permet de mémoriser la date de début d’incident lorsque le site bascule vers l’état indisponible.
• error_date_end enregistre le moment du rétablissement quand le site redevient accessible.

Même si cette structure reste volontairement légère, elle suffit déjà à donner du contexte, à alimenter les messages et à améliorer le tableau de suivi global.

5.3. Pourquoi je ne notifie pas à chaque exécution

C’est sans doute l’un des points les plus importants à comprendre. Le workflow ne notifie pas parce qu’un site est down à l’instant T. Il notifie parce qu’il détecte une transition pertinente.

Un site qui était déjà indisponible et qui l’est encore ne génère pas une nouvelle alerte de panne à chaque passage. De la même façon, un site déjà disponible et toujours accessible ne produit pas de bruit inutile.

Ce principe paraît simple, mais il change totalement la qualité opérationnelle du système. On passe d’un monitoring bavard à un monitoring utile.

6. Ce que ce monitoring apporte concrètement dans une prestation de maintenance

6.1. Une maintenance WordPress plus proactive

Pour moi, la vraie valeur de ce workflow ne se mesure pas seulement à la technique déployée. Elle se mesure surtout à ce qu’il permet côté service.

En ajoutant cette couche de monitoring de sites web automatisé à une offre de maintenance WordPress, je renforce la réactivité face aux incidents. Je ne me contente plus d’assurer les mises à jour et la stabilité logicielle ; je mets aussi en place une forme de veille active sur la disponibilité du site.

C’est particulièrement pertinent pour des clients qui attendent de la fiabilité, sans forcément vouloir investir dans une stack de supervision lourde ou coûteuse.

6.2. Une meilleure réactivité sans complexifier inutilement la stack

Ce que j’aime avec n8n, c’est qu’on peut construire des automatisations très utiles sans sortir immédiatement l’artillerie lourde. Ici, j’utilise des briques simples : une planification, des requêtes HTTP, une Data Table, un peu de logique conditionnelle, quelques notifications.

Le résultat reste lisible, modulaire et compréhensible. Pour une activité freelance, cette simplicité a une vraie valeur. Elle facilite la maintenance du workflow lui-même, son adaptation future et sa reprise éventuelle par une autre personne.

6.3. Une base solide pour industrialiser le suivi de plusieurs sites

Autre avantage : la logique se prête bien à la surveillance multi-sites. Dès lors que la Data Table est bien structurée, il devient facile d’ajouter de nouveaux sites et de conserver un fonctionnement homogène.

C’est exactement le type de fondation que je recherche pour professionnaliser un suivi de parc web : une structure assez légère pour rester souple, mais assez sérieuse pour être intégrée à une offre réelle.

À ce titre, cet article fait aussi écho à mes prestations autour de la maintenance WordPress et de l’automatisation de tâches avec n8n.

7. Les limites actuelles de mon workflow

7.1. Ce qu’il ne fait pas encore

Je préfère être clair : ce workflow n’a pas vocation à couvrir toute la profondeur d’une plateforme d’uptime monitoring avancée. Il ne mesure pas encore précisément les temps de réponse, ne gère pas des seuils complexes après plusieurs échecs consécutifs, n’intègre pas de dashboard dédié et ne propose pas de logique d’escalade multi-niveaux.

Il ne différencie pas non plus, à ce stade, les sites selon leur criticité, leurs plages horaires ou leurs engagements de SLA (Service-level agreement). Enfin, il ne stocke pas un historique détaillé d’incidents dans une base dédiée.

7.2. Pourquoi ce choix est volontaire

Ces limites ne sont pas un oubli. Elles relèvent d’un choix de conception. Je voulais d’abord une base fiable, compréhensible et immédiatement utile.

Il est souvent tentant d’ajouter beaucoup de fonctionnalités dès la première version. Mais cela conduit parfois à un système plus difficile à maintenir qu’à exploiter. Ici, j’ai préféré privilégier la robustesse sur le périmètre essentiel : vérifier, confirmer, comparer, notifier, mémoriser.

Pour un usage concret en maintenance, cette sobriété est souvent une force.

8. Les évolutions que j’envisage

8.1. Historisation plus poussée et tableaux de bord

La première piste d’évolution concerne l’historisation. Aujourd’hui, la Data Table stocke une mémoire d’état minimale, ce qui suffit pour la détection des transitions. Mais on peut aller plus loin avec une table dédiée aux incidents, une base SQL, Airtable ou même Google Sheets selon le contexte.

À partir de là, il devient possible de calculer des durées d’indisponibilité, de suivre des fréquences d’incidents et d’alimenter un véritable tableau de bord.

8.2. Règles d’alerte plus avancées

Une autre évolution intéressante serait d’introduire un compteur d’échecs consécutifs avant alerte, ou une gestion plus fine selon la criticité du site. On pourrait aussi ajouter d’autres canaux comme Slack, Discord ou des webhooks vers des outils tiers.

De la même manière, je pourrais envoyer un message Telegram non seulement lors d’une nouvelle panne, mais aussi lors du retour à la normale afin d’obtenir une boucle de supervision encore plus complète.

8.3. Intégration encore plus forte dans mes offres de maintenance

Enfin, je vois très bien comment ce workflow peut continuer à enrichir mes offres. Il apporte une dimension très concrète à la promesse de maintenance proactive. Il ne remplace pas l’expertise humaine, mais il renforce la capacité à détecter rapidement les signaux utiles et à agir plus tôt.

C’est aussi dans cette logique que je m’intéresse à des outils et documentations externes comme n8n ou les ressources de MDN sur les statuts HTTP.

Conclusion

Ce workflow n8n n’est pas né d’une envie abstraite de faire de l’automatisation pour l’automatisation. Je l’ai conçu pour répondre à un besoin métier très concret : renforcer mes offres de maintenance WordPress avec une couche de surveillance fiable, simple et suffisamment intelligente pour éviter les alertes inutiles.

Ce que j’apprécie le plus dans cette approche, c’est son équilibre. Le workflow reste compréhensible, s’appuie sur des composants standard de n8n, mémorise l’état du site, détecte les transitions vraiment importantes et notifie les bonnes personnes au bon moment. Grâce à la double vérification, il améliore aussi la qualité des alertes en réduisant les faux positifs.

Même s’il a été pensé au départ pour WordPress, il dépasse largement ce cadre. Toute URL peut entrer dans cette logique de contrôle, ce qui en fait une base très intéressante pour la supervision légère d’un parc de sites hétérogènes.

Bref, je le vois comme une brique de service à forte valeur ajoutée : discrète dans sa mise en œuvre, mais très concrète dans ses bénéfices. Et c’est exactement ce que je recherche quand je construis une automatisation utile.

Si vous pensez qu’un workflow de ce type pourrait être utile à votre activité, à votre parc de sites ou à votre offre de maintenance, vous pouvez tout simplement en discuter avec moi. Ce sera l’occasion de voir comment adapter cette logique à votre contexte, à vos contraintes et à vos priorités.