Le Studio Devoxx France

Nicolas Grenié, Developer Advocate chez SLNG.ai, passé par Typeform, alias "Monsieur BuildShit", raconte au Studio Devoxx France comment le vibe coding a changé sa façon de construire des logiciels.

Dans cette conversation, il l'assume : "quand je vibe code, je regarde le code ? Presque jamais". Prototypes lancés depuis la maternité, générateur d'icônes à 15 000 utilisateurs, faille de sécurité corrigée en une soirée. Et quand un exec veut shipper le proto en prod le lendemain, qui tranche ?

Au programme :

- Ce que le bagage technique change quand on vibe code
- Du proto à la prod : sécurité, permissions, dette invisible
- Comment Typeform a mis le prototypage entre les mains des PM
-Pourquoi le dev garde le dernier mot sur ce qui part en prod
- Le developer advocate face à un "client" qui hallucine

"Done is better than perfect" : la formule qui coûte le plus à un ingénieur français.

00:00 Nicolas et son parcours de Developer Advocate
02:08 Mr BuildShit
03:11 Definition de Vibe Coding et bagage technique
06:27 Ta première expérience Vibe Coding
08:24 Lovable
09:17 La relation aux prototypes
12:55 L'ouverture des possibles y compris le vibe coding de bébés
14:56 Comment filtrer ce flux de prototypes
18:12 Ce flow en entreprise
20:27 Du proto à la sécurité
22:31 Une barrière de qualité ?
25:45 Un outil pour PM, un outil de recherche
27:56 Le syndrome on shippe en prod
31:14 Revue de vibe code ou pas ?
33:07 Travail d'équipe interdisciplinaire, la mort du spécialiste ?
35:34 La developer advocacy à l'heure de l'IA
39:13 Le prochain projet de Nicolas
40:25 Les inquiétudes des développeurs
45:32 Les questions rituelles

Tiffany Souterre, Olivier Leplus et Arnaud Jean, developer advocates chez AWS, démontent pour le Studio Devoxx France l'architecture derrière leur workshop : un Maître du Jeu de Donjons & Dragons qui orchestre plusieurs agents IA, avec MCP, A2A et RAG.

Ils racontent comment un orchestrateur distribue le travail à des agents spécialisés, et pourquoi le vrai enjeu n'est pas l'agent qui impressionne en démo mais le système qu'on déploie en prod notamment via l'observabilité.

Au programme :
• Orchestration, chorégraphie ou workflow : qui appelle qui
• MCP pour outiller un agent, A2A pour les faire dialoguer entre eux
• Le RAG est loin d'être mort : la fiabilité quand les règles comptent
• Pannes, contradictions et fallbacks quand on passe à l'échelle
• Observabilité : lire les traces pour voir l'agent raisonner

"MCP, c'est le HTTP des agents".

00:00 Les agents au moyen age
01:58 Systèmes agentiques et orchestration
05:54 Orchestration vs Chorégraphie vs Workflow
09:31 Les grosses évolutions des architectures des agents
12:06 Les protocoles MCP et A2A dans la danse agentique
15:46 Lancement de la version 1.0 de A2A
16:01 RAG, c'est fini ou pas ?
19:18 RAG et contradictions
22:01 Les modes de déploiement des agents
24:22 Modes d'erreurs nouveaux ou vieux comme le monde
26:13 Le rôle clé de l'observabilité

Rémi Forax, enseignant-chercheur à l'Université Gustave Eiffel et membre d'OpenJDK, raconte au Studio Devoxx France douze ans de Project Valhalla et l'arrivée des value class en Java 28.

Modifier la JVM coûte "affreusement cher", le problème des nuls a fait dérailler des prototypes entiers, et la compatibilité ascendante reste la règle du jeu, pas une frustration.

Au programme :
• Ce qu'est une value class : pas d'identité, manipulée par valeur
• Pourquoi Valhalla a mis douze ans : prototypes, erasure, impasses assumées
• Le casse-tête des nuls : alignement, atomicité, surcoût d'un octet
• Ce que Java 28 livre en preview (JEP 401), et ce qui manque encore
• Lilliput, Leyden, CRaC : la suite pour la JVM

