Datacenta Hosting: une route visible n’est pas encore une preuve

Summary

Les données de RIPE et de RIPEstat établissent qu’AS196745, identifié comme DATACENTA-AS, annonce une surface d’adressage observable et dispose de plusieurs voisinages externes enregistrés. Elles n’établissent ni la diversité physique des circuits, ni les conditions d’achat du transit, ni la performance livrée à un client, ni une garantie de disponibilité.
La chaîne des noms ne doit pas être aplatie. ORG-DHL11-RIPE associe l’ASN à Datacenta Hosting Ltd et au numéro SC208801, alors que Companies House rattache aujourd’hui ce numéro à Datacenta Hosting (Scotland) Ltd. Une autre société, 15255267, porte le nom DATACENTA HOSTING LTD, tandis que les conditions de services gérés désignent X-Net (Services) Ltd comme fournisseur opérant sous la marque Datacenta Hosting.
Les pages commerciales décrivent des services de colocation, d’hébergement géré, de connectivité, de sauvegarde et de sécurité. Ces déclarations renseignent l’offre, mais ne ferment pas les questions de capacité réservée, de topologie, de tests de restauration, de périmètre de certification ou de responsabilité contractuelle.
Le document décisif est la Service Specification signée. C’est là que doivent être fixés le débit, le trafic inclus, les règles de pare-feu, la sauvegarde, les niveaux de service, les fenêtres de maintenance, l’accès physique, les crédits, la réversibilité et l’identité exacte de la partie qui assume ces engagements.

Le même nom ne constitue pas une seule preuve

Pour un acheteur de services d’infrastructure, un nom cohérent à travers un site web, une base de routage et une facture semble offrir un raccourci rassurant. Il donne l’impression qu’une seule organisation possède le réseau, exploite les locaux, emploie l’équipe de support et répond de l’ensemble des engagements. Le dossier public de Datacenta montre précisément pourquoi ce raccourci est fragile. Les éléments consultables dessinent une activité réelle et une présence réseau observable, mais ils attribuent des fonctions différentes à plusieurs identités dont les rapports exacts ne sont pas entièrement documentés dans le corpus public.

Cette distinction ne relève pas d’un exercice de dénomination. Elle détermine à qui un client peut réclamer l’exécution d’un niveau de service, qui détient les actifs nécessaires pour l’assurer, qui contrôle les ressources Internet et qui reste responsable lorsque l’exploitation change de structure. Un registre d’ASN répond à une question d’administration de ressource. Companies House répond à des questions d’existence, de nom et de dépôts sociaux. Une page de contact explique comment un fournisseur se présente. Des conditions générales désignent une partie contractante et organisent certaines obligations.

Aucune de ces pièces ne remplace les autres.

La bonne méthode consiste donc à ne pas chercher une formule magique qui réunirait tout. Il faut construire une chaîne de preuve. Le premier maillon établit ce qui est visible sur Internet. Le deuxième identifie les personnes morales et suit les changements de noms. Le troisième vérifie quelle entité propose et facture le service. Le quatrième rattache à cette entité les locaux, les équipements, les contrats de connectivité, les certifications et les équipes qui rendent la promesse possible. Le cinquième transforme enfin les capacités annoncées en obligations mesurables dans une Service Specification.

Dans cette chaîne, une ambiguïté n’est pas automatiquement un défaut opérationnel. Des groupes peuvent légitimement répartir une marque, des actifs et des contrats entre plusieurs sociétés. Un changement de nom peut accompagner une réorganisation ordinaire. Un registre réseau peut conserver un libellé historique sans que les routes cessent de fonctionner. Mais l’acheteur ne doit pas convertir cette possibilité en certitude favorable. Lorsque les pièces ne prouvent pas un transfert ou une relation, la conclusion rigoureuse est que le lien reste à documenter.

Ce que prouve réellement AS196745

Le point de départ le plus solide est AS196745. Le service RDAP de RIPE le décrit comme un système autonome actif, portant le nom DATACENTA-AS, enregistré en décembre 2009. L’objet d’organisation associé est ORG-DHL11-RIPE. Celui-ci utilise le nom Datacenta Hosting Ltd, indique le numéro d’enregistrement SC208801, le pays GB et l’adresse Q.20 Dorset Innovation Park. L’objet d’organisation avait été modifié pour la dernière fois le 13 mai 2026 au moment où le paquet de sources a été constitué.

Ces informations sont importantes. Elles relient un identifiant réseau protégé à un objet d’organisation et à des coordonnées déclarées dans la base de registre. Elles permettent aussi de distinguer cette ressource d’un simple nom commercial sans trace technique. Un client ou un auditeur peut retrouver l’objet, vérifier son statut et comparer ses attributs avec d’autres documents. Il s’agit d’un point d’ancrage vérifiable, pas d’une allégation publicitaire isolée.

