Le défi

Devoir concevoir et déployer une plateforme Cloud Native complète pour traiter les données d'une flotte de trains légers innovants. Ajoutez à cela trois contraintes majeures : un délai d'un mois, un budget ultra-serré, et un acteur cloud non maîtrisé par l’équipe de Platform Engineering. Mission impossible ? Pas si vous êtes... 🚆 SurDesRails 🚆.

Dans ce talk, nous vous présenterons comment notre équipe a relevé ce défi d'ingénierie en s'appuyant sur l'Intelligence Artificielle, non pas comme un gadget, mais comme un véritable pair-programmeur structuré. La méthodologie créé et éprouvé pour l'occasion redéfinit notre DevEx autour de 5 piliers fondamentaux où l'humain garde toujours le contrôle. 🚆 SurDesRails 🚆 ne consiste pas à demander à un LLM de "générer une plateforme Cloud Native". La méthode organise la collaboration entre l’humain et l’IA autour de cinq étapes :

• 📋 clarifier l’intention jusqu’à obtenir des spécifications détaillées ;
• 📐 assurer la traçabilité des décisions d’architecture ;
• 🏗️ préserver l’adaptabilité en maintenant l’humain aux commandes ;
• ✅ faire approuver un plan avant toute implémentation ;
• 🧪 puis confier à plusieurs agents des objectifs vérifiables en matière de code, de documentation, de CI/CD et de tests.

Le résultat

En 20 jours de développement réalisés par 1 ingénieur, une plateforme conforme aux besoins a été livrée, à l'heure, respectant les contraintes budgétaires, en ayant acquis une connaissance opérationnelle d’un tout nouvel environnement cloud ☁️.

Nous partagerons nos succès (respect des coûts et des délais, amélioration drastique de notre Developer Experience), mais aussi les limites rencontrées (intégration d'un nouveau Clouder, changements d'architectures).

Que vous soyez Platform Engineer, DevOps ou Tech Lead, vous trouverez dans le framework méthodologique concret présenté un moyen d'intégrer efficacement l'IA générative dans vos prochains défis de déploiement Cloud Native.

Le crime était presque parfait. Une image vulnérable, glissée discrètement par une main inattentive, et voilà qu'un Pod suspect s'installe tranquillement dans votre cluster. Croyait-il vraiment passer inaperçu ?

Dans ce talk format "thriller express", nous allons suivre la traque d'une ressource malveillante à travers un véritable tribunal DevSecOps. Pas de théorie ici : nous allons vivre l'audience en direct pour comprendre comment votre cluster se défend contre l'indéfendable.

Découvrez les acteurs de votre cour de justice Cloud-Native :

🔍 L'Inspecteur (Trivy Operator) : Il fouille les entrailles des Pods en runtime pour débusquer les vices cachés. 👨‍⚖️ Le Juge (Kyverno) : Il applique la loi (les policies) sans trembler et refuse l'entrée aux récidivistes. 🚔 La Police de proximité (Falco) : Elle surveille les comportements louches en temps réel. Un shell ouvert ? C'est l'arrestation immédiate. 📋 Le Greffier (Policy Reporter) : Il consigne chaque verdict pour que rien n'échappe à l'audit final.

En 30 minutes chrono, nous allons orchestrer une défense en profondeur pour transformer votre cluster d'une passoire silencieuse en un bastion imprenable.

Vous êtes DevOps et souhaitez muscler votre sécurité ? Ou peut-être SRE à la recherche d'outils de détection runtime légers et efficaces ? Alors ce talk est fait pour vous ! Aucune expertise en criminologie n'est requise : une connaissance de base de Kubernetes et de Docker (niveau intermédiaire) suffira pour suivre l'enquête. Vous repartirez avec une vision claire et les clés pour rendre vos environnements enfin inattaquables. ⚖️🚔

Distributed tracing is a core observability signal in cloud-native systems, but it often comes with a hidden cost: high CPU usage, large memory footprints and complex operational requirements. In Kubernetes environments, this can turn tracing into one of the most expensive parts of an observability stack. This talk explores resource efficiency as a design principle for distributed tracing, and why it matters for the long-term sustainability of cloud-native platforms. Using VictoriaTraces as a concrete open-source example, we will look at how modern tracing systems can be built to ingest and query large volumes of trace data while significantly reducing infrastructure and operational overhead. Rather than focusing on features, the talk highlights architectural choices, OpenTelemetry compatibility and standard APIs that enable tracing to scale responsibly. This session is aimed at engineers who care about efficient operations, sustainable open source tooling and observability at scale.

