/* Page prose (fr) */
"WrappingUp" = "# Récapitulatif\n\nUn fait gouverne tout ce chapitre: ton app a un seul **thread principal**, et l'expérience de l'utilisateur vit ou meurt selon que tu le gardes libre. La concurrence existe pour structurer le travail de sorte que les tâches progressent de façon indépendante au lieu de faire la queue derrière ce thread unique. Garde à l'esprit les distinctions ci-dessous et le reste du livre suit naturellement.\n\n* Ton app a un seul **thread principal**, et toute l'UI s'y exécute; bloque-le et l'app gèle.\n* La **concurrence** structure le travail pour que les tâches progressent de façon indépendante; le **parallélisme** les exécute au même instant sur plusieurs cœurs.\n* La concurrence aide même sur un seul cœur, parce que la plupart du travail lent est de l'*attente*.\n* Le premier but est la **réactivité** (libérer le thread principal); la vitesse est un bonus secondaire, apporté par le parallélisme.\n* **Piège:** le travail lourd et non instantané n'a pas sa place sur le thread principal, et les mises à jour de l'UI doivent toujours y revenir.\n* **Piège:** les tâches concurrentes terminent dans l'ordre où elles terminent. Ne compte jamais sur l'ordre d'achèvement, à moins de l'imposer délibérément.\n\n---\n\n## La suite\n\nLe chapitre suivant, [Fondamentaux de GCD](GCD%20Fundamentals.playgroundchapter/Overview), présente Grand Central Dispatch: les dispatch queues, `sync` vs. `async`, et la qualité de service, le véritable outil pour sortir le travail du thread principal.\n\n[Précédent](@previous)  |  page 5 sur 5";
