Less than a month to Devoxx Poland! 🇵🇱
Looking forward to be back on stage, this time talking about observability for AI workloads, and the new paradigm we need to adopt.

And of course I can't wait to catch up with the local gang. if you're around, DM me and let's catch up.

See you 17-19 June in beautiful Krakow.
#devoxx #devoxxPL #AI #observability

Understanding Prompt Injection - Techniques, Challenges, and Advanced Escalation

https://video.ut0pia.org/w/da5UiuCPfisAoCNFpvjRy6

Comment les vidéos Devoxx France sont préparées et mise en ligne sur YouTube

https://video.ut0pia.org/w/3YqPTq1RfsiciDzBRoGHCC

Je suis de retour du #devoxx 2026 à Paris, pleins de supers présentations, pleins de super discussions... 👍👍

mais hélas je n'ai pas repéré un seul lien vers des comptes mastodon sur les pages des présentateurs 😩

il va falloir évangéliser plus.

Retour sur Devoxx France 2026

https://litote.org/blog/billets/retour-sur-devoxx-france-2026/

Focus sur l'IA générative

#ia #Devoxx

[Devoxx] Tu te mets combien en responsive CSS ? Edition 2026

Jusqu’en 2008, il n’y avait pas besoin de responsive css, parce que les écrans avaient à peu près les mêmes formes. Mais en 2008, avec l’introduction de l’iPhone, on se retroue avec des écrans qui ont des formes très différentes.

En 2010, l’article Responsive Web Design invente la méthode, inspirée de l’architecture. L’idée, c’est de créer un design qui, sans être parfait partout, peut rester fonctionnel dans tous les écrans.

Allez, on commence

La page vide

Julien et Théo ont conçu un éditeur WYSIWYG pour montrer les différents rendus, et ils arrivent bien à afficher leur page blanche.

Le paragraphe

Pour afficher un paragraphe, ça peut être intéressant de limiter la taille du bloc pour qu’il ne prene pas tout l’écran, en donnant en plus une taille maximal. Mais attention, parce que pour l’accessibilité, il faut pouvoir supporter une grande taille. Donc pour ça, il faut passer à une unité basée sur la taille de la police, l’incroyable em.

Le jeu de morpion

C’est une belle grille 3×3, et on voit que sur les grands écrans ça semble bizarre. Et on passe à une width en vmin. Et il faut ajouter une taille minimale, ce qui se fait avec clamp. Les tailles d’écran, ça marche bien sur ordinateur, mais moins bien sur les téléphones pour lesquels des unités complémentaires ont été définies (lvh, svh, dvh). Et c’est utilisable sur la plupart des navigateurs (dont tous les navigateurs récents) !

L’image de fond

Ici, Théo va utiliser du responsive HTML avec une balise picture , l’img de base en mode par défaut, et différentes source selon la taille de l’écran. On peut aussi les écrans de résolution très différents en ajoutant des conditions dans l’attribut media. Et ça marche aussi avec les vidéos.

La documentation

On va faire une page de documentation classique avec trois colonnes.

Et pour l’instant, Julien et Théo ne nous ont pas parlé de media queries. Mais ça change maintenant !

Et il utilise encore une nouvelle unité : le fr. Et en combinant une media query et une grid, ça se fait très facilement.

Mais pourquoi on fait du mobile first ?

Généralement, il faut moins de CSS pour faire l’affichage mobile que pour faire l’affichage de bureau. Et si le design mobile rentre plus facilement sur un écran plus grand.

La galerie de photos

Ils vont faire maintenant une galerie de photos avec des miniatures adaptées à l’écran.

Pour ça, un display: flex, du contenu centré, et ça a l’air sympa. Mais il ya parfois des marges. Ca se comble avec flex-grow qui a l’inconvénient que la dernière ligne contient des images d’une taille incohérente.

Essayons autrement, avec une grid. Et en mettant un autofill, le nombre de colonnes s’adapte à la taille de l’écran, sauf dans certains cas.

La règle d’or chez les front, c’est que flex est plutôt bien adapté quand il faut manipuler une dimension, et grid plutôt adapté quand il faut manipuler deux dimensions.

La plateforme de contenu

C’est une espèce de youtube-like avec des présentations variables. Et pour les afficher, on va utiliser des container queries, qui vont modifier le rendu selon l’espace disponible pour le container. Et ils font des démos qui me font penser à un très vieil article Swing sur les « transmogrifying widgets ». Le résultat est en franchement spectaculaire en terme d’adaptabilité.

Dans les design systems, les container queries sont très utiles (voir par exemple le Karkinos Design System).

Ca vaut le coup de nommer les containers. On peut combiner les container queries et les media queries. En revanche, il faut éviter de trop s’en servir pour éviter l’effet sapin de Noël. Et il existe évidement des unités spécifiques au container qu’il vaut mieux utiliser avec parcimonie.

