Fixes #3389 (#3394)

* Replace asterisks mixup

* 2nd pass

2 files changed, 3 insertions, 3 deletions

diff --git a/files/fr/learn/html/introduction_to_html/the_head_metadata_in_html/index.md b/files/fr/learn/html/introduction_to_html/the_head_metadata_in_html/index.md
index c54e7c15c5..366c3c123a 100644
--- a/files/fr/learn/html/introduction_to_html/the_head_metadata_in_html/index.md
+++ b/files/fr/learn/html/introduction_to_html/the_head_metadata_in_html/index.md
@@ -97,7 +97,7 @@ Dans l'exemple que nous avons vu au-dessus, cette ligne était présente :
 <meta charset="utf-8">
 ```
 
-Cet élément définit l'encodage des caractères du document - le jeu de caractères qu'il est autorisé à utiliser. `utf-8` \*\*est un jeu de caractères universel qui inclut à peu près tous les caractères des langues humaines. Cela signifie que votre page web sera capable de gérer l'affichage de n'importe quelle langue ; c'est donc une bonne idée de le définir dans chaque page web que vous créez ! Par exemple, votre page peut gérer l'anglais et le japonais sans aucun souci :
+Cet élément définit l'encodage des caractères du document - le jeu de caractères qu'il est autorisé à utiliser. `utf-8` est un jeu de caractères universel qui inclut à peu près tous les caractères des langues humaines. Cela signifie que votre page web sera capable de gérer l'affichage de n'importe quelle langue ; c'est donc une bonne idée de le définir dans chaque page web que vous créez ! Par exemple, votre page peut gérer l'anglais et le japonais sans aucun souci :
 
 ![Une page Web contenant des caractères français et japonais, le jeu de caractères étant universel ou utf-8. Les deux langues s'affichent correctement.](fr-meta-utf8.png)Si vous définissez votre encodage de caractères en `ISO-8859-1` , par exemple (le jeu de caractères de l'alphabet latin), le rendu de votre page sera totalement perturbé :
 
diff --git a/files/fr/learn/html/multimedia_and_embedding/other_embedding_technologies/index.md b/files/fr/learn/html/multimedia_and_embedding/other_embedding_technologies/index.md
index f8fd114421..c0b0014f29 100644
--- a/files/fr/learn/html/multimedia_and_embedding/other_embedding_technologies/index.md
+++ b/files/fr/learn/html/multimedia_and_embedding/other_embedding_technologies/index.md
@@ -241,7 +241,7 @@ Cet exemple inclut les éléments de base essentiels nécessaires à l'utilisati
 
 Nous avons dit plus haut qu'il y avait des problèmes en matière de sécurité — entrons maintenant un peu plus dans le détail. Nous ne nous attendons pas à cette problèmatique vous soit parfaiment claire dès la première lecture ; nous voulons simplement vous y sensibiliser et fournir un point de référence auquel vous pourrez revenir quand vous aurez plus d'expérience et commencerez à prévoir l'utilisation de `<iframe>` dans vos travaux et expérimentations. Car, il n'y a pas de craintes inutiles à avoir et refuser d'utiliser `<iframe>` — il faut juste être prudent. Poursuivons ...
 
-Fabricants de navigateurs et développeurs Web ont appris à la dure que `<iframe>` constitue sur le Web une cible commune (terme officiel : un **vecteur d'attaque**) pour des personnes mal intentionnées (souvent appelés **hackeurs (**pirates), ou plus exactement, **crackeurs**).  `<iframe>` est une porte d'entrée pour les attaques de ces personnes quand ils essaient de modifier malicieusement une page Web ou d'amener des utilisateurs à faire quelque chose qu'ils ne voudraient pas faire, comme révéler des informations confidentielles comme noms d'utilisateur et mots de passe. Pour cette raison, les ingénieurs spécialistes et les développeurs de navigateurs ont développé divers mécanismes de sécurité pour rendre `<iframe>` plus sûr. De meilleures pratiques sont aussi à prendre en compte — nous allons développer certaines d'entre elles ci-dessous.
+Fabricants de navigateurs et développeurs Web ont appris à la dure que `<iframe>` constitue sur le Web une cible commune (terme officiel : un **vecteur d'attaque**) pour des personnes mal intentionnées.  `<iframe>` est une porte d'entrée pour les attaques de ces personnes quand ils essaient de modifier malicieusement une page Web ou d'amener des utilisateurs à faire quelque chose qu'ils ne voudraient pas faire, comme révéler des informations confidentielles comme noms d'utilisateur et mots de passe. Pour cette raison, les ingénieurs spécialistes et les développeurs de navigateurs ont développé divers mécanismes de sécurité pour rendre `<iframe>` plus sûr. De meilleures pratiques sont aussi à prendre en compte — nous allons développer certaines d'entre elles ci-dessous.
 
 > **Note :** Le {{interwiki('wikipedia','détournement de clic')}} est un type d'attaque courant par l'intermédiaire de `<iframe>` : les hackeurs incorporent un `<iframe>` invisible dans votre document (ou intégrent votre document dans leur propre site malveillant) et s'en servent pour capturer les interactions utilisateur. C'est un moyen courant pour tromper des utilisateurs ou voler leurs données confidentielles.
 
@@ -336,7 +336,7 @@ Il était une fois des greffons qui s'étaient rendus indispensables sur le Web.
 **Mettez‑vous à portée de tout le monde**. Tout le monde a un navigateur, mais les greffons sont de plus en plus rares, surtout chez les utilisateurs mobiles. Puisque le Web est largement utilisable sans greffons, les gens préfèront aller sur les sites de vos concurrents plutôt que d'installer un greffon.
 
 - **Offrez-vous un répit avec les [migraines d'accessibilités supplémentaires](http://webaim.org/techniques/flash/) qui proviennent de Flash et des autres greffons.**
-- **Restez à l'écart des risques supplémentaires en matière de sécurité.\*\*** \*\*Adobe Flash est [notoirement](http://www.cvedetails.com/product/6761/Adobe-Flash-Player.html?vendor_id=53) non‑sûr[,](http://www.cvedetails.com/product/6761/Adobe-Flash-Player.html?vendor_id=53) même avec ses innombrables rustines. En 2015, Alex Stamos, chef de la sécurité chez Facebook, a même [demandé qu'Adobe arrête](http://www.theverge.com/2015/7/13/8948459/adobe-flash-insecure-says-facebook-cso)[ Flash.](http://www.theverge.com/2015/7/13/8948459/adobe-flash-insecure-says-facebook-cso)
+- **Restez à l'écart des risques supplémentaires en matière de sécurité.** Adobe Flash est [notoirement](http://www.cvedetails.com/product/6761/Adobe-Flash-Player.html?vendor_id=53) non‑sûr[,](http://www.cvedetails.com/product/6761/Adobe-Flash-Player.html?vendor_id=53) même avec ses innombrables rustines. En 2015, Alex Stamos, chef de la sécurité chez Facebook, a même [demandé qu'Adobe arrête](http://www.theverge.com/2015/7/13/8948459/adobe-flash-insecure-says-facebook-cso)[ Flash.](http://www.theverge.com/2015/7/13/8948459/adobe-flash-insecure-says-facebook-cso)
 
 Alors, que faire ? Si vous avez besoin d'interactivité, HTML et {{glossary("JavaScript")}} peuvent facilement faire le travail pour vous sans besoin d'applets Java ou d'une technologie ActiveX/BHO dépassée. Au lieu de compter sur Adobe Flash, utilisez la [vidéo HTML5](/fr/docs/Learn/HTML/Howto/Add_audio_or_video_content_to_a_webpage) pour vos besoins en médias, [SVG](/fr/docs/Learn/HTML/Howto/Add_vector_image_to_a_webpage) pour les graphiques vectoriels et [Canvas](/fr/docs/Web/API/Canvas_API/Tutorial) pour les images et animations complexes. [Peter Elst écrivait déjà il y a quelques années](https://plus.google.com/+PeterElst/posts/P5t4pFhptvp) qu'Adobe Flash est rarement le bon outil pour le travail, sauf pour les jeux spécialisés et les applications d'affaires. Quant à ActiveX, même le navigateur{{glossary("Microsoft Edge", "Edge")}} de Microsoft ne le prend plus en charge.