Présentations

Que l’on travaille avec des bases de données, des serveurs web ou même que l’on lise simplement des fichiers, on retrouvera toujours sous Linux les mêmes API en dessous : « poll » ou « select » pour les plus anciens d’entre nous, « epoll » pour les plus récents.

Mais depuis 2019, une révolution bouscule le monde Linux et propose une alternative à ces API historiques : il s’agit de « io_uring ».

Au cours de cette conférence, nous vous expliquerons, via un exemple simple (une socket) et du code, les différentes API Linux, leurs évolutions et les problématiques que ces évolutions résolvent.

En 2021, Copilot m'aidait à terminer des lignes de code.
En 2024, je discutais avec lui.
En 2025, le Context Engineering a marqué un tournant décisif.

Aujourd'hui, en 2026, je ne me contente plus de parler à l'IA — je lui délègue.

GitHub Copilot, Copilot CLI, les Skills, les workflows agentiques, les nouveaux modèles… Je suis passé de la simple assistance à la délégation de pans entiers de mon travail, de la création de projets à l'ouverture et la revue de pull requests, le tout en langage naturel.

Et je ne suis pas le seul : chez GitHub, nos propres équipes produits utilisent ces mêmes capacités pour livrer plus rapidement et repenser la manière dont les logiciels sont conçus.

Ce changement dépasse le cadre des seuls développeurs. Product Managers, SREs, ingénieurs DevOps — ils deviennent tous des bâtisseurs. Il ne s'agit plus seulement d'écrire du code, mais d'exprimer une intention.

Dans cette présentation, je vous montrerai ce qui a fondamentalement changé entre 2025 et 2026, et comment cette évolution m'a transformé : d'un développeur doté d'un excellent assistant à un véritable "builder" capable de piloter de nombreux projets et taches en parallèle.

Chez Doctolib, nous découpons le monolithe historique. En plus de la difficulté métier à faire cela, nous avons dû repenser sur comment déployer de nouveaux services. Il y a un an : 40 pull requests, 3 semaines pour aller en prod. Aujourd'hui : moins de 3 heures.

Pour cela nous sommes passés d'une infrastructure gérée par des SRE à une plateforme self-service facilement utilisable par les développeurs. Résultat aujourd'hui plus de 90% des PRs infrastructure sont écrites et validées par les équipes elles-mêmes.

Mais le chemin pour y arriver n'a pas été évident. Ce talk revient sur les choix faits et les difficultés rencontrées, avec deux points de vue complémentaires : celui d'un Principal SRE, qui doit garantir la fiabilité, la sécurité et la conformité dans un contexte de santé, et celui d'un PM, qui doit rendre la plateforme compréhensible, adoptable et réellement utile pour les équipes.

Description

• L'outil n'était pas la question. Quel outil choisir ? Terraform ? Helm? Kubernetes ? Cette question n'est pas la plus importante. Le vrai sujet est de trouver le bon niveau d'abstraction pour les développeurs - et ça ne se décide pas dans un design doc. Nous l'avons découvert en travaillant avec les premières équipes et en affinant nos descripteurs de deploiment au fil des use cases.
• Liberté et garde-fous. Comment faire du « You build you run it » sans accès à la production dans un domaine aussi contraignant que la santé? Comment satisfaire les contraintes SRE pour garantir la scalabilité et la stabilité de la plateforme, tout en fournissant une interface simple a utiliser et qui permettent aux équipes de continuer à innover?
• L'avenir ? Un fichier YAML est une interface idéale pour un LLM. Le déploiment n'est plus un sujet. Mais de nombreux sujets restent ouverts. Comment faire évoluer la plateforme pour supporter de nouvelles technologies? Comment permettre aux équipes d'étre toujours plus autonome pour opérer leur services en production?

HTTP/3 est né du constat que, malgré les évolutions apportées par HTTP/2, certains problèmes fondamentaux persistent. Cette conférence propose de comprendre pourquoi HTTP/3 a été nécessaire, en montrant qu’il ne s’agit pas simplement d’une nouvelle version de HTTP, mais d’un changement de paradigme rendu possible par QUIC. QUIC apporte une couche de transport plus riche que TCP et fournit un véritable framework pour concevoir de nouveaux protocoles, mieux adaptés aux réseaux actuels et aux usages temps réel.