Le monde réel

Il faut maintenant adapter ces techniques au monde réel. Et utiliser ces techniques vous aidera beaucoup, parce que les agents IA sont incapables pour l’instant de les mettre en oeuvre correctement.

[Devoxx] Eloge de la simplicité

Pour l’orateur, si on pense à un logiciel qu’on déteste, c’est un logiciel professionnel. Parce que dans le monde de l’entreprise, il faut uniformiser. Et si on veut créer un peu de variété, il faut demander à un comité.

Les utilisateurs ne vont pas regarder les roadmaps, la seule chose qui compte, c’est le produit. Pour l’orateur, la définition d’un planning est quasiment une trahison des utilisateurs. Et c’est le quiproquo de l’agilité.

Parce que le but, c’était d’être plus simple. Mais aujourd’hui, on remplace des plannings tous les trois mois par des planning trimestriels. Et souvent les backlogs sont en fait simplement des plannings verticaux.

Le planning, c’est un amas d’informations qui sont inutiles aujourd’hui, et fausses demain. Le planning, c’est un imaginaire qui rassure, un doudou organisationnel. Au contraire, le backlog indique juste ce qu’il faut faire maintenant.

Les organisations qui s’appuient sur es plannings sont dans l’incertitude, mais elles ne le savent pas. Pour le speaker, la transformation agile embrasse l’incertitude.

Si on se concentre sur l’estimation des tâches, on constate que le monde de l’informatique est terriblement mauvais : on ne sait pas estimer le délai, et donc les coûts, ni l’adoption par les utilisateurs, et donc les gains. Ca fait que les estimations sont complètement farfelues. Et c’est comme ça que nous décidons ?! Et pourtant, nous sommes débordés par des nombres construits de manière fantaisiste.

On peut remplacer ces estimations par le fait de demander aux utilisateurs. Les conflits de priorisation se dissolvent par les rencontres avec les utilisateurs. Et les utilisateurs peuvent même proposer des solutions à leurs irritants.

Ca vaut mieux que la méthode qui consiste à réfléchir pour ne pas agir, ce qu’on fait avec les études. Il vaut mieux agir pour apprendre, en l’occurence en écoutant les retours des utilisateurs. C’est l’empathie qui nous fera agir sur les sujets les plus importants. Et pour maximiser le retour sur investissement, il faut aller vers la simplicité et l’amour.

La seule chose qui fait que les gens conservent les plannings, c’est le fait que les gens sont convaincus qu’ils ne peuvent pas fonctionner sans planning.

Le speaker est convaincu que les urgences peuvent aider à comprendre comment une organisation peut être efficace sans planning. Il faut savoir que les urgences sont étudiées scientifiquement dans l’objectif de minimiser le taux de mortalité. Ca marche avec un accueil administratif qui liste les nouveaux arrivants, enchaîné à un accueil infirmier qui priorise les patients. Quand on est patient, on ne sait jamais quand on sera soigné. Mais le maximum de vies sera sauvé, et les cas les plus graves seront forcément traités en premier. Les urgences sont totallement imprédictibles, et pourtant extrêmement efficaces.

Les plannings n’existent pas parce qu’il y a un enjeu, mais parce qu’on ne sait pas faire autrement.

Et ça marche aussi pour la synchronisation : les urgentistes envoient des patients en radiologie qui ont pourtant un planning, et ça marche grâce à la communication permanente.

Dans les organisations qui se basent sur un planning, l’adaptation est impossible.

En fait, il y a une alternative à l’agilité à l’échelle : l’agilité. Le problème, c’est que les gens cherchent à faire des plannings, même en étant agiles. En fait, le vrai défi, c’est de trouver comment travailler sans planning.

[Devoxx] Kubernetes et la JVM

Java sur K8s, c’est plein de préjugés : lent à démarrer, compliqué à exploiter, gourmand en ressources.

Pour commencer, on peut utiliser K8s sur le pote de dév avec des outils comme minikube, k3s, kind, ou flox (qui semble s’inspirer de nix, et permet de créer un environnement de développement reproductible).

Alain nous montre alors comment utiliser flox pour installer kind et démarrer un namespace. On peut même choisir une version spécifique de K8s.

Passons maintenant à la construction des images et aux bonnes pratiques :

• faire de petites images
• utiliser du multistage build
• utiliser Kaniko ou Jib qui optimisent la construction des images

Dans Kubernetes, il ne faut pas oublier d’alimenter les probes, parce que K8s envoie du trafic dès que l’image est démarrée. Et il ne faut pas mettre le même endpoint dans la liveness et la readiness. Pensez aussi à déclarer des requests et des limits pour éviter que le pod soit tué trop facilement.

Dans la suite de la démo, ils vont utiliser une application Java qui se connecte à la Chuck Norris API. Une fois l’application écrite, on peut la déployer dans kind avec un kind deploy docker-image

