Summary

  • France's official company search identifies an active BE YS CLOUD FRANCE, SIREN 838375780, created in 2018, with two open establishments and a 2023 employee band of 20 to 49 people.
  • RIPE records connect the same registration number and Clermont-Ferrand address to LIR organisation ORG-BYCF1-RIPE, autonomous system AS200102 and an allocated IPv4 block.
  • RIPEstat showed nine IPv4 /24 routes announced by AS200102 on July 15, 2026. That is meaningful network evidence, but it is not proof of cloud capacity, data-centre location, customer tenancy or service quality.
  • The public record supports treating BE YS Cloud France as an identifiable French network operator. Buyers still need contractual evidence for workload locality, automation, resilience and support accountability.

The company name needs a legal anchor

The first due-diligence problem is surprisingly basic: which public name identifies the contracting company? The BTW directory uses “BE YS Cloud France SASU,” as does RIPE. France's official company-search API returns the corporate name BE YS CLOUD FRANCE, with SIREN 838375780 and legal form code 5710, the code for a simplified joint-stock company. An exact API search including “SASU” returned no company, while the shorter name returned one clear result. This is not evidence of wrongdoing. Operational registries often preserve a label after corporate particulars change. It is a reason to use the SIREN, rather than typography or a suffix, as the durable identifier.

The French government company record says the company was created on March 21, 2018 and remains administratively active. It lists the head office at 46 rue du Ressort in Clermont-Ferrand and a second open establishment in Balma. The head office is classified under computer systems and software consultancy, while the company-level activity is other information-technology services. The record names Christophe Prugnaud as president and Younes El Gui as director-general.

Scale matters because a cloud name can otherwise imply almost anything. The government record places the workforce in the 20-to-49 employee band for 2023. It also reports 2024 revenue of EUR5.08 million and net income of EUR774,238. Those numbers show an operating business with staff and reported accounts, not merely a dormant corporate wrapper. They still say little about how many people work on infrastructure, security, software engineering or support. Revenue is evidence of commercial activity; it is not a service-level metric.

The identity chain becomes stronger when a separate technical registry lands on the same details. RIPE's organisation object gives the name BE YS Cloud France SASU, the Clermont-Ferrand address and registration number “838 375 780 R.C.S CLERMONT-FERRAND.” The correspondence between an official company number and an independently maintained internet-resource record is the most useful public identity signal in this case.

The routing footprint is the clearest operating evidence

The public network record goes beyond a company description. RIPE's record for the organisation identifies it as a local internet registry and links it to AS200102, whose registered name is BE-YS-CLOUD. The autonomous-system object is assigned rather than reserved, and its declared routing policy names AS3215 as the network from which it accepts routes and to which it announces AS200102. That policy declaration is useful relationship evidence, although it should not be mistaken for a live measurement of path diversity or failover.

The address evidence is similarly concrete. The RIPE RDAP response for 185.34.140.92 places the address inside the active allocation 185.34.140.0/22, named FR-BEYSCLOUD-20130903. The record identifies BE YS Cloud France SASU as the registrant, gives the same Clermont-Ferrand address and exposes a NetworkTeam role plus an abuse contact. Public DNS adds a small but useful bridge: be-ys.com resolves to 185.34.140.92, while be-ys.cloud resolves to 185.34.140.17. Both addresses sit inside the registered /22.

This is stronger than a cloud-themed domain pointing at an unrelated hosting provider. The legal identity, resource-holder identity, autonomous-system name, registered address and domain endpoints converge on the same operator. It suggests that BE YS Cloud France controls at least part of the network surface associated with its public names.

There is also visible routing activity. A RIPEstat snapshot for AS200102, queried on July 15, returned nine IPv4 /24 prefixes visible during the July 1-to-15 interval: four covering 185.34.140.0 through 185.34.143.255, four covering 45.141.112.0 through 45.141.115.255, and 194.31.51.0/24. Nine /24s represent 2,304 IPv4 addresses in route-size terms, although not every address is usable, active or customer-facing. The returned set contained no IPv6 prefix; that observation applies to the response, not to every possible private or upstream arrangement.