La portée de ce point d’ancrage reste pourtant précise et limitée. La base ne dit pas quelle société possède un bâtiment donné, quels salariés assurent une astreinte, quelle entité a acheté les routeurs ou signé les contrats de fibre, ni quelle partie émet une facture. Elle ne démontre pas davantage que toute utilisation de la marque Datacenta Hosting relève de la personne morale indiquée dans l’objet. Le rôle de registrant d’une ressource réseau ne suffit pas à attribuer l’ensemble d’une exploitation commerciale.

La photographie de RIPEstat du 20 juillet 2026 à 16 h 00 UTC complète ce tableau par une observation de routage. À cet instant, AS196745 était vu comme origine de six préfixes IPv4 représentant 1 536 adresses et de dix préfixes IPv6 en /48. Les collecteurs RIS voyaient les routes IPv4 auprès de 323 pairs sur 325, et les routes IPv6 auprès des 320 pairs de l’échantillon. Cette large visibilité autorise une conclusion simple: l’origine n’est pas seulement enregistrée, elle est observable dans le système de routage public au moment de la mesure.

La politique publiée dans l’objet aut-num mentionne des imports depuis AS5511, AS60670 et AS206347. Le jeu de voisinages observés de RIPEstat retourne les mêmes trois numéros. La correspondance entre politique déclarée et observation est un signal utile, parce qu’elle réduit le risque de prendre un champ isolé pour une description sans manifestation visible. Elle montre plusieurs adjacences externes enregistrées autour de l’ASN.

Elle ne montre toutefois pas la construction physique sous-jacente. Trois numéros de systèmes autonomes ne signifient pas nécessairement trois chemins indépendants jusqu’à trois bâtiments, trois adductions séparées ou trois contrats de transit achetés selon des conditions distinctes. Deux circuits peuvent partager un fourreau, un point de présence, un opérateur de dernier kilomètre ou une alimentation. Une route peut être largement propagée sans que le débit réservé à un client soit élevé.

L’observation BGP ne mesure ni le temps de réparation, ni la congestion aux heures de pointe, ni la capacité d’absorption d’une attaque, ni le comportement du basculement.

Pour la diligence raisonnable, la valeur d’AS196745 est donc double. Il fournit une preuve positive de présence réseau et une limite méthodologique. On peut demander au fournisseur de faire correspondre les trois voisinages à des circuits, des sites, des ports et des contrats actuels. On ne peut pas remplir cette matrice à sa place à partir des seules routes publiques. C’est précisément à cet endroit que la visibilité Internet doit céder la place aux schémas, aux commandes opérateurs, aux résultats de tests et aux engagements du contrat client.

PeeringDB: un avertissement sur la fraîcheur, pas une carte négative

La fiche PeeringDB d’AS196745 illustre un autre risque fréquent: transformer une donnée absente en preuve d’absence. Elle identifie Datacenta Hosting, indique une politique de peering ouverte, mais ne divulgue ni volume de trafic ni portée géographique. Elle affiche zéro préfixe IPv4 et zéro préfixe IPv6, ne répertorie aucun point d’échange public ni aucune installation, et sa dernière mise à jour remonte à juillet 2022.

Les champs de préfixes sont manifestement en tension avec l’observation plus récente de RIPEstat, qui voit six origines IPv4 et dix /48 IPv6. Cette divergence ne permet pas de choisir arbitrairement la fiche la plus commode. Elle indique que la fiche auto-déclarée n’est pas une représentation à jour de toute la surface routée. Par conséquent, ses tableaux vides ne démontrent pas que l’opérateur n’utilise aucun site, aucun port privé ou aucune interconnexion. Ils démontrent seulement que PeeringDB, dans cet état et à cette date, ne suffit pas à dresser une carte actuelle.

La comparaison entre PeeringDB, RIPE et RIPEstat révèle ainsi la fonction propre de chaque source. La première est une publication communautaire maintenue par ses membres. La base de RIPE contient les objets administratifs et de politique. RIPEstat observe des phénomènes de routage à partir de collecteurs. Les trois peuvent être cohérents sur certains points et divergents sur d’autres, sans que l’un d’eux fournisse à lui seul une vérité opérationnelle complète. La diligence ne supprime pas les divergences; elle les transforme en questions testables.

Une chronologie juridique à garder séparée

Le deuxième axe de vérification commence avec SC208801, le numéro que l’objet ORG-DHL11-RIPE associe à Datacenta Hosting Ltd. Companies House indique qu’il correspond aujourd’hui à Datacenta Hosting (Scotland) Ltd, société active constituée en juillet 2000 et classée sous le code SIC 63110 pour le traitement de données, l’hébergement et les activités connexes. Le registre précise aussi que cette société a porté le nom DATACENTA HOSTING LIMITED de septembre 2003 au 17 septembre 2024.

