Résumé

  • Le code de Starla examiné déclare une version de paquet 0.8.0, une constante de compatibilité fw=5120 et une version de code de mesure mver=2.6.4. Ces numéros ne désignent pas un exécutable unique.
  • Le message d’enregistrement contient déjà le nom Starla et sa version de paquet compilée. Il ne s’agit donc ni d’une identité partout cachée, ni d’un constat de mesure erronée.
  • Une comparaison historique doit distinguer compatibilité, programme effectivement déployé, méthode de mesure, pertes de collecte et conformité testée. La continuité d’un numéro ne prouve pas celle de l’instrument.

Le nom est envoyé. Reste à savoir à quelles mesures, et à quelle période d’exécution, un lecteur peut le rattacher.

Dans le code d’enregistrement de Starla, la chaîne décrivant l’environnement comprend le système d’exploitation, sa version, l’architecture, starla et la version du paquet à la compilation. Ce n’est pas un détail que l’on puisse omettre pour rendre la critique plus spectaculaire. L’implémentation est explicitement nommée sur cette interface. Le code est public et permet de vérifier comment cette déclaration est construite. Construction de l’identité d’enregistrement.

L’autre interface raconte une histoire différente. Le paquet de l’espace de travail Cargo porte le numéro 0.8.0. La constante de firmware vaut 5120. Le formateur des résultats renseigne mver avec 2.6.4. Ces valeurs coexistent dans le commit 82bf0d9c42883bfe4d8a20d4ee444e7a0f8b55f1, daté du 7 septembre 2026, que nous avons examiné. La première identifie une version déclarée du projet ; les deux suivantes répondent à une convention de compatibilité avec Atlas. Ce constat porte sur une source figée, pas sur les programmes installés chez des contributeurs. Version du paquet, formateur des résultats.

Le problème n’est pas que l’un de ces numéros soit nécessairement faux. Il est qu’on leur demande parfois une réponse qu’ils ne donnent pas : quel programme précis a produit cette observation ?

Un remplacement mérite ses propres preuves

Le développeur a présenté Starla sur le forum de RIPE NCC le 9 avril 2026 comme une réécriture en Rust de RIPE Atlas Software Probe, capable de remplacer le programme original sans changer son usage. Une telle compatibilité peut être précieuse. Elle permet à un système de mesure établi de s’ouvrir à d’autres environnements et évite de confondre le service avec une seule base de code. L’équivalence du comportement des mesures reste toutefois une affirmation du développeur dans cette enquête, et non le résultat de nos propres essais. Présentation du développeur.

La source définit d’ailleurs séparément la constante de firmware et une chaîne de version obtenue à partir de CARGO_PKG_VERSION. Le commentaire associé à la constante justifie son choix par l’acceptation du contrôleur lorsqu’elle correspond à la sonde de référence. Il explique l’intention technique du développeur ; il ne démontre pas la politique effective des contrôleurs aujourd’hui. Définitions partagées des versions.

Une interface stable apporte un bénéfice immédiat aux consommateurs de données. Leurs outils n’ont pas à apprendre un nouveau vocabulaire pour chaque réimplémentation. Mais le contrat qui leur permet de lire un résultat n’est pas, à lui seul, le dossier de fabrication du résultat. Deux programmes peuvent déclarer la même compatibilité sans avoir les mêmes dépendances, les mêmes corrections ou le même historique de compilation. Cela ne prouve aucune divergence de mesure. Cela empêche seulement de déduire leur identité de la ressemblance de leurs déclarations.

La distinction protège aussi le développeur. Une réimplémentation n’a pas à devenir le programme original pour être utile. Elle doit pouvoir dire ce qui est compatible, ce qui a été testé et ce qui relève encore d’une hypothèse. Un seul numéro ne peut porter ces trois responsabilités.

Atlas ne part pas de zéro

La documentation officielle prévoit déjà mver. Elle le décrit comme la version du code de mesure : changement majeur lorsque les résultats deviennent incompatibles, changement mineur lorsque des champs sont ajoutés sans empêcher les anciens outils de lire le résultat, changement de correctif lorsque le code évolue mais conserve son format de sortie. fw indique la version du firmware. Parler d’une absence totale de version logicielle serait donc incorrect. Documentation officielle du format.

Ce mécanisme est utile pour suivre une famille de code selon ses propres conventions. Starla montre pourquoi il faut aussi connaître la famille qui attribue les numéros. Le formateur examiné reprend 2.6.4 ; ce numéro n’est pas la version 0.8.0 déclarée par l’espace de travail. Un outil peut savoir comment décoder la sortie sans savoir quelle lignée de programme l’a produite.

Le besoin dépend de l’usage. Pour vérifier qu’une destination répond, une connaissance aussi fine peut être superflue. Pour attribuer une petite variation de latence à une modification du réseau, la stabilité de l’instrument devient une hypothèse de l’analyse. Si cette hypothèse repose uniquement sur un tuple inchangé, elle n’est pas complètement étayée.

