Résumé

  • APNIC enregistre AS9245 sous le nom COMPASS-NZ-AP, avec le pays NZ, le statut administratif actif et Compass Communications Ltd comme titulaire déclaré.
  • La mention « actif » décrit l’état de l’objet dans le registre ; elle ne prouve ni l’annonce actuelle de routes, ni la portée d’une licence, ni la disponibilité d’un service.
  • À l’instant d’observation du 3 août 2026 à 00:00:00 UTC, RIPEstat indiquait announced=true pour AS9245 et constatait une présence publique en IPv4 et en IPv6.
  • Le relevé de routage comptait douze préfixes IPv4 couvrant 25 600 adresses et un préfixe IPv6 correspondant à 65 536 blocs /48.
  • Les collecteurs RIS échantillonnés voyaient l’origine depuis 329 pairs IPv4 sur 329 et 321 pairs IPv6 sur 321 ; ces dénominateurs interdisent d’étendre l’observation à l’ensemble d’Internet.
  • La réponse bornée du 20 juillet au 3 août 2026 contenait exactement treize préfixes : douze en IPv4 et l’agrégat IPv6 2405:8400::/32.
  • RIPEstat signalait huit voisins observés, sans que cette valeur permette de déduire des contrats de transit, des sessions de peering actives, des volumes de trafic ou une topologie physique.
  • PeeringDB associe également Compass Communications Ltd à AS9245, mais ses données sont maintenues par l’opérateur et ne constituent pas une mesure indépendante des routes ou des interconnexions.
  • Compass présente commercialement des accès, de la voix, des services administrés, un cloud PBX et des produits de centre de données ; ces affirmations décrivent une offre, pas les performances mesurées d’AS9245.
  • Une route visible établit un fait opérationnel daté sur le plan de contrôle public. Elle ne démontre ni la capacité, ni le basculement réussi, ni la disponibilité de bout en bout, ni l’expérience d’un client.

Un identifiant réseau avant d’être une promesse de service

Le nom COMPASS-NZ-AP COMPASS réunit deux plans qu’il faut garder distincts. Le premier est celui de l’identité publique utilisée dans l’annuaire : une entreprise associée à un signal réseau, AS9245. Le second est celui du registre administratif, où APNIC consigne l’identifiant autonome sous le nom COMPASS-NZ-AP et rattache son enregistrement à Compass Communications Ltd. Cette correspondance est suffisamment précise pour relier le nom présenté au public, le numéro de système autonome et le titulaire déclaré. Elle ne transforme pas pour autant le registre en description complète de l’entreprise ou de son réseau.

Un système autonome est visible dans le routage parce qu’il peut apparaître comme origine ou comme participant dans les chemins observés. Ce rôle opérationnel est plus étroit que l’ensemble des activités commerciales d’un fournisseur de télécommunications. Une entreprise peut vendre plusieurs catégories de services, utiliser plusieurs éléments techniques et s’appuyer sur différentes relations opérationnelles. Inversement, la présence d’un ASN dans un registre ne révèle pas automatiquement quels produits, installations, circuits ou clients l’utilisent.

La liaison entre Compass Communications Ltd et AS9245 doit donc rester une liaison d’identité réseau, non une attribution universelle de toute activité de Compass à ce seul identifiant.

Le registre APNIC donne trois repères administratifs utiles. AS9245 porte le nom COMPASS-NZ-AP, son pays est indiqué comme NZ et son statut est actif. Le titulaire déclaré est Compass Communications Ltd. Le dossier mentionne également Network Operations pour les fonctions techniques et administratives, ainsi que IRT-COMPASSCOM-NZ pour la réponse aux incidents. Ces mentions montrent qu’un ensemble cohérent de rôles est consigné autour de la ressource. Elles favorisent l’exactitude de l’identification et offrent des points de référence pour la tenue du registre.

Aucun de ces champs ne constitue cependant une mesure de fonctionnement. Le pays n’est pas une carte des zones effectivement desservies. Le statut actif n’est pas une certification de disponibilité. Le nom d’un rôle opérationnel ne prouve pas le délai de traitement d’un incident. La présence d’un titulaire ne résout pas les questions de propriété économique, de licence, de contrôle exclusif, d’actifs matériels ou de contrats. Le registre dit qui est inscrit à propos de la ressource et comment celle-ci est administrativement décrite ; il ne remplace ni l’observation du routage, ni l’examen des services.

