ULTRANET COLOMBIA S.A.S.: ce que le périmètre public d'AS274310

Summary

ULTRANET COLOMBIA S.A.S. dispose d'une présence publique cohérente avec celle d'un fournisseur d'accès fibre: son site commercialise Internet et Internet avec télévision, tandis que LACNIC attribue AS274310 à l'entreprise.
Les vues publiques inspectées montrent un ensemble de routes étroit, composé de 45.196.223.0/24 et de 2803:1430::/32. Le second préfixe est directement attribué à ULTRANET COLOMBIA S.A.S. par LACNIC; le premier est annoncé par AS274310 mais relève, dans RDAP, d'un espace lié à Cloud Innovation et au registre AFRINIC.
RIPEstat et bgp.tools ne font apparaître qu'un voisin BGP dans l'observation retenue, AS262191, associé à Liberty Networks de Colombia S.A.S. Ce constat décrit une dépendance visible, pas la totalité certaine des chemins physiques ni les termes d'un contrat de transit.
Aucun élément du paquet documentaire ne démontre l'exploitation d'un centres de données, d'une offre de colocation, d'une salle informatique, d'une capacité électrique ou d'un dispositif de refroidissement. La résilience doit donc être évaluée à partir de ce qui est observable, tout en nommant clairement les informations qui manquent.

Une entreprise d'accès, observée par sa frontière publique

Pour comprendre ULTRANET COLOMBIA S.A.S., il faut commencer par résister à une confusion fréquente dans l'analyse des infrastructures numériques. Un fournisseur d'accès possède nécessairement des équipements, des points de concentration, des liens de transport et des lieux où ces équipements sont installés. Cela ne signifie pas que les sources publiques permettent de qualifier ces lieux de datacenters, d'en déduire une activité de colocation ou d'attribuer à l'entreprise une capacité d'hébergement commercial.

L'infrastructure nécessaire à la fourniture d'Internet et l'infrastructure publiquement démontrée ne sont pas deux formulations équivalentes.

Le site d'UltraNet place l'entreprise du côté de l'accès fixe. Il met en avant une connexion par fibre optique et des formules combinant Internet et télévision. Des paliers commerciaux de 200 à 800 « mégas » apparaissent dans les sections consacrées à Cali et à Manizales. Ces indications décrivent une proposition destinée aux abonnés; elles ne mesurent ni le trafic réellement échangé sur Internet, ni la capacité de collecte, ni la redondance du cœur de réseau. Elles établissent néanmoins la fonction économique de base: ULTRANET COLOMBIA S.A.S.

vend de la connectivité d'accès, et AS274310 constitue désormais une partie observable de la manière dont cette activité rejoint le reste de l'Internet.

Cette distinction donne au dossier son véritable objet. Il ne s'agit pas de dresser un inventaire imaginaire de bâtiments, de baies ou de groupes électrogènes. Il s'agit de lire une frontière publique: les ressources d'adressage qui apparaissent dans les registres, les préfixes que les collecteurs voient dans BGP, le voisin par lequel ces annonces sont visibles, les informations volontairement déclarées dans PeeringDB, ainsi que les villes associées aux contacts et au geofeed. Ensemble, ces éléments ne décrivent pas tout le réseau.

Ils montrent toutefois où se concentrent les faits vérifiables et, par conséquent, les principales questions de dépendance.

Cette approche est particulièrement importante pour un système autonome récent. Une faible quantité de routes n'implique pas automatiquement une faible base de clients, pas plus qu'une inscription récente ne prouve un réseau construit de zéro. Une entreprise peut avoir fourni des services avant d'exploiter son propre ASN, utiliser des transports privés non visibles ou faire annoncer d'autres ressources selon des arrangements qui ne figurent pas dans la photographie consultée. À l'inverse, posséder un ASN ne garantit ni diversité de transit, ni continuité énergétique, ni capacité à absorber une panne majeure.

L'intérêt d'AS274310 tient donc moins à un classement de taille qu'à la possibilité de séparer, avec précision, l'observé du supposé.

AS274310, un signal récent mais concret

LACNIC enregistre AS274310 comme actif et directement attribué à ULTRANET COLOMBIA S.A.S. La date d'enregistrement figurant dans le dossier est le 2 février 2026, avec une mise à jour le lendemain. RIPEstat identifie le même détenteur et indique que l'ASN est annoncé dans la fenêtre d'observation du 20 juillet 2026. bgp.tools associe également le numéro à l'entreprise. La convergence de ces trois surfaces donne un socle robuste à l'identité réseau: l'ASN n'est pas seulement un numéro cité par le site de l'opérateur, mais une ressource enregistrée et visible dans les données de routage publiques.

Ce socle doit toutefois être interprété à sa juste portée. Le registre confirme l'attribution administrative. La visibilité BGP confirme que des collecteurs ont reçu des routes dont AS274310 est l'origine. Aucun de ces éléments ne révèle, à lui seul, le nombre d'abonnés, le taux d'occupation des liens, la topologie métropolitaine, le mode de collecte des quartiers desservis ou la qualité mesurée aux heures de pointe.

