Sovy Cloud Services: AS401110 demeure, mais la preuve publique

Summary

ARIN conserve un enregistrement actif pour AS401110, sous le nom AS-SOVYCLOUD, associé à Sovy Cloud Services. Cette donnée établit une identité de registre et une chronologie, mais elle ne certifie pas qu'un service cloud destiné aux clients fonctionne aujourd'hui.
Le 20 juillet 2026, le registre de .cloud indiquait que sovy.cloud était disponible à l'enregistrement, tandis que trois résolveurs DNS distincts renvoyaient NXDOMAIN. Les adresses de contact publiques liées à ce domaine doivent donc être vérifiées par un autre canal, sans conclure pour autant que chaque boîte aux lettres est définitivement hors service.
PeeringDB continue de présenter AS401110 comme un NSP de portée mondiale, avec cinq installations déclarées, mais n'affiche aucun préfixe, aucune présence sur un LAN d'échange et aucun contact public pour ce réseau. Ces entrées sont des déclarations de répertoire à confirmer, non des preuves de capacité actuellement exploitable.
RIPEstat documente une activité de routage réelle entre 2024 et février 2025, puis une absence de visibilité publique actuelle. La conclusion prudente est une appréciation faible de l'exploitation publique présente, et non un verdict sur la fermeture de Sovy Cloud Services, l'existence de clients privés ou l'état physique des sites répertoriés.

Trois horloges qui ne donnent plus la même heure

Une fiche d'entreprise cloud peut sembler cohérente tant que ses différentes traces sont lues séparément. L'ASN existe. Un répertoire d'interconnexion affiche un nom, un site, un périmètre et des installations. Des préfixes apparaissent dans l'historique. Pris isolément, chacun de ces éléments peut évoquer un opérateur constitué. Leur valeur change lorsqu'on les date et qu'on les rapproche.

Le dossier de Sovy Cloud Services met en présence trois horloges. La première est administrative. ARIN a enregistré AS401110 le 29 mai 2024 sous le nom AS-SOVYCLOUD et indique une dernière modification le 30 mai 2024. L'enregistrement reste marqué comme actif. La deuxième est déclarative. PeeringDB conserve un profil décrivant sovy.cloud, Sovy Cloud Services et Sovy Cloud Services LLC comme un NSP de portée mondiale. La troisième est opérationnelle et beaucoup plus récente: le 20 juillet 2026, le domaine n'existait plus dans le DNS public, le registre le donnait disponible, et les vues RIPEstat consultées ne montraient aucun routage actuel pour AS401110.

Ces horloges ne s'annulent pas. Elles répondent à des questions différentes. ARIN permet de relier un numéro de système autonome à une identité déclarée. PeeringDB restitue la manière dont un réseau s'est présenté à l'écosystème d'interconnexion. Le DNS et les observations BGP donnent des indications datées sur une surface publique effectivement observable. L'erreur de diligence consiste à transformer la première ou la deuxième réponse en substitut de la troisième.

Dans un marché où un petit fournisseur peut vendre sous une marque, sous-traiter une partie de son infrastructure ou ne publier qu'une portion de son réseau, l'absence d'un signal public ne suffit jamais à décrire toute l'activité privée. Mais lorsque plusieurs signaux indépendants disparaissent ensemble, l'acheteur ne peut plus traiter les anciennes fiches comme une preuve actuelle. Il doit déplacer la charge de la preuve vers des éléments récents, directement vérifiables.

Ce qu'ARIN établit, et ce que le mot « actif » n'établit pas

L'ancrage le plus solide du dossier est l'enregistrement ARIN. AS401110 est bien un numéro de système autonome enregistré, et AS-SOVYCLOUD est bien le nom qui lui est associé. ARIN rattache la ressource à Sovy Cloud Services et à l'identifiant d'entité SCSL-51, avec l'adresse 25 First Ave. SW STE A, Watertown, SD 57201, aux États-Unis. Cette chaîne donne une base factuelle à l'identité réseau. Elle empêche de réduire AS401110 à une simple mention commerciale sans trace de registre.

Elle ne dit toutefois pas qu'un cloud fonctionne au moment de la lecture. Dans ce contexte, le statut actif qualifie l'objet de registre. Il ne constitue ni un test de disponibilité du service, ni une attestation de clientèle, ni une confirmation de capacité, de personnel ou de support. Un identifiant administratif peut survivre à une évolution commerciale, à une interruption de marque ou à une phase sans annonce BGP visible. À l'inverse, une entreprise peut aussi fournir certains services sans annoncer elle-même des routes sous son propre ASN.

