XSALTO35667 Alpilink Cloud S.A.S. vend une capacité hébergée qui dépend toujours des racks, du transit et des fenêtres de maintenance

Résumé

• Le RDAP de RIPE enregistreAS35667comme XSALTO35667 pour Alpilink Cloud S.A.S.; RIPEstat a signalé l'AS annoncé le 15 juillet 2026, avec94.143.216.0/21comme allocation IPv4 visible etRPKI validepour cette origine.
• La route publique est stable mais étroite:l'état du routage RIPEstata montré un préfixe IPv4, 2 048 adresses IPv4, aucun préfixe IPv6 visible et un voisin observé, tandis queles données de voisinage RIPEstatont identifié ce voisin comme AS28768.
• La propre pageServices Cloudd'Alpilink revendique hébergement, IaaS, machines virtuelles, services gérés, sauvegardes et reprise après sinistre externalisée, support expert français 24h/24, trois datacenters connectés, bande passante garantie de 40 Gbit/s, plus de 1 500 serveurs hébergés et 3 Po de données stockées; ce sont des déclarations opérationnelles de première partie, pas des audits de capacité indépendants.
• La note actuelle des preuves est Moyenne-forte pour l'identité et le contrôle de route, mais seulement Moyenne pour la résilience client. Les archives publiques soutiennent un véritable opérateur cloud et d'hébergement français, mais les clients ont encore besoin de preuves actuelles sur l'emplacement des racks, la capacité utilisable, la conception électrique et de refroidissement, la diversité de route au-delà de l'AS parent, l'isolation de la sauvegarde, l'escalade du support et les droits de migration.

Les archives publiques pointent vers un véritable opérateur cloud français, pas un nom d'hébergement jetable

La première étape la plus importante est l'identité. Un acheteur ne peut pas évaluer la capacité hébergée tant qu'il ne sait pas quelle organisation contrôle les adresses, les contrats, le bureau d'assistance et le patrimoine physique derrière le service. Sur ce point, XSALTO35667 Alpilink Cloud S.A.S. a des preuves publiques utiles. Le RDAP de RIPE àhttps://rdap.db.ripe.net/autnum/35667nomme AS35667 comme XSALTO35667 et le lie à Alpilink Cloud S.A.S., avec l'enregistrement de l'organisation montrant une adresse au 2 Rue de la Viscose, Le Rayon Vert, 38130 Échirolles, France. La même réponse RDAP inclut des contacts administratifs et d'opérations réseau XSALTO avec une adresse à Seyssinet-Pariset. Ces détails ne sont pas une garantie de performance, mais ils ancrent l'entreprise dans un contexte opérationnel français réel.

L'espace d'adresse est également clair. Le RDAP de RIPE àhttps://rdap.db.ripe.net/ip/94.143.216.0/21identifie 94.143.216.0 à 94.143.223.255 comme FR-XSALTO-20090310, alloué PA, pays FR, actif et associé à Alpilink Cloud S.A.S. La vue d'ensemble de l'AS par RIPEstat àhttps://stat.ripe.net/data/as-overview/data.json?resource=AS35667a signalé l'AS annoncé au moment de la requête du 15 juillet 2026. Son point de terminaison des préfixes annoncés àhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS35667a montré 94.143.216.0/21 pendant la fenêtre de deux semaines se terminant le 15 juillet 2026. Sa vue d'ensemble du préfixe àhttps://stat.ripe.net/data/prefix-overview/data.json?resource=94.143.216.0/21a confirmé AS35667 comme titulaire d'origine.

Le réseau est également protégé par un objet d'origine de route. Le point de terminaison de validation RPKI de RIPEstat àhttps://stat.ripe.net/data/rpki-validation/data.json?resource=35667&prefix=94.143.216.0/21a renvoyé un état valide, avec un ROA de validation pour l'AS d'origine 35667, le préfixe 94.143.216.0/21 et une longueur maximale /21. C'est un signal d'hygiène significatif. Cela ne garantit pas la disponibilité, les opérations de sécurité ou la diversité de route, mais cela réduit une classe de risque de routage évitable: une autorisation d'origine de route valide donne aux fournisseurs en amont et aux validateurs de route un moyen de rejeter les origines non autorisées pour le /21 annoncé.

Ces faits techniques comptent parce que l'entreprise vend une dépendance physique enveloppée dans un service cloud. La propre page Services Cloud d'Alpilink àhttps://www.alpilink.fr/services-cloud/liste hébergement, IaaS, machines virtuelles, services gérés, sauvegardes et reprise après sinistre externalisée. Elle indique qu'Alpilink Services Cloud offre l'expertise et les services d'un hébergeur souverain en France, avec une équipe experte française disponible 24h/24, un engagement de sécurité et une politique d'entreprise durable. Elle donne aussi des chiffres d'échelle: trois datacenters connectés, bande passante garantie de 40 Gbit/s, plus de 1 500 serveurs hébergés et 3 Po de données stockées. Ce ne sont pas des revendications logicielles génériques. Elles impliquent des racks, de l'alimentation, du refroidissement, des baies de stockage, des liaisons réseau, des sauvegardes, du personnel de support et des installations.

