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

K8s : le Kubernetes standard entreprise

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

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

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

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

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

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

Ce que K3s change par rapport à K8s

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

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

Empreinte ressources

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

Différences techniques clés

Datastore

Runtime et packaging

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

Architecture du plan de contrôle

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

Scalabilité

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

Tableau comparatif K3s vs K8s

Cas d'usage : lequel choisir ?

Choisissez K3s si :

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

Choisissez K8s (ou une distribution enterprise) si :

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

Cas hybrides : K3s et K8s ensemble

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

Fleet management avec Rancher

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

Clusters de dev et staging K3s, prod K8s

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

CI/CD

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

Kubernetes managé : une troisième voie

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

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

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

FAQ

K3s est-il un fork de Kubernetes ?

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

Peut-on utiliser K3s en production ?

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

K3s supporte-t-il Helm ?

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

Quelle est la différence entre K3s et K3d ?

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

K3s fonctionne-t-il sur ARM ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Là où Docker atteint ses limites

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

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

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

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

Kubernetes : automatiser l’exploitation des conteneurs

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

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

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

Un exemple concret : Docker seul vs Kubernetes

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

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

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

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

Kubernetes vs Docker : lequel remplace l'autre ?

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

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

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

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

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

Quand utiliser Docker sans Kubernetes ?

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

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

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

Quand Kubernetes devient réellement utile

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

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

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

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

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

Docker vs Kubernetes : les différences à retenir

Docker et Kubernetes ne sont pas des technologies concurrentes

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

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

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

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

FAQ

Docker et Kubernetes sont-ils concurrents ?

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

Kubernetes remplace-t-il Docker ?

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

Pourquoi Kubernetes est-il devenu un standard ?

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

Quelle différence entre K3S et Kubernetes classique ?

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

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

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

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 !

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

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

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

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

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

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

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

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

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

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

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

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

Les cadres publics existants pour déployer un PaaS

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

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

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

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

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

Dans quels cas le PaaS est particulièrement pertinent

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

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

Points de vigilance avant de faire ce choix

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La question du coût total et de la gouvernance

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

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

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

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

Comment évaluer objectivement les solutions du marché ?

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

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

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

Une méthode simple pour choisir la bonne solution cloud

La démarche la plus efficace consiste à :

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

Ce que Clever Cloud apporte sur ces sujets

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

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

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

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

Le support est humain et assuré depuis la France.

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

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

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

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

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

Contactez-nous

En plus de l’octroi de crédits cloud, les startups sélectionnées bénéficient d’un onboarding personnalisé avec nos ingénieurs, de coaching, d’un accès à nos workshops et masterclasses, ainsi que d’une mise en visibilité sur nos canaux médias et événements.

L’objectif est clair : leur permettre de se concentrer sur leur cœur de métier, tout en s’appuyant sur une infrastructure cloud fiable, automatisée et souveraine.

Les nouvelles startups de la 3ème promo UP

Cette année, sept jeunes pousses innovantes rejoignent le programme UP. Elles couvrent des secteurs variés – e-commerce, finance, santé, énergie, data – avec un point commun : utiliser la technologie pour répondre à des enjeux concrets.

Chaynon : lutter contre la fraude au remboursement

Chaynon propose un outil d’aide à la décision destiné aux marketplaces et e-commerçants pour lutter contre la fraude aux remboursements. Leur solution permet de détecter les comportements suspects et de réduire les pertes liées aux abus, tout en protégeant les marges des commerçants.

Klafuti : automatiser les données comptables

Klafuti a conçu une plateforme SaaS à destination des professionnels du chiffre (cabinet comptable, expert-comptable…) qui permet d’automatiser l’extraction, la transformation et l’intégration de données comptables. Cette approche simplifie le quotidien des experts et libère du temps pour le conseil stratégique.

Wattflow : optimiser l’énergie dans les bâtiments professionnels

Wattflow orchestre les systèmes de chauffage, ventilation et climatisation de vos immeubles tertiaires en dialoguant directement avec vos machines. Jusqu’à 40 % d’économies d’énergie et de coûts associés, et un meilleur confort pour les usagers. En connectant directement les équipements techniques, Wattflow combine optimisation énergétique et amélioration du confort.

thaink² : simplifier les projets Data & IA