Après une introduction à QUIC et à ses principes fondamentaux, la présentation explique comment HTTP/3 s’appuie concrètement sur QUIC. Nous verrons comment un navigateur découvre et établit une connexion HTTP/3 et comment cette transition se fait de manière progressive et transparente.

Enfin, nous explorerons ce que HTTP/3 débloque au‑delà du modèle requête/réponse classique. L’introduction des HTTP Datagrams ouvre la voie à de nouveaux usages, en permettant l’implémentation de technologies comme WebTransport ou MASQUE.

Le compilateur JIT (Just In Time) permet d'optimiser le bytecode de vos programmes tournant sur la JVM en compilant certaines parties en code machine.

Loin des mythes sur la lenteur de Java et de la JVM, le compilateur JIT permet une optimisation de vos programmes basée sur l'observation de leur exécution.

Ce quickie sera l'occasion de détailler le fonctionnement du compilateur JIT et de voir comment il rend vos programmes toujours plus performant sur la JVM.

Je travaille depuis plusieurs années sur le traitement et l'exposition de données géospatiales. Je sais ce que coûte ce genre de projet "à la main" — avec un vrai backend, une base PostGIS, des standards à respecter et une UI cartographique. J'ai voulu voir jusqu'où on pouvait aller en mode spec-driven, avec Claude Code comme binôme, sur un vrai produit plutôt qu'un POC. Le résultat s'appelle Sanson : un serveur géospatial open source, alternative moderne à GeoServer, conforme au standard OGC API Features, avec son UI d'administration. Node.js, TypeScript, Fastify, PostGIS — un vrai produit prêt pour la prod.