Le défi pour l'acheteur est que les preuves publiques sont solides au niveau de l'identité et du positionnement de première partie, mais incomplètes au niveau de la capacité en direct. Nous pouvons voir un AS actuel, une visibilité de route actuelle, une validité RPKI, des entrées de facility PeeringDB et une page cloud détaillée de première partie. Nous ne pouvons pas voir le registre de capacité client par client: armoires disponibles, puissance réservée, ports libres, stock de serveurs, disques de rechange, saturation du cluster hyperviseur, réserve de sauvegarde, contrats de main distante ou profondeur de la file d'attente de support.

Cette distinction n'est pas hostile à Alpilink. C'est la différence normale entre la preuve qu'un fournisseur existe et la preuve que la charge de travail spécifique d'un client survivra à la prochaine panne.

AS35667 est proprement enregistré, mais c'est aussi une surface de route publique étroite

Les preuves de routage sont encourageantes d'un côté et contraignantes de l'autre. L'état du routage RIPEstat àhttps://stat.ripe.net/data/routing-status/data.json?resource=AS35667a rapporté un préfixe IPv4, 2 048 adresses IPv4, zéro préfixe IPv6 dans la vue visible de AS35667, 326 pairs IPv4 RIS sur 326 voyant la route et un voisin observé au moment de la requête du 15 juillet 2026. C'est une forte visibilité pour l'unique route IPv4. Cela signifie que l'AS n'était pas simplement assigné; il était largement vu dans les données de routage publiques.

La contrainte est le même point de données lu sous un angle de résilience. Un préfixe visible et un voisin observé ne prouvent pas une architecture client multi-chemin. Le point de terminaison des voisins de RIPEstat àhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS35667a montré AS28768 comme seul voisin observé dans l'observation du 14 juillet 2026. La vue whois de RIPEstat àhttps://stat.ripe.net/data/whois/data.json?resource=AS35667enregistre également import depuis AS28768 et export vers AS28768. Le point de terminaison de cohérence àhttps://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS35667a trouvé 94.143.216.0/21 à la fois dans BGP et whois et AS28768 dans les vues import et export. C'est propre. C'est aussi concentré.

AS28768 n'est pas un arrière-plan sans importance. L'objet réseau PeeringDB pourhttps://www.peeringdb.com/api/net?asn=28768identifie XSALTO avec 10 préfixes IPv4, 10 préfixes IPv6, un nombre d'IX et trois enregistrements de facility dans son profil public, tandis quehttps://www.peeringdb.com/api/netixlan?asn=28768liste une entrée de peering France-IX AURA LyonIX. Les données netfac de PeeringDB àhttps://www.peeringdb.com/api/netfac?net_id=9058montrent AS28768 présent à Cogent Grenoble, Orange Business - La Fabrique à Grenoble, et XSALTO Grenoble à Seyssinet-Pariset. Cela suggère que le réseau plus large d'XSALTO/Alpilink est plus étendu que AS35667 seul.

Mais l'assignation ici est spécifiquement XSALTO35667 Alpilink Cloud S.A.S., et la vue publique de AS35667 elle-même ne montre pas la même diversité. L'objet PeeringDB pour AS35667 àhttps://www.peeringdb.com/api/net?asn=35667liste un préfixe IPv4, un préfixe IPv6 dans son profil, un trafic de 1 à 5 Gbit/s, une portée Europe, un ratio équilibré, zéro nombre d'IX et un nombre de facility. Le point de terminaison netfac àhttps://www.peeringdb.com/api/netfac?net_id=13798montre cette facility comme XSALTO Grenoble à Seyssinet-Pariset. Le point de terminaison netixlan pour AS35667 n'a renvoyé aucune ligne IX LAN publique lors de cette revue. Encore une fois, cela ne signifie pas qu'aucune diversité opérationnelle n'existe; cela signifie que la preuve de diversité publique pour cet AS est limitée.

Cela importe parce que de nombreuses pannes client se produisent à la frontière entre « le groupe a de la résilience » et « mon chemin de service exact a de la résilience ».

Si les machines virtuelles d'un client sont numérotées à partir de 94.143.216.0/21 et que leur chemin vers Internet emprunte AS35667 via AS28768, alors le client devrait demander comment AS28768 est conçu, où se trouvent les routeurs de bord, si la route peut basculer à l'intérieur du réseau du groupe, quels chemins de transit et de peering transportent réellement le trafic, et si le DNS, le support, la sauvegarde et le contrôle d'accès du client dépendent de la même facility. Un AS parent ou adjacent peut fournir une redondance réelle, mais seulement s'il est effectivement dans le chemin de service du client.

Le patrimoine physique est centré sur Grenoble, avec des couches actuelles et futures qui ne doivent pas être confondues

Le côté physique des preuves pointe vers Grenoble et ses communes environnantes. Les registres RIPE incluent Échirolles et Seyssinet-Pariset. PeeringDB liste XSALTO Grenoble comme une facility à Seyssinet-Pariset. La page Services Cloud de première partie donne l'adresse de contact au Le Rayon Vert, 2 rue de la Viscose, 38130 Échirolles. La page des garanties HDS àhttps://www.alpilink.fr/services-cloud/garanties-hds/nomme ALPILINK CLOUD au 6 Avenue Pierre de Coubertin, 38170 Seyssinet-Pariset, et nomme également Orange - La Fabrique (EOLAS) au 73 Rue Général Mangin, 38100 Grenoble, comme sous-traitant pour deux racks. C'est une information publique inhabituellement concrète pour un fournisseur cloud régional.

