La Kubecon EU 2025 en bref

Adrien Paysant , Yoan SIMIAND-COSSIN , Hugo Joubert , Sébastien Rouaix , Arthur Planche 08 avr. 2025

Un an après sa participation à la KubeCon EU 2024 (qui a eu lieu dans notre belle capitale), Ippon est de nouveau présent lors de cette édition 2025, cette fois-ci à Londres.

Cet article a pour but de présenter les grandes tendances se dégageant de l’événement.

Elephant in the room! Les thèmes principaux sont le platform engineering, l’IA et l’observabilité. Nous allons résumer rapidement les nouveautés et dynamiques sortant du lot lors des interventions de tous les speakers que nous avons recueillis pour vous !

La plateformisation a le vent en poupe

La plateformisation s’impose aujourd’hui comme une réponse structurante aux défis opérationnels des organisations cloud-native. Portée par l’essor de Kubernetes et de l’infrastructure as code, elle vise à abstraire la complexité technique des couches basses afin de proposer aux développeurs des plateformes internes (Internal Developer Platforms - IDP) cohérentes, standardisées et en self-service.

Au cœur de cette démarche, le projet Backstage, incubé par la CNCF, émerge comme un socle transversal incontournable. Pensé comme un portail développeur extensible, Backstage joue un rôle fédérateur : il centralise la découverte, la documentation, le provisioning et l’opération des services dans une interface unifiée, tout en servant de façade UX aux autres composants de la plateforme.

Lors de la KubeCon EU 2025, deux projets ont particulièrement illustré la montée en maturité de ces approches : NAIS en Norvège et Crossplane dans l’écosystème CNCF. Tous deux démontrent la puissance combinée d’un back-office robuste, d’une plateforme de développement correspondant à leurs besoins, et d’un front office fédérateur.

NAIS : la souveraineté logicielle par la plateforme

En Norvège, la transition vers le numérique de l’État ne se contente pas de principes : elle s’appuie sur une implémentation technique concrète et mature, NAIS (NAV Application Infrastructure Services). Développée et opérée par la NAV (équivalent de la CAF française), cette plateforme open source permet à près de 200 équipes internes de livrer en continu, de manière sécurisée, scalable et autonome, des services critiques pour l’État-providence norvégien.

NAIS repose sur Kubernetes, avec une forte contrainte sur la façon de packager, déployer et monitorer les applications. Elle fournit une expérience "PaaS-like", intégrant :

Un système de déploiement continu basé sur Git, piloté via des manifests YAML standardisés.
Des abstractions de services managés : base de données, Kafka, vaults de secrets, métriques Prometheus, etc.
Des politiques de sécurité fortes par défaut (TLS, mTLS, OIDC, audit logging).
Une observabilité native via la stack Grafana / Prometheus / Loki / GCP Logs.

Mais NAIS ne se limite pas à la technique : elle incarne une vision stratégique de plateformisation souveraine, alignée avec les objectifs d’indépendance numérique et d’efficacité publique. La plateforme technique s'accompagne d'une documentation complète, ainsi que d'un support technique réactif. Pour aider la communauté et la fédérer, un espace de travail Slack a été mis en place où les membres peuvent discuter et collaborer librement avec des personnes et des organisations partageant les mêmes idées. Ils peuvent y poser des questions sur un service ou une API d'une autre agence gouvernementale. Ce projet montre que les principes de plateforme interne ne sont pas réservés aux géants du cloud, mais peuvent être déclinés dans un cadre public, maîtrisé, et pérenne.

La dimension produit est au cœur du succès de NAIS : ses équipes outillent les développeurs sans imposer, guident sans verrouiller, et tendent vers une expérience aussi fluide qu’un PaaS commercial. À ce titre, NAIS s’intègre naturellement avec leur plateforme de développement construite en interne, utilisée comme interface unique de consommation de la plateforme. Ce tandem NAIS + plateforme de développement illustre parfaitement la volonté de plateformer les services internes : rendre accessibles, visibles et utilisables les outils d'infrastructure et de déploiement, sans exposer leur complexité.

Crossplane : l’orchestrateur des infrastructures multi cloud

