Devoxx France 2026: retour d'expérience
Du mercredi 21 avril au vendredi 23 avril dernier se tenait l'édition 2026 de la Devoxx, une conférence pour les développeurs et développeuses créée en 2012 par l'association du Paris JUG France.
Durant ces 3 jours, les conférences et ateliers se sont enchaînés, de 9h à 18h30, mêlant différentes thématiques : développement en Java, sécurité, base de données ou encore observabilité.
Le lien vers le programme est disponible ici. Les replays seront disponibles sur la chaîne Youtube de Devoxx France.
Pour cet article, j'ai choisi de détailler les trois conférences qui m'ont le plus marquées.
Mon top 3 des conférences
Vous pensiez que la dette technique était le pire ? Voici la dette de conception !
Le premier talk auquel j'ai pu assister est l'un de ceux qui m'a le plus marqué, tant sur le fond, que sur la forme : Vous pensiez que la dette technique était le pire ? Voici la dette de conception ! de Julien TOPÇU et Josian CHEVALIER. La conférence met en scène deux ingénieurs d'équipes différentes : l'équipe "booking" et l'équipe "post-booking". Suite à une mise en production de la première, la deuxième se retrouve impactée et ensemble, ils vont essayer de comprendre pourquoi.
Ce que j'en retiens :
- l'arrivée d'une nouvelle fonctionnalité doit venir challenger le code existant, pas juste l'enrichir
- un modèle métier doit être challengé par l'arrivée d'un nouveau besoin métier
- quand on travaille sur les modèles, il faut mettre de côté les principes KISS, DRY, YAGNI car ils favorisent le couplage intrinsèque
- lorsque qu’il y a un couplage des responsabilités d’un modèle, on peut parler d’effet cuichette, la fameuse fourchette-cuillère, qui fait ni bonne cuillère, ni bonne fourchette
- certains couplages peuvent être involontairement crées lors d'ateliers comme l'event storming, à cause, entre autres, de certains biais de langage. Cette section est bien mieux expliquée dans le talk, donc je vous invite à regarder le replay
- les soucis de conception peuvent aller jusqu'à impacter l'organisation d'une entreprise. Le déploiement d’une première équipe peut impacter la prod d’une seconde équipe s’il y a une dépendance dans leur code. La remédiation à ces soucis va souvent passer par la mise en place de processus tels que le multi-versionning, le double run et les feature flags, afin de limiter l'impact sur les autres équipes. Voire, on va commencer à introduire des rôles palliatifs comme le RTE (Release Train Engineer) afin de synchroniser les équipes. À fin humoristique, les speakers ont renommé le rôle en “Readiness Toggle Engineer”
La magie d’OpenTelemetry - réécrire votre app en production
Je recommande ce talk à quiconque souhaite s'initier à OpenTelemetry. Le speaker, Bruce BUJON, développeur chez Datadog, commence sa présentation par une introduction claire et concise d'OpenTelemetry avant de nous mettre en avant les différents impacts applicatif que peut avoir l'instrumentation de son code avec l'agent OpenTelemetry pour Java.
Ce que j'en retiens:
- OpenTelemetry est un framework qui fournit des APIs, SDKs et conventions autour de l'observabilité
- Il est possible d'utiliser et créer ses propres agents en Java.
- Le speaker nous propose la définition suivante de l'instrumentation : capacité d'ajouter du bytecode dans le but d'obtenir de la données qui sera utilisée par d'autres outils
- Lorsqu'on instrumente son code à l'aide d'un agent, il faut avoir conscience que le code qui s'exécute n'est plus celui qu'on a compilé. Durant la présentation, le speaker a instrumenté son application d'exemple via l'agent Java et grâce à l'outil Meta-Agent, il va nous montrer la différence dans le code source : pas moins de 43 000 lignes ajoutées ! Ce code généré ne va pas être sans impact:
- plus grande utilisation de la mémoire pour la création de spans
- surcharge au niveau du CPU
- impact au niveau des - I/O & threads : on passe de thread applicatif à des threads pour l'export.
- Il existe des solutions de remédiation comme GraalVM, AppCDS, Leyden (initiative en cours) mais il faut étudier ces solutions pour voir si notre contexte nécessite cette complexité
Cache-moi si tu peux - patterns et pièges du cache en production
J'ai vraiment aimé ce talk, non pas parce que le nom du speaker, Sébastien LECACHEUR, prêtait à sourire dans ce contexte, mais parce que c'était la première fois que je suivais une conférence qui parlait de cache. L'intention du talk était de montrer que l'adage "on va juste mettre un cache, ca ira plus vite" n'était pas sans risque. Pour appuyer son propos, il nous a partagé une citation de Phil KARLTON : "There are only two hard things in Computer Science: cache invalidation and naming things.".
Ce que j'en retiens:
- il y a trois motivations pour mettre en place du cache :
- améliorer le temps de réponse
- optimiser le coût des traitements
- augmenter la capacité de traitement
- si on veut faire des métriques autour du caching, il faut s'intéresser au ratio hit rate = hits / (hits + misses)
- lorsqu'on veut mettre en place un cache, il faut choisir entre
- la fraîcheur des données
- la performance souhaité
- la simplicité de mise en place
- il y a trois espaces de stockage pour du cache:
- au niveau de l'application
- sur le serveur
- sur un cache distant (et donc toutes les applications peuvent y accéder)
- lorsque l'on travaille avec du cache, il faut se poser des questions comme : que se passe-t-il si le cache est vide ? S'il est faux ? Qui est responsable de son invalidation ?
- dans les cas des LLMs , avoir du cache peut coûter plus cher que de ne pas en mettre
- dans le semantic caching, on ne stocke plus simplement de la donnée brute, mais le sens de la requête via des modèles d'embedding
Sébastien nous aussi partagé quelques bonnes et moins bonnes pratiques autour du cache :
Bonnes pratiques
- définir un timeout à notre cache
- avoir une solution de fallback quand le cache tombe
- versionner les clefs pour les montées de version
- ne pas mettre de données RGPD en cache
- définir un scope: prefix et des droits d'accès sur les clefs
- mettre en place des métriques et du monitoring
- documenter les motivations autour de la mise en place du cache (ADR + cas d'usage)
- faire des tests avec cache activé, désactivé, vide et chargé
- faire du chaos engineering sur le cache
Anti-patterns
- mettre un cache devant chaque brique
- mettre le même TTL partout
- avoir du cache partagé entre des services non coordonnés
- avoir du cache sans stratégie de warm-up
- absence de monitoring du cache
Quelques autres informations qui m'ont marquées
- Afin d'aligner le Temps Universel Coordonné (UTC) avec le temps solaire, l'Observatoire de Paris peut annoncer la nécessité d'ajouter une seconde intercalaire et donc faire durer une minute, 61 secondes. L'ajout de cette seconde supplémentaire a notamment été la raison d'un incident en production chez Cloudflare (Tic-Tac... bomb ! Maîtrisez le temps et NTP avant qu'il ne soit trop tard)
- Le Cloud du Coeur, l'infra des Restos du Coeur, cherche des contributeurs qu'il s'agisse de développeurs, d'ops ou de chef de projet
- Afin de faciliter la communication entre les développeurs et les ops, Deezer propose, depuis un peu plus de deux ans, une CLI à ses équipes ops et dev. Cela a permis aux devs de gagner en autonomie sur certaines tâches comme la création d'une ressource et a permis d'avoir une documentation partagée sous forme de code (CLI-Driven Developer Experience - L'ingrédient secret d'une équipe alignée)
- Marseille et Bordeaux font partie des hubs de datacenter de la France grâce à leur proximité avec les points d'arrivée des câbles sous-marins. Mais l'arrivée massive des data center génère des conflits d'usage sur le foncier et l'électricité (La course à l’IA - La France risque-t-elle de devenir un "territoire servant"?)
Ces trois jours étaient riches en informations. Je suis très contente d'avoir pu y participer et d'avoir pu écouter les différents speakers et speakeuses.
Si vous en avez la possibilité, je vous invite à vous rendre à l'édition 2027. En attendant, je vous invite donc à regarder les replays disponibles sur la chaîne YouTube de la Devoxx France !