XSALTO35667 Alpilink Cloud S.A.S. sells hosted capacity that still depends on racks, transit and repair windows

Summary

• RIPE RDAP registers AS35667 as XSALTO35667 for Alpilink Cloud S.A.S.; RIPEstat reported the AS announced on 15 July 2026, with 94.143.216.0/21 as its visible IPv4 allocation and valid RPKI for that origin.
• The public route is stable but narrow: RIPEstat routing status showed one IPv4 prefix, 2,048 IPv4 addresses, no visible IPv6 prefixes and one observed neighbour, while RIPEstat neighbour data identified that neighbour as AS28768.
• Alpilink's own Services Cloud page claims housing, IaaS, virtual machines, managed services, backup and externalised disaster recovery, 24/7 French expert support, three connected data centres, 40 Gbit/s guaranteed bandwidth, more than 1,500 hosted servers and 3 PB of stored data; those are first-party operating claims, not independent capacity audits.
• The current evidence grade is Medium-strong for identity and route control, but only Medium for customer resilience. Public records support a real French cloud and hosting operation, yet customers still need current proof of rack placement, usable capacity, power and cooling design, route diversity beyond the parent AS, backup isolation, support escalation and migration rights.

The public record points to a real French cloud operator, not a disposable hosting name

The most important first step is identity. A buyer cannot evaluate hosted capacity until it knows which organisation controls the addresses, contracts, support desk and physical estate behind the service. On that point, XSALTO35667 Alpilink Cloud S.A.S. has useful public evidence. RIPE RDAP at https://rdap.db.ripe.net/autnum/35667 names AS35667 as XSALTO35667 and ties it to Alpilink Cloud S.A.S., with the organisation record showing an address at 2 Rue de la Viscose, Le Rayon Vert, 38130 Échirolles, France. The same RDAP response includes XSALTO administrative and network-operations contacts with a Seyssinet-Pariset address. Those details are not a performance warranty, but they anchor the company in a real French operating context.

The address space is similarly clear. RIPE RDAP at https://rdap.db.ripe.net/ip/94.143.216.0/21 identifies 94.143.216.0 through 94.143.223.255 as FR-XSALTO-20090310, allocated PA, country FR, active and associated with Alpilink Cloud S.A.S. RIPEstat's AS overview at https://stat.ripe.net/data/as-overview/data.json?resource=AS35667 reported the AS as announced at the 15 July 2026 query time. Its announced-prefixes endpoint at https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS35667 showed 94.143.216.0/21 during the two-week window ending 15 July 2026. Its prefix overview at https://stat.ripe.net/data/prefix-overview/data.json?resource=94.143.216.0/21 confirmed AS35667 as the origin holder.

The network is also protected by a route-origin entity. RIPEstat's RPKI validation endpoint at https://stat.ripe.net/data/rpki-validation/data.json?resource=35667&prefix=94.143.216.0/21 returned a valid state, with a validating ROA for origin AS35667, prefix 94.143.216.0/21 and maximum length /21. That is a meaningful hygiene signal. It does not guarantee uptime, security operations or route diversity, but it reduces one class of avoidable routing risk: a valid route-origin authorization gives upstreams and route validators a way to reject unauthorized origins for the advertised /21.

Those technical facts matter because the company sells a physical dependency in a cloud wrapper. Alpilink's own Services Cloud page at https://www.alpilink.fr/services-cloud/ lists housing, IaaS, virtual machines, managed services, backup and externalised disaster recovery. It says Alpilink Services Cloud offers the expertise and services of a sovereign hoster in France, with a French expert team available 24 hours a day, a security commitment and a sustainable corporate policy. It also gives headline scale claims: three connected data centres, 40 Gbit/s guaranteed bandwidth, more than 1,500 hosted servers and 3 PB of stored data. Those are not generic software claims. They imply racks, power, cooling, storage arrays, network links, backups, support staff and facilities.

The buyer's challenge is that public evidence is strong at the identity and first-party-positioning layer, but incomplete at the live-capacity layer. We can see a current AS, current route visibility, RPKI validity, PeeringDB facility rows and a detailed first-party cloud page. We cannot see the customer-by-customer capacity ledger: available cabinets, reserved power, free ports, server stock, spare drives, hypervisor cluster headroom, backup saturation, remote-hands contracts or support queue depth. That distinction is not hostile to Alpilink.

