Depuis son lancement, le Programme UP accompagne des startups technologiques à différents stades de maturité, avec un objectif simple : leur permettre de construire, déployer et faire évoluer leur produit sur une base cloud robuste, sans transformer l’infrastructure en frein opérationnel.

Cybersécurité, santé, legaltech, agriculture : cette cinquième sélection illustre une nouvelle fois la diversité des usages accompagnés par Clever Cloud. Elle réunit des projets qui évoluent dans des environnements exigeants, où la fiabilité, la sécurité, la maîtrise des données et la capacité à passer à l’échelle deviennent rapidement des sujets déterminants.

Programme UP : Les startups sélectionnées pour cette cinquième édition

Sentibee — Simplifier la veille sur les vulnérabilités

Sentibee développe une solution de veille sur les vulnérabilités pensée pour aider les organisations à mieux prioriser les risques cyber.

L’objectif : réduire le bruit, contextualiser les alertes et transformer des données complexes en informations réellement exploitables. La plateforme combine collecte de données, qualification par IA et expertise humaine pour aider les équipes à comprendre ce qui compte vraiment : exploitabilité, impact réel, niveau de priorité et actions à mener.

Avec VulnPilot, Sentibee permet également de construire des listes de surveillance, de suivre les actifs ou technologies critiques, puis de produire des plans d’action priorisés. Une approche pragmatique de la cybersécurité, conçue pour rendre la veille plus lisible, plus utile et plus accessible.

Pictaderm — L’expertise dermatologique en pharmacie

Pictaderm facilite l’accès à un avis dermatologique depuis les pharmacies partenaires, sans rendez-vous.

La solution permet à un patient de se rendre en pharmacie pour un problème de peau ou une lésion à surveiller, puis d’obtenir l’avis d’un médecin expert en moins de 48 heures. Pictaderm répond ainsi à un enjeu concret : rapprocher l’expertise médicale du terrain, dans un contexte où les délais d’accès à la dermatologie peuvent être longs.

La plateforme s’appuie sur un réseau de pharmacies inscrites et accompagne déjà plusieurs dizaines de milliers de patients. Pour les pharmaciens, elle offre un outil de téléexpertise permettant d’orienter plus rapidement les patients et de renforcer leur rôle dans le parcours de soin.

Legaia — Un assistant juridique IA pensé par des avocats

Legaia développe Gaia, un assistant juridique IA accessible directement par email et pensé pour les avocats.

La promesse est simple : permettre aux cabinets d’utiliser l’IA sans changer leurs habitudes de travail. Pas de nouvelle plateforme à prendre en main, pas d’outil supplémentaire à ouvrir : l’avocat transfère un email à Gaia et reçoit une première analyse, une recherche, une rédaction ou une traduction.

La solution couvre plusieurs usages du quotidien : rédaction de courriers, recherche de jurisprudences, numérotation et tamponnage de pièces, récupération de documents officiels ou traduction de pièces jointes. Legaia met également l’accent sur la sécurité, la confidentialité et la conformité, des prérequis essentiels pour des professionnels amenés à traiter des documents sensibles.

Cockpit Agriculture — Piloter la performance agricole

Cockpit Agriculture développe une solution de pilotage intelligent de la performance pour les agriculteurs et leurs filières.

La startup s’inscrit dans une logique d’agriculture augmentée : aider les acteurs du monde agricole à gagner en maîtrise, à mieux suivre leur activité et à prendre des décisions plus fiables. Dans un secteur soumis à des contraintes économiques, environnementales et opérationnelles fortes, la capacité à piloter la performance et à prendre des décisions en confiance devient un enjeu clé.

Avec cette approche, Cockpit Agriculture adresse un besoin central : donner aux agriculteurs et aux filières des outils de pilotage adaptés à la réalité du terrain.

Une promotion représentative des enjeux des startups technologiques

Les quatre startups de cette nouvelle sélection évoluent dans des secteurs très différents, mais partagent plusieurs points communs.

Toutes développent des produits où la technologie n’est pas un simple support, mais une partie centrale de la proposition de valeur. Toutes adressent également des usages où la confiance est centrale : vulnérabilités cyber, parcours de soin, documents juridiques, pilotage agricole.

Dans ces contextes, l’infrastructure cloud doit rester fiable, scalable et maîtrisée. Elle doit permettre d’itérer vite, de sécuriser les données, d’absorber la croissance et de maintenir un haut niveau de disponibilité, sans détourner les équipes de leur cœur de métier.

C’est précisément le rôle du Programme UP : accompagner les startups dans cette phase où l’infrastructure devient un sujet stratégique.

Le Programme UP, un cadre d’accompagnement pour construire dans la durée

Le Programme UP a été conçu pour accompagner les startups au-delà des premiers crédits cloud.

Les startups sélectionnées bénéficient d’un ensemble de ressources pour les aider à structurer leur trajectoire technique :

— jusqu’à 10 000 € de crédits cloud la première année ;
— un onboarding sur la plateforme Clever Cloud ;
— une formation avec les ingénieurs Clever Cloud ;
— un coaching mensuel ;
— un accès au support ;
— des workshops et masterclasses pour les équipes techniques ;
— du mentorat pour les fondateurs et les équipes produit ;
— de la visibilité via les médias, réseaux sociaux et événements Clever Cloud ;
— un accès à des outils de pilotage financier et de structuration.