Cette séparation est essentielle pour lire AS9245 correctement. APNIC apporte une identité stable et une continuité documentaire. RIPEstat apporte ensuite une observation datée du comportement public des routes. PeeringDB apporte des déclarations maintenues par l’opérateur au sujet du réseau. Les pages de Compass décrivent enfin la surface commerciale revendiquée. Chacune de ces couches répond à une question différente. Leur rapprochement permet de comprendre la présence réseau de Compass, à condition de ne pas demander à l’une d’elles de prouver ce qu’elle ne mesure pas.

Ce que signifie réellement le statut actif d’APNIC

Le mot « actif » paraît intuitivement fort. Dans un contexte commercial, il peut évoquer un service en fonctionnement, une société en activité ou une infrastructure disponible. Dans un registre de ressources numériques, sa portée est plus précise : il qualifie l’objet enregistré. Il indique que la ressource n’est pas présentée dans ce dossier comme inactive. Il ne dit rien, à lui seul, de la propagation de routes BGP au moment où un lecteur consulte le registre.

La distinction devient visible lorsque le registre est comparé au relevé RIPEstat du 3 août 2026. APNIC fournit le cadre administratif d’AS9245 ; RIPEstat indique séparément que l’ASN était annoncé à l’heure de la capture. Si les deux informations étaient équivalentes, cette seconde observation n’ajouterait rien. Or elle ajoute précisément le fait opérationnel daté qui manque au registre : des collecteurs ont constaté une origine dans le routage public. La cohérence entre les deux sources renforce l’identification, mais elle ne fusionne pas leurs fonctions.

Le statut actif n’atteste pas davantage une autorisation de route. Une annonce vue par des collecteurs n’est pas automatiquement une preuve de validité cryptographique, de conformité à une politique de routage ou de légitimité exclusive. Les éléments disponibles ne permettent pas de conclure sur la validité RPKI des préfixes, sur l’existence d’autorisations de type ROA, sur la correction de chaque chemin ou sur la manière dont les réseaux tiers filtrent les annonces. La tenue du registre et l’observation du protocole sont deux pièces du dossier, non une décision juridique ou technique universelle.

La même prudence s’applique au champ pays. NZ situe l’enregistrement dans son contexte administratif. Il n’établit ni la position physique de chaque équipement, ni l’emplacement d’un client, ni le parcours d’un paquet, ni l’étendue garantie de la couverture. Une route peut être visible depuis de nombreux points sans révéler où se trouvent les accès qui l’utilisent. Une déclaration commerciale de réseau national ne peut pas non plus être convertie, sans mesure supplémentaire, en cartographie de la portée réelle d’AS9245.

La valeur du registre réside donc moins dans une promesse implicite que dans la précision de la correspondance. AS9245, COMPASS-NZ-AP et Compass Communications Ltd forment une chaîne d’identité vérifiable. Network Operations et IRT-COMPASSCOM-NZ complètent la représentation administrative. Cette chaîne permet ensuite d’interroger les observations de routage sous le bon identifiant. Elle évite de confondre un nom commercial, un alias d’annuaire et un numéro de réseau. Elle n’autorise pas à remplir les zones inconnues par des suppositions sur les actifs ou la qualité de service.

Une observation de routage arrêtée dans le temps

RIPEstat signalait AS9245 comme annoncé le 3 août 2026 à 00:00:00 UTC. L’heure appartient au constat. Sans elle, le mot « annoncé » pourrait être lu comme une propriété permanente. Or le routage public évolue : les préfixes visibles, les chemins, les voisins observés et les collecteurs disponibles peuvent changer. Le relevé établit ce que les données montraient à l’instant de la requête, pas une garantie avant ou après cet instant.

L’aperçu RIPEstat associait le titulaire COMPASS-NZ-AP - COMPASS NZ à AS9245. Le rapport de routage comptait douze préfixes IPv4 couvrant 25 600 adresses et un préfixe IPv6 correspondant à 65 536 équivalents /48. Cette combinaison indique une empreinte à double pile dans le plan de contrôle public : l’origine apparaissait dans les deux familles d’adresses. Elle ne dit pas que chaque produit de Compass fournit les deux protocoles, que tous les clients disposent d’IPv6 ou que les deux piles offrent une qualité comparable.

