
Cette annĂ©e encore (comme les deux annĂ©es prĂ©cĂ©dentes), j’Ă©tais prĂ©sent Ă Devoxx France.
Cette fois-ci, pas de talk pour moi, j’Ă©tais donc en “simple visite”, ce qui enlĂšve un Ă©lĂ©ment de stress (ce n’est pas plus mal non plus).
J’ai donc bien profitĂ© des trois jours, entre les diffĂ©rents talks, les discussions animĂ©es, les rencontres inattendues. Je vous raconte tout ça.
Mercredi
Je suis arrivĂ© mercredi matin, vers 9h. AprĂšs avoir dĂ©posĂ© mes affaires au vestiaire, et avec les keynotes dĂ©jĂ en cours, j’en ai profitĂ© pour faire un tour rapide dans le hall des exposants, et pour retrouver mon associĂ© Romain et mes collĂšgues techs de chez EkitĂ© (au nombre de six) qui Ă©taient lĂ uniquement pour la journĂ©e du mercredi. On s’est vite sĂ©parĂ©s pour aller ensuite voir les sujets qui nous intĂ©ressaient, mais on a pu se recroiser tout au long de la journĂ©e et faire une petite photo de groupe dans la soirĂ©e.
J’ai aussi passĂ© beaucoup de temps Ă discuter sur les stands (surtout Clever Cloud đ) et avec les personnĂ©es croisĂ©es dans les couloirs, je suis aussi parti un peu tĂŽt pour pouvoir dĂ©poser mes affaires Ă l’hĂŽtel et retrouver un pote sur Paris. Donc, je n’ai pas vu beaucoup de talks ce mercredi.
G1, ZGC, Shenandoah, … avec tous ces GCs dans Java, je choisis lequel ? - Antoine Dessaigne

Vu la file d’attente au niveau de l’amphi bleu pour aller assister au talk de Julien Topçu et Josian Chevalier, je me suis donc rabattu sur le talk d’Antoine Dessaigne, qui nous a expliquĂ© l’histoire et le fonctionnement des GC en Java, et nous a donnĂ© des pistes pour nous aider au choix.
J’avais dĂ©jĂ vu une version vidĂ©o de ce talk, Antoine m’avait dĂ©mandĂ© mon avis et je lui avais partagĂ© les choses que j’avais aimĂ©es, et je lui avais donnĂ© quelques axes d’amĂ©lioration (en toute simplicitĂ©). Je trouve qu’il a bien amĂ©liorĂ© le talk, qui est trĂšs fluide, et aussi trĂšs visuel. Les collĂšgues que j’ai emmenĂ©s avec moi sur ce talk ont eu l’air d’apprĂ©cier aussi l’aspect pĂ©dagogique.
Antoine nous a donc présenté le fonctionnement de la mémoire en Java, les différents GC, et quelques points importants pour nous aider à choisir.
Le GC Epsilon m’a bien plu, et a surpris l’audience : il ne fait pas de garbage collection, uniquement de l’allocation de mĂ©moire. Il faut que je pense Ă l’utiliser dans mes CLI.
TamboUI : making 2026 the Year of Java in the Terminal - Cédric Champeau - Max Rydahl Andersen

Plus tard, j’ai assistĂ© Ă la prĂ©sentation de Tamboui. Je suis allĂ© voir ce talk puisque j’en prĂ©pare un sur les environnements shell pour une future confĂ©rence. C’Ă©tait l’occasion de voir dans quelle mesure je pourrai me servir de cette librairie pour me coder un petit outil si jamais j’en ai le besoin. Le talk Ă©tait en anglais, j’ai eu un peu de mal Ă suivre certaines parties, mais au global, c’Ă©tait plutĂŽt impressionnant.
L’outil est complet, et propose des widgets et composants utilisables directement. La bonne surprise est le modĂšle de programmation, qui propose aussi bien de travailler trĂšs bas niveau (rendu des “cellules” du shell), ou trĂšs haut niveau (composant). Il est possible d’afficher des images en haute rĂ©solution, des vidĂ©os et d’intĂ©ragir avec la souris assez facilement, c’est bluffant.
Chose intĂ©ressante, le facteur limitant de performances n’est pas Java, mais les I/O que peut accepter le shell. C’est clairement overkill de rafraichir le shell Ă 60 ou 120 FPS, mais c’est possible.
HTTP/3 : 37 ans dâhistoire du protocole HTTP - Chris Navas

