En résumé : K3s est une distribution Kubernetes certifiée CNCF, optimisée pour les environnements contraints (edge, IoT, labs). K8s désigne le projet Kubernetes originel, conçu pour des clusters de production à grande échelle. Le choix dépend de vos ressources disponibles, de votre contexte de déploiement et de votre charge opérationnelle.

K8s : le Kubernetes standard entreprise

K8s est l'abréviation de Kubernetes, le « 8 » représentant les huit lettres entre le « K » et le « s ». Il s'agit du projet open source original, maintenu par la Cloud Native Computing Foundation (CNCF) et initialement développé par Google.

Kubernetes est conçu pour des environnements de production à grande échelle : clusters multi-nœuds, haute disponibilité, intégration avec les clouds publics (AWS, GCP, Azure) ou des datacenters on-premises. Son plan de contrôle comprend plusieurs composants distincts : API server, scheduler, controller manager, etcd, déployés séparément, ce qui offre une flexibilité maximale mais requiert une expertise opérationnelle significative.

Prérequis typiques pour un nœud control plane en production : 2 vCPU et 2 Go de RAM au minimum pour les composants Kubernetes seuls, sans compter etcd ni les charges applicatives.

K3s : une distribution Kubernetes certifiée CNCF, pas un fork

K3s est une distribution certifiée de Kubernetes, pas une version allégée non officielle ni un fork. Créé par Rancher Labs, il a été donné à la CNCF en juin 2020 et passe les mêmes tests de conformité Sonobuoy que toutes les distributions certifiées. Tout manifeste Kubernetes valide fonctionne sur K3s.

Son objectif principal : réduire drastiquement les ressources nécessaires pour faire tourner Kubernetes sur des environnements contraints (edge, IoT, CI/CD, labs)  sans renoncer à la compatibilité API.

Ce que K3s change par rapport à K8s

• Binary unique de moins de 70 Mo (x86, ARM64, ARMv7 et S390X supportés), incluant le runtime containerd, le CNI Flannel, un Ingress Traefik et un load balancer Klipper.
• SQLite comme datastore par défaut en single-node, au lieu d'etcd. En configuration haute disponibilité (3 nœuds serveur minimum), K3s peut utiliser etcd embarqué ou un datastore externe (MySQL, PostgreSQL, etcd externe).
• Composants alpha/beta retirés pour réduire la surface d'attaque et l'empreinte mémoire.

Point important : K3s ne supprime pas etcd ; il le rend optionnel. En single-node, SQLite suffit. En haute disponibilité, etcd embarqué ou externe est supporté - mais ce dernier n'est pas officiellement pris en charge par l'équipe K3s.

Empreinte ressources

K3s fonctionne à partir de 512 Mo de RAM sur un nœud agent. Un server node (control plane) requiert 2 Go de RAM et 2 cœurs CPU selon la documentation officielle (mise à jour mai 2026), hors charge applicative. Un profil mesuré à la charge est disponible dans le guide de resource profiling K3s. À noter : en test sur du matériel avec 1 Go de RAM total, les distributions K3s, k0s et MicroK8s ont montré des instabilités lors du déploiement de charges applicatives réelles (un seul cluster Kubernetes, même léger, consomme des ressources de contrôle non négligeables).

Différences techniques clés

Datastore

Runtime et packaging

K8s ne fournit pas de runtime par défaut depuis la suppression de dockershim (v1.24, 2022). À partir de Kubernetes 1.24, vous devez installer un runtime CRI-compatible (containerd ou CRI-O). K3s embarque containerd directement dans son binaire.

Architecture du plan de contrôle

Dans K8s, les composants du plan de contrôle (API server, scheduler, controller manager) sont des processus séparés. Dans K3s, ils sont fusionnés en un seul binaire, ce qui réduit l'overhead mais limite certaines configurations avancées d'isolation.

Scalabilité

K3s est adapté à des clusters de taille modérée. En configuration haute disponibilité (3 server nodes, 4 vCPU / 8 Go de RAM), la documentation officielle indique une capacité d'environ 1 200 agents. Pour des clusters de très grande taille (plusieurs milliers de nœuds), K8s  reste la référence.

Tableau comparatif K3s vs K8s

Cas d'usage : lequel choisir ?

Choisissez K3s si :

• Vous déployez sur du matériel contraint (Raspberry Pi, appliances industrielles, serveurs edge avec peu de RAM).
• Vous gérez des clusters IoT ou edge distants, potentiellement en mode déconnecté.
• Vous avez besoin d'un cluster de développement ou de CI démarrant rapidement, y compris sur matériel modeste.
• Vous souhaitez un cluster opérationnel avec un minimum de configuration initiale.

Choisissez K8s (ou une distribution enterprise) si :

• Vous orchestrez des centaines ou milliers de nœuds en production.
• Vos workloads requièrent des intégrations cloud-natives avancées (stockage, load balancers, IAM) fournies par les hyperscalers.
• Vous avez besoin de composants API en alpha/beta non disponibles dans K3s.
• Votre organisation dispose d'une équipe SRE dédiée à l'exploitation de clusters.

Cas hybrides : K3s et K8s ensemble

K3s et K8s ne sont pas mutuellement exclusifs. Plusieurs architectures hybrides sont documentées en production :

Fleet management avec Rancher

Des clusters K3s edge sont pilotés depuis un plan de contrôle central tournant sur K8s ou RKE2. The Home Depot (grande distribution américaine, plus de 2 300 magasins) gère ainsi ses sites avec K3s supervisé depuis Rancher.

Clusters de dev et staging K3s, prod K8s

La compatibilité API garantit que les manifests et charts Helm testés sur K3s fonctionnent en production sur un cluster enterprise. Cette parité réduit les surprises en promotion d'environnements.

CI/CD

Des pipelines de test tournent sur K3s (faible coût, démarrage rapide) pendant que les environnements de production utilisent un cluster K8s managé.

Kubernetes managé : une troisième voie

Ni K3s ni K8s ne résolvent la question de l'opération quotidienne : mises à jour, certificats, surveillance du plan de contrôle, gestion des défaillances. C'est précisément ce que couvrent les solutions de Kubernetes managé.

Les hyperscalers (EKS, GKE, AKS) proposent cette gestion dans leurs propres clouds. Mais des solutions managées existent aussi en dehors de ces écosystèmes, notamment pour des organisations qui souhaitent conserver la maîtrise de leurs données et opter pour un Kubernetes souverain, voire un Kubernetes français.

Clever Kubernetes Engine (CKE) est le service Kubernetes managé de Clever Cloud, conçu pour des équipes qui utilisent déjà Kubernetes et souhaitent déléguer la gestion du plan de contrôle (updates, haute disponibilité, monitoring) sans être contraints dans un seul hyperscaler. CKE s'adresse explicitement aux équipes que le modèle PaaS traditionnel ne couvre pas (cas multi-runtime, workloads non-twelve-factor, ou besoin de contrôle granulaire sur les ressources).

FAQ

K3s est-il un fork de Kubernetes ?

Non. K3s est une distribution certifiée CNCF de Kubernetes. Il passe les tests de conformité Sonobuoy et respecte les mêmes APIs que K8s Il n'est pas maintenu en parallèle de Kubernetes : il suit les releases du projet originel.

Peut-on utiliser K3s en production ?

Oui, avec des nuances. K3s est documenté pour des charges de production dans des environnements contraints (edge, IoT). Pour des clusters à grande échelle ou des workloads critiques avec des exigences de SLA élevées, le K8s  (ou une distribution enterprise comme RKE2) est plus adapté.

K3s supporte-t-il Helm ?

Oui. K3s inclut un contrôleur Helm intégré et est compatible avec toute chart Helm valide.

Quelle est la différence entre K3s et K3d ?

K3d est un outil qui fait tourner K3s dans des conteneurs Docker. Il simplifie encore davantage la création de clusters K3s locaux pour le développement, mais n'est pas destiné à la production.

K3s fonctionne-t-il sur ARM ?

Oui. ARM64 et ARMv7 sont nativement supportés, ce qui explique sa popularité sur Raspberry Pi et les appliances industrielles.

Kubernetes managé vs K3s auto-hébergé : quoi choisir ?

K3s auto-hébergé vous donne un contrôle total mais vous rend responsable des opérations (updates, sécurité, haute disponibilité). Un Kubernetes managé délègue cette responsabilité à un opérateur, au prix d'une dépendance envers ce fournisseur. Le choix dépend de vos ressources opérationnelles et de vos exigences de contrôle.

La question Kubernetes vs Docker mérite une réponse précise, parce que les deux technologies ne répondent pas au même besoin.

Docker sert principalement à créer et exécuter des conteneurs. Kubernetes sert à orchestrer ces conteneurs lorsqu’une infrastructure devient plus complexe. Les deux technologies sont donc souvent complémentaires, même si elles sont régulièrement opposées à tort.

Comprendre cette différence permet surtout de mieux savoir quand utiliser Docker seul, quand Kubernetes devient pertinent, et pourquoi toutes les applications n’ont pas forcément besoin d’un cluster Kubernetes.

Docker : standardiser l’exécution d’une application

Docker a popularisé la conteneurisation moderne. Son objectif est simple : permettre à une application de fonctionner de manière identique, quel que soit l'environnement dans lequel elle est exécutée.

Avant Docker, il était fréquent qu'une application fonctionne sur le poste d'un développeur mais rencontre des problèmes une fois déployée sur un serveur. Différences de versions système, dépendances manquantes, configurations incohérentes : ces écarts compliquaient fortement les déploiements.

