Résumé

  • Eternity Cloud Limited est une nouvelle société privée britannique avec une présence d'hébergement publique, un numéro AS actif et une petite route IPv4 visible. Le profil officiel surCompanies Houseindique une constitution le 27 octobre 2025, un statut actif, un siège social à Londres et un code SIC de conseil plutôt qu'une classification d'installations ou d'opérateur.
  • Le site public de l'entreprise oriente les utilisateurs vers les surfaces etyCloud, Whitewhale, identité, checkout et documents. Lesite ety.oneet lesite etyClouddécrivent un service cloud ou d'hébergement, tandis queWhitewhalepropose des plans VPS européens, un routage depuis son propre AS, un placement en centre de données Tier-1, une protection DDoS et une promesse de disponibilité de 99,9 %.
  • Les preuves réseau sont réelles mais étroites. L'objetAS201830 de RIPEnomme Eternity Cloud Limited,RIPEstatmontre un préfixe IPv4 /24 annoncé pendant la fenêtre d'observation, et lavalidation RPKImarque l'origine actuelle pour 82.41.36.0/24 comme valide.
  • Le risque pratique est la concentration des dépendances. Les données de routage publiques révèlent une empreinte d'un seul préfixe, un seul voisin observé dans la vue AS actuelle, aucune annonce IPv6 visible, des surfaces web et de compte frontées par Cloudflare, et aucune liste publique d'installations, d'historique de maintenance ou d'enregistrement d'incidents. Cela fait d'Eternity un petit fournisseur d'hébergement plausible, pas un opérateur d'infrastructure multisite éprouvé.

Pourquoi Eternity compte malgré sa taille

Les petites sociétés d'hébergement peuvent sembler marginales de l'extérieur car leurs dépôts juridiques sont minces, leurs sites web simples et leurs tables de routage réduites. Cela ne les rend pas pour autant insignifiantes. Un fournisseur VPS à bas prix peut toujours se trouver sur le chemin entre un développeur et une application en production, entre une petite entreprise et son panneau de contrôle, ou entre un projet régional et le seul serveur qu'il peut s'offrir. La question d'infrastructure n'est pas de savoir si Eternity Cloud Limited est assez grand pour rivaliser avec les plus grandes plateformes cloud.

Il s'agit de savoir si un acheteur peut comprendre ce qui est réellement acheté lorsque l'offre parle de cloud, VPS, emplacements européens, propre ASN, protection DDoS et capacité mensuelle à bas prix.

Les archives publiques donnent une réponse mitigée. Eternity a plus de substance qu'une simple page d'accueil. La société britannique existe. Le registre public de l'entreprise désigneEternity Cloud Limitedcomme une société privée à responsabilité limitée active. Les enregistrements RIPE relient le nom et l'adresse londonienne de l'entreprise à AS201830, et les données de routage publiques montrent un préfixe IPv4 annoncé par cet AS. La surface de service n'est pas qu'une page de logo: l'applicationetyCloudprésente un environnement de compte d'hébergement, et la pageWhitewhaledonne les noms des offres, les prix, les tailles de ressources et les affirmations réseau.

Ces mêmes archives montrent aussi pourquoi l'entreprise doit être lue avec prudence. Eternity a été constituée le 27 octobre 2025, de sorte qu'elle n'avait pas encore déposé son premier jeu de comptes au moment de cette analyse. Les premiers comptes sont dus en 2027 selon lapage de dépôt de Companies House. Le capital déclaré dans l'acte de constitution est faible. Le siège social est une adresse du centre de Londres souvent utilisée par de nombreuses entreprises, et non une preuve de centre de données. Les registres des dirigeants et du contrôle identifient un seul directeur actif et une personne exerçant un contrôle significatif,Mikhail Karlov, dont l'adresse de correspondance sur Companies House est la même que le siège social. Aucun de ces faits ne rend l'entreprise suspecte en soi. Ils définissent simplement le point de départ: un jeune opérateur avec peu d'historique financier public et une empreinte opérationnelle publique étroite.

Cette distinction est importante pour les acheteurs d'infrastructure car le risque dans la capacité hébergée est rarement situé dans le terme marketing. « Cloud » est une promesse commerciale, mais le service dépend encore de baies particulières, de fournisseurs amont, de blocs d'adresses, de DNS, de systèmes d'identité, de systèmes de facturation et de main-d'œuvre de support.

Si un serveur tombe en panne, une route est retirée, un service de compte rejette les connexions, un lien de paiement se brise, un événement DDoS déclenche un filtrage, ou un bloc d'adresses louées doit être déplacé, le client a besoin de chemins de récupération pratiques. Les archives publiques ne peuvent pas répondre à toutes les questions de support, mais elles peuvent montrer quelles dépendances sont visibles et lesquelles restent opaques.

L'empreinte publique d'Eternity suggère un fournisseur opérant à la lisière de cette transition. Il est suffisamment visible pour vendre de la capacité sous son propre nom et numéro de réseau. Il n'est pas encore assez visible pour permettre à un acheteur de vérifier indépendamment la diversité des installations, la diversité des transporteurs, la propriété du matériel, le personnel de réparation, les pratiques de sauvegarde, la transparence des incidents ou les garanties de migration.

Le résultat est une entreprise qui peut être significative pour une demande d'hébergement à bas prix tout en méritant une note de preuve réseau faible pour l'assurance publique.

