Four startups, four products and very different use cases: telemedicine, AI agents, interactive learning and hotel performance management. Yet behind that diversity lies the same challenge: turning a technology product into a service that people genuinely use.

Once the first users arrive, it is no longer enough for a product simply to work. It needs to be deployed, operated and secured reliably, while being able to support new use cases without its cloud infrastructure becoming a barrier to growth.

This is precisely the stage at which the UP Programme supports selected startups.

The four startups joining the sixth UP Programme cohort

Kernel: simplifying access to online care pathways

Kernel is a telemedicine platform providing access to personalised online care pathways, particularly for dermatology and hair loss.

The process starts with a structured medical questionnaire. A doctor registered with the French Ordre des médecins then reviews the case, establishes a diagnosis and, where necessary, issues an appropriate prescription. The treatment can then be prepared by an authorised pharmacy and delivered to the patient.

Kernel also provides a follow-up area that allows patients to stay in contact with their doctor. In a context where the data involved is particularly sensitive, the platform states that medical data is encrypted and hosted in France on HDS-certified servers.

With Kernel, technology supports an end-to-end care pathway, from the initial consultation through to patient follow-up.

Nijal AI: deploying AI agents without giving up autonomy

Nijal AI develops artificial intelligence agents for businesses, institutions and local authorities.

Its approach is built around three principles: providing solutions that are ready to deploy, allowing them to run either in the cloud or on-premises, and avoiding technological dependencies that can become difficult to control.

Nijal AI also places a strong emphasis on transferring skills to the teams using its solutions. The objective is not simply to design an AI agent, but to enable organisations to integrate it into their processes, maintain it themselves and retain control over how it evolves.

This approach reflects an increasingly practical challenge in AI: moving beyond experimentation towards services that can genuinely be operated, maintained and integrated into an organisation’s information systems.

Qiplim: turning content into interactive learning experiences

Qiplim develops a platform combining interactive live sessions with artificial intelligence.

From a document, presentation, web page or video, the platform can generate interactive activities that can then be used during a live session. Participants join via a QR code without having to create an account.

Qiplim is also developing an AI Studio designed to extend the experience beyond the live session, allowing participants to interact with the source material made available to them and transform it into different learning formats.

Data sovereignty is an integral part of its positioning: Qiplim processes its data in France on Clever Cloud, while the artificial intelligence models it uses are served from within the European Union by Mistral AI.

The platform already reports more than 210 beta testers and positions itself as a sovereign alternative to tools such as Kahoot and NotebookLM.

Arkan: from developing AI solutions to building its own products

Arkan supports businesses in designing, developing and deploying solutions based on artificial intelligence.

Alongside bespoke AI projects for companies across different sectors, Arkan is also developing its own products.

Among them, its Hotel Performance Platform centralises data from the tools already used by hospitality businesses, including property management systems (PMS), channel managers and extranets. This data is brought together in a dashboard designed to make it easier to monitor metrics such as occupancy, average room rate, RevPAR and booking trends. An AI assistant also allows users to query the data using natural language.

The platform is already used by two hotel groups representing thirteen properties.

At the same time, Arkan is developing Covera, a solution designed to automate the verification of suppliers’ insurance certificates using artificial intelligence.

Combining bespoke AI development with the development and operation of its own products also illustrates the scaling challenges technology companies can face as they grow.

When a product meets its users, infrastructure becomes part of the product

Kernel, Nijal AI, Qiplim and Arkan address very different needs and are not necessarily at the same stage of development. Their journeys nevertheless illustrate different aspects of the same transition: turning technology into a service that people genuinely use.

As a product finds its users, new constraints emerge. Applications need to remain available, deployments need to be reproducible, data needs to be protected, resources need to scale with usage and teams need to be able to keep shipping quickly.

Infrastructure gradually stops being just a technical concern in the background. It directly contributes to a company’s ability to develop and grow its product.

The challenge is not to spend ever more time operating that infrastructure, but precisely to ensure that it can support growth without distracting teams from their core business.

The UP Programme: turning cloud infrastructure into a growth enabler

This is the stage that Clever Cloud’s UP Programme is designed to support.

Launched in 2024, the programme was created to support technology startups beyond simply providing cloud credits. Its purpose is to give them access to the technical, human and financial resources they need to build their products on cloud infrastructure that can evolve with them.

Selected startups can benefit from:

• up to €10,000 in cloud credits during their first year;
• onboarding onto the Clever Cloud platform and training with our engineers;
• monthly coaching;
• access to Clever Cloud support;
• workshops and masterclasses for technical teams;
• mentoring for founders and their teams;
• visibility through Clever Cloud media, social channels and events;
• tools and resources to support the structuring of their business.

The objective remains the same: enabling teams to focus their energy on their product, users and market rather than on the day-to-day operation of their infrastructure.

Kernel, Nijal AI, Qiplim and Arkan are therefore joining a programme designed to support this pivotal stage: when usage grows, technical requirements evolve and infrastructure needs to keep pace with the product over the long term.

Want to join the next UP Programme cohort?

The next UP Programme selection will take place on 7 January 2027.

Are you building a technology startup and looking for cloud infrastructure that can scale with your product, while benefiting from regular support from Clever Cloud teams?

Discover the UP Programme and apply to join the next cohort.

What Is a French Managed Kubernetes Service?

A French Kubernetes service is a managed Kubernetes service provided by a French company. Depending on the offering, the infrastructure may be located in France or elsewhere in Europe and may run on a public cloud, a private cloud or dedicated machines.

Why Choose a French Kubernetes Provider?

Greater Digital Sovereignty

Entrusting orchestration to AWS, Google Cloud or Azure exposes organisations to a proprietary ecosystem and a non-European legal framework. Choosing a domestic provider reduces this dependency and supports a broader digital sovereignty strategy that goes beyond technical portability alone.

Clear Infrastructure Location and Responsibility

Knowing exactly where the control plane and worker nodes are running—and who is responsible for operating them—has become a key selection criterion for regulated industries and public-sector buyers alike.

Easier European Compliance

Infrastructure operated in Europe can simplify certain compliance processes relating to data location and transfers outside the European Union.