Les quantités décrivent l’espace annoncé selon la réponse, non la capacité du réseau. Une adresse n’est pas une unité de débit. Un grand préfixe ne mesure ni le trafic qui le traverse, ni le nombre de clients qu’il dessert, ni le nombre d’équipements actifs. De même, le nombre de préfixes ne révèle pas les raisons opérationnelles de leur segmentation. Les données ne montrent pas si les découpages répondent à des choix d’ingénierie, à des contraintes historiques, à des politiques de propagation ou à d’autres besoins.

L’équivalence IPv6 en /48 demande une précaution supplémentaire. Elle exprime la taille de l’espace sous une convention utile à la comparaison ; elle ne compte pas 65 536 réseaux clients réellement utilisés. Elle ne prouve ni l’affectation de chacun de ces blocs, ni leur accessibilité, ni leur usage commercial. La seule conclusion solide est que le relevé comptait un préfixe IPv6 annoncé et exprimait sa taille comme 65 536 équivalents /48.

Le qualificatif « double pile » doit donc rester attaché à l’empreinte de routage. Il décrit la présence observée de routes IPv4 et IPv6 associées à AS9245. Il ne constitue pas un test de service. Pour établir que des utilisateurs peuvent effectivement envoyer et recevoir du trafic dans les deux familles, il faudrait des observations portant sur les chemins de données, les points d’accès concernés, les résolveurs, les équipements terminaux et les conditions de service. Rien de tel n’est contenu dans les valeurs du relevé.

Cette limite ne diminue pas l’intérêt de l’observation. La visibilité conjointe d’IPv4 et d’IPv6 fournit un signal opérationnel plus concret qu’une simple fiche administrative. Elle montre qu’au moment capturé, AS9245 participait publiquement au routage des deux familles. Mais la force de ce signal dépend précisément de sa formulation étroite : un fait observé, daté et quantifié, sans transformation en promesse de performance.

Treize préfixes dans une fenêtre bornée

La requête sur les préfixes annoncés couvrait la période du 20 juillet au 3 août 2026. Elle renvoyait exactement treize entrées :

  • 2405:8400::/32
  • 202.90.47.0/24
  • 202.174.6.0/23
  • 117.104.180.0/22
  • 160.238.80.0/22
  • 202.90.56.0/21
  • 117.104.176.0/22
  • 175.176.216.0/22
  • 103.211.120.0/22
  • 202.36.121.0/24
  • 182.48.128.0/19
  • 203.152.96.0/19
  • 103.9.216.0/22

L’ensemble comprend l’agrégat IPv6 2405:8400::/32 et douze préfixes IPv4. Deux entrées sont en /24, une en /23, plusieurs en /22, une en /21 et deux en /19. Cette diversité de tailles décrit la forme publique de l’annonce dans la fenêtre retenue. Elle ne donne pas la structure interne du réseau. Rien ne permet d’associer un bloc particulier à une ville, à un centre de données, à une technologie d’accès ou à une catégorie de clients.

La fenêtre temporelle compte autant que la liste. Le relevé ne prétend pas recenser toutes les ressources qu’une organisation aurait pu recevoir, utiliser ou déclarer à une autre époque. Il rapporte les préfixes que la réponse bornée associait aux annonces d’AS9245 entre les deux dates. Une comparaison avec un inventaire administratif pourrait produire un périmètre différent, car un registre de ressources et un collecteur de routes ne comptent pas la même chose. L’un décrit des enregistrements ; l’autre décrit ce qui a été vu dans le routage.

Cette différence explique aussi pourquoi les treize préfixes RIPEstat ne doivent pas être rapprochés naïvement des chiffres de PeeringDB. PeeringDB déclare 50 préfixes IPv4 et 50 préfixes IPv6 pour le réseau. Ces valeurs, saisies et entretenues dans une base opérateur, peuvent refléter une convention, une capacité déclarée, une configuration attendue ou un périmètre plus large que la photographie des annonces. Les éléments disponibles ne précisent pas comment ces nombres ont été établis. Les traiter comme s’ils étaient une seconde mesure indépendante créerait une fausse contradiction ou une fausse confirmation.

La liste fournit néanmoins un inventaire opérationnel utile. Elle rend l’empreinte observable et permet d’éviter une formule vague selon laquelle Compass « serait présent » dans le routage. À la place, il est possible d’indiquer quels préfixes étaient contenus dans la réponse et pendant quelle période la requête a été bornée. Cette précision rend également les limites contrôlables : aucune route supplémentaire ne doit être ajoutée par extrapolation, et aucun des treize blocs ne doit être présenté comme la preuve d’un service déterminé.