Son application démarre … en 37 secondes avec 0.2 vCPU, mais instantanément avec 1 vCPU.

Il faut aussi penser à gérer le shutdown hook pour que l’application s’arrête correctement.

Passons à la JVM. Dans cet outil incroyable, deux éléments sont intéressants dans notre cas :

• Le JIT qui améliore l’exécution, une fois que le démarrage est effectué, celui-ci pouvant être assez long. Une méthode est compilée nativement après 10.000 appels par un compilateur de niveau C1, et il sera par la suite optimisé encore plus.
• La gestion de mémoire, et en particulier le garbage collector. La JVM en fournit plusieurs, qui évoluent en performance avec les versions de la JVM. On sélectionne rarement le GC, parce que la JVM le fait automatiquement. C’est fait selon trois critères : throughput, empreinte mémoire, et latence.

Depuis Java 5, les ergonomics permettent d’auto-configurer la JVM selon le nombre de CPU ou d’autres facteurs. On peut néanmoins forcer les valeurs de ces paramètres. On peut aussi les lister, soit par une commande spécifique, soit dans les logs. Dans les ergonomics, il y a aussi le choix de la taille mémoire. Les valeurs par défaut sont bonnes pour les postes de dev, moins pour les environnements conteneurisés. Et de la même manière, ces ergonomics déterminent automatiquement le garbage collector. Et les contraintes de mémoire font que dans les conteneurs, on se retrouve souvent avec SerialGC (qui arrête l’application de temps en temps).

Passons maintenant à l’exécution du code Java dans K8s. Avant Java 10, les ergonomics récupéraient les informations de CPU et de RAM du noeud, et pas celles définies dans le conteneur. Après Java 10, on prend les informations du conteneur. Mais on peut les changer avec XX:MaxRAMPercentage pour lequel la bonne pratique est de mettre 75%.

La JVM a besoin de CPU avec certains pics. Et c’est pour ça que les applications Java deviennent très lentes quand la mémoire est limitée.

Et c’est pire pour la mémoire : si il n’y a pas assez de mémoire, ça tue le conteneur. (OutOfMemoryError par Java ou OOMKill par Kubernetes). Et attention, parce que la JVM n’a pas de mémoire que dans la heap, il y aussi le metaspace, les threads, et la mémoire native. Ca complique bien sûr l’évaluation de la mémoire nécessaire pour faire tourner un conteneur.

On peut améliorer le temps de démarrage de l’application avec différentes techniques. CDS (class data sharing) permet d’accélérer les démarrages successifs des applications. Ca s’appuie sur l’ahead of time compiling, issu des travaux du projet Leyden. On peut aussi utiliser GraalVM qui compile le code Java en code natif. Attention, parce que ça double la charge de test.

Pour finir, Alain nous montre comment compiler une application Java en natif. Le processus n’est pas immédiat, puisque GraalVM vérifie beaucoup de choses.

Pour conclure, Java et K8s sont deux technologies complexes qui, lorsqu’elles sont utilisées ensemble, nécessitent pas mal d’attention, une bonne coordination, et une bonne collaboration.

[Devoxx] Jujutsu, la cerise sur le git, oh !

Jujutsu est un outil de contrôle de source avec lequel on peut utiliser quand même les commandes Git.

Jujutsu n’utilise pas des commits, mais des refsets que jj sait mapper sur des commits Git.

Et Siegfried nous fait ensuite le tour des fonctionnalités de jj, qui sont assez proches de celles git : on peut commiter, on peut merger, et tout le reste, mais avec des éléments assez particuliers, comme par exemple les bookmarks (qui semblent être les branches).

La configuration de jj permet de créer des commandes personnelles, avec une grammaire qui semble bien sympathique.

La gestion des conflits est un peu plus intéressante, puisqu’elle est stockée dans les données du commit, et pas directement dans les fichiers (ce qui rend le conflit non bloquant, contrairement à Git).

jj dispose d’une commande absorb, qui permet en un commit de faire une espèce de git commit --amend, mais potentiellement sur plusieurs branches en même temps (et sur des commits plus anciens).

A noter qu’il n’y a pas à faire de jj add : jj prend toujours tous les fichiers du repository dans ses commits.

Quand on modifie un fichier dans un commit ancien, jj rebase automatiquement les commits basés sur celui qui a été modifié.

Pour apprendre, la documentation est très fournie. Steeve Klabnik a aussi écrit un tutorial. Et il y a aussi un jj-workshop. Et pour partager le code, https://tangled.org/ est une plateforme à la GitHub.

Par défaut, jj limite la taille des fichiers dans le repository à 1 Mb (mais c’est évidement configurable).

Siegfried a par ailleurs repris cette présentation dans un article bien plus complet, disponible sur son blog.