The commercial question is blunt: why would a customer choose a regional cloud operator when AWS, Azure, Google Cloud, OVHcloud, Scaleway, Outscale, Cloud Temple, Clever Cloud and a long tail of hosting providers are one credit card, one reseller agreement, or one procurement line away? The answer cannot be “compute.” Compute is too easy to compare, too easy to rent, and too hard for a small operator to differentiate at the level of CPU cycles, RAM, block storage, object storage or virtual-machine packaging. The only durable market a small French cloud operator can make is around the things that commodity cloud hides: locality, support, migration labor, procurement fit, low-friction operations, abuse handling, billing clarity, language, jurisdictional comfort, and the willingness to be accountable when something breaks.
That is the right frame for Clouding SASU because the public evidence does not support a clean hyperscale-style company profile. It supports something narrower and economically more interesting: an active French SASU with a broad IT-services corporate object, a founder-controlled origin, modest historical disclosed accounts, and real RIPE/RDAP network-resource evidence tied to AS212718, “clouding-asn.” The commercial issue is not whether Clouding can outbuild hyperscalers. It cannot, on any evidence now visible. The issue is whether Clouding can convert a small infrastructure identity into a defensible service market where the buyer pays not for undifferentiated compute but for reduced coordination cost.
The first product is not compute; it is removed hassle
A small regional cloud wins only when the buyer’s real cost is not the published price of a vCPU. For many SMEs, associations, small software publishers, local public-sector contractors, agencies, and industrial firms, the binding constraint is not that AWS is unavailable. It is that AWS is too large a surface area for the internal team, too easy to misconfigure, too expensive to govern, too complex to predict, or too remote when a routine migration, backup failure, DNS issue, certificate renewal, mail deliverability problem, or incident needs human ownership.
This is why “local cloud” is best understood as an economic bundle rather than a technical category. The bundle can include hosting, managed virtual machines, backup, monitoring, firewalling, domain and DNS work, mail routing, data migration, software licensing, light DevOps, procurement paperwork, French-language support, and in some cases network-number resources or BGP competence. The customer buys a reduction in operational ambiguity. Compute is the visible SKU; responsibility is the product.
That distinction matters because the French cloud market is already structurally hostile to generic challengers. The French competition authority described a cloud infrastructure and platform market in which hyperscalers dominate, with AWS, Google Cloud and Microsoft Azure representing most public-cloud infrastructure/application-spending growth in France in 2021; it also identified credits, egress fees, ecosystems and migration frictions as competitive issues. A small operator does not defeat that by matching a catalog. It survives by selling into corners where catalog breadth is less important than local accountability and operational sufficiency.
Clouding SASU’s visible public trail points toward that kind of market, if it points toward a market at all. The records do not reveal a polished public cloud storefront, a visible customer list, a certification portfolio, a procurement footprint, or public product documentation. They do reveal a legal company, an IT-services object, historical service-like economics, a registered autonomous system, and an abuse contact. That combination is not enough to call Clouding a scaled cloud provider. It is enough to treat Clouding as a cloud/hosting-adjacent French micro-operator or services firm with infrastructure optionality.
What the public record actually fixes
The canonical legal entity is Clouding, a French SASU registered under SIREN 891 849 655, active, with its registered office at 2 Allée Lucien Coupaye, 91560 Crosne. The registry-derived Pappers record lists the activity as “Conseil en systèmes et logiciels informatiques,” shows creation on 4 December 2020, identifies Karim Bouabene as leader, and records zero employees in 2026. It also lists legal form SASU, capital of €1,000, VAT number FR14891849655, RCS Evry, and an APE/NAF activity code of 62.02A.
The company’s constitutive statutes are broad rather than cloud-specific. The object covers IT consulting and services in systems, software, programming and training; hardware resale; related activities; development, publishing and sale of software, websites, mobile sites and mobile applications; and acquisition, exploitation and sale of licenses. The same founding document shows capital of €1,000 divided into 1,000 shares, all subscribed by Karim Bouabene at formation.
Those facts create a legal identity, not a cloud-product proof. They show that Clouding can lawfully provide IT services, software, licensing and related activities. They do not show a live public cloud platform, data-center estate, customer base, service-level agreement, product catalog, or recurring hosting revenue. The distinction is important because “clouding” is a generic enough commercial name to create false positives. Some visible review and hosting signals for “Clouding” belong to unrelated businesses such as Clouding.io in Barcelona, not the French Clouding SASU. Trustpilot and HostAdvice pages for Clouding.io point to a Spanish hosting brand and should not be imported into Clouding SASU’s reputation record.
The company is not obviously dormant in the registry sense. Pappers shows an active status, continuing updates, and annual-account deposit notices for 2022, 2023 and 2024 accounts, although later accounts are confidential. It also shows no collective proceedings, no litigation, no sanctions, no public tenders won, no labels or certificates, and no intellectual-property rights in the visible record. That mix is commercially revealing: Clouding appears alive as a legal company, but not publicly demonstrative as a cloud vendor.
A services P&L, not a hyperscale P&L
The only disclosed financial year visible in the Pappers record is 2021. It shows €214,000 of revenue, €214,000 of gross margin, €84,700 of EBITDA, €66,300 of net income, 100% gross margin, 39.6% EBITDA margin, 31% net margin, €57,400 of cash, €67,300 of equity, zero salary expense as a share of revenue, and €94,900 of export revenue.
Those numbers are not consistent with a capital-intensive public-cloud buildout. They are consistent with a founder-operated services business, consulting business, resale/licensing wrapper, or project-based IT activity with low cost of goods sold. The 100% gross margin is especially important. A company running material rented infrastructure, wholesale compute, transit-heavy hosting, or hardware resale at scale would normally show some direct cost leakage, unless the accounting classification is unusual. The visible profile therefore points toward labor and knowledge as the economic engine, not owned compute capacity.
This is not a negative finding; it is the main economic interpretation. A small cloud-adjacent company with high-margin services can be rational. A small company trying to sell raw infrastructure against hyperscalers and large French providers would face brutal price pressure, uptime expectations, abuse burdens, capital requirements, and procurement skepticism. Clouding’s visible accounts suggest the former is more likely than the latter, at least at the point where public accounts were available.
The later confidentiality of accounts blocks revenue trend analysis. It could hide growth, stagnation, restructuring, or a deliberately quiet founder-led company. That opacity itself has commercial meaning. For relationship-led IT services, opacity may not matter much because trust is formed through direct referral, contract history, and personal accountability. For self-serve cloud, opacity is a conversion penalty because the buyer needs public confidence signals before placing workloads on an unknown platform.
The ASN is real, but an ASN is not a cloud
The strongest infrastructure fact is AS212718. Public RDAP/WHOIS context identifies the autonomous system as “clouding-asn,” located in France, with the registrant entity ORG-CS860-RIPE named Clouding SASU, address in Crosne, and an abuse role using contact@clouding.fr. RIPE’s own database documentation explains that the RIPE Database exists to hold registration information for networks in the RIPE NCC service region and related contact details, including coordination and routing-policy uses.
Commercially, that proves Clouding is not merely a name in a corporate registry. It has at least some network-operator identity in the RIPE ecosystem. An autonomous system number is useful if a company intends to originate prefixes, multi-home across upstreams, control routing policy, build hosting infrastructure, operate edge services, or signal technical seriousness to counterparties. It also creates obligations: abuse contacts are meant to receive reports about abusive behavior originating from a resource holder’s network, and hosting networks attract spam, scans, phishing, botnets and complaint traffic.
But the ASN does not prove a cloud. It does not prove active customer workloads, announced prefixes, transit contracts, data-center racks, owned hardware, SLA-backed infrastructure, a support desk, or meaningful traffic. Cloudflare Radar has pages for AS212718 and classifies it in routing/security views, which indicates the ASN is visible enough to be represented in external routing analytics, but the accessible page text does not provide traffic volume or a customer-base measure.
There is also a weak but notable IPv6 clue. A RIPE allocation mirror appears in search results with “fr.clouding,” “Clouding SASU,” date 20250512, and prefix 2a04:5fc0::/29. The underlying mirror describes itself as based on RIPE NCC allocation-file data and gives the format for IPv4 and IPv6 allocations, but the live extracted page did not surface the Clouding line in the accessible text. The right interpretation is not certainty. It is optionality: if the allocation signal is accurate, Clouding may have acquired significant IPv6 address space in 2025, which would support an infrastructure trajectory; if it is stale, indexed incorrectly, or not reflected in the current accessible page, it remains a due-diligence lead rather than proof.
The market implication is precise. Clouding’s network evidence supports “operator capability” more than “market scale.” It makes the company more interesting than a pure consulting shell, but less evidenced than a public cloud. The ASN is a real asset in the narrative; it is not a substitute for product evidence.
Locality is useful, but sovereignty is a higher bar
Locality sells when customers want a French counterparty, French-language support, local invoicing, local legal process, low-latency regional placement, and a provider that understands French business constraints. Sovereignty sells only when the provider can satisfy more demanding requirements around control, certification, jurisdiction, auditability, and operational independence. These are not the same market.
French public-sector cloud policy makes the difference clear. DINUM’s cloud doctrine says state IT teams and contractors should use cloud by default for new projects, but choices must consider security, total cost, internal expertise and technical need. It also says sensitive systems must use SecNumCloud or an equivalent qualification and be immune from unauthorized third-country public-authority access, while multicloud portability and supplier diversity should be considered. ANSSI describes SecNumCloud as a qualification framework for cloud providers, including IaaS, PaaS and SaaS, intended to strengthen confidence in the security of offerings and provider practices.
Pappers shows no labels or certificates for Clouding in the visible record. That does not prevent Clouding from serving ordinary commercial workloads, SMEs, test systems, managed hosting, non-sensitive SaaS backends, agencies, or private customers who value support over certification. It does limit the plausibility of Clouding winning sensitive public-sector or regulated workloads unless it is reselling, integrating or operating alongside a qualified provider.
This is where many local-cloud pitches fail. “French company” is not equivalent to “trusted cloud.” “Local support” is not equivalent to SecNumCloud. “European data center” is not equivalent to lawful immunity from extraterritorial access. A small operator can still make money below that threshold, but it should not pretend to own the sovereign-cloud premium unless it has the certifications, documented controls, legal architecture and audited operations to back it.
The market Clouding can plausibly make
The plausible market is not mass-market public cloud. It is a narrow services-led market with infrastructure features.
The customer is likely to be an organization with enough IT complexity to need external help but not enough internal cloud expertise to govern hyperscaler sprawl. That customer may have a legacy application, a small web platform, a few Linux or Windows servers, a database, backups, DNS, monitoring, VPN, firewall rules, mail routing, or a need to migrate from an old host. It may dislike hyperscaler billing uncertainty. It may not need Kubernetes, global regions, machine-learning platforms, managed data warehouses, or hyperscale marketplaces. It may want one accountable supplier.
For that buyer, locality, simplicity and support can beat raw platform superiority. A local operator can package a smaller set of sufficient services: virtual machines, storage, backup, managed firewall, monitoring, domain/DNS support, migration, patching, incident response, and a direct support channel. The operator does not need to be technically better than AWS. It needs to make the customer’s total operating cost lower after including attention, risk, time, governance, mistakes, and staff availability.
Clouding’s legal object fits this bundle. It explicitly covers IT consulting/services, training, software/site/app development, hardware resale and licensing. That breadth is economically more important than a narrow “cloud” label. A small provider often needs to blend recurring infrastructure with project labor. Pure hosting margin is thin; migration and support labor are the margin pool.
The failure path is also clear. If Clouding sells generic VPS capacity without a visible SLA, status page, security posture, references, pricing, automation, documentation, or certification, it competes in the worst part of the market: commodity compute with low trust. If it sells managed outcomes to customers that know the founder or partner network, public invisibility matters less. That makes Clouding look more like a relationship-led infrastructure services company than a self-serve cloud platform.
Support labor is both the margin pool and the bottleneck
Support is the only credible small-provider moat, but it does not scale cleanly. A local operator can differentiate by answering the phone, doing the migration, explaining backups, translating requirements into working infrastructure, helping after an incident, and owning the boring middle layer between application vendor, ISP, domain registrar, DNS, mail provider and cloud infrastructure.
The economics are attractive when support is packaged into recurring service fees. The customer compares the invoice not to a hyperscaler VM but to the cost of internal staff time, failed migrations, downtime, unmanaged backups, security gaps, and vendor coordination. In that comparison, a regional provider can charge a premium over raw compute.
The bottleneck is labor. Pappers lists zero employees in 2026. A zero-employee cloud-adjacent company can still operate through its founder, subcontractors, automation, resale relationships or part-time arrangements, but it faces key-person risk. The same person may be responsible for sales, architecture, billing, security, abuse, maintenance, documentation, customer support and incident response. That model can work for a small book of customers. It breaks when customers expect 24/7 incident handling, formal change management, compliance evidence, and fast support during simultaneous failures.
This is the core unit-economic constraint. Hyperscalers amortize platform engineering across millions of customers. Large French providers amortize compliance, NOC, datacenter operations, sales, support and legal across thousands. A micro-operator must recover fixed operational burdens from a small revenue base. The only way to do that is to avoid broad promises, specialize, automate, or charge for human responsibility.
Network resources are option value, not proof of scale
AS212718 gives Clouding an infrastructure option. It can use an ASN to multi-home, build its own routing policy, separate itself from an upstream provider’s identity, improve portability between facilities, operate anycast or edge-like services, and present itself as a more serious network counterparty. If the IPv6 allocation clue is real, it adds a forward-looking address-resource base, especially for new deployments where IPv6 is viable.
But network resources also create fixed costs and operational exposure. BGP is not a marketing ornament. If a provider originates routes, it must manage routing policy, RPKI, upstream relationships, filtering, incidents, abuse, DDoS handling, route leaks, blacklists, and monitoring. Even if the company does not yet route customer traffic, the existence of RDAP and abuse contacts means the company sits in an operator accountability chain.
The absence of visible PeeringDB-style interconnection evidence in the source trail matters. A mature infrastructure operator often leaves traces: peering-policy pages, exchange memberships, transit relationships, route objects, RPKI ROAs, NOC contacts, looking glasses, status pages, public uptime disclosures, or customer-visible network documentation. Clouding’s current public evidence is much thinner. That does not mean there is no private infrastructure. It means the commercial claim should be capped: network-capable, not network-proven at scale.
IPv4 is another constraint. A small provider entering cloud/hosting after the easy-allocation era faces scarce and expensive IPv4 resources. Without visible IPv4 holdings, the provider may depend on upstream-supplied or leased addresses, which weakens portability and margin. IPv6 can reduce future constraint but does not eliminate today’s customer reality: many applications, mail systems, third-party integrations and legacy clients still assume IPv4 reachability. If Clouding’s address-resource position is mostly IPv6, its infrastructure upside is real but commercially incomplete.
The supplier stack behind a small cloud
A regional cloud operator rarely owns the whole stack. It assembles it. The hidden stack may include colocation space, power, racks, servers, storage arrays, backup storage, virtualization software, network switches, upstream transit, DDoS mitigation, DNS, domain registration, monitoring, logging, billing, ticketing, payment processing, security tooling, and external contractors. Each dependency can become a margin leak or failure path.
For a small French provider, the strongest strategic choice is usually not to pretend otherwise. The rational model is to control the customer relationship, the architecture, the support process, and enough network identity to avoid total dependence on a single upstream, while buying scale where scale is required. That may mean reselling or integrating larger cloud, colocating a limited platform, or running a managed-hosting stack on leased infrastructure.
Clouding’s public record does not reveal its suppliers. That silence matters. If the company depends on one facility, one upstream, one virtualization stack, one founder, one billing system, or one DDoS provider, a localized failure can become a total-business failure. Larger providers spread these risks across regions, teams and balance sheets. A micro-operator must either disclose enough to reassure customers or sell to buyers who already trust the operator through private channels.
Supplier concentration also changes pricing. Hyperscalers set price floors on commodity services, but small operators often pay retail or near-retail for parts of the stack. They may not beat hyperscalers on raw unit cost. They can beat them only by changing the unit of value from compute to managed outcome. This is the same logic as an MSP: the input can be commodity, but the workflow and accountability are local.
Abuse handling is the tax on hosting
Hosting attracts abuse because compute, IP addresses and bandwidth are useful to bad actors. Even a small provider can inherit disproportionate pain: spam complaints, phishing takedown notices, malware scanning, credential stuffing, open proxies, compromised WordPress instances, botnet command traffic, copyright notices, and DDoS retaliation. Abuse handling is not optional overhead. It is part of the operating cost of being a networked infrastructure provider.
The RDAP abuse contact for Clouding is therefore more than an administrative detail. It places the company in the complaint loop. For a micro-provider, abuse can destroy the economics of cheap hosting. One bad customer can blacklist IP space, trigger upstream intervention, consume support time, and damage deliverability for legitimate customers. IPv4 scarcity worsens this: dirty or blacklisted address space is harder to replace, and reputation repair is slow.
This creates a strategic filter. A small operator should avoid anonymous, low-friction, low-price public compute unless it has strong automated anti-abuse controls. The better customer base is known, contract-based, local, managed, and lower-risk. That again points to a services-led market rather than open self-serve cloud. If Clouding wants a durable niche, it should prefer customers where identity, use case and support relationship are known before provisioning.
Switching costs are changing, but managed-work lock-in remains
The EU Data Act changes the cloud-switching environment. The European Commission describes cloud customers as facing barriers such as high egress charges, lengthy switching procedures and lack of interoperability; the Act requires cloud and edge providers to facilitate switching, increase contractual transparency, remove obstacles, and phase out switching charges including data egress charges by 12 January 2027.
This matters in two opposite ways. First, it weakens one hyperscaler lock-in mechanism at the margin. If egress charges become less punitive, some customers may be more willing to leave large platforms or adopt secondary providers. Second, it reduces one selling point for regional providers that rely on “no lock-in” messaging. If the law forces more openness across the sector, small providers must compete on service quality, support, security, simplicity and local fit, not merely on reversibility claims.
The more durable lock-in is not contractual; it is operational. Once a provider understands the customer’s application, backup pattern, DNS setup, deployment quirks, user permissions, compliance anxieties, and incident history, switching away becomes costly even if data egress is cheap. That can be good or bad. It is good when the provider creates real operational knowledge and documents it. It is bad when the provider becomes an undocumented bottleneck.
A small operator’s defensible economics should therefore come from managed-work lock-in, not technical hostage-taking. The customer should stay because the provider reduces failure probability and operating burden. If the customer stays because no one else understands the setup, the provider has created fragility, not value.
Competition is not one market; it is four different threats
Clouding’s likely competitive environment has four layers.
The first layer is hyperscalers. AWS, Azure and Google Cloud dominate the technical frontier and developer mindshare. They win on breadth, ecosystem, credits, managed services, global regions, marketplace depth, automation, compliance documentation and enterprise procurement. They also create cost governance and complexity problems. For Clouding, hyperscalers are not beaten head-on. They are bypassed when the customer wants a simpler accountable counterparty.
The second layer is large French and European cloud providers. OVHcloud markets a broad public-cloud portfolio, infrastructure services and reversibility; Scaleway offers a wide cloud range; 3DS OUTSCALE has positioned itself around trusted cloud and SecNumCloud qualification; Cloud Temple has SecNumCloud-qualified offerings; Clever Cloud sells European cloud positioning and legal-sovereignty themes. These companies are the real substitute when a French customer wants locality plus more public evidence than a micro-provider can offer.
The third layer is MSPs, web agencies, local IT integrators and hosting resellers. This is probably the most relevant competitive layer for Clouding. These firms do not need to own infrastructure to win the customer. They win by being trusted, available and willing to manage the mess. If Clouding’s advantage is technical network competence, it must convert that into support outcomes customers can feel.
The fourth layer is telecom and data-center incumbents. They sell connectivity, colocation, managed hosting, private cloud, security and hybrid infrastructure. Against them, a micro-operator can be more flexible and cheaper but less certifiable and less redundant.
The implication is that Clouding’s best category is not “national telecom,” not “exchange,” and not “hyperscale cloud.” It is cloud/hosting-adjacent infrastructure services, potentially a micro cloud or managed-hosting operator with RIPE/ASN evidence. For directory or publication classification, “cloud service” is defensible only with a qualification: the public evidence supports cloud/hosting adjacency and operator identity, not a fully evidenced self-serve public cloud platform.
The name collision problem is commercial, not cosmetic
Search-market ambiguity is a real due-diligence cost. “Clouding” is used by other companies. Clouding.io, for example, appears in review and hosting contexts as a Barcelona-based provider, and those reviews cannot be credited to Clouding SASU. Another unrelated “CLOUDING SAS”/clouding.lt presence points to a Colombia-linked company serving broader markets, again not the French SASU.
This matters because small cloud providers rely heavily on trust signals. If a buyer searches the name and finds unrelated reviews, unrelated hosting brands, and sparse official evidence for the French entity, the buyer’s verification burden increases. That burden can be acceptable in referral-led sales. It is damaging in self-serve acquisition.
The name collision also raises reputation risk. A complaint, outage or abuse thread about an unrelated “Clouding” could be misattributed. Conversely, positive reviews about unrelated providers could create false confidence. The correct analyst posture is conservative: do not import third-party Clouding.io reputation to Clouding SASU; treat the lack of Clouding SASU-specific chatter as an absence of visible market signal, not as proof of customer satisfaction.
Silence is not innocence; it is low observability
There is no strong public complaint trail in the gathered source set: no visible outage chatter tied cleanly to Clouding SASU, no review pattern, no public procurement record, no official website listed in Pappers, no certificates or labels in the visible company record, and no cited companies available on Pappers.
This should not be read as “good reputation.” It should be read as low observability. A company with few public customers, private contracts, low traffic, or project-based work will naturally leave fewer public traces. Low observability reduces downside evidence, but it also reduces confidence. In cloud, the buyer cares about continuity, incident response, support depth, security controls and exit options. A quiet profile forces the buyer either to conduct private diligence or to rely on personal trust.
That is the central economic tension. Thin public evidence is workable for consulting. It is a problem for infrastructure. Consulting can be sold through personal credibility. Infrastructure requires institutional credibility because the customer is placing operational continuity on the provider. Clouding sits between those worlds: the registry and ASN evidence suggests infrastructure ambition or capability, while the public commercial surface looks more like a small services company.
Ownership and control: useful concentration, dangerous concentration
Clouding’s founding structure was simple: SASU, €1,000 capital, Karim Bouabene as sole shareholder at formation. Pappers’ leader page continues to associate Karim Bouabene with Clouding as president and shows no broad network of linked companies. A public LinkedIn snippet also associates a Karim Bouabene profile with network/connectivity leadership and “Founder” at clouding, though this is a softer professional-network signal, not a registry fact.
Founder concentration is economically double-edged. It can be an advantage in small infrastructure services because decision-making is fast, technical context is concentrated, and customers may get direct access to the person who understands the system. It is also a continuity risk. If one person carries the architecture, support knowledge, supplier relationships and customer history, the company’s service capacity is bounded by that person’s availability.
For small regional cloud, the question is not only “who owns it?” but “who can operate it during failure?” A support-led cloud must answer during bad hours, not only sell during good hours. The public evidence does not show staff depth. That does not make the company non-viable, but it narrows the viable market to customers whose expectations match the operating model.
The real unit economics
A small French operator’s cost structure is shaped by five constraints.
First, compute has poor differentiation. If the customer wants cheapest VM, broadest service catalog, managed database, managed Kubernetes, AI platform, global CDN, compliance paperwork and instant provisioning, large providers win. Local cloud must package compute with labor and accountability.
Second, support labor does not scale like software. Every migration, outage, backup restore, security incident, billing dispute and abuse notice consumes time. The provider must charge enough recurring margin to cover this. Cheap unmanaged hosting is a trap unless automation is strong and customer quality is tightly controlled.
Third, supplier dependency is unavoidable. Without owned data centers and large capital reserves, a micro-operator depends on upstream providers. That is rational, but it means margin and resilience depend on supplier terms. One facility issue, one upstream route problem, one DDoS gap, or one virtualization licensing change can alter the economics.
Fourth, trust is a cost of capital. Lack of public references, certifications, status history and product documentation increases buyer diligence costs. A small provider can compensate with direct relationships, but that keeps the addressable market small.
Fifth, regulation creates both demand and barriers. European cloud rules, Data Act switching reforms and French sovereignty debates create demand for alternatives to hyperscaler lock-in, but sensitive workloads require evidence and qualifications. The same rules that create the market also raise the bar.
Clouding’s visible record suggests it should optimize for measurable sufficiency, not prestige. It does not need to become a “sovereign cloud” brand to be economically useful. It needs a narrow offer where the customer can verify: where the data is hosted, who supports it, how backups work, what happens during incident, how to exit, what the SLA means, how abuse is handled, and which suppliers sit underneath.
What may be residual signal rather than operating proof
Some Clouding signals may be operating evidence. Others may be residual.
The legal company is active, but legal activity does not prove active cloud services. The statutes permit IT services, but corporate objects are intentionally broad. The 2021 revenue proves commercial activity in that year, but not the current revenue mix. Confidential later accounts prove filings, not growth. The ASN proves RIPE network identity, but not traffic. The abuse contact proves operator accountability, not customer volume. The possible IPv6 allocation proves at most a network-resource lead unless confirmed directly in RIPE objects and routing tables. The absence of public complaints proves low visible complaint surface, not reliability.
This evidence boundary should be part of any commercial reading. If Clouding is being evaluated as a supplier, the next step is not to ask whether it is “real.” It is real as a legal and network-record entity. The next step is to ask what part of the infrastructure stack it operates, what it resells, where customer workloads run, what support coverage exists, what happens on exit, and whether there is enough institutional continuity for the buyer’s risk level.
Category recommendation
Clouding SASU is best categorized as a French cloud/hosting-adjacent IT services and infrastructure micro-operator with RIPE/ASN evidence. It should not be described as a national telecom, exchange, or clearly scaled public cloud provider. The strongest supported category is “cloud service / hosting-adjacent regional infrastructure services,” with an evidence caveat: public records currently support legal continuity, IT-services scope, historical service economics, and network-resource identity; they do not yet support a claim of visible public-cloud scale, certified sovereign-cloud status, material customer footprint, or independent data-center operation.
The practical classification should therefore be conservative: include it in cloud/hosting infrastructure coverage only if the write-up explicitly states the evidence boundary. If future routing, product, certification, customer or procurement signals emerge, the category can move toward regional cloud operator. If no such signals emerge, the safer economic category is IT consulting/services company with network-number resources.
Evidence ledger
Pappers — Clouding company record URL: https://www.pappers.fr/entreprise/clouding-891849655 Source type: French company-registry aggregator using official registry data. Supports: Active French SASU identity, SIREN 891 849 655, Crosne address, activity code 62.02A, legal form, capital, leader, zero employees, 2021 accounts, account-deposit continuity, no visible public tenders, no visible labels/certificates, no visible IP rights. Does not prove: Live cloud product, current customer base, current revenue mix, owned infrastructure, data-center footprint, SLA quality, or operational maturity. Economic importance: Establishes Clouding as a real legal entity while showing a small, service-like visible scale rather than a capital-intensive public-cloud profile.
Pappers — Clouding constitutive statutes PDF URL: https://www.pappers.fr/entreprise/clouding-891849655/documents/CLOUDING%20-%20Statuts%20constitutifs%2009-12-2020.pdf Source type: Company formation/legal document. Supports: Broad IT-services object, hardware resale, software/site/app development, licensing activity, €1,000 capital, Karim Bouabene as sole shareholder at formation. Does not prove: Current ownership if later changed, actual product mix, customer contracts, or cloud operations. Economic importance: Shows the company was formed as a broad IT-services vehicle, not narrowly as a capitalized infrastructure platform.
Pappers — Karim Bouabene officer page URL: https://www.pappers.fr/dirigeant/karim_bouabene_1979-12 Source type: Registry-derived officer/person page. Supports: Karim Bouabene’s continuing association as president of Clouding and lack of a broad visible company network. Does not prove: Day-to-day involvement, current beneficial ownership, staff depth, or operational capacity. Economic importance: Points to founder concentration, which can help technical accountability but creates key-person and continuity risk.
RIPE/RDAP mirror — AS212718 clouding-asn URL: https://zh-hant.ipshu.com/asn/212718 Source type: RDAP/WHOIS/RIR data mirror. Supports: AS212718, “clouding-asn,” France location, ORG-CS860-RIPE Clouding SASU, Crosne address, maintainer/registrant records, abuse contact at contact@clouding.fr. Does not prove: Active route origination, traffic volume, customer workloads, peering, transit relationships, data centers, or revenue. Economic importance: Confirms network-operator identity and infrastructure optionality, but not market scale.
RIPE NCC — RIPE Database description URL: https://www.ripe.net/manage-ips-and-asns/db/ Source type: Official RIR documentation. Supports: The interpretive meaning of RIPE database records as registration, contact and routing-coordination data. Does not prove: Anything specific about Clouding’s commercial operations. Economic importance: Prevents overreading RDAP: registry identity is meaningful, but it is not equivalent to operating cloud capacity.
RIPE NCC — abuse-c policy context URL: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-acceptable-use-policy/ Source type: Official RIR policy/documentation. Supports: Abuse contacts are intended for reports of abusive behavior originating in a resource holder’s network. Does not prove: Clouding has abuse incidents or a specific abuse volume. Economic importance: Shows that network-resource ownership brings operating obligations; abuse handling is a fixed-cost burden for small hosting/cloud operators.
Cloudflare Radar — AS212718 RPKI/routing page URL: https://radar.cloudflare.com/pl-pl/routing/rpki/as212718 Source type: External routing-analytics interface. Supports: AS212718 appears in public routing-monitoring context as “clouding-asn.” Does not prove: Significant traffic, active customer workload, prefix count, route stability, or commercial adoption from the accessible text. Economic importance: Useful as a monitoring lead for whether Clouding’s ASN becomes operationally visible.
Telecom SudParis RIPE allocation mirror/search trace URL: https://www-public.telecom-sudparis.eu/~maigron/rir-stats/ripe-allocations/allocations/fr-ip-allocations.html Source type: Public RIPE allocation mirror/search-index clue. Supports: A weak indexed signal associating “fr.clouding,” Clouding SASU, 20250512 and IPv6 prefix 2a04:5fc0::/29; the mirror itself describes RIPE allocation-file structure. Does not prove: Current allocation, active routing, customer use, or that the line is presently visible in the accessible page extract. Economic importance: If confirmed, it would materially strengthen the infrastructure-optionality thesis; until confirmed, it is a watchpoint, not a firm fact.
Autorité de la concurrence — French cloud-sector opinion URL: https://www.autoritedelaconcurrence.fr/fr/communiques-de-presse/informatique-en-nuage-cloud-lautorite-de-la-concurrence-rend-son-avis-sur-le Source type: French competition authority market analysis. Supports: Hyperscaler dominance in French IaaS/PaaS, concerns around credits, egress fees, ecosystem power and migration barriers. Does not prove: Clouding’s market share, customer base, or conduct. Economic importance: Defines the competitive structure Clouding must work around: raw cloud infrastructure is not an easy differentiated market.
European Commission — Data Act explained URL: https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained Source type: Official EU regulatory explanation. Supports: Switching barriers, egress-charge phaseout, interoperability and contractual-transparency direction for cloud/edge services. Does not prove: Switching will become operationally easy or that small providers automatically benefit. Economic importance: Cloud lock-in economics are changing; small providers must win on service and operational fit, not only on anti-lock-in rhetoric.
DINUM — French public-sector cloud doctrine URL: https://www.numerique.gouv.fr/offre-accompagnement/cloud-administrations/programme/ Source type: Official French government cloud-policy guidance. Supports: Cloud-by-default policy, security and cost criteria, SecNumCloud/equivalent requirement for sensitive systems, portability and supplier-diversity considerations. Does not prove: Clouding is eligible or ineligible for every public contract. Economic importance: Shows why certification and public evidence matter for regulated buyers; locality alone is insufficient.
ANSSI — Recommendations on hosting sensitive information systems in the cloud URL: https://messervices.cyber.gouv.fr/documents-guides/anssi_Recommendations%20on%20hosting%20sensitive%20IS%20in%20the%20cloud.pdf Source type: Official cybersecurity guidance. Supports: Meaning and role of SecNumCloud qualification for cloud providers and trust in operational practices. Does not prove: Clouding has, lacks, sought, or failed any qualification beyond absence of visible certification in company records. Economic importance: Defines the trust premium and compliance barrier that separates ordinary local hosting from sensitive sovereign-cloud workloads.
OVHcloud, Scaleway, OUTSCALE, Cloud Temple and Clever Cloud public materials URLs: https://www.ovhcloud.com/en/public-cloud/ ; https://www.scaleway.com/en/ ; https://en.outscale.com/press-releases/archives/3ds-outscale-french-leader-guaranteeing-fully-trusted-cloud-around-the-world/ ; https://www.cloud-temple.com/en/press-releases/cloud-temple-first-in-france-to-obtain-secnumcloud-qualification-for-a-paas-offering/ ; https://www.clever.cloud/secnumcloud-trusted-cloud/ Source type: Competitor official pages and announcements. Supports: Existence of better-evidenced French/European cloud alternatives with broader product surfaces, sovereignty positioning or certifications. Does not prove: Direct customer overlap with Clouding or that Clouding cannot win niche customers. Economic importance: Sets the competitive ceiling: Clouding’s plausible wedge is support-led specificity, not broad cloud-platform parity.
Trustpilot/HostAdvice Clouding.io and unrelated Clouding web traces URLs: https://fr.trustpilot.com/review/clouding.io ; https://hostadvice.com/hosting-company/clouding-io-reviews/ ; https://www.clouding.lt/about-us/ Source type: Review-site and unrelated company web signals. Supports: Name collision around “Clouding,” especially with a Spanish Clouding.io hosting brand and other unrelated Clouding entities. Does not prove: Reputation, quality, outages, customer satisfaction or complaints for Clouding SASU. Economic importance: Shows due-diligence noise and SEO/reputation ambiguity; positive or negative signals from unrelated “Clouding” brands must not be misattributed.
Watchpoints
Monitor AS212718 for newly visible BGP announcements, route6 objects, RPKI ROAs, upstream changes, invalid routes, route leaks, traffic visibility and peering traces.
Confirm or falsify the 2a04:5fc0::/29 IPv6 allocation lead through RIPEstat, RIPE Database objects, RPKI, route collectors and delegated allocation files.
Watch clouding.fr for a product surface: pricing, SLA, DPA, status page, API documentation, customer portal, legal terms, support policy, incident history and named infrastructure locations.
Track PeeringDB, France-IX, Equinix, Telehouse, transit-provider references and datacenter partner pages for any AS212718 or Clouding SASU appearance.
Track Pappers/BODACC for capital increases, new shareholders, management changes, account publication, mergers, asset transfers, pledges, insolvency signals or address changes.
Watch procurement databases, UGAP references, local-authority tenders, healthcare-hosting references and subcontractor disclosures for Clouding SASU or clouding.fr.
Track certification surfaces: SecNumCloud, ISO 27001, HDS, SOC 2, ANSSI qualification-in-progress lists, or partner claims involving a qualified infrastructure provider.
Watch job postings for SRE, NOC, support, abuse, security, systems engineering or sales roles; headcount is the clearest signal that Clouding is moving beyond founder-led services.
Track customer traces: hosted domains, MX/NS patterns, reseller mentions, GitHub deployment examples, status-page dependencies, testimonials, MSP bundles and invoice references.
Monitor abuse and reputation signals: Spamhaus, phishing takedowns, spam complaints, blacklist history, UCEProtect-style listings, public abuse threads and upstream suspension notices.
Treat any Clouding.io, Clouding.lt or other “Clouding” review/outage signal as non-attributable until the entity, domain, ASN or legal name ties cleanly to Clouding SASU.