It is the normal difference between evidence that a provider exists and evidence that a customer's specific workload will survive the next failure.

AS35667 is cleanly registered, but it is also a narrow public route surface

The route evidence is encouraging in one respect and constraining in another. RIPEstat routing status at https://stat.ripe.net/data/routing-status/data.json?resource=AS35667 reported one IPv4 prefix, 2,048 IPv4 addresses, zero IPv6 prefixes in the visible AS35667 view, 326 of 326 IPv4 RIS peers seeing the route and one observed neighbour at the 15 July 2026 query time. That is strong visibility for the one IPv4 route. It means the AS was not merely assigned; it was being seen broadly in public routing data.

The constraint is the same data point read from a resilience angle. One visible prefix and one observed neighbour do not prove a multi-path customer architecture. RIPEstat's neighbour endpoint at https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS35667 showed AS28768 as the only observed neighbour in the 14 July 2026 observation. RIPEstat's whois view at https://stat.ripe.net/data/whois/data.json?resource=AS35667 also records import from AS28768 and export to AS28768. The consistency endpoint at https://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS35667 found 94.143.216.0/21 in both BGP and whois and AS28768 in both import and export views. That is tidy. It is also concentrated.

AS28768 is not irrelevant background. PeeringDB's network entity for https://www.peeringdb.com/api/net?asn=28768 identifies XSALTO with 10 IPv4 prefixes, 10 IPv6 prefixes, one IX count and three facility records in its public profile, while https://www.peeringdb.com/api/netixlan?asn=28768 lists a France-IX AURA LyonIX peering entry. PeeringDB's netfac data at https://www.peeringdb.com/api/netfac?net_id=9058 shows AS28768 present at Cogent Grenoble, Orange Business - La Fabrique in Grenoble, and XSALTO Grenoble in Seyssinet-Pariset. That suggests the broader XSALTO/Alpilink network estate is wider than AS35667 alone.

But the assignment here is specifically XSALTO35667 Alpilink Cloud S.A.S., and the public AS35667 view does not itself show the same diversity. PeeringDB's AS35667 entity at https://www.peeringdb.com/api/net?asn=35667 lists one IPv4 prefix, one IPv6 prefix in its profile, 1-5 Gbit/s traffic, Europe scope, balanced ratio, zero IX count and one facility count. The netfac endpoint at https://www.peeringdb.com/api/netfac?net_id=13798 shows that facility as XSALTO Grenoble in Seyssinet-Pariset. The netixlan endpoint for AS35667 returned no public IX LAN rows during this review. Again, that does not mean no operational diversity exists; it means the public diversity proof for this AS is limited.

This matters because many customer outages occur at the boundary between "the group has resilience" and "my exact service path has resilience." If a customer's virtual machines are numbered from 94.143.216.0/21 and their path to the Internet rides AS35667 through AS28768, then the customer should ask how AS28768 is engineered, where the border routers live, whether the route can fail over inside the group network, which transit and peering paths actually carry traffic, and whether the customer's DNS, support, backup and control access depend on the same facility.

A parent or adjacent AS can provide real redundancy, but only if it is actually in the customer's service path.

The physical estate is Grenoble-centred, with current and future layers that must not be confused

The physical side of the evidence points to Grenoble and its surrounding municipalities. RIPE records include Échirolles and Seyssinet-Pariset. PeeringDB lists XSALTO Grenoble as a facility in Seyssinet-Pariset. The first-party Services Cloud page gives the contact address at Le Rayon Vert, 2 rue de la Viscose, 38130 Échirolles. The HDS guarantees page at https://www.alpilink.fr/services-cloud/garanties-hds/ names ALPILINK CLOUD at 6 Avenue Pierre de Coubertin, 38170 Seyssinet-Pariset, and also names Orange - La Fabrique (EOLAS) at 73 Rue Général Mangin, 38100 Grenoble, as a subcontractor for two racks. This is unusually concrete public information for a regional cloud provider.

The same HDS page is also important for the operator boundary. It says Alpilink Cloud has its own data centre that it operates without subcontracting, except for colocation hosting in the data centres listed in the table. It describes Alpilink Cloud as the host, Orange - La Fabrique as a subcontractor for an activity involving two racks, and support produced 24/7 partly by staff located in Tahiti, with encrypted access. That gives customers a real map of the boundary: some service is directly operated by Alpilink Cloud, some colocation dependency exists, and support access can cross geography even when the data-hosting claim is French.

