AS60077 rend Cloud.ir visible sur Internet, sans révéler le

Summary

Au 20 juillet 2026, RIPE RDAP et RIPEstat décrivaient AS60077 comme un système autonome actif et annoncé, à l'origine de 18 préfixes IPv4 représentant 14 080 adresses, avec une visibilité auprès de 324 des 325 pairs RIS IPv4 observés.
Le dossier public ne montrait aucun préfixe IPv6 actuellement originaire d'AS60077, ne faisait apparaître qu'AS43754 comme voisin observé et ne révélait dans PeeringDB ni point d'échange ni site déclaré. Ces constats ne prouvent toutefois pas l'absence d'IPv6, de sites ou d'autres chemins privés.
Les pages actives de Cloud.ir établissent l'existence d'une offre commerciale étendue et le SLA en précise certaines limites. Elles ne relient pas chaque service à AS60077 et ne démontrent pas le parcours physique, la capacité utilisable, la diversité indépendante des accès ou le comportement de reprise.
La question utile n'est donc pas de savoir si Asre Dadeha Asiatech possède une présence réseau publique: cette présence est bien documentée. Elle est de déterminer jusqu'où cette visibilité permet d'évaluer la livraison concrète d'un service cloud, et où commencent les zones que les vingt sources ne permettent pas de vérifier.

Une preuve de réseau qui ne doit pas devenir une preuve universelle

L'empreinte d'AS60077 offre un point de départ exceptionnellement précis par rapport à de nombreuses offres cloud dont le réseau reste difficile à attribuer. Un système autonome annoncé laisse des traces que plusieurs registres et observatoires peuvent comparer: un nom, une organisation déclarante, des préfixes, une origine BGP, des voisins observés et, pour certaines routes, une autorisation RPKI. Ces éléments permettent de tester une partie du récit public sans dépendre uniquement du vocabulaire commercial de Cloud.ir.

Cette précision a pourtant une frontière. BGP indique comment des destinations sont annoncées au reste d'Internet; il ne décrit pas automatiquement les bâtiments, les serveurs, les systèmes de stockage ou les contrats qui se trouvent derrière elles. Une route peut être stable et largement vue alors qu'un produit particulier emprunte une autre architecture. À l'inverse, une fonction de service peut être disponible sans être directement identifiable comme un préfixe originaire d'AS60077. Les sources ne fournissent pas de table qui relierait chaque produit, chaque adresse et chaque site.

Il faut donc lire le dossier en plusieurs couches. La première concerne l'identité administrative du réseau. La deuxième concerne son comportement public observé au moment de la collecte. La troisième concerne la surface commerciale de Cloud.ir. La quatrième, plus difficile à documenter, serait celle de la livraison physique et de la reprise: localisation exacte, chemins indépendants, capacité disponible, bascule et restauration. Les trois premières couches contiennent des preuves concrètes. La quatrième reste surtout composée de déclarations de l'opérateur et de questions ouvertes.

Cette séparation n'affaiblit pas les résultats positifs. Elle leur donne une portée exacte. Dire qu'AS60077 est actif, annoncé et très visible dans l'échantillon RIS est une conclusion solide. Dire que cette visibilité démontre à elle seule la résilience de tous les services Cloud.ir serait une extension que le dossier n'autorise pas. L'enjeu de l'analyse est précisément de conserver la force du premier constat sans glisser vers le second.

L'identité administrative d'AS60077 est nette et actuelle

RIPE RDAP inscrit AS60077 sous le nom AT-CLOUD, avec un statut actif. L'organisation déclarante est ORG-ADA42-RIPE / Asre Dadeha Asiatech. L'enregistrement de l'autnum date du 27 juin 2022 et la dernière modification indiquée date du 23 janvier 2026. Ces dates ne prouvent pas une activité commerciale quotidienne, mais elles montrent que l'objet de registre n'est ni anonyme ni figé depuis une époque lointaine.

L'aperçu de RIPEstat complétait cette identité. À l'heure de requête du 20 juillet 2026 à 8 h UTC, il associait AS60077 au détenteur AT-CLOUD Asre Dadeha Asiatech et retournait announced=true. Le registre et l'observation de routage racontaient donc une histoire compatible: le numéro est attribué à l'entité étudiée et il est publiquement annoncé au moment considéré.

Cette compatibilité est importante parce que les différentes sources ne remplissent pas la même fonction. RIPE RDAP décrit un enregistrement administratif. RIPEstat agrège des observations et des données de routage. bgp.tools propose une synthèse publique supplémentaire. Lorsqu'elles convergent sur le nom, le statut et le nombre de préfixes IPv4, la confiance dans l'identification du contrôle réseau augmente. Il ne s'agit plus d'inférer l'opérateur à partir d'un logo ou d'une page de vente.

La convergence ne transforme cependant pas l'organisation déclarante en propriétaire démontré de chaque ressource physique qui sert le produit. Un autnum identifie un domaine de politique de routage. Il ne constitue ni un inventaire d'actifs ni un organigramme opérationnel complet. Le dossier permet d'attribuer AS60077 à Asre Dadeha Asiatech; il ne permet pas de conclure à la propriété des bâtiments, des fibres, des groupes électrogènes, des équipements ou de toute la capacité mentionnée sur les pages de service.

Le nom AT-CLOUD renforce naturellement le rapprochement avec l'offre Cloud.ir, mais le nom ne remplace pas une cartographie technique. La liaison documentaire est plausible et cohérente: les registres identifient Asre Dadeha Asiatech, tandis que les pages officielles présentent Cloud.ir comme une offre de services reposant sur les centres de données d'Asiatech. Ce rapprochement établit un contexte commun. Il ne fournit toujours pas le chemin de bout en bout d'un serveur, d'un VPS, d'un objet stocké ou d'un trafic CDN.

Dix-huit annonces IPv4 forment une empreinte substantielle

Le statut de routage de RIPEstat comptait 18 préfixes IPv4 originés par AS60077 et 14 080 adresses IPv4. La liste des annonces permet de voir comment ce total se compose. Elle inclut 78.110.112.0/21, puis 85.198.8.0/22, 85.198.12.0/22, 85.198.16.0/23, 85.198.19.0/24, 85.198.20.0/23 et 85.198.22.0/23.

