asten-cloud-bretagne ASTEN CLOUD SAS vend une capacité hébergée qui dépend toujours des baies, du transit et des fenêtres de maintenance

Résumé

• Asten Cloud est une société française de cloud et d'hébergement en activité dans les registres publics: le service de recherche d'entreprises français répertorie ASTEN CLOUD comme une société active à Gouesnou dans la gestion d'installations informatiques, le site d'Asten décrit deux centres de données dans la région de Brest, et les registres RIPE montrent ASTEN CLOUD SAS détenant des ressources de système autonome.
• Les preuves physiques les plus solides sont de première main mais concrètes. Asten affirme 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 d'hébergement avec 48 baies, alimentation et refroidissement redondants, choix d'opérateur télécom, accès contrôlé et accès au site 24h/24 et 7j/7.
• La situation du routage est mitigée plutôt que faible. AS199727, détenu sous ASTEN CLOUD SAS, est actuellement visible via RIPEstat avec sept annonces IPv4 /24 et un IPv6 /31, tandis que AS206308, l'ASN nommé « asten-cloud-bretagne », est enregistré mais non annoncé. Le signal réseau public soutient donc l'opération actuelle d'Asten, mais pas une simple affirmation selon laquelle l'ASN nommé Bretagne transporte lui-même le trafic client.
• La sauvegarde et la reprise sont plus qu'une note de bas de page marketing ici. Asten décrit une sauvegarde basée sur Commvault dans deux centres de données français, une rétention longue, une bande optionnelle 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 formel de plan de reprise. Ces affirmations réduisent certains risques clients, mais elles ne publient pas les RTO, RPO, résultats de tests de basculement ou la capacité restante après une perte de centre de données.
• Le niveau de preuve est moyen. L'enregistrement légal, les pages de certification, le routage en direct et les pages de services détaillées rendent l'entreprise matériellement vérifiable, mais le registre public n'expose toujours pas les adresses exactes des installations, l'occupation réelle des baies, la séparation des chemins de transport, la durée de fonctionnement des générateurs, la répartition des clients, la profondeur du personnel de support ou les résultats mesurés de la reprise.

L'entreprise est visible, mais l'actif reste local

La manière utile de lire asten-cloud-bretagne ASTEN CLOUD SAS n'est pas comme une plateforme hyperscale avec des régions abstraites. C'est un opérateur régional d'hébergement français dont la proposition de valeur publique est précisément que les systèmes clients restent proches de la Bretagne, du droit français et des bureaux de support d'Asten. Leservice de recherche d'entreprises françaisidentifie ASTEN CLOUD sous le SIREN 323789990, avec un siège social actif à Gouesnou et un code d'activité pour la gestion d'installations informatiques. Le signal du registre est important car une page de service cloud sans ancrage légal peut n'être guère plus qu'une vitrine commerciale. Ici, l'entreprise a une présence opérationnelle enregistrée qui correspond à l'histoire du cloud breton.

Lapage cloudd'Asten est inhabituellement physique 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'une enveloppe de revente autour d'un cloud public étranger. Ce n'est pas une preuve de chaque charge de travail client, mais c'est une revendication d'actifs concrets: des salles, des baies, des serveurs et du personnel opérationnel doivent exister derrière le catalogue de services.

Lapage d'histoirede l'entreprise aide à expliquer comment cette empreinte s'est développée. Asten déclare que le groupe a été fondé en 1995, a acheté STTG en 2008, est devenu propriétaire de son premier centre de données, a créé le centre de données shelter 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, a obtenu la certification HDS en 2020 et est devenu opérateur télécom la même année. Il donne é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 affirmations de première partie, ils ne doivent donc pas être traités comme une utilisation audité de la capacité, mais ils rendent l'entreprise bien moins opaque qu'une inscription coquille.

La zone de service est nationale dans le langage commercial et régionale dans la logique d'infrastructure. Asten déclare que son expertise est déployée dans toute 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 localité compte 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 en tant que service, mais son approvisionnement est lié à une base d'actifs régionaux finie. Deux centres de données peuvent constituer une conception de résilience significative s'ils sont physiquement, électriquement et opérationnellement indépendants. Ils peuvent aussi être un cluster à destin partagé si les deux sites dépendent du même corridor de transport, de la même équipe de maintenance, du même approvisionnement en carburant, du même calendrier de changement ou du même stock de fournisseur.

