Le cloud autrichien est une chaîne de responsabilité: où la promesse de localité de myDataCenter.at s'arrête réellement

Résumé

• L'identité juridique et opérationnelle est prouvable: myDC Cloud Services GmbH est la société autrichienne derrière la marque myDataCenter.at, et non une simple étiquette pour un groupe d'hébergement plus large.
• Son offre cloud combine des machines virtuelles KVM, un stockage basé sur Ceph, un tableau de bord client, une sauvegarde optionnelle et une revendication de centre de données à Vienne; chaque composant réduit un type de dépendance tout en créant une autre frontière opérationnelle que les acheteurs doivent inspecter.
• La vitrine publique rend les petits déploiements lisibles, mais ce sont les conditions générales — et non le prix mensuel affiché — qui définissent l'économie réelle via la durée du contrat, le préavis, les ajustements liés à l'énergie, la portée du support et les recours limités.
• La localité est le principal différenciateur de myDC et sa revendication la plus difficile à étayer. Les preuves publiques confirment une empreinte opérationnelle autrichienne, mais ne divulguent pas suffisamment l'identité de l'installation, les domaines de défaillance du stockage, l'emplacement des réplicas, les niveaux de service ou la portée des certificats pour qu'un acheteur sérieux s'arrête à « données en Autriche ».

Suivez un clic à travers le service

Imaginez une société de logiciels autrichienne commandant un nouveau serveur de production. Un administrateur entre dans le tableau de bord myDataCenter.at, choisit « Platform Vienna », sélectionne des cœurs de processeur, de la mémoire et du stockage, attache un réseau privé, fournit une clé publique SSH et paie. La machine apparaît assez rapidement pour que la transaction semble un acte unique. Ce n'est pas le cas. Ce clic traverse une chaîne de responsabilité.

Le premier maillon est juridique. Le client contracte avec myDC Cloud Services GmbH, une société immatriculée à Krems, non pas avec un « cloud autrichien » générique et, selon les preuves disponibles, pas avec une grande maison mère internationale. Le deuxième maillon est le plan de contrôle du service: la boutique de myDC, le système de comptes, le workflow de provisionnement, les factures, les tickets et l'affichage des statuts.

Le troisième est technique: une machine virtuelle fonctionnant sous KVM, avec ses disques placés sur un système de stockage Ceph et une logique de haute disponibilité destinée à redémarrer les charges de travail en cas de défaillance d'un nœud de calcul. Le quatrième est physique: alimentation, refroidissement, protection incendie, contrôle d'accès et fibre dans une installation à Vienne. Le cinquième est externe: les réseaux, opérateurs, communautés logicielles, fournisseurs de paiement et partenaires d'implémentation spécialisés sur lesquels un petit opérateur s'appuie inévitablement.

La valeur de myDC n'est donc pas d'abolir la dépendance. Aucun cloud ne le fait. Elle réside dans le fait qu'elle peut transformer un ensemble tentaculaire de dépendances en un service plus petit, géographiquement délimité et humainement navigable. C'est un produit utile pour une organisation qui considère la tutelle autrichienne, le support en allemand ou l'accès à un opérateur local responsable plus importants qu'un catalogue énorme de services gérés propriétaires. Mais cela ne fonctionne que si les limites sont décrites précisément.

Le matériel public de l'entreprise est inhabituellement concret par endroits. Sapage cloudidentifie KVM, Ceph, les processeurs AMD EPYC, les plafonds réseau internes et externes, les snapshots, l'accès de secours et la sauvegarde optionnelle. Songuide de commandeexplique ce qu'un client doit fournir. Sesconditions généralesprécisent les heures de support, les délais de préavis, le traitement des maintenances, les recours et la logique d'ajustement des prix. Ces documents permettent une évaluation plus sérieuse que le slogan habituel du cloud souverain.

Ils révèlent également la tension centrale. myDC commercialise l'immédiateté et la flexibilité à l'interface, tandis que ses fondations juridiques et physiques sont nécessairement plus lentes et plus fixes. Une machine virtuelle peut être redimensionnée ou supprimée dans un tableau de bord; le contrat derrière elle peut avoir une durée minimale et un préavis de trois mois. Un cluster Ceph peut redistribuer les données après une défaillance de disque; cela ne dit rien en soi sur le fait que tous les réplicas partagent une même salle, un même domaine électrique ou un même risque métropolitain.

Un tableau de bord peut afficher des voyants verts; les conditions générales excluent la maintenance de certains recours et ne fournissent pas d'historique public détaillé des incidents. L'unité d'analyse utile n'est pas le serveur. C'est la chaîne.

La GmbH derrière le domaine

Le pont d'identité est suffisamment solide pour soutenir la frontière de l'article. LesImpressum et conditions généralesdu fournisseur nommentmyDC Cloud Services GmbHet indiquent explicitement qu'elle fournit des services sous la marquemyDataCenter.at. Ils donnent l'adresse enregistrée au Dr.-Franz-Wilhelm-Straße 2 à 3500 Krems an der Donau, nomment Robert Siedl comme directeur général, et fournissent le numéro de registre des sociétés FN 533177i et le numéro de TVA ATU75570758. La même page précise que l'entreprise fournit des services d'infrastructure, de plateforme et de logiciels depuis un centre de données à Vienne en utilisant son propre matériel, les données des clients étant stockées en Autriche.

Une inscription publique indépendante de laChambre économique fédérale autrichiennerelie le même nom juridique, marque commerciale, domaine, adresse, numéro de registre et directeur général. Elle enregistre l'autorisation commerciale pour les services de technologies de l'information depuis le 19 juin 2020. Cette vérification croisée est importante. Elle écarte l'erreur facile de traiter myDataCenter.at comme une page produit sans entité contractante claire, ou de substituer silencieusement une installation ou un partenaire de service mieux connu à l'entreprise évaluée.

Le proprehistorique de l'entreprisede l'opérateur ajoute une lignée qui est pertinente mais doit être attribuée comme un récit d'entreprise. Il indique que les fondateurs ont repris une activité cloud existante de Siedl Networks via une vente d'actifs en 2019 et ont créé une société distincte autour de la marque myDataCenter.at. La chronologie décrit des travaux d'infrastructure antérieurs datant de 2015, un cluster plus grand et une boutique en ligne en 2020, l'auto-provisionnement client en 2022, les services de monitoring et Zimbra en 2023, la facturation intégrée en 2024, et un programme partenaire en 2025. C'est une preuve de continuité des connaissances de service, mais pas une preuve que chaque déploiement, client ou revendication opérationnelle antérieure à 2020 appartient à la GmbH actuelle.

Cette distinction devient importante lorsque le matériel de cas public présente les deux noms. Unesuccess story SchoolFoxdécrit les ressources myDataCenter tout en attribuant le conseil, la migration, l'implémentation et le support opérationnel continu à Siedl Networks. Une compilation de 2024 duWKO Open Source Experts Grouprepublie le cas. Robert Siedl apparaît dans l'orbite des deux entreprises, mais les sources examinées n'établissent pas de lien de propriété actuel qui justifierait leur fusion. La lecture défendable est plus étroite: myDC est le sujet contractuel et d'infrastructure cloud; Siedl Networks est un partenaire d'implémentation et de support nommé dans au moins un déploiement documenté.

