Résumé

  • Les éléments déjà publiés par BTW établissent que DFINFRA apparaît comme contact administratif et technique associé à l’AS210860 dans la RIPE Database. Cette visibilité ne démontre ni l’existence d’une personne morale, ni la propriété de l’ASN, ni le contrôle opérationnel du réseau.
  • La présente enquête examine l’étape suivante : relier le signal de registre aux droits de maintenance, aux autorisations de route, aux préfixes annoncés et à une activité BGP observable. Les instantanés de sources ont bien été conservés, mais leurs valeurs de champ actuelles ne sont pas vérifiables dans la projection disponible.

Le changement d’état qui compte

Dans les enquêtes sur les ressources Internet, un nom inscrit dans un registre peut avoir une valeur opérationnelle très différente selon la couche à laquelle il correspond. Il peut désigner un contact administratif, une équipe technique, une organisation, un mainteneur autorisé ou un acteur qui contrôle effectivement des annonces de routes. Ces catégories sont souvent voisines dans les interfaces publiques, mais elles ne sont pas interchangeables.

Pour DFINFRA et l’AS210860, la donnée publiée précédemment par BTW constitue un signal précis : DFINFRA est associé à l’AS210860 comme contact administratif et technique dans la RIPE Database. Cette observation justifie une vérification plus poussée. Elle ne permet pas, à elle seule, de conclure que DFINFRA est un opérateur télécom, une institution juridique, le titulaire actuel des ressources ou l’entité qui émet les routes.

Le changement d’état qu’il faudrait démontrer est plus exigeant. Il faudrait établir une chaîne cohérente entre l’identité visible dans le registre, l’autorité exercée sur les objets de ressources, la capacité d’autoriser des préfixes et l’apparition de ces préfixes dans des observations de routage. Tant que cette chaîne n’est pas établie, la conclusion économiquement prudente reste celle d’un signal institutionnel à vérifier.

Une enquête qui sépare les couches de preuve

La première couche est celle du registre d’autonomous system. Elle peut contenir un nom, une organisation, des contacts ou des références de maintenance. Elle répond à la question : « quel nom est publiquement associé à l’ASN ? » Elle ne répond pas nécessairement à la question : « qui exerce aujourd’hui le contrôle effectif sur les ressources ? »

La deuxième couche concerne les droits d’autorisation et de maintenance. Les objets de route, les relations entre mainteneurs et ressources, ainsi que les mécanismes d’autorisation peuvent transformer une simple association nominale en preuve plus substantielle. Mais cette transformation suppose que les valeurs actuelles soient visibles et que l’on puisse les rattacher sans ambiguïté au même acteur.

La troisième couche est celle du routage observé. Les préfixes annoncés, leur origine, leur présence dans les données de routage et leur historique peuvent montrer qu’un ASN est effectivement utilisé dans le réseau. Là encore, l’existence d’une annonce ne prouve pas automatiquement que le nom d’un contact administratif contrôle l’annonce. Elle doit être rapprochée des droits et des identités enregistrés dans les autres couches.

La quatrième couche est opérationnelle et économique. Un contrôle réel peut produire des conséquences observables : gestion d’un portefeuille de préfixes, relation avec des transitaires ou des pairs, continuité de service, décision de réallocation ou modification des coûts et obligations associés aux ressources. Sans cette jonction, un contact de registre demeure une indication de recherche, pas une démonstration de pouvoir de marché ou de contrôle technique.

Ce que le paquet de sources permet d’établir

Pour cette enquête, des instantanés horodatés ont été conservés à partir de plusieurs familles de sources publiques : la fiche aut-num de la RIPE Database, une recherche inverse sur les objets de route, les données RIPEstat sur l’ASN, les préfixes annoncés, l’état et l’historique du routage, les premières et dernières observations RIS, une fiche PeeringDB, ainsi que les pages bgp.tools et Hurricane Electric BGP.

Les points d’accès documentés sont les suivants : fiche aut-num RIPE pour AS210860, recherche RIPE des routes associées, vue d’ensemble RIPEstat, préfixes annoncés dans RIPEstat, état du routage dans RIPEstat, historique du routage dans RIPEstat, première et dernière observation RIS, fiche PeeringDB, vue bgp.tools de l’AS210860 et vue Hurricane Electric BGP.

Le paquet de sources établit donc que les bonnes familles de vérification ont été ciblées et que des instantanés ont été créés le 9 septembre 2026. Il n’établit pas, dans la projection actuellement accessible, les valeurs détaillées des champs recherchés. Il ne permet donc pas de confirmer l’AS-name, l’organisation, les mainteneurs, les objets de route, les préfixes annoncés, l’état actuel du routage, les dates de première ou dernière observation, les voisins ou les informations PeeringDB.

Cette distinction est essentielle. Dire que les contenus de réponse ne sont pas disponibles dans la projection documentaire n’équivaut pas à dire que les registres sont vides, que l’ASN n’annonce aucun préfixe ou que DFINFRA ne contrôle pas la ressource. L’absence de valeur inspectable est une limite de l’enquête, non une observation d’inactivité.