Dans l'espace 193.151, les annonces comprennent les blocs 193.151.128.0/22, 193.151.132.0/22, 193.151.136.0/22, 193.151.140.0/22, 193.151.144.0/22, 193.151.148.0/22 et 193.151.152.0/22. Quatre préfixes plus spécifiques complètent l'ensemble: 193.151.156.0/24, 193.151.157.0/24, 193.151.158.0/24 et 193.151.159.0/24. Cette énumération ne décrit pas l'usage de chaque bloc, mais elle montre que le chiffre global repose sur une série d'annonces identifiables plutôt que sur une estimation commerciale.

À 16 h UTC le 20 juillet 2026, RIPEstat donnait 193.151.156.0/24 comme dernier préfixe observé. Le même statut indiquait que 324 des 325 pairs RIS IPv4 retenus voyaient AS60077. Une telle proportion signifie que l'origine était largement visible dans ce système de collecte au moment de la mesure. Elle ne garantit pas que chaque internaute disposait d'un chemin performant, mais elle exclut l'image d'une annonce seulement marginale ou invisible dans l'échantillon.

bgp.tools présentait lui aussi AS60077 comme un réseau actif, avec 18 préfixes IPv4 originés, aucun préfixe IPv6 originé et AS43754 comme amont. La fiche utilisait notamment une étiquette liée à l'hébergement de serveurs. Cette synthèse est utile comme corroboration publique, mais elle n'ajoute pas une preuve de capacité client. Une étiquette de catégorie décrit la manière dont le réseau est classé; elle ne mesure pas le nombre de machines actives, le taux d'occupation ou le volume de ressources encore disponibles.

L'empreinte peut servir de base de suivi. Une variation du nombre de préfixes, un changement d'origine ou une évolution de la visibilité RIS serait observable dans le temps. Pour une équipe de diligence, ces indicateurs sont plus utiles lorsqu'ils sont horodatés et comparés à des observations ultérieures. Pris isolément, ils donnent une photographie. Comparés dans la durée, ils peuvent signaler une expansion, une contraction, une migration ou un incident à examiner.

Même dans ce rôle de suivi, la prudence reste nécessaire. Les collecteurs n'observent pas chaque session BGP privée et leur vue dépend de leurs points d'observation. Une route vue par presque tous les pairs RIS n'est pas synonyme d'un service sans panne. Elle indique qu'une information de contrôle est largement propagée. La qualité de la livraison dépend encore des chemins de données, de la congestion, des équipements, des sites et des applications que ces annonces ne décrivent pas.

L'espace d'adressage n'est pas une mesure de capacité cloud

Le chiffre de 14 080 adresses IPv4 paraît quantitatif, ce qui le rend facile à surinterpréter. Il mesure la taille théorique des préfixes actuellement attribués à l'origine dans la vue utilisée. Il ne révèle pas combien d'adresses sont affectées, réservées, inutilisées, partagées, filtrées ou consacrées à des fonctions internes. Il ne dit pas non plus combien de clients, de machines virtuelles ou de services correspondent à cet espace.

Une adresse publique peut représenter une machine, un équipement de bordure, une fonction de traduction, une terminaison partagée ou une ressource temporaire. Plusieurs charges peuvent partager une même adresse, tandis qu'une seule architecture peut consommer plusieurs adresses. Le rapport entre espace annoncé et capacité de calcul n'est donc ni fixe ni directement calculable à partir des routes. La même réserve vaut pour le stockage, la mémoire, la bande passante vendable et la puissance électrique.

Cette distinction est centrale dans le cas de Cloud.ir, car le catalogue présente plusieurs familles de produits. Un serveur cloud, un VPS, un service de stockage, un CDN et une gestion de domaines n'exposent pas nécessairement leurs ressources de la même façon. Les vingt sources ne relient pas les 18 préfixes à une ventilation par produit. Elles ne permettent pas davantage d'identifier la part de l'espace réservée à l'infrastructure de contrôle, aux services internes ou aux clients.

La capacité réellement utilisable est une notion opérationnelle et économique. Elle dépend du matériel installé, des limites de surallocation, des réserves de sécurité, de la demande de pointe et des contraintes du site. Elle dépend aussi de la capacité réseau disponible vers les utilisateurs, pas seulement du nombre d'adresses. Aucun de ces paramètres n'est quantifié dans le corpus étudié.

Une analyse rigoureuse doit donc refuser deux raccourcis. Le premier consisterait à traiter les 14 080 adresses comme 14 080 unités commerciales. Le second consisterait à considérer que l'absence de données de capacité signifie qu'il n'existe aucune capacité significative. Le dossier établit une surface IPv4 de taille mesurable; il ne permet pas de convertir cette surface en offre vendable ou en charge soutenable.

Pour un acheteur, le bon usage du chiffre est plus modeste. Il peut servir à vérifier que l'opérateur contrôle une empreinte publique cohérente et à repérer les préfixes associés à un service lors d'essais. Il ne remplace pas un engagement sur les ressources, une architecture de capacité, des seuils de contention ou des preuves de performance. Une donnée de routage devient utile pour la diligence lorsqu'elle est reliée à un produit précis, pas lorsqu'elle est transformée en indicateur universel.

Le préfixe RPKI valide aligne trois types de preuve

Le préfixe 193.151.156.0/24 offre un point de contrôle particulièrement instructif. La validation RPKI de RIPEstat renvoyait le statut valid, avec des ROA couvrant l'origine 60077. Cela signifie que, pour cet échantillon, l'association entre le préfixe annoncé et AS60077 respecte l'autorisation d'origine publiée.

RIPE RDAP rattachait le même préfixe à la plage PA active IR-AT-20210316, enregistrée pour l'Iran et couvrant 193.151.128.0 à 193.151.158.255. L'enregistrement mentionnait ASIATECH-MNT et les contacts administratifs et techniques Asiatech NOC. Une observation BGP, une autorisation RPKI et une attribution de ressource administrative se rejoignent ainsi autour d'un même exemple.

Cet alignement est plus probant qu'une seule ligne de registre. Il montre que l'origine effectivement vue correspond à l'origine autorisée pour le préfixe testé et que l'espace se rattache à une plage gérée sous des identifiants Asiatech. Pour l'attribution réseau, c'est un résultat positif. Il réduit le risque de confondre AS60077 avec un numéro seulement mentionné sur une page ou avec une origine non autorisée pour cet exemple.