L’objectif est de permettre aux startups de se concentrer sur leur produit, leurs utilisateurs et leur marché, tout en construisant sur une infrastructure automatisée, robuste et capable d’évoluer avec elles.

Vous êtes une startup et souhaitez rejoindre le Programme UP ?

La prochaine sélection du Programme UP aura lieu le 16 septembre 2026.

Les startups souhaitant candidater peuvent dès maintenant déposer leur dossier et échanger avec les équipes Clever Cloud pour présenter leur projet, leurs besoins techniques et leurs enjeux de croissance.

Faisant suite à sa première certification Cloud Concepts 101, elle s’adresse aux développeurs, partenaires techniques et équipes DevOps qui veulent aller plus loin dans leurs usages : comprendre le cycle build / run, configurer leurs environnements, gérer la persistance et rendre leurs déploiements plus reproductibles avec Terraform.

Avec cette deuxième certification, Clever Cloud poursuit son parcours pédagogique autour du cloud et de sa plateforme, avec une approche concrète, progressive et directement applicable.

Comprendre les déploiements avancés sur Clever Cloud

La certification Advanced Deployments repose sur cinq modules principaux :

1. Systèmes intégrés aux déploiements : comprendre le cycle complet d’un déploiement, du build au run, avec les logs, l’isolation, l’immutabilité, le scaling et les différences entre build flavor et run flavor.
2. Configuration avancée par variables d’environnement : apprendre à interagir proprement avec la plateforme, contextualiser les instances, organiser les environnements et utiliser les variables comme un mécanisme central de configuration.
3. Variables d’environnement spécifiques aux langages : comprendre comment Clever Cloud configure les runtimes selon les écosystèmes, comme Node.js, PHP, Python, Java ou Docker, et comment ajuster versions, comportements de build, exécution, mémoire et performance.
4. Gestion du stockage et de la persistance : distinguer les approches stateless et stateful, choisir les bons add-ons de stockage, gérer la persistance dans un environnement distribué, anticiper les enjeux de concurrence, de sauvegarde et de haute disponibilité.
5. Déployer avec Terraform : découvrir l’Infrastructure as Code dans un contexte PaaS, configurer le provider Clever Cloud, décrire applications, bases de données et stockage dans des fichiers HCL, et construire des environnements reproductibles et versionnables.

Une certification pensée pour les environnements réels

Dans la vie d’un projet, les besoins évoluent vite. Une application devient plusieurs environnements. Une configuration simple devient un ensemble de variables à organiser. Une base de données, un cache ou un stockage objet viennent compléter l’architecture. Et lorsque l’infrastructure doit être reproduite, auditée ou partagée, Terraform devient un allié précieux.

Advanced Deployments accompagne cette montée en complexité de manière progressive. Elle permet de mieux comprendre les mécanismes de la plateforme, de diagnostiquer plus rapidement les erreurs de build ou d’exécution, de configurer proprement ses environnements, et de gérer ses déploiements de manière plus fiable et reproductible.

Valoriser sa progression

Comme pour Cloud Concepts 101, les personnes qui valident la certification Advanced Deployments peuvent valoriser cette nouvelle étape de leur parcours.

Elles obtiennent un badge numérique, qu’elles peuvent notamment ajouter à leur profil LinkedIn pour mettre en avant leur montée en compétence sur Clever Cloud et les déploiements avancés.

Passez Advanced Deployments dès maintenant

La certification Advanced Deployments est disponible dès maintenant sur la Clever Cloud Academy.

Vous avez déjà validé Cloud Concepts 101 ? C’est le moment de passer au niveau suivant.

Vous découvrez le parcours de certification Clever Cloud ? Commencez par les bases, puis relevez ce nouveau défi.

Mais en production, le sujet dépasse vite le simple fait de déployer des containers. Un cluster Kubernetes implique aussi de gérer un control plane, des mises à jour, des correctifs de sécurité, du réseau, du stockage, de l’observabilité, des coûts, et une intégration cohérente avec le reste du système d’information.

La question n’est donc plus seulement de savoir s’il faut utiliser Kubernetes, mais comment l’exécuter sans reconstruire toute une plateforme d’exploitation autour du cluster.

Le jeudi 21 mai à 11h30, Clever Cloud organise un webinar dédié à Clever Kubernetes Engine (CKE), notre Kubernetes managé, pour aborder ces enjeux avec vous.

Kubernetes : un standard, mais pas seulement un orchestrateur

Kubernetes apporte un socle commun pour déployer, faire évoluer et opérer des workloads conteneurisés. Il s’intègre avec des outils largement adoptés par les équipes techniques : kubectl, Helm, Terraform, GitOps…

C’est aussi pour cette raison que de nombreuses organisations l’ont adopté. Certaines solutions sont déjà architecturées pour être installées sur Kubernetes. Certains éditeurs distribuent leurs solutions via des charts Helm ou des manifests. Certaines équipes ont construit leurs pratiques, leurs workflows et leurs architectures autour de cet écosystème.

Mais cette standardisation ne supprime pas la charge d’exploitation. Elle la déplace. Dès qu’un cluster doit être utilisé en production, d’autres sujets apparaissent : disponibilité du control plane, mises à jour, supervision, sécurité, résilience, gestion des dépendances et intégration avec les services existants.

C’est précisément là que les choix d’architecture deviennent importants.

CKE : garder Kubernetes, réduire ce qu’il faut opérer