That is valuable disclosure, but it still leaves the operational detail a customer must verify. The public page says ISO 27001 is present and HDS applies, but it does not publish the full audit scope, customer rack placement, backup topology, exact separation between Alpilink-owned facility and Orange-hosted racks, or which workloads sit in which location. For a health-data customer, the distinction between data location, administrative access, backup repository, monitoring tool and support desk matters. For a non-health customer, the same distinction matters for recovery and contract accountability.

Alpilink's new data-centre announcement adds a future layer. The January 2026 first-party article at https://www.alpilink.fr/datacenter-souverain-a-grenoble-alpilink-groupe-renforce-son-offre-dhebergement-avec-un-nouveau-site-opere-par-alpilink-cloud/ says Alpilink Groupe is building a new sovereign data centre in Grenoble, operated by Alpilink Services Cloud, to strengthen its infrastructure around summer 2027. It says the site will be in Saint-Martin-d'Hères, in a building acquired and fitted out for data-centre use. It describes modular multi-room architecture, high ceiling, high-density design, electrical and climatic redundancy, generator sets, enhanced physical security, access control, monitoring, compatibility with advanced disaster-recovery and business-continuity requirements, a target PUE around 1.3 and a schedule with works in 2026, delivery and tests in early 2027, and progressive service in summer 2027.

The project page at https://www.alpilink.fr/services-cloud/nouveau-datacenter-alpilink-cloud-a-grenoble/ repeats the same frame: the future site is designed for higher density, resilience, sovereignty and energy performance; it targets an architecture equivalent to Tier III; and it is not in service yet at the time of the published schedule. That is an important installed-versus-usable capacity boundary. A planned site can support pre-sales, reservation and architecture planning. It cannot support a July 2026 claim that the future rooms, power paths, cooling paths and customer migration procedures are already usable for production traffic.

The right diligence question is therefore twofold. For the current service, where exactly does the customer's workload sit today: Alpilink's own data centre, Orange - La Fabrique racks, another connected site, or a managed location not named publicly? For the 2027 project, when will reserved space become customer-usable, what acceptance tests must pass, how will customers migrate, and what happens if the new site schedule shifts? Installed capacity is the equipment and facility that can be powered, cooled, connected and supported today. Announced capacity is a promise about future equipment or rooms.

Usable capacity is the subset a customer can actually consume with contract terms, network reachability, backup policy and staff coverage.

The current service catalogue is broad enough to create many dependency paths

The Services Cloud page's list of housing, IaaS, virtual machines, managed services, backup and externalised disaster recovery matters because each service has a different failure shape. Housing is closest to the physical plant. The customer may own hardware, but Alpilink supplies rack space, power, cooling, cross-connects, physical access and some remote hands. IaaS and virtual machines move more responsibility to the provider: hypervisors, storage, orchestration, host maintenance, snapshots and sometimes operating-system templates. Managed services add staff and procedures.

Backup and disaster recovery add a separate recovery promise that must be more independent than the production environment it protects.

First-party numbers give a sense of scale: three connected data centres, 40 Gbit/s guaranteed bandwidth, more than 1,500 hosted servers and 3 PB of data stored. Those numbers are specific enough to be useful. They are also first-party numbers. The public route record for AS35667 shows a single visible /21; the broader AS28768 PeeringDB entity suggests more network footprint; the Services Cloud page suggests multi-site infrastructure; the HDS page names an own data centre and a subcontracted Orange rack location.

The evidence is consistent with a mature regional cloud provider, but it does not let an outsider allocate the 1,500-server claim across facilities, customers, service types or spare capacity.

The risk is not that the numbers are wrong. The risk is that buyers may read aggregate scale as individual protection. A provider can host 1,500 servers and still have a customer's workload concentrated in one rack. It can have three connected data centres and still sell a particular backup plan that does not include cross-site restore. It can guarantee 40 Gbit/s at a network level and still have customer ports, firewalls or storage arrays become the bottleneck. It can run 24/7 support and still have a hardware replacement path limited by part availability or access windows.

Aggregate capacity is a useful starting point; workload-level service design is the purchase decision.