Cette exactitude n'est pas du pédantisme juridique. Elle indique à un acheteur où adresser une demande de diligence raisonnable, quelle partie doit apparaître dans l'accord de traitement des données, qui est responsable de la couche d'infrastructure virtuelle, et où commencent les devoirs d'un intégrateur de systèmes. « Local » n'est utile que lorsque la responsabilité a un nom et un numéro de registre.

Ce que Platform Vienna donne réellement à un client

La gamme cloud actuelle de myDC est délibérément réduite. « Platform Vienna » est le bloc de construction cloud privé plus complet; « Server Vienna » est l'offre de serveur virtuel plus simple. Unavis de restructuration de produit publié en août 2025indique que ces offres ont remplacé les anciens packages fixes afin que le CPU, la mémoire, le stockage SSD ou NVMe, la capacité réseau et les modules complémentaires puissent être sélectionnés plus librement. Les configurations existantes devaient se poursuivre sans changement.

Lacomparaison actuelleindique que les deux produits utilisent KVM plutôt que des conteneurs de système d'exploitation, fonctionnent sur des processeurs AMD EPYC et stockent les disques virtuels dans Ceph. Le fournisseur décrit les machines virtuelles comme hautement disponibles. Les clients reçoivent un accès root via SSH ou RDP et peuvent utiliser des snapshots, des tâches, un système de secours et un pare-feu de base via le tableau de bord. Platform Vienna ajoute des réseaux privés et annonce une connectivité interne jusqu'à 10 Gbit/s; la connectivité externe est listée jusqu'à 1 Gbit/s. Un IPv6 /64 est disponible. « Jusqu'à » est un plafond, pas un niveau de débit garanti, et la page publique ne divulgue pas les ratios de contention, les limites de paquets par seconde ou un niveau de service réseau.

La boutique rend l'abstraction commerciale tangible. Le 17 juillet 2026, lavitrine Platform Viennaaffichait un prix mensuel de départ de 46,60 €, tandis que Server Vienna commençait à 8,70 €; les conditions générales précisent que les prix commerciaux indiqués s'entendent hors TVA. Une vue de configuration offrait des cœurs, de la mémoire, du stockage, de la connectivité, des adresses IPv4, des VLAN et une sauvegarde avec des prix individuels. Ces observations sont un instantané daté de la vitrine plutôt qu'un tarif permanent. Elles sont utiles car elles montrent l'unité de vente: myDC ne présente pas un environnement hyperscale à consommation mesurée avec des centaines de services. Il vend une infrastructure virtuelle configurable avec des composants mensuels visibles.

La commande n'est pas entièrement automatique. Selon leguide de la base de connaissancesde l'entreprise, un client choisit une facturation mensuelle, trimestrielle ou annuelle, puis paie par crédit de compte, virement bancaire ou PayPal. Le crédit ou PayPal peuvent déclencher un provisionnement immédiat là où le produit le permet; l'approvisionnement automatique après un virement bancaire nécessite une vérification du compte. L'acheteur fournit un nom d'hôte, un modèle de système d'exploitation et une clé publique SSH. myDC indique qu'il évite délibérément les mots de passe générés ou par défaut. Les clients Platform sélectionnent ensuite des processeurs supplémentaires, de la mémoire, un support de disque de démarrage, des adresses publiques, des réseaux privés et un stockage de sauvegarde.

Ce workflow situe la ligne entre infrastructure et administration. myDC peut instancier une machine virtuelle, attacher des réseaux et fournir un chemin de secours. Le client reste responsable du système d'exploitation invité, des applications, de la conception des identités, des correctifs, des secrets et d'une grande partie de la politique de pare-feu, sauf s'il achète une gestion supplémentaire. La base de connaissances publique contient des instructions pour OPNsense, pfSense, MikroTik et des tâches courantes Linux ou Windows, ce qui est une preuve utile du travail que les clients rencontrent réellement.

C'est aussi la preuve que le « cloud » n'élimine pas l'administration système.

Les achats devraient distinguer les deux familles de produits plus nettement que ne le fait le tableau marketing. Un acheteur devrait demander si une allocation CPU particulière est dédiée ou partagée, comment le surengagement est géré, quelles performances de stockage sont garanties, si la migration à chaud ou uniquement la reprise après redémarrage est proposée, et si les réseaux privés Platform s'étendent sur plus d'un domaine de défaillance physique. Aucune de ces réponses ne doit être devinée à partir de la présence de composants open source familiers.

KVM et Ceph déplacent la frontière de l'enfermement propriétaire

L'architecture utilise des blocs de construction reconnaissables et non propriétaires. C'est significatif. KVM est le mécanisme de virtualisation grand public du noyau Linux, et myDC indique que son service fournit des machines entièrement virtualisées plutôt que des conteneurs. Ceph est un système de stockage distribué conçu pour placer et répliquer les données sur des daemons de stockage d'objets. Ladocumentation de l'architecture Cephexplique que les moniteurs maintiennent la carte du cluster, les OSD stockent et répliquent les objets, et l'algorithme CRUSH mappe les données aux domaines de défaillance sans goulot d'étranglement de recherche centralisée.

Ces composants peuvent réduire une forme de coût de changement. Un client n'écrit pas une application directement contre une API de base de données unique ou un service d'événements juste pour exécuter une machine virtuelle ordinaire. Linux, Windows, un pare-feu virtuel ou un serveur de base de données peuvent en principe fonctionner sur une autre plateforme basée sur KVM. L'engagement public de myDC en faveur des standards ouverts et du support de migration renforce cette direction. Mais « utilise l'open source » et « a un chemin de sortie testé » ne sont pas synonymes.

Le fournisseur ne publie pas les formats d'image disque disponibles pour l'exportation, les mécanismes ou le coût d'une exportation de volume complet, les allocations de bande passante pendant la migration, l'exportation de configuration pour les réseaux et les règles de pare-feu, ou le traitement des snapshots. Il ne publie pas d'interface infrastructure-as-code sur la page cloud. Une opération de tableau de bord qui crée un serveur peut donc rester une dépendance manuelle du plan de contrôle même lorsque la charge de travail elle-même est portable.

Avant de se fier à un faible enfermement, un acheteur devrait demander à myDC d'exporter une machine représentative et ses paramètres réseau, de les ailleurs, de démarrer la copie, et d'enregistrer le temps écoulé, le coût de transfert de données et les modifications nécessaires.