Une route peut être visible alors que le trafic qui l'emprunte varie fortement; un ASN peut être actif tout en dépendant d'un petit nombre de relations externes; une attribution peut être récente alors que l'activité commerciale est plus ancienne.

Le caractère récent de l'enregistrement mérite néanmoins attention, car il situe l'analyse dans une phase où la couche publique paraît encore compacte. PeeringDB indique que sa fiche réseau a été créée le 3 juin 2026 et mise à jour quelques jours plus tard. Le site de l'entreprise et son geofeed fournissent parallèlement des repères sur les services et la localisation. Cette séquence suggère non pas une conclusion sur l'âge de toute l'entreprise, que les sources utilisées ne permettent pas d'établir, mais une mise en visibilité récente de son identité de routage autonome.

Deux préfixes visibles, deux histoires de ressources différentes

RIPEstat recense, entre le 6 et le 20 juillet 2026, deux préfixes annoncés par AS274310: le bloc IPv4 45.196.223.0/24 et le bloc IPv6 2803:1430::/32. bgp.tools présente le même couple et résume l'origine en une route IPv4 et une route IPv6. PeeringDB, dans les informations déclarées par le réseau, indique également un préfixe de chaque famille. La concordance est forte: dans les vues publiques retenues, le périmètre annoncé est bien formé de ces deux blocs.

Ce nombre restreint rend l'empreinte lisible, mais il ne faut pas le transformer en affirmation absolue. RIPEstat précise implicitement une limite structurelle de ce type de donnée: les collecteurs ne voient pas toutes les routes privées, et les routes dont la visibilité est très faible peuvent ne pas apparaître dans certains produits dérivés. Les annonces peuvent aussi changer après la fenêtre observée. La formulation correcte est donc « deux préfixes visibles dans les sources et pendant la période examinée », et non « seulement deux routes existent dans tout le réseau ».

Le couple est intéressant parce qu'il ne repose pas sur une provenance uniforme. Le préfixe IPv6 est une ressource LACNIC directement rattachée à ULTRANET COLOMBIA S.A.S. Le préfixe IPv4 est, lui, associé par RDAP à un espace relevant d'AFRINIC et lié à Cloud Innovation, tout en étant annoncé par AS274310 et localisé en Colombie dans le geofeed de l'opérateur. Sur le plan opérationnel, les deux routes font partie de la frontière visible. Sur le plan de l'attribution, elles racontent deux relations différentes entre l'entreprise, le registre et la ressource.

Cette différence n'est pas un détail administratif. Les équipes qui évaluent un fournisseur doivent savoir si une adresse est attribuée directement, utilisée dans le cadre d'un accord, louée, prêtée, sous-allouée ou simplement annoncée pour le compte d'un tiers. Les modalités déterminent les responsabilités en cas d'abus, de changement de fournisseur, de litige ou de retrait de la ressource. Le paquet documentaire ne révèle pas le contrat relatif à 45.196.223.0/24. Il permet seulement d'affirmer que le bloc est visible derrière AS274310, qu'UltraNet le place à Cali dans son geofeed et que le registre public ne le présente pas comme une allocation directe LACNIC à l'entreprise.

Pour un petit périmètre, chaque route porte une part importante de l'identité publique. Une erreur de politique, une perte d'annonce ou un problème de validation sur un seul bloc peut affecter une fraction substantielle de l'espace visible. Cela ne permet pas de calculer le nombre d'utilisateurs touchés, car le paquet ne fournit pas la répartition des clients ni celle du trafic. Cela justifie toutefois un niveau d'attention élevé sur la qualité des objets de routage, la cohérence des registres, la surveillance des annonces et les procédures de bascule.

L'IPv6 fournit la chaîne de preuve la plus directe

La chaîne documentaire de 2803:1430::/32 est la plus simple. LACNIC marque le réseau IPv6 comme actif et attribué à ULTRANET COLOMBIA S.A.S. L'objet renvoie à AS274310 comme numéro d'origine et reprend le geofeed publié par l'entreprise. L'entité LACNIC de l'opérateur relie elle aussi le bloc IPv6 et l'ASN. RIPEstat voit le préfixe dans BGP et dans les données de registre, tandis que bgp.tools le liste parmi les routes originées. Il existe donc une continuité entre titulaire, ressource, origine et localisation déclarée.

Cette continuité ne doit pas être confondue avec une preuve d'usage généralisé. Disposer d'un /32 IPv6 offre un espace d'adressage considérable, mais la taille mathématique du bloc n'indique pas le nombre d'abonnés effectivement activés en IPv6, la proportion de trafic natif, la politique de délégation aux foyers ou la présence de services en double pile. Aucune mesure du paquet ne montre non plus la qualité des chemins IPv6 par rapport aux chemins IPv4. Une allocation est une capacité d'adressage; son exploitation réelle doit être mesurée séparément.