Retour sur l’histoire du protocole HTTP, et de ses Ă©volutions rĂ©centes, HTTP/2 (qui date dĂ©jĂ de 2014) et HTTP/3 qui date de 2022.
Alors que HTTP 1.1 et 2 reposaient sur TCP, HTTP/3 reposent sur UDP. La promesse est une meilleure utilisation du multiplexage, pour transmettre plusieurs documents en parallÚle, sans avoir le phénomÚne de head-of-line blocking lié à TCP et des packets perdus.
Le speaker parle aussi de l’Ă©tablissement d’une connexion sĂ©curisĂ©e immĂ©diate, sans “round-trip” : QUIC comporte une espĂšce de cache TLS, qui permet d’envoyer immĂ©diatement un paquet de donnĂ©es si on a dĂ©jĂ effectuĂ© une connexion au serveur.
Le taux d’adoption de HTTP/3 est dĂ©jĂ important (prĂšs de 20% si ma mĂ©moire est bonne). Mais on voit que ce sont les adopteurs de HTTP/2 qui ont basculĂ© en version 3 surtout.
Le fait que HTTP/3 est supportĂ© par les CDN principaux (des clouds US) doit aider. Attention cependant, le speaker rappelle que les CDN “coupent” le traffic HTTP/3 et que le traffic interne reste souvent en HTTP/1. L’intĂ©rĂȘt est donc plus faible.
Jeudi
Jeudi, je suis arrivĂ© vers 8h30, et j’ai pu entrer dans l’amphi bleu (parmi les derniers, merci Fanny) pour assister aux deux keynotes.
Comme c’Ă©tait mon premier passage dans l’amphi bleu, c’Ă©tait aussi ma premiĂšre dĂ©couverte des vidĂ©os d’introduction Ă©tendues pour cet amphi. Les “publicitĂ©s” refaites avec les mascottes robotiques de cette Ă©dition ont l’air de bien avoir amusĂ© l’amphi.
Keynote - Le dĂ©veloppeur face Ă l’IA : du prototypage rapide Ă la fin des intermĂ©diaires ? - Nicolas GreniĂ©

La premiĂšre Keynote parlait du vibe coding. Le speaker m’a trigger quand il a dit qu’un dev perdait son temps Ă choisir sa stack (je n’aime pas l’idĂ©e de dĂ©lĂ©guer un choix avec ses consĂ©quences Ă une IA), on comprend plus tard que l’usage qu’il prĂŽne est surtout autour du prototypage.
Je retiens surtout la question d’une personne du public : “On a chiffrĂ© 500 jours, et le POC vibe codĂ© a Ă©tĂ© fait en 5, comment on fait pour justifier les 495 jours d’Ă©cart ?”. La rĂ©ponse du speaker : “Tes 495 jours servent Ă réécrire la merde qui a Ă©tĂ© gĂ©nĂ©rĂ©e par l’IA”.
La conclusion semble bien ĂȘtre que l’IA est cantonnĂ©e aux POCs et aux projets persos dans cette vision.
Keynote - LâIA sur le terrain : lâhumain au cĆur de la valeur - Marjory Canonne

La deuxiĂšme keynote sentait bon le sapin (dans le bon sens). La speakeuse nous a Ă©galement parlĂ© du vibe coding et des opportunitĂ©s d’expĂ©rimentation que ça apporte, en insistant aussi sur les Ă©tapes qui suivent, architecture, sĂ©curitĂ©.
Le message le plus important de cette keynote est de repartir des besoins rĂ©els, et pas de la techno. L’IA n’est pas une fin en soi.
Julien - Rabatteur de speakers
Cette annĂ©e, mon associĂ© Romain avait un badge “Presse” offert par les orgas de Devoxx, et enregistrait ses podcasts au niveau de la zone speaker. Pour lui filer un coup de main, j’ai proposĂ© aux speakers que je croisais de passer le voir pour se faire interviewer. Merci Ă celles et ceux qui ont bien voulu se prĂȘter Ă l’exercice.

