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

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

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

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

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

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

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

Pictaderm — L’expertise dermatologique en pharmacie

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

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

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

Legaia — Un assistant juridique IA pensé par des avocats

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

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

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

Cockpit Agriculture — Piloter la performance agricole

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

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

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

Une promotion représentative des enjeux des startups technologiques

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Comprendre les déploiements avancés sur Clever Cloud

La certification Advanced Deployments repose sur cinq modules principaux :

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

Une certification pensée pour les environnements réels

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

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

Valoriser sa progression

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

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

Passez Advanced Deployments dès maintenant

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

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

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

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

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

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

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

Kubernetes : un standard, mais pas seulement un orchestrateur

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

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

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

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

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

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

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

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

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

PaaS et Kubernetes : deux approches complémentaires

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

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

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

Un webinar pour voir concrètement comment ça fonctionne

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

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

Au programme

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

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

Pourquoi participer ?

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

Vous pourrez notamment :

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

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

Inscrivez-vous dès maintenant

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

À propos d’OVHcloud

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

À propos de DEEP by POST Luxembourg Group

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

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

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

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

À propos de Clever Cloud

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

C’est dans ce contexte que la stack ELK s’est imposée comme un socle technique pour analyser, rechercher et visualiser des données techniques, en particulier les logs. Dans cet article, nous répondons à trois questions essentielles :

• ELK Stack, c’est quoi exactement ?
• À quoi ça sert aujourd’hui, notamment pour l’observabilité ?
• Comment l’utiliser efficacement sans gérer toute l’infrastructure ?

ELK Stack : définition claire

ELK Stack est un acronyme qui désigne historiquement trois composants :

• Elasticsearch : moteur distribué de recherche et d’analyse ;
• Kibana : interface de visualisation et d’exploration des données ;
• Logstash : outil de collecte et de transformation de données (selon les contextes).

À l’heure actuelle, Elasticsearch et Kibana constituent le cœur fonctionnel de la stack ELK, en particulier pour les usages d’analyse et de visualisation des données techniques, une fois les données ingérées dans Elasticsearch.

On parle parfois d’Elastic Stack, un terme plus large qui englobe l’écosystème Elastic dans son ensemble. Dans l’usage courant, notamment en environnement cloud, l’ELK Stack désigne l’association d’un mécanisme de collecte, souvent basé sur des agents, avec Elasticsearch pour le stockage et l’analyse, et Kibana pour la visualisation.

À quoi sert ELK Stack ?

ELK Stack sert à centraliser, analyser et exploiter des données techniques issues de systèmes et d’applications. Elle permet d’indexer de grands volumes de données, d’effectuer des recherches et des analyses sur de larges plages temporelles, en croisant des données issues de multiples sources, services ou environnements.

Cette capacité d’analyse en fait un outil largement utilisé pour comprendre le comportement d’une application, diagnostiquer des incidents, investiguer des anomalies ou explorer des données opérationnelles. L’intérêt principal réside dans la possibilité de passer rapidement de données brutes à des informations exploitables, sans dépendre d’outils spécialisés pour chaque cas d’usage.

ELK Stack et observabilité : quel lien ?

L’observabilité vise à comprendre l’état interne d’un système à partir de ses signaux observables. Parmi ces signaux, les logs jouent un rôle central, car ils décrivent précisément ce que fait une application à un instant donné.

Dans ce cadre, ELK Stack constitue un socle particulièrement adapté à l’observabilité orientée logs. Elasticsearch permet de rechercher et de corréler des événements à grande échelle, tandis que Kibana offre une lecture visuelle qui facilite l’analyse et l’interprétation. L’ensemble permet d’identifier des comportements anormaux, de reconstituer la chronologie d’un incident ou d’analyser des tendances sur la durée.

Comment utiliser ELK Stack sans gérer l’infrastructure

L’un des principaux freins à l’adoption d’ELK Stack a longtemps été sa complexité opérationnelle. Déployer, maintenir et faire évoluer une telle stack implique de gérer le dimensionnement, les mises à jour, la sécurité ou encore les sauvegardes.

En environnement cloud, cette charge peut rapidement détourner les équipes de leur objectif principal, qui est l’analyse des données et non la gestion de l’infrastructure. C’est pour cette raison que de plus en plus d’équipes se tournent vers des approches managées.

Approche managée

Dans une approche managée, Elasticsearch et Kibana sont fournis sous forme de services prêts à l’emploi. L’infrastructure sous-jacente et une partie des opérations courantes (mise à disposition du service, maintenance, sauvegardes, contrôle d’accès selon le modèle de la plateforme) sont pris en charge par la plateforme, ce qui permet aux équipes de se concentrer sur les usages.