La même page HDS est également importante pour la frontière de l'opérateur. Elle dit qu'Alpilink Cloud possède son propre centres de données qu'il exploite sans sous-traiter, à l'exception de l'hébergement en colocation dans les datacenters listés dans le tableau. Elle décrit Alpilink Cloud comme l'hébergeur, Orange - La Fabrique comme sous-traitant pour une activité impliquant deux racks, et le support produit 24h/24 en partie par du personnel situé à Tahiti, avec accès chiffré.

Cela donne aux clients une carte réelle de la frontière: une partie du service est directement exploitée par Alpilink Cloud, une certaine dépendance de colocation existe, et l'accès au support peut traverser la géographie même lorsque la revendication d'hébergement des données est française.

C'est une divulgation précieuse, mais elle laisse encore les détails opérationnels qu'un client doit vérifier. La page publique dit que l'ISO 27001 est présente et que le HDS s'applique, mais elle ne publie pas le périmètre complet de l'audit, l'emplacement des racks clients, la topologie de sauvegarde, la séparation exacte entre les installations appartenant à Alpilink et les racks hébergés par Orange, ou quelles charges de travail se trouvent dans quel emplacement.

Pour un client de données de santé, la distinction entre l'emplacement des données, l'accès administratif, le référentiel de sauvegarde, l'outil de surveillance et le bureau d'assistance compte. Pour un client non lié à la santé, la même distinction compte pour la reprise et la responsabilité contractuelle.

L'annonce du nouveau centres de données d'Alpilink ajoute une couche future. L'article de première partie de janvier 2026 àhttps://www.alpilink.fr/centres de données-souverain-a-grenoble-alpilink-groupe-renforce-son-offre-dhebergement-avec-un-nouveau-site-opere-par-alpilink-cloud/dit que le Groupe Alpilink construit un nouveau centres de données souverain à Grenoble, exploité par Alpilink Services Cloud, pour renforcer son infrastructure d'ici l'été 2027. Il indique que le site sera à Saint-Martin-d'Hères, dans un bâtiment acquis et aménagé pour un usage de centres de données. Il décrit une architecture modulaire multi-salles, plafond haut, conception haute densité, redondance électrique et climatique, groupes électrogènes, sécurité physique renforcée, contrôle d'accès, supervision, compatibilité avec des exigences avancées de reprise après sinistre et de continuité d'activité, un PUE cible autour de 1,3 et un calendrier avec travaux en 2026, livraison et tests début 2027, et mise en service progressive à l'été 2027.

La page projet àhttps://www.alpilink.fr/services-cloud/nouveau-centres de données-alpilink-cloud-a-grenoble/répète le même cadre: le futur site est conçu pour une densité, une résilience, une souveraineté et une performance énergétique plus élevées; il vise une architecture équivalente au Tier III; et il n'est pas encore en service au moment du calendrier publié. C'est une frontière importante entre capacité installée et capacité utilisable. Un site planifié peut soutenir les préventes, la réservation et la planification architecturale. Il ne peut pas soutenir une affirmation de juillet 2026 selon laquelle les futures salles, chemins d'alimentation, chemins de refroidissement et procédures de migration des clients sont déjà utilisables pour le trafic de production.

La bonne question de diligence est donc double. Pour le service actuel, où exactement se trouve la charge de travail du client aujourd'hui: chez Alpilink, chez Orange - La Fabrique, sur un autre site connecté, ou dans un emplacement géré non nommé publiquement? Pour le projet 2027, quand l'espace réservé deviendra-t-il utilisable par le client, quels tests d'acceptation doivent réussir, comment les clients migreront-ils, et que se passe-t-il si le calendrier du nouveau site glisse? La capacité installée est l'équipement et l'installation qui peuvent être alimentés, refroidis, connectés et supportés aujourd'hui.

La capacité annoncée est une promesse sur de futurs équipements ou salles. La capacité utilisable est le sous-ensemble qu'un client peut réellement consommer avec des conditions contractuelles, une joignabilité réseau, une politique de sauvegarde et une couverture du personnel.

Le catalogue de services actuel est assez large pour créer de nombreux chemins de dépendance

La liste de la page Services Cloud comprenant hébergement, IaaS, machines virtuelles, services gérés, sauvegardes et reprise après sinistre externalisée importe parce que chaque service a une forme de défaillance différente. L'hébergement est le plus proche de l'installation physique. Le client peut posséder le matériel, mais Alpilink fournit l'espace rack, l'alimentation, le refroidissement, les cross-connects, l'accès physique et une certaine main distante.

L'IaaS et les machines virtuelles transfèrent davantage de responsabilité au fournisseur: hyperviseurs, stockage, orchestration, maintenance des hôtes, instantanés et parfois modèles de système d'exploitation. Les services gérés ajoutent du personnel et des procédures. La sauvegarde et la reprise après sinistre ajoutent une promesse de reprise distincte qui doit être plus indépendante que l'environnement de production qu'elle protège.

Les chiffres de première partie donnent une idée de l'échelle: trois datacenters connectés, bande passante garantie de 40 Gbit/s, plus de 1 500 serveurs hébergés et 3 Po de données stockées. Ces chiffres sont suffisamment spécifiques pour être utiles. Ce sont aussi des chiffres de première partie. L'enregistrement de route publique pour AS35667 montre un seul /21 visible; l'objet plus large de AS28768 sur PeeringDB suggère une empreinte réseau plus grande; la page Services Cloud suggère une infrastructure multi-site; la page HDS nomme un centres de données propre et un emplacement de rack sous-traité chez Orange.