This is especially true for backup and disaster recovery. Alpilink advertises externalised disaster recovery, and the HDS page uses French terms for continuity and regulatory guarantees. A customer should ask whether backup repositories sit in a separate facility and on separate administrative credentials, whether backup networks route through a different failure domain, whether restore tests are documented, how long a full restore takes, whether snapshots are immutable, and how ransomware, operator error or billing dispute scenarios are handled.

A backup service that depends on the same account, same storage fabric and same support queue as production may reduce accidental loss while still failing in a wider outage.

Managed services create another hidden dependency: people. Alpilink's public pages emphasize French expert availability, 24/7 coverage and local support. The HDS page states that part of the support workforce is in Tahiti and part of the company. That may be a strength, because time-zone spread can improve out-of-hours coverage. It also requires clarity. Which team can power-cycle equipment? Which team can access management networks? Which incidents require staff in Grenoble? How are privileges controlled? How are health-data access restrictions enforced?

What happens when a support incident requires the facility operator, the network team and a customer administrator at the same time?

The route and DNS evidence should be read as control evidence, not as a full service map

The public route evidence proves control of a usable Internet resource. It does not tell us where every service lives. RIPEstat geolocation at https://stat.ripe.net/data/geoloc/data.json?resource=94.143.216.0/21 and MaxMind GeoLite at https://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=94.143.216.0/21 place the /21 in France in the queried view. The DNS-chain query at https://stat.ripe.net/data/dns-chain/data.json?resource=xsalto.com showed xsalto.com resolving to 81.200.40.205 with nameservers ns01.xsalto.net, ns02.xsalto.net and ns03.xsalto.net. That xsalto.com web address is outside the AS35667 /21, so it should not be used as proof of the location or capacity of 94.143.216.0/21.

That is a normal pattern. A company's marketing site can be on a separate platform, a legacy address range, a group network, a web host or a content-delivery provider. The location of the public website is useful only if the claim is about website reachability. It is not a direct map of customer compute. Conversely, a routed /21 is useful control evidence but not a service catalogue. It can host management systems, customer VMs, DNS, monitoring, backup gateways and internal interfaces. Without a public service map, outsiders cannot say which addresses correspond to which product.

PeeringDB adds another layer but also has limits. AS35667's PeeringDB entry at https://www.peeringdb.com/api/net?asn=35667 lists XSALTO 2, website http://www.xsalto.com, AS set AS-XSALTO, one IPv4 prefix, one IPv6 prefix in the profile, Europe scope, 1-5 Gbit/s traffic, zero public IX count and one facility count. The facility API at https://www.peeringdb.com/api/fac/7114 identifies XSALTO Grenoble in Seyssinet-Pariset, with two networks and zero IX count in that facility record. PeeringDB is operator-maintained and can be incomplete, but it is still useful public evidence that the AS is not merely an abstract registration.

The broader AS28768 profile at https://www.peeringdb.com/api/net?asn=28768 is where the larger interconnection story appears. It lists one IX and three facilities, and the netixlan endpoint lists France-IX AURA LyonIX. That can support a hypothesis that Alpilink's wider network has more paths than AS35667 alone. It does not, without a customer-specific network diagram, prove that AS35667 customer traffic has independent upstreams, independent border routers, independent fibre routes or automatic failover across sites. The public route for AS35667 appears behind AS28768; customers should ask what diversity exists behind that boundary.

RPKI validity is the strongest route-hygiene point in the current AS35667 evidence. It reduces the risk of accidental or malicious origin conflict. It does not solve every routing issue. If AS28768 has a fault, if a facility loses power, if a cross-connect is cut, if a firewall fails closed, if a DDoS event overwhelms the handoff, or if customer DNS depends on a single provider path, RPKI cannot restore the application. It is a route-authentication control, not an operational recovery plan.

Power, cooling and density are where announced capacity must be treated carefully

Alpilink's new data-centre pages are notable because they talk directly about power density and thermal design. The January 2026 article says the future site is designed for rising application loads, critical information systems and data/AI workloads. It mentions modular multi-room architecture, high ceilings, electrical redundancy, climate redundancy, generator sets, physical security, access control, supervision, compatibility with advanced disaster recovery and business continuity, and a PUE target around 1.3.

The project page similarly says the future data centre targets a Tier III-equivalent architecture, complete electrical redundancy, modular multi-room design, energy density and efficient hot/cold flow management.

