@dsivd/prestations-ng 19.2.0-beta.11 → 19.2.0-beta.13

package/INTRODUCTION_ANGULAR_SIGNALS.md

@@ -1,60 +1,60 @@
-# Introduction aux Signaux Angular
+# Introduction to Angular Signals
 
-**Objectif** : compréhension solide de `signal()`, `computed()`, `effect()`, `input()`/`model()` et `linkedSignal()`, ainsi que des réflexes pour éviter les pièges les plus fréquents (mutation vs réassignation, sur-tracking dans `effect()`).
+**Goal**: a solid understanding of `signal()`, `computed()`, `effect()`, `input()`/`model()` and `linkedSignal()`, as well as the reflexes to avoid the most frequent pitfalls (mutation vs reassignment, over-tracking in `effect()`).
 
 ---
 
-## Plan de session
+## Session outline
 
-| #   | Bloc                                                        |
-| --- | ----------------------------------------------------------- |
-| 1.  | Pourquoi les signaux ?                                      |
-| 2.  | Les 3 primitives : `signal()`, `computed()`, `effect()`     |
-| 3.  | `input()` et `model()` : le nouveau contrat des composants  |
-| 4.  | `linkedSignal()` : l'état local qui se resynchronise        |
-| 5.  | `untracked()` : maîtriser les dépendances d'un `effect()`   |
-| 6.  | RxJS interop : signaux **et** RxJS, pas l'un contre l'autre |
-| 7.  | Le piège n°1 : mutation vs réassignation                    |
+| #   | Block                                                         |
+| --- | ------------------------------------------------------------- |
+| 1.  | Why signals?                                                  |
+| 2.  | The 3 primitives: `signal()`, `computed()`, `effect()`        |
+| 3.  | `input()` and `model()`: the new contract of components       |
+| 4.  | `linkedSignal()`: local state that resynchronizes             |
+| 5.  | `untracked()`: controlling the dependencies of an `effect()`  |
+| 6.  | RxJS interop: signals **and** RxJS, not one against the other |
+| 7.  | Pitfall #1: mutation vs reassignment                          |
 
 ---
 
-## 1. Pourquoi les signaux ?
+## 1. Why signals?
 
-**Avant** : Angular détecte les changements en réexécutant (potentiellement) **tout l'arbre de composants** à chaque événement asynchrone intercepté par **Zone.js** (clic, timer, XHR...). Efficace historiquement, mais coûteux et peu prévisible à grande échelle.
+**Before**: Angular detects changes by (potentially) re-running **the whole component tree** on every asynchronous event intercepted by **Zone.js** (click, timer, XHR...). Historically effective, but costly and hard to predict at scale.
 
-**Avec les signaux** : chaque valeur réactive **déclare explicitement** qui en dépend. Angular ne recalcule/ré-affiche que ce qui a réellement changé. C'est un modèle **fine-grained** et **déclaratif**.
+**With signals**: each reactive value **explicitly declares** what depends on it. Angular only recomputes/re-renders what has actually changed. It's a **fine-grained** and **declarative** model.
 
-> 🎤 on ne "déclenche" plus la détection de changement, on **décrit un flux de données**. Le framework se charge de propager.
+> 🎤 we no longer "trigger" change detection, we **describe a data flow**. The framework takes care of propagating it.
 
 ---
 
-## 2. Les 3 primitives de base
+## 2. The 3 basic primitives
 
-### `signal()` — une valeur réactive modifiable
+### `signal()` — a writable reactive value
 
 ```ts
 readonly count = signal(0);
 
 increment(): void {
   this.count.update(v => v + 1);
-  // ou, pour remplacer complètement la valeur :
+  // or, to replace the value completely:
   this.count.set(5);
 }
 ```
 
-⚠️ **il n'y a pas de `.mutate()`**. C'était dans la proposition initiale, retiré avant la version stable. On ne modifie jamais la valeur en place — on refait toujours passer par `.set()` / `.update()` avec une nouvelle référence (on y revient en détail au bloc 6).
+⚠️ **there is no `.mutate()`**. It was in the initial proposal, and removed before the stable release. You never modify the value in place — you always go through `.set()` / `.update()` with a new reference (covered in detail in block 7).
 
-### `computed()` — une valeur dérivée, en lecture seule
+### `computed()` — a derived, read-only value
 
 ```ts
 readonly fullName = computed(() => `${this.firstName()} ${this.lastName()}`);
 ```
 
