/* Page prose (fr) */
"DistributedFourPieces" = "# Les quatre pièces\n\nQuatre choses travaillent ensemble. Il vaut la peine de nommer chacune.\n\n---\n\n## 1. Le `distributed actor` lui-même\n\nLe type. Comme un actor local, il possède un état isolé. Contrairement à un actor\nlocal, il *doit* être associé à un actor system, et il gagne une identité qui peut\nêtre remise à d'autres processus (on y reviendra dans un instant).\n\n---\n\n## 2. Les méthodes `distributed`\n\nLe sous-ensemble de méthodes que tu exposes à travers le réseau. Chacune est un\npotentiel **message distant**. Tout ce qui n'est pas marqué `distributed` reste\nprivé à quiconque détient une référence locale.\n\n---\n\n## 3. L'`ActorSystem`: le transport et le runtime\n\nC'est la pièce sans équivalent chez l'actor local, et c'est le cœur de tout le\nmodèle. Un **actor system** est le runtime qui localise réellement les actors et\ntransporte les messages entre eux: il attribue des identités, sérialise les\narguments, envoie des octets sur une connexion, et délivre l'appel de l'autre côté.\n\nTu n'en écris généralement pas un toi-même. Tu utilises une implémentation\nexistante. La plus en vue en 2026 est **`ClusterSystem`**, du paquet open source\nDistributed Cluster d'Apple, qui relie les processus Swift côté serveur en un\ncluster. La chaîne d'outils fournit aussi un `LocalTestingDistributedActorSystem`\npour exercer du code distribué dans les tests sans vrai réseau. Dans tous les cas,\nl'actor system est une *dépendance que tu apportes*, ce qui est exactement pourquoi\ncela ne s'exécute pas dans Swift Playground.\n\nTu remets le system à un actor quand tu le crées:\n\n```swift\n// `system` is an already-running ClusterSystem.\nlet ledger = Ledger(actorSystem: system)\n```\n\nCe paramètre `actorSystem:` n'en est pas un que tu écris à la main: le compilateur\nsynthétise un initialiseur qui le prend et le câble. Le system est désormais\nresponsable de cet actor: il lui a donné une identité et il sait comment router les\nmessages vers lui.\n\n---\n\n## 4. L'`ID`\n\nQuand l'actor system adopte un actor, il l'estampille d'un **`ID`**, un nom unique\net sérialisable pour *cette instance d'actor précise*, tiré du propre type\n`ActorID` du system. L'ID est ce qui rend un actor localisable depuis un autre\nprocessus.\n\nSi l'Agence A connaît l'ID d'un grand livre qui vit sur le serveur de l'Agence B,\nelle peut **résoudre** une référence vers lui et commencer à appeler des méthodes,\nsans jamais détenir l'objet réel:\n\n```swift\n// Branch A resolves a remote ledger it never constructed.\nlet remoteLedger = try Ledger.resolve(id: knownID, using: system)\ntry await remoteLedger.deposit(50)\n```\n\n`resolve(id:using:)` ne récupère pas l'état de l'actor et ne le copie pas. Il\nrenvoie une **référence distante**, un substitut local qui transfère chaque appel à\ntravers le réseau vers l'actor réel. L'état reste en place sur l'Agence B; seuls les\n*messages* voyagent.\n\n[Précédent](@previous)  |  page 4 sur 9  |  [Suivant: Async et throws](@next)";
