#2 - Module Federation et Vue à l'ère de l'IA : retour de la MadVue 2026

Voici la seconde partie de mon retour sur la MadVue 2026, la conférence Vue.js qui s'est tenue à Madrid le 22 mai 2026. Si vous avez manqué le début, la première partie est juste ici :

• Partie 1 - Temps réel, URLs typées, formulaires et toolchain
• Partie 2 - Module Federation et Vue à l'ère de l'IA

Après les fondations de l'application Vue moderne, on change d'échelle et d'époque. Dans cet article, on va voir comment partager des composants entre plusieurs applications Vue avec Module Federation, puis trois talks consacrés à Vue et l'intelligence artificielle : faire générer une interface en direct par un LLM, préparer son projet Vue pour les agents, et enfin apprendre le frontend à l'ère de l'IA.

C'est parti !

Sommaire

• Comment partager des composants Vue entre plusieurs apps ? - Néstor López
• Peut-on faire générer une interface par un LLM ? - Markus Oberlehner
• Comment préparer son projet Vue pour les agents IA ? - Alexander Opalic
• Comment apprendre le frontend à l'ère de l'IA ? - Juan Andrés Núñez

Comment partager des composants Vue entre plusieurs apps ? Néstor López

Néstor López attaque par un problème qui n'est pas technique mais humain : les gens ne scalent pas comme les serveurs. À mesure qu'une équipe grossit, le code devient un champ de bataille partagé, et plus personne ne sait vraiment comment l'ensemble fonctionne.

Le backend a connu ça en premier, et y a répondu avec les microservices (Docker, Kubernetes). Le frontend est passé par la même crise. La première tentative ? Les iframes — ce que Néstor qualifie avec humour de « resume-driven development ». La vraie réponse, c'est le Module Federation : un contrat de partage entre applications JavaScript, qui permet à une app d'en consommer une autre à l'exécution.

Né dans Webpack, il fonctionne aujourd'hui avec Parcel, Rollup, Rolldown et Vite. Et ce n'est pas réservé au frontend : il existe un package pour Node, donc ça marche aussi avec Nuxt (un sujet que Daniel Roe évoquait justement pour Nuxt 5, voir la partie 1).

Est-ce un sujet de niche ? Plus du tout. Néstor déroule une liste de logos qui parle d'elle-même : Adobe, Adidas, Amazon, Cisco, Cloudflare, eBay, Ford, JetBrains, Microsoft, Netflix, PayPal, SAP, Shopify, Sony, Stripe, Tesla, Verizon, Volkswagen… le Module Federation est devenu un standard de l'industrie.

Côté déploiement, deux noms à retenir pour simplifier la mise en production de ces architectures : Medusa et Zephyr Cloud, dont la promesse claque : « the fastest way to deploy on any cloud provider — if it builds, it deploys ». Et Néstor pousse le concept jusqu'à l'idée d'« infrastructure superposée » (superpositioned infrastructure), avec son cas d'usage : composer une UI à partir de morceaux venant de plusieurs applications Vue indépendantes.

Peut-on faire générer une interface par un LLM ? Markus Oberlehner

Markus Oberlehner s'attaque à une idée fascinante : faire générer une UI en temps réel par un LLM, et en streamer le rendu progressivement à l'écran. Son constat : les LLM « classiques » comprennent bien une spécification mais ne sont pas très malins seuls — c'est l'arrivée des agents qui change vraiment la donne.

Pour qu'une interface se construise toute seule, il faut trois ingrédients :

1. Un LLM à la fois intelligent ET rapide (la vitesse compte autant que la qualité quand on stream).
2. Une spécification efficiente : TypeScript sert de contrat entre le modèle et l'UI.
3. Un format streamable.

Et c'est là que le talk devient malin. Pourquoi ne pas streamer directement du HTML ? Parce que le rendu casse tant qu'une balise n'est pas fermée. Le YAML évite ce problème (chaque morceau reçu reste valide), mais la meilleure approche s'est révélée être du JSON couplé à jsonrepair : à chaque chunk reçu, jsonrepair « ferme » le JSON incomplet pour qu'on puisse le parser et rendre l'UI immédiatement.

Markus a aussi présenté un benchmark très parlant comparant plusieurs modèles sur deux métriques : le Time To First Token (le temps avant le premier octet) et le temps total de génération.

La leçon : pour une UI qui se construit sous les yeux de l'utilisateur, un modèle rapide donne une bien meilleure fluidité, quitte à confier les tâches lourdes à un modèle plus puissant en arrière-plan. L'outil Groq sert justement à benchmarker et héberger des modèles très rapides.

Comment préparer son projet Vue pour les agents IA ? Alexander Opalic

Alexander Opalic part d'une anecdote qui pose le décor : il y a deux semaines, Bun a été réécrit en Rust. Le rythme s'accélère, et son sujet est très concret : rendre nos projets Vue « AI ready ». Ses slides sont en ligne.

D'abord, qu'est-ce qu'un agent, au fond ? Une boucle toute simple : prompt → think → tool call → result. Pour qu'un agent soit efficace sur notre code, il a besoin de contexte :

• AGENTS.md : à traiter comme une porte d'entrée, pas comme un dépotoir (dump vs doorway). Une bonne source d'inspiration à piller : le repo brainmaxxing.
• Les Skills : des recettes que l'agent ouvre quand un déclencheur est rencontré.
• Les Hooks : du code qui s'exécute autour des événements de l'agent.