Le statut doit donc être lu précisément, sans lui demander plus qu'il ne peut prouver.

Les contacts imbriqués dans le dossier ARIN apportent un deuxième indice. Les fonctions administratives, techniques et de traitement des abus utilisent des adresses en sovy.cloud. Les remarques publiques signalent aussi des points de contact non validés après absence de réponse depuis le 7 mai 2025. Ce constat fragilise la confiance que l'on peut accorder à ce canal public, surtout lorsque le domaine lui-même n'existe plus dans le DNS. Il ne permet pas d'affirmer que chaque adresse de support, de facturation ou d'abus est définitivement morte. Il permet en revanche de dire qu'une organisation qui dépendrait de ces coordonnées devrait obtenir un canal récent et tester sa capacité à joindre un interlocuteur.

La distinction est essentielle pour un acheteur. Une donnée de registre est utile pour répondre à « qui a demandé cette ressource, et quand ? ». Elle est insuffisante pour répondre à « qui opérera mon service demain matin ? ». La première question porte sur l'attribution et l'identité. La seconde porte sur la continuité, l'escalade et la responsabilité opérationnelle. Confondre les deux revient à transformer une archive administrative en garantie de service.

Le domaine disponible est un signal actuel, pas un certificat de fermeture

Le domaine sovy.cloud occupe une place particulière dans cette vérification. PeeringDB le présente comme le site du réseau. Les contacts ARIN l'utilisent pour leurs adresses électroniques. Il relie donc la marque, la présence commerciale et plusieurs voies de contact. Son état actuel n'est pas un détail de présentation: il affecte la possibilité de découvrir le service et de valider les coordonnées publiées.

Le 20 juillet 2026, la réponse RDAP du registre .cloud indiquait que sovy.cloud était disponible à l'enregistrement. Le même jour, une requête A effectuée par le résolveur du système a renvoyé NXDOMAIN. Les résolveurs publics de Cloudflare à 1.1.1.1 et de Google à 8.8.8.8 ont donné le même résultat. L'accord entre le registre et trois chemins de résolution indépendants produit un signal public plus robuste qu'un simple échec de chargement de page.

NXDOMAIN signifie ici que le nom demandé n'existe pas dans le DNS au moment du contrôle. Cela explique pourquoi un client ne peut pas s'appuyer sur le domaine pour trouver un site ou valider directement les adresses qui lui sont associées. Le statut de disponibilité ajoute qu'il ne s'agit pas seulement d'un serveur Web momentanément indisponible derrière un domaine encore enregistré. Pour une diligence datée, ces deux observations doivent être consignées ensemble.

Elles ne suffisent pourtant pas à prononcer la fermeture de Sovy Cloud Services. Une société peut changer de domaine, communiquer par des canaux privés, fournir un service en marque blanche ou maintenir des engagements qui ne sont pas visibles depuis son ancienne adresse publique. Les sources examinées ne fournissent pas d'annonce officielle de cessation, de registre commercial de dissolution, de contrat client ni de témoignage direct de l'entreprise. Le vocabulaire rigoureux est donc celui d'une surface de marque publique absente au moment de la vérification.

Cette nuance ne réduit pas l'importance du signal pour un client potentiel. Lorsqu'un fournisseur utilise un domaine à la fois comme site déclaré et comme domaine de contact de registre, sa disparition transfère un travail supplémentaire à l'acheteur. Celui-ci doit identifier la personne morale avec laquelle il contracte, obtenir un domaine ou un canal de support actuel, confirmer les mécanismes d'escalade et vérifier que les documents commerciaux ne renvoient pas à une identité numérique que le registre présente désormais comme disponible à l'enregistrement.

Ce sont des contrôles de continuité et d'authenticité, pas une accusation.

PeeringDB conserve une empreinte, pas une preuve de présence

Le profil PeeringDB donne au dossier sa plus forte apparence de continuité. Il associe AS401110 à sovy.cloud, à Sovy Cloud Services et à Sovy Cloud Services LLC. Il classe le réseau comme NSP, lui attribue une portée mondiale, reprend l'identifiant IRR AS-SOVYCLOUD et affiche cinq installations. Dans le même profil, les compteurs publics indiquent zéro préfixe IPv4, zéro préfixe IPv6 et zéro échange Internet.