Le registre de l'entreprise indique une entité nouvelle, active et étroitement contrôlée

Le point de départ juridique est simple. Leprofil Companies Houserépertorie Eternity Cloud Limited sous le numéro d'entreprise 16810688, une société privée à responsabilité limitée active, constituée en Angleterre et au Pays de Galles le 27 octobre 2025. Son siège social est au 71-75 Shelton Street, Londres, WC2H 9JQ. Le code SIC indiqué est 62020, « Activités de conseil en technologies de l'information ». Le registre indique que les premiers comptes sont établis jusqu'au 31 octobre 2026 et dus au 27 juillet 2027, avec une première déclaration de confirmation due en novembre 2026.

Pour un lecteur d'infrastructure, ces informations concernent moins la formalité que la maturité. Un fournisseur peut commencer à commercer avant le dépôt de ses premiers comptes, mais l'absence de comptes signifie qu'il n'y a pas de bilan public, pas de chiffre d'affaires déposé, pas de passif déposé et pas de vue vérifiée ou non des actifs derrière le service. Un client de capacité hébergée ne peut donc pas utiliser le registre des entreprises britanniques pour déduire le nombre de serveurs, l'ampleur des engagements fournisseurs, le volume des revenus, le niveau du fonds de roulement ou la profondeur des ressources de réparation.

Le registre confirme l'existence et le statut. Il ne confirme pas l'échelle opérationnelle.

Le dossier de contrôle est tout aussi concentré. Lapage des dirigeantsrépertorie Mikhail Karlov comme seul directeur actif, nommé à la date de constitution. Lapage des personnes exerçant un contrôle significatifindique que M. Mikhail Karlov détient 75 % ou plus des actions, 75 % ou plus des droits de vote et le droit de nommer ou de révoquer les directeurs. Companies House enregistre également une date d'échéance de vérification d'identité en novembre 2026 pour les enregistrements des dirigeants et des contrôleurs.

Un contrôle étroit est courant dans les jeunes sociétés d'hébergement. Cela peut permettre des décisions rapides, maintenir des prix agressifs et réduire la bureaucratie. Cela peut également créer un risque de personne clé. Si le routage, les relations fournisseurs, les litiges de facturation, la gestion des abus, la récupération d'identité et le support client dépendent tous d'un petit groupe fondateur, le service peut être plus fragile que ne le suggère la page produit.

Les archives publiques ne montrent pas de conseil d'administration, d'équipe de direction ou de personnel technique nommé au-delà du rôle NOC associé à l'entreprise dans les enregistrements RIPE. Un acheteur doit donc supposer que la continuité dépend fortement d'une couche humaine réduite, à moins qu'Eternity ne publie des informations opérationnelles plus solides.

Le siège social nécessite également un traitement prudent. Shelton Street est une adresse de correspondance juridique à Londres. Elle ne doit pas être interprétée comme un emplacement d'hébergement ou une installation réseau. Les enregistrements RIPE utilisent la même adresse pour les objets entreprise et contact, mais ces enregistrements établissent un contact administratif, pas un emplacement de baie. Le site Whitewhale parle de centres de données européens, et les données de routage indiquent des relations amont européennes, mais l'adresse publique de l'entreprise elle-même ne constitue pas une preuve de serveurs à Londres.

C'est un thème récurrent dans le profil public d'Eternity. Les enregistrements ne sont pas vides. Ils ne font tout simplement pas plus de travail que ce pour quoi ils sont conçus. Companies House prouve que l'entreprise existe, est active et contrôlée par une personne nommée. RIPE prouve qu'un AS et des objets de route ont été enregistrés. Les pages de service prouvent que quelqu'un fait de la publicité pour de la capacité VPS et cloud sous l'égide Eternity/etyCloud/Whitewhale.

Aucun de ces enregistrements, en soi, ne prouve la quantité de capacité physique déployée, la manière dont les fenêtres de réparation sont gérées, si du matériel de rechange est en stock, ou comment un client serait migré en cas de litige avec un fournisseur.

La surface de service est un cluster, pas une seule page produit

Le service public d'Eternity est réparti sur plusieurs domaines. Le site racineety.oneprésente la marque Eternity et propose des liens vers les produits, le support, la connexion au compte et l'inscription. Le texte et les ressources de la page publique lient la marque à etyCloud et Whitewhale, et le pied de page utilise le nom Eternity Cloud Limited. Le site expose également des points de contact de support public tels que[email protected]et des liens vers un centre de documentation en anglais et en russe. Cela donne à la marque plus de structure qu'une page de remplacement, mais la structure reste compacte.

Le siteetyCloudest la surface d'hébergement cloud directe. Sa description de page publique indique en russe qu'etyCloud fournit des solutions d'hébergement fiables et rapides pour les entreprises et les développeurs. Le titre du site le présente comme un hébergement abordable. Le texte de l'application montre les actions de compte utilisateur, la commande de serveurs, les factures, les tickets et les détails du serveur tels que processeur, mémoire, stockage, emplacement, canal, type de stockage et prix. Le site se présente donc comme un environnement de contrôle d'hébergement plutôt que comme une brochure d'entreprise générale.

