Supervision de la disponibilité : Comment éviter les temps d’arrêt avec le monitoring de l’uptime

6 803 dollars par seconde. Cela ressemble au salaire de Jeff Bezos, et nous ne serions pas loin de la vérité, car c’est le montant des pertes qu’Amazon a subies lors d’une panne de service de la CDN Fastly le 8 juin 2021. En un peu plus d’une heure, la perte s’est élevée à 32 millions de dollars, car chaque seconde de downtime représente des ventes perdues, des activités interrompues et des clients frustrés qui partent et ne reviennent pas. D’où l’importance de mettre en place une supervision de l’uptime ou monitoring de la disponibilité dans notre infrastructure technologique.
Aujourd’hui, tout va plus vite que jamais, mais rien n’est aussi rapide que l’impatience des utilisateurs, et rien n’est aussi long qu’une heure sans documents, chats ou applications de travail, pendant que l’on voit les euros partir en fumée.
Des erreurs surviendront toujours, la différence réside dans la capacité de mitigation, qui commence par la détection instantanée de toute anomalie. C’est pourquoi nous vous proposons ce guide complet sur le monitoring de l’uptime, comprenant : ce qu’est la supervision de la disponibilité, les techniques et outils essentiels, des exemples et stratégies pratiques, les critères pour choisir la solution adaptée et bien plus encore.

Qu’est-ce que la supervision de la disponibilité et pourquoi est-elle essentielle ?

La supervision de la disponibilité (uptime monitoring) est le système de veille qui garantit que nos services numériques, qu’il s’agisse de sites web, d’APIs, de serveurs ou de Systèmes de Contrôle Industriel, restent toujours opérationnels. En termes techniques, il s’agit d’un ensemble de protocoles et d’outils qui vérifient de manière automatisée et continue l’état de santé des composants de l’infrastructure IT.
Cela permet de :

• Détecter les pannes en temps réel avant que les utilisateurs ne s’en aperçoivent.
• Prévenir les temps d’arrêt des services grâce à des alertes proactives.
• Garantir le respect des Service Level Agreements (SLAs), comme par exemple, un taux de disponibilité de 99,99 %.

Dans la pratique, cela fonctionne grâce à la mise en place de vérifications programmées qui évaluent :

• La connectivité réseau. Le serveur répond-il aux pings ?
• La fonctionnalité des services. L’API renvoie-t-elle les données attendues lors des requêtes ?
• L’accessibilité des applications et leur bon fonctionnement comme la validité du certificat SSL du site web.

Par exemple, si une entreprise utilise Kubernetes, le uptime monitoring ne se limite pas à vérifier que les nœuds sont actifs, mais s’assure également que les pods critiques, comme un service d’authentification, fonctionnent correctement.

L’impact des temps d’arrêt : bien plus que des chiffres

Le coût d’une interruption de service dépasse largement les pertes économiques directes. Par exemple :

• British Airways a payé une amende de 183 millions de livres sterling en 2017 après 3 jours d’interruption de service, sans compter les pertes liées à l’incapacité d’opérer.
• En 2020, une panne chez AWS a paralysé plusieurs services et sites web, peu avant le Black Friday, affectant indirectement des hôpitaux et la logistique.

Mais l’interruption d’un service entraîne également un coût critique difficilement quantifiable : la perte de confiance des clients. Selon les données, 47 % des utilisateurs quittent un site si celui-ci met plus de 2 secondes à charger… 80 % ne reviennent jamais après une mauvaise expérience.
Dans ce contexte, la supervision de la disponibilité (uptime monitoring) n’est plus optionnelle. C’est le strict minimum pour garantir autant que possible la continuité des services.
Comment commencer ?

La clé est de combiner des techniques de base, comme le ping vers le service, avec des méthodes plus avancées, telles que la supervision du réseau et de l’expérience utilisateur (UX) et de l’expérience utilisateur web WUX), afin de créer un filet de sécurité multicouche.
Voyons les principales techniques disponibles pour le construire.