Elle reste néanmoins importante pour la maturité réseau. Une allocation directe permet à l'opérateur de définir un plan d'adressage stable et d'éviter que toute sa présence IPv6 publique repose sur l'espace d'un prestataire. Elle offre aussi une identité plus nette dans les registres. Pour les clients, le bénéfice potentiel se situe dans la continuité de l'adressage et dans l'accès à l'Internet IPv6, mais le bénéfice réalisé dépend de la configuration du dernier kilomètre, des équipements fournis, du DNS, de la sécurité et des chemins de transit.

Le geofeed place 2803:1430::/32 à Cali, dans le département de Valle del Cauca, avec le code postal 760015. Cette information améliore la géolocalisation des adresses par les services qui consomment ce format. Elle ne localise pas un routeur, une salle technique ou un bâtiment précis. Un préfixe déclaré à Cali peut desservir des utilisateurs au-delà d'un seul site, et la sortie vers Internet peut emprunter des infrastructures situées ailleurs. La bonne lecture est celle d'une intention de géolocalisation opérationnelle, publiée par ULTRANET COLOMBIA S.A.S., et non celle d'un plan de ses installations.

Enfin, la présence de la route dans BGP sur la fenêtre étudiée établit une réalité plus forte qu'une allocation inutilisée: le bloc est annoncé. Elle ne donne cependant ni disponibilité historique, ni engagement de service, ni preuve de redondance. Pour savoir si l'IPv6 d'UltraNet constitue une couche résiliente, il faudrait observer la stabilité dans la durée, la diversité des chemins, les interruptions, la latence et le comportement lors des incidents. Le registre fournit le point de départ; il ne remplace pas cette mesure.

L'IPv4 révèle une séparation entre annonce, géolocalisation et attribution

Le cas de 45.196.223.0/24 exige davantage de discipline. RIPEstat et bgp.tools voient AS274310 comme origine de la route. Le geofeed officiel d'UltraNet l'associe à la Colombie, à Valle del Cauca et à Cali. L'objet RDAP consulté indique lui aussi le pays CO et comporte une remarque renvoyant au geofeed de l'entreprise. Pour l'analyse de la frontière publique, il est donc raisonnable de dire que ULTRANET COLOMBIA S.A.S. annonce et géolocalise ce préfixe dans son environnement opérationnel.

Mais RDAP ne rattache pas ce bloc à une allocation LACNIC de l'entreprise. La réponse passe par le registre AFRINIC et montre un espace lié à Cloud Innovation. Le dossier ne fournit aucun document contractuel expliquant comment UltraNet utilise la ressource. Il serait donc incorrect de décrire 45.196.223.0/24 comme un bloc IPv4 « possédé » par ULTRANET COLOMBIA S.A.S., ou comme une attribution directe comparable au /32 IPv6. L'annonce BGP, la géolocalisation et le titre administratif sont trois dimensions qu'il faut conserver séparées.

Cette séparation est fréquente dans un Internet où l'espace IPv4 disponible est rare et où des opérateurs recourent à des ressources obtenues par différents mécanismes. Elle n'est pas, en elle-même, la preuve d'un problème. Elle crée cependant des dépendances de gouvernance supplémentaires. Si l'accès au bloc repose sur un accord externe, la continuité peut dépendre du maintien de cet accord, de la qualité des enregistrements et de la capacité des parties à coordonner les mises à jour.

Le paquet ne permet pas de mesurer ce risque ni d'identifier les clauses applicables; il permet de voir que la provenance administrative mérite d'être vérifiée.

RIPEstat indique que le préfixe est présent à la fois dans BGP et dans les données de type whois, avec RADB comme source IRR mentionnée. Cette cohérence réduit une forme d'ambiguïté: la route n'apparaît pas comme une annonce sans aucun objet documentaire dans la vue examinée. Elle ne règle pas la question de l'attribution ultime, pas plus qu'elle ne garantit que tous les filtres de tous les réseaux sont correctement configurés.

Pour une diligence opérationnelle complète, il faudrait examiner la création et la maintenance des objets, les autorisations d'origine, les mécanismes de validation et la capacité à les mettre à jour rapidement.

Le principal enseignement n'est donc pas que l'IPv4 d'UltraNet serait anormale. Il est que la frontière visible combine une ressource directe en IPv6 et un espace IPv4 dont la provenance administrative est externe. Cette asymétrie doit apparaître dans toute évaluation sérieuse de la continuité. Elle invite à demander quelles garanties encadrent l'utilisation du /24, qui peut agir sur ses enregistrements, quelle procédure s'applique en cas de changement et comment la clientèle serait migrée si la ressource devenait indisponible.

AS262191, une dépendance BGP visible et non un contrat démontré