J’en ai profitĂ© pour assister Ă l’interview d’Olivier Poncet, que je croise avec plaisir Ă chaque confĂ©rence (il est dĂ©cidĂ©ment partout). J’ai trouvĂ© intĂ©ressante la discussion entre Olivier et Romain, principalement parce que j’ai dĂ©couvert qu’Olivier s’organisait d’une maniĂšre similaire Ă la mienne : il a sanctuarisĂ© un job au 4/5Ăšme pour pouvoir travailler sur ses confs, ses vidĂ©os, et les cours qu’il donne.
Bye bye Vendor Lock-in : Standardisez vos Feature Flags avec OpenFeature - Thomas Poignant

Bien que je connaissais dĂ©jĂ OpenFeature (je l’ai dĂ©couvert il y a environ 2 ans), je voulais voir ce talk pour voir comment le projet avait avancĂ©.
OpenFeature est maintenant en phase Incubating Ă la CNCF, ce qui montre une belle maturitĂ©. Les providers disponibles sont nombreux, et j’apprends aussi qu’un provider a dĂ©cidĂ© de ne pas dĂ©velopper son propre SDK mais uniquement un provider OpenFeature, ce qui est un excellent signal pour ce projet. J’ai aussi dĂ©couvert l’intĂ©gration avec OpenTelemetry et les hooks, qui ont l’air plutĂŽt pratiques.
Une question reste en suspens pour moi, mon voisin de gauche (il se reconnaitra) a tendance Ă utiliser les features flags avec un contexte attachĂ© pour implĂ©menter du RBAC, bonne idĂ©e ou pas ? On ne le saura peut-ĂȘtre jamais đ
Silence is Coming: Survivre au chaos dans une archi événementielle distribuée - Jounad Tourvieille - Flora Njofang

Je suis passĂ© voir ce talk pour soutienir Flora, qui avait participĂ© au tremplin des speakers organisĂ© par Cloud Nord et DevLille l’annĂ©e derniĂšre. C’Ă©tait donc l’occasion d’aller l’encourager.
Ici, le sujet n’est pas technique. Ce REX parle de communication. L’outil proposĂ© pour rĂ©pondre aux enjeux de la synchronisation des Ă©quipes est C4 Model. Les diffĂ©rents niveaux de reprĂ©sentation s’adressent Ă des profils diffĂ©rents, et les utiliser permet d’avoir une vision partagĂ©e. Je connaissais dĂ©jĂ les approches “as-code” de C4 avec PlantUML et Structurizr. Pas de surprise sur les outils, mais des bonnes idĂ©es organisationnelles surtout.
Parmi les bonnes idĂ©es que je retiens : poser une gouvernance claire sur la responsabilitĂ© de la mise Ă jour des schĂ©mas : les architectes responsables du niveau C1, les tech leads C2 et C3, les devs le niveau C4 ; partager les modĂšles et schĂ©mas dans un repo unique Ă l’entreprise ; et construire une arborescence de fichiers en miroir Ă l’organisation de l’entreprise pour mieux s’y retrouver.
Se retourner la tĂȘte avec les quiz Java de JosĂ© et Jean-Michel - JosĂ© Paumard - Jean-Michel Doudoux

Probablement un des talks que j’ai prĂ©fĂ©rĂ© sur ces 3 jours.
Dans un format hyper original, Jean-Michel Doudoux (qu’on ne prĂ©sente plus), nous pose quelques-unes de ses questions de QCM, toujours pleines de subtilitĂ©s et de petits piĂšges sur mon langage pref : Java. Le public est invitĂ© Ă y rĂ©pondre avec son smartphone (750 participants en live !). Et JosĂ© se prĂȘte Ă©galement Ă l’exercice sur scĂšne.
Il Ă©tait amusant de voir JosĂ© dĂ©couvrir les questions, et formuler sa rĂ©ponse. En parallĂšle, le public discute, entre voisins, on se dit “je pense que c’est la B, tu dis quoi ? Attends, là ça compile pas ce code ?”. L’amphi bleu Ă©tait bien vivant sur cette session.
Il Ă©tait aussi amusant de voir JosĂ© tomber dans certains piĂšges (et emmener le public avec lui). CouplĂ© aux explications de Jean-Michel, avec l’exĂ©cution du code, c’Ă©tait un quiz trĂšs dynamique. Un format qui devrait replaire Ă l’avenir.
Jujutsu, la cerise sur le git, oh ! - Siegfried Ehret