-- Pure et synchrone, jamais de `.set()` à l'intérieur
-- Paresseux et mémoïsé : ne se recalcule que si une dépendance change
-- Les dépendances sont détectées **automatiquement** — pas besoin de les déclarer
+- Pure and synchronous, never a `.set()` inside
+- Lazy and memoized: only recomputed when a dependency changes
+- Dependencies are detected **automatically** — no need to declare them
 
-### `effect()` — un effet de bord
+### `effect()` — a side effect
 
 ```ts
 effect(() => {
@@ -62,17 +62,17 @@ effect(() => {
 });
 ```
 
-- S'exécute au moins une fois à l'initialisation
-- Se nettoie automatiquement à la destruction du composant
-- **Tout signal lu de façon synchrone dans le corps devient une dépendance** — y compris ceux qu'on ne voulait pas "trigger" (on y revient au bloc 5)
+- Runs at least once at initialization
+- Cleans itself up automatically when the component is destroyed
+- **Every signal read synchronously in its body becomes a dependency** — including the ones you didn't want to "trigger" it (covered in block 5)
 
-**Exemple concret — les trois primitives ensemble :**
+**Concrete example — the three primitives together:**
 
 ```ts
 @Component({
     selector: 'app-counter',
     template: `
-        <p>Count : {{ count() }} ({{ isEven() ? 'pair' : 'impair' }})</p>
+        <p>Count: {{ count() }} ({{ isEven() ? 'even' : 'odd' }})</p>
         <button (click)="increment()">+1</button>
     `,
 })
@@ -81,7 +81,7 @@ export class CounterComponent {
     readonly isEven = computed(() => this.count() % 2 === 0);
 
     constructor() {
-        // se déclenche à l'init, puis à chaque changement de `count`
+        // runs at init, then on every change of `count`
         effect(() => console.log(`count = ${this.count()}`));
     }
 
@@ -91,68 +91,68 @@ export class CounterComponent {
 }
 ```
 
-Remarque : `isEven` ne se recalcule que quand `count` change (mémoïsation), et le template ne se ré-affiche que sur la portion concernée — pas de re-render de tout le composant.
+Note: `isEven` is only recomputed when `count` changes (memoization), and the template only re-renders the affected part — no re-render of the whole component.
 
-### Mental model à donner à l'équipe
+### Mental model to give the team
 
-| Je veux...                                           | J'utilise... |
-| ---------------------------------------------------- | ------------ |
-| Transformer / dériver une donnée                     | `computed()` |
-| Synchroniser avec le DOM, un service externe, logger | `effect()`   |
+| I want to...                                       | I use...     |
+| -------------------------------------------------- | ------------ |
+| Transform / derive data                            | `computed()` |
+| Synchronize with the DOM, an external service, log | `effect()`   |
 
-🚩 **Le red flag à apprendre à repérer** : un `effect()` qui fait `.set()` sur un autre signal est presque toujours un `computed()` déguisé.
+🚩 **The red flag to learn to spot**: an `effect()` that calls `.set()` on another signal is almost always a disguised `computed()`.
 
 ```ts
-// 🔴 À corriger dès que vu en review
+// 🔴 To fix as soon as seen in review
 effect(() => {
   this.minYear.set(this.minDate()?.[0] ?? dayjs().year() - 100);
 });
 
-// 🟢 Ce que c'est vraiment
+// 🟢 What it really is
 readonly minYear = computed(() => this.minDate()?.[0] ?? dayjs().year() - 100);
 ```
 
 ---
 
-## 3. `input()` et `model()` : le nouveau contrat des composants
+## 3. `input()` and `model()`: the new contract of components
 
-### `input()` remplace `@Input()` (binding parent → enfant, une direction)
+### `input()` replaces `@Input()` (parent → child binding, one direction)
 
 ```ts
-// Avant
+// Before
 @Input() closeable = true;
 
-// Après
+// After
 readonly closeable = input(true);
 ```
 
-### `model()` remplace la paire `@Input()` + `@Output()` (binding bidirectionnel)
+### `model()` replaces the `@Input()` + `@Output()` pair (two-way binding)
 
 ```ts
-// Avant
+// Before
 @Input() isVisible = false;
 @Output() isVisibleChange = new EventEmitter<boolean>();
 
-// Après
+// After
 readonly isVisible = model(false);
 ```
 
 ```html
-<!-- deux sens -->
+<!-- both ways -->
 <my-component [(isVisible)]="open" />
 ```
 
