Résumé

  • La fonction Copy API Query reprend les filtres de la recherche avancée de PeeringDB dans une requête utilisable avec curl ou un langage de programmation courant.
  • La carte facultative et le tableau facilitent le repérage d’installations. Aucun des deux ne prouve qu’un port est actif, qu’une route est retenue ou qu’un service est disponible.

Analyse

De la recherche à la requête

L’enjeu n’est pas une recherche de plus dans un navigateur. Quand une équipe étudie une nouvelle ville, la sélection des installations peut entraîner des appels aux exploitants, des demandes de prix, puis un choix de site qui engage un budget et un calendrier. Il ne s’agit pas d’un cas particulier rapporté par PeeringDB, mais du type de décision que ces données aident à préparer. Une liste utile doit donc être facile à reprendre, sans être prise pour une autorisation de construire.

Dans sa mise à jour de septembre, PeeringDB indique avoir livré Copy API Query pour la recherche avancée. Après avoir interrogé le site, l’utilisateur peut transmettre la requête à curl ou choisir un format pour un langage de script courant. Le changement réduit la distance entre un filtre choisi par un opérateur et une demande traitée par un outil. Les critères peuvent être conservés dans une procédure, relus avant exécution et remis à l’équipe suivante. La fonction ne rend pas les données plus autoritatives : elle rend le raisonnement de sélection plus transportable.

Le gain économique est modeste, mais concret : le passage de l’exploration à une liste de candidats reproductible demande moins de travail manuel. Un ingénieur réseau peut vérifier un filtre géographique dans l’interface avant de demander à un script de traiter le résultat. Un analyste peut transmettre les critères eux-mêmes au lieu d’une capture d’écran dont les choix sont difficiles à reconstituer. Le guide de recherche de PeeringDB décrit déjà des filtres avancés portant sur la localisation, la présence d’un réseau, le niveau de service et d’autres caractéristiques, ainsi que l’export JSON ou CSV.

Certaines fonctions, dont la recherche par rayon, requièrent une connexion. Copier la requête rend le transfert plus lisible ; cela ne dispense pas de comprendre la demande ni ses exigences d’accès.

La carte localise des fiches, pas la connectivité

La même mise à jour décrit une carte intégrée et facultative dans les pages pertinentes de recherche avancée. Un réglage du profil l’active. La carte représente la répartition des installations dans une ville en complément du tableau. Un téléchargement KMZ distinct permet de consulter les installations dans un outil SIG et d’y afficher ou masquer plusieurs couches.

Cette vue répond à une difficulté de premier ordre : une liste de noms de sites se lit mal à l’échelle d’une métropole. La carte peut faire apparaître une concentration, des distances et l’écart entre quelques fiches regroupées dans un quartier et d’autres disséminées dans la ville. Le tableau conserve les fiches qui se trouvent derrière les symboles. Ensemble, ces éléments améliorent la découverte géographique.

Ils ne représentent ni le trafic d’un réseau, ni une route, ni un raccordement actif, ni un contrat de service. Un repère indique qu’une fiche d’installation figure dans le résultat choisi. Il ne prouve pas qu’un réseau précis y dispose d’un port éclairé, que les parties ont convenu d’échanger du trafic, qu’une route y est sélectionnée ou qu’une capacité est disponible aujourd’hui. La carte rend une présélection plus exploitable ; elle ne transforme pas une relation de répertoire en relation opérationnelle.

Une requête peut se répéter sans figer ses résultats

Copy API Query transporte une expression de recherche vers une requête. C’est utile pour reprendre la même logique de filtres, mais cette fonction ne doit pas être confondue avec la conservation des fiches qui correspondaient à ces critères. La description de PeeringDB porte sur le transfert d’une requête, pas sur une archive immuable des résultats ou une version horodatée de la base. La différence compte lorsqu’un résultat alimente un dossier de conception, une décision d’achat ou l’analyse ultérieure d’un incident.

Pour rendre le raisonnement vérifiable, l’équipe devrait conserver la date d’exécution, les paramètres, la réponse obtenue et les confirmations apportées par les propriétaires des fiches.

PeeringDB présente son service comme une base communautaire entretenue par ses utilisateurs et comme un point de départ pour les décisions d’interconnexion. Sa politique de propriété des données demande aux utilisateurs de maintenir à jour les informations de leur organisation et décrit le traitement des fiches contestées. La validation par des bénévoles et la responsabilité des contributeurs appartiennent à ce modèle ; il serait inexact d’en faire une garantie d’actualité pour un déploiement donné.

La conclusion opérationnelle découle de ce cadre : la recherche sert à trouver des candidats, tandis que le réseau, l’échange, l’installation et les contreparties doivent confirmer les conditions présentes.

Il faut aussi distinguer cette fonction du débat sur l’API v3 de PeeringDB. La mise à jour de septembre présente ce document comme une proposition soumise aux commentaires avant son amélioration et son éventuelle mise en œuvre, avec des changements envisagés pour l’architecture de lecture et d’écriture et l’efficacité des requêtes. Copy API Query est une fonction de recherche avancée que PeeringDB indique avoir déjà livrée. L’une est une fonction disponible ; l’autre, une proposition. Présenter le bouton de copie comme la preuve que l’API v3 est en service confondrait deux étapes différentes.

Une découverte mieux disciplinée

Le nouvel enchaînement est utile si l’équipe maintient la séparation des étapes. Elle définit un ensemble de candidats dans la recherche avancée, copie la requête pour examiner et reprendre la logique de sélection, puis utilise la carte pour situer les fiches d’installations dans la ville. Il reste ensuite à vérifier les points qui engagent réellement l’exploitation : l’actualité des renseignements sur le site, la présence déclarée par le réseau, l’état du port et du raccordement auprès des parties concernées, ainsi que les conditions commerciales.

Cette division protège les deux versants du travail. Une meilleure recherche évite des efforts d’analyse inutiles et rend les critères plus faciles à transmettre. Une vérification explicite empêche une interface pratique de devenir un certificat de préparation opérationnelle. Une fiche décrit un état déclaré ; elle ne raccorde pas un réseau. PeeringDB a raccourci le chemin de la découverte à l’automatisation. La décision appartient toujours à l’opérateur qui devra répondre de la connexion.

Sources