Docker a largement réduit ce problème en encapsulant une application et ses dépendances dans un conteneur isolé. Concrètement, ce conteneur embarque l'application, ses bibliothèques, ses dépendances, et certains éléments système nécessaires à son exécution.

L'environnement devient alors portable et reproductible. Une image Docker peut être exécutée sur n'importe quelle machine compatible, avec un comportement prévisible. C'est cette standardisation qui explique l'adoption massive de Docker dans les pipelines CI/CD, les environnements de développement et les architectures modernes.

Docker ne sert pas uniquement à “faire tourner des conteneurs”

Dans beaucoup d'équipes, Docker est devenu un outil quotidien. Un développeur peut lancer localement une API Node.js, une base PostgreSQL, Redis ou encore un service Nginx, sans avoir à installer manuellement tous ces composants sur sa machine. Tout est isolé dans des conteneurs indépendants.

Cette approche simplifie énormément le développement local, les tests, les environnements de démonstration, les intégrations continues, et les déploiements applicatifs.

Pour des applications relativement simples, Docker peut suffire à lui seul. C'est notamment le cas lorsqu'une équipe exploite quelques services seulement, une infrastructure limitée, un faible besoin de montée en charge, ou peu d'automatisation d'exploitation. Dans ce contexte, ajouter Kubernetes peut même introduire une complexité inutile.

Là où Docker atteint ses limites

Docker fonctionne très bien pour exécuter des conteneurs. En revanche, il ne résout pas automatiquement les problématiques d'orchestration à grande échelle.

Lorsque le nombre de services augmente, plusieurs questions apparaissent rapidement :

• Comment répartir les conteneurs sur plusieurs serveurs ?
• Comment redémarrer automatiquement un service qui tombe ?
• Comment gérer les mises à jour sans interruption ?
• Comment absorber automatiquement un pic de trafic ?
• Comment superviser des dizaines ou centaines de workloads distribués ?

Docker n'a pas été conçu pour gérer seul ce niveau de complexité opérationnelle. C'est précisément le rôle de l’orchestration de conteneurs, dont Kubernetes est aujourd’hui le standard le plus utilisé.

Kubernetes : automatiser l’exploitation des conteneurs

Kubernetes est un orchestrateur de conteneurs. Son objectif n'est pas de remplacer Docker dans la création des images ou dans la logique de conteneurisation. Kubernetes intervient à un niveau supérieur : celui de l'exploitation et de l'automatisation de l'infrastructure.

Il permet notamment de déployer des applications automatiquement, répartir les workloads sur plusieurs machines, redémarrer des conteneurs en cas de panne, gérer la haute disponibilité, effectuer de l'auto-scaling, piloter des architectures distribuées.

Autrement dit, Docker exécute les conteneurs. Kubernetes organise leur fonctionnement global. Cette différence est essentielle.

Un exemple concret : Docker seul vs Kubernetes

Prenons une plateforme e-commerce moderne. Au départ, l'application peut être relativement simple : un backend, un frontend et une base de données. Docker suffit souvent à faire fonctionner cet ensemble.

Mais avec le temps, l'architecture évolue : plusieurs microservices apparaissent, certaines fonctionnalités doivent scaler indépendamment, des files de messages sont ajoutées, plusieurs environnements doivent être synchronisés, la disponibilité devient critique.

À ce stade, gérer manuellement tous les conteneurs devient rapidement difficile. Kubernetes apporte alors des mécanismes d'automatisation : redémarrage automatique des workloads, répartition des charges, duplication des services, déploiements progressifs, maintien automatique de l'état attendu du cluster.

C'est ce qui explique pourquoi Kubernetes est devenu le standard de facto de l'orchestration cloud-native.

Kubernetes vs Docker : lequel remplace l'autre ?

C'est l'une des questions les plus fréquentes, et la réponse est claire : Kubernetes ne remplace pas Docker.

Pendant longtemps, Kubernetes utilisait Docker comme runtime de conteneurs. Ce n'est plus le cas par défaut. À partir de la version 1.20 (décembre 2020), Kubernetes a déprécié le support direct de Docker via le composant "dockershim". Ce support a été définitivement supprimé dans la version 1.24, publiée en mai 2022. Depuis, Kubernetes s'appuie sur des runtimes compatibles avec l'interface CRI (Container Runtime Interface), comme containerd ou CRI-O.

Ce changement ne concerne pas les développeurs au quotidien. Les images créées avec Docker respectent le standard OCI (Open Container Initiative) et restent parfaitement utilisables sur Kubernetes. Autrement dit, le format d'image n'a pas changé : c'est la couche d'exécution interne au cluster qui a évolué.

En pratique, Docker et Kubernetes continuent de fonctionner ensemble dans de nombreux environnements. Docker sert à construire et tester les images localement. Kubernetes les déploie et les orchestre en production. La confusion vient souvent du fait que Docker était historiquement présent aux deux étapes. Ce n'est plus le cas côté runtime Kubernetes, mais Docker reste très utilisé côté build et développement.

La distinction Kubernetes vs Docker n'est donc pas une question de remplacement, mais de rôle : chacun intervient à une étape différente du cycle de vie d'une application conteneurisée.

Quand utiliser Docker sans Kubernetes ?

Docker seul reste pertinent dans beaucoup de situations. C'est souvent le bon choix pour un projet simple, une application interne, un environnement de développement, un prototype, une petite plateforme web, ou des besoins d'exploitation limités.

Dans ces cas, Kubernetes peut représenter une surcharge opérationnelle importante par rapport au besoin réel. Dans certains cas, une distribution allégée comme K3S peut également être plus adaptée qu’un cluster Kubernetes complet.

Kubernetes n'est pas automatiquement la meilleure réponse pour toutes les applications, c'est d'ailleurs une position explicitement assumée chez Clever Cloud, y compris dans le contexte du lancement de Clever Kubernetes Engine (CKE), un Kubernetes managé développé et opéré par Clever Cloud.

Quand Kubernetes devient réellement utile

Kubernetes devient intéressant lorsque l'architecture nécessite un niveau d'orchestration avancé. C'est notamment le cas lorsque plusieurs services doivent être coordonnés, que les déploiements deviennent fréquents, que la résilience devient critique, que les charges varient fortement, que les équipes utilisent déjà des pratiques GitOps, ou que l'infrastructure devient distribuée ou hybride.Certaines organisations utilisent également Kubernetes pour standardiser leurs déploiements entre plusieurs environnements ou plusieurs fournisseurs cloud. Dans ce contexte, le choix d'un Kubernetes managé devient souvent central pour limiter la dette opérationnelle.

C'est précisément ce type d'usage qui motive le développement de solutions comme CKE, conçu pour rester compatible avec les outils standards de l'écosystème Kubernetes tout en s'intégrant au reste de la plateforme.  

Kubernetes ou PaaS : ce n’est pas toujours un duel

Une autre confusion fréquente consiste à penser que Kubernetes remplace forcément un PaaS (Platform as a Service). Dans la pratique, beaucoup d'applications fonctionnent très bien sur un PaaS classique, avec moins d'exploitation et moins de complexité.

Même dans le cadre de CKE, le positionnement affiché est explicite : Kubernetes ne remplace pas le PaaS. Les deux répondent à des modèles opérationnels différents, pas à des niveaux de complexité différents : le PaaS prend en charge l'exploitation, Kubernetes en donne le contrôle. L'un comme l'autre font tourner des charges de production sérieuses. L'objectif n'est donc pas de mettre systématiquement toutes les applications sur Kubernetes, mais de l'utiliser lorsqu'il apporte une vraie valeur technique ou opérationnelle.

Docker vs Kubernetes : les différences à retenir

Docker et Kubernetes ne sont pas des technologies concurrentes

La question Kubernetes vs Docker n'est pas une question de choix : chacune répond à un besoin distinct à une étape différente du cycle de vie applicatif.

Docker a simplifié la création et l'exécution des applications conteneurisées. Kubernetes a automatisé leur exploitation à grande échelle.

Toutes les applications n'ont pas besoin de Kubernetes. Dans de nombreux cas, Docker seul suffit. Et pour déléguer entièrement l'exploitation, un PaaS prend le relais, y compris sur des architectures distribuées et des exigences de résilience élevées. Kubernetes, lui, devient pertinent lorsqu'on a besoin d'un contrôle explicite sur l'orchestration, d'une intégration avec l'écosystème CNCF ou d'une portabilité multi-cloud sur des standards ouverts. C'est un choix de modèle opérationnel et de besoins d'équipe, pas un niveau de complexité applicative.

L'enjeu n'est donc pas de choisir « Docker ou Kubernetes », mais de reconnaître à partir de quel besoin d'orchestration Kubernetes apporte une réelle valeur.

FAQ

Docker et Kubernetes sont-ils concurrents ?

Non. Docker et Kubernetes répondent à des besoins différents. Docker sert principalement à créer et exécuter des conteneurs, tandis que Kubernetes orchestre leur fonctionnement à grande échelle.

Kubernetes remplace-t-il Docker ?

Non. Depuis la version 1.24 de Kubernetes (mai 2022), Docker n'est plus utilisé comme runtime interne du cluster. Kubernetes s'appuie désormais sur des runtimes compatibles CRI comme containerd ou CRI-O. En revanche, les images Docker, conformes au standard OCI, restent pleinement compatibles avec Kubernetes.

