Cette Ă©dition spĂ©ciale de “La veille de Wittouck” liste les vidĂ©os de Devoxx France 2025 qui m’ont le plus intĂ©ressĂ©.

Parmi les vidĂ©os de la playlist, je vous ai concoctĂ© une sĂ©lection de 26 vidĂ©os que j’ai trouvĂ©es particuliĂšrement intĂ©ressantes. Mon astuce (pour ne pas y passer 300 heures) : je regarde les vidĂ©os en x2, et je ralentis sur les morceaux intĂ©ressants 😅

Je les ai classĂ©es selon les tags que j’utilise d’habitude, elles ne sont pas triĂ©s dans un ordre prĂ©cis.

Je n’ai aussi pas listĂ© les talks que j’avais dĂ©jĂ  mentionnĂ© dans mon article prĂ©cĂ©dent, je vous propose de les retrouver dans l’article DevOxx 2025 - Bilan, que j’ai mis Ă  jour avec les liens des vidĂ©os.

Bon visionnage !

🛜 Internet et Divers

Une confĂ©rence sur l’histoire du dĂ©veloppement des premiers jeux Pokemon, et du glitch qui permet de capturer Mew. Le speaker rentre dans le dĂ©tail des modifications de valeurs de variables tout au long de l’exĂ©cution du glitch. La confĂ©rence est hyper bien rĂ©alisĂ©e, avec des dĂ©mos dans le jeu !

Un talk autour de la gestion de la doc ! Le speaker donne les billes pour avoir une documentation de qualitĂ©, Ă  travers trois critĂšres : clartĂ©, pertinence et accessibilitĂ© (au sens “facile Ă  trouver”), et l’utilisation de revue de doc et de commentaires avec conventional comments.

La speakeuse y dĂ©construit les mythes des licornes, de la perfection qui est perçue de l’extĂ©rieur, l’illusion de l’agilitĂ©. Elle prĂ©sente les approches produit concrĂštes de quelques licornes comme Spotify ou AirBnb, et l’importance des mĂ©triques techniques et produit, des tests et de l’acceptation de l’Ă©chec.

“L’architecture, c’est le boulot de tout le monde”. Les speakers donnent quelques clĂ©s d’architecture Ă  destination des devs. Quelques tips simples comme “Ă©noncer clairement les problĂšmes” Ă  rĂ©soudre, et quels sont les quality attributes Ă  mesurer dans une bonne architecture : disponibilitĂ©, performance, etc. Ils prĂ©sentent aussi quelques points autour architecture monolithiques, modulaires, et des tradeoffs associĂ©s. Enfin, quelques points comme les ADR, les tests d’architecture et les principes de couplage et de cohĂ©sion.

“On se rend compte de la valeur de ses donnĂ©es personnelles le jour oĂč on les perd”. Denis donne quelques billes pour estimer un risque, et la stratĂ©gie “3-2-1”, et implĂ©menter cette stratĂ©gie avec un NAS (Network Attached Storage) et quelques services et logiciels.

Un Ledger implĂ©mente le stockage de comptes et de transactions. On retrouve les principes liĂ©s aux block-chains et cryptos, en particulier l’immutabilitĂ© des transactions. Le speaker prĂ©sente quelques cas concrets d’implĂ©mentation chez Doctolib sur la gestion des factures.

🔒 SĂ©curitĂ©

Le speaker prĂ©sente le fonctionnement de OIDC, les diffĂ©rents types de tokens, les scopes, et les flow clients et serveur, avec des dĂ©mos live. C’est Ă  voir pour tous les devs, front ou back !

On ne prĂ©sente plus l’OWASP (Open Worldwide Application Security Project) qui propose le ‘Top 10’ avec le listing des 10 risques de sĂ©curitĂ© les plus critiques. Le speaker prĂ©sente rapidement Dependency Track, Zed Attack Proxy et ModSecurity.

☕ Java

Une lib pour tester le contenu d’une base de donnĂ©es en Java. Je connaissais dĂ©jĂ  DbUnit sur ce use-case, qui Ă©tait un peu fastidieux Ă  utiliser. AssertJ-DB s’intĂšgre avec AssertJ, et semble plutĂŽt pratique d’utilisation, avec un apprentissage rapide. La killer feature est la possibilitĂ© de capturer les changements effectuĂ©s sur la base de donnĂ©es par le code.

Un talk qui explique le principe sous-jacent au fonctionnement des threads virtuels disponibles depuis Java 21, en particulier la gestion des scope et contextes d’exĂ©cution. L’API Continuation n’est pas sensĂ©e ĂȘtre utilisĂ©e en dehors des mĂ©canismes internes du JDK, mais dĂ©couvrir son fonctionnement permet de se rendre compte de la complexitĂ© qui se cache derriĂšre les threads virtuels. La dĂ©mo est incroyable, le speaker rĂ©implĂ©mente un Generator, et un VirtualThread !

Le speaker prĂ©sente plusieurs axes d’optimisation : AOT et CDS, allocation de threads aux JIT C1 et C2, CRaC, et des Ă©lĂ©ments autour de l’infrastructure Kubernetes et allocation de ressources. C’est assez basique, mais ce sont toujours des bons rappels. J’aurais nĂ©anmoins aimĂ© une dĂ©mo de CRaC, car on en voit rarement.

La lĂ©gende JM Doudoux prĂ©sente 34 formes de Hello World en Java, du fameux System.out.println("Hello World") dans une mĂ©thode main Ă  des moyens plus fous comme des blocs statiques, ou l’API Class-File pour gĂ©nĂ©rer dynamiquement du code.