Cela compte parce qu'un environnement de contrôle est l'endroit où les promesses cloud deviennent des promesses opérationnelles. Si un acheteur commande un serveur via etyCloud, l'expérience dépend de l'identité, de la création de compte, de la génération de paiement, du traitement des factures, du provisionnement des serveurs, de l'attribution d'adresses IP, du routage des tickets et de la réponse du support. Les ressources du site public montrent que ces composants existent en tant qu'interfaces web.

Elles ne prouvent pas le degré d'automatisation derrière elles, la manière dont les exceptions sont gérées, ni si la livraison des serveurs est immédiate, manuelle ou dépendante des fournisseurs.

Whitewhale ajoute une offre commerciale plus explicite. Sapage en anglaisqualifie Whitewhale de fournisseur cloud sur des emplacements européens, décrit « son propre ASN AS201830 », annonce des offres à partir de EUR 1 par mois et répertorie le support à[email protected]plus la facturation à[email protected]. Les cartes d'offres incluent KRILL à EUR 1 par mois avec 1 vCPU, 2 Go de RAM et 10 Go NVMe, NARWHAL à EUR 4 par mois avec 2 vCPU, 4 Go de RAM et 40 Go NVMe, ORCA à EUR 8 par mois avec 4 vCPU, 8 Go de RAM et 80 Go NVMe, LEVIATHAN à EUR 15 par mois avec 6 vCPU, 12 Go de RAM et 160 Go NVMe, et un niveau personnalisé WHITEWHALE+ à partir de EUR 25 par mois. La page annonce également un trafic illimité, des liaisons montantes partagées, une protection DDoS, des emplacements européens et une disponibilité de 99,9 %.

La page Whitewhale est utile car elle rend l'offre concrète. C'est aussi l'endroit où les acheteurs doivent ralentir. Des prix très bas et un langage de trafic illimité peuvent être légitimes lorsque la capacité est partagée, la sursouscription gérée et les règles d'abus strictes. Ils peuvent également devenir des points de pression lorsque des événements réseau, des voisins bruyants, des files d'attente de support ou des coûts fournisseurs augmentent.

Le tableau comparatif de Whitewhale indique que les plans d'entrée partagent 500 Mbps tandis que d'autres textes sur la page parlent d'une liaison montante à haute vitesse de 1 à 3 Gbps sur tous les VPS. Il peut s'agir d'une incohérence de présentation plutôt que d'une contradiction de service, mais cela montre pourquoi le débit exact engagé, les limites d'utilisation équitable et les pratiques de congestion doivent être confirmés avant de s'appuyer sur ces plans pour des charges de travail en production.

Le cluster de produits sépare également plusieurs rôles que les clients peuvent percevoir comme un seul service. Eternity est l'entreprise britannique. ety.one est la passerelle de marque et de compte. etyCloud est l'application d'hébergement. Whitewhale est l'offre VPS/cloud avec les affirmations réseau publiques les plus fortes. La surface d'identité se trouve sous auth.ety.one, et la surface de paiement sous checkout.ety.one. Le centre de documentation est sous documents.ety.one. En pratique, une panne client peut survenir dans n'importe laquelle de ces couches.

Un serveur peut encore fonctionner alors que le portail de compte est indisponible. Le portail de compte peut être accessible alors que la plage IP routée du client est dégradée. La facturation peut échouer alors que le calcul est sain. L'empreinte publique doit donc être lue comme une chaîne de service, et non comme un système unique.

C'est également là que Cloudflare entre en scène. Les en-têtes HTTP pour ety.one, cloud.ety.one, auth.ety.one, checkout.ety.one, documents.ety.one et Whitewhale montrent Cloudflare en périphérie web, et le DNS public pourety.one,cloud.ety.oneetwhitewhale.helpse résout dans l'espace d'adressage de Cloudflare. C'est un choix normal et souvent judicieux pour la diffusion web publique. Cela signifie également que le chemin visible du site web n'est pas la même chose que le chemin serveur-client d'AS201830. Cloudflare peut masquer l'emplacement d'origine, absorber certaines attaques au niveau web et maintenir une page marketing ou de compte accessible même lorsque le préfixe routé du fournisseur a un problème différent. La surface web est une preuve de la présentation du service, pas une preuve de la résilience du calcul en arrière-plan.

Le réseau routé est réel mais étroit

La preuve d'infrastructure la plus solide d'Eternity se trouve dans les enregistrements de routage. L'objetRIPE aut-num pour AS201830nomme l'AS comme ETERNITY-CLOUD-MNT, l'associe à ORG-ECL85-RIPE et l'enregistre comme attribué. L'objet a été créé le 29 janvier 2026 et modifié pour la dernière fois le 5 février 2026. Il répertorie des relations d'importation et d'exportation avec AS16276 et AS24940. AS16276 est OVH, et AS24940 est Hetzner. Ce sont des réseaux d'infrastructure européens importants, et leur apparition dans l'enregistrement de politique correspond à la revendication de Whitewhale d'un hébergement européen et d'un routage propre AS.

L'enregistrementRIPE RDAP ASrend le lien avec l'entreprise plus clair. Il nomme le handle AS201830, donne le nom ETERNITY-CLOUD-MNT, répertorie Eternity Cloud Limited comme entité titulaire et montre un contact NOC sous le nom Eternity Cloud. L'adresse dans ces objets RIPE correspond au siège social londonien. L'enregistrement RDAP répertorie également un contact abuse associé à[email protected]. Pris ensemble, ces enregistrements montrent une identité réseau réelle enregistrée plutôt qu'une simple revendication marketing.