Pourquoi Kubernetes est-il devenu un standard ?

Kubernetes s'est imposé grâce à son modèle déclaratif, sa portabilité entre environnements et l'écosystème cloud-native construit autour de la CNCF, dont il est un projet graduated depuis 2016, notamment avec des outils comme Helm, Prometheus ou ArgoCD.

Quelle différence entre K3S et Kubernetes classique ?

K3S est une distribution Kubernetes allégée, adaptée aux environnements edge, IoT, développement ou petits clusters, avec une consommation de ressources plus faible.

Un Kubernetes managé est-il préférable ?

Dans beaucoup d'organisations, oui. Un Kubernetes managé réduit la charge opérationnelle liée au control plane, aux mises à jour, à la sécurité et à la résilience des clusters. C'est l'approche retenue par Clever Kubernetes Engine.

Nous avons donc construit notre propre orchestrateur. Il repose sur des micro-VMs et nous donne une frontière kernel propre entre les workloads, sans partage de noyau entre tenants. C'est ce qui fait tourner aujourd'hui des dizaines de milliers d'applications en production sur notre PaaS, et c'est encore, pour la plupart des projets, le chemin le plus court entre un commit et de la production.

Quand Docker est arrivé, certains workloads se prêtaient mieux à une image conteneurisée qu'à nos runtimes natifs. Nous avons donc ajouté un runtime Docker à la plateforme, là où ça avait du sens. Pas pour remplacer notre approche, mais pour l'élargir.

Puis Kubernetes s'est imposé comme le standard de fait de l'orchestration de conteneurs. Son écosystème (Helm, opérateurs, GitOps…) est devenu incontournable pour de nombreuses équipes.

Nous aurions pu continuer à répondre que, dans beaucoup de cas, Kubernetes n'est pas le meilleur chemin vers la production. C'est toujours vrai.

Mais ça ne suffisait plus.

C'est pour ça que nous lançons CKE, notre Clever Kubernetes Engine, aujourd'hui disponible en bêta publique.

Comme beaucoup le savent, pendant des années, nous avons résisté à l'idée de proposer Kubernetes comme une case à cocher de plus dans la Console. Non pas parce que Kubernetes ne sert à rien, mais parce qu'il est trop souvent devenu une réponse par défaut à des problèmes que le PaaS résout plus simplement : déployer une application, la scaler, la superviser, l'isoler, lui connecter une base de données, gérer ses variables d'environnement, ses logs et son cycle de vie. Et nous le pensons toujours.

Mais Kubernetes est devenu le langage commun d'une grande partie de l'écosystème cloud-native. Helm, les opérateurs, GitOps, les workloads déjà conteneurisés, les plateformes internes et les chaînes d'outillage existantes font partie de la réalité quotidienne de nombreuses équipes. Et notre raison d'être est de faciliter la vie des équipes techniques.

La question n'était donc plus "faut-il faire du Kubernetes ?", mais "peut-on faire du Kubernetes sans renier ce qui fait Clever Cloud ?"

Pas un Kubernetes empaqueté à la va-vite

Le chemin le plus rapide pour proposer du Kubernetes managé, c'est d'empaqueter une distribution upstream derrière une console d’administration, d'ajouter une API de provisioning, et de facturer le cluster à l'heure.

C'est une stratégie valide pour sortir vite.

Ce n'est pas celle que nous voulions.

Pour CKE, nous avions trois exigences qui ne se résolvent pas en ajoutant simplement Kubernetes à côté du reste de la plateforme.

La première, c'est la souveraineté. CKE est opéré en Europe, sur notre infrastructure et celle de nos partenaires, et peut aussi être déployé sur les infrastructures on-premises de nos clients qui en ont besoin. Pas de dépendance aux hyperscalers américains, pas de zones grises sur la juridiction des données, pas de promesse floue sur la localisation réelle de l'infrastructure.

La deuxième, c'est l'intégration avec le reste de Clever Cloud. Nous ne voulions pas créer un silo Kubernetes à côté du PaaS, des bases de données managées, du stockage objet et du réseau privé. Nous voulions un Kubernetes qui s'inscrive dans la même plateforme, avec la même Console, le même outillage, la même facturation, les mêmes règles de gouvernance et les mêmes services managés.

La troisième, c'est la prévisibilité opérationnelle. Kubernetes est un système distribué complexe, et son comportement sous charge dépend beaucoup de ses fondations. Nous ne voulions pas opérer un produit dont la couche basse resterait une boîte noire ou une limite acceptée par défaut.

C'est ce qui nous a amenés à travailler à un endroit que peu de fournisseurs touchent : la couche de cohérence interne de Kubernetes.

Sous le capot : Materia etcd sur FoundationDB

Dans Kubernetes, etcd est le composant qui stocke l'état du cluster : les manifests, les ressources, les secrets, l'état des nœuds. C'est la source de vérité de tout l'orchestrateur.

C'est aussi l'un des composants les plus sensibles du système.

etcd fonctionne très bien dans le cadre pour lequel il a été conçu. Mais ses limites à grande échelle sont connues : taille du store, latences sous forte charge en écriture, comportement en cas de partition réseau, opérations de sauvegarde et restauration, besoin de compaction et de surveillance fine. Quand Kubernetes devient une fondation critique, etcd devient un sujet d'exploitation à part entière.

Nous ne voulions pas construire CKE sur une brique que nous considérerions ensuite comme une boîte noire fragile.

Nous avons donc repris le problème à sa racine : conserver le contrat attendu par Kubernetes, mais remplacer la couche de cohérence interne par une implémentation adossée à FoundationDB. C'est ce que nous appelons Materia etcd.

FoundationDB nous apporte des transactions ACID distribuées, un modèle de cohérence robuste, et une approche de testing par simulation déterministe qui correspond très bien à notre manière de construire de l'infrastructure critique.

Pour l'utilisateur final, ce travail est invisible. C'est précisément le but. Sous le capot, cette fondation nous permet de construire CKE avec l'auto-scaling, l'auto-healing et la prévisibilité opérationnelle que nous attendons d'un service Clever Cloud.

Nous reviendrons bientôt plus en détail sur Materia etcd, parce que le sujet mérite un article dédié.

Du Kubernetes standard côté développeur

Tout ce travail sur la couche basse a un objectif simple : côté utilisateur, CKE doit être du Kubernetes standard.

Vos manifests fonctionnent sans modification. Vos charts Helm s'installent normalement. Votre Argo CD ou votre Flux se branche comme sur n'importe quel cluster. Vos opérateurs Kubernetes tournent sans surprise.

CKE ne cherche pas à réinventer l'interface développeur de Kubernetes. Ce serait contre-productif. Si vous avez déjà une chaîne de déploiement Kubernetes, l'objectif est qu'elle puisse fonctionner sur CKE avec le moins de friction possible.

La différence se joue ailleurs : dans la manière dont ce Kubernetes s'intègre au reste de la plateforme Clever Cloud.

Kubernetes quand vous en avez besoin, le PaaS quand il suffit

CKE ne remplace pas notre PaaS. Il le complète.

Pour beaucoup d'applications, le PaaS reste le meilleur choix : moins d'exploitation, moins de configuration, moins de YAML, moins de surface de maintenance. Si votre application rentre naturellement dans un runtime Clever Cloud, le PaaS reste souvent le chemin le plus simple et le plus robuste.

Mais il y a des cas où Kubernetes est le bon outil.

Vous avez peut-être besoin :

• D'installer un opérateur ;
• De reprendre des manifests existants ;
• De standardiser une chaîne GitOps ;
• De déployer un workload déjà distribué sous forme de chart Helm ;
• De faire tourner une plateforme interne construite autour de l'API Kubernetes ;
• Ou simplement de répondre aux habitudes d'une équipe qui travaille déjà avec Kubernetes au quotidien.

Dans ces cas-là, le problème n'est pas Kubernetes en soi. Le problème, c'est Kubernetes isolé du reste de votre système.

C'est là que CKE change les choses. Vous pouvez garder une API Node.js sur le PaaS, un frontend statique sur Cellar, une base PostgreSQL managée, et faire tourner sur CKE uniquement le composant, l'opérateur ou le workload qui a réellement besoin de Kubernetes.

Le tout dans le même environnement Clever Cloud.

Une intégration native avec l'écosystème Clever Cloud

CKE a été conçu pour s'intégrer avec les services que vous utilisez déjà sur Clever Cloud.

• Cellar, notre stockage objet compatible S3, peut être utilisé depuis vos workloads Kubernetes.
• Les bases de données managées (PostgreSQL, MySQL, MongoDB, Redis, Materia) s'attachent à votre cluster comme aux autres applications Clever Cloud.
• IAM as a Service permet de gérer l'authentification et les permissions sur le cluster et sur les équipes qui y accèdent.
• Network Groups permet de relier votre cluster CKE à vos applications PaaS Clever Cloud existantes, dans le même réseau privé.

L’intégration avec Network Groups est probablement celle qui change le plus le quotidien.

Kubernetes est souvent introduit dans les organisations comme une nouvelle île : nouvelle console, nouveau réseau, nouveaux secrets, nouvelles règles d'accès, nouvelle facturation, nouvelle façon de connecter les services entre eux.

Avec CKE, l'objectif est inverse. Kubernetes devient une brique de plus dans l'architecture Clever Cloud, pas un monde parallèle.

Vous pouvez donc construire une architecture hybride sans bricolage : une partie sur le PaaS, une partie sur CKE, des bases de données managées, du stockage objet, du réseau privé, et une gouvernance commune.