La portée de la validation doit pourtant rester étroite. Le résultat concerne 193.151.156.0/24 au moment de la requête. Le corpus ne fournit pas un audit RPKI détaillé de chacun des 18 préfixes. Il serait donc incorrect d'écrire que toute l'empreinte est nécessairement valide sur la seule base de cet échantillon. La conclusion vérifiable est qu'au moins une route courante importante dispose d'une autorisation RPKI cohérente.

RPKI ne certifie pas non plus le service situé derrière l'adresse. Le mécanisme aide les réseaux à juger si une origine est autorisée pour un préfixe. Il ne teste ni la disponibilité d'un serveur ni l'intégrité des données. Il ne confirme pas le bâtiment, le propriétaire du matériel, la puissance de secours, l'isolation entre clients ou la qualité du support. Une route peut être RPKI valide tout en menant à un service indisponible pour une autre raison.

Cette limite n'est pas une faiblesse de RPKI; elle reflète son objectif. Une bonne analyse ne demande pas à un mécanisme de sécurité du routage de résoudre une question de continuité commerciale. Elle utilise le résultat pour ce qu'il prouve: l'autorisation de l'origine. Elle cherche ensuite d'autres éléments pour la capacité, la redondance et la reprise.

Pour une équipe cliente, ce préfixe peut néanmoins devenir un repère concret. Elle peut vérifier si ses propres adresses ou destinations Cloud.ir se trouvent dans les annonces attribuées à AS60077, si l'origine reste stable et si le statut RPKI demeure cohérent. Ce contrôle ne répond pas à toutes les questions, mais il transforme une partie de la relation en signal observable plutôt qu'en simple promesse.

BGP et RIPE Whois ne décrivent pas le même état

La vue de cohérence de RIPEstat apporte une autre distinction essentielle. Les préfixes IPv4 d'AS60077 vus dans BGP apparaissaient aussi dans RIPE Whois. Ce rapprochement soutient la cohérence administrative des annonces courantes. Il réduit l'écart entre les routes observées et les objets publiés dans le registre.

La même vue montrait cependant plusieurs plages plus larges ou composantes présentes dans RIPE Whois sans être vues dans BGP. Ce décalage n'est pas nécessairement une anomalie. Un objet de registre peut couvrir une ressource réservée, un agrégat, une politique potentielle ou une configuration qui n'est pas actuellement annoncée sous cette forme. Le registre décrit ce qui est déclaré; BGP montre une partie de ce qui est effectivement propagé.

Cette différence impose une discipline de vocabulaire. Une plage inscrite dans Whois n'est pas automatiquement une route active. Une politique d'import n'est pas automatiquement une session visible. À l'inverse, l'absence d'une relation dans la vue publique ne prouve pas qu'aucune relation privée ou temporaire n'existe. Il faut préciser si l'on parle d'un objet administratif, d'une politique déclarée ou d'une observation de routage.

AS43754 illustre une convergence: il apparaît dans les informations d'import et d'export du côté BGP comme du côté Whois. AS212895 illustre le cas opposé: il figurait dans les données d'import Whois, mais pas dans BGP. Le dossier autorise donc à dire qu'AS43754 est à la fois déclaré et observé dans le rôle examiné. Il n'autorise pas à présenter AS212895 comme un chemin actif sur la seule base de la déclaration.

Cette nuance devient déterminante lorsque l'on évalue la redondance. Une liste de politiques peut donner l'impression de plusieurs options, mais une option inscrite n'est pas encore une voie disponible, testée et dimensionnée. Pour soutenir une affirmation de bascule, il faudrait observer le chemin, connaître son indépendance et disposer d'éléments sur son fonctionnement lors d'une défaillance. Aucun de ces trois niveaux n'est établi pour AS212895 dans le corpus.

La comparaison entre Whois et BGP fonctionne ainsi comme un filtre contre la lecture littérale des registres. Elle conserve la valeur des déclarations sans les confondre avec l'état du réseau. Dans le cas d'AS60077, elle renforce la confiance dans les préfixes actuellement vus tout en empêchant de transformer chaque objet ou chaque import déclaré en capacité opérationnelle.

L'IPv6 est un signal ponctuel, pas une origine courante démontrée

La photographie IPv6 contraste fortement avec la surface IPv4. Le statut de routage de RIPEstat ne comptait aucun préfixe IPv6 actuellement visible comme originaire d'AS60077. Aucun des 321 pairs RIS IPv6 de l'échantillon ne voyait le système autonome dans ce rôle. bgp.tools indiquait également zéro préfixe IPv6 originé.

La liste des préfixes annoncés contenait pourtant 2a05:1a30::/34 pour un seul horodatage, le 13 juillet 2026. Cette observation est suffisamment précise pour devoir être conservée, mais trop limitée pour soutenir une conclusion de service durable. Elle peut correspondre à une annonce brève, à un essai, à une transition ou à un événement que les sources ne décrivent pas. Les sources réunies ne donnent ni explication ni continuité.

Deux erreurs symétriques sont possibles. La première serait d'utiliser cette entrée unique pour affirmer qu'AS60077 exploite actuellement une origine IPv6 stable. Le statut de routage courant ne l'établit pas. La seconde serait d'affirmer qu'aucun service Cloud.ir ne dispose d'IPv6. Les produits pourraient emprunter une autre origine, utiliser des chemins que la collecte ne relie pas à AS60077 ou proposer des fonctions qui ne sont pas visibles dans ces données.

La formulation défendable est donc limitée dans le temps et dans son objet: au moment de la photographie, le dossier ne montrait pas de préfixe IPv6 actuellement originaire d'AS60077, malgré une apparition ponctuelle de 2a05:1a30::/34 une semaine plus tôt. Cette phrase décrit exactement l'observation sans transformer l'absence courante en absence universelle.

Pour un client qui exige une connectivité double pile, cette incertitude doit conduire à une vérification par produit. Il faudrait demander quelles adresses IPv6 sont attribuées, quel système autonome les origine, quels services sont couverts et comment la connectivité est testée. Une simple mention d'IPv6 ne suffirait pas; à l'inverse, la vue d'AS60077 ne suffit pas à rejeter toute possibilité.