L’API Gatherer vient complĂ©ter l’API Stream au niveau des opĂ©rations intermĂ©diaires, de la mĂȘme maniĂšre que l’API Collector complĂšte les opĂ©rations terminales. JosĂ© prĂ©sente en dĂ©tail le fonctionnement de l’API, et comment implĂ©menter son propre Gatherer, avec quelques exemples concrets.

☕ IA

Une des keynotes que j’ai manquĂ© sur cette Ă©dition. Dans la prĂ©sentation et la sĂ©ance de question/rĂ©ponses, Luc dĂ©construit certains mythes de l’IA : les vĂ©hicules autonomes de niveau 5 n’existeront jamais, tout comme les AGI (artificial general intelligence), les LLM sont l’Ă©volution du DeepLearning, les IA sont des outils spĂ©cialisĂ©s. Ses points de vue sont trĂšs tranchĂ©s et clairs, bien argumentĂ©s, mĂȘme dĂ©montrĂ©s et illustrĂ©s.

Des stratĂ©gies concrĂštes pour imposer Ă  une IA des standards de qualitĂ© issus du craftmanship. Ça passe par une approche de TDD, de test d’architecture et de maquettage, ces trois Ă©lĂ©ments Ă©tant passĂ©s au niveau du prompt de l’IA. L’approche semble efficace. Le plugin CLine qui est prĂ©sentĂ© affiche aussi le coĂ»t financier de chaque requĂȘte.

đŸ‘· DevOps

Les speakers dĂ©taillent l’ensemble des rĂšgles et Ă©tapes qu’ils ont intĂ©grĂ©s dans leur build gradle, avec une estimation du temps gagnĂ© par rapport au temps de build ajoutĂ©. Outre les rĂšgles de formatage, et de validation d’architecture qu’on retrouve souvent, je retiens 2 bonnes idĂ©es : le contrĂŽle de l’OpenApi gĂ©nĂ©rĂ© (avec un diff automatisĂ©) avec openapidiff, la suppression des dĂ©pendances inutiles avec du code inspirĂ© de maven-dependency-analyser. En dĂ©finitive, ajouter ces Ă©tapes au build plutĂŽt qu’Ă  la CI suit les approches de type shift-left, comme on peut aussi les observer avec des outils comme Dagger.

Les flaky tests, qui Ă©chouent parfois sont la bĂȘte noire des pipelines. On relance le pipeline en croisant les doigts đŸ€ž. Docker a dĂ©veloppĂ© un outil interne pour dĂ©tecter et marquer les tests flaky, afin de pouvoir les ignorer dans les pipelines. L’impact observĂ© est de 300 PR mergĂ©es du premier coup en plus / mois et 1 an de compute Ă©conomisĂ© / mois.

Un tour d’horizon des diffĂ©rents moyens pour avoir un environnement de travail dĂ©porté : DevContainers, GitPod, JetBrains Gateway, et Cloud Workstation de Google.

Le speaker prĂ©sente le Deterministic Simulation Testing. Cela passe par du property-based testing, l’injection de chaos avec des mocks qui ajoutent des temps de latence alĂ©atoires. Un test est associĂ© Ă  une seed qui permettra de rejouer les tests. C’est intĂ©ressant sur le principe, mais ça manque d’exemples concrets Ă  mon sens.

Burrito est un opĂ©rateur Kubernetes qui exĂ©cute des modules Terraform et s’intĂšgre avec ArgoCD dans une approche GitOps. Il permet de rĂ©concilier en continu des modules, corriger le drift, et fournit une interface pour suivre les dĂ©ploiements. C’est plutĂŽt intĂ©ressant, j’ai eu une approche similaire quand j’ai dĂ©veloppĂ© Gaia il y a quelques annĂ©es.

☞ Kubernetes

SlimFaas est un systĂšme de FaaS pour Kubernetes. La dĂ©mo est plutĂŽt impressionnante, en quelques minutes, le systĂšme est installĂ© et utilisable. Les intĂ©rĂȘts principaux sont la capacitĂ© Ă  scale les applications Ă  0 et la possibilitĂ© de scheduler le dĂ©marrage et l’extinction des pods.

🐋 Docker

Un talk interactif ! Le format est original ! AprÚs chaque question, les speakeuses donnent une petite explication, avec une démo. On découvre des détails autour du fonctionnement des images et registries, des architectures, des SBOM

On dĂ©couvre les fonctionnalitĂ©s de Docker Desktop. La vue du dĂ©tail des images et des vulnĂ©rabilitĂ©s est plutĂŽt pratique, ainsi que l’historique des builds et l’exploration du filesystem d’un container. Les speakeurs prĂ©sentent aussi quelques nouveautĂ©s de Docker Compose, l’option --watch est intĂ©ressante, ainsi que le push/pull de compose files sur les registries OCI.

🐧 Linux

Le use case est d’un autre level. Temps de rĂ©ponse moyen attendu Ă  1 ms. 70 milliard de records. 18M req/secondes. Utilisation optimisĂ©e du page cache linux. Utilisation de disques en raw (sans filesystem). On y dĂ©couvre aussi les challenges rencontrĂ©s en production dans le volet REX.

Un peu d’histoire autour des Terminal User Interface, ainsi qu’une dĂ©mo de dĂ©veloppement d’un CLI TUI en Python, Golang ou Rust. Assez inspirant de voir comment il est facile d’implĂ©menter de tels outils avec des librairies faciles d’accĂšs.


La prochaine publication est prĂ©vue autour du đŸ—“ïž 13 juin 2025