Surveillance interne ou service externe : comment choisir

Un script de surveillance, c'est vingt lignes. C'est précisément pour cela que la question mérite une réponse honnête plutôt qu'un argumentaire : pour un site unique et un enjeu modeste, écrire le vôtre est souvent la bonne décision, et personne n'a intérêt à vous le dire.

Le comparatif, sur les critères qui décident

Une seule ligne de ce tableau est éliminatoire, et c'est la quatrième. Tout le reste se rattrape avec du temps ; une sonde qui meurt avec la machine qu'elle surveille ne se rattrape pas.

L'écrire soi-même : quand c'est le bon choix

Un site, un serveur, une personne. Une tâche cron qui interroge votre page d'accueil et vous envoie un email si le code n'est pas 200, ça marche. Cela coûte une soirée et rien par mois.

Un besoin particulier. Vérifier quelque chose à l'intérieur de votre application, la taille d'une file, un chiffre métier, l'état précis d'une base : aucun service externe ne peut le faire sans un accès qu'il ne faudrait pas lui donner.

Le plaisir de le faire. Une raison légitime, et souvent la plus forte. Un script que vous avez écrit est un script que vous saurez réparer.

Une condition, dans les trois cas : la sonde doit tourner ailleurs que sur la machine surveillée. Une machine à cinq euros par mois chez un autre fournisseur, ou une exécution planifiée chez un tiers, suffit. Sans cela, vous avez écrit un outil qui se tait exactement quand il devrait parler.

Les trois murs que l'on finit par rencontrer

La vérification tourne sur la machine surveillée. Si le serveur tombe, le script tombe avec lui. La panne que personne ne détecte est justement celle où tout est à terre en même temps, et c'est pour celle-là que vous l'aviez écrit.

L'historique disparaît. Savoir que le site est tombé maintenant est la moitié facile. Répondre à « quelle a été sa disponibilité le mois dernier » suppose de stocker chaque vérification, de gérer la rétention, et de savoir recalculer un taux quand une fenêtre de maintenance était prévue. C'est là qu'un projet d'un week-end devient une petite base de données à maintenir.

Ça se multiplie mal. Un site, vingt lignes. Vingt sites, une rotation d'intervalles, des fausses alertes à régler, des alertes qui s'arrêtent sans que personne s'en aperçoive, et un client qui réclame un rapport mensuel. L'organisation d'un parc est un métier à part entière, et ce n'est pas celui pour lequel le script avait été écrit.

Les quatre pièges du script maison, dans l'ordre où on les rencontre

Aucun n'est insurmontable. Tous se découvrent après coup, ce qui est le problème.

L'email d'alerte n'arrive pas. Un serveur qui envoie du courrier depuis sa propre adresse IP finit en indésirable, ou nulle part. On s'en aperçoit le jour où l'on attendait l'alerte, c'est-à-dire trop tard. Le correctif est simple, un service d'envoi transactionnel, et il ajoute une dépendance de plus à surveiller.

Le script s'arrête sans le dire. Une mise à jour de langage, un chemin qui change, un quota atteint : la tâche planifiée échoue silencieusement. Un script de surveillance a besoin d'être surveillé, ce qui est logiquement inconfortable et pratiquement vrai. La parade tient en une ligne : faites-lui envoyer un signe de vie hebdomadaire, dont l'absence vous alerte.

Les faux positifs finissent par gagner. Sans confirmation ni mémoire d'état, un script envoie un email à chaque hoquet réseau. Au bout de trois semaines, personne ne les ouvre plus, et la surveillance existe encore sans servir à rien.

Personne d'autre ne sait le réparer. Le jour où vous êtes en vacances, le script est une boîte noire écrite dans un style personnel, sans documentation. C'est acceptable pour un site personnel, beaucoup moins dès qu'un client dépend de la réponse.

Le coût réel, en temps

C'est le seul argument sérieux, et c'est celui que les comparatifs évitent parce qu'il ne se met pas dans un tableau de prix.

L'écriture initiale coûte une soirée. Le reste coûte par petites tranches : une heure quand le fournisseur d'envoi d'emails change ses règles, deux heures le jour où le certificat de votre propre sonde expire, une demi-journée pour ajouter l'historique quand un client le demande, et un après-midi la première fois que vous découvrez que le script ne s'exécutait plus depuis six semaines.

Comptez une à deux journées par an, réparties au pire moment, toujours pendant que vous faisiez autre chose. À comparer avec un abonnement, en gardant en tête que votre journée vaut probablement plus que ce qu'un an d'abonnement coûte.

Ce qu'un service externe achète réellement

Pas la vérification elle-même : vous savez l'écrire. Il achète le point de vue extérieur, l'historique que vous n'avez pas eu à stocker, et le fait que la chose continue de tourner quand votre infrastructure, elle, ne tourne plus.

Et la part à laquelle personne ne pense au début : quelqu'un d'autre l'entretient. Un script de surveillance qui a cessé de fonctionner il y a trois mois est pire que pas de surveillance du tout, parce que vous vous croyez encore couvert. C'est la panne silencieuse la plus courante du domaine, et la seule que sa victime ne peut pas détecter par définition.

Le montage hybride, qui est ce que font la plupart des équipes sérieuses

Ce n'est pas un compromis mou, c'est la bonne réponse dès que le système dépasse un site.

La surveillance d'infrastructure reste chez vous : disque, mémoire, files d'attente, chiffres métier. Elle voit ce qu'un extérieur ne peut pas voir, et elle a le droit de tomber avec la machine, puisque c'est la machine qu'elle décrit.

La surveillance de site part de l'extérieur : le code de réponse, le temps de réponse, le certificat, le contenu attendu sur la page. Elle voit ce que vos visiteurs voient, et c'est le seul point de vue qui reste valable quand tout le reste est à terre. C'est aussi la seule qui répond à la question à laquelle votre hébergeur ne répondra jamais.

Les deux ne se remplacent pas. Elles répondent à deux questions différentes, et les confondre est la cause la plus fréquente d'une surveillance qui rassure sans protéger.

Une règle de décision honnête

Partez de ce que vous perdriez pendant trois heures de panne, et du nombre de sites dont vous vous occupez. Le premier chiffre se calcule en cinq minutes, le second, vous le connaissez déjà.

• Un site, enjeu faible → écrivez-le vous-même, faites-le tourner ailleurs, et vérifiez une fois par trimestre qu'il se déclenche encore.
• Plusieurs sites, ou un client dans la boucle → un service externe se rembourse en temps que vous ne passez plus à l'entretenir.
• Besoins profonds dans l'application → les deux, à des postes différents.

Le même arbitrage se rejoue, à l'identique, sur un autre objet : suivre ses backlinks dans un tableur tenu à la main tient longtemps, puis cesse de tenir pour exactement les mêmes raisons. Le tableur, ses sept colonnes et sa date de péremption racontent la même histoire avec d'autres lignes.

Et quel que soit votre choix, la question de l'intervalle reste entière : elle se règle à partir du coût, pas de la technique. La première chose à faire ensuite, le jour où quelque chose tombe, est la même dans les deux cas : les quinze premières minutes ne dépendent pas de l'outil.