Those claims are commercially meaningful. They show Alpilink understands the problem that many regional cloud providers now face: density per rack is rising faster than legacy rooms were designed to absorb. A server room built for modest virtualisation can become constrained when customers ask for dense storage, analytics, AI, security appliances or high-memory hosts. The capacity constraint is no longer just rack count; it is power per cabinet, cooling path, cable management, UPS capacity, generator autonomy, breaker selectivity, monitoring and the human ability to replace failed components without disrupting neighbouring loads.

The timing matters. The same pages place works and fit-out in 2026, delivery and tests in early 2027 and progressive service in summer 2027. As of this article's publication date, those future rooms should be treated as planned or under development, not as already proven usable capacity. A buyer reserving space can benefit from the project; a buyer needing immediate production recovery cannot rely on that future site until it is commissioned, tested, connected, contracted and accepted.

The current green-hosting claims should also be read carefully. The July 2024 sustainability article at https://www.alpilink.fr/alpilink-cloud-notre-engagement-envers-un-hebergement-durable/ says Alpilink uses part of its infrastructure in an eco-responsible data centre with 100 percent renewable electricity, groundwater-calorie cooling without consuming water, compliance with the European Code of Conduct for Energy Efficiency in Data Centres and energy efficiency below 1.30 PUE. The June 2024 article at https://www.alpilink.fr/un-datacenter-peut-il-etre-vert/ says the Alpilink Cloud data centre near Grenoble is designed to be as virtuous as possible and uses hydroelectric energy.

Those sustainability claims can be operational strengths. Efficient cooling and local renewable energy can reduce operating cost and risk exposure. But PUE and green energy do not by themselves prove spare capacity. A low-PUE facility can be full. A renewable-powered site can still have generator, UPS, cooling, maintenance or staffing constraints. A sustainable equipment lifecycle can reduce waste while also increasing the need to understand hardware age, spare-part policy and refresh planning.

Customers should therefore ask for current capacity by rack, power draw, cooling allocation and service tier rather than relying on sustainability language alone.

Data locality is a strength, but it must be specified service by service

Alpilink's positioning is built around French sovereignty. The Services Cloud page says the company offers sovereign hosting in France and French support. The Tech&Fest 2026 article at https://www.alpilink.fr/techfest-2026-alpilink-services-cloud-au-coeur-des-enjeux-de-souverainete-numerique/ frames Alpilink Services Cloud around sovereignty, cloud and business continuity in Grenoble. The HDS guarantees page explicitly addresses health-data hosting, data location, certification, subcontractor roles and third-country access risk. That is more useful disclosure than a vague "secure cloud" badge.

The practical rule is still service-by-service. A customer's production VM may sit in Alpilink's own facility. A backup copy may sit in another connected data centre. A health-data rack dependency may involve Orange - La Fabrique. Support access may involve staff in Tahiti through encrypted access. DNS may be in one system, invoices in another and customer documentation in another. A sovereignty claim is strongest when each of those surfaces is mapped: compute, storage, backups, logs, tickets, monitoring, email, credentials, administration and disaster-recovery runbooks.

The HDS page gives customers a head start because it names roles and says no transfer of personal health data to a third country outside the European Economic Area is performed by Alpilink Cloud in that context. It also says Alpilink Cloud is not SecNumCloud 3.2 qualified in the displayed table. That distinction is important. HDS and ISO 27001 can be strong controls for particular uses, but they are not the same as SecNumCloud qualification, not a full resilience proof and not a guarantee that every product, customer or subcontracted component is in the same scope.

For non-health workloads, the same diligence applies with different labels. Where is the data? Who can access it? Which country governs the contract? Which subcontractors provide rack, network, power, monitoring or support? How quickly can the customer export data? Are backups stored in the same legal and operational domain as production? Are logs retained in France? Are encryption keys customer-held, provider-held or shared? If a customer must leave, can it obtain disk images, database dumps, entity-store exports and DNS control without waiting for a manual support queue?

The strongest version of Alpilink's offer is local, specific and operational: Grenoble-centred staff, French facilities, named certifications, concrete racks, known network resources and reachable migration paths. The weaker version would be a broad sovereignty slogan without per-service mapping. The public record is closer to the stronger version than many providers, but a buyer still needs the exact schedule and product scope for its own deployment.