Principales techniques de supervision de la disponibilité (Uptime Monitoring)

On peut être en vie, mais aussi agonisant. C’est pourquoi la supervision de la disponibilité ne se limite pas à vérifier si un serveur répond. Il est essentiel d’appliquer des techniques combinées qui détectent les pannes à différents niveaux de l’infrastructure, en commençant par la couche la plus basique.

Supervision par Ping (ICMP), les bases de la supervision

Cette méthode consiste à envoyer des paquets ICMP à un dispositif pour vérifier sa connectivité basique. Cela permet d’identifier les pannes totales ou les coupures réseau, lorsque le ping ne reçoit pas de réponse.
Mais que se passe-t-il si notre WordPress ne peut pas se connecter à sa base de données en raison d’une erreur de configuration ?
Le ping nous dira que le serveur est « en vie », mais pas qu’il est “malade”. C’est pourquoi d’autres techniques de supervision sont indispensables.
Sans cela, monitorer uniquement avec un ping revient à l’image célèbre du chien assis tranquillement avec une tasse de café, entouré d’un incendie. Le serveur dira ” Tout va bien ” si on le questionne, mais tout autour de lui est en train de brûler.

Supervision HTTP/S, l’étape suivante

Avec cette technique, l’objectif est de s’assurer que le service web répond bien avec le code HTTP 200 OK et que les certificats SSL sont valides. Tant que ces conditions sont remplies, les utilisateurs finaux peuvent accéder et utiliser la page web ou l’API sans problème.
Cette approche permet, par exemple, de détecter qu’une boutique WooCommerce renvoie une erreur 500 le jour du Black Friday. Parce que, comme le dit la loi de Finagle : “Tout ce qui peut mal tourner, tournera mal au pire moment.”
Dans ce cas, il serait judicieux de combiner cette supervision avec une supervision synthétique, en simulant des transactions réelles pour vérifier leur bon fonctionnement et optimiser l’expérience utilisateur.

Supervision DNS, garantir la résolution de domaine

Cette technique permet de superviser la résolution DNS et les temps de propagation, évitant que le domaine devienne inaccessible en raison d’une erreur de configuration, d’attaques de type DNS poisoning, etc.
Imaginons qu’une banque fusionne avec une autre et qu’il soit nécessaire de mettre à jour les enregistrements DNS. Si une erreur se produit dans les enregistrements MX, cela pourrait empêcher les clients d’accéder à leur service de banque en ligne.
Des outils de supervision DNS, capables de déclencher des alertes en cas de modifications non autorisées ou de défaillances dans les résolutions, permettraient d’identifier immédiatement le problème et d’agir rapidement pour le résoudre.

Supervision TCP/UDP, superviser les ports clés

Cette technique permet de vérifier l’accessibilité et les performances des ports spécifiques d’un réseau. Elle garantit que les services utilisant des protocoles TCP (HTTP, SMTP, FTP…) et UDP (streaming vidéo, VoIP…) restent opérationnels.
Par exemple, dans un hôpital, l’accès sécurisé aux dossiers médicaux se fait via le port 443. Mais si, par mégarde, le stagiaire (c’est toujours le stagiaire !) reconfigure le pare-feu et bloque ce port, une supervision TCP/UDP détecterait immédiatement l’anomalie via une alerte, bien avant que les cris des médecins ne nous parviennent.
C’est ici que l’importance des solutions intégrées de supervision de l’infrastructure IT devient évidente..

Supervision SNMP, le «chien de garde» du réseau

