React Paris 2026

Dev, cloud & sécu26–27 mars 2026Paris, Pullman Paris Montparnasse3e édition

Site officiel (nouvel onglet) ↗Programme (nouvel onglet) ↗Chaîne YouTube (nouvel onglet) ↗Synthèse de mars 2026 →

Conférence internationale en anglais, mono-track, organisée par BeJS (équipe de React Brussels) ; ~500 participants annoncés, 22 talks + 1 panel, et un workshop React Query la veille (25/03).

Le front React à l'ère des agents : l'IA écrit de plus en plus de code, si bien que la valeur se déplace vers le jugement, les garde-fous déterministes (types, lint, tests de perf, Knip) et le retour à la plateforme web native, sur fond de montée en puissance de l'écosystème TanStack et de Vite/Rolldown.

23 sessions résumées · 23 vidéos · mise à jour le mercredi 7 octobre 2026 · synthèse à compléter

Sources lues et limites de cette synthèse

Corpus : Programme officiel (react.paris) et 22 transcripts sur 23 des vidéos de la playlist officielle « React Paris 26 » (chaîne BeJS, toutes publiées le 01/04/2026), complétés par la page de présentation de Mark Erikson (slides + vidéo), l'article de Nadia Makarevich dont son talk reprend le titre, et deux mentions dans la newsletter This Week in React (#275 et #276).

Limites : Aucun retour de participant trouvé : les résumés décrivent ce qui a été dit sur scène (sous-titres automatiques anglais, parfois bruités), pas la réception par le public. La session de Nadia Makarevich est résumée à partir de son article de blog homonyme (octobre 2025), sans vérification du contenu exact du talk. Le workshop de Dominik Dorfmeister (25/03) n'est pas documenté.

Synthèse globale

Synthèse établie à partir des transcripts des talks (ce qui a été dit sur scène) : aucun retour de participant n'a été trouvé à ce jour.

1. L'IA partout, mais surtout comme question de jugement

Près d'un talk sur deux parle d'IA, rarement pour la célébrer sans réserve. Le fil commun : quand le code devient abondant, la valeur se déplace vers le jugement. Una Kravets ouvre sur « savoir quoi construire » plutôt que la syntaxe ; Gabriel Pichot rappelle que le goulot « n'a jamais été la frappe mais la compréhension » ; Bree Hall défend le « goût » du développeur, que l'IA n'a pas. Kawtar Choubari dresse le catalogue des anti-patterns React que l'IA reproduit (useEffect superflus, accessibilité oubliée), et Dominik Dorfmeister note que l'IA génère beaucoup de code mort.

2. Les garde-fous déterministes comme contrepoids

La réponse partagée à l'IA n'est pas un meilleur prompt mais un outillage qui ne ment pas : TypeScript strict et lint à zéro erreur (Kitze, Choubari), types inférés de bout en bout (Tanner Linsley), Zod, plafonds de tours et validation humaine des actions destructives (Ankita Kulkarni, après un script qui aurait effacé ses données), Knip en CI (Dorfmeister), domain-lint pour les frontières entre features (Pichot).

3. Le front devient une interface pour agents

Plusieurs talks traitent l'agent comme un second utilisateur du front. Susanna Wong présente WebMCP, où l'app React expose ses fonctions comme outils ; Tanner Linsley conçoit le CLI de TanStack comme un serveur MCP ; Ankita Kulkarni pilote son activité via un bot Telegram outillé. Nikhil Sharma prend le contre-pied en appliquant du machine learning classique à la réconciliation React elle-même.

4. Performance : mesurer, puis verrouiller

Bloc fort de la fin du jour 1 : Mark Erikson montre une démarche quasi scientifique (benchmark, profiling, une hypothèse à la fois) pour gagner ~40 % sur Immer ; Nicolas Dubien transforme chaque régression corrigée chez Pigment en test end-to-end (fuites mémoire, compteur de rendus, long tasks). Côté données, Dan Neciu raconte comment des invalidations en cascade ont saturé une base, et Rody Gosset combine prefetch serveur et cache client pour supprimer les spinners. Le talk de Nadia Makarevich interroge le gain réel des Server Components (non vérifié sur transcript).

