Angular 19 en entretien : Signals, SSR et les questions incontournables

Les entretiens Angular en 2026 testent bien plus que les composants et les services. Angular 19, sorti en novembre 2024, a introduit des changements architecturaux majeurs : Signals stables, SSR avec hydratation incrémentale et détection de changement zoneless. Maîtriser ces concepts fait la différence entre un candidat junior et un candidat senior.

Signals Angular 19 : le nouveau modèle de réactivité

Les Signals représentent le changement le plus fondamental d'Angular depuis l'introduction du change detection. Un Signal est une valeur réactive synchrone qui notifie automatiquement ses consommateurs lorsqu'elle change.

Question type : "Quelle différence entre un Signal et un Observable RxJS ?"

La réponse attendue distingue clairement les deux modèles :

import { signal, computed, effect } from '@angular/core';

// Signal : synchrone, valeur toujours disponible
const count = signal(0);
const doubled = computed(() => count() * 2); // Recalculé uniquement si count change

// Effect : réaction aux changements de signals
effect(() => {
  console.log(`Count: ${count()}, Doubled: ${doubled()}`);
});

count.set(5); // Notification immédiate, synchrone

Les Signals utilisent un graphe de dépendances fin. Contrairement à RxJS qui gère des flux asynchrones complexes (retry, debounce, merge), les Signals optimisent la réactivité synchrone de l'UI. Angular 19 recommande les Signals pour l'état du composant et RxJS pour les flux asynchrones (requêtes HTTP, WebSockets).

Signal Inputs et Queries : migration depuis @Input()

Angular 19 stabilise les API signal-based pour les inputs, outputs et queries. Cette question revient systématiquement en entretien.

Question type : "Comment migrer un @Input() classique vers un Signal Input ?"

import { Component, input, computed } from '@angular/core';

@Component({
  selector: 'app-user-card',
  template: `
    <div class="card">
      <h3>{{ fullName() }}</h3>
      <span>{{ role() }}</span>
    </div>
  `
})
export class UserCardComponent {
  // Signal inputs : typage strict, valeur par défaut optionnelle
  firstName = input.required<string>();
  lastName = input.required<string>();
  role = input<string>('developer'); // Valeur par défaut

  // Computed dérivé des inputs : recalculé automatiquement
  fullName = computed(() => `${this.firstName()} ${this.lastName()}`);
}

L'avantage clé : les Signal Inputs permettent de créer des computed() dérivés directement, sans lifecycle hooks. Plus besoin de ngOnChanges pour réagir aux changements d'inputs. Angular fournit le schematic signal-input-migration pour automatiser la migration.

linkedSignal : synchroniser des états dépendants

linkedSignal est une API expérimentale d'Angular 19 qui crée un signal en écriture lié à une source. Ce concept est fréquemment testé en entretien senior.

Question type : "Comment gérer un état dérivé modifiable avec linkedSignal ?"

import { signal, linkedSignal } from '@angular/core';

// Liste de catégories qui peut changer
const categories = signal(['frontend', 'backend', 'devops']);

// Sélection liée : se réinitialise quand les catégories changent
const selectedCategory = linkedSignal({
  source: categories,
  computation: (cats) => cats[0] // Reset au premier élément
});

// Modification manuelle possible
selectedCategory.set('backend');

// Si categories change, selectedCategory se réinitialise automatiquement
categories.set(['mobile', 'data', 'cloud']);
// selectedCategory() === 'mobile'

Cas d'usage concret : un dropdown de filtres dont la sélection se réinitialise quand la liste source change. Sans linkedSignal, ce pattern nécessitait un effect() avec set() — un anti-pattern qui crée des boucles de mise à jour.

Resource API : charger des données asynchrones avec les Signals

Angular 19 introduit l'API resource (expérimentale) pour le chargement asynchrone. Cette API remplace le pattern classique service + subscribe dans les composants.

