Micro frontends

Un micro frontend est un morceau d’UI construit, testé et livré indépendamment par une équipe, puis composé avec les autres à l’exécution, dans le navigateur. Le mot qui compte est « indépendamment » : si deux parties doivent être livrées ensemble, ce ne sont pas des micro frontends mais des modules d’une même application — aussi séparés que soient leurs dossiers.

Cette architecture résout un problème organisationnel, pas technique : plusieurs équipes autonomes qui veulent livrer à des rythmes différents sans se bloquer mutuellement. Le prix se paie en complexité à l’exécution : versions des dépendances, échecs d’intégration, cohérence visuelle, tests, observabilité.

Ce que c’est et ce que ce n’est pas

Un système de micro frontends a trois propriétés, toutes obligatoires :

• Build séparé — chaque partie a son propre pipeline et son propre package.json (ou au moins sa propre cible de build).
• Déploiement séparé — l’équipe Catalog publie une nouvelle version sans que le shell ou l’équipe Cart n’ait à intervenir.
• Composition à l’exécution — un shell (host) ne découvre que dans le navigateur quelle version de chaque remote charger, généralement à partir d’un manifest.

BUILD — PAS un micro frontend
  libs/catalog ─┐
  libs/cart    ─┼─► ng build shell ─► un seul déploiement
  libs/reviews ─┘
  une version, une release, des contrats vérifiés par le compilateur

EXÉCUTION — micro frontends
  catalog → build → deploy → catalog…/remoteEntry.json ─┐
  cart    → build → deploy → cart…/remoteEntry.json    ─┼─► le shell les compose
  reviews → build → deploy → reviews…/remoteEntry.json ─┘   dans le navigateur
  N versions, N releases, contrats vérifiés seulement à l’exécution

Vraies raisons, fausses raisons

Les raisons qui justifient le prix concernent presque toutes les personnes et la livraison :

• Des équipes autonomes avec des cadences différentes. L’équipe checkout livre plusieurs fois par jour, celle du catalogue une fois par semaine, et une release commune bloque les deux : une régression dans le catalogue arrête un correctif de paiement urgent.
• Les très grandes organisations. Des dizaines de développeurs frontend sur le même produit, plusieurs domaines métier, chacun avec une responsabilité claire (loi de Conway : l’architecture finit de toute façon par refléter l’organisation).
• La migration progressive (strangler fig). Un nouveau shell « enveloppe » l’ancienne application (AngularJS, un Angular plus ancien, un autre framework) ; les écrans migrent un par un, et le vieux code rétrécit jusqu’à disparaître — sans réécriture « big bang ».
• Des produits séparés sous une seule expérience : acquisitions, unités métier, portails qui regroupent des applications existantes.

Les fausses raisons sonnent bien en présentation, mais ont des solutions moins chères :

Le prix

Chacun des coûts ci-dessous apparaît en pratique ; la différence entre un système sain et un système fragile, c’est d’avoir un plan dès le premier jour.

Native Federation pas à pas

Native Federation implémente le modèle Module Federation sur des standards du web : les remotes sont de simples modules ES, reliés par une import map. Pour Angular 22, le paquet est @angular-architects/native-federation 22.x — la version suit le major.minor d’Angular — et il reste sur le builder esbuild du CLI (@angular/build:application), qu’il enveloppe. Le projet a déménagé vers l’organisation github.com/native-federation. Le mécanisme, pas à pas :

1. Build. Chaque remote produit des modules ES et un remoteEntry.json : ce qu’il expose (./routes → le fichier généré) et les dépendances qu’il partage, avec version, requiredVersion, singleton, strictVersion.
2. Démarrage du shell. main.ts appelle initFederation() avant Angular : il lit le manifest (nom → URL), télécharge les métadonnées de chaque remote, négocie les versions et écrit l’import map (avec es-module-shims).
3. Bootstrap. Seulement ensuite, import('./bootstrap') démarre Angular. C’est pourquoi le schematic déplace le bootstrap dans un fichier séparé : @angular/core doit être résolu via l’import map, il faut donc qu’elle existe d’abord.
4. Navigation. loadRemoteModule('catalog', './routes') est, en substance, un import() dynamique d’une URL sur le serveur de l’équipe Catalog. Quand le code du remote fait import '@angular/core', l’import map l’envoie vers la copie du shell : un seul Angular, un seul injector racine.

# la version de l’adaptateur suit le major.minor d’Angular (22.2.x pour Angular 22.2)
npm i -D @angular-architects/native-federation

