Cette version marque une étape : la mécanique sous-jacente est désormais prête à accueillir les fonctionnalités produit que nous voulons bâtir au-dessus. Plutôt qu'une liste de correctifs, nous avons regroupé le travail en six thèmes ; pour chacun, nous disons deux choses — ce qui a été livré, et ce que cela rend possible, pour celles et ceux qui font tourner leurs applications sur la plateforme comme pour les opérateurs qui exécutent Sōzu sur leur propre infrastructure.

1. Un multiplexer HTTP/2 réécrit intégralement

La pile HTTP/1 de Sōzu avait déjà été réécrite autour de kawa, notre format pivot : une représentation interne du message HTTP indépendante de sa version, dans le même esprit que le format HTX de HAProxy. Le multiplexer HTTP/2 en est le prolongement naturel — il étend kawa avec la gestion des sessions et le multiplexing des streams.

Il couvre l'intégralité de la matrice des protocoles (H1↔H1, H1↔H2, H2↔H1, H2↔H2), avec un état de stream partagé, la compression HPACK assurée par loona-hpack, le pooling des connexions HTTP/2 vers les backends, la priorisation des streams selon RFC 9218 Extensible Priorities, et la négociation ALPN par listener, afin que chaque connexion TLS aboutisse sur le bon chemin de code. Environ 181 tests end-to-end et deux cibles de fuzzing (cargo-fuzz) maintiennent le parser et le décodeur HPACK dans le droit chemin — dont des garde-fous de régression qui vérifient octet pour octet l'intégrité des réponses volumineuses sur un trajet « backend HTTP/1 → frontend HTTP/2 », précisément la frontière où se cachent les bugs de readiness en mode edge-triggered d'epoll.

Pour les clients Clever Cloud, l'incidence concrète est simple : chaque application servie par la plateforme parle désormais HTTP/2 par défaut, côté frontend — aucun opt-in, aucune modification de code, aucune configuration. L'activation du HTTP/2 jusqu'au backend reste un choix par cluster — un cluster, dans le modèle de Sōzu, étant l'une de vos applications ; activée de bout en bout, elle débloque notamment gRPC sur toute la chaîne. Les pages s'affichent en moins de connexions TCP ; les navigateurs peuvent mutualiser les requêtes entre les hôtes qui partagent un certificat (nous honorons le SAN coalescing décrit dans la RFC 7540 §9.1.1 : lorsque le certificat, l'autorité d'origine et les conditions de connexion s'y prêtent, Firefox et Chrome peuvent réutiliser une seule connexion vers vos cdn.example.com et assets.example.com au lieu d'en ouvrir plusieurs en parallèle). Il s'agit, au meilleur sens du terme, d'une mise à niveau silencieuse de la plateforme.

C'est aussi le prérequis structurel pour la suite — HTTP/3 sur QUIC et des fondations de streaming plus solides à l'edge. La réécriture du multiplexer est la pièce de la roadmap qui devait advenir en premier.

2. La sécurité pour socle, non comme option

La seconde moitié de la réécriture HTTP/2 est celle dont personne ne réclame l'existence tant qu'elle ne fait pas défaut : la résistance aux floods et aux attaques par déni de service. Sōzu 2.0 embarque des mitigations natives pour les vulnérabilités CVE-2023-44487 (Rapid Reset), CVE-2024-27316 (CONTINUATION flood), CVE-2025-8671 (MadeYouReset), ainsi que pour la famille PING / SETTINGS / empty-DATA des CVE-2019-9512/CVE-2019-9515/CVE-2019-9518. Chaque mitigation expose un counter dédié — douze métriques sous h2.flood.violation.* — afin qu'un SIEM puisse mesurer en fenêtre glissante le taux de déclenchement, sans avoir à parser les logs. Dix-sept motifs de rejet HPACK sont exposés selon le même principe ; il s'agit du premier signal observable côté opérateur pour les tentatives de request smuggling contre la pile HTTP/2.

