Résumé

  • Le 26 octobre 2026, AS139620 — titulaire enregistré : MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY L — annonçait 103.142.144.0/24, 103.142.145.0/24 et 2001:df1:4780::/48, soit 512 adresses IPv4 et un /48, avec une visibilité complète côté IPv4 comme côté IPv6 et sept voisins observés.
  • Le nom enregistré proclame une société publique, la fiche du répertoire classe la même entité en société privée, et aucun document constitutif examiné ici ne tranche entre les deux formulations.
  • Pour qui doit décider s'il appaire, achète du transit ou fait simplement confiance, le routage mesuré est réel et modeste, tandis que les faits corporatifs sont affirmés sans être documentés.

Ce que les routeurs ont vu le 26 octobre

Un relevé de routage est un bon point de départ pour argumenter, parce que personne n'est obligé de vous croire sur parole. Ce jour-là, les points d'observation alimentant RIPEstat attribuaient trois préfixes à l'origine AS139620 : 103.142.144.0/24, 103.142.145.0/24 et 2001:df1:4780::/48 (préfixes annoncés). Chacun porte une chronologie continue du 12 octobre 2026 au 26. La réponse précise aussi une réserve qu'il vaut la peine de répéter : les routes vues par moins de dix pairs RIS en pleine table sont écartées. Un préfixe absent de cette liste n'est pas un préfixe qui n'a jamais existé ; c'est un préfixe que presque personne n'a vu.

Le relevé de statut de routage du même jour donne les totaux : deux préfixes IPv4, 512 adresses, un /48 IPv6, sept voisins observés (statut de routage). La visibilité est le chiffre que je soulignerais. 269 pairs IPv4 sur 269 et 257 pairs IPv6 sur 257 ont déclaré voir cette origine. Ce n'est pas une route qui vacille en bordure de table mondiale : chaque collecteur contribuant à la mesure l'a vue.

512 adresses. Deux /24 et un /48. Pour un opérateur national, c'est assez petit pour tenir dans un seul accès client, dans un seul bloc de service, ou pour ne représenter que la tranche tournée vers le transit de quelque chose de bien plus vaste. Quelle que soit la réalité de MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY L, ce numéro n'en est qu'une extrémité. Rien dans les données ne dit ce que la société exploite d'autre.

Le /23 devenu deux /24

Un détail d'historique mérite plus d'attention qu'on ne lui en accorde d'ordinaire. Le champ first_seen du relevé nomme 103.142.144.0/23, origine 139620, au 2019-09-04T16:00:00 (statut de routage). Le champ last_seen nomme 103.142.145.0/24 au 2026-10-26T08:00:00, et l'ensemble annoncé aujourd'hui contient les deux moitiés sous forme de /24 distincts (préfixes annoncés).

L'arithmétique fait le reste. Un /23, c'est 512 adresses. Les deux /24 sont ce bloc exact coupé en deux. Il y a sept ans, l'observation portait sur un agrégat ; aujourd'hui, elle porte sur deux objets plus précis, annonçant les mêmes 512 adresses.

Je ne vous dirai pas pourquoi. La déagrégation peut relever de l'ingénierie de trafic, d'un filtre qui n'accepte que des /24, d'un client en aval qui prend une moitié, ou d'un tableur. Ce que le relevé soutient est plus étroit, et vaut quand même la peine : le numéro est visible sans interruption depuis septembre 2019 au moins, et la granularité de ce qu'il annonce a changé pendant que le total d'adresses, lui, n'a pas bougé d'un pouce.

Sept voisins, dont deux au-dessus

Le relevé de voisinage en liste sept (voisins). Deux se tiennent à gauche : AS4651, puissance 1109, 1 230 pairs IPv4 et 499 pairs IPv6 ; et AS38082, puissance 568, 1 007 pairs IPv4 et aucun pair IPv6. Cinq se tiennent à droite : AS139595, AS139692, AS139719, AS151482 et AS154481, avec des comptes de pairs IPv4 compris entre 162 et 562, et des pairs IPv6 rattachés à un seul d'entre eux.

« Gauche » et « droite » sont des positions. RIPEstat les déduit de l'endroit où un AS apparaît dans les chemins observés, et c'est de la topologie, pas un contrat. Un voisin de droite est un réseau pour lequel AS139620 est apparu en amont dans des chemins que les collecteurs ont vus. Appeler ces réseaux des clients transforme un chemin en relation commerciale : exactement le saut discret que cet article essaie d'éviter. Ce pourraient être des clients. Ce pourraient être des entités sœurs derrière un transitaire commun. Ce pourraient être les clients d'un client.