Une autre technique essentielle dans notre arsenal est la supervision via le protocole SNMP (Simple Network Management Protocol), qui permet de superviser le réseau en signalant tout problème ou comportement inhabituel. Cela s’effectue en collectant des données provenant de routeurs, commutateurs ou dispositifs IoT via ce protocole.
Par exemple, si une imprimante se connecte à Internet et commence à envoyer des gigaoctets de données vers un serveur inconnu… Cela semble « totalement normal » (spoiler : ce ne l’est pas), mais une supervision SNMP le détecterait immédiatement. Implémenter cette technique permet d’éviter bien des maux de tête. Voici d’ailleurs un guide utile pour configurer SNMP.
Une bonne stratégie de supervision de la disponibilité (uptime monitoring) doit combiner ces techniques en fonction des besoins techniques et opérationnels de l’organisation. Cela permet d’éviter des scénarios où le ping indique que « tout va bien », alors qu’en réalité, l’API de transactions en ligne est en panne, et que personne ne s’en rend compte.
L’objectif final est d’assurer le respect des niveaux de service (SLA, Service Level Agreement). Il est donc crucial d’approfondir ce concept et d’autres notions associées pour élaborer une stratégie de supervision complète et efficace.

SLA, SLO, SLI et leur relation avec la supervision de la disponibilité

Bien que nous travaillions avec des machines, c’est pour des personnes que nous le faisons, et celles-ci exigeront de notre part des garanties de service, étant donné le caractère catastrophique de chaque seconde d’indisponibilité.
C’est ici qu’interviennent tous ces acronymes avec lesquels nous devons être familiers :

• SLA (Service Level Agreement) :Spécifie le niveau minimum de service que nous garantissons à un client. Par exemple, que la disponibilité d’un site web soit de 99,00 %. Dans le cas contraire, des compensations peuvent être établies en cas de non-respect. Voici un guide SLA pour tout savoir à ce sujet.
• SLO (Service Level Objective) : Si le SLA représente l’engagement externe envers les clients, le SLO correspond à l’objectif interne d’efficacité que nous nous fixons. Évidemment, le SLO doit être plus ambitieux que le SLA afin de garantir que nous respectons ce dernier avec une certaine marge de manœuvre. En reprenant l’exemple précédent, si nous promettons 99,00 % de disponibilité dans le SLA, nous pouvons fixer un SLO de 99,90 %, en intervenant lorsque notre système de supervision de la disponibilité indique que nous n’atteignons pas le SLO. Cela garantit le respect du SLA, tout en conservant une précieuse marge de manœuvre.
• SLI (Service Level Indicator): Cette métrique mesure notre respect du SLO. Pour la disponibilité, le SLI est généralement le pourcentage de temps de fonctionnement.

La relation entre ces trois concepts est claire :
Le SLI mesure le SLO, et le SLO, interne et plus strict que le SLA, garantit le respect de ce dernier.

Comment la supervision de la disponibilité impacte les SLA

Il existe un documentaire fascinant et multi-récompensé intitulé Man on Wire (2008). Il recrée l’exploit du funambule français Philippe Petit, qui, en 1974, a tendu illégalement un câble entre les tours jumelles de New York… et a marché dessus d’une tour à l’autre. Chaque pas représentait un exploit, et la moindre erreur ou imprévu signifiait la fin. La traversée fut angoissante : 45 minutes pour parcourir 8 fois les 400 mètres qui séparaient les tours.
Fascinant, vraiment. Mais l’important, c’est qu’avec les SLA, nous sommes dans une situation similaire. Il est très compliqué de progresser et de grignoter des centièmes dans les SLA et SLO pour améliorer ces indicateurs, mais il est très facile de chuter et de ne pas respecter les engagements dès qu’un temps d’indisponibilité nous fait perdre l’équilibre.
La supervision de la disponibilité est le filet du funambule, qui vérifie le respect des engagements et alerte immédiatement pour atténuer la chute. Sans cette supervision de disponibilité :

• Nous ne pourrons pas démontrer que nous atteignons la disponibilité promise.
• Nous risquons des amendes ou des pénalités contractuelles, comme ce fut le cas pour British Airways.
• Et surtout, nous perdons en crédibilité auprès des clients ou des partenaires, une confiance aussi fragile que de la porcelaine fine : facile à briser et presque impossible à réparer une fois endommagée.

