Résumé
- Asten Cloud est une société française de cloud et d'hébergement opérationnelle selon les registres publics: le service de recherche d'entreprises français répertorie ASTEN CLOUD comme une entreprise active à Gouesnou dans la gestion d'installations informatiques, le site propre d'Asten décrit deux centres de données dans la région de Brest, et les enregistrements RIPE montrent qu'ASTEN CLOUD SAS détient des ressources de numéros de systèmes autonomes.
- Les preuves physiques les plus solides sont de première partie mais concrètes. Asten indique que son cloud privé repose sur deux centres de données français, 300 mètres carrés d'espace d'hébergement en salle blanche, plus de 1 000 serveurs physiques et virtuels hébergés, et une offre de housing avec 48 racks, une alimentation et un refroidissement redondants, un choix d'opérateurs télécom, un accès contrôlé et un accès au site 24h/24 et 7j/7.
- Le tableau de routage est mitigé plutôt que faible. AS199727, détenu en tant qu'ASTEN CLOUD SAS, est actuellement visible via RIPEstat avec sept annonces IPv4 /24 et une IPv6 /31, tandis qu'AS206308, l'ASN nommé « asten-cloud-bretagne », est enregistré mais non annoncé. Le signal réseau public soutient donc l'exploitation actuelle d'Asten, mais pas l'affirmation simple que l'ASN nommé Bretagne transporte lui-même le trafic client.
- La sauvegarde et la reprise sont plus qu'une note marketing ici. Asten décrit une sauvegarde basée sur Commvault répartie sur deux centres de données français, une rétention longue, une option bande via un robot dans un centre de données, des tests de restauration périodiques, une analyse d'impact sur l'activité et un service de plan de reprise formel. Ces affirmations réduisent certains risques pour le client, mais elles ne publient pas de RTO, de RPO au niveau des charges de travail, de résultats de tests de basculement ni la capacité restante après la perte d'un centre de données.
- Le niveau de preuve est moyen. L'enregistrement légal, les pages de certification, le routage actif et les pages de service détaillées rendent l'entreprise matériellement vérifiable, mais les archives publiques n'exposent toujours pas les adresses exactes des sites, l'occupation réelle des racks, la séparation des chemins de transport, l'autonomie des groupes électrogènes, la répartition des clients, la profondeur du personnel de support ou les résultats de reprise mesurés.
L'entreprise est visible, mais l'actif reste local
La manière pertinente d'appréhender asten-cloud-bretagne ASTEN CLOUD SAS n'est pas celle d'une plateforme hyperscale aux régions abstraites. Il s’agit d’un opérateur d’hébergement régional français dont la proposition de valeur publique est précisément que les systèmes des clients restent proches de la Bretagne, du droit français et des bureaux de support d’Asten. Leservice français de recherche d'entreprisesidentifie ASTEN CLOUD sous le SIREN 323789990, avec un siège social actif à Gouesnou et un code d'activité pour la gestion d'installations informatiques. Ce signal du registre importe, car une page de service cloud sans ancrage juridique peut n’être guère plus qu’une vitrine commerciale. Ici, l’entreprise a une présence opérationnelle enregistrée qui correspond au récit du cloud breton.
La proprepage cloudd'Asten est inhabituellement concrète pour une offre cloud. Elle indique qu'Asten Cloud héberge les données sur sa propre infrastructure en France, spécifiquement en Bretagne, et décrit deux centres de données souverains dans la région de Brest, 300 mètres carrés d'espace d'hébergement en salle blanche et plus de 1 000 serveurs physiques et virtuels hébergés. Elle présente également le service comme un cloud privé certifié plutôt qu’un emballage de revente autour d’un cloud public étranger. Cela ne prouve pas chaque charge de travail client, mais constitue une affirmation d’actifs concrète: des salles, des racks, des serveurs et du personnel opérationnel doivent exister derrière le catalogue de services.
Lapage historiquede l'entreprise aide à expliquer comment cette empreinte s'est développée. Asten indique que le groupe a été fondé en 1995, a racheté STTG en 2008, est devenu propriétaire de son premier centre de données, a créé le centre de données WhiteBox en 2013, a acheté un nouveau centre de données à Brest en 2018 pour la colocation, a obtenu la certification ISO 27001 en 2019, la certification HDS en 2020 et est devenu opérateur télécom la même année. Elle fournit également des indicateurs d'échelle: deux centres de données en Bretagne, environ 140 experts, 350 clients et 16,5 millions d'euros de chiffre d'affaires. Ces chiffres sont des déclarations de première partie, donc ils ne doivent pas être considérés comme une utilisation auditée des capacités, mais ils rendent l'entreprise bien moins opaque qu'une simple coquille administrative.
La zone de service est nationale dans le discours commercial et régionale dans la logique d'infrastructure. Asten affirme que son expertise est déployée à travers la France et au-delà, mais son argument d'hébergement est ancré dans les centres de données français du Finistère. Lapage d'hébergementdécrit deux centres de données français basés dans le Finistère et présente l'offre comme un hébergement souverain pour les données qui doivent rester sous juridiction française et européenne. Pour un client en Bretagne, un opérateur proche peut raccourcir le chemin d'escalade et rendre les visites sur site plus plausibles. Pour un client hors de la région, la localisation importe toujours, mais la dépendance se déplace vers les liaisons longue distance, le support à distance et la résilience des chemins de transit et d'accès client d'Asten.
Cette géographie est la première contrainte opérationnelle. Asten peut vendre de la capacité cloud comme un service, mais son offre est liée à une base d'actifs régionaux finie. Deux centres de données peuvent constituer un schéma de résilience significatif s'ils sont suffisamment indépendants physiquement, électriquement et opérationnellement. Ils peuvent aussi former un cluster à destin partagé si les deux sites dépendent du même corridor de transport, de la même équipe de maintenance, de la même alimentation en carburant, du même calendrier de changements ou du même stock fournisseur.
Les pages publiques prouvent qu'Asten commercialise deux sites; elles ne publient pas d'arbre de défaillance de site à site.
Les racks transforment la promesse cloud en test de capacité
La page publique de capacité la plus spécifique est l'offre de housingd'Asten. Elle indique que les clients peuvent placer des serveurs physiques dans des centres de données sécurisés, choisir entre des tiers de rack et des racks complets, utiliser des racks de 800 par 1200 millimètres avec 48U chacun, et bénéficier d'une puissance incluse de 1 kVA ou 3 kVA selon l'option. Elle précise également que le centre de données dispose de 48 racks, d'une alimentation électrique sécurisée et redondante de 175 kVA, d'un refroidissement redondant, d'un accès biométrique, de digicodes, de verrous, de détection et d'extinction d'incendie, d'une surveillance 24h/24 et 7j/7 et d'un accès client permanent. Ces détails sont exactement le type de faits qui transforment la « capacité hébergée » en quelque chose de testable.
Ils montrent aussi pourquoi la capacité installée et la capacité utilisable sont différentes. Quarante-huit racks est une mesure de surface au sol. Cent soixante-quinze kVA est une mesure de capacité électrique. Trois cents mètres carrés est une mesure de salle. Plus de 1 000 serveurs hébergés est une affirmation d'inventaire ou d'échelle de service.
Aucun de ces chiffres, à lui seul, ne dit à un client combien de capacité excédentaire reste disponible aujourd'hui, quelle part de la centrale électrique est engagée, quelle marge de refroidissement est réservée, ou ce qui se passe si un site est indisponible et que la capacité survivante doit absorber les charges de travail protégées. Un rack peut être présent mais plein. Un onduleur peut être installé mais limité par l'autonomie des batteries. Un second centre de données peut exister mais manquer de capacité de calcul froide suffisante pour prendre en charge toutes les charges de travail client simultanément.
La page de housing indique que le centre de données est ouvert à différents opérateurs télécom. C'est un bon langage pour le choix du client, car un seul point de terminaison opérateur peut devenir le point commun caché dans une conception d'hébergement par ailleurs redondante. Cependant, « ouvert à différents opérateurs » n'est pas la même chose que de nommer les transporteurs actifs, les entrées diversifiées, les conduits séparés, les salles de rencontre indépendantes ou le basculement testé.
La dépendance physique centrale de l'offre est exactement ici: un client peut externaliser des serveurs chez Asten et rester exposé à la disponibilité des racks, au délai d'approvisionnement des interconnexions, à la maintenance des opérateurs, à la panne d'un routeur et à la fenêtre pratique de réparation d'un port défaillant.
Leportefeuille d'hébergementd'Asten couvre le housing, l'hébergement partagé, l'hébergement HDS, l'hébergement d'applications et l'hébergement de conteneurs. Cette étendue suggère plus d'un modèle d'exploitation. Un client de housing peut posséder ses serveurs et demander à Asten de fournir l'espace, l'alimentation, le refroidissement, la sécurité et l'accès au réseau. Un client d'hébergement partagé peut consommer des serveurs virtuels sur l'infrastructure d'Asten. Un éditeur de logiciels peut dépendre d'Asten à la fois pour l'hébergement et l'exploitation gérée. Un client de conteneurs peut se préoccuper davantage de l'orchestration de la plateforme et de la disponibilité du registre que de la disposition physique des racks. La même panne de centre de données ou d'opérateur affecte chaque client différemment car la responsabilité est divisée différemment à chaque couche.
La tension économique centrale est qu'Asten vend l'affranchissement de la construction d'une salle informatique privée, mais elle doit financer la salle partagée qui remplace de nombreuses salles client. C'est un compromis classique de l'économie de l'hébergement: les clients évitent les dépenses d'investissement, le travail de conformité et les soucis d'alimentation et de refroidissement locaux, tandis que le fournisseur concentre suffisamment de demande pour exploiter des salles sécurisées, des opérations avec personnel et des systèmes redondants. Le fournisseur doit ensuite éviter de survente des ressources rares.
Les preuves publiques permettent à un acheteur de poser des questions pointues, mais n'y répondent pas entièrement: le remplissage actuel des racks, la puissance engagée par rapport à la puissance de pointe, la redondance du refroidissement dans des conditions extérieures maximales, le stock de serveurs de rechange, les délais de remplacement du matériel et le coût du maintien d'une capacité de récupération vide ne sont pas publiés.
La certification resserre la promesse, mais ne supprime pas la machinerie
Asten s'appuie fortement sur la certification, et les pages publiques rendent le périmètre plus clair qu'un simple badge ne le ferait. Lapage des certificationsindique qu'Asten Cloud est certifiée ISO 27001 pour l'hébergement, les services gérés et le support utilisateur. Elle décrit également la certification HDS pour les activités d'hébergement d'infrastructure physique et d'hébergement géré, y compris les six domaines d'activité HDS couvrant les sites physiques, l'infrastructure matérielle, l'infrastructure virtuelle, les plateformes applicatives, l'administration/exploitation et les sauvegardes externalisées. Lapage d'hébergement HDSreprend le cadrage en six domaines et précise que le service s'adresse aux clients de la santé et du médico-social ainsi qu'aux éditeurs de logiciels.
C'est important car HDS n'est pas simplement un slogan sur la sécurité. Cela lie la promesse d'hébergement à des charges de travail sensibles où l'emplacement, le contrôle d'accès, la traçabilité, l'administration et la sauvegarde comptent. La page HDS d'Asten indique que son hébergement de données de santé évite les transferts de données personnelles de santé hors de l'Espace économique européen.
En termes clients, il s'agit d'une promesse de localisation superposée à l'exploitation des installations: les données doivent résider dans des centres de données français, sous protection juridique européenne, gérées par des processus certifiés, et sauvegardées par des services contrôlés. Si l'une de ces couches dérive, la valeur du service change.
La certification, cependant, ne rend pas la capacité infinie ni les pannes impossibles. ISO 27001 indique un système de management de la sécurité de l'information. HDS indique la conformité pour les activités d'hébergement de données de santé. Aucune page ne publie le temps de récupération par client, le nombre d'ingénieurs de garde, le temps moyen de remplacement d'une étagère de stockage défaillante, le calendrier de maintenance des commutateurs partagés, ou la distance géographique réelle et la séparation des chemins de transport entre les deux centres de données.
La certification réduit le risque d'improvisation; elle n'efface pas la dépendance physique à l'égard de l'alimentation, du refroidissement, du matériel, des personnes et des liaisons.
L'offre destinée au secteur public ajoute un autre signal de demande. La page d'Asten pour lescollectivités et établissements publicsindique que le groupe a été retenu pour le lot Bretagne du cadre de cloud et d'hébergement CANUT. Elle présente la colocation, l'hébergement partagé, l'hébergement géré, la sauvegarde, la connectivité et la téléphonie pour les entités publiques. Cela importe car les clients du secteur public apportent souvent des exigences formelles d'approvisionnement, de continuité et des préférences de souveraineté des données. Cela augmente également le coût d'une conception de reprise faible: une panne pourrait affecter une municipalité, une école, un organisme public ou un fournisseur de services local, et pas seulement un environnement de test privé.
La bonne conclusion n'est donc ni le cynisme ni la crédulité. Les certifications d'Asten et son positionnement secteur public sont des signaux significatifs, étayés par des sources, d'une posture opérationnelle sérieuse. Ils justifient un niveau de confiance plus élevé que celui qui serait approprié pour un revendeur à page unique. Mais ils ne se substituent pas à la diligence raisonnable du client.
L'acheteur a encore besoin de la déclaration de périmètre, des dates de validité des certificats, des services exclus, de la liste des sous-traitants, de l'emplacement des sauvegardes, du processus de notification d'incident et de la preuve que la charge de travail contractuelle se situe à l'intérieur du périmètre certifié.
Les preuves de routage distinguent l'exploitation d'Asten de l'ASN Bretagne
L'enregistrement réseau présente une distinction curieuse mais utile. L'ASN nommé pour l'objet de la recherche, AS206308, est enregistré dans RIPE en tant qu'asten-cloud-bretagne ASTEN CLOUD SAS. Les informations du titulaire le relient à ASTEN CLOUD SAS et à des adresses à Gouesnou et dans la région brestoise. Pourtant, lavue d'ensemble RIPEstat pour AS206308le signale comme non annoncé, et lavue de l'état de routagene montre aucun préfixe IPv4 ou IPv6 visible, ni aucun voisin observé au moment de la collecte. Cela ne signifie pas qu'Asten Cloud est hors ligne. Cela signifie que l'ASN nommé Bretagne n'est pas le transporteur de routes public dans les preuves de routage disponibles.
Les preuves de routage en direct pointent plutôt vers AS199727. Le RDAP RIPE répertorieAS199727sous le nom « asten-cloud-idf » pour ASTEN CLOUD SAS, et lavue d'ensemble AS RIPEstatle signale comme annoncé. Sonétat de routagemontre une visibilité IPv4 complète à travers les pairs RIPE RIS et une visibilité IPv6 substantielle. Lerésultat des préfixes annoncésmontre sept IPv4 /24 et un IPv6 /31 visibles dans la fenêtre d'observation actuelle, tandis que lesdonnées de voisins ASNmontrent deux voisins observés: AS174 et AS12645.
Ces deux faits doivent être considérés ensemble. D'un côté, Asten dispose d'une infrastructure de routage active. De l'autre, l'ASN dont le nom contient « bretagne » est silencieux. Un article simpliste pourrait gommer cette distinction et affirmer « Asten Cloud a un ASN ». Une meilleure analyse de l'infrastructure demande pourquoi l'ASN régional nommé est enregistré mais non visible, s'il est réservé pour une conception qui n'est pas actuellement utilisée, si le trafic client se trouve derrière AS199727, et si la configuration à deux ASN reflète des choix de site, d'héritage, de produit ou d'ingénierie de trafic.
Les collecteurs de routes publics ne répondent pas à cette question.
Les noms de préfixes donnent aussi des indices sur les fonctions de service sans prouver le placement client. Le RDAP RIPE identifie185.189.172.0/24comme « HEBERGEMENT »,185.189.173.0/24comme « HEBERGEMENT_SEC2 »,185.189.174.0/24comme « HEBERGEMENT_SEC »,185.37.43.0/24comme « HEBEGEMENT-SEC »,185.37.41.0/24comme « K8S », et185.37.42.0/24comme « HORS-VDOM-INTERNET ». Ces étiquettes sont des indices publics utiles: hébergement, hébergement sécurisé et une dénomination évoquant Kubernetes apparaissent dans l'espace d'adressage contrôlé par Asten. Elles ne révèlent pas la salle de données, le locataire client, le VLAN, la zone de pare-feu ou le niveau de résilience derrière une IP particulière.
Le risque de dépendance au routage n'est donc pas de savoir si Asten peut être vue sur Internet. Elle le peut. Le risque est de savoir si les clients connaissent l'organisation réelle du transit, du chemin et du basculement utilisée par leur charge de travail. Deux voisins de routage observés valent mieux qu'un, mais la diversité des voisins BGP n'est pas la même chose que la diversité des chemins de fibre. Deux sessions peuvent toujours partager un conduit, une entrée de bâtiment, un routeur, une fenêtre de maintenance ou une dépendance commerciale.
Un client à haute disponibilité devrait demander les noms des transporteurs, les points de remise, la diversité des routes, la politique de basculement, les délais de préavis de maintenance, la gestion DDoS, la posture RPKI/IRR et les preuves d'un exercice de basculement récent.
La sauvegarde réduit le risque de perte de données, mais la reprise a toujours un délai
Lapage de sauvegarde et de reprised'Asten est l'une des pages les plus solides de l'ensemble de preuves car elle nomme à la fois le mécanisme et la réflexion sur les pannes. Elle indique qu'Asten Backup utilise Commvault, stocke les sauvegardes dans deux centres de données français, offre une rétention longue personnalisable, peut ajouter une sauvegarde sur bande via un robot dans un centre de données, et utilise des concepts de sauvegarde déconnectés ou isolés pour résister aux cyberattaques. Elle précise également que l'offre inclut des tests de restauration périodiques dans un environnement isolé, des services de plan de reprise, une analyse d'impact sur l'activité et un plan de reprise écrit piloté par une expertise sécurité.
C'est un bon point de départ pour la tâche de redondance. La sauvegarde n'est pas simplement un autre volume de stockage à côté de la production; Asten décrit plusieurs supports, une logique hors site, des tests de restauration et une planification de reprise. La couche optionnelle sur bande est particulièrement pertinente pour les rançongiciels, car une réplique en ligne peut fidèlement répliquer la corruption, le chiffrement ou la suppression. Une rétention longue est utile lorsque la compromission est découverte des semaines ou des mois après la première intrusion.
Les tests de restauration sont importants car une sauvegarde qui ne peut pas être restaurée n'est pas une capacité de récupération.
L'écart restant est l'horloge de service. La page ne publie pas d'objectifs de RPO ou de RTO par défaut pour chaque classe de charge de travail. Elle n'indique pas combien de restaurations client simultanées peuvent s'exécuter lors d'un incident régional, comment le trafic de sauvegarde est limité en débit, si les dépôts de sauvegarde partagent le même fournisseur de stockage que la production, ou si le robot à bande protège tous les clients ou seulement ceux qui achètent une option. Elle n'explique pas non plus comment une restauration est priorisée si de nombreux clients appellent pendant la même panne.
Un client peut croire que « sauvegarde dans deux centres de données » signifie une continuité rapide; le résultat réel dépend du périmètre contractuel, de l'automatisation, du débit réseau, de la capacité de la salle blanche, de la disponibilité du personnel et des dépendances applicatives.
La différence entre protection des données et continuité de service est facile à manquer. Si un serveur physique tombe en panne, une sauvegarde peut restaurer les données mais pas l'environnement de calcul exact, l'état des licences, la règle de pare-feu, le paramètre DNS ou la dépendance applicative. Si un centre de données devient indisponible, une sauvegarde sur un second site peut préserver les données mais nécessiter encore du calcul, du stockage, une accessibilité IP et un séquencement applicatif avant le retour des utilisateurs.
Si une cyberattaque compromet les systèmes d'identité, les données de sauvegarde peuvent exister, mais l'accès privilégié et les décisions de confiance deviennent le goulet d'étranglement. Un plan de reprise résilient doit chorégraphier les personnes et les dépendances, pas seulement copier des blocs.
Le catalogue de services d'Asten reconnaît en partie cela en associant la sauvegarde aux services gérés et à la planification de reprise. La tâche de vérification de l'acheteur est de transformer le catalogue en preuves: date du dernier test de restauration réussi, liste des charges de travail testées, durée de restauration mesurée, cartographie des dépendances, récupération de l'authentification, étapes de basculement réseau, validation post-restauration, et un décideur nommé pour la déclaration d'urgence. La page publique soutient l'affirmation selon laquelle la reprise fait partie de l'offre d'Asten.
Elle ne permet pas à des tiers de calculer à quelle vitesse un client particulier revient.
La main-d'œuvre de support est aussi une ressource de capacité
Les pannes cloud sont souvent décrites comme des événements techniques, mais la réparation est effectuée par des personnes. Lapage des services gérésd'Asten indique que son offre peut couvrir l'infrastructure client sur site, dans le centre de données d'Asten ou sur des plateformes partagées. Elle décrit des systèmes de supervision, une surveillance continue, des alertes en temps réel, la correction des alertes, les mises à jour de sécurité et les correctifs d'urgence pour les vulnérabilités critiques. Elle précise également que le service peut combiner le support sur site avec des ressources externalisées hébergées sur les serveurs d'Asten. C'est la couche opérationnelle qui transforme une salle de serveurs en un service géré.
Lapage du contrat de supportajoute un détail plus prosaïque mais important: les demandes hors périmètre des services gérés peuvent être traitées via un contrat de support à points, avec des techniciens de niveau 1 escaladant vers les ingénieurs et experts de niveaux 2 et 3. Cela importe dans un chemin de défaillance car toutes les pannes ne commencent pas à l'intérieur du cœur d'Asten. Un changement d'application client, une expiration de certificat, une demande de pare-feu, une tâche de configuration mineure ou une intervention matérielle peuvent se situer à la frontière entre les opérations incluses et le support payant. Si cette frontière n'est pas claire pendant une panne, la réparation ralentit.
La main-d'œuvre de support a le même problème d'utilisation que les racks. La page historique d'Asten indique que le groupe compte environ 140 experts, mais les registres publics ne décomposent pas ce chiffre par opérations cloud, sécurité, travail de terrain, centre d'assistance, spécialistes applicatifs, managers ou fonctions administratives. Une journée normale peut avoir suffisamment de personnel pour les alertes, les changements planifiés et les tickets clients.
Un incident simultané touchant l'hébergement, la sauvegarde, le réseau et les systèmes clients peut consommer les spécialistes plus vite que le centre de données ne consomme de l'électricité.
Les clients doivent donc traiter le support comme une ressource contractuelle. La question n'est pas seulement « le support est-il disponible? ». Il s'agit de savoir si le contrat définit les délais de réponse, les déclencheurs d'escalade, les niveaux de gravité, la couverture de garde, les gels de changements, les fenêtres de maintenance d'urgence, les responsabilités du client et le droit de demander des preuves après un incident. Les pages publiques d'Asten soutiennent une attente d'opérations gérées et de support multi-niveaux. Elles ne publient pas la profondeur exacte de la file d'attente ou le plan de personnel derrière cette attente.
Cela est particulièrement important pour les organismes publics et les charges de travail liées à la santé. La page HDS d'Asten décrit une surveillance 24h/24 et 7j/7 et une intervention rapide pour les environnements de données de santé. Une municipalité ou un éditeur de logiciels de santé peut avoir besoin de plus qu'une réponse à un ticket; il peut avoir besoin d'un pont d'incident documenté, d'un ordre de restauration prioritaire, d'un support de notification de confidentialité et de la preuve que les données restent dans le périmètre d'hébergement approuvé pendant les travaux d'urgence.
Le langage marketing public pointe dans cette direction, mais seuls le contrat et les procédures montreraient si cela est opérationnellement applicable.
La souveraineté est une limite opérationnelle, pas une étiquette décorative
La revendication de marché la plus forte d'Asten est la localisation. La page cloud principale indique que les données sont hébergées sur la propre infrastructure d'Asten en France, en Bretagne, sans cloud américain et sans sous-traitance dans cette affirmation cloud. La page d'hébergement indique que le cloud est souverain et sous droit français et européen. La page HDS indique que les données de santé ne sont pas transférées hors de l'Espace économique européen. La page secteur public avance la même logique pour les établissements publics bretons.
Ces affirmations font de la souveraineté des données et de la localisation l'un des sujets contrôlés corrects pour l'article.
Mais la souveraineté n'est pas la même chose que la simplicité. Un cloud local a toujours des fournisseurs de matériel, des éditeurs de logiciels, des opérateurs télécom, des technologies de sauvegarde, des produits de sécurité et des réseaux d'accès client. La page des services gérés d'Asten indique que, pour les exigences SecNumCloud, elle s'appuie sur OUTSCALE, une marque de Dassault Systemes, dans une approche souveraine hybride. Cela peut être une conception sensée pour les clients qui ont besoin d'une option cloud souverain qualifié.
Cela signifie également qu'un acheteur doit demander quelles charges de travail s'exécutent dans les centres de données bretons propres d'Asten, lesquelles s'exécutent dans un environnement OUTSCALE, quelles données circulent entre eux, et quels contrôles contractuels s'appliquent à chaque point.
Cette distinction n'est pas une critique; c'est la définition pratique de la localisation. Si un client achète un hébergement ordinaire, l'actif attendu peut être l'infrastructure d'Asten dans la région de Brest. Si un client achète un service souverain hybride, le périmètre de l'actif peut inclure les locaux client gérés par Asten, les centres de données d'Asten et les ressources OUTSCALE. Si un client achète une sauvegarde pour des données Microsoft 365, le service de production peut rester dans l'environnement de Microsoft tandis que les sauvegardes atterrissent dans les centres de données français d'Asten.
Le mot « souverain » ne peut pas être évalué tant que le chemin de service réel n'est pas tracé.
Il en va de même pour la juridiction légale. Les données stockées en France sous les règles françaises et européennes constituent une protection significative, mais l'accès opérationnel dépend encore des administrateurs, des fournisseurs de support, des systèmes de surveillance, de la gestion des clés de chiffrement et des procédures d'urgence. Les pages HDS et ISO d'Asten soutiennent l'idée que ces processus sont gérés dans le cadre de référentiels de sécurité formels.
Elles ne montrent pas quels journaux sont conservés, où les clés sont détenues, comment les administrateurs client sont authentifiés, ou comment le support transfrontalier des fournisseurs est restreint.
Un bon examen client devrait donc traiter la souveraineté comme un ensemble de points de preuve pratiques plutôt qu'un slogan. Où les données de production sont-elles stockées? Où les sauvegardes sont-elles stockées? Où les journaux de surveillance sont-ils stockés? Qui peut accéder à chaque couche? Les clés de chiffrement sont-elles contrôlées par le client, par le fournisseur ou partagées? Que se passe-t-il lorsque le matériel est retourné, réparé ou détruit? Quels sous-traitants peuvent toucher aux données ou aux métadonnées?
Les preuves publiques font d'Asten un fournisseur local crédible; le contrat doit encore prouver que la charge de travail réelle du client suit le chemin local.
Les chemins de défaillance convergent vers cinq goulets d'étranglement pratiques
Le premier chemin de défaillance est un problème de rack ou de stock de matériel. Les clients de housing peuvent posséder l'équipement, mais Asten fournit toujours la salle, le rack, l'alimentation, le refroidissement, l'accès et éventuellement une intervention physique. Un client d'hébergement partagé dépend plus directement de l'inventaire de serveurs d'Asten et du stock de remplacement. Le chiffre de 48 racks de la page de housing donne une limite de capacité visible.
Une panne matérielle sur un serveur client est étroite; une panne de refroidissement, de distribution électrique, de baie de stockage ou de commutateur partagé peut s'élargir rapidement. La récupération dépend des pièces de rechange, du support fournisseur, de la disponibilité de l'intervention à distance et de la capacité du client à approuver les changements.
Le deuxième chemin de défaillance est l'alimentation électrique. La page de housing indique que le centre de données dispose d'une alimentation électrique sécurisée, onduleuse et redondante de 175 kVA, avec des groupes électrogènes en soutien. Ce langage étaye une revendication de résilience électrique au niveau des installations. Elle ne publie pas l'autonomie des batteries, l'autonomie en carburant des groupes, le calendrier de maintenance, les résultats des tests de charge, la topologie de la chaîne électrique ni la marge restante lorsque les racks sont chargés.
Si Asten vend à la fois de l'hébergement de production et de reprise dans la même enveloppe électrique, la marge disponible après une défaillance de site devient une question économique et technique.
Le troisième chemin de défaillance est la défaillance du transit ou de la route. RIPEstat voit AS199727 comme actif et AS206308 comme inactif. Si le trafic client repose sur AS199727, sa diversité de transit et ses chemins physiques importent. Si un produit utilise une remise opérateur qui n'est pas visible dans le BGP public, la diligence raisonnable du client doit aller au-delà des pages ASN. Un préfixe visible peut disparaître en raison d'une panne de routeur, d'une erreur de politique de routage, d'une maintenance, d'un problème d'atténuation DDoS, d'une panne d'opérateur ou d'un litige commercial.
Un client cloud ressent tout cela comme un temps d'arrêt applicatif même si chaque serveur reste sain.
Le quatrième chemin de défaillance est l'escalade de support. Asten décrit la surveillance, la correction des alertes, les correctifs de sécurité et les niveaux de support. Lors d'un événement majeur, le goulet d'étranglement peut être le nombre de spécialistes capables d'intervenir en toute sécurité sur les pare-feu, les hyperviseurs, le stockage, les sauvegardes, le DNS, l'identité et les applications client. Si les clients du secteur public ou de la santé reçoivent une priorité, l'ordre de priorité doit être explicite.
Si un contrat de support à points couvre des travaux hors périmètre, la politique d'urgence doit indiquer si le décompte des points est suspendu pendant les incidents ou continue comme d'habitude.
Le cinquième chemin de défaillance est la migration et la portabilité. La proposition de valeur d'Asten demande aux clients de déplacer leurs données et systèmes dans ses centres de données ou environnements gérés. Partir ultérieurement peut nécessiter d'exporter des machines virtuelles, des bases de données, des sauvegardes, des règles de pare-feu, des zones DNS, des secrets applicatifs, l'historique de surveillance et la documentation d'accès. Les pages publiques d'Asten mettent l'accent sur la protection, la continuité et la localisation française.
Elles ne publient pas les formats de sortie standard, les frais d'exportation en masse, les délais de migration ou le support pour un rapatriement d'urgence. Un client devrait régler ces questions avant une défaillance du contrat fournisseur, pas pendant.
Qui est affecté lorsque ce système tombe en panne
Les parties affectées sont plus larges que ce que le mot « client » implique. Un client de housing peut être une entreprise locale qui a placé ses propres serveurs dans les racks d'Asten pour éviter de gérer une salle privée. Un client d'hébergement partagé peut être une petite ou moyenne entreprise dont les systèmes de comptabilité, de commande, d'identité ou de collaboration fonctionnent sur des serveurs gérés par Asten. Un éditeur de logiciels peut utiliser l'hébergement d'Asten pour servir ses propres clients, transformant un incident Asten en une panne applicative en aval.
Un organisme public utilisant l'offre liée au CANUT peut dépendre d'Asten pour des services aux citoyens ou administratifs. Un acteur de la santé ou du médico-social utilisant l'hébergement HDS peut avoir des obligations de disponibilité et de confidentialité des données des patients.
L'impact diffère également selon le type de défaillance. Une brève instabilité de l'opérateur peut couper l'accès web sans endommager les données. Une panne de stockage peut laisser les applications en ligne mais incohérentes. Une défaillance de sauvegarde peut être invisible jusqu'à ce qu'une restauration soit nécessaire. Un retard dans le support peut transformer un incident gérable en une panne prolongée. Une fenêtre de maintenance des installations peut être acceptable pour les systèmes batch mais inacceptable pour un portail de service public, un système de planification clinique ou un détaillant en période de pointe.
La meilleure posture client consiste à cartographier les dépendances avant de signer ou de renouveler. Quels services sont critiques pour la production? Lesquels fonctionnent dans les centres de données d'Asten, dans les locaux du client ou dans un environnement hybride? Lesquels sont sauvegardés vers le second centre de données? Lesquels ont des restaurations testées? Lesquels nécessitent des adresses IP fixes, des VPN, des règles de pare-feu ou des modifications DNS pendant la reprise? Quels utilisateurs appelleront Asten directement, et lesquels doivent appeler le propre centre de services du client?
Ces questions semblent procédurales, mais elles déterminent si une promesse de reprise devient un plan utilisable.
Les preuves publiques d'Asten sont suffisamment détaillées pour permettre aux clients de poser ces questions avec précision. Un fournisseur cloud vague peut éluder avec des abstractions. Asten a publié suffisamment d'informations sur les racks, les centres de données, la sauvegarde, le périmètre HDS, le support et le routage pour que les acheteurs puissent tester la revendication. Les pièces manquantes ne sont pas des signes que le service n'est pas sérieux; ce sont les détails opérationnels privés qu'un acheteur sérieux devrait demander.
Le test de l'acheteur est une cartographie des dépendances
L'exercice client le plus utile est de transformer les affirmations publiques d'Asten en une cartographie des dépendances pour le système spécifique déplacé ou protégé. Commencez par le service métier, pas par la machine virtuelle. Un portail municipal peut dépendre d'une interface web, d'un magasin de contenu, de l'identité, du DNS, de la messagerie, d'un connecteur de paiement et d'un contact du centre d'assistance.
Une application de santé peut dépendre de l'hébergement HDS, des sauvegardes chiffrées, de la fédération d'identité, des journaux d'audit, de l'accès VPN et d'un fournisseur capable de supporter l'application après qu'Asten ait restauré la plateforme de base. Un détaillant peut dépendre d'une base de données de point de vente, d'un système de stock, de terminaux de paiement, d'un accès internet depuis les magasins et d'intégrations nocturnes. Chaque service a un point de rupture différent.
Pour chaque dépendance, l'acheteur devrait demander si Asten possède la couche, la gère, ne fait que l'héberger, ou n'a aucun contrôle sur elle. Cette distinction est centrale pour le titre de l'article. La capacité hébergée peut échouer parce que la propre infrastructure d'Asten échoue. Elle peut aussi échouer parce que le serveur d'un client n'est plus sous garantie, qu'une application tierce ne peut pas être reconstruite, qu'un fournisseur de fibre manque un objectif de réparation, qu'un registrar de domaine bloque une modification DNS, ou qu'un incident de sécurité impose une décision de confiance manuelle.
Asten peut être le bon partenaire dans chaque cas, mais le contrat devrait rendre la frontière visible avant l'incident.
La cartographie devrait également séparer le support normal de l'autorité d'urgence. Pendant l'exploitation de routine, un client peut demander un changement de pare-feu, une extension de stockage ou une restauration via un chemin de ticket. Pendant un incident majeur, le même client peut avoir besoin d'une personne nommée capable d'approuver une déclaration de reprise, d'autoriser un basculement DNS, d'accepter des performances dégradées, de suspendre les services non essentiels et de communiquer avec les utilisateurs.
La page de support d'Asten montre une organisation de support structurée, mais l'acheteur a encore besoin de noms, de rôles, de délais d'escalade et de définitions de gravité. Un plan de reprise sans autorité de décision n'est qu'un inventaire.
La localisation des données devrait apparaître sur la même cartographie. Si la production s'exécute dans les centres de données bretons d'Asten, que les sauvegardes sont réparties sur deux centres de données français, et qu'un service lié à SecNumCloud utilise OUTSCALE sous gestion Asten, alors ce sont trois revendications de localisation différentes. Chacune mérite une ligne distincte: où réside la production, où résident les sauvegardes, où résident les journaux, d'où les administrateurs se connectent, où les clés de chiffrement sont conservées et où des copies d'urgence peuvent être créées.
Plus l'histoire de souveraineté d'Asten devient forte, plus il est important de prouver que chaque composant du service réel suit la même politique.
La cartographie des dépendances devrait inclure la capacité après une défaillance, pas seulement la capacité un jour normal. Une conception à deux sites peut être excellente si l'un ou l'autre site dispose de suffisamment de capacité de calcul, de stockage, de licences et de réseau de réserve pour supporter les services protégés. Elle peut être plus faible si le second site est conçu principalement pour le stockage de sauvegarde, des charges de travail critiques sélectionnées ou une reprise plus lente.
La page publique de sauvegarde d'Asten mentionne des tests de restauration périodiques et un second centre de données; le contrat devrait dire si l'environnement du client est censé s'y exécuter, combien de temps le déplacement prend, quelle performance est réservée, et quels autres clients sont en concurrence pour le même pool d'urgence.
Enfin, l'acheteur devrait exiger un chemin de sortie. Ce n'est pas une posture hostile; cela fait partie de la résilience. Un client qui ne peut pas quitter un fournisseur pendant un litige commercial, un changement stratégique ou une panne persistante n'a pas réduit sa dépendance, il l'a concentrée. Pour Asten, le test de sortie devrait couvrir l'exportation des machines virtuelles, l'exportation des sauvegardes, les extractions de bases de données, les clés de chiffrement, la configuration des pare-feu et VPN, les changements d'IP publiques, les zones DNS, la documentation de support et la preuve de suppression après le départ.
Un service véritablement bien géré devrait pouvoir décrire comment un client entre, survit à un incident et part sans perdre le contrôle de ses données.
Ce qui améliorerait les preuves
Le dossier public soutient aujourd'hui une évaluation de confiance moyenne. Il deviendrait plus solide si Asten publiait ou partageait des preuves sans risque pour le client de la conception à deux sites: séparation non sensible des sites, diversité des opérateurs, chemins d'alimentation indépendants, résultats de basculement testés, métriques de restauration des sauvegardes, plages RTO/RPO, procédures d'escalade d'urgence et support de sortie standard. Il serait également utile d'expliquer le rôle de AS206308 par rapport à AS199727.
Si l'ASN nommé Bretagne est réservé, historique ou utilisé uniquement dans des accords privés, le dire empêcherait les tiers de mal interpréter son statut public inactif.
Pour un client, la demande de preuves devrait être concrète. Demandez le dernier périmètre de certificat ISO et HDS, la matrice de services montrant quelles offres tombent dedans, la déclaration de localisation des données pour la production et la sauvegarde, la liste des sous-traitants pouvant affecter le service, et les responsabilités du client pendant une reprise. Demandez combien de chemins d'opérateurs entrent dans chaque site et s'ils sont physiquement diversifiés. Demandez comment les tests de sauvegarde sont planifiés, comment les échecs sont signalés, et si le client peut témoigner ou recevoir le résultat.
Demandez ce qui se passe si un centre de données est perdu pendant une semaine, pas seulement pendant une heure.
Il en va de même pour le coût. L'économie de l'hébergement d'Asten repose sur une infrastructure partagée, c'est pourquoi elle peut être attrayante pour les clients qui ne veulent pas construire leur propre salle sécurisée. Mais la résilience consomme de la capacité réservée. Un service bon marché sans marge de reprise réservée n'est pas équivalent à un service plus cher avec un basculement testé et une capacité de calcul de réserve. Les acheteurs devraient séparer l'hébergement de base, la sauvegarde, le PRA, les opérations gérées, les points de support et l'assistance à la migration au lieu de supposer qu'ils sont groupés.
Le jugement final est que la capacité d'Asten Cloud est suffisamment réelle pour être examinée. Ses documents publics ne ressemblent pas à un fournisseur disparu ou à un pur intermédiaire. Ils montrent une entreprise française légale, des revendications de centres de données bretons, un périmètre de certification, un espace d'adressage routé actif, des produits d'hébergement, des outils de sauvegarde et un ciblage du secteur public. La prudence de l'article est plus étroite: la dépendance opérationnelle du client n'est pas résolue par le mot cloud.
Elle se déplace dans les racks d'Asten, sa centrale électrique, ses choix de routes, ses dépôts de sauvegarde, sa file de support et ses contrats de reprise. C'est une proposition d'infrastructure respectable seulement si ces dépendances physiques et contractuelles sont mesurées avant la défaillance, et non découvertes pendant la fenêtre de réparation.