Logo officiel du Breizhcamp — La conférence à l'Ouest

Retours sur le Breizhcamp 2026

Depuis plusieurs années, le Breizhcamp est une conférence incontournable pour la communauté technologique rennaise. Cette année, j’ai pu y présenter un talk qui me tient à cœur à savoir « Comment je fais ma veille technologique » issu de mon article de blog. Bien que je n’aie pas pu assister aux trois jours complets de l’évènement, j’ai eu le plaisir de participer à plusieurs conférences le mercredi après-midi et pendant toute la journée du vendredi.

Cette année, le programme était riche et varié. Malgré les conditions climatiques exceptionnelles, l’équipe d’organisation et les bénévoles ont été au top pour rendre la conférence agréable pour toutes et tous. En réalité, il n’était pas facile d’assister aux différentes conférences dans des amphithéâtres surchauffés, mais heureusement, des fontaines d’eau rafraîchissante et des coins ombragés étaient disponibles pour nous permettre de nous reposer. Je pense surtout aux personnes qui animaient les stands. La température dans le couloir principal atteignait presque 37 degrés le mercredi.

Dans cet article, j’aimerais partager avec vous les quelques conférences auxquelles j’ai assisté. Le programme étant plutôt riche en variétés sur les thèmes comme sur les formats, je me suis consacré à des thèmes qui me sont chers, mais aussi qui m’ouvrent sur d’autres horizons.

Karpenter & Keda : Le duo gagnant du FinOps

Le premier talk que j’ai choisi concerne la réduction de coût d’un cluster Kubernetes managé. Guillaume Membré et Sébastien Fourreau nous ont présenté deux outils dans l’écosystème Kubernetes qui peuvent aider à ajuster l’utilisation de son cluster Kubernetes à savoir Keda et Karpenter.

Sébastien travaille pour la société RCA qui est éditrice d’applications pour des cabinets comptables. Ces applications sont déployées sur un cluster EKS sur AWS. La charge du cluster fluctue en fonction de la journée et il est difficile de pouvoir ajuster le nombre de pods nécessaires pour répondre aux besoins des utilisateurs.

La première intuition est de prévoir plus de pods que nécessaire ce qui nécessite un gros nombre de nœuds. Le problème est que cela augmente naturellement la facture.

Pour optimiser les coûts de la plateforme, il est nécessaire d’ajuster les ressources en fonction de la demande. Comment le faire automatiquement comme on le ferait avec des VMs sur AWS grâce aux autoscaling groups ?

Dans cette optique, Sébastien nous a présenté l’outil Keda qui permet d’ajuster le nombre de pods automatiquement en fonction de l’heure ou en fonction de métriques spécifiques. Ainsi, le nombre de pods fluctue en fonction de la journée ou en fonction du jour de la semaine (pourquoi faire tourner, par exemple, une application le dimanche ?). Keda s’appuie sur des CRDs spécifiques pour établir les règles d’autoscaling des pods et sur les HPA (Horizontal Pod Autoscaler) natifs à Kubernetes. Un avantage clé de KEDA est le scale-to-zero : les pods peuvent être complètement arrêtés en dehors des heures d’activité, ce qu’un HPA classique ne permet pas.

Une fois que les nœuds sont moins chargés, il est nécessaire d’ajuster leur nombre. Pourquoi payer plus cher pour un ensemble de nœuds qui en nécessiterait-il moins pour héberger les applications ?

Guillaume nous présente ensuite un autre outil qu’il a mis en place, à savoir Karpenter. Initialement, c’était un projet développé par AWS. Depuis, il a été donné à la fondation CNCF pour pouvoir être compatible avec d’autres fournisseurs de cloud. Karpenter est utilisé pour optimiser le nombre de nœuds en fonction de la charge grâce à la consolidation et au choix dynamique du type d’instance (bin-packing), ce qui le rend plus efficace que les node pools par exemple.

Le combo Keda et Karpenter leur a permis en un an de réduire de près de 50 % leur facture du cluster ! Il leur reste des optimisations encore à faire, mais c’est tout de même impressionnant.

Ce talk était intéressant et m’a donné des idées pour mes projets en cours, surtout pour la partie Keda, car mon cluster est hébergé on premise.

REX — Construire un poste d’administration conforme SecNumCloud

