DEVOXX FRANCE 2025 - DAY 3

Devoxx France is a French event based in Paris with almost all content in French, so exceptionally, I post in French. I apologize to my non-French speaking readers.

https://www.devoxx.fr/

Du 16 au 18 avril 2025, j'ai eu la chance de participer aux 3 journées de Devoxx 2025 France à Paris. Une conférence passionnante et enrichissante à laquelle je prends toujours beaucoup de plaisir.

Lors de cette édition, en plus des différents échanges avec d'autres participants, j'ai aussi pu assister à 24 talks, aux keynotes et à des rencontres avec des communautés.

Dans cette série d'article, je vais vous partager mes principaux enseignements de 22 des 24 talks auxquels j'ai assisté. En effet, il y a 2 talks dont je n'ai pas compris le message donc je ne les aborderais pas.

Dans le troisième épisode de cette série, je vais vous partager les principaux enseignements que j’ai retenus des 8 talks auxquels j'ai assisté le troisième jour. Ainsi que le résumé global de mon Devoxx 2025.

• Vincent Heuschling - Datatask

DuckDB est passé en peu de temps du "truc bricolé par des universitaires" à une véritable alternative aux solutions de Lakehouse et de base de données classiques.

En prenant en exemple un projet de base nationale de référence du monde vétérinaire, on va pouvoir voir que DuckDB apporte des réponses à tous les niveaux, qu'il s'agisse de transformer des données en faisant du SQL in-memory, Explorer des datasets dans le navigateur avec un moteur embarqué en WASM, jusqu'à présenter à des utilisateurs au travers d'applications web.

Tout ça sans avoir besoin d'un serveur de bases de données ! Ce moteur est quasi magique tant les possibilité qu'il offre sont infinie.

Et pour enfoncer le clou, on optimise les couts de manière démesurée !

Cette session est un véritable playbook pour adopter DuckDB pour votre organisation, et en tirer tous les bénéfices.

Le talk a démarré par un historique des data platforms : datawarehouse -> datalake -> lakehouse (avec une architecture médaillon).