Local Support and Contract Management

Having a provider in the same time zone, billing in euros and documentation available in French can shorten resolution times and streamline contractual relationships.

French Managed Kubernetes Providers

The descriptions below reflect the offerings available at the time of writing. These services evolve rapidly, so always check the provider’s official website before making a decision.

OVHcloud Managed Kubernetes Service (MKS)

OVHcloud offers MKS, its managed Kubernetes service for the public cloud, in two tiers. MKS Free provides a free managed control plane. MKS Standard, launched in September 2025, adds a 99.99% SLA, with a control plane distributed across a three-availability-zone region (initially Paris, followed by Milan) dedicated etcd storage of up to 8 GB, and a choice of CNI plugins, including Cilium. The service integrates with the OVHcloud Public Cloud ecosystem.

Scaleway Kubernetes Kapsule

Kapsule is a CNCF-certified managed Kubernetes service for the public cloud. Its shared control plane is free, with a dedicated control plane available as an option for mission-critical workloads, while autoscaling is supported natively. The service integrates with Scaleway’s services and emphasises digital sovereignty and GDPR compliance for the European market.

Clever Kubernetes Engine (CKE)

CKE is Clever Cloud’s managed Kubernetes service. It runs on infrastructure located in France, with no dependency on a foreign hyperscaler. Each cluster runs on its own virtual machines, with no infrastructure shared between customers. The control-plane architecture can be configured according to the selected topology, ranging from an all-in-one bundle to one VM per component. The experience remains true to standard Kubernetes, with no lock-in mechanisms or need to rewrite manifests. Cluster state is stored in Materia etcd, an implementation of the etcd protocol developed in France and built on FoundationDB. CKE integrates with managed databases, S3-compatible object storage, IAM, observability services and private networking through Network Groups. The product is currently in public beta.

Comparing French Managed Kubernetes Services

French Kubernetes offerings are based on different architectures and operating models. The most useful comparison criteria are infrastructure location, hosting model, availability guarantees, level of integration with cloud services and compatibility with the standard Kubernetes ecosystem.

None of these offerings is inherently superior to the others. The right choice depends on the required operating model and the level of assurance expected.

French Kubernetes vs AWS EKS, Google GKE and Azure AKS

AWS EKS, Google GKE and Azure AKS remain the most comprehensive managed Kubernetes services in terms of their wider service portfolios and global reach. In return, they increase dependency on their respective ecosystems. A French offering addresses the same orchestration requirements while keeping the control plane and data subject to European law.

French providers host their infrastructure in France or elsewhere in Europe, under European law and with locally operated integrations. Hyperscalers offer a broader service portfolio and global reach, at the cost of greater dependency on their ecosystems.

The general criteria for selecting a managed cluster (irrespective of the national dimension) also warrant careful consideration. These include version policies, autoscaling, storage and the responsibility model.

Key takeaways

The best French Kubernetes service ultimately depends on your specific context. Some organisations will prioritise a generally available offering backed by strong contractual guarantees, while others will seek close integration with their cloud platform or existing environment. OVHcloud, Scaleway and Clever Cloud currently offer different approaches to managed Kubernetes. The choice primarily depends on operational, governance and compliance requirements, as well as the expected level of maturity.

FAQ

Are There Any French Managed Kubernetes Providers?

Yes. Several French companies offer managed Kubernetes services, including OVHcloud with Managed Kubernetes Service, Scaleway with Kubernetes Kapsule and Clever Cloud with Clever Kubernetes Engine. These solutions differ in their infrastructure models, level of managed service and integration with each provider’s cloud ecosystem.

What Is the Difference Between French and European Kubernetes?

A French Kubernetes service is provided by a French company, while a European Kubernetes service is provided by a company established in the European Union. In both cases, it is important to examine the infrastructure’s actual location, the entity that operates the service and the law applicable to the data.

Does a French Provider Guarantee Digital Sovereignty?

No. A provider’s nationality alone is not enough to guarantee sovereignty. Sovereignty also depends on the infrastructure operator, any subcontractors involved in the hosting chain and the legal frameworks to which they are subject.

Can You Use Helm and Terraform with a French Kubernetes Service?

Yes, provided that the service uses a standard Kubernetes implementation. The services offered by OVHcloud, Scaleway and Clever Cloud remain compatible with widely used ecosystem tools such as kubectl, Helm and Terraform, as well as GitOps practices.

How Do French Kubernetes Services Compare with AWS EKS?

AWS EKS benefits from an extensive portfolio of cloud services and a global presence. French offerings generally emphasise operations carried out in Europe, local support and integration with locally operated infrastructure. The right choice depends on each project’s technical, regulatory and organisational constraints.

What Is the Difference Between Managed and Self-Hosted Kubernetes?

The main difference lies in operational responsibility. With managed Kubernetes, the provider operates the control plane and handles part of the platform’s maintenance. With self-hosted Kubernetes, the organisation remains responsible for installing, updating, monitoring and securing the cluster, as well as ensuring its availability. Managed Kubernetes reduces the operational burden, while self-hosting provides greater control over the infrastructure.

Can You Migrate from One Kubernetes Provider to Another?

Yes, provided that a standard Kubernetes implementation is used. YAML manifests, Helm charts and deployment tools generally remain portable from one provider to another. However, certain provider-specific dependencies, such as storage, networking and managed services, may require adaptations.

Which French Kubernetes Service Is Best for an SME?

The right choice depends on the project’s requirements. An SME may prefer an offering with a free control plane for its initial deployments or seek closer integration with a particular cloud ecosystem. In all cases, compatibility with standard Kubernetes makes it easier to move to another offering if requirements change.

The episode, titled “We no longer pay developers to write code”, is available on the Underscore_ YouTube channel.

From AI experimentation to industrialization

About 18 months ago, Quentin started seriously experimenting with AI agents for software development. Initially skeptical, he gradually found that they could deliver certain developments faster, sometimes with a better implementation than the one he would have written himself.

But one of the main lessons from Clever Cloud’s experience is precisely that simply giving developers access to an AI tool is not enough. Adoption required changing practices, supporting teams, and even giving up on the idea of imposing a single tool: in a market evolving extremely quickly, developers experiment with different solutions and share what they learn.