J’ai été voir ce talk donné par d’anciens collègues, à savoir Chris Navas (de WeScale) et David Gandra (de Numspot).

Chris et David travaillent dans le service IT de Numspot et entre autres, sur l’administration des postes de travail et surtout des postes d’administration pour opérer l’infrastructure du cloud provider.

Numspot, pour ceux qui ne connaissent pas, est un cloud provider français de services PaaS qui vise la certification SecNumCloud. SecNumCloud est la plus haute certification au point de vue sécurité proposée par l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information).

Chris et David nous expliquent ce que cela veut dire passer cette certification. Il faut répondre à des exigences pour garantir la sécurité des données de leurs clients. Et ce n’est pas forcément le plus simple. Ils donnent d’ailleurs une bonne astuce pour s’y retrouver dans toute cette documentation, à savoir les ingérer dans une base RAG. Ainsi, ce sera plus facile de comprendre ce qu’il faut mettre en place pour répondre à une exigence.

Et le poste d’administration d’une plateforme SecNumCloud doit être fortement sécurisé. Pour faciliter leur vie, ils ont décidé de le rendre Airgap et immuable. C’est un choix technique qui garantira que l’administrateur ne modifiera pas l’intégrité du système.

La chaîne de CI/CD permet de construire et déployer une image en 30 minutes sur les postes d’administration.

Ce fut très intéressant pour apercevoir les coulisses d’un cloud provider français. Et cela faisait plaisir de les revoir.

Réduire l’empreinte carbone du code legacy avec l’IA

Ce talk peut sembler contre-intuitif : comment l’intelligence artificielle (IA) peut-elle aider à réduire notre empreinte carbone ?

Olivier Bierlaire nous explique dans un premier temps comment calculer l’empreinte carbone de son application à l’aide d’outils que je connaissais déjà comme CodeCarbon, Kepler et ElectricityMap.

Mais comment calculer le coût de CO2 d’une requête à un LLM ? Olivier nous présente un outil disponible sur Hugging Face, intitulé EcoLogits. C’est une estimation, car les données sur la consommation et surtout la localisation de leur infrastructure ne sont pas connues, mais cela donne une base.

Dans une première démo, il nous démontre qu’un refactoring d’une application en Python vers du Rust peut être efficace pour réduire son empreinte carbone, surtout si ce microservice, par exemple, est fortement sollicité. C’est une première piste d’optimisation.

Dans une seconde démo, il propose de faire des optimisations sur une application legacy. Il effectue d’abord un profiling pour ensuite demander à un LLM des pistes d’optimisation. Il faut alors comprendre quel gain avons-nous obtenu en optimisant l’application par rapport au coût en CO2 de l’assistant IA.

Un talk intéressant à tout point de vue, même si c’est assez difficile d’évaluer son empreinte carbone, car, comme le rappelle Olivier, l’empreinte carbone doit être prise de bout en bout de l’extraction du minerai jusqu’au recyclage du serveur sur lequel a tourné notre application.

Rejouer une partie, rejouer le système de la matrice : des replays de jeux vidéo à l’event sourcing

J’étais ravi de voir que ce talk était donné par un copain de mon club d’escrime.

Pierre Fervel propose de faire le parallèle entre le replay que l’on peut voir dans les jeux vidéos et l’event sourcing que l’on peut implémenter dans son backend. Pierre est développeur fullstack et est passionné de jeux vidéos depuis longtemps. Il en a d’ailleurs fait beaucoup de prototypes pour comprendre les mécanismes à implémenter.

Dans une première partie, il nous présente les différentes techniques nécessaires pour implémenter un replay dans un jeu comme Counter Strike ou Fortnite. Ce n’est pas judicieux d’enregistrer la vidéo, ce qui nécessiterait énormément de ressources, mais au contraire enregistrer les évènements du jeu comme les déplacements du joueur à un instant T symbolisé par le Tick de la boucle de jeu (le joueur a appuyé sur la touche left, puis a tiré etc…). Pour faire le replay, il suffit alors de remonter dans le temps en rejouant les évènements les uns après les autres.

Et quel est le parallèle avec l’Évent sourcing ? C’est assez similaire, au lieu de stocker un état dans une base de données, nous allons stocker les différents évènements qui sont arrivés pour constituer un journal d’évènement.