Ceph illustre également pourquoi un nom de produit n'est pas une assurance. Ceph peut répliquer des objets sur plusieurs hôtes et peut encoder une hiérarchie de périphériques, racks, rangées et salles dans une carte CRUSH. Sa propre documentation avertit que la disponibilité dépend du quorum des moniteurs, des paramètres de réplication et de la configuration du domaine de défaillance; elle recommande trois copies pour la haute disponibilité plutôt que de traiter toute installation Ceph comme automatiquement résiliente. Le matériel public de myDC ne divulgue pas son nombre de moniteurs, de nœuds OSD, le nombre de réplicas,min_size, les règles de placement, la distribution des racks, la configuration du chiffrement, la capacité utilisable ou la marge de reconstruction.

Cette absence ne montre pas un cluster faible. Elle montre que la revendication reste au niveau de la description du produit. La question d'approvisionnement correcte n'est pas « Utilisez-vous Ceph? » mais « Montrez comment le pool de ce client est placé, quelles défaillances simultanées il tolère, et ce qu'il advient de la latence et du temps de récupération pendant une reconstruction. » Si les réplicas se trouvent sur des disques différents dans des hôtes différents mais partagent une même salle et une même alimentation, le système est résilient à une défaillance de disque ou d'hôte, mais pas à une défaillance de site.

La même discipline s'applique à la haute disponibilité. L'avis produit 2025 de myDC explique que lorsqu'un hôte tombe en panne, une machine virtuelle affectée peut démarrer automatiquement sur un autre matériel. C'est une récupération d'infrastructure utile. Ce n'est pas une disponibilité continue de l'application: l'invité doit redémarrer, les applications doivent récupérer, et tout état en vol peut être perdu. Un client nécessitant une interruption quasi nulle a encore besoin de clustering d'application, d'état répliqué, de contrôles de santé et de basculement de trafic au-dessus de la couche de machine virtuelle.

« HA » doit donc être traduit en une distribution de temps de récupération mesurée pour la charge de travail, et non laissé comme un badge.

Il y a une deuxième question architecturale dans la différence entre Platform Vienna et Server Vienna. Les réseaux privés jusqu'à 10 Gbit/s peuvent rendre Platform adapté aux systèmes multi-niveaux, au trafic de stockage ou aux liaisons hybrides. Server Vienna semble destiné à des instances plus simples et connectées publiquement. Un acheteur qui commence sur le serveur moins cher et a besoin plus tard d'une segmentation privée doit vérifier si la conversion est possible sans reconstruction. La simplicité du produit est précieuse, mais seulement si le chemin de mise à niveau est explicite.

Le tableau de bord est à la fois commodité et concentration

myDC a investi pour rendre un petit parc d'infrastructure contrôlable via une interface client unique. Uneannonce du tableau de bord de mai 2025indique que les clients peuvent commander, gérer, modifier et annuler des services; voir l'état du réseau; créer des tickets de support; lire la documentation; et gérer les factures en un seul endroit. Elle indique également que la connexion prend en charge l'authentification à deux facteurs. Uneversion de janvier 2024a introduit la surveillance des services et une vue de l'état du réseau.

Pour une petite équipe informatique, cette consolidation fait partie du produit. L'alternative n'est souvent pas une opération hyperscale parfaitement automatisée mais un mélange de portails d'hébergement, de modifications par e-mail, de feuilles de calcul et d'appels à plusieurs fournisseurs. Un tableau de bord local qui relie commande, état technique et support peut réduire les coûts de coordination.

Il concentre également l'autorité. Un compte capable d'ajouter, de modifier ou de supprimer des services—et de voir les factures et les informations de support—est une surface de contrôle matérielle. L'authentification à deux facteurs est donc une base de référence, pas une histoire de sécurité complète.

Les acheteurs doivent vérifier si elle peut être appliquée pour chaque compte, quels facteurs sont pris en charge, si les rôles séparent la facturation de l'administration, comment les identifiants API ou de service sont limités, comment les sessions et la récupération sont gérées, si les événements administratifs sont exportables, et comment l'accès du personnel du fournisseur est approuvé et journalisé.

Les pages publiques ne décrivent pas d'API client, d'outil en ligne de commande, de fournisseur Terraform, d'intégration d'authentification unique, de modèle d'accès basé sur les rôles ou d'exportation d'audit immuable. Peut-être que certains sont disponibles sur demande; le pack de preuves ne les établit pas. Leur absence dans la documentation publique importe le plus pour les clients qui veulent une infrastructure reproductible et le moins pour ceux qui achètent délibérément un modèle opérationnel personnel assisté par tickets.

L'état du service du tableau de bord nécessite également une interprétation. Il peut montrer ce que myDC choisit de surveiller et d'exposer, ce qui est mieux qu'aucune surface d'état. Il ne peut pas établir par lui-même la santé de bout en bout de l'application, la conformité historique avec un niveau de service ou un enregistrement complet des incidents. Un client sérieux devrait connecter ses propres sondes synthétiques depuis l'extérieur du réseau du fournisseur et les concilier avec le tableau de bord après chaque événement matériel.

La salle à Vienne est une dépendance, pas une note de bas de page

myDC indique que son matériel et les données des clients sont en Autriche. Sadescription de l'installationsitue l'opération à Vienne et décrit une alimentation redondante, des onduleurs et des générateurs, le refroidissement, la détection et l'extinction d'incendie, l'accès biométrique, la vidéosurveillance, les patrouilles et l'électricité renouvelable. Elle indique que plusieurs chemins de fibre noire atteignent deux nœuds de réseau autrichiens importants, que les sites sont reliés par un anneau de fibre, et que le centre de données est certifié ISO 27001. La même page annonce une disponibilité « jusqu'à » plus de 99,99 %.

Ce sont des affirmations de l'entreprise. La page publique ne nomme pas l'installation, n'identifie pas le titulaire du certificat, ne donne pas de numéro ou de périmètre de certificat, ne définit pas quel service reçoit quel niveau de disponibilité, et ne situe pas les sites supplémentaires et les réplicas de sauvegarde. Cela laisse un écart de preuve important entre « Vienne » et un modèle de résilience utilisable.

Les preuves réseau publiques réduisent l'environnement d'exploitation probable sans combler l'écart. Le 17 juillet 2026, le tableau de bord myDataCenter résolvait un bloc d'adresses identifié par les données d'enregistrement RIPE comme SIEDL-NETWORKS, tandis qu'un nom d'hôte Zimbra mydc.at résolvait une plage routée par Nessus.La vue actuelle de BGP.tools sur AS47692identifie le système autonome comme Nessus GmbH et montre plusieurs réseaux amont. Par ailleurs,Nessus nomme « MyDC Cloud Services » comme clientet exploite plusieurs centres de données à Vienne.

Il s'agit de preuves externes ponctuelles d'une relation réseau ou d'installation matérielle. Ce n'est pas la preuve que chaque machine virtuelle myDC utilise une adresse, un opérateur ou un bâtiment particulier. Le DNS ne peut représenter qu'un service de plan de contrôle; les adresses et les routes changent; un client peut utiliser ses propres préfixes ou liaisons. Les preuves soutiennent une question d'approvisionnement, pas une déclaration architecturale.