L'épisode du 13 juillet peut aussi servir de point de suivi. Si le préfixe réapparaît de manière stable, la conclusion pourra évoluer. S'il reste absent, le dossier continuera de décrire une empreinte publique essentiellement IPv4. Une analyse horodatée permet cette mise à jour sans effacer ce qui a été réellement observé.

AS43754 est la dépendance visible, pas une preuve de diversité indépendante

La vue des voisins de RIPEstat ne renvoyait qu'AS43754 pour AS60077. RIPEstat et RIPE RDAP décrivaient AS43754 comme actif et détenu par Asiatech Data Transmission company. bgp.tools le présentait également comme l'amont d'AS60077. Plusieurs sources convergent donc sur une relation visible et sur l'identité de l'autre réseau.

Cette convergence permet de nommer la dépendance publique observée. Elle ne permet pas de dresser toute la topologie. Les collecteurs peuvent manquer des relations privées, des sessions de secours, des chemins non exportés ou des configurations qui ne sont activées qu'en cas d'incident. Le fait qu'un seul voisin apparaisse n'est pas une preuve mathématique qu'il n'en existe aucun autre.

Mais la réserve sur les angles morts ne doit pas être inversée. On ne peut pas utiliser la possibilité de chemins invisibles pour affirmer une redondance indépendante. Dans le dossier, aucun second amont actif et indépendant n'est vérifié. AS212895 apparaît dans une déclaration Whois, mais n'est pas observé dans BGP. AS43754 reste le seul voisin que les données publiques réunies montrent effectivement.

L'identité d'AS43754 ajoute une question de domaine de panne. Il est attribué à Asiatech Data Transmission company, tandis qu'AS60077 est attribué à Asre Dadeha Asiatech. Les noms indiquent une proximité Asiatech, mais les sources ne fournissent pas la structure juridique ou opérationnelle détaillée qui permettrait de cartographier toutes leurs dépendances communes. Il serait donc excessif de déclarer qu'ils partagent nécessairement chaque équipement ou chaque site.

Il serait tout aussi excessif de traiter AS43754 comme une preuve d'indépendance externe. Une diversité utile se juge sur les ressources réellement séparées: opérateur, fibres, entrées de bâtiment, équipements, alimentation, contrôle et capacité. Le numéro différent d'un système autonome n'établit pas à lui seul que ces dimensions sont indépendantes. Le corpus n'apporte pas les informations nécessaires pour effectuer ce test.

La différence entre redondance et indépendance est importante. Une architecture peut comporter plusieurs équipements ou plusieurs liens sous un même contrôle et offrir une protection réelle contre certaines pannes. Cette protection peut être précieuse. Elle ne couvre pas nécessairement une défaillance commune touchant le même opérateur, le même site, la même tranchée de fibre ou le même plan de contrôle. Les sources ne décrivent pas les scénarios couverts.

Pour un acheteur, la question ne devrait donc pas être seulement: «Existe-t-il un second lien?» Il faudrait demander qui l'exploite, par où il passe, où il termine, quelle capacité il conserve pendant une panne et quand la bascule a été testée. Il faudrait également savoir si les services concernés par le contrat empruntent réellement ces chemins. Les données publiques fournissent un point de départ avec AS43754, pas les réponses complètes.

Le voisin visible est aussi un rappel que la grande diffusion des préfixes n'est pas synonyme de grande diversité. Une route peut atteindre 324 pairs RIS en passant, en amont, par une dépendance concentrée. Les collecteurs voient le résultat de la propagation; ils ne révèlent pas toutes les vulnérabilités physiques qui se trouvent avant cette propagation.

PeeringDB documente surtout ce qui n'est pas divulgué

PeeringDB possédait une fiche réseau courante pour ASN 60077 au nom de Asre Dadeha Asiatech. Les champs status=ok et rir_status=ok indiquaient que l'enregistrement était en règle dans le cadre de la plateforme et du registre concerné. La présence de la fiche est un signal d'identité supplémentaire.

Le contenu opérationnel public de cette fiche était toutefois très limité. PeeringDB indiquait ix_count=0 et fac_count=0. Aucun site web, looking glass, serveur de routes ou URL de politique n'était fourni. La fiche ne divulguait pas non plus d'estimation de trafic ou de portée. Pour une base conçue afin de décrire les interconnexions, ce manque de détail laisse peu d'éléments exploitables pour reconstruire une implantation.

Les zéros doivent être lus comme des zéros de déclaration dans cette source, non comme la preuve d'une absence physique. PeeringDB dépend des informations saisies et maintenues par ses entités. Un réseau peut utiliser un site sans le publier dans sa fiche, se connecter de manière privée ou choisir de ne pas détailler sa politique. fac_count=0 ne signifie donc pas «aucun centre de données».

De la même façon, ix_count=0 ne démontre pas qu'aucune interconnexion n'existe. Il signifie que la fiche ne déclarait pas d'attachement public à un point d'échange. Les relations de transit et les interconnexions privées ne se résument pas aux lignes de point d'échange. Le seul voisin AS43754 observé par RIPEstat apporte un autre type de signal, mais il ne fournit toujours pas de localisation.

Cette absence de divulgation a néanmoins une conséquence pratique. Un analyste externe ne peut pas utiliser PeeringDB pour vérifier le bâtiment d'origine, la diversité métropolitaine, la séparation des entrées de fibre ou la participation à une matrice publique d'échange. La route est visible à l'échelle d'Internet, tandis que son point de départ physique reste opaque dans cette base.

La fiche ne fournit pas non plus de looking glass permettant à un tiers d'examiner la vue de routage depuis le réseau lui-même. Elle ne publie pas de politique qui expliquerait les conditions de peering. Cette lacune ne prouve pas une mauvaise exploitation; elle réduit simplement les possibilités de validation indépendante à partir des informations ouvertes.

Pour la diligence, PeeringDB fonctionne ici moins comme une carte que comme une limite documentaire. Il confirme qu'une identité réseau a une fiche actuelle, puis montre que les champs capables de relier cette identité à des sites et à des échanges sont vides. Cette combinaison renforce la thèse de l'article: le contrôle IPv4 est visible, mais le chemin physique ne l'est pas.