La visibilité de routage est cependant plus petite que ce que l'existence d'un AS peut laisser entendre. Lavue d'ensemble AS de RIPEstatsignale AS201830 comme annoncé et nomme le titulaire comme Eternity Cloud Limited. Lavue des préfixes annoncés de RIPEstatmontre un seul préfixe IPv4 actuel, 82.41.36.0/24, pendant la fenêtre d'observation. Lavue de l'état de routage de RIPEstat pour l'ASmontre un préfixe IPv4 annoncé, 256 adresses IPv4, une visibilité IPv4 complète dans l'ensemble de rapports, aucun espace IPv6 annoncé dans cette vue et un voisin observé.

C'est suffisant pour dire qu'Eternity a une empreinte routée en direct. Ce n'est pas suffisant pour dire qu'il a un réseau large. Un seul /24 peut prendre en charge un véritable service client, en particulier pour les petits plans VPS, mais cela crée aussi une concentration. Si le préfixe est filtré, retiré, contesté, détourné, mis sur liste noire ou épuisé, il y a peu de preuves publiques de pools d'adresses alternatifs. Si le nombre de voisins observés reste à un, l'accessibilité du client peut dépendre d'un seul chemin amont effectif même si la politique de registre répertorie plus d'un fournisseur autorisé.

Si aucun IPv6 n'est visible, les clients ayant besoin d'un service double pile doivent se demander si IPv6 est indisponible, non annoncé, fourni par un autre chemin ou simplement non représenté dans la vue publique actuelle.

L'enregistrement du préfixe ajoute une autre couche. Lavue d'ensemble du préfixe de RIPEstat pour 82.41.36.0/24identifie AS201830 comme origine annonçante. L'objetde route RIPEenregistre l'origine AS201830 pour ce /24 et a été créé le 29 janvier 2026. Lavalidation RPKIindique que l'origine est valide, avec un ROA autorisant AS201830 à annoncer le /24 exact. C'est une bonne hygiène. Un ROA valide réduit une classe d'ambiguïté d'origine de route et aide les réseaux à rejeter les annonces d'origine non valides conflictuelles.

L'attribution d'adresse comporte également un indice de dépendance. Lesdonnées whois de RIPE pour 82.41.36.0/24et l'enregistrement RDAP IPidentifient le nom de réseau NET-82-41-36-0-24, le pays UE, une organisation d'utilisateur final liée à Eternity Cloud Limited, un objet de route maintenu par netutils-mnt et un geofeed associé à IPXO. Le bloc d'adresses est public et routé, mais le contexte de maintenance et de geofeed indique une chaîne de ressources d'adressage au-delà d'Eternity elle-même. C'est courant sur le marché IPv4. C'est également pertinent pour les clients car les arrangements de ressources d'adressage peuvent affecter la portabilité, la gestion des abus, la géolocalisation, la réputation et la continuité si une relation commerciale change.

Les données de chemin visibles renforcent l'image de dépendance. Unerequête looking-glass de RIPEstat pour 82.41.36.0/24montre que de nombreux collecteurs voient des chemins se terminant via AS16276 vers AS201830. Cela correspond à la politique aut-num et suggère qu'OVH est un chemin amont en direct important pour le préfixe annoncé. Cela ne prouve pas, en soi, l'emplacement de l'installation, la capacité amont de réserve ou un basculement réussi vers Hetzner. Un client doit traiter le chemin public comme une preuve d'accessibilité, et non comme une preuve de résilience multi-opérateur.

Les baies, le transit et les fenêtres de réparation sont le produit caché

L'expression « capacité hébergée » semble numérique, mais elle est vendue à partir de couches physiques et contractuelles. Quelqu'un doit posséder ou louer les serveurs. Quelqu'un doit fournir l'alimentation, le refroidissement, les interconnexions et les interventions à distance. Quelqu'un doit transporter les paquets vers le reste d'Internet. Quelqu'un doit maintenir les enregistrements d'adresses, les objets de route, RPKI et les boîtes aux lettres d'abus. Quelqu'un doit répondre aux tickets lorsqu'un serveur est en panne mais que le site web est toujours en ligne.

Les preuves publiques concernant Eternity identifient certaines de ces couches, mais laissent les parties les plus opérationnelles sans nom.

Whitewhale dit que son infrastructure fonctionne sur des emplacements européens et des centres de données de premier plan avec une alimentation et une connectivité redondantes. Il annonce également une protection DDoS et un SLA de disponibilité de 99,9 %. Ce sont des affirmations commercialement significatives. Elles nécessitent également des détails avant de devenir une garantie.

Une promesse de disponibilité de 99,9 % peut signifier beaucoup de choses selon qu'elle s'applique à la disponibilité du réseau, à l'alimentation du serveur, à l'accès au panneau de contrôle, à la disponibilité de la VM client, aux services de paiement, aux performances de stockage ou à la réponse du support. Elle peut également être mesurée sur différentes périodes, avec différentes exclusions pour la maintenance planifiée, les attaques, les erreurs de configuration du client et les pannes amont.

