C'est précisément le moment où l'Infrastructure as Code (l’IaC, le fait de définir ses ressources sous forme de fichiers que l’on peut versionner et qui font office d'autorité) devient une évidence, et où l'on découvre que Terraform ne sait rien de ce qui existe déjà.

Jusqu'ici, rattraper ce retard coûtait cher : une commande terraform import par ressource, un bloc HCL à écrire à la main pour chacune, attribut par attribut, et un plan qui propose de tout détruire à la moindre ligne oubliée. Quarante ressources, une journée perdue. Clever Tools 5.3 et la version 3.0 de notre provider Terraform ramènent l'opération à trois commandes, clever features, clever terraform generate et terraform plan. Voici comment les enchaîner, et surtout ce qu'il faut vérifier avant d'appliquer.

Ce dont vous avez besoin

Trois outils suffisent : Terraform 1.5 ou plus récent (ou OpenTofu 1.6, le fork de Terraform, ou plus récent, qui implémente les fameux blocs d'import (import blocks)), Clever Tools 5.3 et le provider Clever Cloud en version 3.0. La commande qui nous intéresse est encore en bêta, il faut donc l'activer explicitement :

npm install -g clever-tools@latest
clever login
clever features enable terraform

Un mot sur notre provider

Open source dès ses débuts, publié sur les registries Terraform et OpenTofu, il couvre aujourd'hui l'essentiel de la plateforme : les runtimes, les bases de données et les add-ons managés, le stockage objet et les FS Buckets, les drains de logs, les Network Groups, les clusters Kubernetes et jusqu'aux consumers OAuth. Au-delà du provisionnement, il sait déployer votre code depuis un dépôt Git et épingler un commit, lier une application à ses add-ons comme le fait clever service link-addon, lire l'adresse du load balancer pour vos entrées DNS ou parcourir les sauvegardes d'une base. Depuis la version 3.0, il accepte un token d'API pour s'intégrer à une CI, et avec Terraform 1.14 et plus, ses actions redémarrent une application, exécutent une requête SQL sur un PostgreSQL ou envoient des fichiers dans un FS Bucket sans sortir d'un terraform apply. 48 ressources, deux data sources, trois actions : de quoi décrire une organisation entière, et pas seulement l'importer.

Étape 1 : déclarer le provider Terraform Clever Cloud

Dans un répertoire vide, un fichier provider.tf :

terraform {
  required_providers {
    clevercloud = {
      source  = "CleverCloud/clevercloud"
      version = "~> 3.0"
    }
  }
}
 
provider "clevercloud" {}

Le bloc provider reste vide : après un clever login, le provider réutilise les identifiants du profil actif de Clever Tools. Il ne lui manque que l'organisation à cibler, passée par une variable d'environnement (un identifiant user_… fonctionne aussi pour un espace personnel) :

export CC_ORGANISATION="orga_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
terraform init

Étape 2 : générer les blocs import avec clever terraform generate

C'est ici qu'intervient la nouveauté de Clever Tools 5.3. La commande clever terraform generate parcourt une organisation et écrit, pour chaque application et chaque add-on, le bloc import que Terraform attend :

clever terraform generate --org orga_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx > imports.tf

Le fichier obtenu ressemble à ceci :

# mon-api
import {
  to = clevercloud_nodejs.mon-api
  id = "app_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
 
# ma-base
import {
  to = clevercloud_postgresql.ma-base
  id = "postgresql_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

Chaque application est rattachée à la ressource de son runtime (clevercloud_nodejs, clevercloud_php, clevercloud_docker, clevercloud_java_maven…), chaque add-on à la sienne (clevercloud_postgresql, clevercloud_redis, clevercloud_cellar…).

La commande fait aussi le tri à votre place. Un Keycloak, un Matomo, un Metabase ou un Otoroshi provisionnent leur propre application et leurs propres bases ; un Elasticsearch vient avec son Kibana. Ces ressources apparaissent dans votre organisation comme les autres, mais elles appartiennent à l'add-on qui les gère : les importer reviendrait à les confier à Terraform, qui se mettrait à les modifier en parallèle. clever terraform generate les ignore et le signale sur la sortie d'erreur, comme il signale les quelques runtimes qui n'ont pas encore d'équivalent dans le provider. Rien n'est écarté en silence.

Les noms Terraform sont dérivés de ceux de vos ressources : passés en minuscules, débarrassés des caractères spéciaux, préfixés d’un _ s’ils commencent par un chiffre. Deux ressources de même type et de même nom, deux applications « demo » par exemple, ne peuvent pas cohabiter dans une configuration : la seconde reçoit un suffixe tiré de son identifiant (demo-11ced66e), et la sortie d’erreur le signale (« Name collision on nodejs.demo: suffixing with 11ced66e »). Ces noms ne sont que des étiquettes dans votre code : renommez-les à votre convenance dans imports.tf avant l’étape 3, Terraform générera la configuration sous le nouveau nom.

Pour une adoption progressive, vous pouvez limiter la génération à une seule application, ou aux ressources portant un tag :

clever terraform generate --app mon-api > imports.tf
clever terraform generate --tag env:staging > imports.tf

Étape 3 : générer la configuration HCL avec terraform plan

Depuis sa version 1.5, Terraform sait rédiger lui-même la configuration des ressources déclarées dans des blocs import :

terraform plan -generate-config-out=generated.tf

Terraform lit chaque ressource sur la plateforme, en écrit le bloc HCL dans generated.tf (le fichier ne doit pas exister au préalable) et affiche le plan correspondant, sans rien écrire dans le state. Le fichier contient les vraies valeurs : nom, région, nombre d'instances, flavors, plan de l'add-on, dépendances.

Ce point mérite une précision. Sur une application, min_instance_count, max_instance_count, smallest_flavor et biggest_flavor sont obligatoires, comme plan sur un add-on, et le provider ne les déduira jamais tout seul. Ces attributs déterminent ce que la ressource coûte : nous refusons qu'une configuration reste muette à leur sujet et adopte, sans le dire, ce que la plateforme fait tourner. C'est aussi la raison de préférer les blocs import à la commande terraform import, qui écrit directement dans le state et vous laisse rédiger la configuration complète, sous peine d'un Missing required argument au plan suivant.

Secrets et variables d’environnement : le piège de l’import Terraform

C'est l'étape où il faut ralentir. Terraform ne recopie jamais dans une configuration générée une valeur que le provider déclare sensible, et les variables d'environnement d'une application en font partie. Le fichier généré contient donc, pour chaque application :

resource "clevercloud_nodejs" "mon-api" {
  name               = "mon-api"
  region             = "par"
  min_instance_count = 1
  max_instance_count = 2
  smallest_flavor    = "XS"
  biggest_flavor     = "M"
  environment        = null # sensitive
}

Appliquer ce fichier tel quel supprimerait toutes les variables d'environnement de l'application. Le provider offre une variable d'environnement pour contourner ce comportement le temps de la génération :

BYPASS_SENSITIVE_IMPORTS=true terraform plan -generate-config-out=generated.tf

Les attributs sensibles sont alors écrits comme les autres, et environment contient toutes vos variables, en clair. Et pas seulement dans le fichier : tant que la variable est définie, la sortie de terraform plan affiche elle aussi ces valeurs en clair. Lancez cette étape depuis votre poste, jamais dans un pipeline de CI dont les logs sont conservés.  C'est exactement ce que nous voulions, et c'est aussi ce qui demande de la vigilance : clés d'API, mots de passe de bases de données externes, tokens de services tiers, tout ce que vous aviez confié à clever env set se retrouve dans un fichier .tf que vous vous apprêtez à versionner.

Avant le premier commit, passez ces variables en revue. Les valeurs de configuration ordinaires (NODE_ENV, un port, une URL publique) peuvent rester dans le code. Les secrets doivent en sortir, vers l'outil que votre équipe utilise déjà : HashiCorp Vault ou OpenBao, les variables protégées de votre CI, un fichier chiffré avec SOPS, ou au minimum des variables Terraform marquées sensitive et fournies au moment de l'exécution :

variable "stripe_api_key" {
  type      = string
  sensitive = true
}
 
resource "clevercloud_nodejs" "mon-api" {
  # ...
  environment = {
    NODE_ENV       = "production"
    STRIPE_API_KEY = var.stripe_api_key
  }
}

Ce remplacement devient visible au plan suivant : Terraform annonce une mise à jour d'environnement, alors que la valeur n’a pas changé. Il enregistre seulement dans le state que cette valeur est désormais sensible. Le provider, lui, compare les valeurs et non leur statut : identiques, elles ne déclenchent aucun redémarrage de l’application.

Retirez BYPASS_SENSITIVE_IMPORTS dès que generated.tf est écrit : la configuration reste valide sans elle, et le provider affiche l’avertissement « Sensitive attributes are not redacted » à chaque commande tant que la variable est définie. Quant au state Terraform, il contient toujours ces valeurs, quel que soit votre choix : son stockage mérite la même attention que les secrets eux-mêmes.

Étape 4 : vérifier le plan, puis appliquer

Une fois generated.tf relu et nettoyé, un terraform plan sans la variable de contournement doit annoncer autant d'imports que de ressources, et aucune autre modification que les environment que vous venez de déclarer secret :

terraform plan
# Plan: 2 to import, 0 to add, 1 to change, 0 to destroy.
# ~ environment = (sensitive value) valeur inchangée, statut sensible enregistré
terraform apply

Tout autre changement signale qu’un attribut de la configuration diverge de ce que la plateforme fait tourner : lisez-le avant de confirmer.

L’apply inscrit alors les ressources dans le state et, pour les secrets passés en variables, y note leur statut sensible ; il ne touche à rien sur la plateforme. Un dernier terraform plan doit répondre « No changes » : votre infrastructure est désormais décrite dans du code, et les blocs import peuvent être supprimés.

Le déploiement du code reste votre décision

Un import ne remplit jamais le bloc deployment d'une application. Le provider ne peut pas deviner si vous souhaitez que Terraform gère aussi vos déploiements, et l'ajout de ce bloc déclenche un déploiement au premier apply.

Trois options s'offrent à vous. Ne rien ajouter : Terraform gère la configuration, vous continuez à déployer avec git push ou clever deploy, et un changement de variable redémarre l'application comme aujourd'hui. Déclarer commit = "github_hook" si l'application est liée à un dépôt GitHub : les déploiements restent entre les mains de GitHub, le provider ne pousse jamais de code. Ou confier le déploiement à Terraform avec repository et, si vous le souhaitez, un commit précis. Dans ce dernier cas, un token d'API (clever tokens create) ne suffit pas, car il ne peut pas pousser sur Git : le provider a besoin des identifiants OAuth du profil Clever Tools.

Après l'import

generated.tf est un point de départ, pas une configuration finie. Quelques gestes le rendent durable : découper le fichier par service ou par environnement, remplacer les identifiants en dur du champ dependencies par des références (clevercloud_postgresql.ma-base.id), extraire en variables ce qui diffère entre staging et production. Et puisque la commande est en bêta, vos retours sont les bienvenus sur le dépôt GitHub de Clever Tools : c'est ainsi qu'elle sortira du mode expérimental.

Reste la question du state, que vous confiez aujourd'hui à un bucket S3 ou à un backend tiers. Nous n'en dirons pas plus pour l'instant, sinon qu'il pourrait bientôt ne plus avoir à quitter Clever Cloud.

FAQ

L'import modifie-t-il mes applications ?

Non. Les blocs import n’écrivent que dans le state. La seule mise à jour attendue porte sur environment lorsque vous avez remplacé un secret par une variable sensitive : la valeur est identique et le provider ne redémarre pas l’application. Le seul risque réel est d'appliquer une configuration où environment vaut null : c'est tout l'objet de la section sur les secrets.

Puis-je n'importer qu'une partie de mon organisation ?

Oui, avec --app pour une application ou --tag pour les ressources portant un tag. Rien n'oblige à tout migrer en une fois.

Pourquoi certaines ressources manquent-elles dans imports.tf ?

Soit elles sont gérées par un add-on (l'application d'un Keycloak, le Kibana d'un Elasticsearch) et Terraform ne doit pas les prendre en charge, soit leur runtime n'a pas encore de ressource dans le provider. Dans les deux cas, la commande l'indique sur la sortie d'erreur.

Cela fonctionne-t-il avec OpenTofu, le fork de Terraform ?

Oui. OpenTofu implémente les blocs import et l'option -generate-config-out depuis sa version 1.6, et notre provider est disponible sur son registry.

Faut-il conserver les blocs import ?

Non. Une fois les ressources dans le state, ils ne servent plus et peuvent être supprimés.

Clever Tools 5.3 est open source sur GitHub, disponible sur npm et dans nos dépôts de paquets. Le provider Clever Cloud est publié sur le Terraform Registry, son code est sur GitHub, et la documentation complète est disponible sur www.clever.cloud/developers.

Pour une nouvelle intégration, mieux vaut choisir OpenID Connect lorsque l’application le prend en charge ; SAML 2.0 reste adapté aux logiciels existants ou aux produits qui ne proposent que ce protocole. Il faut ensuite renseigner les URI de redirection OIDC ou les points de réception SAML, puis relier l’application aux points d’accès du royaume.

Pour une Direction des Systèmes d'Information (DSI), le SSO résout un besoin quotidien : ouvrir l'accès à tout un parc d'applications à partir d'une seule connexion, sans disperser la sécurité. Keycloak, solution open source de gestion des identités et des accès (Identity and Access Management, ou IAM), y répond en centralisant l'authentification.

Keycloak, fournisseur d'identité central

Keycloak se positionne entre les applications et leurs utilisateurs : ceux-ci s’authentifient auprès de lui et, tant que leur session SSO reste valide, peuvent accéder aux applications raccordées sans ressaisir leurs identifiants. Chaque application fait confiance aux informations d’authentification transmises par Keycloak pour établir sa propre session. Ce fonctionnement est celui d’un fournisseur d’identité (Identity Provider, ou IdP).

Centraliser la connexion présente un intérêt de sécurité concret : d'après l'ENISA Threat Landscape 2025 (rapport annuel de l'Agence de l'Union européenne pour la cybersécurité), le phishing représente environ 60 % des méthodes d’intrusion initiale observées dans les incidents étudiés. Avec Keycloak, les politiques d’authentification multifacteur peuvent être appliquées au point de connexion commun des applications raccordées. Toutes les formes de MFA n’offrent cependant pas la même protection face au phishing : les passkeys et WebAuthn y résistent par conception, car la clé d’authentification est liée au domaine pour lequel elle a été créée.

Chaque application conserve sa propre session. Dans une intégration OIDC complète, l’application vérifie l’état de la session auprès de Keycloak et peut donc prendre en compte sa fermeture. Certaines applications se limitent toutefois à vérifier localement la signature et la durée de validité du jeton JWT. Dans ce cas, un jeton encore valide peut continuer à être accepté après la fermeture de la session Keycloak ; il s’agit alors d’une authentification fondée sur le JWT plutôt que d’une gestion complète de la session OIDC.

Keycloak prend en charge OpenID Connect (OIDC) et SAML 2.0. Dans un même royaume, des applications récentes et des logiciels existants peuvent ainsi partager la même authentification unique.

Configurer le SSO avec Keycloak, étape par étape

La documentation Keycloak de Clever Cloud détaille l’accès au service, la gestion des royaumes, le filtrage des adresses IP, les déploiements en mode Secured Multi Instances et le suivi des métriques. Pour les réglages propres aux clients OIDC et SAML, consultez également la documentation d’administration de Keycloak.

Pour voir le déploiement et l’interface en pratique, retrouvez la démonstration vidéo sur notre page Keycloak as a Service.

SSO en OIDC ou en SAML 2.0 : lequel choisir ?

Pour un nouveau développement, privilégiez OpenID Connect lorsque l’application le prend en charge. Conservez SAML 2.0 pour les applications dont l’intégration repose déjà sur ce protocole ou qui ne prennent pas en charge OIDC :

• OpenID Connect pour authentifier les utilisateurs des applications web et mobiles récentes ; OAuth 2.0 et ses jetons d’accès servent à contrôler l’accès aux API.
• SAML 2.0 pour les applications existantes et les logiciels d’entreprise qui ne proposent pas d’intégration OIDC.

Keycloak prend en charge les deux protocoles dans un même royaume. Des applications OIDC et SAML peuvent ainsi partager la même authentification unique.

Configurer le SSO sur un Keycloak managé

La configuration du SSO ne représente qu'une partie du travail : un serveur Keycloak doit ensuite être maintenu, mis à jour, supervisé et sauvegardé. C'est cette charge d'exploitation qu'une offre managée absorbe.

Keycloak as a Service, l'offre de Clever Cloud opérée avec l'expertise de Please Open It, déploie un Keycloak infogéré et hébergé en France en quelques clics. Les équipes conservent la maîtrise de l’ensemble des réglages (royaumes, clients et protocoles) et confient l’exploitation de l’infrastructure à Clever Cloud : mises à jour continues, monitoring intégré et sauvegardes régulières. Lorsque le service est déployé en mode clusterisé Secured Multi-Instances, plusieurs nœuds assurent la répartition de charge et renforcent la continuité de service. Indépendamment de cette architecture, le SLA de 99,99 %, l’astreinte téléphonique 24/7 et les délais d’intervention et de résolution garantis relèvent de l'offre Premium pour les services éligibles. L’import et l’export de royaumes facilitent la reprise d’une instance existante. Enfin, pour protéger une application qui n’intègre pas nativement l’authentification, un proxy d’authentification comme OAuth2-Proxy place la connexion en amont, sans modifier le code applicatif.

« Keycloak est un produit Red Hat, mais Red Hat ne fournit pas de version LTS de Keycloak en open source et les correctifs de sécurité ne sont pas rétroportés : il est donc primordial de rester sur la dernière version, ce que facilite largement un déploiement Keycloak as a Service sur Clever Cloud. Un seul royaume, distinct de master, suffit bien souvent ; plusieurs ne se justifient que lorsque les populations d’utilisateurs sont entièrement indépendantes, sans application commune ou avec des déploiements distincts. Keycloak rend enfin l’ajout de facteurs d’authentification indépendant des applications, ce qui permet de proposer les facteurs les plus modernes à toutes les applications intégrées. »

— Loïc Mercier des Rochettes, Co-fondateur et CTO chez Please Open It

Vous évaluez une solution IAM ? Notre checklist 11 questions à poser avant de choisir une solution de gestion des identités réunit les critères à vérifier avant de vous engager.

FAQ

Keycloak permet-il de faire du SSO ?

Oui. Keycloak est une solution open source de gestion des identités qui agit comme fournisseur d'identité central : les applications lui délèguent la connexion et l'utilisateur ne s'authentifie qu'une fois. Il prend en charge OpenID Connect et SAML 2.0.

Faut-il utiliser OIDC ou SAML pour le SSO avec Keycloak ?

Les deux conviennent. OpenID Connect vise les applications web récentes, mobiles et les API ; SAML 2.0 reste la référence pour l'existant applicatif d'entreprise. Keycloak pilote les deux protocoles en parallèle.

Comment connecter une application à Keycloak ?

On crée un client dans le royaume concerné, puis on le configure selon le protocole utilisé par l’application. En OpenID Connect, on renseigne notamment ses URL de redirection et on lui fournit l’identifiant du client, l’URL de découverte du royaume et, uniquement si elle peut le protéger, un secret. En SAML 2.0, on configure l’identifiant de l’application, son URL de réception des assertions et l’échange des métadonnées avec Keycloak.

Doit-on héberger Keycloak soi-même pour mettre en place le SSO ?

Non. Un Keycloak auto-hébergé impose de gérer installation, mises à jour, sécurité et disponibilité. Une offre managée, comme Keycloak as a Service de Clever Cloud, prend en charge cette exploitation ; les équipes restent responsables des clients, des utilisateurs, des droits et des politiques d’authentification.

Peut-on sécuriser une application existante sans modifier son code ?

Oui. Un proxy d’authentification comme OAuth2-Proxy, relié à Keycloak, peut imposer une connexion avant de transmettre les requêtes à l’application, sans modifier son code. Cette approche convient notamment aux back-offices et aux outils internes qui n’intègrent pas d’authentification, à condition que l’application ne soit pas accessible directement en contournant le proxy. Les éventuelles règles d’autorisation propres à l’application restent à définir.

Clever Cloud annonce l'ouverture de deux nouvelles zones de disponibilité (Availability Zones ou AZ) en région parisienne, au sein des data centers ETIX Paris #3 à Vélizy-Villacoublay et Telehouse TH3 à Magny-les-Hameaux. Avec ces deux sites mis en service en 2026, l'entreprise dispose désormais de cinq AZ autour de Paris, contre trois auparavant.

Cette extension permet d'augmenter et de renouveler les capacités d'hébergement de Clever Cloud, mais surtout de renforcer la résilience de son infrastructure.

Cinq zones de disponibilité, une seule infrastructure distribuée

C'est le principe sur lequel repose l'architecture de Clever Cloud. Les ressources informatiques sont réparties entre plusieurs zones de disponibilité, situées dans des bâtiments éloignés et distincts, mais orchestrées au sein d'une même plateforme.

Cette organisation permet de distribuer les charges de travail entre plusieurs infrastructures physiques, tout en limitant la dépendance à un site unique. En cas d'incident matériel, électrique ou réseau affectant une implantation, les autres zones restent disponibles et les ressources se redéploient de façon automatisée, ce qui permet de limiter les conséquences d'une défaillance localisée sur le fonctionnement global de la plateforme.

Le passage à cinq zones de disponibilité permet également le renforcement des solutions distribuées de Clever Cloud, qui peuvent désormais supporter la perte simultanée de deux data centers tout en restant disponibles, contre un seul avec trois zones. La résilience repose ainsi moins sur la fiabilité de chaque équipement que sur la capacité de l’infrastructure à continuer de fonctionner malgré la perte de plusieurs sites.

Deux nouvelles implantations en région parisienne

Les deux nouvelles zones viennent compléter les trois implantations déjà exploitées par Clever Cloud autour de Paris.

La première a été ouverte chez ETIX, au sein du data center Paris #3, à Vélizy-Villacoublay. La seconde se trouve chez Telehouse, sur le site TH3 de Magny-les-Hameaux, et vient compléter la présence historique de Clever Cloud chez cet opérateur, notamment au sein de son data center TH2 à Paris.

Ces ouvertures permettent aussi à Clever Cloud d'augmenter ses capacités d'hébergement afin de répondre aux besoins créés par sa croissance.

Des équipements européens pour une infrastructure maîtrisée

Le choix des data centers n'est pas le seul élément de cette extension. Clever Cloud a également décidé de privilégier des industriels européens pour équiper ses nouvelles zones de disponibilité, notamment 2CRSI, constructeur français de serveurs basé à Strasbourg, et Nokia, groupe technologique finlandais spécialisé dans les infrastructures réseau.

Ce choix s'inscrit dans une stratégie de maîtrise de l'infrastructure qui va au-delà de la localisation des données. Clever Cloud exploite ses propres serveurs, son réseau et développe les technologies logicielles qui permettent d'orchestrer sa plateforme.

En s'appuyant sur des fournisseurs européens, l'entreprise entend également contribuer au développement d'une filière industrielle capable de fournir les équipements nécessaires au fonctionnement des infrastructures numériques. Une manière de faire de l'autonomie stratégique un choix concret, depuis le matériel jusqu'aux services proposés aux clients.

« Notre objectif n'est pas simplement d'ajouter des serveurs dans de nouveaux data centers. Nous avons conçu Clever Cloud comme une infrastructure distribuée, capable de fonctionner sur plusieurs sites orchestrés ensemble. Avec cinq zones de disponibilité autour de Paris, nous renforçons fortement notre résilience. Et puisque nous investissons dans de nouveaux équipements, nous faisons également le choix de travailler avec des industriels européens comme 2CRSI et Nokia. Pour nous, l'autonomie stratégique ne se résume pas à héberger des données en France : elle passe aussi par la maîtrise des technologies et le développement de notre industrie. » Quentin Adam, CEO de Clever Cloud

FAQ

Qu'est-ce qu'une zone de disponibilité (AZ) dans le cloud ?

Une zone de disponibilité (Availability Zone ou AZ) est un ensemble de ressources informatiques hébergées dans une infrastructure physique distincte, au sein d'une même région cloud. La répartition des ressources entre plusieurs AZ permet de limiter la dépendance à un site unique et de renforcer la résilience des services en cas de défaillance matérielle, électrique ou réseau.

Chez Clever Cloud, les cinq zones de disponibilité de la région parisienne sont orchestrées au sein d'une même plateforme cloud.

Pourquoi cinq zones de disponibilité renforcent-elles la résilience ?

En répartissant les ressources entre cinq zones de disponibilité plutôt que trois, Clever Cloud augmente sa capacité à maintenir ses services distribués en fonctionnement malgré des défaillances d'infrastructure.

Cette architecture permet notamment aux solutions distribuées concernées de supporter la perte simultanée de deux data centers, contre un auparavant, sous réserve des mécanismes de réplication et de redondance propres à chaque service.

Les cinq AZ permettent également d'augmenter les capacités d'hébergement et de mieux répartir les charges de travail entre plusieurs infrastructures physiques.

À Devoxx Belgium, nous avons lancé un défi aux développeurs : créer et déployer une véritable application, avec une vraie base de données, en une quinzaine de minutes. Un petit coup de pouce de l'IA, une touche belge et quelques LEGO pour la motivation. Voici ce que ça a donné.

Ça fait presque 20 ans que je vais à Devoxx Belgium. C'est une conférence qui compte énormément pour moi, aussi bien personnellement que professionnellement. C'est là que j'ai eu l'idée de créer ce qui allait devenir FinistDevs, là que j'ai commencé à m'imaginer un jour sur scène en tant que speaker, et là aussi que, quelques années plus tard, j'ai découvert que les Developer Relations pouvaient être un vrai métier.

Alors, quand Clever Cloud a décidé de sponsoriser Devoxx Belgium cette année, j'étais particulièrement heureux.

Mais avant de partir pour Anvers, il y avait une question que je me posais : qu'est-ce qu'on pourrait proposer sur notre stand qui soit vraiment intéressant pour les développeurs ?

Bien sûr, on voulait faire découvrir Clever Cloud. C'est quand même une des raisons pour lesquelles les entreprises sponsorisent des conférences de développeurs.

Mais je n'avais pas envie de passer trois jours à expliquer aux visiteurs à quel point c'est facile de déployer une application sur notre plateforme.

Je voulais qu'ils le découvrent par eux-mêmes.

Et c'est comme ça qu'est né le 15-minute Clever Cloud Challenge.

Stop Prompting. Start Shipping.

Le principe était tout simple.

Venez sur notre stand. Ouvrez votre ordinateur. Créez une petite application. Connectez-la à une vraie base de données. Déployez le tout sur Clever Cloud.

Et faites ça en une quinzaine de minutes.

Il n'y avait que quelques règles :

• N'importe quelle stack. JavaScript, Python, Java, Go, ce que vous préférez.
• N'importe quelle IA. Claude, ChatGPT, Gemini, Copilot ou votre agent de code préféré. Peu importe.
• Une petite touche belge. Frites, bière, BD, cyclisme, Magritte, Devoxx lui-même. Tout ce qui pouvait avoir un rapport, même lointain, avec la Belgique.
• Une vraie base de données et un vrai déploiement. Pas une maquette, pas une capture d'écran, pas une application qui tourne uniquement sur votre ordinateur. Quelque chose d'accessible publiquement, avec des données qui persistent réellement.

Et comme les 15 minutes étaient un objectif, pas une raison de pénaliser quelqu'un qui passait un peu plus de temps à déboguer, on n'était pas particulièrement stricts sur le chronomètre.

L'important, c'était de déployer quelque chose.

Nous avions préparé une page dédiée au challenge avec les instructions, un prompt de démarrage à copier dans son assistant IA préféré et un coupon offrant 200 € de crédits Clever Cloud, valables six mois.

Le prompt proposait trois idées de petites applications, aidait le participant à en choisir une, puis l'accompagnait dans le développement, la création de la base de données et le déploiement.

On avait aussi prévu une petite motivation supplémentaire : chaque personne ayant terminé le challenge pouvait participer à un tirage au sort quotidien pour gagner des LEGO. Parce que bon, des LEGO, quoi.

Mais il n'y avait ni jury, ni classement, ni récompense pour l'application la plus sophistiquée. Une toute petite application fonctionnelle avait exactement les mêmes chances de gagner qu'un projet ambitieux.

On n'organisait pas un hackathon, on invitait les développeurs à découvrir une plateforme en l'utilisant vraiment.

40 développeurs. 48 applications déployées.

Et ça a marché.

Pendant les trois jours, 40 développeurs ont créé et déployé une application avec une véritable base de données sur Clever Cloud.

Je voudrais insister un instant sur ce chiffre.

Pas 40 personnes qui ont scanné un QR code. Pas 40 adresses email récupérées sur un stand. Pas 40 coupons distribués.

40 développeurs qui ont réellement construit quelque chose, provisionné une base de données, déployé leur application et sont revenus nous montrer ce qu'ils avaient créé.

Pour moi, c'est un résultat beaucoup plus intéressant que le nombre de personnes passées devant notre stand.

Et le meilleur dans tout ça ? Ce qu'ils ont construit.

Nous avions volontairement laissé le challenge très ouvert. Pas d'application modèle, pas de tutoriel imposé que tout le monde devait suivre.

On donnait aux participants un objectif, quelques contraintes et la liberté d'être créatifs. Les résultats ont été bien plus variés que ce que j'imaginais.

Quelques-unes de mes applications préférées

Impossible de présenter les 48 applications ici, mais j'avais envie de partager quelques-unes de celles qui m'ont particulièrement marqué.

Pas forcément parce qu'elles étaient les plus sophistiquées techniquement, mais parce qu'elles étaient amusantes, originales ou qu'elles exploitaient particulièrement bien les contraintes du challenge.

It's Raining Devs : quand Magritte rencontre Devoxx

Essayer It's Raining Devs

Celle-ci fait probablement partie de mes préférées.

Prenez les tableaux surréalistes de René Magritte, ajoutez une foule de développeurs participant à Devoxx et transformez le tout en une œuvre interactive et collaborative.

Les participants peuvent créer leur propre personnage flottant, choisir ce qui lui cache le visage, lui donner un nom et rejoindre le tableau.

Et ces développeurs ne sont pas de simples éléments affichés temporairement dans un navigateur. Chacun est enregistré dans PostgreSQL sur Clever Cloud.

Il y a même de petites interactions, un appel des participants et des cartes postales à enregistrer ou à partager.

J'adore cette application parce qu'elle combine quelque chose de très belge, une idée vraiment ludique et une base de données qui fait partie intégrante de l'expérience.

Elle illustre aussi quelque chose que j'apprécie particulièrement dans ce genre de challenges : une petite application n'est pas obligée d'être une application ennuyeuse.

Roll for Waffle : laissez les dés décider de votre destin

Créer votre propre gaufre belge

Qu'est-ce qui se passe quand on mélange des gaufres belges et des dés polyédriques, comme ceux qu'on utilise dans les jeux de rôle sur table ?

On obtient Roll for Waffle, et j'adore le résultat.

Le concept est merveilleusement simple : au lieu de choisir les ingrédients de votre gaufre, vous laissez les dés décider.

D'abord, un lancer pour la base de la gaufre. Ensuite, un autre pour la garniture principale. Et enfin, un dernier pour la garniture secondaire.

Chaque lancer s'accompagne d'un joli dé polyédrique animé, et le résultat vient s'ajouter à votre création.

Vous allez peut-être obtenir une classique gaufre de Liège avec de la pâte de spéculoos et des fraises fraîches. Ou alors une combinaison complètement improbable qu'aucun pâtissier belge n'oserait servir.

C'est justement ce qui fait tout le charme du jeu. Vous ne choisissez pas. Les dés ont parlé.

Et une fois votre création terminée, vous pouvez partager votre chef-d'œuvre généré aléatoirement.

En tant que personne ayant passé un nombre absolument déraisonnable d'heures à lancer des dés polyédriques, cette application m'a immédiatement fait sourire.

C'est un exemple parfait de ce que j'ai aimé dans ce challenge : donnez aux développeurs un thème simple, un peu de liberté et l'occasion d'expérimenter, et ils trouveront des idées auxquelles vous n'auriez jamais pensé.

Bon, excusez-moi, j'ai une gaufre à tirer aux dés.

Devoxx Bingo : parce que chaque conférence a ses clichés

Jouer à Devoxx Bingo

Si vous avez participé à suffisamment de conférences de développeurs, vous savez que certaines choses finissent presque toujours par arriver.

Certaines expressions vont être répétées. Certaines technologies vont être mentionnées. Certains moments vont vous sembler étrangement familiers.

Alors pourquoi ne pas en faire un bingo ?

Devoxx Bingo vous propose une grille de clichés de conférence à repérer pendant l'événement. Cochez-les au fur et à mesure que vous les rencontrez et essayez de compléter une ligne.

L'application se présente comme une quête secondaire non officielle, sans le moindre prix à gagner, mais avec le droit de se vanter de sa victoire. Un droit tout à fait discutable, d'ailleurs.

Exactement le genre d'application qui me fait sourire.

Et franchement, j'imagine très bien des gens y jouer pendant une conférence.

Devoxx YouTube Search : retrouver cette conférence dont on se souvient vaguement

Explorer Devoxx YouTube Search

Vous connaissez cette sensation ? Vous vous souvenez d'avoir vu une excellente conférence, mais impossible de retrouver qui la présentait, ou même en quelle année c'était.

Avec presque deux décennies de conférences enregistrées, Devoxx a constitué une incroyable bibliothèque de connaissances techniques sur YouTube. Mais retrouver une session précise n'est pas toujours évident.

C'est là qu'intervient Devoxx YouTube Search.

L'application permet de rechercher des vidéos Devoxx à partir de leurs titres et descriptions, pour retrouver plus facilement des conférences sur les sujets qui vous intéressent.

Ce que j'aime particulièrement ici, c'est le choix du sujet. Alors que beaucoup de participants ont choisi quelque chose de ludique ou de typiquement belge, ce développeur a décidé de créer un outil directement lié à la conférence et à son contenu.

C'est un joli rappel qu'un challenge comme le nôtre ne produit pas uniquement des jeux et des expérimentations. Il peut aussi inspirer des outils qui répondent à de vrais besoins de la communauté.

Et en tant que personne ayant donné pas mal de conférences au fil des années, j'apprécie forcément tout ce qui peut aider les gens à les découvrir !

BelgiQ : à quel point êtes-vous belge ?

Essayer BelgiQ

BelgiQ se présente comme « Le quiz qui a la frite ».

Ça commence déjà bien.

C'est un quiz sur le thème de la Belgique, disponible en français, en néerlandais et en anglais, avec un classement des joueurs.

Mais ce qui rend cette application particulièrement intéressante, c'est que son créateur, Gwenaël Jakab, a partagé son expérience sur LinkedIn.

Gwenaël a choisi de construire BelgiQ avec Node.js, Express et PostgreSQL. Il a utilisé ChatGPT pour préparer son prompt, puis confié l'implémentation et le déploiement à ChatGPT Work.

15 minutes plus tard, il avait une application fonctionnelle. Après 10 minutes supplémentaires à examiner le résultat, demander quelques ajustements et du refactoring, il avait une V2 dont il était satisfait.

Et il n'avait pas écrit lui-même le code de l'application.

Ce que j'ai particulièrement apprécié dans son témoignage, c'est sa vision du rôle du développeur. Même lorsqu'un agent IA prend en charge l'implémentation, il faut toujours quelqu'un pour faire les choix d'architecture, définir les besoins, relire le code et valider le résultat.

C'est une distinction importante, qui se perd parfois dans les discussions autour du développement assisté par IA.

Pour moi, son expérience illustre aussi exactement ce qu'on cherchait à montrer avec ce challenge : permettre aux développeurs de se concentrer sur ce qu'ils veulent construire, tout en découvrant à quel point il peut être simple de le déployer sur Clever Cloud.

Et le mieux dans tout ça ? Vous pouvez essayer BelgiQ vous-même.

Friesdvisor : les vraies questions de la vie

Explorer Friesdvisor

Oubliez les recommandations de restaurants.

On est en Belgique. Il faut parler de frites.

Friesdvisor est un annuaire dans lequel vous pouvez rechercher une friterie ou une ville, et ajouter de nouveaux établissements.

C'est une idée merveilleusement simple, et exactement le genre de référence belge qu'on espérait voir apparaître.

Ce que j'aime particulièrement, c'est que ce n'est pas juste une blague. C'est un concept qui pourrait devenir une petite application communautaire réellement utile.

Et évidemment, il faut bien un endroit où stocker toutes ces friteries.

48 applications et encore plein de créativité à découvrir

Ce ne sont que quelques-unes de mes préférées.

Mais une des choses que j'ai le plus aimées dans ce challenge, c'est l'incroyable diversité des idées. Donnez à 40 développeurs le même point de départ, les mêmes contraintes et une quinzaine de minutes, et vous obtenez 48 interprétations différentes de ce que peut être une petite application.

Certains ont créé des jeux. D'autres des outils pratiques. Certains ont puisé leur inspiration dans la culture belge, tandis que d'autres se sont tournés vers la conférence elle-même.

Et impossible de rendre justice à toutes ces créations dans un seul article.

C'est pour ça que nous avons créé la galerie Built at Devoxx Belgium, dans laquelle vous pouvez découvrir les applications que les participants ont choisi de partager publiquement.

👉 Découvrir la galerie du Clever Cloud Challenge

Allez y faire un tour. Essayez les applications. Découvrez ce que les participants ont imaginé.

Et si l'une d'entre elles vous fait sourire, ou vous donne une idée de quelque chose que vous aimeriez construire vous-même, alors je pense que notre petite expérience aura déjà accompli quelque chose de plutôt chouette.

Qu'est-ce qu'on a appris ?

Plusieurs choses m'ont marqué pendant ces trois jours.

D'abord, les développeurs sont incroyablement créatifs quand on leur donne juste assez de contraintes.

Le thème belge était volontairement vague. On ne voulait pas que les participants passent dix minutes à se demander si leur idée était recevable.

Un plat belge ? Parfait.

Une référence à un artiste belge ? Excellent.

Une blague sur Devoxx ? Évidemment.

Cette petite contrainte créative donnait un point de départ sans imposer ce qu'il fallait construire.

Ensuite, les assistants de développement IA rendent ce genre d'exercice beaucoup plus accessible.

Tout le monde n'arrivait pas avec une idée d'application, un framework préféré ou une connaissance précise de la manière de provisionner et connecter une base de données. Mais avec un peu d'accompagnement, les participants pouvaient passer d'une idée à quelque chose qui tournait en ligne étonnamment vite.

L'expérience de Gwenaël avec BelgiQ illustre un autre point important : le développement assisté par IA ne fait pas disparaître le développeur. Il change la manière dont celui-ci utilise son temps.

Le développeur continue à prendre les décisions, définir les besoins, examiner les résultats et assumer la responsabilité de ce qui est livré. Pendant ce temps, l'agent de code peut prendre en charge une bonne partie de l'implémentation, et la plateforme s'occupe de l'infrastructure.

Bien sûr, l'IA ne faisait pas disparaître magiquement tous les problèmes. Il y avait toujours des questions de déploiement, des soucis de configuration et des moments où quelqu'un avait besoin d'un petit coup de main. C'est aussi pour ça qu'on était là.

Mais la combinaison du développement assisté par IA et d'une plateforme qui prend en charge l'infrastructure permettait de se concentrer sur la partie intéressante : construire et déployer l'application. Et c'est exactement ce qu'on voulait faire découvrir aux participants avec Clever Cloud.

Enfin, cette expérience m'a rappelé quelque chose de fondamental dans les Developer Relations.

Montrer aux gens comment quelque chose fonctionne, c'est utile. Leur permettre de le découvrir par eux-mêmes, c'est encore mieux.

J'aurais pu passer quinze minutes à expliquer comment Clever Cloud gère les déploiements, les bases de données, les variables d'environnement et l'hébergement des applications. À la place, les développeurs ont passé ces quinze minutes à le faire. Et à la fin, ils avaient quelque chose à eux à nous montrer.

Ça change complètement la conversation qu'on peut avoir sur un stand de conférence.

Et maintenant ?

Le challenge ne doit pas forcément s'arrêter à Devoxx.

Tous les participants ont reçu 200 € de crédits Clever Cloud, valables six mois après leur activation. De quoi continuer à expérimenter, améliorer leur application ou commencer quelque chose de complètement différent.

Nous réfléchissons aussi à la manière de prolonger l'expérience avec de nouveaux petits défis, pour encourager les participants à explorer davantage la plateforme.

Et j'aimerais vraiment renouveler cette expérience dans d'autres conférences.

Le thème belge a merveilleusement bien fonctionné à Devoxx Belgium. Imaginez ce que les développeurs pourraient inventer dans d'autres villes ou d'autres pays.

On a déjà quelques idées.

À votre tour. Stop Prompting. Start Shipping !

J'ai participé à énormément de conférences de développeurs au fil des années, des deux côtés du stand. J'ai distribué des stickers, offert des T-shirts, fait des démonstrations, répondu à des questions techniques et eu d'innombrables conversations autour des plateformes cloud. Et j'aime toujours autant tout ça.

Mais voir quelqu'un arriver sur notre stand avec rien de plus qu'une idée, puis revenir un peu plus tard avec une application fonctionnelle déployée sur Clever Cloud ? Ça, c'était particulièrement satisfaisant.

Et découvrir la créativité de ces 40 développeurs a rendu toute cette expérience encore plus intéressante.

Alors, à toutes celles et ceux qui ont participé au challenge à Devoxx Belgium : merci !

Merci d'avoir pris le temps de découvrir Clever Cloud, d'avoir joué le jeu de notre thème belge un peu farfelu et, surtout, de nous avoir montré vos créations.

Envie d'essayer ?

Bonne nouvelle : pas besoin d'avoir participé à Devoxx pour relever le défi !

Le challenge original de Devoxx Belgium est toujours en ligne, et nous avons également créé une version générique de Stop Prompting. Start Shipping. que tout le monde peut essayer, n'importe où.

Le coupon spécial Devoxx de 200 € n'est plus disponible, mais chaque nouveau compte Clever Cloud bénéficie de 20 € de crédits gratuits, largement de quoi créer et déployer une petite application avec une base de données.

Choisissez un thème. Ouvrez votre assistant de développement IA préféré. Donnez-vous 15 minutes.

Construisez quelque chose d'amusant, connectez une base de données et déployez le tout.

Et si vous le faites, j'adorerais vraiment découvrir ce que vous avez imaginé. Partagez votre application avec moi !

Stop Prompting. Start Shipping.

Lorsque ces échanges nécessitent d’exposer publiquement les ports des différents services, la surface d’attaque s’élargit et la configuration réseau devient plus lourde à maintenir. Créer un réseau privé entre applications répond directement à ce problème, sans imposer de déployer ni d’administrer une infrastructure VPN.

Cette approche permet à des services cloud de communiquer directement entre eux, sur n’importe quel port, sans exposer sur Internet les ports nécessaires à ces échanges. Les données circulent dans un réseau overlay chiffré, indépendant du réseau physique. Sur Clever Cloud, ce sont les Network Groups qui l'assurent : ils établissent des tunnels WireGuard entre les ressources, sans configuration réseau bas niveau.

Pourquoi exposer ses services sur Internet pose problème

Quand les composants d’une application communiquent via des ports publics, chaque service exposé devient une porte d’entrée potentielle. Trois conséquences concrètes :

• Surface d’attaque élargie : chaque point d’accès public doit être protégé, surveillé et maintenu.
• Exposition inutile de ports techniques : certains protocoles nécessitent des ports dédiés pour les échanges internes, sans qu’ils aient vocation à être accessibles publiquement. Un réseau privé permet de les utiliser sans créer de nouveaux points d’entrée depuis Internet.
• Dépendance à des tunnels externes : relier des services répartis sur plusieurs zones impose habituellement de configurer et d’administrer une couche réseau supplémentaire, souvent un VPN.

Connecter les services au sein d’un réseau privé permet de faire transiter leurs échanges internes sans exposer les ports utilisés par ces communications. Cela ne désactive toutefois pas les accès publics déjà configurés. Pour que seule une API Gateway donne accès aux backends depuis Internet, il faut également bloquer leur point d’entrée public.

Le principe d’un réseau privé entre applications

Le principe repose sur un réseau overlay : une couche réseau logique construite au-dessus du réseau physique existant. Les ressources disposent d’une connectivité privée entre elles et leurs échanges sont chiffrés par défaut. Comme l’overlay est indépendant du réseau physique sous-jacent, il peut relier des ressources réparties sur plusieurs zones ou datacenters.

Prenons une application composée d’une API publique, de plusieurs services backend et d’une base de données : seule l’API est exposée sur Internet. Les services internes et la base de données communiquent entre eux via le réseau privé, sur les ports dont ils ont besoin.

Créer un réseau privé entre applications sur Clever Cloud

Cette mise en place passe par les Network Groups. Chaque ressource rattachée à un Network Group reçoit une adresse IP privée issue d’un CIDR dédié, ainsi qu’un nom de domaine interne de la forme « <memberID>.m.<ngID>.cc-ng.cloud ». Les ressources se joignent alors directement, sur n’importe quel port, sans étape de configuration réseau.

Un Network Group peut relier des applications Clever Cloud, des add-ons et des machines externes au sein du même réseau privé. Les échanges sont chiffrés via WireGuard, un protocole reconnu pour sa simplicité et sa rapidité.

Les Network Groups peuvent être créés et administrés depuis la Console Clever Cloud, les Clever Tools (CLI) ou l’API publique. En ligne de commande, par exemple : 

clever features enable ng
clever ng create monNG --link app_xxx,postgresql_xxx

À noter : la compatibilité avec les add-ons dépend de leur génération. Les add-ons déployés depuis 2024 sont compatibles ; les plus anciens peuvent nécessiter une migration ou un redémarrage. Consultez la documentation pour connaître les limitations actuelles.

Dans quels cas utiliser un réseau privé entre applications ?

Les Network Groups ne constituent pas une solution autonome : ils rendent possibles certaines architectures sécurisées plutôt qu’ils ne remplacent un produit existant. Plusieurs cas d’usage reviennent fréquemment.

• Protéger des applications derrière une API gateway : les backends restent injoignables depuis l’extérieur tout en étant accessibles depuis la gateway. 
• Déployer Keycloak en haute disponibilité : plusieurs instances Keycloak se synchronisent via le réseau privé sans être exposées publiquement.
• Faire communiquer des microservices : dans une architecture distribuée, les services échangent en permanence sans ouvrir de ports publics ni configurer de tunnels.
• Intégrer des ressources externes : relier une machine locale ou un serveur tiers à vos applications Clever Cloud via un canal chiffré.

Connecter ses services sans la complexité d’un VPN

Avec les Network Groups, la connectivité privée devient une capacité de la plateforme plutôt qu’une infrastructure à construire et maintenir. Vous choisissez les ressources qui doivent communiquer ; Clever Cloud établit entre elles le réseau privé chiffré. Vous pouvez ainsi utiliser les ports nécessaires à vos échanges internes sans les exposer publiquement, que vos ressources soient dans une même zone, réparties entre plusieurs datacenters ou, selon le cas, externes à Clever Cloud.

FAQ

Quelle est la différence entre un VPN et un réseau privé entre applications ?

La différence tient surtout à ce que vous avez à administrer. Avec un VPN classique, vous devez généralement déployer, configurer et maintenir la connectivité entre les machines ou réseaux concernés. Avec les Network Groups, Clever Cloud gère cette couche pour vous : vous rattachez les ressources au groupe et la plateforme établit la connectivité privée chiffrée via WireGuard.

Faut-il modifier le code de ses applications pour utiliser les Network Groups ?

Dans la plupart des cas, non. Il n'est pas nécessaire de réécrire votre application. Le changement porte sur la configuration, pas sur le code : l'application appelante doit cibler le service de destination via son nom de domaine interne au Network Group (<memberID>.m.<ngID>.cc-ng.cloud) et le port voulu, généralement au travers d'une variable d'environnement. Aucune bibliothèque spécifique ni adaptation applicative n'est requise pour que le trafic emprunte le réseau privé.

Un réseau privé entre applications fonctionne-t-il avec des machines externes à Clever Cloud ?

Oui. Un Network Group peut connecter des applications Clever Cloud, des add-ons et des machines externes dans le même réseau privé. Le rattachement d’un pair externe relève toutefois de fonctionnalités encore en cours de stabilisation pendant la phase de test.

Un réseau privé rend-il une application invisible depuis Internet ?

Non, pas en soi. Les Network Groups permettent d’accéder à des ressources en privé, mais ne servent pas à couper une application d’Internet. Restreindre l’exposition publique relève d’autres mécanismes de la plateforme.

Face à la CLI Clever Cloud, un assistant sans contexte fait ce qu'il peut : il devine. Il invente une option qui n'existe pas, mélange la syntaxe d'une ancienne version avec celle d'aujourd'hui, ou se rabat sur des commandes git push à la main. Ça finit souvent par marcher, après quelques allers-retours.

Clever Tools embarque maintenant un skill : un petit paquet de connaissances que votre assistant charge quand il en a besoin, et qui lui apprend la CLI depuis sa source plutôt que par approximation. Dans ce billet, on l'installe, puis on le regarde travailler sur un vrai déploiement : une application de todo adossée à Materia KV.

Qu'est-ce qu'un skill ?

Un skill, c'est un dossier qui contient un fichier SKILL.md. Ce fichier commence par un nom et une description, suivis d'instructions en Markdown, et peut s'accompagner de fichiers de référence. Le format est ouvert, c'est la spécification Agent Skills, et il est reconnu par Claude Code, Cursor, Codex, Copilot et d'autres.

Le principe est économe. Au démarrage, l'assistant ne lit que le nom et la description de chaque skill installé. Il ne charge le contenu complet que lorsque la tâche le demande : vous parlez de déployer sur Clever Cloud, il ouvre le skill clever-tools. Le reste du temps, il ne coûte rien à votre contexte.

Le nôtre vit dans le dépôt de Clever Tools, à côté du code de la CLI. Il contient un aide-mémoire des commandes essentielles (déploiement, logs, variables d'environnement, domaines, add-ons, scaling, SSH) et une référence complète de toutes les commandes, options, runtimes, add-ons et zones. Comme il évolue dans le même dépôt que la CLI, il suit ses versions.

Installation

Il vous faut Node.js pour npx, et Clever Tools installé et connecté à votre compte (clever login). Ensuite, une seule commande :

npx skills add CleverCloud/clever-tools

skills est l'installeur de l'écosystème Agent Skills. Il clone le dépôt, trouve le skill clever-tools, puis vous pose deux questions :

• pour quels assistants l'installer : Claude Code, Cursor, Codex… ;
• où l'installer : dans le projet courant uniquement, ou globalement pour tous vos projets.

Si vous déployez sur Clever Cloud depuis plusieurs projets, l'installation globale est la plus pratique. Si vous voulez que toute l'équipe en profite, installez-le dans le projet et commitez-le avec le reste.

Deux commandes vous serviront ensuite : npx skills list pour voir ce qui est installé, et npx skills update pour récupérer la dernière version du skill quand la CLI évolue.

Vous croiserez peut-être npx add-skill dans de vieilles documentations : c'est l'ancien nom du même outil, qui affiche désormais un avertissement et redirige vers npx skills add.

Une session réelle

Pour voir ce que ça donne, j'ai demandé à Claude Code, avec le skill installé, une chose simple : « fais une petite application de todo qui utilise Materia KV comme s'il s'agissait d'un Redis, et déploie-la sur Clever Cloud ».

Materia KV est notre base clé-valeur serverless, construite sur FoundationDB et répliquée sur trois datacenters à Paris. Elle parle le protocole Redis : n'importe quel client Redis fonctionne, sans SDK spécifique.

Ce qui suit, ce sont les commandes que l'assistant a réellement lancées, avec leur sortie.

L'application et sa base

Après avoir écrit une petite application Node.js (un serveur HTTP, une page HTML, le client redis officiel), l'assistant a créé l'application et l'add-on :

$ clever create --type node todo-kv --region par
✓ Application todo-kv successfully created!

$ clever addon create kv todo-kv-store --plan base --region par --link todo-kv
Add-on created and linked to application todo-kv successfully!
/!\ The Materia KV provider is in beta testing phase

Le --link fait le travail de branchement : à la création, l'add-on est lié à l'application, et ses variables d'environnement lui sont injectées. L'assistant a vérifié qu'elles étaient bien là :

$ clever env
KV_HOST=…
KV_PORT=…
KV_TOKEN=…
REDIS_HOST=…
REDIS_PORT=…
REDIS_PASSWORD=…
REDIS_URL=…
…

Les alias REDIS_* sont là pour ça : une application qui attend un Redis trouve ce qu'elle cherche sans changer une ligne de configuration.

Un détail intéressant s'est glissé ici. Avant d'écrire le code, l'assistant est allé lire la documentation de Materia KV, en Markdown, et y a trouvé la liste des commandes supportées. Materia KV ne supporte pas encore les listes Redis (LPUSH, LRANGE). Plutôt qu'une liste, les todos sont donc rangés dans un hash, avec un compteur pour les identifiants :

const id = await kv.incr('todos:next-id');
await kv.hSet('todos', String(id), JSON.stringify({ id, title, done: false }));

Deployment

$ clever deploy
   ✓ Code pushed to Clever Cloud (0.6s)
   ✓ Deployment started
Starting with Node.js v24.21.0
Installing dependencies…
todo-kv listening on 8080
Response from GET / is 200 (within expected range 200...500)
Successfully deployed in 0 minutes and 7 seconds

✓ Access your application: https://app-….cleverapps.io/

clever deploy pousse le code et suit le déploiement jusqu'au bout, logs compris. Pour l'assistant, c'est précieux : il voit le résultat dans la même commande, sans aller le chercher ailleurs.

Vérifier, de l'application jusqu'à la base

L'assistant a ensuite testé l'API en ligne : création de trois todos, passage de l'un d'eux à « fait », lecture de la liste. Puis il est allé vérifier directement dans Materia KV avec clever kv, qui envoie une commande brute à la base sans installer redis-cli.

Premier accroc : clever kv n'apparaissait pas dans l'aide. La commande est une fonctionnalité expérimentale, qu'il faut d'abord activer. L'assistant a listé les fonctionnalités avec clever features, trouvé la bonne, et l'a activée :

$ clever features enable kv
Experimental feature 'kv' enabled

$ clever kv todo-kv-store PING
PONG

$ clever kv todo-kv-store HGETALL todos
[
  '1', '{"id":1,"title":"Écrire le billet sur le skill","done":false}',
  '2', '{"id":2,"title":"Tester npx skills add","done":true}',
  '3', '{"id":3,"title":"Ouvrir une PR sur le SKILL.md","done":false}'
]

Les données écrites par l'application sont bien là, dans le format attendu.

Lire les logs

Dernière étape, demander ce qui se passe dans l'application :

$ clever logs --app todo-kv --since 15m --until 1m
…
todo-kv listening on 8080
Successfully deployed in 0 minutes and 7 seconds
KV error SocketClosedUnexpectedlyError: Socket closed unexpectedly

Une erreur, trois minutes après la dernière requête. L'assistant l'a lue, a fait l'hypothèse d'une connexion inactive fermée côté serveur, et l'a vérifiée : le client redis se reconnecte tout seul, et une nouvelle écriture sur l'API passait sans problème. Rien à corriger, mais il fallait le constater plutôt que le supposer.

Au passage, une option utile : --until borne la lecture des logs. Sans elle, clever logs --since 15m continue de suivre le flux indéfiniment, ce qui convient à un humain devant son terminal, beaucoup moins à un assistant qui attend que la commande se termine. L'assistant l'a appris à ses dépens avec clever accesslogs, qui a suivi le flux sans jamais rendre la main, et qu'il a fini par interrompre.

Ce qu'il faut en retenir

Toute la session a tenu en une douzaine de commandes. La plupart ont fait ce que l'assistant attendait d'elles du premier coup, et c'est ce que le skill apporte : la bonne commande, avec les bonnes options, sans tâtonner.

Ce qui rend l'exercice efficace, c'est aussi la boucle courte entre une commande et son résultat. Lancer, lire la sortie, corriger : clever deploy qui montre les logs de build, clever env qui montre ce qui a été injecté, clever kv qui montre ce qui est vraiment en base. L'assistant ne travaille jamais à l'aveugle.

La session a aussi montré les limites actuelles du skill, et c'est tant mieux : la nécessité d'activer clever features enable kv n'y figurait pas, pas plus que le comportement de --until. Ce sont deux lignes à ajouter au SKILL.md, et c'est exactement le genre de retour qu'on attend.

Skill ou serveur MCP ?

Le skill n'est pas la seule porte d'entrée pour un assistant. Clever Cloud propose aussi un serveur MCP, qui donne à l'assistant un accès direct à l'API sans passer par la CLI, à travers trois outils : search pour découvrir les opérations, execute pour les appeler, doc pour lire la documentation. Et toute la documentation est lisible en Markdown, avec un index llms.txt qui permet à un assistant de trouver la bonne page sans parcourir le site.

Les trois se complètent. Le skill est le point de départ le plus simple : une commande d'installation, et votre assistant parle couramment Clever Tools. Le serveur MCP sert quand vous voulez aller au-delà de ce que la CLI expose. La documentation en Markdown, on l'a vu avec Materia KV, sert dans tous les cas. Tout cela est décrit sur la page Drive Clever Cloud from an AI agent de notre documentation.

En résumé

npx skills add CleverCloud/clever-tools

Une commande, deux questions, et votre assistant sait déployer sur Clever Cloud, gérer vos add-ons, vos variables d'environnement et lire vos logs, avec la CLI telle qu'elle est aujourd'hui.

Le skill est open source et vit dans le dépôt de Clever Tools. Il s'améliore comme le reste du code : si votre assistant bute sur une commande, ouvrez une issue ou une PR sur le SKILL.md. Et pour nous dire ce qui fonctionne, ce qui coince et ce qu'il vous manque, la discussion est ouverte sur notre communauté GitHub.

Développé avec Please Open It, spécialiste du SSO et de la gestion des identités, le service permet de déployer en quelques clics un IAM complet sur une infrastructure dédiée, tout en confiant à Clever Cloud et Please Open It son exploitation, ses mises à jour et son maintien en conditions opérationnelles.

Comme nous l'avions évoqué à l'occasion de son passage en disponibilité générale, nous avons travaillé à une tarification permettant son usage à la fois par les développeurs, "solopreneurs", les associations, ainsi que par des entreprises et autres grands comptes. Cette tarification entrera en vigueur à compter du 1er novembre 2026. La première facture concernée sera donc celle émise début décembre 2026.

Nous vous recommandons également de regarder le nombre d'utilisateurs actifs de vos instances afin d'estimer l'impact de cette nouvelle grille sur votre facture > Nous vous recommandons également d'analyser le nombre d'utilisateurs actifs de vos instances afin d'estimer l'impact de cette nouvelle grille sur votre facture. Cette information sera ajoutée au au tableau de suivi Keycloak avant la mise en place de la nouvelle tarification.

Pourquoi la tarification évolue

Keycloak as a Service ne se résume pas à l’hébergement d’une instance Keycloak.

Chaque service repose sur plusieurs ressources dédiées — une application Java, une base de données PostgreSQL et un File System Bucket — auxquelles s’ajoutent l’exploitation et le maintien en conditions opérationnelles du service.

Cela comprend notamment :

• le suivi des versions de Keycloak et la qualification des mises à jour avant leur mise à disposition ;
• le traitement des vulnérabilités de sécurité, particulièrement critique pour un composant d’authentification ;
• la préconfiguration et la simplification de nombreux éléments, notamment les thèmes, plugins, métriques ou imports et exports de realms ;
• les sauvegardes, l’observabilité et le support associés ;
• les fonctionnalités développées autour du service, notamment les instances multiples sécurisées, le filtrage par IP, les métriques et les tableaux de bord Grafana ;
• la poursuite du développement du produit avec Please Open-It.

Pendant la phase de lancement, une partie de ce service managé n’était pas facturée distinctement. L’entrée en vigueur de cette nouvelle tarification permet désormais de prendre en compte l’ensemble du service et de poursuivre son développement.

Cette évolution s’accompagne également d’une augmentation de la taille minimale des instances Keycloak as a Service. Le tarif de base, jusqu’ici de 37,25 € par mois pour la configuration minimale, évoluera ainsi à 47 € par mois à compter du 1er novembre 2026.

Ce qui change dans la facturation

Jusqu’à présent, la facturation de Keycloak as a Service reposait principalement sur les différentes ressources techniques utilisées par le service : runtime Java, base PostgreSQL et stockage.

La configuration minimale était ainsi facturée 37,25 € par mois. À partir du 1er novembre 2026, la taille minimale de l’instance évolue et le prix de base du service passe à 47 € par mois.

À partir du 1er novembre, la facturation suivra une logique plus directement liée au service Keycloak lui-même et à son utilisation.

Elle se compose de deux éléments :

• un prix mensuel par service, fixé à 47 € HT, qui inclut jusqu’à 100 utilisateurs actifs par mois ;
• un prix complémentaire par utilisateur actif, avec un tarif dégressif selon le volume d’utilisateurs.

Un utilisateur actif correspond à un utilisateur ayant eu au moins une session active au cours du mois, par exemple à la suite d’une connexion ou d’un rafraîchissement de token.

À partir de quand cette tarification s’applique-t-elle ?

Il faut distinguer la date à laquelle les consommations commencent à être relevées de la date à laquelle elles apparaissent sur votre facture.

Concrètement, votre première facture concernée sera celle émise début décembre 2026, au titre de votre consommation du mois de novembre.

La part variable reste directement liée à l’utilisation réelle du service.

Comment anticiper l’évolution de votre facture ?

Aucune action n’est nécessaire pour continuer à utiliser Keycloak as a Service : vos services existants continueront à fonctionner normalement.

Vous pouvez néanmoins profiter des prochaines semaines pour vérifier les instances actuellement actives dans votre organisation, notamment les environnements de test ou de recette qui ne seraient plus utilisés.

Nous vous recommandons également de regarder le nombre d’utilisateurs actifs de vos instances afin d’estimer l’impact de cette nouvelle grille sur votre facture.

Si vous souhaitez obtenir une estimation plus précise, nos équipes peuvent examiner avec vous votre configuration et votre niveau d’utilisation afin de réaliser une simulation.

Contactez-nous pour faire le point avec nos équipes.

Pour une Direction des Systèmes d'Information (DSI), SAML 2.0 répond à une question concrète : comment donner à un collaborateur l'accès à des dizaines d'applications avec une seule authentification, tout en centralisant les politiques d’authentification auprès d’un fournisseur d’identité.

Qu'est-ce que SAML 2.0 ?

Cette centralisation de l'authentification, c'est précisément ce que normalise SAML. Le standard a été approuvé dans sa version 2.0 par l'OASIS (Organization for the Advancement of Structured Information Standards) en mars 2005, au plus haut niveau de ratification, en unifiant trois travaux antérieurs : SAML 1.1, le profil Liberty Alliance ID-FF 1.2 et les contributions du projet Shibboleth. Il a également été repris comme recommandation internationale par l'Union internationale des télécommunications (ITU-T X.1141).

Techniquement, le protocole SAML repose sur des assertions : des jetons de sécurité au format XML qui décrivent un utilisateur (le "principal") et son authentification. Ces assertions sont échangées entre deux rôles :

• le fournisseur d'identité (Identity Provider, ou IdP), qui authentifie l'utilisateur ;
• le fournisseur de service (Service Provider, ou SP), c'est-à-dire l'application à laquelle l'utilisateur veut accéder.

Plus de vingt ans après sa ratification, SAML 2.0 n'est pas un protocole hérité : il reste largement déployé dans l'entreprise, le secteur public et le monde académique, où il constitue toujours un socle de la fédération d'identités.

Comment fonctionne l'authentification SAML ?

L'authentification SAML fait intervenir trois acteurs : l'utilisateur, le fournisseur d'identité (IdP) et le fournisseur de service (SP). Dans le scénario le plus courant, dit “initié par le fournisseur de service”, l'échange se déroule ainsi :

La confiance entre l'IdP et le SP ne s'improvise pas : elle est établie au préalable par un échange de métadonnées (certificats, points d'accès, identifiants), qui permet à chaque partie de vérifier l'authenticité des messages de l'autre. C'est la signature cryptographique de l'assertion qui garantit qu'elle provient bien du fournisseur d'identité attendu et n'a pas été altérée.

Les composants du standard SAML 2.0

Le standard SAML 2.0 s'organise en plusieurs briques normatives complémentaires :

• Les assertions : les énoncés eux-mêmes, qui peuvent porter trois types d'information : l'authentification, les attributs (rôle, service, adresse e-mail…) et, plus rarement utilisée, la décision d'autorisation.
• Les protocoles : les messages de requête et de réponse qui transportent les assertions.
• Les liaisons (bindings) : la manière dont ces messages circulent sur le web, par exemple via une redirection HTTP ou un envoi HTTP POST.
• Les profils : les combinaisons prêtes à l'emploi pour un usage donné, dont le plus connu est le profil d'authentification unique par navigateur web (Web Browser SSO Profile).
• Les métadonnées : la description technique échangée entre IdP et SP pour établir la confiance.

À noter : bien que SAML puisse transporter des décisions d'autorisation, son usage dominant reste l'authentification unique et le transport d'attributs. L'autorisation fine est le plus souvent gérée par d'autres mécanismes.

SAML 2.0, OAuth 2.0 et OpenID Connect : quelles différences ?

Ces trois standards sont souvent confondus alors qu'ils ne répondent pas à la même question :

• SAML 2.0 traite de l'authentification et de l'authentification unique. Fondé sur XML, il est très implanté dans les environnements d'entreprise, la fédération inter-organisations et le secteur public.
• OAuth 2.0 traite de l'autorisation : il délègue un accès à une ressource ("cette application peut-elle lire mon agenda ?") et ne gère pas, à lui seul, l'authentification.
• OpenID Connect (OIDC) ajoute à OAuth 2.0 une couche d’authentification qui permet à une application d’établir l’identité de l’utilisateur, notamment grâce à un jeton d’identité (ID token) au format JWT. Il est adapté aux applications web et mobiles ; l’accès aux API s’appuie, quant à lui, sur les jetons d’accès d’OAuth 2.0.

En pratique, SAML 2.0 et OpenID Connect coexistent : le premier reste la référence pour l'existant applicatif d'entreprise, le second pour les nouveaux développements.

Mettre en œuvre SAML 2.0 avec Keycloak

Pour déployer SAML 2.0 sans réimplémenter le protocole, la voie la plus courante est de s'appuyer sur une solution de gestion des identités et des accès (Identity and Access Management, ou IAM). Keycloak, logiciel open source de référence dans ce domaine, peut agir comme fournisseur d'identité SAML 2.0 et prend aussi en charge OpenID Connect, ce qui permet de faire cohabiter applications historiques en SAML et développements récents en OIDC derrière un même point d'authentification.

Clever Cloud propose Keycloak as a Service, une offre de Keycloak infogéré et hébergé en France, opérée avec l'expertise de Please Open It, partenaire spécialiste de Keycloak. Cette approche décharge les équipes de l'exploitation du serveur d'identité (mises à jour, disponibilité, sauvegardes) tout en conservant le contrôle des réglages SAML et OIDC.

« SAML 2.0 reste incontournable en entreprise en raison de son ancienneté (2005), mais aussi de sa simplicité réseau : tout passe par le navigateur de l'utilisateur, sans besoin de connexion directe entre l'application et le serveur d'identité. De son côté, le standard moderne OpenID Connect impose une communication directe de serveur à serveur pour être sécurisé : le mode "100 % navigateur" d'OIDC (le flux Implicit) étant désormais abandonné car jugé trop vulnérable. »

— Mathieu Passenaud, Co-fondateur chez Please Open It

FAQ

SAML 2.0 est-il toujours utilisé en 2026 ?

Oui. Ratifié en 2005, SAML 2.0 reste largement déployé dans l'entreprise, le secteur public et le monde académique pour l'authentification unique et la fédération d'identités. Il coexiste avec OpenID Connect, souvent privilégié pour les nouveaux projets web et mobiles.

Quelle est la différence entre SAML et le SSO ?

Le SSO (Single Sign-On, ou authentification unique) est un principe : s'authentifier une fois pour accéder à plusieurs applications. SAML est l'un des protocoles qui permettent de réaliser ce principe entre domaines ; OpenID Connect en est un autre.

SAML gère-t-il l'authentification ou l'autorisation ?

Les deux sont possibles, mais son usage dominant est l'authentification unique et le transport d'attributs. Le protocole peut porter des décisions d'autorisation, cette capacité étant toutefois rarement utilisée en pratique.

Faut-il choisir SAML 2.0 ou OpenID Connect ?

Cela dépend avant tout du protocole pris en charge par l’application. SAML 2.0 convient aux services qui attendent une fédération SAML ; OpenID Connect est généralement adapté à l’authentification des applications web et mobiles. Pour contrôler l’accès aux API, on utilise les jetons d’accès d’OAuth 2.0. Les deux approches peuvent coexister derrière un même fournisseur d’identité, comme Keycloak.

Keycloak prend-il en charge SAML 2.0 ?

Oui. Keycloak peut agir comme fournisseur d'identité SAML 2.0 et prend également en charge OpenID Connect, ce qui permet de faire cohabiter les deux protocoles.

Quatre startups, quatre produits et des usages très différents : télémédecine, agents IA, formation interactive ou pilotage hôtelier. Mais derrière cette diversité se dessine un même enjeu : celui du passage d’un produit technologique à un service réellement utilisé.

Car lorsque les premiers utilisateurs arrivent, il ne suffit plus qu’un produit fonctionne. Il doit pouvoir être déployé, exploité, sécurisé et faire face à de nouveaux usages sans que son infrastructure devienne un frein à son développement.

C’est précisément à cette étape que le Programme UP accompagne les startups sélectionnées.

Les quatre startups de la sixième promotion du Programme UP

Kernel : Simplifier l’accès à des parcours de soin en ligne

Kernel est une plateforme de télémédecine qui permet d’accéder à des parcours de soin personnalisés en ligne, notamment en dermatologie et pour la chute de cheveux.

Le parcours débute par un questionnaire médical structuré. Un médecin inscrit à l’Ordre examine ensuite le dossier, établit un diagnostic et, lorsque cela est nécessaire, rédige une ordonnance adaptée. Le traitement peut alors être préparé par une pharmacie agréée et livré au patient.

Kernel intègre également un espace de suivi permettant au patient de rester en contact avec son médecin. Dans un contexte où les données traitées sont particulièrement sensibles, la plateforme indique par ailleurs que les données médicales sont chiffrées et hébergées en France sur des infrastructures certifiées HDS.

Avec Kernel, la technologie vient ainsi soutenir un parcours de soin complet, depuis la consultation jusqu’au suivi du patient.

Nijal AI : Déployer des agents IA sans perdre en autonomie

Nijal AI développe des agents d’intelligence artificielle destinés aux entreprises, institutions et collectivités.

Son approche repose sur trois principes : proposer des solutions directement déployables, permettre leur exploitation dans le cloud ou sur site et éviter de créer une dépendance technologique difficile à maîtriser.

Nijal AI met notamment l’accent sur le transfert de compétences vers les équipes qui utilisent ses solutions. L’objectif n’est donc pas seulement de concevoir un agent IA, mais de permettre aux organisations de l’intégrer à leurs processus, de le maintenir et de conserver la maîtrise de son évolution.

Une approche qui illustre un enjeu de plus en plus concret autour de l’IA : passer de l’expérimentation à des services réellement exploitables, maintenables et intégrés au système d’information.

Qiplim : Transformer les contenus en expériences d’apprentissage interactives

Qiplim développe une plateforme qui combine animation de sessions interactives et intelligence artificielle.

À partir d’un document, d’une présentation, d’une page web ou encore d’une vidéo, la plateforme permet de générer des activités interactives puis de les utiliser au cours d’une session en direct. Les participants peuvent rejoindre celle-ci par QR code, sans avoir à créer de compte.

Qiplim développe également un Studio IA destiné à prolonger l’expérience après la session, en permettant aux participants d’interagir avec les sources mises à leur disposition et de les transformer en différents supports d’apprentissage.

La maîtrise des données fait partie intégrante de son positionnement : Qiplim traite ses données en France chez Clever Cloud et les modèles d’intelligence artificielle utilisés sont notamment servis depuis l’Union européenne par Mistral AI.

La plateforme revendique déjà plus de 210 bêta-testeurs et se présente comme une alternative souveraine à des outils comme Kahoot ou NotebookLM.

Arkan : Du développement de solutions IA à l’édition de ses propres produits

Arkan accompagne des entreprises dans la conception, le développement et le déploiement de solutions reposant sur l’intelligence artificielle.

En parallèle de projets développés sur mesure pour des entreprises dans différents secteurs, Arkan développe également ses propres produits.

Parmi eux, sa Hotel Performance Platform centralise les données issues des outils déjà utilisés par les établissements hôteliers, comme les PMS, channel managers ou extranets. Elles sont réunies dans un tableau de bord destiné à faciliter le suivi d’indicateurs tels que l’occupation, le prix moyen, le RevPAR ou l’évolution des réservations. Un assistant IA permet également d’interroger ces données en langage naturel.

La plateforme est déjà utilisée par deux groupes hôteliers représentant treize établissements.

Arkan développe parallèlement Covera, une solution destinée à automatiser la vérification des certificats d’assurance fournisseurs grâce à l’intelligence artificielle.

Cette combinaison entre conception de solutions sur mesure et développement de ses propres produits illustre elle aussi les enjeux de changement d’échelle auxquels peuvent être confrontées les entreprises technologiques.

Quand le produit rencontre ses utilisateurs, l’infrastructure devient une partie du produit

Kernel, Nijal AI, Qiplim et Arkan ne répondent pas aux mêmes besoins et ne se situent pas nécessairement au même stade de développement. Leurs trajectoires illustrent néanmoins différentes facettes d’une même transition : celle qui conduit une technologie à devenir un service réellement utilisé.

À mesure qu’un produit trouve ses utilisateurs, de nouvelles contraintes apparaissent. L’application doit rester disponible, les déploiements doivent pouvoir être reproduits, les données doivent être protégées, les ressources doivent évoluer avec les usages et les équipes doivent pouvoir continuer à livrer rapidement.

L’infrastructure cesse alors progressivement d’être une simple question technique en arrière-plan. Elle participe directement à la capacité de l’entreprise à développer son produit.

L’enjeu n’est pas de consacrer toujours plus de temps à son exploitation, mais précisément de faire en sorte qu’elle puisse suivre la croissance sans détourner les équipes de leur cœur de métier.

Le Programme UP : faire du cloud un accélérateur plutôt qu’un frein

C’est dans cette phase que s’inscrit le Programme UP de Clever Cloud.

Lancé en 2024, il a été conçu pour accompagner les startups technologiques au-delà de la seule mise à disposition de crédits cloud. L’objectif est de leur donner accès à des ressources techniques, humaines et financières leur permettant de construire leur produit sur une infrastructure capable d’évoluer avec elles.

Les startups sélectionnées peuvent notamment bénéficier :

• jusqu’à 10 000 € de crédits cloud pendant leur première année ;
• d’un onboarding sur la plateforme Clever Cloud et de formations avec nos ingénieurs ;
• d’un coaching mensuel ;
• d’un accès au support Clever Cloud ;
• de workshops et de masterclasses pour leurs équipes techniques ;
• de mentorat pour les fondateurs et les équipes techniques ;
• de visibilité à travers les médias, réseaux sociaux et événements Clever Cloud ;
• d’outils et de ressources pour accompagner leur structuration.

L’objectif reste le même : permettre aux équipes de consacrer leur énergie à leur produit, à leurs utilisateurs et à leur marché, plutôt qu’à l’exploitation quotidienne de leur infrastructure.

Kernel, Nijal AI, Qiplim et Arkan rejoignent ainsi un programme pensé pour accompagner cette étape charnière : celle où les usages se développent, où les exigences techniques évoluent et où l’infrastructure doit être capable de suivre le produit dans la durée.

Vous souhaitez rejoindre la prochaine promotion du Programme UP ?

La prochaine sélection du Programme UP aura lieu le 7 janvier 2027.

Vous développez une startup technologique et souhaitez disposer d’une infrastructure cloud capable d’accompagner la croissance de votre produit, tout en bénéficiant d’un accompagnement régulier des équipes Clever Cloud ?

Découvrez le Programme UP et rejoignez la prochaine promotion.

Qu’est-ce qu’un Kubernetes français ?

Un Kubernetes français est un service Kubernetes managé fourni par une entreprise française. Selon les offres, l’infrastructure peut être localisée en France ou dans d’autres pays européens, et selon le fournisseur, il peut reposer sur un cloud public, un cloud privé ou des machines dédiées.

Pourquoi rechercher un Kubernetes français ?

Réduire la dépendance aux hyperscalers

Confier son orchestration à AWS, Google Cloud ou Azure expose à un écosystème propriétaire et à un cadre juridique extra-européen. S'appuyer sur un acteur national limite cette dépendance et nourrit une démarche de souveraineté, au-delà de la seule réversibilité technique.

Maîtriser la localisation de l'infrastructure

Savoir précisément où s'exécutent le control plane et les workers, et sous quelle responsabilité, devient un critère de sélection à part entière pour les secteurs régulés comme pour les acheteurs publics.

Simplifier la conformité

Une infrastructure opérée en Europe peut simplifier certaines démarches de conformité liées à la localisation des données et aux transferts hors Union européenne.

Bénéficier d'un support de proximité

Un interlocuteur dans le même fuseau horaire, une facturation en euros et une documentation en français raccourcissent les délais de résolution et fluidifient la relation contractuelle.

Les principales offres Kubernetes françaises

Les descriptions ci-dessous reflètent l'état des offres au moment de la rédaction. Ces services évoluent vite : vérifiez toujours la page officielle du fournisseur avant une décision.

OVHcloud Managed Kubernetes Service (MKS)

OVHcloud propose MKS, son Kubernetes managé en cloud public, décliné en deux niveaux. MKS Free met à disposition un control plane managé gratuit. MKS Standard, lancée en septembre 2025, ajoute un SLA de 99,99 % avec un control plane réparti sur une région 3-AZ (Paris d'abord, puis Milan), un stockage etcd dédié pouvant atteindre 8 Go et le choix de la CNI, dont Cilium. L'offre s'intègre à l'écosystème Public Cloud OVHcloud.

Scaleway Kubernetes Kapsule

Kapsule est un Kubernetes managé en cloud public, certifié CNCF. Le control plane mutualisé est gratuit, avec une option de control plane dédié pour les charges critiques, et l'autoscaling est natif. L'offre s'intègre aux services Scaleway et met en avant un positionnement de souveraineté et de conformité RGPD pour le marché européen.

Clever Kubernetes Engine (CKE)

CKE est le Kubernetes managé de Clever Cloud. Le service repose sur une infrastructure située en France, sans dépendance à un hyperscaler étranger. Chaque cluster s'exécute sur ses propres VM, sans mutualisation entre clients ; la répartition du control plane est configurable selon la topologie choisie, d'un bundle tout-en-un jusqu'à une VM par composant. L’expérience reste fidèle à Kubernetes, sans mécanisme de verrouillage ni réécriture des manifestes. L’état du cluster est stocké dans Materia etcd, une implémentation du protocole etcd développée en France et bâtie sur FoundationDB. CKE s’intègre aux bases de données managées, au stockage objet compatible S3, à l’IAM, à l’observabilité et au réseau privé via Network Groups. Le produit est actuellement en bêta publique.

OVHcloud, Scaleway, Clever Cloud : le comparatif

Les offres Kubernetes françaises reposent sur des architectures et des modèles d’exploitation différents. Les critères les plus utiles pour les comparer sont la localisation de l’infrastructure, le mode d’hébergement, les garanties de disponibilité, le niveau d’intégration aux services cloud et la compatibilité avec l’écosystème Kubernetes standard.

Aucune de ces offres n'est supérieure dans l'absolu : le bon choix dépend du modèle d'exploitation recherché et du niveau de garantie attendu.

Kubernetes français ou hyperscaler (AWS, Google, Azure) ?

AWS EKS, Google GKE et Azure AKS restent les services Kubernetes managés les plus complets en matière de catalogue annexe et de portée mondiale. En contrepartie, ils renforcent la dépendance à leur écosystème. Une offre française répond aux mêmes besoins d'orchestration tout en gardant le control plane et les données sous droit européen.

Les offres françaises placent l'infrastructure en France ou en Europe, sous droit européen, avec une intégration locale. Les hyperscalers offrent un catalogue de services plus large et une présence mondiale, au prix d'une dépendance accrue à leur écosystème.

Les critères généraux de sélection d'un cluster managé, indépendants de la dimension nationale (politique de versions, autoscaling, stockage, modèle de responsabilité) méritent par ailleurs un examen à part entière.

Ce qu'il faut retenir

Le meilleur Kubernetes français dépend avant tout de votre contexte. Certaines organisations privilégieront une offre en disponibilité générale avec des garanties contractuelles fortes, tandis que d’autres rechercheront une intégration poussée avec leur plateforme cloud ou leur environnement existant. OVHcloud, Scaleway et Clever Cloud proposent aujourd’hui des approches différentes de Kubernetes managé. Le choix dépend principalement des contraintes d’exploitation, de gouvernance, de conformité et du niveau de maturité attendu.

FAQ

Existe-t-il des fournisseurs français de Kubernetes managé ?

Oui. Plusieurs entreprises françaises proposent des offres Kubernetes managées, notamment OVHcloud (Managed Kubernetes Service), Scaleway (Kubernetes Kapsule) et Clever Cloud (Clever Kubernetes Engine). Ces solutions se distinguent par leur modèle d’infrastructure, leur niveau d’infogérance et leur intégration à l’écosystème cloud du fournisseur.

Kubernetes français ou Kubernetes européen : quelle différence ?

Un Kubernetes français est fourni par une entreprise française ; un Kubernetes européen l’est par une entreprise établie dans l’Union européenne. Dans les deux cas, il convient d’examiner la localisation effective de l’infrastructure, l’opérateur réel du service et le droit applicable aux données.

Un Kubernetes français est-il forcément souverain ?

Non. La nationalité de l’éditeur ne suffit pas à garantir la souveraineté. Celle-ci dépend notamment de l’opérateur de l’infrastructure, des sous-traitants impliqués dans la chaîne d’hébergement et du cadre juridique auquel ils sont soumis.

Peut-on utiliser Helm et Terraform avec un Kubernetes français ?

Oui, dès lors que l’offre repose sur une implémentation standard de Kubernetes. Les services proposés par OVHcloud, Scaleway et Clever Cloud restent compatibles avec les outils courants de l’écosystème tels que kubectl, Helm, Terraform ou les approches GitOps.

Kubernetes français ou AWS EKS : lequel choisir ?

AWS EKS bénéficie d’un vaste catalogue de services cloud et d’une présence mondiale. Les offres françaises mettent généralement en avant une exploitation réalisée en Europe, un support de proximité et une intégration avec des infrastructures opérées localement. Le choix dépend des contraintes techniques, réglementaires et organisationnelles de chaque projet.

Quelle différence entre un Kubernetes managé et un Kubernetes auto-hébergé ?

La principale différence réside dans la responsabilité de l’exploitation. Avec un Kubernetes managé, le fournisseur opère le control plane et prend en charge une partie de la maintenance de la plateforme. Avec un Kubernetes auto-hébergé, l’organisation reste responsable de l’installation, des mises à jour, de la supervision, de la sécurité et de la disponibilité du cluster. Le Kubernetes managé réduit la charge opérationnelle, tandis que l’auto-hébergement offre un contrôle plus important sur l’infrastructure.

Peut-on migrer d’un fournisseur Kubernetes à un autre ?

Oui, à condition d’utiliser une implémentation standard de Kubernetes. Les manifestes YAML, charts Helm et outils de déploiement restent généralement portables d’un fournisseur à l’autre. Certaines dépendances spécifiques (stockage, réseau, services managés) peuvent toutefois nécessiter des adaptations.

Quel Kubernetes français pour une PME ?

Le choix dépend des besoins du projet. Une PME peut privilégier une offre disposant d’un control plane gratuit pour ses premiers déploiements, ou rechercher une intégration plus poussée avec un écosystème cloud particulier. La compatibilité standard de Kubernetes facilite dans tous les cas l’évolution vers une autre offre si les besoins changent.