When AI also transforms software quality

The focus then shifts from simply generating code to everything required to verify, test, and secure it. Unit and integration tests, distributed systems simulation, automated security audits: AI makes it possible to apply much more systematically practices that already existed but whose time cost sometimes limited their use.

At Clever Cloud, every commit in GitLab can be sent through simulation to look for failures, generate a report, and open an issue when a problem is detected. The question is therefore no longer simply, “How much code can AI produce?” but rather, “What organization and engineering pipeline do we need to build to use this capability in production?”

That is precisely what separates one-off experimentation from industrialization.

Rust, legacy, and new software development practices

The episode also explores Rust’s role in this transformation. Quentin explains why the language’s constraints and the precise feedback provided by its compiler create a particularly effective feedback loop with AI agents.

This approach is now part of a much broader project at Clever Cloud: reducing and ultimately eliminating the legacy accumulated since the company was founded more than 15 years ago, progressively rewriting components while preserving architectural decisions and strengthening their validation.

At the time of recording, Quentin still described eliminating legacy as a work in progress. Since then, this Rust rewrite is now nearly complete.

For a tech company of more than 100 people operating critical infrastructure, this goes far beyond a POC: it means fundamentally changing how software is designed, built, tested, and maintained.

What role is left for developers and CIOs?

This transformation ultimately raises a broader question: what happens to the developer’s role when producing code becomes significantly cheaper?

Quentin argues that value is shifting towards specifications, architecture, testing, and the environment in which software is produced. As a developer himself, he explains that it took him several months to come to terms with this shift.

For CIOs, this experience therefore raises the question of how to integrate AI without simply adding another tool to the stack, by rethinking the processes required to capture its benefits without sacrificing quality or security. This is precisely where Quentin believes companies focusing solely on code generation risk missing a large part of the potential gains.

Ultimately, this may be the main takeaway: the most structural gains emerge when AI leads us to fundamentally rethink how software is designed, built, and evolved. For European companies, the challenge is therefore no longer simply to adopt these tools, but to turn them into a genuine industrial capability.

To watch the full conversation between Quentin Adam, Micode, and Matthieu Lambda:

Clever Cloud is pleased to welcome you to La Cantine x La French Tech Nantes for a full day, as part of Nantes Digital Week and the Je choisis la French Tech program. The main hall hosts a showroom of local solutions, along with part of the talks, complemented by two conference rooms.

In practice, the goal is to show IT decision-makers that local solutions already exist and run in production today. It's also about showing that they can meet many technology needs today, without relying on the big American platforms. The local ecosystem produces them, but these solutions are often not well known enough to the organizations that could use them. Putting them in the spotlight is exactly what matters to us with Tech Alternatives Nantes.

The Tech Alternatives Nantes program

The day opens with a keynote, then continues with panel discussions, talks and case studies, with no sales pitches. Speakers come to talk about what they've built, not to sell it. For example, attendees will hear how electronic waste becomes a local resource, how AI is being industrialized in Europe, or how to respond to a cyberattack. The day wraps up with a closing address, followed by a networking session.

Also, here are the fourteen local organizations co-organizing the event: ADN Ouest, AlphaEdge, Clever Cloud, CRISP, ETIX, Free Pro, French Tech Nantes x La Cantine, ici_lundi, iTrust, Make IT Safe, Modixia, Octopize, Swiftask and Tranquil IT. Clever Cloud and La Cantine x La French Tech Nantes handle the overall coordination.

Practical information about Tech Alternatives Nantes

📆 Friday, September 18, 2026, 9:30 AM to 4:30 PM
📍 La Cantine x La French Tech Nantes Halle 6, Est, 40 rue La Tour d'Auvergne, Nantes

Free access, ticket required, limited seats available.

Looking forward to seeing you in Nantes!

We're back, and our upcoming events 2026 are already lined up. Over the next three months, we're heading out to meet you, with talks, booths and plenty of opportunities to connect. Here's where to find us and why you should stop by.

September

Jug Summer Camp 2026

📆 4 September 2026
📍La Rochelle

We kick off the season at Jug Summer Camp 2026, the Java conference that keeps the relaxed end-of-summer spirit alive, all packed into a single day. Our DevRel, Horacio Gonzalez, will be on stage with a talk entitled "Wrap, Reshape, or Redesign: Retrofitting Your APIs for a World of Agents", exploring how to adapt existing APIs for a world of AI agents. Between sessions, come and visit our booth, our team will be there to chat.

Universités d'Été (UECC)

📆 10 September 2026
📍Paris

On 10 September, we'll be at the Universités d'Été de la Cyber et du Cloud de confiance (UECC). The event, organised by HexaTrust, brings together key players in cybersecurity and sovereign cloud, a field we know well. You'll find our team at the booth, ready to discuss sovereignty.

API Platform Conference 2026

📆 17 - 18 September 2026
📍Lille & Online

As a sponsor of API Platform Conference 2026, we'll be in Lille on 17 and 18 September. Over two days, the conference will bring together the API Platform community for talks and technical discussions. Come and visit our booth to chat with our team. And if you can't make it in person, the conference is also available online.

Tech Alternatives Nantes

📆 18 September 2026
📍Nantes, France

