TEMPLE Cloud Temple SAS sells hosted capacity that still depends on racks, transit and repair windows

Summary

• TEMPLE Cloud Temple SAS maps to a visible French sovereign-cloud business: Cloud Temple’s public pages describe SecNumCloud-qualified IaaS, VMware IaaS, OpenSource IaaS, object storage, bare metal, VPC, private backbone, housing and support services for regulated sectors.
• Official compliance pages say the IaaS Secure Temple scope covers VMware IaaS, OpenSource IaaS, S3 Object Storage, HSM-KMS encryption and Bare Metal, with SecNumCloud v3.2 validity listed to May 30, 2028; the same page lists PaaS OpenShift separately.
• Public routing is real and current: RIPEstat showed AS33930 announced on July 12, 2026, with six IPv4 prefixes and two IPv6 prefixes, full RPKI-valid origin results in the checked view, and broad RIS visibility.
• The risk is not that the provider lacks public operating evidence; the risk is that certification, AS visibility and product labels still do not tell a customer exactly which rack, availability zone, recovery path, support tier or exit process protects a specific workload.
• Buyers should treat Cloud Temple’s public evidence as a strong starting point for due diligence, then verify workload placement, support escalation, hardware availability, restore tests, customer-circuit responsibility, billing effects and data-portability limits before moving critical systems.

TEMPLE Cloud Temple SAS is the kind of cloud company that can look simple from a directory card and complicated as soon as a customer asks what actually has to work. The name points to a sovereign-cloud provider with visible French offices, compliance claims, a routed autonomous system, a public support offer, an official status page and technical documents that describe compute, storage, network, physical hosting and responsibility boundaries. That is enough to reject a weak operating-status reading. It is not enough to treat every availability or sovereignty claim as self-executing.

The company sells hosted capacity, but the capacity still depends on real facility space, power, cabling, route selection, vendor platforms, support labor, customer configuration, restore testing and contract terms.

The company’s own “Who are we?” page positions Cloud Temple around sensitive sectors, naming industry, finance, healthcare and the public sector as the markets where its promise is meant to matter. Its locations page lists offices in Paris / La Defense, Lyon, Tours, Caen and Nantes, with the Paris / La Defense address at Le Belvedere - SPACES, 1-7 Cours Valmy, 92800 Puteaux. That is useful identity evidence, but the office map is not the infrastructure map. A buyer should not confuse an office address with the site where a virtual machine, bare-metal blade, S3 bucket, VPC gateway or physical rack is running.

The stronger public evidence is the compliance and product footprint. Cloud Temple’s compliance procedures page says the company has ISO 27001 certification for infrastructure since 2018 and for managed services since 2022, HDS certification for health-data activities, SecNumCloud v3.2 qualification, ISAE 3402 reporting and other European compliance entries. The same page gives the most concrete scope statement: “IaaS Secure Temple” is listed under SecNumCloud v3.2 with validity to May 30, 2028, and the footnote says that scope includes VMware IaaS, OpenSource IaaS, S3 Object Storage, HSM-KMS encryption and Bare Metal. That does not make every product identical, but it does place the main infrastructure products inside a public qualification perimeter.

Cloud Temple’s SecNumCloud approach page makes the strategic pitch: cloud should protect confidence for businesses and public bodies, and product design should align with demanding European security standards. The page also says qualification means compliance with more than 700 ANSSI requirements and best practices across technical, physical, contractual and operational areas. That statement matters for infrastructure risk because it is explicitly broader than cyber controls. It is about how a provider is run. Yet even a broad qualification is not a per-customer architecture document. It does not tell a hospital, insurer, public agency or industrial client whether its own tenant has two compute hosts, which availability zone holds the passive copy, or whether its firewall change is covered by the support tier in force.

The product line shows why those details matter. Cloud Temple’s compute offer spans several consumption patterns. The public site describes OpenSource IaaS for virtualized infrastructure on a sovereign platform, VMware IaaS for VMware estates in a qualified cloud environment, Bare Metal for dedicated physical servers, and VM Instances in preview for more shared cloud-style virtual machines. The company’s public docs for OpenSource IaaS describe Cisco UCS compute, IBM Spectrum Virtualize and IBM FlashSystem block storage, Dell ECS object storage, Juniper networking, dedicated compute blades and storage volumes, monthly consumption pricing, region and availability-zone concepts, backups, replication options and API or Terraform operation. That is not a lightweight hosting catalog. It is a physical and operational stack.