Un opérateur pourrait réduire cette incertitude en publiant des informations précises, mais la publication seule ne prouverait pas encore la résilience. Une déclaration de site devrait être rapprochée d'une preuve de présence actuelle; une déclaration de point d'échange devrait être rapprochée de données d'interconnexion. PeeringDB serait alors une meilleure piste, pas un certificat universel.

Cloud.ir possède une surface commerciale active et identifiable

Le versant commercial du dossier n'est pas une simple archive. Le site Cloud.ir répondait en HTTPS au moment de la collecte. Sa page d'accueil, sa page de présentation, sa page de contact et son plan de site de services formaient une surface accessible aux prospects et aux clients. Cette disponibilité distingue l'offre d'une marque qui ne laisserait que des traces historiques.

Le plan de site référençait des pages consacrées au serveur cloud, au VPS, au centre de données cloud, au commutateur cloud, à la gestion de domaines, au CDN et au stockage cloud. Les valeurs lastmod des principales pages se situaient en 2025 et 2026. Ces dates ne garantissent pas que chaque produit a été modifié en profondeur, mais elles montrent que le catalogue est maintenu dans une période récente.

Les pages officielles indiquent que le service cloud a commencé pendant l'année 1399 du calendrier iranien et qu'il propose plus de vingt produits. Elles affirment également que l'offre fonctionne sur les centres de données d'Asiatech en Iran. Ces éléments décrivent le récit opérationnel de l'entreprise et permettent de comprendre comment elle présente sa dépendance à l'infrastructure Asiatech.

Le dossier soutient donc deux constats distincts. D'une part, AS60077 possède une présence IPv4 publique attribuée à Asre Dadeha Asiatech. D'autre part, Cloud.ir présente actuellement un catalogue cloud lié, dans ses propres textes, aux centres de données d'Asiatech. La proximité des noms et des déclarations rend le rapprochement pertinent.

Ce rapprochement ne constitue pourtant pas une correspondance service par service. Les sources ne disent pas que toute adresse d'un serveur cloud appartient à l'un des 18 préfixes. Elles ne disent pas qu'un VPS, un CDN et le stockage utilisent exactement le même réseau. Elles ne révèlent pas les systèmes autonomes éventuels utilisés pour les fonctions externes, la mitigation ou la distribution.

La page de contact ajoute une surface de relation, mais les sources ne mesurent pas la qualité ou le délai des réponses. Une page accessible prouve qu'un canal est publié; elle ne prouve ni qu'une équipe répond à chaque heure ni qu'un incident complexe sera résolu dans un délai donné. La même distinction doit s'appliquer à tout élément commercial visible.

L'intérêt du catalogue est donc réel mais circonscrit. Il établit que Cloud.ir vend et décrit une gamme de services. Il aide à identifier les produits pour lesquels une diligence plus précise devrait être menée. Il ne remplace pas l'architecture de chaque produit. Plus le catalogue est large, plus une attribution globale à un unique chemin réseau devient risquée.

Les affirmations de centre de données restent des déclarations de l'opérateur

Les pages Cloud.ir emploient des références à ISO27001, TIA-942 et à des niveaux présentés dans un vocabulaire de type Tier 2/3. Elles associent également les services à des centres de données Asiatech en Iran. Ces affirmations sont pertinentes parce qu'elles indiquent les standards et la résilience que l'opérateur souhaite mettre en avant.

Le corpus ne contient cependant ni certificat indépendant, ni rapport d'audit, ni liste exacte des sites auxquels chaque affirmation s'applique. Il ne fournit pas la portée d'une éventuelle certification, sa période de validité, l'entité certifiée ou les exclusions. Une référence à une norme sur une page de service ne suffit pas à établir que chaque composant de chaque produit est couvert.

La même prudence vaut pour les niveaux de type Tier 2/3. Ces expressions peuvent décrire une conception, une ambition, un niveau revendiqué ou une classification appliquée à un site particulier. Sans document indépendant et sans identification du site, il est impossible de savoir précisément ce qui a été évalué. L'article doit donc les attribuer à Cloud.ir, et non les présenter comme des résultats vérifiés par les vingt sources.

Les données ne décrivent pas non plus la topologie d'alimentation et de refroidissement. Elles ne donnent ni le nombre de chemins électriques, ni la durée de secours, ni la séparation des groupes, ni la capacité thermique disponible. Elles ne documentent pas les entrées de fibre, la distance entre sites ou les dépendances communes. Tous ces éléments seraient nécessaires pour convertir une revendication de centre de données en analyse de résilience.

L'absence de ces pièces ne réfute pas les affirmations. Elle indique seulement que l'observateur public ne peut pas les contrôler avec ce corpus. Une conclusion négative absolue serait aussi injustifiée qu'une acceptation sans réserve. La formulation correcte est que les pages font ces déclarations et que le corpus ne les vérifie pas indépendamment.

Cette attribution explicite protège également la valeur de futures preuves. Si Cloud.ir publie ensuite un certificat dont la portée, le site et la date sont clairs, le dossier pourra être enrichi sans réécrire l'observation actuelle. Si une autre source confirme une implantation, elle pourra être ajoutée comme corroboration. Aujourd'hui, la couche physique reste une affirmation à vérifier.

Pour un client, le besoin de précision dépend du produit. Un domaine géré, une machine virtuelle critique et une copie de sauvegarde n'ont pas les mêmes exigences. Il faudrait savoir dans quel site chaque composant réside, quels contrôles s'appliquent et quelles dépendances sont partagées. La marque globale d'un centre de données ne répond pas à cette granularité.

Aucun document ne relie encore chaque produit à sa route et à son site

Le principal vide du dossier se trouve entre les preuves réseau et les pages de service. D'un côté, les sources donnent une liste de préfixes et un système autonome. De l'autre, elles donnent des noms de produits et des promesses commerciales. Entre les deux manque une matrice d'attribution.

Une telle matrice indiquerait, pour le serveur cloud, les plages utilisées, le système autonome d'origine, le ou les sites, l'amont principal et le mécanisme de secours. Elle ferait le même travail pour le VPS, le stockage, le CDN et les autres services. Elle préciserait aussi si le plan de contrôle et le plan de données partagent les mêmes dépendances.