Pourquoi agentgateway ? L'IA générative s'impose comme accélérateur opérationnel sur de nombreux cas d'usage métier. Pour router ce trafic LLM de manière fiable, maîtrisée et économiquement pilotable, agentgateway se présente comme une solution solide : une gateway open source contribuée à l'Agentic AI Foundation, qui expose une API compatible OpenAI et centralise le routage vers plusieurs providers backend en un point de contrôle unique. Dans cette session, nous détaillons notre implémentation autour de trois fonctionnalités clés.

• Load balancing — Power of Two Choices : Agentgateway implémente l'algorithme Power of Two Choices. Cette approche réduit significativement la variance de latence par rapport à un round-robin classique. Nous montrons l'impact concret sur nos distributions de latence en production, avec plusieurs providers actifs simultanément.

• Failover automatique : Agentgateway détecte l'indisponibilité d'un provider ou le dépassement de ses limites de débit, et bascule automatiquement vers un backend de secours — de manière transparente pour l'applicatif appelant. Nous partageons comment nous avons structuré notre pool de backends entre providers cloud et modèles on-premise, et les stratégies de retry configurées pour absorber les pics sans dégrader l'expérience utilisateur.

• Système de quotas Le système de quotas d'agentgateway nous permet d'allouer des enveloppes de tokens par équipe ou par projet, avec coupure automatique au dépassement. Ce mécanisme nous donne une imputation précise par usage et la capacité d'arbitrer en temps réel les ressources LLM entre consommateurs — un enjeu central dans un service public.

Retours d'expérience Nous partageons les points de difficultés rencontrés lors du déploiement dans notre infrastructure Kubernetes : intégration avec notre registry interne, contraintes réseau liées au proxy corporate, et gestion des secrets providers. Nous abordons également ce qu'agentgateway ne couvre pas encore dans notre contexte et comment nous le complétons.

À qui s'adresse cette conférence ? Aux architectes, platform engineers et tech leads qui pilotent un déploiement IA à l'échelle dans un SI public ou réglementé. Aucun prérequis sur agentgateway ; une familiarité avec Kubernetes est un plus.

We've all felt the pain of waiting for resources, a database, a secret, or a deployment. Tool sprawl makes it worse. Enterprises manage 20+ clusters and 1,000+ nodes. Yet 50% of clusters are snowflakes that resist standardisation, and 9% of organisations are already drowning in three or more CI/CD tools, leaving platform engineers maintaining glue code instead of building reliable platforms.

What if teams could provision infrastructure, deploy services, and enforce configurations across an entire fleet automatically, triggered by real events, without adding a single new tool?

In this talk, we will demonstrate how Sveltos, a Kubernetes add-on controller, makes it possible. The Sveltos Event Framework detects cluster-level events and triggers deployment of services across fleet clusters consistently, scalably, and GitOps-native from day one.

Attendees leave with a practical, reusable pattern for building a self-service reactive platform that scales with demand, without the sprawl.

Vous avez commencé modestement : un Pi-hole, un Nextcloud, peut-être un Jellyfin. Et puis, comme tout home-lab enthusiast, vous avez ajouté couche après couche, Grafana, Portainer, Vaultwarden, Home Assistant, Gitea, Immich, Uptime Kuma... et soudain, vous vous retrouvez face à 40 interfaces web, chacune avec son propre système d'authentification.

Le réflexe "entreprise" serait de déployer Keycloak ou une solution IAM complète. Sauf que Keycloak réclame 512 Mo de RAM minimum, un serveur de base de données dédié, et plusieurs heures de configuration LDAP/SAML avant d'obtenir un login fonctionnel. Pour un homelab tournant sur un vieux NUC ou un Raspberry Pi, c'est rédhibitoire.

Authelia prend le contre-pied : moins de 30 Mo de RAM, un seul binaire Go, une configuration en YAML, et une intégration native avec Nginx, Traefik ou Caddy via un simple middleware. En 30 minutes, vous avez un SSO avec MFA, PassKeys, des policies d'accès par sous-domaine, un portail de login simple, et la possibilité de partager certains services à vos proches sans exposer l'ensemble de votre lab.

Dans ce talk, nous verrons :

• L'architecture d'Authelia et son modèle de délégation d'authentification par forward-auth
• La configuration pas-à-pas avec Traefik
• La gestion des utilisateurs, des groupes et des règles d'accès
• Le MFA (TOTP, WebAuthn, notifications push)
• La comparaison avec Authentik et Keycloak
• Une démo live sur un homelab réel

Que vous soyez débutant en self-hosting ou administrateur système aguerri, vous repartirez avec une solution clé-en-main pour sécuriser votre homelab sans sacrifier vos ressources.