Les pages publiques ne nomment pas les installations, les fournisseurs de baies ou les villes derrière la revendication « emplacements européens ». Elles ne publient pas de page looking-glass sous la propre marque d'Eternity, de page d'état du réseau, d'archive d'incidents, de calendrier de maintenance, de carte de route, de liste des fournisseurs de transit en production, de guide de communauté BGP, de partenaire d'atténuation DDoS, d'objectif de remplacement de matériel ou de promesse de conservation des sauvegardes. Certains petits fournisseurs choisissent de ne pas publier ces détails pour des raisons de sécurité ou commerciales.

Mais pour un client utilisant le service comme infrastructure, chaque détail manquant devient une question à poser avant de s'y fier.

La première question est de savoir où la capacité est physiquement hébergée. Si les serveurs sont dans les installations d'OVH ou d'Hetzner, ou en colocalisation connectés à ces réseaux, le profil de fiabilité reflétera les règles d'alimentation, de réseau et d'intervention à distance de ces fournisseurs. Si les serveurs sont des machines dédiées louées plutôt que du matériel possédé, la réparation peut dépendre de la file d'attente de support du fournisseur. Si les serveurs sont possédés mais placés dans des baies tierces, la réparation dépend des pièces de rechange, des droits d'accès et de la réponse aux interventions à distance.

Si le fournisseur revend de la capacité virtuelle à partir d'une plateforme plus grande tout en présentant une couche AS propre, les limites opérationnelles diffèrent encore. Les archives publiques ne répondent pas à cette question.

La deuxième question est de savoir comment la diversité amont fonctionne réellement. L'objet aut-num RIPE répertorie des entrées de politique AS16276 et AS24940. La vue AS de RIPEstat montre un voisin observé. Les données looking-glass pour le préfixe actuel montrent fortement des chemins AS16276. Cela ne prouve pas que AS24940 est inutilisé, mais cela signifie que la vue publique au moment de l'examen ne démontre pas une diversité active équilibrée.

Si un chemin orienté OVH tombe en panne, un acheteur voudrait savoir si la route peut passer à Hetzner, si ce passage est automatique ou manuel, si les filtres de préfixe sont pré-approuvés, si le nettoyage DDoS reste disponible et combien de temps la convergence prend normalement.

La troisième question est de savoir comment les adresses sont gouvernées. La route 82.41.36.0/24 est valide sous RPKI, ce qui est bien. Les données whois et RDAP du bloc font également référence à netutils-mnt, aux informations de geofeed IPXO et à une organisation d'utilisateur final. Cela suggère un arrangement de ressources d'adressage où les enregistrements de plus d'une partie comptent. Si la géolocalisation est erronée, les rapports d'abus sont mal gérés, un préfixe développe une mauvaise réputation ou le contrat d'adresse change, les clients peuvent rencontrer des problèmes qui ne sont pas résolus simplement en redémarrant un serveur.

Les acheteurs d'hébergement à bas prix sous-estiment souvent cette couche jusqu'à ce que la livraison des e-mails, la vérification des paiements, les règles d'accès régionales ou le score de fraude commencent à mal traiter une plage IP.

La quatrième question est le délai de réparation. L'interface etyCloud semble inclure des tickets, des factures et des détails de serveur. Whitewhale publie des adresses e-mail de support et de facturation. Le site racine Eternity publie des informations de contact de support. Ce sont des canaux clients nécessaires. Ils ne sont pas la même chose qu'une garantie de réparation publiée.

Un petit fournisseur peut répondre rapidement, mais un acheteur public ne peut pas déduire un personnel 24/7, des pools de capacité de réserve, des droits d'escalade avec les fournisseurs amont ou une communication post-incident à partir des seuls e-mails de contact. La page Whitewhale dit que le support est 24/7, mais les clients doivent encore demander comment les pannes urgentes sont classées, si des crédits sont offerts et quelles informations sont fournies lors d'un événement réseau.

La cinquième question est la sortie du client. Une capacité VPS bon marché est attrayante parce que le coût d'entrée est faible. Le coût de sortie peut être élevé si un client n'a pas de sauvegardes actuelles, pas d'étapes de reconstruction documentées, pas de plan DNS, pas de chemin IP alternatif et pas de migration de test. Les pages publiques d'Eternity ne publient pas de garanties de portabilité des sauvegardes, d'exportation d'instantanés, d'effacement des données, de téléchargement d'images ou de migration d'urgence. Cela ne signifie pas que ces fonctionnalités sont absentes.

Cela signifie que les acheteurs doivent considérer la portabilité comme leur propre responsabilité à moins que le contrat ne dise le contraire.

Cloudflare protège la porte d'entrée, pas tous les serveurs clients

La périphérie web publique est une dépendance distincte du réseau d'hébergement routé. Les réponses DNS pour ety.one, cloud.ety.one et whitewhale.help pointent vers des adresses anycast Cloudflare, et les réponses HTTP identifient Cloudflare comme le serveur devant les pages. Le point de terminaison d'authentification sousauth.ety.onerenvoie une réponse protégée plutôt qu'une page d'application publique, tandis quecheckout.ety.onerenvoie une réponse de type application à la racine. Le centre de documentation sousdocuments.ety.oneest également fronté par Cloudflare.