La liste d'installations est géographiquement étendue: Equinix SG1 - Singapore, Equinix SG3 - Singapore, Equinix HK2 - Hong Kong, Linxdatacenter (Moscow) et NewTelco Kiev. Cette dispersion peut facilement être lue comme une carte de déploiement. Elle ne doit pas l'être sans confirmation contemporaine. L'API netfac prouve que cinq relations de répertoire existent pour l'identifiant réseau 36371. Elle ne montre ni équipement en fonctionnement, ni engagement contractuel, ni charge client, ni redondance entre les sites. Elle ne dit pas non plus que ces installations sont inactives. Elle énumère cinq déclarations dont l'état actuel reste à vérifier.

Deux absences complètent ce tableau. L'API netixlan ne renvoie aucune ligne de LAN d'échange pour ce réseau. L'API publique des points de contact ne renvoie aucun contact public associé à l'identifiant 36371. Il serait abusif d'en conclure qu'il n'existe aucun transit, aucune interconnexion privée ou aucun interlocuteur connu de partenaires existants. PeeringDB n'expose qu'une partie de la réalité, et certains contacts peuvent rester privés. Ces résultats montrent néanmoins qu'un nouvel observateur ne peut pas corroborer, depuis le profil public, une présence d'échange ou un point de contact opérationnel.

PeeringDB est très utile lorsqu'il est traité comme ce qu'il est: un répertoire spécialisé qui aide les réseaux à se décrire et à se trouver. Sa force réside dans les noms, identifiants, politiques déclarées et relations publiées. Sa limite apparaît lorsque la fraîcheur d'une fiche est inconnue ou lorsque d'autres signaux ont changé. Une ligne de facility peut survivre à un changement de déploiement. Un site déclaré peut devenir indisponible. Un champ de portée mondiale peut décrire une intention ou une activité passée sans démontrer un service présent dans chaque lieu.

Pour la diligence, le bon réflexe n'est donc ni d'ignorer PeeringDB, ni de le prendre au pied de la lettre. Il faut convertir chaque élément en question vérifiable. Les cinq installations déclarées deviennent cinq demandes de confirmation datée. L'absence de LAN d'échange devient une demande d'explication sur la connectivité actuellement utilisée. L'absence de contact public devient une demande de voie d'escalade identifiable. Le profil cesse alors d'être une conclusion et redevient un index de contrôles.

Cinq installations déclarées ne forment pas encore une architecture

La géographie du profil mérite un examen séparé, car elle peut produire une impression de solidité plus vite qu'elle ne produit une preuve. Equinix SG1 - Singapore, Equinix SG3 - Singapore, Equinix HK2 - Hong Kong, Linxdatacenter (Moscow) et NewTelco Kiev dessinent, sur une même page, un périmètre qui traverse plusieurs marchés. La donnée vérifiée est toutefois plus étroite: l'API netfac conserve cinq relations entre la fiche du réseau et ces installations. Elle ne décrit pas le rôle actuel de chaque lieu dans un service vendu sous la marque Sovy Cloud Services.

Cette distinction empêche d'assimiler cinq lignes à cinq zones de disponibilité. Une relation de répertoire ne précise pas, dans les éléments examinés, quels produits y seraient servis, si les sites participeraient au même système, quel trafic les traverserait ou si une continuité serait organisée entre eux. Elle ne donne pas non plus de date de test commune aux cinq lieux. La distance entre Singapour, Hong Kong, Moscou et Kiev n'est donc pas, en elle-même, une preuve de redondance. Elle indique seulement que la revendication publique a eu une portée géographique étendue.

Pour vérifier cette empreinte sans demander au fournisseur de divulguer des informations sensibles, un acheteur peut procéder installation par installation. Pour le lieu invoqué dans l'offre, il peut demander sa fonction actuelle, le service concerné, la date à laquelle cette présence a été confirmée et le moyen de vérifier que le chemin annoncé correspond bien au contrat. Une réponse qui porte sur Equinix SG1 - Singapore ne valide pas automatiquement Equinix SG3 - Singapore. De même, une preuve concernant Equinix HK2 - Hong Kong ne renseigne pas sur Linxdatacenter (Moscow) ou NewTelco Kiev.

La granularité de la preuve doit suivre celle de l'affirmation commerciale.