5. Écosystème : TanStack et Vite au centre, la stabilité revendiquée

TanStack traverse l'édition : Query (Neciu, Gosset, Dorfmeister), Router (migration PayFit), Start avec la première présentation publique de ses server components (Linsley, relayé par This Week in React). Côté outillage, Elise Patrikainen présente la chaîne Rust de VoidZero (Oxc, Rolldown, Vite 8, Vite+). Rom Brillout (Vike) et Daishi Kato (Zustand, Jotai, Valtio) défendent des primitives stables et des cœurs minimaux face aux frameworks qui imposent leurs choix. La plateforme web n'est pas en reste : CSS natif (Kravets), réfraction Liquid Glass en SVG (Chris Feijoo), accessibilité de l'authentification (Ramona Schwering).

6. Architecture et organisation : simplifier avant de fédérer

Deux retours d'expérience se répondent. Chez PayFit, Nicolas Beaussart-Hatchuel a tué les micro-frontends (32 dépôts, 6 bundlers) au profit d'un monorepo Nx, en misant sur la confiance (« never mandate, prove »). Chez Tesla, Taylor Quinn-Bohmann recourt à Module Federation pour partager un composant entre équipes, tout en reconnaissant qu'un monorepo suffit pour une seule équipe. Le choix dépend de l'organisation plus que de la technique.

7. Tensions et critiques

  • Maturité de l'IA : Kitze juge que les modèles ne plafonnent pas et Susanna Wong que l'humain n'est plus le goulot ; au panel, Nicolas (PayFit) la voit s'effondrer au-delà de 3 dépôts et Faris Aziz la juge loin d'être prête pour la finance.
  • Juniors : Kitze déconseille l'IA aux stagiaires et juniors ; Taylor Quinn-Bohmann défend leur embauche pour former des « systems thinkers ».
  • Inégalités de budget : l'écart entre entreprises tient aux licences et rate limits (panel).
  • Soutenabilité de l'open source : licence payante pour les grandes entreprises chez Vike, maintenances reprises par Daishi Kato et Mark Erikson.
  • Biais du corpus : synthèse fondée uniquement sur les propos des speakers ; la réception par le public reste inconnue.

Actions concrètes citées

  1. Encadrer le code généré par des garde-fous déterministes : TypeScript strict, zéro erreur ESLint, plan mode, relecture systématique (Choubari, Kitze).
  2. Chasser les useEffect inutiles et calculer les valeurs dérivées pendant le rendu : c'est l'anti-pattern n°1 du code React produit par l'IA (Choubari).
  3. Lancer npx knip (en mode production) pour supprimer le code mort, que l'IA produit en abondance (Dorfmeister : 28 000 lignes en 6 semaines chez Sentry).
  4. Transformer chaque régression de performance corrigée en test end-to-end : sondes de fuite mémoire, compteur de rendus, absence de long tasks (Dubien).
  5. Mesurer avant d'optimiser : benchmark, profiling, une hypothèse à la fois (Erikson, gains de 40 % en moyenne sur Immer sans changer l'API).
  6. Préférer une réponse de mutation qui renvoie l'état complet (setQueryData) à des cascades d'invalidateQueries (Neciu : de 16 requêtes par action à 0).
  7. Combiner prefetch serveur en streaming et cache client pour tuer le spinner (Gosset).
  8. Aller au natif d'abord en CSS (scroll-state queries, anchor positioning, interest invokers, view transitions) avant d'ajouter du JavaScript (Kravets).
  9. Pour une migration à grande échelle, prouver plutôt qu'imposer : démos régulières, early adopters, strangler fig (Beaussart-Hatchuel, PayFit).
  10. Tester l'accessibilité du login au lecteur d'écran, laisser les gestionnaires de mots de passe fonctionner et éviter les champs OTP à 6 cases (Schwering).

Session par session

Jeudi 26 mars

Conférence▶ vidéo + transcript

Little Big Things: Building A Great UX With Modern CSS

