{"id":22386,"date":"2021-11-16T17:12:38","date_gmt":"2021-11-16T17:12:38","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2021\/11\/16\/principes-sre-les-7-regles-fondamentales\/"},"modified":"2026-08-27T21:25:14","modified_gmt":"2026-08-27T21:25:14","slug":"principes-sre-les-7-regles-fondamentales","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/principes-sre-les-7-regles-fondamentales\/","title":{"rendered":"Principes SRE : Les 7 r\u00e8gles fondamentales"},"content":{"rendered":"<figure id=\"attachment_34573\" aria-describedby=\"caption-attachment-34573\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img fetchpriority=\"high\" decoding=\"async\" class=\"size-full wp-image-34573\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/hero-sre-principles-outside-google.webp\" alt=\"Illustration d'une pile web o\u00f9 l'\u00e9quipe poss\u00e8de le noyau de l'application mais d\u00e9pend de services externes CDN, DNS, paiement, et auth\" width=\"1200\" height=\"800\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/hero-sre-principles-outside-google.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/hero-sre-principles-outside-google-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/hero-sre-principles-outside-google-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/hero-sre-principles-outside-google-768x512.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34573\" class=\"wp-caption-text\">Le livre Google SRE suppose que vous poss\u00e9dez toute la pile. Une grande partie de ce que vos utilisateurs vivent fonctionne sur une infrastructure qui ne vous appartient pas.<\/figcaption><\/figure>\n<p>Les sept principes SRE viennent d\u2019une entreprise qui poss\u00e8de ses centres de donn\u00e9es, son r\u00e9seau, ses \u00e9quilibreurs de charge et chaque ligne de code entre les deux. Votre pile ne ressemble probablement pas \u00e0 \u00e7a. Une bonne partie de ce que vos utilisateurs exp\u00e9rimentent tourne sur une infrastructure dans laquelle vous ne pouvez pas SSH : un CDN, un fournisseur d\u2019authentification, une passerelle de paiement, DNS, un gestionnaire de tags, une API partenaire.<\/p>\n<p>Cet \u00e9cart est important, car les principes s\u2019appliquent toujours en dehors de Google. Mais plusieurs d\u2019entre eux changent de forme d\u00e8s lors que le composant en panne n\u2019est pas le v\u00f4tre \u00e0 r\u00e9parer. Un budget d\u2019erreur se comporte diff\u00e9remment lorsqu\u2019un tiers de ce budget est consomm\u00e9 par une panne d\u2019un autre. Les quatre signaux d\u2019or sont diff\u00e9rents vus de l\u2019ext\u00e9rieur du pare-feu par rapport \u00e0 l\u2019int\u00e9rieur. Et le risque que vous ne pouvez pas \u00e9liminer par l\u2019ing\u00e9nierie, vous devez le mesurer.<\/p>\n<p>Cet article passe en revue les sept principes tels que d\u00e9finis dans le <a href=\"https:\/\/sre.google\/sre-book\/table-of-contents\/\" target=\"_blank\" rel=\"noopener\">livre SRE de Google<\/a>, puis ajoute ce que le livre oublie : \u00e0 quoi ressemble chaque principe quand vous d\u00e9pendez de services que vous ne contr\u00f4lez pas. Si vous \u00eates novice dans ce r\u00f4le, commencez par <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/fr\/quest-ce-quun-ingenieur-en-fiabilite-de-site-sre\/\">ce que fait un ing\u00e9nieur fiabilit\u00e9 site<\/a> et revenez ensuite.<\/p>\n<h2 id='quels-sont-les-principes-sre'  id=\"boomdevs_1\" id=\"what-are-the-sre-principles\">Quels sont les principes SRE ?<\/h2>\n<p>Les principes SRE sont les r\u00e8gles de travail que Google a codifi\u00e9es pour faire fonctionner des syst\u00e8mes fiables \u00e0 grande \u00e9chelle : adopter et g\u00e9rer le risque, les objectifs de niveau de service, \u00e9liminer le travail fastidieux, le monitoring, l\u2019automatisation, l\u2019ing\u00e9nierie des mises en production, et la simplicit\u00e9. Ensemble, ils r\u00e9pondent \u00e0 une question : \u00e0 quel niveau de fiabilit\u00e9 ce service doit-il fonctionner, et quelle est la mani\u00e8re la moins co\u00fbteuse et durable d\u2019y parvenir ?<\/p>\n<p>La liste n\u2019a pas chang\u00e9 depuis la publication du livre SRE en 2016. Ce qui a chang\u00e9, c\u2019est la pile moyenne. Microservices, d\u00e9pendances SaaS, et scripts tiers signifient qu\u2019une partie de votre fiabilit\u00e9 est maintenant dans les mains d\u2019autres entreprises. Chaque section ci-dessous couvre le principe tel qu\u2019\u00e9crit, puis ce qui foire quand la d\u00e9pendance n\u2019est pas la v\u00f4tre. En fin, une liste courte des meilleures pratiques SRE tir\u00e9es des sept.<\/p>\n<h2 id='principe-1-adopter-et-g\u00e9rer-le-risque'  id=\"boomdevs_2\" id=\"principle-1-embracing-and-managing-risk\">Principe 1 &#8211; Adopter et g\u00e9rer le risque<\/h2>\n<p>La formulation Google : viser une fiabilit\u00e9 \u00e0 100 % est une erreur. Les utilisateurs vous atteignent par des r\u00e9seaux et appareils qui tombent en panne naturellement, donc au-del\u00e0 d\u2019un certain point, obtenir plus de &#8220;neuf&#8221; co\u00fbte cher et personne ne voit la diff\u00e9rence. Choisissez un objectif de fiabilit\u00e9 d\u00e9fendable par l\u2019entreprise, et traitez l\u2019\u00e9cart entre cet objectif et la perfection comme un budget \u00e0 d\u00e9penser pour livrer des fonctionnalit\u00e9s. Le <a href=\"https:\/\/sre.google\/sre-book\/embracing-risk\/\" target=\"_blank\" rel=\"noopener\">chapitre Adopter le risque<\/a> explique cela en d\u00e9tail.<\/p>\n<p>Chez Google, cela fonctionne car le risque est un bouton qu\u2019ils peuvent tourner. Plus de r\u00e9plications, plus de redondance, d\u00e9ploiements plus lents : d\u00e9pensez de l\u2019argent, obtenez plus de &#8220;neuf&#8221;.<\/p>\n<p>En dehors de Google, une partie de ce bouton n\u2019est reli\u00e9e \u00e0 rien. Vous ne pouvez pas ajouter une r\u00e9plique \u00e0 votre passerelle de paiement. Vous ne pouvez pas r\u00e9gler le comportement de basculement de votre fournisseur DNS. Leur fiabilit\u00e9 est une clause contractuelle, pas un param\u00e8tre d\u2019ing\u00e9nierie.<\/p>\n<p>Le principe change donc de forme : pour les composants que vous poss\u00e9dez, g\u00e9rez le risque par l\u2019ing\u00e9nierie. Pour ceux que vous ne poss\u00e9dez pas, g\u00e9rez-le par la mesure. Vous devez conna\u00eetre la disponibilit\u00e9 r\u00e9elle de votre fournisseur d\u2019authentification telle que mesur\u00e9e depuis le c\u00f4t\u00e9 internet de vos utilisateurs, pas le chiffre de leur page de statut. Les pages de statut affichent souvent du vert lors de pannes partielles, et une d\u00e9pendance qui fonctionne dans son propre centre de donn\u00e9es peut \u00eatre injoignable depuis le v\u00f4tre. La mesure ind\u00e9pendante transforme un soup\u00e7on de &#8220;le CDN est instable&#8221; en une discussion de renouvellement appuy\u00e9e par des donn\u00e9es. C\u2019est le premier travail que fait Dotcom-Monitor ici : mettre une v\u00e9rification externe sur chaque d\u00e9pendance critique. Une <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/produits-de-surveillance\/outil-de-surveillance-dns-dotcom-monitor\/\">v\u00e9rification DNS<\/a> vers les serveurs de noms du fournisseur, une v\u00e9rification HTTP(S) en bout de CDN, une <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/produits-de-surveillance\/surveillance-api\/web-api-monitoring\/\">v\u00e9rification API<\/a> vers la passerelle de paiement. Chacune construit son propre historique de disponibilit\u00e9 et temps de r\u00e9ponse depuis un r\u00e9seau mondial. Et l\u00e0 o\u00f9 les chiffres le justifient, contournez le risque : un second fournisseur DNS, un chemin de paiement de repli, une copie mise en cache du script tiers.<\/p>\n<h3 id='comment-mettre-en-\u0153uvre-la-gestion-du-risque'  id=\"boomdevs_3\">Comment mettre en \u0153uvre la gestion du risque<\/h3>\n<ul>\n<li>Listez chaque d\u00e9pendance touch\u00e9e par une requ\u00eate utilisateur (DNS, CDN, auth, paiements, tags tiers) et indiquez celles que vous pouvez ing\u00e9nier et celles que vous ne pouvez qu\u2019\u00e9valuer par la mesure.<\/li>\n<li>Cr\u00e9ez un dispositif Dotcom-Monitor pour chaque d\u00e9pendance mesurable seulement : une t\u00e2che DNS pointant vers les serveurs de noms du fournisseur, une t\u00e2che HTTP(S) en bordure CDN, une t\u00e2che web services contre le point de terminaison paiement ou authentification.<\/li>\n<li>Ex\u00e9cutez ces v\u00e9rifications de plusieurs emplacements dans les r\u00e9gions de vos utilisateurs, pour qu\u2019une panne r\u00e9gionale chez le fournisseur ne puisse masquer une autre r\u00e9gion en bonne sant\u00e9.<\/li>\n<li>Apportez chaque rapport de disponibilit\u00e9 dans la discussion avec le fournisseur, et ajoutez des chemins de repli (DNS secondaire, voie de paiement de secours) l\u00e0 o\u00f9 les donn\u00e9es montrent que le risque justifie le co\u00fbt.<\/li>\n<\/ul>\n<h2 id='principe-2-objectifs-de-niveau-de-service-sla-slo-sli'  id=\"boomdevs_4\" id=\"principle-2-service-level-objectives-sla-slo-sli\">Principe 2 &#8211; Objectifs de niveau de service (SLA, SLO, SLI)<\/h2>\n<p>Trois termes sont souvent confondus, voici la distinction :<\/p>\n<ul>\n<li><strong>SLA (Service Level Agreement \/ Accord de niveau de service) :<\/strong> le contrat. Ce que vous promettez aux clients, avec des p\u00e9nalit\u00e9s en cas de manquement.<\/li>\n<li><strong>SLO (Service Level Objective \/ Objectif de niveau de service) :<\/strong> la cible fix\u00e9e pour un indicateur de niveau de service, souvent interne et plus stricte que le SLA pour d\u00e9clencher vos alertes avant de violer le contrat. Par exemple, 99,9 % de disponibilit\u00e9, finaliser un achat en moins de 3 secondes, ce genre d\u2019objectif.<\/li>\n<li><strong>SLI (Service Level Indicator \/ Indicateur de niveau de service) :<\/strong> la mesure en elle-m\u00eame. Le chiffre r\u00e9el de disponibilit\u00e9, le temps de r\u00e9ponse observ\u00e9, le taux d\u2019erreur mesur\u00e9.<\/li>\n<\/ul>\n<p>Le SLI mesure, le SLO cible, le SLA promet. Tout ce qui d\u00e9coule, y compris les <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/fonctionnalites\/uptime-and-sla-reports\/\">rapports de disponibilit\u00e9 et SLA<\/a> remis au client, d\u00e9pend de la fiabilit\u00e9 du SLI.<\/p>\n<p>C\u2019est l\u00e0 que la plupart des \u00e9quipes ont un angle mort : le budget d\u2019erreur n\u2019est pr\u00e9cis qu\u2019au niveau de la mesure qui le soutient. Si vos v\u00e9rifications tournent toutes les 5 minutes, chaque panne enregistr\u00e9e a un d\u00e9but et une fin connus seulement \u00e0 +\/- 5 minutes, et les pannes plus courtes que cet intervalle peuvent se terminer sans jamais \u00eatre vues. Voici ce que cela donne pour un budget d\u2019erreur mensuel \u00e0 travers diff\u00e9rents objectifs SLO, sur un mois de 30 jours (43 200 minutes) :<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>SLO mensuel<\/th>\n<th>Budget d&#8217;erreur (mois de 30 jours)<\/th>\n<th>Plus petite panne d\u00e9tect\u00e9e avec certitude par une v\u00e9rif. 5 min<\/th>\n<th>Une quantique de 5 minutes en % du budget<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>99,0 %<\/td>\n<td>7h 12m (432 min)<\/td>\n<td>5 min<\/td>\n<td>1,2 %<\/td>\n<\/tr>\n<tr>\n<td>99,5 %<\/td>\n<td>3h 36m (216 min)<\/td>\n<td>5 min<\/td>\n<td>2,3 %<\/td>\n<\/tr>\n<tr>\n<td>99,9 %<\/td>\n<td>43m 12s (43,2 min)<\/td>\n<td>5 min<\/td>\n<td>11,6 %<\/td>\n<\/tr>\n<tr>\n<td>99,95 %<\/td>\n<td>21m 36s (21,6 min)<\/td>\n<td>5 min<\/td>\n<td>23,1 %<\/td>\n<\/tr>\n<tr>\n<td>99,99 %<\/td>\n<td>4m 19s (4,32 min)<\/td>\n<td>5 min<\/td>\n<td><strong>116 %, plus que tout le budget<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<blockquote><p>Vous ne pouvez pas mesurer un SLO mensuel \u00e0 99,99 % avec des v\u00e9rifications toutes les 5 minutes. Une seule intervalle de v\u00e9rification d\u00e9passe tout votre budget mensuel.<\/p><\/blockquote>\n<p>Les probabilit\u00e9s sont aussi impitoyables. Avec un intervalle de v\u00e9rification de <em>I<\/em> minutes, une panne al\u00e9atoire durant <em>D<\/em> minutes (o\u00f9 <em>D<\/em> est plus courte que <em>I<\/em>) est d\u00e9tect\u00e9e avec une probabilit\u00e9 approximative de <em>D\/I<\/em>, en supposant que le d\u00e9but de panne est ind\u00e9pendant du planning des v\u00e9rifications. Donc une panne de 4 minutes contre un intervalle de 5 minutes est d\u00e9tect\u00e9e environ 4 fois sur 5, et le 1 sur 5 restant correspond \u00e0 une panne qui tombe enti\u00e8rement entre deux v\u00e9rifications et n\u2019est jamais enregistr\u00e9e. Pour les pannes plus longues que l\u2019intervalle, le d\u00e9lai moyen de d\u00e9tection est d\u2019environ la moiti\u00e9 de l\u2019intervalle, donc 5 minutes d\u2019intervalle ajoutent en moyenne 2,5 minutes avant que quelqu\u2019un ne sache.<\/p>\n<p>Un avertissement : ce tableau suppose une seule v\u00e9rification planifi\u00e9e et une comptabilisation du temps d\u2019arr\u00eat bas\u00e9e sur l\u2019intervalle. La confirmation multi-locale et les SLI bas\u00e9s sur les requ\u00eates changent les d\u00e9tails, mais pas le probl\u00e8me d\u2019\u00e9chantillonnage.<\/p>\n<figure id=\"attachment_34580\" aria-describedby=\"caption-attachment-34580\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img decoding=\"async\" class=\"size-full wp-image-34580\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/error-budget-check-interval.webp\" alt=\"Graphique montrant qu\u2019un intervalle de v\u00e9rification de 5 minutes consomme une part croissante du budget d\u2019erreur mensuel \u00e0 mesure que les objectifs SLO deviennent plus stricts de 99% \u00e0 99,99%\" width=\"1200\" height=\"675\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/error-budget-check-interval.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/error-budget-check-interval-300x169.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/error-budget-check-interval-1024x576.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/error-budget-check-interval-768x432.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34580\" class=\"wp-caption-text\">\u00c0 mesure que le SLO se resserre, un intervalle de v\u00e9rification engloutit une part croissante du budget. \u00c0 99,99 %, il d\u00e9passe enti\u00e8rement le budget.<\/figcaption><\/figure>\n<p>Les pannes courtes ne sont pas un cas marginal non plus. Parmi les pannes d\u00e9tect\u00e9es par Dotcom-Monitor, environ 38 % se r\u00e9solvent en moins de 5 minutes. Ce sont principalement des fluctuations de routage r\u00e9seau, des red\u00e9marrages, relances, et basculements qui se corrigent avant qu\u2019une intervention humaine soit possible, et notre filtre de r\u00e9ponse retarde l\u2019alerte pour cette raison exacte. Mais \u00eatre filtr\u00e9 des alertes ne signifie pas \u00eatre filtr\u00e9 de l\u2019enregistrement : ce temps d\u2019arr\u00eat compte toujours contre le SLA, quel qu\u2019il soit, et doit \u00eatre comptabilis\u00e9. Parmi les pannes qui g\u00e9n\u00e8rent une alerte, plus de 56 % se r\u00e9solvent dans les 15 minutes suivant la premi\u00e8re notification, environ 18 % d\u00e9passent l\u2019heure, et environ 3 % s\u2019\u00e9talent au-del\u00e0 de 24 heures. La proportion varie l\u00e9g\u00e8rement selon les types de services, mais la forme reste : plus d\u2019un tiers des pannes se situent dans la tranche que les v\u00e9rifications 5 minutes voient \u00e0 peine. C\u2019est pour cela que la fr\u00e9quence de v\u00e9rification est une d\u00e9cision de mesure, pas simplement financier : \u00e0 des intervalles de 1 minute, la quantique de mesure tombe \u00e0 2,3 % d\u2019un budget mensuel \u00e0 99,9 % au lieu de 11,6 %, et les pannes courtes qui dominent les comptes d\u2019incidents commencent \u00e0 appara\u00eetre dans vos registres. C\u2019est pourquoi Dotcom-Monitor ex\u00e9cute des v\u00e9rifications parfois toutes les minutes et construit ses rapports SLA sur ces m\u00eames donn\u00e9es : le chiffre de conformit\u00e9 que vous montrez \u00e0 un client n\u2019est fiable que dans la mesure o\u00f9 l\u2019\u00e9chantillonnage derri\u00e8re l\u2019est.<\/p>\n<h3 id='comment-mettre-en-\u0153uvre-les-objectifs-de-niveau-de-service'  id=\"boomdevs_5\">Comment mettre en \u0153uvre les objectifs de niveau de service<\/h3>\n<ul>\n<li>D\u00e9finissez deux ou trois SLI que vos utilisateurs reconna\u00eetraient, comme la disponibilit\u00e9 mesur\u00e9e depuis un vrai navigateur ou le temps de finalisation d\u2019achat, et faites d\u2019une v\u00e9rification Dotcom-Monitor la source officielle pour chacun.<\/li>\n<li>Fixez chaque SLO plus strict que le SLA qu\u2019il prot\u00e8ge, puis ajustez la fr\u00e9quence de v\u00e9rification de l\u2019appareil en cons\u00e9quence : selon le tableau ci-dessus, tout au-del\u00e0 de 99,9 % n\u00e9cessite des v\u00e9rifications \u00e0 1 minute.<\/li>\n<li>Programmez les rapports de disponibilit\u00e9 et SLA vers les personnes responsables de la conversation SLA, pour que le chiffre de conformit\u00e9 provienne du m\u00eame registre que les alertes.<\/li>\n<li>Convenir en amont de ce qui se passe lorsque le budget d\u2019erreur est \u00e9puis\u00e9, pendant qu\u2019aucun incident pr\u00e9cis n\u2019est en d\u00e9bat.<\/li>\n<\/ul>\n<h2 id='principe-3-\u00e9liminer-le-travail-r\u00e9p\u00e9titif-toil'  id=\"boomdevs_6\" id=\"principle-3-eliminate-toil\">Principe 3 &#8211; \u00c9liminer le travail r\u00e9p\u00e9titif (toil)<\/h2>\n<p>Le travail r\u00e9p\u00e9titif est tout travail manuel, r\u00e9p\u00e9titif, qui cro\u00eet avec la taille du service et ne produit aucune valeur durable. Le <a href=\"https:\/\/sre.google\/sre-book\/eliminating-toil\/\" target=\"_blank\" rel=\"noopener\">chapitre \u00c9liminer le travail r\u00e9p\u00e9titif<\/a> fixe une limite c\u00e9l\u00e8bre : les SRE ne devraient pas y passer plus de la moiti\u00e9 de leur temps, le reste \u00e9tant consacr\u00e9 \u00e0 des travaux d\u2019ing\u00e9nierie qui font dispara\u00eetre ce travail r\u00e9p\u00e9titif.<\/p>\n<p>Les d\u00e9finitions abstraites rendent le travail r\u00e9p\u00e9titif facile \u00e0 reconna\u00eetre mais difficile \u00e0 identifier pr\u00e9cis\u00e9ment. Alors nommez-le. Dans la plupart des \u00e9quipes, il ressemble \u00e0 \u00e7a :<\/p>\n<ul>\n<li>Quelqu\u2019un se connecte chaque matin pour v\u00e9rifier que le parcours d\u2019achat fonctionne toujours.<\/li>\n<li>Quelqu\u2019un teste manuellement le formulaire d\u2019inscription apr\u00e8s chaque d\u00e9ploiement.<\/li>\n<li>Quelqu\u2019un garde un rappel de calendrier pour les dates d\u2019expiration des certificats SSL.<\/li>\n<li>Quelqu\u2019un teste manuellement une API partenaire quand les tickets support explosent, pour v\u00e9rifier si le probl\u00e8me est chez vous ou chez eux.<\/li>\n<\/ul>\n<p>Chacun d\u2019eux est une transaction script\u00e9e en attente d\u2019\u00eatre \u00e9crite, et c\u2019est l\u00e0 que Dotcom-Monitor montre sa valeur directe. Un script enregistr\u00e9 avec <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/fonctionnalites\/everystep\/\">EveryStep<\/a>, son enregistreur de transactions en point-clic, suit r\u00e9guli\u00e8rement ce parcours d\u2019achat depuis un vrai navigateur et d\u00e9clenche une alerte d\u00e8s qu\u2019une \u00e9tape \u00e9choue. Ses v\u00e9rifications de certificats scrutent les dates d\u2019expiration sans calendrier. Ses v\u00e9rifications API appellent r\u00e9guli\u00e8rement le point de terminaison partenaire et conservent l\u2019historique des temps de r\u00e9ponse qui tranche d\u2019un coup d\u2019\u0153il l\u2019argument &#8220;c\u2019est nous ou eux&#8221;.<\/p>\n<p>Le crit\u00e8re de ce qu\u2019on automatise en premier n\u2019est pas la sophistication, mais la r\u00e9currence. La v\u00e9rification qu\u2019un humain fait tous les jours est celle que la machine doit faire toutes les minutes.<\/p>\n<h3 id='comment-mettre-en-\u0153uvre-l-\u00e9limination-du-travail-r\u00e9p\u00e9titif'  id=\"boomdevs_7\">Comment mettre en \u0153uvre l\u2019\u00e9limination du travail r\u00e9p\u00e9titif<\/h3>\n<ul>\n<li>Gardez une trace hebdomadaire de toutes les v\u00e9rifications manuelles sur l\u2019\u00e9quipe ; c\u2019est la r\u00e9currence, pas la difficult\u00e9, qui d\u00e9cide ce qu\u2019on automatise en premier.<\/li>\n<li>Enregistrez la plus fr\u00e9quente comme script EveryStep en parcourant le flux une fois, puis laissez-la tourner toutes les quelques minutes au lieu d\u2019une fois par jour.<\/li>\n<li>Remplacez le calendrier d\u2019expiration des certificats par les v\u00e9rifications SSL Dotcom-Monitor, et placez les API partenaires sous surveillance programm\u00e9e pour qu\u2019aucune ne d\u00e9pende de la m\u00e9moire d\u2019une personne.<\/li>\n<li>Suivez le nombre d\u2019heures de v\u00e9rification manuelle \u00e9limin\u00e9es chaque trimestre, afin que le travail d\u2019automatisation reste visible et financ\u00e9.<\/li>\n<\/ul>\n<h2 id='principe-4-monitoring-et-les-quatre-signaux-d-or'  id=\"boomdevs_8\" id=\"principle-4-monitoring-and-the-four-golden-signals\">Principe 4 &#8211; Monitoring et les quatre signaux d\u2019or<\/h2>\n<p>Le <a href=\"https:\/\/sre.google\/sre-book\/monitoring-distributed-systems\/\" target=\"_blank\" rel=\"noopener\">chapitre sur le Monitoring des syst\u00e8mes distribu\u00e9s<\/a> nomme quatre signaux d\u2019or : latence, trafic, erreurs, saturation. Surveillez-les et vous attraperez la plupart des probl\u00e8mes.<\/p>\n<p>Le chapitre mentionne le monitoring &#8220;black-box&#8221; (bo\u00eete noire), mais la plupart des \u00e9quipes instrumentent les quatre signaux depuis l\u2019int\u00e9rieur du syst\u00e8me. Surveillez-les depuis l\u2019endroit o\u00f9 se trouvent vos utilisateurs, et trois des quatre changent :<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Signal<\/th>\n<th>Int\u00e9rieur (APM, Prometheus, m\u00e9triques serveur)<\/th>\n<th>Ext\u00e9rieur (v\u00e9rifications synth\u00e9tiques externes)<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Latence<\/strong><\/td>\n<td>Temps applicatif et base de donn\u00e9es. Exclut tout ce qui arrive avant que la requ\u00eate atteigne vos serveurs.<\/td>\n<td>DNS + TCP + TLS + bord CDN + transfert + rendu. Le chiffre tel que ressenti par l\u2019utilisateur.<\/td>\n<\/tr>\n<tr>\n<td><strong>Trafic<\/strong><\/td>\n<td>Requ\u00eates par seconde, enti\u00e8rement visibles.<\/td>\n<td>Non observable de l\u2019ext\u00e9rieur. Une v\u00e9rification synth\u00e9tique g\u00e9n\u00e8re son propre trafic ; elle ne voit pas le v\u00f4tre.<\/td>\n<\/tr>\n<tr>\n<td><strong>Erreurs<\/strong><\/td>\n<td>Taux 5xx, compte d\u2019exceptions.<\/td>\n<td>Le HTTP 200 qui renvoie une page d\u2019achat cass\u00e9e. Le script tiers qui a \u00e9chou\u00e9 silencieusement. L\u2019\u00e9l\u00e9ment de page qui n\u2019a jamais rendu.<\/td>\n<\/tr>\n<tr>\n<td><strong>Saturation<\/strong><\/td>\n<td>CPU, m\u00e9moire, profondeur de file, pools de connexion.<\/td>\n<td>Non mesurable directement. Inf\u00e9r\u00e9e \u00e0 partir de la d\u00e9gradation de la latence quand la charge augmente.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<figure id=\"attachment_34587\" aria-describedby=\"caption-attachment-34587\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img decoding=\"async\" class=\"size-full wp-image-34587\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/golden-signals-inside-vs-outside.webp\" alt=\"Diagramme des quatre signaux d\u2019or par point de vue, montrant quels signaux sont visibles de l\u2019int\u00e9rieur de la pile versus depuis le monitoring synth\u00e9tique externe\" width=\"1200\" height=\"900\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/golden-signals-inside-vs-outside.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/golden-signals-inside-vs-outside-300x225.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/golden-signals-inside-vs-outside-1024x768.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/golden-signals-inside-vs-outside-768x576.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34587\" class=\"wp-caption-text\">Deux des quatre signaux d\u2019or sont pleinement visibles uniquement depuis un c\u00f4t\u00e9. Aucun point de vue ne voit tout.<\/figcaption><\/figure>\n<p>Lisez honn\u00eatement le tableau et la conclusion n\u2019est pas que l\u2019ext\u00e9rieur est meilleur. C\u2019est que ni l\u2019un ni l\u2019autre ne voient tout. Le trafic et la saturation appartiennent \u00e0 vos outils internes : Prometheus, Datadog, New Relic, quelle que soit votre pile APM. La latence telle que v\u00e9cue et les erreurs telles que v\u00e9cues appartiennent au <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/solutions\/synthetic-monitoring\/\">monitoring synth\u00e9tique externe<\/a>. C\u2019est la moiti\u00e9 couverte par Dotcom-Monitor. Les v\u00e9rifications en vrai navigateur depuis un r\u00e9seau global chargent vos pages comme le font les utilisateurs et mesurent tout le chemin : r\u00e9solution DNS, poign\u00e9e de main TLS, bord CDN, rendu de page, \u00e9tapes utilisateur script\u00e9es. Les v\u00e9rifications protocolaires HTTP(S), API, DNS, TCP, et ICMP surveillent les d\u00e9pendances autour de la page. Les deux ne s\u2019opposent pas ; ce sont des vues diff\u00e9rentes des m\u00eames quatre signaux, et vous avez besoin des deux.<\/p>\n<p>La r\u00e8gle pratique : chaque signal que vos utilisateurs peuvent ressentir doit avoir au moins une mesure prise depuis l\u00e0 o\u00f9 ils sont. Un tableau de bord APM affichant du vert pendant que le CDN sert des pages d\u2019erreur en cache \u00e0 la moiti\u00e9 de l\u2019Europe n\u2019est pas une hypoth\u00e8se. C\u2019est le mode d\u2019\u00e9chec standard du monitoring interne seul.<\/p>\n<h3 id='comment-mettre-en-\u0153uvre-le-monitoring'  id=\"boomdevs_9\">Comment mettre en \u0153uvre le monitoring<\/h3>\n<ul>\n<li>Gardez le trafic et la saturation sur votre pile APM ou Prometheus ; confiez la latence et les erreurs aux v\u00e9rifications Dotcom-Monitor en vrai navigateur op\u00e9rant depuis les r\u00e9gions o\u00f9 sont vos utilisateurs.<\/li>\n<li>Configurez des assertions de contenu sur ces v\u00e9rifications, pas seulement des contr\u00f4les de codes statut, pour que le parcours d\u2019achat cass\u00e9 derri\u00e8re un HTTP 200 \u00e9choue comme pour l\u2019utilisateur.<\/li>\n<li>Script les transactions importantes (connexion, recherche, achat) avec EveryStep, de sorte que le monitoring suive le m\u00eame chemin que vos utilisateurs.<\/li>\n<li>Comparez r\u00e9guli\u00e8rement les chiffres int\u00e9rieurs et ext\u00e9rieurs ; l\u2019\u00e9cart est votre couche CDN, DNS et tiers.<\/li>\n<\/ul>\n<h2 id='principe-5-automatisation'  id=\"boomdevs_10\" id=\"principle-5-automation\">Principe 5 &#8211; Automatisation<\/h2>\n<p>L\u2019argument SRE pour l\u2019automatisation est la coh\u00e9rence \u00e0 grande \u00e9chelle. Les humains oublient des \u00e9tapes, les machines non, et toute r\u00e9ponse devant se produire \u00e0 3h du matin ne devrait pas d\u00e9pendre d\u2019un humain alerte \u00e0 3h du matin.<\/p>\n<p>Ce qui change hors de Google : l\u2019automatisation n\u2019est efficace que si le signal qui la d\u00e9clenche est fiable. Scripts de basculement, jobs de rollback, r\u00e8gles d\u2019auto-scaling s\u2019activent sur un \u00e9v\u00e9nement de d\u00e9tection, donc chaque minute de retard d\u00e9tect\u00e9 allonge le temps avant la r\u00e9ponse automatis\u00e9e. Les calculs du chapitre SLO s\u2019appliquent directement : une bascule automatis\u00e9e d\u00e9clench\u00e9e par une v\u00e9rification toutes les 5 minutes donne en moyenne 2,5 minutes de d\u00e9lai avant r\u00e9ponse.<\/p>\n<p>Et certains d\u00e9clencheurs d\u2019automatisation ne peuvent venir que de l\u2019ext\u00e9rieur. Un script qui bascule vers un fournisseur de paiement de secours doit savoir que le principal \u00e9choue pour les utilisateurs, pas seulement que son endpoint de sant\u00e9 r\u00e9pond aux pings depuis le m\u00eame r\u00e9seau. Dotcom-Monitor boucle ce m\u00e9canisme en d\u00e9clenchant <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/fonctionnalites\/fonctionnalites-alertes\/\">alertes<\/a> et webhooks depuis ses v\u00e9rifications externes, pour que le basculement s\u2019active sur ce que vivent les utilisateurs, pas ce que dit l\u2019endpoint sant\u00e9.<\/p>\n<h3 id='comment-mettre-en-\u0153uvre-l-automatisation'  id=\"boomdevs_11\">Comment mettre en \u0153uvre l\u2019automatisation<\/h3>\n<ul>\n<li>Commencez par les r\u00e9ponses que vous effectuez d\u00e9j\u00e0 manuellement lors d\u2019incidents : red\u00e9marrages, basculements, rollbacks.<\/li>\n<li>Connectez les webhooks d\u2019alerte Dotcom-Monitor aux scripts qui les ex\u00e9cutent, pour que l\u2019activation soit une panne confirm\u00e9e depuis l\u2019ext\u00e9rieur et non un endpoint interne.<\/li>\n<li>Utilisez des groupes d\u2019escalade d\u2019alerte pour que la premi\u00e8re notification atteigne la personne ou syst\u00e8me qui agit, pas une bo\u00eete partag\u00e9e que personne ne surveille \u00e0 3h du matin.<\/li>\n<li>Laissez le filtre de r\u00e9ponse absorber les petits incidents auto-r\u00e9solus pour ne pas d\u00e9clencher vos automatisations, et revoyez trimestriellement les d\u00e9clencheurs en fonction des taux de faux positifs.<\/li>\n<\/ul>\n<h2 id='principe-6-ing\u00e9nierie-des-mises-en-production'  id=\"boomdevs_12\" id=\"principle-6-release-engineering\">Principe 6 &#8211; Ing\u00e9nierie des mises en production<\/h2>\n<p>L\u2019ing\u00e9nierie des mises en production est la discipline consistant \u00e0 construire et livrer des logiciels toujours de la m\u00eame mani\u00e8re : builds versionn\u00e9s, pipelines reproductibles, rollbacks qui fonctionnent car r\u00e9p\u00e9t\u00e9s.<\/p>\n<p>Le CI\/CD moderne couvre beaucoup de cela dans le pipeline. Tests valid\u00e9s, artefacts construits, d\u00e9ploiements derri\u00e8re des flags. Ce que le pipeline ne vous dit pas, c\u2019est si le syst\u00e8me fonctionne r\u00e9ellement pour les utilisateurs apr\u00e8s la mise en ligne. Le CI prouve la build ; seul, il ne dit rien du registre DNS non propag\u00e9, du cache CDN qui sert l\u2019ancienne version, du tag tiers cass\u00e9 en combinaison avec votre nouveau code, ou de la valeur de config qui existe uniquement en production.<\/p>\n<p>C\u2019est ce que la v\u00e9rification post-d\u00e9ploiement comble. Un script EveryStep qui parcourt le chemin critique (charger la page, se connecter, finaliser la transaction), ex\u00e9cut\u00e9 depuis le r\u00e9seau Dotcom-Monitor contre la production imm\u00e9diatement apr\u00e8s chaque mise en ligne, est le seul test r\u00e9el de ce que les utilisateurs obtiennent. Les \u00e9quipes qui l\u2019utilisent consid\u00e8rent cela comme la derni\u00e8re \u00e9tape du pipeline : d\u00e9ployer, v\u00e9rifier depuis l\u2019ext\u00e9rieur, et ensuite seulement marquer la mise en production comme r\u00e9ussie. Si la v\u00e9rification \u00e9choue, le rollback d\u00e9clenche pendant que l\u2019impact est encore mesur\u00e9 en minutes.<\/p>\n<h3 id='comment-mettre-en-\u0153uvre-l-ing\u00e9nierie-de-mise-en-production'  id=\"boomdevs_13\">Comment mettre en \u0153uvre l\u2019ing\u00e9nierie de mise en production<\/h3>\n<ul>\n<li>Versionnez chaque build et faites du rollback une action r\u00e9p\u00e9t\u00e9e et en une \u00e9tape plut\u00f4t qu\u2019improvis\u00e9e.<\/li>\n<li>Faites d\u2019une transaction EveryStep contre la production l\u2019\u00e9tape finale du pipeline de d\u00e9ploiement, lanc\u00e9e depuis le r\u00e9seau Dotcom-Monitor pour que DNS, cache CDN et tags tiers fassent partie du test.<\/li>\n<li>Dirigez le webhook d\u2019alerte de la v\u00e9rification vers le pipeline, pour que l\u2019\u00e9chec post-d\u00e9ploiement devienne un signal automatique de rollback, et non un ticket \u00e0 traiter le matin.<\/li>\n<li>Gardez la m\u00eame v\u00e9rification active entre les mises en ligne ; son historique est votre base de r\u00e9f\u00e9rence pour savoir si un d\u00e9ploiement a ralenti le syst\u00e8me.<\/li>\n<\/ul>\n<h2 id='principe-7-simplicit\u00e9'  id=\"boomdevs_14\" id=\"principle-7-simplicity\">Principe 7 &#8211; Simplicit\u00e9<\/h2>\n<p>Le <a href=\"https:\/\/sre.google\/sre-book\/simplicity\/\" target=\"_blank\" rel=\"noopener\">chapitre Simplicit\u00e9<\/a> soutient que fiabilit\u00e9 et complexit\u00e9 s\u2019opposent : chaque composant ajout\u00e9 est un composant susceptible de tomber en panne, et le logiciel doit \u00eatre exactement aussi complexe que la t\u00e2che le requiert.<\/p>\n<p>Appliquez cela \u00e0 la pile de monitoring elle-m\u00eame, car c\u2019est l\u00e0 que la complexit\u00e9 s\u2019accumule silencieusement. Les \u00e9quipes finissent avec un outil APM, une plateforme de logs, un uptime pinger, un service de page de statut, et trois tableaux de bord que personne n\u2019ouvre. Chaque outil alerte selon son propre timing, et le r\u00e9sultat cumul\u00e9 est la fatigue d\u2019alerte : tant de notifications que celles qui comptent sont noy\u00e9es.<\/p>\n<p>Un fournisseur de monitoring vous conseillant de r\u00e9duire vos outils est un argument inhabituel, mais justement c\u2019est pourquoi il m\u00e9rite d\u2019\u00eatre entendu. Le test de simplicit\u00e9 d\u2019une pile de monitoring pose deux questions. Premi\u00e8rement : pour chaque chose que vous surveillez, savez-vous quel outil est l\u2019autorit\u00e9 quand deux d\u2019entre eux ne sont pas d\u2019accord ? Deuxi\u00e8mement : chaque alerte a-t-elle une personne charg\u00e9e d\u2019agir dessus ? Si un outil ne r\u00e9pond pas aux deux questions pour tout ce qu\u2019il surveille, ce n\u2019est pas du monitoring, c\u2019est du bruit avec abonnement. Consolider <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/solutions\/disponibilite\/\">surveillance de disponibilit\u00e9<\/a>, transactions, API, et contr\u00f4le d\u2019infrastructure dans une seule plateforme avec un seul canal d\u2019alerte est d\u2019abord un choix de simplicit\u00e9, avant d\u2019\u00eatre un choix d\u2019achat. C\u2019est ainsi que Dotcom-Monitor est con\u00e7u : toutes ces v\u00e9rifications en un seul endroit, une seule voie d\u2019alerte, fonctionnant en parall\u00e8le avec l\u2019outil APM qui surveille l\u2019int\u00e9rieur, sans s\u2019y substituer.<\/p>\n<h3 id='comment-mettre-en-\u0153uvre-la-simplicit\u00e9'  id=\"boomdevs_15\">Comment mettre en \u0153uvre la simplicit\u00e9<\/h3>\n<ul>\n<li>Faites l\u2019inventaire de vos outils de monitoring et notez, pour chacun, ce dont il est l\u2019autorit\u00e9.<\/li>\n<li>Supprimez toute alerte sans propri\u00e9taire et sans action associ\u00e9e ; si personne ne r\u00e9agit, c\u2019est du bruit.<\/li>\n<li>Int\u00e9grez les v\u00e9rifications externes (disponibilit\u00e9, page, transaction, API, infrastructure) dans Dotcom-Monitor en une seule plateforme avec un seul canal d\u2019alerte, et laissez votre APM g\u00e9rer l\u2019int\u00e9rieur.<\/li>\n<li>R\u00e9p\u00e9tez l\u2019audit chaque ann\u00e9e ; les piles de monitoring regagnent de la complexit\u00e9 par elles-m\u00eames.<\/li>\n<\/ul>\n<h2 id='meilleures-pratiques-sre'  id=\"boomdevs_16\" id=\"sre-best-practices\">Meilleures pratiques SRE<\/h2>\n<p>Les principes indiquent l\u2019objectif \u00e0 atteindre. Voici les pratiques qui tiennent dans des \u00e9quipes ne poss\u00e9dant pas toute la pile :<\/p>\n<ul>\n<li><strong>Fixez les SLO sur ce que les utilisateurs vivent, pas ce que les serveurs rapportent.<\/strong> &#8220;Finalisation de l\u2019achat en moins de 4 secondes depuis un vrai navigateur&#8221; est un SLO que les utilisateurs reconna\u00eetraient. &#8220;API p95 sous 200 ms&#8221; est une donn\u00e9e d\u2019entr\u00e9e.<\/li>\n<li><strong>Adaptez la fr\u00e9quence des v\u00e9rifications \u00e0 votre SLO.<\/strong> D\u2019apr\u00e8s le tableau du budget d\u2019erreur ci-dessus : \u00e0 99,95 %, un quantum de 5 minutes consomme d\u00e9j\u00e0 23 % du budget mensuel, et \u00e0 99,99 %, il d\u00e9passe compl\u00e8tement le budget. Consid\u00e9rez les v\u00e9rifications \u00e0 1 minute comme plancher pratique \u00e0 partir de 99,95 %.<\/li>\n<li><strong>Surveillez vos d\u00e9pendances comme vous vous surveillez.<\/strong> DNS, CDN, paiement, auth : une v\u00e9rification externe par d\u00e9pendance critique, avec son propre historique de temps de r\u00e9ponse. Quand leur page de statut est verte et que vos utilisateurs disent &#8220;c\u2019est cass\u00e9&#8221;, ces donn\u00e9es tranchent le litige.<\/li>\n<li><strong>\u00c9crivez la politique de budget d\u2019erreur avant de d\u00e9penser le budget.<\/strong> Convenir \u00e0 l\u2019avance de ce qui arrive quand il est \u00e9puis\u00e9 : gel des fonctionnalit\u00e9s, sprints fiabilit\u00e9, priorit\u00e9s postmortem. Un budget sans politique est un graphique dont personne ne se sert.<\/li>\n<li><strong>R\u00e9p\u00e9tez les r\u00e9ponses aux incidents avant de les vivre.<\/strong> Astreinte, escalades, postmortems sans bl\u00e2me sont couverts en d\u00e9tail dans notre guide <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/fr\/sre-incident-management-overview-techniques-and-tools\/\">SRE incident management<\/a>.<\/li>\n<li><strong>Gardez le compte d\u2019outils honn\u00eate.<\/strong> Auditez la pile de monitoring chaque ann\u00e9e selon les deux questions de simplicit\u00e9 ci-dessus. Notre synth\u00e8se des <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/fr\/top-13-des-outils-dingenieur-en-fiabilite-de-site-sre\/\">outils SRE<\/a> couvre les cat\u00e9gories \u00e0 conserver.<\/li>\n<li><strong>Faites du reporting de fiabilit\u00e9 une habitude, pas une pr\u00e9cipitation.<\/strong> Rapports programm\u00e9s de disponibilit\u00e9 et SLA signifient que la conversation de conformit\u00e9 d\u00e9marre sur des chiffres partag\u00e9s et non une plong\u00e9e dans les logs apr\u00e8s litige.<\/li>\n<\/ul>\n<h2 id='en-r\u00e9sum\u00e9'  id=\"boomdevs_17\" id=\"the-bottom-line\">En r\u00e9sum\u00e9<\/h2>\n<p>Les sept principes SRE ont surv\u00e9cu au d\u00e9part de Google. Ce qui n\u2019a pas surv\u00e9cu est l\u2019hypoth\u00e8se sous-jacente : que l\u2019\u00e9quipe qui applique les principes contr\u00f4le la pile compl\u00e8te. Ce n\u2019est pas votre cas, et cela change le travail. Le risque que vous ne pouvez pas \u00e9liminer par l\u2019ing\u00e9nierie doit \u00eatre mesur\u00e9. Les budgets d\u2019erreur ne sont valables que dans la mesure o\u00f9 l\u2019intervalle de v\u00e9rification qui les soutient l\u2019est. L\u2019outillage interne g\u00e8re trafic et saturation ; la latence v\u00e9cue et les erreurs ne sont visibles que depuis un point de vue externe. La v\u00e9rification post-d\u00e9ploiement doit s\u2019ex\u00e9cuter de l\u2019ext\u00e9rieur, car c\u2019est le seul endroit o\u00f9 le syst\u00e8me complet existe.<\/p>\n<p>Le fil commun est la mesure depuis l\u2019ext\u00e9rieur. Chaque principe, appliqu\u00e9 \u00e0 une pile compos\u00e9e de composants que vous ne poss\u00e9dez pas, n\u00e9cessite une vue ind\u00e9pendante : v\u00e9rifications par d\u00e9pendance pour le risque, intervalles d\u2019une minute pour les budgets d\u2019erreur, vrais navigateurs pour les signaux d\u2019or, transactions script\u00e9es pour le travail r\u00e9p\u00e9titif et les mises en production, une plateforme unique pour la simplicit\u00e9. C\u2019est le r\u00f4le de Dotcom-Monitor sur les sept principes. Pas une pr\u00e9f\u00e9rence d\u2019outil \u2014 c\u2019est ce que les principes exigent d\u00e8s que la pile cesse d\u2019\u00eatre la v\u00f4tre.<\/p>\n<section class=\"final-cta\">\n<h2 id='mesurez-la-pile-que-vous-ne-poss\u00e9dez-pas'  id=\"boomdevs_18\" id=\"see-what-external-checks-catch\">Mesurez la pile que vous ne poss\u00e9dez pas<\/h2>\n<p>Ex\u00e9cutez des v\u00e9rifications en vrai navigateur \u00e0 intervalles d\u2019une minute depuis un r\u00e9seau mondial, et d\u00e9couvrez ce que votre budget d\u2019erreur manquait. <a href=\"https:\/\/userauth.dotcom-monitor.com\/Account\/FreeTrialSignUp?SolutionType=Monitoring\">Commencez un essai gratuit<\/a>.<\/p>\n<\/section>\n","protected":false},"excerpt":{"rendered":"<p>Les 7 principes SRE, r\u00e9\u00e9crits pour les \u00e9quipes qui ne poss\u00e8dent pas toute leur stack. Ce qui casse en dehors de Google, et ce qu&#8217;il faut mesurer \u00e0 la place.<\/p>\n","protected":false},"author":8,"featured_media":34575,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3446],"tags":[],"class_list":["post-22386","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\/22386","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\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/comments?post=22386"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/22386\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media\/34575"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media?parent=22386"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/categories?post=22386"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/tags?post=22386"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}