ng g @angular-architects/native-federation:init \
  --project catalog --port 4201 --type remote
ng g @angular-architects/native-federation:init \
  --project shell --port 4200 --type dynamic-host

# Ce que change le schematic :
#  • build/serve → @angular-architects/native-federation:build,
#    qui délègue à @angular/build:application (esbuild)
#  • main.ts → initFederation(...) puis import('./bootstrap');
#    l’ancien bootstrap se retrouve dans bootstrap.ts
#  • génère federation.config.mjs (+ public/federation.manifest.json sur dynamic-host)
#  • ajoute es-module-shims aux polyfills (import maps avec scopes)
#  • avec --webcomponent : bootstrap sous forme de custom element (createApplication + define)

// catalog/federation.config.mjs — un remote, tel que généré par la 22.x
import {
  withNativeFederation,
  fromPackageJson,
} from '@angular-architects/native-federation/config';

export default withNativeFederation({
  name: 'catalog',

  exposes: {
    // l’API publique du remote
    './routes': './projects/catalog/src/app/catalog.routes.ts',
  },

  shared: fromPackageJson({
    singleton: true,
    strictVersion: true,
    requiredVersion: 'auto',
    build: 'package',
  })
    // tout @angular/core, entry points secondaires compris → une seule copie
    .patch(['@angular/core'], { includeSecondaries: { keepAll: true } }),

  skip: ['rxjs/ajax', 'rxjs/fetch', 'rxjs/testing', 'rxjs/webSocket'],

  features: { denseChunking: true },
});

// shell/src/main.ts — s’exécute AVANT Angular :
// lit le manifest, télécharge les fichiers remoteEntry.json, négocie les versions,
// écrit l’import map — et seulement ensuite charge bootstrap.ts (et @angular/core)
import { initFederation } from '@angular-architects/native-federation';

initFederation('federation.manifest.json')
  .then((nf) => import('./bootstrap').then((m) => m.bootstrap(nf)))
  .catch((err) => console.error(err));

// La forme courte des anciens tutoriels existe encore en 22.x,
// mais elle est marquée @deprecated :
import { loadRemoteModule } from '@angular-architects/native-federation';

const route = {
  path: 'catalog',
  loadChildren: () =>
    loadRemoteModule('catalog', './routes').then((m) => m.CATALOG_ROUTES),
};

// La raison, d’après le d.ts : elle dépend d’une instance globale et du DERNIER initFederation,
// elle est donc fragile dans les tests et avec plusieurs hosts.
// Recommandé : loadRemoteModule issu du résultat d’initFederation (voir app.routes.ts).

L’exemple ci-dessous reproduit exactement ce flux. Les serveurs sont simulés, mais chaque « remote » est un vrai composant Angular, placé dans son propre chunk et chargé avec un import() dynamique — le même mécanisme que loadRemoteModule utilise en dessous. Le catalogue et le panier ne communiquent que par des événements sur window ; les avis ne parlent à personne.

Dépendances partagées et versions

Pour chaque paquet de shared, un remote déclare quatre choses : version (avec quoi il a été construit), requiredVersion (ce qu’il accepte ; 'auto' = la plage de package.json, par exemple ^22.2.0), singleton (une seule instance pour tous) et strictVersion (refuse une version hors de la plage).

Pourquoi Angular doit être un singleton. @angular/core n’est pas une bibliothèque de fonctions pures : c’est le runtime qui fait le rendu, l’injector, la Change Detection. Les templates compilés appellent les instructions du runtime du build avec lequel ils ont été compilés, donc un composant d’une copie ne peut pas être rendu par une autre. Même pour une bibliothèque ordinaire, deux copies donnent deux classes différentes : inject(AuthService) dans le remote demande un autre token que celui enregistré par le shell, et votre « singleton » a soudain deux instances.

Ce qui se passe quand les versions ne correspondent pas dépend de l’outil :

Pour Angular, « sa propre copie » ne sauve pas la situation : le remote aurait un autre runtime, donc ses composants ne peuvent pas entrer dans l’arbre du shell. Un remote sur une autre version majeure ne s’intègre qu’en isolation — comme Web Component avec son propre bootstrap, ou dans un iframe. Si vous préférez le découvrir au démarrage plutôt qu’à la navigation, l’orchestrator a l’option strict.strictExternalCompatibility, qui lève une erreur à l’initialisation au lieu de créer des scopes.

// Trois façons d’écrire `shared` dans federation.config.mjs