The stack has a specific implication: installed capacity and usable capacity are not the same thing. A page can show blade classes, storage classes and connectivity figures, while a customer still has to ask whether the exact class is available in the desired region, whether adding another host requires hardware stock, whether a GPU blade has a lead time, whether the second availability zone has matching storage performance, and whether the customer’s licensing allows live failover.

Cloud Temple’s OpenSource IaaS concepts list blade classes from ECO through PERFORMANCE 4, with memory, core counts, 10 Gbit/s or 25 Gbit/s connectivity and, for the top class, NVIDIA L40S GPUs as of May 1, 2024. That is useful detail. It also tells a buyer that capacity is not abstract: it is delivered by particular hardware families with finite inventory.

Bare metal sharpens the point. The Bare Metal documentation describes dedicated physical servers connected to distributed block storage, Cisco UCS blades, IBM Spectrum Virtualize storage, availability-zone placement, KVM-style console access, ISO mapping, power operations, VLAN tagging and two network interfaces whose speed depends on the blade class. The product is attractive precisely because it gives customers more control over the operating environment. But that control pushes some risk back to the customer. If a customer installs its own hypervisor or operating system, Cloud Temple can provide the blade, storage and platform access, but the customer still owns the choices that turn hardware into a resilient application.

The VMware side has a similar tension. Cloud Temple’s VMware IaaS material describes dedicated blade, storage and network resources, vSphere compatibility, L2 VLANs, inter-availability-zone propagation, intra-AZ latency below 3 ms and inter-AZ latency below 5 ms in the documented view, and high availability that only works if a cluster has the required host design. The public docs note that if an availability zone contains only one hypervisor, automatic restart on another hypervisor is not possible. That is the kind of sentence that turns a cloud promise into engineering reality.

A customer can buy infrastructure from a qualified provider and still build a fragile single-host environment if it chooses the wrong shape or defers the second node.

Storage also needs precision. Cloud Temple’s public object storage page says the service is based on Dell Elastic Cloud Storage, offers high S3 compatibility, is qualified SecNumCloud, certified HDS and ISO 27001, replicates automatically across three availability zones, uses EC 12+4 erasure coding, supports TLS 1.2/1.3 plus server-side encryption options, lists 99.99 percent availability and 99.999999999 percent durability, and advertises no egress fees. Those are serious claims for backup, archive and application storage buyers. They still need to be mapped onto the customer’s own duty to set lifecycle, immutability, key and restore policy. Three-zone object storage helps with platform durability; it does not by itself prove that a customer can restore the right entity version after ransomware, mistaken deletion, bad retention design or an access-key compromise.

The responsibility split is not hidden. Cloud Temple’s shared-responsibility page points readers to RACI matrices for IaaS, VM Instances, object storage, network and other services. The IaaS responsibility matrix says Cloud Temple is responsible and accountable for implementing physical data centres, compute infrastructure, storage infrastructure, backbone connectivity, essential platform software licenses, baseline tenant configuration and initial backup setup. It also says the customer is responsible and accountable for defining the overall architecture, tenant count, availability-zone count, continuity and recovery strategy, sizing for compute, storage, network and backup, creating and maintaining virtual machines, associating each VM with coherent backup and recovery plans, and carrying out periodic backup and recovery tests.

That division is probably the most important fact in the whole record. It means the company can be a qualified infrastructure provider while still leaving critical design decisions with the customer. If the customer under-sizes a tenant, omits backup tests, fails to spread workloads across zones, keeps a broken firewall rule, loses administrator access, or keeps a single application node inside an otherwise resilient platform, the failure will not behave like a simple provider outage. It will be a joint architecture failure with only some layers covered by provider commitments.

The article’s risk question is therefore not “Is TEMPLE Cloud Temple SAS a real cloud company?” The answer is yes. The question is “Which part of this customer system is inside Cloud Temple’s accountable perimeter, and which part is still the customer’s own design?”