Si Kubernetes a résolu le problème de la portabilité des workloads, celui de la portabilité des infrastructures restait présent. C’est précisément la mission de Crossplane, projet CNCF, qui transforme Kubernetes en orchestrateur d’infrastructure, en exposant une API déclarative, GitOps-friendly, pour provisionner et gérer des ressources cloud via des CRDs (databases, buckets, réseaux...) de manière provider-agnostique.

Contrairement à Terraform, Crossplane s’ancre pleinement dans l’écosystème Kubernetes, via des CRDs (Custom Resource Definitions) et une approche nativement déclarative et composable. Les équipes plateforme peuvent encapsuler des architectures complètes dans des compositions, exposées via des interfaces simplifiées comme CompositeDatabase ou CompositeCluster, utilisables par les développeurs dans un modèle self-service.

Crossplane repose sur plusieurs piliers techniques :

Providers (AWS, GCP, Azure, Helm, etc.)
Compositions pour abstraire des assemblages complexes
Claims pour le binding entre les utilisateurs et les ressources

Mais la véritable force de Crossplane se révèle lorsqu’il est couplé à Backstage. Le provisioning de services devient alors un flux continu et ergonomique, où les développeurs interagissent avec des formulaires simples ou des templates dans le portail Backstage, pendant que Crossplane orchestre les ressources sous-jacentes. Cette architecture modulaire, intégrée, et standardisée fait émerger une nouvelle génération de plateformes produits internalisées.

Une convergence des outils, une vision commune

NAIS et Backstage/Crossplane incarnent deux visages complémentaires de la plateformisation moderne :

NAIS, en tant que plateforme souveraine, packagée, opérée et éprouvée
Backstage/Crossplane, en tant que moteur d’orchestration multi cloud, extensible et composable

Backstage, quant à lui, joue le rôle du catalyseur transversal, qui relie des briques techniques à l’expérience développeur. Il fédère, documente, expose, automatise.

Dans un monde où les infrastructures sont distribuées, les applications complexes, et les développeurs saturés, offrir une plateforme robuste, intuitive et sécurisée n’est plus un luxe — c’est un impératif stratégique.

Les expériences de mise en place de plateformes internes

De nombreux retours d'expérience nous ont montré que les entreprises manquent encore de maturité dans la mise en place d’une plateforme interne commune pour accompagner les équipes produits.

Decathlon et Lego, par exemple, n’ont pas la même approche ni les mêmes succès.

Decathlon peine à conjuguer évolutions techniques, changements disruptifs et retours des utilisateurs.

En revanche, Lego a profité du changement de son centre de données pour favoriser l'adoption de Kubernetes au sein des équipes produits, en communiquant efficacement et en échangeant beaucoup avec les utilisateurs.

La conférence ”Starting and Scaling a Platform Engineering Team” liste d’ailleurs les défis que toute entreprise devra relever pour mettre en place une équipe plateforme :

Gérer la complexité
Créer l’effet de levier
Améliorer la productivité

Ils décrivent les étapes à accomplir :

Identifier les défis partagés (importance du dialogue avec les utilisateurs)
Concevoir une plateforme de zéro (NAIS ?) ou adopter des solutions existantes (Backstage ?)
Recueillir les retours, affiner, favoriser l’adoption
Maintenir et exploiter : assurer le support

Ce dernier point est un véritable défi. Proposer une plateforme commune est une chose, mais répondre aux problèmes techniques imprévus qui peuvent survenir sur la plateforme produit en est une autre. La présence d’une équipe SRE est indispensable, mais les plateformes deviennent de plus en plus complexes et les besoins de réactivité sur des systèmes critiques augmentent.

C’est là qu'un outil comme K8sGPT peut se rendre indispensable sur les plateformes Kubernetes.

K8sGPT utilise un LLM pour identifier les erreurs sur un cluster Kubernetes. L’outil n’est pas nouveau, mais ce qui nous intéresse ici, c’est l'opérateur K8sGPT qui a été présenté lors d’une conférence. Il permet de faire de l'auto-remédiation. Via des analyseurs, il surveille les pods, les services, les ingress, les nœuds et d’autres composants de votre cluster et il corrige automatiquement les erreurs. Ce qui est intéressant ici, c’est la possibilité d’enrichir le LLM avec une base de connaissances des problèmes déjà identifiés au sein de l'entreprise pour remédier aux erreurs déjà rencontrées auparavant.