One of the highlights of our autumn calendar will be Tech Alternatives Nantes, as part of Nantes Digital Week. Together with around fifteen organisations from the local tech scene, we are co-organising a day dedicated to sovereign digital solutions, those that offer an alternative to the major US platforms. The programme features keynote speeches, talks, panel discussions and case studies, along with a showroom where you can speak directly with exhibitors. Come and meet us there. The event starts at 9.30am at La Cantine x La French Tech Nantes (Halle 6 Est, 40 rue de la Tour d'Auvergne) and admission is free upon registration.

Salon de la Data et de l'IA

 📆 22 September 2026

📍 Nantes, France

Our CEO, Quentin Adam, will be speaking at the Salon de la Data et de l'IA on 22 September at the Cité des Congrès in Nantes. This flagship event of Nantes Digital Week is dedicated to the uses and challenges of data and AI. The programme combines talks, case studies and demonstrations on topics such as GenAI, DataOps, cybersecurity and sovereignty. Come and listen to his talk entitled "AI, Tech and the Economy: What Impact on Your Children's School?".

Confitura Conference

 📆 25 - 26 September 2026

📍 Warsaw, Poland

On 25 and 26 September, our DevRel, Horacio Gonzalez, is heading to Warsaw for the Confitura Conference, one of the longest-running Java community gatherings in Poland. He will be giving a talk entitled 'Wrap, Reshape, or Redesign: Retrofitting Your APIs for a World of Agents', exploring how to adapt existing APIs for a world of AI agents. If you're there, do come along to his talk and catch up with him afterwards to continue the discussion.

October

Our upcoming events 2026 continue in October.

Volcamp 2026

 📆 1 - 2 October 2026

📍 Clermont-Ferrand

On 1 and 2 October, we'll be in Clermont-Ferrand for Volcamp 2026, the first tech conference set deep in the heart of the Auvergne volcanoes. Two talks are on the programme: our colleagues Alexandre Burgoni and Pierre Zemb will be giving a talk entitled 'Houston, we have a problem with ETCD', while Horacio Gonzalez will be speaking on 'Your cloud architecture is actually an organisational chart'. Between sessions, do come and see us at our booth to discuss your projects.

Devoxx Belgium 2026

📆 5–9 October 2026

📍 Kinepolis, Antwerp, Belgium

Our DevRel, Horacio Gonzalez, will be at Devoxx Belgium for a talk on adapting existing APIs for a world of AI agents. The event is one of the largest developer conferences in Europe, with five days of talks, workshops and community gatherings in Antwerp. If you're attending, come along to his talk and catch up with him afterwards.

Forum PHP 2026

 📆 8 - 9 October 2026

📍 Disneyland Paris

Forum PHP 2026 is coming up on 8 and 9 October, the annual gathering of the PHP community in France. Our CEO, Quentin Adam, will be giving a talk on digital sovereignty in the age of AI. Our team will welcome you at our booth on both days, so pop by for a catch-up between talks.

BDX I/O

 📆 29 - 30 October 2026

📍 Bordeaux, France

Horacio Gonzalez, our DevRel, will be at BDX I/O on 29 October for a talk on how infrastructure choices shape team organisation. The two-day event will bring together Bordeaux's tech community for talks focusing on programming and careers in the field. Come along to his talk and have a chat with him.

Cloud Nord 2026 

📆 30 October 2026

📍 Lille, France

On 30 October, we'll also be in Lille for Cloud Nord 2026, with two talks on the programme. Our teammates Alexandre Burgoni and Pierre Zemb will be giving their talk, while our CTO, Steven Le Roux, will be discussing active defence in his talk entitled 'HoneySwamp: Active Defense to Ruin Attackers'. If you're attending, do come along to their talks and catch up with them afterwards.

November

#UYBHYS26

📆 6 - 7 November 2026

📍 Brest, France

Our upcoming events 2026 continue in November with #UYBHYS26, which stands for 'Unlock Your Brain, Harden Your System', an event in Brest dedicated to cybersecurity. Our CTO, Steven Le Roux, will be speaking on active defence strategies to thwart attackers. If you're in Brest, come and hear him and stick around to chat after the sessions.

DevFest Toulouse

 📆 19 November 2026

📍 Toulouse

DevFest Toulouse will be hosting our DevRel, Horacio Gonzalez, on 19 November for a talk on cloud architecture. The event brings together developers and tech enthusiasts for a day of talks and networking. It's a great opportunity to attend his talk and have a chat with him.

Codeurs en Seine

 📆 19 November 2026

📍 Rouen

On the same day, we'll be sponsoring Codeurs en Seine, and you'll be able to meet our teammates at our booth throughout the day. Join us between talks to discuss your projects or just chat about the cloud and development.

See you there

So that's our programme of upcoming events 2026. If you're attending any of these, do come and meet us to discuss your projects, share your ideas or simply take a moment to have a chat with us.

A compliance manager's field report.

When I joined Clever Cloud four years ago, I walked into a deeply technical culture: no collaborative suite, no conventional project management tool. Everything lives in GitLab, GitHub and terminals.

Running an integrated management system (ISO 9001, ISO 27001, HDS, regulatory compliance) is formalisation work: policies, procedures, security rules.

So we started out the conventional way, on a collaborative suite.

Some of the habits that came with it quickly turned into a time sink. Version numbers tracked by hand in a spreadsheet. PDFs sent to the steering committee for sign-off. Signatures. Folders labelled "approved" and "in progress". Links breaking every time a format changed.

Human checks everywhere, so mistakes waiting to happen. And above all: developers never go into those tools. Their documentation sits in GitLab.

So we made a simple call. The entire documentation set in Markdown, version-controlled in GitLab, in the same place as the technical documentation.

What that changes in practice:

• a complete, native history: commits, diffs, authors
• every change goes through a merge request, with at least one approval from a third party. Segregation of duties no longer rests on a declared process, it is carried by the tool
• the technical population reads the policies all year round, not only at the annual awareness session (the new challenge is the non-technical profiles, who now learn GitLab during onboarding, as I did four years ago)

Then we automated. A monthly script reads the platform changelogs, drafts the updates in the right places across the policies, and opens the merge requests. What is left for me is the review, then approval by whoever owns the subject. That is where the month becomes 30 minutes.

And the real change is somewhere else. We no longer update documents for the audit, once a year. We update them at every actual change to the information system. In front of the auditor, the sources, the versions and the approvals are right there. Compliance becomes a measured state rather than a declared one.

That is how I picture compliance as code from an integrated management system governance standpoint. What it changes at a deeper level is the tempo: compliance now moves at the speed of the information system, not at the speed of the audit calendar.

The story is that of a French company engaged in a commercial dispute with a local competitor, abroad. The authorities of the country decide to launch an audit and the company, anxious to be beyond reproach, agrees to hand over financial data as well as information on its manufacturing processes.

The result: the company is hit with a surcharge all the same, then loses the majority of its customers to the competitor that had reported it. In the meantime, it has handed over valuable economic information which, for its part, can never be taken back.

This case led me to consider a dimension of compliance that we do not discuss enough for my liking. We generally regard it as a way of reducing risk, protecting the company and establishing trust.

But what happens when the tools of compliance (the audit, the inspection, the certification) stop being safeguards and become weapons of economic warfare?

Behind the procedure, the balance of power

An audit appears neutral to us because its vocabulary is. We speak of frameworks, of evidence, of non-conformities, of corrective actions. Everything seems to belong to an objective method whose conclusion would follow naturally from the facts observed.

Yet a control procedure never takes place outside the political and economic context in which it was decided.

The DGSI says so bluntly: these audits, "generally requested by government authorities as part of regulatory procedures, may also result from requests by competing companies".

What I take from this: the official procedure can be diverted in order to capture know-how, to slow a rival down, or to force it to expose itself.

Since it is the authority that audits, and that determines the information it wishes to obtain, the power sits on the other side and the balance of forces is uneven.

The two other examples reported by the DGSI illustrate precisely this risk: an audit tied to an export licence drags the timescales out to the point of leaving a factory facing a supply shortage, and in the other case, a compliance inspection results in modification requirements heavy enough to destabilise the company concerned.

The information that an audit makes it possible to obtain is considerable: the complete supply chain, the detail of industrial processes, the identity of those who hold the know-how, the architecture of a system, sometimes access to source code.

In this way, delaying a licence, suspending a delivery, drawing on the processes, taking the market, imposing costly modifications all become a reality within the economic and industrial balance of power.

In each of these situations, the company's cooperation is not enough to protect it. This obviously does not mean that every audit should be refused, or every certification suspected of being a hostile manoeuvre. It simply means that a technical tool can also carry a political function, and that it would be unwise to forget it.

The concrete cases

Without dwelling on the well-known examples of Alstom or BNP Paribas, concerning foreign interference that goes even further than simple audit procedures, there are a good number of concrete cases worth knowing.

The Micron affair, in China, is probably the clearest example of this shift.

In March 2023, the Cyberspace Administration of China opened a cybersecurity review into the products of the American memory manufacturer. Two months later, it announced that these products presented serious problems liable to threaten the supply chain of the country's critical infrastructure. The operators concerned were therefore ordered to stop buying them.

The regulator did not publish technical details precise enough to allow any assessment of the nature of the vulnerabilities found.

The decision also came amid strong tensions surrounding semiconductors, at a time when the United States had already tightened its restrictions on the export of advanced technologies to China.

It is hardly surprising, then, that it was widely interpreted as a retaliatory measure, even though the reason officially given remains that of cybersecurity. Here, a genuine security concern serves a broader economic strategy: the decision put at stake half of Micron's Chinese market, or around 12.5% of its worldwide revenue.

China had already raised concerns in 2015, when it sought to impose highly intrusive control rules on service providers in the banking sector, rules that amounted to leaving all know-how at the point of entry. The initiative was suspended that same year following significant diplomatic pressure.

A quick detour to our British neighbours brings us to the case of Huawei.

From 2010, the Chinese company submitted to British scrutiny for close to a decade. GCHQ (Government Communications Headquarters) and then the NCSC (National Cyber Security Center) examined the company's equipment, its source code and its engineering practices. In July 2020, the British services were not convinced and, under American pressure, Huawei was removed from the British 5G network.

The tools France has built

France is not defenceless, it holds several defensive regulatory instruments:

The blocking statute of 1968, for a long time almost never applied, was reformed in 2022 (decree no. 2022-207). It prohibits the disclosure to a foreign authority of sensitive information of an economic, commercial, industrial, financial or technical nature that touches on the essential interests of France. Since April 2022, a single point of contact, the SISSE (the strategic information and economic security service, attached to the DGE), issues an opinion within one month setting out what may or may not be disclosed (sources: economie.gouv.fr, DGE, DGSI).

To this judicial shield an infrastructure shield has been added. The cloud at the centre policy, set out by circular in 2021 and updated in 2023, requires public administrations to host their digital projects on the state's internal clouds or on qualified commercial offerings.

For data of particular sensitivity, the offering chosen must hold the SecNumCloud qualification, or an equivalent European qualification, and must be immune to any unauthorised access by the public authorities of third states.

This qualification goes beyond technical measures, covering the legal control of the company, its personnel, the location of its activities and the legislation to which the service may be subject.

SecNumCloud constitutes, in this sense, a defensive instrument. It allows the state to define the conditions under which certain sensitive data may be entrusted to a provider, rather than accepting that the market or foreign powers alone determine the level of risk we ought to tolerate.

France then argued for the introduction of comparable criteria into the European cloud services certification scheme, EUCS, particularly at its highest level. These sovereignty criteria have never commanded consensus among member states. The scheme has been pending ever since.

Several member states and organisations representing European and foreign industrial interests opposed these criteria, which they considered protectionist and alien to a certification that was supposed to remain purely technical. Conversely, several European companies called for them to be retained, precisely because they held that the security of a cloud could not be separated from the law to which it is exposed.

The United States, for its part, does not hesitate: its FedRAMP programme has for years made access to the federal market for cloud services conditional on a certification that it controls.

This debate says a great deal about our collective difficulty. At the very moment when we were seeking to define the conditions of trust applicable to our own market, we hesitated to accept that a certification might also express a sovereignty choice. To return to the image of the weapon, we began by blunting it ourselves. The reality is that we have not managed to equip ourselves with the safeguards needed in the face of the compliance instruments of non-European countries.

Their function is defensive, they are ramparts. Unlike the FCPA and OFAC, which are instruments of projection: they go and find the foreign company on its own ground.

From compliance endured to reciprocity

Two thousand four hundred years ago, Thucydides staged the Melian dialogue. Athens wants to subjugate the small island of Melos, which appeals to law and justice. The Athenians' reply has remained famous: "the strong do what they can and the weak suffer what they must".

The idea is not to devalue the usefulness of compliance and of law, nor to call open markets into question. It is to recall that being in order does not guarantee being protected. Law does not defend itself: it only truly protects where a public authority is prepared to enforce it.

For as long as the asymmetry in means of pressure exists, the most aggressive actor will keep its advantage. If access to a foreign market entails handing over source code or opening up one's factories, we must be able to demand comparable guarantees.

It is time to add a principle that the European Union and its member states have recently begun to establish, but still hesitate to assume fully: reciprocity in their regulatory framework, faced with the offensive legal instruments of third countries.

— Darya KHENDRIK, Compliance Manager at Clever Cloud, IMS lead (Integrated Management System) and DPO

Sources

• DGSI, Foreign audits as vectors of destabilisation and interference for French strategic entities
• Cyberspace Administration of China, Micron decision of 21 May 2023
• USITO, suspension of the Chinese banking "secure and controllable" guidelines
• NCSC, summary of analysis of the US May 2020 sanctions concerning Huawei
• NCSC, advice on high-risk vendors
• ANSSI, SecNumCloud framework of requirements v3.2
• ITI, position of 11 April 2024 on removing the sovereignty criteria from the EUCS
• FedRAMP, conditions of access for cloud services to the federal market
• EUR-Lex, International Procurement Instrument, Regulation 2022/1031
• EUR-Lex, Foreign Subsidies Regulation 2022/2560
• EUR-Lex, Anti-Coercion Instrument, Regulation 2023/2675

workloads and node pools but does not administer the cluster’s critical infrastructure.

The control plane consists of Kubernetes’ standard components: the API server, etcd (the datastore that stores the cluster’s state), the scheduler and the controller manager. If the control plane fails, workloads that are already running continue to operate, but the cluster can no longer be managed: no new deployments, no scaling, and no response to kubectl commands. Managed services remove responsibility for precisely this layer from engineering teams.

Why is Kubernetes difficult to operate yourself?

Kubernetes  is a container orchestration standard, not a turnkey product. Deploying a cluster without a managed layer means handling:

• version upgrades (the Kubernetes project actively supports the three most recent minor releases);
• internal TLS certificate rotation;
• high availability of the control plane across multiple nodes;
• backup and consistency of the etcd datastore;
• security patches, often under tight time constraints.

These tasks are repetitive, consume valuable engineering time, and are a frequent source of incidents when not performed correctly. Managed services are specifically designed to remove this operational burden from product teams.

Use cases: when managed Kubernetes delivers value

Kubernetes—whether managed or self-managed—becomes relevant in specific scenarios. It is not a systematic replacement for a PaaS: the two approaches address different needs.

Managed Kubernetes is well suited when:

• the architecture includes multiple interdependent services requiring fine-grained orchestration (rolling updates, resource management by namespace);
• workloads are already built for Kubernetes and delivered as Helm charts or YAML manifests;
• the team requires multi-cluster or hybrid environments (on-premises + cloud);
• operating the control plane represents a real and measurable cost for SRE or DevOps teams.

A PaaS remains a better fit when:

• the application deployment model (code push with platform-managed build and runtime) matches the way your team works;
• you want to focus on application code without managing orchestration primitives (networking, scheduling, node management);
• your applications do not require fine-grained control over workload placement or the cluster’s network topology.

Comparison table: self-managed Kubernetes vs managed Kubernetes vs PaaS

Note: here, vanilla refers to a standard Kubernetes experience, with no changes to native Kubernetes behaviour and no proprietary tooling imposed.

Common mistakes when choosing or adopting managed Kubernetes

Managed Kubernetes in Europe: which sovereignty criteria matter?

For organisations subject to the GDPR, sector-specific regulations (healthcare, public sector, defence) or data residency requirements, where the cluster is hosted is a compliance issue, not just a performance consideration.

Points to verify:

• physical location of the    datacenters (country and applicable jurisdiction);
• identity of the operator and the involvement of foreign subcontractors in the hosting chain;
• infrastructure certifications (SecNumCloud, ISO 27001, HDS, depending on the provider and the offering);
• potential access to data by non-European third parties, particularly under extraterritorial legislation.

A managed Kubernetes service operated in France by a French provider addresses these requirements without requiring additional user-side configuration. This is the approach taken by Clever Kubernetes Engine (CKE), operated end to end in France by Clever Cloud, with no foreign hyperscaler involved in the hosting chain.

Key takeaways

Managed Kubernetes is relevant when your organisation already relies on Kubernetes and maintaining the control plane represents a meaningful operational burden. It is not a universal solution: when a PaaS deployment model matches the way your team works, it often remains the most straightforward choice. For organisations with European sovereignty requirements, the choice of provider and hosting location is critical.

The key selection criteria are: vanilla compatibility (no vendor lock-in), the release policy, a clear division of responsibilities between provider and user, and the overall cost model-list price plus internal engineering costs.

FAQ

What is managed Kubernetes?

A service in which the cloud provider manages the Kubernetes control plane (provisioning, updates and availability). The user manages workloads and node pools, but not the cluster’s critical infrastructure.

What is the difference between managed Kubernetes and a PaaS?

A PaaS handles the build, deployment and execution of what you deliver (source code or a container image) without requiring you to define the underlying orchestration. Managed Kubernetes retains the standard Kubernetes interface (kubectl, Helm and YAML manifests), allowing you to manage these primitives while delegating control plane operations to the provider. These are two distinct operational models that are complementary rather than interchangeable.

Does managed Kubernetes create a risk of vendor lock-in?

It depends on the implementation. A vanilla offering (with no changes to Kubernetes’ native behaviour and no proprietary tooling imposed) allows workloads to be migrated without rewriting them. By contrast, non-standard CRDs or exclusive networking integrations can create dependency on a specific provider.

Who is responsible for what in a managed Kubernetes cluster?

The provider manages the control plane: updates, availability and patching. The user remains responsible for node pools (sizing and scaling), workloads, application security and RBAC policies.

How can I tell whether my organisation needs managed Kubernetes rather than a PaaS?

The key question is architectural complexity. If your applications require multi-service orchestration, advanced networking interactions or are already designed for Kubernetes, managed Kubernetes is appropriate. If you are deploying relatively standard services, a PaaS will usually be faster and less expensive to operate.

Managed Kubernetes in France: what sovereign options are available?

In France, several providers offer managed Kubernetes on sovereign infrastructure, including Scaleway (Kubernetes Kapsule), OVHcloud (Managed Kubernetes Service) and Clever Cloud with CKE. Beyond location, the key differentiators are the actual level of sovereignty (operator, subcontractors involved in the hosting chain), vanilla compatibility and the shared responsibility model between provider and user.

Kubernetes is a container orchestrator; the cloud is where it most often runs. The term "Kubernetes cloud" therefore covers two related realities: running Kubernetes on cloud infrastructure, and relying on a managed Kubernetes service operated by a provider.

Kubernetes Is Not a Cloud

Kubernetes is an open source container orchestrator. How Kubernetes works comes down to orchestrating containers spread across a set of machines: it schedules their placement, deploys them, supervises their lifecycle, and manages their scaling and network exposure. These containers are often built with Docker, and the distinction between Kubernetes and Docker is itself a common source of confusion.

What Kubernetes does not do is provide the underlying machines, storage, and network. It needs infrastructure to run on, and that infrastructure can take several forms: physical servers (bare metal), virtual machines, a private cloud, or a public cloud. This is the layer a cloud provider supplies.

Hence a frequent confusion: comparing "Kubernetes" with "AWS", or Kubernetes with a cloud provider in general. The two sit at different layers. A cloud provider sells infrastructure and often offers a managed Kubernetes on top of it. Kubernetes orchestrates the containers running on that infrastructure. You do not choose between Kubernetes and the cloud: you can run Kubernetes on a cloud, or use the managed Kubernetes that cloud offers.

In other words, choosing an infrastructure and choosing who operates the cluster are two separate decisions. That is what shapes the types of offerings described below.

Running Kubernetes in the Cloud: Managed or Self-Managed

Once that relationship is clear, two operating models appear. Either you install and operate Kubernetes yourself on machines rented from a cloud provider, or you use a managed service where the provider operates the control plane for you.

The control plane is the dividing line between the two. It groups the components that drive the cluster: the apiserver, etcd (the datastore that holds the cluster state), the scheduler, and the controller-manager. Operating it yourself means handling version upgrades, which the Kubernetes project requires you to keep up with since it only supports its three most recent minor versions, internal TLS certificate rotation, high availability of these components across several nodes, etcd backup and consistency, and security patches under time pressure. A managed service takes this layer off your hands: you keep control of your workloads, your node pools, and their security, but no longer administer the cluster's critical infrastructure.

Not every need calls for a full cluster. Lighter distributions, such as K3s, exist and are worth evaluating depending on the workload and the context. And Kubernetes, managed or not, is one operating model among others. A PaaS follows a different one: you ship code, and the platform handles the build, execution, and scaling, without you having to operate an orchestrator. PaaS and Kubernetes meet different, complementary needs, and a single organization can use both.

The Three Types of Offerings for Running Kubernetes in the Cloud

Offerings fall into three types, depending on whether you operate the cluster yourself or a provider does, and, in the latter case, on whether that provider is a global hyperscaler or a European player.

Self-Managed on Cloud Infrastructure

You rent compute, storage, and network from a provider, then install and operate Kubernetes yourself. This approach gives the most complete control over the cluster and the underlying infrastructure, at the cost of the operational burden described above. It makes sense when specific infrastructure, network, or compliance constraints are not covered by the managed offerings available. It is also the approach of teams that want to keep a hand on every component of the cluster, from the container runtime to the scheduling and internal network configuration.

Managed by a Hyperscaler

The large global cloud providers offer managed Kubernetes services: Amazon EKS, Google GKE, Microsoft AKS. The provider operates the control plane, and you deploy your workloads with the standard Kubernetes tooling. These offerings are tightly integrated with each provider's ecosystem, which is their strength when your other services already run there, and the point to watch if you ever consider moving away. Their operators, however, fall under non-European jurisdictions, including for the regions they run in Europe. These offerings therefore do not meet a European sovereignty requirement, a decisive criterion for certain sectors and certain types of data.

Managed by a European Provider

Several European providers offer managed Kubernetes on infrastructure located within the European Union. Location matters, but it does not make an offering sovereign. A datacenter sitting in Europe remains within reach of the US CLOUD Act if the company operating it answers to a foreign jurisdiction. What determines sovereignty is the legal and capital control of the operator, not where the servers sit.

On this ground, several players offer managed Kubernetes: OVHcloud (Managed Kubernetes Service) and Scaleway (Kubernetes Kapsule). Clever Cloud offers Clever Kubernetes Engine, a managed Kubernetes operated by a European company based in France. Beyond location, these offerings differ in their real level of sovereignty, which depends on the operator and its subcontracting chain, and in how well they fit the tools you already use. For a closer look, French managed Kubernetes offerings are covered in a dedicated article.

Kubernetes Cloud: Key Takeaways

"Kubernetes cloud" refers to running Kubernetes on cloud infrastructure, along with the managed services providers offer so you do not have to operate the cluster yourself. The line between self-managed and managed runs through the control plane, the layer a provider either takes on or does not. Three types of offerings then appear: self-managed on cloud infrastructure, managed by a hyperscaler, and managed by a European provider, bearing in mind that a European location alone is not enough to make an offering sovereign. Which one fits depends on your infrastructure constraints, the tooling already in place, and your requirements around data and sovereignty. It all comes down to one distinction: the cloud supplies the infrastructure, Kubernetes orchestrates what runs on it, and the managed model determines who, the provider or you, operates the cluster in between.

What remains is to work out when a managed Kubernetes makes sense and how to choose one, and to clarify what a sovereign Kubernetes really means.

FAQ

Is Kubernetes a cloud?

No. Kubernetes is a container orchestrator, not an infrastructure provider. A cloud supplies the servers, storage, and network; Kubernetes orchestrates the containers running on top of them. You can run it on a cloud, or use the managed Kubernetes service a cloud offers.

Can you run Kubernetes outside the cloud, on bare metal or on-premises?

Yes. Kubernetes is infrastructure-agnostic: it runs on physical servers, virtual machines, a private or public cloud, and on hybrid environments combining several of these. The cloud is the most common setting, not a requirement.

Are "Kubernetes cloud" and "managed Kubernetes" the same thing?

Not exactly. "Kubernetes cloud" broadly means running Kubernetes on cloud infrastructure, which covers both a cluster you operate yourself and a managed service. "Managed Kubernetes" specifically refers to the offering where a provider operates the control plane for you. Every managed Kubernetes is Kubernetes in the cloud, but the reverse is not always true.

What is the difference between Kubernetes and a cloud provider like AWS?

They operate at different layers. AWS is a cloud provider: it sells infrastructure and offers, on top of it, a managed Kubernetes (Amazon EKS). Kubernetes is the orchestrator that drives the containers on that infrastructure. Setting them against each other is like confusing the warehouse with the system that organizes what goes into it.

Early on, we recognised that building a coherent and extensible cloud platform did not require creating every component ourselves. It required connecting the right technologies, operators and expertise within an open ecosystem.

At the heart of our strategy are three foundational pillars: customer centricity, innovation through collaboration, and mutual growth. These principles guide how we work with partners, support our users, and continuously enhance our platform.

1. Customer Centricity

Our first and foremost commitment is to our users. Every partnership we forge is evaluated through the lens of customer value. Does it address a real need? Does it simplify processes? Does it contribute to a better experience for developers and teams?

When our users expressed the need for enhanced observability capabilities, we didn’t just take note, we acted. For example, our partnership with Elastic brought Elasticsearch into our ecosystem in a way that is fully integrated, production-ready, designed to work seamlessly from day one. This made Clever Cloud one of the very few global players able to offer Elasticsearch Platinum. It's a clear example of how we listen, respond, and collaborate to create tangible impact.

Customer centricity is more than listening; it’s about co-developing practical, scalable solutions that simplify everyday operations. Our goal is to ensure that the services we provide and the partnerships we cultivate consistently reduce complexity, enhance reliability, and support developers through every stage of their application lifecycle.

2. Innovation Through Collaboration

True progress occurs when diverse minds come together to tackle complex challenges. At Clever Cloud, we view collaboration not as a convenience, but as a catalyst for innovation. We work alongside a wide range of partners, from open-source communities and research institutions such as Institut Mines-Télécom to industry consortia, to explore new ideas and build forward-looking technologies.

We actively contribute to open-source projects like Eclipse Biscuit, Sōzu, and Exherbo Linux, which are integral to our cloud stack. Our contributions help drive development in areas critical to both our infrastructure and the broader ecosystem.

In parallel, we engage with European and national initiatives such as ReNESENS, Hyper Open X, and CollabNext, helping to shape standards, foster knowledge exchange, and build next-generation technologies. We also partner with academic and research institutions, encouraging experimentation and long-term thinking that benefits everyone in the tech ecosystem, from students, professors and research labs to leading edge innovation engineering teams and industrialization.

In this context, our commitment to innovation through collaboration is also a key enabler of the Strategic Digital Autonomy approach: we believe in cultivating autonomy by fostering interoperability, reversibility, and transparency through open standards and open-source technologies. This reinforces our partners’ and customers’ ability to adapt, evolve, and remain competitive.

3. Mutual Growth

We believe that strong partnerships should be mutually rewarding. That’s why we strive to create opportunities that help both Clever Cloud and our partners grow together.

Our marketplace reflects this philosophy. It brings together Clever Cloud’s core services with powerful tools and technologies from partners like Elastic, Azimutt, MailPace, and open-source projects such as Keycloak, Metabase, Otoroshi among many others.

We embrace two distinct types of relationships for the Marketplace: first-party add-ons, which are co-created with partners and fully managed by Clever Cloud as part of our platform; and third-party add-ons, where Clever Cloud acts as a distribution channel while the partner independently manages and supports their service; 

In addition to this, we also develop strategic partnerships, where we collaborate with trusted providers to integrate their solutions into our portfolio, ensuring our customers have access to a broad, reliable toolkit for their infrastructure needs.

This ecosystem allows our customers to access a rich, integrated suite of services in a unified environment, while giving our partners valuable visibility and access to our user base.

Mutual growth also means ensuring that Clever Cloud and its ecosystem work seamlessly with other bare metal and IaaS cloud service providers, expanding the flexibility, performance, and scalability options available to our users. As such, in addition to its own infrastructure, Clever Cloud is also available on a range of leading European sovereign cloud service providers, including OVHcloud, Scaleway, Cloud Temple and 3DS OUTSCALE’s SecNumCloud services.

In the same way in Africa and Asia, we collaborate with local actors to foster digital sovereignty and cloud adoption by supporting infrastructure strengthening and local talent development, co-developing solutions that embrace open innovation and technology reversibility. 

We extend this mutual growth commitment through our UP startup program, which supports emerging companies with technical resources, mentorship, and market insights. It is designed not just to provide credits, but to deliver meaningful guidance and opportunities for growth.

A Shared Vision for the Cloud

These three pillars, customer centricity, innovation through collaboration, and mutual growth, are not separate initiatives. They are deeply interconnected values that shape how we build, grow, and engage with our ecosystem.

At Clever Cloud, we’re not just talking about partnerships: we’re taking the initiative to build them. We’re actively engaging with database, developer tools, security, user-facing SaaS providers, and other technology vendors. Whether you’ve already been approached or not, this is an open invitation to join forces, know that we’re still ready to build together with one clear message: our goal is to complement existing catalogs, not to do everything alone.

Our mindset is all about revenue sharing, not about one party financing the other. We’re in this as equals, aiming to co-create value and drive real impact. This isn’t a ‘wait-and-see’ mindset. It’s a deliberate, open, and proactive stance, and we’re looking for partners who share it.

Ultimately, these partnerships are not just about growth, they’re about delivering real, tangible benefits to cloud users. By combining complementary expertise, we broaden what customers can deploy, reduce integration work and accelerate access to production-ready technologies. The result is a more coherent and reliable experience for developers, startups and enterprises.

If this approach resonates with you, get in touch. Let’s build something meaningful together.