Avec Clever Kubernetes Engine, l’objectif est de proposer une autre manière d’exécuter Kubernetes : conserver les standards, les outils et les pratiques que vos équipes utilisent déjà, tout en réduisant la part d’infrastructure à gérer au quotidien.

CKE permet de créer et d’exploiter des clusters Kubernetes sur l’infrastructure Clever Cloud. Le control plane est opéré par Clever Cloud, les nœuds sont provisionnés à la demande, et les mises à jour peuvent être appliquées à la demande ou en cas de faille critique.

Côté équipes techniques, le principe reste le même : vous utilisez Kubernetes avec vos outils habituels. Vous récupérez votre kubeconfig, vous utilisez kubectl, Helm, Terraform ou vos workflows GitOps, sans devoir adopter un outil propriétaire ou revoir entièrement vos pratiques.

CKE ne vous impose pas de changer vos outils Kubernetes. Il réduit surtout ce que vous avez à gérer autour du cluster.

PaaS et Kubernetes : deux approches complémentaires

Chez Clever Cloud, le PaaS reste au cœur de notre approche. Pour une grande partie des applications, il permet de déployer rapidement, de réduire la charge d’infrastructure et de se concentrer sur le code. Mais tous les usages ne se ressemblent pas.

Certaines équipes utilisent déjà Kubernetes. Certaines architectures nécessitent davantage de contrôle sur l’orchestration. Dans ces cas, Kubernetes n’est pas seulement un choix technique : c’est déjà le cadre de travail de l’équipe.

CKE vient compléter le PaaS Clever Cloud pour répondre à ces besoins, sans opposer les deux modèles. L’enjeu est plutôt d’utiliser le bon outil au bon endroit : le PaaS quand il permet d’aller plus vite, Kubernetes quand il s’intègre naturellement dans l’architecture et les pratiques de l’équipe.

Un webinar pour voir concrètement comment ça fonctionne

Le jeudi 21 mai à 11h30, Florent Perreux, CSO chez Clever Cloud, et Gilles Biannic, Ingénieur SRE chez Clever Cloud, vous montreront comment CKE s’intègre dans des architectures existantes et ce qu’il change dans l’exploitation quotidienne d’un cluster Kubernetes.

L’objectif : comprendre comment utiliser Kubernetes avec vos outils habituels, tout en réduisant la charge d’exploitation autour du cluster.

Au programme

Lors de ce webinar de 30 minutes, nous reviendrons sur :

• pourquoi Kubernetes reste exigeant à exploiter en production ;
• dans quels cas Kubernetes est pertinent en complément d’un PaaS ;
• ce que CKE prend en charge : control plane, mises à jour, correctifs critiques, intégration plateforme ;
• comment conserver vos outils habituels : kubectl, Helm, Terraform, GitOps ;
• une démonstration : création d’un cluster, récupération du kubeconfig, déploiement d’une application et exposition d’un service ;
• des cas d’usage concrets : migration depuis un cluster existant, complément PaaS, réduction de la charge d’exploitation ;
• une session Q&A pour poser vos questions en direct.

Pourquoi participer ?

Ce webinar s’adresse aux équipes qui utilisent déjà Kubernetes, exploitent des clusters en self-managed ou chez un hyperscaler, ou cherchent une alternative européenne aux clusters opérés chez des hyperscalers ou en self-managed.

Vous pourrez notamment :

• comprendre ce qui génère réellement de la complexité autour de Kubernetes ;
• identifier si CKE correspond à votre contexte : hyperscaler, self-managed, PaaS ou architecture hybride ;
• voir comment utiliser Kubernetes sans changer vos outils ni vos workflows ;
• découvrir comment CKE s’intègre avec l’écosystème Clever Cloud ;
• poser vos questions directement à nos équipes.

CKE est actuellement disponible en bêta publique. Pendant cette période, vous pourrez également échanger avec nos équipes pour en savoir plus sur les conditions d’accès et les coupons de réduction disponibles.

Inscrivez-vous dès maintenant

Le webinar aura lieu le jeudi 21 mai 2026 à 11h30, en ligne sur Livestorm.

Vous utilisez déjà Kubernetes, vous exploitez vos propres clusters, ou vous cherchez une alternative intégrée pour réduire votre charge d’exploitation ? Rejoignez-nous le 21 mai prochain.

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

Une réponse concrète aux enjeux de souveraineté et un standard de référence pour le cloud européen.

Dans un contexte de dépendance accrue aux technologies extra-européennes, cette décision illustre la capacité de ces trois acteurs à proposer des solutions concrètes, compétitives et alignées avec les valeurs de l’Union. 

Au travers de cette sélection, la Commission démontre qu’il est possible de concilier performance technologique et contrôle stratégique. Elle fait le choix d’un modèle multi-fournisseurs, visant à renforcer la résilience et à éviter toute dépendance à un acteur unique.

Un consortium européen au service de l’autonomie stratégique de l’UE 

Le consortium sélectionné réunit des acteurs européens complémentaires et de premier plan, répondant aux exigences les plus élevées en matière de souveraineté, de sécurité et de performance.

Concrètement, OVHcloud met à disposition, avec sa plateforme OPCP, une solution cloud standardisée, opérable, et de grande capacité, conçue pour fournir des ressources de calcul massives et assurer un déploiement rapide à grande échelle grâce à OPCP Core.