Une deuxième personne morale apparaît sous le numéro 15255267. Constituée en Angleterre en novembre 2023 sous le nom PBL 200 LTD, elle a adopté le nom DATACENTA HOSTING LTD le 23 septembre 2024. Son historique de dépôts comprend des comptes de société dormante pour la période se terminant en novembre 2024. Cette mention est un fait de dépôt relatif à une période donnée; elle ne permet pas à elle seule de décrire toute activité ultérieure, ni de conclure que la marque ou le service serait inactif.

La proximité des dates attire nécessairement l’attention. Le nom historique a cessé d’être celui de SC208801 le 17 septembre 2024, puis 15255267 a adopté DATACENTA HOSTING LTD six jours plus tard. Il est raisonnable de considérer cette séquence comme un indice possible de coordination. Il serait en revanche excessif d’en déduire un transfert déterminé. Les documents publics examinés ne démontrent pas que des clients, des actifs, des contrats, des adresses IP, des droits de propriété intellectuelle, des salariés, des certifications ou des passifs ont migré d’une société vers l’autre.

Le troisième fil juridique concerne 03290605. Companies House enregistre cette société comme active. Elle portait auparavant le nom KIMCELL LIMITED jusqu’en avril 2024 et utilise désormais le nom X-NET (SERVICES) LTD dans le registre. Le site de X-Net explique que X-Net est le nouveau nom de Kimcell, laquelle exerçait aussi sous la marque Datacenta Hosting, et donne pour le support Datacenta des coordonnées dans le Dorset.

Le texte contractuel apporte un élément plus directement exploitable que la seule page de contact. Les conditions de services gérés désignent X-Net (Services) Ltd comme fournisseur, opérant sous la marque Datacenta Hosting. Cette phrase n’efface ni SC208801, ni 15255267, ni ORG-DHL11-RIPE. Elle identifie la partie que ces conditions présentent comme fournisseur du service couvert par elles. Pour un client soumis à cette version des conditions, c’est un candidat central pour le rôle de cocontractant; il faut encore vérifier que le devis, le bon de commande, la facture et la Service Specification signés utilisent la même identité et le même numéro de société.

Le dossier comporte ainsi au moins quatre libellés fonctionnels qu’il faut conserver dans des colonnes distinctes: le nom de l’objet d’organisation du registre réseau, la société portant le numéro historique associé à cet objet, la nouvelle société ayant adopté un nom Datacenta en 2024, et la société présentée comme fournisseur sous la marque. La marque peut assurer une continuité commerciale entre eux, mais une continuité de marque n’est pas automatiquement une novation contractuelle, une cession d’actifs ou une prise en charge de responsabilité.

Une revue sérieuse devrait demander un organigramme juridique daté, accompagné d’une explication du rôle de chaque société. Elle devrait ensuite relier chaque fonction critique à une entité: propriété ou bail des locaux, propriété des équipements, emploi des équipes, détention des comptes fournisseurs, contrôle administratif des ressources Internet, émission des factures, détention des assurances, titularité des certifications et responsabilité des crédits de service. La réponse doit être compatible avec les documents signés, non seulement avec une présentation commerciale.

Le contrat comme surface de contrôle

Dans de nombreuses évaluations d’hébergement, le contrat est traité à la fin, après la visite technique. Ici, il doit être lu beaucoup plus tôt, car les conditions publiées indiquent explicitement que plusieurs caractéristiques essentielles ne sont pas uniformes. L’espace maximal de serveur, les niveaux du service Internet, le trafic inclus, les règles de pare-feu et d’autres paramètres de performance sont placés dans la Service Specification propre au client.

Ce renvoi change la nature de l’analyse. Une page web peut annoncer de la connectivité, une surveillance permanente ou une offre de sauvegarde. Les conditions générales peuvent décrire le cadre dans lequel ces services sont vendus. Mais seule la spécification signée permet de savoir ce que le client a effectivement acheté. Sans elle, un évaluateur peut décrire le catalogue; il ne peut pas mesurer l’obligation.

La Service Specification devrait d’abord fixer le périmètre technique sans termes vagues. Pour la connectivité, cela signifie le débit de port, le débit garanti éventuel, le mode de facturation des pointes, le trafic inclus, les adresses fournies, la responsabilité du routage, les protections disponibles et les seuils qui déclenchent une action. Pour le calcul et le stockage, cela signifie les quantités réservées, la classe de matériel, les marges de croissance, les délais d’extension et la conduite à tenir lorsqu’une ressource est épuisée.

Elle doit ensuite définir le temps. Les niveaux de service ne valent que si leur fenêtre de mesure, leurs exclusions, leurs points de départ et d’arrivée, leurs calendriers et leurs remèdes sont compréhensibles. Une disponibilité mensuelle mesurée au port réseau n’est pas la même chose qu’une disponibilité applicative de bout en bout. Une réponse de support n’est pas une restauration. Un accusé de réception n’est pas une résolution. Un crédit plafonné à une petite fraction de la facture ne compense pas nécessairement la perte économique d’un incident.