Le libellé de la description de l'installation de myDC ressemble étroitement à la description publique deNDC1de Nessus, y compris les routes de fibre noire vers deux nœuds autrichiens et les contrôles de sécurité physique. L'aperçu de l'hébergementde Nessus indique que ses installations à Vienne sont neutres en termes d'opérateurs et certifiées ISO 27001. Pourtant, myDC ne nomme pas NDC1 sur sa propre page, et Nessus décrit désormais trois installations avec des spécifications différentes. Il serait hasardeux de déduire le site exact, le rack, le périmètre du certificat ou l'emplacement d'un second réplica à partir d'un libellé similaire.

Pourquoi la distinction importe-t-elle si tous les candidats sont à Vienne? Parce que « Autriche uniquement » est une frontière juridictionnelle, pas une frontière de reprise après sinistre. Deux racks dans un même bâtiment, deux bâtiments sur un même campus et deux sites métropolitains sur des domaines électriques et d'inondation différents offrent une résilience différente. Un anneau de fibre peut encore avoir des conduits communs ou des points d'agrégation. Plusieurs opérateurs peuvent encore partager un système autonome ou un échange.

Un acheteur doit obtenir une carte des dépendances physiques et logiques sous confidentialité si nécessaire: sites primaire et de secours, domaines électriques, salles de rencontre, responsabilité d'accès, transit IP, chemin DDoS, hébergement du plan de contrôle, surveillance, et chaque sous-traitant qui peut accéder aux données des clients.

Le réseau détermine également ce que la localité ne peut pas résoudre. Le trafic entre un utilisateur autrichien et une charge de travail viennoise peut rester domestique, mais seule une mesure de route peut montrer le chemin réel à un moment donné. Le trafic des utilisateurs mondiaux traversera des réseaux étrangers. Les défaillances amont, les fuites de route et les attaques par déni de service ne respectent pas une frontière nationale. Les conditions de myDC reconnaissent que la connectivité vers d'autres réseaux ne peut être garantie et permettent la déconnexion temporaire d'un service attaqué lorsqu'il menace d'autres services.

Le produit DDoS optionnel dans la vitrine fait donc partie de la conception du service, pas un ajout décoratif pour les systèmes exposés à Internet.

La localité a encore de la valeur. Elle peut simplifier les visites de site, la juridiction contractuelle, la latence pour les utilisateurs autrichiens, les explications sur l'emplacement des données et la communication pendant une panne. Mais elle est plus forte lorsqu'elle est présentée comme un choix opérationnel délimité—sites nommés, sous-traitants nommés, routes mesurées et reprise testée—pas comme l'affirmation que la géographie supprime le risque d'infrastructure.

La sauvegarde crée une deuxième carte de souveraineté

myDC expose deux idées de sauvegarde liées mais distinctes. La sauvegarde de machine virtuelle peut être ajoutée à Platform Vienna; l'avis de restructuration de 2025 indique que les sauvegardes sont répliquées sur deux sites et peuvent être restaurées via le tableau de bord. Par ailleurs, l'entreprise vend unservice de sauvegarde Proxmox gérée (Managed Proxmox Backup Service)pour protéger l'environnement Proxmox du client. La vitrine affichait un prix de départ de 25 € par mois le 17 juillet 2026 et décrivait un stockage évolutif, des jobs push ou pull, la restauration de machines virtuelles, la sauvegarde de fichiers pour Linux, la vérification et le chiffrement optionnel.

Les guides d'implémentation sont plus révélateurs que la fiche produit. Pour que myDC tire depuis un serveur de sauvegarde Proxmox sur site, le client a besoin d'une adresse publique statique et doit rendre le port 8007 accessible depuis myDataCenter. Leguide de configuration du tableau de bordrecommande fortement de restreindre l'accès à l'adresse publique de myDC. Il indique au client de créer un compte local avec au moins le rôleDatastoreReader, d'échanger une empreinte de datastore, de définir l'emplacement distant et de planifier une synchronisation par pull. La rétention peut être modifiée; les sauvegardes individuelles peuvent être protégées contre la suppression par rétention ordinaire.

L'intégration inverse est également possible. Leguide du serveur localexplique comment un client utilise le nom d'hôte, le compte, le mot de passe et l'empreinte exposés dans le tableau de bord pour connecter le datastore myDC en tant que distant. Unguide de vérificationdistinct indique aux clients de planifier des contrôles d'intégrité et d'inspecter les journaux.

Il s'agit d'un workflow opérationnel crédible car il expose les responsabilités. Le client fournit une connectivité stable, limite les adresses sources, crée des identifiants de moindre privilège, vérifie l'empreinte du point de terminaison, choisit les plannings et examine les journaux. myDC fournit le stockage distant et l'interface de contrôle. Ladocumentation en amont du serveur de sauvegarde Proxmoxconfirme que le logiciel prend en charge le contrôle d'accès, l'authentification à deux facteurs, le chiffrement côté client, la vérification, la rétention, la synchronisation à distance et les opérations de restauration. Elle n'établit pas lesquels de ces contrôles myDC active par défaut ou gère pour un client particulier.

La sauvegarde modifie la carte de souveraineté car une copie a son propre emplacement, ses propres clés de chiffrement, identifiants, règles de rétention et exigences de sortie. « Répliqué sur deux sites » ne suffit pas pour l'approvisionnement.

L'acheteur doit savoir si les deux sites se trouvent dans des bâtiments et domaines électriques distincts; si le plan de sauvegarde partage l'identité, le réseau et le personnel avec la production; qui détient les clés de chiffrement; si les snapshots protégés sont immuables face à un administrateur compromis; quel délai de suppression s'applique; à quelle fréquence les restaurations complètes sont testées; et quel temps de récupération est réaliste pour le plus grand ensemble de données sur la bande passante achetée.

Il y a aussi un compromis de concentration. Envoyer une sauvegarde Proxmox sur site vers myDC crée une séparation géographique utile. Sauvegarder une machine virtuelle myDC dans un référentiel qui partage le même fournisseur, la même ville, le même compte de contrôle ou le même réseau peut toujours protéger contre la suppression logique et la défaillance de l'hôte, mais peut être plus faible contre les événements à l'échelle du fournisseur ou de la métropole. Une troisième copie dans un autre domaine de défaillance peut améliorer la résilience, même si elle complique une politique Autriche uniquement.

La souveraineté et la récupérabilité sont des objectifs à équilibrer, pas des étiquettes interchangeables.

Le support personnel fait partie de l'architecture

L'avantage probable de myDC sur un grand hébergeur de commodité n'est pas un algorithme de stockage secret. C'est la réduction de la distance organisationnelle. Lapage de supportpublie les horaires téléphoniques en semaine, tandis que les conditions générales définissent le support ordinaire comme du lundi au vendredi, 08:00–12:00 et 13:00–16:45. Les clients qui ont acheté un support 24/7 reçoivent un numéro d'urgence séparé avec leurs identifiants. C'est une distinction plus claire qu'une déclaration générique selon laquelle l'infrastructure est surveillée en continu.