Il serait par exemple tentant d’associer les grands blocs IPv4 à une importante clientèle ou l’agrégat IPv6 à un déploiement généralisé. Les données ne le permettent pas. La taille de l’espace annoncé n’indique pas son taux d’utilisation. Elle ne distingue pas les adresses affectées, réservées, internes à une offre, attribuées à des équipements ou simplement routables. Elle ne mesure pas non plus le trafic. Une route annonce une possibilité dans le plan de contrôle ; elle ne révèle pas combien de communications empruntent effectivement ce chemin.

La lecture la plus robuste est donc sobre : treize préfixes apparaissaient dans la réponse couvrant le 20 juillet au 3 août 2026, dont douze en IPv4 et un en IPv6. Ils matérialisent l’empreinte publique observée d’AS9245 pendant cette fenêtre. Leur présence ne prouve pas la portée géographique, l’usage commercial, l’autorisation d’origine, l’exclusivité du contrôle ou la qualité de fonctionnement de l’espace correspondant.

Ce que les collecteurs RIS voyaient — et ce qu’ils ne voyaient pas

Le rapport de routage indiquait une visibilité depuis 329 pairs IPv4 sur 329 et 321 pairs IPv6 sur 321 dans l’échantillon RIS. Ces fractions sont informatives parce qu’elles conservent leur dénominateur. Elles montrent qu’au moment observé, tous les pairs inclus dans chacune des deux populations rapportées voyaient l’origine. Elles ne signifient pas que chaque réseau sur Internet recevait ces routes, encore moins que chaque utilisateur pouvait atteindre chaque adresse annoncée.

Un collecteur observe le plan de contrôle depuis des points précis. La mention 329 sur 329 décrit l’accord de l’échantillon IPv4 retourné, non une enquête exhaustive de tous les systèmes autonomes. La fraction 321 sur 321 joue le même rôle pour IPv6. D’autres réseaux peuvent appliquer des politiques différentes, filtrer certains préfixes, manquer temporairement une annonce ou ne pas appartenir à l’échantillon. La formulation correcte doit donc toujours conserver les mots « pairs RIS échantillonnés » et la date de capture.

La visibilité du plan de contrôle n’est pas la connectivité du plan de données. Un pair peut apprendre une route sans qu’un service applicatif réponde à l’adresse visée. Des paquets peuvent rencontrer des problèmes au-delà du point observé. Des politiques internes, des équipements, des circuits d’accès ou des systèmes terminaux peuvent influencer l’expérience sans apparaître dans la table BGP du collecteur. À l’inverse, un incident local chez un utilisateur ne se reflète pas nécessairement dans l’annonce globale du préfixe.

Les fractions ne mesurent pas non plus la qualité des chemins. Elles n’expriment ni latence, ni perte, ni congestion, ni débit. Elles ne disent pas si les chemins ont changé, s’ils sont économiquement préférables ou s’ils reposent sur une diversité physique. Une route reçue par tous les pairs échantillonnés peut être associée à des performances très variables selon l’emplacement, l’heure, le réseau d’accès et le trafic. Le nombre de collecteurs qui voient l’origine n’est donc pas un score de service.

Le relevé comportait également huit voisins observés. Dans un graphe de routage, cette donnée suggère plusieurs adjacences visibles autour d’AS9245. Elle ne révèle toutefois pas la nature contractuelle de chaque relation. Un voisin BGP observé peut apparaître pour différentes raisons, et la seule observation du chemin ne suffit pas à distinguer de manière certaine un fournisseur de transit payé, un pair sans règlement, un client ou une relation technique particulière. Elle ne prouve pas non plus qu’une session directe était active entre deux réseaux au moment exact où un autre collecteur a vu le chemin.

Huit voisins ne signifient pas huit chemins physiques indépendants. Plusieurs relations logiques peuvent partager des fibres, des conduits, des bâtiments, des équipements, des fournisseurs en amont ou des zones de défaillance. À l’inverse, une seule relation logique peut reposer sur une architecture plus complexe que ce que montre le chemin AS. Sans données physiques et opérationnelles, il est impossible de calculer la redondance à partir du seul nombre de voisins.