Le mécanisme causal : du nom au contrôle

Le mécanisme à tester comporte plusieurs maillons. Un nom inscrit comme contact peut d’abord être relié à une organisation ou à une personne identifiable. Cette identité peut ensuite être liée à des droits de maintenance ou à une autorité sur les objets de ressources. Ces droits peuvent, à leur tour, soutenir des autorisations de route ou la gestion de préfixes. Enfin, les données BGP peuvent montrer que les mêmes ressources sont effectivement originées ou administrées par l’acteur identifié.

Si le premier maillon échoue, le contact ne peut pas être attribué de manière fiable à une entité juridique ou opérationnelle. Si le deuxième échoue, l’identité ne démontre aucune capacité d’action sur les objets de ressources. Si le troisième échoue, la visibilité du registre ne se traduit pas en autorisation de routage. Si le quatrième échoue, il n’existe pas de preuve indépendante que cette autorité soit exercée dans le réseau réel.

La conséquence économique suit la même logique. Une identité associée à un ASN ne crée pas, par elle-même, un actif contrôlable, un pouvoir de négociation ou une capacité à modifier les flux de trafic. Ces effets apparaissent seulement lorsque l’acteur peut exercer des droits sur des ressources et que ces droits ont une expression opérationnelle : annonces, maintenance, interconnexion, continuité ou changement de gestion.

Ce qui reste ouvert

La question nouvelle par rapport à la couverture précédente est donc étroite mais déterminante : les données d’autorisation et de routage actuelles relient-elles effectivement DFINFRA à l’AS210860 au-delà de la seule présence du nom dans un registre ?

Plusieurs réponses restent possibles. Les données pourraient montrer une continuité entre le contact, l’organisation et les mainteneurs. Elles pourraient révéler une relation historique sans activité actuelle. Elles pourraient associer l’ASN à un autre acteur opérationnel. Elles pourraient aussi être insuffisantes pour établir une relation, même si l’ASN demeure techniquement visible dans certains systèmes.

Le paquet actuel ne permet pas de choisir entre ces scénarios. Il identifie exactement les éléments à contrôler, mais ne fournit pas les valeurs nécessaires pour trancher. L’incertitude porte donc non pas sur l’existence des endpoints consultés, mais sur la capacité à inspecter et à relier leurs champs à une identité opérationnelle.

Cette limite empêche également toute conclusion sur l’inactivité. Une absence d’annonce dans une valeur non inspectable ne serait pas une preuve d’absence d’annonce. De même, la présence éventuelle d’un objet de route ne prouverait pas automatiquement que DFINFRA en est le bénéficiaire économique ou l’opérateur. Chaque position doit être attribuée à la source correspondante et reliée à une valeur observable.

Pourquoi la différence compte pour la gouvernance des ressources

Les registres Internet remplissent plusieurs fonctions à la fois : ils rendent des identités visibles, facilitent le contact administratif, structurent des responsabilités techniques et permettent à différents systèmes de sécurité ou de routage de référencer des ressources. Cette polyvalence crée un risque d’interprétation excessive. Un champ de contact peut être lu comme une preuve de propriété, alors qu’il ne fait parfois qu’indiquer le canal par lequel une question doit être posée.

Pour les investisseurs, les partenaires réseau et les organismes de gouvernance, la différence modifie le niveau de confiance à accorder à une information. Un contact stable peut constituer un indicateur précoce de changement. Mais un indicateur n’est pas encore un fait de contrôle. Il devient plus significatif lorsque des sources indépendantes convergent sur l’identité, les droits et l’activité.

C’est aussi pourquoi une modification future du registre pourrait être informative sans être décisive. Un nouveau contact, une nouvelle organisation ou une nouvelle référence de maintenance signalerait un changement institutionnel possible. Pour établir sa portée, il faudrait ensuite observer si les droits sur les ressources et les comportements de routage changent de manière cohérente.

Conclusion : le prochain test est observable, mais pas encore résolu

DFINFRA reste donc un signal de registre associé à l’AS210860, non une preuve autonome de contrôle opérationnel. La démonstration recherchée doit relier identité, autorisation, ressources et routage observé. Le paquet actuel a conservé les sources nécessaires à cette vérification, mais la projection accessible ne permet pas d’inspecter leurs valeurs de champ.

Le prochain test utile est concret : vérifier les données actuelles de l’aut-num, les relations de maintenance, les objets de route et les préfixes effectivement observés, puis comparer ces résultats à l’identité DFINFRA. Tant que ces éléments ne convergent pas, toute conclusion sur la propriété, l’opérateur ou le pouvoir économique de DFINFRA doit rester conditionnelle.

Pour suivre ce signal dans le temps, le point de référence public est l’entrée DFINFRA du répertoire BTW. Cette entrée peut servir à documenter les changements futurs, mais elle ne remplace pas les preuves indépendantes de contrôle.

Sources publiques conservées