Initial translation for missing SharedArrayBuffer pages (#5516)

* Initial translation for SAB constructor & planned changes

* nitpicking, let to const (same as en-US)

Co-authored-by: cw118 <[email protected]>

files/fr/web/javascript/reference/global_objects/sharedarraybuffer/planned_changes/index.md

@@ -0,0 +1,58 @@
+---
+title: Changements prévus à propos de la mémoire partagée
+translation_of: Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes
+slug: Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes
+---
+{{JSRef}}
+
+Un travail de standardisation est en cours afin de permettre à nouveau l'utilisation des objets [`SharedArrayBuffer`](/fr/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer), mais des modifications sont nécessaires afin que ceux-ci puissent être utilisés entre des <i lang="en">threads</i> (par défaut `postMessage()` lève une exception pour les objets `SharedArrayBuffer`). Ces modifications améliorent l'isolation entre les sites et aident à réduire l'impact des attaques utilisant des minuteurs à haute résolution, comme ceux pouvant être créés avec de la mémoire partagée.
+
+> **Note :** À partir de Firefox 79, les fonctionnalités décrites dans ce document sont activées par défaut.
+
+## En-têtes HTTP
+
+Pour commencer, les documents doivent utiliser [un contexte sécurisé](/fr/docs/Web/Security/Secure_Contexts).
+
+Pour les documents de plus haut niveau, deux en-têtes doivent être présents&nbsp;:
+
+- [`Cross-Origin-Opener-Policy`](/fr/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) avec la valeur `same-origin` (qui protège l'origine des acteurs malveillants)
+- [`Cross-Origin-Embedder-Policy`](/fr/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy) avec la valeur `require-corp` (qui protège les victimes de votre origine)
+
+Avec ces deux en-têtes ainsi paramétrés, `postMessage()` ne déclenchera plus d'exceptions pour les objets `SharedArrayBuffer` et la mémoire partagée entre les <i lang="en">threads</i> sera donc disponible.
+
+Les documents imbriqués et les <i lang="en">workers</i> dédiés devront également utiliser l'en-tête [`Cross-Origin-Embedder-Policy`](/fr/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy) avec la même valeur. Aucun changement supplémentaire n'est nécessaire pour les documents imbriqués de la même origine et pour les sous-ressources. Les documents imbriqués et les sous-ressources d'un même site mais d'une origine différente devront fixer l'en-tête [`Cross-Origin-Resource-Policy`](/fr/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy) avec la valeur `same-site`. Dans le cas d'une origine et d'un site différent, ce même en-tête devra avoir la valeur `cross-origin`. On notera qu'utiliser toute autre valeur que `same-origin` pour [`Cross-Origin-Resource-Policy`](/fr/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy) ouvre la porte à des attaques potentielles, telles que [Spectre](https://fr.wikipedia.org/wiki/Spectre_(vuln%C3%A9rabilit%C3%A9)).
+
+On notera que l'en-tête [`Cross-Origin-Opener-Policy`](/fr/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) limite la capacité à retenir une référence vers une popup. L'accès direct entre deux fenêtres de plus haut niveau fonctionnera uniquement si elles partagent la même origine et que les deux en-têtes ont les mêmes valeurs.
+
+## Modifications de l'API JavaScript
+
+En raison de ces nouvelles contraintes, quelques modifications sont apportées à l'API&nbsp;:
+
+- L'objet `Atomics` est toujours disponible.
+- En principe, les objets `SharedArrayBuffer` sont toujours disponibles. En pratique, il est nécessaire que les deux en-têtes mentionnés soient définis, sinon le constructeur rattaché à l'objet global est masqué. On peut espérer que cette restriction soit levée à l'avenir. [`WebAssembly.Memory`](/fr/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/Memory) peut toujours être utilisé afin d'obtenir une instance.
+- À moins que les deux en-têtes mentionnés avant soient définis, les différentes API `postMessage()` lèveront une exception pour les objets `SharedArrayBuffer`. Si les en-têtes sont bien paramétrés, `postMessage()` fonctionnera sur les objets `Window` et les <i lang="en">workers</i> dédiés et permettra le partage de la mémoire.
+- Afin d'éviter d'avoir à vérifier si `postMessage()` provoque des erreurs, [`self.crossOriginIsolated`](/fr/docs/Web/API/crossOriginIsolated) est en cours de standardisation&nbsp;: il s'agit d'un accesseur renvoyant un booléen indiquant si les en-têtes sont bien définis et qui est disponible dans les contextes de la fenêtre et des <i lang="en">workers</i>.
+
+## Mémoire partagée en WebAssembly
+
+[La proposition sur les <i lang="en">threads</i> WebAssembly](https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md) permet à des objets [`WebAssembly.Memory`](/fr/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/Memory) d'être créés avec un nouveau marqueur [`shared`](https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md#javascript-api-changes) pour le constructeur. Lorsque ce marqueur vaut `true`, l'objet `Memory` construit peut être partagé entre les <i lang="en">workers</i> avec `postMessage()`, comme `SharedArrayBuffer`, et le [`buffer`](/fr/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/Memory/buffer) de l'objet `Memory` correspondant est un objet `SharedArrayBuffer`. Aussi, les conditions exposées ci-avant pour le partage d'un `SharedArrayBuffer` entre les <i lang="en">workers</i> s'appliquent également au partage d'un objet `WebAssembly.Memory`.
+
+Cette proposition définit également un nouvel ensemble d'instructions [atomiques](https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md#atomic-memory-accesses). À l'instar de `SharedArrayBuffer` et de ses méthodes qui sont autorisées sans condition (seul le partage entre <i lang="en">threads</i> est conditionné aux en-têtes), les instructions atomiques WebAssembly sont aussi autorisées sans condition.
+
+## Voir aussi
+
+- [Explication des en-têtes `Cross-Origin-Opener-Policy` et `Cross-Origin-Embedder-Policy` (en anglais)](https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit)
+- `Cross-Origin-Opener-Policy`&nbsp;:
+  - [Issue n°3740 sur le dépôt `whatwg/html`](https://github.com/whatwg/html/issues/3740),
+  - [Brouillon de spécification](https://gist.github.com/annevk/6f2dd8c79c77123f39797f6bdac43f3e).
+- `Cross-Origin-Embedder-Policy`&nbsp;:&nbsp;:
+  - [Issue n°4175 sur le dépôt `whatwg/html`](https://github.com/whatwg/html/issues/4175),
+  - [Brouillon de spécification](https://mikewest.github.io/corpp/).
+- `Cross-Origin-Resource-Policy`&nbsp;:
+  - [Standardisée avec l'API Fetch](https://fetch.spec.whatwg.org/#cross-origin-resource-policy-header)
+  - La nouvelle valeur `cross-origin` fait partie des travaux sur `Cross-Origin-Embedder-Policy`.
+- Modifications apportées à `postMessage()` et [`self.crossOriginIsolated`](/fr/docs/Web/API/crossOriginIsolated)
+  - [Issue n°4732 sur le dépôt `whatwg/html`](https://github.com/whatwg/html/issues/4732),
+  - [Issue n°4872 sur le dépôt `whatwg/html`](https://github.com/whatwg/html/issues/4872),
+  - [Brouillon de spécification](https://github.com/whatwg/html/pull/4734).
+- [Mises à jour quant à `SharedArrayBuffer` pour Chrome pour Android 88 et Chrome pour ordinateur 92 (en anglais)](https://developer.chrome.com/blog/enabling-shared-array-buffer/)

files/fr/web/javascript/reference/global_objects/sharedarraybuffer/sharedarraybuffer/index.md

@@ -0,0 +1,59 @@
+---
+title: Constructeur SharedArrayBuffer()
+slug: Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/SharedArrayBuffer
+translation_of: Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/SharedArrayBuffer
+browser-compat: javascript.builtins.SharedArrayBuffer.SharedArrayBuffer
+---
+{{JSRef}}
+
+> **Note :** `SharedArrayBuffer` a été désactivé par défaut pour l'ensemble des navigateurs principaux le 5 janvier 2018 en réponse à la faille [Spectre](https://meltdownattack.com/). Chrome [a réactivé cette fonctionnalité à partir de la version 67](https://bugs.chromium.org/p/chromium/issues/detail?id=821270) sur les plateformes où la fonctionnalité d'isolation des sites est activée et protège des vulnérabilités analogues à Spectre.
+
+Le **constructeur `SharedArrayBuffer()`** permet de créer un objet [`SharedArrayBuffer`](/fr/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer) qui représente un tampon de mémoire binaire brute de taille fixe, similaire à un objet [`ArrayBuffer`](/fr/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer).
+
+{{EmbedInteractiveExample("pages/js/sharedarraybuffer-constructor.html","shorter")}}
+
+## Syntaxe
+
+```js
+new SharedArrayBuffer()
+new SharedArrayBuffer(longueur)
+```
+
+### Paramètres
+
+- `longueur` {{optional_inline}}
+  - : La longueur, exprimée en octets, du tampon de mémoire à créer.
+
+### Valeur de retour
+
+Un nouvel objet `SharedArrayBuffer` de la taille indiquée et dont les éléments du tableau sont initialisés à `0`.
+
+## Exemples
+
+### L'opérateur `new` est obligatoire
+
+Le constructeur `SharedArrayBuffer()` doit être appelé avec l'opérateur [`new`](/fr/docs/Web/JavaScript/Reference/Operators/new). Appeler le constructeur `SharedArrayBuffer()` comme une fonction, c'est-à-dire sans utiliser `new`, déclenchera une exception [`TypeError`](/fr/docs/Web/JavaScript/Reference/Global_Objects/TypeError).
+
+```js example-bad
+const sab = SharedArrayBuffer(1024);
+// TypeError: calling a builtin SharedArrayBuffer constructor
+// without new is forbidden
+```
+
+```js example-good
+const sab = new SharedArrayBuffer(1024);
+```
+
+## Spécifications
+
+{{Specifications}}
+
+## Compatibilité des navigateurs
+
+{{Compat}}
+
+## Voir aussi
+
+- [`Atomics`](/fr/docs/Web/JavaScript/Reference/Global_Objects/Atomics)
+- [`ArrayBuffer`](/fr/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer)
+- [Les tableaux typés en JavaScript](/fr/docs/Web/JavaScript/Typed_arrays)