La forte visibilité dans l’échantillon reste une observation substantielle. Elle indique qu’AS9245 ne se limitait pas à un objet administratif dormant dans la capture étudiée : son origine apparaissait largement chez les pairs RIS interrogés en IPv4 comme en IPv6. Cette conclusion est solide tant qu’elle n’est pas élargie. Elle ne doit devenir ni « accessible partout », ni « hautement résilient », ni « sans panne », ni « correctement autorisé ». La précision du dénominateur protège la valeur du constat contre ces glissements.

Une chronologie de visibilité, pas un certificat de continuité

RIPEstat donnait comme première route observée 203.98.24.0/24 le 18 août 2000 à 08:00:00 UTC. La route la plus récente dans la réponse était 202.90.56.0/21 à l’heure de la requête, le 3 août 2026 à 00:00:00 UTC. Ces deux repères offrent une profondeur historique à l’identité de routage. Ils indiquent que les données consultées associaient une observation ancienne et une observation contemporaine à AS9245.

La distance entre ces dates ne prouve pas une annonce ininterrompue. « Première observation » ne signifie pas que RIPEstat ou ses sources ont capturé chaque seconde depuis lors. « Dernière observation » ne garantit pas que la route est restée stable pendant tout l’intervalle. Des changements d’annonces, des retraits, des variations de chemin ou des périodes non visibles peuvent exister sans être résumés par les deux extrémités. Les repères ne forment pas un relevé de disponibilité.

Ils ne constituent pas davantage une chronologie commerciale. Le fait qu’une route soit observée en 2000 ne permet pas de conclure quels services Compass offrait alors, quels clients l’utilisaient ou quelle infrastructure la portait. De la même manière, la route 202.90.56.0/21 vue à la date de la requête ne peut pas être reliée à un produit actuel sans une preuve spécifique. Les préfixes sont des éléments du routage ; les produits sont des offres commerciales. Leur relation ne doit pas être inventée.

Ces dates peuvent néanmoins éclairer la notion de continuité opérationnelle si elle est formulée comme une question, non comme une conclusion. L’identité AS9245 possède une trace publique qui s’étend entre une première observation historique et une capture récente. Cette trace invite à examiner la manière dont un réseau conserve une présence routable au fil du temps, adapte son espace annoncé et maintient ses informations de registre. Elle ne suffit pas à évaluer la disponibilité continue d’un service.

La continuité documentaire et la continuité du routage ne sont pas non plus identiques. APNIC peut conserver un objet cohérent alors que les annonces évoluent. Un collecteur peut voir des routes alors que certains champs administratifs deviennent anciens. Dans le cas présent, les noms et l’ASN s’alignent entre APNIC, RIPEstat et PeeringDB, ce qui réduit l’ambiguïté d’identité. Cet alignement ne mesure toujours pas la fraîcheur de chaque déclaration commerciale ou la qualité de chaque opération.

La chronologie doit ainsi être utilisée comme une structure de preuve minimale : une première route observée, une dernière route dans la réponse et une photographie détaillée à l’heure de requête. Elle montre que le réseau possède une histoire visible dans les données de routage. Elle ne permet pas d’écrire une histoire continue de sa performance, de ses incidents ou de sa croissance.

PeeringDB : une déclaration opérateur, pas un second collecteur

La fiche PeeringDB portant l’identifiant réseau 6849 nomme Compass Communications Ltd et l’associe à AS9245. Elle classe le réseau dans le type Cable/DSL/ISP, lui attribue une portée Asia Pacific et indique une politique générale ouverte. Elle déclare également 50 préfixes IPv4 et 50 préfixes IPv6. Ces champs complètent la représentation publique du réseau, mais leur provenance leur impose une interprétation différente de celle des données RIPEstat.

PeeringDB repose ici sur des informations maintenues par l’opérateur. La fiche exprime donc la manière dont le réseau se présente aux acteurs de l’interconnexion. Le type Cable/DSL/ISP offre un contexte fonctionnel. La portée Asia Pacific situe l’ambition ou le champ déclaré. Une politique générale ouverte signale une orientation annoncée envers le peering. Rien de cela ne démontre qu’une session particulière était active le 3 août 2026.

Le mot « ouverte » ne vaut pas acceptation automatique de toute demande. Une politique générale peut coexister avec des conditions techniques, opérationnelles ou commerciales que les champs disponibles ne détaillent pas. Elle n’indique pas avec qui AS9245 échange effectivement du trafic, où les sessions se trouvent, quels volumes passent, ni si une relation est directe. Elle ne permet pas non plus de déterminer quels voisins relevés par RIPEstat correspondent à des pairs, à des fournisseurs ou à d’autres types de relations.