Je ne suis pas un expert Claude Code — d'autres font bien mieux que moi — mais en 15 minutes, je vous partage un retour d'expérience honnête : comment partir d'une spec et la faire vivre plutôt que prompter au fil de l'eau ; ce qui marche très bien, ce qui pique encore, ce qu'il faut désapprendre ; ce que j'ai appris en chemin (la spec OGC API Features, pg-boss, et plein de petits trucs que je n'aurais pas explorés sinon) ; et surtout, le plaisir intact à créer un produit de bout en bout — c'est peut-être ça, finalement, la vraie surprise. Démo live, ton décomplexé, et quelques pratiques concrètes à remporter dans vos bagages.

On nous dit que le métier de développeur va disparaître, je pense l'exact contraire. À l'aube de nouveaux outils et de nouvelles capacités, c'est justement davantage d'humain dont on va avoir besoin. Car tout ce qu'on fait, de manière monétisée ou pas, on le fait pour d'autres humains, sinon ce n'est pas la peine.

Je vous propose donc de discuter de secteur de la Tech qui est la création de contenus. Streamer, YouTuber, TikToker, derrière tout ces "-er", comment peut-on faire de la Tech autrement ?

• Pourquoi s'intéresser à la création de contenu dans la Tech, en 2026 ? Le partage, bien sûr, mais également votre veille technologique turbochargée ! Car « L'attention est un jeu à somme nulle », il faut choisir ce qu'on fait, ou regarde, avec soin
• Montrer le chemin aux plus juniors, c'est aussi se mettre dans les formes de création qui leur parle. Faire le pont entre les générations, ce n'est pas simple… mais ça vaut le coup de se battre !
• Le quoi, le comment, le où, etc. Comment itérer m'a permis de mieux comprendre les enjeux de ce domaine de la Tech pas comme les autres. L'«Entertainment» est à l'opposé de notre métier, et je l'ai appris en me plantant régulièrement 😅

Alors, venez faire ce pas de côté avec moi. Et vous comprendrez alors pourquoi mon autre nom, sur les réseaux, c'est "Le Permacodeur" 😉

"C'est bizarre, ça marche sur ma machine." Cette phrase, nous l'avons tous entendue (ou prononcée) après avoir passé trois heures à déboguer une version de Python mal alignée ou un PATH récalcitrant. Si l'Infrastructure as Code (IaC) a révolutionné nos serveurs, nos environnements de développement restent souvent des petites choses fragiles, documentés dans des README que personne ne lit.

Découvrons ensemble l'approche Workstation-as-code avec l'outil Mise. Bien plus qu'un simple gestionnaire de versions, Mise se positionne comme le couteau suisse ultime du développeur. Il propose entre autres :

• Le Runtime Management : Gérez vos versions de Node, Go, Python ou Terraform de manière déclarative.
• L'Environment Management : Remplacez direnv pour injecter vos variables d'environnement au bon moment.
• Le Task Running : Dites adieu aux Makefile cryptiques avec un orchestrateur de tâches moderne et performant.

Dans ce talk, nous explorerons comment Mise permet de passer d'un onboarding de trois jours à un simple mise install. Nous verrons comment standardiser les environnements d'une équipe entière et pourquoi cet outil est en train de devenir le standard de la Developer Experience.

Uber. Slack. Tinder. Elastic. Shopify.

Vous pensez connaître la CI/CD qui propulse ces géants ? Vous imaginez sûrement une usine à gaz Jenkins ou des milliers de GitHub Actions ? Et bien non. Vous ne la connaissez pas. Leur point commun s'appelle Buildkite.

Mais pourquoi l'élite de la Tech a-t-elle choisi cet outsider plutôt que les standards du marché ? C'est la question que je me suis posée. J'ai testé pour vous cet OVNI de l'intégration continue. Venez découvrir mon retour d'expérience et comprendre pourquoi, après ce talk, vous ne regarderez plus vos pipelines de la même façon.

On attend du Techlead qu’il sache. On vient le voir pour chaque décision : relecture de code, décision d'architecture, arbitrage produit, debug complexe, médiation d'équipe… Et plus il est compétent, plus il est sollicité !

Le paradoxe ? Sa valeur crée sa surcharge. Et si le rôle du TechLead n’était pas d’avoir les meilleures réponses… mais de poser les meilleures questions ?

Le questionnement puissant est une compétence centrale en coaching mais quasiment absente de la culture technique.

Alors permettez-moi de vous offrir cet angle nouveau qui pourrait vous permettre de :

• réduire la charge cognitive du TechLead,
• faire émerger des solutions plus solides,
• responsabiliser sans imposer,
• et d'éviter les dépendances invisibles

Un sujet pour celles et ceux qui veulent faire grandir leur impact sans s’épuiser.

Imaginez : votre produit, star du Web, cartonne. Tout va bien dans le meilleur des mondes… jusqu'à ce que vos clients se mettent à hurler : "On veut ça sur mobile avec une vraie expérience Android et iOS!"

C'est là que le cauchemar du développeur commence. On se retrouve à tester plusieurs solutions : du natif Android(Kotlin) iOS(Swift), du multiplatforme Flutter (Dart), React Native (TypeScript).

Mais plusieurs problème apparaissent :

• la Redondance: comme on ne peut pas partager de code sur des langages hétérogènes on le recopie
• l'Incohérence : on se base sur des composants différents et on multiplie les expériences utilisateurs
• le Coût : il ne faut plus une équipe de dev mais plusieurs

C'est là que Kotlin Multiplatform (KMP) entre en scène pour amener une réponse et une solution viable. Une seule base de code, et packagée via Gradle pour Android, iOS, une JVM et même le Web.

Au cours de cette conférence, nous allons remonter le temps pour comprendre l'émergence de KMP et pourquoi je pense qu'il est une solution viable pour un développement full-stack. Préparez-vous, car je vous montrerai des exemples de code concrets qui prouvent que ce rêve de code unique déployable sur plusieurs plateformes n'est plus une utopie, mais une réalité.

À mesure que l’intelligence artificielle progresse, elle transforme non seulement notre manière de travailler, mais aussi notre manière de penser, d’apprendre et de créer. L’enjeu n’est plus simplement technologique : il devient profondément cognitif et humain. Cette conférence propose d’explorer une question essentielle pour les professionnels du numérique : que signifie être créatif dans un monde où les machines peuvent générer du contenu à grande échelle ? En croisant les apports de la recherche académique, des retours d’usage en entreprise et des pratiques issues des industries créatives, cette session met en lumière le rôle critique de l’intention humaine dans les processus de création augmentés par l’IA. L’humain fixe la direction, définit les critères et arbitre ce qui fait sens, tandis que l’IA explore rapidement de multiples variations plausibles. À partir d’études récentes comparant écriture assistée, recherche classique et production autonome, nous analyserons les impacts mesurés de l’IA sur la charge cognitive, la mémoire et l’originalité des productions. Ces travaux montrent notamment que l’usage non maîtrisé des LLM peut réduire l’engagement cognitif et homogénéiser les outputs créatifs. La session se conclura par des méthodes concrètes permettant de développer une créativité véritablement humaine, complémentaire de l’IA : stratégies d’idéation, approches métacognitives et techniques issues du design créatif.

On entend souvent parler de souveraineté numérique, de dépendance aux grandes plateformes, de respect de la vie privée numérique. Comment en tant qu'individu pouvons nous essayer de retrouver la liberté sur nos usages ?

J'ai décidé de prendre le taureau par les cornes : j’ai quitté Windows pour Linux, installé GrapheneOS sur mon téléphone et remplacé (presque tous) les services proposés par les GAFAM dans mon quotidien.

Dans cette conférence, je propose :

• un retour d’expérience honnête, avec les galères et les surprises
• une cartographie des dépendances invisibles dans nos usages modernes
• et surtout une réflexion : en tant que développeurs, peut-on concevoir des applications qui laissent une porte de sortie à leurs utilisateurs ?

Pendant vingt ans, nous avons conçu des APIs pour des développeurs humains. Et ça marchait, parce que les humains compensent : ils lisent la doc, déduisent les conventions, repèrent les opérations dangereuses et comblent ce que l’interface n’a jamais rendu explicite.

Aujourd’hui, ces mêmes APIs ont un deuxième consommateur : des agents basés sur des LLMs, des copilotes et des workflows pilotés par des agents. Ce nouveau consommateur ne compense pas de manière fiable. Il interprète les descriptions au pied de la lettre, choisit la mauvaise action avec assurance et ne peut pas deviner les limites opérationnelles que votre API n’a jamais déclarées.

La réponse naïve consiste à exposer les APIs existantes avec quelques descriptions d’outils et à considérer le travail comme fait. En pratique, certaines capacités peuvent être exposées telles quelles, d’autres doivent être remodelées en outils plus étroits, orientés intention, et d’autres encore révèlent des défauts de conception plus profonds qui nécessitent une vraie refonte.

Dans ce talk, je partagerai un framework pratique pour adapter des APIs et des capacités de plateforme existantes à la consommation par des agents, à partir d’exemples concrets issus d’une plateforme en production. Nous verrons des cas avant/après, nous discuterons des compromis de chaque stratégie, et nous verrons pourquoi concevoir pour les agents améliore souvent la plateforme pour les humains aussi.

Et si, en 30 minutes, on créait ensemble une App ChatGPT dédiée au Jug Summer Camp ?

Dans ce Tools in Action, Mathieu et Sébastien vous proposent une session 100 % concrète autour de MCP — Model Context Protocol : à quoi ça sert, comment ça fonctionne, et surtout comment l’utiliser pour connecter ChatGPT à vos propres données, outils ou services.

Plutôt qu’une présentation théorique, nous construirons en live une App ChatGPT capable d’interagir avec l’univers du Jug Summer Camp : programme, sessions, speakers, lieux, informations pratiques… L’objectif : montrer pas à pas comment passer d’une idée à une première app fonctionnelle, en exposant des tools via MCP et en les rendant utilisables directement depuis ChatGPT.

En sortant de la session, vous aurez compris les grands principes de MCP, les cas d’usage possibles, et les premières briques nécessaires pour créer vos propres Apps ChatGPT.

Nous avons développé un outil interne pour connecter notre outil de messagerie Slack à notre outil de versioning de code Gitlab car le suivi et la communication autour des revues de code entre les membres d'une équipe de développement était chaotique. Ainsi, les développeurs sont tenus au courant et peuvent agir rapidement sur les revues de code. Cet outil a été apprécié et étendu à toutes les équipes, puis amélioré en ajoutant par exemple les déploiements de nouvelles versions en production depuis Slack.

Notre entreprise étant utilisatrice et contributrice du monde open source, l'idée de rendre public et open source ce projet a germé.

Mais cette aventure n'a pas été si simple et rapide. Grâce à une petite équipe de 5 motivés, nous avons amélioré le projet, sa documentation, sa compatibilité, rendu accessible et disponible à tous, que ce soit pour l'utiliser dans leur entreprise ou y contribuer.

Nous aimerions vous raconter cette histoire et partager notre expérience pour permettre à d'autres entreprises d'open sourcer leurs projets internes.

Classifier et extraire les données de milliers, voire de millions de documents, c'était 6 mois de développement, une équipe de ML engineers et d'annotateurs externes, des dizaines de milliers d'images annotées et un budget à six chiffres.

Aujourd'hui, un LLM multimodal fait le même travail en quelques jours, sans dataset et sans entraînement.

Trop beau pour être vrai ? Dans cette démo live, je vous montre exactement comment ça fonctionne sur un cas réel de KYC bancaire, par exemple CNI, passeports, justificatifs, RIB, et surtout, comment on évite que le modèle hallucine sur vos données les plus sensibles.

PostgreSQL est une des bases de données les plus utilisées et les plus appréciées. Mais sait-on vraiment comment elle fonctionne ?

Qu’est ce qui lui permet d’être à la fois performante, tolérante aux crashs et hautement disponible ?

Je vous propose de découvrir ensemble les internals de Postgres et d'apprendre comment sont stockées vos données sur celle-ci.

En partant d’une simple requête sql et en passant par toutes les étapes pour récupérer la donnée que l'on recherche, découvrons comment PG fonctionne.

Nous aborderons les notions spécifiques aux implémentations de bases de données et plus spécifiquement celles de Postgres (query planner, write ahead log, mvcc, tuples, vacuum, …).

Hey Claude, jette un œil au ticket PROJ-1234. 12 minutes plus tard, dans le même thread Slack : PR ouverte, screenshot ci-joint.

Pas de browser. Pas de Jira UI. Pas de laptop. Tout dans une conversation.

Retour d'expérience sur une chaîne déployée en production : un agent IA org-wide qui pioche (ou créé un ticket) dans Jira via un label, identifie le bon repo, écrit le code, lance tests + lint, prend un screenshot, ouvre une PR signée, transitionne le ticket. En GitHub Actions, sans intervention humaine, déployable à n'importe quelle équipe.

Au programme :

• Démo live : ticket → PR review depuis un téléphone
• Les bugs prod : commits non-signés, PRs hallucinées, agents qui contournent leur propre safety check
• Les guardrails non-négociables : sanity diff check, no-bypass rules, downgrade graceful
• Le coût réel : ~10€ / PR, 10 min en moyenne
• Les prochaines étapes

Un pattern reproductible, pas un POC.

On a toutes et tous été confronté•es, un jour, à devoir (ré)installer tout notre environnement de développement lors d'un changement de machine. Que ce soit par choix ou juste en mode "on-boarding" lors d'un changement de société, de mission, … On a aussi, parfois, passé de longues heures pour comprendre quels outils installer pour proposer une PR ou MR dans un projet Open Source.

Dans encore beaucoup d'autres cas, nous sommes vite confrontés à l'enfer de la configuration des outils et autres frameworks pour faire ce que l'on aime : développer. Et je ne vous parle pas des montées de versions et inter-dépendances 😅…

Heureusement, il existe une solution à tous ces problèmes : les dev containers.

Lors de ce talk, je vous propose de partir à leur découverte. La seule chose que je m'autorise à installer sur ma machine : Docker ! Le reste sera de la gestion de configuration pour que les outils, les frameworks et la gestion des versions et dépendances soit un non-évènement dans votre process de développement.

Vous repartirez en sachant utiliser les dev containers mais aussi en sachant construire as-code votre stack de développement 🧑‍💻.

Depuis longtemps, en front on a pris l'habitude de debuguer à coup de console.log.

Aussi, combien de fois avons-nous été confronté à des problèmes utilisateurs sans les comprendre réellement ?

Et si je vous disais qu'il existe de nombreuses autres façon de debuguer votre front et que de nombreuses astuces autour de votre navigateur peuvent vous aider tous les jours ?

Durant ce temps, nous aborderons différentes aspects des Chrome DevTools pour que vous ne soyez plus démunis face à un front récalcitrant et pour vous faire gagner en expérience développeur.

Gérer des dates en JavaScript, c'est la prise de tête garantie : fuseaux horaires qui dérapent, mutations silencieuses qui te poignardent dans le dos, et un objet Date vieillissant de 30 ans — hérité de Java.

L'API Temporal débarque enfin en Stage 4 — et elle change tout. Un setMonth(1) sur le 31 mars qui retourne le 3 mars ? Terminé. Types dédiés, immutabilité, gestion explicite des timezones.

Dans ce talk, on retrace son voyage (du Stage 0 TC39 à ton navigateur), et on voit concrètement ce que ça change dans ton code au quotidien.