The same split appears in networking. Cloud Temple’s Private Backbone documentation says the product provides L2 VPLS private networks across availability zones, private Internet access components, IP addressing, native anti-DDoS protection, ports for external connectivity, 1G/10G circuits and private links on two diversified optical paths for dedicated circuit products. The Internet concepts page says Cloud Temple operates its own AS, offers two transit paths and two Paris exchange points, supports BGP4, provides public IPv4 by unit and IPv6 prefixes, reserves Internet bandwidth in 100 Mbit/s increments, and charges on a 95th percentile basis rather than volume egress. These are material network-design facts, not decorative claims.

But again, the boundary matters. The network responsibility matrix says the customer is responsible and accountable for subscribing to operator connectivity to access a physical Cloud Temple data centre, and for managing incidents, problems and capacity on the customer’s own operator links. Cloud Temple takes responsibility for the backbone, collection points and data-centre interconnection points, and for physical housing starts responsibility at the top-of-rack equipment. That boundary is exactly where many incidents become painful. A workload may be healthy inside Cloud Temple, but a customer site can still fail through an enterprise MPLS link, a carrier access circuit, a bad IPsec change, a local firewall, a DNS mistake or a capacity limit on the customer side.

Public routing evidence supports the idea that the company operates a real network. RIPE RDAP for AS33930 names CLOUD-TEMPLE and lists Cloud Temple SAS as a registrant entity, with the organization address at Le Belvedere, 1 Cours Valmy, 92800 Puteaux. RIPEstat’s AS overview identified the holder as CLOUD-TEMPLE Cloud Temple SAS and showed the AS as announced at the July 12, 2026 query time. RIPEstat’s announced-prefixes view showed eight active announcements in the window ending July 12, 2026: 91.223.207.0/24, 45.15.212.0/22, 185.56.204.0/22, 194.6.240.0/24, 93.187.40.0/21, 80.75.152.0/21, 2a02:668::/36 and 2a02:668:9000::/36.

That routing record is stronger than a marketing-only footprint. RIPEstat’s routing-status view showed six IPv4 prefixes, two IPv6 prefixes, 6,656 announced IPv4 addresses, 8,192 IPv6 /48s, 54 observed neighbours, and near-complete RIS visibility in the checked snapshot. RIPEstat’s routing-consistency view showed the announced AS33930 prefixes present in both BGP and RIPE route-policy sources, with no inconsistent-prefix list in the checked output. RPKI validation returned “valid” for the eight checked AS33930 prefix-origin pairs. Those facts do not tell a customer how redundant a particular service is, but they do show that the network layer is visible, maintained and not merely legacy residue.

Transit and peering evidence is also useful, though it must be read carefully. RIPE RDAP remarks for AS33930 mention peering requests, France-IX and Equinix Paris exchange details. PeeringDB’s Cloud Temple network page lists the network as Cloud Temple, with Cloud Temple’s older aka name Intrinsec, an open general peering policy, and an updated date in April 2025. PeeringDB’s public exchange view shows France-IX Paris and Equinix Paris IX entries at 10 Gbit/s, while its facility view lists Telehouse Paris 2, Telehouse Paris 3, Equinix PA6, Digital Realty Paris PAR7 and DATA4 Paris Marcoussis - PAR1 as facilities associated with the network profile. This corroborates Paris-market interconnection, but it is still a public peering profile, not a binding map of customer workload placement.

The public status page adds another angle. Cloud Temple’s status page exposes components under FR1, including AZ labels such as PA6, PAR7, TH3, PAR7S, TH3S and AZ07, along with categories for OpenIaaS, Object Storage, PaaS OpenShift, Bare Metal, VPC, edge services and public interfaces. A status page is valuable because it gives customers a public place to observe incidents and maintenance. It does not answer the deeper question by itself: which of those availability zones, services and components does this customer actually use, and does the customer’s own application survive if one of them is degraded?

The failure paths become clearer when the product line is read as one system. A rack or facility failure affects compute, storage, network and housing differently depending on placement. An upstream or route failure affects Internet-facing services, customer prefixes, VPN access and support visibility differently depending on BGP design. A hardware-stock failure matters for bare metal, GPU blades, storage expansion, firewall appliances and replacement hosts. A support failure matters differently under Standard, Premium and Company tiers. A billing or order failure can delay provisioning or expansion.