Clever Cloud apporte une couche d’orchestration avancée — PaaS, conteneurisation et services managés — qui permet de piloter, automatiser et unifier des environnements complexes. Cette approche rend possible la mise en œuvre d’architectures hybrides, combinant cloud public, privé et infrastructures dédiées, avec un haut niveau de flexibilité.

Enfin, DEEP amène non seulement ses capacités d’hébergement mais également son expertise dans les domaines du cloud, de la cybersécurité et de l’intelligence artificielle.

Un signal fort pour l’avenir numérique de l’Europe

Ce cadre élève le niveau d’exigence en matière de souveraineté, encourage l’adoption de standards européens et ouvre la voie à une concurrence plus équilibrée dans le cloud et l’IA.
Cette sélection reflète également un alignement strict avec le Cloud Sovereignty Framework de la Commission européenne, qui fixe un niveau d’exigence élevé en matière de maîtrise stratégique et juridique, de sécurité et de conformité européennes, de transparence des dépendances, d’ouverture technologique et de performance environnementale.

Octave Klaba, CEO d’OVHcloud déclare : « Je suis très heureux de la confiance accordée par la Commission Européenne à notre consortium. Ce projet prouve qu’il existe en Europe des alternatives solides, capables de répondre aux plus hauts standards. Cette décision démontre également que, quand les acteurs européens unissent leurs forces, ils font la différence ».

Quentin Adam, CEO de Clever Cloud ajoute : « Nous sommes très fiers d’avoir été sélectionnés. C’est le résultat d’un travail collectif important mené avec OVHcloud et DEEP. Nous avons construit une réponse solide, capable de répondre aux exigences des institutions européennes. Ce qui est intéressant ici, c’est que la souveraineté technologique ne reste pas un concept : elle se traduit concrètement par des infrastructures, des plateformes et des acteurs capables d’opérer ensemble en production. C’est aussi la preuve que des acteurs européens peuvent coopérer efficacement et faire progresser l’ensemble de l’écosystème ».

Sébastien Genesca, Managing Director de DEEP by POST Group conclut : « Nous remercions la Commission Européenne pour la confiance qu’elle témoigne à notre consortium. Nous avons réalisé avec OVHcloud et Clever Cloud, un travail exigeant et passionnant, avec un objectif commun : bâtir une offre de cloud souverain en apportant le meilleur de nos expertises technologiques. Tout cela en partageant des valeurs communes et européennes. »

À propos d’OVHcloud

OVHcloud est un acteur mondial et le leader européen du Cloud opérant plus de 500 000 serveurs dans 46 centres de données sur 4 continents à destination de 1,6 million de clients dans plus de 140 pays. Fer de lance d'un Cloud de confiance et pionnier d'un Cloud durable au meilleur ratio performance-prix, le Groupe s’appuie depuis plus de 20 ans sur un modèle intégré qui lui confère la maîtrise complète de sa chaîne de valeur : de la conception de ses serveurs, à la construction et au pilotage de ses centres de données, en passant par l’orchestration de son réseau de fibre optique. Cette approche unique lui permet de couvrir en toute indépendance l’ensemble des usages de ses clients en leur faisant profiter des vertus d’un modèle raisonné sur le plan environnemental avec un usage frugal des ressources et d'une empreinte carbone atteignant les meilleurs ratios de l'industrie. OVHcloud propose aujourd’hui des solutions de dernière génération alliant performance, prévisibilité des prix et une totale souveraineté sur leurs données pour accompagner leur croissance en toute liberté.

À propos de DEEP by POST Luxembourg Group

DEEP est une entité de POST Telecom S.A., filiale de POST Luxembourg, qui regroupe l’ensemble des expertises Télécom & ICT du Groupe afin d’accompagner la transformation numérique des entreprises et organisations.  Avec plus de 750 collaborateurs, DEEP se positionne comme un partenaire de référence en matière de services numériques professionnels au Luxembourg, en Grande-Région et à l'international.

DEEP propose un portefeuille complet de services et solutions à travers sept domaines technologiques parmi lesquels le Cloud, la Cybersécurité et l’Intelligence Artificielle (IA) jouent un rôle clé. A la fois acteur luxembourgeois et fournisseur de services critiques pour l’économie nationale, DEEP apporte des réponses aux enjeux du numérique avec des offres conçues et opérées par ses propres équipes. 

DEEP s’appuie sur les infrastructures télécom et data centres les plus performantes et résilientes du pays et reconnues comme étant parmi les plus robustes d’Europe. La convergence des expertises télécom et ICT permet à DEEP de couvrir l’ensemble de la chaîne de valeur, des besoins en connectivité à la valorisation des données.

Pour plus d’informations : www.deep.eu - www.postgroup.lu 

À propos de Clever Cloud

Fondée en 2010 à Nantes (France), Clever Cloud est spécialisée dans l’hébergement et l’automatisation informatique. Sa plateforme cloud permet de déployer des applications en quelques clics, sur cloud public comme sur les infrastructures du client, sans avoir à gérer la montée en charge ni la maintenance. Elle garantit en parallèle un haut niveau de sécurité et de maîtrise des données, dans le respect des exigences de souveraineté. Parmi ses clients figurent Airbus, Great Place to Work, MAIF, Docaposte, Fairphone, Solocal ou encore Limagrain.

Depuis plus de 15 ans, nous construisons Clever Cloud pour éviter ce compromis. L’objectif : proposer une plateforme européenne polyvalente avec des services managés, opérés sur une infrastructure que nous contrôlons, chez nos partenaires ou chez vous. Un environnement où votre application s’exécute toujours comme vous l’avez conçue.