Tout en dĂ©mo, Siegfried nous prĂ©sente l’utilisation de Jujutsu (jj) sur un projet exemple. Les premiĂšres commandes sont simples, la gestion du rebase est bluffante, la compatibilitĂ© avec Git permet d’utiliser JJ en co-localisation avec Git, ce qui est aussi intĂ©ressant.
La conclusion de Seigfried m’a fait sourire : ne demandez pas Ă votre manager si vous pouvez installer JJ, vu que ça marche avec Git, ça ne pose pas de problĂšme.
Ă tester.
Mise : un multi-outil pour votre poste de Dev & Ops - Rémi VerchÚre

Suite Ă mon article sur l’outil mise, j’avais un peu Ă©changĂ© avec RĂ©mi sur cet outil que j’utilise au quotidien et qu’il utilisait dĂ©jĂ un peu.
Dans nos discussions, il m’avait aussi notifiĂ© qu’il soumettait cette conf, et m’avait envoyĂ© ses slides en avant-premiĂšre, pour me partager ce qu’il allait prĂ©senter.
Il est allĂ© vraiment loin, tout y passe (ou presque) : les outils, les variables d’environnement, les tasks, l’intĂ©gration avec fnox. C’Ă©tait trĂšs dense pour un talk de 30 minutes !
Cas intĂ©ressant, il nous explique aussi comment utiliser mise dans une CI pour unifier le tooling, comment sĂ©curiser la rĂ©cupĂ©ration des tools avec le mode “paranoid”. Il nous a aussi prĂ©sentĂ© son usage autour du switch de contexte k8s pour ses diffĂ©rents environnements avec des hooks.
Je pensais connaitre le sujet, j’ai quand mĂȘme appris des trucs. RĂ©mi a aussi citĂ© mon article dans les ressources intĂ©ressantes sur le sujet. C’est pas bon pour mes chevilles ça đ
La soirée au calme
C’Ă©tait une journĂ©e assez chargĂ©e somme-toute. Je me suis eclipsĂ© aprĂšs le talk de RĂ©mi pour aller partager un verre avec Romain, et dĂ©briefer de sa journĂ©e d’enregistrements, en me disant que j’allais peut-ĂȘtre repasser Ă la soirĂ©e ensuite.
Mais ma fatigue en a décidé autrement.
Vendredi
Dernier jour, la fatigue s’accumule, les jambes commencent aussi Ă peser. J’ai dĂ©cidĂ© pour ne pas m’Ă©puiser d’allĂ©ger ma journĂ©e, et d’aller voir uniquement les quelques talks que je ne voulais pas manquer. Je devais aussi passer sur certains stands, pour avoir des discussions plus poussĂ©es sur certains produits que je veux tester.
Mon train retour Ă©tait prĂ©vu Ă 17h45, j’avais dĂ©jĂ renoncĂ©, en prenant mon billet retour, aux derniers tools-in-action de la journĂ©e. Je sais que j’aurai des talks Ă aller voir en vidĂ©o pour complĂ©ter mon Devoxx.
J’avais aussi les yeux trĂšs fatiguĂ©s (c’est encore le cas), vous m’avez probablement vu avec mes lunettes teintĂ©es toute la journĂ©e.
Les Value Types ne sont pas âomplexes - ClĂ©ment de Tastes - RĂ©mi Forax