Sans cette matrice, plusieurs architectures restent possibles. Certains produits pourraient utiliser AS60077 directement. D'autres pourraient reposer sur AS43754, sur des réseaux tiers ou sur des ressources qui ne sont pas visibles dans le corpus. Le CDN pourrait avoir une distribution différente du serveur cloud. Le stockage pourrait avoir un chemin interne distinct. Les sources ne permettent pas de choisir entre ces possibilités.

Cette incertitude interdit d'utiliser un succès de routage comme substitut à un test de produit. Le fait que 193.151.156.0/24 soit largement visible et RPKI valide ne prouve pas qu'une instance donnée soit disponible. Inversement, une instance disponible ne prouve pas qu'elle se trouve dans ce préfixe. L'évaluation doit partir de la ressource réellement achetée.

Une méthode de vérification pourrait commencer par les adresses observées par le client. Elle les rapprocherait des préfixes, de leur origine et de leur statut RPKI. Elle demanderait ensuite à l'opérateur de confirmer le site et les chemins applicables. Enfin, elle comparerait ces réponses aux engagements contractuels et aux essais de bascule. Chacune de ces étapes couvre une couche différente.

Le contrôle doit aussi porter sur les fonctions de gestion. Un portail, une API, un système de sauvegarde et le trafic d'une machine peuvent dépendre de réseaux différents. Une panne qui épargne le plan de données mais atteint l'authentification peut empêcher une intervention. Les pages étudiées ne fournissent pas cette décomposition; elles ne permettent donc pas de créditer une indépendance qui n'est pas montrée.

Cette lacune documentaire explique pourquoi la thèse ne porte pas sur l'existence de Cloud.ir. L'offre et le réseau sont bien visibles. Elle porte sur la liaison entre les deux. Une infrastructure cloud devient évaluée de bout en bout seulement lorsque les routes, les sites, la capacité et les procédures de reprise peuvent être rattachés aux services effectivement utilisés.

Le SLA trace une frontière de responsabilité plus qu'un plan de reprise

Le SLA de Cloud.ir est une pièce essentielle parce qu'il montre ce que l'opérateur choisit de couvrir et d'exclure. Le texte limite les garanties de disponibilité au réseau et au serveur cloud dans le cadre des opérations ordinaires. Cette portée est plus étroite que l'idée générale d'une disponibilité de toute l'expérience client.

Le document exclut notamment les logiciels et les systèmes d'exploitation du client, les erreurs de configuration et les défaillances d'équipements appartenant au client. Cette répartition est classique dans un modèle d'infrastructure: le fournisseur protège certaines couches, tandis que le client reste responsable de ce qu'il installe et administre. Elle signifie néanmoins qu'une interruption visible par l'utilisateur peut se situer hors de la garantie si sa cause est attribuée à la couche cliente.

Les attaques par déni de service figurent aussi parmi les exclusions. Cette mention est importante pour un service exposé à Internet. Elle ne dit pas qu'aucune protection n'existe; elle indique que la garantie décrite ne doit pas être lue comme une couverture universelle de ce scénario. Les sources ne détaillent ni un service de mitigation ni les conditions dans lesquelles une attaque serait prise en charge.

La maintenance et les correctifs critiques sont également exclus. Une fenêtre planifiée et une intervention urgente peuvent donc produire une indisponibilité sans relever de la même comptabilisation qu'une panne ordinaire. Pour évaluer la disponibilité vécue, un client doit connaître non seulement le pourcentage annoncé, mais aussi les catégories retirées du calcul, la fréquence des interventions et le préavis.

Le SLA mentionne encore la force majeure, les suspensions, les arrêts demandés par le client, le non-paiement et certaines injonctions légales ou de sécurité. Ces exclusions montrent que l'accès au service dépend de facteurs techniques, contractuels et réglementaires. Une architecture peut fonctionner correctement tout en devenant indisponible pour une cause extérieure au matériel.

Cette liste ne doit pas être présentée comme anormale en soi. Un SLA sert précisément à définir une frontière. Sa valeur analytique tient au fait qu'il empêche de transformer une promesse de disponibilité en garantie absolue. Deux incidents identiques du point de vue de l'utilisateur peuvent être classés différemment selon leur cause et la partie responsable.

Le document consulté ne fournit pas les séquences de bascule pour chaque service. Il ne donne pas d'objectif de temps de reprise, d'objectif de point de reprise, de résultat d'exercice ou d'historique d'incident. Il ne précise pas quelle capacité reste disponible lorsqu'un composant majeur est perdu. La frontière contractuelle est visible; le mécanisme technique de récupération reste opaque.

Cette distinction compte particulièrement pour les données. Une garantie de disponibilité du serveur ou du réseau ne répond pas automatiquement à la question de la persistance, de la réplication ou de la restauration. Le corpus ne permet pas d'établir où se trouvent les copies, si elles partagent un site ou comment elles sont testées. Il serait donc incorrect de déduire la récupération des données à partir d'une garantie d'accès.

Le SLA n'établit pas non plus que tous les produits du catalogue disposent de la même couverture. Son langage porte sur le réseau et le serveur cloud dans des conditions définies. Un client du VPS, du stockage ou du CDN doit vérifier les engagements applicables à son service précis. Le catalogue commercial et la portée contractuelle ne doivent pas être supposés identiques.

Pour comparer des offres, un acheteur devrait demander trois ensembles d'informations. Le premier est la formule de calcul de la disponibilité, avec les exclusions. Le deuxième est l'architecture de reprise, avec les dépendances. Le troisième est la preuve de fonctionnement, sous forme de tests et d'incidents documentés. Le SLA étudié apporte une partie du premier ensemble, mais pas les deux autres.

La visibilité du contrôle ne prédit pas le comportement pendant une panne

AS60077 peut continuer à annoncer ses 18 préfixes alors qu'un service particulier rencontre un problème interne. À l'inverse, une route peut changer pendant que le service reste accessible par un autre chemin. BGP et la disponibilité applicative évoluent à des couches différentes. Leur relation doit être observée, pas supposée.

Une panne de serveur, de stockage ou de logiciel ne retire pas nécessairement la route. Les collecteurs continueraient alors à voir l'origine, même si le client ne peut plus utiliser sa ressource. Une panne d'amont pourrait, au contraire, modifier la visibilité tout en laissant les systèmes internes en état. Les sources ne contiennent pas de chronologie d'incident permettant de comparer ces signaux.