Les preuves sont cohérentes avec un fournisseur cloud régional mature, mais elles ne permettent pas à un observateur externe d'allouer la revendication de 1 500 serveurs entre les installations, les clients, les types de service ou la capacité disponible.

Le risque n'est pas que les chiffres soient faux. Le risque est que les acheteurs puissent lire l'échelle agrégée comme une protection individuelle. Un fournisseur peut héberger 1 500 serveurs et avoir encore la charge de travail d'un client concentrée dans un seul rack. Il peut avoir trois datacenters connectés et encore vendre un plan de sauvegarde particulier qui n'inclut pas la restauration inter-site. Il peut garantir 40 Gbit/s au niveau réseau et avoir encore les ports clients, les pare-feux ou les baies de stockage comme goulot d'étranglement.

Il peut assurer un support 24h/24 et avoir encore un chemin de remplacement matériel limité par la disponibilité des pièces ou les fenêtres d'accès. La capacité agrégée est un point de départ utile; la conception du service au niveau de la charge de travail est la décision d'achat.

C'est particulièrement vrai pour la sauvegarde et la reprise après sinistre. Alpilink fait la publicité d'une reprise après sinistre externalisée, et la page HDS utilise des termes français pour la continuité et les garanties réglementaires.

Un client devrait demander si les référentiels de sauvegarde se trouvent dans une installation séparée et avec des identifiants administratifs séparés, si les réseaux de sauvegarde passent par un domaine de défaillance différent, si les tests de restauration sont documentés, combien de temps prend une restauration complète, si les instantanés sont immuables, et comment les scénarios de ransomware, d'erreur d'opérateur ou de litige de facturation sont gérés.

Un service de sauvegarde qui dépend du même compte, de la même matrice de stockage et de la même file d'attente de support que la production peut réduire la perte accidentelle tout en échouant lors d'une panne plus large.

Les services gérés créent une autre dépendance cachée: les personnes. Les pages publiques d'Alpilink mettent l'accent sur la disponibilité d'experts français, la couverture 24h/24 et le support local. La page HDS indique qu'une partie du personnel de support est à Tahiti et une partie de l'entreprise. Cela peut être une force, car le décalage horaire peut améliorer la couverture en dehors des heures de bureau. Cela nécessite également de la clarté. Quelle équipe peut effectuer un cycle d'alimentation sur un équipement? Quelle équipe peut accéder aux réseaux de gestion? Quels incidents nécessitent du personnel à Grenoble?

Comment les privilèges sont-ils contrôlés? Comment les restrictions d'accès aux données de santé sont-elles appliquées? Que se passe-t-il lorsqu'un incident de support nécessite simultanément l'exploitant de l'installation, l'équipe réseau et un administrateur client?

Les preuves de route et DNS doivent être lues comme des preuves de contrôle, pas comme une carte de service complète

Les preuves de route publiques prouvent le contrôle d'une ressource Internet utilisable. Elles ne nous disent pas où vit chaque service. La géolocalisation RIPEstat àhttps://stat.ripe.net/data/geoloc/data.json?resource=94.143.216.0/21et MaxMind GeoLite àhttps://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=94.143.216.0/21placent le /21 en France dans la vue interrogée. La requête de chaîne DNS àhttps://stat.ripe.net/data/dns-chain/data.json?resource=xsalto.coma montré xsalto.com résolvant vers 81.200.40.205 avec les serveurs de noms ns01.xsalto.net, ns02.xsalto.net et ns03.xsalto.net. Cette adresse web xsalto.com est en dehors du /21 de AS35667, elle ne doit donc pas être utilisée comme preuve de l'emplacement ou de la capacité de 94.143.216.0/21.

C'est un schéma normal. Le site marketing d'une entreprise peut être sur une plateforme distincte, une plage d'adresses héritée, un réseau de groupe, un hébergeur web ou un fournisseur de diffusion de contenu. L'emplacement du site web public n'est utile que si la revendication concerne la joignabilité du site web. Ce n'est pas une carte directe du calcul client. Inversement, un /21 routé est une preuve de contrôle utile mais pas un catalogue de services. Il peut héberger des systèmes de gestion, des VM client, du DNS, de la surveillance, des passerelles de sauvegarde et des interfaces internes.

Sans une carte de service publique, les observateurs externes ne peuvent pas dire quelles adresses correspondent à quel produit.

PeeringDB ajoute une autre couche mais a aussi des limites. L'entrée PeeringDB de AS35667 àhttps://www.peeringdb.com/api/net?asn=35667liste XSALTO 2, site webhttp://www.xsalto.com, AS set AS-XSALTO, un préfixe IPv4, un préfixe IPv6 dans le profil, une portée Europe, un trafic de 1 à 5 Gbit/s, zéro nombre d'IX public et un nombre de facility. L'API de facility àhttps://www.peeringdb.com/api/fac/7114identifie XSALTO Grenoble à Seyssinet-Pariset, avec deux réseaux et zéro nombre d'IX dans cet enregistrement de facility. PeeringDB est maintenu par les opérateurs et peut être incomplet, mais il reste une preuve publique utile que l'AS n'est pas simplement une inscription abstraite.

