Devoxx France est la plus grande conférence indépendante autour du développement et de la programmation, en Europe. Cette année encore, Sedona a participé aux 3 jours de conférences qui se sont tenus du 16 au 18 avril. Cette année l’IA était à l’honneur, l’IA est de plus en plus présente que ce soit sur les besoins de nos clients ou bien en assistance de nos développements, il est donc normal que ce sujet ait été le plus discuté cette année.
Nous avons choisi quelques talks que nous souhaitons vous partager pour ce jour 2, on vous raconte ?
Jeudi 17 Avril 2025
Les clés de l’architecture pour les devs – Christian Sperandio (Arolla ), CYRILLE MARTRAIRE (Arolla)
Au cœur de cette session, nous avons retrouvé la vision de l’architecture comme un processus vivant, loin d’une simple photo figée. On a passé en revue l’évolution des systèmes, de l’ère des monolithes aux architectures distribuées dans le cloud, en insistant sur la modularité comme pilier de flexibilité et de maintenabilité. Ce qui nous a particulièrement marqué, c’est la mise en lumière de la modularité physique versus logique : on peut déjà découper proprement un monolithe avant de plonger dans la complexité des microservices.
Mais l’architecture, c’est d’abord une histoire de besoins : avant de coder, il faut poser le vrai problème, dessiner le contexte avec un diagramme clair, et échanger sans présupposer de solution technique. Nous avons apprécié les conseils concrets autour des attributs de qualité (disponibilité, performance, coût) et des bonnes pratiques comme rédiger des ADR, tester l’architecture et formaliser des contrats explicites entre services. En fin de compte, ce talk rappelait que l’architecture est avant tout un travail collaboratif, où chaque décision compte pour bâtir un système robuste et évolutif.
Kubernetes : 5 façons créatives de flinguer sa prod – Denis Germain (Lucca)
Dans ce talk, Denis Germain nous plonge au cœur de ses plus belles frayeurs en production Kubernetes, à travers cinq incidents marquants. Nous avons retrouvé le souvenir de la fois où un simple probe de liveness s’est transformé en boucle infernale à cause d’une dépendance cyclique sur RabbitMQ : un excellent rappel que nos checks de santé ne doivent jamais devenir des points de fragilité. Le récit des mises à jour foireuses avec Helm v2, perdues dans des manifests disparus, m’a rappelé qu’un GitOps bien rodé est plus qu’un luxe : c’est une bouée de secours lorsqu’un simple rm –rf peut coûter des heures de debugging.
Mais l’humain reste au centre : entre les ingress dupliqués qui partageaient malencontreusement le même endpoint, l’angoisse de l’autorité de certification interne qui expire au pire moment, et la mise à jour SystemD qui a vidé les règles de routage, chaque anecdote est une leçon de prudence et d’automatisation. Nous avons particulièrement aimé la conclusion : privilégier des images immuables, adopter Cert-Manager pour ne plus craindre l’expiration des certificats, et valider par des webhooks pour éviter les doublons. Autant d’approches concrètes pour transformer la peur en résilience.
Securing LLM-Powered Applications: Overcoming Security and Privacy Challenges – Brian Vermeer (Snyk)
Cette présentation de Brian Vermeer nous a rappelé à quel point les modèles de langage peuvent être à la fois puissants et fragiles lorsque leur sécurité n’est pas pensée dès la conception. Nous avons retenu l’exemple du chatbot qui a vendu une voiture pour 1$ à cause d’une mauvaise interprétation : une démonstration cinglante de l’importance cruciale de la sanitisation des entrées et de la mise à jour régulière des bibliothèques pour colmater les failles. L’idée que les LLM sont « sans état » nous a aussi marqué : sans gestion de la mémoire de chat, on perd vite le fil et on s’expose à des injections de contexte ou de SQL, comme dans l’anecdote de la réservation annulée grâce à un fichier piégé.
Au-delà des vulnérabilités, nous avons apprécié les conseils pragmatiques pour bâtir des applications IA plus sûres : établir des messages système stricts pour encadrer le LLM, utiliser des garde-fous avant et après chaque appel, et restreindre les permissions en fonction des rôles. L’approche « security by design » revient sans cesse : choisir le bon modèle pour chaque usage, intégrer des revues de sécurité dans le pipeline CI/CD et prévoir une validation humaine sur les points critiques. En somme, ce talk nous a convaincu que tirer pleinement parti de l’IA, c’est surtout savoir anticiper et maîtriser ses angles morts.
Optimisez vos applications Spring Boot avec CDS et Project Leyden – Sébastien Deleuze (Broadcom)
L’optimisation des applications Spring Boot n’est pas qu’un simple exercice de gains de temps : il s’agit avant tout de réduire les coûts d’hébergement, de diminuer l’empreinte énergétique et de garantir des performances fluides dans des environnements conteneurisés. Class Data Sharing (CDS), introduit dès Java 9 et pleinement supporté avec Spring Boot 3 sur Java 17, permet de mutualiser les classes chargées à l’initialisation, et offre ainsi un démarrage jusqu’à deux fois plus rapide tout en réduisant la mémoire de 20 %. À partir de Java 24, l’AOT Cache (via JEP 483) va plus loin en stockant non seulement la représentation pré-parsée, mais aussi l’état des classes après leur chargement et leur linkage, ce qui peut multiplier par 2 à 4 le gain de startup comparé à CDS classique.
En regardant vers l’avenir, Project Leyden promet d’enrichir encore cette chaîne d’optimisation en introduisant le profiling de méthode et la compilation AOT de certains passages critiques pour réduire la latence de « warmup » des applications. Sébastien Deleus souligne l’importance de tester ces approches dans des environnements proches de la production, de combiner Spring AOT (génération de proxies à la compilation) avec l’AOT Cache, et d’envisager des images immuables pour limiter les risques liés aux mises à jour dynamiques. En adoptant ces technologies, on peut non seulement atteindre des démarrages quasi instantanés, mais aussi préparer ses services à évoluer de façon plus durable et résiliente.
La réactivité et les signaux : démystifions la magie du frontend – Estéban Soubiran (Maiaspace)
Nous avons beaucoup apprécié la façon dont Estéban a posé la réactivité comme une simple « fonction de l’état », un principe aussi limpide qu’efficace : dès qu’une valeur change, l’interface se met à jour sans qu’on ait à y penser. L’exemple du tableau Excel m’a rappelé combien ce concept est universel, puis la plongée dans la théorie des graphes a permis de visualiser concrètement comment les nœuds et les liens orchestrent le flux de mises à jour.
La découverte d’Alien Signals nous a particulièrement enthousiasmé : cette librairie légère reprend le meilleur du modèle push-pull et offre des primitives claires (Signal, Computed, Effect) pour enchaîner les dépendances sans se perdre dans des boucles infinies ni des glitches. Les quatre défis (glitches, dépendances cycliques, états mutables, mises à jour dynamiques) sont traités de manière pragmatique, et le parallèle avec Vue.js montre qu’on est sur quelque chose de solide, prêt à s’intégrer dans tout projet moderne.
Gitflow c’est bien, Gitbutler c’est mieux ! – Yann-Thomas Le Moigne (Apside), Lilian Forget (Apside)
Nous avons trouvé la démo de Git Butler particulièrement rafraîchissante : pouvoir manipuler des « branches virtuelles » sans changer constamment de contexte, c’est vraiment un gain de temps au quotidien. Lorsqu’ils ont travaillé sur NG Baguette, passer d’une feature à une autre sans checkout classique permet bien d’éviter de multiples commits intermédiaires et leur a permis de prototyper plus librement. La gestion simplifiée des commits—avec la possibilité d’appliquer un même correctif à plusieurs branches en une seule commande— semble être une solution idéale pour collaborer sans craindre de faire exploser l’historique.
Nous avons aussi apprécié l’intégration d’IA pour générer des messages de commit : un coup de pouce bienvenu quand on court après le temps. Côté conflits, Git Butler nous a paru bien plus fluide, avec des résolutions partiellement automatisées qui laissent la main dès qu’il y a besoin de décision humaine. Même si l’outil reste encore en bêta (et dépend de GitHub/GitLab), nous avons perçu un vrai potentiel pour alléger la courbe d’apprentissage de Git et rendre les workflows plus adaptables, même pour les équipes qui utilisent des stratégies plus classiques comme Git Flow.
Quand Java rencontre l’AI – Construisez des applications utilisant l’AI en Java – Emmanuel Bernard et Clement Escoffier
Dans cette présentation, Emmanuel Bernard et Clément Escoffier abordent l’intégration de l’IA dans des applications Java à l’aide de Quarkus.
Ils explorent des sujets tels que les modèles de langage, le RAG (Retrieval-Augmented Generation), le function calling, et les architectures agentiques. L’objectif est de fournir aux participants une compréhension approfondie des outils et des techniques disponibles pour développer des applications enrichies par l’IA.
– Les modèles de langage (LLM) sont des réseaux neuronaux conçus pour prédire le mot ou le token suivant en fonction d’un contexte donné.
Ils sont à la base des systèmes d’IA générative. Parmi les exemples connus figurent GPT, Claude, ou encore LLaMA 3.2.
– Le RAG (Retrieval-Augmented Generation) est une approche qui combine la recherche d’informations et la génération de texte par un modèle de langage.
Son objectif est d’enrichir les réponses générées en s’appuyant sur des données externes, souvent spécialisées ou mises à jour.
Le processus commence par une phase d’indexation, où les documents sont chargés et découpés en segments pertinents, puis transformés en vecteurs via un modèle d’embedding.
Lorsqu’une question est posée, le système effectue une recherche vectorielle pour identifier les segments les plus proches du sens de la requête.
Ces extraits sont ensuite transmis au modèle de génération (comme GPT), qui produit une réponse contextualisée à partir de ces informations.
Grâce à cette combinaison, RAG permet de réduire les erreurs de type « hallucination », d’accéder à des contenus actualisés, et d’offrir des réponses plus fiables et adaptées à des besoins métiers spécifiques.
Le function calling permet à un modèle de langage d’interagir avec des fonctions ou services externes afin d’enrichir ses réponses avec des données dynamiques ou spécifiques.
Mécanisme :
– L’utilisateur soumet une requête.
– Le modèle détecte qu’une fonction peut etre utilisée pour répondre.
– Il génère un appel à cette fonction avec les paramètres dont il a à sa disposition
– Le modèle utilise la réponse reçue pour formuler une réponse finale complète et contextualisée.
Exemples d’outils :
– Bases de données pour obtenir des informations précises
– Services web (API météo, boursière, médicale, etc.)
– Fonctions personnalisées (calculs, extraction de données, conversion de formats)
Avantages :
– Accès à des informations actualisées en temps réel
– Réponses plus pertinentes, fiables et adaptées à des cas spécifiques
– Extension des capacités du modèle au-delà de son entraînement initial
– En somme, le function calling transforme un modèle de langage en véritable assistant connecté, capable de combiner génération de texte et exécution de fonctions précises selon les besoins.
Les guardrails sont des mécanismes qui encadrent les interactions entre un utilisateur et un modèle de langage, afin de garantir la sécurité et la validité des entrées et des sorties.
On distingue deux types principaux :
Input Guardrails : filtrent ou valident les requêtes avant qu’elles ne soient traitées, pour éviter les entrées malveillantes, mal formulées ou inappropriées.
Output Guardrails : vérifient les réponses générées pour s’assurer qu’elles ne contiennent pas d’informations sensibles, offensantes ou non conformes aux règles d’usage.
Ils sont essentiels pour assurer un fonctionnement sécurisé, fiable et contrôlé des modèles de langage et peuvent être mis en œuvre via des règles, des modèles de filtrage ou des outils spécialisés comme Guardrails AI.
Le MCP (Model Context Protocol) est un protocole récent qui vise à standardiser la manière dont les modèles de langage interagissent avec des outils, des données et des applications externes.
Il a été introduit pour structurer les échanges entre un client (comme une application ou une interface utilisateur) et un serveur de modèle (comme un LLM) de façon cohérente et extensible.
La présentation met en lumière les nombreuses possibilités offertes par l’intégration de l’IA dans les applications Java via Quarkus et Langchain4j.
Jour 3 dans le prochain article !
Article rédigé par Edouard Lamotte, Mathieu Broutin, Amine Amarir, Kaiqiang Xu et Omar Belahcen