Les valeurs de 50 préfixes IPv4 et 50 préfixes IPv6 doivent être conservées comme déclarations. Elles ne sont pas interchangeables avec les douze préfixes IPv4 et le préfixe IPv6 du rapport de routage. La différence peut résulter des objectifs distincts des deux bases, de conventions de saisie, de périodes de mise à jour ou de périmètres de comptage. Les éléments disponibles ne permettent pas de choisir une explication. Il serait donc erroné d’affirmer que l’une des sources invalide l’autre.

La comparaison est malgré tout instructive. Elle montre pourquoi le mot « préfixe » n’a pas toujours la même portée pratique dans deux jeux de données. Un champ opérateur peut renseigner les partenaires potentiels sur la taille déclarée du réseau ou sur une attente de configuration. Un collecteur recense ce qu’il voit selon une requête et une fenêtre précises. Pour mesurer le routage public à une date donnée, l’observation RIPEstat est la référence pertinente. Pour comprendre la présentation du réseau dans l’écosystème du peering, la fiche PeeringDB apporte le contexte approprié.

PeeringDB ne mesure ni le trafic ni la capacité. Une liste ou un nombre de préfixes ne fournit aucun débit. Une portée régionale ne prouve aucune couverture garantie. Une politique ouverte ne quantifie pas la redondance. La présence de l’entreprise dans la base ne confirme pas l’état physique d’une installation ou d’une interconnexion. Ces limites doivent rester visibles, surtout lorsque les informations sont rapprochées de déclarations commerciales sur un réseau national ou des centres de données.

L’alignement nominal reste important : Compass Communications Ltd et AS9245 apparaissent ensemble chez APNIC comme dans PeeringDB, tandis que RIPEstat observe l’ASN annoncé. Trois plans indépendants par leur fonction convergent ainsi sur l’identité de base. Le registre administratif, la base opérateur et l’observation de routes racontent une histoire cohérente sur le nom du réseau. Ils ne fournissent pas trois mesures indépendantes de sa résilience.

L’offre commerciale de Compass et la frontière d’AS9245

Compass indique avoir commencé ses activités en 1995. L’entreprise se décrit comme néo-zélandaise, indépendante et dotée d’un réseau national. Ses pages présentent la fibre, le VDSL, l’ADSL, la connectivité rurale, la voix, le cloud PBX, les services administrés et les produits de centre de données. Cette diversité explique pourquoi AS9245 peut constituer un identifiant pertinent pour comprendre une partie de sa présence Internet. Elle ne permet pas d’attribuer chaque offre au même chemin de routage.

Une page commerciale répond d’abord à la question de ce qui est proposé. Elle ne décrit pas nécessairement les dépendances techniques de chaque produit. Une offre de voix peut mobiliser des systèmes qui ne sont pas visibles comme simples routes d’origine. Un service administré peut s’appuyer sur plusieurs fournisseurs, plateformes ou circuits. Un accès rural peut avoir une chaîne technique différente d’un accès fibre. Les faits disponibles ne donnent pas ces architectures et ne doivent pas être complétés par analogie.

L’affirmation d’un réseau national est également une déclaration de l’opérateur. Elle ne devient pas une carte de couverture garantie par la seule présence de préfixes dans BGP. Les treize préfixes observés ne portent aucune étiquette géographique dans la réponse bornée. Ils ne disent pas quelles zones de Nouvelle-Zélande sont desservies, à quelles conditions ou avec quelles performances. Le champ NZ d’APNIC ne remplit pas ce rôle non plus.

L’indépendance revendiquée par Compass ne constitue pas une conclusion sur sa propriété économique. Les données disponibles n’établissent ni bénéficiaire effectif, ni structure de groupe, ni contrôle capitalistique. Il est possible de rapporter que Compass se présente comme indépendante et néo-zélandaise, tout en laissant ouverte la question juridique plus large. Le titulaire APNIC, Compass Communications Ltd, fournit une identité légale déclarée pour AS9245, pas une analyse de l’actionnariat.

Les produits d’accès donnent une raison de s’intéresser à la continuité, mais ils ne la démontrent pas. Pour un utilisateur, la résilience dépend de l’ensemble du parcours : accès local, équipements, alimentation, transport, interconnexion, services de nommage, applications et systèmes de destination. L’annonce d’un préfixe par AS9245 n’observe qu’une partie de cet ensemble. Même une visibilité totale chez les pairs RIS échantillonnés ne teste pas la boucle locale ou l’équipement d’un client.