Enfin, la spécification doit relier la promesse à la bonne personne morale. Une annexe techniquement excellente est insuffisante si elle ne fait pas partie du contrat exécutoire, si son ordre de priorité est incertain ou si elle utilise une marque sans identifier le débiteur. Le client devrait vérifier les signatures, les numéros de société, les adresses de notification, la hiérarchie entre devis, bon de commande, conditions et annexes, ainsi que le traitement d’un changement d’entité pendant la durée du service.

Cette exigence n’implique pas que les conditions publiées soient défaillantes. Au contraire, leur renvoi à une spécification révèle honnêtement que les services gérés sont configurés par client. Le risque naît lorsque l’acheteur prend le cadre générique pour le contenu de son propre accord. La meilleure preuve n’est donc pas une capture du site, mais un dossier contractuel complet dont les paramètres peuvent être rapprochés de l’architecture réellement déployée.

Bande passante: distinguer présence, capacité et engagement

La page réseau de Datacenta présente une gamme comprenant le haut débit, les liaisons point à point, un peering sélectionné et le transit IP sous AS196745. Cette description est cohérente avec l’existence observable de l’ASN. Elle ne précise toutefois pas les ports, les capacités installées, les engagements de transit, la réserve disponible ou l’allocation faite à un client particulier.

L’acheteur doit éviter trois substitutions. Premièrement, la présence d’une route ne vaut pas capacité. Une annonce peut être vue mondialement tout en traversant un lien dont la marge est inconnue. Deuxièmement, plusieurs voisins BGP ne valent pas diversité physique. Il faut connaître les opérateurs de dernier kilomètre, les entrées de bâtiment, les chemins de fibre et les points où les circuits convergent. Troisièmement, une capacité installée ne vaut pas engagement client. Le fournisseur peut disposer d’un port rapide sans garantir un débit minimal à chaque service.

Les conditions publiées renforcent cette lecture: elles n’accordent pas de taux minimal de transfert lorsque l’option de bande passante garantie n’a pas été choisie. La question d’achat n’est donc pas « l’ASN est-il multiconnecté ? », mais « quelle bande passante notre accord garantit-il, où est-elle mesurée, et que se passe-t-il lorsqu’elle n’est pas atteinte ? ». La réponse devrait figurer dans la Service Specification, avec des unités, des fenêtres de mesure et une procédure d’escalade.

Pour les services critiques, le dossier de preuve peut inclure un schéma logique et physique à jour, les identifiants des circuits, les capacités de chaque port, les politiques de préférence et de basculement, ainsi que des résultats de tests. Il doit aussi décrire les dépendances qui ne sont pas visibles dans BGP: alimentation d’un équipement d’accès, châssis commun, fibre commune, point de présence partagé, fournisseur de protection DDoS ou intervention humaine nécessaire au rétablissement.

Les données publiques restent utiles pour contrôler ce dossier. Les voisins déclarés peuvent être comparés aux voisins observés. Les préfixes annoncés peuvent être rapprochés des adresses affectées au service. Les changements futurs de visibilité peuvent déclencher une question. Mais le contrôle externe est un détecteur d’écarts, pas un substitut au contrat. Il aide à vérifier une affirmation; il ne crée pas l’engagement absent.

Sauvegarde: une option annoncée n’est pas une restauration prouvée

La page consacrée à la sauvegarde indique que les données sont chiffrées et stockées au Royaume-Uni, que des sauvegardes peuvent être réalisées localement dans chaque centre de données ou à distance entre centres, et qu’un site secondaire peut être proposé. Ces affirmations décrivent plusieurs architectures possibles. Leur formulation ne montre pas laquelle est fournie à un client, où se trouvent exactement les copies, ni comment leur disponibilité a été testée.

Les conditions de services gérés placent en outre la sauvegarde sous la responsabilité du client, sauf lorsqu’une option de sauvegarde a été demandée et convenue. Cette règle rend dangereuse toute inférence à partir du seul catalogue. Le fait qu’un fournisseur vende une sauvegarde ne signifie pas qu’elle est incluse dans une configuration donnée. Un client qui ne retrouve pas l’option, sa portée et son prix dans les documents signés peut découvrir après un incident qu’il avait seulement supposé sa présence.

La Service Specification devrait énumérer les systèmes et données couverts, les exclusions, la fréquence des copies, leur durée de conservation et leur mode de suppression. Elle devrait distinguer une copie locale d’une copie distante et documenter la séparation des domaines de panne. « Secondaire » doit devenir un lieu, une plateforme et une relation opérationnelle identifiables. Le chiffrement doit être relié à une gestion de clés, à des droits d’accès et à un processus de récupération.

