Résumé

  • Un article publié le 8 septembre sur RIPE Labs décrit une petite campagne RIPE Atlas menée dans dix pays. Les mesures révèlent des points d’arrivée, pas la logique interne qui les sélectionne.
  • Dans le réseau d’accès de SkyTel, deux exports distincts attribuent 72 % à des actifs GGC et 77 % à un équipement Meta, mais sur des périodes et selon des définitions différentes. La source exclut toute comparaison directe.
  • La présence d’un appareil, l’itinéraire vu par une sonde et une part calculée par un fournisseur ne constituent pas le même fait.
  • Avant d’en déduire un gain de capacité ou une résilience, l’opérateur a besoin d’un relevé propre au service, avec le périmètre du fournisseur et un test de repli autorisé.

Le dernier saut visible ne porte pas la décision

Dans une carte réseau, un cache local ressemble à une destination. Dans un système de diffusion, il n’est qu’une possibilité. La plateforme choisit les services et objets éligibles, associe une requête à un point d’arrivée et définit le repli en cas de saturation ou d’indisponibilité. L’opérateur d’accès héberge la machine, fournit l’énergie, les ports, le routage local et le dernier kilomètre. La proximité physique ne dit donc pas, à elle seule, qui commande la livraison.

C’est la limite la plus instructive de « The Internet’s New Edge Builders », publié sur RIPE Labs. Arman Obosyan y relate une campagne RIPE Atlas restreinte, réalisée en juin 2026 dans dix pays. Les points d’arrivée changeaient selon le nom d’hôte et le réseau source, parfois entre deux sondes d’un même pays. L’auteur qualifie le résultat d’instantané de diagnostic : le chemin sélectionné est visible, le raisonnement interne de la plateforme ne l’est pas.

Cette absence n’est pas une erreur de RIPE Atlas. Le service conserve une observation produite par une sonde, vers une cible et à une date données, avec des paramètres définis. Sa documentation détaille les réglages du traceroute et précise que la structure des résultats peut varier selon le micrologiciel de la sonde. On peut répéter et comparer la mesure. On ne peut pas en extraire une table d’éligibilité que la plateforme n’a jamais publiée.

Garder 72 et 77 dans leurs propres cadres

L’exemple de SkyTel rend cette séparation très concrète. Selon l’article, Google Global Cache et un équipement Meta se trouvent dans le même réseau d’accès, AS49628. SkyTel assure l’hébergement et la connectivité. Chaque plateforme décide ce que son équipement peut servir, quels utilisateurs y sont orientés et comment le trafic est déplacé si le système local n’est plus disponible.

L’export du portail Google attribue 72 % de sa répartition à des actifs GGC nommés entre le 5 août et le 4 septembre 2026. Un autre export attribue 77 % à l’équipement Meta entre le 29 août et le 5 septembre. L’article indique que SkyTel a autorisé la publication de ces agrégats.

Il serait pourtant faux d’y voir deux mesures jumelles. Les fenêtres temporelles et les définitions diffèrent. Les exports privés ne figurent pas dans le dossier public. Les pourcentages ne doivent être ni additionnés, ni moyennés, ni convertis en part de l’ensemble du trafic de SkyTel. Chacun reste valable seulement dans la population que son fournisseur a définie.

Un traceroute RIPE Atlas appartient à un troisième périmètre. Il montre ce qu’une sonde a atteint pour une cible précise. Il ne mesure pas le taux de succès du cache, le volume transporté sur un réseau privé ou la totalité des abonnés. Un chemin local ne prouve pas davantage une baisse de facture : l’engagement de transit, le transport interne, l’énergie, les ports et la capacité de secours peuvent fixer l’économie ailleurs.

Documenter un placement, pas une marque

Un relevé utile doit partir du service testé. Il nomme le nom d’hôte ou la classe d’objet, la sonde et son réseau source, la famille d’adresses, l’identifiant de mesure, l’heure, le point d’arrivée et le chemin public. Si une statistique de portail intervient, il faut aussi conserver son dénominateur, sa règle d’éligibilité et sa période.

Les inconnues ont leur place dans ce relevé. Le taux de succès du cache peut rester inconnu, tout comme la raison d’une décision de répartition ou la part portée par le réseau privé. Les responsabilités sont ensuite séparées : hébergement et routage local pour l’opérateur ; logiciel, éligibilité, orientation et retrait pour la plateforme.

Le repli exige sa propre observation. Lors d’un essai autorisé, on peut relever le chemin de secours, la demande en amont, la latence, les pertes et l’hypothèse de capacité. Ni un trajet normal, ni un pourcentage de portail ne certifie à l’avance que cette charge sera absorbée.

Ce relevé de placement est une proposition éditoriale de Theo March, non une règle annoncée par RIPE NCC, SkyTel, Google ou Meta. Il empêche simplement qu’une observation publique serve de substitut à une décision privée.

Ce que les sources établissent — et ce qu’elles n’établissent pas

RIPE Labs rapporte la campagne de l’auteur, l’exemple SkyTel, les deux agrégats bornés et leur non-comparabilité. La documentation RIPE Atlas définit les paramètres et le format des mesures. Meta décrit de son côté un vaste réseau de points de présence. Ces sources ne publient aucun algorithme de répartition, ne généralisent pas l’exemple à tous les réseaux et ne démontrent ni économie, ni panne, ni violation.

Sources