Planning BreizhC@mp 26

L'IA générative ne se contente pas de bousculer nos outils ; elle redéfinit l'architecture même de notre pensée. En quelques mois, nous avons basculé du plaisir de l'écriture à une posture de supervision permanente. Mais cette accélération a un prix que nous ressentons chaque jour : le plaisir du craft qui s'efface, des compétences qui risquent de s'atrophier faute de friction et la charge cognitive d'un métier devenu gestion de flux. À travers nos deux regards, nous vous proposons une exploration lucide de cette transition. Nous chercherons ensemble comment continuer à aimer ce métier quand l'IA en modifie jusqu’à l’essence, et comment ancrer durablement nos savoirs dans un monde de raccourcis permanents. Notre ambition est de partager avec vous des pistes pour rester des artisan·es aux commandes, et non de simples opérateur·ices.

Fini les listes de mots de passe à retenir et les oublis stressants ! Grâce aux passkeys, il devient possible de se connecter de façon sûre et rapide, sans compromis sur la sécurité. Cette conférence explique simplement ce que sont les passkeys et comment différents scénarios de passkeys fonctionnent. Au programme : une présentation des standards derrière les passkeys et des concepts techniques fondamentaux, ainsi que des exemples concrets pour comprendre le fonctionnement de plusieurs types d'implémentation des passkeys (clé matérielle YubiKey, téléphone, Windows Hello…), accompagnés de démonstrations. Vous découvrirez les points forts de ces technologies (simplicité d’usage, robustesse face au phishing…), les contextes les plus adaptés à chaque type de passkey, mais aussi leurs limites et les questions à se poser avant de les adopter. Rejoignez-nous pour entrevoir un quotidien numérique plus simple, sans avoir à jongler avec des mots de passe !

Envie de découvrir un framework qui démarre en un éclair, consomme trois fois rien et simplifie la vie des développeurs de microservices ? Bienvenue dans cet atelier 100% pratique consacré à Micronaut, le framework JVM pensé pour la performance, la modularité… et la sérénité en production. Pendant deux heures, nous construirons une application complète intégrant plusieurs interfaces : - une API REST, - une consommation/production Kafka, - une persistence via base de données, Nous plongerons ensuite dans la réalité du terrain : 👉 quelles difficultés rencontre‑t‑on lorsqu’on vient de frameworks plus classiques comme Spring ? 👉 pourquoi certaines habitudes ne fonctionnent pas ici ? 👉 quelles limitations et pièges faut‑il anticiper ? 👉 et surtout : en quoi les choix techniques de Micronaut changent‑ils la donne (performance, GraalVM, légèreté, prédictibilité…) ? Cet atelier s’adresse autant aux curieux qu’aux développeurs expérimentés souhaitant se faire un avis sur Micronaut… et si cela pourrait devenir un allié de choix dans leurs futures architectures. Venez les mains sur le clavier : on code, on teste, on compare, et on repart avec une application fonctionnelle et un regard neuf sur un framework qui gagne à être connu.

Alors que la Developer Experience s'immisce timidement dans les réflexions techniques et managériales de nos organisations, notre Ops Experience, elle, est encore trop souvent oubliée. Pire, lorsqu'on construit une solution technique basée sur une plateforme interne, que l'on doit respecter des jalons, améliorer la qualité du code, la fiabilité des tests, automatiser les process,... nous, Dev et Ops, restons des ressources au service des autres équipes métiers de l'entreprise, considérés comme un centre de coût à optimiser. Et si on inversait ce prisme ? Que se passerait-il concrètement si on se considérait nous-mêmes comme des utilisateurs, voire des clients, avec nos besoins, nos irritants et nos attentes, souvent différentes ? Au travers de ce retour d'expérience, je vous propose de penser nos expériences Dev & Ops, comme on pense l'expérience utilisateur. Je vous parlerai des techniques pour comprendre et améliorer le quotidien des équipes de réalisation et traiter nos plateformes internes comme un produit. Je vous emmènerai dans un monde mêlant techniques de marketing (Design Thinking, expérience utilisateur...), d'industrie (Value Stream Mapping, Kaizen...) et de psychologie (Communication Non Violente, sécurité psychologique...). Venez (re-)découvrir des techniques actionnables pour transformer vos DevEx et OpsEx en commençant par le plus simple : considérer Dev et Ops comme des clients précieux dont il faut vraiment écouter les besoins !