On commence par une présentation des algorithmes de Mandelbrot, qui produit les fractales qui sont toujours impressionnantes.
Une formule mathĂ©matique, s’appuyant sur des nombres complexes (iÂČ=-1) est implĂ©mentĂ©e avec des records. Et lĂ , les performances s’effondrent (x15).
Les value types, portĂ©es par le projet Valhalla depuis maintenant plusieurs annĂ©es (2014 !), permettent de dĂ©clarer des classes sans identitĂ© (sans pointeur) et sont directement stockĂ©es “Ă plat” sur la stack ou la heap. Les optimisations de performance sont alors folles : le CPU peut charger directement les valeurs depuis la stack, sans passer de temps Ă rĂ©soudre des adresses mĂ©moire. Une contrainte est alors ajoutĂ©e : l’immutabilitĂ© des champs (je ne suis pas certain d’en avoir compris la raison). Quelques exemples de code ont Ă©tĂ© partagĂ©s, et les performances semblent au rendez-vous.
L’implĂ©mentation du nouveau mot-clĂ© value est uniquement portĂ©e par la JVM et pas par le compilateur.
Le talk se conclut rapidement (ils étaient un peu juste sur le timing a priori), en évoquant une fonctionnalité aussi attendue poussée par Valhalla : la possibilité de déclarer un type null-restricted avec le marqueur bang !.
Cette fonctionnalitĂ© permet Ă Valhalla d’Ă©viter de devoir gĂ©rer un bit marqueur pour indiquer qu’un champ d’un value type est null, autrement cette obligation a un impact sur la mĂ©moire consommĂ©e et sur l’efficacitĂ© de la rĂ©cupĂ©ration des valeurs (entre la RAM et le CPU).
On voit aussi un screenshot de la PR du projet : +206,994 -40,537, sur un unique commit (probablement squashĂ©), la PR des enfers, qui montre l’impact de la fonctionnalitĂ© sur le code de la JVM.
Une inquiĂ©tude de mon cĂŽtĂ©, que ce mot clĂ© ne soit pas bien compris (qui connait volatile ?), et qu’il soit mis systĂ©matiquement sur toutes les classes sans comprendre les impacts (dont je ne suis pas certain d’avoir tous compris moi-mĂȘme).
Et si écrire du SQL redevenait cool ? - Sebastien Ferrer

Je suis passé voir ce lunch talk en soutien au pote Sébastien.
Il nous a alors rĂ©pĂ©tĂ© plusieurs fois “J’aime le SQL” (oui SĂ©bastien, tu nous l’avais dĂ©jĂ dit ahah).
Il nous explique alors les avantages et inconvĂ©nients d’utiliser un ORM, et nous prĂ©sente une alternative originale : sqlc.
sqlc est un CLI qui prend des fichiers .sql (schĂ©mas, migrations, requĂȘtes), pour gĂ©nĂ©rer du code dans le langage de notre choix (SĂ©bastien a illustrĂ© avec du Go). Les accĂšs Ă la base de donnĂ©es sont donc SQL-first, ce qui est intĂ©ressant pour s’assurer de la bonne maitrise des requĂȘtes jouĂ©es. Le typage des diffĂ©rentes structures et fonctions gĂ©nĂ©rĂ©es par l’outil, Ă partir du schĂ©ma et des champs des requĂȘtes est aussi intĂ©ressant : on sait Ă la compilation que le code correspondra bien au schĂ©ma.
Point nĂ©gatif, les requĂȘtes dynamiques ne peuvent pas ĂȘtre supportĂ©es.
J’ai bien envie d’aller regarder comment l’outil gĂ©nĂšre du code en Java.
Kubernetes et la JVM - Alain Regnier - Jean Michel Doudoux

Alain nous présente certains concepts de Kubernetes, de mon point de vue plutÎt classiques, principalement les request/limits et les probes. Jean Michel revient ensuite sur le fonctionnement de la JVM et nous explique les impacts de ces concepts k8s sur la JVM.
Les parties les plus intĂ©ressantes : les ergonomics de la JVM, qui dĂ©cident au dĂ©marrage d’un certain nombre de paramĂštres, comme le GC sĂ©lectionnĂ©, la taille de la Heap, et le nombre de threads allouĂ©s au ForkJoinPool et aux carrier threads des threads virtuels.
Les prĂ©cos sont celles auxquelles je m’attendais : allouer 75% de la RAM dispo Ă la heap avec MaxRamPercentage (et augmenter cette valeur avec la taille de la RAM). Faire attention au choix du GC, et faire attention au throttle de CPU, qui a tendance Ă dĂ©truire les performances de la JVM.
Je portais un discours similaire il y a déjà quelques années avec mon BBL sur Spring Boot, Docker et Kubernetes.
Il nous rappelle aussi que la compilation native n’est pas magique, puisque les optimisations C2 ne sont jamais faites, donc un binaire natif peut ĂȘtre moins performant qu’une JVM sur la durĂ©e. MĂȘme combat pour les AOT cache ou CRAC, qui ne marchent pas dans tous les cas.
J’ai par contre dĂ©couvert que la JVM pouvait logger les ergonomics Ă son dĂ©marrage, ce qui est bien pratique.
Ăloge de la simplicitĂ© - FrĂ©dĂ©ric LeguĂ©dois