Les pages publiques prouvent qu'Asten commercialise deux sites; elles ne publient pas d'arbre de défaillance site à site.

Les baies transforment la revendication cloud en test de capacité

La page de capacité publique la plus spécifique est l'offre d'hébergementd'Asten. Elle indique que les clients peuvent placer des serveurs physiques dans des centres de données sécurisés, choisir entre un tiers de baie et des baies complètes, utiliser des baies mesurant 800 sur 1200 millimètres avec 48U chacune, et bénéficier d'une alimentation incluse à 1 kVA ou 3 kVA selon l'option. Elle indique également que le centre de données dispose de 48 baies, 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 serrures, de détection et d'extinction d'incendie, d'une surveillance 24h/24 et 7j/7 et d'un accès client 24h/24. Ces détails sont exactement le type de faits qui transforment une « 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 baies 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 déclaration d'inventaire ou d'échelle de service.

Aucun de ces chiffres ne dit à lui seul au client combien de capacité de réserve reste aujourd'hui, combien de la centrale électrique est engagée, combien de 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. Une baie peut être présente mais pleine. Un onduleur peut être installé mais contraint par l'autonomie de la batterie. Un deuxième centre de données peut exister mais manquer de capacité de calcul froide suffisante pour prendre en charge toutes les charges de travail client à la fois.

La page d'hébergement indique que le centre de données est ouvert à différents opérateurs télécoms. C'est un bon langage pour le choix du client, car un seul bord de transporteur peut devenir le point commun caché dans une conception d'hébergement autrement redondante. Pourtant, « ouvert à différents opérateurs » n'est pas la même chose que nommer les transporteurs actifs, les entrées diverses, les conduits séparés, les salles de rencontre indépendantes ou le basculement testé.

La dépendance physique centrale de la mission est exactement ici: un client peut externaliser des serveurs vers Asten et rester exposé à la disponibilité des baies, au délai de livraison des interconnexions, à la maintenance des opérateurs, à la défaillance des routeurs et à la fenêtre de réparation pratique pour un port défaillant.

Leportefeuille d'hébergementd'Asten couvre l'hébergement, l'hébergement partagé, l'hébergement HDS, l'hébergement d'applications et l'hébergement de conteneurs. Cette diversité suggère plus d'un modèle opérationnel. Un client d'hébergement peut posséder des serveurs et demander à Asten de fournir l'espace, l'alimentation, le refroidissement, la sécurité et l'accès 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 pour l'hébergement et les opérations gérées. Un client de conteneurs peut se soucier davantage de l'orchestration de la plateforme et de la disponibilité du registre que de la disposition physique des baies. La même panne de centre de données ou de transporteur affecte chaque client différemment car la responsabilité est divisée différemment à chaque couche.

La tension économique centrale est qu'Asten vend le soulagement de la construction d'une salle informatique privée, mais doit financer la salle partagée qui remplace de nombreuses salles clients. C'est un compromis classique de l'économie d'hébergement: les clients évitent les dépenses d'investissement, le travail de conformité et les soucis locaux d'alimentation/refroidissement, tandis que le fournisseur concentre suffisamment de demande pour faire fonctionner des salles sécurisées, des opérations staffées et des systèmes redondants. Le fournisseur doit alors éviter de sur-réserver des ressources rares.

Les preuves publiques permettent à un acheteur de poser des questions précises, mais elles n'y répondent pas complètement: le taux de remplissage actuel des baies, la puissance engagée par rapport à la puissance de pointe, la redondance du refroidissement dans des conditions extérieures de pointe, le stock de serveurs de rechange, les délais pour le matériel de remplacement et le prix du maintien d'une capacité de reprise vide ne sont pas publiés.

La certification réduit la promesse, mais n'élimine 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. Lapage de certificationsindique qu'Asten Cloud est certifié ISO 27001 pour l'hébergement, les services gérés et le support utilisateur. Elle décrit également la certification HDS pour l'hébergement d'infrastructure physique et les activités d'hébergement géré, y compris les six domaines d'activité HDS qui couvrent 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 HDSrépète le cadre des six domaines et indique que le service est destiné aux clients et éditeurs de logiciels de santé et médico-sociaux.