Exemples de métriques clés pour la disponibilité et les SLA

Il n’existe pas de métriques parfaites, seulement celles qui sont les plus adaptées à une organisation selon son activité. Cependant, certaines sont essentielles pour la supervision de la disponibilité et le respect des SLA, telles que :

Indicateur	Comment cela se mesure	Impact sur les SLA
Uptime (%)	(Temps de fonctionnement / Temps total) × 100	Indicateur principal pour les SLA de disponibilité.
MTTR (Mean Time to Repair)	Temps moyen pour résoudre les incidents.	Un MTTR élevé = Plus de pénalités pour le temps d’indisponibilité.
Latence maximale	Temps de réponse d’un service (ex : <500 ms).	Si cela est dépassé, cela peut être considéré comme un « downtime fonctionnel » en rendant un service inutilisable.

Dans ce guide définitif des SLA, SLO et SLI vous pouvez approfondir ce sujet.

Comparaison des outils de supervision de la disponibilité

Lorsqu’il s’agit de choisir l’outil adapté à notre situation, il est essentiel de se demander si nous avons simplement besoin d’une alarme basique pour notre modeste site web, ou d’un véritable centre de commande et de contrôle, car nous sommes liés par des SLA avec des clients.
Le choix de l’outil dépendra de cette réflexion. Analysons donc quelques options populaires :

Outils spécialisés (axés uniquement sur la disponibilité)

Outil	Avantages	Inconvénients	Convient pour
Uptime Robot	– Gratuit jusqu’à 50 moniteurs. – Alertes par email, SMS et intégrations de base.	– Pas de métriques avancées (ex : WUX), seulement des métriques de base (ping, HTTPS, etc.).	Projets personnels et entreprises en démarrage.
Uptime.com	– Supervision de base et avancée, comme la supervision transactionnelle (ex : flux de connexion). – Bons rapports.	– Limité dans certaines intégrations, comme les tickets.	Entreprises avec des SLA stricts.
Pingdom	– Supervision avancée (synthetique et utilisateur réel). – API simple.	– Le rapport coût/performances est légèrement plus élevé que d’autres alternatives.	Commerces en ligne avec un trafic mondial.

Si dans notre cas, nous avons besoin de ce centre de commande, il est essentiel de considérer des solutions intégrales qui combinent la supervision de la disponibilité avec d’autres métriques fondamentales. C’est particulièrement important pour les organisations de grande envergure ou fortement axées sur la technologie.
Voyons quelques options :

Solutions intégrales (combinaison de la disponibilité avec d’autres métriques)

Outil	Avantages	Inconvénients	Convient pour
Better Stack	– Pages d’état personnalisables. – Idéal pour les équipes DevOps (API REST).	– Peu d’options pour les réseaux on-premise. – Devient rapidement coûteux avec de nombreux sites web.	Webmasters et startups technologiques avec une infrastructure cloud.
ManageEngine	– Supervision SNMP et réseau intégrée. – Alertes basées sur l’apprentissage automatique.	– Courbe d’apprentissage élevée. – L’implémentation n’est pas très intuitive.	Entreprises avec des réseaux hybrides.
Datadog	– Plus de 500 intégrations (AWS, Kubernetes, etc.). – Supervision synthétique et utilisateur réel (RUM).	– Le coût par hôte et par mois peut rapidement augmenter. – Trop complexe pour des besoins simples.	Corporations avec une infrastructure multicloud.
Pandora FMS	–Tout-en-un : uptime, WUX, SNMP, analyse des journaux, etc. – Scalable des PME aux grandes entreprises.	– Nécessite une configuration initiale détaillée.	Environnements complexes (ex : supervision des réseaux + WUX).