Activer CKE et déployer une première application

Pour cette démo, on va rester sur le minimum vital : activer la fonctionnalité, créer un cluster, récupérer un kubeconfig, ajouter un node group et déployer une première application avec un service de type LoadBalancer.

Côté prérequis, il faut avoir Clever Tools en version 4.3 ou supérieure, et kubectl installé sur votre poste.

Depuis l'ouverture de la bêta publique le 27 avril, la fonctionnalité Kubernetes peut être activée par tous les clients Clever Cloud, en une commande :

clever features enable k8s

On peut alors créer un cluster. Donnez-lui un nom, précisez votre organisation, et l'option --watch permet de suivre l'avancement du déploiement :

clever k8s create my-cluster --org <your-org-id> --watch

La création prend environ une minute. À tout moment, on peut lister les clusters de l'organisation avec clever k8s list.

Une fois le cluster prêt, on récupère son kubeconfig et on l'écrit directement comme configuration locale par défaut :

clever k8s get-kubeconfig my-cluster --org <your-org-id> > ~/.kube/config

À partir de là, c'est du Kubernetes standard. kubectl parle au cluster, et tout votre outillage habituel suit. On peut commencer par vérifier que tout est en place :

kubectl get nodes

À ce stade, la liste est vide : le cluster est créé mais sans capacité de calcul. C'est l'occasion d'introduire la première spécificité de CKE côté API : le NodeGroup. Un node group est un ensemble de nœuds Kubernetes de même profil (même flavor, même région), gérés comme un tout. Vous le décrivez comme n'importe quelle ressource Kubernetes, dans un fichier YAML :

apiVersion: api.clever-cloud.com/v1
kind: NodeGroup
metadata:
  name: example-nodegroup
spec:
  flavor: M
  nodeCount: 2

Et vous l'appliquez avec kubectl :

kubectl create -f example-nodegroup.yaml

Soixante à quatre-vingt-dix secondes plus tard, les nœuds rejoignent le cluster :

kubectl get nodegroups
NAME                DESIREDNODECOUNT   CURRENTNODECOUNT   FLAVOR   STATUS   AGE
example-nodegroup   2                  2                  M        Synced   2m

kubectl get nodes
NAME                      STATUS   ROLES    AGE   VERSION
example-nodegroup-node0   Ready       2m    v1.35.0
example-nodegroup-node1   Ready       2m    v1.35.0

Pour ajuster la taille du node group, on reste dans l'API Kubernetes :

kubectl scale nodegroup example-nodegroup --replicas=4

Avec un cluster qui dispose maintenant de capacité de calcul, on peut déployer une première application. Pour faire simple, un nginx exposé via un service de type LoadBalancer, ce qui provisionnera automatiquement un load balancer côté Clever Cloud :

kubectl create deployment nginx --image=nginx:alpine --replicas=2 
kubectl expose deployment/nginx --type=LoadBalancer --port 80 
kubectl get service nginx

Quelques secondes plus tard, le service expose une adresse publique. C'est exactement le comportement réactif évoqué plus haut sur la phase de test privé : provisionner un node group, le scaler ou exposer un service ne demande ni attente ni configuration manuelle.

À partir d'ici, c'est du Kubernetes comme partout ailleurs. Vous pouvez ajouter du persistent storage via le CSI Clever Cloud, installer le Clever Kubernetes Operator pour provisionner depuis vos manifests une base de données managée, ou brancher votre chaîne GitOps habituelle. Le cluster supporte les versions Kubernetes 1.34, 1.35 et 1.36, avec 1.35 par défaut. Tout est détaillé dans la documentation CKE.

Ce qu'on a vu en test privé et à Devoxx, et la suite

CKE est désormais en bêta publique, mais certains de nos clients y ont accès en test privé depuis plusieurs mois. Cette phase a été très utile pour confronter le produit à des usages réels avant de l'ouvrir plus largement.

Les retours sont très positifs. Le cluster se comporte comme attendu, et les opérations qui touchent souvent au quotidien d'une équipe Kubernetes, comme l'ajout d'un nœud ou la mise en place d'un load balancer, sont rapides et prévisibles. C'est précisément le comportement que nous visions en investissant autant de temps sur la couche de cohérence interne.

À Devoxx France, nous avons présenté CKE sur le stand Clever Cloud pendant trois jours. Les discussions ont confirmé deux choses que nous observions déjà.

D'abord, les équipes ne cherchent pas seulement un cluster Kubernetes. Elles cherchent un Kubernetes qui s'intègre proprement à leur plateforme, à leur réseau, à leurs bases de données, à leurs contraintes de sécurité et à leurs pratiques existantes.

Ensuite, et c'est sans doute le retour le plus marquant, les développeurs ne cherchent pas à tout mettre sur Kubernetes. Beaucoup veulent garder leurs applications classiques sur notre PaaS, là où il est le plus efficace, et déployer sur Kubernetes uniquement les composants qui le méritent vraiment, par leur complexité, par leur architecture distribuée ou par les contraintes de l'écosystème dans lequel ils s'inscrivent.

C’est exactement le genre d’architecture hybride que CKE est conçu pour permettre.

C’est aussi pour ça que nous avions construit, en amont du lancement, le Clever Kubernetes Operator. Il permet à un workload qui tourne dans un cluster Kubernetes, qu’il soit hébergé chez nous ou ailleurs, de provisionner et de consommer nos services managés directement depuis l’API Kubernetes : PostgreSQL, MySQL, MongoDB, Redis, Cellar ou Materia.

Pour vos équipes, c’est du kubectl apply qui crée une base de données managée. Pour CKE, c’est l’outil naturel pour faire le pont entre les workloads Kubernetes et le reste de la plateforme Clever Cloud.

La bêta est ouverte à tous les clients Clever Cloud. Vous pouvez l'activer dès maintenant, déployer vos premiers workloads, et nous faire remonter ce qui vous manque, ce qui vous surprend ou ce que vous aimeriez voir arriver ensuite.

La discussion est ouverte sur notre communauté GitHub, et la documentation est disponible ici.

CKE ne remplace pas notre PaaS. Il le complète.

Pour beaucoup d'applications, le PaaS reste le chemin le plus simple entre un commit et de la production. Mais quand vous avez besoin de Kubernetes, pour un opérateur, un chart Helm, une chaîne GitOps, un workload déjà standardisé ou une plateforme interne, vous pouvez maintenant le faire dans l'environnement Clever Cloud, avec nos choix d'infrastructure, notre réseau, nos services managés et nos exigences de souveraineté.

C'est ce Kubernetes-là que nous voulions construire.

Nantes, France — Clever Cloud, fournisseur européen de solutions cloud, annonce l'ouverture en bêta publique de Clever Kubernetes Engine (CKE) le 27 avril 2026 dans l’après-midi. Le produit sera présenté en avant-première au Devoxx à partir du 22 avril, où les participants pourront le tester directement sur le stand Clever Cloud.

Conçu pour la production et la scalabilité

Kubernetes est devenu le standard de l'orchestration de conteneurs. Clever Cloud a travaillé pendant deux ans pour proposer une version managée et souveraine, conçue pour s'intégrer naturellement dans l'écosystème Clever Cloud et s'opérer avec la même simplicité que les autres services de la plateforme. CKE est pensé pour accompagner des charges de production réelles, avec une scalabilité élevée et un comportement prévisible à grande échelle.

Pour y parvenir, Clever Cloud a notamment développé Materia etcd, une réimplémentation de la couche de cohérence interne de Kubernetes construite sur FoundationDB. C'est ce travail de fond, invisible pour l'utilisateur final, qui garantit à CKE sa robustesse et sa stabilité en production, notamment grâce à de l’auto-scalabilité et de “l'auto-healingde façon native.

CKE s'intègre nativement aux services Clever Cloud existants — stockage objet Cellar (compatible S3), bases de données managées, IAM as a Service, Network Groups — et reste accessible via les outils standard du marché : kubectl, Helm ou GitOps.

Souverain par conception

Hébergé et opéré en Europe par Clever Cloud sur son cloud public, CKE offre aux organisations une alternative concrète aux offres Kubernetes des grandes plateformes américaines, sans compromis sur les performances ni sur la maîtrise juridique des données. CKE peut aussi être déployé sur les infrastructures on-premises du client. 

Modalités d'accès

La bêta publique est ouverte à tous les clients de Clever Cloud à partir du 27 avril 2026, via l'activation de fonctionnalités à réaliser par l’utilisateur. À noter : certains clients bénéficient d'un accès en test privé depuis plus de six mois déjà, ce qui a permis d'affiner le produit avant cette ouverture générale.

"Clever Cloud a longtemps développé des alternatives à Kubernetes. Nos clients nous ont exprimé un besoin clair pour cette technologie, et nous avons décidé de la construire à leurs côtés, avec le niveau d'exigence technique et de souveraineté qui définit notre plateforme." Quentin Adam, CEO de Clever Cloud

En savoir plus

La BSL n'est pas une licence open source au sens de l'Open Source Initiative : elle restreint les usages commerciaux jugés concurrents des offres HashiCorp. Du jour au lendemain, des milliers d'organisations qui avaient structuré leur infrastructure autour de Terraform se sont retrouvées dans une zone d'incertitude juridique inconfortable.