On a l'impression qu'avec chaque version de Java il y a de plus en plus de Garbage Collectors (GCs) avec de plus en plus d'options. On entend des phrases cryptiques telles que "Oh trop bien ZGC est devenu générationnel alors que Shenandoah ne l'est pas" ou "T'as vu chez Netflix ils ont réduit leurs tail latencies avec ZGC". Du coup on se pose tout plein de questions: * qu'est-ce qu'ils racontent ? * ZGC c'est quoi ? * si ce ZGC est si magique, pourquoi il y a d'autres GCs dans Java, hein ? * pourquoi on ne parle toujours que des différents GCs de Java mais jamais pour Go ou JavaScript ? chez Java ils ne sont pas capables d'en choisir un ? * et en natif, on a besoin d'un GC ? Dev Java ou simples curieuses et curieux, tout le monde est bienvenu. On va repartir des bases, en commençant il y a 30 ans lors de la création de Java jusqu'à maintenant pour comprendre pourquoi on a toujours besoin d'un GC et pourquoi ce n'est pas un problème résolu (comme l'API Collection). On fera aussi un tour des GCs, de leurs évolutions, de pourquoi on en est arrivé là, de leurs forces et de leurs faiblesses. (spoiler alert: ZGC n'est pas le GC qui les remplacera tous) À l'issue de ce talk vous saurez quand utiliser quel GC afin de trouver le plus adapté à chaque projet, chaque application, chaque environnement.

Bienvenue dans la Matrice. Un monde où les deadlines pleuvent, où les notifications remplacent les battements de ton cœur, et où la productivité est devenue la nouvelle réalité. Tu te crois libre, maître de ton code et de ton agenda ? 🧑‍💻 Et si tout cela n’était qu’une illusion soigneusement entretenue ? Dans ce talk, je vous invite à replonger dans votre cerveau, non pas pour sauver l’humanité, mais pour sauver vous-même. Car quelque part entre un sprint Jira et un visio Teams, beaucoup d’entre nous ont avalé la mauvaise pilule. 😵‍💫 En suivant la voie de Neo, on décodera ensemble les illusions du travail moderne — performance, perfection, disponibilité permanente — qui nous font glisser pas à pas vers le burn-out 🧠. Avec humour, anecdotes et auto-dérision, je vous montrerai les 10 programmes les plus dangereux de la Matrice du travail, et surtout comment en sortir… sans débrancher complètement. 🎤 Format et ton : Un talk énergique, fun, un brin philosophique — mélange de storytelling, d’interaction, de références pop-culture et de déclics concrets à appliquer dès le lendemain. Ni moralisateur ni soporifique : un miroir bienveillant pour tous les devs, managers ou freelancers coincés dans la simulation. 🎯 Plan du talk : 1️⃣ Bienvenue dans la Matrice du boulot — Pourquoi on ne voit pas les signaux du burn-out 2️⃣ Les 10 programmes toxiques — “Toujours dispo”, “travailler plus = valeur”, “ignorer les bugs physiques” 3️⃣ L’illusion du contrôle — Pourquoi le cerveau adore le stress (et comment il nous trompe) 4️⃣ Choisir la pilule rouge — Les vrais hacks pour se reconnecter au réel (sommeil, limites, déconnexion, sens) 5️⃣ Reload — Comment reprogrammer durablement son rapport au travail ⚡ Public : Développeurs, managers, indépendants, curieux du lien entre temps, code et santé mentale. Un talk pour rire, réfléchir et, peut-être, choisir enfin… la pilule rouge. 🔴

Chaque application naît propre. Quelques années plus tard, elle est devenue le monstre que personne ne veut toucher. Ce n'est pas une fatalité, ce n'est pas de la malveillance, c'est le cycle de vie naturel d'une application. Tout professionnel de l'informatique a ou aura la chance (ou la malchance) de travailler sur des projets récents comme en fin de vie ; avec peu d'utilisateurs comme des milliers ; sur des architectures propres comme sur des codebases que personne n'oserait ouvrir ! On va d'abord comprendre pourquoi nos applications ne sont pas éternelles, comment une codebase si propre et si performante se retrouve petit à petit sous perfusion. Pression produit, turnover, dépendances qui meurent, hotfixes qui s'accumulent… On nomme les coupables. Puis on passe aux antidotes : comment maintenir une application en bonne santé du début à la fin, et quand ce n'est plus possible, comment préparer la transmission dans les meilleures conditions ? Durant ce talk, vous allez pouvoir prendre du recul sur vos projets. À lire leur état de santé. Et surtout, à répondre à la vraie question : est-ce qu'on se bat pour la survie ou est-ce qu'on accompagne pour laisser place à autre chose ?