Dans ce modèle, la collecte des logs est assurée par les mécanismes de la plateforme. Sur Clever Cloud, les applications et add-ons peuvent exposer leurs logs via des drains, qui permettent de les rediriger vers un Elasticsearch cible, sans déployer d’outil de collecte dans le PaaS.

Sur Clever Cloud, il est par exemple possible de créer un add-on Elastic Stack qui fournit :

• un service Elasticsearch managé ;
• une instance Kibana associée ;
• des mécanismes de sécurité et de sauvegarde intégrés ;
• une connexion via les informations d’accès fournies par l’add-on.

Cette approche permet d’exploiter ELK Stack sans gérer les aspects bas niveau, tout en conservant la puissance d’analyse d’Elasticsearch.

Cas d’usage concrets en observabilité

Analyse de logs applicatifs

Centraliser les logs applicatifs dans Elasticsearch permet de rechercher rapidement des erreurs, d’explorer des événements précis ou de filtrer des données selon différents critères. Cette capacité est essentielle pour comprendre le comportement réel d’une application en production.

Diagnostic d’incidents

Lorsqu’un incident survient, la corrélation des événements devient un enjeu clé. ELK Stack permet d’analyser la chronologie des faits, d’identifier les composants impliqués et de mieux comprendre les causes sous-jacentes, sans se limiter à une vision fragmentée des logs.

Suivi du comportement applicatif

Sur la durée, l’analyse des données indexées dans Elasticsearch permet de détecter des tendances, des pics anormaux ou des évolutions de comportement. Les tableaux de bord Kibana facilitent cette lecture et offrent une vision synthétique adaptée aux équipes techniques.

Conclusion

ELK Stack reste aujourd’hui un socle solide pour analyser et exploiter des données techniques, en particulier les logs. Son rôle dans les démarches d’observabilité s’est renforcé avec l’évolution des architectures cloud et distribuées.

En s’appuyant sur le cœur fonctionnel de la stack ELK, à savoir Elasticsearch et Kibana, il est possible de construire un environnement d’analyse adapté aux besoins modernes, sans nécessairement gérer l’infrastructure sous-jacente. Les approches managées permettent de réduire la complexité opérationnelle et de se concentrer sur la valeur des données.

Les usages autour de l’ELK Stack continuent toutefois d’évoluer. Les travaux récents d’Elastic autour de nouveaux modèles de gestion des logs, comme les streams, ouvrent la voie à des approches plus flexibles et mieux adaptées aux volumes actuels. Ces évolutions prolongent les fondations existantes, sans remettre en cause le rôle central d’Elasticsearch dans l’analyse des données d’observabilité.

Pour celles et ceux qui souhaitent explorer ces usages dans un cadre maîtrisé, créer un add-on Elastic Stack sur Clever Cloud constitue une manière pragmatique d’aborder l’observabilité basée sur Elasticsearch, sans transformer l’exploitation en contrainte.

C’est précisément le rôle de l’observabilité. Et c’est aussi la raison pour laquelle Elasticsearch s’est progressivement imposé comme un socle d’analyse pour les logs, les métriques et les traces.

Nous allons voir comment Elasticsearch s’inscrit dans une démarche d’observabilité, au-delà du simple logging, et comment il permet de corréler les signaux techniques pour mieux comprendre le comportement des applications.

Qu’est-ce que l’observabilité, et pourquoi Elasticsearch est concerné

L’observabilité désigne la capacité à comprendre l’état interne d’un système à partir de ses signaux externes. Contrairement au monitoring traditionnel, elle ne se limite pas à des métriques prédéfinies ou à des seuils fixes.

Elle repose sur la collecte de données riches et contextuelles, sur leur analyse transversale et sur la possibilité d’explorer des situations non anticipées. Dans ce cadre, Elasticsearch joue un rôle clé. Son moteur d’indexation et de recherche permet d’analyser de grands volumes de données hétérogènes, structurées ou non, en quasi temps réel, ce qui correspond exactement aux besoins d’une approche d’observabilité moderne.

Les trois piliers de l’observabilité : logs, métriques et traces

Une stratégie d’observabilité repose sur trois types de signaux complémentaires. Chacun répond à une problématique différente.

Logs : comprendre ce qui s’est passé

