Résumé
- kCore Cloud dispose d'une surface d'exploitation vérifiable. Son site Web accepte les commandes d'hébergement partagé, son portail client a publié un avis de maintenance d'urgence en mai 2026, ARIN l'identifie comme le détenteur de AS401197 et de deux allocations d'adresses, et RIPEstat a observé ses routes IPv4 et IPv6 sur l'ensemble des pairs à flux intégral déclarants en juillet 2026.
- Le réseau visible est compact et concentré. AS401197 a émis un /24 IPv4 et un /40 IPv6, avec AS4213 comme seul voisin observé. La route IPv6 disposait d'une autorisation d'origine de route valide, tandis que la route IPv4 a renvoyé un statut inconnu car aucune autorisation de validation n'a été trouvée.
- L'affirmation de la société selon laquelle elle possède du matériel et dispose de son propre espace de centre de données est plausible mais pas suffisamment localisée. Son site corporatif utilise une adresse AS4213 dans un bloc enregistré comme
KRYPT-IAD1, et des mesures à faible latence depuis Ashburn pointent vers le nord de la Virginie, mais aucune page publique de l'entreprise n'identifie d'installation, de nombre de racks, de conception électrique, de stock de pièces de rechange ou de site de production alternatif. - La garantie réseau annuelle de 99,9 % publiée exclut la maintenance programmée, les travaux d'urgence, les pannes matérielles ou logicielles réparées en moins d'une heure, les attaques par déni de service, le travail de support et plusieurs autres catégories de pannes. Il s'agit donc d'un recours financier limité, et non d'une preuve qu'un site Web, une boîte aux lettres et un panneau de contrôle peuvent tous se rétablir dans les délais requis par un client.
- Le risque de sauvegarde et de localité est explicite dans le contrat. Les clients sont tenus de conserver une copie indépendante; une sauvegarde hébergée peut être indisponible ou corrompue; et les données du compte ou les sauvegardes peuvent être déplacées vers un autre centre de données, État, pays ou continent. Un ASN américain et une adresse au Texas n'établissent pas où repose chaque copie client.
- Le niveau de preuve est moyen. Les routes actuelles, le commerce en direct et un avis opérationnel récent établissent que la société est active, mais le seul fournisseur d'accès observé, l'absence d'identité publique de l'installation, le parc matériel non quantifié, la vue privée de l'état du réseau et les preuves de récupération limitées empêchent une évaluation plus solide.
La promesse de la petite entreprise a une adresse physique, mais pas encore de plan physique
kCore Cloud ne se présente pas comme un service public immense. Sapage d'accueilindique qu'il s'agit d'une petite entreprise avec son propre matériel et son propre espace de centre de données. Sapage à proposla présente comme une petite entreprise fondée par un expert en infrastructure Internet. Le produit actuellement visible pour un acheteur non authentifié est plus restreint que le mot « cloud » ne le laisse entendre: hébergement de sites Web et de courriels partagés, enregistrement de noms de domaine, aide à la migration et conseils techniques payants. Lapage d'hébergementrépertorie des formules avec 5 Go, 10 Go ou 40 Go de stockage SSD, des allocations de base de données correspondantes et un nombre limité de comptes de messagerie et de domaines.
Ce n'est pas une critique. L'hébergement partagé reste un service d'infrastructure important pour les petites organisations qui ne souhaitent pas exploiter un serveur, corriger une pile Web, gérer le courrier ou négocier directement avec une société de colocation. Le client achète une abstraction: un identifiant, un quota de stockage, une base de données, un certificat, des boîtes aux lettres et un support. kCore doit à son tour assembler un système beaucoup moins abstrait.
Il a besoin de serveurs, de disques, de mémoire, de ports réseau, d'alimentation rack, de refroidissement, de transit Internet, de services de domaine, de logiciels de facturation, de surveillance et de personnes capables d'intervenir lorsque l'un de ces composants tombe en panne.
L'expression « notre propre espace de centre de données » ne définit qu'une partie de cette frontière. Elle suggère un modèle de colocation ou d'espace loué, et non la propriété d'un bâtiment entier. Dans ce modèle, kCore peut posséder des serveurs et des équipements réseau tandis qu'un autre opérateur contrôle la propriété, les alimentations électriques, les générateurs, les systèmes d'alimentation sans interruption, le refroidissement, la protection incendie, le quai de chargement, la liste d'accès, la salle de rencontre et le service de télémaintenance.
Un fournisseur réseau peut contrôler les circuits externes et les routeurs par lesquels AS401197 atteint Internet. Ces arrangements peuvent fournir un excellent service. Ils divisent également la responsabilité entre des contrats qu'un client d'hébergement partagé ne voit jamais.
Aucune page publique de kCore examinée pour cet article n'identifie une installation de production par son nom ou son adresse postale. L'adresse à Houston dansl'enregistrement ARINde l'entreprise correspond à l'adresse enregistrée dans ses conditions juridiques, mais une adresse postale d'entreprise n'est pas un emplacement de serveur. Le site ne publie pas le nombre de racks, l'allocation d'alimentation, l'inventaire actuel des serveurs, la réserve de stockage, le certificat de l'installation ou une deuxième région de production. Il ne précise pas si « espace » signifie une partie d'une armoire, plusieurs armoires, une cage ou une capacité obtenue via un fournisseur d'hébergement.
Cette carte manquante change la façon dont le service doit être évalué. Un acheteur ne peut pas supposer que l'adresse légale de Houston est le lieu des données. Il ne peut pas supposer que deux équipements se trouvent dans des bâtiments différents parce qu'ils ont des adresses IP différentes. Il ne peut pas supposer qu'il existe des baies de disques libres, des unités de rack inutilisées ou de la puissance non engagée simplement parce que de nouvelles commandes sont acceptées.
La première question de diligence raisonnable est donc simple: identifier l'opérateur de l'installation, la métropole, le bâtiment, l'empreinte rack et la propriété de l'équipement pour le service acheté. Tant que kCore ne publie pas ou ne fournit pas contractuellement cette réponse, son emplacement physique reste une hypothèse bien étayée plutôt qu'un fait client vérifié.
AS401197 prouve une bordure active, pas un grand domaine
La preuve la plus solide que kCore est plus qu'une vitrine est son empreinte de ressources numériques Internet.L'enregistrement d'ARIN pour AS401197identifie kCore Cloud LLC, enregistre l'attribution du système autonome en juin 2024 et pointe verskcore.net.L'enregistrement IPv6 d'ARINattribue à l'entreprise l'allocation active2602:f897::/40, enregistrée en juin 2024.L'enregistrement IPv4 d'ARINmontre une allocation directe active de199.184.211.0/24, enregistrée en octobre 2025. Le bloc IPv4 contient 256 adresses; le /40 IPv6 contient 256 réseaux possibles de taille /48 pour clients, bien que les mathématiques de l'espace d'adressage ne disent rien sur le nombre utilisé.
La vue de l'état de routage de RIPEstata observé un préfixe IPv4, un préfixe IPv6 et un système autonome voisin en juillet 2026. Les 326 pairs IPv4 à flux intégral déclarants et les 322 pairs IPv6 déclarants ont tous vu les routes dans cette observation.La vue des préfixes annoncésidentifie ces routes comme199.184.211.0/24et2602:f897::/40. C'est une preuve solide d'une bordure réseau double pile globalement visible.
Le calendrier est révélateur.L'historique de route de RIPEstata vu la route IPv6 à partir de juillet 2024, peu après l'attribution, tandis que le /24 IPv4 actuel est apparu en octobre 2025. Ce schéma est cohérent avec un réseau qui a établi l'IPv6 en premier et a ajouté un bloc IPv4 directement attribué plus tard. Il ne montre pas si le trafic client utilisait les adresses d'un autre fournisseur avant octobre 2025, ni quelle quantité de production a été déplacée lorsque le /24 est apparu. Il montre une visibilité continue de la route plutôt qu'une attribution entièrement inactive.
Les routes ont également des états de sécurité d'origine différents.La vérification RPKI de RIPEstat pour la route IPv6a trouvé une autorisation d'origine de route valide permettant à AS401197 d'annoncer le /40. Lavérification IPv4 correspondantea renvoyé un statut inconnu car elle n'a trouvé aucune autorisation de validation. Inconnu n'est pas la même chose qu'invalide: cela signifie que le système cryptographique d'origine de route ne peut pas confirmer l'origine à partir d'une autorisation correspondante. Créer une autorisation valide pour la route IPv4 supprimerait cette ambiguïté évitable.
Ce que les données de route ne peuvent pas révéler est tout aussi important. Un /24 peut prendre en charge des centaines d'adresses individuelles ou un petit nombre de frontaux partagés. Un /40 peut être généreusement sous-réseauté tandis que seuls quelques hôtes répondent. BGP n'expose pas le nombre de CPU, l'état des disques, le nombre de locataires, les requêtes Web, la charge de la base de données ou la puissance restante dans le rack. Il ne montre pas si un serveur a deux alimentations, si ces alimentations entrent dans des chemins de distribution indépendants, ou si une deuxième machine peut absorber ses locataires.
La preuve réseau établit une frontière opérationnelle réelle. Elle ne transforme pas la déclaration non quantifiée de l'entreprise sur le matériel en un chiffre de capacité.
Des mesures indépendantes renforcent cette prudence.La page d'IPinfo pour AS401197répertorie les mêmes deux plages d'adresses mais n'estime qu'un seul domaine hébergé et a trouvé très peu d'adresses répondant au ping dans des analyses récentes. Son traceroute de juin 2026 depuis Ashburn a atteint une adresse dans le /24 de kCore après AS4213 avec une faible latence.La vue d'IPinfo du bloc IPv4rapporte également une utilisation de domaine visible clairsemée. Ce sont des signaux de marché non officiels, pas un recensement. L'hébergement partagé peut placer de nombreux noms derrière une seule adresse, les pare-feu peuvent supprimer les sondes, les services IPv6 peuvent ignorer le trafic non sollicité, et les adresses de gestion privées seront invisibles. Les mesures suggèrent une petite empreinte publique; elles ne peuvent pas prouver le nombre de clients, les revenus, la capacité inutilisée ou le manque d'utilisation.
Un seul fournisseur d'accès observé est la concentration la plus claire
Les données de voisin de RIPEstatn'ont observé que AS4213 du côté gauche de AS401197 et aucun système autonome en aval.bgp.toolsidentifie également AS4213, historiquement enregistré comme Krypt Technologies et maintenant présenté publiquement comme Evocative Global, comme le fournisseur d'accès pour IPv4 et IPv6.CIDR Reportmontre la même adjacence unique dans les routes collectées.
C'est une concentration, pas une preuve de mauvaise ingénierie. Un fournisseur peut délivrer deux circuits physiques, des ports diversifiés et une dorsale robuste. Un deuxième chemin peut exister mais rester inactif, privé ou invisible pour les collecteurs utilisés ici. Le fournisseur peut exploiter des routeurs et des liens redondants à l'intérieur d'une même installation même si la table de routage globale voit un seul ASN amont. Inversement, deux sessions BGP vers AS4213 pourraient encore partager un conduit, une carte de ligne, un compte, une métropole ou une bordure d'installation et tomber en panne ensemble.
Le routage public peut compter les chemins de systèmes autonomes; il ne peut pas inspecter les chemins de câbles.
La distinction est importante car la page d'accueil promet une « redondance intégrée ». La redondance doit être liée à un domaine de défaillance. Les disques en miroir protègent contre certaines pannes de disque. Deux alimentations protègent contre une seule panne à condition qu'elles soient connectées à des alimentations véritablement indépendantes. Deux commutateurs protègent un serveur uniquement si ses interfaces, son réseau virtuel et sa route amont sont configurés pour utiliser les deux.
Deux liaisons vers un seul opérateur peuvent survivre à un problème de panneau de brassage mais pas à la suspension commerciale de l'opérateur ou à une panne de routeur partagée. Un deuxième opérateur dans le même bâtiment peut encore partager l'entrée de fibre externe.
La RFC 4116explique pourquoi le multi-hébergement Internet est utile mais pas magique: plusieurs chemins peuvent améliorer la survie des sessions, mais les délais de convergence, la politique d'adressage et la complexité opérationnelle subsistent. Pour kCore, une divulgation convaincante de la redondance indiquerait s'il existe un deuxième fournisseur d'accès par défaut; si les circuits sortent par des chemins physiques séparés; si les routeurs de bordure, les optiques et l'alimentation sont dupliqués; et si le chemin survivant dispose d'une capacité engagée suffisante pour transporter le trafic prioritaire. Elle montrerait également que le basculement est exercé plutôt que simplement configuré.
L'absence d'entrée de kCore dansla requête PeeringDB pour AS401197n'ajoute aucune preuve dans un sens ou dans l'autre. La participation à PeeringDB est volontaire, en particulier pour les petits réseaux qui achètent du transit plutôt que de rechercher un peering public. En revanche,l'enregistrement PeeringDB de AS4213décrit un réseau beaucoup plus grand opérant dans de nombreuses installations. Cette envergure appartient à AS4213. Elle ne doit pas être attribuée automatiquement à kCore. Une route client entrant dans un grand fournisseur d'accès n'hérite pas de la capacité indépendante de kCore dans tous les sites du fournisseur d'accès.
Le résultat pratique est simple. Une panne ou un différend contractuel au point d'échange AS4213 est un chemin de mode commun crédible pour les routes publiques de kCore. Les preuves qui réduiraient cette préoccupation comprennent un deuxième fournisseur d'accès observé, un test de basculement publié, un collecteur de routes montrant des chemins alternatifs, ou un contrat décrivant des points d'échange diversifiés avec une bande passante de secours suffisante. Jusque-là, la bordure double pile de kCore est active et globalement visible, mais elle n'a qu'une seule sortie externe.
Le nord de la Virginie est le signal de localisation le plus fort, pas une installation confirmée
Le réseau de kCore laisse des indices sur l'endroit où au moins certains équipements peuvent fonctionner. Le site Web corporatif résout en67.198.230.22.La réponse d'information réseau de RIPEstatplace cette adresse dans67.198.230.0/24, émis par AS4213 plutôt que par AS401197. Les résumés des registres publics labellisent le bloc englobant67.198.230.0/23commeKRYPT-IAD1, utilisant le code aéroportuaire communément associé au marché de Washington Dulles et du nord de la Virginie. Le flux de géolocalisation commerciale de RIPEstat place le bloc à Reston. Le traceroute d'IPinfo vers le propre bloc IPv4 de kCore a atteint la cible depuis Ashburn en environ deux millisecondes après le réseau AS4213.
Pris ensemble, ces observations suggèrent fortement un point d'exploitation dans le nord de la Virginie. Elles n'identifient pas le bâtiment exact. La géolocalisation IP peut refléter l'enregistrement, la politique de routage ou un routeur à proximité plutôt que le rack du serveur.IAD1est une étiquette de fournisseur, pas une déclaration contractuelle de kCore. AS4213 opère dans de nombreuses métropoles américaines, et une route peut être remise à distance. La faible latence rend un site de production éloigné moins probable pour l'adresse mesurée, mais une seule mesure ne peut pas localiser chaque service ou chaque sauvegarde.
C'est pourquoi les signaux de Houston et du nord de la Virginie ne doivent pas être amalgamés. Houston est la surface légale et de contact affichée dans ARIN et les conditions de l'entreprise. Le nord de la Virginie est le meilleur signal technique pour l'infrastructure mesurée publiquement. Un avis juridique distinct sur le site répertorie une autre adresse à Houston pour la correspondance relative aux droits d'auteur. Aucune de ces adresses n'établit où les fichiers clients, les courriels ou les copies de sauvegarde sont stockés.
Lesconditionsde l'entreprise préservent des droits de mouvement étendus. La section 4.3 indique que les configurations matérielles peuvent varier et que kCore peut remplacer le matériel hôte, déplacer un compte vers un autre serveur, ou le transférer vers un autre centre de données ou emplacement géographique lorsqu'il le juge nécessaire pour la qualité du service et la sécurité. La section 15.4 indique qu'un compte et ses sauvegardes peuvent se trouver dans des centres de données différents, que les sauvegardes peuvent être stockées dans un autre État, pays ou continent, et que la restauration d'urgence peut avoir lieu en dehors de l'emplacement choisi par le client.
Ces clauses peuvent aider à la récupération en permettant à l'opérateur d'échapper à un matériel défaillant ou à un site problématique. Elles signifient également que la localité n'est pas fixe simplement parce que l'entreprise et l'ASN sont américains. Un acheteur avec des restrictions étatiques, nationales, contractuelles ou sectorielles a besoin d'un engagement écrit de placement qui couvre la production, la sauvegarde, la récupération temporaire, l'accès au support et les sous-traitants. Le contrat devrait expliquer le préavis et le consentement lorsqu'une copie franchit la limite convenue.
Sans cet engagement, le droit du fournisseur de déplacer les données est plus large que la carte d'infrastructure publique.
Le DNS montre une séparation utile, mais ce n'est pas une deuxième région d'hébergement
La conception du service de domaine de kCore est plus distribuée que sa bordure BGP publique.La réponse d'enregistrement A de Google Public DNSmontre le site corporatif sur l'adresse AS4213 plutôt que sur le propre /24 IPv4 de l'entreprise. Saréponse NSdélègue la zone àa.ns.cl0secall.netetb.ns.cl0secall.net. Au moment de l'examen, le premier serveur faisant autorité utilisait des adresses dans AS4213 et AS401197, tandis que le second utilisait des adresses dans AS25795 et un réseau IPv6 séparé. Laréponse MXplaçait de même un serveur de messagerie dans AS401197 et un autre sur le réseau séparé.
Cet arrangement peut apporter de véritables avantages. Si AS401197 disparaît, un serveur faisant autorité secondaire en dehors de cette route peut continuer à répondre pour le domaine. Un serveur de messagerie externe peut mettre en file d'attente les messages pendant que le serveur principal est indisponible. Héberger le site de vente sur l'espace d'adressage du fournisseur d'accès peut maintenir la page publique accessible pendant une panne d'origine de route affectant le /24 de kCore. Ce sont des séparations sensées au niveau des couches de domaine et de communication.
Elles créent également des dépendances qui devraient être nommées. Les noms d'hôtes faisant autorité utilisentcl0secall.net, un domaine différent dont la propriété et les conditions de service ne sont pas expliquées sur le site de kCore. La page corporative reste à l'intérieur de AS4213, le même système autonome observé publiquement comme le seul fournisseur d'accès de kCore. Un incident au niveau de la route de AS4213 pourrait donc affecter à la fois le réseau client et le site Web de l'entreprise, même si leurs adresses appartiennent à des allocations différentes. Le deuxième chemin DNS et de messagerie peut survivre, mais les preuves publiques n'établissent pas comment le personnel de support publierait un incident si le portail client et le réseau principal tombaient en panne ensemble.
Le portail client contient des liens vers une page d'état du réseau, mais une requête non authentifiée est redirigée vers la connexion. Leflux d'annonces publiquesest visible et utile, bien qu'il ne s'agisse pas d'un tableau de bord d'état mis à jour en continu. La distinction est importante lors d'une panne. Un client qui ne peut pas s'authentifier parce que le portail ou le service d'identité est en panne a besoin d'une source publique et hébergée indépendamment pour la propriété de l'incident, les services affectés et les mises à jour de restauration.
La diversité DNS mérite donc du crédit mais ne doit pas être interprétée comme une redondance applicative. Un site Web peut résoudre correctement alors que sa base de données, son stockage ou son panneau de contrôle sont indisponibles. Un serveur de messagerie secondaire peut accepter un message sans restaurer la boîte aux lettres du client. Un canal d'état séparé peut décrire une panne sans la réduire. Chaque couche a de la valeur; aucune ne prouve que la charge de travail d'hébergement partagé sous-jacente peut être déplacée vers une autre pile de production.
Le RAID 10 SSD est une capacité installée, pas une capacité utilisable garantie
La page d'hébergement de kCore indique que toute la plateforme fonctionne sur un stockage SSD RAID 10. Le RAID 10 combine normalement la mise en miroir et la répartition, permettant à certains disques de tomber en panne sans perdre la matrice et améliorant les performances par rapport à un seul disque. C'est un choix de conception raisonnable pour l'hébergement partagé.
Il laisse encore plusieurs questions sans réponse: le nombre et le modèle des disques, la conception du contrôleur, la politique de rechange, le temps de reconstruction, les seuils de surveillance, la disposition du système de fichiers, la protection du cache d'écriture et si les répliques partagent le même châssis ou le même domaine d'alimentation.
L'économie se cache derrière ces détails. Le forfait d'entrée répertorié coûte moins de dix dollars par mois et comprend le stockage, l'espace base de données, la messagerie, l'automatisation des certificats, le support, la surveillance et la migration. Les prix bas sont possibles parce que de nombreux locataires partagent des serveurs, des licences logicielles, la capacité réseau et le temps du personnel. Le fournisseur obtient un retour en maintenant une utilisation élevée.
La résilience nécessite la marge opposée à des moments cruciaux: baies de disques inutilisées, serveurs de rechange, stockage libre, puissance rack non engagée et temps du personnel disponible lorsque plusieurs choses tombent en panne à la fois.
La capacité installée est la quantité physiquement présente. La capacité utilisable est ce qui peut être vendu en toute sécurité tout en préservant les performances, l'espace de reconstruction et la marge de récupération. Un serveur peut avoir un espace disque nominal abondant mais manquer de performances d'entrée/sortie suffisantes pendant une reconstruction RAID. Un rack peut avoir des unités vacantes mais plus d'allocation d'alimentation. Un hôte virtuel peut accepter un autre compte mais manquer de mémoire pour absorber les voisins après la panne d'un nœud.
Les limites des forfaits publics décrivent le quota du client, pas la réserve restante du fournisseur.
Lapage plateformede kCore indique qu'elle utilise du matériel serveur de qualité entreprise, conçoit autour des pannes de composants individuels et gère activement les cycles de vie des équipements. Ce sont les catégories correctes. La page ne publie pas les générations de matériel, les seuils de remplacement, les taux de défaillance ou un inventaire des pièces de rechange prêtes. Le contrat permet aux configurations matérielles de varier. Cette flexibilité soutient les opérations pratiques, mais elle empêche un acheteur de déduire une flotte standard ou une classe de remplacement garantie.
Les fenêtres de réparation dépendent du stock et de l'accès. Si un disque tombe en panne, une pièce de rechange locale peut être installée rapidement; si aucun disque compatible n'est sur site, l'approvisionnement et l'expédition deviennent une partie de la panne. Si une carte mère tombe en panne, une pièce de rechange pour l'ensemble du système peut raccourcir la récupération; sinon, l'opérateur peut devoir transplanter les disques, restaurer sur un matériel différent ou attendre une pièce. Dans un espace loué, kCore peut avoir besoin que le personnel de l'installation admette un technicien ou effectue des opérations à distance.
Une exclusion d'une heure dans le SLA ne rend pas un remplacement physique en une heure possible.
Une réponse solide sur la capacité quantifierait la réserve de panne sans exposer des détails sensibles: nombre de sites de production, nombre de domaines de défaillance des serveurs, marge minimale de nœuds de rechange, catégories de remplacement sur site, seuil d'espace libre de stockage et politique de sursouscription maximale. Elle indiquerait si un seul serveur peut tomber en panne sans déplacer les locataires manuellement. Elle distinguerait également le stockage de sauvegarde du stockage redondant en direct.
Le RAID maintient un service en fonctionnement à travers certaines pannes de composants; il ne crée pas une copie historique indépendante.
La garantie de 99,9 % est plus étroite que le titre
kCore promet à plusieurs reprises une disponibilité de 99,9 %. Sur une base annuelle, ce pourcentage autorise environ huit heures et 46 minutes d'indisponibilité comptée. La page d'hébergement arrondit cela à environ neuf heures par an. Pour un dépliant, cette arithmétique est compréhensible. Pour un opérateur décidant si un site Web peut être hors ligne pendant une journée entière d'activité, la définition de l'indisponibilité comptée est plus importante que le pourcentage.
La section 5 desconditions publiéesdéfinit l'engagement comme une disponibilité réseau mesurée annuellement. Le recours commence par un mois d'hébergement gratuit si la disponibilité totale est inférieure à 99,9 % mais supérieure à 99 %, avec un autre mois pour chaque point de pourcentage en dessous de 99 %. L'indemnisation est limitée, et les registres internes de l'entreprise sont la seule norme pour déterminer le droit. L'accord décrit ce crédit comme le recours exclusif en cas de panne réseau, logicielle, matérielle ou d'équipement là où la loi le permet.
Les exclusions sont larges. La maintenance programmée ne compte pas. La maintenance d'urgence et les pannes matérielles ou logicielles réparées en moins d'une heure ne comptent pas. Les attaques par déni de service distribué, les attaques de pirates, les temps d'arrêt causés par l'atteinte des limites du forfait, les changements de service, les périodes consacrées au traitement des demandes de support technique, la configuration client, les applications tierces, certains changements de DNS ou d'adresse notifiés, les violations de politique, la force majeure ou les événements hors du contrôle de l'entreprise ne comptent pas non plus.
Ces exclusions peuvent avoir un sens opérationnel individuellement. La maintenance est nécessaire; les clients causent des incidents; les attaques peuvent submerger la capacité achetée. Collectivement, cependant, elles créent une grande différence entre l'indisponibilité subie et l'indisponibilité créditée. Onze pannes matérielles distinctes de 59 minutes pourraient produire près de onze heures de perturbation tout en restant dans l'exclusion de moins d'une heure. Un client peut être incapable de servir du trafic pendant une attaque par déni de service tandis que l'événement ne réduit pas le calcul du SLA.
Une restauration dépendante du support peut rester en dehors du calcul précisément pendant que le client attend de l'aide.
La garantie concerne également le réseau, alors que le service vendu est plus large. Une route peut être accessible lorsque le serveur Web renvoie des erreurs. Un serveur Web peut fonctionner alors que la base de données est verrouillée. Un panneau de contrôle peut être hors ligne tandis que les sites statiques continuent de servir. Les courriels peuvent être retardés alors qu'un site Web est sain. Un client a besoin d'indicateurs de service spécifiques aux composants ou d'une définition de bout en bout qui commence à la demande du visiteur et inclut les dépendances applicatives que kCore contrôle.
L'avis de maintenance d'urgence de mai 2026illustre la distinction. kCore a déclaré qu'un problème de sécurité urgent nécessitait une brève panne du portail client à 22 h (heure de l'Est) et a ensuite marqué la maintenance comme terminée à 22 h 25. C'est une preuve opérationnelle positive: un avis daté, une raison indiquée, une mise à jour d'achèvement et une invitation au support. Il concernait le portail, pas nécessairement les sites Web hébergés. Le dossier public ne montre pas si la panne a compté contre une mesure de service, si les clients ont conservé un autre chemin de gestion, ou si un examen d'incident ultérieur a été publié.
Un registre de disponibilité plus utile à la décision publierait des mesures mensuelles, la durée de l'incident du point de vue du client, les exclusions spécifiques au service et le nombre de locataires affectés. Il séparerait le travail planifié du travail d'urgence et indiquerait à quelle fréquence l'exception d'une heure est utilisée. Le SLA actuel est assez réel pour fixer le prix d'un crédit limité. Ce n'est pas un engagement de temps de récupération pour chaque couche sur laquelle le client compte.
Le langage sur les sauvegardes fait du client la dernière ligne de récupération
Le contrat est le plus clair là où la page marketing est la moins précise. La section 11.20 exige des clients qu'ils conservent des copies de tout le contenu dans un emplacement indépendant de kCore et déclare qu'ils ne doivent pas utiliser le service de sauvegarde de kCore comme seule sauvegarde. La section 15 déclare que kCore utilisera des efforts commercialement raisonnables pour sauvegarder les données du compte d'hébergement, mais qu'une copie peut être indisponible en raison du nombre de fichiers, d'une défaillance du logiciel de sauvegarde, d'une défaillance de stockage ou d'une corruption.
Elle conserve un nombre limité de copies comme indiqué sur la page produit applicable et peut supprimer les anciennes copies après un changement de forfait.
La page d'hébergement publique examinée ici fait la promotion de fonctionnalités de sauvegarde et de restauration au niveau de l'application mais ne précise pas un nombre de rétention pour la sauvegarde de la plateforme. Les conditions ajoutent qu'une copie restaurée peut arriver sous forme de données brutes nécessitant un reformatage, et que le recours du client après une restauration insatisfaisante est d'utiliser sa propre sauvegarde. La création et la restauration de sauvegardes payantes sont exclues de la politique de remboursement. Ce n'est pas une assurance d'un point de récupération ou d'un temps de récupération particulier.
Les risques sont différents. Le RAID 10 traite certaines pannes de disque en direct. Une sauvegarde traite la suppression, la corruption, la compromission ou le besoin de revenir à un état antérieur. Une copie dans le même rack peut survivre à une panne de disque mais pas à une panne d'alimentation du rack. Une copie sur le même compte administratif peut survivre à une perte de serveur mais pas nécessairement à un vol de compte. Une copie géographiquement distante peut survivre à un incident d'installation mais peut introduire un temps de transfert, des restrictions de localité et une dépendance aux mêmes identifiants ou fournisseur.
Le guide contre les rançongiciels de la CISArecommande des sauvegardes hors ligne, cryptées et des tests de restauration réguliers. Le mot important est « testé ». Un travail de sauvegarde signalant un succès prouve que des octets ont été écrits quelque part; il ne prouve pas que les bases de données sont cohérentes, que les identifiants existent, que les clés de cryptage sont disponibles, que les noms peuvent être redirigés, ou que le site restauré fonctionnera sur la pile cible. Un test utile mesure le temps entre la déclaration de panne et le trafic servi à partir de la copie récupérée.
Pour les clients de kCore, la copie indépendante devrait inclure les fichiers du site Web, les vidanges de base de données, les courriels s'ils sont importants, les enregistrements DNS, le certificat et le matériel de clé le cas échéant, la configuration du compte, les tâches planifiées et la documentation des versions logicielles nécessaires pour exécuter le site. La copie devrait être accessible sans le portail kCore. Sa destination de restauration devrait être identifiée avant un incident, pas après que le serveur partagé soit indisponible.
kCore pourrait renforcer les preuves en publiant les périodes de rétention, la fréquence des copies, la séparation du stockage, les pratiques de cryptage, la priorité de restauration et le succès historique des restaurations. Il pourrait définir un objectif de point de récupération et un objectif de temps de récupération par forfait. À l'heure actuelle, le contrat conseille prudemment aux clients de ne pas déléguer leur dernière copie au fournisseur. Les acheteurs devraient prendre cet avertissement au pied de la lettre.
La migration vers kCore est décrite; la migration hors de kCore reste un exercice client
Lapage de migrationpropose une séquence d'entrée simple: acheter l'hébergement, transférer éventuellement le domaine, ouvrir un ticket de conciergerie et laisser l'équipe migrer le site Web. La page d'hébergement indique que des experts déplaceront les données du site Web depuis l'ancien fournisseur avec peu ou pas de temps d'arrêt. Pour un petit site, une aide à la migration pratique peut être plus précieuse qu'un outil en libre-service sophistiqué.
L'assistance à l'entrée n'établit pas la portabilité de sortie. Le matériel public ne définit pas quels panneaux de contrôle source, versions de base de données, formats de boîte aux lettres, tâches planifiées ou piles d'applications sont pris en charge. Il ne promet pas d'exportation complète du compte, de temps d'exportation maximal, de bande passante de sortie ou d'aide pour déménager vers un fournisseur concurrent. Le seul article public sur l'accès shell indique que les clients peuvent demander un accès shell pour un hébergement partagé ou WordPress via un ticket de support.
Cela peut faciliter le transfert de fichiers, mais cela ne précise pas le niveau de privilège, la durée ou l'accès pendant une suspension de compte.
La feuille de route des normes de cloud computing du NISTtraite de la portabilité comme la capacité de déplacer des données ou des applications et met en évidence les différences d'interfaces, de formats et de technologies de machines virtuelles comme sources de verrouillage. L'hébergement partagé est plus simple que le déplacement d'un domaine virtuel complexe, mais le même principe s'applique. Les fichiers ne sont qu'une partie d'un service fonctionnel. L'encodage de la base de données, les boîtes aux lettres, le timing DNS, les certificats, les extensions PHP, les permissions de fichiers, les tâches d'arrière-plan et les secrets d'application doivent arriver dans un état utilisable.
Le contrat crée également une pression de sortie autour de la facturation. Les frais sont dus à l'avance. Un paiement échoué peut entraîner une suspension ou une résiliation, et kCore décline toute responsabilité pour le contenu perdu en conséquence. Le renouvellement automatique peut échouer même lorsqu'il est activé, et le client reste responsable d'assurer le paiement. Les services peuvent prendre fin à l'échéance. Lors d'un litige de facturation, un rétrofacturation peut entraîner une suspension jusqu'à ce que les montants impayés soient réglés.
Ce n'est pas inhabituel dans l'hébergement à bas prix, mais cela transforme la facturation en une dépendance d'infrastructure. Une carte expirée peut devenir un événement de disponibilité des données. Un client dont la seule copie récente se trouve derrière le portail du fournisseur peut découvrir que le moment de préparer une exportation était avant le litige de facture. Le remède est opérationnel: maintenir plus d'un contact de paiement à jour, surveiller les confirmations de renouvellement, conserver des copies indépendantes et tester la restauration ailleurs.
Une déclaration de sortie mature préciserait combien de temps les données restent disponibles après une annulation, une suspension ou une expiration; si les exportations restent possibles pendant un litige; les formats fournis; le débit attendu; et les frais de support pour une sortie gérée. Elle séparerait l'enregistrement de domaine de l'hébergement afin que le client comprenne quels noms, enregistrements et contenu peuvent être déplacés indépendamment. kCore explique comment arriver. Les clients doivent encore concevoir comment partir.
Le travail du support fait partie de la capacité vendue
kCore se différencie par un support humain. Lapage conciergerieindique que ses techniciens sont compétents et ne sont pas externalisés vers un grand centre de support générique. Elle propose des conseils techniques individualisés et des services de conseil limités à un tarif horaire. La page plateforme revendique une surveillance continue et une couverture de réponse d'astreinte complète. Les formules d'hébergement incluent le support par ticket, et le site publie des contacts téléphoniques et par courriel.
Le support par petite équipe peut être excellent car la personne qui répond peut comprendre l'ensemble de l'environnement. Il peut également concentrer les connaissances et les autorisations. ARIN répertorie une seule personne nommée pour les rôles administratif, technique, de routage, DNS, d'exploitation réseau et d'abus pour les ressources de l'entreprise. Cela ne prouve pas qu'il n'y a qu'un seul opérateur; les contacts des registres sont souvent délibérément consolidés. L'entreprise ne publie pas d'effectif, de modèle de quarts, d'échelle d'escalade, d'objectifs de réponse ou de dispositions de succession.
Le langage contractuel réduit la promesse. Le support technique est fourni selon disponibilité, et kCore ne garantit pas que chaque demande sera traitée dans les moyennes statistiques annoncées. Il peut avoir un accès complet aux services et au contenu en assistant. Les clients sont invités à sauvegarder avant de demander de l'aide car les modifications peuvent affecter le fonctionnement du site Web. Les demandes en dehors du périmètre inclus peuvent nécessiter un paiement anticipé, et le support peut être refusé dans plusieurs circonstances.
La réparation a donc une file d'attente humaine. Une alerte de surveillance doit atteindre une personne capable de diagnostiquer la bonne couche. Cette personne peut avoir besoin d'un accès à l'installation, d'un ticket amont, d'une pièce de rechange, d'une licence fournisseur ou de l'approbation du client. Si plusieurs locataires tombent en panne avec le même serveur, un expert peut être efficace car la cause est partagée. Si un incident d'installation ou de sécurité produit de nombreuses tâches distinctes, la même petite équipe peut devenir la ressource limitante.
L'avis du portail de mai 2026 montre au moins un cycle de communication rapide et directe et une mise à jour d'achèvement. Il ne mesure pas la réponse à une panne de stockage nocturne ou à une panne de route généralisée. La surface d'état du réseau liée publiquement nécessite une authentification, de sorte que les clients potentiels ne peuvent pas inspecter l'historique de disponibilité ou les incidents. L'archive d'annonces contient peu d'historique public. L'absence de rapports n'est pas une preuve d'absence d'incidents; c'est une absence de dossier public à partir duquel des étrangers peuvent calculer les performances.
Les acheteurs devraient demander des définitions de gravité, des objectifs de réponse initiale, la propriété de la restauration et un chemin qui reste accessible lorsque le portail est indisponible. Ils devraient identifier qui peut autoriser les changements DNS d'urgence et la libération des données. Pour un service critique pour l'entreprise, la capacité de support fait partie de l'architecture au même titre que le disque et le transit.
La panne se propage à travers les locataires, les domaines et les communications
Une panne d'hébergement partagé affecte rarement uniquement le propriétaire du serveur. Un hôte physique peut héberger de nombreux sites Web, bases de données et boîtes aux lettres non liés. Un problème de stockage peut mettre plusieurs clients hors ligne à la fois. Un panneau de contrôle compromis peut exposer des domaines et des comptes. Une panne DNS peut rendre un contenu sain inaccessible. Une panne de facturation ou de renouvellement de domaine peut interrompre un site sans aucun matériel défectueux.
La petite empreinte d'adresse visible de kCore rend cette agrégation importante. L'estimation du nombre de domaines hébergés par IPinfo est trop incomplète pour compter les clients, et une IP partagée peut faire face à de nombreux noms. La preuve nécessaire pour établir l'exposition est une distribution des locataires fournie par le fournisseur: pas les identités des clients, mais le nombre maximum de comptes par domaine de défaillance, le pourcentage de clients sur le plus grand serveur, et si la messagerie, le DNS et les services de contrôle partagent ce domaine.
Le produit de domaine ajoute une autre chaîne de dépendance. kCore indique qu'il revend des noms de domaine via un partenaire registraire. Lapage domainespermet aux clients de gérer les serveurs de noms, les verrous registraire et les informations de contact dans le même environnement client. Le regroupement simplifie l'administration et la facturation. Cela signifie également qu'un compte compromis ou un renouvellement échoué peut toucher à la fois le contenu et le nom utilisé pour l'atteindre. Le contrat note que les transferts et les enregistrements de domaine restent soumis aux règles du registre et du registraire.
Les clients peuvent réduire ce rayon d'explosion en séparant les identifiants de propriété, en exigeant une authentification multifacteur, en conservant les enregistrements DNS ailleurs et en décidant si l'enregistrement de domaine doit rester avec un registraire indépendant. Les conditions de kCore exigent une authentification à deux facteurs pour l'espace utilisateur, ce qui est un contrôle utile. La récupération de compte nécessite toujours un moyen de contact indépendant et un processus documenté de preuve de propriété.
L'adéquation du service a également des limites. Les conditions indiquent que le service n'est pas conforme à la HIPAA et interdisent les informations de santé protégées. Les utilisations à haut risque nécessitent une confirmation préalable et des systèmes redondants indépendants. Ces exclusions aident à éviter qu'une petite plateforme d'hébergement partagé ne soit confondue avec une infrastructure conçue pour la sécurité des personnes ou les données de santé réglementées. Elles ne répondent pas à chaque question de localité ou de confidentialité pour les données clients ordinaires.
Lorsque kCore tombe en panne, les parties les plus directement affectées sont les propriétaires de sites Web, leurs visiteurs, les utilisateurs de boîtes aux lettres et toute personne dépendant d'un domaine hébergé. Les effets secondaires peuvent inclure des ventes perdues, des messages manqués, des liens d'authentification expirés, des informations communautaires inaccessibles et une coordination d'incident retardée. La facture mensuelle bon marché peut donc se trouver en amont d'activités valant bien plus que les frais d'hébergement.
Le crédit SLA est peu susceptible de correspondre à ce coût externe, c'est pourquoi la récupération indépendante est importante.
Ce qui démontrerait la résilience plutôt que simplement la décrire
kCore dispose de suffisamment de preuves publiques pour éviter une évaluation opérationnelle négative. Sa surface de commande est active. Ses routes sont actuelles et largement visibles. Il dispose d'un espace d'adressage directement attribué, d'annonces double pile, de services faisant autorité et de messagerie fonctionnels, d'un contrat documenté, de canaux de support actifs et d'une communication de maintenance datée de 2026. Ce sont des signaux substantiels pour un petit fournisseur.
La prochaine preuve devrait être opérationnelle et de portée étroite. Premièrement, identifier la métropole de production et l'exploitant légal de l'installation, tout en permettant aux détails sensibles sur les racks de rester privés. Indiquer s'il existe un deuxième site de production actif et quels services peuvent y fonctionner. Distinguer l'emplacement de sauvegarde de la capacité de basculement. Une copie à distance est précieuse, mais ce n'est pas une plateforme applicative prête à moins que le calcul, les logiciels, les identifiants, le DNS et la capacité réseau soient également préparés.
Deuxièmement, documenter les domaines de défaillance du réseau. Nommer le nombre de fournisseurs d'accès, de routeurs de bordure et de points d'échange physiques; indiquer si les liaisons utilisent des entrées et des alimentations séparées; et publier la date et le résultat d'un exercice de basculement. Ajouter une autorisation d'origine de route valide pour le /24 IPv4. L'autorisation IPv6 montre que l'entreprise comprend déjà le mécanisme.
Troisièmement, divulguer les contrôles de capacité utilisable. Un acheteur n'a pas besoin de numéros de série. Il a besoin de savoir que le plus grand serveur peut tomber en panne sans surcharger les survivants, que des remplacements compatibles sont sur site ou disponibles contractuellement, et que les reconstructions de stockage préservent les performances. Indiquer la marge réservée et l'objectif de remplacement pour les disques, les serveurs et les équipements réseau.
Quatrièmement, transformer le langage sur les sauvegardes en une récupération mesurable. Publier la fréquence, la rétention, la séparation, la priorité de restauration et les plages de récupération testées. Proposer une procédure d'exportation lisible par le client qui ne dépend pas d'un portail sain. Clarifier l'emplacement des données pour la production, les sauvegardes et la restauration d'urgence, en particulier lorsqu'un client paie pour un placement aux États-Unis.
Cinquièmement, rendre les preuves d'incident publiques. Une page d'état hébergée indépendamment avec un historique des composants permettrait aux clients de distinguer les pannes de site Web, de portail, de DNS, de messagerie et d'hébergement. Publier des comptes rendus d'incidents concis pour les événements matériels et signaler à la fois l'indisponibilité subie et celle comptée dans le SLA. Cela rendrait le nombre de 99,9 % vérifiable sans révéler d'informations sur les clients.
Enfin, décrire l'escalade du support. Publier les niveaux de gravité, les objectifs d'accusé de réception, les canaux après les heures de travail et qui peut autoriser un travail d'installation ou une migration d'urgence. Une petite entreprise n'a pas besoin d'imiter un hyperscaler. Elle doit montrer qu'une personne indisponible, un seul processeur de paiement défaillant ou une seule file d'attente de tickets surchargée ne peut pas bloquer indéfiniment la restauration.
Le verdict opérationnel est réel mais délibérément limité
kCore Cloud est en activité. Les preuves actuelles sont plus solides qu'une description succincte pourrait le suggérer: AS401197 a un routage double pile soutenu, l'entreprise a acquis son propre espace IPv4, le site commercial et le portail sont actifs, et un avis de maintenance de sécurité de 2026 montre que quelqu'un entretient le service. Le langage de l'entreprise fixe également une attente utile en mettant l'accent sur la petite échelle et le matériel possédé plutôt que de prétendre être un service public mondial.
Les mêmes preuves définissent la limite. Un seul fournisseur d'accès observé en externe transporte les deux familles de routes. Le site physique n'est pas identifié publiquement. Le nord de la Virginie est l'inférence la plus forte, pas un engagement client confirmé. La quantité de matériel installé et la capacité de basculement restante sont inconnues. Le SLA exclut de nombreuses expériences de panne réelles. La restauration des sauvegardes n'est pas garantie, les copies indépendantes sont la responsabilité du client, et les données peuvent traverser les frontières des États ou des pays.
L'historique public des incidents et l'escalade du support restent clairsemés.
Pour un site Web modeste dont le propriétaire conserve une copie externe testée et peut tolérer des heures de perturbation, ce risque peut être acceptable au prix publié. Pour un service qui doit rester disponible malgré une panne d'opérateur, une pénurie de matériel, un litige de facturation ou une évacuation d'installation, les preuves publiques sont insuffisantes. Le client aurait besoin d'un engagement contractuel sur le placement, d'un transit diversifié, d'une capacité de récupération quantifiée, de droits d'exportation et d'une destination de restauration indépendante.
C'est le compromis central de l'économie de l'hébergement. kCore combine racks, licences, transit et expertise humaine afin que les clients n'aient pas à les acheter séparément. Le faible coût mensuel fonctionne parce que ces ressources sont partagées. La résilience fonctionne uniquement lorsque certaines d'entre elles ne sont pas entièrement consommées, lorsque les domaines de défaillance sont véritablement séparés, et lorsqu'une réparation peut avoir lieu avant que le client n'épuise sa tolérance. kCore a montré un service en activité et un petit réseau crédible.
Il n'a pas encore montré, en public, le système de réserve qui prendrait le relais lorsque le système visible tombe en panne.