La distinction devrait guider le placement des charges de travail. Une petite entreprise avec des systèmes fonctionnant aux heures de bureau peut valoriser l'accès à des personnes qui connaissent son environnement plus qu'une couverture téléphonique de nuit. Un service public avec un impact sur les revenus ou la sécurité à minuit a besoin de la voie d'escalade payante, des engagements de réponse et de restauration par écrit.

« Opérations 24/7 » peut signifier que les alarmes sont surveillées; cela ne signifie pas nécessairement qu'un client peut joindre un ingénieur au prix standard, ou que l'ingénieur doit rétablir le service dans un délai défini.

Lapage partenairenomme Siedl Networks, PLP Datentechnik, Genius IT, Compution IT et bavarialogy comme des organisations pouvant aider à la configuration, l'exploitation et la maintenance. Uneannonce de juillet 2026 concernant bavarialogyindique que ce partenaire utilise Platform Vienna et Server Vienna pour le travail client. Ce sont des déclarations du fournisseur, pas des mesures indépendantes de résultats clients, mais elles démontrent le modèle opérationnel prévu: myDC fournit l'infrastructure et un réseau de spécialistes régionaux peut fournir la couche applicative et d'administration.

Le cas SchoolFox rend cette allocation concrète. Le document produit par le fournisseur indique que le déploiement utilisait des ressources cloud myDataCenter avec une pile open source incluant Univention Corporate Server, Zimbra, IKARUS et OPNsense. Siedl Networks a assuré le conseil, la migration et la mise en service et a continué à fournir l'exploitation et le support. La citation du client fait état d'une administration et d'une collaboration plus faciles, mais le cas ne publie aucune métrique de disponibilité, de performance, de coût ou de migration.

C'est une preuve de schéma d'implémentation, pas une preuve statistique de la qualité du service.

Pour un acheteur, la question centrale est de savoir qui possède l'incident à chaque couche. Si une application est lente, est-ce que myDC prouve les performances de calcul et de stockage tandis que le partenaire inspecte l'invité et la base de données? Qui coordonne quand aucun ne voit de défaut? Le client ouvre-t-il un ticket ou deux? Les actions du partenaire sont-elles visibles dans la piste d'audit myDC? Un autre partenaire peut-il prendre le relais sans reconstruction?

Un écosystème local peut réduire les frictions de réponse, mais une matrice de responsabilité ambiguë peut recréer le même problème de coordination qu'il est censé résoudre.

Le prix mensuel n'est pas le contrat économique

La vitrine invite à la comparaison par le prix mensuel affiché. Les conditions générales définissent une unité différente: la relation dans le temps. Lesconditions générales d'octobre 2023de myDC s'appliquent aux entreprises et indiquent que chaque produit forme un contrat séparé. Sauf accord contraire, la durée minimale est de douze mois ou une période de facturation plus longue sélectionnée dans la boutique; le contrat se renouvelle alors pour la même période. L'annulation ordinaire doit parvenir par lettre signée au moins trois mois avant l'expiration.

Le guide de commande propose une facturation mensuelle, trimestrielle et annuelle. Un intervalle de facturation mensuel ne doit pas être considéré comme un engagement d'un mois, car la cadence de facturation et la durée minimale du contrat sont des concepts différents dans les documents publics. Un acheteur devrait faire en sorte que la confirmation de commande indique clairement les deux dates: début du service, fin de la durée minimale, date limite de préavis et période de renouvellement.

Si le checkout en direct offre des conditions différentes des conditions générales, l'enregistrement de commande signé ou sauvegardé devrait résoudre le conflit.

Les mêmes conditions générales exigent que les factures soient payées d'avance dans les quatorze jours et permettent la suspension après un délai de guérison. Si le client provoque une résiliation anticipée, les frais restants peuvent devenir exigibles. Les travaux en dehors des heures de support ordinaires et le dépannage causé par le client peuvent être facturés séparément. Ces clauses sont assez normales pour un petit fournisseur d'entreprise, mais elles font de la carte de machine virtuelle la moins chère une estimation de coût incomplète.

L'énergie est un intrant particulièrement explicite. myDC se réserve le droit d'ajuster les prix avec préavis et inclut une formule liée aux indicateurs de l'électricité de gros lorsque la moyenne trimestrielle augmente d'au moins cinq pour cent. Le client reçoit un droit de résiliation exceptionnel si l'augmentation résultante dépasse trente pour cent; d'autres ajustements annuels peuvent suivre un pourcentage minimum, les prix à la consommation ou les changements de salaires collectifs sans le même droit de sortie. La clause exacte doit être examinée dans le texte allemand faisant foi plutôt que réduite à un pourcentage unique.

Sa signification stratégique est plus claire: la tarification du cloud local reste exposée à l'économie de l'énergie, de la main-d'œuvre et des installations, et myDC transmet une partie de cette volatilité plutôt que de faire semblant que l'infrastructure est sans coût.

Le côté recours est modeste. Les conditions générales ne promettent pas un accès ininterrompu, toute connexion externe souhaitée ou la survie de tout équipement ou donnée. Elles permettent la maintenance planifiée et les travaux urgents, et précisent que les restrictions liées à la maintenance ne créent pas automatiquement une réduction de frais ou un recours en garantie. Le dépannage commence pendant les heures de bureau dans le cadre standard. Pour une fourniture initiale retardée, le crédit standard indiqué est de 13 € par semaine à partir de la troisième semaine seulement, sous réserve d'exclusions telles que le retard d'un tiers.

La responsabilité pour négligence ordinaire est limitée, les dommages indirects et la perte de profit sont exclus, et les dommages totaux sont plafonnés à 20 000 € selon les conditions publiées, sous réserve des exceptions légales habituelles qui ne peuvent être contractuellement écartées. Les conditions permettent également la suspension temporaire d'un service sous attaque par déni de service s'il en affecte d'autres, les coûts liés à l'attaque pouvant être facturés au client. Ces dispositions peuvent être tout à fait acceptables pour un petit système interne et totalement inadéquates pour une plateforme critique pour les revenus.

C'est pourquoi la comparaison des prix devrait utiliser un scénario de charge de travail plutôt qu'une carte de serveur. Inclure le calcul, la mémoire, la croissance du stockage, les adresses publiques, les réseaux privés, la capacité de sauvegarde, la rétention, la protection DDoS, les licences, l'administration partenaire, le support premium, le transfert de données pour l'utilisation courante et la sortie, la main-d'œuvre client, et le coût d'un test de récupération. Ensuite, évaluer l'inconvénient contractuel: ce que coûteraient une heure, un jour et une semaine d'indisponibilité, par rapport au recours réellement offert.

Le point idéal économique de myDC est probablement un acheteur pour qui la petite taille du fournisseur et l'accès personnel réduisent suffisamment les coûts de gestion pour compenser une automatisation moindre et une standardisation contractuelle moindre. Les preuves publiques ne révèlent pas les revenus, la concentration de la clientèle, l'effectif, les marges ou la capacité d'investissement, elles ne peuvent donc pas soutenir un jugement sur la résilience financière.