Les logs sont des événements produits par les applications et les composants d’infrastructure. Dans Elasticsearch, ils sont associés à un horodatage, qu’il provienne du contenu du log lui-même ou du moment de son ingestion. Ils fournissent un niveau de détail élevé et permettent de comprendre le contexte précis d’une erreur, d’un comportement inattendu ou d’un incident.

Elasticsearch est historiquement très adapté à cet usage :

• ingestion de volumes importants ;
• recherche plein texte rapide ;
• exploration fine des événements.

Les logs apportent beaucoup de contexte, mais deviennent difficiles à exploiter seuls lorsque les architectures se distribuent et que les volumes augmentent fortement.

Métriques : mesurer l’état du système

Les métriques sont des données numériques agrégées dans le temps. Elles décrivent l’état global d’un système et permettent de suivre son évolution. Latence, taux d’erreur ou consommation de ressources donnent une vision synthétique de la santé d’une application ou d’une infrastructure.

Dans Elasticsearch, ces données sont stockées sous forme de séries temporelles. Cela permet de réaliser des agrégations, d’analyser des tendances sur la durée et de détecter des anomalies, tout en conservant la possibilité de relier ces métriques à d’autres signaux techniques.

Traces : suivre une requête de bout en bout

Les traces décrivent le parcours complet d’une requête à travers un système distribué. Elles sont essentielles pour comprendre les dépendances entre services et identifier précisément l’origine d’une latence ou d’une erreur.

Chaque trace est composée de plusieurs segments représentant les différentes étapes d’exécution. Une fois indexées dans Elasticsearch, ces traces peuvent être reliées aux logs et aux métriques associées, ce qui facilite l’analyse des comportements complexes dans des environnements microservices.

Comment Elasticsearch corrèle logs, métriques et traces

La valeur de l’observabilité ne réside pas dans chaque signal pris isolément, mais dans leur corrélation. Elasticsearch la facilite grâce à plusieurs mécanismes structurants :

• un moteur d’indexation commun ;
• des schémas partagés comme ECS (Elastic Common Schema), qui fournit une structure commune pour les logs, les métriques et les traces ;
• des capacités de recherche transverses.

Concrètement, cette approche permet de naviguer naturellement entre les signaux. Une alerte issue d’une métrique peut conduire à l’analyse des traces concernées, puis à l’exploration des logs associés à une requête précise. Kibana joue ici un rôle central en rendant ces corrélations visibles et exploitables, grâce à des visualisations, des tableaux de bord et des outils d’exploration adaptés à l’analyse croisée des signaux.

Historiquement, Elasticsearch est surtout connu pour permettre de créer des moteurs de recherche applicatifs, notamment pour indexer et interroger des contenus sur des sites web. Ce même principe de recherche rapide et contextuelle s’applique aux données d’observabilité : logs, métriques et traces sont eux aussi indexés et interrogés comme des ensembles de données, ce qui rend possible leur exploration et leur corrélation à grande échelle.

OpenTelemetry : un standard clé pour l’observabilité avec Elasticsearch

Dans les architectures modernes, la collecte des données est un enjeu aussi important que leur analyse. OpenTelemetry s’est imposé comme un standard ouvert pour l’instrumentation des applications, couvrant à la fois les traces, les métriques et les logs.

Elasticsearch supporte nativement OpenTelemetry, ce qui permet de standardiser la collecte des signaux sans dépendre d’un format propriétaire. Cette compatibilité facilite l’interopérabilité, limite le verrouillage technologique et permet de faire évoluer les outils d’observabilité sans remettre en cause l’instrumentation applicative existante.

Observer ses applications avec Elastic sur Clever Cloud

Sur Clever Cloud, Elasticsearch est proposé sous forme d’add-on managé. Les applications peuvent y envoyer leurs logs via des drains Elasticsearch, ce qui permet de centraliser automatiquement les logs applicatifs. Plusieurs briques peuvent ensuite être activées selon les besoins :

• un Elasticsearch administré ;
• Kibana pour l’exploration et la visualisation ;
• Elastic APM pour l’analyse des performances applicatives.

Cette approche permet de centraliser les logs applicatifs, de collecter des métriques pertinentes et de tracer les requêtes sans avoir à gérer l’infrastructure sous-jacente. L’objectif n’est pas de multiplier les outils, mais de fournir une base d’observabilité cohérente, intégrée au cycle de vie des applications.

Conclusion

L’observabilité ne se résume pas à empiler des outils de monitoring. Elle repose sur la capacité à corréler logs, métriques et traces pour comprendre des systèmes de plus en plus complexes.