Cet arrangement est judicieux pour un jeune fournisseur. Cloudflare peut absorber les attaques web courantes, fournir une terminaison TLS, mettre en cache les pages publiques, améliorer l'accessibilité des pages et réduire l'exposition des serveurs d'origine. Cela peut également donner l'impression que la marque est plus disponible que le réseau de calcul sous-jacent lors de certains incidents. Une page marketing peut être accessible via Cloudflare alors que le VPS d'un client sur 82.41.36.0/24 est inaccessible. Inversement, un serveur client peut toujours fonctionner alors que la surface d'authentification ou de paiement est dégradée.

Pour les clients, ce sont des pannes différentes avec des remèdes différents.

Cette distinction est souvent manquée dans la diligence raisonnable des petits fournisseurs. Un acheteur charge le site web, voit que la page est rapide et suppose que la plateforme d'hébergement est tout aussi résiliente. Mais le chemin du site web utilise le réseau de Cloudflare. Le chemin du serveur client, s'il est attribué à partir du préfixe routé actuel d'Eternity, dépend d'AS201830, de son chemin amont actuel, du bloc d'adresses, du réseau de l'installation et du serveur lui-même. Le chemin du compte dépend d'auth.ety.one. Le chemin de facturation dépend de checkout.ety.one. Le chemin de documentation dépend de documents.ety.one.

Le chemin de support dépend des e-mails et du traitement des tickets. Ces couches peuvent échouer indépendamment.

Le DNS public montre également des enregistrements de routage de courrier Cloudflare pour ety.one et Whitewhale. C'est encore normal, mais cela signifie que la réception des e-mails pour les adresses de support et de facturation a sa propre dépendance de service. Si une panne client inclut l'incapacité de recevoir ou d'envoyer des e-mails, la communication de support peut être affectée par le DNS, le routage de courrier, le filtrage anti-spam, l'accès au compte et la réponse humaine. Rien de tout cela n'est propre à Eternity. C'est la pile ordinaire derrière les petits fournisseurs d'hébergement.

Le risque est que le faible prix mensuel donne l'impression que la pile est plus simple qu'elle ne l'est.

Il y a aussi un angle de gouvernance. Les pages publiques frontées par Cloudflare peuvent être mises à jour rapidement et peuvent masquer la topologie d'origine. C'est utile pour la sécurité, mais cela réduit ce que les observateurs extérieurs peuvent vérifier. Le client voit la marque, le plan et le paiement. Le chercheur réseau voit un AS, un préfixe IPv4 visible, RPKI valide et des surfaces web Cloudflare. Le chaînon manquant est la plateforme de production: hyperviseurs, stockage, sauvegardes, contrats d'installation, basculement de transit et pratiques du personnel.

Un acheteur sérieux n'a pas besoin que tout cela soit publié sur une page d'accueil, mais doit demander suffisamment de détails pour correspondre au risque de la charge de travail.

Ce que les clients doivent déduire de la tarification

L'échelle des prix de Whitewhale est l'un des signaux publics les plus clairs sur le marché visé. Les plans commençant à EUR 1 par mois ne sont pas des offres de cloud d'entreprise. Ce sont des offres VPS à petit budget destinées aux développeurs, aux petits projets, aux expériences et aux charges de travail sensibles aux coûts. Cela peut être précieux. De nombreux services Internet commencent sur des machines virtuelles bon marché parce que l'alternative n'est pas un contrat hyperscale; c'est de ne pas lancer du tout.

La question est de savoir à quoi un client renonce à ce niveau de prix. Les fournisseurs VPS à bas prix s'appuient généralement sur une utilisation élevée, des liaisons montantes partagées, des contrôles d'abus stricts, des flux de support simples et des garanties limitées sur mesure. La page Whitewhale est ouverte sur la bande passante partagée sur les cartes de plan, tout en annonçant un trafic illimité. « Illimité » dans ce contexte ne doit pas être interprété comme une capacité dédiée infinie.

Cela signifie généralement qu'il n'y a pas de plafond de transfert mensuel fixe dans le cadre de règles d'utilisation acceptable, et non que chaque client peut saturer en permanence la liaison montante partagée sans conséquence. Un acheteur doit se renseigner sur l'utilisation équitable, la limitation de débit, les seuils DDoS, les restrictions de port, la politique de courrier et ce qui se passe lorsque le trafic affecte les voisins.

Le tableau des plans indique également les aspects économiques de l'hébergement. Le plan KRILL offre 1 vCPU, 2 Go de RAM et 10 Go NVMe pour EUR 1 par mois. Même à grande échelle, ce prix laisse peu de marge pour une intervention manuelle coûteuse. Un ticket de support qui prend une heure peut dépasser plusieurs mois de revenus bruts pour ce client. Cela ne signifie pas que le support sera médiocre. Cela signifie que le service doit être standardisé, automatisé et strict quant à la portée pour être durable.

Les clients ayant des besoins inhabituels ne doivent pas supposer qu'une ingénierie personnalisée est fournie avec un plan VPS économique, sauf si elle est explicitement vendue.

Les surfaces de compte publiques d'Eternity renforcent cette forme de libre-service. etyCloud semble présenter la commande de serveurs, les tickets, les factures, l'état du serveur et les champs de configuration. Le point de terminaison de paiement est séparé sous checkout.ety.one, et la surface d'identité est séparée sous auth.ety.one. C'est un modèle standard pour un petit fournisseur essayant de réduire le travail manuel. Cela donne aux clients un moyen familier d'acheter et de gérer des serveurs. Cela signifie également que la surface de contrôle elle-même fait partie du service.