Failure paths: what breaks first, and who is affected

The most obvious failure path is a rack or facility problem. Housing customers may lose power, cooling, cross-connects or remote-hands access. IaaS customers may experience host, storage or network failure. Managed-services customers may also lose the staff operating sequence needed to diagnose incidents. If the affected location is Alpilink's own data centre, the provider controls more of the response. If the affected asset is a subcontracted colocation rack, the provider must coordinate with the colocation operator. That distinction matters during a night or weekend outage.

The route failure path is narrower but visible. AS35667 publicly rides through AS28768 in the observed data. If the internal boundary between AS35667 and AS28768, the parent AS routers, or the upstream/peering fabric behind AS28768 has trouble, customers numbered from 94.143.216.0/21 may see reachability effects. RPKI validity will not help if the authorized path is physically or operationally down. Customers should ask whether customer prefixes can be shifted, whether there are multiple border devices, where the devices are located, and whether path diversity is tested rather than just configured.

The support failure path is human. Alpilink's 24/7 support claim is valuable, and the HDS page's reference to Tahiti-based support may improve coverage. But customers should know what that support can actually do. Can the overnight team restart a host? Can it replace a disk? Can it access the facility? Can it approve route changes? Can it restore a backup? Can it communicate in the customer's required language? Can it act when health-data restrictions apply? The difference between "we saw the alert" and "we restored service" is the difference between monitoring and recovery.

The migration failure path is the quietest and often the most expensive. Alpilink's current cloud services and future data-centre project make migration a central question. Customers may need to move from an existing Alpilink room to the new Saint-Martin-d'Hères site, from a legacy rack to a high-density room, from physical servers to IaaS, or from Alpilink to another provider. Each move depends on network renumbering, DNS TTLs, backup export, storage replication, maintenance windows, application dependencies and staff availability. A future data-centre build improves resilience only after the migration plan is real.

The affected parties are wider than the direct buyer. Alpilink's cloud services serve organisations that care about sovereignty, health-data hosting, managed operations, business continuity and local support. If a rack, route, storage cluster or support process fails, end users may lose public websites, tourism or commerce systems, payment-adjacent applications, internal business services, health-data workflows, backup restores or disaster-recovery staging. The public articles around Tech&Fest describe DSI, RSSI and business teams looking for regional and sovereign cloud models.

Those are precisely the users for whom recovery time, data location and support escalation are not abstract concerns.

What would raise or lower the evidence grade

The current evidence grade is Medium-strong for identity and network hygiene because RIPE RDAP, RIPEstat and PeeringDB agree on the company, AS, address block, route visibility and French facility context. It is Medium for customer resilience because public evidence does not show the live service map behind the aggregate claims. Alpilink publishes more operating detail than many small providers, but customers still need direct confirmation of present rack placement, usable capacity, power design, backup isolation and support authority.

The grade would improve if Alpilink published a dated infrastructure statement that maps current services to facilities, explains which data centres are connected by the optical loop, states where AS35667 and AS28768 border devices sit, names current upstream/transit arrangements at a service level, gives a public status or incident-history page, describes backup separation, and distinguishes current capacity from the 2027 site. It would improve if the company published customer-readable migration guidance for the Saint-Martin-d'Hères build, including acceptance testing, failback, route plans and support windows.

The grade would fall if AS35667 lost broad route visibility, if the valid RPKI state disappeared without explanation, if PeeringDB facility information became stale or contradictory, if first-party pages stopped distinguishing current services from future capacity, if HDS/ISO statements became unclear, or if customers could not obtain current facility and recovery facts under contract. It would also fall if the future data-centre project were marketed as usable production redundancy before it was commissioned and tested.

The most important point is that Alpilink's public record is not empty. It is substantive. The caution comes from precision, not from absence. A buyer has enough evidence to justify a serious evaluation. It does not yet have enough public evidence to skip technical due diligence.

What customers should require before they count the capacity

The most practical way to buy from Alpilink is to ask for a workload map before treating any headline number as available capacity. The map should name the facility where production compute runs today, the facility where backups rest, the route path used by the customer's public addresses, the storage layer behind virtual machines, the support team that can act out of hours and the migration method if the customer moves to the planned Saint-Martin-d'Heres site. That request is not special treatment. It is the minimum translation from public infrastructure claims into a customer-specific operating plan.