Le profil plus large de AS28768 àhttps://www.peeringdb.com/api/net?asn=28768est là où l'histoire d'interconnexion plus large apparaît. Il liste un IX et trois facilities, et le point de terminaison netixlan liste France-IX AURA LyonIX. Cela peut soutenir une hypothèse selon laquelle le réseau plus large d'Alpilink a plus de chemins que AS35667 seul. Cela ne prouve pas, sans un schéma de réseau spécifique au client, que le trafic client de AS35667 a des fournisseurs en amont indépendants, des routeurs de bord indépendants, des routes fibres indépendantes ou un basculement automatique entre les sites. La route publique de AS35667 apparaît derrière AS28768; les clients devraient demander quelle diversité existe derrière cette frontière.

La validité RPKI est le point d'hygiène de route le plus fort dans les preuves actuelles de AS35667. Elle réduit le risque de conflit d'origine accidentel ou malveillant. Elle ne résout pas tous les problèmes de routage. Si AS28768 a une panne, si une facility perd de l'alimentation, si un cross-connect est coupé, si un pare-feu tombe en panne fermée, si un événement DDoS submerge l'interface, ou si le DNS client dépend d'un seul chemin de fournisseur, le RPKI ne peut pas restaurer l'application. C'est un contrôle d'authentification de route, pas un plan de reprise opérationnelle.

L'alimentation, le refroidissement et la densité sont des domaines où la capacité annoncée doit être traitée avec précaution

Les pages du nouveau centres de données d'Alpilink sont remarquables car elles parlent directement de densité de puissance et de conception thermique. L'article de janvier 2026 dit que le futur site est conçu pour des charges applicatives croissantes, des systèmes d'information critiques et des charges de travail de données/IA.

Il mentionne une architecture modulaire multi-salles, des plafonds hauts, une redondance électrique, une redondance climatique, des groupes électrogènes, une sécurité physique, un contrôle d'accès, une supervision, une compatibilité avec la reprise après sinistre avancée et la continuité d'activité, et un PUE cible autour de 1,3. La page projet dit de même que le futur centres de données vise une architecture équivalente au Tier III, une redondance électrique complète, une conception modulaire multi-salles, une densité énergétique et une gestion efficace des flux chaud/froid.

Ces revendications sont commercialement significatives. Elles montrent qu'Alpilink comprend le problème auquel de nombreux fournisseurs cloud régionaux sont désormais confrontés: la densité par rack augmente plus vite que les salles héritées n'ont été conçues pour l'absorber. Une salle de serveurs construite pour une virtualisation modeste peut devenir contrainte lorsque les clients demandent du stockage dense, de l'analyse, de l'IA, des appliances de sécurité ou des hôtes à mémoire élevée.

La contrainte de capacité n'est plus seulement le nombre de racks; c'est la puissance par armoire, le chemin de refroidissement, la gestion des câbles, la capacité des onduleurs, l'autonomie des groupes électrogènes, la sélectivité des disjoncteurs, la surveillance et la capacité humaine à remplacer des composants défaillants sans perturber les charges voisines.

Le timing est important. Les mêmes pages placent les travaux et l'aménagement en 2026, la livraison et les tests début 2027, et la mise en service progressive à l'été 2027. À la date de publication de cet article, ces futures salles doivent être traitées comme planifiées ou en développement, pas comme une capacité utilisable déjà prouvée. Un acheteur réservant de l'espace peut bénéficier du projet; un acheteur ayant besoin d'une reprise de production immédiate ne peut pas compter sur ce futur site tant qu'il n'est pas mis en service, testé, connecté, contracté et accepté.

Les revendications actuelles d'hébergement vert doivent également être lues avec prudence. L'article sur le développement durable de juillet 2024 àhttps://www.alpilink.fr/alpilink-cloud-notre-engagement-envers-un-hebergement-durable/dit qu'Alpilink utilise une partie de son infrastructure dans un centres de données éco-responsable avec 100 % d'électricité renouvelable, un refroidissement par calories d'eau souterraine sans consommation d'eau, une conformité avec le Code de conduite européen pour l'efficacité énergétique des datacenters et une efficacité énergétique inférieure à 1,30 PUE. L'article de juin 2024 àhttps://www.alpilink.fr/un-centres de données-peut-il-etre-vert/dit que le centres de données Alpilink Cloud près de Grenoble est conçu pour être aussi vertueux que possible et utilise l'énergie hydroélectrique.

Ces revendications de durabilité peuvent être des forces opérationnelles. Un refroidissement efficace et une énergie renouvelable locale peuvent réduire les coûts d'exploitation et l'exposition au risque. Mais le PUE et l'énergie verte ne prouvent pas par eux-mêmes une capacité de réserve. Une facility à faible PUE peut être pleine. Un site alimenté par des énergies renouvelables peut encore avoir des contraintes de groupe électrogène, d'onduleur, de refroidissement, de maintenance ou de personnel.

Un cycle de vie durable des équipements peut réduire les déchets tout en augmentant le besoin de comprendre l'âge du matériel, la politique de pièces de rechange et la planification du renouvellement. Les clients devraient donc demander la capacité actuelle par rack, tirage électrique, allocation de refroidissement et niveau de service plutôt que de se fier uniquement au langage de la durabilité.

La localisation des données est une force, mais elle doit être spécifiée service par service

