Un déploiement passe tous ses contrôles, puis la latence p99 entre deux régions grimpe sans que personne sache pourquoi. Les journaux montrent des délais dépassés, la console du cloud reste au vert. Le réseau entre vos services, qu'il s'agisse d'un peering VPC, d'une passerelle de transit ou de l'Internet public entre un nœud CDN et votre origine, est la partie que vous ne maîtrisez pas et qu'aucun tableau de bord ne montre. Un traceroute l'expose saut par saut : quel routeur, quel réseau, et où le délai commence.
Un traceroute visuel transforme cette liste de sauts en un document lisible par l'équipe pendant un incident : chaque saut sur une carte, avec latence, gigue, perte de paquets et ASN propriétaire. Lancé depuis plusieurs sources, il montre si les utilisateurs de Francfort et ceux de São Paulo atteignent le même nœud, si le DNS les envoie vers la bonne région, et si le chemin a changé après votre dernière livraison. Exportez-le, joignez-le au ticket, et cessez de débattre de la responsabilité du réseau.
Valider un déploiement depuis là où sont vos utilisateurs
Après un déploiement dans une nouvelle région, ne testez pas seulement depuis votre CI. Tracez vers le nouveau point d'entrée depuis Falkenstein, Gravelines et une sonde Globalping proche de vos utilisateurs. Le DNS d'abord : le nom se résout-il vers l'adresse attendue dans cette région, ou l'anycast l'envoie-t-il ailleurs ? Le chemin ensuite : combien d'ASN séparent la sonde de votre fournisseur, et que coûte le dernier saut ? Un chemin qui aboutit dans la mauvaise région, ou un premier saut chez votre fournisseur 40 ms trop loin, relève du routage ou du DNS, pas de l'application. Si la trace se termine par des astérisques, relancez en TCP sur le port 443 : beaucoup de répartiteurs de charge filtrent ICMP mais répondent sur leur port de service.
Distinguer un vrai problème d'un routeur qui vous ignore
Les routeurs bridant leurs réponses ICMP, un saut intermédiaire à 50 % de perte avec une destination à 0 % est cosmétique : le routeur transmet vos paquets et néglige seulement ses propres réponses. Une vraie perte persiste d'un saut jusqu'à la destination. La latence se lit de même : un saut à 200 ms suivi de sauts à 20 ms est un plan de contrôle lent, pas un chemin lent. Préférez la gigue à la moyenne : 30 ms de moyenne avec 25 ms de gigue pénalisent un appel gRPC au délai serré plus qu'un 60 ms stable. Surveillez la colonne ASN : un délai qui bondit exactement là où l'ASN change désigne la jonction entre deux réseaux, la seule chose que vous puissiez escalader preuves à l'appui.
Mettre le réseau sous surveillance comme tout le reste
Un changement de route est un signal précurseur : un transitaire qui bascule, un CDN qui vous déplace vers un autre point de présence, un changement BGP en amont. Planifiez une trace vers chaque point critique (origine, base de données dans une autre région, API tierce) et posez des alertes sur la latence, la perte de paquets et le changement de route. Quand une alerte se déclenche, ouvrez l'ancienne et la nouvelle trace côte à côte pour voir si une régression de 80 ms vient de votre livraison ou d'un nouveau chemin de transit. Via l'API, lancez une trace après chaque déploiement et comparez la destination et la latence du dernier saut à vos seuils. Exportez en CSV ou JSON pour vos outils d'incident, en PDF pour le post-mortem.
Lire une trace : un appel inter-régions devenu lent
Exemple pédagogique, pas une mesure réelle. Un service à Francfort appelle une API en Virginie. Les sauts 1 à 5 restent chez le fournisseur cloud, entre 1 et 3 ms. Au saut 6, l'ASN passe à un transitaire et la latence affiche 12 ms ; le saut 7 affiche 95 ms, et tous les sauts suivants restent proches de 95 ms, sans perte. Le bond persiste jusqu'au bout, donc il est réel, et 90 ms, c'est la traversée de l'Atlantique. Une seconde trace depuis une sonde Globalping à New York atteint la cible en 8 ms : l'API est saine, Francfort appelle la mauvaise région. Redirigez l'appel vers la réplique européenne ou budgétez cette latence. Si les sauts suivants étaient redescendus à 12 ms, le pic aurait été du bruit de routeur, pas un problème de chemin.
Les outils qui complètent le tableau
Ping sur une minute vous donne la gigue et la perte sans le détail des sauts, de quoi confirmer une régression avant de tracer. DNS Lookup montre quelle adresse renvoie chaque résolveur, premier réflexe quand une région semble disparaître. HTTP/SSL Check suit les redirections et lit le certificat comme un client, y compris les certificats expirés ou au mauvais nom qu'un contrôle de santé peut manquer. Port Check confirme une règle de pare-feu depuis l'extérieur. BGP Viewer indique quel ASN annonce le préfixe où aboutit votre trafic.
Questions fréquentes
- Puis-je lancer un traceroute depuis un pipeline CI ?
- Oui, via l'API, disponible avec les offres Pro et Business. Appelez-la après un déploiement pour tracer vers le nouveau point d'entrée depuis la source de votre choix, puis comparez dans votre propre script les sauts, la latence et l'adresse de destination renvoyés avec ce que vous attendez. Le résultat est le même JSON que celui téléchargeable depuis l'interface : il se joint proprement à un rapport de déploiement ou à un incident.
- Ma trace se termine par des astérisques avant le répartiteur de charge. Le service est-il en panne ?
- Pas forcément. Beaucoup de répartiteurs de charge et de nœuds cloud rejettent ICMP et ignorent les sondes UDP : la trace devient muette alors que HTTPS fonctionne. Relancez-la en mode TCP sur le port que vous servez réellement, et confirmez avec HTTP/SSL Check. Si la trace TCP atteint la destination et que le contrôle HTTP répond, le service va bien et les astérisques sont du filtrage, pas une panne.
- Comment savoir si un problème de latence vient de chez moi ou de mon fournisseur ?
- Regardez où le délai apparaît en premier et s'il persiste. S'il commence dans l'ASN de votre fournisseur et se maintient jusqu'à la destination, le problème est dans son réseau ou à son peering. S'il apparaît exactement là où l'ASN change, c'est une jonction entre deux opérateurs. Relancez la même trace depuis une seconde source : deux sources qui s'accordent sur le même saut sont une preuve solide à joindre à votre ticket.