// 1. le défaut en 22.x : tout ce qui est dans dependencies de package.json, mêmes règles
shared: fromPackageJson({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),

// 2. le style classique (toujours exporté)
shared: { ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }) },

// 3. explicite, paquet par paquet
shared: share({
  '@angular/core': { singleton: true, strictVersion: true, requiredVersion: 'auto' },
  // a de l’état → singleton
  '@ngrx/signals': { singleton: true, strictVersion: true, requiredVersion: 'auto' },
  // utilitaire sans état : chaque remote peut avoir sa propre copie
  'date-fns': { singleton: false },
}),

// requiredVersion: 'auto' → la plage de package.json (p. ex. "^22.2.0")
// autoShareScope({ level: 'minor' }) → ne partage qu’entre remotes
//   de la même ligne de versions (p. ex. "ng22.2")

{
  "imports": {
    "@angular/core": "https://shell.example/core-22.2.2.js"
  },
  "scopes": {
    "https://cart.example/": {
      "@angular/core": "https://cart.example/core-22.1.4.js"
    }
  }
}

• Idéal : exactement la même version d’Angular dans le shell et dans tous les remotes. ^ donne de la tolérance entre mineures, mais le code compilé en AOT utilise des instructions internes du runtime — testez la combinaison, ne vous fiez pas à semver.
• Le host gagne : à chaque nouvelle mineure, le shell peut donc passer en premier, tant que les plages des remotes l’acceptent. Une nouvelle majeure exige une montée de version synchronisée, ou d’isoler le remote en retard.
• Singleton + strictVersion pour le framework et tout ce qui a de l’état : Angular, router, stores, design system, bibliothèque d’auth. Les utilitaires sans état peuvent rester non-singleton.
• autoShareScope() lie le partage à une ligne de versions (par exemple ng22.2), pour ne pas mélanger accidentellement des builds incompatibles.

Module Federation, Web Components, iframes

Module Federation (webpack)

@angular-architects/module-federation a une version pour Angular 22, mais c’est la variante « classique », sur webpack : ng add fait passer le projet du builder esbuild à @angular-builders/custom-webpack (à partir d’Angular 22 ; jusqu’à la 21 il utilisait ngx-build-plus), et il vous avertit explicitement que, pour les nouveaux projets, l’alternative est Native Federation. Il existe aussi un builder rspack, marqué expérimental. Ne le choisissez que si vous étendez un système Module Federation existant ou devez partager le runtime avec des remotes déjà construits sur webpack.

// Module Federation classique (webpack) — @angular-architects/module-federation 22.x
const {
  shareAll,
  withModuleFederationPlugin,
} = require('@angular-architects/module-federation/webpack');

module.exports = withModuleFederationPlugin({
  name: 'catalog',
  exposes: {
    './routes': './projects/catalog/src/app/catalog.routes.ts',
  },
  shared: {
    ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
  },
});

Web Components

Chaque remote démarre sa propre application avec createApplication() et définit une balise ; le shell se contente de la poser sur la page. Cela fonctionne entre versions majeures d’Angular différentes et entre frameworks, car rien n’est partagé. C’est exactement son coût : chaque bundle apporte son propre runtime (≈ 33 kB transférés pour un élément simple, mesurés sur la page Angular Elements), il n’y a pas de DI commune, et la communication passe par des attributs et des événements. Cela se combine bien avec la federation : un remote sur une autre majeure est exposé comme Web Component et chargé quand même via loadRemoteModule.

// Un remote sur une AUTRE version majeure d’Angular (ou un autre framework) : intégré en isolation,
// comme Web Component avec son propre runtime.
//
// remote — federation.config.mjs :  exposes: { './Bootstrap': './src/bootstrap.ts' }
// remote — bootstrap.ts :
//   createApplication(appConfig).then(({ injector }) =>
//     customElements.define('mfe-legacy', createCustomElement(App, { injector })));
//
// shell — une page qui charge le bundle (son effet : define), puis utilise la balise
import { CUSTOM_ELEMENTS_SCHEMA, Component, inject, input, resource } from '@angular/core';
import { NATIVE_FEDERATION } from '../app.config';

@Component({
  selector: 'app-legacy-page',
  schemas: [CUSTOM_ELEMENTS_SCHEMA],
  template: `
    @if (bundle.hasValue()) {
      <mfe-legacy [attr.customer-id]="customerId()"></mfe-legacy>
    } @else if (bundle.error()) {
      <p role="alert">
        Le module legacy n’est pas disponible.
        <button (click)="bundle.reload()">Réessayer</button>
      </p>
    }
  `,
})
export class LegacyPage {
  private readonly nf = inject(NATIVE_FEDERATION);
  readonly customerId = input.required<string>();

