Mon premier Devoxx 2026 : 4 confs à ne pas rater et leurs takeaways

"Même pas le temps de dire bonjour, j'ai rendez-vous dans l'amphi bleu." 🎵

Ces paroles de la musique qui tournait dans les salles résument bien l'expérience Devoxx : dense, rythmée, sans temps mort. Des dizaines de conférences, des centaines de développeurs. Et pour moi, une première fois ✨.

Ce qui m'a frappée d'emblée, c'est l'ampleur de la chose : de grandes salles pensées pour accueillir des talks de haute volée, une organisation au millimètre, et une qualité de contenu qui était vraiment au rendez-vous.

Dans cette sélection, je te partage quatre conférences qui m'ont particulièrement marquée que je t'invite à aller voir. Pour chacune : une description de la conf, ce qui m'a accrochée, et un takeaway technique pour repartir directement avec quelque chose de concret, même si tu n'as pas le temps de regarder la rediffusion.

1. "Cache-moi si tu peux : patterns et pièges du cache en production" de Sébastien Lecacheur

"There are only two hard things in Computer Science: cache invalidation and naming things." – Phil Karlton

Si cette citation t'a fait sourire, c'est que tu est au bon endroit. Sébastien Lecacheur nous a donné dans sa conférence les clés pour s’en sortir avec ce problème compliqué