Una Kravets — Google

  • Point de départ : avec l'IA, la syntaxe compte moins et savoir quoi construire compte davantage. Trois principes UX structurent le talk : réduire le bruit, guider, personnaliser.
  • Réduire le bruit : sur Google Photos mobile, header, filtres et pop-up occupent près de 40 % de l'écran. Les scroll-state queries (Chrome 144+) permettent une barre qui se cache sans JavaScript ; scroll-driven et scroll-triggered animations complètent l'arsenal.
  • UI en couches : Popover API, anchor positioning (désormais dans tous les navigateurs), anchored container queries, border-shape (Chrome 147), et les interest invokers (interestfor) pour des hover cards accessibles à la souris, au clavier et à l'appui long.
  • Guider : sibling-index() pour décaler les animations, linear() pour des ressorts, un scroll spy en deux lignes avec scroll-target-group, des view transitions scopées pour les morphings.
  • Personnaliser : light-dark(), fonctions CSS custom (@function + if()), contrast-color(), customizable select (appearance: base-select).
  • Conclusion : « reach for native first ».
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

React Will Not Solve Your Problems

Gabriel Pichot — CraftValue

  • Contexte : back-offices, outils internes et legacy B2B. Un formulaire de deux champs qui empile React Hook Form, Zod, TanStack Query et trois hooks custom illustre le coût cognitif des librairies, lourd surtout pour un junior.
  • Appui sur la théorie de la charge cognitive (intrinsèque, extrinsèque, germane). Choisir une librairie qui ne résout pas votre problème (Redux pour du data fetching) ajoute de la complexité.
  • Sur l'IA : elle fait aller plus vite, « but faster in the wrong direction » ; le goulot n'a jamais été la frappe mais la compréhension. Certains coéquipiers ne relisent plus les tests générés.
  • Deux outils construits avec l'IA : des « widget object models » (inspirés des page objects Playwright) partagés entre Testing Library et Playwright, et domain-lint, une CLI open source qui mesure cycles d'imports et violations de frontières entre features.
  • Message : aucun outil ne résoudra vos problèmes ; choisir la librairie alignée sur le problème et utiliser l'IA pour faire remonter l'information.
Voir sur YouTube (nouvel onglet) ↗

Lightning talk▶ vidéo + transcript

React Anti-Patterns In AI-Generated Code