A migration failure can strand workloads even when the platform is healthy. None of these risks mean the provider is weak. They mean the cloud contract needs to be read as infrastructure, not as a magic abstraction.

Support terms are part of that infrastructure. Cloud Temple’s support levels page lists Standard, Premium and Company support with monthly rates of 5, 7 and 10 percent of service billing, minimum monthly billing levels, different Technical Account Manager access, P1 response targets of 2 hours, 30 minutes and 15 minutes, and 24/7 monitoring and intervention for cloud incidents. It also says engineers are available 24/7 for cloud incidents, while support requests have business-hour channels, with France-based support in French and English. The difference matters. A production incident for which Cloud Temple is responsible is not the same as a general assistance request, a customer-side configuration change, a migration planning question or a request for a non-catalogue task.

The support page also points back to the responsibility matrix for incidents with production impact for which Cloud Temple is responsible. That qualifier is not small print in practice. If a customer’s VM is up at the hypervisor layer but the application is down because the guest operating system is broken, the support path changes. If a customer’s VPC is healthy but the on-premise carrier circuit is down, the support path changes. If a backup exists but the customer never ran restore tests, the support path changes. Good support can help all of these cases, but the contract boundary and paid tier decide speed, channel and accountability.

The published SLA documents make the same point with numbers. The VM Instances SLA defines a 99.95 percent monthly availability commitment for each active billed VM Instance, equivalent to 21.9 minutes of allowed monthly unavailability. But it measures unavailability at the underlying Cloud Temple infrastructure layer, excludes guest OS, customer software, customer network configuration, application failures, scheduled maintenance, missing management components, abusive behavior and force majeure, and requires a support ticket within 30 calendar days to claim service credits. That is a normal cloud structure. It is also a warning: the SLA is not an application-uptime guarantee.

The VPC SLA is similarly specific. It gives 99.99 percent monthly availability for the VPC data plane and 99.9 percent for the control plane, with five minutes as the counted unavailability threshold. It covers Cloud Temple-managed VPC components such as the router, private networks, external gateway, NAT, DNAT and floating IPs. It excludes customer filtering rules, bad addressing, connected compute failures, external Internet connectivity beyond Cloud Temple’s demarcation, scheduled maintenance, abusive behavior and force majeure. Those exclusions are not failures in the document; they are how the real operating boundary is drawn.

Object storage has a different exit and recovery profile. The public product page says customers can recover entities through S3-compatible access and that Cloud Temple does not charge egress fees. The S3 responsibility matrix says Cloud Temple is responsible for maintaining and securing the S3 platform, access to the service, logs, monitoring, incidents, problems, capacity and service changes. It says the customer is responsible for creating entities, creating access keys, managing entity lifecycle, managing entity rights, managing logical security, backups of the data, periodic restoration tests, application continuity plans and reversibility execution. That means no egress fee is helpful, but portability still requires customer planning, credentials, bandwidth, retention logic and a tested destination.

Migration is where hosted capacity often reveals its true cost. Cloud Temple’s products are explicitly compatible with familiar ecosystems: VMware estates, S3 access, OpenStack-style OpenSource IaaS, API-based operation, Terraform-based provisioning and BGP for customer prefixes. Those are interoperability signals. They reduce lock-in compared with a closed proprietary stack. Yet a move out of the platform is still a project: server images, storage volumes, entity buckets, firewall rules, access rights, routing, keys, DNS, monitoring, support agreements and rollback windows all have to line up.

The IaaS RACI says the customer is responsible for planning reversibility, choosing target infrastructure, executing transition operations and managing service-quality effects during transfer, while Cloud Temple handles dismantling configurations and secure erasure after contract end.

Billing and ordering are not side issues. The support page says minimum support billing starts when resources are provisioned. The network docs say public IPv4 addresses are delivered within available stock, Internet bandwidth is reserved by 100 Mbit/s increments, private circuits can carry 36-month commitments, and dedicated housing or hands-and-eyes services can have 12- or 36-month terms depending on item. Object storage pricing is usage-oriented, while bare metal and housing are tied to physical units. This mix affects resilience.

