Voici un live report de cette soirée, tenue le 13 janvier dans les locaux d’ExaltIT à Châtelet. Les Paris JUG (Java User Group), ce sont d’habitude des évènements permettant à 2 personnes de faire une présentation d’une heure chacune sur des sujets touchant de près ou de loin au monde Java, avec un buffet au milieu de la soirée. Ce sont en quelques sorte des mini Devoxx mensuelles sur un bout de soirée.
Cette fois, et comme à chaque mois de janvier, ce ne sont pas 2 présentations d’une heure, mais 6 présentations de 20 minutes (questions comprises !), réalisées par des gens qui se lancent en tant que speakers. Comme expliqué par l’organisation, ces soirées JUG Academy sont préparées bien en avance, la première candidature est systématiquement validée, une autre est tirée au sortet les 4 dernières sont choisies parmi toutes les propositions. Cette année, il était évident qu’il y aurait de nombreux sujets portant sur le thème très à la mode, l’IA, l’organisation des Paris JUG a donc fait en sorte qu’il n’y ait pas QUE de l’IA, et nous aurons donc des thèmes assez variés.
Voici la page résumant la soirée : https://www.parisjug.org/events/2026/01-13-parisjug-academy/ et le compte Youtube des Paris JUG pour les replays : https://www.youtube.com/@ParisJUG
1- Quand les tests de performance deviennent un critère d’acceptance
Dans cette première présentation, Amal Chaieb nous parle d’une catégorie de tests qui n’est pas forcément très courante lors des process de CI/CD : les tests de performance. Lors du build au cours d’un run jenkins par exemple, les tests seront exécutés, et permettront de valider la cohérence de l’application : tests unitaires, tests d’intégration avec potentiellement tout un processus géré par l’application de bout en bout, avec à chaque fois une comparaison avec le résultat attendu. Mais on verra rarement parmi ces tests des validations de tests de charge, pourtant ce genre de validation peut être crucial pour le fonctionnement de certaines applications (le contexte ici étant un système de courrier recommandé en version électronique, envoi et signature).
Afin de mettre cette phase en place, il faut commencer par déterminer comment faire ces tests (on peut par exemple utiliser Jmeter), puis les faire tourner pour commencer à obtenir des valeurs moyennes (qui permettront de définir les seuils de performance lors des runs de CI), et enfin les intégrer dans la CI/CD, afin de pouvoir les lancer lors de chaque commit par exemple. Il faut ensuite dédier un environnement bien calibré pour pouvoir refléter la production, afin que les tests restent cohérents.
Ensuite, de tous les types de tests de performances possibles, le plus simple sera à préférer : un test de charge nominale, typique d’une charge constatée régulièrement en production. Comme on reste sur un run de CI, il ne faut pas non plus que ça parte sur des heures de tests de stress. Et une fois que tout est bien calibré, le test sera accepté s’il est contenu dans les limites définies, sinon la pull request pourra être rejetée car une baisse de performance aura été détectée.
TLDR : vous travaillez sur une appli où la performance est très importante, et avez peur à chaque pull request qu’elle se dégrade ? Voilà quelques recommandations pour automatiser ce check, basées sur un vrai cas de production.
Replay de la conférence : https://www.youtube.com/watch?v=b1Iz3QKClg0
2- Spring AI with Docker model runner and Debugging
Lors de cette présentation, Sreenu Doosari nous montre ses tests et tâtonnements pour parvenir à tester Spring AI (sans se ruiner avec les différents abonnements IA, ou les quotas de requêtes !) avec divers LLM, puis les tester/débugger sous IntelliJ avec un déploiement local Docker avec Docker Model Runner. Le tout avec des outils compatibles avec l’infrastructure d’entreprise : en effet, les prompts IA étant une nouvelle possible source de fuite de données, beaucoup d’entreprises sont pour le moment très prudentes sur l’IA en externe, et essayent de trouver des compromis pour avoir l’intégration de solutions IA en interne.
Avec une simple appli qui se contentait d’afficher le retour d’une requête IA (« tell a short joke in french ») grâce à un ChatClient qui prend une String en entrée (le prompt) et retourne une String (la réponse), et permettant de jongler entre divers LLM, on a donc pu voir que tout était très facile à mettre en place pour se retrouver en debug.
Replay de la conférence : https://www.youtube.com/watch?v=zDl-xaBglIE
3- CVE en hausse : comment maintenir un produit sûr sans Security Officer
Ensuite, Chloé Delphis nous parle vulnérabilités, et à quel point toute une équipe de développeurs peut être concernée par ce travail obligatoire plutôt que de réserver ce rôle à une seule personne. Des outils de CI/CD permettent de valider et traquer les vulnérabilités dans les dépendances grâce à des appels à la base NVD (National Vulnerability Database), ou mieux à des appels sur une copie locale de cette base (en la mettant à jour régulièrement c’est aussi efficace et permet de ne pas avoir les soucis de panne de la base).
Dans son cas concrêt de mise en place de cette traque aux vulnérabilités, elle recommande un rôle tournant en binôme (jeune + expérimenté), de bien analyser les impacts et les risques réels pour ne pas mettre en risque son projet avec trop de changement, car une vulnérabilité dans une dépendance ne veut pas forcément dire que le code impacté est utilisé dans notre projet. Les détections se feront sous forme de rapports générés niveau CI/CD.
Replay de la conférence : https://www.youtube.com/watch?v=_r8Bf7KBEpc
4- Clean Code Matters
Dans la présentation suivante (et après un buffet), Marc Lecanu aborde un sujet bien connu, mais pour lequel il n’est jamais inutile de refaire une passe, le clean code, d’abord mis en évidence en 2008 par Robert C. Martin, aka Uncle Bob.
On repasse donc sur toutes les règles essentielles pour nommer ses classes/méthodes/variables, faire des constantes au lieu de les mettre en plein code, faire des méthodes efficaces (pas trop longues et avec une utilité unique si possible), documenter, ainsi que tous les acronymes bien connus du monde du clean code : KISS, DRY, YAGNI, SOLID + évidemment les tests à ne jamais négliger.
Le tout pour que nos projets soient maintenables, lisibles pour les générations futures dans l’équipe, et évitent aux développeurs de s’arracher les cheveux.
Replay de la conférence : https://www.youtube.com/watch?v=uAidHF0BMpY
5- Un dojo de code
On passe ensuite à un autre type de sujet : le partage de connaissance, et la volonté d’entretenir ses compétences avec ses collègues, par Christelle Prut. Même si on code déjà au quotidien dans nos missions, on a aussi besoin de s’entretenir sur les thèmes qu’on ne voit pas forcément souvent, ou d’en découvrir de nouveau. D’où l’existence des Dojos, dans lesquels le code se pratique façon Kata.
Plusieurs formes d’organisations sont possibles dans le cadre de ces exercices en groupe, autour de rôles clés comme celui qui code (le driver) ou celui qui mène les débats (le navigateur), et le reste de l’équipe qui suggère des exercices, propose des solutions (l’assemblée) : le mob programming, le fishbowl, le randori. Il faut bien organiser ce genre d’évènement pour que tout se passe bien, avoir un environnement de développement prêt, et de bonnes conditions pour que tout le monde puisse participer.
Replay de la conférence : https://www.youtube.com/watch?v=rx4Yly_A36E
6- Construire des agents IA en Kotlin avec Koog
Le dernier sujet présenté par Latfi Ghassane parle d’IA, et non pas en Java cette fois, mais avec du Kotlin. Il s’agit ici d’utiliser Koog (écrit justement en Kotlin) pour construire des agents IA en gérant plusieurs LLMs et en ayant des entrées/sorties complexes, comme des chatbots, ou assistants pour coder par exemple.
Au fil d’un exemple basé sur un contexte médical, on pourra donc voir comment construire un agent qui permet de détecter des problèmes afin de soutenir un support client. On verra donc un workflow précis, où le prompt est analysé et validé, et à partir duquel on va interroger une base de données et utiliser la réponse pour composer une réponse finale, code à l’appui.
Replay de la conférence : https://www.youtube.com/watch?v=MjO7EUHckw0
Chaque speaker recevra un diplôme, pour une soirée riche en découvertes.
Les prochains rendez-vous du Paris JUG :
