Résumé
- Linxdatacenter ne doit pas être évalué uniquement sur la base de l'étiquette Amsterdam. Le dossier public appuie une couche identitaire d'origine néerlandaise via Linxtelecom B.V., une adresse à Amsterdam au Hullenbergweg 300 dans plusieurs répertoires d'infrastructure, et un historique interne selon lequel l'entreprise a été fondée aux Pays-Bas en 2000 puis a développé des activités de centres de données en Russie. Le dossier juridique et de service actuel de première partie est cependant centré sur Svyaz VSD LLC, les installations de Moscou et Saint-Pétersbourg, les licences télécoms et de sécurité russes, les services de données personnelles russes et les canaux d'assistance russes.
- La preuve de service la plus solide n'est pas un slogan. C'est la combinaison de pages produits internes, de descriptions de service standard téléchargeables, de règles du portail client, de règles d'assistance technique, de conditions d'intervention à distance, de conditions de colocation, de conditions de connectivité, d'enregistrements d'installations PeeringDB et d'un enregistrement de point d'échange Internet. Ces sources montrent une surface opérationnelle réelle pour la colocation, le cloud, la connectivité, la sauvegarde, la reprise après sinistre (DRaaS), le stockage S3, l'intervention à distance, la communication par portail et l'escalade de l'assistance, tout en laissant d'importantes lacunes de diligence concernant la propriété actuelle, le statut de dépôt néerlandais, les résultats réels des clients, l'historique des pannes, le comportement d'exportation et les risques de sanctions ou de contrats transfrontaliers.
- Les preuves de ressources réseau sont significatives mais limitées. Les enregistrements PeeringDB lient Linxdatacenter à AS48399 dans ses installations de Moscou et Saint-Pétersbourg et à un point d'échange Linxdatacenter-IX à Moscou avec un préfixe d'échange 185.1.162.0/24 et un petit ensemble de pairs. Cela soutient un contexte de routage et d'interconnexion réel. Cela ne prouve pas que l'adresse d'Amsterdam fournisse un hébergement local néerlandais, que chaque service cloud fonctionne de manière identique dans tous les sites, ou qu'un acheteur puisse se fier aux affirmations marketing publiques sans la commande réelle, la description de service, les règles d'assistance et les conditions de localité des données.
Commencer par le nom
Linxdatacenter ressemble, à première vue, à un nom néerlandais de services de centres de données. Plusieurs répertoires d'infrastructure décrivent l'entreprise avec un siège à Amsterdam, et PeeringDB répertorie une organisation au Hullenbergweg 300, Amsterdam, Noord-Holland, 1101 BV, avec le code pays NL. L'historique interne de l'entreprise indique également que Linxtelecom B.V. a été fondée aux Pays-Bas en 2000. C'est suffisant pour rendre le dossier néerlandais pertinent. Ce n'est pas suffisant pour faire du dossier néerlandais la réponse opérationnelle.
La raison est simple: les preuves de service se déplacent rapidement vers l'est. Le site interne actuel de Linx redirige l'ancien domaine Linxdatacenter vers linx.ru et présente des services cloud, de centre de données et de sécurité de l'information pour les entreprises sous les marques Linx, Linx centres de données et Linx Cloud. La page de contacts donne des adresses russes à Moscou et Saint-Pétersbourg, des numéros de téléphone, des canaux d'assistance, des détails juridiques pour Svyaz VSD LLC, des identifiants fiscaux et d'enregistrement, des coordonnées bancaires et une adresse légale à Moscou.
L'historique interne indique que Linxtelecom B.V. a acquis Svyaz VSD en 2011, a poursuivi la direction des centres de données sous la marque Linxdatacenter, puis précise que l'entreprise est devenue russe en 2021 après son acquisition par des investisseurs russes. En 2023, l'historique indique que l'entreprise est passée à une marque ombrelle où Linx est devenue la marque principale et Linx centres de données et Linx Cloud sont devenues des sous-marques.
Cette séquence modifie la question de diligence. Un acheteur ne doit pas seulement demander si Linxdatacenter existe dans les répertoires publics. Il doit demander quelle entité juridique signe, quelle installation fournit le service, quelle juridiction régit les données clients et les dossiers d'assistance, quelles ressources réseau sont réellement utilisées, quelles affirmations publiques sont étayées par des documents de service standard, et quelles affirmations dépendent d'un bon de commande privé. L'adresse d'Amsterdam est un indice d'identité. Les documents juridiques et d'installation russes sont l'indice de service.
La décision commerciale réside dans l'écart entre eux.
Cette distinction est importante car les services de centres de données sont souvent vendus avec des mots lourds: niveau, conformité, disponibilité, connectivité cloud mondiale, portail client, intervention à distance, assistance, sauvegarde, reprise après sinistre et garanties financières. Ces mots peuvent être vrais dans un contrat particulier et faibles dans une brochure générale. Une installation peut être bien exploitée tandis qu'une adresse de répertoire est obsolète. Un service cloud peut être techniquement utile tandis que sa localité est inadaptée pour un client réglementé.
Un processus d'assistance peut être documenté tandis qu'un acheteur individuel doit encore tester comment l'accès, l'escalade et les rapports d'incident fonctionnent.
La lecture correcte est donc prudente mais pas dismissive. Linxdatacenter a un dossier opérationnel beaucoup plus riche que de nombreuses entités de répertoire maigres. Il a des pages de service internes, des conditions standard téléchargeables, un guide du portail, des règles d'assistance, des installations nommées, des certifications et licences, des enregistrements PeeringDB et une entrée de point d'échange visible. Le dossier public est suffisamment solide pour soutenir une conversation sérieuse de diligence sur l'infrastructure.
Il n'est pas suffisamment solide pour laisser l'étiquette néerlandaise se substituer à la preuve de service actuelle.
L'ancre néerlandaise est une couche d'identité
L'ancre néerlandaise comporte deux parties principales. La première est l'historique de l'entreprise. La propre page à propos de Linx indique qu'une entreprise de télécommunications appelée Linxtelecom B.V. a été fondée aux Pays-Bas en 2000. Elle décrit ensuite l'expansion européenne en 2001-2002, le début des activités russes en 2003 via une restructuration autour des actifs de Cable & Wireless et la création de Svyaz VSD, et l'acquisition de Svyaz VSD par Linxtelecom B.V. en 2011.
Cet historique est important car il explique pourquoi la marque porte une identité publique néerlandaise alors que le dossier opérationnel est concentré en Russie.
La deuxième partie est la couche d'adresse d'Amsterdam. PeeringDB répertorie Linxdatacenter avec l'adresse 1 au Hullenbergweg 300 et la localisation Amsterdam, Noord-Holland, 1101 BV. Datacenters.com répète Hullenbergweg 300, 1101 BV Amsterdam, et donne un profil de fournisseur avec deux centres de données. DataCenterMap et Baxtel décrivent l'entreprise comme ayant son siège à Amsterdam tout en répertoriant les installations russes et les emplacements partenaires. D'autres enregistrements de type répertoire répètent également l'adresse d'Amsterdam. Ces enregistrements sont utiles car ce sont des ancres publiques indépendantes.
Ils montrent que l'identité tournée vers Amsterdam n'est pas inventée pour une seule page.
Mais la couche néerlandaise est mince là où les acheteurs ont souvent besoin de la plus grande précision. Le vaste dossier public examiné ici n'a pas gelé une page de détails actuelle de la Chambre de commerce néerlandaise pour Linxtelecom B.V. ni aucun extrait de registre néerlandais actuel liant l'adresse d'Amsterdam, les administrateurs, la propriété, les noms commerciaux et l'autorité contractuelle aux services actuellement commercialisés sous les noms Linx, Linx centres de données ou Linx Cloud.
Le propre site public de KVK explique que la Chambre de commerce néerlandaise tient à jour les informations du registre des entreprises et les services de bureau, mais ce contexte de registre générique n'est pas identique à un extrait d'entreprise actuel. Un acheteur devrait donc obtenir un extrait KVK frais ou une preuve d'entreprise actuelle équivalente avant de traiter la couche d'Amsterdam comme une autorité contractuelle.
Ce n'est pas un point de paperasse mineur. Les contrats de centres de données dépendent de contreparties précises. Si l'histoire commerciale dit « siège à Amsterdam », mais que la commande juridique indique Svyaz VSD LLC, l'acheteur doit savoir quelle entité facture, quelle entité possède ou loue l'installation, quelle entité reçoit les données personnelles, quelle entité exploite le portail client, quelle entité est responsable des défaillances d'assistance et quelle entité est couverte par les certifications et licences.
Si la réponse est différente pour la colocation, l'IaaS, la connectivité, la sauvegarde, la DRaaS et l'intervention à distance, chaque service a besoin de sa propre limite.
Il y a aussi un problème de timing. Certains répertoires publics décrivent encore Linxdatacenter comme actif depuis 2001 et opérant en Europe centrale et orientale, en Russie, en Asie et dans les pays nordiques. L'historique interne de Linx indique que l'architecture de marque a changé en 2023 et que l'entreprise est devenue russe en 2021. Un profil de répertoire peut être en retard sur un changement d'entreprise. Un historique interne officiel peut comprimer les détails de propriété et juridiques pour la lisibilité marketing. Un client ne doit pas forcer ces enregistrements dans une seule histoire soignée.
Il doit préserver la contradiction comme un élément de diligence.
Le dossier néerlandais a donc de la valeur comme point de départ pour l'attribution. Il indique à l'acheteur d'où vient le nom, quelle adresse apparaît dans les répertoires d'infrastructure et pourquoi l'entreprise est parfois décrite comme européenne ou basée à Amsterdam. Il ne prouve pas la résidence actuelle des données aux Pays-Bas, le droit néerlandais, la couverture d'assistance néerlandaise, les opérations néerlandaises de centres de données ou le recours réglementaire néerlandais. Ces affirmations nécessitent des preuves contractuelles actuelles, pas une identité héritée.
Le dossier opérationnel russe est la couche de service
La couche de service est beaucoup plus concrète. Les pages anglaises et russes de Linx décrivent des services cloud, des services de centres de données et des services de sécurité de l'information. Le site répertorie IaaS, calcul GPU, cloud privé, Kubernetes géré, cloud sécurisé pour la loi russe sur les données personnelles, DRaaS, serveurs VPS ou VDS, sauvegarde, bases de données cloud, migration, stockage objet S3, colocation, services réseau, audit de centre de données, L2VPN, SAST, MFA, WAF et AntiDDoS, NGFW, antivirus, analyse de vulnérabilités, SOC, VPN GOST, pare-feu et services de sensibilisation à la sécurité.
Toutes les affirmations ne méritent pas le même poids, mais la surface publique est plus large qu'une page de répertoire générique de centre de données.
Le dossier d'installation est également plus détaillé. La page d'accueil anglaise interne répertorie Linx Moscou au 8 Marta Street 14, Moscou, avec 4 400 mètres carrés de superficie totale, 5 MW de puissance totale et des normes conformes Tier II ou Tier III. Elle répertorie Linx Saint-Pétersbourg au Repishcheva Street 20a, avec 9 000 mètres carrés, 12 MW de puissance et des normes conformes Tier III. Les pages russes et les pages de service répètent ces deux installations.
Les enregistrements d'installations PeeringDB ajoutent un contexte réseau: l'installation de Moscou répertorie 25 réseaux et trois points d'échange locaux, tandis que l'installation de Saint-Pétersbourg répertorie 13 réseaux et un point d'échange local. PeeringDB répertorie également les opérateurs télécoms sur site et identifie Linxdatacenter elle-même comme AS48399 dans les deux installations.
Le dossier juridique est interne et russe. La page de contacts répertorie Svyaz VSD LLC comme nom officiel, donne INN 7713339141, KPP 771301001, OGRN 1037713010444, date d'enregistrement le 3 mars 2003, adresse légale à Moscou, adresse réelle à Moscou, adresse de la succursale de Saint-Pétersbourg, numéro d'assistance, e-mail et coordonnées bancaires. Ces détails ne remplacent pas un extrait d'entreprise russe officiel, mais ils sont beaucoup plus spécifiques sur le plan opérationnel que la couche de répertoire d'Amsterdam. Ils identifient la contrepartie publique pour le site de service actuel.
Le dossier documentaire est particulièrement important.
La page documents contient un accord-cadre d'infrastructure virtuelle version datée du 3 mars 2026, des documents d'accès de démonstration datés du 29 octobre 2025, des descriptions de service pour la colocation, Linx Cloud IaaS, BaaS, connectivité, interconnexions, intervention à distance, services Linx Cloud, MFA, DRaaS, S3 et Kubernetes géré, plus des conditions standard telles que l'utilisation acceptable, les règles d'assistance technique client, les règles d'échange de documents électroniques, la confidentialité et la non-divulgation des données personnelles, et un guide du portail Linx.
Ces documents renforcent le dossier public car ils décrivent la relation opérationnelle en termes procéduraux, pas seulement marketing.
Cela dit, la couche russe soulève ses propres questions de diligence. Si l'acheteur est aux Pays-Bas, dans l'Union européenne ou dans toute juridiction avec des politiques strictes de risque fournisseur, il doit décider si l'exploitation d'installations russes, la contractualisation avec une entité juridique russe, les services de données personnelles russes, les licences télécoms russes et les canaux d'assistance russes sont acceptables. Un service peut être techniquement solide et commercialement inadapté pour une classe de données particulière. La question de l'article n'est pas de savoir si Linx est « bon » ou « mauvais ».
La question est de savoir si le dossier public permet à un acheteur de cartographier la responsabilité, la localité et la récupération suffisamment bien pour se fier à la limite de service.
La réponse est conditionnelle. Pour un client qui souhaite une colocation russe ou des services cloud locaux russes, le dossier est assez riche pour commencer une diligence sérieuse. Pour un client qui souhaite une garantie locale néerlandaise, le dossier est mince. La couche d'Amsterdam ne montre pas, par elle-même, la capacité d'installation néerlandaise, l'hébergement néerlandais, l'assistance néerlandaise, la résidence des données néerlandaise ou un contrat légal néerlandais pour les services actifs.
La colocation est la surface opérationnelle la plus claire
La colocation est le service le plus facile à évaluer car les documents publics la décrivent en termes d'installation. La page de colocation offre un placement de serveur, de baie et de zone dédiée. Elle revendique une fiabilité alignée Tier III, plus de 60 opérateurs télécoms sur les sites, une assistance 24/7/365 en russe et en anglais, et un SLA jusqu'à 99,98 % avec garanties financières.
Elle répertorie les travaux opérationnels inclus ou associés: emplacement pour les serveurs, connexion électrique, surveillance de l'état physique, aide au transport, organisation des baies, assistance à l'installation et à la connexion, zones séparées, options de sécurité, surveillance de l'infrastructure, service à distance, interconnexions, stockage pour équipements et pièces de rechange, câblage et espace de bureau d'urgence.
La description de service de colocation téléchargeable ajoute un langage de contrôle utile. Elle indique que le service s'applique aux centres de données Linx à Moscou et Saint-Pétersbourg, fait partie des conditions de l'accord-cadre standard, et décrit les moyens techniques et l'espace pour l'équipement du client. Elle définit les centres de données Linx comme des locaux équipés appartenant à Linx et situés à Moscou et Saint-Pétersbourg, avec contrôle environnemental, protection incendie, alimentation de secours, connexions télécommunications protégées et équipement de sécurité physique.
Elle décrit le contrôle d'accès, la vidéosurveillance 24/7, le personnel autorisé, la détection incendie et fumée, la suppression par gaz, les paramètres climatiques, les générateurs diesel de secours et les onduleurs, les dispositions de baies et d'espace en baie, les interconnexions, la distribution électrique et les options de surveillance à distance.
Il s'agit d'un matériel de preuve de service. Il ne dit pas simplement « fiable ». Il nomme la limite client: espace, baie, PDU, interface, alimentation, refroidissement, sécurité, câblage, surveillance, maintenance et composants spécifiques à la commande. Il révèle également où la diligence doit atterrir.
Le client doit demander quel module de Moscou ou quel hall de Saint-Pétersbourg est concerné, quelle norme d'installation s'applique, quelle baie ou cage est attribuée, quelle configuration électrique est achetée, quel PDU appartient à Linx, où se trouve le point de transfert de responsabilité, quel processus d'accès s'applique, comment les interconnexions sont commandées, à quoi ressemblent les avis de maintenance et comment les crédits de service sont calculés.
La description standard aide également à éviter les excès. Une déclaration selon laquelle un centre de données a des éléments alignés Tier III ne signifie pas que chaque service client a le même profil de risque. La page Moscou elle-même distingue les normes Tier II et Tier III pour Moscou, tandis que le document indique que les modules de Moscou et les installations de Saint-Pétersbourg peuvent avoir des normes de notation différentes. Un client achetant de la colocation devrait insister sur le site exact, le module, la salle, le chemin d'alimentation et la version du contrat.
Un enregistrement de répertoire ne peut pas répondre à ces questions.
La valeur commerciale de la colocation dépend de la capacité de Linx à réduire la charge opérationnelle sans cacher la limite. Si Linx gère l'accès à l'installation, la sécurité physique, l'alimentation, le refroidissement, la présence de transporteurs, l'intervention à distance et les interconnexions, le client évite de construire sa propre opération de centre de données russe. Mais le client possède toujours la configuration de l'équipement, la résilience des applications, la conception de la sauvegarde, l'inventaire, les pièces de rechange, la conception du réseau et la planification de sortie, sauf si ceux-ci sont contractés séparément.
Les documents publics rendent cette séparation suffisamment visible pour poser les bonnes questions.
Les services cloud sont un problème d'assurance différent
Les affirmations cloud nécessitent un test plus difficile que les affirmations de colocation. Un service en baie peut être inspecté via l'emplacement, l'accès, l'alimentation, le refroidissement et les enregistrements d'interconnexion. Un service cloud ajoute la virtualisation, l'identité, la séparation des locataires, le comportement de l'API, la politique de sauvegarde, la localité des données, la gestion des images, les modifications du catalogue de services, la mesure, la facturation, la résilience du plan de contrôle, les outils de sécurité et l'exportation client.
La page IaaS publique de Linx indique que son infrastructure virtuelle fonctionne sur ses propres centres de données de niveau Tier III à Moscou et Saint-Pétersbourg, offre SLA et garanties financières jusqu'à 99,99 %, un trafic illimité à un gigabit, un stockage conforme à la loi russe sur les données personnelles, une assistance 24/7, des réseaux privés avec routage et filtrage, des adresses IP publiques et l'équilibrage de charge. Elle nomme VMware et OpenStack comme plateformes de virtualisation.
Ce sont des affirmations utiles, mais ce ne sont pas des assurances complètes. VMware et OpenStack indiquent quelque chose sur la base technique. Ils ne révèlent pas l'implémentation de l'isolation des locataires, la politique IAM, la disponibilité du plan de contrôle, la journalisation d'audit, la rétention des snapshots, la provenance des images, la gestion des clés, les limites de taux d'API, la gestion des vulnérabilités, les fenêtres de maintenance, les formats de sortie ou les tests de restauration. Un acheteur ne doit pas confondre un nom de plateforme avec un résultat opérationnel.
Le menu cloud public de Linx est large. Il inclut Kubernetes géré, bases de données cloud, stockage objet compatible S3, sauvegarde, DRaaS, cloud privé, cloud sécurisé pour données personnelles, ressources GPU et migration. La page de stockage objet indique que le service est compatible S3, prend en charge des outils familiers tels que API, CLI, WinSCP, Java SDK et Python SDK, et se positionne comme conforme aux exigences russes en matière de données personnelles. La page de sauvegarde décrit la sauvegarde depuis le site ou vers Linx Cloud, trois niveaux d'assistance, des scénarios de sauvegarde flexibles et le chiffrement côté client.
La page DRaaS indique que les machines virtuelles sont répliquées à l'aide de VMware Cloud Director Availability, les RTO et RPO sont définis individuellement, et les charges de travail peuvent être transférées vers le cloud Linx en mode semi-automatique après un incident.
Ces pages aident à identifier les modules de service. Elles ne prouvent pas que le déploiement d'un client atteindra son propre objectif de reprise. La DRaaS ne fonctionne que si la portée de la réplication, le séquencement de la reprise, le DNS, le routage réseau, l'authentification, la cohérence des données et la cadence des tests sont bien conçus. La sauvegarde ne fonctionne que si les tests de restauration prouvent que la sauvegarde est utilisable.
La compatibilité S3 n'a d'importance que si les applications, les clés, les besoins de verrouillage d'objet, la politique de rétention, les journaux d'audit et le plan de sortie du client sont clairs. Kubernetes géré n'aide que si la mise à niveau du cluster, l'image du nœud, le registre, la politique réseau et la réponse aux incidents sont compris contractuellement.
La page documents est donc plus précieuse que la grille de produits. La description de service IaaS 2026, le document DRaaS, le document S3, le document Kubernetes géré et le guide du portail sont les documents qu'un acheteur devrait demander et comparer à son architecture. Les résumés de site Web publics montrent le menu; les descriptions de service standard montrent les limites. L'assurance finale vient toujours d'une commande, d'un diagramme d'architecture, d'une revue de sécurité, d'un test d'assistance et d'un exercice de reprise.
C'est là que la question commerciale devient pratique. Linx peut justifier sa valeur pour les clients qui ont besoin d'une infrastructure locale russe, de certifications locales, d'une assistance en russe et en anglais, d'une proximité de colocation, de services réseau et d'une migration gérée. Il peut être moins attractif pour les clients dont la contrainte décisive est la résidence des données dans l'UE, le recours légal néerlandais ou un écosystème cloud avec des artefacts de conformité publique plus approfondis. Le dossier public ne peut pas trancher ce compromis. Il peut rendre le bon compromis visible.
Le portail est une surface de gouvernance
Le portail Linx est l'un des enregistrements les plus importants du matériel public. La page de connexion du portail est visible à portal.linxdatacenter.com. La page documents lie un guide d'utilisation du portail, et les règles d'assistance technique font du portail un canal de tickets. Le guide du portail indique que l'utilisation du portail Linx est disponible via un compte client et donne accès aux informations sur les services fournis au client et aux fonctionnalités du portail.
Il indique que le compte client principal est créé par l'assistance technique Linx et que les données de connexion sont envoyées à l'adresse e-mail du contact principal du client. Il définit les comptes clients comme des comptes pour le contact principal ou les représentants autorisés, et l'administration du compte comme des actions du contact principal pour créer et définir les droits pour des comptes de portail supplémentaires.
C'est un langage de gouvernance. Il montre que le portail client n'est pas seulement un écran de commodité; c'est une surface de contrôle. Le guide indique que le portail peut être utilisé pour accéder aux informations de service, administrer les comptes, utiliser le système de tickets, exporter des rapports et des statistiques pour certains services, demander un accès permanent ou temporaire au centre de données, demander l'entrée et le retrait d'équipement, recevoir des avis de travaux planifiés et d'urgence, et accéder aux documents liés au contrat et aux commandes.
Il indique également que les messages reçus via le système de tickets sont juridiquement significatifs et ont la même force que les messages écrits remis en personne, par courrier, coursier, e-mail ou échange de documents électroniques. Un message du portail peut donc faire partie du dossier de service formel.
Cela renforce le dossier public, mais cela soulève également des risques. Si les messages du portail sont juridiquement significatifs, le contrôle d'accès est important.
Le guide public indique que le contact principal administre les comptes, mais le dossier public examiné ici ne montre pas la politique de mots de passe, l'authentification multifacteur pour le portail, les options d'authentification unique, la granularité des rôles, la rétention des journaux d'audit, la revue des utilisateurs inactifs, les chaînes d'approbation déléguées, la révocation d'urgence, les formats d'exportation, l'accès API, la sauvegarde des enregistrements du portail, ou ce qui se passe si le contact principal quitte le client.
Linx vend MFA comme un service de sécurité séparé, mais cela ne prouve pas que le portail client lui-même impose MFA par défaut.
La demande de diligence appropriée est simple. Le client devrait demander comment les utilisateurs du portail sont créés, approuvés, modifiés et révoqués; quelles actions du portail sont contraignantes; quelles actions nécessitent une deuxième approbation; quels enregistrements peuvent être exportés; quels documents et commandes sont visibles; comment les avis de travaux planifiés et d'urgence sont délivrés; comment l'accès au centre de données client est autorisé; et comment l'historique des tickets est conservé après la résiliation.
Si le service est critique pour l'activité, le client devrait tester un ticket d'assistance, un changement de contact, une demande d'accès, une exportation de rapport et une notification de maintenance planifiée avant de se fier au portail en situation de stress.
Le portail renvoie également à la localité. Un acheteur devrait savoir où les données du portail sont traitées, quelle entité exploite le portail, quelle loi régit les messages du portail, qui peut accéder au contenu des tickets, combien de temps les enregistrements sont conservés et si les pièces jointes client peuvent inclure des diagrammes d'infrastructure sensibles. Aucun de ces détails n'est complètement résolu par le guide public. Le guide public indique cependant exactement où demander.
Le travail d'assistance est visible et mesurable
Le travail d'assistance local n'est pas caché dans le dossier Linx. Le site répertorie à plusieurs reprises une assistance technique 24/7, avec une assistance en russe et en anglais sur la page anglaise principale et les pages russes. La page de contacts donne un numéro d'assistance. Les règles d'assistance technique sont plus précieuses: elles demandent au personnel client autorisé de soumettre les problèmes via le système de tickets du portail Linx, l'e-mail d'assistance ou le téléphone.
Elles définissent le personnel autorisé comme le contact principal dans la commande, une autre personne nommée dans la commande, ou une personne contactant Linx depuis le domaine d'entreprise du client ou via le système de tickets du portail. Elles précisent les informations à inclure dans la demande d'assistance: nom légal de l'entreprise, numéro et date du contrat, nom du contact, téléphone, priorité et description détaillée du problème.
Les mêmes règles d'assistance fournissent des objectifs de réponse. Les incidents critiques qui arrêtent les opérations commerciales ont un objectif de réponse de 15 minutes, un temps de résolution cible de quatre heures, des mises à jour de statut toutes les heures, un délai d'escalade d'une heure et des rapports d'incident sur demande dans les deux jours ouvrables.
Les incidents de priorité élevée ont également un objectif de réponse de 15 minutes, un temps de résolution cible de huit heures, des mises à jour de statut toutes les deux heures, un délai d'escalade de quatre heures et des rapports d'incident sur demande dans les deux jours ouvrables. Les incidents moyens ont un objectif de réponse d'un jour ouvrable et un temps de résolution cible de deux jours ouvrables.
Les demandes de changement urgentes ou d'informations ont un temps de réponse d'une heure et un temps de réponse cible de quatre heures; les demandes ordinaires ont un temps de réponse d'un jour ouvrable et un temps de réponse cible de deux jours ouvrables. Les règles donnent également un e-mail d'escalade pour les progrès insatisfaisants ou les informations manquantes.
C'est une véritable responsabilité d'assistance. C'est beaucoup plus solide qu'une ligne de brochure disant que l'assistance est disponible. Cela donne aux acheteurs un moyen de tester le comportement du service. Le client peut placer une demande à faible risque, vérifier la création du ticket, observer le timing de réponse, vérifier si l'identifiant de service est reconnu, tester le libellé d'escalade et voir si les mises à jour arrivent via le même canal. Le client peut également confirmer si les objectifs s'appliquent à son service, à sa commande, à son emplacement et à sa définition de gravité.
La prudence est que les objectifs d'assistance ne sont pas identiques aux performances de la plateforme. Un objectif de réponse de 15 minutes ne signifie pas que chaque incident est résolu en 15 minutes. Une résolution cible de quatre heures pour un incident critique nécessite des définitions, des exclusions et des limites de dépendance. Un problème d'alimentation du centre de données, un défaut d'équipement client, un défaut de transporteur en amont, une session BGP mal configurée et une panne d'application sont des incidents différents.
Le client devrait demander quand le chronomètre démarre, ce qui compte comme résolution, comment les retards de tiers sont traités, comment les fenêtres de maintenance affectent les objectifs et quels incidents donnent droit à des crédits de service.
L'intervention à distance a également une profondeur procédurale publique. La description de l'intervention à distance indique que le service couvre l'assistance technique professionnelle pour l'installation et l'exploitation de l'équipement, la configuration des services et applications client, et les services connexes nécessaires à la colocation ou à l'infrastructure cloud.
Elle répertorie des composants tels que l'installation ou le basculement, les vérifications visuelles, les vérifications de connexion réseau et électrique, l'organisation des connexions, le remplacement de pièces hot-swap et de bandes, la configuration de composants réseau, le déploiement de machines virtuelles, l'installation de systèmes d'exploitation et de mises à jour à partir des distributions client, l'exécution de tests, le dépannage et la prise de contact avec le support fournisseur. Elle indique que les actions sont effectuées sur la base d'instructions du personnel client autorisé par téléphone, e-mail ou portail.
Cela crée une limite de travail humain. Le personnel de Linx peut être précieux car il peut toucher l'équipement, vérifier les indicateurs, remplacer des pièces et exécuter des instructions convenues lorsque le client ne peut pas être dans la salle. Mais l'intervention à distance crée également un risque de contrôle: mauvaises instructions, autorisation peu claire, enregistrements de modification manquants, équipement mal étiqueté, erreurs de pièces de rechange et ambiguïté après action. Le dossier public soutient l'existence d'un processus d'intervention à distance. Il ne prouve pas la qualité d'une intervention particulière.
Un acheteur sérieux devrait tester une tâche d'intervention à distance bénigne et exiger des enregistrements horodatés.
Les preuves réseau sont réelles mais limitées
Les preuves de ressources réseau pour Linxdatacenter sont inhabituellement concrètes par rapport à de nombreuses entreprises de répertoire. PeeringDB répertorie l'organisation Linxdatacenter à l'adresse d'Amsterdam, avec une dernière mise à jour en juin 2023. Il répertorie des installations à Moscou et Saint-Pétersbourg. L'enregistrement de l'installation de Moscou répertorie 25 réseaux, trois points d'échange locaux, l'adresse au 8 Marta 14, et note la superficie totale, la puissance, le niveau de fiabilité et les certifications. Il répertorie également un long ensemble d'opérateurs télécoms sur site et inclut Linxdatacenter comme AS48399.
L'enregistrement de l'installation de Saint-Pétersbourg répertorie 13 réseaux, un point d'échange local, l'adresse au Repishcheva 20a, la superficie totale, la puissance, la centrale électrique au gaz, le niveau de fiabilité, les certifications, les connexions directes à deux hubs, les opérateurs télécoms sur site et Linxdatacenter comme AS48399.
L'enregistrement de point d'échange PeeringDB est encore plus spécifique. Linxdatacenter-IX est décrit comme un point d'échange Internet pour les points de présence Linxdatacenter à Moscou. Il répertorie cinq pairs, cinq connexions, deux pairs ouverts, une capacité totale de 42 G, zéro pour cent IPv6, installation locale à Linxdatacenter Moscou, e-mail technique et politique à[email protected], téléphone technique, LAN 3072, MTU de charge utile 1500, préfixe IPv4 185.1.162.0/24, et pairs incluant CITIC Telecom CPC Netherlands, Linxdatacenter AS48399, Nauka-Svyaz, et deux ASN TC TEL CENTER.
Cela soutient plusieurs affirmations limitées. Linxdatacenter a un enregistrement d'interconnexion publique. Les installations ne sont pas seulement des noms marketing; elles apparaissent dans PeeringDB avec des réseaux et des points d'échange. Linxdatacenter elle-même apparaît comme entité au système autonome dans les deux installations et au point d'échange. Le site public propose une page looking-glass et IX qui pointe vers ix.linxdatacenter.com et lg.linxdatacenter.com.
La page de services réseau décrit DIA, IPT, BGP si nécessaire, bande passante de 1 Mbit/s à 10 Gbit/s, support de l'infrastructure réseau, surveillance 24h/24 à l'aide de Zabbix, accès de sauvegarde à l'équipement réseau via un serveur console, et L2VPN comme moyen de connecter bureaux, centres de données et clouds.
Mais les preuves réseau ne doivent pas être étirées. PeeringDB est une base de données communautaire auto-maintenue, pas un rapport de performance réseau audité. Il ne prouve pas la qualité actuelle du trafic, la disponibilité, la sécurité de routage, la configuration RPKI, la résilience DDoS, la préparation IPv6, l'hygiène de routage client, la perte de paquets ou la latence. L'enregistrement du point d'échange ne montre aucune part IPv6, ce qui peut ou non pour le cas d'utilisation d'un client.
Les enregistrements d'installations répertorient les opérateurs et les réseaux, mais un client a toujours besoin de ses propres options d'interconnexion, taille de port, SLA, avis de maintenance et politique de routage. Un client doit également confirmer si AS48399 est utilisé pour son service ou si une disposition en amont, partenaire ou privée s'applique.
L'utilisation correcte de l'enregistrement réseau est de réduire l'ambiguïté, pas de vendre la confiance par association. Un acheteur peut demander l'ASN exact, le préfixe, le support des communautés BGP, le processus LOA ou CFA, la politique RPKI et IRR, la pratique de filtrage de routage, la gestion DDoS, l'accès au looking-glass, l'escalade NOC, le calendrier de maintenance, la diversité de chemin et les alternatives de transporteur. Le dossier public de Linx donne suffisamment d'indices pour rendre ces questions spécifiques.
La localité des données est un choix contractuel
La localité des données est le risque central caché derrière l'étiquette néerlandaise. Une entreprise avec un historique d'origine néerlandaise et une adresse à Amsterdam peut toujours fournir des services cloud, de colocation, d'assistance et de portail via des installations russes et une entité juridique russe. Les propres pages de Linx mettent l'accent sur les services de données personnelles russes, y compris le positionnement 152-FZ et 242-FZ dans les descriptions de partenaires et les pages internes. Les pages de cloud sécurisé et de stockage objet encadrent la protection des données en termes réglementaires russes.
La page d'accueil anglaise indique que Linx propose un cloud sécurisé pour les données personnelles et une infrastructure conforme à la loi fédérale russe 152. La page de contacts pointe vers Svyaz VSD LLC et des adresses russes.
Pour un client dont les charges de travail sont destinées à rester en Russie, cela peut être une fonctionnalité. Une exploitation locale russe de centre de données, des licences télécoms russes, des certificats de sécurité de l'information russes, une assistance russe et une conformité aux données personnelles russes peuvent être exactement l'objectif opérationnel. Pour un client dont les données doivent rester dans l'Espace économique européen, les mêmes faits sont un avertissement.
L'adresse néerlandaise ne prouve pas que le calcul, le stockage, la sauvegarde, les tickets de portail, les pièces jointes d'assistance, les journaux, les enregistrements de facturation, les rapports d'incident, les avis de maintenance ou les enregistrements de localisation restent aux Pays-Bas ou dans l'EEE.
La localité des données diffère également selon le type d'enregistrement. Un serveur placé à Moscou ou Saint-Pétersbourg est physiquement local en Russie. Une machine virtuelle peut fonctionner dans un cloud russe Linx. Les copies de sauvegarde peuvent résider dans Linx Cloud ou être transférées depuis les locaux du client. Les objets S3 peuvent être stockés selon les exigences russes en matière de données personnelles. Les tickets de portail peuvent inclure des noms de clients, e-mails, numéros de téléphone, identifiants de service, demandes d'accès en baie, demandes de déplacement d'équipement, descriptions d'incident et pièces jointes.
Les appels d'assistance peuvent être traités par du personnel russe. Les documents et communications électroniques peuvent être juridiquement significatifs selon les conditions standard de Linx. Chaque enregistrement a besoin de sa propre carte.
Le dossier public ne fournit pas d'accord de traitement des données complet pour les clients non russes. Il ne montre pas de représentant UE actuel, de liste de sous-traitants, d'analyse d'impact des transferts, de voie contractuelle néerlandaise, de calendrier de conservation des données client, d'emplacement des données du portail, d'emplacement des journaux d'assistance, de conservation des clés de chiffrement ou de processus de certificat de suppression. Cela ne signifie pas que ces documents n'existent pas en privé. Cela signifie qu'un acheteur ne peut pas les déduire des pages publiques.
La réponse pratique est de diviser la localité en quatre questions. Premièrement, où se trouve la charge de travail de production? Deuxièmement, où se trouvent les sauvegardes et les répliques? Troisièmement, où se trouvent les enregistrements d'assistance, de portail, de facturation et contractuels? Quatrièmement, quelle entité juridique et quelle loi régissent chaque catégorie? Si Linx peut répondre clairement à ces questions et fournir un langage contractuel, le service peut être adapté à la classe de données visée.
Si ce n'est pas le cas, l'acheteur doit traiter la couche néerlandaise comme une simple identité de marque et éviter de placer des données réglementées qui nécessitent une localité néerlandaise ou européenne.
C'est également là que le coût de migration entre dans la décision commerciale. Un client qui conclut un arrangement cloud ou de colocation sans règles d'exportation, de suppression, d'accès et de conservation des enregistrements d'assistance peut faire face à des coûts de changement élevés plus tard. La localité des données n'est pas seulement une case à cocher de conformité. Elle affecte la vitesse de sortie, le traitement des litiges, la préservation des preuves et la continuité en cas de changement géopolitique ou commercial.
La reprise signifie plus qu'un produit de reprise après sinistre
Linx vend des services de reprise après sinistre (DRaaS), de sauvegarde et de résilience de colocation. C'est pertinent, mais la reprise doit être évaluée sur l'ensemble de la surface opérationnelle. La page DRaaS publique indique que les machines virtuelles sont répliquées avec VMware Cloud Director Availability, les RTO et RPO sont définis individuellement, et les charges de travail peuvent être déplacées vers Linx Cloud en mode semi-automatique après un incident. La page de sauvegarde décrit plusieurs scénarios et niveaux d'assistance.
La page de colocation revendique la résilience des installations via l'alimentation, le refroidissement, la sécurité, le BMS, les générateurs de secours et les onduleurs. Les règles d'assistance donnent des objectifs de réponse et d'escalade. Le guide du portail indique que les clients peuvent recevoir des avis de travaux planifiés et d'urgence via le portail.
Ensemble, ces enregistrements montrent un écosystème de reprise. Ils ne prouvent pas un résultat de reprise. Un produit de reprise peut échouer si les dépendances applicatives ne sont pas incluses, si les routes réseau ne bougent pas, si le DNS n'est pas mis à jour, si les identifiants ne sont pas disponibles, si les sauvegardes sont cohérentes en cas de panne plutôt que cohérentes au niveau application, si les contacts d'assistance sont obsolètes, si l'accès au portail est détenu par la mauvaise personne, si le propre runbook du client est faible, ou si les tests de restauration ne sont jamais effectués.
Un client ne doit pas acheter DRaaS comme un charme contre les temps d'arrêt. Il doit acheter des chemins de reprise testés.
Les documents publics aident à définir les tests. Pour l'IaaS, le client devrait demander comment les snapshots, les sauvegardes, les modèles de VM, les réseaux et les règles de pare-feu sont récupérés. Pour la DRaaS, il devrait demander le RTO, le RPO, les fenêtres de test, les étapes de retour arrière, les dépendances réseau et les preuves d'un test récent. Pour S3, il devrait demander le versionnage, les options d'immuabilité, la gestion des clés, la récupération après suppression et l'exportation.
Pour la colocation, il devrait demander comment les incidents d'installation sont communiqués, comment l'intervention à distance est priorisée, comment les pièces de rechange sont stockées, comment l'accès est accordé en cas d'urgence et comment les défaillances d'interconnexion sont isolées. Pour la connectivité, il devrait demander comment les incidents ETHERLINX, DIA et IPT sont classifiés et crédités.
La reprise inclut également la reprise de compte. Le guide du portail rend le compte client et le contact principal centraux. Si le contact principal n'est pas disponible, un contact de secours peut-il ouvrir des tickets critiques, autoriser l'intervention à distance, demander l'accès, recevoir des notifications d'urgence et obtenir des rapports? Si un client perd l'accès au portail pendant un incident, l'assistance peut-elle authentifier la demande sans créer de contournement de sécurité? Si le client a besoin d'une exportation complète de l'historique des tickets après la résiliation, est-ce disponible?
Les documents publics identifient le portail mais ne répondent pas à toutes les questions de reprise.
La valeur commerciale de l'offre de reprise de Linx dépend de sa capacité à réduire la propre charge du client. Un fournisseur mature devrait rendre la reprise ennuyeuse: rôles clairs, procédures testées, listes de contacts à jour, notification fiable, dépendances documentées, exercices de routine et règles de crédit explicites. Le dossier public pointe vers la procédure. Il ne montre pas de performance de reprise mesurée. Un acheteur devrait demander des preuves de test avant de se fier aux affirmations de reprise.
Le cas commercial dépend de la limite
Linxdatacenter peut avoir un sens commercial pour un acheteur spécifique. Si l'acheteur a besoin d'une présence d'installation en Russie, d'un cloud local russe, d'une conformité aux données personnelles russes, d'une colocation plus intervention à distance, d'une interconnexion à Moscou ou Saint-Pétersbourg, d'une assistance technique en anglais et en russe, de descriptions de service standard et d'un portail client, le dossier public offre une limite de service cohérente. Ce n'est pas seulement un nom de répertoire. Il y a des installations, des documents, des enregistrements réseau et des procédures d'assistance à examiner.
Le même dossier public peut rendre Linx inadapté pour un autre acheteur. Si le besoin principal de l'acheteur est une capacité de centre de données néerlandais, un traitement uniquement dans l'UE, le droit néerlandais, un recours actuel auprès d'une société néerlandaise, des artefacts de conformité UE publics, ou une plateforme cloud avec des preuves étendues de centre de confiance public, le dossier n'est pas suffisant. L'adresse d'Amsterdam et l'histoire d'origine néerlandaise ne peuvent pas porter cette exigence.
L'acheteur aurait besoin de preuves juridiques, de traitement de données, d'installation et d'assistance actuelles que le dossier public ne fournit pas.
C'est la différence entre la valeur d'étiquette et la valeur de limite. Une étiquette dit « siège à Amsterdam », « fournisseur mondial », « Tier III », « cloud », « assistance » ou « disponibilité 100 % ». Une limite dit qui signe, où la charge de travail fonctionne, qui peut entrer dans la salle, qui peut ouvrir un ticket, quelle action de portail est contraignante, quel ASN ou transporteur transporte le trafic, comment l'assistance escalade, quels enregistrements sont exportables, quels crédits de service s'appliquent et comment le client sort. Le dossier public est utile car il contient suffisamment de matériel de limite pour tester.
Les acheteurs devraient évaluer les éléments suivants. Premièrement, la clarté juridique: entité contractuelle actuelle, propriété, juridiction, extraits KVK ou russes, filtrage des sanctions et autorité de vendre le service. Deuxièmement, la clarté technique: installation exacte, module, plateforme cloud, chemin réseau, interconnexion, ASN, préfixe, SLA, fenêtres de maintenance et surveillance. Troisièmement, la clarté de l'assistance: contacts autorisés, objectifs de réponse, escalade, rapports de tickets, périmètre de l'intervention à distance et procédures après heures.
Quatrièmement, la clarté des données: emplacement de production, emplacement de sauvegarde, emplacement des enregistrements de portail et d'assistance, conservation, exportation et suppression. Cinquièmement, la clarté de la reprise: tests de restauration de sauvegarde, tests DRaaS, reprise d'accès, rapports d'incident et runbook de sortie.
Lorsque ces réponses sont solides, un fournisseur comme Linx peut réduire la charge d'infrastructure locale d'un client. Lorsque ces réponses sont faibles, le client hérite d'un travail caché: enregistrements parallèles, surveillance supplémentaire, suivi manuel de l'assistance, sauvegardes en double, examen par un conseil externe et planification de migration d'urgence. Le dossier public ne dit pas à l'acheteur quel résultat il obtiendra. Il dit à l'acheteur où regarder.
Ce que le dossier public ne peut pas prouver
Le dossier public a des limites qui devraient être énoncées clairement. Il ne prouve pas le statut actuel de la société néerlandaise, les administrateurs, la propriété ou l'autorité de Linxtelecom B.V. Il ne prouve pas les opérations d'installations néerlandaises. Il ne montre pas que l'adresse d'Amsterdam est un centre de données opérationnel. Il ne montre pas que les charges de travail des clients peuvent être placées aux Pays-Bas. Il ne fournit pas d'extrait KVK actuel, d'accord de traitement des données néerlandais, de liste de sous-traitants UE, d'engagement de résidence des données UE ou de flux de travail d'assistance néerlandais.
Il ne prouve pas non plus les résultats clients. Les pages internes revendiquent disponibilité, assistance, conformité et garanties financières, mais le dossier public n'inclut pas l'historique des pannes, les demandes de crédit de service, la surveillance indépendante de la disponibilité, les rapports d'incident client, les échantillons de réponse d'assistance, les tests de restauration réels, la disponibilité du portail, le comportement d'exportation de tickets, ou les audits clients privés.
Les certifications et licences sont répertoriées, et certaines sont liées, mais les acheteurs devraient vérifier le périmètre du certificat, l'entité juridique, l'installation, la date d'expiration et l'applicabilité du service directement.
Les preuves réseau sont visibles mais pas complètes. PeeringDB montre les installations, les réseaux, les détails du point d'échange et la présence d'AS48399. Il ne prouve pas la qualité de routage, la sécurité de routage, la couverture RPKI, les performances de mitigation DDoS, la perte de paquets, la latence, la discipline de maintenance ou la disponibilité actuelle complète du transporteur. Les liens looking-glass et IX montrent que des outils réseau existent, mais cet article n'a pas effectué de tests réseau, de scans ou de mesures de routage. Les pages publiques ont été lues; les systèmes clients n'ont pas été touchés.
Le processus d'assistance est documenté mais non testé ici. Les règles d'assistance technique répertorient les objectifs de réponse et les chemins d'escalade. Le guide du portail décrit les messages contraignants et l'administration du compte. Les documents d'intervention à distance décrivent les tâches possibles. Ce sont de forts indices procéduraux, pas une preuve qu'un incident critique sera résolu dans le temps cible pour un client particulier.
Ces lacunes ne rendent pas Linxdatacenter inutilisable. Elles en font un fournisseur qui doit être évalué par des preuves de limite, pas par une étiquette de catégorie. Le dossier public est suffisamment solide pour soutenir une conversation d'approvisionnement sérieuse et suffisamment faible pour punir les hypothèses paresseuses. C'est la leçon centrale du dossier néerlandais derrière le nom: Amsterdam peut être l'endroit où pointe l'identité, mais l'assurance de service réside dans l'entité juridique actuelle, l'installation, le réseau, le portail, l'assistance et les enregistrements de reprise.
Un acheteur qui maintient ces couches séparées peut évaluer Linxdatacenter équitablement. Un acheteur qui les effondre en une seule revendication de marque prend un risque que le dossier public ne justifie pas.