Il n'y a qu'un problème informatique vraiment sérieux : c'est l'AI Native. Juger que le Cloud Native est ou n'est plus nécessaire au profit de l'AI Native, c'est répondre à la question fondamentale de l'informatique de ces dernières années.

Paraphrase passée, dans cette courte présentation nous établirons le lien entre Cloud Native et AI Native au travers d'une question simple : est-il possible de déployer une stack AI exclusivement à l'aide d'outils CNCF ? Du système d'exploitation (ex: Flatcar) à l'inférence (ex: Kaito), en passant par systemd-sysext ou le support GPU, nous aborderons les questions principales à se poser lors de l'idéation pour ne sacrifier ni la sécurité, ni la performance, ni la portabilité.

Aujourd'hui, un secteur pesant plusieurs milliards d'euros repose sur un vivier de contributeurs et de mainteneurs dangereusement restreint et surchargé. L'épuisement des mainteneurs constitue la plus grande menace pour la santé de l'open source, et un risque direct pour la sécurité de la supply-chain logicielle. Regardez les projets comme etcd ou ingress-nginx.

Une solution : attirer et accueillir les talents inexploités qui ont été négligés jusqu'ici. C'est la mission de Merge Forward, une initiative communautaire de la CNCF qui rassemble huit groupes dédiés à la diversité, de Women in Cloud Native à Neurodiversity, en passant par Deaf and Hard of Hearing. Nous construisons des réseaux de mentorat et des espaces communautaires pour les contributeurs issus de milieux sous-représentés, ainsi que pour les alliés qui les soutiennent, afin de combler l'écart entre celles et ceux qui utilisent l'open source et celles et ceux qui le construisent.

L'open source n'est résilient qu'à la hauteur de la communauté qui le soutient. Venez découvrir comment vous pouvez contribuer.

Ton cluster est privé. L'API server n'est joignable de nulle part, ton RBAC est carré, tes ServiceAccounts au cordeau et tout est géré en GitOps. Tu as bien fait le boulot.

Sauf qu'il reste un chemin d'écriture vers ton cluster que ton RBAC ne voit pas : Git.

En 5 minutes, je te montre comment un manifeste banal, le genre qu'on approuve en diagonale, devient une élévation de privilèges vers cluster-admin, sans jamais toucher ni à l'API server ni au RBAC. Puis comment refermer le trou et, surtout, traiter ton dépôt GitOps comme le composant de sécurité qu'il est devenu.

Tu repars avec une seule question en tête : chez toi, qui a le droit de merger ?

Chez Doctolib, nous découpons le monolithe historique. En plus de la difficulté métier à faire cela, nous avons dû repenser sur comment déployer de nouveaux services. Il y a un an : 40 pull requests, 3 semaines pour aller en prod. Aujourd'hui : moins de 3 heures.

Pour cela nous sommes passés d'une infrastructure gérée par des SRE à une plateforme self-service facilement utilisable par les développeurs. Résultat aujourd'hui plus de 90% des PRs infrastructure sont écrites et validées par les équipes elles-mêmes.

Mais le chemin pour y arriver n'a pas été évident. Ce talk revient sur les choix faits et les difficultés rencontrées, avec deux points de vue complémentaires : celui d'un Principal SRE, qui doit garantir la fiabilité, la sécurité et la conformité dans un contexte de santé, et celui d'un PM, qui doit rendre la plateforme compréhensible, adoptable et réellement utile pour les équipes.

Description

• L'outil n'était pas la question. Quel outil choisir ? Terraform ? Helm? Kubernetes ? Cette question n'est pas la plus importante. Le vrai sujet est de trouver le bon niveau d'abstraction pour les développeurs - et ça ne se décide pas dans un design doc. Nous l'avons découvert en travaillant avec les premières équipes et en affinant nos descripteurs de deploiment au fil des use cases.
• Liberté et garde-fous. Comment faire du « You build you run it » sans accès à la production dans un domaine aussi contraignant que la santé? Comment satisfaire les contraintes SRE pour garantir la scalabilité et la stabilité de la plateforme, tout en fournissant une interface simple a utiliser et qui permettent aux équipes de continuer à innover?
• L'avenir ? Un fichier YAML est une interface idéale pour un LLM. Le déploiment n'est plus un sujet. Mais de nombreux sujets restent ouverts. Comment faire évoluer la plateforme pour supporter de nouvelles technologies? Comment permettre aux équipes d'étre toujours plus autonome pour opérer leur services en production?