In a rush, a customer may discover that the emergency action is not only a technical command; it may be a new order, a support request, a circuit quote, a stock-dependent delivery, or a contract amendment.

Procurement channels add another operating layer. Cloud Temple’s IaaS and Bare Metal pages point public-sector and health-sector buyers toward public purchasing routes such as UGAP and CAIH. That matters because it can make the provider easier to adopt for organizations that cannot buy infrastructure through ad hoc negotiation. It also means resilience planning may be shaped by framework terms, pre-approved catalog entries, order forms, minimum commitments and public procurement timing.

A public buyer may be able to order a qualified service more cleanly, but it still needs to know whether a later capacity expansion, urgent circuit, premium support change or migration-assistance request fits the same purchasing path.

This is one reason the economics of hosted capacity should not be reduced to a monthly unit price. A customer moving from its own server room to TEMPLE Cloud Temple SAS is shifting capital cost, staffing burden and facility risk to a provider with specialized infrastructure. That can be rational, especially for regulated customers that cannot easily build SecNumCloud-grade controls alone. But the customer is also accepting a new cost shape: reserved bandwidth, support-tier percentages, storage consumption, IP addresses, private circuits, hands-and-eyes time, professional assistance, physical hosting terms, and exit bandwidth.

The cloud bill is not only compute and storage. It is also the price of choices made before a failure.

The no-egress-fee claim on object storage is a good example of a buyer-friendly term whose operational meaning depends on context. If a customer can recover all entities through S3-compatible access without egress charges, the commercial barrier to exit is lower than in many hyperscale arrangements. But moving many terabytes or petabytes still consumes time, bandwidth, access-key control, destination capacity, entity naming discipline and retention-policy awareness. If Entity Lock is enabled, a customer also has to respect its own immutability choices.

The absence of an egress fee does not erase the need for a migration window, a destination design and a verified copy process.

The public status page should be used in the same practical way. It is valuable because it names components that customers can monitor during an incident, and it signals that Cloud Temple has made part of its operational state visible. Yet a status component is only useful if the customer knows how it maps to its service. If a customer sees an item for FR1 Object Storage or a specific availability-zone label, can it tell whether its bucket, tenant, VPC gateway or bare-metal blade is affected? Does the customer’s own incident bridge include someone who understands those labels?

Has the support tier promised a communication channel for the severity at hand? Visibility helps only when it is connected to the customer’s runbook and ownership records.

There is also a quiet dependency in the provider’s own public edge. A point-in-time DNS lookup observed cloud-temple.com on Cloud Temple address space, Gandi name servers, Microsoft mail protection, the console on another Cloud Temple address, and the status hostname through Atlassian Statuspage and CloudFront. Those are normal choices, and they do not weaken the core platform evidence. They do, however, show that customer communication may depend on layers beyond AS33930. In a serious incident, the provider website, console, status page, mail path, phone support and customer tenant can fail or survive in different combinations.

Customers should keep more than one escalation channel and should not wait until an outage to test them.

The global category assigned to this article also needs nuance. Cloud services can be bought and reached globally, and AS33930 has worldwide routing visibility. But Cloud Temple’s public sovereignty story is primarily French and European, with FR1 product language, French offices, French support teams, ANSSI qualification, HDS relevance, Paris peering and French facility-market signals. For a customer outside France, the dependency may still be attractive if the goal is French or European data locality.

It also means latency, customer access circuits, legal expectations and operational support hours should be evaluated against the real user base. A global user population served from a French sovereign cloud may need additional caching, regional access design or application-level tolerance.

Sovereignty can also create a false sense of completeness if the customer treats it as a substitute for architecture. A qualified French provider can reduce exposure to certain legal, operational and security concerns, but it cannot decide the customer’s data classification, route failover, application clustering, tenant rights, key rotation, restore frequency or exit priority. Cloud Temple’s public documentation is unusually clear that many of those items remain with the customer. That clarity is good news. It gives buyers the chance to make the split explicit before production.

The risk is that a buyer reads the certificate headline and ignores the responsibility table.