La réponse n'a pas tardé. Moins d'un mois après l'annonce, un manifeste réclamant le retour à une licence open source avait réuni 33 000 étoiles sur GitHub et le soutien de près de 140 entreprises. HashiCorp n'a pas bougé. Le fork a été publié en septembre 2023, intégré à la Linux Foundation, et renommé OpenTofu. Depuis janvier 2024, il est en production stable. Depuis avril 2025, il fait partie du Cloud Native Computing Foundation (CNCF).

Notre provider Terraform est entièrement compatible avec OpenTofu. Aucune modification de vos configurations n'est nécessaire pour l'utiliser.

Qu'est-ce qu'OpenTofu ?

OpenTofu est un outil d'infrastructure as code (IaC) open source, fork du dernier Terraform sous licence MPL 2.0 (version 1.5.x), distribué sous cette même licence Mozilla Public License 2.0. Il permet de décrire, provisionner et gérer des infrastructures cloud via des fichiers de configuration déclaratifs écrits en Hashicorp Configuration Language.

Il est développé sous la gouvernance de la Linux Foundation, avec un Technical Steering Committee composé de représentants de plusieurs organisations — Gruntwork, Spacelift, Harness, Env0, Scalr — afin qu'aucune entreprise ne puisse en contrôler seule la direction. C'est précisément ce modèle de gouvernance qui a convaincu beaucoup d'équipes de franchir le pas : la garantie que l'outil restera vraiment open source, quelle que soit l'évolution commerciale de ses contributeurs.

En pratique, OpenTofu fonctionne avec les mêmes fichiers .tf, les mêmes providers, les mêmes modules et le même workflow CLI que Terraform — init, plan, apply, destroy. Pour la grande majorité des équipes, migrer se résume à remplacer le binaire.

Quelle différence concrète avec Terraform ?

La différence principale est la licence, et tout ce qu'elle implique sur le long terme.

Terraform est aujourd'hui distribué sous BSL, qui restreint les usages commerciaux pouvant être considérés comme concurrents de HashiCorp — une notion délibérément floue, et que HashiCorp (désormais filiale d'IBM) peut interpréter différemment à l'avenir. OpenTofu est distribué sous MPL 2.0, une vraie licence open source sans restriction commerciale.

Au-delà de la licence, les deux projets ont commencé à diverger techniquement depuis le fork. Les différences les plus notables à ce jour :

• Chiffrement du state : OpenTofu supporte nativement le chiffrement côté client des fichiers d'état, une fonctionnalité longtemps réclamée par la communauté et que Terraform n'a toujours pas implémentée.
• Gouvernance : OpenTofu est piloté par un comité technique multi-organisations au sein de la Linux Foundation. Terraform est sous contrôle d'IBM via HashiCorp, avec une feuille de route dictée par des priorités commerciales.
• Compatibilité : OpenTofu maintient la compatibilité syntaxique et fonctionnelle avec Terraform. Providers, modules et configurations existants fonctionnent sans modification pour la quasi-totalité des cas d'usage.
• Extension .tofu : OpenTofu supporte cette extension en complément de .tf, ce qui permet aux auteurs de modules de fournir des variantes spécifiques à OpenTofu tout en restant compatibles avec Terraform.
• Actions Terraform : HashiCorp a récemment introduit les "actions" dans Terraform, une fonctionnalité permettant de déclencher des comportements personnalisés lors du cycle de vie des ressources. OpenTofu ne la supporte pas encore — c'est le revers inhérent à tout fork : les nouvelles fonctionnalités propriétaires de Terraform ne sont pas automatiquement disponibles, et leur implémentation dans OpenTofu dépend des priorités du comité technique.

Pourquoi des équipes migrent vers OpenTofu

Trois raisons reviennent systématiquement.

Le risque juridique. La BSL interdit l'usage de Terraform dans des produits pouvant entrer en concurrence avec les offres HashiCorp. Pour les équipes qui construisent des plateformes internes, des produits cloud ou des services managés, cette incertitude est un risque opérationnel réel — d'autant que la définition de "compétitif" appartient à HashiCorp, et peut évoluer. À cela s'ajoute une réalité moins visible mais tout aussi structurante : dans le registry Terraform, les providers open source ne bénéficient d'aucune mise en avant particulière. Obtenir un badge "officiel" nécessite de négocier directement avec HashiCorp — et de payer. Dans le registry OpenTofu, tous les providers sont traités à égalité, quelle que soit la taille ou les moyens de leurs mainteneurs.

L'autonomie stratégique sur l'outillage. Votre infrastructure as code est le socle de tout le reste. En dépendre d'un outil contrôlé par une entreprise américaine soumise au Cloud Act, c'est introduire une dépendance supplémentaire que beaucoup d'organisations préfèrent éviter. OpenTofu, sous gouvernance Linux Foundation / CNCF, offre une continuité indépendante de tout acteur commercial.

Les fonctionnalités que Terraform ne livre pas. Le chiffrement natif des fichiers d'état est l'exemple le plus cité : réclamé pendant des années, implémenté en quelques mois par OpenTofu. C'est aussi un signal sur la vitesse à laquelle une gouvernance communautaire peut répondre à des besoins réels, par rapport à une roadmap pilotée par des intérêts commerciaux.

Migrer de Terraform vers OpenTofu

Pour la grande majorité des équipes, la migration est une opération de quelques minutes. Il suffit de s'assurer que le state est propre, d'installer OpenTofu, et de remplacer terraform par tofu dans ses commandes.

OpenTofu sur Clever Cloud : rien à changer

Notre provider officiel (CleverCloud/clevercloud, actuellement en version 1.10) fonctionne de façon identique avec Terraform et OpenTofu. La source du provider, la syntaxe HCL et l'ensemble des ressources disponibles sont exactement les mêmes. Un exemple minimal pour déployer une application Node.js avec sa base PostgreSQL :

terraform {

  required_providers {

    clevercloud = {

      source  = "CleverCloud/clevercloud"

      version = "~> 1.10"

    }

  }

}

provider "clevercloud" {organisation}

resource "clevercloud_node" "app" {

  name       = "mon-app-node"

  region     = "par"

  min_flavor = "XS"

  max_flavor = "M"

}

resource "clevercloud_postgresql" "db" {

  name   = "ma-base-postgres"

  region = "par"

  plan   = "dev"

}

tofu init

tofu plan

tofu apply

La combinaison OpenTofu + Clever Cloud constitue une stack IaC entièrement souveraine : outillage open source sous gouvernance Linux Foundation / CNCF, infrastructure hébergée dans nos propres datacenters en France, hors de portée du Cloud Act américain. C'est le choix que font de plus en plus d'équipes qui veulent garder la main sur l'ensemble de leur chaîne d'outillage, pas seulement sur leurs données.

Le provider Clever Cloud est disponible sur le Terraform Registry et entièrement open source sur GitHub.

FAQ

OpenTofu est-il compatible avec mes configurations Terraform existantes ?

Pour la quasi-totalité des cas d'usage, oui. OpenTofu maintient la compatibilité syntaxique et fonctionnelle avec Terraform. Fichiers .tf, providers et modules existants fonctionnent sans modification. Il est recommandé de tester dans un environnement non-production avant de basculer des workloads critiques.

OpenTofu est-il prêt pour la production ?

Oui. La première version stable d'OpenTofu a été publiée en janvier 2024. Le projet a depuis dépassé 10 millions de téléchargements et est utilisé en production par des organisations de toutes tailles, y compris des entreprises du Fortune 500. Son intégration au CNCF en avril 2025 a renforcé sa crédibilité pour les environnements enterprise.

Quelle est l'alternative open source à Terraform ?

OpenTofu est la principale alternative open source à Terraform. Distribué sous MPL 2.0, maintenu par la Linux Foundation et membre du CNCF, il est la continuité directe de Terraform dans son état open source d'origine.

Le provider Terraform Clever Cloud est-il compatible avec OpenTofu ?

Oui, sans aucune modification de configuration. Notre provider officiel (CleverCloud/clevercloud) fonctionne identiquement avec Terraform et OpenTofu.

Comment fonctionne OpenTofu ?

De façon identique à Terraform : vous décrivez l'état cible de votre infrastructure en HCL, OpenTofu calcule les changements nécessaires (tofu plan) et les applique (tofu apply). Il gère les dépendances entre ressources, le state et le cycle de vie complet de chaque ressource. C'est aussi là que le rachat de HashiCorp par IBM introduit une incertitude supplémentaire : certains projets gravitant autour de Terraform, comme CDK for Terraform, pourraient être déprioritisés ou abandonnés en fonction des arbitrages commerciaux d'IBM. Avec OpenTofu, la feuille de route est publique, discutée en RFC ouverte, et ne dépend d'aucune décision prise en coulisses par un acteur unique.

Cette transformation s’inscrit toutefois dans un cadre de réduction des coûts, de rationalisation des infrastructures existantes et de mutualisation des ressources informatiques.

Dans ce contexte contraint, la question n’est pas uniquement de savoir quel fournisseur ou quelle technologie adopter, mais quel modèle d’exécution applicative est le plus adapté au projet concerné. Le PaaS (platform as a service) fait partie des options possibles, à condition d’en comprendre précisément les apports, les limites et les cadres dans lesquels il peut être mobilisé.

Les enjeux et problématiques spécifiques des services publics

Les organisations publiques font face à des contraintes structurelles qui influencent directement leurs choix techniques. La pression budgétaire est permanente, avec des objectifs explicites de maîtrise, voire de réduction, des coûts d’exploitation IT. Les équipes techniques sont souvent limitées en effectif, avec des difficultés de recrutement sur certains profils spécialisés, tels que les administrateurs systèmes, les développeurs, les experts cybersécurité ou les ingénieurs cloud et DevOps.