Grâce à ses capacités d’indexation, de recherche et d’analyse, Elasticsearch constitue un socle technique solide pour cette approche. Associé à des standards ouverts et à des interfaces comme Kibana, il permet de passer d’une vision fragmentée à une compréhension globale du comportement applicatif.

Dans un environnement cloud moderne, cette corrélation n’est plus un luxe. C’est une condition nécessaire pour exploiter la production de manière fiable.

Depuis son lancement, le Programme UP accompagne des jeunes entreprises technologiques à différents stades de maturité, en mettant l’accent sur la solidité technique, la maîtrise de l’infrastructure cloud et la capacité à faire évoluer un produit dans la durée.

Les précédentes sélections ont permis d’accueillir des startups issues de secteurs variés, allant de la data à la Green IT, en passant par la fintech, la healthtech ou la legaltech. Pour les découvrir :

• Clever Cloud accueille les premières startups du Programme UP
• Programme UP : Qui sont les nouvelles startups lauréates ?
• Programme UP : découvrez les startups de la troisième promotion

Les startups sélectionnées pour cette quatrième édition

Moustache AI – Agent conversationnel IA sur mesure

Moustache AI développe des agents conversationnels et vocaux personnalisés, conçus pour s’adapter aux usages métiers spécifiques de chaque organisation.

La solution permet d’automatiser une grande partie des demandes entrantes tout en conservant un haut niveau de contrôle sur les données, l’hébergement et la conformité réglementaire. Les agents sont déployés rapidement et s’intègrent aux outils existants, sans dépendance technique lourde.

Diag n’Grow – Évaluation et valorisation des actifs immatériels

Diag n’Grow propose une plateforme d’évaluation financière des actifs immatériels des entreprises : logiciels, brevets, marques, données ou savoir-faire.

La solution s’adresse aussi bien aux startups qu’aux PME et ETI confrontées à des enjeux de pilotage financier, de fiscalité, de réorganisation ou de levée de fonds. L’objectif est de fournir une vision claire et documentée de la valeur réelle de ces actifs, souvent sous-estimés dans les états financiers.

Swily – Logiciel métier pour infirmiers libéraux

Swily est un logiciel conçu pour simplifier le quotidien des infirmiers libéraux. La plateforme permet de gérer les tournées, les dossiers patients, la facturation et la télétransmission, depuis une application pensée pour un usage terrain.

Développée avec des professionnels de santé, la solution répond à des contraintes fortes de fiabilité, de sécurité des données et de continuité de service, essentielles dans le secteur médical.

LeCoffre.io – Échange sécurisé de documents pour les notaires

LeCoffre.io est une plateforme d’échange et de collecte de documents sécurisés, conçue par et pour les notaires.

La solution vise à remplacer les échanges de documents sensibles par e-mail, en s’appuyant sur des mécanismes de chiffrement avancés et de traçabilité. Les données sont hébergées en France et respectent des exigences strictes en matière de souveraineté et de conformité réglementaire.

Expert-Flow.ai – Plateforme IA pour experts judiciaires

Expert-Flow.ai développe une plateforme d’intelligence artificielle dédiée aux experts judiciaires, visant à automatiser et structurer l’ensemble du processus d’expertise, de la réquisition à la remise du rapport.

La solution permet de réduire fortement le temps consacré aux tâches administratives grâce à l’extraction automatique des données, à l’assistance à la préparation des entretiens et à la rédaction guidée des rapports. Conçue pour des usages sensibles, la plateforme répond à des exigences élevées en matière de sécurité, de confidentialité et de conformité réglementaire.

Une nouvelle sélection représentative de l’écosystème accompagné

Les startups qui rejoignent aujourd’hui le Programme UP évoluent dans des environnements exigeants, où la technologie est au cœur du produit.

Intelligence artificielle, finance, santé ou legaltech : ces projets sont déjà en production ou en phase d’accélération, avec des enjeux concrets de performance, de sécurité, de conformité et de passage à l’échelle. Autant de problématiques rencontrées par de nombreuses startups au moment où l’infrastructure devient un sujet structurant. C’est dans ce contexte que s’inscrit leur intégration au Programme UP.

Le Programme UP, un cadre d’accompagnement structurant

Le Programme UP a été pensé pour accompagner les startups technologiques au-delà des premières phases de déploiement. Il combine crédits cloud, accompagnement technique, accès aux équipes Clever Cloud, temps d’échange réguliers et mise en visibilité, afin de permettre aux fondateurs et aux équipes produit de se concentrer sur l’essentiel : construire et faire évoluer leur solution.

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