  protected readonly bundle = resource({
    loader: () => this.nf.loadRemoteModule('legacy', './Bootstrap'),
  });
}

iframes

L’isolation la plus forte : un autre document, un autre JavaScript, un autre CSS ; les erreurs, les fuites mémoire et les styles restent dans le frame, et avec sandbox vous pouvez exécuter du code auquel vous ne faites pas confiance. Vous la payez en intégration : la hauteur se synchronise via postMessage, un dialog ne peut pas sortir du frame, les deep links et l’historique du navigateur doivent être reliés à la main, le focus et l’accessibilité se compliquent, et chaque frame charge toute l’application. Adapté au code tiers, aux applications legacy que vous ne pouvez pas modifier et aux outils internes.

<!-- L’isolation la plus forte : un autre document, un autre JS, un autre CSS ;
     les erreurs restent dans le frame -->
<iframe
  src="https://billing.exemplu.ro/embed?customer=42"
  title="Facturation"
  sandbox="allow-scripts allow-same-origin allow-forms"
  loading="lazy"
  style="width: 100%; border: 0"
></iframe>

<!-- Le prix : la hauteur se communique via postMessage, un dialog ne peut pas sortir
     du frame, les deep links et l’historique du navigateur se synchronisent à la main,
     et chaque frame charge toute l’application. -->

Contrats, communication, fallback

Le contrat d’un remote, c’est tout ce qui en dépend de l’extérieur : les clés de exposes, ce qu’elles exportent, les paramètres de route qu’elles lisent, les événements qu’elles émettent et les dépendances partagées. Traitez-le comme une API publique avec semver : un changement incompatible signifie une nouvelle clé (./routes-v2), et l’ancienne reste jusqu’à ce que le shell migre.

La communication, dans l’ordre où elle vaut la peine d’être essayée :

1. L’URL — paramètres de route et query params. Gratuite, accessible par lien direct, elle survit à un rafraîchissement, et le remote n’importe rien d’un autre remote.
2. Des événements typés sur window, depuis un minuscule paquet contracts (types + emit/listen). N’oubliez pas celui qui démarre tard : il doit demander l’état.
3. Quelques petits Services, partagés en singletons — auth, utilisateur courant, feature flags — depuis une bibliothèque incluse dans shared.

À éviter : un Store global commun (le même Store NgRx, ou le même Service qui détient tout l’état, utilisé par chaque remote). Tout changement de la forme de l’état devient un changement coordonné entre équipes — exactement le couplage que vous vouliez supprimer. Chaque remote garde son propre état ; seuls des événements et des URL circulent entre eux (voir aussi State Management).

// 1. L’URL est le premier canal : gratuite, accessible par lien direct, survit à un rafraîchissement.
//    /catalog/audio?sort=price → le remote lit l’URL, pas un Store partagé.
//    (withComponentInputBinding() va dans le SHELL : les routes du remote
//    s’exécutent dans le routeur du shell)
export class ProductList {
  readonly category = input<string>();                 // depuis :category
  readonly sort = input<'price' | 'rating'>('rating'); // depuis ?sort=
}

// 2. La navigation entre remotes passe aussi par l’URL :
//    le remote n’importe rien d’un autre remote.
this.router.navigate(['/cart'], { queryParams: { added: product.id } });

Fallback. N’importe quel remote peut manquer : un déploiement raté, un CDN en panne, une erreur dans le manifest d’un environnement. Deux situations, deux solutions :

• Une route entière : laissez loadChildren échouer et transformez l’erreur en redirection avec withNavigationErrorHandler. Un loader rejeté n’est pas mis en cache par le routeur, donc la navigation suivante réessaie le remote.
• Un remote dans une page (un widget, un slot) : un composant du shell charge le remote avec resource, avec un timeout, un fallback et reload() pour « Réessayer » — comme dans le premier exemple.

// Une ROUTE de remote EN ÉCHEC : laissez loadChildren échouer et redirigez.
// Un loader rejeté n’est PAS mis en cache par le routeur → la navigation suivante réessaie.
import { ApplicationConfig, inject } from '@angular/core';
import {
  NavigationError,
  RedirectCommand,
  Router,
  provideRouter,
  withNavigationErrorHandler,
} from '@angular/router';
import type { NativeFederationResult } from '@angular-architects/native-federation';
import { routes } from './app.routes';