Dans la photographie retenue, RIPEstat recense un seul voisin unique pour AS274310: AS262191. Son produit de cohérence de routage montre le même numéro dans les imports et les exports observés en BGP, tout en signalant que cette relation n'apparaît pas dans la vue whois correspondante. bgp.tools présente AS262191 dans ses tableaux d'amont et de pair pour IPv4 comme pour IPv6. Le nom associé est Liberty Networks de Colombia S.A.S.

La convergence de ces vues justifie une conclusion prudente mais importante: AS262191 est l'unique dépendance BGP visible d'AS274310 dans les sources inspectées, pour les deux familles d'adresses. Si cette visibilité reflète le chemin opérationnel courant, elle concentre la portée externe des deux préfixes sur la même relation observée. Une perturbation de session, de transport ou de politique entre les deux ASN pourrait alors toucher simultanément la connectivité IPv4 et IPv6 visible. Le conditionnel est essentiel, car les données publiques ne décrivent pas nécessairement chaque lien de secours ou chaque chemin privé.

Il serait en revanche excessif d'affirmer que ULTRANET COLOMBIA S.A.S. n'a physiquement qu'un seul opérateur amont, qu'elle est commercialement « mono-transitée » ou qu'un contrat exclusif la lie à Liberty Networks de Colombia S.A.S. BGP montre des relations d'annonce; il ne publie ni les factures, ni les accords de niveau de service, ni la propriété des fibres, ni les mécanismes de protection de transport. Deux sessions logiques vers le même ASN pourraient emprunter des chemins physiques distincts. À l'inverse, deux fournisseurs apparents pourraient partager une même infrastructure sous-jacente.

Le paquet ne permet de confirmer aucun de ces scénarios.

Le mot « pair » demande la même réserve. Les interfaces publiques peuvent classer ou présenter une relation à partir des chemins observés et de leurs propres conventions. Cette étiquette ne prouve pas un peering sans règlement, une relation symétrique ou une politique commerciale précise. PeeringDB indique une politique ouverte pour ULTRANET COLOMBIA S.A.S., mais ne liste aucun point d'échange où une session publique serait établie. L'interprétation la plus solide reste donc celle d'une adjacence BGP observable avec AS262191.

Cette adjacence offre un axe de surveillance concret. Une analyse longitudinale pourrait vérifier si d'autres voisins apparaissent, si les chemins se diversifient, si l'origine reste stable et si les deux préfixes suivent toujours la même dépendance. Elle pourrait également comparer les vues de plusieurs collecteurs afin de réduire le risque qu'un seul point d'observation masque un chemin. Le dossier actuel ne mène pas cette étude historique; il fixe une base au 20 juillet 2026.

Pour une entreprise cliente, la question utile n'est pas de savoir si le mot « unique » peut être appliqué sans nuance. Elle est de comprendre les domaines de défaillance. Les deux familles IP disposent-elles de transports géographiquement distincts ? Les équipements de bordure sont-ils doublés ? Les sessions vers AS262191 se terminent-elles dans des lieux différents ? Existe-t-il une route de secours non visible dans la table globale ? Les opérations peuvent-elles modifier rapidement une politique en cas d'incident ?

Sans réponses, la présence d'un seul voisin public reste un signal de concentration qui mérite une vérification directe.

Cali et Manizales: des signaux complémentaires, pas un plan de sites

Les sources officielles répartissent les repères géographiques entre Cali et Manizales. Le geofeed place les deux préfixes à Cali, dans Valle del Cauca. Les pages commerciales et juridiques affichent des points de contact dans les deux villes. L'entité LACNIC donne une adresse de titulaire à Manizales, tandis que l'objet de l'ASN associe aussi des éléments de contact à Cali. Cette combinaison est cohérente avec une entreprise dont les fonctions administratives, commerciales ou techniques peuvent être réparties, mais elle ne révèle pas l'architecture exacte de cette répartition.

Il serait tentant de transformer le geofeed en carte d'infrastructure. Ce serait une erreur. Un geofeed sert à indiquer la localisation prévue d'adresses IP afin d'améliorer leur traitement géographique. Il ne certifie ni l'emplacement d'un routeur de bordure, ni celui d'un noeud d'accès, ni le bâtiment où se trouvent les équipements. La localisation d'un préfixe peut représenter une zone de clientèle ou une convention opérationnelle. Elle ne donne aucune information sur l'alimentation électrique, les chemins de fibre, la propriété du site ou les protections contre les sinistres.

Les adresses de contact ne remplissent pas davantage ce rôle. Une adresse de titulaire dans un registre peut être administrative. Un bureau commercial peut recevoir les clients sans héberger le cœur de réseau. Une adresse technique peut correspondre à une équipe plutôt qu'à une installation. Le paquet signale même une petite variation dans le libellé de la rue de Cali entre des surfaces inspectées, ce qui suffit à déconseiller une description trop précise du lieu sans vérification supplémentaire. La ville est un signal robuste; la fonction exacte de chaque adresse ne l'est pas.