C'est important car HDS n'est pas seulement un slogan sur la sécurité. Il lie la revendication d'hébergement à des charges de travail sensibles où la localisation, 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, c'est une promesse de localité superposée à l'exploitation de l'installation: les données doivent se trouver dans des centres de données français, sous protection juridique européenne, gérées par des processus certifiés et sauvegardées via 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 gestion de la sécurité de l'information. HDS indique une 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 d'astreinte, le temps moyen pour remplacer une baie 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'alimentation, au refroidissement, au matériel, aux personnes et aux liaisons.

L'offre secteur public ajoute un autre signal de demande. La page d'Asten pour lescollectivités et établissements publicsindique que le groupe a été sélectionné pour le lot régional Bretagne du cadre cloud et d'hébergement CANUT. Il 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 compte car les clients du secteur public apportent souvent des achats formels, des exigences 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, pas seulement un environnement de test privé.

La bonne conclusion n'est donc ni le cynisme ni la crédulité. Les certifications et le positionnement secteur public d'Asten sont des signaux significatifs et sourcés d'une posture opérationnelle sérieuse. Ils justifient un niveau de confiance plus élevé que celui qui conviendrait à un revendeur d'une page. Mais ils ne remplacent pas la diligence raisonnable du client.

L'acheteur a toujours besoin de l'énoncé de périmètre, des dates de validité des certificats, des services exclus, de la liste des sous-traitants, de l'emplacement de la sauvegarde, du processus de notification d'incident et de la preuve que la charge de travail contractée se trouve dans le périmètre certifié.

Les preuves de routage séparent l'opération Asten de l'ASN Bretagne

L'enregistrement réseau a une distinction étrange mais utile. L'ASN nommé pour la mission, AS206308, est enregistré dans RIPE commeasten-cloud-bretagne ASTEN CLOUD SAS. Les informations du titulaire le relient à ASTEN CLOUD SAS et aux adresses à Gouesnou et dans la région de Brest. Pourtant, lavue d'ensemble RIPEstat pour AS206308le marque comme non annoncé, et lavue du statut de routagene montre aucun préfixe IPv4 ou IPv6 visible et aucun voisin observé à la date de recherche. Cela ne signifie pas qu'Asten Cloud est hors ligne. Cela signifie que l'ASN nommé Bretagne n'est pas le porteur de route public dans les preuves de routage disponibles.

Les preuves de routage en direct pointent plutôt vers AS199727. RIPE RDAP listeAS199727comme « asten-cloud-idf » sous ASTEN CLOUD SAS, et lavue d'ensemble RIPEstat ASle marque comme annoncé. Sonrésultat de statut 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 tenus ensemble. D'un côté, Asten dispose d'une infrastructure routée en direct. De l'autre, l'ASN dont le nom contient « bretagne » est silencieux. Un article simple pourrait effacer cette distinction et dire « Asten Cloud a un ASN ». Une meilleure lecture d'infrastructure demande pourquoi l'ASN régional nommé est enregistré mais pas 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 disposition à deux ASN reflète des choix de site, d'héritage, de produit ou d'ingénierie du trafic.

Les collecteurs de routes publics ne répondent pas à cette question.

Les noms de préfixes suggèrent également des fonctions de service sans prouver le placement client. RIPE RDAP 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 nommage de type 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 de routage n'est donc pas de savoir si Asten est visible sur Internet. Il l'est. Le risque est de savoir si les clients connaissent le transporteur, le chemin et la disposition de basculement réels utilisés 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 que la diversité des chemins de fibre. Deux sessions peuvent encore partager un conduit, une entrée de bâtiment, un routeur, une fenêtre de maintenance ou une dépendance commerciale.

Un client hautement disponible devrait demander les noms des transporteurs, les emplacements de remise, la diversité des routes, la politique de basculement, les périodes de préavis de maintenance, la gestion des DDoS, la posture RPKI/IRR et la preuve d'un exercice de basculement récent.

La sauvegarde réduit le risque de perte de données, mais la reprise a toujours une horloge

Lapage de sauvegarde et 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ée ou isolée pour résister aux cyberattaques. Elle indique également que l'offre comprend 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 dirigé par une expertise en 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 médias, une logique hors site, des tests de restauration et une planification de reprise. La couche bande optionnelle est particulièrement pertinente pour les ransomwares car une réplique en ligne peut fidèlement reproduire la corruption, le chiffrement ou la suppression. Une rétention longue aide lorsque la compromission est découverte des semaines ou des mois après la première intrusion.