Deux objectifs doivent être exprimés séparément: le point de reprise, ou RPO, limite la quantité de données susceptible d’être perdue; le temps de reprise, ou RTO, encadre le délai attendu pour remettre le service en état. Ni l’un ni l’autre ne peut être déduit du nombre de copies. Une réplication rapide peut aussi propager une suppression ou un chiffrement malveillant. Une archive immuable peut être intacte mais trop lente à restaurer. La bonne combinaison dépend de la charge et doit être testée.

Les preuves les plus utiles sont des rapports de restauration périodiques indiquant la date, l’échantillon, le volume, la durée, les erreurs et les mesures correctives. Pour une application complexe, restaurer un fichier ne suffit pas: il faut démontrer la cohérence entre données, machines virtuelles, secrets, DNS, règles réseau et dépendances externes. Le contrat devrait préciser qui déclenche l’exercice, qui valide le résultat et quelles conséquences suivent un échec.

Le corpus public ne permet pas d’affirmer qu’une restauration récente a réussi, qu’une copie est immuable ou qu’une capacité particulière est réservée. Il permet de formuler les contrôles à demander et d’identifier le risque contractuel: une responsabilité par défaut placée sur le client, sauf option expressément convenue. Pour un comité d’achat, cette phrase mérite plus d’attention qu’une promesse générale de sécurité des données.

Locaux, sécurité et preuves attribuées

Les pages de Datacenta décrivent une offre de colocation dans le Dorset, de l’hébergement et des applications gérés, des contrôles environnementaux, des onduleurs, de la surveillance et une capacité de support 24 heures sur 24 et 7 jours sur 7. La page de sécurité affirme que l’opérateur possède ses locaux d’hébergement, qu’il ne revend pas d’espace au sol ou en baie à d’autres hébergeurs et qu’il utilise des circuits acheminés par des voies diverses.

Ces éléments ont une valeur: ils définissent les affirmations que le fournisseur choisit de rendre publiques. Ils orientent une visite et permettent de demander des documents précis. Ils ne sont cependant pas des constatations indépendantes. Les pages ne donnent pas un inventaire daté de la capacité libre, les allocations de clients, les contrats de circuit, les résultats de test de générateurs ou d’onduleurs, ni le périmètre détaillé de certificats actuels.

La question de la propriété illustre la nécessité de relier le langage commercial à l’identité juridique. Si « l’opérateur » possède les locaux, quelle société en est propriétaire au registre foncier ou les occupe en vertu d’un bail ? Est-ce la même qui signe la Service Specification ? Si une autre société du groupe détient le bâtiment ou les équipements, quels accords garantissent leur mise à disposition pendant toute la durée du contrat client ? Le dossier consulté ne ferme pas ces points et ne justifie donc pas une attribution catégorique.

La diversité des circuits appelle le même traitement. Une visite peut montrer deux entrées, mais seule une documentation de chemin et des essais de basculement permettent d’évaluer les points communs. Le fournisseur devrait pouvoir présenter la date des derniers tests, le scénario utilisé, les services touchés, le délai observé et les anomalies restantes. Pour l’énergie et le refroidissement, l’acheteur devrait demander les capacités nominales, les charges actuelles pertinentes, les seuils d’alerte, les calendriers de maintenance et les comptes rendus d’essais sous charge.

La sécurité ne se réduit pas à une liste de contrôles. Il faut connaître le périmètre: sites, systèmes, personnes morales, dates et exclusions. Une certification attribuée à une société ou à un lieu ne doit pas être étendue par analogie à toute une marque. De même, une surveillance continue ne signifie pas nécessairement qu’un ingénieur habilité peut intervenir immédiatement sur chaque incident. Les horaires, les astreintes, les niveaux d’escalade et les responsabilités doivent être définis.

L’image associée à cet article est une illustration éditoriale réaliste. Elle n’est pas une photographie documentaire d’un site Datacenta et ne prouve aucun emplacement, itinéraire de circuit, niveau de capacité, événement de support, client, contrat, équipement ou droit de propriété. Cette distinction empêche qu’un élément visuel conçu pour accompagner l’analyse soit utilisé comme une dix-septième source implicite.

Maintenance et accès: le calendrier fait partie du service

Les conditions publiées autorisent des opérations de maintenance planifiées et des interventions d’urgence. Une telle clause est normale dans un environnement qui doit être réparé et mis à jour. Son effet opérationnel dépend cependant des détails: préavis, fréquence, durée, heures choisies, services exclus du calcul de disponibilité et procédure lorsque l’urgence rend le préavis impossible.