"Invoke dynamic n'existe que parce que Sun est mort", quand les vraies features mûrissent sans deadline.

00:00 Présentation de Rémi Forax : enseignant-chercheur
01:17 Plongée dans les Value Class
04:20 La question identitaire de la Value Class
08:52 12 ans pour Value Class, pourquoi ?
11:56 Compatibilité ascendante, la plaie ?
16:58 Gestion des Exceptions et Compatibilité Ascendante
21:46 Le problème des nuls dans les Value Class
26:31 Plus de 64 bits, l'impact sur les performances
28:14 Ce qu'il y a dans Java 28
41:58 Le temps de la recherche
44:19 Le futur au delà de 28
56:16 Les questions rituelles

Rémi Forax, maître de conférences à l'Université Gustave Eiffel et membre d'OpenJDK, raconte pour le Studio Devoxx France comment il a codé LazyLR, sa lib de parsing de grammaire, avec un LLM, sans renoncer au design.

Dans cette conversation, il défend une approche bottom-up : "le LLM doit faire toute l'équipe autour du chirurgien". Pas de vibe coding, du TDD, des blueprints en code, un contexte taillé court pour empêcher le modèle de dériver. Et un retour cash sur ce que les LLM cassent dans l'enseignement.

Au programme :

• LazyLR : un parser LR qui construit son automate à la volée, sans étape de build
• Contextual lexing : quand le parser souffle au lexer ce qu'il a le droit de voir
• Pourquoi les vrais parsers de prod sont toujours réécrits à la main
• Sa méthode Claude Code : blueprints en code, design notes, dépendances ciblées
• OpenJDK interdit les LLM : ce que les faux bug reports d'ASM révèlent
Étudiants biberonnés au LLM : la béquille qu'on ne sait plus enlever

"Faut pas qu'il génère un code parfait, faut qu'il sache expliquer à un humain pourquoi il est parfait." Sa ligne de crête entre productivité et compréhension.

00:00 Présentation de Rémi Forax : enseignant-chercheur
01:51 Equilibre enseignant et OpenJDK
03:46 La boucle de retour étudiant - OpenJDK
06:12 L'évolution des étudiants au fil des générations
14:41 LazyLR - un nouveau parseur LR avec boucle de design immédiate
17:03 LR, LL et Konami code
19:20 Le Lazy de LazyLR
25:38 L'aide du Lexer pour les langages modernes
27:31 Problèmes des langages modernes
29:19 Les vrai parseurs de langages font...
31:06 LLM en testeur d'etudiant moyen
32:15 LazyLR codé avec de l'IA générative
34:02 L'approche chirurgien
37:10 La boite à outil AI de Rémi
39:36 Stratégies d'interaction avec le LLM
47:27 La politique pas d'IA d'openJDK
51:11 Dans 5 ans on code comment ?

Didier Girard, directeur général du groupe Sfeir, raconte pour le Studio Devoxx France comment l'IA fait passer un site web de 100k€ en 6 mois à 1k€ en 70 heures et ce que ça change au métier de développeur.

Dans cette conversation, il pose : « le temps passé n'est plus une unité de mesure de création de valeur ». Le développeur devient product engineer, l'analyse revient, les équipes rétrécissent et la facturation bascule à l'engagement de résultat.

Au programme :
- Refaire un site web institutionnel en 4 heures avec Claude Code
- Constitution, contexte chaud, contexte froid : le context engineering
- Pourquoi SFEIR ne recrute plus quelqu'un qui refuse l'IA
- Evolution client: du temps passé au résultat
- Pizza team vs sandwich team : 2 personnes augmentées au lieu de 10

« Le 10x, c'est maintenant » pas une projection, l'état du terrain en 2026.

00:00 Introduction et Présentation de Didier Girard
01:01 De 6 mois et 100k à 70 heures et 1k pour un projet
04:07 Le besoin du context engineering
05:47 Developper, you are not
08:12 Le retour en grâce de l'analyste ?
09:46 Didier recrute quels profils ?
10:51 Moins cher ou faire plus ?
14:25 Le contexte froid, le contexte chaud
18:05 Pizza teams, sandwich teams
19:55 Les questions rituelles