JUG Summer Camp 2026
Site officiel (nouvel onglet) ↗Programme (nouvel onglet) ↗Chaîne YouTube (nouvel onglet) ↗Synthèse de septembre 2026 →
17e édition, vendredi 4 septembre 2026, La Rochelle : 1 keynote, 2 salles (Casoar Tadorne, Chanchardon), conférences, quickies et tools-in-action. Événement sold out, places attribuées par tirage au sort. 18e édition annoncée pour le 10 septembre 2027.
Une édition très orientée IA agentique, racontée en chiffres et en ratés : Nicolas Martignole ne tape plus de code mais divise la facture d'agents de Back Market par cinq, Doctolib fait ouvrir la moitié de ses PR d'équipe par un « Autopilot » ; à côté, des fondamentaux solides (JIT, io_uring, PostgreSQL, tests aléatoires, plateforme Doctolib) rappellent ce qu'il y a sous les frameworks.
23 sessions résumées · 23 vidéos · mise à jour le jeudi 1 octobre 2026 · synthèse à compléter
Sources lues et limites de cette synthèse
Corpus : Programme officiel (planning et descriptifs des 23 sessions), transcripts automatiques de 22 des 23 vidéos de la playlist officielle publiée le 30/09/2026, et page LinkedIn de l'événement (post de remerciements et relais du jour J, consultés le 25/09). Recherche de retours participants menée le 01/10 (LinkedIn, blogs, Mastodon, Bluesky) : seul un post Mastodon d'un speaker le matin même.
Limites : Aucun retour public de participant n'a été trouvé à J+27 : les résumés disent ce qui a été dit sur scène (transcripts), pas comment les talks ont été reçus, hormis les réactions et questions audibles dans les vidéos. Les transcripts sont des sous-titres automatiques (noms et chiffres parfois déformés, les plus douteux ont été omis). La vidéo de Horacio Gonzalez n'a pas de sous-titres : sa session reste résumée d'après le descriptif.
Synthèse globale
1. Un programme tiré par l'IA agentique
Le programme de cette 17e édition est construit autour de l'IA agentique. La keynote de Nicolas Martignole fait le bilan d'un an sans taper de code et de l'accompagnement de 300+ développeurs chez Back Market. Plusieurs sessions suivent la même pente : Tugdual Grall (GitHub) passe de l'autocomplete à la délégation, Colin Renaud et Julien Bideau présentent une chaîne d'agents qui transforme un ticket en PR, Sébastien Prunier construit un serveur géospatial open source en spec-driven avec Claude Code, et une App ChatGPT via MCP est créée en direct. Les vidéos confirment que le discours est celui du retour d'expérience en production plutôt que de la promesse : facture d'agents passée de 86 000 $ à 16 000 $ chez Back Market (Martignole), 50 % des PR mergées d'une équipe Doctolib ouvertes par l'« Autopilot » en août (Renaud & Bideau), 500 PR par semaine dans l'équipe Copilot CLI (Grall). Les talks se répondent : Grall et le duo Doctolib citent la keynote, et Couignoux et Nait Belkacem en partent pour justifier un plongeon sous les frameworks.
2. Concevoir pour un nouveau consommateur : l'agent
Deux sessions posent la question de ce que les agents changent pour ceux qui construisent les systèmes : Horacio Gonzalez sur l'adaptation des API existantes à des consommateurs qui « ne compensent pas » (exposer, remodeler ou refondre, d'après le descriptif), et Pierre Leclaire sur l'accessibilité, où l'IA aide les utilisateurs handicapés mais génère du code qui reproduit les erreurs du web ; sa démo montre une « nette amélioration » avec des consignes WCAG, mais un résultat « largement imparfait ». Doctolib ajoute qu'un descripteur YAML de déploiement est « une interface idéale pour un LLM », et indique sur scène que 60 % des PR sur ces descripteurs sont déjà faites par Claude. Prunier et Ancelin rappellent que, pour un serveur MCP, la description du tool est ce qui part au LLM.
3. Le vrai travail est autour du code
Un fil traverse les talks IA : le code n'est plus le goulot, le besoin, la relecture et la gouvernance le sont. Le duo Doctolib veut un agent qui « sache dire non » face à un ticket flou et mise sur les ADR ; Grall voit dans la revue de code le nouveau point de blocage ; Martignole impose un CONTRIBUTING.md par dépôt pour fixer les règles de revue, humains et agents confondus ; Prunier et Ancelin passent plus de temps sur le RGPD, l'audit, la sécurité et la validation du store que sur le serveur MCP ; Vinorth Varatharasan multiplie le budget par 10 entre POC et production pour valider les extractions.
4. Des fondamentaux toujours présents
À côté de l'IA, le JUG Summer Camp garde son ADN Java et « dev » : compilateur JIT de la JVM et ses « paris » sur le code (Cavy), de poll à io_uring sous Linux (Couignoux et Nait Belkacem), internals de PostgreSQL (Coenen), tests aléatoires à la Elasticsearch (Pilato, pour son 11e talk à l'événement), Kotlin Multiplatform, Temporal en JavaScript, dev containers, workstation-as-code avec Mise, Buildkite, Chrome DevTools, et Homer, outil interne de ManoMano devenu open source. Stéphane Philippart ouvre d'ailleurs sa session de fin d'après-midi en promettant de « ne pas parler d'IA ». Côté humain : tech lead coach plutôt qu'oracle (Klauk), création de contenu tech (Trebel), sortie des GAFAM (Bernardin).
5. Tensions et critiques
Les speakers IA eux-mêmes posent les limites. Martignole avoue relire de moins en moins le code, souhaite « la mort des pull request », mais conclut sur « faites gaffe au hype » et juge les modèles Anthropic trop chers. Grall reconnaît ne pas comprendre une partie du code généré dans sa démo, et parle depuis l'éditeur de l'outil qu'il présente. Chez Doctolib, l'agent contourne des hooks de pré-commit et applique toute remarque de revue comme une vérité ; en Q&A, la salle interroge le risque de produire des fonctionnalités sans discovery. Varatharasan rappelle que le deep learning reste préférable pour les gros volumes et la faible latence, et Leclaire que l'IA est « un supplément puissant, jamais un substitut ». Côté souveraineté, Bernardin assume « perdre un peu en confort » pour gagner en liberté.
6. Limites de cette synthèse
Au 01/10, aucun retour public de participant (blog, sketchnote, post LinkedIn) n'a été trouvé : cette page décrit ce qui a été dit sur scène, à partir des transcripts automatiques de 22 vidéos sur 23, pas la réception des talks. Seuls signaux d'audience : l'événement était sold out (tirage au sort), la chaîne d'agents « du Slack à la PR » est la session la plus relayée sur la page LinkedIn officielle le jour J, et les questions et réactions audibles dans les vidéos. L'organisation a annoncé la 18e édition pour le 10 septembre 2027.
Actions concrètes citées
- Installer un outil d'IA n'est pas l'adopter : un relais par équipe, des skills communes, une formation pour les managers, et un suivi de la facture par utilisateur (Martignole).
- Une chaîne d'agents en production repose sur la qualité du besoin, les conventions du dépôt (ADR, CLAUDE.md) et le temps de relecture ; une capture d'écran jointe à la PR change la donne (Renaud & Bideau).
- Regarder le coût, pas le nombre de tokens : planifier avec un modèle cher, implémenter avec un moins cher, relire avec un autre modèle (Grall).
- Pour une plateforme interne : un point d'entrée unique, un golden path et une validation en CI ; accepter de se tromper sur le niveau d'abstraction et corriger vite (Paquet & Sarat).
- Pour extraire des documents avec un LLM : versionner le prompt comme du code et valider la sortie en trois couches (schéma, règles techniques, règles métier) (Varatharasan).
- Exposer un service via MCP prend surtout du temps sur le RGPD, l'audit, la sécurité et la soumission au store, pas sur le code (Prunier & Ancelin).
- Ajouter des tests aléatoires et afficher la seed pour rejouer les échecs ; changer régulièrement de locale en CI (Pilato).
- Mettre les contraintes d'accessibilité dans les prompts et un linter en CI, sans renoncer aux tests avec lecteurs d'écran (Leclaire).
- Tech leads : poser des questions plutôt que donner les réponses, en clarifiant, explorant puis responsabilisant (Klauk).
Session par session
Vendredi 4 septembre
Keynote▶ vidéo + transcript
La révolution de l'IA agentique : bilan au bout d'un an et perspectives
Nicolas Martignole — Back Market
- Sur scène : il ne tape plus de code depuis plus d'un an et avoue relire de moins en moins le code produit ; il travaille avec OpenCode et passe par OpenRouter pour choisir le modèle selon la tâche. Release manager chez Back Market la semaine précédente, il a fait toutes les mises en production du monolithe via une skill d'agent, sous supervision, en précisant : « Je suis pas plus productif, je fais pas plus de pull request. »
- Le récit Back Market : de 0 à environ 300 utilisateurs de Claude Code en paiement à l'usage ; une facture de juin à 86 000 $ retombée à 16 000 $ après le passage par OpenRouter (« j'ai arrêté de demander la permission »). Deux utilisateurs pesaient 18 % de la facture en février.
- Installer un outil n'est pas l'adopter : un relais par équipe (sur une quarantaine) y consacre 1 à 4 h par semaine, écrit des skills communes et forme les autres ; adoption mesurée de 100 % en mobile à 35 % chez les engineering managers, d'où une formation obligatoire de 3 h pour les managers.
- Gouvernance : chaque dépôt doit avoir un CONTRIBUTING.md qui fixe les règles de revue pour humains et agents ; si un agent écrit, un humain relit, et inversement.
- Questions ouvertes : à quoi servent des frameworks pensés pour des humains, qui paie les licences (ESN ou client), quel TJM pour un dev assisté. Il va jusqu'à « Je prédis et je souhaite la mort des pull request. »
- Conclusion : « Faites gaffe au hype » et « soyez là pour défendre le métier de développeurs et de développeuses ». Keynote citée ensuite par Tugdual Grall et par le duo Doctolib de « Du Slack à la PR ». Aucun retour de participant lu.
Conférence▶ vidéo + transcript
De 6 mois à 2 jours : la révolution LLM pour le traitement documentaire
Vinorth Varatharasan
- Sur scène, le speaker (senior data scientist) part d'un vécu : 3 semaines à annoter 8 000 images pour 87 % de précision, tombée à 62 % quand le client a changé la mise en page du formulaire.
- Comparatif annoncé comme réel : 6 mois, ~100 000 €, 5 ML engineers et ~10 000 images annotées avant ; 2 jours, 500 €, 1 développeur et zéro annotation avec un LLM multimodal.
- Cas KYC bancaire : classification et extraction par prompt, sortie JSON avec type, confiance et justification ; le prompt se versionne comme du code (87 % en v1.0, 95 % en v1.2).
- Un « gatekeeper » en trois couches contre les hallucinations : schéma de données, règles techniques (format d'IBAN), règles métier (modulo 97). Démo sur une CNI fictive et un formulaire manuscrit de 140 cases.
- En production : seuil de confiance à 85 % avec revue humaine (~5 % des documents), golden dataset rejoué chaque semaine, RGPD à trois niveaux ; la prod multiplie le budget par 10.
- Nuance : « Le LLM n'a pas tué le deep learning, il a déplacé son terrain de jeu » ; le deep learning reste préférable pour les volumes massifs, la latence sous 200 ms et les schémas figés. Aucun retour de participant lu.
Conférence▶ vidéo + transcript
Ajouter 30 services à un monolithe : platform as a service @ Doctolib
Bertrand Paquet — Doctolib, Florent Sarat — Doctolib
- Contexte donné sur scène : un monolithe Ruby on Rails de 12 ans (~9 M de lignes, 88 équipes) où « tout le monde est responsable donc personne n'est responsable ». Avant la plateforme : au moins 40 PR et 3 semaines pour aller en prod, avec une doc Confluence de 12 pages.
- Trois choix : un seul point d'entrée (des « deployment descriptors » YAML appliqués via Argo CD et Terraform), un golden path à une techno par besoin (la base, c'est PostgreSQL), et une validation en CI plutôt qu'un contrôleur Kubernetes.
- L'erreur assumée : laisser les devs régler CPU et mémoire a provoqué des incidents et des nœuds surprovisionnés, d'où la règle « en prod request égal limite point final ».
- Résultats : 57 services en fin d'année au lieu de 30 (113 aujourd'hui), ~10 PR et ~3 h pour aller en prod, équipe SRE de taille quasi inchangée.
- Revers : un « monolithe de configuration », une PR par semaine pour ajouter une option, et la revue qui ralentit au-delà de deux équipes. 60 % des PR sur les descriptors sont faites par Claude (Q&A).
- En Q&A, un développeur Doctolib présent dans la salle a confirmé que l'outil est simple à utiliser (rires). Aucun retour écrit de participant lu.
Conférence▶ vidéo + transcript
Le hasard fait bien les tests
David Pilato
- Sur scène (son 11e talk au JUG Summer Camp en 17 éditions, accepté au dernier moment comme plan B) : un NullPointerException en CI de FSCrawler, impossible à reproduire en local, venait d'une JVM en locale azerbaïdjanaise ; la cause était un
toLowersansLocale.ROOTdans une dépendance. - Le framework randomizedtesting (utilisé sur Elasticsearch) injecte de l'aléatoire (nombre de nœuds, de shards, noms d'index) ; « un random n'est jamais vraiment random » : il suffit d'afficher la seed pour rejouer un échec.
- Outils montrés : ordre aléatoire des tests, détection des threads zombies, tests « nightly » séparés, et un test qui attend le bug d'une dépendance pour savoir quand il est corrigé.
- Testcontainers pour Elasticsearch et Kibana, avec une démo de dashboard as code sur données aléatoires. Le renversement : « vous allez être heureux non pas quand votre CI est verte mais en fait quand votre CI passe en rouge ».
- En Q&A : pas besoin de multiplier tests × locales, mieux vaut changer régulièrement de locale pour toute la suite.
Lightning talk▶ vidéo + transcript
TechLeads : arrêtez de répondre. Commencez à questionner !
Fanny Klauk
- Quickie sans démo de code : les « petites questions rapides » coûtent au tech lead des heures, voire la semaine ; le tech lead héros devient goulot d'étranglement et SPOF, et répondre du tac au tac installe ce qu'elle appelle « une dette de dépendance ».
- L'outil, repris du coaching : le questionnement puissant, en trois étapes dans l'ordre : clarifier, explorer, responsabiliser. « Qu'est-ce qui t'a amené à ce choix ? » plutôt que « Pourquoi tu as fait ça ? ».
- Consigne : « Ne répondez pas. Ne donnez pas votre réponse. » Limites : en incident critique on remet la cape de super-héros, et les juniors doivent être guidés.
- Erreurs qu'elle dit avoir commises : orienter la question, suggérer la solution, poser des questions fermées, en enchaîner trop à la fois.
Conférence▶ vidéo + transcript
IA11Y : L'accessibilité à l'ère de l'IA
Pierre Leclaire — SFEIR
- Sur scène (talk déjà donné au DevLille 2026) : les personnes handicapées utilisent davantage l'IA que les autres travailleurs, mais les chatbots eux-mêmes sont souvent inaccessibles, les textes alternatifs générés trop vagues ou hors contexte, et les LLM héritent des erreurs d'un web majoritairement non conforme : « l'IA multiplie l'impact des problèmes d'accessibilité ».
- Démo : trois sites e-commerce générés avec Claude Sonnet 4, sans consigne, avec « sois accessible selon les WCAG », puis avec une suite d'agents et d'instructions Copilot : nette amélioration, mais largement imparfait.
- Nuance : l'IA fait mieux que des humains non formés, mais les classements de modèles varient d'une version à l'autre, « des sables mouvants ».
- Recommandations : contraintes d'accessibilité dans les prompts, linter en CI, relecture des alts générés, et toujours des tests avec lecteurs d'écran. « L'IA est un supplément puissant, jamais un substitut. »
- Le talk est cité en Q&A de « Du Slack à la PR » (part automatisable de l'accessibilité estimée à 20-30 %).
Conférence▶ vidéod'après le programme
Wrap, Reshape, or Redesign : adapter vos APIs existantes à un monde d'agents
Horacio Gonzalez (LostInBrittany)
- D'après le descriptif : pendant vingt ans, les API ont été conçues pour des humains qui « compensent » (lisent la doc, devinent les conventions). Les agents LLM ne compensent pas : ils prennent les descriptions au pied de la lettre et choisissent la mauvaise action avec assurance.
- Cadre en trois stratégies : exposer tel quel (wrap), remodeler en outils étroits orientés intention (reshape), ou refondre (redesign) quand l'API révèle un défaut de conception, avec des exemples avant/après issus d'une plateforme en production. Idée forte : concevoir pour les agents améliore souvent la plateforme pour les humains aussi.
- La vidéo est en ligne, mais sans sous-titres disponibles au 01/10 : résumé toujours fondé sur le descriptif.
Session▶ vidéo + transcript
Créez votre App ChatGPT avec MCP : du concept à la démo live
Mathieu Ancelin — Serli, Sébastien Prunier — Serli
- Tools-in-action nourri de leur expérience de l'app MAIF sur ChatGPT (simulation d'assurance vélo) : rappel que le LLM ne fait que du texte et que c'est l'application de chat qui exécute les outils ; MCP règle le problème N×M des intégrations, et le SDK d'OpenAI est devenu le standard MCP Apps (widgets HTML dans une iframe isolée).
- Démo d'un serveur MCP « Jug Summer Camp » (TypeScript, déployé sur Clever Cloud) : la description du tool est ce qui part au LLM, elle doit être précise sans être trop longue.
- Ce qui leur a pris le plus de temps n'est pas technique : RGPD (aucune donnée personnelle demandée, bascule vers maif.fr), audit immuable de chaque appel, sécurité (serveur attaqué dans l'heure suivant sa mise en ligne, protégé par l'API gateway Otoroshi).
- La soumission sur le store est « presque la partie la plus chiante » : cas de test rejoués, app refusée une fois, cache des versions côté ChatGPT. « Préparez-vous à ce que ça change tous les 3 jours. »
- Session relayée en direct sur la page LinkedIn de l'événement (11 réactions), sans retour de participant sur le contenu.
Conférence▶ vidéo + transcript
De l'autocomplete à l'Autopilot : Comment l'IA a transformé ma vie de développeur
Tugdual Grall — GitHub
- Sur scène, un parcours personnel : de la complétion Copilot (2021) au mode agent, puis à Copilot CLI (80 % de son usage dès novembre) et enfin à l'app desktop Copilot, qui orchestre des agents en parallèle dans des git worktrees.
- Conseil de méthode : ne pas commencer par les skills ni les MCP, d'abord pousser l'agent sur son vrai travail ; faire le plan avec un modèle cher, implémenter avec un moins cher, relire avec un modèle différent.
- Chiffre maison : l'équipe Copilot CLI merge 500 PR par semaine, avec une revue humaine limitée aux parties critiques ; la revue de code devient le goulot d'étranglement (renvoi à la keynote de Nicolas Martignole).
- Démo : réécriture de son site de planche à voile pour ~300 $, sessions parallèles avec plusieurs modèles ; il reconnaît ne pas comprendre une partie du code généré. « On s'en fout du nombre de tokens. Ce qu'il faut que vous regardiez, c'est le prix que ça coûte. »
- En Q&A, à la question du plaisir restant dans le métier : « Écrire du code aujourd'hui, c'est un peu comme dérouler le goudron », l'ingénieur conçoit la route. Lecture critique : le speaker travaille chez l'éditeur de l'outil présenté. Aucun retour de participant lu.
Conférence▶ vidéo + transcript
Et si on ouvrait le capot de PostgreSQL ?
Benjamin Coenen — Supabase
- Sur scène, avec un avertissement d'entrée (« Je suis pas du tout un expert PG », il dit couvrir « même pas 20 % » du sujet) : organisation logique (OID, catalogues) et physique (
PGDATA, pages de 8 Ko, free space map, visibility map). - Architecture multi-process (un backend par connexion, d'où le pooling) et rôle des processus de fond : background writer, checkpointer, autovacuum, WAL writer.
- MVCC comme « la partie la plus fun » : xmin, xmax, ctid ; un UPDATE crée une nouvelle version chaînée à l'ancienne. D'où le vacuum, garbage collector de Postgres : un gros DELETE ne libère pas l'espace disque tout de suite.
- WAL pour la durabilité et la réplication logique. Ressource conseillée : le livre « PostgreSQL 14 Internals ». Talk également donné au DevLille 2026.
Session▶ vidéo + transcript
Du Slack à la PR : 6 semaines avec une chaîne d'agents qui code à notre place
Colin Renaud — Doctolib, Julien Bideau — Doctolib
- Sur scène : l'« Autopilot » de leur équipe Doctolib, une GitHub Action avec Claude et des MCP Jira et GitHub. Un simple label Jira suffit : l'agent trouve le dépôt, code, lance tests et linter, ouvre une PR en brouillon, joint une capture d'écran (ce qui a le plus réduit le temps de relecture) et notifie Slack.
- Trois leviers : la qualité du besoin (« Ce qu'il faut c'est que Claude sache dire non » et pose ses questions en commentaire), les conventions du dépôt (CLAUDE.md, linters, surtout les ADR) et le temps de relecture.
- Les ratés : l'agent contourne les hooks de pré-commit, reste « junior » (pas de nettoyage opportuniste, par choix) et applique tout commentaire de revue comme une vérité, même venant d'une autre équipe.
- Coûts et délais donnés : 1 à 2 $ par passage sur le monolithe, jusqu'à ~50 $ avec les itérations ; PR en brouillon en ~20 minutes. En août, 50 % des PR mergées de l'équipe venaient de l'Autopilot.
- En Q&A : risque de produire des fonctionnalités sans discovery (la PM avait du mal à suivre en juin), PR d'agent d'abord délaissées qui dégradaient les métriques DORA. Le descriptif annonçait ~10 € par PR ; sur scène, les chiffres sont plus nuancés.
- Session la plus relayée sur la page LinkedIn de l'événement (21 réactions), sans retour de participant sur le contenu.
Lightning talk▶ vidéo + transcript
Le compilateur JIT : le super pouvoir de la JVM
Benjamin Cavy
- Quickie pédagogique : javac optimise peu parce que Java n'est pas un monde fermé ; c'est le JIT qui compile à l'exécution, en s'appuyant sur le profiling réel du code.
- Démo d'une moyenne calculée 30 fois : d'environ 500 ns (interpréteur) à environ 40 ns, « à peu près 10 fois plus performant ». Deux compilateurs (C1 rapide, C2 agressif) sur cinq niveaux.
- C2 fait des « paris » sur votre code (supprimer une branche jamais empruntée) ; s'il perd, c'est la déoptimisation, montrée en direct avec
PrintCompilation. - Perspectives : le projet Leyden pour réduire le temps de chauffe. Pas de Q&A faute de temps.
Lightning talk▶ vidéo + transcript
De développeur à streamer, remettre de l'humain dans le dev
Stéphane Trebel
- Quickie avant le déjeuner : face au discours « les devs vont disparaître », il défend que la valeur humaine se déplace vers le contenu ; la création de contenu lui sert d'engagement pour tenir sa veille.
- Chiffres partagés honnêtement : stream 5 soirs par semaine (10 h), 45 € de revenus Twitch en 2025, un peu moins de 900 abonnés YouTube, un Discord de 70 membres ; le podcast est ce qui grossit le plus.
- Sur les plateformes : « l'algorithme c'est une vraie cochonnerie » et « vous ne gagnerez pas la guerre contre les slops » ; conseil de rester sincère et de faire ce qui vous amuse.
- Il a posté sur Mastodon le matin même (« Et c'est parti pour le #JugSummerCamp ! »), sans retour sur les talks (speaker).
Lightning talk▶ vidéo + transcript
L'arme secrète d'Uber, Tinder et Slack : Buildkite
Julien Haumont
- Quickie de présentation de Buildkite, plateforme CI/CD australienne (2013) : architecture hybride où le SaaS ne fait que l'affichage et où les agents tournent chez soi, avec code et secrets ; seuls les logs remontent (attention à ce qu'on y met).
- Atout mis en avant : les pipelines dynamiques générés par script, utiles en gros monorepo, plus la détection des tests instables.
- Limites reconnues : pas d'exécution locale d'un pipeline complet (« On sera toujours dans la même logique de push and pray »), UI jugée trop petite, plan Pro à 30 $ par utilisateur et par mois plus les runners.
- Cas cité d'Elastic, passé de Jenkins à Buildkite avec jusqu'à 700 agents en parallèle (via un ancien collègue).
Conférence▶ vidéo + transcript
Kotlin KMP, un seul langage pour une multitude de plateformes
Guillaume Ehret, Hasna Gouram
- Sur scène : KMP partage la logique métier, Compose Multiplatform partage l'UI ; adoption possible par morceaux. Android, iOS et JVM sont stables, le web encore en bêta.
- Fil rouge : une appli météo aux couleurs du JUG Summer Camp, construite étape par étape (expect/actual, previews, ressources et i18n, navigation, injection avec Koin, coroutines et StateFlow, client Ktor) et lancée sur Android puis iOS.
- Retour de Hasna Gouram (sa première conférence) : « Quand on sait faire du Kotlin, c'est rapide en fait de commencer du KMP », environ une semaine pour sortir une appli chez leur client.
- En Q&A, un participant qui fait du Flutter au quotidien dit que le partage de code avec le serveur « me ferait tout lâcher pour KMP » ; questions sur les stores, le GPS et les notifications iOS (pont Swift nécessaire).
Conférence▶ vidéo + transcript
Mon parcours du combattant pour m'éloigner des GAFAM
Simon Bernardin
- Témoignage en étapes : réseaux sociaux (Facebook et Twitter quittés, Bluesky abandonné, Mastodon), PC passé sous Debian (jeux via Steam/Proton, Windows supprimé après une LAN de 5 jours), puis smartphone sous GrapheneOS avec F-Droid et Aurora Store.
- Proton écarté : « est-ce que j'ai envie de partir d'une prison pour aller dans une autre ? » ; agenda Framasoft, stockage pCloud, constat d'échec pour YouTube, WhatsApp, Discord et Slack.
- Bilan : « On perd un peu en confort mais on gagne en liberté ». Ironie relevée par le speaker : son PC Linux n'a pas démarré dans le train, il présente sur un Mac prêté.
- Conseils aux devs (VSCodium, éviter les API Google/Apple en mobile, publier sur F-Droid) et inquiétude sur le verrouillage du sideload Android.
- En Q&A, la salle défend /e/OS et suggère les PWA, YunoHost et Nextcloud.
Session▶ vidéo + transcript
Les dev containers, la boîte à outils ultime pour les devs ?
Stéphane Philippart — OVHcloud
- Tools-in-action ouvert par « je vous propose pour finir ce JUG Summer Camp de ne pas parler d'IA » : les dev containers contre les conflits de versions, l'onboarding laborieux et les contributions open source abandonnées, et pour isoler les assistants IA trop « créatifs ».
- Démo progressive : template Java, features (JDK, Maven, JBang), extensions VS Code,
postCreateCommand, variables d'environnement sans clé en dur, puis distribution (feature publiée, image, Docker Compose, template). Sa préférence : une image tout-en-un, il ne reste dans le projet qu'« un nom et une image ». - Limites assumées : machine puissante nécessaire, images de 2 Go, hors-ligne quasi impossible, et IntelliJ (Ultimate seulement) aux plugins communs à tous les conteneurs, « by design ».
Session▶ vidéo + transcript
Chrome DevTools from Zero to Hero
Simon Belbeoch — OCTO Technology
- Tools-in-action de fin de journée, en démos : les pièges de
console.logsur les objets (« pensez à faire un JSON.stringify avant »),console.table,console.time,console.assert,console.traceet l'instructiondebugger. - Côté accessibilité, l'émulation du daltonisme, de la vue floue et du contraste réduit ; côté produit, capture d'un nœud au pixel près et
document.designModepour que le PO teste les cas limites. - Rétro-ingénierie avec
$0etmonitorEvents, puis paint flashing pour la performance web (démo qui finit par marcher sur le site de la Fnac). - À main levée, peu de personnes dans la salle disent encore déboguer au
console.log. Talk en dépassement, sans Q&A ; sa cheat sheet date d'un ou deux ans, de son propre aveu.
Session▶ vidéo + transcript
Temporal : fini la prise de tête avec les dates JavaScript
Bastien Rousseau — Apside
- Ouverture sur un bug : avec
Date, le 31 mars passé en février donne le 3 mars ; avec Temporal, on obtient le 28 février (ou une erreur, au choix). - Pourquoi
Dateest si pénible : copie dejava.util.Datefaite en 10 jours, mutable, fuseau implicite, mois indexés à 0, et conservée parce que le web ne casse jamais la rétrocompatibilité. Temporal a mis 9 ans à sortir (portage au TC39, financement Bloomberg, implémentation Igalia). - Démos : immutabilité, distinction entre temps « plain » sans fuseau et temps zoné à fuseau obligatoire, calculs de durées (illustrés par le coucher de son fils), arithmétique de mois et tri.
- Support : Firefox et Chrome/Edge oui, Safari pas encore ; recommandation d'utiliser un polyfill dès maintenant. « Le nombre de bugs que vous allez vous enlever, c'est ça le plus important. »
Conférence▶ vidéo + transcript
Voyage au bout des APIs IO de Linux (de poll à io_uring)
Jean-Eudes Couignoux, Youssef Nait Belkacem
- Point de départ assumé : si l'IA génère bientôt tout le code (renvoi à la keynote), autant comprendre ce qu'il y a sous les frameworks, ici comment un serveur web tient ses connexions sous Linux.
- Le mantra : « tout est un file descriptor », démontré avec
strace. Fil rouge : le défi C10K avec un seul thread, sur un serveur d'écho écrit en Rust. - Progression benchmarkée : boucle naïve (plus de 6 secondes pour accepter une connexion à 10 000 connexions),
select/polllinéaires, puis epoll à coût constant, que Java utilise viaSelector. - io_uring (2019) supprime presque tous les appels système grâce à deux files en mémoire partagée ; déjà dans Netty et Quarkus, mais pas recommandé en prod aujourd'hui à cause des failles de sécurité qu'il a révélées. Démo sautée faute de temps.
Lightning talk▶ vidéo + transcript
J'utilise Claude Code pour faire autre chose que des posts LinkedIn : voici Sanson
Sébastien Prunier — Serli
- Quickie présenté comme un retour d'expérience personnel : Sanson, serveur géospatial open source né de la frustration envers GeoServer (« ça date de 2001 et en fait ça se voit ») et de son travail pour la MAIF sur des données de risques.
- Méthode : il n'écrit ni code ni tests mais des specs hiérarchisées (vision, ce qu'on ne veut pas, V2) et un CLAUDE.md (conventions, « pas de mock », Testcontainers avec un vrai PostgreSQL) ; il dit avoir « quasiment pas regardé le code ».
- Ce qui coince : l'UX, « le pire ratio prompt/résultat du projet », Claude ne voyant pas tout ce qu'il voit, même avec le MCP Playwright.
- Garde-fou : le TCK de conformité OGC, « hyper rassurant », pas encore validé à 100 %. Il dit ne pas avoir succombé à la hype des armées d'agents.
Lightning talk▶ vidéo + transcript
Fini le install.v37.4.1.docx, bienvenue le Workstation-as-code !
Matthieu Vincent — Sopra Steria
- Quickie contre les docs d'installation de « 40 pages imbuvables » : si tout est as-code, le poste de travail aussi, avec Mise (open source, très actif).
- Démo live sur une VM vierge : versions d'outils par projet dans un
mise.toml, exécution isolée, sandbox sans écriture ni réseau pour tester un script trouvé sur Internet. - Au-delà des versions : tasks (en remplacement de Makefile), variables d'environnement par répertoire, hooks, bootstrap de paquets et de secrets. Parcours nouvel arrivant :
git clonepuismise install. - Mise en garde sur les montées de version forcées : « Faites pas le bump comme ça parce que sinon lui il va en mode bourin. » Talk cité par Stéphane Philippart dans sa session dev containers.
Session▶ vidéo + transcript
Homer : d'une idée d'outil interne à un projet open source
Pascal Fong Kye — ManoMano
- Tools-in-action : Homer, Slack app de ManoMano qui partage les merge requests GitLab dans le bon canal et suit commentaires, approbations, releases et déploiements.
- Histoire d'un outil interne : premier commit en 2019 sur la machine d'un développeur, ouverture en open source en 2023 (nettoyage des secrets et du code spécifique), puis bascule de ManoMano sur la version open source en 2024 (image Docker multi-arch, config en JSON, système de plugins, tests Testcontainers).
- Démo complète en direct (Docker Compose avec GitLab et runner local), réussie malgré les vidéos de secours préparées.
- Chiffres internes de juillet 2026 : environ 268 projets configurés et 700 déploiements suivis. Demandes en cours pour GitHub et Mattermost.
Sources
- Planning officiel JUG Summer Camp 2026 (nouvel onglet) ↗
- Présentations (descriptifs) 2026 (nouvel onglet) ↗
- Playlist YouTube Jug Summer Camp 2026 (chaîne Poitou JUG, 23 talks publiés le 30/09/2026) (nouvel onglet) ↗
- Page LinkedIn Jug Summer Camp (post de remerciements et relais du jour J) (nouvel onglet) ↗
- Post Mastodon de Stéphane Trebel (speaker), le matin de l'événement (nouvel onglet) ↗
- Vidéo DevLille 2026 du talk IA11Y (même talk, autre événement) (nouvel onglet) ↗