L'absence de lignes netixlan ne réfute pas ces relations de facility. Une présence dans une installation et une présence sur un LAN d'échange sont deux objets distincts dans PeeringDB. Un réseau peut utiliser du transit ou des interconnexions privées sans publier de session sur un échange. Mais, dans ce dossier, aucun préfixe courant, aucun voisin RIPEstat et aucun LAN d'échange public ne vient fournir une corroboration réseau contemporaine aux cinq lignes. L'acheteur doit donc chercher cette corroboration ailleurs au lieu de laisser le nombre d'installations jouer le rôle d'une preuve cumulée.

L'absence de point de contact public dans l'API PeeringDB réduit encore la possibilité d'une vérification externe simple. Elle ne signifie pas que les exploitants de ces installations ne connaissent aucun interlocuteur, ni qu'aucun partenaire privé n'existe. Elle signifie que le lecteur du profil ne dispose pas, par ce canal, d'une personne publique à qui demander si la relation est actuelle. Le contrôle doit alors revenir vers la partie qui propose le service et vers les pièces qu'elle accepte de rattacher à son offre.

Cette lecture change la valeur pratique de la fiche. Les cinq installations ne sont ni effacées ni présumées inactives; elles sont reclassées comme cinq affirmations à dater. Si aucune offre ne s'appuie sur un lieu donné, sa présence historique dans le répertoire a peu d'effet sur le risque du client. Si un contrat promet au contraire une implantation, une reprise ou une faible latence grâce à l'un de ces sites, la ligne correspondante devient une hypothèse essentielle à confirmer. C'est le lien entre le lieu déclaré et le service acheté, et non la longueur de la liste, qui crée une preuve utile.

RIPEstat montre qu'il y a eu un réseau visible

Le silence actuel de RIPEstat ne doit pas effacer l'histoire. Les données de routage montrent qu'AS401110 n'est pas un ASN resté purement administratif depuis sa création. L'historique attribue à cet ASN l'origine de six préfixes au cours de fenêtres allant de mai ou juin 2024 à février 2025: 166.88.177.0/24, 2a12:8fc6:4011::/48, 81.161.230.0/24, 109.206.237.0/24, 136.0.121.0/24 et 23.27.222.0/24.

Le résumé d'état de routage précise une première observation du préfixe IPv6 2a12:8fc6:4011::/48 le 31 mai 2024. Il donne comme dernière observation le préfixe IPv4 109.206.237.0/24 le 14 février 2025. Ces repères ne racontent pas, à eux seuls, la nature des services fournis sur ces adresses. Ils montrent en revanche qu'un historique BGP public a bien existé sous AS401110.

Cette chronologie change l'interprétation. Sans elle, on pourrait confondre un ASN enregistré mais jamais visible avec une ressource qui a effectivement annoncé des routes. Avec elle, le dossier devient celui d'une présence observable qui a cessé d'apparaître dans les vues consultées. C'est une différence importante pour les opérateurs et les clients, car elle permet de poser des questions sur la transition plutôt que de spéculer sur une absence totale d'activité passée.

Elle évite aussi une autre erreur: prendre l'ancienneté d'une annonce pour une preuve de contrôle actuel. Une table historique établit qu'un ASN a été vu comme origine à une date et dans une fenêtre données. Elle n'établit pas que l'organisation contrôle encore le préfixe, qu'elle en est titulaire, qu'elle l'utilise pour les mêmes clients ou que les accords commerciaux sont inchangés. Pour connaître l'état présent, il faut revenir aux observations présentes.

Au 20 juillet 2026, la surface de routage publique est vide

À l'heure de requête du 20 juillet 2026 à 08:00 UTC, l'aperçu RIPEstat marque AS401110 comme non annoncé. La vue des préfixes annoncés ne renvoie aucun préfixe actuel pour l'ASN dans sa dernière fenêtre de deux semaines. Cette source comporte une réserve méthodologique: les routes dont la visibilité est très faible dans les flux complets RIS peuvent être exclues. Le résultat décrit donc la visibilité fournie par la mesure, pas une impossibilité absolue qu'une route existe dans un contexte mal observé.

Le rapport d'état est néanmoins cohérent sur plusieurs dimensions. Il indique zéro préfixe IPv4 annoncé, zéro /48 IPv6, zéro voisin observé et zéro visibilité RIS actuelle en IPv4 comme en IPv6. La vue des voisins renvoie elle aussi zéro voisin à gauche, à droite, unique ou incertain au dernier instant disponible. Aucune de ces mesures, seule, ne couvrirait tous les cas possibles. Leur convergence donne toutefois une conclusion précise: les données publiques RIPEstat consultées ne montrent pas de surface BGP active pour AS401110 à cette date.