For route resilience, the map should separate AS35667 from the broader AS28768 context. Public RIPEstat evidence shows AS35667 with one visible IPv4 /21 and one observed neighbour, while PeeringDB shows AS28768 with a broader facility and exchange footprint. That difference can be perfectly reasonable inside one provider group, but a customer should not assume that every AS28768 path protects every AS35667 service.

The contract should say which AS originates the customer's addresses, where the border routers sit, which upstream or peering paths carry the traffic, whether failover has been tested, and whether customer DNS and control access depend on the same location.

For facility resilience, the map should distinguish Alpilink's own data-centre operation from the Orange - La Fabrique rack dependency named in the HDS guarantees page. A customer whose workload is housed in an Alpilink-operated room faces one response model; a customer whose workload depends on subcontracted racks faces another. The buyer should know who controls physical access, who can replace equipment, who owns the power incident response, what maintenance windows apply and which service credits or exit rights apply if either site is unavailable.

Without that detail, the phrase "three connected data centres" remains useful marketing context rather than customer-level redundancy proof.

For installed versus usable capacity, the buyer should ask for current numbers rather than project numbers. The Services Cloud page's 1,500 hosted servers, 3 PB of stored data and 40 Gbit/s bandwidth claims describe aggregate scale. The 2027 Grenoble project pages describe future high-density rooms, generator-backed resilience and PUE targets. Neither set of claims tells a specific customer how much spare CPU, RAM, storage, cabinet power, cross-connect capacity or support time is available today.

A customer planning a critical deployment should ask which capacity is free, which is reserved, which is oversubscribed, which requires hardware procurement and which depends on the 2027 commissioning schedule.

For recovery, the map should include restore proof. Backups and externalised disaster recovery are valuable only if the backup path is separate enough from the production failure. Customers should require recent restore-test evidence, backup location, backup access controls, encryption-key ownership, restore-time estimates, restore-order priorities and a data-export route that does not depend on a single overloaded support queue. A provider can have real regional strengths and still leave a customer exposed if the recovery process is manual, undocumented or tied to the same failed storage system.

These questions do not turn Alpilink into a weak candidate. They are the questions a credible regional provider should be able to answer. The public evidence already shows a routeable French cloud operator with visible infrastructure investment. The missing piece is not identity; it is customer-specific resilience proof. Once the workload map exists, Alpilink's local presence, compliance claims, Grenoble focus and future data-centre project can be evaluated against a real failure model rather than against a brochure.

Bottom line for dependent operators

XSALTO35667 Alpilink Cloud S.A.S. should be treated as a real French regional cloud and hosting operator with stronger-than-average public identity evidence. AS35667 is registered to Alpilink Cloud S.A.S., its main visible IPv4 /21 is broadly announced, RPKI is valid, PeeringDB lists XSALTO Grenoble, and Alpilink's own cloud pages describe housing, IaaS, virtual machines, managed services, backup, disaster recovery, certifications, health-data guarantees and a multi-data-centre story. The operating picture is specific enough to matter.

The dependency picture is also specific enough to question. AS35667's public route surface is narrow. The broader AS28768 network appears more diverse, but the exact customer path must be verified. The Services Cloud scale claims are first-party and aggregate. The new Grenoble data-centre project is planned for 2027 and should not be counted as July 2026 usable production capacity. HDS, ISO 27001 and sustainability claims are valuable, but they must be mapped to the customer's actual facility, service and support path.

For a current customer, the practical questions are direct. Which facility hosts my workload today? Which AS and prefix carry it? Which upstreams and routers are in my path? Are backups outside the production failure domain? Which staff can act out of hours? What is my restore time for a failed host, storage system, rack power event, route problem or site outage? If I need to migrate to the new data centre, what has to change and who owns each step?

For a new buyer, the public record supports a qualified conversation rather than a blind purchase. Alpilink has the visible ingredients of a credible regional cloud provider: real routing resources, a named facility context, local operations, compliance claims and an infrastructure investment plan. The purchase decision should turn on current proof of usable capacity, failure isolation and exit rights. Hosted capacity always resolves back to physical dependencies.

In Alpilink's case, those dependencies are visible enough to ask better questions: racks in Grenoble, route control through AS35667 and AS28768, power and cooling limits, 24/7 support authority, backup separation, and the migration path from today's rooms to tomorrow's promised site.