{"id":34534,"date":"2026-08-25T02:32:38","date_gmt":"2026-08-25T02:32:38","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/cloud-infrastructure-monitoring\/"},"modified":"2026-08-27T00:31:11","modified_gmt":"2026-08-27T00:31:11","slug":"surveillance-de-l-infrastructure-cloud","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/surveillance-de-l-infrastructure-cloud\/","title":{"rendered":"Surveillance de l&#8217;infrastructure cloud : ce que votre fournisseur ne vous dira pas"},"content":{"rendered":"<figure id=\"attachment_34519\" aria-describedby=\"caption-attachment-34519\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img fetchpriority=\"high\" decoding=\"async\" class=\"size-full wp-image-34519\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/08\/hero-cloud-infrastructure-monitoring.webp\" alt=\"Centre d&apos;op\u00e9rations r\u00e9seau avec un tableau de bord d&apos;infrastructure cloud tout vert \u00e0 c\u00f4t\u00e9 d&apos;une alerte de surveillance externe rouge montrant des emplacements d&apos;\u00e9chec de v\u00e9rification dans le monde entier\" width=\"1200\" height=\"800\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/08\/hero-cloud-infrastructure-monitoring.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/08\/hero-cloud-infrastructure-monitoring-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/08\/hero-cloud-infrastructure-monitoring-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/08\/hero-cloud-infrastructure-monitoring-768x512.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34519\" class=\"wp-caption-text\">Un guide d&#8217;achat pour les responsables informatiques \u00e9valuant les outils de surveillance cloud<\/figcaption><\/figure>\n<p>Votre console cloud est verte. Vos alertes sont silencieuses. Et la file de support se remplit de clients qui ne peuvent pas se connecter.<\/p>\n<p>Cette combinaison est plus courante que ce que la plupart des \u00e9quipes admettent, et ce n&#8217;est g\u00e9n\u00e9ralement pas une mauvaise configuration. La surveillance cloud-native s&#8217;ex\u00e9cute \u00e0 l&#8217;int\u00e9rieur de la m\u00eame infrastructure qu&#8217;elle surveille \u2014 donc, lorsque cette infrastructure conna\u00eet une mauvaise journ\u00e9e, sa propre t\u00e9l\u00e9m\u00e9trie est le dernier endroit o\u00f9 chercher une r\u00e9ponse ind\u00e9pendante.<\/p>\n<p>Si vous comparez des outils de surveillance d&#8217;infrastructure cloud en ce moment, ce d\u00e9ficit devrait orienter votre s\u00e9lection plus que toute matrice de fonctionnalit\u00e9s. Ci-dessous : ce que la surveillance de votre fournisseur peut et ne peut pas voir, comment tester un fournisseur face aux pannes que vous rencontrez r\u00e9ellement, et quelles conditions tarifaires surprennent les \u00e9quipes environ six mois apr\u00e8s usage.<\/p>\n<h2 id='ce-que-contient-ce-guide'  id=\"boomdevs_1\">Ce Que Contient Ce Guide<\/h2>\n<ul>\n<li><a href=\"#pourquoi-la-surveillance-de-votre-fournisseur-cloud-ne-peut-pas-d\u00e9tecter-la-panne\">Pourquoi la surveillance de votre fournisseur cloud ne peut pas d\u00e9tecter la panne<\/a><\/li>\n<li><a href=\"#ce-que-mesure-r\u00e9ellement-la-surveillance-cloud-native\">Ce que mesure r\u00e9ellement la surveillance cloud-native<\/a><\/li>\n<li><a href=\"#trois-pannes-qui-apparaissent-en-vert-sur-un-tableau-de-bord-cloud\">Trois pannes qui apparaissent en vert sur un tableau de bord cloud<\/a><\/li>\n<li><a href=\"#comment-\u00e9valuer-un-outil-de-surveillance-d-infrastructure-cloud\">Comment \u00e9valuer un outil de surveillance d\u2019infrastructure cloud<\/a><\/li>\n<li><a href=\"#quelles-m\u00e9triques-inclure-dans-votre-test-de-pr\u00e9s\u00e9lection\">Quelles m\u00e9triques inclure dans votre test de pr\u00e9s\u00e9lection<\/a><\/li>\n<li><a href=\"#o\u00f9-la-tarification-de-la-surveillance-cloud-pi\u00e8ge-les-\u00e9quipes\">O\u00f9 la tarification de la surveillance cloud pi\u00e8ge les \u00e9quipes<\/a><\/li>\n<li><a href=\"#questions-\u00e0-poser-\u00e0-chaque-appel-avec-un-fournisseur\">Questions \u00e0 poser \u00e0 chaque appel avec un fournisseur<\/a><\/li>\n<li><a href=\"#le-point-sur-la-surveillance-d-infrastructure-cloud\">Le point sur la surveillance d\u2019infrastructure cloud<\/a><\/li>\n<li><a href=\"#heading-faq\">Questions fr\u00e9quemment pos\u00e9es<\/a><\/li>\n<\/ul>\n<h2 id='pourquoi-la-surveillance-de-votre-fournisseur-cloud-ne-peut-pas-d\u00e9tecter-la-panne'  id=\"boomdevs_2\" id=\"why-your-cloud-provider-s-monitoring-can-t-see-the-outage\">Pourquoi la surveillance de votre fournisseur cloud ne peut pas d\u00e9tecter la panne<\/h2>\n<p>Chaque syst\u00e8me de surveillance dispose d\u2019un point de vue. Le point de vue de votre fournisseur se situe \u00e0 l&#8217;int\u00e9rieur de son propre r\u00e9seau.<\/p>\n<p>Une d\u00e9finition d&#8217;abord, car elle d\u00e9cide du reste de l&#8217;argumentation. La surveillance cloud-native signifie ici les m\u00e9triques et alarmes par d\u00e9faut des ressources que vous obtenez avec la plateforme \u2014 Amazon CloudWatch, Azure Monitor, Google Cloud Monitoring \u2014 et non pas chaque fonctionnalit\u00e9 de disponibilit\u00e9 que le fournisseur vend avec.<\/p>\n<p>Ces options par d\u00e9faut sont utiles. CloudWatch vous dira qu&#8217;une instance est bloqu\u00e9e \u00e0 100 % CPU, qu&#8217;un groupe d&#8217;Auto Scaling a ajout\u00e9 de la capacit\u00e9, que les connexions \u00e0 la base de donn\u00e9es sont \u00e9puis\u00e9es. Ce sont de vrais signaux, et vous devez continuer \u00e0 les collecter.<\/p>\n<p>Mais la v\u00e9rification s&#8217;ex\u00e9cute sur le plan de contr\u00f4le du fournisseur, via le r\u00e9seau du fournisseur, contre l&#8217;API du fournisseur. Si le plan de contr\u00f4le se d\u00e9grade, le pipeline des m\u00e9triques se d\u00e9grade avec. Et les m\u00e9triques retard\u00e9es ressemblent exactement \u00e0 des m\u00e9triques saines sur un tableau de bord : aucune alarme ne s&#8217;enclenche, car aucune donn\u00e9e n&#8217;est arriv\u00e9e qui pourrait en d\u00e9clencher une.<\/p>\n<p>La deuxi\u00e8me limite est encore plus importante pour tout ce qui est orient\u00e9 client. Ces m\u00e9triques par d\u00e9faut mesurent vos ressources, pas le chemin entre un utilisateur \u00e0 S\u00e3o Paulo et votre load balancer dans us-east-1. La r\u00e9solution DNS, le routage BGP, le comportement du CDN sur le bord, la n\u00e9gociation TLS, les scripts tiers, les r\u00e8gles WAF \u2014 tout cela est hors de cette limite, et l\u2019un de ces \u00e9l\u00e9ments peut interrompre votre service alors que CPU et m\u00e9moire restent stables.<\/p>\n<blockquote><p>Un syst\u00e8me de surveillance qui vit \u00e0 l&#8217;int\u00e9rieur du domaine de panne est le dernier \u00e0 vous dire que ce domaine est en panne.<\/p><\/blockquote>\n<h3 id='mais-cloudwatch-synthetics-ne-fait-il-pas-d\u00e9j\u00e0-cela'  id=\"boomdevs_3\" id=\"but-doesn-t-cloudwatch-synthetics-already-do-this\">Mais CloudWatch Synthetics ne fait-il pas d\u00e9j\u00e0 cela ?<\/h3>\n<p>En partie, et cette objection m\u00e9rite d\u2019\u00eatre prise au s\u00e9rieux. Chaque fournisseur majeur vend quelque chose dans ce domaine : les canaris CloudWatch Synthetics, les contr\u00f4les de sant\u00e9 Route 53, les tests de disponibilit\u00e9 Azure Monitor, les contr\u00f4les d&#8217;uptime Google Cloud. Ils effectuent de vraies requ\u00eates contre vos points de terminaison et cela fonctionne.<\/p>\n<p>Le probl\u00e8me est d&#8217;o\u00f9 ils s&#8217;ex\u00e9cutent. Ces contr\u00f4les fonctionnent dans la m\u00eame infrastructure du fournisseur et envoient les r\u00e9sultats \u00e0 la m\u00eame console, la couverture en dehors des r\u00e9gions du fournisseur est mince, et un \u00e9v\u00e9nement r\u00e9gional \u00e9tendu peut frapper les contr\u00f4les et la charge de travail simultan\u00e9ment. Des outils utiles \u2014 mais pas ind\u00e9pendants.<\/p>\n<p>L&#8217;ind\u00e9pendance est le vrai besoin, et il est juste de la retourner contre tout fournisseur. Beaucoup de services de surveillance tiers fonctionnent aussi sur un cloud majeur. Demandez donc o\u00f9 sont situ\u00e9s les points de contr\u00f4le : un r\u00e9seau couvrant plusieurs fournisseurs et des n\u0153uds op\u00e9r\u00e9s par des transporteurs, ou trois r\u00e9gions lou\u00e9es dans le cloud que vous utilisez d\u00e9j\u00e0. Dotcom-Monitor exploite son propre <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/fonctionnalites\/caracteristiques-surveillance-du-reseau\/\">r\u00e9seau mondial de surveillance<\/a> au lieu de louer des r\u00e9gions, ce qui rend les contr\u00f4les significatifs.<\/p>\n<p>Vous pouvez construire une version de ceci. Prometheus Blackbox Exporter sonde les points de terminaison, et pour un ou deux points de vue, c\u2019est une r\u00e9ponse raisonnable. Le co\u00fbt appara\u00eet quand vous avez besoin de dizaines de g\u00e9ographies, d&#8217;un rendu r\u00e9el en navigateur, et de quelqu&#8217;un de disponible pour les sondes elles-m\u00eames.<\/p>\n<p>Dans tous les cas, lancez la v\u00e9rification en dehors du syst\u00e8me que vous contr\u00f4lez. La <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/solutions\/synthetic-monitoring\/\">surveillance synth\u00e9tique<\/a> envoie des requ\u00eates via Internet public selon un planning que vous param\u00e9trez. Si une requ\u00eate \u00e9choue, vous le savez gr\u00e2ce au contr\u00f4le et non via un client.<\/p>\n<h2 id='ce-que-mesure-r\u00e9ellement-la-surveillance-cloud-native'  id=\"boomdevs_4\" id=\"what-cloud-native-monitoring-actually-measures\">Ce que mesure r\u00e9ellement la surveillance cloud-native<\/h2>\n<p>Voici la ventilation, couche par couche. Cartographiez votre couverture actuelle avant de parler \u00e0 un fournisseur.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Couche<\/th>\n<th>M\u00e9triques cloud par d\u00e9faut<\/th>\n<th>Contr\u00f4les externes ind\u00e9pendants<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>CPU, m\u00e9moire, disque sur vos instances<\/td>\n<td>Oui, en d\u00e9tail<\/td>\n<td>Non<\/td>\n<\/tr>\n<tr>\n<td>Sant\u00e9 des bases de donn\u00e9es et files g\u00e9r\u00e9es<\/td>\n<td>Oui<\/td>\n<td>Indirectement, via le comportement de l&#8217;application<\/td>\n<\/tr>\n<tr>\n<td>\u00c9v\u00e9nements d\u2019autoscaling et de d\u00e9ploiement<\/td>\n<td>Oui<\/td>\n<td>Non<\/td>\n<\/tr>\n<tr>\n<td>R\u00e9solution DNS publique<\/td>\n<td>Partielle, depuis l&#8217;int\u00e9rieur du VPC<\/td>\n<td>Oui, depuis de vrais r\u00e9solveurs dans le monde entier<\/td>\n<\/tr>\n<tr>\n<td>Validit\u00e9 du certificat TLS \u00e0 la p\u00e9riph\u00e9rie<\/td>\n<td>Partielle<\/td>\n<td>Oui<\/td>\n<\/tr>\n<tr>\n<td>Chemin r\u00e9seau et routage vers les utilisateurs<\/td>\n<td>Non<\/td>\n<td>Oui<\/td>\n<\/tr>\n<tr>\n<td>Comportement CDN et cache en p\u00e9riph\u00e9rie<\/td>\n<td>Non<\/td>\n<td>Oui<\/td>\n<\/tr>\n<tr>\n<td>Parcours complet de connexion ou de paiement<\/td>\n<td>Non<\/td>\n<td>Oui<\/td>\n<\/tr>\n<tr>\n<td>Pannes API tierces et scripts<\/td>\n<td>Non<\/td>\n<td>Oui<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>Aucune des deux colonnes ne remplace l\u2019autre. Les outils de votre fournisseur sont le meilleur instrument pour diagnostiquer la cause racine une fois qu\u2019on sait qu\u2019il y a un probl\u00e8me. Les contr\u00f4les externes vous disent que quelque chose cloche en premier lieu \u2014 et ils continuent \u00e0 rapporter quand le pipeline du fournisseur est bloqu\u00e9. Notre article sur <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/fr\/what-is-infrastructure-monitoring\/\">ce que couvre la surveillance d\u2019infrastructure<\/a> approfondit l\u2019aspect niveau ressource.<\/p>\n<p>Utilisez les deux. Pr\u00e9voyez un budget pour les deux.<\/p>\n<figure id=\"attachment_34526\" aria-describedby=\"caption-attachment-34526\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img decoding=\"async\" class=\"size-full wp-image-34526\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/08\/inside-vs-outside-failure-domain.webp\" alt=\"Diagramme comparant la surveillance cloud-native \u00e0 l&apos;int\u00e9rieur du r\u00e9seau fournisseur avec des contr\u00f4les synth\u00e9tiques externes ex\u00e9cut\u00e9s depuis l&apos;ext\u00e9rieur\" width=\"1200\" height=\"530\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/08\/inside-vs-outside-failure-domain.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/08\/inside-vs-outside-failure-domain-300x133.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/08\/inside-vs-outside-failure-domain-1024x452.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/08\/inside-vs-outside-failure-domain-768x339.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34526\" class=\"wp-caption-text\">Les agents cloud-native rapportent depuis l\u2019int\u00e9rieur du r\u00e9seau du fournisseur. Les contr\u00f4les externes lancent la m\u00eame requ\u00eate qu\u2019un client.<\/figcaption><\/figure>\n<h2 id='trois-pannes-qui-apparaissent-en-vert-sur-un-tableau-de-bord-cloud'  id=\"boomdevs_5\" id=\"three-failures-that-show-up-green-on-a-cloud-dashboard\">Trois pannes qui apparaissent en vert sur un tableau de bord cloud<\/h2>\n<p>Ce sont des tendances, pas des \u00e9tudes de cas. Faites tourner des charges de production sur AWS, Azure ou Google Cloud pendant quelques ann\u00e9es, et au moins un cas vous semblera familier.<\/p>\n<h3 id='un-enregistrement-dns-tomb\u00e9-en-panne-pour-la-moiti\u00e9-de-vos-utilisateurs'  id=\"boomdevs_6\" id=\"a-dns-record-that-broke-for-half-your-users\">Un enregistrement DNS tomb\u00e9 en panne pour la moiti\u00e9 de vos utilisateurs<\/h3>\n<p>Quelqu\u2019un met \u00e0 jour un enregistrement lors d\u2019une migration. Le changement est correct au niveau du serveur de noms faisant autorit\u00e9, donc toutes les v\u00e9rifications internes passent. Mais le point de terminaison ancien a \u00e9t\u00e9 d\u00e9commissionn\u00e9 avant que le TTL pr\u00e9c\u00e9dent ne soit expir\u00e9, si bien que les r\u00e9solveurs r\u00e9cursifs du monde entier continuent de retourner l\u2019ancienne adresse jusqu\u2019\u00e0 l\u2019expiration de leur cache. Une part de votre trafic continue de cibler un point qui ne r\u00e9pond plus.<\/p>\n<p>Vos instances sont en bonne sant\u00e9. Votre load balancer voit moins de trafic et ne rapporte rien d\u2019inhabituel. Capturer ce probl\u00e8me signifie r\u00e9soudre le nom depuis l\u2019ext\u00e9rieur, depuis plusieurs g\u00e9ographies, comme le ferait un vrai client. C\u2019est ce que fait la <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/produits-de-surveillance\/outil-de-surveillance-dns-dotcom-monitor\/\">surveillance DNS<\/a>, et c\u2019est pourquoi l\u2019emplacement des r\u00e9solveurs compte dans une \u00e9valuation.<\/p>\n<h3 id='un-certificat-expir\u00e9-sur-un-load-balancer'  id=\"boomdevs_7\" id=\"a-certificate-that-expired-on-a-load-balancer\">Un certificat expir\u00e9 sur un load balancer<\/h3>\n<p>Le renouvellement est automatis\u00e9 maintenant, c\u2019est pr\u00e9cis\u00e9ment pour cela que la panne est silencieuse. Un job casse, personne ne remarque, et le certificat sur un \u00e9couteur ou une propri\u00e9t\u00e9 CDN en p\u00e9riph\u00e9rie expire.<\/p>\n<p>Les instances derri\u00e8re sont correctes. Le CPU est correct. Les logs d\u2019application montrent une chute des requ\u00eates, pas une erreur. Les navigateurs, eux, affichent un avertissement interm\u00e9diaire \u00e0 chaque visiteur. La <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/produits-de-surveillance\/ssl-certificate-monitoring\/\">surveillance de certificat SSL<\/a> qui v\u00e9rifie la cha\u00eene depuis l\u2019ext\u00e9rieur d\u00e9tecte cela plusieurs semaines avant.<\/p>\n<h3 id='une-r\u00e9gion-marqu\u00e9e-comme-fonctionnant-normalement'  id=\"boomdevs_8\" id=\"a-region-marked-operating-normally\">Une r\u00e9gion marqu\u00e9e comme fonctionnant normalement<\/h3>\n<p>Les pages de statut des fournisseurs attendent g\u00e9n\u00e9ralement une confirmation interne avant que la couleur ne change. C\u2019est une fa\u00e7on raisonnable d\u2019\u00e9viter les fausses alertes pour des millions de clients, mais cela signifie aussi que la page est souvent en retard sur l\u2019incident. Les \u00e9quipes voient r\u00e9guli\u00e8rement des erreurs avant que le tableau de bord ne devienne jaune.<\/p>\n<p>Si votre r\u00e9ponse aux incidents attend la page de statut, vous laissez le temps de d\u00e9tection \u00e0 un autre processus de revue. Les contr\u00f4les ind\u00e9pendants vous donnent votre propre chronologie \u2014 pendant l\u2019incident, et apr\u00e8s, quand vous r\u00e9conciliez avec un SLA. Ce sont les donn\u00e9es qui rendent les <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/fonctionnalites\/uptime-and-sla-reports\/\">rapports de disponibilit\u00e9 et SLA<\/a> valables en cas de litige.<\/p>\n<h2 id='comment-\u00e9valuer-un-outil-de-surveillance-d-infrastructure-cloud'  id=\"boomdevs_9\" id=\"how-to-evaluate-a-cloud-infrastructure-monitoring-tool\">Comment \u00e9valuer un outil de surveillance d&#8217;infrastructure cloud<\/h2>\n<p>La plupart des comparaisons de fournisseurs classent les fonctionnalit\u00e9s. Cela vous dit peu de choses \u2014 les listes de fonctionnalit\u00e9s ont converg\u00e9, et la moiti\u00e9 d\u00e9crivent la m\u00eame capacit\u00e9 sous un branding diff\u00e9rent. Testez plut\u00f4t avec vos propres pannes.<\/p>\n<p><strong>\u00c9tape 1 : Notez les cinq derniers incidents que vous avez r\u00e9ellement eus.<\/strong> R\u00e9cup\u00e9rez-les dans votre syst\u00e8me de tickets, pas de m\u00e9moire, et notez comment vous avez appris chaque incident. Si plus d\u2019un vient d\u2019un client, vous avez un probl\u00e8me de d\u00e9tection, pas de tableau de bord.<\/p>\n<p><strong>\u00c9tape 2 : V\u00e9rifiez d&#8217;o\u00f9 le fournisseur lance ses contr\u00f4les.<\/strong> Demandez la liste des emplacements, pas un simple nombre, et demandez qui poss\u00e8de ces emplacements. Trente emplacements regroup\u00e9s en Am\u00e9rique du Nord et Europe de l\u2019Ouest ne disent rien sur les utilisateurs en Asie du Sud-Est. Les emplacements lou\u00e9s dans le cloud que vous utilisez d\u00e9j\u00e0 ne servent \u00e0 rien en cas d\u2019\u00e9v\u00e9nement r\u00e9gional.<\/p>\n<p><strong>\u00c9tape 3 : Testez un parcours multi-\u00e9tapes, pas un simple ping de page d\u2019accueil.<\/strong> Un code 200 sur votre URL racine prouve presque rien. Script une connexion, une recherche, un ajout au panier, un appel API authentifi\u00e9 avec un identifiant de test limit\u00e9. Les v\u00e9rifications de code-status r\u00e9ussissent tous vos tests et manquent encore la panne qui vous co\u00fbte de l\u2019argent. Le scripting <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/fonctionnalites\/everystep\/\">EveryStep<\/a> g\u00e8re le cas du parcours enregistr\u00e9.<\/p>\n<p><strong>\u00c9tape 4 : Cassez quelque chose volontairement pendant la p\u00e9riode d\u2019essai.<\/strong> Pointez un contr\u00f4le vers un nom d\u2019h\u00f4te de staging que vous contr\u00f4lez, puis retirez l\u2019enregistrement DNS ou retournez une erreur 500 dure. Chronom\u00e9trez l\u2019alerte et lisez ce qu\u2019elle dit. C\u2019est l\u2019heure la plus utile que vous passerez sur un essai.<\/p>\n<p><strong>\u00c9tape 5 : Lisez l\u2019alerte comme si elle vous r\u00e9veillait.<\/strong> Nomme-t-elle l\u2019\u00e9tape qui a \u00e9chou\u00e9, l\u2019emplacement, la classe d\u2019erreur, le temps de r\u00e9ponse ? Ou dit-elle juste \u00ab site down \u00bb ? Cette diff\u00e9rence d\u00e9cide si votre ing\u00e9nieur d\u2019astreinte commence \u00e0 r\u00e9parer \u00e0 2h04 du matin ou commence \u00e0 enqu\u00eater. V\u00e9rifiez comment <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/fonctionnalites\/fonctionnalites-alertes\/\">l\u2019alerte<\/a> s\u2019int\u00e8gre \u00e0 ce que vous utilisez d\u00e9j\u00e0 \u2014 PagerDuty, Slack, Teams, un webhook.<\/p>\n<p><strong>\u00c9tape 6 : Confirmez qu\u2019elle atteint aussi vos syst\u00e8mes internes.<\/strong> Beaucoup de ce que vous ex\u00e9cutez n\u2019est pas public : panneaux d\u2019administration, API internes, staging, tout ce qui est derri\u00e8re un VPN. Un outil qui ne voit qu\u2019Internet ouvert vous fait acheter un second. Les <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/fonctionnalites\/caracteristiques-agents-prives\/\">agents priv\u00e9s<\/a> lancent des contr\u00f4les depuis votre r\u00e9seau et rapportent \u00e0 la m\u00eame console.<\/p>\n<p><strong>\u00c9tape 7 : Mod\u00e9lisez la facture \u00e0 l\u2019\u00e9chelle de l\u2019ann\u00e9e prochaine.<\/strong> Doublez vos contr\u00f4les actuels, appliquez l\u2019intervalle que vous souhaitez r\u00e9ellement plut\u00f4t que celui adapt\u00e9 \u00e0 la d\u00e9mo, et demandez ce chiffrage par \u00e9crit.<\/p>\n<h2 id='quelles-m\u00e9triques-inclure-dans-votre-test-de-pr\u00e9s\u00e9lection'  id=\"boomdevs_10\" id=\"which-metrics-belong-in-your-shortlist-test\">Quelles m\u00e9triques inclure dans votre test de pr\u00e9s\u00e9lection<\/h2>\n<p>Le pourcentage de disponibilit\u00e9 finit dans le rapport au conseil, c\u2019est le chiffre le moins utile pendant une \u00e9valuation \u2014 les chiffres de disponibilit\u00e9 arrondissent exactement les pannes qui vous importent. Demandez plut\u00f4t ces indicateurs :<\/p>\n<ul>\n<li><strong>Temps de d\u00e9tection.<\/strong> Minutes entre le d\u00e9but de la panne et l\u2019arriv\u00e9e de l\u2019alerte. C\u2019est ce chiffre qui justifie l\u2019achat.<\/li>\n<li><strong>Temps de r\u00e9ponse par emplacement.<\/strong> Un p95 par r\u00e9gion, pas une moyenne globale qui masque vos march\u00e9s lents.<\/li>\n<li><strong>R\u00e9partition des erreurs par couche.<\/strong> DNS, TCP, TLS, HTTP, assertions de contenu. Un outil qui note \u00ab \u00e9chec \u00bb sans nommer la couche vous renvoie la d\u00e9bogage.<\/li>\n<li><strong>Comportement de confirmation d\u2019\u00e9chec.<\/strong> Combien d\u2019emplacements doivent \u00eatre en panne avant qu\u2019une alerte se d\u00e9clenche, et \u00e0 quelle vitesse. Trop laxiste et vous obtenez du bruit ; trop strict et vous avez des d\u00e9lais.<\/li>\n<li><strong>R\u00e9tention des donn\u00e9es brutes des v\u00e9rifications.<\/strong> Les synth\u00e8ses sont suffisantes pour les rapports. La revue post-incident a besoin des contr\u00f4les individuels.<\/li>\n<\/ul>\n<p>Les backend distribu\u00e9s compliquent cela \u2014 les d\u00e9pendances \u00e9chouent partiellement et les sympt\u00f4mes se d\u00e9placent. Notre guide sur <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/fr\/surveillance-des-systemes-distribues\/\">la surveillance des syst\u00e8mes distribu\u00e9s<\/a> couvre ce cas.<\/p>\n<h2 id='o\u00f9-la-tarification-de-la-surveillance-cloud-pi\u00e8ge-les-\u00e9quipes'  id=\"boomdevs_11\" id=\"where-cloud-monitoring-pricing-catches-teams-out\">O\u00f9 la tarification de la surveillance cloud pi\u00e8ge les \u00e9quipes<\/h2>\n<p>Les factures de surveillance ont tendance \u00e0 cro\u00eetre plus vite que l\u2019infrastructure qu\u2019elles surveillent. Voici o\u00f9 cela se produit :<\/p>\n<p><strong>Tarification par h\u00f4te dans un environnement autoscal\u00e9.<\/strong> Si vous \u00eates factur\u00e9 par h\u00f4te surveill\u00e9 et que votre flotte s\u2019adapte au trafic, la facture augmente aussi. Demandez comment les instances \u00e9ph\u00e9m\u00e8res sont compt\u00e9es et sur quelle p\u00e9riode.<\/p>\n<p><strong>M\u00e9triques personnalis\u00e9es et tags \u00e0 haute cardinalit\u00e9.<\/strong> La surveillance cloud-native facture souvent par m\u00e9trique personnalis\u00e9e par mois. Ajoutez un tag \u00e0 haute cardinalit\u00e9 \u2014 un ID client, un ID conteneur \u2014 et le nombre se multiplie sans qu\u2019on d\u00e9cide de d\u00e9penser plus.<\/p>\n<p><strong>Ingestion, r\u00e9tention, si\u00e8ges, et SMS.<\/strong> Le volume de logs baisse rarement, alors v\u00e9rifiez ce qui se passe \u00e0 chaque palier et si la r\u00e9tention est factur\u00e9e s\u00e9par\u00e9ment de l\u2019ingestion. Certaines plateformes facturent aussi les utilisateurs, ce qui transforme le fait de \u00ab donner un acc\u00e8s en lecture au support \u00bb en discussion budg\u00e9taire, et facturent s\u00e9par\u00e9ment SMS et alertes vocales.<\/p>\n<p><strong>Fr\u00e9quence des contr\u00f4les.<\/strong> Chez les fournisseurs qui facturent par ex\u00e9cution, passer d\u2019un intervalle de cinq minutes \u00e0 une minute multiplie le co\u00fbt de ce moniteur par cinq. D\u2019autres groupent les ex\u00e9cutions ou limitent la fr\u00e9quence selon le plan, donc la forme varie \u2014 mais ce n\u2019est jamais gratuit, et cela d\u00e9termine si vous d\u00e9tectez une panne courte ou non. \u00c9valuez la fr\u00e9quence que vous utiliserez r\u00e9ellement, par service. La <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/prix\/\">tarification<\/a> de Dotcom-Monitor se base par contr\u00f4le et par intervalle, donc les calculs sont faciles \u00e0 faire \u00e0 l\u2019avance.<\/p>\n<p>Mettez le total en regard du <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/fr\/quel-est-le-cout-des-temps-darret\/\">co\u00fbt de l\u2019indisponibilit\u00e9<\/a> sur votre propre service. Pour la plupart des \u00e9quipes, la ligne de surveillance est petite \u00e0 c\u00f4t\u00e9 d&#8217;une seule mauvaise heure \u2014 mais ayez cette comparaison \u00e9crite avant la discussion de renouvellement.<\/p>\n<h2 id='questions-\u00e0-poser-\u00e0-chaque-appel-avec-un-fournisseur'  id=\"boomdevs_12\" id=\"questions-to-ask-on-every-vendor-call\">Questions \u00e0 poser \u00e0 chaque appel avec un fournisseur<\/h2>\n<p>Apportez-les \u00e0 la d\u00e9mo. Les r\u00e9ponses diff\u00e9rencient rapidement les outils :<\/p>\n<ul>\n<li>Qui poss\u00e8de vos emplacements de contr\u00f4le \u2014 vos propres n\u0153uds, des installations de transporteurs, ou des r\u00e9gions lou\u00e9es chez AWS, Azure ou Google Cloud ?<\/li>\n<li>Le contr\u00f4le utilise-t-il un vrai navigateur ou un client HTTP, et que change cela dans ce qui est d\u00e9tect\u00e9 ?<\/li>\n<li>Comment surveillez-vous un point de terminaison n\u00e9cessitant OAuth ou SSO ?<\/li>\n<li>Combien d&#8217;emplacements doivent \u00e9chouer avant que vous alertiez, et ce param\u00e8tre est-il r\u00e9glable ?<\/li>\n<li>Combien de temps conservez-vous les r\u00e9sultats bruts des contr\u00f4les, et puis-je les exporter ?<\/li>\n<li>\u00c0 quoi ressemblerait la facture si je double mes contr\u00f4les et divise par deux mon intervalle ?<\/li>\n<\/ul>\n<p>Pour le processus de s\u00e9lection \u00e9largi \u2014 stabilit\u00e9 du fournisseur, support, conditions contractuelles \u2014 nous en avons fait un guide s\u00e9par\u00e9 dans nos <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/fr\/lignes-directrices-pour-le-choix-dune-plate-forme-de-surveillance\/\">lignes directrices pour choisir une plateforme de surveillance<\/a>.<\/p>\n<h2 id='le-point-sur-la-surveillance-d-infrastructure-cloud'  id=\"boomdevs_13\" id=\"the-bottom-line-on-cloud-infrastructure-monitoring\">Le point sur la surveillance d&#8217;infrastructure cloud<\/h2>\n<p>Gardez la surveillance de votre fournisseur. C\u2019est le meilleur outil que vous avez pour le diagnostic au niveau ressources, il est d\u00e9j\u00e0 d\u00e9ploy\u00e9, et les m\u00e9triques de base sont incluses avec le compute. Surveillez la facture des m\u00e9triques personnalis\u00e9es, des logs et de la r\u00e9tention, mais conservez-le.<\/p>\n<p>Ne le faites simplement pas devenir votre d\u00e9tecteur de panne. Il rapporte depuis l\u2019int\u00e9rieur du syst\u00e8me qu\u2019il surveille, et les m\u00e9triques par d\u00e9faut ne peuvent pas voir le chemin r\u00e9seau, la r\u00e9solution DNS publique, le certificat en p\u00e9riph\u00e9rie, ou le parcours de connexion dont d\u00e9pendent vos clients. Ce sont les pannes qui arrivent en premier dans votre file de support.<\/p>\n<p>L\u2019\u00e9valuation qui fonctionne est courte : listez vos incidents r\u00e9els, testez les candidats contre ces pannes, cassez quelque chose pendant l\u2019essai, \u00e9valuez la configuration que vous utiliserez r\u00e9ellement. Un outil qui aurait d\u00e9tect\u00e9 vos cinq derni\u00e8res pannes cinq minutes plus t\u00f4t s\u2019est d\u00e9j\u00e0 pay\u00e9.<\/p>\n<section class=\"final-cta\">\n<h2 id='d\u00e9couvrez-ce-que-d\u00e9tectent-les-contr\u00f4les-externes'  id=\"boomdevs_14\">D\u00e9couvrez ce que d\u00e9tectent les contr\u00f4les externes<\/h2>\n<p>Dotcom-Monitor ex\u00e9cute des contr\u00f4les en vrai navigateur et protocolaires contre votre infrastructure cloud depuis un r\u00e9seau mondial d\u2019emplacements, plus des agents priv\u00e9s pour tout ce qui est derri\u00e8re votre pare-feu. Lancez un essai gratuit et pointez un contr\u00f4le vers le service dont vous doutez le plus.<\/p>\n<p><a href=\"https:\/\/www.dotcom-monitor.com\/fr\/solutions\/surveillance-infrastructure\/\">Explorez la surveillance d&#8217;infrastructure<\/a> ou <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/produits-de-surveillance\/surveillance-des-applications-web\/\">la surveillance d\u2019applications web<\/a>.<\/p>\n<\/section>\n","protected":false},"excerpt":{"rendered":"<p>La surveillance de votre fournisseur de cloud s&#8217;ex\u00e9cute \u00e0 l&#8217;int\u00e9rieur du domaine de d\u00e9faillance qu&#8217;elle surveille. Voici ce qu&#8217;il faut tester avant de choisir un outil de surveillance.<\/p>\n","protected":false},"author":39,"featured_media":34521,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3446],"tags":[],"class_list":["post-34534","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-non-classifiee"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/34534","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/comments?post=34534"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/34534\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media\/34521"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media?parent=34534"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/categories?post=34534"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/tags?post=34534"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}