/* Page prose (fr) */
"JobInThreeSteps" = "# Un travail en trois étapes dépendantes\n\nRetour à l'**imprimerie**. Pour produire un livret, trois choses doivent se passer *dans l'ordre*, chacune ayant besoin de la précédente :\n\n1. **Charger un design** (un modèle à partir duquel imprimer).\n2. **Rendre une épreuve** à partir de ce design (en combien de pages il se transforme).\n3. **Relier le livret** à partir de ce nombre de pages.\n\nVoici les trois blocs de construction asynchrones. Chacun simule une attente réelle (une lecture disque, un rendu, un passage à la reliure) avec `asyncAfter`, et rend compte via un completion handler qui porte un `Result`. Comme chaque étape a besoin du résultat précédent, chaque appel s'imbrique dans le dernier handler. On met tout ça dans une petite classe pour qu'un détail du monde réel s'invite : les closures capturent `self`, donc on doit penser aux cycles de rétention.";
"JobInThreeSteps-2" = "**Observe l'exécution:** après environ une seconde et demie, tu verras `✅ Ready:\nBooklet(12 pages)`. Ça marche. Mais regarde *ce qu'il a fallu* pour faire fonctionner trois étapes ordonnées, et chaque endroit où ça aurait pu mal tourner à la place.\n\n* callout(Essaie): Supprime l'enveloppe `DispatchQueue.main.async { ... }` et appelle\n`completion(.success(booklet))` directement. La sortie a l'air identique ici, ce qui est exactement la raison pour laquelle un saut vers le thread principal oublié part si facilement en production.\n\n[Précédent](@previous)  |  page 3 sur 6  |  [Suivant: Où se cachent les bugs](@next)";