La prochaine sélection du Programme UP aura lieu le 16 mai 2026. Les startups souhaitant candidater peuvent dès maintenant déposer leur dossier et échanger avec les équipes Clever Cloud.

Pour les équipes techniques, la question dépasse la simple localisation des données. Elle concerne aussi l’hébergement des applications, l’automatisation de l’infrastructure, la résilience et la capacité à exploiter une plateforme cloud dans la durée.

Dans ce contexte, de nombreuses organisations recherchent désormais des alternatives françaises aux hyperscalers américains tels qu’AWS, Microsoft Azure ou Google Cloud.

L’écosystème français du cloud s’est fortement structuré ces dernières années. Plusieurs fournisseurs proposent aujourd’hui des infrastructures et plateformes capables de répondre aux besoins et exigences aussi bien d’acteurs privés que publics.

Voici une analyse des 5 principaux acteurs du cloud souverain en France, chacun avec son positionnement technique, ses forces et son modèle d’exploitation.

Cloud souverain France : les points clés à retenir

• Un cloud souverain français vise à garantir une gouvernance française ou européenne et l’absence de soumission aux lois extraterritoriales comme le Cloud Act ou la FISA ;
• Il facilite la conformité au RGPD et la maîtrise juridique des données ;
• Certains fournisseurs proposent une infrastructure (IaaS), d’autres une plateforme automatisée (PaaS) ;
• Tous les acteurs ne proposent pas le même niveau d’automatisation ;
• Clever Cloud adopte une approche PaaS automatisée orientée DevOps, qui réduit la charge opérationnelle des équipes.

Qu’est-ce qu’un cloud souverain français

Un cloud souverain repose généralement sur plusieurs éléments structurants :

• une entreprise soumise au droit européen et qui met en œuvre un cadre de conformité au RGPD DPA, mesures techniques et organisationnelles, traçabilité) ;
• une gouvernance indépendante des juridictions extraterritoriales (Cloud Act, loi FISA, etc.) ;
• des infrastructures opérées par l’acteur lui-même, ou des partenaires eux-mêmes souverains ;
• un contrôle technique sur les données et les opérations.

La souveraineté ne dépend donc pas uniquement de la localisation des data centers. Elle repose aussi sur le cadre juridique, la gouvernance technologique et l’indépendance opérationnelle.

Dans la pratique, les fournisseurs cloud adoptent des approches différentes.

Infrastructure as a Service (IaaS)

Un fournisseur IaaS fournit des ressources brutes :

• machines virtuelles ;
• stockage ; 
• réseau ;
• orchestration.

L’équipe technique doit gérer l’architecture, les déploiements, la haute disponibilité et la supervision.

Platform as a Service (PaaS)

Un fournisseur PaaS automatise une partie importante de l’exploitation selon l’offre :

• déploiement applicatif ;
• gestion des runtimes ;
• scalabilité ;
• supervision ;
• continuité de service.

Cette approche réduit la charge opérationnelle et accélère les cycles de développement.

Les 5 meilleurs clouds souverains français

Les acteurs suivants proposent des infrastructures ou plateformes permettant d’héberger et d’exécuter des applications dans un cadre souverain français.

1. Clever Cloud : PaaS automatisé pour héberger et déployer des applications

Clever Cloud est une plateforme cloud française fondée en 2010 qui permet d’héberger, déployer et exploiter des applications sans avoir à gérer l’infrastructure sous-jacente. La plateforme repose sur une approche Platform as a Service (PaaS), qui automatise une grande partie de l’exploitation technique et simplifie le déploiement des applications.

Clever Cloud est conçu pour simplifier l’exploitation d’applications pour tout type d’organisation, qu’il s’agisse d’équipes techniques indépendantes, d’entreprises ou d’organisations publiques. La plateforme prend en charge la scalabilité automatique, la résilience et la supervision des applications.

Avantages :

• Plateforme PaaS automatisée ;
• Support natif des runtimes : Node.js, PHP, Docker, .NET, Go, Python, etc. ;
• Kubernetes managé (CKE) ;
• Déploiement Git natif et intégrations CI/CD;
• Haute disponibilité gérée par la plateforme ;
• Certification ISO 27001, ISO 9001, HDS (Hébergement des Données de Santé) ;
• Souveraineté avec une infrastructure opérée hors juridictions extraterritoriales ;
• Réduction de la charge d’exploitation pour les équipes.

Limites :