Puis il y a eu une présentation de DuckDB (https://duckdb.org/) qui est un projet universitaire. Il s’agit d’un “in process analytical fast database” écrit en C++ et extensible. “DuckDB” car le fondateur avait un canard en animal de compagnie.
Sur les bases de données in process, il y a notamment : sqlite (transactional) / DuckDB (analytics).
Contrairement à sqlite qui est “row oriented”, DuckDB est une base de données orientée colonne avec une optimisation “vectorisée” : dans chaque column on récupère des vecteurs pour limiter l'empreinte mémoire.

Ensuite il y a eu une présentation d’un cas d’usage avec DuckDB dont les principaux éléments qui j’ai retenus sont les suivants :

• souverain, flexible, rapide, économique

• stockage objet chez Clever Cloud

• streamlit app pour la couche de présentation

• daily batch pour un coût 47€/mois avec 500Go de stockage

Pour fini il y a eu une démo qui m’a fait découvrir les notebooks “marimo” (https://marimo.io/).

• HELA BEN KHALFALLAH

À l'ère du Big Data, les structures de données classiques atteignent leurs limites en performance et en mémoire. Comment traiter efficacement d’énormes volumes d'information avec une précision "suffisante" sans exploser les coûts ? Découvrez les structures de données probabilistes – Bloom Filter, HyperLogLog, Count-Min Sketch, MinHash… – qui misent sur l’approximation intelligente pour relever les défis des bases modernes, des systèmes distribués et des traitements en temps réel.

• slides : https://helabenkhalfallah.com/wp-content/uploads/2025/04/Probabilistic-Data-Structures_-Smart-Approximations-for-Big-Data_v1.pdf

Dans ce talk, l’oratrice a évoqué les différentes structures probabilistes (Bloom filter, HyperLogLog, …) utilisées pour palier aux différentes limitations des structures de données traditionnelles (Array, LSM, Trees, …).

Les limites des structures de données traditionnelles sont :

• la mémoire

• la latence

• la scalabilité

• la gestion des streams

Les structures de données probabilistes offrent des résultats moins précis mais plus efficace en terme de consommation de ressources et de temps de réponse. Elles sont définies par des formules mathématiques qui permet d’évaluer leur imprécision. Elles reposent sur trois principes fondamentaux qui sont :

• compact representation

• hash functions

• bounded errors

• David Pilato - Elastic

Viens découvrir à travers une histoire vraie, comment une simple petite réponse dans un forum de discussion sur un projet méconnu peut complètement changer et accélérer ta carrière.

J’ai retenu trois choses concernant ce talk très intéressant sur la façon dont l’open source peut nous aider à évoluer :

• ne pas hésiter à publier le code même s'il est imparfait

• ne pas hésiter à se lancer et à demander de l’aide : peering, relecture, entraînement

• garder la bienveillance et la patience dans toutes les circonstances

• Mohamed AIT ABDERRAHMAN - Thoth Technologies

• flexibilité, chaque développer est responsabilisé

• efficacité

• collaboration améliorée (baisse de la frustration)

• Alice Bonhomme-Biais - Freelance

• Théotime Levêque - Back Market

Ça y est, vous êtes Staff Engineer, félicitations !
Mais très vite, vous réalisez que ce rôle est un peu différent de vos précédents challenges. Entre le manque de temps pour penser stratégie, le context switching constant, la sensation de ne pas être entendu.e par le leadership, ou encore la difficulté de lâcher prise sur certaines tâches… Les défis ne manquent pas !
Dans cette session, Alice, ancienne Staff à Google et coach de Staff engineers et Théotime Principal Engineer à Back Market partageront des situations concrètes, accompagnées de conseils pratiques pour mieux naviguer ces situations. Comment prioriser dans un emploi du temps surchargé ? Comment influencer des décisions ? Comment redéfinir votre impact dans un rôle de leadership ? Comment repenser la nature de vos contributions en dehors des contributions techniques directes? Comment déléguer? Comment communiquer efficacement avec d’autres leaders?
Avec des anecdotes réelles et des conseils concrets, cette conférence vous aidera à transformer les galères du quotidien en opportunités d'impact et à vous épanouir dans votre rôle de Staff Engineer. Bienvenue dans les coulisses d’un rôle clé du leadership tech !

• pig picture

• project exécution

• leveling up

Ces 3 piliers sont basés sur les connaissances techniques et l’expérience.

Ensuite, les orateurs ont évoqué les principaux problèmes rencontrés par les Staff et apporté des solutions :

• Se libérer du temps

  • réduire les interruptions (utiliser les canaux plutôt que les one.one)

  • auditer l'agenda

  • déléguer et mentorer

  • dire non

• Éviter de faire soi même

  • laisser faire

  • accepter que d'autres fassent autrement

  • partager le contexte

  • soutenir

• Que suis je censé faire ?

  • écoute active

  • être identifiable

  • ne pas se disperser

  • skip level interview

• Personne ne m'écoute

  • établir une confiance réciproque

  • carte mentale des intérêts de chacun

  • feedback / debrief

  • architecturer ses discussions

• Faire passer un message

  • demande claire et succincte

  • expliquer le pourquoi

• Je ne fais que dire non

  • demander et partager du feedback

  • penser à l'impact des décisions

• Je sens que je perds la main, comment rester technique

  • ai-je du temps pour des sujets qui me plaisent ?

  • ai-je besoin de rester très technique ?

  • quelle est la suite de ma carrière ?

• Virginie JUGIE - Pigment

Comment la culture d'équipe peut naturellement encourager l'adoption de la pratique « No estimate » sans qu'il soit nécessaire d'avoir à mentionner ce concept ?
À travers mon vécu dans une des mes équipes, nous explorerons comment des valeurs telles que la confiance, la collaboration et la livraison continue créent un environnement où les estimations deviennent inutiles. Nous aborderons les conditions clés qui permettent à la pratique « No Estimate » de fonctionner, les stratégies de communication pour garder les parties prenantes alignées, et les meilleures pratiques pour favoriser une culture qui soutient cette approche de manière transparente.

Bases propices pour la mise en place du No Estimates :

• équipe produit (ownership)

• qualité

• livraison continue (plusieurs fois par jour + feature toggle)

• un sponsor (personne influente dans l'entreprise qui protège l'équipe)

On ne peut améliorer que ce que l'on mesure :

• mesures tech (délai de production, taux d'échecs/ anomalies

• mesures produits (taux d'adoption, efficacité, problèmes résolus)

• mesure business (être aligné avec le business)

Ce que je retiens de la mise en place du No Estimates et du succès dans le cas présenté :

• petites itérations

• priorisation (now, next, later) avec score cards ((business impact x pain points) / complexity)

• focus : on ne fait pas plusieurs tâches en parallèle

• fixation d'objectifs chiffrés et datés sur une mesure

• collaboration (tech, produit, business) avec un alignement sur le vocabulaire du business

• Guillaume Laforge - Google

Vous connaissez les Large Language Models sur le bout des doigts ? Vous maîtrisez le Retrieval Augmented Generation pour aider un LLM à chercher dans vos documents ? Il est temps de plonger dans le monde merveilleux des agents intelligents !

Dans cette session, nous commencerons d’abord par définir ce que sont les agents, ou tout du moins ce qui rends un système “agentique”. Nous expliquerons quelles sont les limites des LLMs et de RAG. Ensuite, au travers d’exemples concrets, nous implémenterons différents agents en Java, en utilisant le framework LangChain4j, pour illustrer certains patterns typiques des agents et pour comprendre comment aller plus loin qu’un simple appel à un LLM pour obtenir des réponses qui répondront aux besoins de vos utilisateurs, voire même pour déclencher des actions avec le système environnant. Nous évoquerons également l'importance de Model Context Protocol (MCP) pour étendre les LLMs avec de nouveaux outils.

Agents devoxxiens êtes vous prêts pour la prochaine hype des agents ? Venez la découvrir dans cette session !

Ce talk m’a permis de découvrir et de comprendre ce qu’est un agent dans le cadre des LLM.

Un agent est un service qui parle à un modèle en utilisant des outils et un contexte.
Un agent fonction avec 4 grandes étapes : think / plan / act / reflect et peut faire des appels à des fonctions (Function calling), contrôler le flux (Control flows) ou encore attendre une intervention humaine (Human in the loop).

MCP (Model Context Protocol) est un protocol pour apporter du contexte à des LLM : https://modelcontextprotocol.io/introduction ; attention au serveur MCP que l'on utilise car il peut appeler notre modèle avec nos tokens.

Google propose un framework nommé ADK (Agent Development Kit) pour développer des agents : https://google.github.io/adk-docs/ ; ainsi qu’un protocole pour la communication entre agents nommé A2A : https://github.com/google/A2A

• Jean-Christophe Sirot - Decathlon

Dagger est un moteur de workflow qui a pour but d’améliorer la CI/CD actuelle.
La CI/CD actuelle repose bien souvent sur des fichiers yaml complexes qui ne sont pas du code et qui ne tournent pas sur notre machine. Dagger apporte une CI/CD composable et maintenable qui tourne en local et dans le langage de notre choix.
Dagger est composé de module et un module peut appeler un autre module, quelque soit le langage dans lequel a été développé le module.

Au delà des échanges enrichissants que j’ai pu avoir, je retiendrai principalement quatre sujets de mon Devoxx 2025.

1. Le sujet qui est revenu le plus souvent dans les talks auxquels j’ai assisté est l’IA. D’ailleurs je l’ai trouvée omniprésente, dans les discussions, dans les keynotes, dans les talks, dans l’identité visuelle mais surtout c’est devenu un assistant indispensable pour plus d’efficacité au quotidien. L’identité visuelle de Devoxx a été générée avec l’aide de l’IA, dans les talks qui ne parlent pas d’IA on retrouve des images dans les slides qui ont été générées avec de l’IA, bref, elle est partout.

2. Les structures de données et les “compute engine” ont toujours leur place dans les talks ce qui m’a permis d’approfondir mes connaissances sur Iceberg, Delta, Arrow, les structures de données probabilistes mais aussi Spark et DuckDB.

3. Ce Devoxx m’a aussi permis de mieux comprendre la structure des containers et de découvrir Dagger pour leur utilisation dans la CI.

4. Enfin j’ai pu trouver de l’inspiration sur des aspects plus organisationnel avec un super talk sur le rôle de Staff Engineer ou encore sur l’amélioration du flux de livraison avec le “Ship, Show, Ask” ou le No Estimates.