So you finally got your organization to invest in OpenTelemetry. You carefully evaluated observability backends and picked the perfect one. Everything is awesome. Then twelve months later, your costs have skyrocketed and you can’t explain why. What happened?

This talk examines how to emit meaningful telemetry while keeping costs under control, by exploring the following:

• Why the easy path isn't always the best path
• What to actually instrument
• Which metrics to focus on
• Pipeline efficiency with tools like OTel Arrow
• Applying sampling, filtering, and intentional instrumentation to cut down on noise
• Schema management and validation with tools like Weaver
• Takeaways: what you can do NOW

We’ll review the ingredients of a mature observability implementation with OpenTelemetry: one that grows with you instead of overwhelming you.

You’ll learn how to apply cost-effective techniques to achieve meaningful observability.

Kubernetes est devenu la norme de facto pour déployer et exploiter des applications conteneurisées. Mais sécuriser ses clusters peut être difficile même si l'on sait quel outil on veut utiliser.

Vous avez déjà entendu parler de "Kyverno" mais n'avez pas très bien compris à quoi cela pouvait servir ? Et quel était son lien avec Kubernetes ?

Dans ce talk je vous propose de découvrir Kyverno, de manière visuelle, sous forme de sketchnotes et d'illustrations. Nous découvrirons, de manière concrete, ce qu'est Kyverno, comment il s'interface avec Kubernetes et quels sont ses pouvoirs magiques (rules et policies).

Il y a deux ans, Ingress NGINX était la réponse par défaut à la question « comment exposer des services dans Kubernetes ? » Puis, en novembre 2025, le projet a été officiellement arrêté et chacun a dû faire un choix.

Chez Giant Swarm, nous exploitons des infrastructures Kubernetes pour des dizaines de clients à travers de multiples environnements. Rester sur un contrôleur d'ingress abandonné n'était pas envisageable, mais migrer l'ensemble de notre plateforme vers une nouvelle implémentation de Gateway API exigeait des preuves solides de sa pertinence, et pas seulement le ressenti de la communauté. Nous avons donc mené des tests de charge à grande échélle.

Dans cette présentation, nous verrons comment nous avons construit une pipeline de load testing entièrement automatisée et reproductible à l'aide de Grafana k6, Tekton et de notre propre stack d'observabilité (Alloy + Mimir + Grafana). Je vous partagerai les chiffres réels comparant Envoy Gateway et Ingress NGINX Controller sous trafic soutenu, notamment la latence p99, le débit en RPS, l'utilisation du CPU et de la mémoire ainsi que les taux d'erreur. Spoiler : les résultats n'ont pas toujours été ceux que nous attendions.

Vous repartirez avec une vision claire des performances d'Envoy Gateway à grande échelle, un modèle pour construire votre propre dispositif de benchmark de gateway, et un aperçu honnête des compromis que nous avons du faire en migrant une plateforme de production vers Gateway API

You ask a coding agent to build something, grab a coffee, and come back to find it stopped three steps in, asking whether it should continue. Welcome to babysitting your agent.

Last year I got tired of the babysitting and tried the dumbest fix I could think of: a while loop. The Ralph Loop. I gave it a small SaaS to build and left it alone. And it worked, from the application logic to the underlying infrastructure.

Ralph turned out to be the first draft of a much bigger idea. The pattern has since caught on, and it's now known as loop engineering. So what is this all about, and can you trust a loop enough to let go of the babysitting? That's the question this talk takes apart, and the answer will surprise you.

I won't pretend it's all upside. A loop that works without you can go wrong without you, and code that ships faster than you understand it is a new kind of debt. How much autonomy is actually useful? Come find out where I finally let go, and where I never will.

In this practical session, we’ll explore the fundamentals of prompt engineering and how to communicate effectively with AI systems. We’ll cover how LLMs interpret instructions, the role of context, examples, constraints, and structured outputs, and how to iteratively improve prompts to achieve more reliable results. Through hands-on examples, we’ll transform vague requests into clear, actionable prompts and explore techniques that can be applied to everyday engineering tasks: debugging, documentation, automation, and cloud-native workflows.

