⚠️ Les replays seront ajoutés lorsqu’ils seront dispo (encore quelques semaines de patience !)
Ce mercredi 16 avril, j’ai eu la chance de participer à Devoxx France 2025, l’un des plus grands rendez-vous francophones de Dev, mais aussi archi et surtout IA cette année. Organisé au Palais des Congrès de Paris, l’événement a rassemblé plus de 4000 participants (je crois) et 315 speakers ! 😱
Mais avant tout ça, ptit réveil 5h du mat’ pour prendre le train direction Paris. 🚄
Hop on saute sur le petit-déjeuner de bienvenue, un croissant, un café et on part pour la keynote d’ouverture ! 🥐
Keynote d’ouverture
La journée a commencé fort avec la keynote d’ouverture signée Luc Julia, co-créateur de Siri (rien que ça ! 😅). Le titre de sa conférence “L’Intelligence Artificielle n’existe pas” , annonce direct la couleur. Pas d’effet “Whaou ✨” mais un retour à la réalité sur ce qu’est réellement une IA.
Selon lui, l’IA telle qu’on la présente aujourd’hui est largement surcotée, alimentée par “un storytelling hollywoodien”. Il rappelle que les IA ne sont ni intelligentes ni autonomes, mais simplement des outils conçus pour exécuter des tâches précises. Il va même jusqu’à affirmer, je cite : “Les IA génératives n’existent pas, et ça n’existera jamais.”
Ce point de vue est provocateur, je dois avouer. Maiiiiiis, ça permet d’ouvrir les yeux sur le battage médiatique autour de l’IA, tout en soulignant l’importance de poursuivre les recherches en machine learning et deep learning !
Pourquoi devez-vous connaître ce nouveau format de stockage de données ?
La première conférence à laquelle j’ai assisté portait sur Apache Iceberg, avec un talk intitulé “Pourquoi devez-vous connaître ce nouveau format de stockage de données ?” présenté par Bertrand Paquet qui travaille chez Doctolib en tant que SRE.
À première vue, le sujet semblait très orienté « data », mais Bertrand a réussi à le rendre clair, accessible et surtout pertinent même pour ceux qui, comme moi, ne baignent pas au quotidien dans la data. 😅
J’ai découvert qu’Iceberg a été créé par Netflix et qu’il est open source. Il s’impose progressivement comme le standard des Data Lakes. En grande partie, car il est le plus utilisé. Parmi ses points forts, Bertrand a mis en avant :
- le support natif des transactions ACID (Atomicité, Cohérence, Isolement, Durabilité)
- la possibilité de faire du « time travel » (revenir à l’état des données à un instant T)
- un système de branching façon Git
- la possibilité de faire des updates sur des datasets ce qui n’est pas possible avec Parquet
Les démonstrations sur le service Athena d’AWS étaient particulièrement parlantes, notamment pour comparer les performances de vitesse d’exécution entre des requêtes sur fichiers CSV, Parquet, et Iceberg. 🏎️
Même en n’étant pas un Data Engineer, ce talk a vraiment piqué ma curiosité surtout la phrase de l’abstract “Même si vous ne travaillez pas dans une équipe data, cela finira par vous impacter”. Donc très content d’avoir pu y assister ! 👍
Comment API Gateway transforme l’exposition des ressources Kubernetes ?
Depuis un moment déjà, j’entendais parler de la Gateway API comme du futur remplaçant des objets Ingress sur Kubernetes. Autant dire que je ne voulais surtout pas rater cette conférence présentée par Emile Vauge (créateur de Traefik) et Nicolas Mengin (mainteneur du projet). Et je n’ai pas été déçu. 😉
Le talk a débuté par un retour historique sur l’évolution des Ingress dans Kubernetes :
- Ingress (2015) : simple, basé sur des annotations, limité à HTTP
- IngressRoute (2019) : configuration via spec, support de HTTP, TCP et UDP
- Gateway API (depuis 2019) : configuration via des objets dédiés, meilleure séparation des responsabilités, support HTTP/TCP.
Si les Ingress ont longtemps été suffisants pour des cas simples mais on voit rapidement leur limites : pas de rate limiting, pas de mTLS, pas de politiques CORS, pas d’authentification OAuth/JWT native…
Et pour contourner tout ça ? Jusqu’à 117 annotations différentes, dans un format clé/valeur pas vraiment pensé pour la lisibilité… 😰
C’est là que Gateway API entre en jeu. L’approche repose sur des ressources kube et surtout sur une séparation claire des rôles :
- Les ops gèrent des ressources comme GatewayClass et Gateway,
- Les devs se concentrent sur des objets comme HTTPRoute ou TLSRoute.
Bref, exactement ce que j’étais venu chercher : comprendre pourquoi Gateway API va prendre la place d’Ingress à terme. 🥰
Pause miam miam & goodies
Après une matinée bien rythmée entre keynote et confs, petite pause déj bien méritée. Au menu : Bagna poulet/avocat, parfait pour recharger les batteries. 🔋
L’occasion aussi de récupérer le fameux sac Devoxx, mon premier. 😍
Mais pas le temps de s’endormir, les conférences reprennent vite. Let’s go, on y retourne 💻🔥
Vol au dessus d’un nid de vulnérabilités
L’après-midi a repris avec la conférence “Vol au-dessus d’un nid de vulnérabilités”, présentée par Damien Lucas, tech lead chez Onepoint. Le sujet ? Le SBOM, ou Software Bill Of Materials.
Damien a commencé par un constat que beaucoup partagent. Il est difficile de maintenir à jour toutes ses dépendances… Et encore plus de les auditer régulièrement. C’est là que le SBOM entre en jeu. Pour ceux qui ne seraient pas à l’aise avec ce terme, c’est une sorte d’inventaire ultra complet de toutes les dépendances utilisées dans une application.
Aux États-Unis, les fournisseurs de logiciels pour le gouvernement sont obligés de fournir un SBOM depuis 2021 et l’Europe commence à suivre le mouvement. 💪
Le talk a ensuite bien détaillé :
- Les formats de SBOM : CycloneDX (OWASP) vs SPDX (Linux Foundation),
- Les outils de génération : Syft, Trivy, Docker Scout, cdxgen, sbom-tool,
- La signature des SBOM avec cosign,
- Et surtout, l’outil Dependency Track, capable d’ingérer un SBOM et de détecter les vulnérabilités
Parmi les recommandations concrètes de Damien :
- Privilégier CycloneDX pour sa compatibilité étendue,
- Scanner à la fois les dépendances et les conteneurs,
- Et si possible, déployer une instance de Dependency Track
Même si je connaissais déjà le concept de SBOM, cette présentation m’a permis d’y voir plus clair sur les outils, les standards, et les bonnes pratiques à adopter ! 👍
Kubernetes en 2025
Impossible de passer une journée à Devoxx sans parler de Kube, non ? Même si on avait déjà un peu abordé le sujet avec la Gateway API le matin, cette conférence intitulée “Kubernetes en 2025” par Alain Regnier (CTO de Kubo Labs) était l’occasion de faire un état des lieux des dernières évolutions de l’écosystème, et surtout de ne pas continuer à utiliser Kubernetes comme en 2015. 😅
Le talk a balayé pas mal de fonctionnalités et parfois méconnues, comme :
kubectl debug : super pratique pour ajouter un container éphémère dans un pod afin de le diagnostiquer (idéal quand il n’a ni shell, ni curl…) 🛠️
VolumeSnapshot : une vraie découverte pour moi ! Il permet de faire des snapshots de PV à un instant T. Parfait pour les backups, les restores ou les migrations (attention, dispo uniquement selon le CSI utilisé, tous ne l’ont pas) 💾
eBPF et Cilium : Alain recommande fortement de s’intéresser à cilium ! 🔎
Et bien sûr, clins d’œil à ce qu’on avait déjà vu ce matin, la Gateway API ! Ça prouve que ça commence à se faire une place au profit des ingress !
Il y avait d’autres sujets intéressants évoqués : gestion des ressources avec request/limits au niveau des pods, Kueue pour les jobs batch, etc. Si ça vous intéresse, je vous invite à jeter un œil au replay, promis ça vaut le détour.
En tout cas, je ressors de ce talk avec les prochaines tendances de kube en bien tête. Très content 😁
Exegol le hacking à base de conteneurs
C’était mon moment, le dernier talk de la journée, ma présentation d’Exegol. J’avais déjà eu la chance de la donner au BreizhCamp en juin dernier. Mais cette fois, c’est Devoxx France, une autre dimension, une autre pression. Je savais que j’allais avoir plus de monde, potentiellement des profils très techniques… Et ça me stressait pas mal, surtout à l’idée de tomber sur une question à laquelle je ne saurais répondre. 😰
J’ai passé une bonne partie de la journée avec un petit stress constant. Et puis… miracle. Le timer démarre, je commence à parler et tout disparaît. Le stress, les doutes, pouf, envolés. Je déroule ma présentation hyper à l’aise, en kiffe total. Pas d’hésitations, pas de bafouillage, juste 30 minutes de pur plaisir. 😍
Un immense merci à celles et ceux qui sont venus m’écouter, surtout en fin de journée ! Et une mention spéciale à WeScale et aux WeScalers qui sont passés me soutenir. Vous êtes les bests. 🫶
Dîner des speakers
La journée s’est terminée par le fameux “Dîner des speakers” 🍽️
Un moment très sympa. C’était l’occasion parfaite de papoter avec les copains, débriefer les talks, échanger et mettre des visages sur des noms. J’ai notamment eu le plaisir de discuter avec Damien, Anis et Stéphane. J’ai passé un super bon moment. Si vous passez par là 👋
Côté nourriture… Bon, disons que les quantités étaient un peu limitées. 😅
Il fallait choisir, papoter ou manger et devinez quoi, j’ai surtout discuté. 😂
Une belle manière de boucler cette première journée à Devoxx. 🫶
Conclusion
C’était mon tout premier Devoxx et franchement… Quelle claque ! 😱
Trois jours incroyables, entre les conférences super intéressantes, les speakers au top du top, les moments sur le stand WeScale (avec les boosters 😏) et les discussions passionnantes que j’ai pu avoir… J’en ressors avec des étoiles plein des yeux. 🤩
Et surtout une furieuse envie de recommencer. J’espère sincèrement que ce premier Devoxx ne sera que le début d’une longue série ! 🤞
Merci à tous ceux que j’ai croisés, aux speakers, aux participants, aux orgas et bien sûr à l’équipe WeScale. 🫶
👉 Et si vous voulez le récap des deux autres journées, ça se passe sur le blog de WeScale !