Kawtar Choubari — Alobees

  • Les outils d'IA choisissent React, Next.js, Tailwind et shadcn par défaut, car React domine les données d'entraînement, y compris des tutoriels datés.
  • Causes des anti-patterns : pas de visibilité sur le runtime (re-renders), code correct composant par composant mais confus une fois assemblé, biais « happy path » (ni cleanup, ni validation, ni accessibilité).
  • Anti-pattern n°1 : le useEffect (trois useState et deux effets chaînés pour des valeurs qu'on peut calculer au rendu). Autres cas : index comme key, fetch sans cleanup (race conditions), count && … qui affiche « 0 ».
  • Le plus dangereux car il passe en revue : l'accessibilité (div cliquable, modale sans gestion du focus, input sans label). Réponse : HTML sémantique et ARIA.
  • Garde-fous : ESLint, Git hooks, TypeScript strict, règles Cursor et agent skills, plan mode et auto-critique avant de générer, relecture systématique, sessions de refactoring régulières.
Voir sur YouTube (nouvel onglet) ↗

Lightning talk▶ vidéo + transcript

Liquid Glass In The Browser: Refraction With CSS & SVG

Chris Feijoo — kube.io

  • Histoire de la lumière dans les interfaces : Windows 95, XP, Aqua, Aero (premier flou temps réel), flat design, puis Liquid Glass d'Apple en 2025.
  • Base physique : la loi de Snell-Descartes (air n = 1, verre n = 1,5). On donne à l'objet un profil de bord, on lance des rayons sur une moitié (symétrie), on normalise les déplacements pour obtenir un champ de vecteurs.
  • Ce champ devient une displacement map pour le filtre SVG feDisplacementMap (X dans le rouge, Y dans le vert, 128 comme valeur neutre) ; un vecteur de lumière ajoute le reflet spéculaire.
  • Démos : loupe, switch, slider, lecteur de musique. Annonce de Refractive, librairie en pré-alpha orientée performance.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Share Once, Ship Everywhere: Federated UI at Scale

Taylor Quinn-Bohmann — Tesla

  • Contexte : la recharge de véhicules électriques. Deux applications, développées par deux équipes, affichent pour le même site et le même jour 250 sessions d'environ 3 h 30 contre 315 sessions de 47 minutes : une logique métier divergente (un filtre sur les sessions de moins de 5 minutes).
  • Un composant partagé sur npm unifie l'UI mais pas les données, et ajoute couplage au déploiement et écarts de version ; les iframes cloisonnent trop.
  • Solution : Module Federation (2.0, découplée du bundler). Le composant fait son propre fetch et s'adapte au rôle ; le host ne fournit que l'identité (token SSO, site), et l'API amont vérifie les claims.
  • Vigilance : erreurs au runtime (error boundaries), déploiements immédiats qui imposent de traiter l'UI comme une API rétrocompatible, debug plus difficile. Pour une seule équipe, un monorepo suffit.
  • QA : Storybook par PR, types générés par Module Federation 2.0 vérifiés en CI, monitoring du chargement de remoteEntry.js.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Killing Micro-Frontends: How Radical Simplification 10x'd Our Frontend Velocity

Nicolas Beaussart-Hatchuel — PayFit

  • Départ chez PayFit (~100 ingénieurs) : CI de 45 minutes et instable, 2 à 5 jours pour mettre une PR en prod, 5 façons de faire du micro-frontend, 32 dépôts pour une app, 6 bundlers, et un premier monorepo imposé qui a échoué.
  • Remise en ordre : Vite avec config verrouillée, versions unifiées (l'équipe était bloquée sur React 16), Nx pour generators, graphe et conformance. Avec Nx Cloud, la CI passe de 45 à 7 minutes et les tests flaky deviennent mesurables.
  • La confiance avant la migration : démos publiques presque chaque mois pendant 2 ans, roadmap publique, early adopters accompagnés, migration par clusters repérés dans le graphe du système.
  • Mesurer le « cargo cult » : la file de merge tenait dans un Google Doc (3 h en moyenne) ; Mergify la ramène à 20-25 minutes. Une seule approbation par défaut, revue imposée sur les zones critiques.
  • React Router v5 (286 routes) vers TanStack Router selon le strangler fig pattern : 4 mois, plus de 20 bugs de query params révélés, 245 providers custom supprimés.
  • Résultats annoncés en 2 ans avec 2,5 ingénieurs : 15 à 20 déploiements par jour, 92 Mo de JavaScript en moins, 5 s gagnées au chargement. Leçon : « never mandate, prove ».
Voir sur YouTube (nouvel onglet) ↗

Lightning talk▶ vidéo + transcript

Killing The Spinner: Hybrid Data Fetching For Better UX

Rody Gosset — Muséum national d'Histoire naturelle

  • Exemple : « Muse », l'application de gestion des prélèvements et prêts de spécimens du Muséum.
  • Rendu client seul : chargement initial lent mais navigation instantanée grâce au cache. Rendu serveur seul (RSC, streaming) : affichage initial rapide, mais chaque navigation repasse par le serveur.
  • Approche hybride : prefetch dans un Server Component sans await, query client déshydraté dans un HydrationBoundary, promesses en streaming, useSuspenseQuery côté client (pattern « Advanced Server Rendering » de TanStack Query).
  • Résultat de la démo : le streaming du serveur et la navigation instantanée du client ; un cache persisté rapproche du local-first.
  • Conseil final : les spinners sont un fallback, pas l'état par défaut.
Voir sur YouTube (nouvel onglet) ↗

Lightning talk▶ vidéo + transcript

How Not To Use TanStack Query

Dan Neciu — CareerOS

  • Histoire vraie : un CRM gamifié pour étudiants, passé de React Context à TanStack Query. Avec plus de 100 types d'actions de gamification, chaque mutation déclenchait au moins 12 invalidateQueries. « The problem was it worked ».
  • Aux pics de rentrée, CPU de la base à 100 % ; l'équipe soupçonne SQL et monte l'infrastructure (5 à 10 k sur GCP pour 300 utilisateurs quotidiens) avant de voir le bon indicateur : 1 400 requêtes par seconde.
  • Correctifs successifs : file qui regroupe les invalidations (66 à 11 requêtes), abort, désactivation ciblée du retry par défaut.
  • La vraie solution, revenir aux bases de REST : le POST renvoie l'état complet, setQueryData met le cache à jour (16 requêtes par action à 0).
  • Idées reçues corrigées : staleTime: 0 ne refetch pas à chaque rendu, gcTime concerne le garbage collection. Conseil : query keys hiérarchiques et onglet Network ouvert.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Oxc, Rolldown, Vitest, Vite: The Future of The JavaScript Toolchain

Elise Patrikainen — WeSave

  • Problème : un outillage JS fragmenté. Vite combinait esbuild (rapide, peu de contrôle), Rollup (riche mais ~40 fois plus lent) et SWC, d'où complexité et écarts dev/prod.
  • VoidZero (fondée par Evan You) réécrit une chaîne unifiée en Rust. Oxc regroupe parser (3 fois plus rapide que SWC), resolver, transformer, minifier, linter (650+ règles) et formatter (beta).
  • Rolldown, bâti sur Oxc : quasi aussi rapide qu'esbuild avec les optimisations de Rollup (~35 fois plus rapide que Rollup sur un benchmark de 19k modules).
  • Vite 8 fait de Rolldown le bundler par défaut, « le plus gros changement d'architecture depuis Vite 2 » ; un mode dev « full bundle » expérimental vise un build identique en dev et prod.
  • Vite+, désormais open source : une config unique et une CLI vp (création de monorepo, vp check, task runner avec cache). Selon Jeff Cross (Nx), interrogé par la speakeuse, il couvre 80 à 90 % des cas, en local seulement.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

How I Made Immer Twice As Fast: Performance Optimization In Practice

Mark Erikson — Replay.io

  • Fin 2024, un utilisateur signale que Redux avec Immer serait 100 fois plus lent que du code immuable écrit à la main ; Mark Erikson reprend l'enquête.
  • L'investigation de performance est du debugging : comprendre, reproduire, une hypothèse, un changement à la fois.
  • Le benchmark (Mitata, une vingtaine de scénarios, Immer v5 à v10) confirme une dégradation à partir de la v8. Piège : les accès à process.env.NODE_ENV sous Node faussaient les mesures.
  • Le profilage révèle que isPlainObject prend 2 s sur un benchmark de 30 s. Cache de ce test, Object.keys, sorties anticipées : ~20 % gagnés en quelques lignes ; puis nettoyage des proxies inspiré de Mutative et plugin d'override des tableaux.
  • Total : de 5 % à 79 % de gain (~40 % en moyenne) dans Immer 10.2 à 11.1, sans changer l'API publique. « I was the one who actually took the time and did the work. And so can you. »
  • Il présente aussi Replay MCP, qui permet à des agents d'analyser les rendus React d'un enregistrement.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Chasing Performance Drifts

Nicolas Dubien — Pigment

  • La performance a un impact business : exemples cités de Google (100 ms, -20 % de trafic), Amazon (100 ms, -1 % de ventes) et Figma (une ligne de CSS qui divisait les performances par 3).
  • Le sujet n'est pas le correctif mais ne jamais réintroduire une régression.
  • Fuite mémoire (un listener keydown mal retiré) : un hook interne useLeakProber pose des sondes WeakRef ; un test Cypress force le GC et vérifie que le nombre de sondes vivantes n'augmente pas après un parcours.
  • Re-rendus en cascade dans une grille : un compteur de rendus par type de composant, avec une assertion (au plus 2 cellules re-rendues par déplacement).
  • Scroll lent : détection des long tasks (plus de 50 ms) via PerformanceObserver, vérifiée après chaque test end-to-end.
  • Ces tests restent un dernier filet ; tests unitaires, revue, lint et analyse statique doivent attraper les problèmes avant.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Behind The APIs: How Zustand, Jotai, and Valtio Were Born

Daishi Kato

  • Depuis l'arrivée des hooks (2018), Daishi Kato se concentre sur la gestion d'état et le data fetching. Ses premières libs (React Hooks Global State, React Tracked) lui apprennent qu'un comportement caché crée un décalage avec les attentes.
  • Il reprend la maintenance de Zustand en 2020 ; la v3 stabilise une API minimale à sélecteurs, inchangée depuis.
  • Jotai naît après Recoil (clés en string jugées inadaptées) : API calquée sur useState, force des atomes dérivés en graphe de dépendances. Valtio rend le proxy explicite (snapshots immuables, Suspense).
  • Les trois libs se placent sur un spectre d'optimisation : sélecteurs manuels, atomes intermédiaires, tracking automatique ; même philosophie de cœur minimal.
  • Q&R : les signals TC39 sont des valeurs, les atomes des définitions ; à titre personnel, il choisirait Jotai.
Voir sur YouTube (nouvel onglet) ↗

Vendredi 27 mars

Conférence▶ vidéo + transcript

The Cake Is A Lie... And So Is Your Login's Accessibility

Ramona Schwering — Auth0

  • Cocher des cases (European Accessibility Act) ne veut pas dire être accessible. Le handicap est un spectre qui concerne tout le monde à un moment (gouttes dans les yeux, bruit, enfant dans les bras).
  • Démo VoiceOver : l'erreur de login n'est pas annoncée. Correctif : role=alert, aria-invalid, aria-describedby, et du HTML sémantique.
  • Les gestionnaires de mots de passe sont des technologies d'assistance : préserver l'autofill. Pour les daltoniens, des icônes plutôt qu'une bordure colorée.
  • CAPTCHA : charge cognitive et dépendance culturelle ; préférer des défis invisibles ou fondés sur le risque.
  • MFA : codes valables au moins 60 s, copier-coller autorisé, alternative texte aux QR codes. Les champs OTP à 6 cases cassent le collage et sont mal lus par les lecteurs d'écran.
  • Toujours proposer plusieurs méthodes (magic links, passkeys) : aucun facteur n'est parfait.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Coding For The Senses

Bree Hall — Atlassian

  • Une to-do list devient une « quête » façon Donjons et Dragons : la différence n'est pas fonctionnelle mais ressentie, construite autour des cinq sens.
  • Vue : React Three Fiber et drei pour des dés en 3D, useFrame pour animer sans 60 re-rendus par seconde. Toucher : GSAP pour l'impératif, React pour le cycle de vie (useGSAP).
  • Son : jamais seule porte d'entrée ; boucles génératives Tone.js sur une gamme pentatonique.
  • « Odorat » : l'identité d'ensemble ; changement de thème via View Transitions, avec flushSync pour éviter d'animer l'ancien état (ViewTransition disponible depuis React 19.2).
  • « Goût » : celui du développeur. L'IA aide à construire mais n'a pas le goût pour juger une expérience cohérente ; question finale : « how should it actually feel? ».
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Vike: React Framework For Building Advanced Apps With Stability & Flexibility

Rom Brillout

  • Critique des frameworks qui imposent leurs priorités (Next.js, Vercel, Server Components) : « A good piece of software is a piece of software you forget, not something you constantly fight. »
  • Vike propose des briques assemblables avec de bons défauts, sur des primitives stables (SSR, SSG, streaming, routing), agnostique de l'UI et du déploiement ; côté serveur, un simple middleware.
  • Cas clients : Ecosia (migration page par page de Vue 2 à Vue 3), un réseau social sur Rails en hybride, Contra avec Relay, un groupe média allemand qui a bâti son framework interne dessus.
  • Telefunc (« it's just a function ») : RPC, upload avec progression, streaming de chat IA, temps réel (en partie en beta).
  • Modèle économique : MIT et gratuit pour les petites équipes, licence payante pour les grandes entreprises ; travail en cours sur Universal Deploy pour les frameworks basés sur Vite.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

TanStack Start: A Client-First Web Framework

Tanner Linsley — TanStack

Retours : Newsletter This Week in React #275

  • Type-safety par inférence : presque plus d'annotations, ce qui protège aussi d'une IA qui « is just going to write whatever the heck it wants ».
  • Client-first : Start est « 80-90 % TanStack Router », une SPA à laquelle on ajoute le serveur là où il sert (SSR et streaming, routes API, server functions RPC avec validation obligatoire, middleware, loaders isomorphes).
  • Côté IA : plutôt que de faire générer un projet par un agent, utiliser le CLI conçu comme un serveur MCP (docs, skills).
  • Annonce inédite : des server components vus comme de « simples streams » cachables via useQuery, et des « composite components » sans use client ; pas de server actions, pour raisons de sécurité. La newsletter This Week in React (#275) relaie cette première présentation publique du support RSC.
  • 1.0 annoncée imminente après 5 ans de développement ; Solid supporté, Vue presque prêt.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

From Vibe Coding To Vibe Engineering

Kitze — Sizzy

  • Thèse provocatrice : « LLMs are actually good at writing React because there's no good way of writing React ».
  • Vibe engineering : tout générer avec des agents, mais relire avec méfiance. Plus de 20 apps en 365 jours, dont environ 4 utiles ; le vibe coding pur reste bon pour des outils jetables.
  • Garde-fous : commits fréquents, git worktrees, types et lint à zéro erreur, fichiers de 200 lignes max, méfiance quand l'agent désactive des règles ; taguer docs et code dans chaque prompt, dictée vocale.
  • Pourquoi certains détestent le vibe coding : mauvais timing, budget insuffisant, et surtout une « skill issue ».
  • Positions tranchées : contre l'IA pour les stagiaires et juniors ; les modèles ne plafonnent pas, mais la maintenance de legacy restera bien payée.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Humanizing React Apps With AI-Powered Reconciliation

Nikhil Sharma — Deel

  • Idée : utiliser un petit modèle TensorFlow au service de la réconciliation React, pour décider si un rendu vaut la peine (et non des features IA pour l'utilisateur).
  • Démo 1 : le modèle prend en entrée vitesse de scroll, clics, likes et fréquence de mise à jour pour filtrer les rendus d'une liste ; argument contre le if/else : au-delà de 10 à 20 facteurs pondérés.
  • Démo 2 : pré-chargement prédictif de composants lazy selon les widgets les plus cliqués. Démo 3 : batching des mises à jour piloté par un réseau de neurones.
  • Précautions : l'IA est « une secrétaire » de React, pas un remplaçant ; repli sur le comportement normal si l'erreur est trop grande, entraînement côté serveur ou en web workers. Exemples présentés comme « contrived ».
  • Formule finale : « the best render is like no render at all ».
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

My AI Agent Toolkit For Building Minions

Ankita Kulkarni

  • Un « minion » est un agent autonome dans des limites (« autonomous doesn't mean uncontrolled ») : contexte, mémoire, outils, cerveau.
  • Stack : Next.js, TypeScript, Zod, Convex pour journaliser chaque étape, Sentry, cron Vercel, SDK Anthropic. La boucle d'agent n'est qu'une boucle while avec un switch sur les outils.
  • Cas réel : un bot Telegram vérifie si son cours Next.js est à jour, dispose de 9 outils (rembourser, inscrire, statistiques) et ouvre des PR qu'elle relit ; nombre de tours plafonné.
  • Incident : un script de migration généré aurait supprimé toutes ses données. Règles depuis : validation humaine des actions destructives, backups, permissions limitées, rate limiting, escalade après 5 échecs, logs complets.
  • Conseil : commencer petit, car « the best agent… is the one that actually ships ».
Voir sur YouTube (nouvel onglet) ↗

Table ronde▶ vidéo + transcript

ConTejas AI Panel

Tejas Kumar — IBM (animateur), Una Kravets — Google, Faris Aziz — Smallpdf, Nicolas Beaussart-Hatchuel — PayFit, Taylor Quinn-Bohmann — Tesla

  • Panélistes identifiés dans le transcript par leur prénom et leur entreprise (seul le nom de Faris Aziz est prononcé ; les autres correspondent aux speakers de l'édition).
  • Una Kravets : l'IA est en retard sur le CSS moderne à cause des délais d'entraînement ; elle compense avec un fichier agents et des skills.
  • Faris Aziz : 41 % des CFP de ZurichJS mentionnent l'IA, souvent superficiellement ; chez Smallpdf, il juge l'IA loin d'être prête pour la finance (risques juridiques, licences).
  • Nicolas (PayFit) : un agent lancé chaque nuit pendant un mois a retiré un Redux legacy ; mais avec 892 repos, « bonne sur 1 repo, OK sur 2, s'effondre à 3 ». L'écart entre entreprises tient surtout au budget et aux rate limits.
  • Taylor (Tesla) : 4 sessions Claude Code en parallèle, dont l'astreinte via MCP (Splunk, Confluence, GitHub) ; le plaisir de coder « s'est déplacé ».
  • Débat sur les juniors et le plaisir de coder : Taylor défend leur embauche pour former des « systems thinkers » ; Faris pointe des politiques d'entreprise floues (quotas de tokens, IA en entretien).
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

React at Warp Speed: How Chrome MCP + AI Became My Frontend Superpower

Susanna Wong — Typeform

  • Son talk initial sur Chrome DevTools MCP a « mal vieilli » en 3 mois : les agents lancent désormais eux-mêmes un navigateur pour vérifier leur code, l'humain n'est plus le maillon faible de la boucle de test front.
  • Le code n'est plus une ressource rare : une remise à zéro du métier plutôt que sa fin, selon elle.
  • Un deuxième utilisateur, les agents : le front devient « an execution service », mais les agents le parcourent par captures d'écran ou parsing du DOM, fragiles et coûteux.
  • Chrome DevTools MCP (septembre 2025, Puppeteer + CDP) permet une boucle mesurer, diagnostiquer, corriger.
  • WebMCP : l'app React expose ses fonctions comme outils (nom, description, schéma), avec l'authentification de la session ; humain et agent partagent le même state (exemple Typeform « add question »). Vigilance : sécurité, outils atomiques et idempotents ; API encore en preview.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Dead Code Shouldn't Exist: How We Removed 28k Lines of Code, One Knip at a Time

Dominik Dorfmeister — Sentry

  • Talk volontairement sans IA. Le code mort a un coût : charge cognitive, upgrades et règles de lint plus pénibles ; l'IA en produit beaucoup en abandonnant ses tentatives, et TypeScript ne voit pas les exports inutilisés.
  • Knip construit un graphe depuis les points d'entrée, avec plus de 140 plugins détectés via le package.json.
  • Démo live sur le code de Sentry : un fichier passe de 565 à 191 lignes en relançant Knip jusqu'à « no issues ». Le mode production (ignore le code utilisé seulement par les tests) a fourni plus des 2/3 des suppressions.
  • Frictions : code ajouté « pour plus tard », exports systématiques (« I've also seen AI do this a lot »), imports dynamiques supprimés à tort puis restaurés.
  • Bilan : ~50 PR en 6 semaines, ~28 000 lignes supprimées (~3 % d'un front d'un million de lignes). Pour démarrer : npx knip.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo

React Server Components: Do They Really Improve Performance?

Nadia Makarevich

  • Résumé établi à partir de l'article homonyme de la speakeuse (developerway.com, octobre 2025), le transcript n'ayant pu être récupéré : le contenu exact du talk n'est pas vérifié.
  • Méthode de l'article : une app multi-pages avec données dynamiques, mesurée en CPU ralenti 6x et Slow 4G, en comparant CSR, SSR (fetch client ou serveur), Next.js Pages et App Router.
  • Résultats de l'article : le CSR affiche un LCP de 4,1 s sans cache ; l'App Router avec Suspense descend à 1,28 s, mais un écart d'interactivité d'environ 2,4 à 2,5 s demeure (page visible, JavaScript pas encore chargé).
  • Conclusion de l'article : les Server Components seuls n'apportent pas de gain mesurable ; le bénéfice vient du streaming avec des frontières Suspense et d'une refonte du data fetching côté serveur.
Voir sur YouTube (nouvel onglet) ↗

Sessions sans retour trouvé (1)

  • Workshop React Query - Beyond The Basics (Dominik Dorfmeister, 25/03, non filmé)

Sources