Ce que cette convergence permet de dire est plus limité que ce qu'elle pourrait suggérer. Elle permet d'écarter l'idée qu'un simple regard sur l'ASN suffit à retrouver un réseau public annoncé de manière visible. Elle ne permet pas de nier l'existence d'un service privé, d'une clientèle privée, d'une route privée, d'une activité fournie par un autre ASN ou d'une surface non publique. Elle ne permet pas davantage d'identifier la cause du retrait des annonces.

Pour un client qui pense acheter une infrastructure directement opérée sous AS401110, cette absence devient cependant une question centrale. Le fournisseur devrait pouvoir expliquer quel ASN et quels préfixes portent actuellement le service, comment la connectivité est assurée, quelles adresses seront attribuées et comment ces éléments peuvent être testés avant engagement. Si le service n'utilise plus AS401110, ce n'est pas automatiquement un défaut. Mais l'écart entre la documentation publique et l'architecture réelle doit être rendu intelligible.

Les préfixes historiques ont désormais leur propre trajectoire

Deux préfixes offrent un contrôle supplémentaire. 109.206.237.0/24, que l'état RIPEstat donne comme dernière observation sous AS401110 le 14 février 2025, est actuellement annoncé par AS16045 BULINFO-HOSTING Spektar AD dans la vue d'ensemble du préfixe. Le préfixe IPv6 2a12:8fc6:4011::/48, premier repère historique du dossier, n'est pour sa part pas annoncé au moment de la consultation.

Le changement d'origine du préfixe IPv4 est un fait de routage, pas une explication commerciale. Les sources examinées ne disent pas s'il résulte d'une réaffectation, de la fin d'un accord, d'un changement de client, d'une modification technique ou de toute autre cause. Il serait donc injustifié de transformer l'observation en récit sur les relations entre Sovy Cloud Services et AS16045 BULINFO-HOSTING Spektar AD.

Pour la diligence, le point utile est différent. Une ancienne annonce ne garantit aucune continuité d'adressage. Si une organisation a utilisé des adresses associées à AS401110 dans une documentation, une liste blanche, une règle de pare-feu ou une procédure de reprise, elle doit vérifier qui les annonce aujourd'hui et si elles font toujours partie du service contracté. Le contrôle doit porter sur les préfixes actuels et leur origine actuelle, non sur une capture historique isolée.

Le cas IPv6 appelle la même discipline. L'absence actuelle d'annonce pour 2a12:8fc6:4011::/48 ne renseigne pas sur la raison de cette absence. Elle indique seulement que le préfixe n'offre pas, au moment du contrôle, une preuve publique de continuité IPv6 sous AS401110. Une promesse de connectivité IPv6 devrait donc être validée par une route, une adresse de test et un chemin effectivement observables.

Plusieurs zéros ne deviennent pas automatiquement une certitude

Le dossier actuel comporte une série de valeurs nulles: aucun préfixe annoncé dans la fenêtre consultée, aucun voisin dans la vue dédiée, aucune visibilité RIS actuelle, aucun LAN d'échange dans PeeringDB et aucun résultat DNS pour le domaine. L'accumulation est importante, mais elle doit être interprétée selon l'origine de chaque mesure. Compter simplement chaque zéro comme un vote indépendant produirait une confiance artificielle.

Les vues as-overview, announced-prefixes, routing-status et asn-neighbours de RIPEstat interrogent des dimensions différentes d'une même surface BGP publique. Leur cohérence réduit le risque qu'un seul champ vide ou qu'une seule réponse mal lue explique le résultat. Elle ne transforme pas quatre sorties d'un même système d'observation en quatre observateurs totalement indépendants. La réserve sur les routes de très faible visibilité reste pertinente pour l'ensemble de l'interprétation.

PeeringDB apporte une autre catégorie d'information, mais son zéro n'a pas le même sens. Zéro ligne netixlan signifie que le profil public ne déclare pas de présence sur un LAN d'échange. Ce n'est pas une mesure globale de tout transit ou de toute interconnexion. Les compteurs de préfixes et de points d'échange décrivent la fiche telle qu'elle est publiée; ils ne capturent pas nécessairement une architecture privée ou un service porté par un tiers. Leur convergence avec RIPEstat signale que le répertoire n'offre pas de contre-preuve publique actuelle, non qu'il observe lui-même l'absence de tout réseau.