-| Scénario                                                | Outil            |
-| ------------------------------------------------------- | ---------------- |
-| Le parent écrit, l'enfant lit seulement                 | `input()`        |
-| Le parent écrit, l'enfant réécrit, le parent lit        | `model()`        |
-| Le parent écrit, l'enfant réécrit, le parent ne lit pas | `linkedSignal()` |
-| Dérivé d'autres inputs                                  | `computed()`     |
+| Scenario                                                          | Tool             |
+| ----------------------------------------------------------------- | ---------------- |
+| The parent writes, the child only reads                           | `input()`        |
+| The parent writes, the child writes back, the parent reads        | `model()`        |
+| The parent writes, the child writes back, the parent doesn't read | `linkedSignal()` |
+| Derived from other inputs                                         | `computed()`     |
 
-**Exemple concret — avant/après sur un composant type modale :**
+**Concrete example — before/after on a modal-like component:**
 
 ```ts
-// 🔴 Avant : @Input()/@Output() + synchronisation manuelle
+// 🔴 Before: @Input()/@Output() + manual synchronization
 @Input() isVisible = false;
 @Output() isVisibleChange = new EventEmitter<boolean>();
 
@@ -163,7 +163,7 @@ close(): void {
 ```
 
 ```ts
-// 🟢 Après : model()
+// 🟢 After: model()
 readonly isVisible = model(false);
 
 close(): void {
@@ -172,26 +172,26 @@ close(): void {
 ```
 
 ```html
-<!-- Côté parent : aucun code de synchronisation à écrire -->
+<!-- On the parent side: no synchronization code to write -->
 <app-modal [(isVisible)]="showModal" />
 ```
 
 ---
 
-## 4. `linkedSignal()` : l'état local qui se resynchronise
+## 4. `linkedSignal()`: local state that resynchronizes
 
-Le chaînon manquant entre `computed()` (lecture seule) et `signal()` (aucune synchro automatique) : une valeur **modifiable localement**, mais qui **se réinitialise** quand une source change.
+The missing link between `computed()` (read-only) and `signal()` (no automatic synchronization): a value that is **writable locally**, but that **resets** when a source changes.
 
 ```ts
 readonly options = input<string[]>([]);
 readonly selectedOption = linkedSignal(() => this.options()[0]);
 
-// L'utilisateur peut toujours écrire dessus...
+// The user can still write to it...
 this.selectedOption.set('other value');
-// ...jusqu'à ce que `options` change, auquel cas ça se réinitialise.
+// ...until `options` changes, in which case it resets.
 ```
 
-🚩 **Red flag à apprendre** : un `effect()` qui reset un `signal()` classique quand une autre valeur change est un `linkedSignal()` qui s'ignore.
+🚩 **Red flag to learn**: an `effect()` that resets a plain `signal()` when another value changes is a `linkedSignal()` in disguise.
 
 ```ts
 // 🔴
@@ -202,7 +202,7 @@ effect(() => this.selectedOption.set(this.options()[0]));
 readonly selectedOption = linkedSignal(() => this.options()[0]);
 ```
 
-**Exemple concret — un `select` dont les options viennent du parent :**
+**Concrete example — a `select` whose options come from the parent:**
 
 ```ts
 @Component({
@@ -221,100 +221,100 @@ readonly selectedOption = linkedSignal(() => this.options()[0]);
 export class BranchSelectComponent {
     readonly branches = input<string[]>([]);
 
-    // se réinitialise sur le premier élément à chaque changement de `branches`,
-    // mais reste librement modifiable par l'utilisateur entre deux changements
+    // resets to the first element on every change of `branches`,
+    // but stays freely writable by the user between two changes
     readonly selectedBranch = linkedSignal(() => this.branches()[0]);
 }
 ```
 
-Sans `linkedSignal()`, il faudrait un `effect()` qui fait `.set()` sur un `signal()` classique à chaque changement de `branches` — exactement le red flag vu plus haut.
+Without `linkedSignal()`, you would need an `effect()` calling `.set()` on a plain `signal()` on every change of `branches` — exactly the red flag seen above.
 
 ---
 
-## 5. `untracked()` : maîtriser les dépendances d'un `effect()`
+## 5. `untracked()`: controlling the dependencies of an `effect()`
 
-Un `effect()` s'abonne à **tout** signal lu de façon synchrone dans son corps — pas seulement à ceux qu'on avait en tête comme déclencheurs. `untracked()` permet de lire une valeur **sans** créer cette dépendance.
+An `effect()` subscribes to **every** signal read synchronously in its body — not only to the ones you had in mind as triggers. `untracked()` reads a value **without** creating this dependency.
 
 ```ts
 effect(() => {
-    const id = this.userId(); // tracké
-    const config = untracked(() => this.appConfig()); // lu, mais pas tracké
+    const id = this.userId(); // tracked
+    const config = untracked(() => this.appConfig()); // read, but not tracked
     this.analytics.logUserView(id, config);
 });
 ```
 