Un acheteur critique devrait demander des assurances financières ou de continuité appropriées en privé plutôt que de les déduire d'un faible prix de départ mensuel ou d'une liste de logos clients.

La sortie est plus facile au niveau de la charge de travail qu'au niveau du service

myDC indique qu'il favorise les standards ouverts et évite l'enfermement. L'architecture soutient une partie de cette affirmation. Les machines virtuelles KVM ordinaires, le réseau IP conventionnel et les sauvegardes compatibles Proxmox sont en principe plus portables qu'une application assemblée à partir de services sans serveur propriétaires et de services de données gérés. L'entreprise dit également qu'elle aide les clients à migrer.

La sortie opérationnelle comporte encore au moins quatre parties. Premièrement, extraire les données et les images machine dans un format convenu. Deuxièmement, reproduire les réseaux, les règles de pare-feu, les adresses, le DNS, les certificats et la surveillance à destination. Troisièmement, transférer ou recréer l'historique des sauvegardes et prouver une restauration. Quatrièmement, résilier chaque contrat de produit avant sa date limite distincte. Le logiciel open source aide principalement pour les deux premières; il ne les achève pas.

La continuité des adresses est un coût caché fréquent. Une adresse IPv4 publique fournie par myDC peut ne pas suivre le client. Les applications, les pare-feu distants, les listes blanches et les intégrations tierces peuvent l'intégrer. Les guides de commande et de sauvegarde eux-mêmes montrent pourquoi: une relation de sauvegarde peut dépendre d'une adresse source publique statique. La migration peut nécessiter un fonctionnement parallèle pendant que chaque pair est mis à jour, ce qui signifie payer les deux fournisseurs et gérer la cohérence des données.

Il en va de même pour le tableau de bord. Les factures et les tickets peuvent être téléchargés ou conservés uniquement selon le processus d'exportation et de clôture de compte existant. L'historique d'audit, les données de surveillance et l'état de la configuration doivent être exportés avant la suppression. La documentation publique ne précise pas combien de temps les données de service résilié ou les enregistrements de compte restent récupérables, ni comment la suppression est prouvée.

Le service Kopano abandonné offre un exemple utile et non catastrophique de dépendance amont. Dans unavis de novembre 2024, myDC a indiqué que le fournisseur de Kopano mettrait fin au produit concerné en mars 2025, donc myDC cesserait son offre gérée et recommanderait Zimbra. Il a offert aux clients existants la migration des e-mails, calendriers, contacts et tâches sans frais. C'est la preuve d'une réponse de transition responsable. C'est aussi un rappel qu'un fournisseur local ne contrôle pas chaque cycle de vie de produit en amont.

Un test de sortie de niveau approvisionnement devrait avoir lieu avant la production, alors que le levier et la bonne volonté sont les plus élevés. Exporter une machine virtuelle représentative, restaurer une sauvegarde en dehors de myDC, recréer un réseau privé, faire tourner tous les identifiants, et demander un projet de certificat de suppression. Enregistrer les dépendances qui ne se transfèrent pas. Répéter l'exercice après des changements architecturaux majeurs. Si le fournisseur facilite ce test, sa promesse de standards ouverts devient une preuve plutôt qu'un positionnement.

Les étiquettes de sécurité ont des propriétaires et des périmètres différents

L'histoire de sécurité publique de myDC contient plusieurs bons contrôles. L'entreprise indique que son tableau de bord prend en charge l'authentification à deux facteurs. Le flux de commande utilise des clés publiques SSH fournies par le client au lieu de mots de passe standard ou générés. La description de l'installation couvre l'accès physique, la surveillance, l'extinction d'incendie, l'alimentation et le refroidissement. Le workflow de sauvegarde recommande la restriction d'adresse source et la vérification d'empreinte.

Les conditions générales reconnaissent la réponse aux dénis de service, et la vitrine offre une option de protection dédiée.

Ces contrôles ne s'additionnent pas automatiquement à un système de gestion de la sécurité de l'information certifié pour myDC Cloud Services GmbH. L'entreprise indique que lecentre de donnéesest certifié ISO 27001. L'ISO explique queISO/CEI 27001spécifie les exigences pour un système de management de la sécurité de l'information. La valeur d'un certificat dépend de son titulaire nommé, de ses sites, services, exclusions, version, organisme de délivrance et validité. Le certificat d'un exploitant d'installation peut fournir une assurance héritée importante sans certifier les processus du personnel de myDC, le développement du tableau de bord, l'accès au support ou le périmètre du service client.

myDC indique également avoir renouvelé un label autrichien Cyber Trust. Ladescription du programmedu label lui-même offre plusieurs niveaux d'assurance et positionne son label standard comme un point d'entrée pragmatique. Lesrègles du programme 2026sont particulièrement utiles: le périmètre est lié à l'entreprise enregistrée et aux systèmes, processus et personnel sous son contrôle; le niveau standard repose sur une auto-déclaration validée, tandis que le niveau le plus élevé nécessite un audit externe; les labels sont limités dans le temps; et le programme ne promet pas une sécurité absolue. Sans un enregistrement de certificat public ou un niveau dans les preuves examinées, il serait erroné d'élever « Cyber Trust » en une revendication équivalente à une certification ISO auditée indépendamment.

Les preuves publiques manquantes sont aussi importantes que les badges visibles. Les pages examinées ne fournissent pas de certificat ISO myDC, de déclaration d'applicabilité, de résumé de test d'intrusion, de voie de divulgation de vulnérabilité, de liste de sous-traitants, de spécification de chiffrement au repos pour les disques cloud, d'objectif de notification d'incident de sécurité, d'objectifs de récupération, de description du contrôle d'accès du personnel ou de dossier d'audit client. Cela ne signifie pas que ces documents n'existent pas. Cela signifie qu'un acheteur réglementé ou à fort impact doit les demander.

Pour les données personnelles, le droit européen donne de l'importance au contrat et à la conception opérationnelle.L'article 28 du RGPDexige des clauses relatives au responsable de traitement couvrant les instructions, la confidentialité, les sous-traitants, l'assistance en matière de sécurité, la suppression ou le retour et les informations d'audit; l'article 32 exige une sécurité adaptée au risque, y compris la résilience et la restauration en temps utile le cas échéant. « Toutes les données en Autriche » peut simplifier une partie de l'analyse des transferts, mais cela ne remplace pas ces obligations n'établit que chaque sous-service de support, télémétrie, paiement ou communications reste dans la même frontière.