Le "1 Billion Row Challenge" a poussé Java dans ses derniers retranchements. Mais Node.js, souvent réduit à son rôle "single-threaded", a-t-il les épaules pour relever ce défi ? Je vous propose un voyage au cœur de la compréhension du runtime. Nous partirons d'une implémentation naïve pour la reconstruire brique par brique. Au programme : éviter le Garbage Collector, maîtriser le Zero-Allocation, et orchestrer Worker Threads et Shared Memory ou encore utiliser WebAssembly. Venez découvrir comment transformer du JavaScript classique en une solution haute performance, grâce à des concepts applicables bien au-delà de ce challenge.

Cette conférence est issue d'une histoire vraie, où j'ai du écrire un moteur de règles qui doit pouvoir modifier le contenu d'un document JSON en utilisant un DSL maison 🍜 exposé par une API REST 😅 Lors de la première tentative, nous étions parti sur l'utilisation du langage Kotlin, à base de KFunction, de KParameters, d'introspection, qui s'est révélée être un enfer. C'est en discutant de mes déboires avec un collègue qu'il m'a dit: "mais en fait c'est un AST ton truc 💡". L'AST, Abstract Syntax Tree est une structure de données permettant de représenter un programme, exactement ce que l'on cherche à accomplir pour notre moteur de règles, mais ça je ne le savais pas ! Le lendemain, il m'envoyait un scratch IDEA de 40 lignes représentant bien mieux le coeur de notre futur moteur que mes innombrables fonctions génériques de haut niveau et mon code impossible à maintenir. C'est pas clair ? Alors venez, on redéveloppe from-scratch le coeur du moteur avec Kotlin en quelques lignes de code, en illustrant le concept de ce fameux AST.

Dans nos métiers du numérique, où la technique évolue plus vite que nos plannings, le temps est souvent perçu comme un luxe inaccessible. Pourtant, nourrir notre curiosité, apprendre, expérimenter ou encore partager fait partie intégrante de notre développement professionnel. Et si, plutôt que de courir après ce temps, on apprenait à "tricher" un peu pour mieux l’utiliser ? Je vous propose une approche concrète, pragmatique et libératrice : consacrer 30 minutes par jour à soi. À la veille technologique, aux sides projects qui ne seront jamais terminés, à l’écriture d’articles ou de conférences, à l’amélioration de son espace de travail ou à la consolidation de son réseau professionnel. 30 minutes sans pression, mais avec rigueur. Un espace quotidien pour explorer, tester, échouer parfois, mais surtout progresser. Cette conférence partage un retour d’expérience, des conseils applicables dès demain, et une vision décomplexée de la montée en compétences continue. Objectif : entretenir la flamme de notre passion pour ce métier autant humain que technique.

"Trop de slop." "Usine à dette technique." "Ça marche pas sur les gros repos." On a tous vécu ça : on lance un agent IA sur un vrai projet, et le résultat est générique, inadapté, voire cassé. La réaction classique, c'est d'attendre des modèles plus intelligents. Mais le problème n'est pas l'intelligence du modèle, c'est ce qu'on lui donne à manger. Dans ce talk, je vous montre pourquoi le context engineering, la discipline de gérer ce qui entre dans la fenêtre de contexte d'un LLM, est la compétence la plus importante pour tirer parti des outils IA en développement. On verra : - Pourquoi les LLMs sont des fonctions stateless, et ce que ça implique concrètement - Ce qui bouffe le contexte avant même que l'agent commence à coder - La technique de compaction intentionnelle pour garder le savoir sans le bruit - Comment les micro-agents permettent de contrôler la qualité en isolant l'exploration - Le workflow Research → Plan → Implement qui garde chaque session dans la "smart zone" - Comment structurer un CLAUDE.md (ou équivalent) pour que l'agent démarre informé Ce talk s'appuie sur le travail de Dex Horthy (HumanLayer, 12-Factor Agents) et sur des exemples concrets tirés de mes propres expérience avec mon équipe. Pas de théorie abstraite : des techniques applicables dès lundi.