[Notez que je peux le faire en Francais si c'est préférable]

At Giant Swarm we use Cluster API to provision and bootstrap our k8s clusters. With this setup, control plane (CP) and worker nodes must run on the same infrastructure which was never an issue so far...

However, in bare-metal environments, using 128-core servers for CP nodes is luxury. It's far more efficient to host them as virtual machines on a hypervisor while keeping workers on physical hardware. But can we get around CAPI's limitations?

We will walk through how we built Frankenstein's cluster by mixing vSphere for the CP and Proxmox for workers as a testing ground. While technically functional, this required "hacky engineering". We will share the hurdles we hit and the operational risks of this hybrid cluster setup.

Finally, we will demonstrate how we solved this challenge with a cleaner, upstream-friendly alternative. Kamaji lets us run the CP as pods in a management cluster. We achieved even better resource optimisation with full native community support and no custom hacks.

Contexte

Gateway API est souvent présentée comme le successeur naturel des Ingress. Sur le papier, la migration semble simple : remplacer des objets Ingress par des HTTPRoute et déployer un contrôleur compatible. En production, la réalité est plus nuancée. Dans cette session, je partagerai le retour d’expérience de la migration d’Ingress NGINX et ModSecurity vers Envoy Gateway, Gateway API et Coraza WAF. Cette évolution ne s’est pas limitée au remplacement du point d’entrée de nos clusters : elle a aussi impliqué une adaptation de l’écosystème autour de la plateforme.

Migration vers Gateway API

Si Gateway API était prête, l’ensemble de l’écosystème ne l’était pas toujours. Nous verrons les points de friction rencontrés au cours de la migration : compatibilité des versions des CRD, support des ListenerSets, intégration avec cert-manager pour la gestion des certificats, prise en charge par ExternalDNS, ainsi que la maturité variable des fonctionnalités selon les contrôleurs Gateway.

Cette partie mettra en lumière les choix d’architecture réalisés pour avancer malgré ces contraintes, ainsi que les compromis nécessaires pour mener une migration progressive sans interruption de service.

Sécurité WAF

À cette migration de la couche d’exposition s’est ajoutée une évolution de la couche de sécurité, avec le remplacement de ModSecurity par Coraza. Nous verrons les différences entre ces deux approches, les adaptations nécessaires des règles WAF et les points d’attention pour conserver un niveau de protection équivalent tout au long de la transition. Cette dimension sécurité a été un sujet central de la migration, car elle a demandé de concilier continuité de protection, compatibilité applicative et modernisation de la plateforme.

Retours d’expérience

Au-delà des aspects techniques, cette présentation partagera les enseignements tirés de cette migration menée en production : ce qui a bien fonctionné, ce qui a été plus complexe que prévu, et les erreurs à éviter si vous envisagez une démarche similaire.

Vous repartirez avec une vision concrète de l’état actuel de l’écosystème Gateway API, une meilleure compréhension des interactions entre Gateway, Envoy et Coraza, ainsi que des recommandations pratiques pour moderniser votre propre plateforme sans découvrir ces obstacles au dernier moment.

Many organizations still treat observability as a tooling decision: select a vendor, deploy agents, and expect insight to follow. Yet teams continue to struggle with fragmented signals, rising complexity, and slow incident response. The real issue is rarely the tool itself - it’s the absence of a shared foundation and a coherent product experience.

This talk reframes observability as an internal platform product, designed with clear users, sane defaults, and long-term evolution in mind. Drawing parallels to Kubernetes and platform engineering, we’ll explore why powerful primitives are not enough - and why standardization, correlation, and paved paths matter more than features.

We’ll look at how OpenTelemetry provides a vendor-neutral foundation for structured telemetry, decoupling instrumentation from backends and enabling correlation by default. This structured approach not only reduces cognitive load and improves reliability, it also lays the groundwork for AI-assisted debugging and natural language interaction with production systems.

Observability isn’t just about collecting more data. It’s about designing a platform that makes understanding systems easier - for both humans and machines.

Derrière chaque cluster Kubernetes se cache le même composant critique : ETCD. Tout y passe : la configuration, l'état des pods, les secrets, et la moindre seconde d'indisponibilité fait vaciller le control-plane. Pourtant, quand on opère du Kubernetes managé à grande échelle, ce data-store peut rapidement devenir un goulot d'étranglement.

Après des années à opérer ETCD chez différents cloud providers, nous nous sommes rendus à l'évidence : on ne peut pas se contenter d'empiler des clusters standalones. Plutôt que de continuer à contourner ses limites, nous avons choisi chez Clever Cloud de le réécrire. Plus précisément, construire une couche stateless compatible avec son protocole, en s'appuyant sur FoundationDB pour le stockage, le Key-Value distribué transactionnel utilisé par Apple pour iCloud et OpenAI.

Lors de ce deep-dive, nous partagerons notre retour d'expérience : pourquoi ETCD nous a poussés à le réécrire, ce qu'on découvre quand on plonge dans ses internals (watchers, révisions, ce qui se passe à chaque kubectl apply), et comment cette réécriture en couche stateless au-dessus de FoundationDB change la donne pour servir du Kubernetes à grande échelle.