Le reste du travail de sécurité se déploie à travers le proxy : un plafond de connexions par couple (cluster, IP source) assorti d'une réponse 429 Too Many Requests ; une éviction optionnelle des sessions les plus anciennes lorsque l'accept queue sature ; un durcissement du command channel, du parser HTTP/1, du pattern-trie router (fermeture d'un contournement de routing via regex non ancrées) et du wildcard matcher ; un assainissement du pipeline d'audit contre les séquences Trojan-Source et le SIEM column-smuggling ; et une rotation à chaud des certificats TLS qui ne laisse jamais tomber le certificat fonctionnel en cas d'échec, quand bien même le nouveau serait malformé. Quatre security advisories de dépendances purgées au cours de la même fenêtre.

Chaque mutation privilégiée atterrit désormais dans un journal d'audit structuré : chaque action du plan de contrôle est consignée sous la forme d'une ligne Command(verb=…, actor_uid=…, actor_user=…, result=…) — qui a fait quoi, depuis où, et avec quel résultat. Deux sinks dédiés l'exportent : audit_logs_target pour le flux lisible, et audit_logs_json_target pour un objet JSON à schéma stable par ligne, de sorte que la piste se déverse directement dans un SIEM (Wazuh, Elastic, Loki, Splunk) sans parser sur mesure — dans un format pensé pour PCI-DSS 10.5.

Le cadrage produit est limpide : notre métier, c'est d'opérer la plateforme et de protéger vos applications dès que nous le pouvons. Lorsque la prochaine vulnérabilité HTTP/2 de cette classe paraît un vendredi à vingt-et-une heures, elle n'a pas à se traduire par un week-end de correctifs et de redéploiements sur des milliers d'applications : les attaques de cette classe sont largement absorbées ou atténuées au niveau du proxy, un counter s'incrémente sur un dashboard, et les applications continuent de servir leur trafic. Le « trust-by-default » n'est pas un slogan : c'est l'effet cumulé de dizaines de petits correctifs défensifs, livrés à la couche où la frontière de sécurité se joue véritablement.

3. De la visibilité à chaque couche

L'ajout le plus visible pour l'utilisateur en 2.0 est sozu top — une TUI opérateur (derrière le feature flag Cargo tui) qui offre une vue en temps réel, à la manière de btop ou htop, sur sept panes : Overview, Clusters, Backends, Listeners, H2, Certificates, Events. Palette accessible aux personnes daltoniennes, thèmes personnalisables : l'essentiel tient dans un terminal, sans dashboard externe.

Sous la TUI, la surface des métriques elle-même a été refondue. Le multiplexer expose des counters par type de frame et par code d'erreur RFC 9113, la télémétrie des handshakes TLS, des counters HTTP par status code, et de nouvelles gauges de cycle de vie du worker. L'access log gagne les champs TLS et de forwarding (version, cipher, SNI, ALPN, chaîne XFF), la propagation x_request_id de bout en bout, ainsi que les RTT client et serveur — de quoi corréler une requête d'un hop à l'autre.

Une nouvelle commande, SetMetricDetail, permet à un opérateur d'élever à la demande la cardinalité des métriques, via un lease à durée limitée qui expire : la production reste à faible cardinalité par défaut, et l'inspection fine devient une décision ponctuelle plutôt qu'une réécriture de configuration.

Pour Clever Cloud, c'est le socle du prochain chapitre de l'observabilité tournée vers le client — percentiles de latence par application, disponibilité par cluster, décomposition des handshakes TLS, request IDs traçables d'un hop à l'autre. Les métriques existent désormais au niveau du proxy. L'étape suivante consiste à les exposer dans la console Clever Cloud, à leur juste place, aux côtés des vues de build et de déploiement — afin qu'aucun APM externe ne soit nécessaire pour comprendre le trafic que votre application reçoit véritablement.

4. Des policies de trafic enfin actionnables d'un geste

Sōzu 2.0 refond l'intégralité de la surface des policies côté frontend (#1231) : HSTS typé (RFC 6797), configurable par listener et par frontend ; URL rewrite (host, path, port) avec propagation des regex captures depuis le routing trie vers les rewrite templates ; réécriture des headers de requête et de réponse par frontend — ajouter, modifier ou supprimer n'importe quel header (une valeur vide le supprime, parité avec le del-header de HAProxy), avec en complément l'injection de X-Real-IP au niveau listener et l'élision anti-spoofing des valeurs fournies par le client ; redirects HTTP 301 / 302 / 308 au travers d'une enum typée RedirectPolicy ; et l'authentification HTTP Basic par frontend, avec des credentials hashés en SHA-256 et une comparaison constant-time assurée par la crate subtle (le credential boundary est durci contre les side-channels temporels — la code review l'avait identifié).

C'est la partie de la release où l'opportunité produit est la plus saillante. Aujourd'hui, mener une migration de domaine propre sur une plateforme managée requiert typiquement soit un backend sachant rediriger, soit un service de redirection déployé en parallèle ; placer une URL de preview derrière un mot de passe requiert typiquement un add-on d'authentification. Avec Sōzu 2.0, ces usages deviennent des boutons sur le proxy. La plomberie existe ; ce qu'il reste à accomplir, c'est d'exposer ces boutons dans la console Clever Cloud — sous la forme d'une case à cocher sur un domaine, ou d'un toggle à clic unique pour les preview environments. C'est la surface no-code de contrôle du trafic que nous voulons construire ensuite.

5. L'exploitation comme bénéfice pour le client

Une réécriture de cette profondeur ne se livre sereinement que si la flotte demeure en mouvement en dessous. L'exploitation au quotidien a reçu une attention particulière en 2.0.

sozu listener {http,https,tcp} update est un nouveau patch verb field-masked qui ajuste à la volée les paramètres d'un listener modifiables sans recycler les sockets sous-jacents : seuils de flood HTTP/2, SNI binding, préférence ALPN, idle timeouts, HSTS, custom answers. Les mitigations CVE peuvent désormais être resserrées sous attaque sans recycler les sockets d'écoute. Les health checks actifs des backends s'exécutent à l'intérieur de la loop d'événements mio existante (aucun scheduler async, aucun thread supplémentaire), avec des sondes HTTP/1.1 et HTTP/2, des intervalles dotés d'un léger jitter, et un fail-open path qui achemine à travers les backends au statut Normal dont la retry policy l'autorise. L'intégration systemd (qui clôt #228) effectue enfin ce qu'il convient : des units Type=notify, un READY=1 envoyé seulement après la création des workers initiaux et le replay de l'état sauvegardé, un STOPPING=1 lors du graceful shutdown, un MAINPID=<nouveau> lors des hot upgrades.

Les releases elles-mêmes ont changé de forme. Pousser un tag produit désormais dix tarballs pré-compilés (trois cibles Linux croisées avec jusqu'à quatre crypto providers), signés keyless via sigstore (cosign + GitHub OIDC), accompagnés d'une attestation SLSA build provenance et d'un pointeur SOURCE.txt vers le code source correspondant satisfaisant l'AGPL §6 et la LGPL §4 — refermant ainsi l'écart noté dans #1089. Les fichiers fullchain.pem ACME se chargent à présent proprement, y compris lorsque le client a émis le leaf en tête de chaîne (Certbot, lego, acme.sh) ; une race condition vieille de six ans sur l'auto-restart des workers (#515) est corrigée par pinning de l'inode original au moyen de /proc/self/fd. Le verbe IPC LoadState demeure forward-compatible avec les clients sozu-command-lib 1.1.1, de sorte que l'écosystème d'intégrations ne se brise pas lors de l'upgrade.

À l'échelle de Clever Cloud, le coût d'un incident d'exploitation ne se mesure pas en tickets — il s'agit d'une latence qui s'accumule sur des milliers d'applications, et du temps d'ingénierie que nous devons à la construction de l'étape suivante. Sōzu 2.0 est le proxy qui se laisse exploiter en silence, et cette tranquillité est ce que les clients vivent comme de l'uptime. C'est également ce qui rend Sōzu crédible comme outil que l'on peut exécuter sur sa propre infrastructure : binaires signés, hot reloads, particularités ACME absorbées, intégration systemd menée correctement.

6. Une crypto prête pour demain

La pile TLS a reçu une refonte plus discrète, mais d'égale importance (#1191). Sōzu prend désormais en charge quatre crypto providers pluggables pour rustls : crypto-ring (par défaut), crypto-aws-lc-rs, crypto-openssl, et fips (qui implique aws-lc-rs en mode FIPS). Les quatre sont exercés par la CI, et la precedence chain fips > ring > aws-lc-rs > openssl résout le provider actif de manière déterministe lorsque plusieurs features sont activées simultanément.

Ce dont nous sommes le plus satisfaits, en revanche, est le groups_list par défaut : X25519MLKEM768 est désormais le groupe d'échange de clés en première préférence lorsque le provider le prend en charge. Il s'agit de l'hybride post-quantique en cours de normalisation à l'IETF (draft-ietf-tls-ecdhe-mlkem), déjà enregistré dans le registre TLS de l'IANA ; en pratique, cela signifie qu'un client uniquement compatible X25519 et un client post-quantum négocient l'un comme l'autre l'échange le plus robuste mutuellement pris en charge, sans aucune action de l'opérateur.

Lorsque la transition post-quantique deviendra une exigence réglementaire — selon un calendrier dont l'industrie débat encore — les fondations seront déjà en place sur Clever Cloud : tout client TLS 1.3 qui propose l'hybride le négocie dès aujourd'hui, sans action de l'opérateur. Nous avons effectué ce choix en silence, et nous l'avons inscrit par défaut.

Du reverse proxy à l'edge programmable

Sōzu a toujours été un load balancer d'infrastructure : bien au-delà du HTTP, il équilibre aussi du TCP brut, avec un chemin de forwarding zéro-copie via splice(2) sous Linux pour les listeners TCP. Avec la 2.0, il se rapproche d'une API gateway et devient le substrat d'un edge programmable — et « programmable » est le mot qui compte. Chaque capacité décrite ci-dessus (HTTP/2 par défaut, contrôles anti-abus, observabilité, policies de trafic, crypto agility, calme opérationnel) est un bouton. L'année qui vient de la roadmap Clever Cloud consiste à exposer ces boutons sous la forme de features produit : à travers la console, à travers l'API, à travers les workflows que vous utilisez déjà pour déployer vos applications.

Voilà ce que nous voulons dire lorsque nous affirmons que Sōzu 2.0 est un premier pas vers quelque chose de plus grand. La 2.0 n'est pas la destination — c'est la plateforme sur laquelle nous bâtissons désormais. Le HTTP/2 managé, partout, en constitue la première brique. La deuxième : une console permettant d'activer HSTS, de protéger par mot de passe un preview environment, ou de rediriger un domaine migré. L'aboutissement — un edge entièrement programmable, doté de policy primitives que vous composez — est ce vers quoi nous bâtissons au fil du prochain release cycle.

Deux chantiers sont déjà sur l'établi. D'abord, un volet load balancing UDP — dans l'esprit d'IPVS, mais avec le rechargement à chaud propre à Sōzu — assorti de health checks TCP pour valider la disponibilité des backends UDP ; de quoi ancrer un peu plus le rôle de load balancer d'infrastructure. Ensuite, des backends joignables en HTTPS, qui consolident la connectivité amont et ouvrent la voie à l'API gateway.

Sōzu est un projet open source publié sous AGPL-3.0 (la command library est diffusée sous LGPL-3.0). Les binaires de la version 2.0 sont signés via sigstore et embarquent une attestation SLSA ; si vous opérez votre propre edge, cette version vous appartient : à utiliser, à auditer, à étendre. Le code, l'issue tracker, et les conversations vivent à l'adresse github.com/sozu-proxy/sozu.

Nous remercions les contributeurs qui ont rendu cette release possible — ainsi que toutes celles et ceux qui exécutent Sōzu en production, dont les retours guident la suite.

Références

Standards et spécifications

• RFC 6797 — HTTP Strict Transport Security (HSTS). https://datatracker.ietf.org/doc/html/rfc6797
• RFC 7540 — Hypertext Transfer Protocol Version 2 (HTTP/2). Désormais obsolétée par la RFC 9113, mais le §9.1.1 sur le connection coalescing demeure la citation reprise par la RFC 9113. https://datatracker.ietf.org/doc/html/rfc7540
• RFC 9113 — HTTP/2 (en vigueur). §5 streams, §6 frames, §6.8 GOAWAY, §7 codes d'erreur, §8.1 sémantique HTTP. https://datatracker.ietf.org/doc/html/rfc9113
• RFC 9218 — Extensible Prioritization Scheme for HTTP. https://datatracker.ietf.org/doc/html/rfc9218
• draft-ietf-tls-ecdhe-mlkem — Hybrid key exchange in TLS 1.3 : X25519MLKEM768 (Internet-Draft IETF, enregistré à l'IANA ; l'hybride post-quantique que Sōzu privilégie par défaut). https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-mlkem

CVE

• CVE-2019-9512 — HTTP/2 Ping Flood. https://nvd.nist.gov/vuln/detail/CVE-2019-9512
• CVE-2019-9515 — HTTP/2 Settings Flood. https://nvd.nist.gov/vuln/detail/CVE-2019-9515
• CVE-2019-9518 — HTTP/2 Empty Frames Flood. https://nvd.nist.gov/vuln/detail/CVE-2019-9518
• CVE-2021-42574 — Trojan Source (bidirectional override). https://nvd.nist.gov/vuln/detail/CVE-2021-42574
• CVE-2023-44487 — HTTP/2 Rapid Reset. https://nvd.nist.gov/vuln/detail/CVE-2023-44487
• CVE-2024-27316 — HTTP/2 CONTINUATION Flood. https://nvd.nist.gov/vuln/detail/CVE-2024-27316
• CVE-2025-8671 — MadeYouReset (HTTP/2). https://nvd.nist.gov/vuln/detail/CVE-2025-8671

Pour aller plus loin

• Cloudflare — HTTP/2 Rapid Reset: deconstructing the record-breaking attack. Le compte rendu canonique de la divulgation coordonnée d'octobre 2023, incluant la mécanique de l'attaque ainsi que le pic de 398 millions de rps capturé en direct. https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
• HAProxy Technologies — HAProxy is Not Affected by the HTTP/2 Rapid Reset Attack (CVE-2023-44487). L'argument structurel de HAProxy quant à la raison pour laquelle son cycle de vie de stream absorbe naturellement le Rapid Reset ; un contraste utile face à l'approche par counters de flood retenue par Sōzu. https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-http-2-rapid-reset-attack-cve-2023-44487
• Cloudflare blog — série Post-quantum. Couverture pluriannuelle assurée par Bas Westerbaan et ses collaborateurs sur l'échange de clés post-quantique et les groupes hybrides ; filiation de l'hybride X25519MLKEM768 que Sōzu négocie désormais par défaut. https://blog.cloudflare.com/tag/post-quantum/
• Cloudflare Learning Center — What is HSTS?. Primer accessible sur HSTS, la sémantique max-age / includeSubDomains / preload, et la politique de la HSTS preload list.

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

K8s : le Kubernetes standard entreprise

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

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

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

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

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

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

Ce que K3s change par rapport à K8s

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

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

Empreinte ressources

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

Différences techniques clés

Datastore

Runtime et packaging

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

Architecture du plan de contrôle

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

Scalabilité

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

Tableau comparatif K3s vs K8s

Cas d'usage : lequel choisir ?

Choisissez K3s si :

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

Choisissez K8s (ou une distribution enterprise) si :

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

Cas hybrides : K3s et K8s ensemble

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

Fleet management avec Rancher

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

Clusters de dev et staging K3s, prod K8s

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

CI/CD

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

Kubernetes managé : une troisième voie

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

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

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

FAQ

K3s est-il un fork de Kubernetes ?

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

Peut-on utiliser K3s en production ?

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

K3s supporte-t-il Helm ?

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

Quelle est la différence entre K3s et K3d ?

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

K3s fonctionne-t-il sur ARM ?

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

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

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

Plusieurs vulnérabilités récentes du noyau Linux ont nécessité une réponse rapide de la part des opérateurs d'infrastructure. Parmi elles, Copy Fail et Dirty Frag ont attiré l'attention car elles concernent des scénarios d'élévation locale de privilèges.

Copy Fail est suivie sous la CVE-2026-31431.

Dirty Frag regroupe deux vulnérabilités distinctes, la CVE-2026-43284 et la CVE-2026-43500, liées à des composants du noyau Linux.

Chez Clever Cloud, nous avons traité ces vulnérabilités comme des sujets d'infrastructure critiques.

Notre objectif était double : réduire rapidement la fenêtre d'exposition, puis améliorer durablement notre processus de sélection et de déploiement des kernels.

Cet article revient sur notre approche, les décisions prises et les changements apportés à notre chaîne d'exploitation.

Pourquoi ces vulnérabilités demandaient une réaction rapide

Copy Fail et Dirty Frag appartiennent à la famille des vulnérabilités d'élévation locale de privilèges. Dans ce type de scénario, un attaquant doit déjà pouvoir exécuter du code localement, mais peut ensuite tenter d'obtenir des privilèges plus élevés sur la machine concernée.

Dirty Frag repose sur deux failles du noyau Linux.

Elles affectent notamment des modules liés à ESP, utilisé par IPsec, et à RxRPC. Dans une plateforme cloud, ce type de vulnérabilité impose une analyse rapide. Le risque ne se limite pas à la machine isolée. Il faut aussi évaluer les scénarios liés aux environnements mutualisés, aux workloads containerisés et aux mécanismes d'isolation.

Ce que nous avons vérifié

Nous avons analysé l'impact potentiel de ces vulnérabilités sur nos environnements.

Cette étape ne consiste pas seulement à lire les avis de sécurité.

Elle consiste aussi à vérifier si un scénario théorique peut devenir pertinent dans notre contexte d'exploitation.

Dans le cas de CopyFail, la faille venait sous embargo avec son correctif. Nous avons publié une nouvelle image système avec le correctif appliqué dans les jours qui ont suivi.

Les applications de nos clients ont été redéployées dans la foulée.

Dans le cas de Dirty Frag, nos analyses internes ont confirmé que ces vulnérabilités devaient être traitées sérieusement. En effet, les modules ESP sont activés dans nos noyaux pour répondre à certains besoins client spécifiques.

Heureusement, les modules liés à RxRPC ne sont pas présents chez nous car inutile dans notre usage. Nous ne détaillons pas ici les étapes techniques de l'exploitation, car l'objectif de cet article est d'informer nos clients, pas de publier une procédure reproductible.

Cette validation a confirmé la décision opérationnelle : traiter le sujet immédiatement, réduire la surface exposée, puis forcer les redéploiements nécessaires.

Notre réponse opérationnelle

Déployer des mesures immédiates

Nous avons d'abord appliqué des mesures rapides sur les kernels concernés. Dans le cas de Dirty Frag, les mesures publiques recommandées portent notamment sur les composants kernel concernés par ESP et RxRPC.

Côté Clever Cloud, l'objectif était clair : réduire les surfaces exposées identifiées et réduire la fenêtre d'exposition avant d'attendre un cycle classique de maintenance

Redéployer les workloads concernés

Une mise à jour kernel n'est utile que si les systèmes concernés redémarrent effectivement sur un environnement corrigé. Nous avons donc lancé un redéploiement progressif des applications, puis traité les cas qui bloquaient ce redéploiement.

Cette phase est importante. Dans une plateforme managée, la correction ne se limite pas à produire une image ou à compiler un kernel. Il faut aussi s'assurer que la chaîne d'exécution utilise réellement la version attendue.

Améliorer le processus au passage

Nous avons aussi profité de cette séquence pour remplacer un mécanisme temporaire par une intégration plus propre dans notre chaîne d'orchestration.

Concrètement, le choix du kernel est désormais transmis plus explicitement dans notre chaîne interne, jusqu'à Supernova, notre agent d'hyperviseur. Cette évolution remplace le contournement plus rigide mis en place dans l'urgence.

C'est le point central de cette intervention : corriger vite, puis rendre la correction plus fiable pour les prochaines opérations.

Ce que cela change pour les clients de Clever Cloud

Pour les clients, l'effet attendu est simple : réduire l'exposition sans action manuelle de leur part lorsque la plateforme peut prendre en charge le redéploiement.

Clever Cloud exploite une architecture qui repose notamment sur l'isolation par virtualisation. Cette approche est documentée dans nos pages sécurité et dans nos contenus techniques sur l'exécution de conteneurs dans des machines virtuelles.

Elle ne supprime pas tous les risques, mais elle limite certains scénarios de mouvement latéral par rapport à des modèles où plusieurs workloads partagent directement le même environnement d'exécution.

Nous évitons toutefois de présenter cette isolation comme une garantie absolue. Une vulnérabilité kernel doit toujours être traitée sérieusement. C'est pourquoi nous avons combiné mitigation, redéploiement et amélioration de notre chaîne d'exploitation.

Ce que nous retenons

Cette séquence confirme trois principes.

D'abord, une vulnérabilité kernel doit être analysée dans son contexte réel d'exploitation. Une alerte publique ne suffit pas.

Il faut comprendre si les conditions nécessaires à l'exploitation peuvent exister sur la plateforme.

Ensuite, la vitesse de réaction compte. Les vulnérabilités Copy Fail et Dirty Frag ont été divulguées publiquement à quelques jours d'intervalle, avec des analyses publiées par plusieurs acteurs de l'écosystème Linux et cloud.

Enfin, une réponse sécurité utile ne doit pas seulement corriger le problème du moment. Elle doit aussi améliorer le système qui permettra de répondre au prochain incident.

C'est ce que nous avons fait ici : traiter les vulnérabilités, réduire la fenêtre d'exposition et renforcer notre processus de gestion des kernels.

FAQ

Qu'est-ce qu'une vulnérabilité kernel locale ?

Une vulnérabilité kernel locale est une faille qui nécessite déjà une capacité d'exécution sur la machine concernée. Elle peut ensuite permettre d'obtenir des privilèges plus élevés, par exemple root, si le noyau est vulnérable.

Pourquoi ces failles concernent-elles les plateformes cloud ?

Les plateformes cloud exécutent de nombreux workloads avec des mécanismes d'isolation. Une faille kernel peut devenir critique si elle permet de franchir certaines barrières entre processus, conteneurs ou environnements d'exécution.

Dirty Frag et Copy Fail sont-elles la même vulnérabilité ?

Non. Copy Fail est suivie sous la CVE-2026-31431. Dirty Frag regroupe la CVE-2026-43284 et la CVE-2026-43500. Ces vulnérabilités sont proches par leur impact, mais elles sont distinctes.

Quelle action est demandée aux clients Clever Cloud ?

Aucune action générale n'est demandée aux clients pour les environnements pris en charge par la plateforme. L'automatisation apportée par Clever Cloud a permis de tout mettre à jour sans action nécessaire. Les cas spécifiques font l'objet d'un suivi dédié.

En une décennie, K8S s'est imposé comme la base technique sur laquelle s'exécute une part majoritaire des applications cloud modernes.

Comment fonctionne Kubernetes : un orchestrateur déclaratif

La plupart des descriptions de Kubernetes énumèrent ses composants, pods, deployments, services, sans expliquer le mécanisme central. Or le concept fondamental est ailleurs : Kubernetes est avant tout un orchestrateur, et son moteur central repose sur des boucles de réconciliation.

Vous ne dites pas à Kubernetes quoi faire. Vous lui dites à quoi vous voulez que votre système ressemble. Cette distinction, déclaratif contre impératif, change tout.

Concrètement, vous décrivez l'état désiré dans des fichiers manifestes, généralement au format YAML : « je veux 3 répliques de cette image, exposées sur le port 80, avec ces variables d'environnement ». Vous envoyez ce manifeste à l'API Kubernetes via kubectl. À partir de là, Kubernetes compare en permanence l'état réel du cluster (ce qui tourne effectivement) à l'état désiré (ce que vous avez déclaré), et agit pour les rapprocher. Si un nœud meurt, ses pods sont reprogrammés ailleurs. Si vous passez de 3 à 10 répliques dans le manifeste, Kubernetes en démarre 7 de plus. Si un conteneur plante, il est redémarré.

Cette boucle de réconciliation est le cœur de tout ce que fait Kubernetes : auto-réparation, scaling, déploiements progressifs (rolling updates), retours arrière. Pour creuser ce mécanisme et les autres fonctions qu'il rend possibles, découvrez en détail à quoi sert l'orchestration de conteneurs.

Architecture en bref : control plane, nodes, pods

Un cluster Kubernetes se divise en deux ensembles. Le control plane est le cerveau : il prend les décisions globales, accepte les requêtes API, planifie les charges de travail, et surveille l'état du cluster. Il s'appuie sur quelques composants clés comme le serveur API (kube-apiserver), le planificateur (kube-scheduler) et le gestionnaire de contrôleurs (kube-controller-manager), ainsi que sur un magasin de données distribué qui mémorise tout l'état du cluster, traditionnellement etcd.

Les nodes sont les machines qui exécutent réellement les charges de travail. Sur chacune, un agent appelé kubelet reçoit ses instructions du control plane et lance les conteneurs via un moteur d'exécution (containerd, CRI-O, etc.). La plus petite unité déployable n'est pas un conteneur isolé mais un pod : un ou plusieurs conteneurs qui partagent un réseau et un stockage. Au-dessus, des objets de plus haut niveau (Deployment, Service, Ingress, ConfigMap, Secret) décrivent comment les pods doivent être gérés, exposés et configurés.

Cette architecture est aussi la source d'une confusion fréquente avec Docker, dont les rôles sont en réalité complémentaires de ceux de Kubernetes plutôt que concurrents.

Pourquoi K8S est devenu le standard de l'orchestration

Selon le CNCF Annual Cloud Native Survey 2025, publié en janvier 2026, 98 % des organisations interrogées ont adopté des techniques cloud native, et 82 % des utilisateurs de conteneurs déploient Kubernetes en production, contre 66 % en 2023. La domination est massive. Mais l'expliquer uniquement par des qualités techniques serait incomplet, c'est aussi une histoire d'écosystème et d'alignement d'intérêts.

Sur le plan technique, trois propriétés expliquent l'adoption. D'abord, le modèle déclaratif décrit plus haut : il rend les déploiements reproductibles, versionnables dans Git, et résistants aux pannes. Ensuite, la portabilité : un même manifeste fonctionne sur une machine de développement (Minikube, kind, k3d), sur un cluster on-premise et sur n'importe quel cloud. Enfin, l'extensibilité : l'API de Kubernetes accepte des objets personnalisés (Custom Resource Definitions) et des contrôleurs personnalisés (Operators), ce qui en a fait une plateforme pour étendre la plateforme. Cet effet a déclenché une dynamique d'écosystème massive.

Sur le plan stratégique, l'histoire est moins racontée. En 2014, Google avait plus d'une décennie d'expérience dans la gestion de conteneurs à grande échelle avec ses systèmes internes Borg et Omega, dont les principes ont été partagés publiquement via des papiers de recherche académiques (Omega en 2013, Borg en 2015). Plutôt que d'open-sourcer Borg lui-même, qui restait étroitement couplé à l'infrastructure Google, l'équipe a créé Kubernetes comme un nouveau projet inspiré de cette expérience, avec une implémentation distincte conçue dès le départ pour une adoption externe. Le projet a été publié en open source en juin 2014 puis donné à la Cloud Native Computing Foundation en 2015. Cette neutralité, un projet hébergé par une fondation Linux et non par un cloud, a été déterminante. Aucun concurrent ne pouvait se permettre de ne pas l'adopter sous peine d'être marginalisé hors de l'écosystème cloud-native naissant. AWS, qui poussait initialement sa propre solution propriétaire (ECS), a annoncé EKS fin 2017 et l'a lancé en disponibilité générale en juin 2018. À ce moment-là, le standard était scellé.

Sur le plan de l'écosystème, l'effet réseau a fait le reste : Helm pour empaqueter les applications, Prometheus pour la supervision, Istio et Linkerd pour le service mesh, ArgoCD et Flux pour le GitOps, Trivy et Falco pour la sécurité. Chaque outil supplémentaire renforce la valeur du standard. Côté ressources humaines, les compétences Kubernetes sont devenues massivement demandées sur les offres DevOps et SRE, ce qui crée un cercle vertueux : plus d'ingénieurs formés, plus d'entreprises qui adoptent, plus d'ingénieurs qui se forment.

Dans le rapport CNCF 2025, la communauté qualifie aujourd'hui Kubernetes de « boring », au sens noble du terme : un outil mature, prévisible, dont les API ne se cassent plus à chaque release. C'est précisément ce qu'on attend d'une infrastructure standard.

Quand utiliser Kubernetes, et quand privilégier le PaaS ?

Le fait que K8S soit le standard ne signifie pas qu'il soit la bonne réponse à tous les problèmes. Choisir Kubernetes, un PaaS, ou une combinaison des deux dépend du contexte technique et organisationnel ; chez Clever Cloud, beaucoup d'équipes utilisent les deux en parallèle pour des workloads différents.

Kubernetes apporte une vraie valeur dans plusieurs contextes :

• portabilité forte attendue : multi-cloud, hybride, on-premise associé à du cloud, où le manifeste Kubernetes devient un dénominateur commun ;
• architectures distribuées qui appliquent les principes du 12-factor app et l'approche « cattle » (instances interchangeables, sans état) avec des besoins d'orchestration sophistiqués ;
• alignement stratégique sur l'écosystème CNCF (Helm, Operators, ArgoCD, Istio…) ou prérequis client / partenaire qui imposent ce standard ;
• besoin d'une plateforme commune pour des équipes nombreuses, avec une équipe plateforme dédiée ou la volonté d'externaliser cette responsabilité à un service managé.

À l'inverse, dans d'autres contextes, un PaaS comme Clever Cloud répond directement aux mêmes besoins que Kubernetes (déploiements industrialisés, autoscaling, résilience) sans la complexité opérationnelle de l'orchestrateur. C'est notamment vrai pour les architectures applicatives classiques (web + backend + base de données) où l'effort de configuration et d'opération de Kubernetes ne se traduit pas en valeur ajoutée concrète.

Et pour les charges intermédiaires (IoT, edge, environnements de développement, petits clusters), les différences entre K3S et K8S méritent d'être pesées avant de trancher : la distribution allégée est souvent plus adaptée. Le standard de facto n'est pas une obligation morale. C'est un outil puissant et coûteux à opérer, dont l'usage doit être choisi en fonction des problèmes qu'il résout, souvent en complément des autres approches plutôt qu'en remplacement.

Les limites du standard : la dette opérationnelle

Faire tourner Kubernetes en production n'est pas trivial. C'est l'une des raisons pour lesquelles beaucoup d'entreprises qui adoptent K8S optent pour un service managé plutôt qu'une installation auto-gérée.

Les sources de complexité sont multiples : configurer correctement le contrôle d'accès (RBAC), choisir et opérer un plugin réseau (CNI), brancher du stockage persistant (CSI), mettre en place une observabilité, gérer les certificats, faire les mises à jour mineures et majeures sans interruption, durcir la sécurité, gérer les sauvegardes du control plane. Chacun de ces sujets est un métier en soi. Le rapport CNCF 2025 montre d'ailleurs que les défis se sont déplacés du purement technique vers l'organisationnel : 47 % des organisations citent désormais les « changements culturels avec l'équipe de développement » comme principal obstacle, devant la complexité technique brute.

Au cœur de cette dette se trouve un composant moins discuté : etcd. C'est la base de données clé-valeur distribuée qui stocke l'état complet du cluster. etcd est solide pour les clusters de taille modérée, mais devient un goulot d'étranglement à l'échelle. Ce n'est pas un hasard si Google a annoncé fin 2024 le remplacement d'etcd par Spanner pour son offre GKE, en conservant uniquement la compatibilité API. AWS, de son côté, a réécrit une « nouvelle génération » de son architecture etcd pour soutenir l'échelle. K3S, conçu pour les environnements légers, a poussé la logique plus loin en proposant plusieurs alternatives à etcd, dont SQLite par défaut. Quand un composant central doit être reconçu pour soutenir l'usage en production, c'est un indice révélateur.

C'est ce constat qui nous a poussés, chez Clever Cloud, à reconsidérer cette pièce. Notre Clever Kubernetes Engine remplace l'etcd standard par Materia etcd, notre réimplémentation du protocole etcd construite sur  Materia KV, et FoundationDB, répliquée  sur trois datacenters parisiens. Cette approche, c'est aussi ce qui rend Clever Cloud unique : un control plane multi-tenant qui scale horizontalement sans dégrader les performances, hérite de la simulation continue de pannes de FoundationDB, et libère les équipes de la gestion de milliers d'instances etcd fragiles.

Mais que vous choisissiez CKE ou un autre service, le principe vaut : si vous voulez Kubernetes en production sans bâtir une équipe plateforme dédiée, un Kubernetes managé est presque toujours la bonne décision.

En résumé

Kubernetes s'est imposé comme standard pour de bonnes raisons techniques, mais aussi grâce à un alignement d'intérêts qui a fait converger l'industrie autour d'un projet neutre porté par la CNCF. Le mécanisme central, la boucle de réconciliation et le modèle déclaratif, explique sa robustesse. L'écosystème qui s'est construit autour explique sa pérennité.

Cela ne signifie pas qu'il faut l'adopter pour tout. Pour beaucoup de contextes, un PaaS ou une autre approche est mieux adaptée, et bien souvent, les deux cohabitent dans une même architecture, chacun là où il apporte le plus de valeur. Pour des architectures distribuées sérieuses, il reste l'outil de référence, à condition de mesurer la dette opérationnelle qu'il introduit, et de choisir entre l'opérer soi-même ou s'appuyer sur un service managé.C'est précisément la promesse que Clever Kubernetes Engine, notre Kubernetes managé, cherche à tenir : Kubernetes standard, opéré en France sur une infrastructure souveraine, avec un control plane reconçu pour éliminer la friction d'etcd à l'échelle. Et pour les équipes qui n'ont pas besoin de Kubernetes, notre PaaS reste la voie la plus directe vers la mise en production.

FAQ

K8S et Kubernetes, c'est la même chose ?

Oui. K8S est une abréviation : la lettre K, les huit lettres d'« ubernete » condensées en 8, et la lettre S finale. Les deux désignent le même système d'orchestration de conteneurs.

Quelle est la différence entre Docker et Kubernetes ?

Docker est un moteur de conteneurisation : il empaquette une application avec ses dépendances dans une image qui s'exécute comme un conteneur. Kubernetes est un orchestrateur : il déploie, supervise et fait évoluer ces conteneurs sur un parc de serveurs. Cette distinction est l'une des plus mal comprises de l'écosystème, alors queles deux outils répondent en réalité à des besoins différents et complémentaires.

Kubernetes est-il gratuit ?

Le logiciel est open source et gratuit, sous licence Apache 2.0. Mais l'infrastructure sur laquelle il tourne, le temps d'ingénierie pour le maintenir et les outils complémentaires (supervision, sauvegardes, sécurité) ont un coût réel. C'est pourquoi de nombreuses entreprises optent pour un Kubernetes managé.

Faut-il toujours Kubernetes pour déployer en production ?

Non. Kubernetes apporte une orchestration sophistiquée, particulièrement adaptée aux architectures distribuées exigeant portabilité, écosystème CNCF, ou orchestration avancée. Pour beaucoup d'autres contextes, un PaaS répond aux mêmes objectifs (déploiement industrialisé, autoscaling, résilience) sans la complexité opérationnelle. Et dans la pratique, les deux approches cohabitent souvent dans une même architecture.

Quelle différence entre K3S et K8S ?

K3S est une distribution Kubernetes certifiée par la CNCF (donc pas un fork), allégée et conçue pour les environnements aux ressources limitées : edge, IoT, machines de développement, petits clusters. Elle remplace certains composants par des alternatives plus légères et tient dans un binaire unique. Les différences entre K3S et K8S tiennent à plusieurs choix d'architecture précis qu'il faut peser avant de choisir.

Comment commencer avec Kubernetes ?

Le plus rapide est de monter un cluster local avec Minikube, kind ou k3d, puis de déployer une application simple via un manifeste YAML. Pour passer en production, le choix raisonnable pour la majorité des équipes est un Kubernetes managé.

Cela représente une étape importante, issue de trois années de préparation, et s’inscrit dans une stratégie plus large visant à conserver un contrôle complet sur l’infrastructure réseau de notre région Paris.

Pourquoi ce changement

Aux débuts de Clever Cloud, nous avons délégué la gestion du réseau à des partenaires. Ce choix était logique : il nous permettait d’accélérer le développement, de nous concentrer sur les services cloud, et d’éviter d’investir immédiatement dans une expertise que nous ne maîtrisions pas encore.

Mais à mesure que notre infrastructure a grandi, les limites de cette dépendance sont devenues évidentes. Nous n’avions aucun contrôle sur des décisions stratégiques : la manière dont le trafic était routé sur Internet, les chemins empruntés par nos paquets, ou la rapidité avec laquelle nous pouvions réagir aux incidents. Chaque modification, chaque incident nécessitait l’intervention d’un tiers.

Nous avons donc décidé de reprendre cette responsabilité. Cela nous a permis d’obtenir plusieurs avantages concrets. Nous optimisons les coûts grâce à la gestion directe de nos relations de transit et de peering. Nous définissons notre propre politique de routage au lieu de subir les contraintes d’un intermédiaire. Nous résolvons les incidents nous-mêmes, sans dépendre de fournisseurs externes. Et nous obtenons un contrôle complet de notre stack réseau — dans la continuité du contrôle que nous avons progressivement acquis sur nos serveurs et nos datacenters au cours des dernières années.

Mais cette transition ne concerne pas uniquement notre indépendance opérationnelle. Elle apporte des bénéfices immédiats et concrets pour nos utilisateurs. Le plus important est la résilience. Auparavant, l’ensemble du trafic passait par un seul fournisseur. Tout incident de leur côté impactait l’ensemble des services. Nous disposons désormais de quatre fournisseurs upstream répartis sur trois datacenters en région parisienne. Lorsqu’un lien tombe — ce qui s’est produit au cours de l’année passée — le trafic bascule automatiquement vers les alternatives disponibles, sans interruption pour les utilisateurs. Nous pouvons même absorber la perte simultanée de plusieurs liens de transit.

Au-delà de la redondance, nous gagnons le contrôle du routage lui-même. Nous décidons désormais comment le trafic atteint sa destination. Cela nous permet d’optimiser les chemins pour réduire la latence et améliorer les performances, et d’ajuster ces décisions en fonction des besoins spécifiques et de la topologie réseau. Nous réagissons en temps réel à la congestion, aux variations du réseau et aux contraintes opérationnelles.

Enfin, la responsabilité opérationnelle change. Les incidents réseau ne nécessitent plus d’attendre qu’un fournisseur externe les prenne en charge. Les défaillances du réseau public relèvent directement de notre responsabilité : nous les détectons, les analysons et les corrigeons. Cela réduit directement le temps entre l’apparition d’un problème et sa résolution, ce qui améliore la disponibilité et la fiabilité pour nos utilisateurs.

Exploiter son propre réseau sur Internet

Pour opérer un réseau indépendant sur Internet, une organisation doit travailler avec un registre Internet régional (RIR). Les RIR sont responsables de l’attribution et de la gestion des adresses IP et des numéros d’AS dans des zones géographiques spécifiques.

Il existe cinq RIR dans le monde :

• RIPE NCC — Europe, Asie centrale et Moyen-Orient
• ARIN — Amérique du Nord (États-Unis, Canada, Caraïbes)
• LACNIC — Amérique latine et Caraïbes
• APNIC — région Asie-Pacifique
• AFRINIC — Afrique

Pour Clever Cloud, dont l’infrastructure est principalement en Europe, nous travaillons avec le RIPE NCC (Réseaux IP Européens).

Espace d’adressage alloué

En tant que membre d’un RIR, une organisation reçoit des allocations d’adresses IPv4 et IPv6. Pour les membres du RIPE NCC, cela correspond généralement à un bloc IPv4 en /24 (selon disponibilité) et un bloc IPv6 en /29. Ces ressources sont associées à l’organisation et peuvent être utilisées pour opérer un réseau à l’échelle globale.

Création de notre système autonome

Les bases de cette transition ont été posées plusieurs années auparavant. En 2019, nous avons créé notre compte RIPE NCC afin de devenir LIR (Local Internet Registry). Cela nous a permis d’obtenir un bloc IPv4 /24 (91.208.207.0/24) et un bloc IPv6 /29 (2a0f:d0c0::/29).

Puis, en 2022, nous avons enregistré notre numéro de système autonome (ASN) auprès du registre régional. Notre numéro d’AS est AS213394.

> whois AS213394

aut-num:        AS213394
as-name:        CleverCloud
org:            ORG-CCS42-RIPE
import:         from AS29075 accept ANY
import:         from AS3257 accept ANY
import:         from AS3356 accept ANY
import:         from AS43424 accept ANY
export:         to AS29075 announce AS213394:AS-CLVRCLD
export:         to AS3257 announce AS213394:AS-CLVRCLD
export:         to AS3356 announce AS213394:AS-CLVRCLD
export:         to AS43424 announce AS213394:AS-CLVRCLD
admin-c:        QA171-RIPE
tech-c:         QA171-RIPE
status:         ASSIGNED
mnt-by:         RIPE-NCC-END-MNT
mnt-by:         mnt-fr-clvrcldnet-1
created:        2022-11-28T08:24:23Z
last-modified:  2025-02-25T16:36:15Z
source:         RIPE

Un ASN (Autonomous System Number) est un identifiant unique attribué à un réseau sur Internet. Il est nécessaire pour annoncer des routes via BGP, le protocole qui permet le routage entre réseaux.

Maintenant que nous disposons d’un ASN, nous pouvons annoncer nos préfixes aux autres réseaux via le protocole BGP.

Le rôle de la base de données RIPE

Le RIPE NCC maintient une base de données publique d’objets de routage (comme l’objet aut-num présenté précédemment). Parmi ces objets figurent les objets de type route, qui indiquent quel système autonome (AS) est autorisé à annoncer un préfixe IP donné.

En pratique, ces entrées sont principalement utilisées par les opérateurs réseau et les fournisseurs de transit pour construire leurs politiques de routage et leurs mécanismes de filtrage (filtrage basé sur l’IRR). Ces filtres permettent d’accepter ou de rejeter les annonces reçues de leurs pairs. Il s’agit d’un des mécanismes utilisés pour tenter de prévenir les détournements BGP (BGP hijacks).

En appliquant ces filtres aux routes reçues de leurs pairs, les opérateurs peuvent limiter la propagation d’un préfixe annoncé par un ASN non autorisé.

Prenons un exemple : imaginons que l’organisation A possède le préfixe 192.0.2.0/24 et l’annonce à un fournisseur de transit X. Le fournisseur X applique un filtre sur les routes reçues de l’organisation A afin de n’accepter que les préfixes IP enregistrés dans la base RIR de cette organisation.

Dans ce cas, si l’organisation A commence à annoncer un préfixe qui ne lui appartient pas (par exemple notre préfixe public 91.208.207.0/24), le fournisseur X est censé rejeter cette annonce. Cela permet d’éviter qu’une route incorrecte soit propagée sur Internet et que le trafic soit redirigé vers une entité non légitime.

Le protocole BGP : comment Internet route le trafic

Pour comprendre comment nous annonçons nos préfixes sur Internet, il est essentiel de comprendre BGP — le Border Gateway Protocol. BGP est le protocole de routage de référence sur Internet. Il permet aux réseaux (systèmes autonomes) d’échanger des informations sur les préfixes IP qu’ils possèdent et sur la manière de les atteindre.

BGP fonctionne dans les deux sens. Lorsque nous annonçons à nos pairs et à nos fournisseurs de transit « nous possédons 91.208.207.0/24 », cette annonce se propage sur Internet de réseau en réseau. Chaque réseau qui relaie cette annonce ajoute son propre numéro d’AS dans le AS_PATH — une liste qui représente la séquence de réseaux qu’un paquet doit traverser pour nous atteindre.

Par exemple, OVHcloud (AS16276) voit le chemin [AS29075, AS213394] : le trafic passe par l’un de nos fournisseurs de transit (AS29075), puis arrive jusqu’à nous (AS213394). Chaque réseau qui relaie l’annonce la met à jour de cette manière, construisant progressivement un chemin complet.

Voici un exemple obtenu via le service Looking Glass d’OVHcloud :

> show route for 91.208.207.0/24 all

91.208.207.0/24    via 172.18.16.0 on eno1 [lil1_rbx1_bagg1_8k 2025-12-25] * (100/0) [AS213394i]
    Type: BGP unicast univ
    BGP.origin: IGP
    BGP.as_path: 29075 213394
    BGP.next_hop: 172.18.16.0
    BGP.med: 161
    BGP.local_pref: 40
    BGP.community: (0,0) (29075,18000) (65535,65281)
    BGP.23 [t]: 00 00 b8 6e
                   via 172.18.16.64 on eno1 [lil1_rbx8_bagg1_8k 2025-12-25] (100/0) [AS213394i]

Dans le même temps, nous recevons des annonces provenant d’autres réseaux concernant leurs propres préfixes et les chemins permettant de les atteindre. Cela construit la vue inverse : lorsque nous devons envoyer du trafic sortant, nous savons quel chemin emprunter pour atteindre une destination donnée.

Voici un exemple avec un préfixe d’OVHcloud :

> /routing/route/print detail where dst-address=5.39.0.0/17 and active

Ab   afi=ip4 contribution=active dst-address=5.39.0.0/17 routing-table=main pref-src=185.133.116.2 gateway=213.242.111.201 immediate-gw=213.242.111.201%sfp28-6 distance=20 scope=40 target-scope=10 belongs-to="bgp-IP-213.242.111.201"

      bgp.as-path="3356,16276" bgp.communities=3356:2,3356:2066,3356:22,16276:40001,3356:100,65002:7018,3356:123,3356:901,65002:701,65000:64990,65000:64995,65000:64996,3356:502 .med=0 .atomic-aggregate=no .origin=igp

Dans cet exemple, le chemin réseau utilisé par OVHcloud pour nous atteindre est différent de celui que nous utilisons pour les atteindre.

Le processus de migration

os préfixes IP étaient entièrement gérés par notre fournisseur historique. Bien que nous en soyons propriétaires, nous lui avions délégué leur annonce sur Internet.

Cela impliquait que son ASN (AS43424) apparaissait comme origine dans les tables de routage, et que l’ensemble du trafic transitait par son infrastructure.

Clever Cloud Services
   |
   | all inbound/outbound traffic
   v
Historical Provider (AS43424)
   |
   | originates: 91.208.207.0/24 (origin AS43424)
   v
Internet

Nous voulions que notre ASN devienne l’origine des annonces. Pour cela, nous avons planifié une migration en trois étapes, sans interruption pour les utilisateurs.

Migration d’un préfixe entre AS

Pour migrer un préfixe d’un AS vers un autre, nous devions modifier son objet route dans la base de données RIPE. La procédure était relativement simple, mais nécessitait un timing précis.

Nous avons d’abord créé un second objet route dans la base RIPE pour notre préfixe 91.208.207.0/24. Désormais, les deux ASN étaient enregistrés comme autorisés à annoncer ce même préfixe — à la fois l’AS de notre fournisseur historique et notre propre AS (213394).

Ces objets de routage sont interrogeables publiquement via la commande whois ou via l’interface web du RIPE. Par exemple, la commande suivante permet d’obtenir les deux objets enregistrés :

❯ whois -h whois.ripe.net -T route 91.208.207.0/24
% Information related to '91.208.207.0/24AS213394'

route:          91.208.207.0/24
mnt-by:         mnt-fr-clvrcldnet-1
descr:          CleverCloud subnet
origin:         AS213394
created:        2025-01-15T10:29:14Z
last-modified:  2025-01-15T10:29:14Z
source:         RIPE

% Information related to '91.208.207.0/24AS43424'

route:          91.208.207.0/24
mnt-by:         mnt-fr-clvrcldnet-1
mnt-by:         MAGICRETAIL-MNT
descr:          CleverCloud subnet
origin:         AS43424
created:        2020-02-13T09:06:33Z
last-modified:  2020-02-13T09:06:48Z
source:         RIPE

Une fois ce second objet route enregistré et propagé sur Internet (c’est-à-dire une fois que les opérateurs réseau ont récupéré une version à jour de la base RIPE pour construire leurs filtres de routage), nos nouveaux fournisseurs de transit pouvaient constater que notre ASN était autorisé à annoncer ce préfixe. À partir de ce moment-là, nous pouvions commencer à annoncer ce préfixe via notre propre infrastructure.

Si nous n’avions pas créé cet objet route, nos annonces auraient pu être rejetées et nous aurions pu être considérés comme des acteurs malveillants réalisant un détournement BGP (BGP hijack).

Annonce via notre fournisseur historique

Une fois le second objet route propagé, nous avons réalisé la première étape dans la nuit du 16 janvier 2025 : nous avons commencé à annoncer nous-mêmes le préfixe via BGP à notre fournisseur historique.

Le trafic continuait d’emprunter le même chemin de transit, mais cette fois avec Clever Cloud (AS213394) comme origine des annonces, au lieu de notre fournisseur historique. Ce dernier continuait à relayer le préfixe, mais le recevait désormais de notre part au lieu de l’annoncer directement.

Clever Cloud Services (AS213394)
   |
   | originates: 91.208.207.0/24 (origin AS213394)
   v
Historical Provider (AS43424)
   |
   | re-announces: 91.208.207.0/24 (origin AS213394)
   v
Internet

Cette première phase a servi de validation : en cas de problème, nous pouvions revenir rapidement en arrière sans impacter les autres chemins de transit.

Annonce via nos propres transits

Quelques jours plus tard, dans la nuit du 21 janvier 2025, nous avons franchi l’étape finale : nous avons commencé à annoncer le préfixe via nos propres connexions de transit dédiées.

Clever Cloud Services (AS213394)
   |
   | originates: 91.208.207.0/24 (origin AS213394)
   |
   +---+---+---+
   |   |   |   |
   v   v   v   v
  T1  T2  T3  HP
(Transit providers + historical provider)
   |   |   |   |
   +---+---+---+
   |
   v
Internet

Nous annonçons désormais nos préfixes directement à quatre fournisseurs upstream (trois fournisseurs de transit, T1/T2/T3, ainsi que notre fournisseur historique HP). Le trafic circule à travers l’ensemble de ces chemins, et nous disposons d’un contrôle complet sur les décisions de routage ainsi que sur la redondance.

Tout au long de ces deux phases, nous n’avons observé aucune interruption ayant un impact pour les utilisateurs. La redondance intrinsèque du protocole BGP, combinée à la nature progressive de la transition, a permis d’assurer un écoulement du trafic sans interruption, quel que soit le chemin privilégié à un instant donné.

Visibilité complète du routage Internet

Dans le cadre de la phase 2, nos trois principaux fournisseurs de transit ont commencé à nous fournir une « full view » de la table de routage Internet. Il s’agit de l’ensemble complet des préfixes IPv4 et IPv6 publiquement annoncés — soit environ 1 million de routes IPv4 et 220 000 routes IPv6.

Disposer d’une full view nous offre une visibilité inédite sur la structure d’Internet et nous permet de prendre des décisions de routage avancées. Au lieu de dépendre de la vision d’un seul fournisseur, nous avons désormais accès à l’ensemble des chemins disponibles pour atteindre n’importe quelle destination.

Avec ces informations, nous sommes en mesure de choisir les chemins optimaux pour notre trafic sortant en fonction de notre topologie réseau et de nos préférences, de mettre en œuvre du traffic engineering pour diriger les flux via des fournisseurs de transit spécifiques, de réagir dynamiquement aux conditions réseau et à la congestion, et d’équilibrer la charge entre nos quatre connexions de transit en nous appuyant sur des données de routage en temps réel.

Ce niveau de contrôle fin sur notre politique de routage est une conséquence directe de l’exploitation de notre propre système autonome et de la gestion de nos propres annonces — exactement le niveau d’indépendance opérationnelle que nous recherchions au début de cette transition.

Un an plus tard

Près d’un an après le début de l’exploitation de nos propres annonces réseau, la transition s’est révélée concluante. Nous n’avons rencontré aucun incident majeur et notre infrastructure a démontré sa résilience. Lorsque des incidents mineurs se sont produits — comme des pertes de paquets sur un fournisseur de transit spécifique ou la perte temporaire d’un lien — le trafic s’est automatiquement rééquilibré sur les connexions restantes.

Nous avons pu détecter et corriger ces problèmes directement, sans dépendre d’un fournisseur tiers. Nos utilisateurs n’ont subi aucune interruption ayant un impact. Cette capacité à assumer la responsabilité de notre réseau et à résoudre rapidement les problèmes est sans doute le principal bénéfice de cette transition.

Et ensuite

Cette transition est loin d’être terminée. Plusieurs évolutions sont prévues :

• augmentation de la capacité réseau pour absorber la croissance du trafic
• mise en place de peering BGP avec d’autres réseaux pour optimiser le trafic local sans recourir au transit
• déploiement de ROA (Route Origin Authorization) pour signer cryptographiquement nos annonces et prévenir les détournements de préfixes
• validation RPKI (Resource Public Key Infrastructure) pour vérifier la légitimité des annonces reçues et renforcer la sécurité du routage
• extension d’IPv6, en entrée (réception de trafic IPv6) comme en sortie (émission de trafic IPv6), déployée progressivement

Conclusion

Début 2025, Clever Cloud a finalisé sa transition vers une exploitation entièrement autonome de son réseau. Nous annonçons désormais nos propres préfixes IP via quatre fournisseurs upstream, ce qui nous donne un contrôle complet sur la manière dont le trafic entre et sort de notre infrastructure.

Pour nos utilisateurs, cela se traduit par une meilleure fiabilité et des temps de résolution plus courts dans notre région Paris. Lorsqu’un incident réseau survient, nous le traitons directement, et notre redondance multi-fournisseurs garantit la continuité du trafic.

Cette étape marque le début d’une nouvelle phase. Nous travaillons déjà sur le peering BGP pour optimiser le trafic local, sur le déploiement de ROA et la validation RPKI pour renforcer la sécurité du routage, ainsi que sur l’extension d’IPv6 pour généraliser le dual-stack. Nous construisons un réseau aussi robuste et autonome que le reste de notre infrastructure.

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.

Dans ce contexte, la question n'est plus de savoir s'il faut migrer, mais comment structurer ce qui existe, maîtriser les opérations au quotidien et conserver le contrôle sur ses environnements et ses données.

Le mardi 28 avril à 11 h 30, Clever Cloud et Cycloid organisent un webinaire pour aborder ces enjeux.

Deux regards croisés sur un problème commun

Nous vous proposons un échange croisé pour apporter un éclairage concret sur ces sujets.

Cycloid traite la structuration et la gouvernance des environnements au travers d'un portail et d'une plateforme de développement interne unifiés. Clever Cloud aborde l’exploitation managée, le maintien en condition opérationnelle (MCO) et la souveraineté opérationnelle.

Rejoignez Florent Perreux (Chief Sales Officer @ Clever Cloud), Steven Le Roux (CTO @ Clever Cloud), Alexandre Blin (Business Director SEMEA @ Cycloid) et Olivier de Turckheim (Solution Architect @ Cycloid) pour comprendre comment articuler gouvernance et exploitation sans ajouter de complexité.

Au programme

🔹 Pourquoi la modernisation cloud ne se limite plus à une migration ;

🔹 Les enjeux de structuration et de gouvernance dans des environnements multi-cloud ;

🔹 Les défis opérationnels liés à l’exploitation et au MCO ;

🔹 Comment articuler gouvernance et exploitation sans multiplier la complexité ;

🔹 Une session Q&A pour poser vos questions en direct.

Pourquoi participer ?

✅ Comprendre les causes réelles de la complexité dans les projets cloud ;

✅ Identifier les leviers pour structurer vos usages et limiter la dépendance fournisseur ;

✅ Mieux appréhender les enjeux d’exploitation et de souveraineté ;

✅ Bénéficier de retours d’expérience concrets ;

✅ Échanger directement avec des experts.

Inscrivez-vous dès maintenant

🗓️ Mardi 28 avril 2026

⏰ 11h30 - 12h00

💻 Webinaire en ligne sur Livestorm

Vous êtes confronté à ces enjeux, rejoignez-nous le 28 avril prochain !

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

Conçu pour la production et la scalabilité

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

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

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

Souverain par conception

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

Modalités d'accès

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

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

En savoir plus

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

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

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

Qu'est-ce qu'OpenTofu ?

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

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

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

Quelle différence concrète avec Terraform ?

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

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

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

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

Pourquoi des équipes migrent vers OpenTofu

Trois raisons reviennent systématiquement.

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

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

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

Migrer de Terraform vers OpenTofu

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

OpenTofu sur Clever Cloud : rien à changer

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

terraform {

  required_providers {

    clevercloud = {

      source  = "CleverCloud/clevercloud"

      version = "~> 1.10"

    }

  }

}

provider "clevercloud" {organisation}

resource "clevercloud_node" "app" {

  name       = "mon-app-node"

  region     = "par"

  min_flavor = "XS"

  max_flavor = "M"

}

resource "clevercloud_postgresql" "db" {

  name   = "ma-base-postgres"

  region = "par"

  plan   = "dev"

}

tofu init

tofu plan

tofu apply

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

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

FAQ

OpenTofu est-il compatible avec mes configurations Terraform existantes ?

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

OpenTofu est-il prêt pour la production ?

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

Quelle est l'alternative open source à Terraform ?

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

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

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

Comment fonctionne OpenTofu ?

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

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

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

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

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

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

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

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

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

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

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

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

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

Les cadres publics existants pour déployer un PaaS

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

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

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

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

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

Dans quels cas le PaaS est particulièrement pertinent

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

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

Points de vigilance avant de faire ce choix

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

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

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

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