thaink² Analytics est la plateforme Data & IA qui simplifie vos projets de bout en bout. SaaS no-code, intuitive et pensée par des experts. Fini les pipelines de données instables, les modèles ML/IA qui restent au stade du POC. L’objectif : rendre l’IA opérationnelle et accessible à toutes les entreprises, sans complexité technique.

LiteoMED : un écosystème digital pour l’oncologie

LiteoMED met en place une plateforme complète dédiée aux oncologues. Elle combine médecine de précision et approche centrée patient, permettant aux praticiens de gagner du temps tout en améliorant la prise en charge et le suivi des patients atteints de cancer.

Kocliko : réduire les dépenses énergétiques et carbone dans l’habitat collectif

Kocliko déploie une solution deeptech unique de pilotage intelligent du chauffage collectif, combinant IA, capteurs certifiés et jumeau numérique pour réduire durablement consommations, émissions et charges locatives.

Cloud Data Engine : sécuriser les échanges de données distribuées

Cloud Data Engine est spécialisée dans la gestion opérationnelle des espaces de données et dans l’automatisation de la conformité des écosystèmes de données décentralisés (dataspaces, catalogues, marketplaces…).

Pourquoi rejoindre le Programme UP ?

Le programme est conçu comme un véritable tremplin pour les startups. En intégrant UP, elles accèdent à un accompagnement technique de haut niveau, à des sessions de mentorat, ainsi qu’à une mise en avant auprès de notre réseau et de nos partenaires.

Chez Clever Cloud, nous sommes convaincus que le cloud doit être un accélérateur, et non un frein, dans le parcours des entrepreneurs. C’est pourquoi nous investissons dans ces jeunes pousses prometteuses et leur donnons les moyens de grandir plus vite.

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

Candidatez dès à présent pour intégrer la prochaine promotion !

Une initiative inédite portée par Gigalis

Créé en 2000 par le Conseil régional des Pays de la Loire, Gigalis s’est imposé comme un acteur clé du numérique public. Devenu Groupement d’Intérêt Public (GIP) en janvier 2025, il accompagne désormais les collectivités et institutions régionales avec des services souverains en matière de connectivité, de cybersécurité, de cloud et de mutualisation des achats numériques. C’est dans cette dynamique qu’a été lancée officiellement le 1er septembre dernier, la Fabrique IA Territoriale, un dispositif unique en France qui associe acteurs publics et entreprises privées pour répondre aux défis de l’intelligence artificielle et de l’Open Source.

Trois lots complémentaires pour structurer l’écosystème IA

L’accord-cadre imaginé par Gigalis a été découpé en trois lots, afin de couvrir l’ensemble du cycle de vie des projets.

1. Le premier concerne le conseil et la sensibilisation à l’intelligence artificielle et a été confié à un groupement d’acteurs nationaux et régionaux, parmi lesquels Linagora, Onepoint, Pyxis support, Synchrone et Wavestone.
2. Le second, dédié à l’intégration dans les communautés, réunit Atos, DRI, Metapolis, Beewant, Reel IT, Cross Data, PARTHEMA, DATA INCEPTIO.AI et Valeuriad.
3. Enfin, le troisième lot, centré sur l’infrastructure, l’hébergement, le déploiement et l’exploitation en Open Source, a été attribué à Clever Cloud, Linagora, DRI, Siium et Reel IT.

Cette organisation garantit une complémentarité forte et permet de proposer aux acteurs publics une offre cohérente, souveraine et adaptée à leurs besoins.

L’expertise de Clever Cloud pour le Lot 3

La participation de Clever Cloud à la Fabrique IA Territoriale s’inscrit pleinement dans notre mission : fournir un cloud européen et sécurisé qui libère les organisations publiques des contraintes techniques. Concrètement, notre approche s’appuie sur des briques open source éprouvées, intégrées dans une infrastructure automatisée afin de garantir interopérabilité, performance et sécurité. Dans le même temps, nous assurons un haut niveau de disponibilité, une supervision continue et un engagement mesurable à travers des indicateurs de qualité transparents.

Au-delà de la technique, notre contribution consiste également à transmettre nos compétences afin de rendre progressivement les bénéficiaires autonomes. Cette logique de transfert de savoir-faire est au cœur de notre démarche : accompagner, sécuriser et rendre pérennes les projets numériques, sans dépendance vis-à-vis d’acteurs extérieurs.