Le positionnement d'Alpilink est construit autour de la souveraineté française. La page Services Cloud dit que l'entreprise propose un hébergement souverain en France et un support français. L'article sur Tech & Fest 2026 àhttps://www.alpilink.fr/techfest-2026-alpilink-services-cloud-au-coeur-des-enjeux-de-souverainete-numerique/cadre Alpilink Services Cloud autour de la souveraineté, du cloud et de la continuité d'activité à Grenoble. La page des garanties HDS aborde explicitement l'hébergement des données de santé, la localisation des données, la certification, les rôles des sous-traitants et le risque d'accès par un pays tiers. C'est une divulgation plus utile qu'un simple badge « cloud sécurisé ».

La règle pratique est toujours service par service. La VM de production d'un client peut se trouver dans la propre installation d'Alpilink. Une copie de sauvegarde peut se trouver dans un autre centres de données connecté. Une dépendance de rack pour les données de santé peut impliquer Orange - La Fabrique. L'accès au support peut impliquer du personnel à Tahiti via un accès chiffré. Le DNS peut être dans un système, les factures dans un autre et la documentation client dans un autre.

Une revendication de souveraineté est la plus forte lorsque chacune de ces surfaces est cartographiée: calcul, stockage, sauvegardes, journaux, tickets, surveillance, e-mail, identifiants, administration et runbooks de reprise après sinistre.

La page HDS donne une longueur d'avance aux clients car elle nomme les rôles et dit qu'aucun transfert de données de santé personnelles vers un pays tiers en dehors de l'Espace économique européen n'est effectué par Alpilink Cloud dans ce contexte. Elle indique également qu'Alpilink Cloud n'est pas qualifié SecNumCloud 3.2 dans le tableau affiché. Cette distinction est importante.

HDS et ISO 27001 peuvent être des contrôles solides pour des usages particuliers, mais ils ne sont pas identiques à la qualification SecNumCloud, ni une preuve de résilience complète, ni une garantie que chaque produit, client ou composant sous-traité est dans le même périmètre.

Pour les charges de travail non liées à la santé, la même diligence s'applique avec des étiquettes différentes. Où sont les données? Qui peut y accéder? Quel pays régit le contrat? Quels sous-traitants fournissent le rack, le réseau, l'alimentation, la surveillance ou le support? À quelle vitesse le client peut-il exporter ses données? Les sauvegardes sont-elles stockées dans le même domaine juridique et opérationnel que la production? Les journaux sont-ils conservés en France? Les clés de chiffrement sont-elles détenues par le client, par le fournisseur ou partagées?

Si un client doit partir, peut-il obtenir des images de disque, des vidages de base de données, des exports de stockage d'objets et le contrôle DNS sans attendre une file d'attente de support manuelle?

La version la plus forte de l'offre d'Alpilink est locale, spécifique et opérationnelle: personnel centré sur Grenoble, installations françaises, certifications nommées, racks concrets, ressources réseau connues et chemins de migration accessibles. La version plus faible serait un slogan de souveraineté large sans cartographie par service. Les archives publiques sont plus proches de la version forte que de nombreux fournisseurs, mais un acheteur a encore besoin du calendrier exact et du périmètre produit pour son propre déploiement.

Chemins de défaillance: ce qui casse en premier, et qui est affecté

Le chemin de défaillance le plus évident est un problème de rack ou de facility. Les clients d'hébergement peuvent perdre l'alimentation, le refroidissement, les cross-connects ou l'accès à la main distante. Les clients IaaS peuvent subir une panne de l'hôte, du stockage ou du réseau. Les clients de services gérés peuvent également perdre la séquence d'opérations du personnel nécessaire pour diagnostiquer les incidents. Si l'emplacement affecté est le propre centres de données d'Alpilink, le fournisseur contrôle davantage la réponse.

Si l'actif affecté est un rack de colocation sous-traité, le fournisseur doit se coordonner avec l'opérateur de colocation. Cette distinction compte lors d'une panne de nuit ou de week-end.

Le chemin de défaillance de route est plus étroit mais visible. AS35667 transite publiquement par AS28768 dans les données observées. Si la frontière interne entre AS35667 et AS28768, les routeurs de l'AS parent, ou le tissu de fournisseur en amont/de peering derrière AS28768 a des problèmes, les clients numérotés à partir de 94.143.216.0/21 peuvent voir des effets de joignabilité. La validité RPKI n'aidera pas si le chemin autorisé est physiquement ou opérationnellement hors service.

Les clients devraient demander si les préfixes clients peuvent être déplacés, s'il existe plusieurs dispositifs de bord, où se trouvent les dispositifs, et si la diversité de chemin est testée plutôt que simplement configurée.

Le chemin de défaillance du support est humain. La revendication de support 24h/24 d'Alpilink est précieuse, et la référence de la page HDS au support basé à Tahiti peut améliorer la couverture. Mais les clients devraient savoir ce que ce support peut réellement faire. L'équipe de nuit peut-elle redémarrer un hôte? Peut-elle remplacer un disque? Peut-elle accéder à la facility? Peut-elle approuver des changements de route? Peut-elle restaurer une sauvegarde? Peut-elle communiquer dans la langue requise par le client? Peut-elle agir lorsque des restrictions liées aux données de santé s'appliquent?

La différence entre « nous avons vu l'alerte » et « nous avons rétabli le service » est la différence entre la surveillance et la reprise.

Le chemin de défaillance de la migration est le plus silencieux et souvent le plus coûteux. Les services cloud actuels d'Alpilink et le futur projet de centres de données font de la migration une question centrale. Les clients peuvent avoir besoin de passer d'une salle Alpilink existante au nouveau site de Saint-Martin-d'Hères, d'un rack hérité à une salle haute densité, de serveurs physiques à l'IaaS, ou d'Alpilink à un autre fournisseur.