Un client devrait demander que les fenêtres prévues soient inscrites ou référencées dans la Service Specification. Il doit savoir si elles peuvent interrompre le réseau, l’alimentation, l’accès aux machines, la console distante ou les services de sauvegarde. Il doit aussi distinguer les travaux sans impact, les travaux à risque et les interruptions attendues. Lorsque plusieurs opérations se succèdent, la mesure doit permettre de voir leur effet cumulé plutôt que de les faire disparaître chacune derrière une exclusion générale.

L’accès physique est lui aussi contractuellement borné. Les conditions indiquent qu’il nécessite un préavis et qu’il s’exerce dans les limites des heures de support. Pour une entreprise qui place son propre serveur en colocation, ce point influence directement le temps de réparation. L’existence d’une assistance 24/7 annoncée ne dit pas automatiquement que le client peut entrer à toute heure, ni qu’une intervention à distance est incluse, ni sous quel délai elle commencera.

La spécification devrait définir les personnes autorisées, le processus d’identification, le préavis normal et urgent, les heures applicables, le coût d’une intervention, les outils disponibles et la chaîne d’escalade. Elle devrait prévoir le cas où le portail ou le contact habituel est indisponible. Si le service dépend d’une présence physique pour rétablir un équipement appartenant au client, le délai d’accès doit être cohérent avec l’objectif de reprise annoncé.

Les crédits de maintenance ou de disponibilité doivent enfin être lisibles. Il faut savoir si le client doit les réclamer, dans quel délai, avec quelles données et auprès de quelle société. Un crédit n’est utile que si l’événement peut être mesuré et attribué. Là encore, l’identité du débiteur, le calendrier technique et la preuve de performance se rejoignent dans le même document contractuel.

Sortie: tester la dépendance avant qu’elle ne devienne urgente

Les conditions prévoient qu’à la fin du contrat le client retire son serveur à ses frais dans un délai de sept jours. Elles décrivent ensuite des frais de stockage et une possibilité ultérieure de disposer d’un équipement non récupéré. Cette clause rend la réversibilité concrète: la sortie n’est pas seulement l’export abstrait de données, elle peut impliquer une machine physique, un rendez-vous, un transport et un délai court.

Un plan de sortie devrait être préparé pendant que la relation fonctionne. Il doit inventorier ce qui appartient au client, au fournisseur ou à un tiers; indiquer les numéros de série et les emplacements; préciser qui peut démonter, emballer et remettre le matériel; et prévoir la chaîne de garde. Le client doit savoir si des factures contestées, des règles de sécurité ou une indisponibilité de personnel peuvent retarder l’accès. La responsabilité du risque pendant le stockage et le transport doit être explicite.

Pour les services virtuels, l’inventaire est différent mais tout aussi exigeant. Il faut organiser l’export des machines virtuelles, volumes, instantanés, configurations, journaux et clés. Les formats, débits et coûts d’extraction doivent être testés. Une copie récupérée n’est utile que si elle peut être restaurée ailleurs. Les dépendances DNS, les certificats, les listes d’autorisation, les adresses IP et les règles de pare-feu doivent être cartographiés avant la bascule.

Les ressources réseau méritent une attention particulière. Le fait que le fournisseur exploite AS196745 ne signifie pas que le client peut conserver une adresse après son départ. La Service Specification devrait identifier les adresses dépendantes du fournisseur, les délais de renumérotation, le support offert pour modifier le DNS et les éventuelles contraintes sur l’annonce d’un espace appartenant au client. Une migration mal préparée peut être techniquement complète mais rester invisible ou inaccessible.

La suppression finale doit également être prouvée. Le contrat devrait décrire le calendrier de fermeture, la révocation des accès, le traitement des sauvegardes résiduelles et l’attestation de destruction lorsque celle-ci est promise. Il doit répartir les tâches entre les équipes et désigner la société qui répond de leur exécution. Le délai de sept jours pour le matériel montre pourquoi ces questions ne doivent pas attendre la notification de résiliation.

Une répétition de sortie, même partielle, est le meilleur moyen de découvrir les dépendances cachées. Exporter un échantillon, restaurer une machine ailleurs, mesurer le temps nécessaire et vérifier les contacts transforme une clause en capacité démontrée. Le coût de cet exercice doit être comparé au coût d’une dépendance non testée, surtout lorsque l’hébergement soutient un service difficile à interrompre.

Une matrice de diligence raisonnable adaptée au dossier

La chaîne de preuve peut être organisée en matrice, avec pour chaque affirmation une source publique, un document privé attendu, un responsable et une date de vérification. Cette structure évite qu’une information exacte dans un domaine soit utilisée pour remplir une case différente. Elle permet aussi de suivre les changements de nom ou d’architecture sans recommencer toute l’analyse.