Un engagement pour la souveraineté numérique régionale

La Fabrique IA Territoriale est plus qu’un accord-cadre : c’est une vision collective d’un numérique de confiance, pensé pour les territoires. En rejoignant cette initiative, Clever Cloud renforce son engagement en faveur d’une alternative européenne crédible face aux grands opérateurs internationaux. Cette démarche permet aux collectivités de bénéficier d’infrastructures modernes et résilientes, tout en soutenant l’écosystème économique ligérien.

Pour Clever Cloud, cette participation illustre la convergence entre nos valeurs et celles portées par Gigalis : souveraineté, coopération et durabilité. Nous croyons qu’un numérique éthique et responsable doit s’appuyer sur des solutions ouvertes, sécurisées et accessibles à tous les acteurs publics.

Conclusion et perspectives

Notre rôle dans la Fabrique IA Territoriale confirme notre volonté d’accompagner la transformation numérique des services publics, en leur donnant les moyens de piloter leurs projets avec efficacité et transparence. Aux côtés de partenaires engagés, nous mettons l’automatisation, la sécurité et la souveraineté au service de l’intelligence collective et de l’innovation locale.

Pour aller plus loin et découvrir comment Clever Cloud peut accompagner vos projets publics et territoriaux :

Contactez-nous

Pour Madietenligne, plateforme qui accompagne plus de 2 500 diététicien·ne·s dans la gestion de leur activité, garantir cette conformité devenait de plus en plus complexe… jusqu’à leur migration vers le PaaS certifié HDS de Clever Cloud.

Le mardi 17 juin 2025 à 11 h 30, Madietenligne revient sur ce virage stratégique lors d’un webinar certification HDS.

Pourquoi un webinar sur la conformité HDS ?

En tant qu’hébergeur de données de santé certifié sur les 6 activités prévues par le référentiel, Clever Cloud soutient les éditeurs qui veulent se concentrer sur leur métier, sans sacrifier la sécurité ni la souveraineté.

Dans ce webinar, nous aborderons :

• Un panorama clair des obligations HDS et de leur impact concret sur votre solution ;
• Le « fast‑track » conformité HDS : bénéficier immédiatement d'un cloud certifié et souverain, sans formalités réglementaires ni administratives à gérer ;
• Les coulisses de la migration < 3 semaines de Madietenligne et les gains observés (sécurité, scalabilité, souveraineté) ;
• Les points que vous souhaiterez éclaircir, au travers d'une session Q&A en direct.

Au programme

Rejoignez Florent Perreux (Chief Sales Officer @ Clever Cloud) et Eddy Montus (Co-fondateur @ MaDietEnLigne) pour explorer, pas à pas, les défis et les gains d’une migration vers un cloud souverain et conforme HDS.

Au menu :

🔹 Les enjeux de la conformité HDS pour les entreprises traitant des données de santé ;

🔹 Les bénéfices concrets d’un PaaS certifié HDS ;

🔹 L’expérience d’un client engagé sur les sujets de sécurité et de souveraineté ;

🔹 Une session Q&A pour poser vos questions.

Pourquoi participer ?

🔖 Comprendre les obligations HDS et savoir comment y répondre ;

🎯 Découvrir un retour d’expérience concret avec un éditeur SaaS santé engagé ;

👑 Explorer une solution cloud souveraine, scalable et conforme ;

❓ Échanger en direct avec nos intervenants.

🗣️ « En moins de trois semaines, nous avons migré nos environnements de dev et de prod.  Et le plus important, je suis plus que satisfait du service et de l'excellence du support !» — Eddy Montus, Co-fondateur @ Madietenligne

Inscrivez-vous dès maintenant

📅 Mardi 17 juin 2025

⏰ 11h30 - 12h00

💻 Webinar en ligne sur Livestorm

Vous codez, nous garantissons la conformité HDS, alliée à un hébergement souverain, scalable et automatisé. Rejoignez‐nous le 17 juin pour découvrir comment ! 🚀

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

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

Je prends rendez-vous !

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

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

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

Qu’est-ce que la certification HDS ?

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

Pourquoi choisir un cloud HDS ?

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

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

Sécurisation et confidentialité des données

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

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

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

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

Contactez nos équipes