Mais le cœur du talk, ce sont les boucles de feedback. Pour qu'un agent (et un humain !) produise du bon code, il faut des garde-fous rapides, sur quatre niveaux :

1. La sûreté de typage (type safety) ;
2. Le lint et le format ;
3. Des règles de lint Vue qui gardent les composants petits ;
4. Les tests.

Parmi les outils cités : agent-browser, un CLI navigateur pour les agents signé Vercel, et Lefthook comme gate au moment du commit. Enfin, Alexander insiste sur la découvrabilité du code : one folder = one feature, migrer d'une structure « à plat » vers une architecture feature-sliced, et définir explicitement qui peut importer quoi. Sa philosophie quand un agent se trompe : « Fix the factory, not the PR » — on corrige l'usine (les règles, le contexte) plutôt que de rustiner les pull requests une par une.

Comment apprendre le frontend à l'ère de l'IA ? Juan Andrés Núñez

Pour clore, Juan Andrés Núñez livre le talk qui m'a sans doute le plus fait réfléchir. Ce n'est pas un cours de prompt engineering, mais un retour d'expérience honnête sur la pédagogie à l'ère des LLM.

En 2025, il avait construit FrontendLeap v1 : 200+ vidéos, une centaine d'étudiants, un an en production. En 2026 : « I scrapped it all. » Il a tout jeté. Pas par perte de confiance dans les LLM, mais dans le modèle pédagogique lui-même : on regarde passivement vidéo après vidéo, on privilégie la couverture à la compréhension, la quantité à la friction productive.

Pour reconstruire, il s'appuie sur six principes cognitifs de l'apprentissage. Rien de nouveau — on les connaît depuis des décennies — mais on n'avait jamais su les passer à l'échelle. Jusqu'à maintenant :

1. Le problème des 2 sigma de Bloom (1984) — un tutorat individuel fait mieux que 98 % des élèves d'une classe classique. On le sait depuis 40 ans, mais personne ne savait offrir un tuteur par élève. L'IA, si.
2. La pratique délibérée (Ericsson, 1993) — le mythe des « 10 000 heures » vient de là, et il est faux. Ce n'est pas une question de temps, mais de pratiquer à sa limite, avec du feedback, avec intention.
3. Le rappel actif (Karpicke & Roediger, 2008) — ceux qui se testent retiennent 50 % de plus une semaine après que ceux qui ont relu quatre fois. Essayer de se souvenir, c'est ça, apprendre.
4. La zone proximale de développement (Vygotsky, 1978) — entre ce qu'on sait faire seul et ce qu'on ne sait pas encore faire, il y a une zone intermédiaire : c'est là que l'apprentissage a lieu, et l'étayage se retire au fur et à mesure.
5. Les difficultés désirables (Bjork, 1994) — la difficulté améliore la rétention à long terme, même si elle est désagréable sur le moment. Ce qui donne l'impression d'être efficace (relire, regarder) ne l'est généralement pas.
6. Le feedback immédiat (Hattie & Timperley, 2007) — l'un des facteurs les plus puissants… à condition d'être immédiat ET spécifique. Un « good job » ne compte pas.

Le nouveau FrontendLeap est donc Vue.js powered, avec un mentor socratique disponible 24h/24, un apprentissage guidé qui s'adapte au niveau et au rythme de l'élève, et de la vraie pratique : écrire, exécuter, verbaliser, recevoir un retour immédiat. Sa promesse : « 0 % de vidéo, 0 % de contenu statique, 0 % d'enthousiasme feint. »

Les leçons qu'il en tire dépassent largement la pédagogie :

• Trouvez un problème qui vous tient vraiment à cœur. Ne suivez pas les tendances, suivez un problème que vous voulez profondément résoudre.
• Votre expertise métier est votre premier prompt. Pas de docs de prompt engineering, pas de patterns sophistiqués : « I just transcribed myself. » Votre connaissance du domaine est l'ancre concrète.
• Faites confiance au modèle. Et cette punchline que j'ai notée : « If you have to SHOUT at the model, you are already fcked. »* Si vous devez crier en majuscules dans votre prompt, c'est déjà perdu.
• La technologie n'est pas le problème. Les gens, si. La bonne question n'est pas « l'IA va-t-elle remplacer les profs ? », mais « pourquoi tant d'élèves préfèrent-ils une vidéo YouTube à un tuteur individuel disponible en permanence ? ». La techno est là ; le goulot d'étranglement est culturel.

A-t-il trouvé son « moment de magie » ? Pas encore, admet-il. Mais le retour d'un utilisateur résume bien l'ambition : « The knowledge keeps clicking into place like Legos. »

Et voilà qui conclut mon retour sur la MadVue 2026 ! Une édition qui aura tenu ses promesses : des fondations Vue de plus en plus solides (temps réel, routing typé, formulaires, toolchain, Nuxt 5), une mise à l'échelle qui se démocratise avec Module Federation, et une réflexion salutaire sur la place de l'IA — dans nos interfaces, dans nos projets, et jusque dans la façon dont on apprend notre métier.

Si vous avez manqué la première partie, elle est juste ici : Partie 1 - Temps réel, URLs typées, formulaires et toolchain. Merci de votre lecture, et à la prochaine !