La surface commerciale et la surface de routage doivent donc être rapprochées avec méthode. Compass décrit une gamme de services ; AS9245 montre une identité et une empreinte publique. Le lien entre les deux existe au niveau de l’opérateur, puisque APNIC et PeeringDB associent l’ASN à Compass Communications Ltd. En revanche, aucun élément ne permet d’affirmer qu’un préfixe précis porte un produit précis, qu’un centre de données utilise une route précise ou qu’un client bénéficie d’un chemin déterminé.

Cette frontière évite deux erreurs opposées. La première consisterait à ignorer le routage et à réduire Compass à sa communication commerciale. La seconde consisterait à considérer AS9245 comme une représentation exhaustive de tous les services de l’entreprise. La lecture la plus fidèle conserve les deux plans : une offre décrite par l’opérateur et une empreinte réseau observée, reliées par une identité commune mais séparées par des questions techniques encore ouvertes.

Centres de données, interconnexions et SLA revendiqués

La page consacrée aux centres de données attribue à l’offre de Compass des installations à Auckland et Hamilton, des relations d’interconnexion et un SLA de 99,99 %. Ces éléments sont pertinents pour comprendre la manière dont l’opérateur présente sa capacité de service. Ils ne sont pas des mesures indépendantes des installations, des interconnexions ou du résultat effectif du SLA.

Le vocabulaire de l’exploitation mérite une prudence particulière. Dire qu’une entreprise « opère » une installation n’établit pas nécessairement la propriété juridique du bâtiment, du terrain, des équipements ou de chaque composant. Les modalités peuvent inclure différents droits, contrats ou responsabilités que la page disponible ne décrit pas. En l’absence de documents supplémentaires, il faut conserver la formulation attribuée : Compass associe Auckland et Hamilton à son offre de centre de données.

Les relations d’interconnexion mentionnées sur une page opérateur ne prouvent pas l’état instantané de sessions BGP. Elles ne disent pas si toutes les relations sont actives, dans quels lieux elles fonctionnent, quels produits les utilisent ou quel trafic elles transportent. Elles ne montrent pas davantage que les huit voisins observés par RIPEstat correspondent exactement aux partenaires nommés. Une relation commerciale, une connexion physique et une adjacence visible dans un chemin BGP sont trois notions qui peuvent se recouper sans être identiques.

Le SLA de 99,99 % est une affirmation attachée à une offre. Sans la définition contractuelle de son périmètre, de sa période, de ses exclusions et de son mode de calcul, il ne peut pas être converti en mesure historique. Il ne signifie pas que tous les services de Compass ont atteint ce niveau, que chaque client bénéficie des mêmes conditions ou que l’ensemble d’AS9245 possède une disponibilité de 99,99 %. Un engagement commercial et un résultat mesuré sont deux faits distincts.

AS9245 n’apporte pas la preuve manquante. La visibilité d’un préfixe dans RIS peut persister pendant qu’un service particulier connaît une dégradation, tout comme un service local peut rester accessible malgré un changement de route vu ailleurs. BGP n’observe pas directement la température d’une salle, l’alimentation d’un équipement, le fonctionnement d’une application ou la disponibilité d’un circuit d’accès. Il ne calcule pas non plus le respect d’un SLA.

La présence IPv4 et IPv6 ne suffit pas davantage à établir une redondance. Les deux familles peuvent partager des dépendances physiques ou logiques. Les données publiques examinées ne montrent ni les fibres, ni les conduits, ni l’alimentation, ni les équipements, ni les chemins internes. Elles ne permettent pas de déterminer si un basculement a été testé ou réussi. Toute conclusion sur la diversité réelle des chemins dépasserait donc le niveau de preuve.

Les déclarations relatives aux centres de données gardent cependant une utilité. Elles indiquent les surfaces où des questions opérationnelles deviennent importantes : hébergement, interconnexion, disponibilité et continuité. Elles aident à comprendre pourquoi Compass entretient une identité de routage publique et une fiche PeeringDB. Elles ne répondent pas elles-mêmes à ces questions. Pour passer de la description de l’offre à l’évaluation de la résilience, il faudrait des mesures, des contrats précisément délimités et des observations techniques supplémentaires.