Si les factures, les paiements ou l'accès au compte échouent, les modifications de serveur et les renouvellements peuvent être affectés même lorsque la VM sous-jacente est toujours alimentée.

Pour les utilisateurs en production, la tarification devrait conduire à une hiérarchisation. Un serveur à EUR 1 ou EUR 4 peut convenir à un nœud de surveillance, un environnement de test, un projet personnel, un petit relais, une charge de travail de préproduction ou un site web à faible risque. Il ne convient pas automatiquement à une application critique pour les revenus, à moins que le client ne dispose de sauvegardes, de surveillance, de DNS secondaire, d'un deuxième fournisseur, d'étapes de restauration testées et d'une acceptation claire des temps d'arrêt.

Les preuves publiques d'Eternity ne justifient pas de traiter le service comme une plateforme de fournisseur unique pour des charges de travail à haute valeur sans assurances supplémentaires.

Pour les utilisateurs sensibles à la vie privée ou à la juridiction, le langage « emplacements européens » est attrayant mais incomplet. Whitewhale dit que les emplacements sont européens et mentionne la localisation GDPR/UE dans son texte de comparaison. L'enregistrement de préfixe RIPE indique le pays UE. L'entreprise elle-même est enregistrée au Royaume-Uni, la résidence du contrôleur sur Companies House est la Géorgie, le champ de nationalité du dirigeant indique russe et la périphérie web est Cloudflare. Rien de tout cela n'est intrinsèquement disqualifiant.

Cela signifie simplement que les questions de localisation des données et de juridiction doivent être précises. Où se trouve l'hôte de la VM? Où sont les sauvegardes? Quelle entité juridique contracte avec le client? Quelle loi régit l'accord? Quels sous-traitants traitent l'identité, le paiement, le filtrage DDoS, les e-mails et le support? Les pages publiques ne répondent pas entièrement à ces questions.

Abus, confiance et le coût d'être bon marché

Tout fournisseur VPS à bas prix doit gérer les abus. Des serveurs virtuels bon marché et rapides attirent à la fois les développeurs légitimes et le trafic indésirable. Le spam, les attaques par identifiants, le scan, la revente de proxy, les plaintes pour droits d'auteur, la fraude au paiement et les représailles DDoS peuvent arriver plus vite que les revenus. La page de Whitewhale met l'accent sur des règles claires et une utilisation légale. Les enregistrements RIPE publient des contacts d'abus. Ce sont de bons signes, mais la gestion des abus est un autre domaine où les archives publiques sont minces.

Le bloc d'adresses est important ici. Un seul /24 ne contient que 256 adresses IPv4. Si un petit nombre de clients brûlent la réputation par le spam, les rappels de logiciels malveillants ou l'abus de proxy, les voisins innocents peuvent hériter des conséquences via le listage noir, la notation du risque de paiement, les CAPTCHA, la suspicion de géolocalisation ou le rejet de courrier. RPKI protège la validité de l'origine de la route; il ne protège pas la réputation IP. Cloudflare protège les pages web publiques; il ne rend pas le trafic d'origine du client digne de confiance.

Un client utilisant Eternity pour des charges de travail sensibles au trafic sortant doit tester la réputation IP et demander si des remplacements propres sont disponibles si une adresse est déjà endommagée.

La structure de contact d'abus est également divisée. Les données RDAP d'AS montrent un contact d'abus associé à ety.one. L'enregistrement RDAP de préfixe pour 82.41.36.0/24 répertorie un e-mail d'abus sous abuseradar.com. Ce n'est pas nécessairement un problème; les fournisseurs de ressources d'adressage gèrent souvent les contacts d'abus pour les blocs attribués. Mais cela signifie que les rapports peuvent passer par les règles de traitement de plus d'une organisation.

Les clients qui hébergent du contenu généré par les utilisateurs, du courrier, des proxys, des serveurs de jeux ou d'autres services sujets aux plaintes doivent comprendre quelle décision peut suspendre un serveur, annuler une route IP ou exiger des informations sur le client.

La confiance est également façonnée par la documentation. Lecentre de documentationd'Eternity fournit une surface de document juridique publique avec des options de langue, et le site racine renvoie aux documents de contrat d'abonnement. La présence de documents est positive. L'acheteur public doit encore inspecter l'accord exact utilisé lors de l'inscription, car les conditions des petits fournisseurs contrôlent souvent les parties les plus importantes du service: éligibilité au remboursement, délais de renouvellement, annulation, suspension, utilisation interdite, conservation des données, plafonds de responsabilité, crédits SLA, juridiction et droits de résiliation. Le risque opérationnel n'est pas seulement de savoir si le serveur est rapide; c'est de savoir si le contrat donne au fournisseur de larges droits de suspendre le service pendant les litiges ou les événements d'abus.

Les fournisseurs à bas prix vivent également sous la pression de leurs propres fournisseurs. Si les frais amont augmentent, un bail de préfixe change, le trafic DDoS augmente ou une installation impose des règles d'abus plus strictes, un petit fournisseur peut avoir besoin de changer rapidement les prix, les emplacements, les plages d'adresses ou les conditions. Les clients publics doivent surveiller les signes de continuité: avis de renouvellement, messages d'état, explications publiques d'incidents, canaux de support stables, historique de route propre et langage de tarification cohérent.