Chaque déplacement dépend du renumérotage réseau, des TTL DNS, de l'export de sauvegarde, de la réplication du stockage, des fenêtres de maintenance, des dépendances applicatives et de la disponibilité du personnel. Une construction de centres de données futur n'améliore la résilience qu'après la réalisation du plan de migration.

Les parties affectées sont plus larges que l'acheteur direct. Les services cloud d'Alpilink servent des organisations qui se soucient de la souveraineté, de l'hébergement des données de santé, des opérations gérées, de la continuité d'activité et du support local. Si un rack, une route, un cluster de stockage ou un processus de support échoue, les utilisateurs finaux peuvent perdre des sites web publics, des systèmes de tourisme ou de commerce, des applications internes liées aux paiements, des services internes d'entreprise, des workflows de données de santé, des restaurations de sauvegarde ou des étapes de reprise après sinistre.

Les articles publics autour de Tech & Fest décrivent des DSI, RSSI et équipes métier à la recherche de modèles cloud régionaux et souverains. Ce sont précisément les utilisateurs pour lesquels le temps de reprise, la localisation des données et l'escalade du support ne sont pas des préoccupations abstraites.

Ce qui ferait monter ou descendre la note des preuves

La note actuelle des preuves est Moyenne-forte pour l'identité et l'hygiène réseau car RIPE RDAP, RIPEstat et PeeringDB s'accordent sur l'entreprise, l'AS, le bloc d'adresses, la visibilité de route et le contexte de la facility française. Elle est Moyenne pour la résilience client car les preuves publiques ne montrent pas la carte de service en direct derrière les revendications agrégées.

Alpilink publie plus de détails opérationnels que de nombreux petits fournisseurs, mais les clients ont encore besoin d'une confirmation directe de l'emplacement actuel des racks, de la capacité utilisable, de la conception de l'alimentation, de l'isolation de la sauvegarde et de l'autorité du support.

La note s'améliorerait si Alpilink publiait une déclaration d'infrastructure datée qui cartographie les services actuels aux installations, explique quels datacenters sont connectés par la boucle optique, indique où se trouvent les dispositifs de bord de AS35667 et AS28768, nomme les arrangements actuels de fournisseur en amont/de transit au niveau du service, donne une page de statut ou d'historique des incidents publique, décrit la séparation de la sauvegarde, et distingue la capacité actuelle du site de 2027.

Elle s'améliorerait si l'entreprise publiait des conseils de migration lisibles par les clients pour la construction de Saint-Martin-d'Hères, y compris les tests d'acceptation, le retour arrière, les plans de route et les fenêtres de support.

La note baisserait si AS35667 perdait une large visibilité de route, si l'état RPKI valide disparaissait sans explication, si les informations de facility PeeringDB devenaient obsolètes ou contradictoires, si les pages de première partie cessaient de distinguer les services actuels de la capacité future, si les déclarations HDS/ISO devenaient peu claires, ou si les clients ne pouvaient pas obtenir les faits actuels sur la facility et la reprise dans le cadre du contrat. Elle baisserait également si le projet de futur centres de données était commercialisé comme une redondance de production utilisable avant d'être mis en service et testé.

Le point le plus important est que les archives publiques d'Alpilink ne sont pas vides. Elles sont substantielles. La prudence vient de la précision, pas de l'absence. Un acheteur a suffisamment de preuves pour justifier une évaluation sérieuse. Il n'a pas encore suffisamment de preuves publiques pour sauter la diligence technique.

Ce que les clients devraient exiger avant de compter la capacité

La manière la plus pratique d'acheter chez Alpilink est de demander une carte de charge de travail avant de traiter tout chiffre global comme une capacité disponible. La carte devrait nommer la facility où s'exécute le calcul de production aujourd'hui, la facility où reposent les sauvegardes, le chemin de route utilisé par les adresses publiques du client, la couche de stockage derrière les machines virtuelles, l'équipe de support qui peut agir en dehors des heures ouvrables et la méthode de migration si le client se déplace vers le site prévu de Saint-Martin-d'Hères. Cette demande n'est pas un traitement spécial.

C'est la traduction minimale des revendications d'infrastructure publiques en un plan d'exploitation spécifique au client.

Pour la résilience de route, la carte devrait séparer AS35667 du contexte plus large de AS28768. Les preuves publiques de RIPEstat montrent AS35667 avec un seul /21 IPv4 visible et un voisin observé, tandis que PeeringDB montre AS28768 avec une empreinte de facility et d'échange plus large. Cette différence peut être parfaitement raisonnable au sein d'un groupe de fournisseurs, mais un client ne devrait pas supposer que chaque chemin de AS28768 protège chaque service de AS35667.

Le contrat devrait dire quel AS origine les adresses du client, où se trouvent les routeurs de bord, quels chemins de fournisseur en amont ou de peering transportent le trafic, si le basculement a été testé, et si le DNS et l'accès de contrôle du client dépendent du même emplacement.

Pour la résilience des facilities, la carte devrait distinguer l'exploitation du propre centres de données d'Alpilink de la dépendance de rack chez Orange - La Fabrique nommée dans la page des garanties HDS. Un client dont la charge de travail est hébergée dans une salle exploitée par Alpilink fait face à un modèle de réponse; un client dont la charge de travail dépend de racks sous-traités fait face à un autre.