Cette distinction n'affaiblit pas l'intérêt de la géographie. Elle déplace la question vers la résilience. Si Cali porte la géolocalisation des deux préfixes et si Manizales apparaît dans l'identité du titulaire ainsi que dans la présence commerciale, comment les services sont-ils reliés entre les deux villes ? Les abonnés de Manizales sortent-ils vers Internet par une infrastructure locale, par Cali ou par un autre point ? Les opérations disposent-elles de chemins interurbains indépendants ? Un incident régional peut-il affecter simultanément la collecte et la sortie ?

Aucune réponse n'est contenue dans les sources, mais la coexistence des deux villes rend ces questions nécessaires.

Elle a aussi une dimension de communication. Un fournisseur local peut gagner en confiance en distinguant clairement ses zones de service, ses bureaux, ses points techniques et ses périmètres de géolocalisation. Sans exiger la publication de détails sensibles, une description des régions couvertes et des principes de redondance permettrait aux clients professionnels de mieux comprendre le service. À ce stade, les informations publiques montrent une présence à Cali et à Manizales, mais pas la relation technique entre ces présences.

Ce que PeeringDB dit réellement de la posture réseau

La fiche PeeringDB d'AS274310 classe ULTRANET COLOMBIA S.A.S. dans la catégorie Cable/DSL/ISP. Cette auto-description correspond au site de l'entreprise et renforce le cadre de fournisseur d'accès. La fiche déclare un trafic compris entre 20-50Gbps, un ratio Mostly Inbound, une portée South America et une politique de peering Open. Elle indique aussi qu'aucun contrat ni emplacement préalable n'est requis selon les champs déclarés.

Ces données sont utiles parce qu'elles expriment la manière dont le réseau souhaite être compris par l'écosystème d'interconnexion. Un trafic majoritairement entrant est compatible avec un réseau d'accès dont les utilisateurs consomment davantage de contenus qu'ils n'en publient vers l'extérieur. Une politique ouverte peut signaler une volonté d'établir de nouvelles relations. La fourchette de trafic donne un ordre de grandeur déclaré, mais elle ne constitue ni une mesure indépendante, ni une capacité garantie, ni une moyenne vérifiée.

Il serait particulièrement imprudent d'utiliser 20-50Gbps comme preuve de capacité d'infrastructure physique. La valeur ne révèle pas la somme des ports, le niveau de pointe, la marge disponible, la capacité engagée auprès d'un transporteur ou le débit livré aux abonnés. Elle ne dit pas non plus si le trafic est mesuré sur une interface, agrégé sur plusieurs liens ou estimé. PeeringDB est une base communautaire alimentée par les réseaux eux-mêmes; sa force réside dans la coordination, pas dans l'audit financier ou technique.

Deux zéros sont tout aussi importants: la fiche ne liste aucun point d'échange et aucun site. Les compteurs d'IX et de facilities sont à zéro, sans association netixlan ou netfac visible dans le paquet. Cela signifie qu'aucune présence de ce type n'est publiée dans PeeringDB pour AS274310 à la date observée. Cela ne prouve pas que l'entreprise n'utilise aucun site technique, aucune interconnexion privée ou aucun transport vers un lieu tiers. Un réseau ne peut pas fonctionner sans équipements physiques; il peut simplement ne pas les déclarer dans cette base.

La combinaison des champs dessine donc une posture en devenir: un fournisseur d'accès avec une fourchette de trafic auto-déclarée, une politique d'ouverture, un préfixe IPv4 et un préfixe IPv6, mais sans présence d'interconnexion ou de site publiquement attachée à son objet PeeringDB. Pour un partenaire potentiel, l'étape suivante serait de demander où une session peut réellement être établie, sur quelles capacités, selon quelles conditions techniques et avec quelle redondance. La fiche ouvre la conversation; elle ne la conclut pas.

Pourquoi l'absence de preuve de centres de données est un résultat éditorial

Les sources examinées ne montrent aucune salle de centres de données, aucune offre de colocation, aucun inventaire de baies, aucune puissance électrique disponible, aucune architecture de refroidissement, aucun temps d'autonomie de générateur et aucun espace d'interconnexion de type meet-me room. Elles ne montrent pas davantage une plateforme d'hébergement ou une capacité de serveurs commercialisée. Le site vend de l'accès fibre et de la télévision. Les registres décrivent des ressources Internet. PeeringDB décrit un réseau de type fournisseur d'accès et ne lui rattache aucun site.

Cette absence ne permet pas d'affirmer que ULTRANET COLOMBIA S.A.S. ne possède aucun local technique. Ce serait physiquement peu plausible pour un opérateur d'accès, et surtout non démontré. Elle interdit plutôt une autre affirmation: présenter l'entreprise comme un opérateur de centres de données ou de colocation sur la base du seul fait qu'elle exploite un ASN et une infrastructure fibre. Une analyse rigoureuse doit pouvoir conclure que le dossier public s'arrête avant les installations, sans combler ce silence par des hypothèses.