For customers, the mechanism matters. Public routes are the paths through which hosted services, management interfaces and automated integrations become reachable. An assigned ASN and recurring prefix visibility show an operating surface that can be monitored independently. They do not reveal server count, storage capacity, tenancy model, traffic volume, latency, DDoS controls or whether customer applications actually use those prefixes.

A network is not yet a cloud-service proof

The evidence supports “network operator” more strongly than it supports any particular meaning of “cloud.” The reviewed public sources did not expose a product catalogue, API reference, orchestration model, service-status history, standard architecture or customer support terms attributable to this legal entity. Without those materials, there is no sound basis for asserting that BE YS Cloud France provides infrastructure as a service, managed private cloud, backup, platform automation or some narrower hosting function.

That distinction is especially important for enterprise software automation. A buyer needs to know whether provisioning, identity, policy, metering, backup and incident actions can be driven through stable interfaces rather than tickets and manual intervention. Evidence would include versioned API documentation, infrastructure-as-code support, role-based access controls, audit-event export, maintenance semantics and tested recovery procedures. The ASN cannot answer any of those questions. It proves an addressable network boundary, not an automation contract.

The same caution applies to resilience. AS200102's registry policy names one external autonomous system, but a registry entry does not establish the number of physical carriers, diverse fibre paths, data-centre sites or power domains. A buyer assessing a critical workload should request a current topology at an appropriate level of disclosure, then reconcile it with observed routing and contractual recovery objectives. The public record is a starting point for that conversation, not the conclusion.

French registration does not prove French data residency

BE YS Cloud France has meaningful French locality signals. Its company and RIPE addresses are in Clermont-Ferrand, the company has establishments in Clermont-Ferrand and Balma, and the reviewed IPv4 allocation carries country code FR. These facts can support jurisdictional and supplier-identity checks. None proves where customer data, backups, encryption keys, logs or privileged administrators are located.

Data sovereignty is a chain of controls, not a postal address. A buyer would need named processing and backup locations; the legal entities operating each site; subprocessor and remote-access arrangements; replication boundaries; key-management responsibility; deletion and return procedures; and the contractual remedy if data crosses an agreed boundary. Route registration can indicate where an operator is organised, but IP-country fields are not workload geolocation certificates. Traffic may also traverse foreign networks even when storage remains in France.

The prudent conclusion is narrower and more useful: the public record makes BE YS Cloud France traceable to a French company and a French-registered internet-resource holder. Any stronger claim about sovereign cloud status requires service-specific documentation and contract language.

Local presence improves accountability, but support remains unmeasured

The staffing and contact record offers more than a mailbox company would. The official employment band indicates a local workforce of some substance. RIPE publishes a NetworkTeam role, a Clermont-Ferrand telephone number and an abuse mailbox on the be-ys.com domain. These are genuine accountability signals because technical and abuse issues have a named organisational route tied to the same address as the company.

They are not a substitute for customer support evidence. An abuse contact serves internet-coordination duties; it does not promise 24-hour incident response, an escalation manager or restoration within a defined period. The public sources do not establish support hours, languages, severity definitions, response targets, on-call staffing, customer communication cadence or historical attainment.

For a prospective customer, the useful test is operational: ask who receives a priority-one alert at 03:00, which team can change the network and platform, how an escalation crosses from support to engineering, and what evidence is supplied after an incident. Then put the answer into measurable contract terms. Local labour matters when it shortens that chain of responsibility. Headcount alone cannot show that it does.

What the public record now supports

BE YS Cloud France should not be treated as an assurance claim merely because “cloud” appears in its name. It should be treated as an identifiable French business with reported activity, staff, a RIPE LIR identity, an assigned ASN, registered address space and nine recently visible IPv4 routes. That is a substantive foundation and a considerably sharper picture than the directory's unassessed status alone provides.

The remaining uncertainty is equally substantive. Public evidence does not yet describe the service boundary, customer automation, physical hosting locations, resilience design, data-residency controls or support performance. Those gaps do not negate the network evidence. They define the next layer of proof. For procurement and risk teams, the decision rule is simple: use the SIREN and RIPE records to establish who and what exists, then require service-specific documents before converting an operating footprint into operating assurance.