Il ne s’ensuit pas qu’il faille mettre de côté les anciennes mesures. L’enquête n’a identifié ni résultat défectueux, ni population de sondes Starla en service, ni incident. L’incertitude sur le producteur doit rester une incertitude documentée, pas se transformer en verdict sur la donnée.

Le programme disponible n’est pas toujours la méthode exécutée

Le code de ping contient une méthode Native, exécutée dans le programme, et une méthode Scamper disponible sous Linux. Après le choix de cette branche, le résultat reçoit la même constante de firmware. Le traceroute propose également ces alternatives et construit sa ligne complète avec mver=2.6.4. Le tuple de ces sorties ne constitue donc pas, dans les chemins examinés, un identifiant du moteur choisi. Implémentation du ping, implémentation du traceroute.

Une restriction change la portée de ce constat. Lorsqu’il transforme les tâches ordinaires de ping et de traceroute en mesures exécutables, l’ordonnanceur figé utilise backend: Default::default(). Le choix par défaut est Native. Nous ne pouvons donc pas affirmer que ces tâches du contrôleur sélectionnent Scamper, qu’une mesure publique l’a utilisé ou que les deux méthodes produisent des observations différentes. La présence d’une option dans une bibliothèque n’est pas une expérience de production. Conversion des tâches.

Cette limite est importante pour une future déclaration de provenance. Une liste de fonctions disponibles ne dit pas ce qui a été exécuté. Il faudrait rattacher la méthode effective et les paramètres pertinents à la période de mesure, lorsqu’ils sont connus. Sans cela, on remplace simplement une ambiguïté de version par une ambiguïté de catalogue.

Même une empreinte exacte du binaire n’établirait pas son équivalence scientifique avec un autre programme. Elle identifierait un artefact. La comparaison de sa construction de paquets, de ses temporisations ou de son traitement des erreurs demanderait des essais distincts, avec un périmètre déclaré. Identifier, décoder et valider sont trois opérations différentes.

Une observation absente a aussi une histoire locale

Le chemin de collecte donne un autre exemple de ce que les seuls numéros ne racontent pas. Lorsque sa file en mémoire atteint sa capacité, Starla supprime le résultat le plus ancien avant d’en ajouter un nouveau. Après un échec d’envoi, la remise en file restaure les travaux à l’avant et, si nécessaire, réduit la file par l’arrière. D’autres suppressions dépendent de l’âge ou du nombre de tentatives. Il serait donc inexact de résumer tous les abandons par une règle unique consistant à enlever le plus ancien. Ordre de la file.

Le gestionnaire prévoit par défaut une capacité de 10 000 résultats et un âge maximal de 3 600 secondes, avec des limites de tentatives et un nettoyage périodique. Ce sont des paramètres de source. Ils ne prouvent ni la configuration d’un hôte, ni un abandon effectivement survenu. Paramètres et nettoyage du gestionnaire.

La limitation est défendable : contribuer à un réseau de mesure ne doit pas engager une machine bénévole à fournir une mémoire sans borne. Le coût analytique est ailleurs. Une série reçue peut refléter les observations conservées, pas toutes celles qui ont été tentées. Une période difficile pour les envois peut aussi être précisément celle que le chercheur veut comprendre.

Un trou ne suffit pas à départager absence de réponse, défaut de planification, problème de transport et abandon local. Des compteurs sûrs d’omission, les limites appliquées et un inventaire des tentatives aideraient à le faire. Leur absence doit élargir l’intervalle d’incertitude. Elle ne fournit pas une cause de remplacement.

Donner une date à l’identité

L’enregistrement apporte un point de départ solide, mais il faut préserver sa dimension temporelle. Un hôte peut changer de programme tout en gardant son identité de sonde. Une description mise à jour aujourd’hui peut être exacte et ne rien dire du binaire exécuté pendant une panne ancienne. Une version de paquet déclarée peut également couvrir plusieurs compilations.

L’unité utile serait un épisode de production : une déclaration d’implémentation, un artefact lorsqu’il est connu, un début et une fin, et les résultats auxquels cette association s’applique. Il faudrait indiquer ce qui provient d’une déclaration de l’hôte, d’un enregistrement conservé ou d’une vérification. Une association manquante ne devrait jamais être inventée à partir de 5120 et 2.6.4.

Rien dans cette lecture du code ne démontre que RIPE NCC ne détient pas déjà des éléments internes, ni que ses interfaces publiques ne permettent aucune identification. La question laissée ouverte est celle de l’association historique disponible pour un usage précis. Il faut l’examiner à cette échelle, sans transformer un périmètre de recherche limité en absence générale.

Sources

Les liens ci-dessus renvoient à neuf fichiers Starla figés au commit du 7 septembre, à la présentation du développeur en avril et à la documentation officielle d’Atlas capturée le 14 septembre 2026. Nous n’avons installé, enregistré ou exécuté aucune sonde, réalisé aucune mesure payante ni testé indépendamment la conformité. La continuité du programme et la complétude de la collecte restent des questions à documenter, non des incidents constatés.