À cela s’ajoute un patrimoine applicatif hétérogène, parfois ancien, reposant sur des technologies ou des environnements qui ne sont plus maintenus ou difficilement évolutifs. Les exigences en matière de sécurité, de disponibilité et de conformité réglementaire sont élevées, tandis que les délais de mise en œuvre des projets numériques doivent rester compatibles avec les besoins opérationnels des administrations, collectivités ou établissements publics.

En quoi le PaaS peut répondre à ces enjeux dans le secteur public

Le recours à une plateforme cloud peut répondre à une partie de ces problématiques, sans pour autant constituer une solution universelle. L’un de ses apports majeurs réside dans la réduction de la charge opérationnelle. Concrètement, cela signifie que l’exploitation des systèmes d’exploitation, la gestion des runtimes applicatifs, les mécanismes de déploiement, de redémarrage ou de supervision sont pris en charge au niveau de la plateforme. Les équipes techniques n’ont plus à administrer l’infrastructure sous-jacente au quotidien et peuvent se concentrer sur le développement, l’évolution et la qualité des applications.

Sur le plan de la sécurité et des mises à jour, une solution d’hébergement applicatif permet également de maintenir des environnements techniques à jour de manière plus systématique. Dans le secteur public, où la gestion du legacy est un enjeu central, cela contribue à limiter les risques liés à l’obsolescence des systèmes, aux dépendances non maintenues ou aux correctifs de sécurité appliqués tardivement. Cette solution ne supprime pas le legacy existant, mais il peut en encadrer l’exploitation et faciliter une modernisation progressive, sans refonte immédiate de l’ensemble du système d’information.

C’est dans ce cadre qu’un PaaS pour les services publics peut constituer un levier pertinent, à condition d’être choisi pour des usages clairement identifiés.

Tous les projets publics ne relèvent pas du même cadre de déploiement

Les projets numériques portés par les services publics couvrent des réalités très différentes. Une application métier interne, un service numérique à destination des citoyens, une plateforme de données ou un projet de recherche n’impliquent pas les mêmes contraintes ni les mêmes niveaux d’exigence.

Certains contextes, notamment ceux liés à la défense ou au traitement d’informations sensibles, requièrent des garanties renforcées en matière de sécurité, de contrôle et de souveraineté. Dans ces cas, des démarches de qualification spécifiques, comme SecNumCloud, peuvent être nécessaires et limiter les options techniques envisageables. Le PaaS n’est donc pas adapté à tous les périmètres, et son usage doit être évalué au regard de la sensibilité des données et des obligations réglementaires applicables.

Les cadres publics existants pour déployer un PaaS

Contrairement à une idée reçue, les acteurs publics disposent déjà de cadres opérationnels pour accéder à des services cloud et solution d’hébergement applicatif conformes.

Pour les administrations et établissements publics, le recours à l’UGAP permet de s’appuyer sur une centrale d’achat nationale, avec des contrats mutualisés et juridiquement sécurisés.

À l’échelle régionale, des dispositifs comme La Fabrique IA Territoriale portée par GIGALIS, offrent aux collectivités et institutions locales des Pays de la Loire un cadre structuré pour accéder à des services numériques et cloud, dans une logique de mutualisation et d’accompagnement.

Dans le secteur de la santé, les établissements hospitaliers peuvent quant à eux s’appuyer sur Resah, qui référence des solutions adaptées aux exigences spécifiques du domaine sanitaire.

Ces cadres ne définissent pas les usages techniques, mais constituent des points d’accès concrets à des services conformes au droit de la commande publique.

Dans quels cas le PaaS est particulièrement pertinent

Le modèle cloud managé se révèle particulièrement adapté dans des situations où l’objectif est de créer une nouvelle application sans volonté d’assurer de l’administration système. Il est également pertinent pour la modernisation ou la refonte d’applications existantes, lorsque l’enjeu principal est de simplifier l’exploitation tout en améliorant la fiabilité et la sécurité.

Pour des projets applicatifs nécessitant des cycles de déploiement rapides, une meilleure prévisibilité des coûts d’exploitation et une réduction du temps consacré aux tâches d’administration, une offre cloud pour les acteurs publics peut représenter un choix cohérent, dès lors que le périmètre fonctionnel et réglementaire est clairement défini.

Points de vigilance avant de faire ce choix

Avant d’opter pour un PaaS, il reste indispensable d’évaluer plusieurs éléments : le périmètre réel de responsabilité de la plateforme, les conditions de réversibilité, la localisation et la protection des données, ainsi que l’adéquation entre le niveau de sensibilité des informations traitées et les garanties proposées. Ces points conditionnent la pertinence du modèle et sa soutenabilité dans le temps.

Vous travaillez sur un projet applicatif au sein d’un service public et vous vous interrogez sur la pertinence d’un modèle PaaS dans votre contexte ?

Identifier le bon cadre contractuel permet de gagner du temps et de garantir la conformité de vos projets numériques publics.

Ou retrouvez directement Clever Cloud via les plateformes publiques UGAP, pour les administrations et établissements publics, la Fabrique IA Territoriale pour les acteurs des Pays de la Loire, et Resah pour les établissements de santé.

En parallèle, dans sa synthèse parue en début d’année, l’organisme de cybersécurité CERT-FR, porté par l’Agence nationale de la sécurité des systèmes d’information (ANSSI), indique que 218 incidents cyber ont été traités en 2024 pour les collectivités territoriales. Aussi, dans son rapport d'activité de 2024, l’ANSSI qualifie la menace de “systémique” pour le tissu public et social.

Dans ce contexte, choisir une solution cloud sécurisée pour les administrations publiques est devenu un enjeu central pour les DSI, les RSSI et les responsables de projets numériques.

L’objectif n’est pas simplement de trouver une infrastructure performante, mais de s’assurer que le cloud choisi respecte à la fois les exigences juridiques, réglementaires, techniques et opérationnelles propres au secteur public.

Comprendre ce qu’implique la sécurité cloud dans le secteur public

Les données manipulées par les administrations (informations personnelles, données de santé, données financières, informations sensibles liées aux infrastructures publiques) sont strictement encadrées par la CNIL et le RGPD. À cela s’ajoutent les certifications de sécurité attendues dans le secteur public : ISO/IEC 27001, HDS pour les données de santé, voire SecNumCloud pour les environnements les plus critiques.

Ces exigences montrent qu’un cloud sécurisé ne se limite pas à un pare-feu ou à du chiffrement. Il implique une approche complète, encadrée et auditée.

La souveraineté numérique, un critère devenu incontournable

Pour une administration publique, il est indispensable de savoir où sont hébergées les données et sous quelle juridiction elles se trouvent, afin de respecter le RGPD et d’encadrer correctement les éventuels transferts hors de l’Union Européenne.

Un cloud souverain implique non seulement une localisation des données en Union Européenne, mais aussi une absence d’exposition à des lois extraterritoriales comme le Cloud Act américain (2018), qui permet à un gouvernement étranger d’exiger l’accès à des données stockées chez un fournisseur soumis à sa juridiction.

La souveraineté participe également à la résilience des systèmes d’information. En limitant les dépendances techniques, contractuelles ou juridiques à un fournisseur unique, une administration conserve la capacité de réagir rapidement en cas de contrainte, par exemple s’il faut changer de prestataire ou relocaliser un service lorsque le contexte réglementaire, opérationnel ou stratégique l’impose. Cette marge de manœuvre constitue un facteur important de maîtrise et de pérennité des services numériques publics.

Le critère de souveraineté constitue donc un point différenciant majeur lorsqu’il s’agit de choisir entre un fournisseur européen et un fournisseur américain.

Au-delà de la conformité : les exigences techniques essentielles

Pour garantir un niveau de sécurité adapté au secteur public, une solution cloud doit offrir une isolation forte entre les environnements, un chiffrement systématique des données en transit et au repos, un durcissement des hôtes, ainsi que des mécanismes de supervision continus (logs, métriques, alertes).

La gestion des identités (IAM), l’authentification multifacteur et l’application du principe du moindre privilège s’inscrivent dans une logique Zero Trust, désormais recommandée par l’ANSSI pour réduire la surface d’attaque.

La sécurité repose également sur la résistance opérationnelle : continuité de service, capacité de récupération, haute disponibilité, et architecture tolérante aux pannes.

La place de l’automatisation dans la réduction du risque

L’automatisation est souvent perçue comme un confort pour les développeurs ; dans le secteur public, c’est surtout un levier de réduction du risque humain.

Les déploiements automatisés, la scalabilité automatique ou encore l’autoréparation (self-healing) permettent de limiter les erreurs opérationnelles, qui représentent une part importante des incidents de sécurité.

En réduisant le nombre d’opérations manuelles, on diminue les risques de mauvaise configuration et on améliore la disponibilité globale du service.

La question du coût total et de la gouvernance

Choisir un cloud sécurisé ne revient pas uniquement à comparer des prix catalogue.

Le secteur public doit intégrer la notion de coût total de possession (TCO) :

• Coût de l’infrastructure,
• Coûts humains internes,
• Complexité des opérations,
• Maintenance,
• Temps passé à gérer les incidents,
• Effort nécessaire pour migrer un service ou en assurer la réversibilité.

Une plateforme qui automatise la majorité des opérations et rend les environnements reproductibles peut réduire significativement la charge interne, et donc le coût global.