Ce résultat a une valeur pratique. Les achats de connectivité mélangent souvent plusieurs couches: accès local, transport, transit IP, hébergement d'équipements et continuité énergétique. Un fournisseur peut maîtriser certaines couches et en sous-traiter d'autres. Si un client suppose qu'un opérateur fibre possède aussi les bâtiments où son trafic sort, il peut mal évaluer les dépendances. Inversement, l'absence de marque de centres de données ne signifie pas nécessairement une mauvaise qualité de service. Elle signifie que le modèle de responsabilité doit être demandé et documenté.

Les preuves nécessaires seraient concrètes. Pour qualifier une capacité de colocation, il faudrait au minimum identifier une offre, un site, des conditions d'accès et des caractéristiques techniques. Pour évaluer la résilience d'un noeud, il faudrait connaître les alimentations, les groupes de secours, le refroidissement, la détection incendie, la sécurité et les chemins de fibre. Pour parler de diversité de transport, il faudrait distinguer fournisseurs logiques et tracés physiques. Aucun de ces éléments ne figure dans le paquet.

La prudence protège aussi l'entreprise contre une lecture erronée. Attribuer à UltraNet des capacités qu'elle ne revendique pas publiquement créerait des attentes injustifiées. Le dossier le plus fidèle est celui d'un fournisseur colombien d'accès fibre dont l'identité autonome est désormais visible, avec deux routes et une adjacence BGP publique concentrée. Les bâtiments et les systèmes qui rendent ce service possible existent nécessairement quelque part; leur nature, leur propriété et leurs garanties demeurent hors du champ démontré.

La surface réglementaire est visible, mais incomplètement vérifiée

UltraNet publie sur son site le numéro de Registro Unico de TIC 96005573. La même référence apparaît dans les éléments de bas de page et dans la surface juridique examinée. Cette répétition montre que l'entreprise présente publiquement ce numéro comme partie de son identité réglementaire. Le portail de MinTIC figure parmi les sources du paquet, mais la consultation n'a pas fourni de contenu statique exploitable permettant une confirmation indépendante pendant la collecte.

La formulation doit donc rester exacte: le numéro est publié par l'entreprise; il n'a pas été vérifié dans une réponse du registre officiel au cours de cette recherche. Cette nuance n'est pas une accusation. Les portails interactifs, les délais de réponse et les mécanismes techniques peuvent empêcher une capture automatisée sans remettre en cause le contenu déclaré. Elle définit simplement le niveau de preuve disponible au moment de l'article.

La page juridique décrit par ailleurs une politique de gestion du trafic. Selon cette publication, l'entreprise ne bloque pas les contenus sauf obligation légale et présente ses mesures de gestion comme raisonnables et non discriminatoires. Le site met aussi à disposition des liens vers des indicateurs de service pour 2024 et 2025. Les feuilles correspondantes n'ayant pas été récupérées dans le paquet, aucune valeur de plainte, de qualité ou de délai ne peut être citée ici. Seule l'existence de la surface de publication est établie.

Un document de protection des données personnelles est également accessible depuis le site et a répondu comme fichier PDF pendant la collecte. Ce document confirme l'existence d'une couche de conformité publiée, mais il n'a pas été utilisé pour tirer des conclusions sur le réseau. Une politique de données renseigne sur les obligations envers les clients; elle ne prouve ni l'architecture BGP, ni la sécurité technique, ni la résilience physique.

Pour l'évaluation globale, cette surface réglementaire est encourageante dans la mesure où elle donne des points de contrôle publics. Elle reste distincte de la preuve opérationnelle. Le prochain niveau de transparence consisterait à rendre facilement vérifiables l'inscription officielle, les indicateurs de service et la portée des politiques, tout en maintenant des informations cohérentes entre le site, les registres réseau et les canaux de contact.

La résilience se joue dans des domaines de défaillance encore invisibles

À partir des faits disponibles, la résilience d'AS274310 ne peut pas être résumée par un chiffre. Elle doit être décomposée en domaines de défaillance. Le premier est celui du routage externe. Deux préfixes sont visibles, et le même voisin BGP apparaît pour IPv4 et IPv6. Si les deux familles dépendent du même équipement, du même transport ou du même point de terminaison, une panne commune pourrait les affecter. Si plusieurs sessions et chemins physiques existent derrière cette relation, le risque pourrait être plus faible. Les sources ne permettent pas de trancher.

Le deuxième domaine est celui de l'adressage. L'IPv6 repose sur une allocation directe LACNIC, tandis que l'IPv4 visible appartient à un espace administrativement lié à Cloud Innovation dans le registre AFRINIC. La continuité du service IPv4 peut donc comporter une dépendance documentaire ou contractuelle supplémentaire. Il faudrait savoir qui contrôle les objets nécessaires, quelles autorisations couvrent l'annonce et quel plan existe si l'utilisation du bloc change. Rien ne permet de conclure qu'un changement est imminent; c'est la structure de dépendance qui importe.

