Résumé

  • Dans les sources examinées de RIPE Atlas Tools, le réglage HTTP de dix secondes est transmis au géocodeur de Google, mais pas à la création d’une mesure Atlas via Cousteau.
  • Un test local, sans réseau, confirme cette différence pour les valeurs 3, 10 et 30. Il ne démontre ni panne réelle, ni durée d’attente, ni comportement de toutes les installations.

Un réglage ne voyage pas tout seul

Un opérateur qui lit « dix secondes » dans une configuration peut légitimement chercher à savoir ce qui attendra au-delà. Dans RIPE Atlas Tools, la réponse dépend du chemin emprunté par la requête. Le géocodeur reçoit le réglage http-timeout. Le parcours de création d’une mesure Atlas que nous avons examiné ne le reçoit pas.

L’historique officiel présente ce réglage parmi les changements de la version 3.4.0, datée du 3 juin 2026. Il s’agit ici d’un examen en septembre du travail publié en juin, et non de l’annonce d’une nouvelle version. La valeur par défaut figure bien dans les paramètres du logiciel. Le problème n’est donc pas un bouton imaginaire : il est de déterminer où ce bouton agit.

Pour convertir un lieu en coordonnées, la commande de recherche de sondes appelle le service de Google avec Requests. Elle lui passe explicitement la valeur configurée comme paramètre de délai et prend en charge les erreurs de dépassement. Sur ce trajet précis, l’intention et le mécanisme se rejoignent.

Créer une mesure passe par une autre couche. La commande prépare un AtlasCreateRequest avec le serveur, la clé d’autorisation, l’identifiant logiciel du client, les définitions de mesure, les sources de sondes et le caractère ponctuel de l’opération. Le réglage HTTP ne fait pas partie de cette transmission.

Dans le code de Cousteau 2.3.0 étudié, AtlasCreateRequest hérite d’AtlasRequest. Les arguments de la requête réunissent paramètres, en-têtes, vérification TLS et mandataires réseau ; l’envoi POST ajoute le corps JSON. L’appel final à Requests utilise cet ensemble sans paramètre de délai. L’appartenance des deux logiciels au même environnement ne suffit pas à faire hériter le SDK d’un choix de configuration du client.

Vérifier la transmission, sans interroger Atlas

Nous avons isolé les véritables méthodes de création et de géocodage des sources figées, ainsi que les classes de requête et de création du SDK. Leur exécution locale utilisait des définitions de mesure et des sources synthétiques. Les fonctions de transport capturaient les arguments et renvoyaient des données de test, pas une réponse d’Atlas.

À 3, 10 puis 30, la valeur configurée apparaissait exactement dans l’appel de géocodage. Elle n’apparaissait dans aucun des trois dictionnaires d’arguments POST destinés à Atlas. Le code extrait ne disposait d’aucune fonction de connexion réseau. Aucune clé n’a été utilisée, aucune mesure créée, aucun crédit dépensé.

C’est une vérification ciblée du passage d’un paramètre. Ce n’est pas un essai complet de la commande installée, un test d’intégration de tous ses modules ou une expérience sur les serveurs. Elle ne permet pas d’affirmer qu’une requête a duré trente secondes, qu’un utilisateur a subi une panne ou que le système distant a accepté une tâche.

La précision est importante. Un test limité peut établir une frontière de code sans établir les effets de cette frontière en exploitation. Il faut garder les deux propositions séparées.

Dix secondes ne constituent pas un délai global

La documentation de Requests explique qu’en l’absence d’un paramètre explicite, ses appels n’ont pas de délai d’expiration spécifié. Elle précise aussi qu’un délai fourni n’est pas une limite pour la durée totale du téléchargement de la réponse. Le contrôle de l’attente sur une connexion n’est pas un chronomètre couvrant toute une opération.

Même le trajet du géocodeur ne garantit donc pas une fin exactement dix secondes après le lancement de la commande. Inversement, l’absence du paramètre dans le trajet Atlas ne prouve pas une attente éternelle : une connexion, le système d’exploitation, un mandataire ou un superviseur extérieur peuvent interrompre le travail. Cet examen n’a pas inventorié leurs règles.

Il ne faut pas davantage confondre cette attente HTTP avec le délai d’une sonde pour ses paquets, ou avec la période pendant laquelle un client écoute les résultats. Un retard de réponse de l’API ne mesure pas les performances du réseau sondé.

Préserver ce que l’on ne sait pas

La conséquence opérationnelle tient au statut du résultat. Si une réponse de création est perdue après l’acceptation de la requête par le serveur, arrêter le client ne prouve pas que la tâche distante a été refusée. C’est un scénario possible, pas une observation de notre test.

Avant de décider d’un nouvel envoi, l’opérateur devrait rapprocher l’opération d’un enregistrement distant auquel il est autorisé à accéder, ou maintenir explicitement le résultat dans l’état « inconnu ». Une expiration locale et une annulation côté serveur ne sont pas équivalentes.

La bonne description du logiciel nommerait séparément le géocodage, les appels Atlas du SDK et la limite globale imposée par l’automatisation. Chacun peut avoir une règle différente. Ce qui manque au lecteur, si cette portée n’est pas expliquée, est la possibilité d’associer une valeur à une opération et à un responsable précis.

Sources