L'acheteur devrait savoir qui contrôle l'accès physique, qui peut remplacer l'équipement, qui possède la réponse aux incidents d'alimentation, quelles fenêtres de maintenance s'appliquent et quels crédits de service ou droits de sortie s'appliquent si l'un ou l'autre site est indisponible. Sans ce détail, la phrase « trois datacenters connectés » reste un contexte marketing utile plutôt qu'une preuve de redondance au niveau client.

Pour la capacité installée par rapport à la capacité utilisable, l'acheteur devrait demander des chiffres actuels plutôt que des chiffres de projet. Les 1 500 serveurs hébergés, 3 Po de données stockées et 40 Gbit/s de bande passante de la page Services Cloud décrivent une échelle agrégée. Les pages du projet Grenoble 2027 décrivent de futures salles haute densité, une résilience avec groupes électrogènes et des objectifs de PUE. Aucun de ces ensembles de chiffres ne dit à un client spécifique combien de CPU, RAM, stockage, puissance d'armoire, capacité de cross-connect ou temps de support sont disponibles aujourd'hui.

Un client planifiant un déploiement critique devrait demander quelle capacité est libre, laquelle est réservée, laquelle est sursouscrite, laquelle nécessite un achat de matériel et laquelle dépend du calendrier de mise en service de 2027.

Pour la reprise, la carte devrait inclure une preuve de restauration. Les sauvegardes et la reprise après sinistre externalisée ne valent que si le chemin de sauvegarde est suffisamment séparé de la panne de production. Les clients devraient exiger des preuves récentes de test de restauration, l'emplacement de la sauvegarde, les contrôles d'accès à la sauvegarde, la propriété des clés de chiffrement, les estimations de temps de restauration, les priorités d'ordre de restauration et une route d'exportation des données qui ne dépend pas d'une seule file d'attente de support surchargée.

Un fournisseur peut avoir de réelles forces régionales et laisser tout de même un client exposé si le processus de reprise est manuel, non documenté ou lié au même système de stockage en panne.

Ces questions ne font pas d'Alpilink un candidat faible. Ce sont les questions qu'un fournisseur régional crédible devrait pouvoir répondre. Les preuves publiques montrent déjà un opérateur cloud français routable avec un investissement infrastructurel visible. La pièce manquante n'est pas l'identité; c'est la preuve de résilience spécifique au client. Une fois la carte de charge de travail existante, la présence locale d'Alpilink, ses revendications de conformité, son focus grenoblois et son futur projet de centres de données peuvent être évalués par rapport à un modèle de panne réel plutôt qu'à un dépliant.

Conclusion pour les opérateurs dépendants

XSALTO35667 Alpilink Cloud S.A.S. doit être traité comme un opérateur français régional de cloud et d'hébergement réel avec des preuves d'identité publique plus fortes que la moyenne. AS35667 est enregistré auprès d'Alpilink Cloud S.A.S., son principal /21 IPv4 visible est largement annoncé, le RPKI est valide, PeeringDB liste XSALTO Grenoble, et les propres pages cloud d'Alpilink décrivent hébergement, IaaS, machines virtuelles, services gérés, sauvegardes, reprise après sinistre, certifications, garanties de données de santé et une histoire multi-centres de données. Le tableau opérationnel est suffisamment spécifique pour compter.

Le tableau des dépendances est également suffisamment spécifique pour être remis en question. La surface de route publique de AS35667 est étroite. Le réseau plus large de AS28768 apparaît plus diversifié, mais le chemin client exact doit être vérifié. Les revendications d'échelle de Services Cloud sont de première partie et agrégées. Le nouveau projet de centres de données de Grenoble est planifié pour 2027 et ne doit pas être compté comme une capacité de production utilisable en juillet 2026.

Les revendications HDS, ISO 27001 et de durabilité sont précieuses, mais elles doivent être cartographiées sur la facility, le service et le chemin de support réels du client.

Pour un client actuel, les questions pratiques sont directes. Quelle facility héberge ma charge de travail aujourd'hui? Quel AS et préfixe la portent? Quels fournisseurs en amont et routeurs sont dans mon chemin? Les sauvegardes sont-elles en dehors du domaine de panne de production? Quel staff peut agir en dehors des heures ouvrables? Quel est mon temps de restauration pour un hôte en panne, un système de stockage, un événement d'alimentation de rack, un problème de route ou une panne de site? Si je dois migrer vers le nouveau centres de données, qu'est-ce qui doit changer et qui possède chaque étape?

Pour un nouvel acheteur, les archives publiques soutiennent une conversation qualifiée plutôt qu'un achat aveugle. Alpilink a les ingrédients visibles d'un fournisseur cloud régional crédible: de vraies ressources de routage, un contexte de facility nommé, des opérations locales, des revendications de conformité et un plan d'investissement infrastructurel. La décision d'achat devrait reposer sur une preuve actuelle de capacité utilisable, d'isolation de défaillance et de droits de sortie. La capacité hébergée se résout toujours en dépendances physiques.

Dans le cas d'Alpilink, ces dépendances sont suffisamment visibles pour poser de meilleures questions: racks à Grenoble, contrôle de route via AS35667 et AS28768, limites d'alimentation et de refroidissement, autorité du support 24h/24, séparation de la sauvegarde, et chemin de migration des salles d'aujourd'hui vers le site promis de demain.