Les entités financières font face à un test plus exigeant en vertu durèglement sur la résilience opérationnelle numérique (DORA). Les dispositions contractuelles relatives aux tiers ICT de DORA exigent des descriptions claires des services, des emplacements de traitement et de stockage des données, des engagements de disponibilité et d'intégrité, de l'assistance en cas d'incident, des droits d'audit et d'accès, du support à la continuité et des clauses de sortie, avec des exigences supplémentaires pour les fonctions critiques ou importantes. Une annonce partenaire qui invoque DORA ou NIS2 est une revendication marketing jusqu'à ce que le contrat sous-jacent, les contrôles et les preuves répondent aux obligations du client.

La posture de sécurité la plus crédible pour myDC serait donc délibérément en couches: identifier les contrôles exploités par la GmbH, les contrôles hérités du fournisseur d'installation et de réseau, les contrôles inhérents à Ceph ou Proxmox mais dépendants de la configuration, les contrôles délégués aux partenaires d'implémentation, et les contrôles conservés par le client. Une matrice de responsabilité partagée d'une page serait plus précieuse qu'une liste plus longue de noms de sécurité non circonscrits.

Une page de statut verte est un instantané, pas un historique

Le 17 juillet 2026, lapage de statut réseaupublique de myDC affichait les services listés comme opérationnels et rapportait des chiffres de 100 % pour ses moniteurs visibles. La page indique que la disponibilité est mesurée sur un an et exclut les maintenances. Son flux RSS public ne montrait aucune entrée d'incident en cours au moment de l'examen.

Cela ne soutient qu'une déclaration vérifiée étroite: le fournisseur ne signalait pas publiquement de problème actif à cet instantané. Cela n'établit pas qu'aucun incident ne s'est produit au cours de l'année. L'historique visible n'exposait pas une chronologie complète des événements facilement vérifiable, et exclure la maintenance peut rendre un pourcentage de disponibilité inadapté au calcul de bout en bout du client. Aucune source publique crédible dans l'ensemble de preuves figé n'établissait une interruption myDC matérielle; l'absence d'un incident remonté n'est pas une preuve de service sans incident.

L'entreprise a au moins publié des preuves de tests de résilience physique. Unavis de maintenance de mars 2024annonçait un test de « black building » dans lequel l'alimentation électrique normale serait interrompue et les systèmes UPS et générateur activés; myDC a indiqué ne pas s'attendre à une interruption client. Publier le plan est positif. Le matériel examiné ne comprenait pas de rapport après action avec les performances de transfert mesurées ou les anomalies.

Pour un acheteur, le test le plus fort est de demander douze ou vingt-quatre mois d'enregistrements d'incidents et de maintenance, y compris les événements qui n'ont pas enfreint de seuil contractuel. Les comparer avec une surveillance externe. Demander le temps de détection, le temps de communication, le temps d'atténuation, les couches affectées, la cause racine, les mesures correctives et la récurrence. Demander également comment la maintenance d'urgence, la défaillance réseau amont, l'isolement DDoS et la dégradation partielle du stockage apparaissent dans le tableau de bord public.

La transparence peut être un avantage d'un petit opérateur local, mais seulement si elle survit à une journée difficile.

myDC rivalise avec trois types de sortie

myDC n'est pas simplement en concurrence avec un autre prix de serveur virtuel autrichien. Son client peut sortir dans trois directions, chacune modifiant le modèle de dépendance.

La première est un cloud européen plus large avec une zone autrichienne.Exoscaleliste publiquement deux zones à Vienne et un catalogue plus large incluant machines virtuelles, Kubernetes, stockage objet et bloc, réseautage privé, bases de données et API. Une telle plateforme peut offrir une automatisation plus forte et des schémas multi-zones tout en introduisant une surface de service plus grande et une identité contractuelle étrangère. Pour une équipe qui a besoin de services de données gérés ou de contrôle de flotte programmatique, cette largeur peut l'emporter sur le support personnel de myDC. Pour celle qui veut une poignée de machines conventionnelles et une relation locale, elle peut ajouter de la complexité sans résoudre un problème pressant.

La deuxième est un grand fournisseur d'infrastructure de commodité dans une juridiction voisine.Hetzner Cloudmet l'accent sur des options CPU virtuelles partagées et dédiées à faible coût, une API, des outils en ligne de commande, des réseaux et des intégrations. C'est une référence solide en termes de prix et d'automatisation, mais un emplacement allemand n'est pas un emplacement autrichien. Le comparer avec myDC révèle ce que la prime de localité achète: non seulement des millisecondes, mais aussi une proximité contractuelle, une revendication de localisation nationale des données et la possibilité d'une opération assistée par un partenaire.

La troisième est l'auto-exploitation, souvent avec la même famille open source. Un client peut exécuter Proxmox et des logiciels de sauvegarde sur du matériel possédé ou colocalisé et conserver un contrôle plus profond sur la configuration et les clés. Il hérite également de l'approvisionnement, de la planification de capacité, des correctifs, de la surveillance, des astreintes, des pièces de rechange, de l'alimentation et de la coordination des installations.

Le service de sauvegarde Proxmox gérée de myDC est intéressant précisément parce qu'il peut compléter cette voie: garder le contrôle principal sur site tout en plaçant une copie gérée ailleurs.

Il existe également des fournisseurs de services gérés et des exploitants d'installations autrichiens qui peuvent assembler des clouds privés sur mesure. Ils peuvent offrir une responsabilité plus adaptée et moins de libre-service instantané. myDC occupe un juste milieu utile: plus packagé et transparent qu'un projet d'intégration personnalisée, plus personnel et géographiquement spécifique qu'un grand cloud, et moins lourd opérationnellement que de posséder toute la pile.

Aucune preuve publique examinée ne soutient une revendication de part de marché ni ne prouve que myDC est moins cher au total. Sa différenciation défendable est qualitative. Il emballe une infrastructure familière, une garde autrichienne et des spécialistes accessibles dans un petit catalogue. Le risque est que la même compacité peut signifier moins de niveaux de service divulgués, moins d'interfaces d'automatisation et une plus grande dépendance à l'égard de personnes clés ou de partenaires.

L'approvisionnement devrait décider quel côté de ce compromis importe pour la charge de travail plutôt que d'attribuer des points pour la taille de l'entreprise dans un sens ou dans l'autre.

Neuf tests avant d'appeler le service souverain

Le mot « souverain » est plus utile comme plan de test. Un acheteur considérant myDC peut transformer les lacunes de preuves publiques en neuf tests d'acceptation concrets.

1. Concilier la carte d'identité et de responsabilité.Mettre myDC Cloud Services GmbH, le partenaire d'implémentation, l'exploitant de l'installation, l'opérateur réseau, les concédants de logiciels et les sous-traitants de support dans un seul tableau. Pour chacun, indiquer le contrat, la tâche, l'accès aux données et le devoir d'escalade. Confirmer que l'accord de traitement des données nomme la même entité que la commande.

2. Obtenir un calendrier des emplacements.Lister le site et le pays pour les disques actifs, les réplicas Ceph, les sauvegardes de machines virtuelles, les magasins de sauvegarde Proxmox, les données du tableau de bord, les journaux, les pièces jointes de support et les copies de reprise après sinistre. Enregistrer si « Autriche » est une condition contractuelle, quelles exceptions existent, et comment un changement d'emplacement est notifié. Un nom de ville ne suffit pas pour évaluer les domaines de défaillance courants.