The cleanest procurement question is therefore a table of demarcations, not a yes-or-no trust question. For each workload, the customer should write down the compute service, storage service, network service, availability zones, backup target, restore owner, support tier, customer circuit, public prefix, identity administrator, key owner, billing owner, maintenance contact and exit destination.

Then it should ask TEMPLE Cloud Temple SAS to confirm which items are provider-operated, which are customer-operated, which are in SecNumCloud scope, which are HDS-relevant, which are outside qualified areas, which are preview, and which need separate professional assistance. That exercise is mundane, but it is where cloud resilience becomes visible.

Physical housing is the most concrete reminder that the cloud has edges. Cloud Temple’s Housing documentation describes physical hosting by rack unit in shared racks or by dedicated 42U rack, two electrical chains for shared racks, per-U power limits, server-oriented 2U units with C19 power, dedicated racks with 3 kW over two 16A electrical chains, extra 2 kW increments, a 1,000 kg maximum equipment mass, monitored PDUs, copper or fiber network ports, meet-me-room connectivity and hands-and-eyes services. It also says dedicated racks are in shared hosting space outside the SecNumCloud area. That last distinction is important: “Cloud Temple housing” and “qualified IaaS Secure Temple” are not interchangeable phrases.

For some customers, housing is a bridge. A legacy appliance, mainframe-adjacent system, proprietary storage box, HSM, firewall or migration staging server may need to sit near cloud resources while a regulated workload moves. That can be sensible. It can also create a two-perimeter architecture: part qualified cloud, part non-qualified physical hosting, part customer-owned equipment, part Cloud Temple-managed network, part carrier circuit. If the customer assumes all of it has the same qualification, support response and recovery mechanics, the design can become misleading.

The housing docs are helpful precisely because they force the buyer to talk about rack units, watts, ports, optical paths, hands-and-eyes response and support escalation.

The data-sovereignty argument is therefore strongest when kept concrete. Cloud Temple’s pages make a credible sovereignty claim around French operation, SecNumCloud qualification, HDS, ISO 27001, support teams in France and products designed for regulated sectors. The object storage page emphasizes French and European regulatory needs. The support page says support teams are based in France and operate from France. The compliance page lists official validity dates and scopes. But sovereignty is not only a national label.

It is also placement, support access, subcontractor evidence, key custody, incident communication, export route, deletion proof and residual-risk disclosure. A customer should ask where each data copy, backup, log stream, support artifact and support intervention sits.

The public network footprint gives a similar lesson. AS33930 has visible prefixes, valid route-origin authorization in the checked view, exchange participation and facility listings. That is better than seeing only a reseller front end on someone else’s network. It means Cloud Temple has direct routing surface and a public interconnection story.

Still, routing evidence does not reveal which customer tenant uses which prefix, how DDoS mitigation is steered during attack, whether all paths are equally available during maintenance, which route preferences apply to customer-owned prefixes, or how quickly a customer can move IP identity away from the platform. A strong BGP record is necessary for some workloads, not sufficient for all of them.

The customers most affected are the ones Cloud Temple itself targets: public-sector bodies, healthcare providers, financial firms, industrial operators, software publishers and other organizations that need both compliance assurance and operational continuity. In those settings, a cloud outage is rarely just an inconvenience. It can delay care, freeze regulated reporting, halt plant-adjacent systems, block citizen services, interrupt identity access, or stop a software publisher from serving downstream customers. The right due-diligence question is not “Can Cloud Temple host a VM?” It clearly can.

The question is “Does the chosen service design match the operational harm if this application stops?”

For a public agency, the answer may involve SecNumCloud scope, tenant segregation, support tier, incident communication and reversibility. For a healthcare provider, it may involve HDS scope, backup restoration tests, support access, entity-lock retention and whether subcontractor evidence covers every path. For a finance team, it may involve audit evidence, route diversity, immutable archive, encryption, key custody and DORA-style exit planning. For an industrial company, it may involve low-latency links, facility proximity, private backbone design, maintenance windows and local operational fallback.

A single product label cannot answer those questions. The customer has to turn the public evidence into a workload-specific design review.