Le domaine fournit un contrôle plus distinct. La disponibilité à l'enregistrement vient du registre .cloud, tandis que NXDOMAIN a été observé par le résolveur du système, Cloudflare et Google. Ces chemins concordants rendent robuste la conclusion limitée selon laquelle sovy.cloud n'existait pas dans le DNS public au moment du contrôle. Ils ne disent toujours pas si une autre adresse de marque ou un canal privé a pris le relais. Le domaine et le BGP peuvent disparaître ensemble pour plusieurs raisons; leur simultanéité ne révèle pas laquelle.

Une diligence défendable conserve donc, pour chaque résultat, quatre attributs: la question posée, la source, l'heure et la limite. Pour le DNS, la question est l'existence publique du nom au 20 juillet 2026. Pour RIPEstat, elle est la visibilité de routes associées à AS401110 dans les vues consultées à 08:00 UTC. Pour PeeringDB, elle est le contenu public du profil et de ses relations au moment de l'appel. Pour ARIN, elle est l'état de l'objet administratif. Une formulation qui garde ces périmètres visibles résiste mieux au temps qu'une étiquette générale comme « actif » ou « inactif ».

Cette méthode permet aussi de savoir quelle nouvelle preuve pourrait changer l'évaluation. Une annonce BGP actuelle et observable modifierait le constat de routage. Un domaine enregistré et résolu, officiellement relié à Sovy Cloud Services, modifierait le constat sur la surface de marque. Une confirmation datée d'une installation modifierait la valeur de la ligne correspondante. Un contrat ou une démonstration pourrait établir un service fourni par un autre ASN sans rendre fausses les observations sur AS401110.

Une conclusion utile doit pouvoir être révisée par une preuve précise; sinon, elle ressemble davantage à un verdict qu'à une analyse.

Des scénarios différents restent compatibles avec la même empreinte

Les sources publiques ne permettent pas de choisir une cause unique à la disparition des signaux actuels. Elles délimitent un problème de preuve, pas un récit complet sur l'entreprise. Plusieurs situations conceptuellement différentes peuvent produire un ASN toujours enregistré, une fiche PeeringDB encore renseignée, un domaine disponible et aucune route visible. Les énumérer ne consiste pas à affirmer qu'elles se sont produites. Cela sert à définir ce qu'il faudrait observer pour les départager.

Une première possibilité serait le déplacement de la surface technique. Un service pourrait être désormais fourni sous un autre domaine, un autre ASN ou les ressources d'un partenaire. Dans ce cas, l'absence sous AS401110 serait réelle sans équivaloir à l'absence de tout service. La preuve attendue serait un lien vérifiable entre Sovy Cloud Services, la nouvelle identité publique et le service vendu: documents contractuels cohérents, coordonnées actuelles, préfixes ou adresses de test, et explication de la responsabilité opérationnelle. Le paquet de sources examiné n'identifie aucune surface de remplacement de ce type.

Une deuxième possibilité serait une activité privée ou en marque blanche qui n'utilise pas la marque et l'ASN de la manière suggérée par les anciens annuaires. Le BGP public et le DNS de sovy.cloud auraient alors une portée limitée pour observer le service réel. Cette hypothèse ne peut pas être validée par son invisibilité même. Elle exige au contraire une démonstration directe: qui contracte, qui opère, quel réseau transporte le service, quels contrôles le client peut exercer et vers qui une alerte est escaladée. Sans ces éléments, « privé » ne peut pas devenir une explication passe-partout.

Une troisième possibilité serait une interruption, une mise en sommeil ou une réorganisation laissant les identifiants administratifs et les profils plus longtemps en place que l'exploitation publique. Les dates observées sont compatibles avec un décalage temporel: routage visible jusqu'en février 2025, remarques défavorables sur la validation des contacts après mai 2025, puis domaine disponible et absence de route en juillet 2026. Cette succession montre une dégradation des signaux; elle ne révèle ni décision sociale, ni durée prévue, ni statut de contrats éventuels.

Seule une information récente émanant d'une partie responsable pourrait préciser la situation.

Une quatrième possibilité serait que les entrées publiques soient simplement devenues obsolètes après une réduction ou une fin d'activité. C'est l'interprétation la plus tentante lorsque domaine et routes ont disparu, mais les sources disponibles ne la prouvent pas. Il manque notamment une annonce officielle, une donnée juridique concluante ou une confirmation directe. Une diligence rigoureuse doit pouvoir garder cette possibilité ouverte sans la transformer en constat de fermeture.