Identité contractuelle. Le dossier doit contenir le certificat ou l’extrait courant de la partie au contrat, son numéro de société, son adresse de notification et ses signataires autorisés. Le devis, le bon de commande, la facture, les conditions et la Service Specification doivent être rapprochés. Toute différence entre X-Net (Services) Ltd, Datacenta Hosting Ltd, Datacenta Hosting (Scotland) Ltd et DATACENTA HOSTING LTD doit recevoir une explication écrite. Si une entité agit comme agent, propriétaire d’actif ou prestataire d’une autre, l’accord correspondant doit être identifié.

Contrôle des ressources réseau. Les objets AS196745, DATACENTA-AS et ORG-DHL11-RIPE fournissent le point de départ. L’acheteur devrait demander qui détient les comptes administratifs, qui peut modifier les objets, qui autorise les annonces et quel mécanisme assure la continuité si l’entité contractante change. Les préfixes utilisés par le client, leur origine et leur plan de renumérotation doivent être consignés. Les observations de RIPEstat peuvent servir de contrôle périodique, sans devenir une promesse de performance.

Sites et équipements. La liste des lieux de production, de sauvegarde et de reprise doit être exacte, avec la fonction de chacun. Pour chaque site, la matrice devrait indiquer le propriétaire ou bailleur pertinent, l’entité qui exploite, les équipements essentiels, les dépendances d’énergie et de refroidissement, ainsi que les dernières dates de test. Les affirmations publiques de propriété ou de diversité doivent être confirmées par des pièces actuelles adaptées au niveau de risque, et non simplement recopiées.

Connectivité et capacité. Les trois voisinages externes observés sont une entrée de contrôle. Le document privé doit ajouter les opérateurs, les circuits, les ports, les chemins physiques, les capacités engagées et disponibles, les mécanismes de basculement et les résultats d’essais. La capacité réservée au client doit être distinguée de la capacité totale. Les limites de protection, les contacts d’urgence et les délais d’augmentation doivent être connus avant une pointe ou une attaque.

Sauvegarde et reprise. La matrice doit nommer les charges protégées, les copies, les sites, les durées de conservation, l’immutabilité éventuelle, les RPO et RTO, les tests et les personnes chargées de valider. Elle doit indiquer clairement ce qui reste à la charge du client. Une ligne « sauvegarde disponible » ne suffit pas: chaque charge critique doit avoir une architecture et une preuve de restauration.

Exploitation et support. Les heures de couverture, les rôles d’astreinte, les niveaux de priorité, les temps de réponse et de résolution, les canaux de secours et les procédures d’escalade doivent être alignés sur la criticité. L’accès physique, la télémaintenance et les changements urgents doivent avoir leurs propres règles. Les rapports d’incident devraient montrer comment les engagements sont mesurés et comment les actions correctives sont suivies.

Maintenance et remèdes. Les exclusions de disponibilité, les fenêtres, les préavis et les urgences doivent être suffisamment bornés pour ne pas vider l’objectif de service de son sens. Les crédits, plafonds et formalités de réclamation doivent être compris. Pour les pertes que les crédits ne couvrent pas, l’acheteur doit évaluer les assurances, les limites de responsabilité et ses propres mesures de continuité.

Réversibilité. Le plan doit couvrir les données, les machines virtuelles, les DNS, les adresses, les secrets, les configurations et le matériel physique. Il doit donner un calendrier compatible avec les sept jours prévus pour le retrait d’un serveur, préciser les coûts et organiser la suppression finale. Une date de répétition et un propriétaire de plan rendent cette exigence exploitable.

Cette matrice n’a pas pour but de produire une certitude absolue. Elle rend visibles les hypothèses et empêche leur glissement. Une information peut être marquée « confirmée », « attribuée au fournisseur », « observée à une date », « à vérifier dans le contrat » ou « non établie ». Le niveau de preuve exigé peut varier selon la criticité, mais la catégorie ne doit jamais être dissimulée.

Ce que l’acheteur paie réellement

L’économie d’un service d’hébergement ne se résume pas au prix mensuel. Le client paie pour un ensemble de droits sur des ressources partagées ou réservées, une priorité d’intervention, une capacité de reprise et une option de sortie. Lorsque ces droits ne sont pas spécifiés, deux offres portant le même nom peuvent avoir des profils économiques très différents.

Une bande passante non garantie coûte moins qu’un débit réservé, mais transfère le risque de congestion vers le client. Une sauvegarde proposée en option réduit le prix de base, mais laisse au client le coût de concevoir et d’exploiter sa propre protection s’il ne l’achète pas. Un support disponible en permanence peut ne pas inclure le même volume d’intervention qu’une astreinte avec délai contractuel. Des fenêtres de maintenance largement exclues peuvent préserver le fournisseur de crédits tout en laissant au client le coût d’une interruption.