Les changements sont historisés et les modifications appliquées sont vérifiées puis restaurées si elles ne correspondent pas aux attentes. De belles promesses, hâte de tester !

Promouvoir la standardisation de l’observabilité

Un axe clé abordé durant cette KubeCon est la standardisation de l'observabilité, en particulier grâce à OpenTelemetry. Kasper Borg Nissen de Dash0 a mis en avant les avantages de l’adoption d'OpenTelemetry en particulier dans le contexte de platform engineering. Ce standard permet d'uniformiser l'intégration des métriques, logs et traces dans des environnements de développement complexes. OpenTelemetry propose une API cohérente, des “paved paths” pour l’intégration et une modularité facilitant l’ajout de nouvelles fonctionnalités sans perturber l’infrastructure existante. Ce cadre d’observabilité s'intègre parfaitement avec des principes comme l'auto-service et la modularité, offrant ainsi aux équipes de développement une solution flexible et extensible.

En ce qui concerne la CI/CD, des avancées significatives ont été réalisées pour standardiser les métriques et les logs liés aux pipelines de déploiement. Dotan Horovits et Adriel Perkins ont présenté les nouvelles conventions sémantiques, “semcon”, d’OpenTelemetry pour le suivi des pipelines, des déploiements et des systèmes de contrôle de versions (comme GitHub et GitLab). Ces conventions, désormais appliquées à leur propre infrastructure CI/CD, apportent un cadre structuré pour les métriques et les attributs, facilitant ainsi leur utilisation et leur analyse. Les prochaines étapes sont de rajouter des variables d'environnement dans les métriques, permettant ainsi une meilleure contextualisation et une analyse plus approfondie des déploiements. Ainsi que de travailler les conventions de nommage liées aux artifacts. Tous ces travaux sont observables sur leurs dépôts GitHub, notamment celui pour les conventions de nommage: semantic-conventions.

Toujours dans un souci d’amélioration de l’observabilité, notamment de l’ensemble des clusters Kubernetes que l’on peut se retrouver à gérer, nous avons eu le droit à la présentation d’un projet CNCF: Headlamp. C’est un projet qui à été accepté dans l'environnement sandbox de la CNCF en 2023 et qui a pour but d’essayer d’unifier au maximum les différentes composantes de Kubernetes. L’outil essaie de résoudre une problématique qui est de rendre l’apprentissage de Kubernetes le plus accessible et le plus fluide possible, et ainsi d’en faciliter l’adoption pour des personnes voulant apprendre ou le déployer en production. Pour cela, il se focalise sur trois grands axes :

Une entrée unique via un portail web
Une interface unique pour manager tous ses clusters kubernetes
Que tout cela soit “plug and run”

Des LLMs à gogo

L’IA avec kubernetes

Un autre sujet était sur les lèvres de tous les orateurs : l’IA dans des clusters Kubernetes. Des problématiques de gestion des charges de travail ont été évoquées durant la keynote d’ouverture. Rob Koch de Slalom Build, nous a présenté une solution sur laquelle lui et son équipe travaille : un modèle qui permet d'interpréter la langue des signes (American Sign Language) motorisé par un modèle de Machine Learning. Cette solution doit prendre en compte beaucoup de données de contexte pour effectuer ce travail d’interprétation, avec le bruit ambiant qui peut survenir durant la captation d’un dialogue en langue des signes. Les charges de travail sont très lourdes et très difficiles à mettre en œuvre de manière native dans Kubernetes. Rob Koch et son équipe ont porté leurs dévolus sur un écosystème d’outils et de framework : Kubeflow. Ce dernier leur permet d’améliorer grandement leur productivité et la collaboration entre les équipes du projet.

Une deuxième solution de gestion des charges de travail d’inférence d’IA générative nous à été présentée par deux membres de Solo.io, Idit Levine fondatrice de l’entreprise et Keith Babo CPO.