Dans un one-man-show dont il a le secret, FrĂ©dĂ©ric nous propose de rĂ©flĂ©chir Ă l’agilitĂ© telle qu’elle est pratiquĂ©e en entreprise.
Des outils qu’on n’aime pas, mais qu’on conserve par souci d’unification, des plannings inutiles, des calculs de ROI farfelus. Chercher Ă prĂ©dire le futur avec un planning est inutile, mais on continue de le faire, de synchroniser des plannings. Tout ça est du temps perdu.
L’analogie avec le fonctionnement des urgences, qu’il illustre avec 2 boites Ă chaussures, est rĂ©vĂ©latrice : dans un hĂŽpital, l’inconnu est partout (arrivĂ©e de patients, dĂ©gradation de leur Ă©tat de santĂ© dans la salle d’attente, durĂ©e de la consultation dans les box), et le systĂšme tient avec des rĂšgles de tri et de priorisation simples. Tout ça, sans l’ombre d’un Scrum Master ni d’un planning.
Mais nous, IT, faisons des plannings et rĂ©unions, pour paraĂźtre sĂ©rieux. Ce qui nous ralentit, et ne permet pas d’aider nos utilisateurs. Notre planning ne les intĂ©resse pas, puisque par dĂ©finition, c’est un mensonge, au mieux une prĂ©diction Ă laquelle on pourra appliquer un facteur 2 (une bonne estimation donc), ou un facteur 10 (une estimation normale).
Un bon retour aux sources, un de mes talks prĂ©fĂ©rĂ©s de cette Ă©dition. Le public de l’amphi bleu a apprĂ©ciĂ©, et beaucoup ri aux situations mises en avant.
C’Ă©tait trĂšs théùtral Ă©galement. Une belle perf d’orateur, avec une occupation de toute la scĂšne, des temps de pause, de la rĂ©pĂ©tition. Ce talk est aussi trĂšs inspirant sur cet aspect technique.
Retour Ă Lille
Ă la sortie de ce talk, je me suis dirigĂ© vers le vestiaire pour rĂ©cupĂ©rer mes affaires et me mettre en route transquillement. Puis je suis parti, avec une petite heure de marge sur l’heure de mon train pour ĂȘtre safe.
Pour moi, cette Ă©dition de Devoxx Ă©tait “pĂ©pouze” comme je l’ai dit plusieurs fois. Ne pas avoir de talk enlĂšve quand mĂȘme beaucoup de stress, j’ai pu pas mal profiter des talks et des discussions avec tout celles et ceux que j’ai eu la chance de croiser.
J’ai gardĂ© de cĂŽtĂ© quelques talks que j’ai zappĂ© (fatigue, discussion, ou conflit de crĂ©neau), je regarderai les vidĂ©os lors de leur sortie (en gĂ©nĂ©ral, elles sont publiĂ©es rapidement, souvent dĂ©but mai), et je les partagerai au fil de l’eau avec ma veille habituelle.
Ăa reste quand mĂȘme des journĂ©es intenses et fatiguantes, aussi bien physiquement : on marche beaucoup, on reste souvent debout Ă discuter aussi ; que mentalement : on ingĂšre beaucoup de connaissances dans un temps trĂšs rĂ©duit sur des thĂšmes trĂšs diffĂ©rents.
Les salariĂ©s de EkitĂ© Ă©taient prĂ©sents uniquement le mercredi, mais j’ai l’impression qu’ils ont passĂ© une bonne journĂ©e Ă©galement. Romain avait aussi l’air content de ses enregistrements de podcasts et de ses rencontres.

Bisous aux personnes que j’ai croisĂ© (sans ordre particulier) : LoĂŻc, Olivier, Fanny, SĂ©bastien, Julien (x3), Renaud, Matthieu, Nicolas (x2), Horacio, JĂ©rĂŽme, Denis, Quentin, StĂ©phane, Guillaume (x2), David, François (x2), Flora, RĂ©mi, Estelle, AurĂ©lie, Laurent, Nathan, et probablement plein d’autres que j’ai juste saluĂ© d’un coucou de loin ou d’une tape sur l’Ă©paule.
Merci aux orgas, merci aux polos rouges (vous ĂȘtes toutes et tous gĂ©niaux). Merci aux sponsors. Bravo aux speakeuses et speakers. C’Ă©tait une belle Ă©dition.
Vivement l’annĂ©e prochaine (pour jouer Ă Factorio dans l’amphi bleu ?).