Résumé
- Aruba Cloud DE doit être jugé sur la traçabilité qu’un client peut conserver à travers le choix de localisation, le provisionnement, la sauvegarde, la restauration, le routage, l’assistance et l’exportation, et non sur l’étendue du catalogue de services public d’Aruba Cloud.
- Son principal atout est une surface d’exploitation européenne avec une infrastructure détenue en Italie, des preuves de réseau en Allemagne, des documents de conformité formels et une documentation pratique du panneau de contrôle; son point faible est que les clients conservent eux-mêmes une grande partie de la discipline de gestion d’état, de récupération et de migration.
La revendication de localité qui doit survivre à l’usage
Aruba Cloud DE évolue sur un marché du cloud où la localité est devenue un argument d’achat, une préoccupation réglementaire et une stratégie de substitution. Les acheteurs européens ne se demandent pas simplement si un fournisseur possède des serveurs en Europe. Ils cherchent à savoir si l’endroit où une charge de travail s’exécute peut être choisi, vérifié, récupéré et quitté sans transformer le service en une dépendance opaque. Cette distinction est importante car de nombreuses décisions cloud commencent comme des décisions de conformité mais se terminent comme des décisions opérationnelles.
Une équipe financière, un fournisseur du secteur public, une société de logiciels ou un fournisseur de services gérés régional peut commencer avec l’obligation de conserver les données en Europe ou à proximité d’une base d’utilisateurs allemande. Le test quotidien est plus mécanique: l’équipe peut-elle reconstruire le serveur, restaurer les fichiers, confirmer la route, conserver les journaux et obtenir de l’assistance à temps lorsqu’un changement de routine tourne mal?
L’étiquette DE doit donc être interprétée de manière restrictive. Elle ne signifie pas que tous les services Aruba sont allemands, que les charges de travail des clients restent automatiquement dans un seul pays, ni qu’un fournisseur régional supprime la charge de conformité propre du client. Aruba Cloud est la marque de services cloud d’Aruba S.p.A., un groupe italien de services numériques, et les données publiques situent l’offre cloud au sein d’un réseau européen plus large qui comprend des infrastructures détenues en Italie, en République tchèque et des emplacements partenaires dans d’autres pays européens.
Les enregistrements réseau publics montrent également une empreinte de système autonome orientée vers l’Allemagne et une présence au point d’échange de Francfort. Ce sont des signaux significatifs. Ils ne constituent pas une preuve complète de l’emplacement de chaque bloc de disque, objet de sauvegarde, journal de gestion ou action d’assistance pour chaque configuration client.
C’est là le problème central de l’évaluation. La substitution par un cloud local n’est utile que lorsqu’elle produit un meilleur historique opérationnel que les alternatives. Face aux hyperscalers, Aruba Cloud ne peut pas gagner uniquement par l’étendue de son offre. AWS, Microsoft Azure et Google Cloud restent les plateformes par défaut pour les équipes qui souhaitent les catalogues de services gérés les plus riches, les intégrations d’identité mondiales, les écosystèmes de marketplace et les outils de développement. Face aux fournisseurs de VPS non gérés, Aruba Cloud ne peut pas gagner simplement en étant bon marché ou européen.
Le client qui achète un cloud régional veut le contrôle, la documentation et l’assistance supplémentaires pour justifier le processus ajouté de vérification de la région, de l’étendue des services et du comportement de récupération. Face à une infrastructure détenue en propre, Aruba Cloud doit réduire la charge en capital et en personnel sans masquer les modes de défaillance précis que le matériel possédé rendait visibles.
Le test utile est un enregistrement de localité accepté. Avant une migration en production, le client doit pouvoir indiquer la région prévue, le type de service, l’emplacement du stockage et de la sauvegarde, l’objectif de récupération, le canal d’assistance responsable, les hypothèses de routage ou de peering, le chemin d’exportation des données et les lacunes connues. Après un changement, le même enregistrement doit rester vrai ou présenter une exception visible. Si un serveur est redimensionné, l’enregistrement doit montrer ce qu’il est advenu des vCPU, de la RAM, des disques, des adresses IP et des instantanés.
Si une sauvegarde est restaurée, il doit indiquer si la restauration a été partielle ou complète, si les fichiers ont été écrasés, renommés ou envoyés vers un autre emplacement, et si le mot de passe de récupération et le support de restauration ont été traités correctement. Si un service est déplacé, il doit indiquer si l’exportation est en libre-service, prise en charge par API ou dépendante d’une demande d’assistance.
Selon ce critère, Aruba Cloud DE n’est ni une simple réponse de souveraineté ni une offre d’hébergement générique. Sa valeur est conditionnelle. Il est le plus pertinent pour les PME européennes, les développeurs, les fournisseurs de services et les organisations réglementées qui sont prêts à gérer les changements cloud comme un travail de préservation des preuves. Il est moins adapté aux équipes qui s’attendent à ce que la localité cloud soit automatique, que les sauvegardes remplacent les restaurations testées, ou que les crédits d’assistance se substituent à la discipline interne de gestion des incidents.
Ce que montre la surface d’exploitation publique
La documentation publique d’Aruba Cloud présente un cloud européen construit autour de composants de cloud public, VPS, cloud privé, stockage objet, stockage bloc, sauvegarde, reprise après sinistre, Kubernetes géré, base de données et réseau. L’entreprise se décrit comme un fournisseur cloud italien de premier plan et met l’accent sur une infrastructure de centres de données propriétaires sur le sol italien. Elle indique également que les services cloud peuvent être hébergés en Italie ou dans un réseau européen de centres de données.
Sa base de connaissances définit une région comme un emplacement géographique composé d’une ou plusieurs zones connectées par des réseaux redondants à faible latence, les régions étant décrites comme indépendantes les unes des autres et ne partageant pas les risques environnementaux. C’est le vocabulaire approprié pour la localité, mais le vocabulaire n’est que le début.
La documentation officielle sur les centres de données donne à Aruba Cloud son premier avantage opérationnel: elle ne présente pas l’Europe comme une étiquette de conformité abstraite. Elle traite de la sécurité physique, de l’alimentation redondante, du refroidissement, des mesures de continuité d’activité et de l’interconnexion européenne. Elle fait également référence à des certifications et normes de centres de données, y compris des certifications de la famille ISO et des références ANSI/TIA-942 pour les installations à haute résilience.
Les pages publiques sur la protection des données relient l’architecture cloud à la norme ISO 27001 et au code de conduite CISPE. Les pages dédiées au secteur public ajoutent des revendications concernant la qualification pour l’administration publique italienne, notamment les niveaux d’infrastructure AI3 et de service QC3 selon la terminologie d’Aruba.
Ces déclarations rendent Aruba Cloud plus inspectable qu’un simple fournisseur VPS. Un client peut demander quel service, quelle région, quelle classe de centre de données, quelle certification et quel document contractuel s’appliquent. La présence d’une page de conditions, d’un document SLA public, de procédures dans la base de connaissances et d’une documentation sur l’exportation est importante, car les petits fournisseurs échouent souvent précisément sur ce point.
Ils peuvent avoir des ingénieurs compétents et des installations locales, mais l’acheteur ne peut pas produire un dossier propre pour les auditeurs, les assureurs ou les comités de risque internes. L’ensemble des documents publics d’Aruba donne aux acheteurs de la matière pour travailler.
Le volet allemand du dossier est plus précis dans les preuves réseau que dans le marketing général. Les bases de données de peering identifient AS200185 comme Aruba Cloud DE, avec une présence opérationnelle à DE-CIX Francfort et des preuves d’installation d’interconnexion à Francfort. Le contexte BGP montre également des préfixes étiquetés allemands associés à l’empreinte de système autonome d’Aruba.
Des listes indépendantes de centres de données situent l’installation DE1 d’Aruba.it à Francfort-sur-le-Main, mais ces listes doivent être considérées comme un contexte tiers et non comme un substitut à une confirmation de service Aruba spécifique à la commande. Cela est important car la preuve d’installation n’est pas la même que la preuve de charge de travail. Un client ne doit pas déduire qu’un service, une sauvegarde ou un flux de journaux sélectionné est allemand simplement parce qu’une installation ou une route allemande apparaît dans les enregistrements réseau publics.
La conclusion la plus solide est plus modeste: Aruba Cloud dispose d’une surface d’exploitation cloud européenne avec une propriété italienne visible, un langage de centres de données européen, une présence réseau allemande et des artefacts de conformité formels. Cela suffit à en faire une alternative régionale plausible. Cela ne suffit pas à supprimer l’obligation du client de conserver l’enregistrement exact du service au moment du provisionnement et au fil des changements ultérieurs.
La vérité du provisionnement est le premier test de fiabilité
La plupart des défaillances cloud commencent avant l’incident. Elles commencent lorsque l’équipe ne peut pas reconstituer ce qui a été commandé, où cela a été placé, quel hyperviseur a été sélectionné, quelle version IP était active, quel modèle de disque a été utilisé, quel plan régissait les rétrogradations et quels paramètres ont été hérités d’un modèle. La documentation d’Aruba Cloud rend cela visible car plusieurs choix de services ne sont pas cosmétiques. Ils modifient ce qui peut être changé ultérieurement, ce qui est couvert par quel niveau de disponibilité et le degré de supervision qu’une petite équipe doit assurer.
Pour le VPS Cloud, la base de connaissances d’Aruba montre le chemin de provisionnement comme une série de choix: technologie, système d’exploitation, taille, modèle, détails du serveur et accès de gestion. Elle distingue les profils Starter et Standard, avec une disponibilité Linux uniquement par rapport à Linux et Windows, des valeurs par défaut IPv4 et IPv6, un stockage SSD ou NVMe et différents chiffres de disponibilité de service publiés. Une page distincte sur l’hyperviseur indique que le choix de l’hyperviseur est fondamental et ne peut pas être modifié ultérieurement.
Elle montre également différentes plages de ressources, la disponibilité des instantanés et les caractéristiques réseau selon les variantes OpenStack et VMware. Une équipe qui traite ces options comme un simple formulaire de commande peut créer un verrouillage futur chez le fournisseur avant même que des données ne soient téléchargées.
C’est pourquoi l’enregistrement opérationnel accepté doit saisir la décision de provisionnement comme un contrôle technique, et non comme une facture. L’enregistrement doit identifier l’hyperviseur sélectionné, le modèle, le système d’exploitation, le statut IP publique, le statut IPv6, le type de stockage, le plan tarifaire, la région et le chemin d’assistance. Il doit également indiquer quels choix sont réversibles et lesquels ne le sont pas. Dans la documentation publique d’Aruba, certains changements nécessitent un arrêt, la suppression d’instantanés ou une attente jusqu’au prochain renouvellement.
Certaines mises à niveau de ressources sont immédiates, tandis que les rétrogradations dans le cadre de plans mensuels ou annuels prennent effet plus tard. La suppression de disques secondaires peut entraîner une perte de données. Ce sont des contraintes cloud normales, mais elles sont importantes car le client qui achète un cloud régional dispose souvent d’une équipe d’exploitation réduite. Le coût caché n’est pas seulement le prix mensuel du serveur. C’est le coût de la vérification de chaque changement avant d’appuyer sur confirmer.
Le même problème apparaît dans le comportement tarifaire. Aruba documente des plans horaires, mensuels sur 30 jours et annuels pour Cloud Server PRO, avec des délais différents pour les rétrogradations et les changements de plan. L’attrait commercial de la tarification mensuelle ou annuelle est un coût prévisible. Le coût opérationnel est qu’une taille, un plan ou une ressource inutile peut persister jusqu’au renouvellement. La tarification horaire permet un ajustement plus rapide mais peut exiger une surveillance plus étroite des coûts. Un fournisseur qui expose ces mécanismes donne aux clients les outils pour les gérer.
Cela montre aussi clairement que l’élasticité du cloud n’est pas universelle. L’élasticité existe à l’intérieur des règles du service sélectionné.
Le test de vérité du provisionnement est donc simple. Un client peut-il répéter un changement de charge de travail trois fois et aboutir aux mêmes faits intacts? La réponse dépend en partie de la plateforme Aruba et en partie de la discipline d’exécution du client. Aruba fournit des panneaux de contrôle, des API, des journaux et des instructions dans la base de connaissances. Le client doit décider s’il intègre ces détails dans l’approbation des changements. Sans cela, un choix de localité allemande ou italienne peut devenir un vague souvenir plutôt qu’un fait opérationnel.
Le bilan de récupération est plus important que l’étiquette de sauvegarde
Le langage de la sauvegarde est facile à mal interpréter. La documentation d’Aruba est utile car elle distingue la redondance du stockage, les instantanés, les sauvegardes et la reprise après sinistre au lieu de prétendre qu’un seul mot couvre tous les risques. Cette distinction est importante pour les clients qui veulent des services sensibles à la localité. Une charge de travail peut survivre à une panne matérielle de disque tout en perdant des données parce qu’un utilisateur a supprimé les mauvais fichiers, qu’une application a corrompu une base de données, qu’un instantané a expiré ou qu’un mot de passe de restauration était indisponible.
La documentation d’Aruba sur les méthodes de sauvegarde indique que chaque disque cloud est activé sur un stockage redondant synchrone, de sorte que le risque déclaré de défaillance matérielle est différent du risque de suppression accidentelle par le client. Elle recommande ensuite des approches pratiques de sauvegarde: ajouter des disques secondaires, configurer un autre serveur dans un autre centre de données comme cible de sauvegarde, exporter un disque dur vers l’espace FTP du client, ou utiliser des instantanés comme point de récupération court avant des changements.
L’avertissement crucial est que l’instantané n’est pas une stratégie de sauvegarde complète. C’est un point de restauration conservé pendant une période limitée. La page d’Aruba sur les instantanés indique explicitement que les instantanés sauvegardent les disques durs et la configuration du disque, pas les réseaux ni les ressources de calcul. Elle précise également qu’un seul instantané peut être créé à la fois, que 10 % d’espace disque libre sont nécessaires, qu’un instantané est conservé pendant 48 heures, que le serveur doit être éteint pour la restauration, et que la restauration supprime l’instantané.
Ces détails modifient le modèle de risque de l’acheteur. Un instantané est utile avant l’application de correctifs, les mises à niveau de paquets, les déploiements d’applications ou les modifications de configuration. Il ne remplace pas une architecture de sauvegarde testée par des restaurations. Il ne préserve pas l’environnement complet. Il ne conserve pas un long historique. Il peut bloquer certaines modifications tant qu’il est actif. Il peut ne pas répondre aux besoins du client si le problème est découvert après la fenêtre de rétention. Il crée également des frictions de processus car le serveur doit être arrêté pour la restauration.
Pour une petite entreprise, cela peut être acceptable. Pour un service 24 heures sur 24, cela nécessite une planification de la maintenance.
La documentation sur la sauvegarde cloud ajoute une autre couche. La restauration au niveau des fichiers permet des choix tels que la restauration vers l’emplacement d’origine ou un emplacement alternatif, et de décider si les fichiers existants doivent être écrasés, conservés ou renommés. C’est utile car cela permet une récupération partielle sans nécessairement restaurer un serveur entier. Mais cela signifie aussi que la restauration est un point de décision.
L’opérateur doit savoir si le chemin cible est propre, si l’écrasement est acceptable, si les fichiers renommés perturberont l’application, et si l’état restauré est compatible avec la cohérence de la base de données ou de l’application.
La restauration bare-metal soulève une exigence opérationnelle plus stricte. La documentation d’Aruba indique que l’opérateur a besoin des données pour se connecter au panneau de contrôle avec la sauvegarde bare-metal, et une documentation distincte sur les travaux avertit qu’un mot de passe de chiffrement doit être spécifié lors de la création d’un travail et sera requis pour la restauration partielle ou totale. Si ce mot de passe ne peut pas être récupéré, la sauvegarde peut devenir administrativement présente mais pratiquement inutilisable. C’est le genre de défaillance que l’image de marque d’un cloud régional ne peut pas résoudre.
C’est un problème de supervision.
La reprise après sinistre en tant que service (DRaaS) crée une promesse différente. Aruba décrit le DRaaS pour Virtual Private Cloud comme un moyen de protéger l’infrastructure avec des réplicas autonomes entre les sites et structure la conception autour du RPO et du RTO. La présence du langage RPO et RTO est positive car elle oblige l’acheteur à définir la perte de données acceptable et le temps de restauration. Mais les preuves doivent encore être spécifiques au client. Quel site principal? Quel site secondaire? Quelle méthode de réplication? Quel manuel opérationnel? Quel résultat de test?
Quelles dépendances applicatives restent en dehors de l’environnement répliqué? Tant que ces réponses n’existent pas, le DRaaS est une capacité plutôt qu’un bilan de récupération.
L’état du réseau fait partie du produit
Les acheteurs de cloud réduisent souvent la localité au calcul et au stockage. C’est incomplet. Pour une charge de travail européenne, l’état du réseau peut déterminer si le fournisseur régional semble résilient, accessible et commercialement crédible. Les preuves réseau d’Aruba Cloud DE sont utiles car elles montrent que l’étiquette allemande n’est pas purement rédactionnelle. PeeringDB identifie AS200185 comme Aruba Cloud DE et enregistre un peering opérationnel à DE-CIX Francfort avec un port de 10 Gbit/s. Il répertorie également les installations d’interconnexion, notamment Francfort et Aruba IT3 à Ponte San Pietro.
Les outils BGP montrent un mélange de descriptions de préfixes allemands et italiens, un contexte de routage valide et des relations en amont.
Cela ne prouve pas les performances applicatives. Un port d’échange de 10 Gbit/s n’est pas une garantie de latence pour le client. Un préfixe étiqueté Allemagne n’est pas un certificat de résidence de la charge de travail. Les enregistrements de peering peuvent changer. Les décisions de routage peuvent différer selon le réseau source, la politique en amont, la taille des paquets, la congestion et la configuration du client. Mais les preuves de peering public restent importantes car elles donnent aux équipes techniques quelque chose à tester.
Elles peuvent mesurer les chemins depuis les réseaux à large bande allemands, les bureaux italiens, les réseaux de partenaires européens et les points de surveillance externes. Elles peuvent comparer les traceroutes avant et après la migration. Elles peuvent observer si le basculement modifie le chemin d’une manière qui rompt les hypothèses de localité.
La couche réseau expose également l’un des compromis d’Aruba Cloud par rapport aux hyperscalers. Les plus grandes plateformes mondiales exploitent de vastes réseaux fédérateurs privés, des points de terminaison de service privés, des systèmes d’ingénierie de trafic matures et de nombreuses options de périphérie gérée. Leur risque est la concentration, la complexité juridictionnelle et le verrouillage.
Un fournisseur de cloud régional peut offrir une géographie plus simple et un positionnement européen plus clair, mais il peut dépendre de manière plus visible des points d’échange, des opérateurs, des installations partenaires et des chemins Internet publics. Cette visibilité n’est pas une faiblesse si le client l’enregistre et la teste. Elle devient une faiblesse si le client suppose qu’une étiquette régionale rend le comportement du réseau évident.
La documentation produit d’Aruba comprend également des composants réseau dédiés: des pare-feu physiques, des commutateurs physiques et des options de commutateur en tant que service pour les réseaux privés autour de serveurs dédiés. Cela importe pour les clients qui essaient de reproduire des modèles sur site dans un environnement hébergé. Un appareil de pare-feu ou un commutateur privé peut être précieux lorsque le client a besoin d’une segmentation et d’un contrôle familiers. Mais cela peut aussi ramener la conception vers des opérations spécifiques au matériel.
Plus l’architecture repose sur des appareils réseau particuliers, plus il devient important de documenter les chemins de remplacement, les sauvegardes de configuration, la responsabilité du micrologiciel et qui peut agir pendant un incident.
Pour Aruba Cloud DE, le test de l’état du réseau doit être inclus dans chaque migration. Un client doit enregistrer les plages d’adresses IP publiques utilisées, le comportement DNS, les besoins de DNS inverse, les règles de pare-feu, la configuration de l’équilibreur de charge, les contrôles de surveillance, les attentes de chemin de peering et le canal d’assistance pour les événements de connectivité. La tâche répétée n’est pas simplement « créer un serveur ».
C’est « créer un serveur, le rattacher au contexte réseau attendu, prouver qu’il est joignable depuis les marchés européens visés, et conserver la preuve lorsque le serveur est redimensionné, restauré ou remplacé ».
La continuité de l’assistance est un coût, pas un slogan
Les documents d’Aruba Cloud mentionnent régulièrement l’assistance: assistance technique dédiée pour le stockage objet, service client 24 heures sur 24 dans le SLA, tickets d’assistance technique, services de consultation et canaux de service client. La continuité de l’assistance fait partie de la proposition de valeur car les acheteurs de cloud régional manquent souvent de personnel pour gérer chaque couche seuls. Pourtant, l’assistance est aussi le lieu où les attentes peuvent dériver. Un canal d’assistance ne signifie pas que le fournisseur possède l’état applicatif du client.
Un service 24 heures sur 24 ne signifie pas que chaque incident est résolu dans le délai de récupération souhaité par le client. Une clause de crédit ne rend pas l’application complète.
Le SLA public est instructif. Il définit les paramètres de disponibilité pour l’infrastructure du centre de données, l’accessibilité Internet et les nœuds physiques hébergeant l’infrastructure virtuelle du client, avec des variations spécifiques au service pour certains produits VPS. Il exclut la maintenance planifiée des calculs de disponibilité et indique que la maintenance planifiée doit être communiquée avec un préavis d’au moins 48 heures.
Il précise que les pannes et anomalies sont signalées en ouvrant un ticket d’assistance, et qu’aux fins de crédit, seules les pannes confirmées par le système de surveillance d’Aruba sont prises en compte. Il décrit également la compensation sous forme de crédits ou de prolongation de contrat, sous réserve de limites temporelles et de plafonds.
C’est un langage contractuel cloud normal, mais il doit façonner les attentes opérationnelles. Si un client ne peut pas produire un ticket en temps utile, des journaux, des horodatages, des enregistrements de surveillance et la preuve que le problème n’est pas causé par sa propre configuration, il peut avoir du mal à obtenir réparation. Si la panne est une défaillance applicative, une mauvaise configuration du client, un problème logiciel tiers ou une mauvaise utilisation du service, le SLA peut ne pas s’appliquer. Le crédit peut également être économiquement faible par rapport au coût de l’incident.
Un crédit de cinq pour cent pour l’infrastructure virtuelle affectée sur des unités de quinze minutes n’est pas une assurance contre les interruptions d’activité.
La bonne conclusion n’est pas que l’assistance Aruba Cloud est faible. La conclusion est que l’assistance doit être intégrée dans le modèle opérationnel du client. Pour une PME, cela peut signifier désigner un responsable interne qui connaît le panneau de contrôle, la console de sauvegarde, le portail d’assistance et le processus de restauration. Pour un fournisseur de services gérés, cela peut signifier conserver un dossier de preuves d’assistance par client avec les numéros de commande, les identifiants de service, la sélection de région, les identifiants de travaux de sauvegarde et les contacts d’escalade.
Pour une organisation réglementée, cela peut signifier traiter les documents d’assistance d’Aruba comme une couche d’un plan plus large de réponse aux incidents, et non comme le plan lui-même.
La continuité de l’assistance a également un impact sur le travail. Un cloud régional peut réduire l’approvisionnement en matériel, l’alimentation, le refroidissement, les installations et les travaux de maintenance physique. La documentation d’Aruba sur le cloud privé géré indique qu’Aruba gère la maintenance matérielle, la gestion de la plateforme VMware, les mises à jour de sécurité et certaines parties de la couche IaaS tandis que le client contrôle les machines virtuelles et la configuration. Cette répartition peut réduire le travail d’infrastructure de routine.
Mais elle crée un nouveau travail de gestion des fournisseurs, de documentation des configurations, d’exercices de restauration, d’examen des coûts et d’escalade du support. Elle déplace le travail de la salle des serveurs vers le plan de contrôle.
La conformité n’est utile que lorsqu’elle correspond aux services
La posture de conformité d’Aruba Cloud est l’un de ses principaux différenciateurs. L’entreprise fait référence à la norme ISO 27001 et aux normes connexes, à l’adhésion au code de conduite CISPE, à la qualification pour l’administration publique, au RGPD, à NIS2, au positionnement orienté DORA, à l’implication dans Gaia-X et aux initiatives cloud européennes. Le registre public CISPE et les documents du CEPD donnent un contexte plus large au code de conduite en tant que cadre reconnu de protection des données pour les services d’infrastructure cloud.
La page de certification d’Aruba indique que plusieurs services cloud Aruba ont une adhésion contrôlée par Bureau Veritas, notamment Cloud PRO, Virtual Private Cloud, Cloud Object Storage, Cloud Backup, DBaaS, DRaaS et IaaS pour SAP HANA.
C’est significatif. Cela signifie que le fournisseur ne se contente pas de dire « faites-nous confiance » dans une brochure commerciale. Il offre des références qu’une équipe d’approvisionnement peut inspecter. Cela aide également les fournisseurs régionaux à répondre à un marché dominé par les hyperscalers américains. Les acheteurs européens préoccupés par la juridiction, le traitement des données, la portabilité des services et les exigences du secteur public ont besoin de plus qu’un drapeau. Ils ont besoin de normes nommées, de services nommés, d’organismes de surveillance nommés et d’engagements contractuels nommés.
Mais la conformité a un problème de granularité. Un certificat ou une adhésion à un code peut s’appliquer à un service, un processus, un centre de données, un système de gestion ou un ensemble d’emplacements déclarés. Il peut ne pas s’appliquer à chaque produit adjacent, à chaque configuration client ou à chaque composant tiers. L’acheteur d’Aruba Cloud doit donc faire correspondre chaque revendication de conformité au service commandé. Le service sélectionné est-il couvert par la déclaration CISPE pertinente? Le centre de données ou la région est-il couvert par la certification citée?
Le service de sauvegarde a-t-il le même niveau de qualification que le service de calcul? L’accès au support, les journaux, les données de surveillance et les métadonnées du plan de gestion sont-ils inclus dans la compréhension du client de l’emplacement des données? L’application propre du client introduit-elle des processeurs en dehors de la frontière d’Aruba?
La documentation sur le secteur public illustre ce point. Aruba déclare que les données sensibles et stratégiques du secteur public sont gérées par du personnel local autorisé dans des centres de données italiens et qu’elle n’est pas soumise aux lois non européennes. C’est une revendication importante pour les organismes publics et les fournisseurs italiens, mais le client doit toujours vérifier si le service, la région et le contrat spécifiques correspondent à son obligation légale.
Une PME allemande utilisant un service cloud orienté vers Francfort ne doit pas automatiquement une déclaration d’administration publique italienne dans son propre dossier de conformité. Le dossier de conformité doit correspondre à l’achat.
Il en va de même pour la protection des données. La documentation publique d’Aruba met l’accent sur la responsabilité partagée entre la sécurité du cloud et la sécurité dans le cloud. C’est le modèle correct. Aruba peut exploiter des installations, des plateformes, du stockage, des contrôles réseau et des processus d’assistance.
Le client conserve la propriété des comptes, des identifiants, du renforcement du système d’exploitation, de la sécurité des applications, des calendriers de sauvegarde, des tests de restauration, de la classification des données et de la gestion des clés, à moins qu’un service géré ne modifie explicitement cette répartition. En pratique, les défaillances cloud les plus graves sont des défaillances de responsabilité partagée: un service techniquement disponible héberge une application mal sécurisée, une sauvegarde non testée, un certificat expiré, une clé exposée ou un chemin de migration non documenté.
Pour Aruba Cloud DE, la conformité n’est donc pas la réponse. C’est la carte de départ. La valeur apparaît lorsque cette carte de conformité est attachée à un enregistrement de service capable de survivre aux changements.
L’automatisation réduit la corvée uniquement lorsque l’état est exportable
La base de connaissances d’Aruba comprend une documentation API, des journaux d’activité, des journaux de modifications, des conseils sur l’exportation de données et des instructions de panneau de contrôle spécifiques aux services. Cela importe car la substitution par un cloud local échoue lorsque le fournisseur est compréhensible par les humains mais pas par les systèmes. Une PME européenne peut commencer avec quelques serveurs créés manuellement. Un fournisseur de services ou un acheteur réglementé aura éventuellement besoin d’un provisionnement reproductible, de pistes d’audit, de journaux exportables et de contrôles scriptés.
La page API publique indique que les API Aruba Cloud permettent aux clients de gérer les fonctionnalités de manière indépendante et de les automatiser ou de les intégrer sans utiliser la plateforme de gestion. La page d’exportation de données est plus révélatrice sur le plan opérationnel. Elle répertorie la disponibilité de l’exportation par catégorie de calcul, de stockage, de réseau, de sauvegarde, de surveillance et de journal, et distingue les actions du client, la participation de l’opérateur, les demandes d’assistance, les guides et les API.
Le tableau montre que certains services ont une exportation en libre-service ou basée sur un guide, certains nécessitent une assistance, et certains chemins de reprise après sinistre ne sont pas exportables au sens ordinaire. Il note également que les clés gérées via KMS ne peuvent pas être exportées de manière autonome d’une façon qui permettrait l’accès aux volumes chiffrés, car l’exportation de données est déjà en texte clair.
C’est une divulgation sérieuse et utile. Elle empêche un acheteur de supposer que chaque service est également portable. Elle donne également au client un moyen de classer le verrouillage. Un service peut être commercialement attractif tout en nécessitant une exportation assistée par un opérateur. Un produit de sauvegarde peut être résilient tout en exigeant une intervention du support pour l’exportation des données. Un modèle de gestion des clés peut améliorer la sécurité tout en réduisant ce que le client peut emporter. La question n’est pas de savoir si le verrouillage existe. Chaque cloud a un verrouillage.
La question est de savoir si le verrouillage est visible avant que le client n’engage la charge de travail.
Le règlement européen sur les données (Data Act) ajoute une pression sur cette question. La politique européenne présente désormais le changement de fournisseur cloud et l’interopérabilité comme des exigences du marché, et non plus comme de simples préférences des clients. La documentation publique de la Commission européenne indique que les fournisseurs de services cloud et de périphérie doivent respecter des exigences minimales pour faciliter l’interopérabilité et permettre le changement.
Elle identifie également les obstacles au changement tels que les frais élevés, les procédures longues, le manque d’interopérabilité et la possible perte de données ou d’applications. La documentation d’Aruba sur l’exportation de données n’est donc pas qu’un simple article d’assistance. Elle fait partie de la frontière de confiance pour les clients qui cherchent à préserver leurs droits de sortie.
L’automatisation crée également un coût de supervision. Un client peut utiliser des API pour scripter la création de serveurs, la journalisation, la surveillance ou les contrôles réseau, mais chaque script doit toujours connaître le modèle de service. Si une API crée la mauvaise région, omet IPv6, ne parvient pas à capturer un identifiant de travail de sauvegarde ou ne stocke pas le mot de passe de restauration dans un coffre-fort contrôlé, l’automatisation accélère l’erreur. Si une API peut exporter des journaux mais que la politique de rétention du client ne les collecte pas avant suppression, la piste d’audit reste incomplète.
L’utilisation mature du cloud n’est pas une question de manuel contre automatisé. Il s’agit de savoir si l’automatisation transporte le bon état.
Pour Aruba Cloud DE, la tâche d’automatisation la plus solide est une migration contrôlée ou un enregistrement de changement: créer ou redimensionner la charge de travail, confirmer l’emplacement et l’état du réseau, attacher le stockage et la sauvegarde, tester la restauration, enregistrer le plan tarifaire, capturer les identifiants d’assistance, exporter la configuration lorsque c’est disponible, et documenter les exceptions où une assistance est requise. Si cela peut être répété à moindre coût, le cloud régional a une valeur opérationnelle.
Si chaque changement dépend d’un opérateur senior qui se souvient des contraintes cachées, l’économie de main-d’œuvre s’érode.
Économie unitaire: factures prévisibles contre supervision cachée
L’argument commercial d’Aruba Cloud n’est pas simplement le prix. Les pages publiques montrent un mélange de paiement à l’usage, de forfaits mensuels, de plans horaires, de plans sur 30 jours et de formules annuelles. Le stockage objet, par exemple, est annoncé avec un modèle de paiement à l’usage basé sur des blocs de 10 Go et des prix de package commençant à des bundles mensuels plus importants. Les composants réseau tels que les pare-feu, les commutateurs et le commutateur en tant que service sont facturés comme des éléments mensuels supplémentaires. Cloud Server PRO propose des plans horaires, mensuels et annuels.
Ce menu peut être attrayant pour les équipes qui souhaitent une infrastructure régionale prévisible sans acheter de matériel.
Mais l’économie unitaire est plus large que les lignes de facture. Un client doit comparer Aruba Cloud avec au moins trois substituts. Le premier est l’hyperscaler. Les hyperscalers peuvent sembler plus chers pour le calcul et le stockage simples, mais ils peuvent réduire le temps d’ingénierie grâce à des bases de données gérées, à l’identité, à l’observabilité, aux outils de politique, à la mise en réseau privée, aux services de sécurité et à un écosystème énorme. Ils imposent également leur propre complexité, leurs coûts de sortie et leur verrouillage. Le deuxième substitut est le VPS non géré.
Il peut être moins cher et plus simple pour une petite application web, mais il manque souvent de la documentation de conformité et de récupération nécessaire aux acheteurs réglementés ou professionnels. Le troisième substitut est l’infrastructure détenue en propre. Elle offre un contrôle physique maximal, mais elle exige des dépenses d’investissement, des achats, la gestion des installations, des pièces de rechange, la sécurité, l’énergie et une main-d’œuvre qualifiée.
Aruba Cloud se situe entre ces alternatives. Sa documentation publiée convient le mieux aux clients qui veulent plus de structure qu’un VPS non géré et plus de clarté sur la localité européenne qu’une région par défaut mondiale, mais qui n’ont pas besoin du catalogue complet des hyperscalers. La valeur n’est pas seulement le prix du serveur. C’est la combinaison d’options de centres de données régionaux, d’une assistance documentée, de produits de sauvegarde et de récupération, d’artefacts de conformité, d’opérations de panneau de contrôle et d’API. Le coût est la nécessité de vérifier les limites opérationnelles de chaque service.
Il existe également des modes de défaillance de facturation. Une rétrogradation de ressources peut ne pas prendre effet immédiatement dans le cadre de certains plans prépayés. Les téléchargements multiparties du stockage objet peuvent laisser des fragments qui comptent dans le stockage si un problème interrompt le téléchargement et que les fragments ne sont pas nettoyés. Des IP publiques supplémentaires, des appareils réseau, le trafic sortant, la consultation du support et la rétention des sauvegardes peuvent modifier le coût réel.
Une courte fenêtre d’instantané peut obliger à utiliser un produit de sauvegarde distinct, ce qui ajoute un coût mais réduit le risque opérationnel. Une exportation assistée par le support peut être bon marché en conditions normales mais coûteuse en temps lors d’une sortie précipitée.
L’unité pratique d’analyse devrait être un changement, pas un serveur. Combien coûte le provisionnement correct de la charge de travail, sa surveillance, sa sauvegarde, sa restauration une fois lors d’un test, son redimensionnement après des changements de demande, l’exportation de ses données et sa fermeture sans ressources orphelines? Ce chiffre est plus difficile à calculer que le vCPU et la RAM mensuels, mais il est plus proche de la réalité.
Pour un acheteur européen, la valeur commerciale d’Aruba Cloud est la plus forte lorsque la réponse est inférieure à celle de l’infrastructure détenue en propre et moins exposée opérationnellement que l’hébergement non géré, tout en restant plus claire sur la localité qu’un déploiement hyperscaler générique.
Modes de défaillance qui importent
Les modes de défaillance connus pour Aruba Cloud DE ne sont pas exotiques. Ce sont des modes de défaillance cloud ordinaires rendus plus conséquents par les attentes de localité et de conformité.
Le premier est l’ambiguïté de région ou de résidence. Un client peut sélectionner un service en croyant qu’il est allemand, italien ou globalement européen sans conserver la preuve exacte de l’emplacement. Plus tard, une sauvegarde, un journal, un processus d’assistance ou un chemin de migration peut se situer en dehors de l’hypothèse initiale. La prévention n’est pas un slogan. C’est un enregistrement de localité par service.
Le deuxième est l’erreur de provisionnement. Un mauvais hyperviseur, un mauvais modèle, une mauvaise configuration IP, un mauvais plan tarifaire ou une mauvaise taille de disque peut coûter cher à défaire. Certains choix ne peuvent pas être modifiés ultérieurement. D’autres nécessitent un temps d’arrêt, un timing de renouvellement ou des décisions à risque pour les données. La prévention est une approbation des changements qui traite les options de provisionnement comme de l’architecture.
Le troisième est l’incident de stockage ou la confusion sur la perte de données. Le stockage redondant protège contre certaines défaillances matérielles. Il ne protège pas contre toutes les erreurs du client. Les instantanés sont de courte durée et limités. Les travaux de sauvegarde nécessitent des mots de passe, des calendriers et des tests de restauration. La prévention est un exercice de restauration qui prouve que le client peut récupérer l’état souhaité, et pas seulement voir un objet de sauvegarde.
Le quatrième est l’échec de restauration de sauvegarde. Une restauration au niveau des fichiers peut écraser, conserver ou renommer les fichiers existants. Une restauration bare-metal peut être bloquée par des informations d’identification manquantes. Un plan de reprise après sinistre peut échouer si le site de récupération ne contient pas les dépendances applicatives. La prévention consiste à tester le chemin de restauration exact qui sera utilisé en production.
Le cinquième est la dérive IAM et des accès. La documentation publique d’Aruba souligne la responsabilité partagée, les panneaux de contrôle, les clés API et la gestion par le client. Si les clés API sont créées sans rotation, que les comptes d’assistance sont partagés ou que les administrateurs partent sans révocation, les contrôles de la plateforme du fournisseur ne peuvent pas résoudre le problème seuls. La prévention est une gouvernance des identités qui inclut les comptes Aruba et les systèmes du client.
Le sixième est la panne réseau ou le changement de chemin inattendu. Les preuves de peering public fournissent un contexte utile, mais le trafic applicatif dépend toujours des routes, des opérateurs, du DNS, des pare-feu et de la configuration du client. La prévention est une surveillance externe depuis les marchés qui importent, ainsi qu’un comportement de basculement enregistré.
Le septième est le litige de mesure. L’économie du cloud dépend des blocs de stockage, du trafic sortant, des plans de ressources, du timing de renouvellement et des artefacts orphelins. La prévention est un rapprochement de routine des coûts et des vérifications de suppression après les tests, les échecs de téléchargement et les migrations.
Le huitième est le retard d’assistance ou l’inadéquation des tickets. Si les preuves du client sont incomplètes, la conversation d’assistance ralentit. Si le problème est en dehors de la surveillance confirmée du fournisseur, les crédits peuvent ne pas s’appliquer. La prévention est une surveillance interne horodatée, des identifiants de service et un processus clair de gravité.
Le neuvième est l’échec de retour arrière de migration. Une équipe peut migrer vers Aruba Cloud mais manquer d’un chemin de sortie testé. La prévention est la classification de l’exportation avant la migration: quelles données peuvent être exportées par le client, lesquelles nécessitent des API, lesquelles ont besoin d’assistance, et quel service a une exportation ordinaire limitée.
Ces défaillances ne rendent pas Aruba Cloud inadapté. Elles définissent le travail nécessaire pour bien l’utiliser.
Preuves de marché et limites d’incertitude
Le contexte du marché soutient la demande pour la proposition d’Aruba Cloud, mais il ne garantit pas son résultat. Eurostat a rapporté que 52,74 % des entreprises de l’UE utilisaient des services de cloud computing payants en 2025, l’Italie à 75,6 % et les grandes entreprises à 84,67 %. Parmi les entreprises utilisant le cloud payant, une grande majorité a acheté au moins un service IaaS. Cela signifie que le marché adressable pour l’infrastructure régionale est réel. Cela signifie également que la base d’acheteurs est de plus en plus sophistiquée. Le cloud n’est plus seulement un remplacement d’hébergement bon marché.
Il devient une couche de dépendance pour la sécurité, les bases de données, la livraison de logiciels, les enregistrements commerciaux et les services réglementés.
Dans le même temps, Synergy Research a décrit un marché européen du cloud où les fournisseurs locaux ont augmenté leurs revenus mais ne détiennent qu’environ 15 % du marché européen, tandis qu’Amazon, Microsoft et Google ont le plus profité de la croissance globale. Cela crée une position difficile pour des fournisseurs comme Aruba Cloud. L’argument de souveraineté est plus fort qu’il y a dix ans, mais la gravité opérationnelle des hyperscalers est également plus forte. Les développeurs connaissent leurs outils. Les équipes d’achat connaissent leurs remises. Les intégrateurs connaissent leurs architectures de référence.
Un fournisseur régional européen doit donc gagner sur des charges de travail spécifiques, et non dans l’abstraction cloud.
Les charges de travail les mieux adaptées sont celles où la localité, la prévisibilité des coûts, l’accès à l’assistance et la familiarité avec l’infrastructure l’emportent sur le besoin d’une large gamme de services gérés. Parmi les exemples figurent les applications web européennes, les portails clients, les référentiels de sauvegarde, les composants SaaS régionaux, les environnements proches de VMware, les petites plateformes de données, les charges de travail d’agences, les systèmes de fournisseurs du secteur public et les parcs de fournisseurs de services. La caractéristique commune n’est pas le secteur.
C’est que la charge de travail peut être décrite proprement en termes de calcul, de stockage, de réseau, de sauvegarde et d’assistance.
La moins bonne adéquation est une charge de travail qui dépend fortement des bases de données gérées natives des hyperscalers, des plateformes d’IA, des systèmes d’événements, des intégrations d’identité, de la diffusion de contenu mondiale, des modèles complexes sans serveur ou d’une architecture active-active multinationale. Aruba Cloud a un ensemble de services en croissance, mais les preuves disponibles dans la documentation publique ne permettent pas de le considérer comme un remplacement un pour un des plus grands catalogues cloud mondiaux. Un acheteur ne devrait pas exiger cela.
La meilleure question est de savoir si Aruba Cloud peut exploiter la charge de travail sélectionnée avec moins d’ambiguïté juridictionnelle et un contrôle technique suffisant.
L’incertitude demeure dans plusieurs domaines. Les pages publiques ne prouvent pas les taux réels de réussite des restaurations des clients. Elles ne montrent pas le temps de réponse moyen du support par gravité. Elles ne fournissent pas un historique complet des incidents publics pour chaque service. Elles ne prouvent pas l’emplacement exact de chaque sauvegarde, journal ou élément de métadonnées spécifique au client. Elles ne montrent pas les performances comparatives en charge. Elles ne montrent pas à quelle fréquence les clients ont besoin d’une exportation assistée par le support ni combien de temps ces exportations prennent.
Ce ne sont pas des accusations. Ce sont les limites normales de la recherche publique. Un acheteur sérieux devrait les combler par des questions d’approvisionnement, des déploiements pilotes et des tests de restauration.
Le test opérationnel de l’acheteur
Un client évaluant Aruba Cloud DE devrait exécuter une séquence d’acceptation pratique avant d’y déplacer des travaux critiques. La séquence devrait commencer par l’identité et la portée. Confirmer que le fournisseur est Aruba Cloud sous Aruba S.p.A. et non HPE Aruba Networking, qui utilise le nom Aruba sur un marché différent. Confirmer le service Aruba Cloud exact acheté ainsi que l’entité juridique, les conditions, la région et le canal d’assistance qui y sont attachés.
Ensuite, prouver la localité. Sélectionner la région ou l’option de centre de données prévue dans la commande de service. Capturer les preuves publiques et contractuelles de ce choix. Confirmer si le calcul, le stockage principal, le stockage de sauvegarde, les journaux, les données de surveillance, l’accès au support et les processus d’exportation partagent les mêmes hypothèses de localité. Là où ce n’est pas le cas, enregistrer la différence. Ceci est particulièrement important dans un contexte Allemagne-Italie car la marque, les preuves réseau et d’infrastructure s’étendent sur plus d’un pays.
Ensuite, provisionner une charge de travail représentative. Utiliser le même hyperviseur, modèle, version IP, modèle de disque, plan tarifaire, pare-feu et conception de surveillance que ceux que la production utilisera. Enregistrer les choix qui sont irréversibles. Enregistrer les changements qui nécessitent un arrêt. Créer un profil de route et de latence de référence depuis les marchés d’utilisateurs attendus. Confirmer le comportement DNS et les besoins de DNS inverse si pertinent.
La quatrième étape est la récupération. Créer une politique de sauvegarde, prendre un instantané avant un changement, restaurer un fichier vers un autre emplacement, exécuter un test d’écrasement contrôlé sur des données non productives, et effectuer une restauration complète ou un exercice de reprise après sinistre si la charge de travail le justifie. Stocker les mots de passe de restauration dans un système sécurisé contrôlé. Confirmer la différence entre les instantanés de courte durée et les sauvegardes durables. Confirmer qui est autorisé à initier une restauration.
La cinquième étape est la sortie. Utiliser la documentation d’exportation d’Aruba pour classer chaque composant: calcul, stockage, configuration réseau, journaux, données de sauvegarde et données de surveillance. Déterminer ce qui est en libre-service, ce qui est pris en charge par API, ce qui nécessite un guide et ce qui nécessite une assistance. Estimer combien de temps une sortie prendrait et ce qui serait perdu ou reconstruit. Faire cela avant que le service ne devienne critique pour l’activité.
La dernière étape est la répétition de l’assistance. Ouvrir le canal d’assistance approprié pour une question non critique, enregistrer les identifiants de service requis, et vérifier que la surveillance interne peut fournir des horodatages et des preuves. Examiner les mécanismes de crédit du SLA, les exclusions et les dispositions de maintenance afin que l’entreprise comprenne la différence entre un recours du fournisseur et une reprise d’activité.
Cette séquence d’acceptation peut sembler lourde pour un petit serveur. C’est là l’essentiel. Si la charge de travail est petite et non critique, Aruba Cloud peut être utilisé comme un hébergement ordinaire. Si la charge de travail est sensible à la localité, réglementée ou commercialement importante, le coût d’acceptation fait partie de l’achat. Un fournisseur de cloud régional ne peut pas supprimer ce travail. Il peut rendre le travail possible en publiant des documents techniques, juridiques et d’assistance utilisables.
Le verdict opérationnel
La plus grande valeur d’Aruba Cloud DE n’est pas d’être européen au sens large. Sa valeur la plus forte est qu’un client peut assembler un bilan opérationnel européen concret à partir d’éléments publics: la position d’infrastructure italienne d’Aruba Cloud, le réseau de centres de données européen, les preuves de routage allemand, les documents de protection des données, les références CISPE et de certification, les conseils de panneau de contrôle, les procédures de sauvegarde et de restauration, la documentation API et d’exportation, et un SLA public.
Ce bilan est suffisamment bon pour justifier une évaluation sérieuse par les PME européennes, les développeurs, les fournisseurs de services et les organisations réglementées qui souhaitent une alternative cloud régionale.
La mise en garde est tout aussi claire. Le même bilan montre que de nombreux contrôles décisifs restent entre les mains du client. La sélection de l’hyperviseur peut être persistante. Les instantanés sont étroits et de courte durée. La restauration de sauvegarde dépend de mots de passe, de choix et de tests. L’exportation de données est inégale d’un service à l’autre. Les crédits d’assistance ne sont pas une continuité d’activité. Les preuves réseau sont utiles mais ne garantissent pas les performances. Les revendications de conformité doivent être mises en correspondance service par service.
Cela fait d’Aruba Cloud DE un fournisseur pour acheteur discipliné. Il récompense les équipes qui savent ce qu’elles déplacent, peuvent décrire où cela doit résider, peuvent tester comment cela récupère, peuvent surveiller comment cela atteint les utilisateurs, et peuvent conserver suffisamment de preuves pour étayer un audit ou un examen d’incident. Il est moins indulgent pour les équipes qui veulent que l’expression « cloud européen » fasse le travail opérationnel toute seule.
Sur le marché européen du cloud, c’est une niche défendable. Les hyperscalers garderont leur force d’attraction. Les fournisseurs de VPS non gérés garderont leur attrait tarifaire. L’infrastructure détenue en propre gardera son attrait de contrôle. Aruba Cloud DE est le plus crédible là où l’acheteur veut de la localité, une infrastructure reconnaissable, des produits de récupération documentés et un contexte d’assistance européen sans assumer l’exploitation complète d’un centre de données.
Sa valeur se décide dans la tâche répétée: modifier la charge de travail, récupérer l’état, vérifier la route, comprendre la facture et garder l’enregistrement de localité intact. Si ces faits survivent, le fournisseur a livré plus qu’un catalogue cloud. Il a livré une surface d’exploitation qu’un client européen peut effectivement gouverner.