Les tests de restauration comptent car une sauvegarde qui ne peut pas être restaurée n'est pas une capacité de reprise.

L'écart restant est l'horloge de service. La page ne publie pas d'objectifs RPO ou RTO par défaut pour chaque classe de charge de travail. Elle n'indique pas combien de restaurations clients simultanées peuvent être exécutées lors d'un incident régional, comment le trafic de sauvegarde est limité, si les référentiels de sauvegarde partagent le même fournisseur de stockage que la production, ou si le robot de 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 la protection des données et la 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 de licence, 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 deuxième site peut préserver les données mais nécessite toujours du calcul, du stockage, de l'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 goulot 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 une partie de cela en associant la sauvegarde à des 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, carte 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 aux étrangers de calculer la rapidité avec laquelle un client particulier revient.

Le travail 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 de 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 indique également que le service peut combiner un 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 de contrat de supportajoute un détail plus banal 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 faisant remonter aux ingénieurs et experts de niveaux 2 et 3. Cela compte dans un chemin de panne car toutes les pannes ne commencent pas au cœur d'Asten. Un changement applicatif client, une expiration de certificat, une demande de pare-feu, une tâche de configuration mineure ou une intervention matérielle peut se situer à la frontière entre les opérations incluses et le support payant. Si cette frontière est floue pendant une panne, la réparation ralentit.

Le travail de support a le même problème d'utilisation que les baies. La page d'histoire d'Asten indique que le groupe compte environ 140 experts, mais le registre public ne détaille pas la répartition par opérations cloud, sécurité, travail sur le terrain, help desk, spécialistes applicatifs, gestionnaires ou fonctions administratives. Un jour normal peut avoir suffisamment de personnel pour les alertes, les changements planifiés et les tickets clients. Un incident simultané sur l'hébergement, la sauvegarde, le réseau et les systèmes clients peut consommer des spécialistes plus rapidement que le centre de données ne consomme de l'énergie.

Les clients devraient donc traiter le support comme une ressource contractuelle. La question n'est pas seulement « le support est-il disponible? » mais si le contrat définit les temps de réponse, les déclencheurs d'escalade, les niveaux de gravité, la couverture d'astreinte, les gelées de changement, 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.

C'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 de ticket; il peut avoir besoin d'un pont d'incident documenté, d'un ordre de priorité de restauration, 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 le travail d'urgence.

Le langage marketing public va dans cette direction, mais seul le contrat et les manuels opérationnels montreraient s'il est applicable sur le plan opérationnel.

La souveraineté est une frontière opérationnelle, pas une étiquette décorative

La revendication de marché la plus forte d'Asten est la localité. 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 revendication 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 vend la même logique aux établissements publics bretons.

Ces affirmations font de la souveraineté et de la localité des données l'un des sujets contrôlés pertinents 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écoms, des technologies de sauvegarde, des produits de sécurité et des réseaux d'accès clients. La page de services gérés d'Asten indique que, pour les exigences SecNumCloud, elle s'appuie sur OUTSCALE, une marque de Dassault Systèmes, dans une approche souveraine hybride. Cela peut être une conception judicieuse pour les clients qui ont besoin d'une option cloud souverain qualifiée.

Cela signifie aussi qu'un acheteur doit demander quelles charges de travail tournent dans les propres centres de données bretons d'Asten, lesquelles 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 localité. 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, la frontière de l'actif peut inclure les locaux clients gérés par Asten, les centres de données Asten et les ressources OUTSCALE. Si un client achète une sauvegarde pour les données Microsoft 365, le service de production peut rester dans l'environnement Microsoft tandis que les sauvegardes atterrissent dans les centres de données français d'Asten.

Le mot « souverain » ne peut ê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 sont une protection significative, mais l'accès opérationnel dépend toujours 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 des cadres de sécurité formels.

Elles ne montrent pas quels journaux sont conservés, où les clés sont détenues, comment les administrateurs clients sont authentifiés, ou comment le support fournisseur transfrontalier est restreint.

Un bon examen client devrait donc traiter la souveraineté comme un ensemble de points de preuve pratiques plutôt que comme un slogan. Où sont stockées les données de production? Où sont stockées les sauvegardes? Où sont stockés les journaux de surveillance? 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 goulots d'étranglement pratiques