Comme nous pouvons le constater, il existe des différences clés entre les outils spécialisés de supervision de la disponibilité et les solutions intégrales comme Pandora FMS, différences que nous pouvons visualiser facilement.

	Outils spécialisés	Solutions intégrées (Pandora FMS)
Portée	Ils vérifient « si c’est en ligne ».	Ils analysent « comment cela fonctionne » (ex : performance des APIs, goulots d’étranglement dans les réseaux, etc.).
Intégrations	APIs de base.	Ils se connectent également avec les CRM, ERP, outils de Business Intelligence, journaux, etc.
Coût	Peu coûteuses au début, mais évoluent mal.	Investissement initial plus élevé, mais économies à long terme en évitant l’utilisation de multiples outils.
Cas d’utilisation	Blog personnel, page de destination, etc.	Toute organisation : magasins en ligne, hôpitaux, banques, etc.

En résumé, un outil de supervision de la disponibilité s’apparente à l’achat d’un thermomètre pour superviser la santé de notre infrastructure : il alerte en cas de « fièvre », mais ne va pas au-delà et ne permet pas d’en identifier les causes. En revanche, des solutions comme Pandora FMS sont de véritables systèmes de diagnostic complet, un véritable « hôpital » capable de révéler les causes profondes, et pas seulement les symptômes, afin de résoudre toute éventualité pouvant menacer le respect des SLA.

Les limites de la mesure de la disponibilité : le rôle de l’expérience utilisateur (UX/WUX)

Un uptime de 99,95 % peut sembler impressionnant, mais imaginez un centre médical avec cette métrique où chaque dossier patient met 30 secondes à se charger. Ou encore, une boutique en ligne avec une erreur partielle qui empêche le chargement du panier d’achat.
Ces exemples démontrent que l’uptime seul est insuffisant dans des scénarios réels. Il devient donc essentiel de superviser l’expérience utilisateur (User Experience – UX et Web User Experience – WUX).
Mesurer cette expérience est un concept vaste et humain, qui dépasse les simples chiffres, mais que l’on peut aborder avec des techniques comme :

• Tests synthétiques : Réalisés avec des scripts qui simulent les actions des utilisateurs, comme réserver un vol ou effectuer un paiement. Des fonctionnalités telles que la supervision synthétique de Pandora FMS permettent ces mesures.
• Alertes proactives : Par exemple, quantifier les temps de chargement des dossiers médicaux et informer l’équipe IT avant que des tickets urgents ne soient soumis.

Les indicateurs techniques ne sont rien face aux expériences humaines. C’est pourquoi, pour réussir, le minimum est de disposer d’une supervision de la disponibilité, mais cela ne constitue que la première étape d’un long voyage.

Critères pour choisir la meilleure solution de supervision de la disponibilité

Comme mentionné précédemment, il n’existe pas de solutions parfaites, mais des solutions qui s’adaptent le mieux à nos besoins et à notre infrastructure IT. C’est pourquoi tout commence par une analyse de ces deux aspects fondamentaux :

• Besoins : Quels SLA devons-nous respecter ? Quelles fonctionnalités devons-nous garantir pour offrir une expérience utilisateur agréable et fluide ?
• Infrastructure : Quels services doivent être disponibles pour garantir cette expérience utilisateur ? Quelles solutions parmi celles mentionnées sont compatibles avec notre environnement IT ? Comment s’intègrent-elles avec d’autres systèmes de supervision ? Pouvons-nous centraliser la supervision dans une seule solution, comme Pandora FMS (scénario idéal) ?

Comme on le voit, la réponse variera en fonction de chaque organisation. Les meilleures pratiques commencent toujours par se mettre à la place des personnes que nous servons (clients et utilisateurs finaux), afin de choisir ensuite la technologie qui permettra de fournir cette expérience optimale.
Ainsi, nous construirons un système de supervision de la disponibilité en plusieurs couches, garantissant que tout fonctionne comme une horloge… et que l’application de tickets reste silencieuse (mais pas parce qu’elle est tombée sans que nous le sachions !).