Une plateforme complète, pas seulement une couche de calcul

Ce qui distingue Clever Cloud ne tient pas à une fonctionnalité en particulier.C’est l’étendue de ce qui fonctionne nativement sur la plateforme, opéré par nos équipes, sur notre infrastructure.

Déployez vos applications dans 18 runtimes : Node.js, Bun, Python (avec uv), Java (Gradle, Maven, WAR), PHP, FrankenPHP, Ruby, Go, Rust, .NET, Elixir, Scala, Haskell, V, Meteor.js, Docker, ainsi que deux runtimes statiques. Le premier repose sur Static Web Server/Caddy avec détection automatique des SSG (Hugo, Astro, Docusaurus, Zola, VitePress, Nuxt, MkDocs, mdBook, Storybook). Le second repose sur Apache avec support de .htaccess pour les SPA et les règles de réécriture. Si aucun de ces runtimes ne convient, vous pouvez déployer un Dockerfile — avec accès complet au système de fichiers, aux ports TCP/UDP, à plusieurs processus, selon vos règles.

Mais le compute n’est que le début. La plateforme inclut PostgreSQL managé (versions 14 à 18, plus de 40 extensions, réplication, Pgpool-II), MySQL, MongoDB, Redis, Elastic Stack, ainsi que Materia KV — un store clé-valeur serverless basé sur FoundationDB, répliqué sur trois datacenters, avec une API compatible Redis. Elle inclut également un stockage objet compatible S3 avec Cellar, un système de fichiers persistant avec FS Buckets, une messagerie distribuée pub/sub avec Apache Pulsar, un API gateway avec Otoroshi, la gestion des identités avec Keycloak, la business intelligence avec Metabase, de l’analytics respectueux de la vie privée avec Matomo, l’hébergement Git avec Heptapod, l’email transactionnel avec Mailpace, ainsi que des moyens simples de déployer des applications de preview depuis GitLab ou GitHub.

Chaque base de données peut être chiffrée au repos avec LUKS2/AES-XTS. Chaque service est provisionné comme un add-on managé — en un clic, avec injection des variables d’environnement et intégration directe avec vos applications.

Co-construit avec des partenaires open source, intégré comme services managés

Plusieurs de ces services — Otoroshi, Keycloak, Metabase — ne sont pas simplement des produits que nous intégrons. Nous les co-construisons avec leurs communautés respectives, nous y contribuons, et nous les opérons comme des offres entièrement managées sur notre infrastructure. Lorsque nous ajoutons une fonctionnalité à Otoroshi ou travaillons sur le modèle de déploiement de Keycloak, ce travail bénéficie à la fois au projet open source et à chaque client de Clever Cloud.

Cette approche va au-delà du logiciel. Nous construisons un écosystème de partenaires — revendeurs, intégrateurs, partenaires technologiques — qui apportent leur expertise métier sur la plateforme. Notre academy forme les équipes à opérer efficacement sur Clever Cloud, de l’onboarding à la production. L’objectif n’est pas d’enfermer les utilisateurs, mais de créer un réseau de personnes et d’organisations capables de construire efficacement sur une infrastructure européenne.

Request Flow : une chaîne de middleware programmable

Le trafic HTTP sur Clever Cloud ne va pas directement d’Internet vers votre application. Il passe par notre load balancer Sōzu, écrit en Rust, et vous pouvez configurer une chaîne de middleware — le Request Flow — que vous contrôlez avec une seule variable d’environnement.

Définissez CC_REQUEST_FLOW pour composer un pipeline à partir des services intégrés : Varnish pour le cache HTTP, Redirection.io pour la réécriture d’URL et les redirections optimisées SEO, OAuth2-Proxy pour l’authentification, Otoroshi Challenge pour la vérification des requêtes. Vous pouvez également brancher votre propre reverse proxy avec CC_REQUEST_FLOW_CUSTOM, la plateforme gérant automatiquement l’allocation des ports.

Besoin de couper totalement l’accès HTTP public tout en conservant le réseau privé actif ? Configurez le flow en mode blocage. La plateforme renvoie un 200 OK pour les vérifications de santé tout en refusant tout autre trafic. Votre application reste accessible via les Network Groups, mais invisible depuis Internet.

Ce type de fonctionnalité est rare sur les PaaS. En général, vous disposez soit d’un reverse proxy fixe que vous ne pouvez pas configurer, soit vous devez déployer votre propre Nginx, Caddy ou HAProxy et le gérer en parallèle de votre application. Sur Clever Cloud, la couche middleware est un service de la plateforme à part entière.

Mise : un fichier de configuration pour les outils, les tâches et les environnements

Chaque runtime Clever Cloud inclut Mise et peut ajouter automatiquement des outils avant la phase de build. Il suffit de déposer un fichier mise.toml à la racine du projet pour que Mise gère de manière déclarative les versions des outils, les variables d’environnement et les tâches de build et d’exécution.

Cela permet par exemple d’installer Deno sur un runtime Node.js, d’utiliser Bazel pour construire votre projet, de fixer une version spécifique de Hugo sur un runtime statique, ou de définir des commandes de build qui fonctionnent à l’identique en local et en production — sans écrire de scripts shell ni personnaliser des buildpacks. Sur le runtime Linux, les tâches Mise sont natives : la plateforme vérifie d’abord CC_BUILD_COMMAND et CC_RUN_COMMAND, puis les tâches Mise, puis les cibles Makefile.