Le premier chemin de défaillance est un problème de baie ou de stock de matériel. Les clients d'hébergement peuvent posséder l'équipement, mais Asten fournit toujours la salle, la baie, l'alimentation, le refroidissement, l'accès et éventuellement une intervention pratique. Un client d'hébergement partagé dépend plus directement de l'inventaire de serveurs et du stock de remplacement d'Asten. Le chiffre de 48 baies de la page d'hébergement donne une frontière 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 du fournisseur, de la disponibilité d'une assistance à distance et de la capacité du client à approuver les changements.

Le deuxième chemin de défaillance est l'alimentation. La page d'hébergement indique que le centre de données dispose d'une alimentation électrique sécurisée, supportée par onduleur et redondante de 175 kVA, avec des générateurs derrière la transition. Ce langage soutient une revendication de résilience électrique au niveau de l'installation. Il ne publie pas l'autonomie de la batterie, l'autonomie en carburant du générateur, le calendrier de maintenance, les résultats des tests de charge, la topologie de la chaîne électrique ou la marge restante lorsque les baies sont chargées.

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 panne de site devient une question économique et technique.

Le troisième chemin de défaillance est une panne de transporteur ou de routage. RIPEstat voit AS199727 comme actif et AS206308 comme inactif. Si le trafic client repose sur AS199727, sa diversité amont et ses chemins physiques comptent. Si un produit utilise une remise de transporteur 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 à cause d'une panne de routeur, d'une erreur de politique de routage, d'une maintenance, d'un problème de mitigation DDoS, d'une panne de transporteur ou d'un différend 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 du 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 goulot d'étranglement peut être le nombre de spécialistes qui peuvent toucher en toute sécurité aux pare-feu, hyperviseurs, stockage, sauvegardes, DNS, identité et applications clients. 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 les travaux hors périmètre, la politique d'urgence devrait indiquer si la comptabilisation des points s'arrête 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 les données et les systèmes dans ses centres de données ou environnements gérés. Partir plus tard peut nécessiter l'exportation de machines virtuelles, bases de données, sauvegardes, règles de pare-feu, zones DNS, secrets applicatifs, historique de surveillance et 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 le rapatriement d'urgence. Un client devrait régler ces questions avant une défaillance de contrat fournisseur, pas pendant une.

Qui est affecté lorsque ce système tombe en panne

Les parties affectées sont plus larges que ce qu'implique le mot « client ». Un client d'hébergement peut être une entreprise locale qui a placé ses propres serveurs dans les baies d'Asten pour éviter de gérer une salle privée. Un client d'hébergement partagé peut être une PME dont les systèmes de comptabilité, de commande, d'identité ou de collaboration tournent 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 à CANUT peut dépendre d'Asten pour des services citoyens ou administratifs. Un acteur de santé ou médico-social utilisant l'hébergement HDS peut avoir des obligations de disponibilité et de confidentialité des données patients.

L'impact diffère également selon le type de panne. Un bref flap de transporteur peut casser l'accès web sans endommager les données. Une panne de stockage peut laisser les applications en ligne mais incohérentes. Une panne de sauvegarde peut être invisible jusqu'à ce qu'une restauration soit nécessaire. Un backlog de support peut transformer un incident gérable en une panne prolongée. Une fenêtre de maintenance d'installation peut être acceptable pour les systèmes par lots mais inacceptable pour un portail de service public, un système de planification de clinique ou un détaillant pendant les heures de pointe.

La meilleure posture client est de cartographier les dépendances avant de signer ou de renouveler. Quels services sont critiques pour la production? Lesquels tournent dans les centres de données d'Asten, dans les locaux du client ou dans un environnement hybride? Lesquels sont sauvegardés vers le deuxième 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 service desk du client?

Ces questions semblent procédurales, mais elles décident 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 se défendre avec des abstractions. Asten a publié suffisamment d'informations sur les baies, 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 carte des dépendances

L'exercice le plus utile pour le client est de transformer les affirmations publiques d'Asten en une carte des dépendances pour le système spécifique qui est déplacé ou protégé. Commencez par le service métier, pas par la machine virtuelle. Un portail municipal peut dépendre d'un front-end web, d'un store de contenu, d'une identité, du DNS, du courrier, d'un connecteur de paiement et d'un contact de help desk.