The failure path most worth testing is the compound one: an incident that crosses provider infrastructure, customer configuration and support process. Imagine a customer running VMware IaaS across two availability zones with a firewall pair, S3 backup copies, a customer-owned prefix, an on-premise fiber path and a Premium support tier. If one zone degrades, the application may depend on HA configuration, storage replication, firewall state, DNS behavior, route convergence, S3 availability, and a ticket that is classified correctly. If the customer’s own carrier circuit also has trouble, Cloud Temple’s backbone may not be the bottleneck.

If the customer’s backup policy was misdesigned, three-zone object storage may preserve the wrong data. That is why shared responsibility has to be exercised before the outage, not merely cited during it.

Maintenance windows deserve the same attention. The SLA language excludes scheduled maintenance notified under the customer’s support contract. That is normal, but it shifts practical planning to the customer. Who receives maintenance notices? Are they routed to the team that owns the application? Does the customer know whether a hypervisor update can trigger a restart? Does it understand that some hypervisor OS updates may be a customer decision because Cloud Temple is not aware of every workload-specific constraint? Are backup, monitoring and firewall teams present during the window?

A maintenance event is routine for the provider only if it is also routine for the customer.

Repair windows and hardware stock are more difficult to verify from public sources. The docs reveal classes of blades, storage limits, network ports and physical hosting units, but they do not publish spare blade counts, storage-controller spares, GPU inventory, lead times by class, or exact replacement practice by availability zone. That does not mean the stock is absent. It means public research cannot prove it. The right customer request is simple: show the capacity-reservation, expansion and replacement process for the chosen service.

If the application needs four more GPU blades during an emergency, or a replacement host after a blade failure, or extra object storage throughput during a recovery, the customer should know whether the answer is immediate, scheduled, order-dependent or quote-dependent.

The same applies to restore proof. Cloud Temple’s qualified platform, S3 redundancy and backup architecture create a stronger starting point than a generic host. But the IaaS and S3 responsibility matrices repeatedly place backup-plan coherence and periodic restore testing with the customer, sometimes with Cloud Temple consulted. That should change procurement language.

Buyers should ask not only “Is backup included?” but “Who writes the restore plan, who runs the test, who records the result, what happens if the restore misses the target, and what support tier applies during a real recovery?” An untested restore remains an aspiration even when the storage underneath is built well.

The evidence grade for TEMPLE Cloud Temple SAS should therefore be better than the assignment’s thin-footprint caution, but still not absolute. The public record is broad, current and specific: official pages identify regulated-sector positioning, French offices, SecNumCloud and HDS scope, product families, support tiers, object storage architecture, private backbone design, VPC and VM SLA terms, housing physical limits, AS33930 routing, RPKI validity, exchange points and public status components. That is a substantial footprint.

The missing evidence is narrower but decisive: customer-specific placement, exact facility operator assignment for each workload, spare inventory, support performance history, restore-test results, customer concentration, maintenance communications and real exit execution.

For buyers, the practical conclusion is to treat TEMPLE Cloud Temple SAS as a credible sovereign-cloud dependency that still needs workload-level proof. Ask for a diagram that names the region, availability zones, compute hosts or classes, storage classes, S3 buckets, backup policies, VPC gateways, Internet exits, customer circuits, support contacts and escalation paths. Ask which commitments are covered by SecNumCloud scope, which are HDS, which are ordinary housing, which are preview, and which are customer-owned. Ask how service credits are claimed and what they do not cover.

Ask how a workload leaves, how data is erased, how keys are handled, and how support behaves outside business hours.

For infrastructure readers, the lesson is broader. A sovereign-cloud provider can be both genuinely operational and still dependent on the mundane physics of capacity. TEMPLE Cloud Temple SAS sells an attractive combination: qualified French infrastructure, recognizable enterprise platforms, visible routing, object storage across three availability zones, support in France and explicit responsibility matrices. But the customer does not buy “sovereignty” in the abstract. It buys a particular tenant, blade class, storage tier, network path, ticket tier, maintenance calendar and exit arrangement.

Those are the pieces that will decide whether the hosted capacity survives a rack event, upstream event, hardware shortage, support queue, billing friction, migration pressure or provider-contract failure.