Ces scénarios n'ont pas à recevoir une probabilité improvisée. Ils conduisent à des demandes de preuve différentes et, surtout, à des décisions différentes. Si une nouvelle architecture existe, il faut l'évaluer telle qu'elle fonctionne maintenant. Si l'activité est privée, il faut obtenir des mécanismes de contrôle qui ne dépendent pas de sa visibilité publique. Si une interruption est temporaire, il faut connaître les conditions de reprise et les engagements encore applicables. Si les traces sont obsolètes, il faut éviter de contracter sur la foi de ces traces.

Le point commun est la nécessité d'une chaîne contemporaine reliant l'identité, le service et l'infrastructure. ARIN fournit le premier maillon historique et administratif. Le fournisseur doit apporter les suivants: identité contractante actuelle, canal de contact contrôlé, architecture ou dépendances pertinentes, moyens de test et responsabilité en cas d'incident. Tant que cette chaîne manque, la bonne réponse n'est ni de supposer le pire, ni d'adopter l'explication la plus favorable. Elle est de réduire l'engagement, de demander une preuve ciblée et de conserver une solution de sortie.

Une méthode de diligence fondée sur des niveaux de preuve

Le dossier Sovy Cloud Services est surtout utile parce qu'il oblige à classer les preuves selon la question posée. Tout mélanger produirait soit une confiance excessive, soit un verdict excessif. Une méthode plus robuste peut tenir en cinq niveaux.

Premier niveau: l'identité et la chronologie. L'enregistrement ARIN relie AS401110, AS-SOVYCLOUD, Sovy Cloud Services et SCSL-51. Les dates d'enregistrement et de modification fournissent des repères. Ce niveau est solide pour l'identité de registre. Il ne répond pas encore à la question de l'exploitation présente.

Deuxième niveau: la surface de marque actuelle. Le domaine sovy.cloud, son statut RDAP et sa résolution DNS permettent de savoir si la voie publique déclarée existe au jour du contrôle. Ici, disponibilité à l'enregistrement et NXDOMAIN concordent. Ce niveau est défavorable à la découvrabilité et à la vérification des contacts, tout en restant muet sur une éventuelle activité menée ailleurs.

Troisième niveau: la visibilité réseau actuelle. Les vues AS, préfixes, état de routage et voisins de RIPEstat doivent être lues ensemble et datées. Ici, elles ne montrent ni annonce, ni préfixe, ni voisin. La réserve sur les routes à très faible visibilité et les limites du BGP public doivent être conservées dans la conclusion.

Quatrième niveau: les déclarations d'écosystème. PeeringDB fournit la catégorie NSP, la portée mondiale, l'IRR, les installations et les compteurs publics. Ces données aident à formuler les contrôles. Lorsque le domaine et le routage ne corroborent plus la fiche, elles doivent être considérées comme une empreinte à rafraîchir, pas comme une attestation.

Cinquième niveau: la preuve directe d'exploitation. C'est ici que le fournisseur peut combler l'écart. Un acheteur peut demander l'identité contractante actuelle, des coordonnées testées, les ASN et préfixes réellement utilisés, une démonstration d'accès au service, les mécanismes d'incident et d'escalade, ainsi qu'une confirmation datée des lieux ou partenaires pertinents. La réponse peut montrer une architecture légitime qui n'apparaît pas sous AS401110. Elle peut aussi révéler que les documents publics ne reflètent plus le service vendu. Dans les deux cas, elle remplace l'inférence par une vérification.

Cette hiérarchie évite de donner le même poids à toutes les sources. Un registre stable est souvent excellent pour l'identité mais lent à refléter une évolution opérationnelle. Un répertoire communautaire peut être riche mais dépend de la maintenance de la fiche. Le DNS et le BGP sont plus proches de l'exploitation observable, mais ne donnent qu'une vue publique et datée. La preuve directe complète l'ensemble, à condition d'être récente, testable et liée au service effectivement proposé.

Ce qu'une PME devrait demander avant de dépendre du service

Pour une petite ou moyenne entreprise, le risque ne tient pas seulement à la probabilité d'une panne. Il tient à l'incertitude sur la personne à contacter, l'infrastructure réellement utilisée et la manière de sortir d'une dépendance si les hypothèses initiales étaient fausses. Dans ce dossier, les anciens repères publics ne suffisent plus à réduire cette incertitude.

