Résumé

  • Le plan RIPE Atlas du troisième trimestre 2026 classe comme achevées les limites visant le « probe farming » et les fonctions de sélection de sondes dissemblables.
  • Les contrats publics de création et de modification d’une mesure ne donnent pas de nom à ce sélecteur et ne publient ni métrique ni version.
  • Les listes de sondes et les journaux de participation documentent le résultat, mais pas toujours la raison du choix entre candidats admissibles.
  • Un reçu de sélection, borné et versionné, rendrait l’échantillon vérifiable sans exposer les hôtes ni promettre une représentativité universelle.

Un échantillon est déjà une décision

Un traceroute peut être exact et néanmoins répondre à une question différente de celle que son lecteur imagine. Tout dépend du point de départ. Cinquante sondes réparties sur une carte ne constituent pas nécessairement cinquante domaines de panne, cinquante opérateurs ou cinquante expériences indépendantes. Deux appareils dans des préfixes distincts peuvent partager le même accès, la même ville ou le même fournisseur d’hébergement. Deux sondes dans un seul ASN peuvent, au contraire, se trouver à des milliers de kilomètres et emprunter des chemins très différents.

Le mot « dissemblable » exige donc un prédicat. Porte-t-il sur le préfixe, l’ASN, le pays, la forme matérielle, des chemins observés, la latence vers des ancres ou une combinaison de ces éléments ? À quel instant les attributs sont-ils évalués ? Comment une sonde indisponible est-elle remplacée ? Sans réponse publique stable, le terme reste une propriété annoncée, non une propriété que le lecteur peut contrôler.

Le plan trimestriel Q3 2026 est précis sur le calendrier : les limites au regroupement excessif de sondes et la capacité de choisir des sondes dissemblables ont été achevées au deuxième trimestre. Le soutien aux agrégateurs de mesures demeure, lui, en cours. Cette séparation est importante. L’agrégateur pose la question de savoir pour quel client une mesure est lancée. La dissemblance pose celle de savoir pourquoi ces points d’observation ont été retenus.

Le débat public n’a jamais établi que la proximité était une faute

L’archive d’une discussion de la liste RIPE Atlas contient le signal initial : un participant a observé de nombreuses sondes logicielles dans un même préfixe et des résultats répétés lors d’une sélection nationale. Son inquiétude portait sur un biais possible si le chercheur ne regardait pas la liste des sondes.

C’est un témoignage, pas un jugement sur l’opérateur concerné. Une grappe de sondes proches peut être utile pour comparer les appareils, détecter une panne locale ou étudier la variation à l’intérieur d’un réseau. Supprimer toute proximité reviendrait à confondre répétition inutile et répétition expérimentale.

Le compte rendu du groupe Measurements and Tools de mai 2024 montre une réponse mesurée. RIPE NCC a contacté des utilisateurs exploitant un grand nombre de sondes et indique que la plupart avaient des justifications raisonnables. La première règle retenue limite le nombre de sondes logicielles provenant de la même adresse IP ou du même préfixe. La réduction des crédits et les métriques de similarité sont alors présentées comme des options ultérieures.

Cette chronologie, complétée par les anciens plans trimestriels, révèle deux contrôles. L’admission limite ce qui entre dans le parc et les incitations qu’un hôte peut recevoir. La sélection compose un échantillon à partir du parc admissible. Une limite par préfixe peut améliorer le premier contrôle sans expliquer le second.

L’API décrit la demande, pas le test de dissemblance

Le manuel de sélection des sondes documente un tableau probes : nombre demandé, type et valeur. Les types visibles sont la région, plusieurs pays, le préfixe, l’ASN, les identifiants explicites et une mesure antérieure. Des balises peuvent inclure ou exclure des sondes. Chaque élément accepté devient une demande de participation.

Le contrat des demandes de participation ajoute l’action, une description, un identifiant et l’heure de création. Il énumère également area et country. Dans les pages consultées, aucun type dissimilar n’est nommé. Aucun champ ne conserve une famille de méthode, une version, un seuil, l’identité d’un ensemble de candidats ou la raison du choix entre deux candidats admissibles.