Comment évaluer objectivement les solutions du marché ?

Pour évaluer une solution cloud destinée au secteur public, il est essentiel de s’appuyer sur des critères factuels : le niveau de souveraineté, les certifications, les capacités techniques, la réversibilité, la disponibilité d’options cloud privé ou on-premise, l’existence d’environnements air-gap, la qualité du support et la compatibilité avec les outils existants.

Les erreurs les plus fréquentes consistent à choisir un acteur par habitude, à se baser uniquement sur le prix, ou à confondre souveraineté de localisation et souveraineté juridique.

Une autre erreur récurrente consiste à surestimer la difficulté d’une migration : un test ou un Proof of Concept est souvent suffisant pour valider la faisabilité.

Une méthode simple pour choisir la bonne solution cloud

La démarche la plus efficace consiste à :

Cette méthode offre une vision équilibrée entre sécurité, conformité, performance et durabilité.

Ce que Clever Cloud apporte sur ces sujets

Clever Cloud est un hébergeur européen certifié ISO/IEC 27001:2022 et HDS, proposant des environnements cloud publics, privés, on-premise et air-gap. Pour les besoins ultra-réglementés, une zone déjà qualifiée SecNumCloud est disponible sur demande via notre partenariat avec Cloud Temple. Cela permet de répondre aux exigences du “cloud de confiance” tout en bénéficiant de la plateforme Clever Cloud.

La plateforme suit une approche de sécurité basée sur l’isolation, le durcissement, l’authentification forte et l’observabilité intégrée.

Les déploiements automatisés, la montée en charge automatique (auto-scaling) et les mécanismes de self-healing réduisent l’effort opérationnel et limitent les erreurs humaines.

Les données restent en Europe et leur portabilité est garantie, sans dépendance propriétaire.

Le support est humain et assuré depuis la France.

Enfin, il est à noter que pour les organismes publics qui passent par les marchés mutualisés, Clever Cloud est également référencé sur le marché Nuage Public (UGAP). Les administrations peuvent ainsi souscrire nos services dans un cadre d’achat public déjà validé, ce qui simplifie les démarches administratives et accélère la mise en service.

Vers un cloud public sécurisé, souverain et durable

Pour une administration, choisir un cloud sécurisé revient à trouver un équilibre entre souveraineté, conformité, sécurité technique, productivité et maîtrise des coûts.

En s’appuyant sur des critères clairs et sur les référentiels officiels (ANSSI, ISO, RGPD, HDS), il devient possible de sélectionner une solution réellement adaptée aux besoins du secteur public, capable d’assurer à la fois la continuité de service et la protection des données des citoyens.

Vous souhaitez évaluer une plateforme cloud souveraine et automatisée ?

Contactez-nous

De manière assez paradoxale, le plus grand changement de ces derniers mois et aussi le moins visible depuis l'extérieur : le renforcement de notre approche "Clever Cloud Everywhere".

Une plateforme de cloud ouverte qui s'adapte partout, à vos besoins

Car nous sommes plus qu'un fournisseur de services PaaS avec ses propres infrastructures, nous proposons à nos clients de déployer leurs applications et services chez nos partenaires (Cloud Temple, Ionos, OVHcloud, Scaleway, etc.), ou même sur leurs serveurs, pour des besoins qui vont d'offres edge (machines locales) à de l'air gap (déconnecté d'Internet).

Ainsi, ce n'est pas à vous de vous adapter aux contraintes de notre cloud, c'est l'inverse. En 2025, un nombre croissant de clients est venu nous demander des adaptations à leurs besoins de manière fine, ce que nous faisons avec plaisir. Ainsi, si vous voulez votre propre Clever Cloud, c'est possible : nous pouvons fournir le matériel de partenaires ou nous installer sur ceux déjà à votre disposition. C'est comme cela que nous nous déployons hors de Paris.

D'ailleurs, après l'ouverture d'une zone à Londres et des partenariats en Afrique de l'Ouest et au Kazakhstan, nous avons récemment annoncé notre filiale marocaine. Cela ne nous empêche pas de continuer à renforcer notre ancrage local, que ce soit à travers notre intégration à la Fabrique IA Territoriale en Pays de la Loire, notre soutien aux startups via le programme UP ou notre partenariat avec l'acteur allemand SpiNNcloud pour une plateforme européenne de calcul pour l’IA.

Kubernetes chez Clever Cloud

L'autre grande étape franchie par nos équipes est le lancement de Clever Kubernetes Engine (CKE), notre offre Kubernetes managée. Elle est pour l'instant proposée à un nombre restreint de clients qui la consomment activement, utilisable depuis notre API, les Clever Tools et la Console. Elle sera ouverte plus globalement d'ici quelques semaines.

Deux nouveaux points de présence à Paris

Une extension de nos services accompagnée par une extension de notre infrastructure, puisque nous passons de 3 à 5 datacenters où nous sommes présents à Paris. Nous commençons en effet notre installation à Vélizy chez notre partenaire Etix tout en renforçant notre partenariat avec TeleHouse en nous installant à TH3 (Magny).

Cela nous permettra de répondre aux besoins croissant de nos clients tout en nous préparant à la mise en place de nouveaux services, tels que notre offre d'Infrastructure-as-a-Service (IaaS) dont vous devriez entendre parler dans le courant de l'année prochaine.

Êtes-vous certifiés Clever Cloud ?

2025 aura également été l'année du lancement de notre première certification, très demandée par de nombreux clients et partenaires. Une première étape qui s'est accompagnée du renforcement continu de notre équipe commerciale ces derniers mois.

Une seconde formation, pour niveau intermédiaire arrive très bientôt. De quoi mieux vous accompagner au quotidien et prendre le temps de répondre à vos besoins, tout en multipliant les ateliers, formations, en présentiel, via des webinaires et autres streams sur Twitch et YouTube. Prochaine étape : les ambassadeurs Clever Cloud !

Une amélioration continue de notre offre

Bien entendu, nous avons également continué à améliorer notre solution historique de PaaS en déployant chaque semaine de nouvelles images et fonctionnalités, avec une meilleure réactivité d'intégration. Par exemple, de Node.js 24 ou de Java 25, l'amélioration du support de pnpm et Yarn en complément de Bun. .NET 10 et PHP 8.5 sont les prochains sur la liste.

Nous réduisons peu à peu les délais sur d'autres services sur les bases de données. Ainsi, PostgreSQL 18 est d'ores et déjà disponible. Redis 8.4 et Elasticsearch 9 arrivent.

Nous avons continué de renforcer les services managés que nous proposons à l'ensemble de nos clients comme Keycloak, Matomo, Metabase ou Otoroshi. Tous sont disponibles dans leur version la plus récente, avec désormais la possibilité de gérer vos mises à jour à la création et depuis le dashboard de la Console, mais aussi d'activer des fonctionnalités avancées.

Ainsi, nous avons introduit il y a quelques mois le Secure Multi Instances au sein de Keycloak, qui exploite nos Network Groups. On peut également les mettre en place d'un clic au sein de l'API Gateway Otoroshi pour y relier différentes applications. Cette dernière gère d'ailleurs désormais le chargement de plugins tiers et la configuration des domaines à la création.

D'autres services continuent leur évolution. Ainsi Materia KV est désormais accessible en bêta et va continuer de s'améliorer avant une disponibilité générale attendue pour le début de l'année prochaine. Cette étape sera d'ailleurs franchie sous peu par notre solution de messagerie Apache Pulsar, dont les tarifs évolueront à cette occasion.

Notre offre devient progressivement disponible au sein d'un outil que nous avons considérablement renforcé cette année afin d'accompagner les besoins de certains de nos clients: notre provider Terraform. Passé en 1.0 cet été, il est désormais disponible dans sa version 1.7.1 et offre de très nombreuses possibilités. N'hésitez pas à l'utiliser et à nous faire vos remarques et suggestions.

Clever Tools et Console évoluent, la révolution en 2026

Les Clever Tools peuvent désormais être lancés via npx, gèrent les nouveaux drains, et ont gagné de nombreuses fonctionnalité au fil des mois. Nous avons commencé une refonte en profondeur avec la version 4.0 publiée en septembre dernier. Et cela va continuer en 2026.

Dans la Console, nous avons récemment mis en place notre nouvelle interface de logs pour les access logs. Suivront les logs d'add-ons. Nous allons progressivement étendre les nouveaux dashboards à l'ensemble de nos services, puis intégrer les Network Groups et mettre en place une interface de gestion native de notre stockage objet : Cellar.

Mais nous avons surtout entamé le travail de refonte de la Console, qui s'accompagnera de nouvelles API afin de moderniser encore un peu plus notre plateforme et les services qu'elle propose avec toujours la même obsession : simplifier la vie des développeurs.

Là aussi, rien ne serait possible sans un travail de fond, peu visible, mené au fil de l'année : la refonte de notre client JavaScript. Plus simple à prendre en main, plus complet, Type-safe, gérant les API Tokens, il sera à l'origine de plusieurs initiatives dont nous reparlerons sous peu.

Envie d'en savoir plus ? Suivez l'ACCES !