Un talk rafraîchissant et didactique. Le parallèle entre les deux concepts est plutôt évident pourtant totalement différent sur le papier.

Gateway API, 10 ans de maturation pour une nouvelle API Kubernetes

Avec la dépréciation de Nginx Ingress Controller, il est nécessaire de se pencher sur la spécification Gateway API qui est plutôt mature maintenant (la spécification est sortie en 1.5 depuis peu).

Kevin Davin nous explique pourquoi il est nécessaire maintenant de passer à Gateway API pour migrer ses workload depuis les Ingress.

En effet, les ingress sont disponibles depuis les premières versions de Kubernetes. Une des premières limites est que cela ne concerne essentiellement que les requêtes HTTP/HTTPS. Comment faire simplement pour déclarer une entrée pour des Websockets ou du GRPC ?

L’introduction de Gateway API, il y a près de 6-7 ans, tente de combler les limites des ingress. Une des premières forces de ce nouvel objet est qu’il n’est pas inclus dans Kubernetes par défaut. Cela veut dire que nous ne risquons pas de casser l’existant lors d’une mise à jour d’un cluster Kubernetes. Ensuite, la spécification ne propose pas d’implémentation de référence. Par contre, les projets qui désirent implémenter la spécification doivent démontrer qu’ils l’ont mise en œuvre, en tout ou en partie, grâce à des tests d’intégration.

Gateway API s’adresse à différents personas. Tout d’abord à l’ingénieur réseau/infrastructure qui va définir comment faire le routage à l’aide de classe de Gateway. Ensuite, d’autres objets doivent être gérés par ceux qui administrent le cluster et enfin les développeurs qui décrivent comment leur application peut être exposée via différentes routes.

Kevin nous présente aussi différents modèles d’architecture possible pour déclarer sa gateway API, de l’approche monolithique à l’approche distribuée.

J’ai vraiment apprécié ce talk car il est très didactique et pragmatique. Un bon talk de Kevin à revoir en replay.

Passkeys : Adieu les mots de passe, bonjour la sécurité sans friction !

Les passkeys comblent les failles de sécurité que sont les mots de passe. Il y avait déjà eu un talk sur ce sujet le mercredi matin (mais je n’ai pas pu y assister), mais plutôt sur la partie entre le browser et le stockage de la clé de chiffrement sur le device à l’aide du protocole FIDO2.

Ici, Sébastien Buchoux nous démontre la partie protocolaire entre le browser et le relying party à savoir le serveur qui sera en charge d’authentifier l’utilisateur à l’aide de sa clé de chiffrement.

En effet, le protocole WebAuthn est basé sur le chiffrement asymétrique à savoir une clé privée stockée dans un authenticator de l’utilisateur (TPM, clé de sécurité matérielle, gestionnaire de mots de passe) et une clé publique qui servira à authentifier l’utilisateur. Lors de la demande d’accès à un site web, le relying party initiera un ping pong avec le browser pour récupérer le chiffrement d’un challenge afin de vérifier que l’utilisateur possède la bonne clé.

Cette conférence était intéressante à tout point de vue et très pédagogique. Sébastien a parfaitement démystifié ce protocole qui semble obscur quand on ne connaît pas la cryptographie. Seul bémol, il s’est trop attardé à décrire l’implémentation pas à pas du protocole, surtout côté serveur.

Tuner uv pour travailler avec Docker

Un petit quickie pour se réveiller après le buffet. Ce talk de 15 minutes nous explique comment optimiser son image Docker d’un programme Python à l’aide de uv.

Florent Vuillemin présente brièvement les diverses options d’amélioration de son image grâce aux diverses instructions offertes par UV. Il est ainsi passé d’une image de près de 500 Mo à une image de 55 Mo.

Cela me donne des astuces pratiques pour l’optimisation de certains composants développés en Python pour notre démonstrateur de dataspace à Teralab.

Astro GitOps — Press ⓧ to start

C’était le deuxième talk de Kevin Davin dans la journée. Il a dû être bien crevé à la fin de la journée, surtout que les amphis étaient encore à 31° dans l’après-midi.

Kevin nous explique l’approche Gitops qui est décrite dans le projet OpenGitops.

Contrairement à ce que nous pourrions penser, mettre des scripts dans Git n’est pas conforme à l’approche GitOps.

