dotJS 2026
Site officiel (nouvel onglet) ↗Programme (nouvel onglet) ↗Chaîne YouTube (nouvel onglet) ↗Synthèse de septembre 2026 →
Vendredi 18 septembre 2026, Folies Bergère, le lendemain de dotAI (billet combiné possible). Une journée, une seule piste : 9 talks de 20 minutes et 5 lightning talks de 10 minutes, sélectionnés par un comité éditorial indépendant.
D'après les 14 vidéos et un compte rendu d'agence, une édition partagée entre une plateforme web « abondante » qui allège l'outillage sans le supprimer (no-build progressif, Temporal, API de performance, IA dans le navigateur décidée tâche par tâche) et la confiance dans le code à l'ère des agents (npm 12, analyse du codebase entier, portes TypeScript, code généré traité comme non fiable).
14 sessions résumées · 14 vidéos · mise à jour le jeudi 1 octobre 2026 · synthèse à compléter
Sources lues et limites de cette synthèse
Corpus : Les 14 vidéos officielles publiées le 28/09 sur la chaîne dotConferences et leurs transcripts automatiques (anglais, trois lus dans une traduction automatique française), l'agenda officiel, les slides de Matheus Albuquerque, la page presse de Fallow, un post LinkedIn pré-événement du comité éditorial, cinq posts Bluesky (trois d'un participant, deux de speakers) et le seul compte rendu de contenu, celui de l'agence Premier Octet, connu uniquement par des extraits indexés (article toujours en HTTP 429 le 30/09, archive inaccessible). Le 30/09 s'ajoute un fil Mastodon de 11 posts d'un participant (Antoine D., 22/09) sur l'IA dans le navigateur ; cinq recherches web (blogs, LinkedIn, dev.to, Medium) et les recherches Bluesky et Mastodon n'ont rien trouvé d'autre. Revue du 01/10 (trois recherches web, Bluesky, tag Mastodon #dotjs, chaîne dotConferences) : aucun nouveau retour ni nouvelle vidéo.
Limites : Le contenu des talks est désormais complet grâce aux transcripts, mais la réception reste mal connue : un seul compte rendu (Premier Octet, lu indirectement), un seul retour critique détaillé (Mastodon), aucun post LinkedIn, X ou dev.to de participant, et des posts Bluesky surtout d'ambiance ou de speakers. Douze talks sur quatorze n'ont aucun retour de salle au-delà de Premier Octet. Les transcripts automatiques déforment certains noms propres (outils, entreprises) et les chiffres avancés par les speakers n'ont pas été vérifiés.
Synthèse globale
1. Une plateforme web « abondante », qui allège l'outillage sans le supprimer
Une bonne moitié de la journée porte sur ce que la plateforme sait désormais faire seule. Jad Joubran ouvre sur l'« abondance » : UI native (dialog, popover, ancres, <select> personnalisable), View Transitions entre documents, Document Picture-in-Picture, WebHID, File System Access, speculation rules. Il en fait la démonstration par l'absurde : toute sa présentation tenait dans une seule requête HTTP streamée, sans JavaScript côté client, grâce aux declarative partial updates de Chrome. Matheus Albuquerque déroule les API de mesure et d'optimisation natives, Devlin Duldulao raconte les trente ans de Date jusqu'à Temporal (livré dans V8 en janvier, ES2026 et Node.js 26).
Lea Verou clôt la journée sur le no-build, mais sans dogmatisme : le but n'est pas de supprimer les bundlers, qui gagneront toujours sur certains terrains, mais de les rendre moins indispensables et plus légers. Pour elle, le point bloquant n'est ni la transpilation ni la performance, c'est la résolution des dépendances, un « usability cliff » que la plateforme a délégué à l'outillage tiers ; elle y répond avec les import maps et son propre « unbundler », montré pour la première fois. Vishnudhasan Govindarajan apporte le contrepoint : un 100/100 Lighthouse sur MacBook ne dit rien de l'expérience sur un Android à 100 $, et brider le réseau dans les DevTools ne simule pas un appareil lent.
2. L'IA côté client : possible, mais à décider tâche par tâche
Nico Martin (Hugging Face) et Maximiliano Firtman défendent une IA locale, hors ligne et sans facture de tokens, avec des démos entièrement dans le navigateur. Les vidéos montrent un discours plus nuancé que le compte rendu de Premier Octet, qui présentait l'assistant « Jamie » comme 100 % local : Nico Martin explique que Jamie, c'est 3 Go de modèles à télécharger par origine et 3 tokens/s sur un portable haut de gamme d'il y a quelques années. Il conseille donc de garder le LLM sur le serveur et de réserver le client aux tâches « ennuyeuses » qui passent déjà partout (transcription, embeddings, détourage, filtre de données sensibles). Maximiliano Firtman arrive à la même conclusion : pas besoin d'un LLM pour tout, API intégrées quand elles existent, repli cloud toujours prêt.
Harshil Agrawal (Cloudflare) prolonge vers l'UI générative et Nikolay Rodionov (Alpic) vers les MCP apps, avec une thèse plus radicale : les sites web deviendraient une interface « legacy » face aux agents, d'où l'idée d'« expérience agentique ».
3. La confiance dans le code, fil rouge des sessions « IA »
Les transcripts confirment que la moitié « IA » de la journée parle moins de génération que de vérification. Karen Li (GitHub) détaille npm 12 (scripts, dépendances Git et URL distantes bloqués par défaut), min-release-age, trusted publishing et staged publishing. Bart Waardenburg part du même constat que Guillaume Moigneu : face au code « slop » des agents, la meilleure défense est l'outillage déterministe. Le premier le prolonge au codebase entier avec Fallow (graphe de dépendances, code mort, frontières d'architecture, couverture en production), le second en fait un argument pour TypeScript (strict mode, any interdit, validation à l'exécution par schéma). Harshil Agrawal pose trois questions à tout code généré (que peut-il atteindre, que peut-il faire, que renvoie-t-il) et l'exécute dans des isolates V8 sans accès réseau sortant. Le quiz de Thorsten Seyschab rappelle le même point sur un ton léger : as ne valide rien à l'exécution.
4. Des équipes et des agents bornés
Deux lightning talks relient architecture et organisation. Gabor Csomak présente les microfrontends comme une réponse organisationnelle (un composant, une équipe de 1 à 5 personnes, des contrats conçus comme des API back) plutôt que technique, et Guillaume Moigneu compare l'arrivée des agents à l'onboarding de juniors dans une grande organisation. Les deux ajoutent qu'un périmètre borné et documenté est aussi plus facile à lire pour un agent. Lea Verou note de son côté que les agents apprennent vite des pratiques nouvelles quand on leur fournit un fichier de skill.
5. Tensions : les navigateurs ne suivent pas tous
Plusieurs talks butent sur le même mur. Firefox et Safari s'opposent à la Prompt API (Firtman) et ne soutiennent pas File System Access (Joubran) ; Firefox ne gère pas encore les import maps multiples (Verou) ; la proposition d'annotations de types en JavaScript est au point mort faute d'accord des navigateurs. Lea Verou en tire un appel : « faites du bruit » dans les enquêtes et le processus Interop 2027. Autre tension, plus implicite : entre l'enthousiasme pour l'IA locale et les chiffres réels de téléchargement et de matériel donnés par Nico Martin.
La seule critique de salle documentée vise un angle mort. Dans un fil Mastodon, Antoine D. (participant) note que l'IA côté client déplace le calcul du serveur vers l'appareil de l'utilisateur, et qu'aucun des speakers « passionnés d'IA » n'a évoqué l'impact énergétique ou environnemental de ce choix, ce qu'il juge « complètement dingue ». Interrogés en aparté, deux speakers lui ont répondu « ah ouais, aucune idée », avec un « désintérêt poli ». Il en fait aussi un argument business : les datacenters sont mal acceptés, les smartphones puissants restent désirables.
6. Dans la salle : une IA tenue pour acquise
Les rares posts publics du jour J parlent d'ambiance plus que de contenu. Christopher Buecheler, participant, relève un « coup du lapin culturel » : son fil Bluesky, rempli d'auteurs et d'artistes, est très hostile à l'IA, alors qu'en développement web elle est « acceptée à presque 100 % ». Antoine D. nuance ce consensus en rapportant le mot d'un autre participant : « il y a dans la salle ceux qui veulent développer des fonctionnalités IA, et il y a ceux qui y sont forcés ». Le quiz de Thorsten Seyschab a réuni près de 200 participants sur leur téléphone, avec des taux de bonnes réponses parfois bas (24 % sur le comportement de fetch face à un 429). Une semaine après, Jad Joubran (speaker) résume son ouverture comme le passage de la pénurie à l'abondance.
7. Limites de cette synthèse
Depuis la publication des 14 vidéos le 28/09, le contenu des talks est connu en détail par leurs transcripts automatiques (dont trois lus dans une traduction française), qui déforment parfois les noms propres ; les chiffres cités par les speakers n'ont pas été vérifiés. La réception reste en revanche très mal documentée : un seul compte rendu (Premier Octet, lu par extraits, le site restant en HTTP 429), un fil Mastodon d'un participant centré sur l'IA dans le navigateur, quelques posts Bluesky d'un participant ou de speakers, aucun post LinkedIn de participant trouvé à J+13.
Actions concrètes citées
- (Talk) Passer à npm 12 (scripts de cycle de vie, dépendances Git et URL distantes bloqués par défaut) et régler
min-release-agepour ne pas installer une version publiée il y a quelques minutes (Li). - (Talk) Côté mainteneur, publier via trusted publishing et staged publishing plutôt qu'avec un token longue durée (Li).
- (Talk) Traiter tout code généré comme non fiable : l'exécuter hors de l'app, sans accès réseau sortant, et ne rendre que des composants connus après validation par schéma (Agrawal).
- (Talk) Ajouter une analyse déterministe du codebase entier (code mort, dépendances inutilisées, duplication, frontières) dans la boucle de l'agent et en CI (Waardenburg).
- (Talk) Activer le strict mode, interdire
anyaux agents, valider à l'exécution avec un schéma et imposer une seule bibliothèque par besoin (Moigneu, Seyschab). - (Talk) Décider tâche par tâche ce qui tourne sur l'appareil ou sur le serveur, avec repli cloud ; beaucoup de tâches n'ont pas besoin d'un LLM (Martin, Firtman).
- (Talk) Acheter un Android à 100 $ pour tester : brider le réseau d'un MacBook ne simule pas un appareil d'entrée de gamme (Govindarajan).
- (Talk) Traiter les Core Web Vitals comme un point de départ et instrumenter Long Animation Frames, Layout Instability ou Compute Pressure pour ses propres signaux (Albuquerque).
- (Talk) Viser moins de build plutôt que zéro build : CSS natif, import maps, et réclamer aux navigateurs les fonctionnalités manquantes via enquêtes et Interop 2027 (Verou).
Session par session
Vendredi 18 septembre
Conférence▶ vidéo + transcript
The (Abundant) State of the Web
Jad Joubran — consultant web perf, LearnJavaScript.online
Retours : Blog Premier Octet (extraits indexés), Jad Joubran (speaker, Bluesky)
- Sur scène (transcript) : le web n'a jamais été aussi riche, mais « personne ne l'a vraiment dépensé ». Le talk suit trois actes : la page s'améliore, la page sort de l'onglet, l'onglet devient l'ordinateur.
- La page : dialog, popover, positionnement d'ancre,
<select>personnalisable, bientôt les scroll-state container queries (styler un élément collé, snappé ou scrollé jusqu'au bout en CSS seul), et les View Transitions entre deux documents avec un minimum de HTML et CSS. - Hors de l'onglet : Document Picture-in-Picture (aperçu de code sur un second écran, ticket de caisse affiché au client), web apps installables avec notifications push, y compris sur iOS une fois installées, et le lien, « toujours invaincu ».
- L'onglet comme ordinateur : mise à jour du firmware de ses lunettes XREAL via WebHID, File System Access (Excalidraw, vscode.dev), avec un bémol : Firefox et Safari ne suivent pas. Speculation rules pour pré-rendre la page suivante, et IA via Prompt API ou transformers.js avec repli cloud (son futur cours learnai.online).
- Démo finale : les declarative partial updates (Chrome), des marqueurs HTML remplis plus tard dans la même réponse streamée. Révélation : toute la présentation était une seule requête HTTP ouverte 20 minutes, sans JavaScript côté client, chaque slide étant poussée par le serveur. Le speaker juge l'API pas encore prête pour la production.
- Retenu par les participants : Premier Octet cite le tour d'horizon (select CSS, animations au scroll, View Transitions, Document PiP, speculation rules, transformers.js). Le speaker résume ensuite son talk comme le passage de la pénurie à l'abondance (speaker, Bluesky). Aucun retour de salle ne mentionne la démo en requête unique.
Conférence▶ vidéo + transcript
Boring but Effective: WebAI That Ships
Nico Martin — Hugging Face
Retours : Blog Premier Octet (extraits indexés), Antoine D. (participant, fil Mastodon)
- Sur scène (transcript) : démo de Jamie, assistant de cuisine vocal tournant dans le navigateur (environ 140 tokens/s sur un MacBook M3 avec un runtime expérimental), puis « le côté que j'avais laissé de côté » : Jamie, c'est quatre modèles et environ 3 Go à télécharger, par origine, car les caches sont isolés.
- Deux trous à combler : la distribution (quantification 1 à 1,5 bit, future Cross-Origin Storage API) et la couverture d'exécution (3 tokens/s sur un Dell XPS 15 avec ONNX Runtime ; Hugging Face travaille à un runtime dédié WebGPU, 5 à 10 fois plus rapide).
- Les tâches « ennuyeuses » qui marchent déjà partout via l'API
pipelinede Transformers.js : transcription Whisper tiny (14 fois le temps réel sur M3, au moins 1,7 fois sur machines plus modestes), estimation de profondeur (34 images/s), détourage (environ 40 images/s), embeddings (1 020 recettes indexées en 3 s, recherche en 17 ms). - La vraie question n'est pas « l'IA peut-elle tourner sur l'appareil ? » mais « doit-elle ? » : décider tâche par tâche selon réseau, taille du modèle et calcul. Pour Jamie en production : détection vocale et transcription côté client, LLM côté serveur, téléchargement local en option.
- Dernier exemple : des notes médicales passées dans un filtre de confidentialité local qui remplace les données sensibles par des placeholders avant l'appel au LLM cloud.
- Retenu par les participants : Premier Octet décrit Jamie comme un assistant 100 % local et en tire que l'IA dans le navigateur est devenue un sujet d'ingénierie. Le talk nuance ce point : il recommande plutôt de garder le LLM côté serveur tant que le téléchargement et le matériel posent problème.
- Retour critique d'un participant (Antoine D., Mastodon, 22/09, sur l'IA dans le navigateur en général) : il retient l'arbitrage entre appel d'API et modèle téléchargé en amont (rapide et hors ligne, mais lourd, avec profilage de l'appareil et modèle imposé par le navigateur) et regrette qu'aucun des speakers « passionnés d'IA » n'ait abordé l'impact énergétique du calcul déplacé sur l'appareil de l'utilisateur.
Conférence▶ vidéo + transcript
What You're Really Trusting When You Run npm install
Karen Li — GitHub
Retours : Blog Premier Octet (extraits indexés)
- Sur scène (transcript) : déroulé de
npm install(arbre existant, arbre idéal depuis le lockfile ou lepackage.json, diff, téléchargement, scripts de cycle de vie, mise à jour du lockfile, audit) et trois points où la confiance peut être exploitée. Scénario type : lockfile supprimé, version malveillante publiée à 8 h, installée à 8 h 03,postinstallexécuté. - Côté installateur : passer à npm 12 (sorti en juillet), qui bloque par défaut les scripts de cycle de vie, les dépendances Git et les URL distantes ; ré-autoriser au cas par cas avec
npm approve-scripts(et committer la liste danspackage.json). Utilisermin-release-age(depuis npm 11.10) pour ne pas installer une version de moins d'un jour. - Côté publieur : les attaques passent par la prise de compte, le vol de tokens et l'exfiltration en CI. Réponses : trusted publishing (token éphémère lié au dépôt et au workflow) et staged publishing (le paquet attend l'approbation d'un mainteneur avant d'être public), tokens limités au « stage » pour ceux qui contournent la 2FA.
- Annonces : restriction à venir des tokens contournant la 2FA pour publier, création de paquets via staged publishing, historique d'activité de publication ; feuille de route npm publiée la veille sur GitHub Community.
- Conclusion : on ne fait pas qu'installer du code, « on fait confiance à des gens, à un système et à du code qu'on ne voit pas », mais on n'est pas démuni.
- Retenu par les participants : Premier Octet retient le déroulé de l'installation, la quarantaine des versions fraîches et le blocage des scripts à partir de npm 12, ce que le talk confirme.
Lightning talk▶ vidéo + transcript
Web Performance APIs That You (Probably) Never Knew Existed
Matheus Albuquerque — Medallia
Retours : Slides du speaker (Speaker Deck), Blog Premier Octet (extraits indexés)
- Sur scène (transcript) : préambule sur l'histoire de HTML5 ; la plateforme n'avance plus par grands manifestes mais par des fonctionnalités qui arrivent sans bruit, et la performance peut redevenir simple.
- Mesurer avec la plateforme : Layout Instability (trouver le coupable d'un décalage), Long Animation Frames (frames de plus de 50 ms attribuées aux scripts), Self Profiling chez les vrais utilisateurs, mesure mémoire (exemples de fuites : timers qui retiennent des closures, nœuds DOM détachés encore référencés), Compute Pressure pour dégrader la qualité quand le CPU sature.
- Améliorer avec la plateforme : preconnect, Speculation Rules (précharger le tableau de bord après la connexion), Priority Hints (y compris
prioritysurfetch), lazy loading natif,scheduler.postTasketyieldcontre les longues tâches, View Transitions qui ont apporté une continuité visuelle à une MPA React routée par un monolithe Java sans la réécrire en SPA. - Conclusions : les Core Web Vitals sont un point de départ, pas une ligne d'arrivée ; son entreprise a quitté un outil RUM du marché pour le sien (coût à l'échelle, métriques propres au produit) ; les ingénieurs qui comprennent ordonnancement et rendu restent ceux qui savent quoi faire optimiser aux agents ; la performance relève aussi de l'accessibilité (définition de Mozilla).
- Retenu par les participants : Premier Octet cite la même liste d'API. Aucun retour de salle trouvé.
Conférence▶ vidéo + transcript
Unlocking Client-Side AI in Your Web App
Maximiliano Firtman
Retours : Blog Premier Octet (extraits indexés), Antoine D. (participant, fil Mastodon)
- Sur scène (transcript) : le sujet n'est ni les agents qui naviguent sur nos sites, ni les apps dans ChatGPT, ni l'IA qui code, mais l'IA à l'intérieur de nos web apps : support client, détection de propos haineux avant envoi, traduction, résumés, tags automatiques, vision, voix, RAG.
- Pourquoi côté client : confidentialité (avocats, médecins, banques), latence, hors ligne, coût (pas de facture de tokens le jour où l'on devient viral). « Pas encore une solution miracle. »
- API intégrées : Translator, Summarizer, Writer/Rewriter (expérimentales), Speech API désormais adossée à l'IA, et Prompt API (sortie contrainte par JSON Schema, desktop uniquement). Le modèle est téléchargé une fois pour toutes les origines : Gemini Nano dans Chrome (Gemma 4 derrière un flag dans Canary), Phi-4 mini dans Edge. Firefox et Safari s'y opposent ; un polyfill permet un repli cloud ou local.
- Apporter son modèle : transformers.js, WebLLM, MediaPipe, LiteRT, TensorFlow.js, ONNX Runtime Web…, LLM de 1 à 9 milliards de paramètres, sur WebGPU (donc tous navigateurs) ; WebNN reste expérimental. Pas besoin d'un LLM pour tout : certains modèles pèsent 200 Ko.
- Démos entièrement hors ligne : chatbot Gemma 4, traduction vocale en direct vers le français, RAG vocal, description de la caméra par un modèle open source d'Apple. Recette : vérifier que le cas s'y prête, API natives si disponibles, repli cloud, cache du modèle.
- Retenu par les participants : Premier Octet retient la distinction entre briques bas niveau (transformers.js, ONNX Runtime Web) et API haut niveau du navigateur adossées à Gemini Nano. Antoine D. (Mastodon, 22/09) retient la même distinction entre API intégrées (traduction, résumé, recherche, sans forcément de LLM) et Prompt API, « celle-ci qui pose problème, notamment à Mozilla » ; il juge « complètement dingue » l'absence de toute question sur l'impact énergétique, et rapporte un « désintérêt poli » de deux speakers interrogés sur le sujet.
Lightning talk▶ vidéo + transcript
Promise You'll Know It? The async JavaScript Quiz
Thorsten Seyschab
Retours : Thorsten Seyschab (speaker, Bluesky, avant le talk)
- Sur scène (transcript) : quiz en direct sur smartphone, huit questions, près de 200 participants, avant le déjeuner ; 600 magnets à gagner (speaker).
- Les pièges et les taux de bonnes réponses annoncés :
asen TypeScript ne valide rien à l'exécution (environ la moitié de bonnes réponses ; valider avec un schéma, Valibot ou Zod) ; unfetchqui reçoit un 429 ne rejette pas, il renvoieok === false(24 %) ; l'ordreA, D, B, Centre code synchrone, microtâche etsetTimeout(44 %). - Suite :
^0.3.4n'autorise que les mises à jour de patch (en écho au talk de Karen Li) ;Promise.allrejette sans annuler les opérations en cours (28 %) ;forEachavec un callback async n'attend pas (la plupart ont bon). - Aucun retour de salle trouvé ; questions et logiciel du quiz annoncés sur le site du speaker.
Lightning talk▶ vidéo + transcript
Building ChatGPT and MCP Apps with All the Comfort of Modern TypeScript DevX
Nikolay Rodionov — Alpic
- Sur scène (transcript) : thèse d'ouverture, les sites web vont devenir une interface « legacy », comme le téléphone pour réserver un restaurant ; plus de la moitié du trafic viendrait déjà d'agents et de bots (chiffre du speaker). Il faut penser « expérience agentique » et pas seulement expérience utilisateur.
- MCP apps : le serveur MCP renvoie, en plus des données, une ressource HTML rendue dans une iframe du chatbot (exemple d'un widget produit dans ChatGPT). Problème : cette architecture casse l'outillage web, d'où une DX très mauvaise (tunnel, connexion au client, prompt pour tester chaque changement, pas de typage, comportements différents selon Codex, Claude ou Gemini).
- Skybridge, framework TypeScript open source d'Alpic : typage de bout en bout, hooks React, skills pour agents, devtools locaux avec hot module reload, aperçu ChatGPT/Claude, tunnel intégré, playground avec LLM, audit de conformité aux stores, déploiement en un clic. Démo : une MCP app dotJS générée par Codex.
- Aucun retour participant trouvé.
Lightning talk▶ vidéo + transcript
Microfrontends done right
Gabor Csomak — Bally's Intralot
- Sur scène (transcript) : les résultats de recherche donnent une mauvaise image des microfrontends (une app en trois frameworks, une équipe par bouton, « le back est passé aux microservices, donc le front aussi »).
- Le vrai problème est organisationnel : plusieurs équipes sur un même codebase se marchent dessus. Règle du speaker, inspirée de la loi de Conway : un composant appartient à une seule équipe, de 1 à 5 développeurs, et on redécoupe quand le backlog l'exige.
- Exemples vécus : une plateforme de trading multi-écrans il y a 15 ans, son entreprise actuelle (socle header/footer, modules sports, iGaming, inscription), une autre qui fait de chaque page entière un microfrontend.
- Objectif : les métriques DORA et des équipes autonomes de bout en bout. Pratiques : tests end-to-end, coutures invisibles pour l'utilisateur, cache CDN, contrats hôte/microfrontend conçus comme des API back, harnais de test isolés ; la technique (iframe, module federation, single-spa) est secondaire.
- À l'ère de l'IA : un périmètre borné et documenté est aussi plus lisible pour un agent, qui consomme moins de tokens.
- Aucun retour participant trouvé.
Lightning talk▶ vidéo + transcript
TypeScript was built for agent factories (it just didn't know it yet)
Guillaume Moigneu — Upsun
Retours : Blog Premier Octet (extrait indexé)
- Sur scène (transcript) : répondant à un article qui présentait Go comme le langage idéal des agents, le speaker note que Claude Code, Gemini CLI ou le SDK d'agents d'OpenAI sont en TypeScript, et que l'afflux de contributeurs TypeScript sur GitHub nourrit les données d'entraînement.
- Parallèle : TypeScript a été conçu pour faire travailler de gros effectifs sur du JavaScript ; en 2026, on n'intègre plus des juniors mais des agents. Le métier se déplace de l'écriture vers la vérification (le code est-il correct ?) et la validation (fait-il ce qu'on voulait ?).
- Chiffres avancés par le speaker, sans source détaillée : 94 % des erreurs du code généré seraient des erreurs de type ; les agents utiliseraient
anyneuf fois plus qu'un humain. - Faiblesses de TypeScript face à Go : types non vérifiés à l'exécution (« un videur qui demande la carte d'identité sans regarder la date »), trop de façons de faire, chaîne d'approvisionnement fragile.
- Recette : strict mode,
anyinterdit,tscet Biome comme portes déterministes avant la revue, Zod pour valider à l'exécution, tests de comportement par des agents, et imposer aux agents une seule bibliothèque par besoin. Upsun construit « Dispatch », une software factory sur ce principe. - Retenu par les participants : Premier Octet résume le talk comme TypeScript en filet de sécurité du code généré par l'IA.
Conférence▶ vidéo + transcript
JavaScript tooling has a blind spot: codebase-wide questions
Bart Waardenburg — Fallow
Retours : Blog Premier Octet (extraits indexés), Page presse du site Fallow (speaker)
- Sur scène (transcript) : face au code « slop » des agents, la meilleure défense est l'outillage déterministe (même entrée, même sortie). Point de départ : Cursor, fin 2024, renvoie les erreurs de TypeScript et du linter au modèle. Mais un linter lit un fichier à la fois et ne voit pas ce qui se joue entre les fichiers ; empiler Knip, JSCPD ou Sonar ralentit.
- Fallow, commencé en mars : à partir des points d'entrée (framework, tests, stories), un graphe de tout le codebase qui détecte fichiers et exports morts, dépendances inutilisées (surface d'attaque supply chain), duplication, complexité (cyclomatique, fréquence des commits, score CRAP complexité/couverture) et frontières d'architecture (import
use client/ serveur dans Next.js). - Autres usages du graphe : classes CSS inutilisées, couleurs Tailwind qui dérivent du design system, variables d'environnement serveur qui fuitent vers le client.
- Branché dans la boucle de l'agent, dans l'éditeur et en CI (« je ne fais pas toujours confiance à mon agent, et encore moins à ceux de mes collègues »). Nouveauté : une balise de couverture en production pour savoir si un code défensif généré (un
isRecordsuperflu) s'exécute vraiment. - Conclusion : ces outils libèrent du temps pour la partie intéressante du métier, construire quelque chose d'utile.
- Retenu par les participants : Premier Octet résume la question posée, qui garde la vue d'ensemble quand les agents écrivent le code ?, et présente Fallow comme un analyseur écrit en Rust.
Conférence▶ vidéo + transcript
Your Lighthouse Score Doesn't Matter on 3G
Vishnudhasan Govindarajan — Virgio
Retours : Blog Premier Octet (extrait indexé)
- Sur scène (transcript) : on fait une capture d'écran du 100/100 Lighthouse et on la poste sur Slack, sans se demander pour qui est ce 100. Presque toute la salle teste sur MacBook Pro, alors qu'une large part des utilisateurs de certaines régions d'Asie et d'Afrique utilise des Android à 100 $ (chiffres cités par le speaker d'après « un article »).
- Brider le réseau en 3G dans les DevTools, c'est tester un M5 Pro sur un mauvais réseau, pas un appareil d'entrée de gamme. Première action du lundi : faire acheter un Android à 100 $ et y déboguer à distance.
- D'où vient le coût : parsing, compilation et exécution sur un seul thread principal, CSS inutilisé, hydratation qui affiche une UI pas encore cliquable, dépendances importées sans analyse de bundle, frameworks choisis par effet de mode.
- Remèdes : rendu serveur et composants serveur, CSS critique, chargement selon l'intention de l'utilisateur, report du non prioritaire ; Lighthouse comme signal de régression en labo, pas comme juge, et du RUM ; faire la performance une propriété de livraison avec baseline et budget dans le cycle de développement.
- Cinq règles finales : envoyer moins, exécuter moins, réduire le coût d'une action, laisser respirer le navigateur, tester sur de vrais appareils.
- Retenu par les participants : Premier Octet retient la thèse centrale, le score Lighthouse ne reflète pas l'expérience réelle en 3G.
Conférence▶ vidéo + transcript
Beyond the Chatbot: Generative UI and the Execution Trust Problem
Harshil Agrawal — Cloudflare
Retours : Blog Premier Octet (extrait indexé)
- Sur scène (transcript) : cas réel, l'interface d'administration de la plateforme de certification de Cloudflare. Des tableaux de bord fixes, puis un chatbot (« des blocs de texte »), puis l'UI générative.
- Le modèle n'écrit ni JSX ni HTML : il écrit une fonction qui récupère les données via un outil au schéma d'entrée strict (pas de SQL libre), calcule, et renvoie une description de l'UI.
- Où exécuter ce code non relu ? Ni iframe, ni web worker, ni conteneur (trop lourd pour du JavaScript) : des Dynamic Workers Cloudflare, sur isolates V8, chargés à la volée puis détruits. Réglage clé :
globalOutboundànull(ou liste d'URL autorisées) pour empêcher toute exfiltration. - Côté navigateur, deux défenses : validation par schéma, puis un
switchqui mappe chaque type à un composant React connu ; un type inventé (du HTML brut) n'est jamais rendu. - Trois questions à se poser : que peut atteindre ce code, que peut-il faire pendant son exécution, que renvoie-t-il ; limites de CPU, outils restreints, validation côté serveur et client, et exécution hors de l'application. « Traitez le code généré comme du code non fiable. »
- Retenu par les participants : Premier Octet résume une démo d'exécution sûre de composants React générés dans des isolates V8. Le talk précise que le modèle ne génère justement pas de composants React mais une description mappée vers des composants existants.
Conférence▶ vidéo + transcript
A 50-year accident: how JavaScript got Date, and why Temporal exists
Devlin Duldulao — DaloyJS
Retours : Blog Premier Octet (extrait indexé)
- Sur scène (transcript) : « si vous aviez une machine à remonter le temps jusqu'en mai 1995, que corrigeriez-vous dans JavaScript ? » La réponse du talk : l'API de dates. Leçon d'histoire en étapes.
- 1970 : Unix choisit un instant unique, parfait pour les machines, jamais prévu pour les anniversaires ou les horaires d'ouverture. Mois indexés à zéro hérités de C et Java (« un indexage incohérent est pire qu'une règle cohérente mais laide »). 1986 : la base des fuseaux horaires, un problème de maintenance de données, d'où un JS limité à UTC et heure locale.
- 1995 : JavaScript copie en dix jours le
Datemutable et à type unique de Java, pensé pour valider des formulaires, pas réserver des vols. Java et C# le remplacent ensuite ; le web, lui, ne peut rien supprimer, la seule issue est une nouvelle API. - 2011 : Moment.js devient la norme de fait (mutable, lourd). 2017 : proposition TC39 Temporal ; neuf ans plus tard, livraison dans V8 en janvier 2026, ES2026 et Node.js 26, avec l'arrivée annoncée dans la prochaine LTS de Node.
- Migration : plus simple côté serveur ; plus compliquée côté client, car les sélecteurs de date des bibliothèques d'UI (Material UI, shadcn) reposent sur leurs propres bibliothèques de dates. Au passage, des types sémantiques que « l'IA adore ».
- Chute : en 1995, « ils ont livré un chronomètre et l'ont appelé Date ». Retenu par les participants : Premier Octet résume le talk comme l'histoire mouvementée de
Dateet l'arrivée de Temporal.
Conférence▶ vidéo + transcript
No-build: pipe dream, or near future?
Lea Verou — TC39, WHATWG
Retours : Blog Premier Octet (extrait indexé)
- Sur scène (transcript) : presque tout le monde utilise un bundler, mais dans ses sondages environ la moitié (Mastodon) et un tiers (Twitter) voudraient s'en passer, et les outils de build dépassent le débogage dans les difficultés citées par State of JS. Le problème n'est pas la compilation, c'est la fragmentation : « nous servons les bundlers ».
- Pas de posture extrême : le but n'est pas de supprimer les bundlers, mais de les rendre moins indispensables et plus légers. « Pas besoin d'aller jusqu'au bout pour en tirer les bénéfices. »
- Trois raisons d'utiliser un bundler. Transpilation : la proposition TC39 d'annotations de types est au point mort, « faites du bruit » (enquêtes, Interop 2027) ; CSS : nesting fiable, Autoprefixer inutile, fonctions,
if()et mixins à venir. Performance : HTTP/2 et 3, fetch priority, early hints, compression dictionaries réduisent l'écart, même si le bundler gagnera toujours. - Résolution des dépendances : le vrai « usability cliff », car on en a besoin dès le premier jour. « Être sans dépendance ne devrait pas être un badge d'honneur, c'est un signal d'alarme pour l'écosystème. » Vendoring et CDN (affaire polyfill.io) écartés ; les import maps existent mais restent bas niveau.
- Première présentation publique de son « unbundler » (Nudeps, paquet publié sur npm), bâti sur JSPM et le hook
dependenciesde npm, qui vendorise localement par version. Manques restants : ressources non-JS, workers, import maps multiples dans Firefox, paquets qui supposent Node. - Les agents s'y adaptent (Claude, surtout avec un fichier de skill) ; elle cite Modern Web Guidance, projet Google pour enseigner aux agents les fonctionnalités modernes. Retenu par les participants : Premier Octet ne dit que la clôture de la journée sur l'avenir sans bundler.
Sources
- Agenda officiel et descriptifs des talks (nouvel onglet) ↗
- Site dotJS (liste des speakers 2026) (nouvel onglet) ↗
- Playlist YouTube dotJS 2026 (14 talks, publiés le 28/09, chaîne dotConferences) (nouvel onglet) ↗
- Premier Octet, « DotJS 2026: AI in the Browser, Web Security & Performance Take Center Stage » (lu via extraits indexés) (nouvel onglet) ↗
- Slides de Matheus Albuquerque, « Web Performance APIs That You (Probably) Never Knew Existed » (Speaker Deck) (nouvel onglet) ↗
- Post LinkedIn pré-événement d'un membre du comité éditorial (nouvel onglet) ↗
- Post Bluesky de Jad Joubran (speaker) sur son talk d'ouverture, 25/09 (nouvel onglet) ↗
- Posts Bluesky de Christopher Buecheler (participant), 18/09 (nouvel onglet) ↗
- Post Bluesky de Thorsten Seyschab (speaker) avant son quiz, 18/09 (nouvel onglet) ↗
- Page presse de Fallow (talk de Bart Waardenburg) (nouvel onglet) ↗
- Fil Mastodon d'Antoine D. (participant) sur l'IA dans le navigateur à dotJS, 11 posts, 22/09 (nouvel onglet) ↗
- Nudeps, le « unbundler » présenté par Lea Verou (npm) (nouvel onglet) ↗