Le premier outil était kgateway (anciennement Gloo), qui implémente un ingress-controller (basé sur Envoy proxy) ainsi qu’une API-Gateway (basé sur Kubernetes Gateway API). L’outil de gateway fournit des fonctionnalités permettant de sécuriser les données qui transitent, de gérer le trafic des workloads d’inférence plus efficacement, de permettre la haute disponibilité des LLMs déployés sur le cluster et enfin de pouvoir gérer le nouveau protocole à la mode : le MCP (Model Context Protocol). Le code projet à été ouvert et donné à la CNCF.

Le deuxième outil présenté est un agent autonome pour Kubernetes simplement nommé : kagent. C’est un framework qui permet de construire et déployer des agents IA pour gérer et maintenir les clusters K8s sous la supervision d’un administrateur via une interface en CLI ou sur navigateur. Le projet est récent et vient d’être proposé à donation à la CNCF.

L’interprétation des données d’observabilité avec des LLMs

Le dernier sujet majeur de cette 9ème édition de la KubeCon Europe était un mélange des deux sujets présentés dans les deux premières sections.

Un des intervenants, Vijay Samuel d'eBay, a abordé l'intégration de l'IA dans l'observabilité des systèmes. Il a expliqué que l'IA peut être un atout majeur pour analyser les logs, traces et métriques, en permettant des résumés automatiques, en réduisant ainsi le temps nécessaire à l’interprétation des données afin de passer plus rapidement à la résolution d’incidents.

Cependant, il a insisté sur le fait que l'IA doit être utilisée avec discernement, en se concentrant sur des tâches où elle excelle, comme la synthèse d’informations ou la génération de code, tout en laissant le reste aux approches traditionnelles de programmation.

Une attention a été aussi portée sur la fenêtre de contexte que le modèle prend en entrée, car plus le LLM prend de données en entrée plus il est sujet à des hallucinations. Vijay Samuel a exposé comment eBay avait mis en place de l’IA dans leur observabilité, en itérant par petit bloc, chacun s’occupant d’un axe d’observabilité spécifique: trace, log, metric et change explainer.

Conclusion

La KubeCon EU 2025 a posé les cartes sur table. L’avenir du cloud-native se dessine clairement autour de trois axes majeurs : platform engineering, IA et observabilité.

La plateformisation n’est plus un luxe, c’est une évidence. Des outils comme Backstage, NAIS ou encore Crossplane deviennent les fondations nécessaires pour dompter la complexité croissante de nos stacks et offrir aux devs des environnements carrés, standardisés, autosuffisants. On parle ici d’industrialisation intelligente, pas de rigidité imposée.

Les talks les plus marquants, notamment ceux de Decathlon et Lego, rappellent une chose simple mais souvent oubliée : une plateforme, aussi bien pensée soit-elle, ne vaut rien sans une vraie posture produit et une communication claire avec ses utilisateurs. Une plateforme sans vision UX, c’est juste un autre silo.

Côté SRE et ops, des outils comme K8sGPT pointent le bout de leur nez pour injecter un peu d’intelligence dans la boucle de remédiation. Moins de bruit, plus de signal. Et surtout, des pistes concrètes pour automatiser ce qui peut (et doit) l’être.

Quant à l’observabilité, on y est : OpenTelemetry s’impose comme la brique standard. On ne parle plus juste de collecter de la donnée, mais de l’exploiter intelligemment, de comprendre nos systèmes de l’intérieur. L’IA vient d’ailleurs se greffer là-dessus, que ce soit pour Kubernetes ou pour l’analyse des signaux. On entre dans une ère d’assistance proactive, de pilotage éclairé.

Bref, cette KubeCon 2025 a été un concentré d’énergie, de retours lucides et d’innovations qui ne jouent pas à l’esbroufe. On sent que la communauté est en train de passer un cap. Les défis sont costauds, mais les outils sont là, les idées aussi. Ce qui se dessine, c’est un cloud-native plus mature, plus outillé, plus humain aussi. Et pour les boîtes qui veulent rester dans la course, il va falloir embrasser ces mutations, sans tarder.