La structure juridique fait aussi partie de cette économie. Si les actifs, les équipes et le contrat sont répartis entre plusieurs entités, la continuité dépend des accords qui les relient. Cette organisation peut être efficace, mais l’acheteur doit savoir quelles ressources sont à la disposition du cocontractant et quels recours subsistent en cas de changement. Le risque ne vient pas du nombre de sociétés en lui-même; il vient d’une dépendance essentielle dont le fondement n’est pas documenté.

Le coût de sortie complète enfin le prix d’entrée. Sept jours pour retirer un serveur, des frais de stockage possibles, un export volumineux ou une renumérotation urgente peuvent rendre une migration chère même sans pénalité explicite. Une offre moins coûteuse à l’exploitation peut devenir plus chère sur son cycle de vie si la réversibilité n’a pas été testée. L’analyse commerciale devrait donc chiffrer les options nécessaires pour obtenir le niveau voulu, les contrôles internes qui restent au client et le coût d’un scénario de départ crédible.

Une conclusion fondée sur les limites de chaque source

Le dossier Datacenta ne conduit ni à nier l’existence du réseau, ni à accepter sans examen une identité unique. AS196745 est actif et visible selon les sources consultées. Son objet de registre rattache DATACENTA-AS à ORG-DHL11-RIPE, lequel porte le nom Datacenta Hosting Ltd et le numéro SC208801. Les observations récentes montrent des préfixes IPv4 et IPv6 propagés et trois voisinages externes correspondant à la politique déclarée. Ce sont des faits positifs, précis et utiles.

Ils s’arrêtent avant le contrat. Companies House montre des noms et des dates qui imposent de distinguer SC208801, 15255267 et 03290605. Les pages de X-Net et les conditions de services gérés placent X-Net (Services) Ltd dans le rôle de fournisseur opérant sous la marque Datacenta Hosting. Les pages Datacenta décrivent encore des capacités techniques et des choix d’offre. Aucune de ces couches ne peut être fusionnée sans documents complémentaires.

La décision d’achat devrait donc reposer sur une correspondance vérifiée: personne morale, ressource technique, site, service et obligation. La Service Specification est le lieu naturel de cette correspondance, à condition qu’elle soit signée, incorporée au contrat, suffisamment précise et cohérente avec l’architecture déployée. Elle doit transformer les mots « connectivité », « sauvegarde », « sécurité » et « support » en quantités, délais, responsabilités, preuves et remèdes.

Cette approche ne demande pas aux données publiques d’accomplir une tâche pour laquelle elles n’ont pas été conçues. Elle utilise RIPE, RIPEstat, PeeringDB, Companies House et les pages du fournisseur selon leur fonction propre. Elle accepte qu’une observation ait une date, qu’une déclaration soit attribuée, qu’un registre puisse conserver un libellé et qu’un contrat générique renvoie à une annexe. La rigueur vient de la séparation, puis du rapprochement documenté.

Pour le client, la question finale n’est donc pas de savoir si une route est visible. Elle est de savoir si la route, le circuit, le site, la sauvegarde, l’équipe et la responsabilité juridique aboutissent tous à une promesse exécutoire adaptée à sa charge. Tant que cette chaîne n’est pas fermée, la visibilité d’AS196745 reste une preuve nécessaire, mais pas la preuve du service acheté.

Sources

Companies House, dossier 03290605: https://find-and-update.company-information.service.gov.uk/company/03290605
Companies House, dossier 15255267: https://find-and-update.company-information.service.gov.uk/company/15255267
Companies House, historique des dépôts de 15255267: https://find-and-update.company-information.service.gov.uk/company/15255267/filing-history
Companies House, dossier SC208801: https://find-and-update.company-information.service.gov.uk/company/SC208801
RIPE RDAP, AS196745: https://rdap.db.ripe.net/autnum/196745
RIPE Database, objet aut-num AS196745: https://rest.db.ripe.net/ripe/aut-num/AS196745.json?unfiltered
RIPE Database, objet ORG-DHL11-RIPE: https://rest.db.ripe.net/ripe/organisation/ORG-DHL11-RIPE.json?unfiltered
RIPEstat, voisinages observés d’AS196745: https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS196745
RIPEstat, état du routage d’AS196745: https://stat.ripe.net/data/routing-status/data.json?resource=AS196745
Datacenta, sauvegarde et restauration en ligne: https://www.datacenta.net/Online_Backup/Online_Backup_and_Restore.aspx
Datacenta, connectivité réseau: https://www.datacenta.net/Products_Services/Network_Connectivity.aspx
Datacenta, sécurité: https://www.datacenta.net/Security.aspx
Datacenta, solutions d’hébergement sécurisé: https://www.datacenta.net/secure_hosting/hosting_solutions.aspx
PeeringDB, fiche AS196745: https://www.peeringdb.com/asn/196745
X-Net, contact: https://www.x-net.co.uk/contact-us/
X-Net, conditions générales: https://www.x-net.co.uk/terms-and-conditions/