Kevin nous présente les différents concepts nécessaires pour faciliter cette approche. Ainsi, il faut que nous décrivions de manière déclarative l’état souhaité de l’infrastructure ou de l’application.

L’état doit être versionné dans GIT et immuable. Cela facilitera la relecture et la connaissance de ce qui a été appliqué entre deux versions lors d’une investigation après un problème. D’ailleurs, Kevin nous explique pourquoi les charts Helm ne répondent pas à cette problématique. D’une part, parce qu’ils ne sont pas standardisés, et d’autre part, parce que d’une version à une autre, il est difficile de tracer les évolutions. Il préconise plutôt de commiter le manifeste yaml généré via Helm (en plus des values) plutôt que de laisser faire l’outil utilisé comme ArgoCD ou Flux.

L’outil utilisé doit pouvoir récupérer les manifestes via un pull ce qui sécurise le cluster. D’ailleurs, pour optimiser les réconciliations, il préconise d’exposer un webhook dans le cluster que la CICD pourrait appeler dès qu’une version est déployée. Cela optimise le CPU et la RAM au niveau du cluster, surtout quand le nombre d’applications est important.

Et enfin, le système fait une réconciliation constante de l’état désiré.

Ce deuxième talk de Kevin était plutôt dense, mais facile à suivre. L’approche GitOps est une approche que j’utilise depuis plusieurs années, mais j’ai tout de même appris des choses. Et cela donne envie d’explorer plus en détail le projet OpenGitops.

Rust pour le développement d’applications métier haut-niveau ! 🦀

J’adore voir les talks de Stéphane Trébel alias le permacodeur qui est un excellent Showman et à chaque fois, il me bluffe par son éloquence et sa pertinence. Stéphane est un ancien collègue et c’était un plaisir de le revoir sur scène et en off.

Dans ce talk, Stéphane nous démystifie les concepts les plus difficiles de Rust afin de nous démontrer que Rust peut être largement utilisé pour construire des applications métiers.

En effet, Rust est un langage plutôt mature et bien pensé. Son expérience développeur est vraiment excellente aussi bien grâce à sa syntaxe et ses concepts, mais aussi à son outillage avec le compilateur qui explique les erreurs commises et propose des solutions.

Les différents concepts que sont les structs, les new types, les traits et le pattern matching y sont décrits. Stéphane s’attarde aussi sur différentes crates les plus populaires ainsi que différents frameworks qui facilitent la vie du développeur d’application.

Cette introduction à Rust donne envie de s’y mettre sérieusement. D’ailleurs, Stéphane streame plusieurs fois par semaine sur justement le développement rust.

Un très bon talk, proche d’un standup.

Comment j’organise ma veille technologique

J’ai eu la chance de donner mon talk dans un amphi bien rempli. Je ne pensais pas avoir autant de personnes intéressées par mon approche pour faire ma veille technologique.

Je présente le workflow que j’ai développé depuis plus d’un an pour transformer une veille passive en apprentissage actif : capturer et annoter les sources (articles, podcasts via Snipd, livres via Kindle) dans Readwise, puis les centraliser dans Obsidian pour en faire des notes structurées, des articles ou encore des talks. Le tout en une heure par jour, pendant la pause déjeuner. J’ai publié un article de blog qui en retrace les grandes lignes pour ceux qui n’ont pas pu y assister.

J’étais content de ma prestation avec au final un timing respecté, des questions intéressantes et des retours plus que positifs. Cela me conforte dans l’idée que je devrais le présenter à d’autres conférences.

En conclusion

Le Breizhcamp est une conférence que j’apprécie énormément. Elle est conviviale depuis ses origines, les organisateurs comme les bénévoles, sont bienveillants et sont aux petits oignons pour les speakers comme pour les spectateurs. Et cette année a été particulièrement gratinée entre les chaleurs caniculaires (il faisait plus chaud à Rennes qu’à Montpellier) et les orages du jeudi soir qui ont fait des dégâts sur le campus de Beaulieu.

Les sujets présentés sont toujours aussi intéressants et il y en a pour tous les goûts. J’ai hâte de venir à l’édition 2027, en attendant je suis parti à Montpellier pour profiter de la fraîcheur et accessoirement assister à SunnyTech.