Une application de santé peut dépendre d'un hébergement HDS, de sauvegardes chiffrées, d'une fédération d'identité, de journaux d'audit, d'un accès VPN et d'un fournisseur capable de supporter l'application après qu'Asten a 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, de l'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, l'héberge simplement ou n'a aucun contrôle dessus. Cette distinction est centrale dans 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 est hors garantie, qu'une application tierce ne peut pas être reconstruite, qu'un fournisseur de fibre manque un objectif de réparation, qu'un bureau d'enregistrement de domaine bloque un changement DNS, ou qu'un incident de sécurité force 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 carte devrait également séparer le support normal de l'autorité d'urgence. En fonctionnement de routine, un client peut demander un changement de pare-feu, une extension de stockage ou une restauration via un chemin de ticket. Lors d'un incident majeur, le même client peut avoir besoin d'une personne nommée qui peut approuver une déclaration de reprise, autoriser un basculement DNS, accepter des performances dégradées, suspendre des services non essentiels et communiquer avec les utilisateurs.

La page de support d'Asten montre une disposition de support structurée, mais l'acheteur a toujours 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 localité des données devrait apparaître sur la même carte. Si la production tourne dans les centres de données bretons d'Asten, les sauvegardes se trouvent dans deux centres de données français, et un service lié à SecNumCloud utilise OUTSCALE sous gestion Asten, alors ce sont trois affirmations de localité différentes. Chacune mérite une ligne séparée: où vit la production, où vivent les sauvegardes, où vivent 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 carte des dépendances devrait inclure la capacité après une panne, 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 licence et de réseau pour prendre en charge les services protégés. Elle peut être plus faible si le deuxième site est conçu principalement pour le stockage de sauvegarde, certaines charges de travail critiques ou une reprise plus lente.

La page publique de sauvegarde d'Asten mentionne des tests de restauration périodiques et un deuxième centre de données; le contrat devrait indiquer si l'environnement du client est censé y fonctionner, combien de temps prend le déplacement, combien de performance est réservée et quels autres clients rivalisent 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 lors d'un différend commercial, d'un changement stratégique ou d'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 de machines virtuelles, l'exportation de sauvegardes, les vidages de bases de données, les clés de chiffrement, la configuration du pare-feu et du VPN, les changements d'IP publique, les zones DNS, la documentation de support et la preuve de suppression après le départ.

Un service qui est vraiment bien géré devrait être capable de 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 registre public soutient aujourd'hui une évaluation de confiance moyenne. Il deviendrait plus fort si Asten publiait ou partageait des preuves sûres pour les clients de la conception à deux sites: la séparation des sites non sensibles, la diversité des transporteurs, les chemins d'alimentation indépendants, les résultats de basculement testés, les métriques de restauration de sauvegarde, les bandes RTO/RPO, les procédures d'escalade d'urgence et le support de sortie standard. Il serait également utile d'expliquer le rôle d'AS206308 par rapport à AS199727.

Si l'ASN nommé Bretagne est réservé, historique ou utilisé uniquement dans des arrangements privés, le dire empêcherait les étrangers 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 des certificats ISO et HDS, la matrice de services montrant quelles offres se trouvent à l'intérieur, la déclaration de localisation des données pour la production et la sauvegarde, la liste des sous-traitants qui peuvent affecter le service, et les responsabilités du client pendant une reprise. Demandez combien de chemins de transporteurs entrent dans chaque site et s'ils sont physiquement divers.

Demandez comment les tests de sauvegarde sont programmés, comment les défaillances sont rapportées, et si le client peut en être témoin ou en recevoir le résultat. Demandez ce qui se passe si un centre de données est perdu pendant une semaine, pas seulement pour une heure.

Il en va de même pour le coût. L'économie d'hébergement d'Asten dépend d'une infrastructure partagée, c'est pourquoi elle peut être attractive 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 basculement testé et capacité de calcul de rechange. 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 à ceux d'un fournisseur disparu ou d'un pur intermédiaire. Ils montrent une entreprise française légale, des revendications de centre de données breton, un périmètre de certification, un espace d'adressage routé en direct, 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 vers les baies d'Asten, la centrale électrique, les choix de routage, les référentiels de sauvegarde, la file d'attente de support et les contrats de reprise. C'est une proposition d'infrastructure respectable seulement si ces dépendances physiques et contractuelles sont mesurées avant la panne, et non découvertes pendant la fenêtre de réparation.