-Cas d'usage le plus fréquent dans nos composants : un `effect()` qui lit **et** réécrit potentiellement le même signal (ex. corriger un `model()` de texte selon un préfixe).
+Most frequent use case in our components: an `effect()` that reads **and** possibly writes back the same signal (e.g. fixing a text `model()` according to a prefix).
 
-⚠️ **Piège à ne pas commettre** : ici, il ne faut **pas** faire `untracked(() => this.value())` sur le signal principal qu'on veut corriger — si on l'untrack, l'effect ne sera plus jamais redéclenché quand `value` change ailleurs (ex. la frappe de l'utilisateur), donc plus aucune correction ne se produira après le premier passage. `untracked()` sert à exclure des **signaux secondaires** qui ne doivent pas déclencher l'effect (un flag de config par exemple) — pas le signal principal qu'on observe.
+⚠️ **Pitfall to avoid**: here, you must **not** do `untracked(() => this.value())` on the main signal you want to fix — if you untrack it, the effect will never be triggered again when `value` changes elsewhere (e.g. the user typing), so no fix will happen anymore after the first run. `untracked()` is for excluding **secondary signals** that must not trigger the effect (a configuration flag for example) — not the main signal being observed.
 
-La sécurité contre la boucle infinie ne vient pas d'`untracked()` dans ce cas, mais de la **convergence** : l'effet ne réécrit que si une condition change réellement, donc le second passage (déclenché par sa propre écriture) devient un no-op.
+The protection against the infinite loop doesn't come from `untracked()` in this case, but from **convergence**: the effect only writes if a condition really changes, so the second run (triggered by its own write) becomes a no-op.
 
 ```ts
-private previousPrefix = DEFAULT_PREFIX; // simple champ de classe, pas un signal : pas besoin de réactivité dessus
+private previousPrefix = DEFAULT_PREFIX; // plain class field, not a signal: no need for reactivity on it
 
 effect(() => {
-  let valueCopy = this.value();      // tracké : l'effect DOIT réagir aux changements de value
-  const prefix = this.prefix();      // tracké : l'effect DOIT réagir aux changements de prefix
+  let valueCopy = this.value();      // tracked: the effect MUST react to the changes of value
+  const prefix = this.prefix();      // tracked: the effect MUST react to the changes of prefix
 
-  // signal secondaire, hors sujet pour le déclenchement de cet effect : untracked() légitime
+  // secondary signal, irrelevant for triggering this effect: untracked() is legitimate
   if (untracked(() => this.trimOnBlur())) {
     valueCopy = valueCopy?.trim() ?? null;
   }
 
-  // Le prefix a changé : on corrige value et on notifie le parent
+  // The prefix has changed: fix value and notify the parent
   if (!valueCopy?.includes(prefix)) {
     const withoutOldPrefix = valueCopy?.includes(this.previousPrefix)
       ? valueCopy.slice(this.previousPrefix.length)
       : valueCopy;
 
-    this.value.set(withoutOldPrefix); // re-déclenche cet effect (voulu, cf. commentaire ci-dessous)
-    this.onUserInput(withoutOldPrefix); // vrai effet de bord (ex: notifier le parent)
+    this.value.set(withoutOldPrefix); // triggers this effect again (intended, see the comment below)
+    this.onUserInput(withoutOldPrefix); // real side effect (e.g. notify the parent)
   }
 
-  // ⚠️ Ce .set() ci-dessus re-déclenche cet effect une 2e fois (attendu) :
-  // au 2e passage, valueCopy.includes(prefix) devient vrai → plus d'écriture → convergence.
+  // ⚠️ The .set() above triggers this effect a 2nd time (expected):
+  // on the 2nd run, valueCopy.includes(prefix) becomes true → no more write → convergence.
   this.previousPrefix = prefix;
 });
 ```
 
-Ce qui rend ce `.set()` sur `value` légitime malgré le red flag de la section 2 : l'effect fait aussi `onUserInput()`, un vrai effet de bord (notifier le parent) — ce n'est pas une dérivation pure, donc pas un `computed()` déguisé.
+What makes this `.set()` on `value` legitimate despite the red flag of section 2: the effect also calls `onUserInput()`, a real side effect (notifying the parent) — it's not a pure derivation, so not a disguised `computed()`.
 