La même réserve vaut pour la bascule. Un second équipement ou un second site peut exister sans prendre la charge correctement. La preuve utile n'est pas seulement son existence, mais le résultat d'un exercice ou d'un événement réel. Il faut connaître le temps de détection, le temps de décision, le temps de convergence et l'état des données après reprise.

Le seul voisin public observé, AS43754, concentre l'attention sur le chemin amont, mais il ne permet pas de modéliser tout le comportement. Une redondance cachée pourrait intervenir. Une dépendance commune pourrait aussi limiter la bascule. Sans topologie et sans test, les deux hypothèses restent ouvertes. L'analyse doit enregistrer cette incertitude plutôt que choisir le scénario le plus favorable ou le plus alarmant.

La visibilité RIS elle-même est un indicateur externe. Elle montre que de nombreux points d'observation reçoivent l'annonce. Elle ne mesure pas la latence, les pertes, la saturation ou le succès d'une connexion vers une application. Un réseau peut être visible et dégradé. Une mesure de contrôle doit être complétée par des mesures de données et de service.

Cette distinction permet d'éviter une confusion fréquente dans l'économie du cloud. Les ressources qui rendent une offre vendable ne se réduisent pas à l'adressage et au routage. Elles comprennent le calcul, le stockage, l'énergie, le refroidissement, les opérations, le support et la capacité de remplacer un composant. Le corpus montre une partie du premier plan, mais pas l'ensemble.

La conclusion ne doit donc pas être que les données de routage sont secondaires. Elles sont indispensables pour attribuer et surveiller le réseau. Leur utilité augmente lorsque leur limite est reconnue. Elles détectent certaines ruptures et rendent certaines affirmations vérifiables; elles ne remplacent pas un plan de continuité.

Ce qu'un acheteur peut vérifier à partir des preuves disponibles

La première étape consiste à identifier le produit réellement concerné. Une organisation qui achète un serveur cloud n'a pas exactement les mêmes dépendances qu'une organisation qui utilise le CDN ou le stockage. Il faut obtenir les adresses, les noms de service, les points d'administration et les engagements contractuels propres à cette ressource.

Les adresses observées peuvent ensuite être comparées aux 18 préfixes d'AS60077. Si elles s'y trouvent, l'acheteur dispose d'un lien concret entre son service et l'empreinte analysée. Si elles ne s'y trouvent pas, il ne doit pas conclure automatiquement à une anomalie: le service peut utiliser une autre origine. Il doit demander quelle entité et quel système autonome assurent alors la livraison.

Pour les adresses qui relèvent d'AS60077, l'origine BGP et le statut RPKI peuvent être surveillés. L'exemple 193.151.156.0/24 montre comment croiser RIPEstat, RIPE RDAP et les ROA. Le même travail devrait être réalisé sur le préfixe exact du client. L'objectif est de vérifier l'attribution et les changements, non de déduire la disponibilité complète.

La question suivante porte sur les sites. Quel bâtiment héberge le service principal? Où se trouve la copie de secours? Les deux emplacements partagent-ils l'alimentation, le refroidissement, une entrée de fibre ou un opérateur? PeeringDB ne fournit pas ces réponses pour AS60077. Elles doivent donc venir d'une documentation précise ou d'une preuve indépendante adaptée.

L'amont doit être traité avec la même granularité. AS43754 est le voisin visible, mais l'acheteur doit savoir si un autre chemin existe pour son service, s'il est actif, s'il dispose d'une capacité suffisante et s'il suit une route physiquement distincte. Une politique Whois ou un numéro d'AS supplémentaire ne constitue pas une preuve de bascule.

La capacité doit être exprimée dans les unités du produit. Pour le calcul, cela peut inclure les ressources garanties, les limites de surallocation et les réserves. Pour le réseau, cela inclut les débits, les points de contention et la capacité maintenue lors d'une panne. Pour le stockage, cela inclut la réplication, l'intégrité et la restauration. Les 14 080 adresses IPv4 ne répondent à aucune de ces questions.

La reprise doit être vérifiée par des objectifs et des résultats. Quel délai s'applique à un incident couvert? Quelle perte de données maximale est prévue? Quand une bascule a-t-elle été testée? Quelles exclusions du SLA s'appliquent? Le corpus montre les exclusions, mais pas les résultats de test. Une réponse commerciale devrait être reliée au contrat et à un service précis.

L'IPv6 nécessite un contrôle séparé. Le signal ponctuel de 2a05:1a30::/34 ne démontre pas une offre actuelle; l'absence courante d'origine AS60077 ne démontre pas l'absence de tout produit IPv6. Un client doit demander des adresses et tester la connectivité sur la ressource qu'il compte utiliser.

Enfin, le client doit conserver un chemin de sortie. La capacité d'exporter les données, de déplacer le DNS, de récupérer les configurations et de révoquer les accès réduit la dépendance à une reprise parfaite du fournisseur. Les sources ne décrivent pas les mécanismes Cloud.ir sur ces points. Elles montrent pourquoi ces questions doivent être posées avant un incident.

Cette démarche transforme l'incertitude publique en programme de diligence. Elle ne présume pas que les réponses seront négatives. Elle distingue simplement les éléments déjà observables des éléments qui nécessitent une confirmation directe. Le réseau public fournit des repères; le contrat, l'architecture et les tests doivent compléter la chaîne.

Ce que les vingt sources ne permettent pas d'affirmer

Le dossier ne permet pas d'affirmer le chemin exact jusqu'à un centre de données. Aucun préfixe n'est associé à une adresse de site, une salle, une baie ou une entrée de fibre. Les pages Cloud.ir parlent de centres de données Asiatech en Iran, mais elles ne donnent pas la cartographie nécessaire pour relier chaque service à un lieu.

Il ne permet pas d'affirmer la propriété des installations ou des équipements. Une organisation peut exploiter, louer, revendre ou partager des ressources. Les registres de réseau n'arbitrent pas ces modèles. Les termes commerciaux ne suffisent pas non plus à établir le titre de propriété.

Il ne permet pas de prouver une redondance amont indépendante. AS43754 est le seul voisin observé; AS212895 reste une déclaration Whois non vue dans BGP. Des chemins non publics peuvent exister, mais ils ne sont pas démontrés. L'indépendance physique et opérationnelle est encore moins documentée.