Réseau privé avec WireGuard et Tailscale

Les Network Groups créent des réseaux overlay WireGuard chiffrés entre vos applications, vos add-ons et des pairs externes. Chaque membre dispose d’une résolution DNS interne (<memberID>.m.<ngID>.cc-ng.cloud), tous les ports sont accessibles au sein du réseau privé, et le trafic ne transite jamais par Internet. Vous pouvez ainsi construire des architectures microservices où les services communiquent en privé et où seul l’API gateway est exposé publiquement.

Pour les équipes qui utilisent déjà Tailscale, l’intégration est native : définissez TAILSCALE_AUTH_KEY et chaque instance d’application rejoint votre réseau Tailscale sous la forme CC-<NAME>-<INSTANCE_NUMBER>. Utilisez TAILSCALE_LOGIN_SERVER pour pointer vers un serveur de contrôle Headscale auto-hébergé. Configuration DNS, publication de routes — tout fonctionne comme attendu.

Nous supportons également IPSec et OpenVPN pour les environnements qui en ont besoin. Des adresses IP sortantes dédiées sont disponibles pour le whitelisting firewall.

API-first, prêt pour l’IA

Clever Cloud est exposé comme une API, conçu avec l’Infrastructure as Code en tête. Nous avons construit nos propres intégrations dessus, du Console web au provider Terraform, ainsi que des outils majeurs comme le Kubernetes Operator, le CLI Clever Tools et ses capacités AI.

Pour faciliter l’usage de l’IA, nous fournissons un fichier LLMs.txt qui résume la documentation, et toutes les pages peuvent être obtenues en Markdown sur demande par vos outils. Vous souhaitez explorer une application déployée ? clever ssh vous donne un accès shell à vos instances de production, et vous pouvez aussi utiliser clever ssh --command 'any command' pour exécuter directement une commande et récupérer le résultat. Une fonctionnalité utile lorsque vous utilisez Claude Code, Codex, Gemini ou OpenCode pour diagnostiquer une application en cours d’exécution.

Observabilité : Grafana, Warp 10 et métriques personnalisées intégrées

Chaque service dispose d’un dashboard Grafana. Le CPU, la RAM, le disque, le réseau et les requêtes par seconde sont collectés automatiquement. Des dashboards préconfigurés sont disponibles dans un dossier « Clever Cloud », et vous pouvez créer les vôtres, avec des alertes lorsque la consommation dépasse un seuil.

En interne, les métriques sont stockées dans Warp 10, une base de données de séries temporelles géospatiales avec une précision à la microseconde, interrogeable via WarpScript — un langage basé sur une pile.

Pour l’instrumentation personnalisée, vous pouvez envoyer des métriques vers StatsD sur le port 8125 ou exposer un endpoint Prometheus sur localhost:9100. La plateforme collecte plus de 170 classes de métriques Telegraf, toutes étiquetées avec owner_id, app_id, host et deployment_id. Le profiling avec Blackfire ainsi que l’intégration New Relic sont disponibles pour une analyse plus fine au niveau applicatif.

La plupart des plateformes facturent l’observabilité en supplément, limitent la rétention à quelques heures ou quelques jours, ou nécessitent la mise en place d’outils externes dès le départ. Sur Clever Cloud, les logs sont conservés pendant 7 jours avec recherche par regex, les logs d’accès sont disponibles dans plusieurs formats (CLF, JSON avec géolocalisation et version TLS), et les log drains permettent un envoi vers Syslog, Elasticsearch, Datadog ou New Relic sans surcoût au gigaoctet.

Otoroshi : API gateway, WAF et gateway LLM en un seul outil

Otoroshi n’est pas simplement un reverse proxy. C’est un API gateway managé qui intègre un WAF Coraza exécutant l’OWASP Core Rule Set en WebAssembly — en mode détection ou prévention, avec des règles personnalisées par domaine et des logs d’audit pour la conformité. Sans condition de type « offre Enterprise requise ».

L’extension LLM transforme Otoroshi en une gateway unifiée pour les modèles de langage, exposant une API compatible OpenAI capable de router vers plusieurs fournisseurs : OpenAI, Anthropic, Mistral, Cloud Temple, DeepSeek, Gemini, Groq, HuggingFace, Ollama, OVHcloud, Scaleway et d’autres. Le cache sémantique réduit les appels redondants. La gestion des quotas permet de maîtriser les coûts. Le failover automatique bascule d’un fournisseur à l’autre de manière transparente en cas d’indisponibilité. Le prompt fencing empêche les fuites d’informations sensibles. Le support du MCP (Model Context Protocol) permet de construire des agents capables d’utiliser des outils.

L’ensemble fonctionne comme un service managé dans votre compte Clever Cloud — sans fournisseur tiers, sans surcoût par token. C’est l’outil que nous utilisons pour construire la technologie au cœur de Clever AI.

Clever Tasks : exécuter, payer, arrêter

Tous les workloads ne sont pas des serveurs web. Clever Tasks sont des applications qui exécutent une commande puis s’arrêtent. Vous pouvez définir n’importe quelle application comme une Task, définir CC_RUN_COMMAND="python manage.py migrate", déclencher via un git push ou un clever restart, et le scaler s’exécute exactement pendant la durée de la commande. Vous payez le temps de build et d’exécution, à la seconde.