Le troisième domaine est géographique. Cali concentre la géolocalisation des deux préfixes, tandis que Manizales apparaît dans l'enregistrement du titulaire et dans les points de contact. Sans carte des transports et des sorties Internet, il est impossible de savoir si cette présence répartit le risque ou si les deux villes convergent vers une même infrastructure. La distance entre des bureaux ne garantit pas la diversité du réseau. Seuls des chemins physiquement séparés, des équipements indépendants et des procédures de bascule testées pourraient établir une véritable protection régionale.

Le quatrième domaine est énergétique et immobilier. Le paquet n'indique pas où se trouvent les routeurs, les équipements d'accès ou les systèmes de gestion. Il ne décrit ni alimentation secourue, ni autonomie, ni refroidissement. Une coupure électrique locale, un incident de bâtiment ou une restriction d'accès peuvent être aussi déterminants qu'une erreur BGP. En l'absence de données, la seule conclusion honnête est que ce domaine n'a pas été vérifié.

Le cinquième domaine est opérationnel. Un réseau compact peut bénéficier de décisions rapides et d'une connaissance locale approfondie. Il peut aussi dépendre d'un petit nombre de personnes capables de modifier le routage, de traiter les abus et de coordonner les fournisseurs. Le registre donne des contacts administratifs, techniques et d'abus, mais pas l'organisation de l'astreinte, la séparation des rôles, les procédures d'escalade ou la fréquence des exercices. Ces éléments sont essentiels à la restauration et restent privés.

Le sixième domaine est celui de la mesure. PeeringDB déclare 20-50Gbps, mais aucune série temporelle indépendante ne montre la charge, la marge ou les pertes. Les plans commerciaux annoncent des débits aux abonnés, mais ne prouvent pas le dimensionnement agrégé. Pour juger la résilience, il faudrait observer la disponibilité, la latence, la perte de paquets, le temps de réparation et le comportement pendant les pointes. Sans ces données, la capacité déclarée ne peut servir de substitut à la qualité vécue.

Ces domaines ne forment pas une liste d'échecs. Ils forment une carte des questions. Les informations publiques montrent que le réseau est actif, qu'il annonce IPv4 et IPv6 et qu'il s'inscrit dans un cadre de service local. Elles montrent aussi une concentration visible et plusieurs limites de preuve. La diligence doit donc porter sur la façon dont UltraNet réduit les risques communs, et pas seulement sur le nombre de préfixes ou le débit inscrit dans une base communautaire.

Ce qu'un client professionnel devrait demander

Un client qui envisage une connexion critique auprès d'UltraNet devrait commencer par demander un schéma de responsabilité, même simplifié. Qui fournit le dernier kilomètre ? Qui assure le transport entre la zone de service et la bordure Internet ? Où s'arrête la responsabilité de ULTRANET COLOMBIA S.A.S. et où commencent celles de partenaires ? Cette cartographie est plus utile qu'une promesse générale de fibre, car elle identifie les interlocuteurs en cas de panne.

La diversité doit ensuite être testée avec des questions physiques. Deux liens entrent-ils par des parcours distincts ? Utilisent-ils des conduites, des poteaux, des chambres ou des équipements communs ? Les sessions externes terminent-elles sur des routeurs différents et dans des sites différents ? La visibilité d'un seul ASN voisin ne répond pas à ces questions. Une redondance logique au sein de AS262191 pourrait être solide; une seconde relation visible pourrait elle-même partager le même tracé. Seule la description des domaines communs permet d'évaluer la protection.

Pour l'adressage, le client devrait clarifier le service IPv6 effectivement fourni et le statut de l'IPv4. Reçoit-il une délégation IPv6 stable ? Les équipements du client et de l'opérateur prennent-ils en charge le double empilement sans traduction inutile ? Pour 45.196.223.0/24, quelles garanties permettent à AS274310 de continuer l'annonce et de maintenir les objets de routage ? Ces questions n'exigent pas la divulgation de clauses commerciales sensibles; elles exigent une assurance sur la continuité.

Les engagements de service devraient distinguer disponibilité de l'accès, disponibilité du routage et performance. Un lien local peut rester synchronisé alors que la route externe est perdue. Inversement, BGP peut rester visible alors qu'un segment d'accès est interrompu. Les délais de réparation, les canaux d'escalade, les fenêtres de maintenance et les modalités de mesure doivent être associés à chaque couche. Les liens publics vers des indicateurs de service pourraient contribuer à cette discussion lorsque les données seront accessibles et interprétables.

Enfin, le client devrait demander des preuves de test. Un plan de secours non exercé apporte moins de protection qu'une bascule répétée et mesurée. Les journaux d'incident anonymisés, les résultats d'exercices, les temps de convergence et les contrôles de capacité peuvent démontrer une discipline opérationnelle sans révéler une topologie sensible. Le dossier public ne contient pas ces preuves. Il permet de savoir précisément pourquoi elles sont nécessaires.

Méthode, temporalité et limites de la photographie

