{"id":34314,"date":"2026-07-20T21:18:25","date_gmt":"2026-07-20T21:18:25","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/ipv6-monitoring\/"},"modified":"2026-07-24T21:32:18","modified_gmt":"2026-07-24T21:32:18","slug":"ipv6-monitoring","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/ipv6-monitoring\/","title":{"rendered":"Surveillance IPv6 avec Dotcom-Monitor : Trouvez les angles morts IPv6"},"content":{"rendered":"
\"Diagramme
Une v\u00e9rification IPv4 peut r\u00e9ussir alors que le chemin IPv6 vers le m\u00eame site est en panne.<\/figcaption><\/figure>\n

La plupart des sites fonctionnent d\u00e9sormais en dual-stack. Le m\u00eame serveur, API ou page de paiement r\u00e9pond simultan\u00e9ment en IPv4 et en IPv6. Cette configuration vous rend accessible alors que les adresses IPv4 se font rares, mais elle r\u00e9partit \u00e9galement votre trafic sur deux r\u00e9seaux qui peuvent tomber en panne ind\u00e9pendamment.<\/p>\n

Voici le probl\u00e8me que cela cr\u00e9e. Si votre surveillance ne teste que via IPv4, elle affiche du vert alors que les utilisateurs natifs IPv6 rencontrent une passerelle morte, un enregistrement DNS manquant ou une r\u00e8gle de pare-feu jamais mise \u00e0 jour. Le tableau de bord indique 100 % de disponibilit\u00e9. Une part croissante de votre audience affirme que le site est en panne.<\/p>\n

Cet article explique comment Dotcom-Monitor teste le chemin IPv6 selon ses propres termes : des n\u0153uds natifs IPv6-only sans tunnel, des scripts de navigateur qui chargent chaque ressource tierce via IPv6, et des contr\u00f4les de protocole qui isolent une d\u00e9faillance IPv6 tandis que le chemin IPv4 reste sain.<\/p>\n

Qu’est-ce que la surveillance IPv6 ?<\/h2>\n

La surveillance IPv6 consiste \u00e0 tester si votre site web, API et services r\u00e9pondent correctement en IPv6, du point de vue d\u2019un v\u00e9ritable utilisateur IPv6 natif. Elle effectue les m\u00eames v\u00e9rifications de disponibilit\u00e9 et de performance que vous utilisez d\u00e9j\u00e0 en IPv4 \u2014 r\u00e9solution DNS, chargement de pages, transactions et r\u00e9ponses de protocole \u2014 mais sur le chemin IPv6, qui dispose de ses propres enregistrements DNS, routes et r\u00e8gles de pare-feu.<\/p>\n

Sur un site dual-stack qui sert les deux protocoles, la surveillance IPv6 est la seule fa\u00e7on de confirmer que la partie IPv6 fonctionne. Un test IPv4 r\u00e9ussit que l\u2019IPv6 soit sain ou non, donc sans test d\u00e9di\u00e9 de surveillance r\u00e9seau IPv6, une panne touchant uniquement les utilisateurs IPv6 reste invisible. Les sections ci-dessous montrent comment Dotcom-Monitor effectue ce test depuis des n\u0153uds natifs IPv6-only, couvrant la disponibilit\u00e9, les transactions, DNS et contr\u00f4les de protocole sur les deux plans.<\/p>\n

Pourquoi les r\u00e9seaux dual-stack cr\u00e9ent un angle mort dans la surveillance<\/h2>\n

Un service dual-stack r\u00e9pond sur deux protocoles, mais IPv4 et IPv6 ne partagent pas un m\u00eame chemin. Ce sont deux plans de routage. Le trafic se r\u00e9sout via diff\u00e9rents enregistrements DNS, traverse diff\u00e9rentes r\u00e8gles de pare-feu et transite par diff\u00e9rents fournisseurs avant d\u2019atteindre la m\u00eame origine.<\/p>\n

Ainsi, une requ\u00eate peut r\u00e9ussir sur un plan et \u00e9chouer sur l\u2019autre. Le client IPv4 r\u00e9sout votre enregistrement A, franchit un pare-feu IPv4 configur\u00e9 depuis des ann\u00e9es par votre \u00e9quipe, et charge la page. Le client IPv6 r\u00e9sout votre enregistrement AAAA, tombe sur une passerelle jamais compl\u00e8tement configur\u00e9e, et expire. Les deux utilisateurs ont tap\u00e9 la m\u00eame URL. L\u2019un pense que votre site est en panne.<\/p>\n

Les deux plans diff\u00e8rent aussi en technologie. IPv6 utilise un en-t\u00eate de base fixe de 40 octets, un champ Traffic Class de 8 bits et un Flow Label de 20 bits, donc les routeurs transit traitent les paquets IPv6 diff\u00e9remment du mod\u00e8le IPv4 best-effort qu\u2019ils ont support\u00e9 pendant des d\u00e9cennies. Et un seul sous-r\u00e9seau IPv6 contient bien plus d\u2019adresses que tout l\u2019internet IPv4 legacy, ce qui modifie la propagation des routes et l\u2019application des filtres. L\u2019essentiel pour la surveillance est simple : un r\u00e9sultat IPv4 ne vous renseigne pas de fa\u00e7on fiable sur le chemin IPv6. Vous devez tester chacun sur son propre terrain.<\/p>\n

Comment Dotcom-Monitor r\u00e9alise une surveillance native IPv6-only<\/h2>\n

Dotcom-Monitor ex\u00e9cute ses contr\u00f4les depuis un r\u00e9seau mondial de surveillance<\/a> constitu\u00e9 de n\u0153uds sur de v\u00e9ritables backbones IPv4 et IPv6. Certains de ces n\u0153uds sont dual-stack et peuvent atteindre une cible via l\u2019un ou l\u2019autre protocole. D\u2019autres sont uniquement IPv6.<\/p>\n

Les localisations IPv6-only sont la partie importante ici, \u00e0 cause de ce qu\u2019elles refusent de faire. Une grande partie des \u00e9quipements r\u00e9seau qui supportent IPv6 peuvent aussi retranscrire le trafic en IPv4 via des m\u00e9canismes de transition comme le tunneling 6to4 ou NAT64. Cette traduction est pratique en production mais trompeuse en test. Un agent dual-stack peut rapporter un r\u00e9sultat propre tout en retombant silencieusement sur IPv4, ce qui masque la d\u00e9faillance exacte que vous cherchez \u00e0 d\u00e9tecter.<\/p>\n

Un n\u0153ud IPv6-only n\u2019utilise aucune traduction. Il n\u2019envoie et ne re\u00e7oit que du IPv6. Lorsqu\u2019un contr\u00f4le r\u00e9ussit depuis ce n\u0153ud, la cible a r\u00e9ellement r\u00e9pondu en IPv6 natif. Lorsqu\u2019il \u00e9choue, vous avez d\u00e9tect\u00e9 une vraie panne IPv6 au lieu d\u2019un report de secours.<\/p>\n

Ex\u00e9cuter le m\u00eame contr\u00f4le depuis un n\u0153ud natif IPv4 et un n\u0153ud natif IPv6-only vous donne un pr\u00e9alable et un post\u00e9rieur clairs pour chaque plan. Tout \u00e9cart entre les deux r\u00e9sultats est un probl\u00e8me sp\u00e9cifique \u00e0 IPv6, et non un bruit de mesure.<\/p><\/blockquote>\n

Cette base de r\u00e9f\u00e9rence fractionn\u00e9e fonctionne sur tous les types d\u2019appareils de la plateforme. La surveillance Web Applications pilote un v\u00e9ritable navigateur via une transaction script\u00e9e. La surveillance Web Pages charge une page unique de la m\u00eame mani\u00e8re. La surveillance Internet Infrastructure ex\u00e9cute des v\u00e9rifications de protocole contre vos serveurs. Et la surveillance Web Services valide vos API. Chacun peut \u00eatre assign\u00e9 \u00e0 des localisations IPv6-only, et les deux appareils navigateur enregistrent avec l\u2019outil de script EveryStep<\/a>, afin que vous capturiez un chemin une fois et le rejouiez depuis n\u2019importe quel n\u0153ud.<\/p>\n

D\u00e9tecter les fant\u00f4mes AAAA tiers avec une surveillance en vrai navigateur<\/h2>\n

Votre origine peut supporter parfaitement IPv6 et vos pages peuvent quand m\u00eame se casser pour les utilisateurs IPv6. La raison est tout ce que vous n\u2019h\u00e9bergez pas. Une page moderne fait appel \u00e0 un CDN, des polices web, une balise d\u2019analyse, un widget de chat et un processeur de paiement. Lorsqu\u2019un utilisateur IPv6-only charge cette page, le navigateur tente de r\u00e9cup\u00e9rer chacun de ces \u00e9l\u00e9ments aussi via IPv6.<\/p>\n

Si un tiers n\u2019a jamais publi\u00e9 d\u2019enregistrement AAAA ou laisse tomber les paquets IPv6, le navigateur reste bloqu\u00e9 sur cet \u00e9l\u00e9ment. Il attend que la connexion expire et peut retenir le reste du rendu en attendant. Le r\u00e9sultat visible est une page \u00e0 moiti\u00e9 charg\u00e9e : navigation manquante, cadres d\u2019\u00e9l\u00e9ments vides, bouton de paiement inop\u00e9rant. Votre tableau de bord interne de sant\u00e9 reste vert tout le temps, car votre origine est correcte. La panne est dans le r\u00e9seau de quelqu\u2019un d\u2019autre.<\/p>\n

\"Comparaison
M\u00eame page, deux plans : en IPv6-only, les ressources tierces sans enregistrement AAAA expirent.<\/figcaption><\/figure>\n

La surveillance Web Applications<\/a> capture ce ph\u00e9nom\u00e8ne en chargeant la page compl\u00e8te dans un v\u00e9ritable navigateur depuis un n\u0153ud IPv6-only et en enregistrant chaque requ\u00eate dans la cascade. Pour une page unique plut\u00f4t qu\u2019une transaction compl\u00e8te, la surveillance Web Pages<\/a> fonctionne pareillement. Au lieu d\u2019un simple succ\u00e8s\/\u00e9chec, vous voyez quel \u00e9l\u00e9ment a r\u00e9solu, lequel a expir\u00e9, et o\u00f9 le rendu s\u2019est bloqu\u00e9. Le tableau ci-dessous montre le mod\u00e8le qu\u2019elle r\u00e9v\u00e8le.<\/p>\n

\n\n\n\n\n\n\n
Profil de test<\/th>\nHTML principal<\/th>\nCDN et ressources m\u00e9dias<\/th>\nScripts tiers<\/th>\nCe que voit l’utilisateur<\/th>\n<\/tr>\n<\/thead>\n
Surveillance IPv4<\/td>\nR\u00e9sout (enregistrement A)<\/td>\nR\u00e9sout<\/td>\nR\u00e9sout<\/td>\nLa page compl\u00e8te se charge normalement.<\/td>\n<\/tr>\n
Surveillance IPv6-only<\/td>\nR\u00e9sout (enregistrement AAAA)<\/td>\n\u00c9chec de r\u00e9solution<\/td>\nExpiration<\/td>\nChargement partiel : mise en page cass\u00e9e, cadres vides, paiement bloqu\u00e9.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Prenons un flux de paiement en exemple. Un script Web Applications se connecte, ajoute un article, et arrive \u00e0 l\u2019\u00e9tape du paiement. En IPv4, toute la s\u00e9quence r\u00e9ussit. Depuis le n\u0153ud IPv6-only, le script du processeur de paiement n\u2019a pas d\u2019enregistrement AAAA, donc le navigateur se bloque avant que le formulaire soit utilisable. Le script \u00e9choue \u00e0 cette \u00e9tape et vous indique quel \u00e9l\u00e9ment en est la cause. Un ping de disponibilit\u00e9 sur votre propre domaine n\u2019aurait jamais d\u00e9tect\u00e9 ce probl\u00e8me de paiement. Script la transaction avec la surveillance synth\u00e9tique<\/a> transforme un \u00ab site en ligne \u00bb en \u00ab clients pouvant r\u00e9ellement payer \u00bb.<\/p>\n

Comment la surveillance Internet Infrastructure isole les \u00e9checs de protocole IPv6<\/h2>\n

Les contr\u00f4les navigateur capturent ce que voient les utilisateurs. Vous avez aussi besoin de la couche en dessous. La surveillance Internet Infrastructure<\/a> ex\u00e9cute des v\u00e9rifications au niveau protocole contre vos serveurs, aussi souvent qu\u2019une fois par minute, et depuis des localisations IPv6-only de la m\u00eame fa\u00e7on que les appareils navigateur.<\/p>\n

Cette fr\u00e9quence et cette isolation sont la partie utile. Si votre point de terminaison HTTP\/S ou DNS r\u00e9pond en IPv4 mais \u00e9choue en IPv6, la surveillance Internet Infrastructure rapporte l\u2019erreur protocole IPv6 isol\u00e9ment au lieu de l\u2019effacer dans la moyenne avec le r\u00e9sultat IPv4 sain. La surveillance Web Services<\/a> fait de m\u00eame pour vos points d\u2019API. Vous recevez une alerte qui nomme le protocole et le chemin, pas un vague \u00ab temps de r\u00e9ponse en hausse \u00bb.<\/p>\n

Le DNS m\u00e9rite une v\u00e9rification d\u00e9di\u00e9e. Un site dual-stack n\u00e9cessite un enregistrement A et un enregistrement AAAA r\u00e9solus globalement \u00e0 la m\u00eame vitesse, et un enregistrement AAAA p\u00e9rim\u00e9 ou manquant est l\u2019une des pannes IPv6 les plus courantes. La surveillance DNS<\/a> confirme que les deux enregistrements r\u00e9pondent partout et surveille les valeurs TTL pour qu\u2019un changement de routage lors d\u2019une migration ne bloque pas les utilisateurs IPv6 sur une entr\u00e9e morte. Lorsqu\u2019une alerte se d\u00e9clenche, un traceroute IPv6<\/a> automatique indique si la panne se situe sur votre origine ou dans une table de routage d\u2019un fournisseur transit en amont.<\/p>\n

Comment Dotcom-Monitor r\u00e9v\u00e8le la latence Happy Eyeballs<\/h2>\n

Certains probl\u00e8mes IPv6 ne se manifestent jamais par une panne. Ils se manifestent par un site lent sans cause identifiable. La cause est souvent Happy Eyeballs.<\/p>\n

Happy Eyeballs (RFC 8305) est un secours du navigateur. Le navigateur commence d\u2019abord la connexion IPv6, puis attend un court intervalle (le d\u00e9lai de tentative de connexion, environ 250 millisecondes par d\u00e9faut) avant de lancer aussi une course IPv4. Si le chemin IPv6 est cass\u00e9 ou lent, la tentative IPv4 gagne et porte la requ\u00eate. La connexion r\u00e9ussit toujours, donc l\u2019utilisateur voit rarement une erreur.<\/p>\n

C\u2019est bon pour l\u2019utilisateur et mauvais pour votre visibilit\u00e9. L\u2019attente avant que le navigateur abandonne IPv6 et bascule sur IPv4 s\u2019ajoute au vrai Temps jusqu\u2019au Premier Octet et au Largest Contentful Paint. Chaque utilisateur IPv6 paie une taxe de latence sur une connexion qui finit par marcher en IPv4. Les outils passifs et l\u2019analytique utilisateurs r\u00e9els enregistrent un chargement r\u00e9ussi et poursuivent, donc la faute structurelle reste invisible tandis que l\u2019exp\u00e9rience se d\u00e9grade silencieusement.<\/p>\n

La surveillance native IPv6-only mesure directement cette taxe, car il n\u2019y a pas de secours disponible pour s\u2019en cacher. Le chemin IPv6 fonctionne ou pas, et le chiffre appara\u00eet dans le rapport. Les rapports en cascade c\u00f4te \u00e0 c\u00f4te<\/a> affichent les temps IPv4 et IPv6 c\u00f4te \u00e0 c\u00f4te, donc un \u00e9cart de 250 millisecondes que les utilisateurs per\u00e7oivent mais ne peuvent d\u00e9crire devient une ligne pointable. Si vous souhaitez un rappel sur la lecture de ces graphiques, consultez notre guide sur les graphiques en cascade<\/a>.<\/p>\n

Comment configurer la surveillance dual-stack dans Dotcom-Monitor<\/h2>\n

Voici la configuration qui vous donne les deux plans sans doubler la charge de maintenance.<\/p>\n

    \n
  1. \u00c9tape 1 : Construisez le contr\u00f4le une seule fois dans EveryStep.<\/strong> Enregistrez votre chemin critique ou contr\u00f4le de protocole une seule fois. Le m\u00eame script EveryStep s\u2019ex\u00e9cute sur tous les sites, donc vous ne maintenez pas de versions IPv4 et IPv6 s\u00e9par\u00e9es.<\/li>\n
  2. \u00c9tape 2 : Assignez des localisations natives IPv4 et IPv6-only.<\/strong> Ajoutez le contr\u00f4le \u00e0 la fois sur un n\u0153ud natif IPv4 et un n\u0153ud IPv6-only. \u00c9vitez les localisations 6to4 et NAT64 pour la base IPv6 afin qu\u2019aucune traduction ne se situe entre le n\u0153ud et votre cible.<\/li>\n
  3. \u00c9tape 3 : R\u00e9glez la fr\u00e9quence des contr\u00f4les.<\/strong> Ex\u00e9cutez les contr\u00f4les de protocole Internet Infrastructure jusqu\u2019\u00e0 une fois par minute. Planifiez les contr\u00f4les navigateur Web Applications selon l\u2019intervalle d\u00e9fini par votre SLA.<\/li>\n
  4. \u00c9tape 4 : Ajoutez des contr\u00f4les DNS pour les enregistrements A et AAAA.<\/strong> Confirmez que les deux enregistrements se r\u00e9solvent globalement \u00e0 la m\u00eame vitesse, et surveillez les valeurs TTL afin qu\u2019une migration ne bloque pas les utilisateurs IPv6 sur une route p\u00e9rim\u00e9e.<\/li>\n
  5. \u00c9tape 5 : D\u00e9clenchez un traceroute IPv6 en cas de d\u00e9viation.<\/strong> Programmez des alertes qui lancent un traceroute d\u00e8s que la disponibilit\u00e9 ou le temps de r\u00e9ponse baisse, pour que vous puissiez imm\u00e9diatement diff\u00e9rencier une panne d\u2019origine d\u2019une panne chez un transit en amont.<\/li>\n
  6. \u00c9tape 6 : Comparez les deux cascades.<\/strong> Examinez les rapports IPv4 et IPv6 c\u00f4te \u00e0 c\u00f4te. Tout \u00e9l\u00e9ment, saut ou protocole diff\u00e9rent entre eux est votre probl\u00e8me sp\u00e9cifique \u00e0 IPv6.<\/li>\n<\/ol>\n

    Le r\u00e9sum\u00e9<\/h2>\n

    Dual-stack signifie que chaque requ\u00eate a deux voies pour vous joindre et deux fa\u00e7ons de tomber en panne. La surveillance uniquement IPv4 en surveille une seule et rapporte sur les deux, ce qui explique comment un site peut avoir un taux de disponibilit\u00e9 parfait alors que les utilisateurs IPv6 obtiennent des expirations, des pages \u00e0 moiti\u00e9 charg\u00e9es et une p\u00e9nalit\u00e9 de latence que personne ne peut tracer.<\/p>\n

    Dotcom-Monitor comble ce foss\u00e9 en testant le chemin IPv6 selon ses propres termes. Des n\u0153uds natifs IPv6-only sans tunnel, des scripts navigateur Web Applications qui chargent chaque ressource tierce en IPv6, des contr\u00f4les de protocole Internet Infrastructure jusqu\u2019\u00e0 une fois par minute, et des cascades c\u00f4te \u00e0 c\u00f4te qui distinguent une panne d\u2019origine d\u2019une panne en amont. Vous arr\u00eatez de deviner pour la moiti\u00e9 de votre trafic qui n\u2019a jamais \u00e9t\u00e9 touch\u00e9e par les contr\u00f4les IPv4.<\/p>\n

    \n

    Testez votre chemin IPv6 avant vos utilisateurs<\/h2>\n

    D\u00e9ployez des n\u0153uds de surveillance natifs IPv6-only et voyez exactement ce que vivent vos utilisateurs dual-stack, jusqu\u2019\u00e0 la ressource tierce. Commencez un essai gratuit de 30 jours avec Dotcom-Monitor.<\/p>\n

    Commencez votre essai gratuit<\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

    Les contr\u00f4les du protocole IPv6 s’ex\u00e9cutent une fois par minute \u00e0 partir de n\u0153uds natifs, isolant des d\u00e9fauts que votre surveillance IPv4 ne d\u00e9tectera jamais. Voici comment Dotcom-Monitor le fait.<\/p>\n","protected":false},"author":39,"featured_media":34300,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-34314","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/34314","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=34314"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/34314\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media\/34300"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media?parent=34314"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/categories?post=34314"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/tags?post=34314"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}