Vous pouvez les utiliser pour des migrations de base de données, des suites de tests, des conversions de fichiers, du traitement de données, des tâches de compilation — tout ce qui n’a pas vocation à tourner en continu. Il est possible d’enchaîner plusieurs commandes avec && ou de les encapsuler dans un script. Toutes les variables d’environnement de votre application sont disponibles.

C’est fondamentalement différent des planificateurs basés sur cron avec des intervalles minimum de 10 minutes, des limites sur le nombre de tâches et des garanties d’exécution incertaines. Une Clever Task s’exécute quand vous le décidez, pendant le temps nécessaire, puis s’arrête.

Infrastructure européenne, souveraineté réelle

Clever Cloud repose sur une infrastructure que nous opérons dans plusieurs régions : Paris, Gravelines, Roubaix, Londres, Varsovie, Montréal, Singapour et Sydney. Nous travaillons avec des fournisseurs européens — OVHcloud, Scaleway — et ne dépendons pas d’un hyperscaler américain unique. Notre approche de la souveraineté est structurelle : capital 100 % français, hébergement exclusivement européen, aucune exposition aux législations extraterritoriales.

Plusieurs régions disposent de la certification HDS (Hébergement de Données de Santé), le standard réglementaire français pour l’hébergement de données de santé. Cela s’applique à toutes les bases de données managées dans ces régions — PostgreSQL, MySQL, MongoDB, Redis, Elastic Stack — et non à un sous-ensemble. Ce n’est pas une option facturée en supplément, mais une caractéristique intégrée à l’infrastructure. Pour les organisations nécessitant un niveau d’exigence plus élevé, nous proposons également des options de niveau SecNumCloud au sein de notre offre cloud.

Les données restent dans la région que vous choisissez. Il n’y a pas de comportement de type « us-east-1 par défaut », pas de réplication implicite vers une juridiction non choisie, pas de traitement des données dans un autre pays pour des raisons opérationnelles.

Pricing prévisible

La facturation est calculée à la seconde, en fonction de la taille des instances et de la durée d’exécution. Pas à l’invocation. Pas à la requête. Pas au hit de cache en edge. Pas au million d’opérations sur un store clé-valeur. Votre facture mensuelle varie généralement d’environ ±5 %, car elle reflète l’usage réel du compute — et non des pics de trafic multipliés par des unités tarifaires peu visibles.

Les log drains ne sont pas facturés au gigaoctet. Les dashboards Grafana et les métriques Warp 10 sont inclus. Les sauvegardes de bases de données sont incluses. L’observabilité est incluse. Vous n’avez pas besoin de multiplier les lignes budgétaires pour comprendre le comportement de vos applications.

Ce que nous construisons pour la suite

Nous savons où la plateforme doit évoluer et restons à l’écoute des besoins du marché. Clever Kubernetes Engine est actuellement une priorité de développement. En parallèle, nous travaillons sur de nombreuses nouvelles fonctionnalités et de nouveaux services. Vous souhaitez nous faire part de vos attentes prioritaires ? N'hésitez pas à nous en parler.

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é.

Pendant des années, le cloud a surtout été abordé sous l’angle du coût, de la montée en charge et de l’expérience développeur. Ces critères restent importants. Mais le contexte géopolitique mondial impose désormais une autre lecture : celle de la résilience, de la continuité d’activité et du contrôle.

L’instabilité géopolitique est désormais un risque cloud

Les événements récents dans le Golfe l’ont rappelé de manière très concrète. Quand des tensions régionales affectent les systèmes énergétiques, les routes logistiques et les infrastructures physiques, les conséquences ne s’arrêtent pas aux ports ou aux voies maritimes. Elles atteignent aussi les centres de données, les plateformes cloud et la disponibilité des applications.

Pour les acteurs publics comme pour les entreprises, cela change la nature du risque. Une dégradation locale peut désormais produire des effets opérationnels très réels sur des services numériques considérés comme critiques.

L’infrastructure numérique n’est jamais purement virtuelle

Il faut le rappeler : l’infrastructure numérique reste une infrastructure physique. La résilience du cloud repose sur un constat simple : les services numériques dépendent de centres de données, d’alimentation électrique, de connectivité, de chaînes d’approvisionnement, de cadres juridiques et de personnes présentes sur le terrain. Tant que ces conditions tiennent, le système fonctionne. Lorsqu’elles se fragilisent, la dépendance numérique devient une vulnérabilité opérationnelle.

L’autonomie stratégique numérique doit donc être traitée comme un enjeu de préparation, et non comme un débat idéologique. Il ne s’agit pas de prôner l’isolement ni de remettre en cause les coopérations internationales. Il s’agit de s’assurer que les capacités critiques restent sous un contrôle juridique, technique et opérationnel fiable, notamment lorsque l’environnement extérieur devient instable.

Pour les États, les secteurs régulés et les organisations stratégiques, la question n’est donc plus seulement de savoir où les workloads sont hébergés. Elle est de savoir si les services essentiels resteront disponibles lorsqu’une région se déstabilise, lorsque la connectivité se dégrade, lorsque le cadre juridique évolue ou lorsque la concentration des infrastructures devient un risque systémique.

La résilience dépend du contrôle, pas seulement de l’échelle

L’échelle offre des avantages évidents. Mais l’échelle, la résilience et le contrôle ne se confondent pas. Les grandes plateformes apportent de la puissance, de la standardisation et de la capacité d’exécution. Elles peuvent aussi créer des dépendances que l’on sous-estime facilement en période stable : dépendance à un fournisseur unique, exposition à une seule région, soumission à une juridiction extérieure, fragilité logistique ou opérationnelle.