Il traite du cache, pas un détail d'implémentation, mais comme un vrai sujet d'architecture avec ses propres règles, ses pièges et ses décisions à assumer. En 45 minutes, il couvre à la fois les fondamentaux (ce qu'est un cache, comment ça fonctionne) et les situations concrètes où ça déraille : incohérences de données, comportements impossibles à reproduire, accidents en prod qui auraient pu être évités. Une conf dense mais très facile à écouter, qui donne des outils concrets pour ne plus improviser sur le sujet.

💡 Takeaway technique

Un cache, c’est un composant logiciel qui stocke temporairement des données pour accélérer leur accès. Son implémentation cache une vraie complexité de choix du pattern en fonction de notre besoin. Mettre en place un cache, c'est naviguer entre trois objectifs qui se tirent dessus :Performance : le cache doit répondre vite, c'est sa raison d'être.Fraîcheur : les données servies doivent être à jour, ou au moins, pas trop obsolètes.Simplicité : plus le système de cache est complexe à opérer, plus il devient une source de bugs en lui-même.

On ne peut pas tout avoir. Un cache performant et toujours frais sera difficile à opérer. Un cache simple et performant risque de servir des données obsolètes. Un cache frais et simple sera probablement lent.

Chaque choix de pattern est en réalité une réponse à cette tension : read-through, cache-aside, write-through, write-behind, prefetching. Chacun privilégie un équilibre différent entre ces trois axes. Sébastien Lecacheur les passe tous en revue pendant la conf, avec les cas d'usage qui vont avec.

Ce que j'en retiens surtout : le cache, c'est un outil qu'on ajoute souvent trop vite et qu'on comprend trop tard. Cette conf m'a donné envie de remettre à plat ma façon d'y réfléchir avant même d'en avoir besoin.

👉 Les slides sont déjà dispo sur speakerdeck.com/slecache si tu veux aller plus vite que la rediffusion.

2. "Production Troubleshooting : booster vos skills, une étude de cas" de William Montaz

Un incident réel chez Criteo comme fil conducteur : des jobs Spark qui produisent un problème de cohérence des données en pleine migration de datacenter. Mais William Montaz ne s'arrête pas à l'anecdote. Il s'en sert pour parler de quelque chose de plus universel : comment on mène vraiment une investigation quand on ne sait pas par où commencer.

La méthode qu'il présente s'applique à n'importe quel incident complexe. Et c'est là que ça devient vraiment utile.

💡 Takeaway technique

Quand quelque chose casse en prod, on a l'impression de chercher de façon rationnelle. En réalité, notre cerveau prend des raccourcis, et ces raccourcis font perdre un temps précieux. Quatre biais reviennent systématiquement :

Le biais de popularité : "Tout le monde utilise ce framework, ça peut pas venir de là." Cette confiance peut devenir un angle mort. Remettre en question ses outils doit faire partie du processus de base.

Le biais d'autorité : "Des gens plus expérimentés ont utilisé cette librairie sans trouver de bug." L'expérience des autres ne garantit rien dans ton contexte précis.

Le biais de confirmation : construire des tests qui cherchent à confirmer ce qu'on pense déjà, plutôt qu'à invalider l'hypothèse. C'est contre-intuitif mais décisif.

Le biais de disponibilité : aller vers la piste qui vient en tête en premier (souvent la dernière chose qu'on a touchée) plutôt que celle qui est la plus probable.

Ce qui m'a frappé, c'est de me reconnaître dans les biais décrits et de réaliser que je les avais déjà vécus sans les avoir nommés. Mettre des mots dessus, c'est déjà une façon de mieux les détecter la prochaine fois.

3. "De zéro à des milliards de traces, le tracing distribué chez Winamax" de Anthony Maffert & Nicolas Fidel

La conf Winamax, c'était dans le grand amphi bleu. Et ça envoyait fort : présence sur scène, stack impressionnante, chiffres qui donnent le vertige : 700 microservices, des milliards de traces à gérer au quotidien.

700 microservices, des pics de trafic imprévisibles les soirs de match, et l'impossibilité d'utiliser les outils SaaS du marché pour des raisons de confidentialité. Anthony Maffert & Nicolas Fidel racontent comment Winamax a construit sa propre stack d'observabilité from scratch, avec uniquement de l'open source, et comment ils ont réussi à la faire tenir à l'échelle. Ce qui est intéressant dans cette conf, c'est qu'on ne voit pas juste le résultat final, on comprend les contraintes qui ont dicté chaque choix, de l'instrumentation des services jusqu'au stockage des traces.

💡 Takeaway technique

OpenTelemetry, c'est un standard open source qui définit une façon uniforme de traiter des données d'observabilité. Il unifie trois types de signaux : les traces (le chemin d'une requête à travers les services), les métriques (des mesures agrégées dans le temps : latence, taux d'erreur, saturation) et les logs (les événements discrets).

Une stack d'observabilité complète, c'est quatre étapes qui s'enchaînent : la production des traces (chaque service génère des données sur ce qu'il fait), la collecte (un composant intermédiaire récupère, filtre et route ces données sans perdre en route), le stockage (les traces sont indexées pour pouvoir être requêtées rapidement, parfois sur des volumes de plusieurs téraoctets) et la recherche (être capable lorsqu’on a besoin d’une information de la retrouver rapidement dans tout notre amat de traces).

Chez Winamax, chacune de ces étapes a posé ses propres défis, et c'est précisément ce que la conf détaille.

L'observabilité à cette échelle, c'est autant une question de culture d'équipe que de stack technique. Le processus d'adoption, l'instrumentation progressive, tout ça compte autant que les outils choisis. On ne construit pas une stack d'observabilité pour autant de microservices du premier coup : on la fait grandir, et ça demande une vraie discipline collective.

Si le sujet te plait et que tu veux en apprendre encore plus je te recommande grandement la conférence d'Alexandre Moray et Florian Meuleman. C'est ma suggestion si tu veux approfondir ta compréhension ce que Winamax met en œuvre à grande échelle : ils reprennent les fondamentaux de l'observabilité, expliquent les concepts clairement, et illustrent tout ça avec des démos concrètes sur une app Java avec OpenTelemetry et Signoz. Les deux confs sont complémentaires : l'une pose les concepts, l'autre montre ce que ça donne quand on pousse le système à l'extrême.

4. "2 ans après, les devs n'ont pas disparu… du coup, l'IA ça sert à quoi ?" de Matthieu Vincent & Yann Gloriau

"Tu es développeur junior, pourquoi je t'embaucherais toi plutôt que d'utiliser une IA ?"

C'est le genre de question qu'on m'a déja posé en entretien. Le genre de question qui reste en tête. Alors forcément, cette conférence, je l'attendais.

Matthieu Vincent et Yann Gloriau arrivent avec une énergie de fou : intro en musique, beaucoup d'humour, beaucoup d'interactions entre eux. Le ton est léger. Le fond, lui, est plus sérieux. Deux ans après leur première conf sur le sujet, ils reviennent avec un bilan honnête : l'IA a changé beaucoup de choses, mais pas toujours celles qu'on espérait. Ils passent en revue ce qui fonctionne vraiment, ce qui déçoit, et les effets de bord qu'on n'avait pas anticipés. On peut soulever une question qui traverse le talk : est-ce qu'on garde le contrôle, ou est-ce qu'on le subit ?

💡 Takeaway technique

L'effet Dory. Un LLM ne garde pas en mémoire tout ce qu'on lui a dit. Il travaille avec une "fenêtre de contexte", c'est-à-dire une quantité limitée d'informations qu'il peut traiter à la fois. Trop d'informations dans cette fenêtre et il se noie, perd le fil, génère des réponses moins pertinentes. Pas assez, et il manque du contexte nécessaire pour être vraiment utile. Bien utiliser l'IA, c'est apprendre à gérer ça : donner les bonnes informations au bon moment, savoir quand repartir sur une conversation propre plutôt que de traîner un contexte alourdi. C'est une compétence qui s'apprend et qui fait une vraie différence.

La question des juniors. Si on ne leur apprend pas à travailler avec ces outils, quand le feront-ils ? Mais si on les laisse tout déléguer dès le départ, qu'est-ce qu'ils apprennent vraiment ? L'analogie avec le copier-coller Stack Overflow est juste : le problème n'était pas de copier, c'était de copier sans comprendre. Même combat avec l'IA.

Cette question d'entretien, elle m'a fait réfléchir. En tant que dev, et surtout en début de carrière, elle pousse à clarifier ce qu'on apporte vraiment : la communication, la méthodologie, la capacité à cadrer un problème, la tenue d'une prod... Autant des compétences et de tâches que l'IA ne peut pas faire, pour lesquelles le developpeur est indispensable.

Ce que cette conf m'a apporté, c'est surtout de la perspective. Le marché est encore mouvant : les prix changent, les technos évoluent, les usages se cherchent. Personne n'a toutes les réponses. Et quelque part, c'est rassurant : il y a encore de la place pour construire sa place intelligemment.

Conclusion

Le Devoxx, c'est un moment où on sort la tête du quotidien. On écoute des gens qui ont creusé leurs sujets vraiment loin et qui ont envie de le partager. On repart avec l'envie de faire pareil.

Ce qui m'a frappée, c'est l'énergie de l'endroit : une grande source de connaissances de haute voltige, mais aussi d'échanges, que ce soit sur la tech et sur l'humain. Voir ça pour la première fois, c'est une chose. Avoir déjà envie d'y retourner, c'en est une autre.

Un immense merci aux speakers pour la générosité avec laquelle ils partagent leur travail et leur expertise. Si un de ces sujets t'a donné envie d'en savoir plus, toutes les rediffusions seront disponibles sur la chaîne YouTube du Devoxx. Fonce ! Les confs valent vraiment le détour. 🚀