3. Démontrer la défaillance, pas seulement la redondance.Demander à myDC de montrer l'architecture sous un accord de confidentialité approprié: nombre de nœuds de calcul, politique de réplication de stockage, domaines de défaillance Ceph, quorum de moniteurs, chemins réseau, marge de capacité et séparation des sauvegardes. Observer un exercice de défaillance d'hôte et mesurer le redémarrage de l'invité. Demander le résultat des derniers tests de transfert de puissance et de restauration.

4. Convertir le langage de disponibilité en un objectif de charge de travail.Identifier le pourcentage exact de niveau de service, le point de mesure, les exclusions, le processus de notification et le recours pour le produit acheté. Définir les objectifs de temps de récupération et de point de récupération séparément. Ajouter une surveillance d'application depuis un réseau indépendant. « Jusqu'à 99,99 % » ne devrait jamais être la dernière ligne d'une conception de production.

5. Tester le plan de contrôle.Appliquer l'authentification à deux facteurs, séparer les rôles de facturation et techniques, examiner la récupération du compte, exporter les événements administratifs, et apprendre comment le personnel du fournisseur accède. Déterminer si une API ou une méthode de configuration reproductible existe. Simuler la perte d'accès au tableau de bord et confirmer une voie de changement d'urgence authentifiée.

6. Restaurer le plus grand système réaliste.Effectuer des restaurations au niveau fichier et machine complète. Mesurer le temps de vérification, le débit de transfert de données, la cohérence de l'application et la récupération des dépendances. Répéter après avoir chiffré la sauvegarde, et prouver que le client peut récupérer si myDC est indisponible. Documenter qui détient les clés et ce qui se passe lorsque le détenteur des clés quitte.

7. Évaluer le stress, pas seulement l'état stable.Modéliser la croissance du stockage, des adresses, du réseau, de la rétention des sauvegardes, de la défense DDoS et du support. Appliquer la logique d'ajustement énergétique et indicielle du contrat. Ajouter la main-d'œuvre partenaire, les mois de migration parallèle et l'exportation de données. Comparer ce total avec un cloud en zone autrichienne, un hôte allemand de commodité et Proxmox auto-exploité.

8. Exercer la sortie tant que le service est sain.Exporter une machine et une sauvegarde, reconstruire son réseau ailleurs, modifier les listes blanches et le DNS, et demander la suppression sécurisée de la source. Confirmer les dates de préavis pour chaque contrat de produit et le coût de la résiliation anticipée. Enregistrer les artefacts du tableau de bord et les journaux qui restent disponibles après la fermeture.

9. Valider le périmètre d'assurance.Obtenir le certificat actuel de l'installation, le périmètre exact, le niveau Cyber Trust et la validité, le processus de contact de sécurité, les preuves de test d'intrusion, la liste des sous-traitants et l'engagement de notification d'incident. Mapper ces contrôles aux obligations RGPD, NIS2 ou DORA du client plutôt que d'accepter un raccourci de conformité d'une page partenaire.

Ces tests sont proportionnés même pour un petit fournisseur car la plupart n'exigent pas la divulgation publique de diagrammes sensibles. Ils exigent que l'acheteur et l'opérateur partagent une compréhension privée précise. L'échelle locale de myDC pourrait rendre ce dialogue plus facile qu'avec une plateforme mondiale. Si l'entreprise peut répondre rapidement et tester visiblement, l'opacité dans les pages marketing devient moins conséquente. Si elle ne le peut pas, la revendication de localité porte plus de risque qu'elle n'en résout.

Surveillez la frontière, pas le slogan

Cinq développements modifieraient matériellement l'évaluation.

Premièrement, un calendrier de service public qui associe chaque produit à un objectif de disponibilité défini, une méthode de mesure, un traitement de maintenance et un engagement de réponse rendrait la promesse opérationnelle plus facile à évaluer. Deuxièmement, la publication du titulaire et du périmètre du certificat de l'installation—et une description claire des sites qui hébergent les données de production et de sauvegarde—comblerait le plus grand écart dans les preuves de localité.

Troisièmement, un chemin d'exportation d'image et de configuration documenté, idéalement avec une API ou un outillage reproductible, transformerait l'architecture open source en une friction de sortie démontrablement faible.

Quatrièmement, l'assurance sécurité de myDC pourrait passer d'étiquettes à un dossier de preuves en couches: contrôles d'entreprise, contrôles d'installation hérités, configuration logicielle, accès partenaire et devoirs du client. Le cadre Cyber Trust peut être une étape utile, mais le niveau exact et le périmètre enregistré importent. Cinquièmement, la communication des incidents du fournisseur devrait être observée au fil du temps. Une page de statut avec des rapports d'incidents accessibles et des résultats de maintenance permettrait aux acheteurs de vérifier comment un petit opérateur apprend.

L'échelle de l'entreprise mérite également une observation neutre. De nouveaux partenaires peuvent étendre la capacité d'implémentation; ils peuvent aussi élargir la chaîne de responsabilité. De nouveaux services gérés peuvent augmenter les revenus et la commodité du client; ils peuvent aussi des cycles de vie de produits en amont comme l'arrêt de Kopano. De nouvelles installations ou chemins réseau peuvent améliorer la résilience; ils peuvent aussi compliquer la promesse que chaque copie reste dans une frontière comprise. Aucun n'est intrinsèquement bon ou mauvais. Chacun modifie la garde.

La proposition de myDC est la plus forte lorsqu'elle est dépouillée de mystique. C'est une GmbH autrichienne offrant une infrastructure KVM et Ceph configurable, une sauvegarde et des services gérés sélectionnés via un tableau de bord pratique et un écosystème de support régional. Cela peut être une excellente alternative à un hébergement de commodité lointain ou à un compte cloud public surdimensionné. Ce n'est pas une échappatoire aux installations, aux opérateurs, aux mainteneurs de logiciels, aux échéances contractuelles ou à l'administration client.

La conclusion correcte est donc conditionnelle mais utile. Les preuves publiques prouvent le pont entreprise-marque et soutiennent une réelle empreinte opérationnelle autrichienne. Elles soutiennent la présence de virtualisation open source et de stockage distribué, d'un workflow en libre-service, d'un support local et d'une tentative sérieuse de résilience. Elles ne prouvent pas encore chaque domaine de défaillance, périmètre de certificat, niveau de service ou étape de sortie qu'une charge de travail critique exige.

Une promesse de cloud local n'est aussi forte que sa transition la moins visible. Pour myDataCenter.at, l'opportunité est de faire de ces transitions son produit: nommées, contractuellement délimitées, techniquement testées et humainement responsables. Lorsque la localité devient une chaîne de preuves plutôt qu'une étiquette de pays, un petit fournisseur peut offrir quelque chose que les plus grands clouds trouvent étonnamment difficile à égaler.