Cette observation doit rester limitée à la documentation publique. Une fonction peut exister dans l’interface graphique, être appliquée par défaut ou être proposée à certains utilisateurs sans apparaître sous la forme d’un type d’API. Rien dans les sources vérifiées ne permet d’affirmer qu’elle est absente ou défectueuse. Le problème est celui de la concordance : une réalisation annoncée ne se retrouve pas sous un nom vérifiable dans le contrat qui décrit la sélection.

Le guide des mesures définies par l’utilisateur ajoute deux faits. La valeur par défaut est un choix aléatoire de cinquante sondes dans le monde ; et même une sonde explicitement demandée peut ne pas être utilisée si elle est déconnectée ou trop occupée. Il existe donc au moins deux moments de variation : le choix parmi les candidats et la disponibilité lors de la planification.

Une liste finale ne dit pas nécessairement lequel a joué. Une exclusion destinée à augmenter la diversité appartient à la méthode d’échantillonnage. Une sonde choisie mais indisponible appartient à l’exécution. Un remplacement survenu plus tard appartient à l’historique de la mesure. Les fondre dans une seule liste transforme une décision en simple état.

Les éléments du reçu existent déjà en grande partie

RIPE Atlas ne part pas de zéro. Le contrat de lecture d’une mesure expose le nombre de sondes demandé et planifié. Il peut inclure les demandes de participation, les journaux, les sondes actuelles, leurs sources et leurs fiches. Un chercheur peut publier ses identifiants de sondes, expliquer son propre filtrage et réanalyser les résultats.

C’est le meilleur contre-argument à une nouvelle obligation. Les spécialistes peuvent construire un échantillon mieux adapté qu’un sélecteur générique. Rendre public chaque détail d’une défense contre les abus faciliterait son contournement. Publier une graine aléatoire pourrait rendre les points d’observation prévisibles. L’API n’a pas non plus à reproduire chaque commodité de l’interface web.

Un reçu borné respecte ces limites. Il associerait à l’identifiant de mesure : l’identifiant de la demande de participation, l’heure, le nombre demandé, les critères visibles, une référence à l’état d’admissibilité, le nom et la version de la méthode, des classes d’attributs non sensibles, les sondes retenues, les nombres et motifs généraux d’exclusion, les substitutions et les corrections. Une empreinte d’engagement peut remplacer une graine exploitable.

Le reçu ne certifierait pas la représentativité. Il dirait seulement : voici comment RIPE Atlas a opéré ce choix sous cette version. La conclusion scientifique resterait à l’auteur. La présence d’un pays, d’un ASN ou d’une sonde ne donnerait aucun mandat politique et ne décrirait pas à elle seule l’expérience de tous les utilisateurs.

La version du choix doit survivre à la version de l’interface

Les algorithmes de sélection doivent pouvoir changer. Un nouveau signal topologique, une meilleure protection de la vie privée ou une contrainte de capacité peut justifier une amélioration. Mais deux études demandant le même nombre de sondes dans le même pays peuvent alors obtenir des échantillons différents pour une raison invisible. Le résultat brut ne répare pas l’identité manquante de la décision.

RIPE NCC contrôle l’admission, les crédits, l’éligibilité, la sélection par défaut, la planification et le schéma public. L’utilisateur contrôle la question, la cible, la période et l’interprétation. L’hôte fournit un point d’observation, sans devenir responsable de la conclusion. Un reçu répartit ces responsabilités au lieu de laisser au graphique final le soin de les deviner.

La prochaine étape n’est donc pas de publier un algorithme immuable. Elle est de nommer le sélecteur public, de versionner sa méthode et de relier son résultat à une trace compacte. RIPE Atlas pourrait alors améliorer son système sans effacer la raison pour laquelle une mesure historique a commencé ici plutôt qu’ailleurs.

Sources

  1. Plan trimestriel RIPE Atlas, Q3 2026
  2. Archives des plans trimestriels RIPE Atlas
  3. Discussion sur le regroupement possible de sondes logicielles
  4. Archive MAT Working Group de mai 2024
  5. Manuel API de sélection des sondes
  6. Contrat API des demandes de participation
  7. Guide des mesures définies par l’utilisateur
  8. Contrat API de lecture d’une mesure