export const appConfig = (nf: NativeFederationResult): ApplicationConfig => ({
  providers: [
    provideRouter(
      routes(nf),
      withNavigationErrorHandler((e: NavigationError) => {
        const router = inject(Router);
        const target = `/indisponibil?url=${encodeURIComponent(e.url)}`;
        return new RedirectCommand(router.parseUrl(target));
      }),
    ),
  ],
});

// ✗ Le piège : un fallback renvoyé par le loader est un SUCCÈS pour le routeur.
//   Il est mis en cache sur la route jusqu’au rechargement de la page, donc « Réessayer »
//   n’atteint plus jamais le remote :
//   loadComponent: () => nf.loadRemoteModule(...).then(...).catch(() => RemoteDown)

Quand OUI, quand NON

La décision dépend de l’organisation plus que du code. Le score ci-dessous applique les règles de cette page : ce n’est pas une formule magique, mais il vous force à répondre aux questions qui comptent et vous montre pourquoi une recommandation ressort.

Pièges fréquents

• La bibliothèque « partagée » qui n’est pas dans shared → chaque remote l’embarque séparément, donc providedIn: 'root' produit deux instances (deux classes, deux tokens). Incluez les bibliothèques avec état dans shared et vérifiez remoteEntry.json.
• singleton: false sur @angular/core ou un remote sur une autre majeure → deux runtimes Angular. La même version partout ; pour les exceptions, l’isolation (Web Component, iframe).
• strictVersion: false pour que ça « passe » → le message disparaît de la console, le problème reste et apparaît en production. Corrigez les versions, pas le flag.
• Un fallback renvoyé par loadComponent (.catch(() => RemoteDown)) → le routeur le met en cache sur la route jusqu’au rafraîchissement, et « Réessayer » n’atteint jamais le remote. Laissez le loader échouer, ou utilisez un composant host avec reload().
• Pas de timeout → un remoteEntry.json qui ne répond pas laisse la page en « chargement » pour toujours. Mettez un timeout sur chaque chargement de remote.
• Un seul manifest pour tous les environnements → le staging charge les remotes de production (ou l’inverse). Un manifest par environnement, généré au déploiement.
• Un Store global commun entre remotes → des releases en lockstep, un monolithe distribué. État local + événements + URL.
• Un remote qui importe du code directement d’un autre remote → une dépendance cachée entre déploiements. Tout passe par libs/contracts ou par l’URL.
• Des routes absolues écrites dans un remote (/products/42) → elles cassent quand le shell le monte sous un autre préfixe. Naviguez relativement à la route active.
• Du CSS global dans les remotes → les styles d’une équipe cassent ceux d’une autre. Pas de styles globaux dans les remotes ; des tokens CSS issus du design system ; ShadowDom pour les Web Components.
• Des erreurs sans contexte → vous ne savez pas quel remote, dans quelle version, a planté. Attachez le nom et la version du remote à chaque erreur remontée (voir gestion des erreurs).

Aide-mémoire

// REMOTE — federation.config.mjs
withNativeFederation({
  name: 'catalog',
  exposes: { './routes': './src/app/catalog.routes.ts' }, // API publique, versionnée
  shared: fromPackageJson({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
});

// SHELL — public/federation.manifest.json (un par environnement : dev / staging / prod)
// { "catalog": "https://catalog.exemplu.ro/remoteEntry.json" }

// SHELL — main.ts
initFederation('federation.manifest.json')
  .then((nf) => import('./bootstrap').then((m) => m.bootstrap(nf)));

// SHELL — routes
const catalog = {
  path: 'catalog',
  loadChildren: () =>
    nf.loadRemoteModule<{ CATALOG_ROUTES: Routes }>('catalog', './routes')
      .then((m) => m.CATALOG_ROUTES),
};

// VERSIONS : la même version d’Angular partout ; le host a priorité.
//   incompatible + strictVersion    → copie propre dans les scopes (NF)
//                                     "Unsatisfied version …" (webpack MF)
//   incompatible, sans strictVersion → utilise la version partagée + avertissement
// COMMUNICATION : URL → événements typés (libs/contracts) → petits Services partagés.
//   Pas de Stores communs.
// ÉCHEC : route → withNavigationErrorHandler + redirection
//          slot → composant host avec timeout + resource.reload()
// AUTRE MAJEURE / AUTRE FRAMEWORK → Web Component avec son propre runtime, ou iframe