Il ne permet pas de calculer la capacité disponible pour les clients. Le nombre d'adresses ne mesure ni les processeurs, ni la mémoire, ni le stockage, ni l'énergie, ni le débit restant. Les pages de service ne fournissent pas, dans le corpus, un inventaire vérifié qui comblerait ce manque.

Il ne permet pas d'affirmer qu'aucun service IPv6 n'existe. Il établit seulement l'absence d'une origine IPv6 AS60077 actuellement visible dans la photographie et l'existence d'un signal ponctuel le 13 juillet 2026. Les autres architectures ne sont pas testées.

Il ne permet pas de présenter ISO27001, TIA-942 ou les niveaux de type Tier 2/3 comme indépendamment certifiés pour toute l'offre. Ces références viennent des pages de l'opérateur et leur portée n'est pas documentée par une pièce externe dans le corpus.

Il ne permet pas de déduire le comportement de reprise. Le SLA décrit des frontières et des exclusions, mais pas une séquence vérifiée de restauration. Aucune mesure d'exercice, aucun historique détaillé et aucun objectif par produit ne sont inclus.

Il ne permet pas enfin d'attribuer tous les services Cloud.ir à AS60077. La relation entre la marque, Asre Dadeha Asiatech et le réseau est étayée à plusieurs niveaux, mais la matrice par produit manque. Cette limite doit accompagner toute utilisation de l'empreinte.

Ces interdictions de conclure ne constituent pas une liste de soupçons. Elles sont la conséquence normale d'une enquête fondée sur des sources publiques limitées. Elles empêchent qu'une absence de preuve devienne une accusation, tout comme elles empêchent qu'une déclaration devienne une certitude.

Les signaux qui permettraient de réduire l'incertitude

Une première amélioration serait une cartographie publique ou contractuelle reliant les produits aux préfixes et aux systèmes autonomes. Elle permettrait de savoir quelles conclusions sur AS60077 s'appliquent effectivement au serveur cloud, au VPS, au stockage ou au CDN. Elle rendrait aussi visibles les dépendances différentes entre produits.

Une deuxième amélioration serait une divulgation précise des sites et des interconnexions. Une fiche PeeringDB plus complète pourrait fournir des pistes, mais elle devrait être corroborée. Une confirmation de présence, une architecture de chemins et une description des domaines de panne apporteraient une preuve plus forte que le simple nom d'un centre de données.

Une troisième amélioration concernerait l'amont. L'observation stable d'un second voisin indépendant, accompagnée d'une description de la diversité physique et de tests de bascule, modifierait l'évaluation. Une politique Whois seule ne suffirait pas. Il faudrait montrer que le chemin est actif, dimensionné et réellement utilisable lorsqu'AS43754 n'est pas disponible.

Pour IPv6, une annonce stable de 2a05:1a30::/34 ou d'un autre préfixe, visible dans le statut courant et reliée à des produits, constituerait un signal plus fort. Des adresses attribuées et des tests compléteraient l'observation. L'entrée unique du 13 juillet deviendrait alors un épisode dans une trajectoire documentée plutôt qu'un signal isolé.

Les affirmations de centre de données gagneraient en valeur avec des certificats dont la portée, l'entité, le site et la validité sont clairement identifiés. Des éléments sur l'alimentation, le refroidissement, les fibres et les capacités de secours permettraient de passer d'une étiquette à une architecture analysable.

Enfin, des objectifs de reprise, des résultats de tests et des historiques d'incident réduiraient l'écart entre le SLA et le comportement réel. Une garantie est plus informative lorsqu'elle est associée à la manière dont le service revient, à la capacité disponible pendant la dégradation et à la qualité des données après restauration.

Chacun de ces signaux doit rester dans sa couche. Une nouvelle route n'établit pas une certification de site. Un certificat n'établit pas une diversité amont. Un test de bascule ne prouve pas la capacité commerciale permanente. La force du dossier viendrait de leur combinaison, non de la transformation d'un seul indicateur en réponse totale.

Une empreinte vérifiable, une chaîne de livraison encore incomplète

Le cas de CLOUD Asre Dadeha Asiatech montre pourquoi les données de routage sont à la fois puissantes et insuffisantes. Elles identifient AS60077, confirment son activité IPv4, détaillent 18 annonces, mesurent une visibilité auprès de 324 des 325 pairs RIS IPv4 et fournissent un exemple RPKI valide. Elles relient aussi l'origine à des objets RIPE RDAP et à des contacts Asiatech.

Ces résultats établissent une vraie surface de contrôle publique. Ils permettent de suivre le réseau, de vérifier une attribution et de distinguer une route observée d'une simple déclaration. Ils constituent une base plus solide qu'un catalogue commercial pris seul.

Les mêmes données font ressortir les limites de la vue. Aucun préfixe IPv6 courant n'était visible comme originaire d'AS60077, malgré un signal ponctuel. AS43754 était le seul voisin observé. PeeringDB ne divulguait ni site ni point d'échange. Le chemin physique, la capacité utilisable et la diversité indépendante ne pouvaient donc pas être reconstruits.

Cloud.ir ajoute une surface client active, un catalogue de plus de vingt produits revendiqués et des pages récemment maintenues. Son SLA clarifie plusieurs exclusions. Mais le corpus ne relie pas chaque produit à une route, un site, une capacité et un mécanisme de reprise. Il ne vérifie pas indépendamment les références de centre de données.

La conclusion la plus robuste est ainsi asymétrique. Il existe suffisamment de preuves pour dire que le réseau IPv4 d'AS60077 est actif et largement visible, et que Cloud.ir présente une offre commerciale actuelle. Il n'existe pas suffisamment de preuves pour dire comment chaque service traverse les installations, quelle redondance indépendante le protège, quelle capacité reste mobilisable ou comment il se rétablit après une défaillance.

Cette asymétrie n'est ni un verdict de faiblesse ni une approbation de résilience. Elle est une frontière de connaissance. Pour la franchir, un acheteur doit relier son service concret aux préfixes, aux sites, aux chemins, au contrat et aux tests. Tant que cette chaîne n'est pas fournie, AS60077 rend Cloud.ir visible sur Internet sans rendre transparente toute l'infrastructure qui livre ses services.

AS60077 rend Cloud.ir visible sur Internet, sans révéler le chemin physique de ses services