aboutsummaryrefslogtreecommitdiff
path: root/files/fr/web/progressive_web_apps
diff options
context:
space:
mode:
Diffstat (limited to 'files/fr/web/progressive_web_apps')
-rw-r--r--files/fr/web/progressive_web_apps/add_to_home_screen/index.md2
-rw-r--r--files/fr/web/progressive_web_apps/app_structure/index.md8
-rw-r--r--files/fr/web/progressive_web_apps/introduction/index.md6
-rw-r--r--files/fr/web/progressive_web_apps/loading/index.md4
-rw-r--r--files/fr/web/progressive_web_apps/offline_service_workers/index.md18
-rw-r--r--files/fr/web/progressive_web_apps/re-engageable_notifications_push/index.md6
6 files changed, 22 insertions, 22 deletions
diff --git a/files/fr/web/progressive_web_apps/add_to_home_screen/index.md b/files/fr/web/progressive_web_apps/add_to_home_screen/index.md
index 59875ebc2c..35c6b10a88 100644
--- a/files/fr/web/progressive_web_apps/add_to_home_screen/index.md
+++ b/files/fr/web/progressive_web_apps/add_to_home_screen/index.md
@@ -191,7 +191,7 @@ Ici il faut:
- Appeler `Event.preventDefault()` pour empêcher Chrome 67 et les versions antérieures d'appeler automatiquement l'invite d'installation (ce comportement a été modifié dans Chrome 68).
- Stocker l'objet événement dans la variable `deferredPrompt` afin qu'il puisse être utilisé ultérieurement pour effectuer l'installation réelle.
-- Configurer le bouton  `display: block` afin qu'il apparaisse dans l'interface utilisateur sur laquelle l'utilisateur peut cliquer.
+- Configurer le bouton `display: block` afin qu'il apparaisse dans l'interface utilisateur sur laquelle l'utilisateur peut cliquer.
- Définir un gestionnaire de `click` pour le bouton.
Le gestionnaire de clics contient les étapes suivantes:
diff --git a/files/fr/web/progressive_web_apps/app_structure/index.md b/files/fr/web/progressive_web_apps/app_structure/index.md
index 6b3841be1a..56fb12cba4 100644
--- a/files/fr/web/progressive_web_apps/app_structure/index.md
+++ b/files/fr/web/progressive_web_apps/app_structure/index.md
@@ -28,7 +28,7 @@ Nous pouvons contrôler ce qui est demandé au serveur et ce qui est récupéré
### Pourquoi dois-je l'utiliser ?
-Cette architecture permet à un site web de bénéficier de la plupart des fonctionnalités PWA - elle met en cache l'app shell et gère le contenu dynamique d'une manière qui améliore grandement les performances. En plus de la structure de base, vous pouvez ajouter d'autres fonctionnalités telles que [l'ajouter à l'écran d'accueil](/fr/docs/Web/Apps/Progressive/Add_to_home_screen) ou [l'envoi de notifications](/fr/docs/Web/API/Push_API), sachant que l'application fonctionnera toujours correctement si elles ne sont pas prises en charge par le navigateur de l'utilisateur - c'est la beauté de l'amélioration continue.
+Cette architecture permet à un site web de bénéficier de la plupart des fonctionnalités PWA - elle met en cache l'app shell et gère le contenu dynamique d'une manière qui améliore grandement les performances. En plus de la structure de base, vous pouvez ajouter d'autres fonctionnalités telles que [l'ajouter à l'écran d'accueil](/fr/docs/Web/Apps/Progressive/Add_to_home_screen) ou [l'envoi de notifications](/fr/docs/Web/API/Push_API), sachant que l'application fonctionnera toujours correctement si elles ne sont pas prises en charge par le navigateur de l'utilisateur - c'est la beauté de l'amélioration continue.
Le site web se comporte comme une application native, offrant une interaction instantannée et de solides performances tout en conservant les avantages du web.
@@ -38,7 +38,7 @@ Il est important de se rappeler les avantages des PWA et de les garder à l'espr
- Accessible par un lien: Même s'il se comporte comme une application native, il reste un site web - vous pouvez cliquer sur les liens d'une page et envoyer une URL à quelqu'un si vous voulez le partager.
- Progressive: Commencer avec un "bon vieux site web basic” et ajouter progressivement de nouvelles fonctionnalités tout en se rappelant de détecter si elles sont disponibles dans le navigateur et de gérer proprement toute erreur qui pourrait survenir si la prise en charge n'est pas disponible. Par exemple, un mode déconnecté possible grâce aux service workers n'est qu'une caractéristique bonus qui améliore l'expérience sur le site web, mais ce dernier reste totalement fonctionnel sans elle.
-- Adaptatif: La conception web adaptative s'applique également aux applications web progressives, attendu que les deux sont principalement destinés aux appareils mobiles. Il y a tellements d'appareils différents en plus des navigateurs - il est important de préparer votre site web à fonctionner sur différentes tailles d'écran, supports d'affichage ou densité de pixels, en utilisant des technologies telles que  [les tags meta viewport](/fr/docs/Mozilla/Mobile/Viewport_meta_tag), [les reqêtes media CSS](/fr/docs/Web/CSS/Media_Queries/Using_media_queries), [les Flexbox](/fr/docs/Web/CSS/CSS_Flexible_Box_Layout) et les [Grid CSS](/fr/docs/Web/CSS/CSS_Grid_Layout).
+- Adaptatif: La conception web adaptative s'applique également aux applications web progressives, attendu que les deux sont principalement destinés aux appareils mobiles. Il y a tellements d'appareils différents en plus des navigateurs - il est important de préparer votre site web à fonctionner sur différentes tailles d'écran, supports d'affichage ou densité de pixels, en utilisant des technologies telles que [les tags meta viewport](/fr/docs/Mozilla/Mobile/Viewport_meta_tag), [les reqêtes media CSS](/fr/docs/Web/CSS/Media_Queries/Using_media_queries), [les Flexbox](/fr/docs/Web/CSS/CSS_Flexible_Box_Layout) et les [Grid CSS](/fr/docs/Web/CSS/CSS_Grid_Layout).
## Approche différente : les streams
@@ -98,7 +98,7 @@ Du point de vue HTML, l'app shell est tout ce qui est à l'extérieur de la sect
</html>
```
-La section {{htmlelement("head")}} contient certaines informations de base telles que le titre, la description et des liens vers les CSS, le manifeste web, le fichier JS contenant les jeux et  app.js — c'est là où notre application JavaScript est initialisée. Le {{htmlelement("body")}} est divisé en {{htmlelement("header")}} (contenant les images liées), {{htmlelement("main")}} la page (avec le titre, la description et un emplacement pour le contenu) et  {{htmlelement("footer")}} (le copyright et les liens).
+La section {{htmlelement("head")}} contient certaines informations de base telles que le titre, la description et des liens vers les CSS, le manifeste web, le fichier JS contenant les jeux et app.js — c'est là où notre application JavaScript est initialisée. Le {{htmlelement("body")}} est divisé en {{htmlelement("header")}} (contenant les images liées), {{htmlelement("main")}} la page (avec le titre, la description et un emplacement pour le contenu) et {{htmlelement("footer")}} (le copyright et les liens).
Le seul travail de l'application est de lister toutes les entrées A-Frame de la compétition js13kGames 2017. Comme vous pouvez le voir, c'est un site web en une page tout ce qu'il y a de plus ordinaire - le but est d'avoir quelque chose de simple afin que nous puissions nous concentrer sur l'implémentation des réelles fonctionnalités PWA.
@@ -158,7 +158,7 @@ button.addEventListener('click', function(e) {
});
```
-Le dernier bloc crée des notifications qui affichent  un élément choisi au hasard dans la liste des jeux:
+Le dernier bloc crée des notifications qui affichent un élément choisi au hasard dans la liste des jeux:
```js
function randomNotification() {
diff --git a/files/fr/web/progressive_web_apps/introduction/index.md b/files/fr/web/progressive_web_apps/introduction/index.md
index 14d5beeaf6..156468624e 100644
--- a/files/fr/web/progressive_web_apps/introduction/index.md
+++ b/files/fr/web/progressive_web_apps/introduction/index.md
@@ -37,7 +37,7 @@ Il y a des principes clés qu'une application web devrait suivre afin d'être id
- [Discoverable](/fr/docs/Web/Progressive_web_apps/Advantages#Discoverable), afin que le contenu soit trouvé à l'aide de moteurs de recherche.
- [Installable](/fr/docs/Web/Progressive_web_apps/Advantages#Installable), afin d'être disponible sur l'écran d'accueil de l'appareil.
-- [Linkable](/fr/docs/Web/Progressive_web_apps/Advantages#Linkable), afin que vous puissiez la partager simplement en envoyant un lien.
+- [Linkable](/fr/docs/Web/Progressive_web_apps/Advantages#Linkable), afin que vous puissiez la partager simplement en envoyant un lien.
- [Network independent](/fr/docs/Web/Progressive_web_apps/Advantages#Network_independent), afin qu'elle fonctionne hors-ligne ou avec une mauvaise connexion internet.
- [Progressive](/fr/docs/Web/Progressive_web_apps/Advantages#Progressive), afin qu'elle soit utilisable sur les plus vieux navigateurs, mais complétement fonctionnelle sur les derniers.
- [Re-engageable](/fr/docs/Web/Progressive_web_apps/Advantages#Re-engageable), afin qu'elle soit capable d'envoyer des notifications lorsque du nouveau contenu est disponible.
@@ -49,7 +49,7 @@ Il y a des principes clés qu'une application web devrait suivre afin d'être id
Absolument! Avec relativement peu d'effort pour implémenter l'essentiel des fonctionnalités requises par une PWA, les bénéfices sont énormes. Par exemple:
- Une diminution du temps de chargement après avoir installé l'application, et ceci grâce au système de cache des [Service Workers](/fr/docs/Web/API/Service_Worker_API), s'accompagnant aussi par une économie précieuse de bande passante et de temps.
-- La possibilité de seulement mettre à jour le contenu qui a changé lorsque qu'une mise à jour d'application est disponible. A contrario, avec une  application native, même la plus petite modification peut obliger l'utilisateur à télécharger entièrement l'application à nouveau.
+- La possibilité de seulement mettre à jour le contenu qui a changé lorsque qu'une mise à jour d'application est disponible. A contrario, avec une application native, même la plus petite modification peut obliger l'utilisateur à télécharger entièrement l'application à nouveau.
- Une sensation d'utilisation et une apparence plus proche d'une application native— icônes d'applications sur l'écran d'accueil, des applications qui s'ouvrent en plein écran, etc.
- Les utilisateurs sont plus engagés grâce à un système de notifications et de messages _push_, créant des utlisateurs plus impliqués apportant des taux de conversion plus élevés.
@@ -63,7 +63,7 @@ Vous pouvez consulter la liste sur [pwa.rocks](https://pwa.rocks/) pour plus d'e
Vous pouvez même générer des PWA en ligne à l'aide du site web [PWABuilder](https://www.pwabuilder.com/).
-Pour les informations spécifiques aux _service workers_ et aux notifications _push_, consultez le [Service Worker Cookbook](https://serviceworke.rs/), une collection d'exemples utilisant des _service workers_.
+Pour les informations spécifiques aux _service workers_ et aux notifications _push_, consultez le [Service Worker Cookbook](https://serviceworke.rs/), une collection d'exemples utilisant des _service workers_.
Ça vaut le coup d'essayer l'approche PWA, afin que vous puissiez constater par vous-même si ça convient à votre application.
diff --git a/files/fr/web/progressive_web_apps/loading/index.md b/files/fr/web/progressive_web_apps/loading/index.md
index 91b2a90e4b..dc07a9dbd4 100644
--- a/files/fr/web/progressive_web_apps/loading/index.md
+++ b/files/fr/web/progressive_web_apps/loading/index.md
@@ -12,7 +12,7 @@ Dans les articles précédents, nous avons abordé les APIs qui nous aident à f
## Première visualisation signifiante
-Il est important de fournir quelque chose qui ait du sens pour l'utilisateur dès que possible  — plus il attend que la page se charge, plus il y a de chances qu'il s'en aille plutôt que d'attendre que tout soit fini. Nous devrions être capable de lui montrer au moins une vue basique de la page qu'il veut voir avec des emplacements où du contenu supplémentaire sera chargé à un moment donné.
+Il est important de fournir quelque chose qui ait du sens pour l'utilisateur dès que possible — plus il attend que la page se charge, plus il y a de chances qu'il s'en aille plutôt que d'attendre que tout soit fini. Nous devrions être capable de lui montrer au moins une vue basique de la page qu'il veut voir avec des emplacements où du contenu supplémentaire sera chargé à un moment donné.
Ceci peut être réalisé grâce au chargement progressif — également appelé [Lazy loading](https://en.wikipedia.org/wiki/Lazy_loading). Tout ceci consiste en retardant autant que possible le plus de ressources que possible (HTML, CSS, JavaScript), et ne charger immédiatement que celles qui sont réellement nécessaire pour la toute première expérience.
@@ -144,7 +144,7 @@ Rappelez-vous qu'il y a de nombreuses façons d'optimiser les temps de chargemen
Nous ne le ferons pas car l'application elle-même dépend de JavaScript — sans lui, la liste des jeux ne sera même pas chargée et le code du Service Worker ne s'exécutera pas.
-Nous pourrions réécrire le processus de chargement  pour charger non seulement les images mais aussi les éléments complets composés des descriptions complètes et des liens. Cela fonctionnerait comme un défilement infini — charger les éléments de la liste seulement quand l'utilisateur fait défiler la page vers le bas. De cette façon, la structure HTML initiale sera minimale, le temps de chargement encore plus court et nous aurions des bénéfices de performance encore meilleurs.
+Nous pourrions réécrire le processus de chargement pour charger non seulement les images mais aussi les éléments complets composés des descriptions complètes et des liens. Cela fonctionnerait comme un défilement infini — charger les éléments de la liste seulement quand l'utilisateur fait défiler la page vers le bas. De cette façon, la structure HTML initiale sera minimale, le temps de chargement encore plus court et nous aurions des bénéfices de performance encore meilleurs.
## Conclusion
diff --git a/files/fr/web/progressive_web_apps/offline_service_workers/index.md b/files/fr/web/progressive_web_apps/offline_service_workers/index.md
index e4a376c6cb..dae15b064c 100644
--- a/files/fr/web/progressive_web_apps/offline_service_workers/index.md
+++ b/files/fr/web/progressive_web_apps/offline_service_workers/index.md
@@ -16,7 +16,7 @@ Maintenant que nous avons vu à quoi ressemble l'architecture de js13kPWA et que
## Les Service workers expliqués
-Les Service Workers sont des proxy virtuels entre le navigateur et le réseau. Ils permettent enfin de régler les problèmes auxquels les développeurs front-end se débattent depuis des années — et plus particulièrement comment mettre proprement en cache les composants d'un site web et les rendre disponibles quand l'appareil de l'utilisateur est hors connexion.
+Les Service Workers sont des proxy virtuels entre le navigateur et le réseau. Ils permettent enfin de régler les problèmes auxquels les développeurs front-end se débattent depuis des années — et plus particulièrement comment mettre proprement en cache les composants d'un site web et les rendre disponibles quand l'appareil de l'utilisateur est hors connexion.
Ils s'exécutent dans un processus séparé de celui du code JavaScript principal de notre page et n'ont aucun accès à la structure DOM. Cela introduit une approche différente de celle de la programmation web traditionnelle — l'API est non bloquante et peut émettre et recevoir de la communication entre différents contextes. Vous pouvez donner à un Service Worker quelque chose à faire et recevoir le résultat quand il est prêt en utilisant une approche basée sur les [Promise](/fr/docs/Web/JavaScript/Reference/Global_Objects/Promise).
@@ -42,7 +42,7 @@ Assez de théorie — voyons un peu de code source !
Commençons par regarder le code qui enregistre un nouveau Service Worker, dans le fichier app.js:
-**NOTE** : Nous utilisons la syntaxe des **fonctions flèchées** pour l'implémentation du Service Worker
+**NOTE** : Nous utilisons la syntaxe des **fonctions flèchées** pour l'implémentation du Service Worker
```js
if('serviceWorker' in navigator) {
@@ -50,11 +50,11 @@ if('serviceWorker' in navigator) {
};
```
-Si l'API service worker est prise en charge dans le navigateur, il est enregistré pour le site en utilisant la méthode {{domxref("ServiceWorkerContainer.register()")}}. Son contenu se trouve dans le fichier sw\.js et peut être exécuté une fois que l'enregistrement a réussi. C'est la seule partie de code du Service Worker qui se trouve dans le fichier app.js. Tout le reste spécifique au Service Worker se trouve dans le fichier sw\.js .
+Si l'API service worker est prise en charge dans le navigateur, il est enregistré pour le site en utilisant la méthode {{domxref("ServiceWorkerContainer.register()")}}. Son contenu se trouve dans le fichier sw\.js et peut être exécuté une fois que l'enregistrement a réussi. C'est la seule partie de code du Service Worker qui se trouve dans le fichier app.js. Tout le reste spécifique au Service Worker se trouve dans le fichier sw\.js .
### Le cycle de vie d'un Service Worker
-Une fois que l'enregistrement a été réalisé, le fichier sw\.js est automatiquement téléchargé, puis installé, et finalement activé.
+Une fois que l'enregistrement a été réalisé, le fichier sw\.js est automatiquement téléchargé, puis installé, et finalement activé.
#### Installation
@@ -124,7 +124,7 @@ Le service worker ne s'installe pas tant que le code de `waitUntil` n'est pas ex
`caches` est un objet {{domxref("CacheStorage")}} spécial accessible dans la portée du Service Worker et qui permet d'enregistrer les données — l'enregistrement dans le [web storage](/fr/docs/Web/API/Web_Storage_API) ne fonctionnera pas, parce que le web storage fonctionne de façon synchrone. Avec les Service Workers, nous utilisons l'API Cache à la place. Ici, nous ouvrons un cache sous un nom donné, puis nous lui ajoutons tous les fichiers que notre app utilise, de telle sorte qu'ils soient disponibles la prochaine fois qu'il sera chargé (identifié par l'URL de la requête).
-Vous avez remarqué que nous n'avons pas mis en cache le fichier `game.js`. Ce fichier contient les données utilisées pour afficher les jeux. En réalité, ces données seront appelées depuis le endpoint d'une API ou depuis une base de données.Mettre en cache ces données signifierait qu'elles ne seraient mises à jour que périodiquement quand il y' a une connexion au réseau. Nous n'irons pas plus loin sur ce sujet, pour en savoir plus : [Web_Periodic_Background_Synchronization_API](/fr/docs/Web/API/Web_Periodic_Background_Synchronization_API) .
+Vous avez remarqué que nous n'avons pas mis en cache le fichier `game.js`. Ce fichier contient les données utilisées pour afficher les jeux. En réalité, ces données seront appelées depuis le endpoint d'une API ou depuis une base de données.Mettre en cache ces données signifierait qu'elles ne seraient mises à jour que périodiquement quand il y' a une connexion au réseau. Nous n'irons pas plus loin sur ce sujet, pour en savoir plus&nbsp;: [Web_Periodic_Background_Synchronization_API](/fr/docs/Web/API/Web_Periodic_Background_Synchronization_API) .
#### Activation
@@ -132,7 +132,7 @@ Il y a également un événement `activate` qui est utilisé de la même façon
### Répondre aux requêtes
-Nous avons également un événement `fetch` à notre disposition et qui est déclenché à chaque fois qu'une requête HTTP est émise par notre app. Ceci est très  utile car ça nous permet d'intercepter des requêtes et d'y répondre de façon personnalisée. Voic un exemple d'utilisation simpliste:
+Nous avons également un événement `fetch` à notre disposition et qui est déclenché à chaque fois qu'une requête HTTP est émise par notre app. Ceci est très utile car ça nous permet d'intercepter des requêtes et d'y répondre de façon personnalisée. Voic un exemple d'utilisation simpliste:
```js
self.addEventListener('fetch', (e) => {
@@ -165,7 +165,7 @@ Ici, nous répondons à l'événement `fetch` grâce à une fonction qui essaie
La méthode {{domxref("FetchEvent.respondWith")}} prend le contrôle — c'est la partie qui agit en tant que serveur proxy entre l'application et le réseau. Ceci nous permet de répondre à chacune des requêtes avec la réponse que nous voulons: celle préparée par le Service Worker, celle récupérée dans le cache, modifiée si nécessaire.
-ça y est ! Notre application met en cache ses ressources lors de l'installation et les sert en les récupérant dans le cache, si bien qu'elle fonctionne même si l'utilisateur n'a pas de connexion. Elle met également en cache les contenus dès qu'il y en a de nouveaux d'ajoutés.
+ça y est ! Notre application met en cache ses ressources lors de l'installation et les sert en les récupérant dans le cache, si bien qu'elle fonctionne même si l'utilisateur n'a pas de connexion. Elle met également en cache les contenus dès qu'il y en a de nouveaux d'ajoutés.
## Mises à jour
@@ -219,9 +219,9 @@ Servir des fichiers depuis le cache n'est pas la seule fonctionnalité que le Se
## Résumé
-Dans cet article, nous avons rapidement abordé la façon de faire fonctionner notre PWA en mode déconnecté grâce aux service workers. Consultez  la documentation si vous voulez en apprendre davantage sur les concepts qui sont derrière l'[API Service Worker](/fr/docs/Web/API/Service_Worker_API) et comment l'exploiter au mieux.
+Dans cet article, nous avons rapidement abordé la façon de faire fonctionner notre PWA en mode déconnecté grâce aux service workers. Consultez la documentation si vous voulez en apprendre davantage sur les concepts qui sont derrière l'[API Service Worker](/fr/docs/Web/API/Service_Worker_API) et comment l'exploiter au mieux.
-Les Service Workers sont également utilisés pour gérer les [push notifications](/fr/docs/Web/API/Push_API) — ceci sera expliqué dans un prochain article.
+Les Service Workers sont également utilisés pour gérer les [push notifications](/fr/docs/Web/API/Push_API) — ceci sera expliqué dans un prochain article.
{{PreviousMenuNext("Web/Apps/Progressive/App_structure", "Web/Apps/Progressive/Installable_PWAs", "Web/Apps/Progressive")}}
diff --git a/files/fr/web/progressive_web_apps/re-engageable_notifications_push/index.md b/files/fr/web/progressive_web_apps/re-engageable_notifications_push/index.md
index 75752e6e9f..2162236487 100644
--- a/files/fr/web/progressive_web_apps/re-engageable_notifications_push/index.md
+++ b/files/fr/web/progressive_web_apps/re-engageable_notifications_push/index.md
@@ -70,7 +70,7 @@ Pousser (push) est plus compliqué que de faire des notifications — nous avons
La technologie en est toujours à ses tous débuts — certains exemples fonctionnels utilisent la plateforme Cloud de messagerie de Google, mais elles sont en cours de réécriture pour prendre en charge [VAPID](https://blog.mozilla.org/services/2016/08/23/sending-vapid-identified-webpush-notifications-via-mozillas-push-service/) (Voluntary Application Identification) qui offre une couche de sécurité supplémentaire pour votre application. Vous pouvez étudier les [exemples du Cookbook des Service Workers](https://serviceworke.rs/push-payload.html), essayer de mettre en place un serveur d'émission de messages utilisant [Firebase](https://firebase.google.com/) ou construire votre propre serveur (en utilisant Node.js par exemple).
-Comme mentionné précédemment, pour être capable de recevoir des messages poussés, vous devez avoir un service worker dont les fondamentaux ont déjà été expliqué dans l'article  [Permettre aux PWAs de fonctionner en mode déconnecté grâce aux Service workers](/fr/docs/Web/Apps/Progressive/Offline_Service_workers). A l'intérieur du service worker, un mécanisme de souscription à un service d'émission est créé.
+Comme mentionné précédemment, pour être capable de recevoir des messages poussés, vous devez avoir un service worker dont les fondamentaux ont déjà été expliqué dans l'article [Permettre aux PWAs de fonctionner en mode déconnecté grâce aux Service workers](/fr/docs/Web/Apps/Progressive/Offline_Service_workers). A l'intérieur du service worker, un mécanisme de souscription à un service d'émission est créé.
```js
registration.pushManager.getSubscription() .then( /* ... */ );
@@ -137,7 +137,7 @@ const convertedVapidKey = urlBase64ToUint8Array(vapidPublicKey);
L'application récupère la clef publique du serveur et convertit la réponse sous forme de texte; puis cette réponse doit être convertie en un tableau de nombre entier non signé (Uint8Array (pour une prise en charge par Chrome). Pour en apprendre davantage sur les clefs VAPID, vous pouvez lire le message de blog [Envoyer des notifications WebPush identitées par VAPID via le service de Push de Mozilla](https://blog.mozilla.org/services/2016/08/23/sending-vapid-identified-webpush-notifications-via-mozillas-push-service/).
-L'application peut maintenant utiliser le {{domxref("PushManager")}} pour abonner le nouvel utilisateur. Il y a deux options passées à la méthode {{domxref("PushManager.subscribe()")}}  — la première est `userVisibleOnly: true`, qui signifie que toutes les notifications envoyées à l'utilisateur lui seront visibles et la seconde est `applicationServerKey`, qui contient notre clef VAPID une fois récupérée et convertie avec succès.
+L'application peut maintenant utiliser le {{domxref("PushManager")}} pour abonner le nouvel utilisateur. Il y a deux options passées à la méthode {{domxref("PushManager.subscribe()")}} — la première est `userVisibleOnly: true`, qui signifie que toutes les notifications envoyées à l'utilisateur lui seront visibles et la seconde est `applicationServerKey`, qui contient notre clef VAPID une fois récupérée et convertie avec succès.
```js
return registration.pushManager.subscribe({
@@ -183,7 +183,7 @@ document.getElementById('doIt').onclick = function() {
};
```
-Quand le bouton est cliqué,  `fetch` demande au serveur d'envoyer la notification avec les paramètres suivants: `payload` est le contenu que la notification doir afficher, `delay` définit un délai en seconde avant que la notification soit affichée et `ttl` indique en seconde le temps que cette notification doit rester disponible sur le serveur.
+Quand le bouton est cliqué, `fetch` demande au serveur d'envoyer la notification avec les paramètres suivants: `payload` est le contenu que la notification doir afficher, `delay` définit un délai en seconde avant que la notification soit affichée et `ttl` indique en seconde le temps que cette notification doit rester disponible sur le serveur.
Au tour maintenant du fichier Javascript suivant.