• Moins adapté aux architectures nécessitant un contrôle IaaS complet ;
• Pas de certification SecNumCloud directe (mais une zone SecNumCloud disponible via partenariat avec Cloud Temple).

Pourquoi Clever Cloud diffère des acteurs IaaS ?

Contrairement aux fournisseurs IaaS, Clever Cloud automatise l’exploitation de la plateforme. Les équipes techniques ne gèrent pas :

• les machines virtuelles (VM) ;
• la scalabilité ;
• la résilience ;
• la supervision.

La plateforme applique un principe simple : “Vous codez, on s’occupe du reste.”

2. OVHcloud : infrastructure cloud européenne à grande échelle

OVHcloud est l’un des principaux fournisseurs cloud européens. Fondé en France en 1999, l’entreprise opère aujourd’hui un vaste réseau de datacenters en Europe, en Amérique et en Asie.

L’offre couvre l’ensemble du spectre cloud : infrastructure, cloud public, cloud privé, bare metal et services managés. OVHcloud cible notamment les grandes entreprises et les organisations publiques.

Avantages :

• Large catalogue de services cloud ;
• Offre IaaS, PaaS et bare metal ;
• Certification SecNumCloud sur certaines offres ;
• Kubernetes managé ;
• Gouvernance européenne ;
• Infrastructure opérée par l’entreprise.

Limites :

• Architecture parfois complexe à exploiter ;
• Automatisation dépendante de l’intégration ;
• Courbe d’apprentissage pour les équipes non spécialisées.

3. Scaleway : cloud public français orienté développeurs

Scaleway est une filiale du groupe Iliad (Free) et l’un des principaux fournisseurs cloud français. La plateforme propose une offre cloud public complète, incluant calcul, stockage et services managés. Scaleway est particulièrement populaire auprès des startups et des entreprises technologiques.

Avantages :

• Cloud public français ;
• Kubernetes managé ;
• Stockage compatible S3 ;
• API riche ;
• Tarification transparente.

Limites :

• Processus engagé pour l’obtention de SecNumCloud ;
• Automatisation CI/CD non native ;
• Approche majoritairement IaaS.

4. Cloud Temple : cloud souverain pour environnements réglementés

Cloud Temple est un fournisseur cloud français spécialisé dans les environnements fortement régulés. L’entreprise propose des infrastructures souveraines certifiées et accompagne de nombreuses organisations publiques. La plateforme est souvent utilisée pour des projets nécessitant des exigences de conformité élevées.

Avantages :

• Certification SecNumCloud ;
• Positionnement secteur public ;
• Cloud privé souverain ;
• Forte expertise réglementaire ;
• Accompagnement personnalisé.

Limites :

• Moins orienté développeurs ;
• Offre davantage sur mesure ;
• Offres souvent structurées autour de projets sur mesure et d’environnements réglementés, avec un modèle moins orienté plateforme applicative en libre-service.

5. Outscale (Dassault Systèmes) : cloud souverain certifié SecNumCloud

Outscale est la filiale cloud de Dassault Systèmes. La plateforme propose une infrastructure cloud hautement sécurisée, particulièrement utilisée dans les secteurs régulés. L’offre Outscale est certifiée SecNumCloud par l’ANSSI, ce qui en fait l’un des clouds les plus conformes aux exigences de sécurité françaises.

Avantages :

• Certification SecNumCloud ;
• Haute conformité réglementaire ;
• API compatibles AWS ;
• Infrastructure adaptée aux secteurs régulés ;
• Forte résilience.

Limites :

• Offre principalement IaaS ;
• Moins orienté développeurs ;
• Exploitation nécessitant des compétences cloud avancées.

Le cloud souverain français : un écosystème mature

L’écosystème du cloud souverain en France est aujourd’hui particulièrement riche. Les fournisseurs français couvrent l’ensemble du spectre cloud :

• infrastructures certifiées SecNumCloud ;
• cloud public ;
• plateformes PaaS automatisées.

Cette diversité permet aux organisations de choisir une plateforme adaptée à leurs contraintes : conformité réglementaire, performance, automatisation ou simplicité d’exploitation. Pour les équipes techniques, le choix dépend souvent du niveau d’automatisation souhaité et des compétences internes disponibles.

Dans ce paysage, les plateformes PaaS automatisées occupent une place particulière : elles permettent de réduire la complexité opérationnelle tout en conservant une infrastructure souveraine. Clever Cloud s’inscrit dans cette approche, en combinant automatisation de l’exploitation, souveraineté technologique et standards ouverts.