Les deux voisins de gauche comptent pour une autre raison : ils sont plus gros, sur chaque dimension mesurée, et c'est la forme qu'on attend d'un réseau qui achète du transit plutôt qu'il n'en vend. Je ne sais pas qui détient AS4651 ou AS38082 au-delà de leurs numéros. Je ne l'ai pas établi à partir d'un texte source conservé dans ce travail, et je ne vais pas fournir un nom que je n'ai pas vérifié. Les mesures sont l'affirmation. Les noms ne sont pas à moi d'ajouter.

Ce que le registre affiche vraiment

Le versant registre est d'une clarté rafraîchissante. Le WHOIS d'APNIC pour ce numéro renvoie aut-num AS139620, as-name MTNPCL-AS-AP, descr MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY LIMITED, country MM (WHOIS APNIC). Le handle d'organisation associé à ce titulaire est ORG-MTNP1-AP (requête APNIC). La vue d'ensemble de RIPEstat confirme et ajoute le bloc : 139578-140601, décrit « Assigned by APNIC », au sein du registre IANA des numéros de système autonome 32 bits, titulaire « MTNPCL-AS-AP - MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY LIMITED », annoncé vrai pour la fenêtre de 08:00 le 26 octobre (vue d'ensemble AS).

Notez maintenant ce qui manque. Aucune date d'allocation. Aucune date d'enregistrement. Aucun statut d'objet au-delà du « Assigned by APNIC » du bloc. Aucune remarque. Si vous voulez savoir quand cette société a reçu le numéro, les documents que j'ai pu lire ne le disent pas.

Cette absence a pris des dents, parce que deux documents que je voulais consulter n'ont pas répondu du tout. L'objet RDAP autnum d'APNIC pour 139620 n'a renvoyé aucun enregistrement lisible dans ce travail (RDAP APNIC), et la copie hébergée sur rdap.org — un service différent, et l'un des deux documents que la fiche du répertoire désigne comme sa preuve — n'a pas abouti non plus (rdap.org). Tous deux sont cités ici comme des documents tentés qui n'ont pas répondu. Une URL en échec n'est pas une preuve. C'est un trou avec une adresse.

Deux documents, une note

C'est ici que l'article a commencé.

La fiche de répertoire de ce titulaire affiche une confidence_score de 0,95. Son tableau evidence_basis contient deux entrées, chacune à 0,82 : le document autnum de rdap.org et la vue d'ensemble AS de RIPEstat. La fiche a été mise à jour le 17 juin 2026 et porte le statut queued_for_profile_article (fiche du répertoire Réservé au Cercle stratégique).

Le lecteur voit 0,95. Les intrants sont 0,82, 0,82, et l'un des deux n'a pas pu être ouvert. Ce n'est pas un scandale. C'est un artefact de notation, et les artefacts de notation pullulent. C'est en revanche un rappel précis de ce qu'est un indice de confiance : une affirmation sur une affirmation. 0,95 décrit la croyance de la fiche dans son propre contenu. Cela ne signifie pas que 95 pour cent des paragraphes ci-dessus ont été confirmés indépendamment, et aucun lecteur ne devrait repartir avec cette idée en tête.

La ligne data_gaps de la fiche est plus franche que son chiffre de tête : vérifier le pays de l'entité juridique, les services actuels, les actifs visibles, les liens de maison mère ou de filiale, et les contacts de direction responsables. Cinq choses à vérifier, énumérées à l'intérieur d'une fiche qui affiche 0,95.

Le nom dit publique. Le champ dit privée.

Vient la collision.

Le legal_name de la fiche est MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY L. Son unique alias est TELECOMMUNICATION NETWORK PUBLIC COMPANY L — la même chaîne, le pays en moins. Son legal_type est private_company.

Un nom qui proclame une société publique, classé sous un type juridique de société privée. Deux explications tiennent debout, et d'ici je ne peux pas choisir entre elles. Soit le champ legal_type est faux, soit le nom est une enseigne commerciale qui ne reflète pas la forme enregistrée. Les deux arrivent. Ni l'une ni l'autre n'est établie par ce que j'ai pu retrouver.

Ce que je peux affirmer, c'est ce qui n'est pas arrivé : aucun document constitutif, aucun extrait de registre du commerce, aucun dépôt de forme juridique. L'écart tient donc comme un écart entre deux chaînes d'une même fiche, et non comme la preuve que l'une des deux serait fausse. Qui a besoin de la forme juridique devra aller acheter le certificat.

Une deuxième couture, plus fine, court à côté. La fiche tronque le nom en un « L » final solitaire. Le registre écrit « LIMITED ». Un seul titulaire, deux rendus, et rien ici ne dit lequel correspond aux statuts déposés.

Une troisième couture est la plus révélatrice. hq_country et registration_jurisdiction portent tous deux « Myanmar (Burma) », code pays MM — alors que la ligne data_gaps de la même fiche demande encore de vérifier le pays de l'entité juridique. L'objet affirme une juridiction et, dans le même souffle, reconnaît ne pas l'avoir confirmée.

Un seul ASN, classé virtuel

La fiche ne liste qu'une ressource : AS139620, resource_type asn, statut observé, service ip_transit, pays « Myanmar (Burma) ». Son resource_class est virtual.

Ce mot est un classement, pas un fait sur la société. Dans la grammaire de cette fiche, une ressource virtuelle est un numéro attribué à une organisation sans bloc d'adresses enregistré correspondant sur la même ligne : l'ASN existe, l'annonce existe, l'espace derrière n'est pas attesté ici. C'est une convention de classement. C'est aussi, discrètement, la chose la plus utile de la fiche, parce qu'elle dit exactement ce qui est affirmé — une identité de routage, pas un détenteur d'espace d'adressage.

La couverture de service indique ip_transit et managed_network pour MM avec des rôles de fournisseur, et le tableau répète le rôle deux fois. Deux facettes de contact restreintes existent, toutes deux circonscrites à MM avec les mêmes deux services, et aucune ne porte de nom au-delà de celui de l'organisation elle-même. Rien à qui écrire. Personne à qui attribuer.

Des pièces vides

Quatre collections sont vides : relationships, leadership_contacts, related_events, contextual_references. Trois champs sont nuls : external_id, source_system, first_seen_at.

Lus ensemble, ces constats disent quelque chose de précis. La fiche ne peut pas vous dire qui détient la société, qui la dirige, ce qu'elle a fait l'an dernier, à qui d'autre elle est reliée, ni quand elle est apparue. Elle peut vous dire qu'un numéro existe, qui le registre dit le détenir, et que le système de routage l'a vu annoncer sans interruption depuis septembre 2019 au moins.

Pour un opérateur national historique, c'est un silence étonnant. Pour une ligne de répertoire qui ingère des registres et des données de routage, et peu d'autre chose, c'est exactement le silence qu'on doit attendre. La distinction compte, parce que les deux lectures mènent à des décisions différentes.

Ce qu'il faut vraiment à un lecteur qui doit décider

Supposez que vous pesiez l'idée d'appairer avec ce titulaire, d'acheter du transit chez lui, ou de signer quelque chose. Voici la séparation honnête.

Vérifié, reproductible, le jour même : le numéro existe ; APNIC l'attribue dans le bloc 139578-140601 ; la chaîne du titulaire est celle citée ; et le 26 octobre 2026 l'origine annonçait 512 adresses IPv4 et un /48, avec une visibilité complète et sept voisins observés.

Non vérifié ici : la forme juridique, la juridiction d'incorporation en tant que fait documenté, la date d'allocation, la chaîne de détention, les dirigeants responsables nommés, la clientèle derrière ces cinq voisins de droite, et toute partie du réseau physique de la société au-delà de cet unique AS.

L'écart entre ces deux listes, c'est l'article. Une ligne de registre est un pointeur vers un ensemble de documents. Ce n'est pas les documents. Une annonce de routage est une affirmation de joignabilité un jour donné. Ce n'est pas la description d'une activité.

Ce qui changerait la lecture

Je préfère être corrigée que cohérente, alors voici les falsificateurs. Le fait le plus fort disponible serait la date d'allocation de l'autnum APNIC, ou un certificat d'incorporation, ou les accords d'appairage derrière ces sept relations de voisinage. N'importe lequel d'entre eux fait passer un paragraphe de non résolu à résolu.

Le deuxième plus fort serait un mouvement dans les chiffres : 512 adresses devenant 1 024, les deux /24 se recomposant dans le /23 d'origine, ou l'ensemble des voisins perdant une entrée de gauche. Chacun est daté et vérifiable, ce qu'on ne peut pas dire des faits corporatifs.

La conséquence bornée

MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY L détient un numéro d'AS qui annonce 512 adresses IPv4 et un /48 IPv6 depuis derrière deux réseaux plus gros, visible sans interruption depuis septembre 2019. Sa fiche de répertoire la dit publique dans le nom et privée dans le champ, lui attribue 0,95 construit sur deux intrants à 0,82 dont l'un n'a pas pu être ouvert, et ne liste rien du tout sur qui la possède ou la dirige.

Ce n'est pas l'histoire d'une société imaginaire. Le numéro est réel, les adresses sont réelles, les pairs sont réels. C'est une histoire sur ce qu'une ligne de registre peut porter et sur l'endroit où le portage s'arrête — et sur une chaîne de forme juridique que personne, dans la chaîne, n'est actuellement payé pour réconcilier.