import { resource, signal } from '@angular/core';
import { inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';

const userId = signal(42);
const http = inject(HttpClient);

// Resource : lie un signal source à un chargement async
const userResource = resource({
  request: () => ({ id: userId() }),  // Recalculé si userId change
  loader: async ({ request }) => {
    const response = await fetch(`/api/users/${request.id}`);
    return response.json();
  }
});

// Accès dans le template
// userResource.value()   → les données (ou undefined)
// userResource.isLoading() → boolean
// userResource.error()    → erreur éventuelle

En entretien, démontrer la connaissance de resource vs rxResource (version RxJS) montre une veille technologique active. rxResource utilise des Observables comme loader, utile pour les équipes avec une base RxJS existante.

SSR et hydratation incrémentale dans Angular 19

Angular 19 fait passer le SSR à un niveau supérieur avec l'hydratation incrémentale en developer preview. Cette fonctionnalité, testée à l'échelle de Google Search, est un sujet d'entretien de plus en plus fréquent.

Question type : "Comment fonctionne l'hydratation incrémentale d'Angular 19 ?"

L'hydratation classique re-crée l'arbre de composants entier côté client après le rendu serveur. L'hydratation incrémentale hydrate uniquement les composants nécessaires, au moment où ils deviennent visibles ou interactifs.

import { Component } from '@angular/core';

@Component({
  template: `
    <app-header />
    <app-product-details [id]="productId" />

    <!-- Hydraté uniquement quand visible dans le viewport -->
    @defer (on viewport) {
      <app-reviews [productId]="productId" />
    }

    <!-- Hydraté uniquement à l'interaction utilisateur -->
    @defer (on interaction) {
      <app-comment-form />
    }
  `
})
export class ProductPageComponent {
  productId = 'angular-19-guide';
}

La directive @defer contrôle précisément le moment de l'hydratation. Les triggers disponibles : on viewport (visible), on interaction (clic, focus), on idle (navigateur inactif), on timer(5s) (délai). Le contenu reste visible en HTML statique avant hydratation — aucun flash de contenu.

Route-level render mode : SSR granulaire par route

Angular 19 introduit le render mode au niveau des routes, permettant de mixer SSR, SSG et CSR dans la même application.

import { RenderMode, ServerRoute } from '@angular/ssr';

export const serverRoutes: ServerRoute[] = [
  // Pages marketing : pré-rendues au build (SSG)
  { path: '', renderMode: RenderMode.Prerender },
  { path: 'pricing', renderMode: RenderMode.Prerender },

  // Dashboard : rendu côté serveur à chaque requête (SSR)
  { path: 'dashboard/**', renderMode: RenderMode.Server },

  // Éditeur interactif : rendu côté client uniquement (CSR)
  { path: 'editor/**', renderMode: RenderMode.Client },
];

En entretien, la capacité à justifier le choix du render mode par route démontre une compréhension des trade-offs performance/SEO/interactivité. Les pages statiques (landing, blog) bénéficient du prerender. Les pages dynamiques avec données utilisateur utilisent le SSR. Les applications fortement interactives restent en CSR.

Détection de changement zoneless : architecture sans Zone.js

La détection de changement sans Zone.js est l'évolution architecturale la plus significative d'Angular 19. Cette question est devenue incontournable en entretien senior.

Question type : "Comment fonctionne la détection de changement sans Zone.js ?"

import { bootstrapApplication } from '@angular/platform-browser';
import {
  provideExperimentalZonelessChangeDetection
} from '@angular/core';
import { AppComponent } from './app.component';

bootstrapApplication(AppComponent, {
  providers: [
    provideExperimentalZonelessChangeDetection()
  ]
});

Sans Zone.js, Angular ne patche plus les API asynchrones du navigateur (setTimeout, Promise, addEventListener). La détection de changement se déclenche uniquement via les Signals. Les bénéfices mesurables :

• Réduction du bundle de 10-15 KB (suppression de zone.js)
• Stack traces propres sans frames Zone.js
• Détection de changement ciblée : seuls les composants affectés par un Signal modifié sont re-rendus

Standalone par défaut : la fin des NgModules

Angular 19 fait des composants standalone le défaut. Le flag standalone: true n'est plus nécessaire. Cette décision simplifie l'architecture et réduit le boilerplate.

Question type : "Quel impact a standalone par défaut sur l'architecture d'une application Angular ?"

@Component({
  selector: 'app-dashboard',
  imports: [CommonModule, RouterModule, UserCardComponent],
  template: `
    <nav>
      <a routerLink="/home">Accueil</a>
    </nav>
    @for (user of users(); track user.id) {
      <app-user-card [firstName]="user.firstName" [lastName]="user.lastName" />
    }
  `
})
export class DashboardComponent {
  users = signal<User[]>([]);
}

Chaque composant déclare explicitement ses dépendances via imports. Les NgModules restent disponibles pour la rétrocompatibilité, mais les nouvelles applications Angular 19+ n'en ont plus besoin. En entretien, expliquer la migration progressive (composant par composant) plutôt qu'un big bang est valorisé.

Stratégies de réponse en entretien Angular 19

Les recruteurs techniques évaluent trois dimensions sur Angular 19 :

• Compréhension architecturale : expliquer pourquoi les Signals remplacent progressivement Zone.js, pas seulement comment les utiliser
• Trade-offs : savoir quand utiliser computed() vs linkedSignal vs effect(), et quand garder RxJS
• Migration : décrire une stratégie de migration incrémentale depuis une application Angular classique vers les Signals et le mode zoneless

La clé : ne pas réciter la documentation officielle Angular. Illustrer chaque réponse avec un cas d'usage concret tiré d'un projet réel — un formulaire complexe, une page e-commerce avec SSR, un dashboard temps réel.

Pour approfondir les bases Angular avant l'entretien, consulter le guide complet des 25 questions d'entretien Angular.

Conclusion

• Les Signals Angular 19 remplacent les patterns @Input() + ngOnChanges par un modèle réactif fin et synchrone — signal(), computed(), input() couvrent 90% des cas
• linkedSignal résout le problème des états dérivés modifiables sans recourir à l'anti-pattern effect() + set()
• L'hydratation incrémentale via @defer réduit le Time to Interactive sans sacrifier le SEO — chaque composant s'hydrate selon son trigger
• Le mode zoneless supprime Zone.js du bundle et cible la détection de changement aux seuls composants affectés par un Signal
• Le render mode par route permet de mixer SSG, SSR et CSR dans la même application selon les besoins de chaque page
• Les composants standalone par défaut éliminent le besoin de NgModules pour les nouvelles applications
• En entretien, démontrer les trade-offs (Signals vs RxJS, SSR vs CSR, zoneless vs Zone.js) compte plus que la syntaxe