Vous l'aurez compris, 2025 a été une année pleine de nouveautés et de chamboulement pour Clever Cloud et son équipe. Et 2026 sera sur la même tendance. Pour vous en convaincre, n'hésitez pas à venir nous rencontrer à l'occasion de notre Amazing Clever Cloud Enterprise Summit (ACCES) qui se tiendra jeudi 11 décembre 2025, pendant le FOST (ex-apidays) qui se déroulera du 9 au 11 décembre. Nous y tenons un pavillon avec plusieurs de nos clients et partenaire afin de présenter ce que nous vous préparons pour les mois à venir, de Clever AI à Materia TS en passant par notre KMS.

Il a été conçu pour gérer de l'infrastructure, et en ce sens, il vient avec de la complexité et donc des coûts cachés. Or, chez Clever Cloud notre boussole est d’améliorer la productivité, la sécurité et l’autonomie des développeurs.

Depuis, le contexte a changé. Le marché évolue, nos clients également. Nous avons désormais la maturité technologique pour répondre à un tel besoin… à notre manière. Voici pourquoi nous avons pris le temps de créer notre propre version d'ETCD, et pourquoi Kubernetes arrive enfin chez Clever Cloud

Pourquoi nous n’avons pas sauté sur Kubernetes plus tôt

Historiquement, nous n’avons jamais vu Kubernetes comme un levier de simplification. Il est parfois vécu comme une complexité supplémentaire, surtout pour des équipes qui veulent juste déployer, passer à l’échelle et sécuriser leurs applications : se focaliser sur la création de valeur sans consacrer trop de temps sur le reste. 

Or le passage à l'échelle engendre souvent des machines à gaz. Nous sommes hébergeurs, autant vous dire que c'est une sacrée échelle qu'il nous faut. Notre orchestrateur développé et enrichi de 15 ans d’ expériences en production permet cela. Via une exécution directe des runtimes (une quinzaine, dont Node.JS, PHP, Rust, Scala, Docker etc), notre orchestration va plus loin dans la finesse du provisionnement et du scaling automatique, la pertinence des mises à jour et la sécurité.

Pour nous, la containerisation n’est pas une fin en soi. Si un runtime existe, nous préférons en simplifier l’usage, le supporter nativement. Cela permet de contrôler les mises à jour de sécurité de l’image de base, sans dépendre du bon vouloir de l’équipe applicative. Pour tout code qui ne correspond pas à un runtime existant, nous proposons naturellement le déploiement dans une image Docker. Cependant, il faut avoir à l’esprit que cette image, nous pouvons la mettre à jour, mais naturellement, nous ne pouvons pas patcher ou mettre à jour le code encapsulé.

Néanmoins, au fil de notre croissance nous rencontrons des prospects de plus en plus gros et utilisateurs de Kubernetes. Le marché demande Kubernetes. De plus en plus de clients veulent une interopérabilité avec leurs outils habituels, une gestion fine de leurs workloads, ou simplement un standard pour leurs équipes. Nous ne pouvions pas l’ignorer.

Le maillon faible de Kubernetes : ETCD

Kubernetes est souvent qualifié de « système d’exploitation du cloud ». Mais comme tout OS, il repose sur un élément données critique : ETCD, une base de données clé-valeur distribuée censée stocker l’état global du cluster. Et là, les ennuis commencent.

ETCD ne tient pas la charge. Son architecture, pensée pour des cas modestes, impose une limite technique dure à 8 Go. Les performances chutent dès qu’on passe à l’échelle, la documentation est lacunaire, et la gouvernance du projet a été fragilisée par des changements successifs de mainteneurs.

Et ce n'est pas pour rien que Google, Microsoft et autres hyperscalers ont réécrit leur version d'ETCD, comme pour le projet k3s qui utilise une base de données PostgreSQL. Quand chaque client possède son propre cluster Kubernetes, cela signifie potentiellement des milliers d’instances ETCD à gérer, chacune avec ses subtilités, ses backups, ses performances variables. C'est un cauchemar opérationnel quand notre métier est le maintien en conditions opérationnelles.

Repenser ETCD à la racine : notre stack maison

Nous avons donc fait ce que Clever Cloud sait faire de mieux : repenser intelligemment. En nous appuyant sur Materia KV, notre base de données serverless clé-valeur, bâtie sur FoundationDB, nous avons réimplémenté ETCD.

Concrètement, nous avons recréé les APIs clés de compatibilité (KeyValue, Watch, Lease, Compaction…) en les interfaçant sur une infrastructure que nous maîtrisons, avec :

• une architecture multi-tenant, pensée pour l’échelle car en utilisant FoundationDB comme base de données, nous pouvons utiliser du scaling horizontal. Habituellement, chaque noeud ajouté dans ETCD ralentit ses performances. Ici, chaque noeud ajouté dans MateriaETCD permet d'accueillir plus de clients sans impact autre;
• une gestion fine des transactions, des droits, des quotas, des statistiques ;
• une stack cohérente et maintenue par nos équipes.

Le résultat : une base de données logiques compatible avec le protocole d'ETCD, rapide, fiable et scalable, le tout reposant sur FoundationDB, et opéré à l’échelle Clever Cloud. Fini les clusters fragiles et les équipes DBA sur-sollicitées : tout est intégré, industrialisé, et instrumentable, profitant de notre écosystème, intégration et application. Mais surtout, cette solution bénéficie d’un fort niveau de résilience, hérité directement de FoundationDB. Grâce à sa simulation continue en environnement distribué, nous sommes capables de valider chaque release logicielle dans des milliers de scénarios de panne simulée. C’est un niveau de robustesse rare, qui nous permet d’anticiper les comportements extrêmes et de garantir une très haute disponibilité de nos services — et donc des vôtres.

Cette approche nous donne une confiance sans précédent dans notre capacité à maintenir des milliers de clusters Kubernetes sans tomber dans le piège d’une complexité opérationnelle exponentielle.

Kubernetes managé par Clever Cloud : une approche souveraine et pragmatique

Nous ne changeons pas notre vision : notre PaaS reste la meilleure solution pour les équipes qui veulent un maximum de productivité et de sécurité avec un minimum d’efforts. Mais nous savons aussi que certaines organisations ont besoin de Kubernetes pour des raisons d’architecture, de portabilité ou de standardisation.

C’est pourquoi notre Kubernetes managé entre aujourd’hui en phase de test privé. Si vous êtes client Clever Cloud et que vous souhaitez le tester, vous pouvez nous contacter dès maintenant pour y accéder.

Notre promesse ? Un Kubernetes intégré, sécurisé, maîtrisé, qui repose sur une fondation technique solide. Un K8S qui respecte l’état de l’art — mais sans les défauts de ses briques historiques, et qui vous laisse, enfin, vous concentrer sur votre métier.

La protection des données de santé concerne aujourd'hui de nombreux secteurs d'activité. Éditeurs de logiciels, établissements de santé, services publics, laboratoires... De plus en plus d'acteurs doivent garantir un hébergement sécurisé de ces données sensibles.

Prêt à sécuriser et optimiser l’hébergement de vos données ? Contactez nos équipes pour en savoir plus!

Je prends rendez-vous !

Comprendre la certification cloud Hébergement des Données de Santé (HDS)

Qu’est-ce qu’une donnée de santé ?

Toute information qui permet d’identifier une personne et d’en apprendre sur son état de santé, physique ou mental, est une donnée de santé (informations collectées lors d’un suivi médical, résultats d’examens médicaux, informations relatives à une maladie, une allergie, un traitement ou un handicap,...).

Qu’est-ce que la certification HDS ?

La certification HDS (Hébergeur de Données de Santé) vise à renforcer la sécurité et la confidentialité des données de santé à caractère personnel, garantissant ainsi un environnement de confiance pour l’e-santé et le suivi des patients. Pour assurer ce niveau d’exigence, elle s’appuie sur des référentiels conformes aux normes ISO et se base sur le RGPD. Délivrée par un organisme indépendant accrédité, elle couvre six domaines d’activité : la mise à disposition et le maintien en conditions opérationnelles et de sécurité (MCO / MCS) des sites physiques, de l'infrastructure matérielle, de l'infrastructure virtuelle, de la plateforme d'hébergement d'applications sur SI traitant des données de santé à caractère personnel (DSCP), ainsi que l'administration et l'exploitation du SI et la sauvegarde des DSCP.

Pourquoi choisir un cloud HDS ?

Une obligation légale pour les acteurs du secteur de la santé

Tous les acteurs (publics ou privés) qui hébergent, exploitent ou sauvegardent des données de santé pour un tiers (à l’exception des services d'archivages informatiques qui ne sont pas concernés par ces obligations) doivent être certifiés HDS. Seuls les établissements de santé qui gèrent leur propre système d’information sont exemptés (L.1111-8 du code de la santé publique).

Sécurisation et confidentialité des données

Contrairement à une infrastructure on-premise où l’entreprise devrait gérer elle-même l’hébergement, l’exploitation et la sécurisation des données, un cloud HDS de type Platform as a Service comme Clever Cloud permet d’automatiser ces aspects critiques. Cela garantit un déploiement rapide, la scalabilité automatique, la commande de base de données en un clic, la sécurisation avancée (chiffrement, continuité de service, anonymisation) et une maintenance sans effort, le tout de façon certifiée.

Un cloud HDS ne se limite pas à fournir des ressources d’hébergement : il engage la responsabilité du prestataire sur l’exploitation, la sécurité et la conformité du système d’information.

En choisissant un cloud HDS, vous vous concentrez sur votre cœur de métier, tout en vous assurant que vos infrastructures respectent les plus hauts standards de protection des données de santé.

Faites confiance à Clever Cloud pour l’hébergement HDS de vos données sensibles

Contactez nos équipes