-⚠️ `untracked()` ne remplace pas une garde de convergence. Il contrôle **ce qui déclenche** l'effet (signaux secondaires à exclure), pas le fait qu'une écriture sur le signal principal doive être conditionnelle pour éviter une boucle infinie — ce sont deux problèmes différents, qui se combinent souvent dans le même effect comme ci-dessus.
+⚠️ `untracked()` doesn't replace a convergence guard. It controls **what triggers** the effect (secondary signals to exclude), not the fact that a write on the main signal must be conditional to avoid an infinite loop — these are two different problems, which are often combined in the same effect as above.
 
 ---
 
-## 6. RxJS interop : signaux **et** RxJS, pas l'un contre l'autre
+## 6. RxJS interop: signals **and** RxJS, not one against the other
 
-> 🎤 **on ne migre pas tout le RxJS existant vers des signaux**. Les deux modèles répondent à des besoins différents, et le mélanger au mauvais endroit est aussi un piège.
+> 🎤 **we don't migrate all the existing RxJS to signals**. Both models answer different needs, and mixing them in the wrong place is a pitfall too.
 
-|           | Signal                                              | Observable (RxJS)                                                                                                      |
-| --------- | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
-| Modèle    | **État** — une valeur à un instant T                | **Flux** — une séquence de valeurs dans le temps                                                                       |
-| Mode      | Pull (on lit `signal()` quand on veut)              | Push (on s'abonne, on reçoit)                                                                                          |
-| Fort pour | État de composant, dérivations synchrones, template | Async (HTTP, WebSocket), opérateurs (`debounceTime`, `switchMap`, `retry`, `combineLatest`...), annulation de requêtes |
+|            | Signal                                             | Observable (RxJS)                                                                                                   |
+| ---------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
+| Model      | **State** — a value at a time T                    | **Stream** — a sequence of values over time                                                                         |
+| Mode       | Pull (you read `signal()` when you want)           | Push (you subscribe, you receive)                                                                                   |
+| Strong for | Component state, synchronous derivations, template | Async (HTTP, WebSocket), operators (`debounceTime`, `switchMap`, `retry`, `combineLatest`...), request cancellation |
 
-**Règle simple à donner à l'équipe** : si la donnée représente "un état actuel", signal. Si elle représente "une séquence d'événements dans le temps" avec de la composition/annulation à gérer, RxJS reste le bon outil — un appel HTTP en est l'exemple typique.
+**Simple rule to give the team**: if the data represents "a current state", signal. If it represents "a sequence of events over time" with composition/cancellation to handle, RxJS remains the right tool — an HTTP call is the typical example.
 
-### `toSignal()` — exposer un Observable comme un Signal
+### `toSignal()` — exposing an Observable as a Signal
 
-Le cas le plus courant : un service qui expose un appel HTTP en `Observable`, consommé comme un `Signal` côté composant pour éviter le `| async` dans le template.
+The most common case: a service exposing an HTTP call as an `Observable`, consumed as a `Signal` in the component to avoid the `| async` in the template.
 
 ```ts
 import { toSignal } from '@angular/core/rxjs-interop';
 
 private readonly userService = inject(UserService);
 
-// userService.getUser() retourne un Observable<User> (appel HTTP RxJS, inchangé)
+// userService.getUser() returns an Observable<User> (RxJS HTTP call, unchanged)
 readonly user = toSignal(this.userService.getUser(), { initialValue: null });
 ```
 
-- Se comporte comme le `| async` du template, mais utilisable partout (pas seulement en template)
-- Si l'Observable complète, le signal garde la dernière valeur émise
-- Si l'Observable erreur, l'erreur est relancée à la lecture du signal
+- Behaves like the `| async` of the template, but usable everywhere (not only in the template)
+- If the Observable completes, the signal keeps the last emitted value
+- If the Observable errors, the error is thrown again when the signal is read
 
-### `toObservable()` — exposer un Signal comme un Observable
+### `toObservable()` — exposing a Signal as an Observable
 
-Le sens inverse : utile quand on veut piper un signal (ex. une valeur de recherche tapée par l'utilisateur) dans des opérateurs RxJS avant de déclencher un appel HTTP.
+The other way around: useful when you want to pipe a signal (e.g. a search value typed by the user) into RxJS operators before triggering an HTTP call.
 
 ```ts
 import { toObservable, toSignal } from '@angular/core/rxjs-interop';
@@ -322,7 +322,7 @@ import { debounceTime, distinctUntilChanged, switchMap } from 'rxjs';
 
 readonly query = signal('');
 
-// on garde RxJS pour ce que RxJS fait bien : debounce + annulation de requêtes en vol
+// we keep RxJS for what RxJS does well: debounce + cancellation of in-flight requests
 private readonly results$ = toObservable(this.query).pipe(
   debounceTime(300),
   distinctUntilChanged(),
@@ -332,13 +332,13 @@ private readonly results$ = toObservable(this.query).pipe(
 readonly results = toSignal(this.results$, { initialValue: [] });
 ```
 
-C'est l'exemple le plus parlant à montrer à l'équipe : **le signal pilote l'input utilisateur, RxJS gère le debounce/switchMap/annulation, et on ressort un signal côté template.** Aucun des deux modèles n'est sacrifié.
+It's the most telling example to show the team: **the signal drives the user input, RxJS handles the debounce/switchMap/cancellation, and a signal comes out for the template.** Neither model is sacrificed.
 
-⚠️ `toObservable()` doit être déclaré comme **champ de classe** (et non appelé à l'intérieur d'une méthode) car il a besoin d'un contexte d'injection au moment de sa création.
+⚠️ `toObservable()` must be declared as a **class field** (and not called inside a method) because it needs an injection context when it is created.
 
-### `rxResource()` — appels asynchrones pilotés par un signal, avec état loading/error inclus
+### `rxResource()` — asynchronous calls driven by a signal, with loading/error state included
 
-Alternative à `toSignal()` quand on veut aussi le suivi d'état (chargement, erreur, rechargement) sans le coder à la main. `rxResource()` accepte un `Observable` comme source de données, et se redéclenche automatiquement quand les signaux dont dépend la `request` changent.
+An alternative to `toSignal()` when you also want state tracking (loading, error, reload) without coding it by hand. `rxResource()` accepts an `Observable` as data source, and is triggered again automatically when the signals the `request` depends on change.
 
 ```ts
 import { rxResource } from '@angular/core/rxjs-interop';
@@ -350,13 +350,13 @@ readonly userResource = rxResource({
   loader: ({ request: id }) => this.userService.getUser(id), // Observable<User>
 });
 
-// dans le template : userResource.value(), userResource.isLoading(), userResource.error()
+// in the template: userResource.value(), userResource.isLoading(), userResource.error()
 ```
 
-**Exemple concret — avant/après sur un appel HTTP géré à la main :**
+**Concrete example — before/after on an HTTP call handled by hand:**
 
 ```ts
-// 🔴 Avant : subscribe() manuel + variables loading/error gérées à la main
+// 🔴 Before: manual subscribe() + loading/error variables handled by hand
 readonly user = signal<User | null>(null);
 readonly loading = signal(false);
 readonly error = signal<unknown>(null);
@@ -371,7 +371,7 @@ ngOnInit(): void {
 ```
 
 ```ts
-// 🟢 Après : rxResource(), loading/error inclus, re-fetch automatique si userId() change
+// 🟢 After: rxResource(), loading/error included, automatic re-fetch if userId() changes
 readonly userResource = rxResource({
   request: () => this.userId(),
   loader: ({ request: id }) => this.userService.getUser(id),
@@ -379,30 +379,30 @@ readonly userResource = rxResource({
 // userResource.value(), userResource.isLoading(), userResource.error()
 ```
 
-### Doit-on abandonner le pipe `async` ?
+### Should we drop the `async` pipe?
 
-Non, il n'est pas déprécié. Mais la tendance recommandée pour du code neuf est de préférer `toSignal()` dans la plupart des cas :
+No, it isn't deprecated. But the recommended trend for new code is to prefer `toSignal()` in most cases:
 
-- `toSignal()` se comporte comme le pipe `async`, mais la valeur obtenue est utilisable **partout** — pas seulement dans le template (dans un `computed()`, un `effect()`, en `input` d'un enfant...)
-- Une **seule souscription** même si la valeur est lue plusieurs fois dans le template (le pipe `async` utilisé deux fois sur le même flux crée deux souscriptions distinctes, sauf `shareReplay`)
-- Lectures cohérentes avec le reste du graphe de signaux (important avec `OnPush`/zoneless)
+- `toSignal()` behaves like the `async` pipe, but the value obtained is usable **everywhere** — not only in the template (in a `computed()`, an `effect()`, as `input` of a child...)
+- A **single subscription** even if the value is read several times in the template (the `async` pipe used twice on the same stream creates two distinct subscriptions, unless `shareReplay`)
+- Reads consistent with the rest of the signal graph (important with `OnPush`/zoneless)
 
-Le pipe `async` garde toute sa légitimité quand l'`Observable` n'est consommé **que dans le template**, à un seul endroit, sans que la valeur ait besoin de sortir vers le reste de la classe — convertir en signal dans ce cas n'apporte rien.
+The `async` pipe stays fully legitimate when the `Observable` is consumed **only in the template**, in a single place, without the value needing to go to the rest of the class — converting it to a signal brings nothing in that case.
 
-> 🎤 si la valeur ne sert qu'à l'affichage à un endroit précis, `| async` reste légitime. Si elle sert ailleurs dans le composant (calcul dérivé, passage à un enfant, logique dans un effet), `toSignal()`.
+> 🎤 if the value is only used for display in one specific place, `| async` stays legitimate. If it is used elsewhere in the component (derived computation, passed to a child, logic in an effect), `toSignal()`.
 
-### Ce qu'on ne migre **pas**
+### What we **don't** migrate
 
-> 🎤 afin d'éviter la sur-correction après cette session :
+> 🎤 to avoid over-correcting after this session:
 
-- Les appels HTTP restent des `Observable` au niveau service (`HttpClient` retourne du RxJS, on ne change rien ici)
-- Les flux avec opérateurs de composition/temporisation (`debounceTime`, `combineLatest`, `retry`, `race`...) restent en RxJS
-- On ne convertit un `Observable` en `Signal` (via `toSignal()`) **qu'au bord** — c'est-à-dire au tout dernier moment, là où la donnée quitte le monde RxJS pour devenir un état à afficher, jamais au milieu d'une chaîne d'opérateurs
+- HTTP calls stay `Observable`s at the service level (`HttpClient` returns RxJS, nothing changes here)
+- Streams with composition/timing operators (`debounceTime`, `combineLatest`, `retry`, `race`...) stay in RxJS
+- An `Observable` is converted to a `Signal` (with `toSignal()`) **only at the edge** — that is, at the very last moment, where the data leaves the RxJS world to become a state to display, never in the middle of a chain of operators
 
     ```ts
-    // 🔴 Conversion prématurée en plein milieu du pipeline : un Signal
-    // n'est pas "pipeable", il faut repasser par toObservable() pour
-    // continuer la composition — aller-retour inutile
+    // 🔴 Premature conversion in the middle of the pipeline: a Signal
+    // isn't "pipeable", you have to go back through toObservable() to
+    // continue the composition — a useless round trip
     private readonly debounced = toSignal(
       toObservable(this.query).pipe(debounceTime(300)),
     );
@@ -412,7 +412,7 @@ Le pipe `async` garde toute sa légitimité quand l'`Observable` n'est consommé
     );
     readonly results = toSignal(this.results$, { initialValue: [] });
 
-    // 🟢 Un seul point de conversion, à la toute fin de la chaîne
+    // 🟢 A single conversion point, at the very end of the chain
     private readonly results$ = toObservable(this.query).pipe(
       debounceTime(300),
       distinctUntilChanged(),
@@ -421,48 +421,48 @@ Le pipe `async` garde toute sa légitimité quand l'`Observable` n'est consommé
     readonly results = toSignal(this.results$, { initialValue: [] });
     ```
 
-    Ça vaut aussi entre les couches : un service peut composer entièrement en RxJS (`debounceTime`, `retry`, `combineLatest`...) et rester testable indépendamment de tout composant — c'est le composant consommateur, "au bord", qui convertit en signal au moment de l'affichage.
+    It also applies between layers: a service can compose entirely in RxJS (`debounceTime`, `retry`, `combineLatest`...) and stay testable independently of any component — it's the consuming component, "at the edge", that converts to a signal when displaying.
 
 ---
 
-## 7. Le piège n°1 : mutation vs réassignation
+## 7. Pitfall #1: mutation vs reassignment
 
-C'est **le** réflexe à perdre lorsqu'on vient de l'ère Zone.js : avant, muter un tableau ou un objet imbriqué "finissait par marcher" parce que la détection de changement repassait régulièrement sur tout. **Avec les signaux, ce n'est plus vrai** : seul `.set()` / `.update()` notifie les abonnés. Une mutation en place est invisible pour le signal, le template, et tout `computed()`/`effect()` qui en dépend.
+It's **the** reflex to unlearn when coming from the Zone.js era: before, mutating an array or a nested object "ended up working" because change detection regularly went over everything again. **With signals, this is no longer true**: only `.set()` / `.update()` notify the consumers. An in-place mutation is invisible to the signal, the template, and any `computed()`/`effect()` depending on it.
 
 ```ts
-// 🔴 No-op silencieux du point de vue du signal
+// 🔴 Silent no-op from the signal's point of view
 this.address().locality.name = 'newName';
 
-// 🟢 Nouvelle référence de premier niveau
+// 🟢 New top-level reference
 this.address.update((current) => ({
     ...current,
     locality: { ...current.locality, name: 'newName' },
 }));
 ```
 
-Même logique pour les méthodes mutantes des tableaux :
+Same logic for the mutating methods of arrays:
 
 ```ts
-// 🔴 push/splice/pop/shift/unshift/sort/reverse mutent en place
+// 🔴 push/splice/pop/shift/unshift/sort/reverse mutate in place
 this.model().push({ name: null, address: null });
 
-// 🟢 Toujours une nouvelle référence
+// 🟢 Always a new reference
 this.model.update((current) => [...current, { name: null, address: null }]);
 ```
 
-...et pour `Map` / `Set` (piège sournois : `Map.prototype.set` porte le même nom que le `.set()` du signal) :
+...and for `Map` / `Set` (a sneaky pitfall: `Map.prototype.set` has the same name as the `.set()` of the signal):
 
 ```ts
-// 🔴 Ceci est Map.prototype.set, pas celui du signal — mute la même instance
+// 🔴 This is Map.prototype.set, not the signal's — it mutates the same instance
 this.cache().set(key, value);
 
 // 🟢
 this.cache.update((current) => new Map(current).set(key, value));
 ```
 
-> 💡 si une méthode modifie "en place" et ne renvoie pas un objet/tableau/Map/Set flambant neuf, elle mute — on la wrap dans une copie. `map`, `filter`, `slice`, `concat`, le spread : toujours sûrs.
+> 💡 if a method modifies "in place" and doesn't return a brand new object/array/Map/Set, it mutates — wrap it in a copy. `map`, `filter`, `slice`, `concat`, the spread: always safe.
 
-**Exemple concret — le plus percutant à montrer à l'équipe :**
+**Concrete example — the most striking one to show the team:**
 
 ```ts
 @Component({
@@ -471,21 +471,21 @@ this.cache.update((current) => new Map(current).set(key, value));
         @for (contact of contacts(); track contact.id) {
             <p>{{ contact.name }}</p>
         }
-        <button (click)="addBroken()">Ajouter (cassé)</button>
-        <button (click)="addFixed()">Ajouter (correct)</button>
+        <button (click)="addBroken()">Add (broken)</button>
+        <button (click)="addFixed()">Add (correct)</button>
     `,
 })
 export class ContactListComponent {
     readonly contacts = signal<Contact[]>([{ id: 1, name: 'Alice' }]);
 
     addBroken(): void {
-        // 🔴 push() mute le tableau en place : le signal ne détecte rien,
-        // RIEN ne s'affiche à l'écran malgré la donnée bien présente en mémoire
+        // 🔴 push() mutates the array in place: the signal detects nothing,
+        // NOTHING is displayed on screen although the data is in memory
         this.contacts().push({ id: 2, name: 'Bob' });
     }
 
     addFixed(): void {
-        // 🟢 nouvelle référence : le @for se met à jour normalement
+        // 🟢 new reference: the @for updates normally
         this.contacts.update((current) => [...current, { id: 2, name: 'Bob' }]);
     }
 }
@@ -493,11 +493,11 @@ export class ContactListComponent {
 
 ---
 
-## Checklist de fin de session
+## End-of-session checklist
 
-- Je sais choisir entre `input()`, `model()`, `computed()`, `linkedSignal()` et `signal()`
-- Je sais repérer un `effect()` qui devrait être un `computed()`
-- Je sais repérer un `effect()` qui devrait être un `linkedSignal()`
-- Je ne mute plus jamais une valeur de signal en place — toujours `.set()`/`.update()` avec une nouvelle référence
-- Je sais quand utiliser `untracked()` dans un `effect()`
-- Je ne cherche pas à remplacer tout mon RxJS par des signaux — je garde RxJS pour l'async composé (HTTP, debounce, switchMap...) et je ne convertis en signal qu'au bord, avec `toSignal()`/`toObservable()`/`rxResource()`
+- I know how to choose between `input()`, `model()`, `computed()`, `linkedSignal()` and `signal()`
+- I know how to spot an `effect()` that should be a `computed()`
+- I know how to spot an `effect()` that should be a `linkedSignal()`
+- I never mutate a signal value in place anymore — always `.set()`/`.update()` with a new reference
+- I know when to use `untracked()` in an `effect()`
+- I don't try to replace all my RxJS with signals — I keep RxJS for composed async (HTTP, debounce, switchMap...) and I only convert to a signal at the edge, with `toSignal()`/`toObservable()`/`rxResource()`