Avant un nouvel engagement, l'acheteur devrait d'abord vérifier l'identité juridique qui émet le contrat et la facture, puis la relier explicitement à Sovy Cloud Services ou Sovy Cloud Services LLC. Il devrait obtenir un canal de contact qui ne dépende pas uniquement de sovy.cloud, le tester et identifier une procédure d'escalade. La remarque ARIN sur les POC non validés ne prouve pas l'absence de support, mais elle rend ce test raisonnable.

L'acheteur devrait ensuite demander une description actuelle du chemin réseau. Si AS401110 n'est plus annoncé, quel opérateur porte le trafic ? Quels préfixes et quelles adresses seront utilisés ? Existe-t-il un point de test avant migration ? Ces questions ne supposent pas que le fournisseur doive posséder tous les éléments de la chaîne. Elles visent à rendre visibles les dépendances qui portent réellement le service.

La liste PeeringDB appelle, elle aussi, une confirmation ciblée. Si une offre s'appuie sur l'une des cinq installations déclarées, le fournisseur peut préciser le rôle actuel de ce lieu et fournir une preuve adaptée à l'engagement proposé. L'objectif n'est pas d'exiger que les cinq lignes soient actives. Il est d'empêcher qu'une carte historique soit interprétée comme une architecture actuelle sans lien avec le contrat.

Enfin, la continuité doit être pensée comme une capacité de reprise. L'entreprise cliente devrait connaître le format et le délai d'export de ses données, les dépendances DNS et d'adressage, les conditions de résiliation, les sauvegardes qu'elle contrôle elle-même et le temps nécessaire pour basculer vers une autre plateforme. Ces mesures sont utiles pour tout petit fournisseur. Elles deviennent prioritaires lorsque la marque, le contact public et le réseau déclaré ne sont plus corroborés par des signaux actuels.

Une appréciation faible de l'exploitation publique, avec une incertitude assumée

Les preuves disponibles permettent une appréciation nuancée. L'identité de registre est forte: AS401110 existe dans ARIN, sous AS-SOVYCLOUD, avec une association explicite à Sovy Cloud Services. L'existence d'une activité de routage passée est également bien étayée: six préfixes apparaissent dans l'historique et les bornes temporelles situent une présence visible entre 2024 et février 2025.

La preuve publique d'une exploitation actuelle est, elle, faible. Le domaine de marque est disponible et renvoie NXDOMAIN. Les contacts de registre liés à ce domaine comportent des remarques de validation défavorables. PeeringDB conserve une empreinte mondiale et cinq installations, mais ne montre ni préfixe, ni LAN d'échange, ni contact public pour le réseau. RIPEstat ne voit aucun ASN annoncé, aucun préfixe courant, aucun voisin et aucune visibilité actuelle pour AS401110 dans les vues examinées.

Ce bilan ne doit pas être reformulé en certitude de fermeture. Les sources n'observent pas les contrats privés, les services en marque blanche, les clients servis par un autre réseau, les routes privées ni les communications directes. Elles ne démontrent pas non plus que les installations PeeringDB sont inactives. Elles montrent que les traces qui restent publiquement accessibles ne suffisent plus à prouver un cloud Sovy actuellement joignable et opéré sous la surface annoncée.

La conclusion pratique est donc conditionnelle. Si Sovy Cloud Services fournit encore des services, une contre-preuve récente et simple devrait pouvoir expliquer le domaine ou canal désormais utilisé, le réseau qui porte le trafic, les ressources effectivement servies, les contacts opérationnels et le rôle actuel des installations ou partenaires invoqués. En l'absence de cette corroboration, un client prudent doit traiter les anciennes fiches comme des pistes historiques, non comme une assurance de continuité.

Le principal enseignement dépasse cette entreprise. Dans l'infrastructure, les identifiants sont conçus pour durer, les annuaires pour être consultés et les routes pour changer. Une diligence sérieuse ne demande pas à une seule source de raconter toute l'histoire. Elle date chaque observation, sépare identité, déclaration et exploitation, puis cherche les points où des sources indépendantes se corroborent ou se contredisent. Pour Sovy Cloud Services, ce travail fait apparaître un ASN réel et un passé de routage réel, mais pas, au 20 juillet 2026, une preuve publique suffisante d'un cloud de marque actuellement actif.

Sovy Cloud Services: AS401110 demeure, mais la preuve publique d'un cloud actif s'amenuise