Résumé
- Network LIGA HOSTING LTD est l'identité orientée infrastructure de l'activité d'hébergement public de LIGA HOSTING LTD. Le Companies House enregistre la société numéro 17069738 comme une société privée à responsabilité limitée active en Angleterre et au Pays de Galles, constituée le 4 mars 2026 avec le code SIC 63110, tandis que les conditions de la société indiquent que l'activité d'hébergement est active depuis 2019 et sert des clients dans plus de 30 pays.
- La surface de service public est suffisamment réelle pour être testée: LigaHosting annonce des VPS Standard à Tulcea et à Francfort, des VPS Performance Ryzen 9 9950X à Francfort, un hébergement web cPanel avec des sauvegardes quotidiennes de sept jours, et un hébergement de jeux sous la marque roumaine. Le même site revendique l'AS201131, une protection DDoS, des liaisons montantes de 10 à 40 Gbps, un provisionnement de VPS en moins de 60 secondes et un SLA mensuel de 99,9 % pour le réseau et l'infrastructure principale.
- L'AS201131 est actuellement visible. Le RIPE RDAP identifie l'AS201131 comme LGH-Network, enregistré au nom de LIGA HOSTING LTD le 3 mars 2026; la dernière vue de l'état de routage de RIPEstat montre trois IPv4 /24 et deux IPv6 /48 avec une visibilité RIS complète ou quasi complète. Les trois paires origine-route IPv4 vérifiées sont validées sous RPKI, tandis que les deux IPv6 /48 actuelles ont renvoyé une validation inconnue dans la vue RIPEstat vérifiée.
- Le niveau de preuve estMoyen. Les preuves publiques de routage, de produit, d'état et de contrat étayent une empreinte d'hébergement opérationnelle, mais le dossier ne prouve toujours pas la propriété des racks, les exploitants des installations, les chemins d'alimentation doubles, le matériel de rechange, la diversité de routage à l'intérieur de chaque site, les restaurations testées ou les droits de migration des clients.
Une nouvelle société britannique enveloppant une histoire d'hébergement plus ancienne
Le premier fait à distinguer est l'identité juridique de l'historique d'exploitation.Companies Houseenregistre LIGA HOSTING LTD sous le numéro de société 17069738, active, constituée le 4 mars 2026, avec un siège social situé au 3rd Floor, 86-90 Paul Street, Londres, EC2A 4NE et une nature d'activité 63110, traitement de données, hébergement et activités connexes. Lapage des dirigeantsrépertorie Ionel-Florin Florin Moisa en tant qu'administrateur actif, nommé à la date de constitution. Leregistre des personnes ayant un contrôle significatifenregistre Ionel-Florin Moisa avec la propriété d'actions et de droits de vote de 75 % ou plus, ainsi que le droit de nommer ou de révoquer des administrateurs.
Cela rend la société visible, mais jeune. Ses premiers comptes ne sont pas exigibles avant décembre 2027 et sa première déclaration de confirmation n'est pas exigible avant mars 2027. Les clients ne peuvent donc pas encore consulter un historique de dépôt mature, un historique des comptes ou une longue séquence d'événements d'entreprise. Cela importe lorsqu'un acheteur décide si un serveur à bas prix est une contrepartie durable ou une marque d'hébergement en évolution rapide qui pourrait changer de forme juridique, d'arrangements de ressources d'adresse ou de fournisseurs d'exploitation.
Le site public raconte une histoire commerciale plus longue. Lesconditions de LigaHosting, mises à jour le 29 avril 2026, indiquent que LIGA HOSTING LTD exploite les marques ligahosting.com pour l'hébergement VPS international et web cPanel et ligahosting.ro pour l'hébergement de jeux, est active depuis 2019, dessert des clients dans plus de 30 pays et gère une infrastructure VPS en Roumanie et en Allemagne. Cette déclaration d'historique plus ancien peut bien décrire la marque ou l'opération commerciale avant la constitution de la société britannique. Il ne faut pas l'interpréter comme un historique Companies House pour le numéro de société 17069738.
La distinction n'est pas tatillonne. Si un service a des clients plus anciens, des panneaux de contrôle plus anciens ou des contrats d'infrastructure antérieurs, une nouvelle société peut hériter de certaines pratiques d'exploitation sans hériter d'un long historique de dépôts légaux.
Si la société est une enveloppe nouvellement formalisée autour d'une entreprise d'hébergement roumaine ou européenne existante, les clients doivent demander quelle entité juridique signe le contrat actuel, quelle entité possède ou loue le matériel, quelle entité détient les comptes fournisseurs et ce qu'il advient des services existants si une autre marque, un compte revendeur ou un ancien panneau reste dans la chaîne.
Le siège social à Londres n'est pas non plus une revendication de centre de données. L'adresse Companies House et les données d'organisation structurées du site identifient une adresse d'entreprise, pas un emplacement de rack. Cela correspond à une société britannique vendant une infrastructure roumaine et allemande. Cela n'établit pas que les données des clients sont traitées au Royaume-Uni, que le personnel de soutien est à Londres, ou que l'entreprise possède une installation au Royaume-Uni. L'histoire de l'hébergement doit être vérifiée au regard des pages de produits, des pages d'état, des tables de routage et des conditions.
Ce que la surface de produit public vend
Les pages de produits montrent un service destiné aux petits et moyens acheteurs d'hébergement plutôt qu'à un cloud hyperscale. Lesite principal de LigaHostingannonce « VPS Standard & Performance », une protection DDoS, un déploiement instantané, une connectivité réseau premium, du matériel d'entreprise et une portée européenne en Roumanie et en Allemagne. Il désigne l'AS201131 comme le backbone de l'entreprise et indique que le provisionnement des VPS prend moins de 60 secondes. Il annonce également des liaisons montantes de 10 à 40 Gbps et des réponses de support en moins de 15 minutes. Ce sont des affirmations commerciales, mais elles sont suffisamment spécifiques pour se traduire en questions physiques.
Lapage VPS Standardnomme deux nœuds d'infrastructure: Tulcea, Roumanie, décrit comme Standard sur du matériel dual Intel Xeon Gold 6254, et Francfort, Allemagne, décrit comme Standard sur AMD EPYC 7702. Les fiches de plan vont des petites instances VPS vers le haut et incluent une adresse IPv4 et une protection DDoS. Lapage VPS Performanceconcentre le niveau haute fréquence à Francfort sur des processeurs AMD Ryzen 9 9950X, avec des plans qui évoluent de 1 vCPU, 2 Go de RAM et 100 Go NVMe à 12 vCPU, 64 Go de RAM et 1,6 To NVMe. C'est une histoire de calcul concrète, pas seulement une étiquette « cloud » vide.
Lapage d'hébergement webajoute une surface de produit différente: hébergement cPanel, stockage SSD, SSL gratuit, comptes de messagerie et sauvegardes quotidiennes. Web Starter annonce 20 Go de stockage SSD et un site web. Web Pro étend le stockage et la portée du compte. Web Business annonce un stockage SSD illimité, des sites web illimités et une IP dédiée gratuite. Le changement de dépendance important est que l'hébergement cPanel concentre plusieurs comptes sur des serveurs partagés et des systèmes administratifs partagés, tandis que l'hébergement VPS donne à l'acheteur un accès root mais transfère également plus de responsabilité de sauvegarde et de configuration à l'acheteur.
La marque roumaine d'hébergement de jeux ajoute un autre signal.LigaHosting.roannonce un hébergement de serveurs de jeux en Roumanie et en Allemagne, un objectif de disponibilité de 99,9 %, un support 24/7 et un panneau d'infrastructure montrant la Roumanie sur 5.180.33.0/24 et l'Allemagne sur 163.5.26.0/24. Elle répertorie le calcul en Roumanie comme une plateforme Intel Core i9-14900K avec 192 Go de DDR5 et 2 To NVMe, tandis que l'Allemagne est une plateforme AMD Ryzen 9 9950X avec 128 Go de DDR5 et 2 To NVMe. Ces affirmations de page correspondent à deux des préfixes IPv4 visibles de l'AS201131, mais elles n'identifient toujours pas l'exploitant de l'installation ni ne prouvent la capacité de réserve.
Lapage d'étatest également utile car elle nomme les emplacements de service en termes opérationnels: Tulcea, Roumanie pour VPS Standard, et Francfort, Allemagne pour VPS Standard, VPS Performance et hébergement Web. Elle affichait « Tous les systèmes opérationnels » et aucun incident actif lors de la vérification, les deux emplacements étant marqués comme opérationnels. Une page d'état verte actuelle n'est pas une archive de disponibilité, mais elle indique aux clients ce que le fournisseur considère comme ses composants de service public.
C'est suffisamment de preuves pour dire que LigaHosting n'est pas simplement une coquille vide. Il a un catalogue public, des emplacements de service actifs, des revendications de processeurs spécifiques, une page d'état client, des conditions et un réseau en direct. Ce n'est pas suffisant pour dire que l'entreprise possède les racks, contrôle les bâtiments ou peut déplacer toutes les charges de travail entre les régions. Un acheteur de VPS voit un nom de plan, une famille de CPU et une adresse IP. La décision de résilience dépend de ce qui se cache derrière ces étiquettes.
L'AS201131 est visible, mais la visibilité n'est pas synonyme de contrôle partout
La preuve technique la plus solide est le réseau.Le RIPE RDAP pour l'AS201131identifie l'AS201131 comme LGH-Network, enregistré le 3 mars 2026 et modifié pour la dernière fois le 15 juin 2026, avec LIGA HOSTING LTD comme organisation titulaire et contact d'abus [email protected].L'aperçu AS de RIPEstatidentifie le titulaire comme « LGH-Network LIGA HOSTING LTD » et marque l'ASN comme annoncé. Cela aligne la revendication du site avec les preuves de routage public.
L'ensemble de routes actuel est compact.La vue de l'état de routage de RIPEstata montré, pour la dernière requête du 12 juillet 2026, trois préfixes IPv4 totalisant 768 adresses IPv4 et deux IPv6 /48. Elle a signalé une visibilité IPv4 complète sur les pairs RIS et une visibilité IPv6 quasi complète.La vue des préfixes annoncés de RIPEstata également montré que plusieurs IPv6 /48 étaient apparues au cours de la fenêtre de deux semaines précédente, mais n'étaient plus dans l'ensemble à haute visibilité actuelle au 12 juillet. C'est assez normal pour un petit réseau, mais cela signifie que les acheteurs doivent distinguer les routes de production actuelles de la visibilité de route récente ou expérimentale.
Les trois préfixes IPv4 actuels correspondent à la géographie des produits.5.180.33.0/24,163.5.26.0/24et146.19.215.0/24étaient chacun visibles avec l'AS201131 comme origine dans les vues de l'aperçu des préfixes de RIPEstat. Le site roumain de jeux mappe explicitement 5.180.33.0/24 à la Roumanie et 163.5.26.0/24 à l'Allemagne. Les pages de produits officielles et la page d'état placent les services VPS et d'hébergement web en Roumanie et en Allemagne. Cela donne une géographie plausible: la Roumanie et l'Allemagne sont les régions de service destinées aux clients, avec la société britannique comme contrepartie juridique.
La sécurité de l'origine de la route est un point positif pour IPv4.La validation RPKI de RIPEstat pour 5.180.33.0/24,163.5.26.0/24et146.19.215.0/24ont renvoyé valide pour l'AS201131. Un RPKI valide ne rend pas un serveur fiable, mais il réduit une classe de défaillances de routage en indiquant aux réseaux qui effectuent une validation d'origine que l'AS201131 est autorisé à annoncer ces préfixes.
Le tableau IPv6 est plus faible. Les vérifications actuelles de l'aperçu des préfixes pour2a06:9801:c2::/48et2a06:9801:22c::/48les ont montrés annoncés par l'AS201131, mais les URL de validation RPKI vérifiées ont renvoyé inconnu plutôt que valide. Inconnu ne signifie pas invalide. Cela signifie que la vue vérifiée n'a pas trouvé d'autorisation d'origine de route validante pour la paire origine-préfixe interrogée. Pour les clients qui exigent une IPv6 native et une assurance d'origine de route, c'est une question à régler avant l'achat.
Les preuves en amont nécessitent un langage prudent. L'enregistrement aut-num de la base de données RIPErépertorie une politique d'importation et d'exportation impliquant AS209735, AS58061, AS58212, AS213323 et AS207841.La vue des voisins ASN de RIPEstata observé quatre voisins au dernier moment vérifié: AS213323, AS397373, AS58061 et AS58212.CAIDA AS Ranka vu l'AS201131 comme un petit AS avec trois fournisseurs, aucun client observé et aucun pair observé dans son ensemble de données. Les noms et rôles exacts diffèrent entre les enregistrements de politique de routage et les ensembles de données d'observation, ce qui est attendu dans BGP. La conclusion prudente est que l'AS201131 est multiconnecté dans l'observation publique, mais le dossier public ne prouve pas quels fournisseurs en amont desservent chaque emplacement, si les deux sont actifs dans chaque région, ou si les chemins de fibre et les paires de routeurs sont physiquement diversifiés.
PeeringDB ajoute une absence de plus. Larequête API PeeringDB pour l'AS201131n'a renvoyé aucun objet réseau lors de la vérification. Ce n'est pas un défaut; de nombreux petits réseaux ne maintiennent pas de profil PeeringDB. Cela signifie que les clients ne peuvent pas utiliser PeeringDB pour confirmer les présences d'installations, les LAN d'échange, la politique de peering public ou les niveaux de trafic. Pour un opérateur qui vend sur le langage « propre backbone », la publication d'un profil d'interconnexion de base rendrait la surface de contrôle plus facile à vérifier.
L'histoire des racks se tait au point le plus important
Un serveur hébergé est vendu comme un objet logiciel, mais il tombe en panne comme un objet physique. Le site peut provisionner un VPS en quelques secondes uniquement parce qu'un véritable serveur est déjà alimenté, refroidi, connecté et installé dans un rack. Un serveur de jeu peut annoncer une faible latence uniquement parce que les paquets transitent par la commutation en haut de rack, les routeurs de bordure, les fournisseurs de transit et l'atténuation DDoS.
Un compte cPanel peut promettre des sauvegardes uniquement parce que le stockage et les tâches de sauvegarde s'exécutent quelque part avec suffisamment de disque, de bande passante et d'attention de l'opérateur.
Pour LigaHosting, les emplacements visibles sont Tulcea et Francfort. C'est mieux qu'une vague revendication « Europe ». L'écart restant est l'identité de l'installation. Les sources publiques examinées pour cet article n'ont pas identifié l'exploitant du centre de données à Tulcea, l'installation de Francfort, la propriété des racks, le nombre d'armoires, la conception de l'alimentation électrique, le fournisseur d'intervention à distance, l'étendue de la suppression d'incendie, la redondance de refroidissement, la salle de rencontre des opérateurs ou le processus de remplacement du matériel.
Le site public indique « une infrastructure cloud européenne en Roumanie et en Allemagne »; il ne dit pas si LIGA HOSTING LTD possède le matériel dans des racks colocalisés, loue des serveurs dédiés, revend une plateforme, ou mélange ces modèles par produit.
Cela importe car une installation, un rack et un cluster de virtualisation sont des couches différentes. Un centre de données de Francfort peut avoir plusieurs arrivées de services publics, des systèmes UPS et des générateurs, tandis qu'un locataire branche toujours un serveur à cordon unique sur une seule multiprise. Un rack peut se trouver dans une bonne installation alors que son commutateur en haut de rack reste un point de défaillance unique. Un serveur peut avoir deux périphériques NVMe alors que les instantanés résident sur le même nœud.
Un indicateur vert au niveau du site peut coexister avec un hôte défaillant ou un pool de stockage surchargé.
Les preuves produit indiquent une plateforme compacte. La page VPS Standard mentionne les nœuds Tulcea dual Intel Xeon Gold 6254 et Francfort AMD EPYC 7702. La page Performance mentionne le Ryzen 9 9950X de Francfort. Le site de jeux mentionne les plateformes Core i9-14900K en Roumanie et Ryzen 9 9950X en Allemagne. Ce sont des classes de serveurs d'hébergement familières, et elles peuvent offrir un excellent rapport qualité-prix pour de petites charges de travail. Elles ne prouvent pas à elles seules le basculement de cluster, la migration en direct, le stockage distribué ou les serveurs de rechange.
Ladéfinition du cloud computing du NISTest utile ici car elle sépare un véritable pool de ressources élastiques des machines virtuelles hébergées ordinaires. Un produit VPS peut offrir un large accès réseau et un certain provisionnement en libre-service sans prouver une élasticité rapide, un service mesuré, un pooling inter-hôte ou une résilience multi-sites. Le mot « cloud » dans le pied de page d'un site d'hébergement ne règle pas l'architecture. Le test est de savoir si un client peut perdre un nœud, un rack ou un site et récupérer dans une fenêtre connue.
Pour un petit fournisseur, cet écart n'est pas inhabituel. De nombreuses entreprises d'hébergement réelles ne publient pas de contrats d'installation ni de schémas de racks. Le problème n'est pas que l'information soit absente de la page d'accueil. Le problème est que les clients qui achètent des charges de travail de production doivent poser la question car les preuves ne peuvent être déduites. Quels produits sont à nœud unique? Lesquels utilisent un stockage répliqué? Lesquels ont des instantanés? La Roumanie et l'Allemagne sont-elles des domaines de défaillance indépendants ou simplement des emplacements de produits distincts?
La VM d'un client peut-elle se déplacer entre eux? L'adresse IP se déplace-t-elle avec elle? Ces réponses déterminent si le produit est une capacité bon marché ou une capacité résiliente.
La capacité installée n'est pas une capacité récupérable
La table de routage donne une limite supérieure sur certaines ressources réseau, pas sur le calcul. Trois IPv4 /24 donnent 768 adresses IPv4 dans l'ensemble d'origines public actuel. Un plan d'une IPv4 par VPS peut consommer ces adresses rapidement, mais le nombre d'adresses n'indique pas combien d'hôtes physiques existent. Un serveur peut prendre en charge de nombreuses instances VPS bas de gamme. Un client peut consommer de nombreuses adresses. Certaines adresses sont réservées à l'infrastructure, au remplacement en cas d'abus, aux tests de routage ou à la croissance future.
Le nombre d'IPv4 est donc une contrainte, pas un registre de capacité.
Il en va de même pour les processeurs annoncés. Un hôte Ryzen 9 9950X peut être attrayant pour les charges de travail de jeux et de VPS performance à haute fréquence. Il peut également devenir un domaine de défaillance brutal si de nombreux serveurs sensibles à la latence partagent un seul boîtier physique. Un nœud AMD EPYC ou dual Xeon peut prendre en charge de nombreuses instances VPS standard, mais la capacité de réserve dépend de la marge de mémoire, de la marge de stockage, du surengagement du CPU et de la disponibilité d'un autre nœud compatible.
Les pages publiques indiquent les spécifications des plans, pas les ratios de surengagement ni les pools de réserve à chaud.
Le stockage est l'autre frontière cachée. NVMe peut signifier des disques locaux rapides sur un hôte, un stockage local en miroir, un serveur de stockage séparé ou un système de stockage distribué. Chaque conception a un comportement de défaillance différent. Le NVMe local peut être extrêmement rapide jusqu'à ce qu'un disque, un contrôleur ou un hôte tombe en panne. Le stockage local en miroir peut survivre à un disque mais pas à toutes les pannes d'hôte.
Le stockage distribué ne peut tolérer la perte de nœud que si les répliques sont réparties sur des machines indépendantes, que le quorum survit et que le trafic de reconstruction ne submerge pas le réseau. Les pages publiques de LigaHosting annoncent du stockage NVMe et SSD mais ne décrivent pas l'architecture de durabilité des plans VPS.
Le produit d'hébergement web est plus clair car les conditions indiquent que les plans d'hébergement web cPanel reçoivent des sauvegardes quotidiennes automatiques conservées pendant sept jours. C'est utile, mais ce n'est pas la même chose qu'une réplication continue ou une sauvegarde immuable hors site. Cela protège certains clients de la perte de serveur et des erreurs ordinaires, à condition que les sauvegardes se terminent, restent lisibles et soient stockées en dehors de la panne qui a endommagé le serveur principal.
Les conditions indiquent explicitement que les sauvegardes internes sont destinées à la reprise après sinistre au niveau du serveur et que le fournisseur ne garantit pas leur intégrité ou leur disponibilité. C'est une limitation prudente, et les clients doivent y voir un avertissement pour conserver leurs propres copies.
Le produit VPS est plus clair dans le sens inverse: les sauvegardes ne sont pas incluses par défaut. Les conditions indiquent que les clients VPS sont responsables de leurs propres sauvegardes et que des instantanés ou des sauvegardes supplémentaires peuvent être disponibles moyennant des frais. C'est une limite honnête, mais elle fait passer le produit de « l'hôte restaurera mon serveur » à « l'hôte peut maintenir la VM en fonctionnement, mais je suis propriétaire de la récupérabilité à moins d'acheter et de tester plus ».
Tout acheteur qui considère un VPS par défaut comme une infrastructure sauvegardée a manqué l'arrangement d'exploitation.
Le SLA de 99,9 % du fournisseur doit également être lu comme un mécanisme de crédit, pas comme une garantie de récupération.Les conditionsdéfinissent une disponibilité mensuelle de 99,9 % pour le réseau et l'infrastructure principale, soit environ 43 minutes de temps d'arrêt non planifié par mois, avec des exclusions pour la maintenance planifiée, les attaques DDoS dépassant la capacité d'atténuation, la force majeure, le code client et les logiciels tiers. Si le SLA n'est pas respecté, le recours du client est un crédit de compte lié au paiement mensuel, plafonné à 50 %. Cela ne reconstruit pas une base de données, ne rend pas une réputation IP perdue et ne compense pas une interruption d'activité au-delà des frais de service.
C'est normal pour l'économie de l'hébergement. Les prix mensuels bas dépendent de la limitation de responsabilité, des systèmes partagés, de l'automatisation et de la responsabilité du client. La question pratique est de savoir si les clients ont adapté leur propre risque à cette transaction. Un serveur de jeu de loisir peut accepter quelques heures d'arrêt et une restauration à partir d'une copie locale. Une agence hébergeant des sites clients, une application orientée paiement ou un serveur de messagerie avec des listes d'autorisation IP doit considérer le produit par défaut comme un seul composant d'un plan de récupération plus large.
La diversité de transit doit être testée à l'intérieur de chaque emplacement de service
Le routage public de l'AS201131 est l'un des meilleurs éléments du dossier. Il est actif, compact et visible. Les trois routes IPv4 sont validées, et RIPEstat voit plusieurs voisins. Le site revendique des liaisons montantes de 10 à 40 Gbps, une connectivité européenne premium et une protection DDoS en périphérie du réseau. Ces faits soutiennent une véritable exploitation réseau. Ils ne prouvent pas que chaque emplacement dispose de chemins physiques indépendants.
La différence importe en cas de panne. Un serveur roumain peut avoir une adresse AS201131 tout en dépendant d'une seule liaison montante locale, d'un commutateur ou d'une interconnexion d'installation. Un nœud de performance à Francfort peut se cacher derrière un mélange de transit plus solide mais avoir toujours une seule paire de routeurs orientée client. Le filtrage DDoS peut bien fonctionner jusqu'à ce que la taille de l'attaque dépasse la capacité souscrite ou que le filtrage détourne le trafic d'une manière qui augmente la latence pour les serveurs de jeux.
Une table BGP montre la accessibilité depuis les collecteurs de routes, pas le chemin de câble à travers un bâtiment.
LaRFC 7454décrit des contrôles opérationnels tels que le filtrage de préfixes, les contrôles de chemin AS, les limites de préfixes maximum et l'hygiène de la politique de routage. La validation RPKI complète cela en répondant à la question de savoir si une origine de route est autorisée. L'état d'origine de route IPv4 vérifié de LigaHosting est positif, mais l'hygiène BGP n'est pas la même chose que l'ingénierie de la disponibilité. Une route valide peut toujours être retirée accidentellement, filtrée par un fournisseur en amont, mise en trou noir pendant l'atténuation, ou bloquée derrière une interconnexion défaillante.
L'enregistrement de la politique de routage montre également pourquoi les clients doivent poser des questions directes. L'enregistrement aut-num RIPE répertorie les importations de plusieurs ASN, et RIPEstat observe un ensemble en direct différent. Ce n'est pas suspect en soi. C'est ainsi que les registres de routes et le BGP en direct diffèrent souvent. Pour un achat en production, cependant, la question pertinente n'est pas « combien de noms se trouvent dans l'objet de politique? », mais « quels fournisseurs en amont transportent activement le préfixe de ce client depuis ce site, et que se passe-t-il si l'un d'eux tombe en panne? »
La divulgation la plus utile serait une simple déclaration de connectivité site par site: la Roumanie a ces fournisseurs en amont, Francfort a ces fournisseurs en amont, les deux sont surveillés, l'atténuation DDoS se trouve ici, la maintenance planifiée est annoncée via ces canaux, et les changements de route d'urgence sont autorisés par ces personnes. Les noms des installations et les adresses des routeurs n'ont pas besoin d'être publics. L'objectif est de montrer si le réseau annoncé comme un backbone dispose de chemins indépendants là où le serveur du client fonctionne réellement.
Pour l'hébergement de jeux, la qualité de la route n'est pas seulement la disponibilité. La latence et la gigue comptent. Une route qui reste active mais qui fait un détour par un autre pays peut donner l'impression aux joueurs que le serveur est cassé. Le site de jeux mesure la latence depuis l'appareil de l'utilisateur et affiche des sondes de région, ce qui est utile au moment de l'achat. Cela ne remplace pas les données de latence historiques, les rapports de perte de paquets ou les notes d'incident.
Les clients ayant des charges de travail compétitives ou communautaires doivent exécuter leurs propres sondes depuis les géographies de joueurs qui importent.
La facturation et le contrôle du compte font partie de la surface de panne
Les conditions rendent un chemin de défaillance inhabituellement explicite. Les services sont facturés à l'avance. Si une facture reste impayée, des e-mails de rappel sont envoyés pendant les jours un et deux suivant l'échéance, le service est automatiquement suspendu le jour trois, un avertissement final de résiliation apparaît le jour sept, et le jour quatorze, le service est résilié et toutes les données sont définitivement supprimées.
Les conditions indiquent que les données supprimées ne peuvent pas être récupérées et que la réactivation après résiliation nécessite une nouvelle commande et ne garantit pas la même IP, le même nom d'hôte ou les mêmes données.
Ce n'est pas seulement un langage financier. C'est une dépendance opérationnelle. Un serveur en état de marche peut devenir indisponible parce qu'une carte a échoué, un compte PayPal a été bloqué, la confirmation de cryptomonnaie a pris du retard, l'e-mail de facturation est allé dans les spams, un employé de l'agence est parti, ou un compte côté client a été compromis. De l'extérieur, le service est en panne même si le rack, l'alimentation et la route sont sains. L'équipe technique la plus rapide ne peut pas restaurer une VM résiliée dont les données ont été délibérément supprimées en vertu des règles de facturation.
La règle de suppression au jour 14 affecte également la migration. Si un client attend qu'une fenêtre de contestation ou de non-paiement ait déjà commencé, le temps restant pour exporter les données, réduire les valeurs TTL DNS, répliquer les bases de données et tester un autre fournisseur peut être court. Si le titulaire du compte est absent, le propriétaire du service peut même ne pas recevoir les rappels. L'accès multi-personne au compte, des contacts de facturation surveillés et des sauvegardes indépendantes sont donc des contrôles de disponibilité, pas des subtilités administratives.
Les conditions de remboursement renforcent la même logique économique. La garantie de remboursement de 30 jours s'applique à une première commande de service d'hébergement pour les nouveaux clients, pas aux domaines, aux frais de configuration marqués comme non remboursables, aux serveurs dédiés ou au matériel personnalisé, aux renouvellements, aux comptes résiliés pour violation des conditions ou à certains cas de remboursement en cryptomonnaie. C'est normal pour l'hébergement. Cela signifie également que les clients ne doivent pas utiliser la remboursabilité comme substitut aux tests.
Une charge de travail doit être évaluée, sauvegardée et restaurée ailleurs pendant le premier mois, lorsque la friction de sortie est la plus faible.
Le contrôle du compte peut également affecter la continuité de l'adresse IP. Les conditions ne promettent pas qu'un service restauré ou réactivé conserve la même adresse IP après résiliation. De nombreuses charges de travail hébergées peuvent se déplacer derrière un DNS si le client contrôle la zone. Certaines ne le peuvent pas. Les intégrations de paiement, les listes d'autorisation de sécurité, la réputation de messagerie, les communautés de serveurs de jeux et les API partenaires dépendent souvent d'IP stables.
Un client utilisant LigaHosting doit documenter quelles dépendances peuvent tolérer un changement d'IP et lesquelles nécessitent une notification préalable ou un deuxième fournisseur.
Les fenêtres de maintenance et les tests de restauration déterminent le produit réel
Les conditions publiques s'engagent à ce que la maintenance planifiée soit annoncée au moins 48 heures à l'avance et exclue du SLA. C'est une norme de préavis raisonnable pour les clients, mais cela laisse des questions pratiques. Quel canal transmet l'avis? Apparaît-il sur la page d'état, par e-mail, dans l'espace client ou sur Discord? L'avis nomme-t-il l'emplacement, le nœud ou le produit affecté? Un client peut-il reporter un redémarrage? La maintenance d'urgence est-elle traitée différemment?
La page d'état actuelle montre l'état en direct, pas une archive de maintenance, de sorte qu'un acheteur ne peut pas encore inspecter comment les travaux précédents ont été communiqués.
Les fenêtres de réparation sont particulièrement importantes pour les petits fournisseurs d'hébergement car la panne traverse souvent les frontières des fournisseurs. Si un nœud tombe en panne à Tulcea, le fournisseur peut avoir besoin d'une intervention locale. Si une interconnexion à Francfort tombe en panne, l'installation ou l'opérateur doit agir. Si un fournisseur DDoS met une destination en trou noir, l'opérateur réseau doit coordonner le filtrage. Si un nœud de performance Ryzen a un défaut de carte mère, le remplacement dépend de la disponibilité de stock compatible.
Les clients n'ont pas besoin de chaque nom de fournisseur, mais ils ont besoin de savoir qui peut agir et à quelle vitesse.
Leguide sur les rançongiciels de la CISArecommande des sauvegardes chiffrées hors ligne, des tests réguliers de disponibilité et d'intégrité, des images de référence et la prise en compte d'un deuxième fournisseur de cloud. Les conseils sont rédigés pour les cyberincidents, mais la même discipline de récupération s'applique à la perte de stockage, à la suspension de compte et au matériel défaillant. Une sauvegarde qui n'a jamais été restaurée est un espoir, pas un contrôle.
Ledocument de planification d'urgence du NISTencadre la récupération autour d'équipements de remplacement, de sites de remplacement, de stockage de remplacement et de télécommunications. Pour un client de LigaHosting, la version pratique est simple: exportez l'application, restaurez-la sur un autre fournisseur, pointez un nom d'hôte de test vers elle, confirmez l'authentification et les e-mails, et chronométrez l'exercice. Si la restauration nécessite que le VPS d'origine soit en ligne, le plan de récupération est trop dépendant du système défaillant.
Pour les utilisateurs de cPanel, la fenêtre de sauvegarde de sept jours du fournisseur est utile mais courte. Elle peut protéger contre une mise à jour cassée découverte rapidement, mais peut ne pas couvrir une corruption lente, une compromission restée cachée pendant des semaines, ou un client qui demande une récupération après la résiliation du compte. Pour les utilisateurs de VPS, la situation par défaut est plus sévère: pas de sauvegardes incluses.
Les instantanés peuvent aider à une restauration immédiate, mais les instantanés sous le même compte fournisseur ne protègent pas contre la fermeture du compte, la suppression côté fournisseur ou un événement de service à l'échelle de la région.
Le modèle client propre est donc un modèle à plusieurs niveaux. Conservez les instantanés du fournisseur s'ils sont abordables et testés. Conservez des sauvegardes indépendantes en dehors du compte. Gardez le DNS et l'enregistrement de domaine sous le contrôle du client. Stockez les notes de déploiement, les informations d'identification et la configuration dans un système séparé. Testez la restauration sur une petite VM dans un autre emplacement.
Pour les charges de travail où l'adresse IP elle-même fait partie du service, maintenez un plan de communication pour modifier les listes d'autorisation et une route de secours via un autre fournisseur.
La localité est divisée entre la constitution au Royaume-Uni et l'infrastructure européenne
L'entreprise est constituée en Angleterre et au Pays de Galles. Les emplacements de service public sont la Roumanie et l'Allemagne. La marque d'hébergement de jeux est orientée vers le marché roumain et le contenu produit est bilingue ou multilingue sur la surface publique. Il s'agit d'un arrangement d'hébergement européen viable, mais cela signifie que « local » dépend de la question de l'acheteur. Un client britannique peut avoir une contrepartie juridique au Royaume-Uni et du calcul situé dans l'UE. Une communauté de joueurs roumaine peut avoir une région de service en Roumanie mais un contrat avec une société britannique.
Un client allemand de VPS performance peut moins se soucier du domicile de l'entreprise que du routage de Francfort et du traitement des données.
Les données personnelles en font une question de contrat et de cartographie. Lesconseils de l'ICO sur les transferts internationauxexpliquent que les organisations doivent comprendre quand les informations personnelles sont transférées ou rendues accessibles à travers les frontières. Lesconseils de l'ICO sur les responsables de traitement et les sous-traitantsexpliquent pourquoi le rôle de chaque partie affecte les obligations. Un client d'hébergement ne peut pas répondre à ces questions à partir du seul code pays de l'IP.
La relation UE-Royaume-Uni n'est pas non plus la même que « n'importe où en Europe, c'est pareil ». Lesinformations de la Commission européenne sur l'adéquationexpliquent le mécanisme par lequel la Commission peut décider qu'un pays tiers offre une protection adéquate, et la Commission a annoncé en janvier 2026 qu'elle a renouvelé les décisions d'adéquation pour le Royaume-Uni. Cela aide les flux de données UE-Royaume-Uni, mais ne règle pas tous les transferts ultérieurs, l'accès du support à distance, l'accès des sous-traitants, les sauvegardes ou les journaux.
La législation européenne en matière de cybersécurité ajoute une autre optique. Ladirective NIS 2couvre des catégories d'infrastructures numériques importantes, y compris le cloud computing et les services de centre de données, sous réserve de la transposition nationale et de seuils de taille ou de rôle. Une petite société d'hébergement peut ou non relever d'un champ d'application national particulier, et cet article ne constitue pas une évaluation juridique. Le point opérationnel est que les clients doivent identifier quelle entité fournit le service, où les données et les sauvegardes sont stockées, et quels sous-traitants peuvent accéder aux systèmes.
La souveraineté des données inclut également la gestion des pannes. Si une sauvegarde est copiée dans un autre pays, si le personnel de support peut accéder à une console depuis une autre juridiction, si l'atténuation DDoS détourne le trafic via un autre réseau, ou si les journaux sont conservés dans un service SaaS tiers, la carte pratique des données est plus large que l'emplacement VPS annoncé.
Les conditions publiques de LigaHosting indiquent que le contenu du client reste la propriété du client et accordent au fournisseur un droit limité de stocker, de copier à des fins de sauvegarde et de redondance, et de transmettre le contenu pour fournir les services. Les conditions ne publient pas de carte pays par pays des sous-traitants ou des emplacements de sauvegarde.
Pour les charges de travail ordinaires à faible risque, la structure Royaume-Uni-Roumanie-Allemagne peut suffire si le client la comprend. Pour les données personnelles réglementées, les communautés sensibles, les charges de travail du secteur public ou les clients ayant des engagements stricts en matière de localité, l'acheteur doit demander un accord écrit de traitement des données, une carte des emplacements pour les données de production et de sauvegarde, des contrôles d'accès au support, des règles de suppression et des détails sur les sous-traitants.
Le site public donne un point de départ, pas une réponse complète en matière de souveraineté.
Qui est affecté lorsque le système tombe en panne
Les utilisateurs probablement exposés ne sont pas seulement les personnes dont les noms figurent sur les factures. Une petite agence peut héberger de nombreux sites clients sur un seul plan cPanel ou plusieurs instances VPS. Un propriétaire de serveur de jeu peut soutenir une grande communauté qui ne connaît qu'un nom de domaine et un canal Discord. Un développeur peut exécuter une API pour des utilisateurs payants. Une entreprise peut héberger la messagerie sur un plan partagé et découvrir pendant une panne que les réinitialisations de mot de passe, les factures et les communications de support dépendent toutes du même fournisseur.
Pour les clients VPS, les modes de défaillance directs sont familiers: un nœud hôte plante, un périphérique de stockage tombe en panne, un filtre DDoS réagit de manière excessive, un fournisseur en amont change de politique, ou un événement de facturation suspend l'accès. Les défaillances indirectes sont souvent pires. Un client n'a pas de sauvegarde hors site actuelle. Le DNS est détenu par le même compte. Le seul administrateur utilise une boîte aux lettres électronique sur le serveur défaillant. L'application dépend d'une IP codée en dur. Un instantané existe mais ne peut pas être téléchargé ou restauré ailleurs.
Dans chaque cas, la fenêtre de récupération du fournisseur ne devient qu'une partie de la panne.
Pour les clients d'hébergement web, le risque lié au serveur partagé est différent. Un compte abusif ou compromis peut affecter la réputation du serveur, la délivrabilité du courrier ou les limites de ressources. Les conditions se réservent le droit de limiter, de demander des mises à niveau ou de suspendre les services qui affectent d'autres clients sur le même serveur physique. C'est nécessaire pour l'hébergement partagé, mais cela signifie que le client ne contrôle pas entièrement l'environnement de performance.
Le langage de bande passante et de stockage « illimité » est limité par l'utilisation normale et exclut la distribution de fichiers volumineux, la diffusion multimédia, les serveurs de téléchargement ou l'utilisation de type CDN sur l'hébergement partagé.
Pour l'hébergement de jeux, l'impact est autant social que technique. Les communautés de joueurs remarquent immédiatement le lag, la perte de paquets, les redémarrages et les changements de région. Un nœud qui est techniquement en ligne mais congestionné peut toujours vider un serveur. Une IP modifiée peut casser les listes de serveurs, les favoris enregistrés et les instructions de la communauté.
Le site roumain donne des informations utiles sur la région et le matériel, mais les clients qui gèrent des communautés sérieuses doivent demander comment les panneaux de jeu, les répertoires de données, les packs de mods et les bases de données sont sauvegardés et à quelle vitesse un serveur peut être déplacé entre la Roumanie et l'Allemagne.
Pour les trois familles de produits, le contrôle le plus fort du client est la portabilité. Gardez les noms de domaine indépendants. Faites surveiller les contacts de paiement et de support par plus d'une personne. Conservez la configuration de l'application en dehors du serveur. Conservez les sauvegardes dans un autre compte et chez un autre fournisseur. Testez une restauration avant le premier incident grave. Ce ne sont pas des signes de méfiance. Il s'agit de la répartition normale des responsabilités dans l'hébergement économique et de milieu de gamme.
Quelles preuves justifieraient un verdict plus solide
Network LIGA HOSTING LTD pourrait passer d'un niveau de preuve moyen à un niveau de preuve solide sans exposer d'éléments internes sensibles. La première amélioration serait une déclaration d'infrastructure concise: quelles villes sont actives, si l'entreprise possède le matériel ou loue une capacité dédiée dans chaque ville, quelles familles de produits fonctionnent sur chaque site, si chaque site dispose d'au moins deux chemins en amont, et si l'espace IP du client peut se déplacer lors d'une défaillance d'un fournisseur.
Un enregistrement PeeringDB public serait utile, mais même une simple page réseau en texte brut rendrait la revendication de backbone plus facile à vérifier.
La deuxième amélioration serait le contexte de l'installation et de l'alimentation. Les clients n'ont pas besoin des numéros de rack. Ils ont besoin de savoir si les serveurs se trouvent dans des centres de données professionnels, si l'alimentation est double, si les hôtes sont à cordon unique ou double, si des interventions à distance sont sous contrat, si les pièces de rechange sont stockées localement, et si la maintenance planifiée de l'installation a une conception sans temps d'arrêt ou une fenêtre de redémarrage pour le client.Le matériel sur les niveaux de l'Uptime Instituterappelle que la capacité de l'installation et la topologie du locataire ne sont pas identiques; un bâtiment certifié ne certifie pas automatiquement chaque nœud hébergé.
La troisième amélioration serait les preuves de sauvegarde et de restauration. Les conditions tracent déjà une limite claire autour des sauvegardes cPanel et de la responsabilité VPS par défaut. L'étape suivante plus solide serait des objectifs de restauration spécifiques au produit: délai de demande de restauration cPanel, options de rétention des instantanés, choix d'emplacement de sauvegarde hors site, formats de téléchargement/exportation, et le résultat du dernier exercice de restauration effectué par le fournisseur. Pour le VPS, un produit de sauvegarde payant doit indiquer s'il est stocké hors nœud, hors rack ou hors site.
La quatrième amélioration serait l'historique des statuts. Une page verte à un moment donné est utile; un historique des incidents et de la maintenance est plus utile. Les clients doivent pouvoir voir à quelle fréquence la Roumanie et Francfort ont eu des travaux planifiés, si des incidents ont traversé les régions, combien de temps la restauration a pris et ce qui a été changé par la suite. Ce n'est pas seulement du théâtre de transparence. Cela permet aux acheteurs de comparer l'objectif mensuel revendiqué de 99,9 % avec le comportement opérationnel réel.
La cinquième amélioration serait les droits de sortie. Les conditions indiquent déjà que les services résiliés peuvent ne pas conserver les IP, les noms d'hôte ou les données. Un fournisseur adapté à la production peut toujours publier comment les clients exportent les images VPS, récupèrent les sauvegardes cPanel, réduisent la dépendance DNS, transfèrent les domaines et demandent un accès d'urgence aux données avant la suppression. Le verrouillage de l'hébergement apparaît souvent pendant une panne, pas pendant l'achat.
Verdict: capacité d'hébergement visible, résilience profonde non prouvée
Network LIGA HOSTING LTD est un sujet d'hébergement mieux étayé que ce que suggérait l'instantané initial d'un répertoire clairsemé. La société britannique existe et correspond au code SIC de l'hébergement. Le site public et les conditions décrivent des services VPS, cPanel et d'hébergement de jeux concrets. La page d'état nomme les emplacements de service de Tulcea et de Francfort. L'AS201131 est enregistré au nom de LIGA HOSTING LTD, actif dans le routage public et émet actuellement trois IPv4 /24 plus deux IPv6 /48 visibles. L'état d'origine de route IPv4 vérifié est valide. Ces points soutiennent une véritable empreinte opérationnelle.
Le plafond est tout aussi important. L'entreprise est nouvellement constituée. Le dossier public ne nomme pas les installations, la propriété des racks, le fournisseur d'intervention à distance, les interconnexions, le stock de pièces de rechange, la composition exacte des fournisseurs en amont par emplacement, la capacité DDoS, la conception de la réplication du stockage, l'historique des tests de restauration ou les droits de migration des clients. Le SLA est principalement une promesse de crédit de service. Les sauvegardes VPS ne sont pas incluses par défaut.
Les règles de facturation peuvent suspendre le service le troisième jour et supprimer les données le quatorzième jour. Ce ne sont pas des défauts en soi; ce sont la forme réelle de la dépendance.
Pour une utilisation expérimentale de VPS, les communautés de jeux avec leurs propres sauvegardes, les petits sites web et les charges de travail qui peuvent se déplacer par DNS, les preuves publiques de LigaHosting peuvent être suffisantes si le prix, la latence et le support conviennent. Pour les données réglementées, l'hébergement de production de clients, les applications critiques pour les revenus ou les services ayant des objectifs de récupération stricts, l'acheteur doit traiter la plateforme comme une capacité hébergée qui nécessite toujours une conception de récupération indépendante.
Demandez des preuves de site, de sauvegarde et de route. Testez la restauration en dehors du compte. Possédez le DNS et l'enregistrement de domaine. Sachez ce qui se passe si une facture, un rack, un nœud, un fournisseur en amont ou un contrat de fournisseur échoue.
Le fait central n'est pas que l'AS201131 existe, ni que Tulcea et Francfort apparaissent sur une page d'état. C'est que chaque serveur virtuel vendu sous cette surface se résout toujours en une petite chaîne de dépendances physiques et contractuelles: un serveur, un rack, l'alimentation, le refroidissement, le transit, l'atténuation DDoS, la main-d'œuvre de support, l'état de facturation et un chemin de sortie. Network LIGA HOSTING LTD a suffisamment de preuves publiques pour être pris au sérieux en tant qu'hôte opérationnel.
Il n'a pas encore publié suffisamment de preuves pour permettre aux clients de sous-traiter la résilience au fournisseur.