Une perturbation majeure n’a pas besoin de faire tomber un système entier. Il suffit qu’elle affecte une partie suffisamment critique de la chaîne pour ralentir ou paralyser les opérations.

Autrement dit, le risque cloud n’est plus seulement une question de cybersécurité ou d’achats. C’est aussi une question de continuité, de juridiction et de concentration. C’est pourquoi les modèles de cloud souverain et de cloud de confiance doivent désormais être considérés comme des composantes à part entière d’une stratégie de résilience.

Concrètement, cela suppose de protéger les workloads critiques sur des infrastructures que l’on peut gouverner avec confiance. Cela suppose aussi de réduire la dépendance à un acteur unique, de concevoir des architectures capables de fonctionner en mode dégradé, d’aligner la juridiction applicable avec les intérêts stratégiques, et d’investir dans les compétences, les opérateurs et les capacités locales.

En période de stabilité, ces choix peuvent sembler redondants. En période de crise, ils font la différence entre interruption et continuité. Ce qui se joue aujourd’hui dans le Golfe confirme d’ailleurs une tendance plus large : l’infrastructure numérique appartient désormais au même niveau stratégique que l’énergie, la logistique ou les routes de communication. Le même choc géopolitique qui perturbe les chaînes d’approvisionnement et l’activité industrielle peut, dans le même temps, fragiliser la disponibilité du cloud.

Ce que les décideurs publics et dirigeants doivent désormais évaluer

Cette situation doit conduire les décideurs publics et les dirigeants à poser des questions plus directes. Qui contrôle réellement l’infrastructure dont nous dépendons ? Sous quelle juridiction opère-t-elle ? En combien de temps des workloads critiques peuvent-ils être déplacés, isolés ou repris ? Les services essentiels peuvent-ils continuer à fonctionner en mode dégradé ? Maîtrisons-nous réellement notre plan de continuité, ou en avons-nous externalisé une part excessive ?

La stratégie cloud n’est plus seulement un sujet informatique. C’est désormais un sujet de sécurité économique et d’indépendance stratégique.

Pour les services critiques, la résilience doit être intégrée dès la conception de la stratégie cloud. La question n’est plus seulement de savoir s’il faut aller vers le cloud. La vraie question est de savoir qui reste opérationnel lorsque la stabilité ne peut plus être considérée comme acquise.

Ce texte étend aux grandes collectivités territoriales les obligations de protection des données sensibles prévues par la loi SREN renforçant ainsi la doctrine « cloud au centre ». Par ailleurs, le texte prévoit des mécanismes de dérogation pour les projets déjà engagés ou en cas de difficultés techniques ou de surcoût important. Ces dispositions soulignent la nécessité d’une mise en œuvre pragmatique tout en maintenant l’objectif central de sécurisation effective des données publiques sensibles.

Nous saluons, en tant qu’acteur engagé de l’écosystème cloud français, cette initiative qui vise à associer l’ensemble des parties prenantes au débat public sur la sécurisation des marchés publics numériques.

La Commission des Lois examinera le 25 février la proposition de loi adoptée par le Sénat visant à renforcer la sécurisation juridique des marchés publics numériques. À l’initiative de Philippe Latombe, député de la Vendée (1re circonscription) et rapporteur du texte, une table ronde, organisée le 20 février, réunira plusieurs acteurs du cloud opérant en France, dont Clever Cloud, OVHcloud, Orange Business Services, Scaleway, Outscale, Cloud Temple et Numspot.

Des obligations “cloud” élargies au niveau territorial

L’article 31 de la loi du 21 mai 2024 visant à sécuriser et réguler l’espace numérique (loi SREN) encadre l’usage des services en nuage par l’État et ses opérateurs lorsqu’ils traitent des données sensibles. Il exige que ces données soient effectivement protégées contre tout accès par des autorités étrangères qui ne serait pas autorisé par le droit de l’Union européenne.

La proposition de loi insère l’article 31-1 afin de rendre ce mécanisme applicable aux régions, départements, communes de plus de 30 000 habitants, communautés urbaines, communautés d’agglomération, métropoles, ainsi qu’aux principaux établissements publics de coopération intercommunale.

Cette disposition prolonge l’article 31 de la loi SREN et s’inscrit dans la dynamique européenne, notamment avec l’entrée en application du Data Act en septembre 2025. Il vise notamment à limiter l’exposition des services publics aux effets de législations extraterritoriales et étend ainsi au niveau territorial un mécanisme jusqu’ici centré sur l’État.

Une responsabilité collective

Clever Cloud se félicite de pouvoir contribuer aux travaux parlementaires sur ce texte.

« Cette audition marque une prise de conscience essentielle : la protection des données publiques ne peut plus être pensée uniquement à l’échelle de l’État. Les collectivités possèdent et traitent de nombreuses données sensibles qui jouent un rôle clé dans la continuité des services publics et dans la protection des citoyens. Les accompagner vers des solutions qui garantissent une sécurité juridique réelle n’est pas une option, c’est une responsabilité collective. » précise Quentin Adam, CEO de Clever Cloud.

Clever Cloud entend participer activement au débat législatif et accompagner les collectivités territoriales dans la mise en œuvre de solutions techniquement fiables et juridiquement sécurisées.