Cette analyse repose exclusivement sur quinze sources arrêtées dans un paquet collecté le 20 juillet 2026. Elles comprennent les pages officielles d'UltraNet, son geofeed, les objets RDAP pertinents, plusieurs produits RIPEstat, bgp.tools, PeeringDB et le point d'entrée public de MinTIC. Chaque source répond à une question différente. Le site décrit l'offre et les informations publiées par l'entreprise. LACNIC établit l'identité des ressources relevant de son registre. RDAP expose la provenance de l'IPv4. Les vues BGP décrivent ce que des collecteurs ont observé.

PeeringDB contient des déclarations destinées à l'interconnexion.

La concordance entre sources augmente la confiance, mais ne supprime pas leurs limites communes. Plusieurs données sont auto-publiées. Les collecteurs ont une visibilité partielle. Les registres indiquent des droits et des contacts, pas l'état des équipements. Les dates de création d'un objet ne racontent pas toute l'histoire commerciale d'une entreprise. Les absences dans PeeringDB signalent l'absence d'enregistrement public, pas l'absence physique d'une installation.

La temporalité est particulièrement importante pour BGP. Les deux préfixes sont observés sur une fenêtre de deux semaines dans RIPEstat, tandis que le voisinage correspond à une photographie du 20 juillet. Une route retirée avant ou ajoutée après cette période ne serait pas reflétée de la même manière. Les produits dérivés peuvent aussi classer les relations selon des méthodes différentes. Les affirmations de cet article sont donc datées et formulées en termes de visibilité.

Le paquet comporte trois limites documentaires majeures. Premièrement, le portail MinTIC n'a pas fourni de confirmation statique exploitable du numéro RUTIC publié par l'entreprise. Deuxièmement, les feuilles d'indicateurs de service n'ont pas été ouvertes, de sorte qu'aucune valeur n'est utilisée. Troisièmement, aucun document officiel de registre du commerce n'a été capturé pour établir des détails d'incorporation ou d'identification fiscale. L'article s'abstient donc d'en introduire.

Cette méthode peut sembler restrictive, mais elle produit une conclusion plus durable. Elle évite que des chiffres marketing deviennent des mesures de capacité, que des routes annoncées deviennent des actifs possédés, que des voisins BGP deviennent des contrats et que des adresses deviennent des datacenters. Pour une infrastructure critique, la qualité de l'analyse dépend autant des limites respectées que des faits accumulés.

Conclusion: une frontière désormais visible, une résilience encore à documenter

ULTRANET COLOMBIA S.A.S. apparaît dans les sources comme un fournisseur d'accès fibre colombien doté d'une identité de routage autonome active. AS274310 annonce publiquement un /24 IPv4 et un /32 IPv6. Le bloc IPv6 est directement rattaché à l'entreprise dans LACNIC; le bloc IPv4 est exploité dans sa frontière visible mais relève d'un espace lié à Cloud Innovation dans RDAP. Les deux routes sont géolocalisées à Cali par le geofeed officiel.

Le voisinage public concentre l'attention sur AS262191, associé à Liberty Networks de Colombia S.A.S. C'est le seul voisin observé dans les produits consultés et il apparaît pour IPv4 comme pour IPv6. Cette donnée constitue un signal de dépendance externe. Elle ne démontre ni exclusivité commerciale, ni absence de secours privé, ni unicité physique des transports. La prudence n'annule pas le signal; elle en fixe la portée.

Cali et Manizales composent une géographie publique à plusieurs fonctions. La première porte la géolocalisation des préfixes et certains contacts; la seconde apparaît dans l'identité du titulaire et dans la présence de l'entreprise. Sans topologie, cette répartition ne peut être qualifiée de redondance. Elle indique les lieux autour desquels une diligence technique devrait s'organiser.

Surtout, rien dans les quinze sources ne permet de transformer UltraNet en opérateur de centres de données ou de colocation. Aucun hall, aucune baie, aucune puissance, aucun refroidissement, aucun groupe électrogène et aucun point d'interconnexion physique ne sont documentés. Le sujet infrastructurel n'est donc pas un parc immobilier caché derrière l'ASN. Il est la chaîne de dépendances qui relie un service fibre local à deux ressources de routage, à une provenance IPv4 distincte, à un voisin BGP visible et à des opérations dont la redondance reste privée.

Cette frontière publique est suffisamment claire pour être surveillée et suffisamment incomplète pour exiger des questions directes. L'évolution du voisinage, la stabilité des routes, la maintenance des registres, l'apparition de sites d'interconnexion et la publication de garanties de continuité permettront de juger la prochaine étape. Au 20 juillet 2026, la conclusion la plus solide est simple: le réseau d'ULTRANET COLOMBIA S.A.S. est visible; sa résilience physique et organisationnelle n'est pas encore démontrée par le dossier public.

ULTRANET COLOMBIA S.A.S.: ce que le périmètre public d'AS274310 prouve et ce qu'il ne prouve pas