L'empreinte publique actuelle d'Eternity est trop jeune pour montrer un long modèle.

La meilleure interprétation des preuves

L'interprétation généreuse est qu'Eternity Cloud Limited est un jeune fournisseur réel, assemblant une offre d'hébergement européenne autour d'une société britannique, de son propre AS enregistré, d'un /24 IPv4, de services publics frontés par Cloudflare, d'une interface d'hébergement en libre-service et d'une marque VPS économique en Whitewhale. L'entreprise a enregistré les objets de réseau public nécessaires, annoncé une route valide, publié des contacts de support et de facturation et présenté des détails de plans concrets. C'est plus qu'une vague page d'entreprise.

L'interprétation prudente est que la surface opérationnelle visible reste étroite. Un seul /24 actuel et un seul voisin observé ne montrent pas une large résilience réseau. Les pages publiques n'identifient pas les installations, la propriété du matériel, la diversité active des fournisseurs amont, les engagements de réparation, les garanties de sauvegarde ou un long historique d'incidents. L'entreprise est nouvellement constituée et étroitement contrôlée, sans comptes déposés à ce jour.

Les surfaces web sont frontées par Cloudflare, ce qui améliore la présentation publique mais sépare la disponibilité du site web de la disponibilité des serveurs clients. Le bloc d'adresses semble se situer dans une chaîne de ressources d'adressage plus large, ce qui est normal mais ajoute une autre dépendance.

Les deux lectures peuvent être vraies. Eternity peut être un vrai petit fournisseur tout en restant un pari d'infrastructure faiblement documenté. C'est la bonne catégorie à garder à l'esprit pour les acheteurs. Le service peut convenir aux charges de travail à faible risque et sensibles aux coûts. Il peut être utile comme nœud secondaire, serveur de test, petit hébergeur web, environnement de laboratoire, relais régional ou projet qui valorise un faible coût mensuel plutôt que des garanties formelles d'entreprise.

Il ne doit pas être traité comme une plateforme résiliente éprouvée simplement parce qu'il utilise le langage cloud, annonce son propre ASN ou a une route valide.

La mise à niveau la plus importante serait la transparence opérationnelle. Eternity pourrait améliorer considérablement son assurance publique en publiant une page d'état, une liste d'installations ou de zones métropolitaines, une courte page réseau nommant les fournisseurs amont actifs, un plan IPv6, une page de looking-glass de route, une politique d'abus, un document SLA définissant la mesure et les crédits, une politique de sauvegarde et d'instantané, et une archive d'incidents.

Elle pourrait également clarifier si Whitewhale est un produit d'Eternity Cloud Limited, comment etyCloud et Whitewhale sont liés contractuellement, quelle entité juridique facture les clients et quelles conditions régissent chaque service. Aucune de ces divulgations ne nécessite de révéler une topologie sensible. Elles réduiraient simplement l'ambiguïté.

Les clients peuvent réduire leur propre risque sans attendre. Ils doivent tester un serveur d'essai avant de déplacer une charge de travail, vérifier la latence et la perte de paquets depuis les régions pertinentes, vérifier le comportement du courrier sortant et du risque de paiement, confirmer la plage IP attribuée, lire l'accord, tester la réponse du support, se renseigner sur les sauvegardes, conserver des copies hors fournisseur, utiliser un DNS indépendant, surveiller depuis l'extérieur du réseau et maintenir un deuxième fournisseur pour les systèmes critiques.

Plus le prix mensuel est bas, plus ces contrôles côté client sont importants.

Conclusion

Eternity Cloud Limited doit être considéré comme un opérateur d'hébergement émergent avec une empreinte réseau publique réelle mais petite. L'entreprise existe dans les registres britanniques, propose des services d'hébergement et de cloud via ses propres propriétés web, relie sa marque à etyCloud et Whitewhale, détient AS201830 dans les enregistrements RIPE, annonce 82.41.36.0/24 et dispose d'un RPKI valide pour cette route. Ce sont des faits significatifs.

Ces mêmes faits ne prouvent pas qu'Eternity contrôle une capacité physique profonde, dispose d'un transit en direct redondant, maintient du matériel de rechange, opère dans plusieurs installations ou peut rétablir rapidement le service client lors d'incidents complexes. Le produit vendu aux clients n'est pas seulement du CPU, de la RAM et du stockage NVMe. C'est une chaîne d'accès aux baies, de contrats fournisseurs, de politique de transit, de gouvernance d'adresses, de gestion DDoS, de services de compte frontés par Cloudflare, de chemins de paiement, de documentation, de tickets et de main-d'œuvre de réparation.

Les preuves publiques montrent des parties de cette chaîne et laissent d'autres parties non vérifiées.

Cela rend la note de preuve actuelle faible plutôt que négative. Le fournisseur est visible, routé et commercialement présent. L'incertitude n'est pas de savoir s'il y a une empreinte publique; l'incertitude est de savoir si l'empreinte publique peut soutenir la résilience impliquée par le mot cloud. Jusqu'à ce qu'Eternity publie plus de détails opérationnels ou construise un historique public plus long, les acheteurs doivent le traiter comme une option d'hébergement économique qui peut être utile au bon niveau, et non comme une dépendance d'infrastructure à laquelle se fier sans sauvegardes, surveillance et un chemin de sortie clair.