Fix: translation error (#830)

* Fix: translation error
* UPDT: Refresh from en-US, Rmv macros, Fix typos
* UPDT: Making the "See also" clear

Co-authored-by: tristantheb <tristantheb@users.noreply.github.com>

1 files changed, 72 insertions, 62 deletions

diff --git a/files/fr/web/http/authentication/index.html b/files/fr/web/http/authentication/index.html
index 87b0e287be..c2193228d6 100644
--- a/files/fr/web/http/authentication/index.html
+++ b/files/fr/web/http/authentication/index.html
@@ -1,89 +1,100 @@
 ---
-title: HTTP authentication
+title: Authentification HTTP
 slug: Web/HTTP/Authentication
+tags:
+  - Access Control
+  - Authentication
+  - Guide
+  - HTTP
+  - Security
 translation_of: Web/HTTP/Authentication
 ---
 <div>{{HTTPSidebar}}</div>
 
-<p class="summary">HTTP fournit la structure permettant le contrôle d'accès ainsi que l'authentification. Le schéma d'authentification HTTP le plus courant est l'authentification "Basique" ("Basic authentication" en anglais). Cette page a pour but de présenter ce schéma d'authentification, et montre comment l'utiliser pour restreindre l'accès à votre serveur.</p>
+<p class="summary">HTTP fournit la structure permettant le contrôle d'accès ainsi que l'authentification. Le schéma d'authentification HTTP le plus courant est « l'<em>authentification basique</em> » (« <em>Basic authentication</em> » en anglais). Cette page a pour but de présenter ce schéma d'authentification, et montre comment l'utiliser pour restreindre l'accès à votre serveur.</p>
 
-<h2 id="La_structure_d'authentification_HTTP">La structure d'authentification HTTP</h2>
+<h2 id="the_general_http_authentication_framework">La structure d'authentification HTTP</h2>
 
-<p>La {{RFC("7235")}} définit la structure d'authentification HTTP qui est utilisable par un serveur pour {{glossary("challenge", "défier")}} une requête client, et inversement par un client pour fournir des informations d'authentification à un serveur. Le fonctionnement du défi/réponse se déroule ainsi : le serveur répond à un client avec un statut {{HTTPStatus("401")}} (Unauthorized) et fournit l'information permettant l'autorisation via un en-tête de réponse {{HTTPHeader("WWW-Authenticate")}} contenant au moins un défi. Le client désirant s'authentifier peut ensuite le faire en incluant un en-tête de requête {{HTTPHeader("Authorization")}} contenant ses identifiants. Très souvent, le client va demander à l'utilisateur un mot de passe  et ensuite envoyer la requête au serveur en incluant cette information dans l'en-tête <code>Authorization</code>.</p>
+<p>La <a href="https://tools.ietf.org/html/rfc7235">RFC 7235</a> définit la structure d'authentification HTTP qui est utilisable par un serveur pour <a href="/fr/docs/Glossary/challenge">défier</a> une requête d'un client, et inversement par un client pour fournir des informations d'authentification à un serveur.</p>
 
-<p><img alt="" src="https://mdn.mozillademos.org/files/14689/HTTPAuth.png" style="height: 335px; width: 710px;"></p>
+<p>Le fonctionnement du défi/réponse se déroule ainsi :</p>
 
-<p>Dans le cadre d'une authentification basique ("Basic authentication" en anglais) comme montré dans l'image ci-dessus, les échanges <strong>doivent</strong> s'effectuer au travers d'une connection HTTPS (TLS) afin d'être sécurisée.</p>
+<ol>
+  <li>Le serveur répond à un client avec un statut <a href="/fr/docs/Web/HTTP/Status/401"><code>401</code></a> (« Unauthorized ») et fournit l'information permettant l'autorisation via un en-tête de réponse <a href="/fr/docs/Web/HTTP/Headers/WWW-Authenticate"><code>WWW-Authenticate</code></a> contenant au moins un défi.</li>
+  <li>Le client désirant s'authentifier peut ensuite le faire en incluant un en-tête de requête <a href="/fr/docs/Web/HTTP/Headers/Authorization"><code>Authorization</code></a> contenant ses identifiants.</li>
+  <li>Très souvent, le client va demander à l'utilisateur un mot de passe et ensuite envoyer la requête au serveur en incluant cette information dans l'en-tête <code>Authorization</code>.</li>
+</ol>
 
-<h3 id="Authentification_par_procuration">Authentification par procuration</h3>
+<p><img alt="Un diagramme de séquence illustrant les messages HTTP entre un client et la ligne de vie du serveur" src="HTTPAuth.png"></p>
 
-<p>Le même mécanisme de défi et réponse peut être utilisée pour <em>l'authentification par procuration</em> (<em>Proxy authentication</em> en anglais). Dans ce cas, c'est un système de procuration intermédiaire qui requiert l'authentification. Comme les deux authentifications (celle de la ressource et celle du système de procuration) peuvent coexister, un autre jeu d'en-têtes et de codes de réponses HTTP est nécessaire. Dans le cadre des systèmes de procuration, le code HTTP de défi est {{HTTPStatus("407")}} (Proxy Authentication Required), l'en-tête de réponse {{HTTPHeader("Proxy-Authenticate")}} contient au moins un défi applicable au système de procuration et l'en-tête de requête {{HTTPHeader("Proxy-Authorization")}} est utilisé pour fournir les identifiants au serveur de procuration.</p>
+<p>Dans le cadre d'une authentification basique comme montré dans l'image ci-dessus, les échanges <strong>doivent</strong> s'effectuer au travers d'une connection HTTPS (TLS) afin d'être sécurisée.</p>
 
-<h3 id="Accès_interdit">Accès interdit</h3>
+<h3 id="proxy_authentication">Authentification par procuration</h3>
 
-<p>Si un serveur de procuration reçoit des identifiants valides ne permettant pas d'avoir accès à une ressource donnée, le serveur doit répondre avec un code de réponse {{HTTPStatus("403")}} <code>Forbidden</code>. Dans ce cas, à l'inverse des codes {{HTTPStatus("401")}} <code>Unauthorized</code> ou {{HTTPStatus("407")}} <code>Proxy Authentication Required</code>, l'authentification n'est pas possible pour cet utilisateur.</p>
+<p>Le même mécanisme de défi et réponse peut être utilisée pour <em>l'authentification par procuration</em> (« <em>Proxy authentication</em> » en anglais). Dans ce cas, c'est un système de procuration intermédiaire qui requiert l'authentification. Comme les deux authentifications (celle de la ressource et celle du système de procuration) peuvent coexister, un autre jeu d'en-têtes et de codes de réponses HTTP est nécessaire. Dans le cadre des systèmes de procuration, le code HTTP de défi est <a href="/fr/docs/Web/HTTP/Status/407"><code>407</code></a> (« Proxy Authentication Required »), l'en-tête de réponse <a href="/fr/docs/Web/HTTP/Headers/Proxy-Authenticate"><code>Proxy-Authenticate</code></a> contient au moins un défi applicable au système de procuration et l'en-tête de requête <a href="/fr/docs/Web/HTTP/Headers/Proxy-Authorization"><code>Proxy-Authorization</code></a> est utilisé pour fournir les identifiants au serveur de procuration.</p>
 
-<h3 id="Authentification_des_images_multi-origines">Authentification des images multi-origines</h3>
+<h3 id="access_forbidden">Accès interdit</h3>
 
-<p>Une faille de sécurité potentielle qui a été récemment corrigée par les navigateurs est l'authentification des images multi-origines. À partir de <a href="/en-US/docs/Mozilla/Firefox/Releases/59">Firefox 59</a> et version ultérieures, les images chargées depuis des origines différentes du site courant ne sont plus en mesure de déclencher l'ouverture d'une fenêtre de dialogue ({{bug(1423146)}}) demandant l'authentification HTTP, empêchant ainsi le vol d'identifiants utilisateurs si des personnes mal-intentionnées étaient en mesure d'embarquer une image aléatoire dans une page.</p>
+<p>Si un serveur de procuration reçoit des identifiants valides ne permettant pas d'avoir accès à une ressource donnée, le serveur doit répondre avec un code de réponse <a href="/fr/docs/Web/HTTP/Status/403"><code>403</code></a> (« Forbidden »). Dans ce cas, à l'inverse des codes <a href="/fr/docs/Web/HTTP/Status/401"><code>401</code></a> (« Unauthorized ») ou <a href="/fr/docs/Web/HTTP/Status/407"><code>407</code></a> (« Proxy Authentication Required »), l'authentification n'est pas possible pour cet utilisateur.</p>
 
-<h3 id="Encodage_de_caractère_de_l'authentification_HTTP">Encodage de caractère de l'authentification HTTP</h3>
+<h3 id="authentication_of_cross-origin_images">Authentification des images multi-origines</h3>
 
-<p>Les navigateurs utilisent l'encodage de caractère <code>utf-8</code> pour les noms d'utilisateur ainsi que les mots de passe. Firefox utilisait auparavant l'encodage <code>ISO-8859-1</code>, mais l'a remplacé par <code>utf-8</code> afin de s'aligner avec les autres navigateurs et ainsi éviter les potentiels problèmes, comme décrit dans le {{bug(1419658)}}.</p>
+<p>Une faille de sécurité potentielle qui a été récemment corrigée par les navigateurs est l'authentification des images multi-origines. À partir de <a href="/fr/docs/Mozilla/Firefox/Releases/59">Firefox 59</a> et version ultérieures, les images chargées depuis des origines différentes du site courant ne sont plus en mesure de déclencher l'ouverture d'une fenêtre de dialogue (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1423146">bug 1423146</a>) demandant l'authentification HTTP, empêchant ainsi le vol d'identifiants utilisateurs si des personnes mal-intentionnées étaient en mesure d'embarquer une image aléatoire dans une page.</p>
 
-<h3 id="En-têtes_WWW-Authenticate_et_Proxy-Authenticate">En-têtes <code>WWW-Authenticate</code> et <code>Proxy-Authenticate</code></h3>
+<h3 id="character_encoding_of_http_authentication">Encodage de caractère de l'authentification HTTP</h3>
 
-<p>Les en-têtes de réponse {{HTTPHeader("WWW-Authenticate")}} et {{HTTPHeader("Proxy-Authenticate")}} définissent le schéma d'authentification devant être utilisée pour accéder à une ressource, afin que le client désirant y accéder puisse savoir comment fournir les identifiants. La syntaxe pour ces en-têtes est la suivante :</p>
+<p>Les navigateurs utilisent l'encodage de caractère <code>utf-8</code> pour les noms d'utilisateur ainsi que les mots de passe. Firefox utilisait auparavant l'encodage <code>ISO-8859-1</code>, mais l'a remplacé par <code>utf-8</code> afin de s'aligner avec les autres navigateurs et ainsi éviter les potentiels problèmes, comme décrit dans le <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1419658">bug 1419658</a>.</p>
 
-<p> </p>
+<h3 id="www-authenticate_and_proxy-authenticate_headers">En-têtes WWW-Authenticate et Proxy-Authenticate</h3>
 
-<pre class="syntaxbox">WWW-Authenticate: &lt;type&gt; realm=&lt;realm&gt;
-Proxy-Authenticate: &lt;type&gt; realm=&lt;realm&gt;</pre>
-
-<p> </p>
+<p>Les en-têtes de réponse <a href="/fr/docs/Web/HTTP/Headers/WWW-Authenticate"><code>WWW-Authenticate</code></a> et <a href="/fr/docs/Web/HTTP/Headers/Proxy-Authenticate"><code>Proxy-Authenticate</code></a> définissent le schéma d'authentification devant être utilisée pour accéder à une ressource, afin que le client désirant y accéder puisse savoir comment fournir les identifiants.</p>
 
-<p>Ici, <code>&lt;type&gt;</code> est le schéma d'authentification ("Basic" est le plus courant des schémas, et est présenté <a href="/en-US/docs/Web/HTTP/Authentication#Basic_authentication_scheme">ici</a>). Le <code>realm</code> (<em>domaine</em> en français) est utilisé pour décrire la "zone" protégée, ou pour indiquer la portée de la protection. Cela pourrait être un message comme par exemple "Accès au site de pré-production", pour que l'utilisateur puisse savoir à quel espace il est en train d'accéder.</p>
+<p>La syntaxe pour ces en-têtes est la suivante :</p>
 
-<h3 id="En-têtes_Authorization_et_Proxy-Authorization">En-têtes <code>Authorization</code> et <code>Proxy-Authorization</code></h3>
+<pre class="brush: html">WWW-Authenticate: &lt;type&gt; realm=&lt;realm&gt;
+Proxy-Authenticate: &lt;type&gt; realm=&lt;realm&gt;</pre>
 
-<p>Les en-têtes de requête {{HTTPHeader("Authorization")}} et {{HTTPHeader("Proxy-Authorization")}} contiennent les identifiants pour authentifier un client avec un serveur (de procuration). Ici, le type est encore une fois nécessaire, suivi par les identifiants, qui peuvent être encodés voire encryptés selon le schéma d'authentification utilisé.</p>
+<p>Ici, <code>&lt;type&gt;</code> est le schéma d'authentification (« Basic » est le plus courant des schémas, et est présenté <a href="#basic_authentication_scheme">ici</a>). Le <code>realm</code> (« <em>domaine</em> » en français) est utilisé pour décrire la « zone » protégée, ou pour indiquer la portée de la protection. Cela pourrait être un message, par exemple « Accès au site de pré-production », pour que l'utilisateur puisse savoir à quel espace il est en train d'accéder.</p>
 
-<pre class="syntaxbox">Authorization: &lt;type&gt; &lt;credentials&gt;
-Proxy-Authorization: &lt;type&gt; &lt;credentials&gt;
-</pre>
+<h3 id="authorization_and_proxy-authorization_headers">En-têtes Authorization et Proxy-Authorization</h3>
 
-<h3 id="Schéma_d'authentification">Schéma d'authentification</h3>
+<p>Les en-têtes de requête <a href="/fr/docs/Web/HTTP/Headers/Authorization"><code>Authorization</code></a> et <a href="/fr/docs/Web/HTTP/Headers/Proxy-Authorization"><code>Proxy-Authorization</code></a> contiennent les identifiants pour authentifier un client avec un serveur (de procuration). Ici, le type est encore une fois nécessaire, suivi par les identifiants, qui peuvent être encodés voire encryptés selon le schéma d'authentification utilisé.</p>
 
-<p>La structure d'authentification HTTP est utilisée par plusieurs schémas d'authentification. Ils diffèrent de par leur niveau de sécurité ainsi que par leur disponibilité dans les systèmes client ou serveur.</p>
+<pre class="brush: html">Authorization: &lt;type&gt; &lt;credentials&gt;
+Proxy-Authorization: &lt;type&gt; &lt;credentials&gt;</pre>
 
-<p>Le plus commun est le schéma d'authentification "Basique" ("Basic" en anglais), qui est présenté plus en détail ci-dessous. IANA maintient une <a class="external external-icon" href="http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml">liste des schéma d'authentification</a>, mais ils y en a d'autres fournit par des services d'hébergement comme Amazon AWS. Les schéma communs sont :</p>
+<h3 id="authentication_schemes">Schéma d'authentification</h3>
 
-<p> </p>
+<p>La structure d'authentification HTTP est utilisée par plusieurs schémas d'authentification. Ils diffèrent de par leur niveau de sécurité ainsi que par leur disponibilité dans les systèmes client ou serveur.</p>
 
-<ul>
- <li><strong>Basic</strong> (voir {{rfc(7617)}}, identifiants encodés en base64. Voir ci-dessous pour plus de détails.),</li>
- <li><strong>Bearer</strong> (voir {{rfc(6750)}}, jetons <em>bearer </em>("porteur" en français) pour accéder à des ressources protégées par OAuth 2.0),</li>
- <li><strong>Digest</strong> (voir {{rfc(7616)}}, Firefox n'est compatible qu'avec l'encryption md5, voir {{bug(472823)}} pour la compatibilité avec l'encryption SHA),</li>
- <li><strong>HOBA</strong> (voir {{rfc(7486)}} (brouillon), <strong>H</strong>TTP <strong>O</strong>rigin-<strong>B</strong>ound <strong>A</strong>uthentication, basé sur une signature digitale),</li>
- <li><strong>Mutual</strong> (voir <a href="https://tools.ietf.org/html/draft-ietf-httpauth-mutual-11">draft-ietf-httpauth-mutual</a>),</li>
- <li>
-  <p><strong>AWS4-HMAC-SHA256</strong> (voir <a href="http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html">Documentation AWS</a>).</p>
- </li>
-</ul>
+<p>Le plus commun est le schéma d'authentification « Basique » (« Basic » en anglais), qui est présenté plus en détail ci-dessous. IANA maintient une <a href="https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml">liste des schémas d'authentification</a>, mais ils y en a d'autres fournit par des services d'hébergement comme Amazon AWS. Les schémas communs sont :</p>
 
-<p> </p>
+<dl>
+  <dt>Basic</dt>
+  <dd>Voir <a href="https://tools.ietf.org/html/rfc7617">RFC 7617</a>, identifiants encodés en base64. Voir ci-dessous pour plus de détails.</dd>
+  <dt>Bearer</dt>
+  <dd>Voir <a href="https://tools.ietf.org/html/rfc6750">RFC 6750</a>, jetons <em>bearer</em> (« porteur » en français) pour accéder à des ressources protégées par OAuth 2.0.</dd>
+  <dt>Digest</dt>
+  <dd>Voir <a href="https://tools.ietf.org/html/rfc7616">RFC 7616</a>, Firefox n'est compatible qu'avec l'encryption md5, voir <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=472823">bug 472823</a> pour la compatibilité avec l'encryption SHA.</dd>
+  <dt>HOBA</dt>
+  <dd>Voir <a href="https://tools.ietf.org/html/rfc7486">RFC 7486</a>, <strong>H</strong>TTP <strong>O</strong>rigin-<strong>B</strong>ound <strong>A</strong>uthentication, basé sur une signature digitale.</dd>
+  <dt>Mutual</dt>
+  <dd>Voir <a href="https://tools.ietf.org/html/draft-ietf-httpauth-mutual-11">draft-ietf-httpauth-mutual</a>.</dd>
+  <dt>AWS4-HMAC-SHA256</dt>
+  <dd>Voir la <a href="https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html">Documentation AWS</a>.</dd>
+</dl>
 
-<h2 id="Schéma_d'authentification_basique_(Basic)">Schéma d'authentification basique ("Basic")</h2>
+<h2 id="basic_authentication_scheme">Schéma d'authentification basique</h2>
 
-<p>Le schéma d'authentification "basique" est définit dans la {{rfc(7617)}}, et transmet les identifiants via des ensembles ID_utilisateur/mot_de_passe, encodés avec base64.</p>
+<p>Le schéma d'authentification « basique » est défini dans la <a href="https://tools.ietf.org/html/rfc7617">RFC 7617</a>, et transmet les identifiants via des ensembles ID_utilisateur/mot_de_passe, encodés avec base64.</p>
 
-<h3 id="Sécurité_de_l'authentification_basique">Sécurité de l'authentification basique</h3>
+<h3 id="security_of_basic_authentication">Sécurité de l'authentification basique</h3>
 
-<p>Étant donnée que l'ID utilisateur et le mot de passe transitent sur le réseau en clair (base64 étant un encodage réversible), le schéma d'authentification basique n'est pas sécurisé. C'est pourquoi HTTPS / TLS doivent être utilisés avec ce type d'authentification. Sans cela, ce schéma <strong>ne doit pas</strong> être utilisé pour protéger des informations sensibles.</p>
+<p>Étant donné que l'ID utilisateur et le mot de passe transitent sur le réseau en clair (base64 étant un encodage réversible), le schéma d'authentification basique n'est pas sécurisé. C'est pourquoi HTTPS / TLS doivent être utilisés avec ce type d'authentification. Sans cela, ce schéma <strong>ne doit pas</strong> être utilisé pour protéger des informations sensibles.</p>
 
-<h3 id="Restreindre_l'accès_avec_Apache_et_l'authentification_basique">Restreindre l'accès avec Apache et l'authentification basique</h3>
+<h3 id="restricting_access_with_apache_and_basic_authentication">Restreindre l'accès avec Apache et l'authentification basique</h3>
 
-<p>Pour protéger avec un mot de passe un répertoire sur un serveur Apache, vous aurez besoin d'utiliser un ou plusieurs fichiers <code>.htaccess</code>  et <code>.htpasswd</code> .</p>
+<p>Pour protéger avec un mot de passe un répertoire sur un serveur Apache, vous aurez besoin d'utiliser un ou plusieurs fichiers <code>.htaccess</code> et <code>.htpasswd</code>.</p>
 
 <p>Le fichier <code>.htaccess</code> ressemble à ceci :</p>
 
@@ -92,35 +103,34 @@ AuthName "Accès au site de pré-production"
 AuthUserFile /chemin/vers/.htpasswd
 Require valid-user</pre>
 
-<p>Le fichier <code>.htaccess</code> fait référence à un fichier <code>.htpasswd</code> dans lequel chaque ligne contient un nom d'utilisateur ainsi qu'un mot de passe séparés par deux-points (":"). Vous ne pouvez pas déchiffrer les mots de passe à l'intérieur car ils sont <a href="https://httpd.apache.org/docs/2.4/misc/password_encryptions.html">encryptés</a> (md5 en l'occurrence). Vous pouvez tout à fait nommer votre fichier <code>.htpasswd</code> différemment si vous le désirez, mais gardez en tête que ce fichier ne doit pas être accessible à quiconque. (Apache est normalement configuré pour empêcher l'accès aux fichiers <code>.ht*</code>).</p>
+<p>Le fichier <code>.htaccess</code> fait référence à un fichier <code>.htpasswd</code> dans lequel chaque ligne contient un nom d'utilisateur et un mot de passe séparés par deux-points (« : »). Vous ne pouvez pas déchiffrer les mots de passe à l'intérieur, car ils sont <a href="https://httpd.apache.org/docs/2.4/misc/password_encryptions.html">encryptés</a> (md5 en l'occurrence). Vous pouvez tout à fait nommer votre fichier <code>.htpasswd</code> différemment si vous le désirez, mais gardez en tête que ce fichier ne doit pas être accessible à quiconque. (Apache est normalement configuré pour empêcher l'accès aux fichiers <code>.ht*</code>).</p>
 
 <pre>aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
-user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
-</pre>
+user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/</pre>
 
-<h3 id="Restreindre_l'accès_avec_nginx_et_l'authentification_basique">Restreindre l'accès avec nginx et l'authentification basique</h3>
+<h3 id="restricting_access_with_nginx_and_basic_authentication">Restreindre l'accès avec nginx et l'authentification basique</h3>
 
 <p>Pour nginx, vous aurez besoin de spécifier une zone ou emplacement (<em>location</em> en anglais) à protéger, ainsi que la directive <code>auth_basic</code> définissant le nom de cette zone. La directive <code>auth_basic_user_file</code> fait référence à un fichier .htpasswd contenant les identifiants utilisateurs encryptés, exactement comme dans l'exemple avec Apache ci-dessus.</p>
 
 <pre>location /status {
-    auth_basic           "Access to the staging site";
-    auth_basic_user_file /etc/apache2/.htpasswd;
+  auth_basic           "Access to the staging site";
+  auth_basic_user_file /etc/apache2/.htpasswd;
 }</pre>
 
-<h3 id="Accès_avec_identifiants_dans_l'URL">Accès avec identifiants dans l'URL</h3>
+<h3 id="access_using_credentials_in_the_url">Accès avec identifiants dans l'URL</h3>
 
 <p>Beaucoup de clients permettent d'éviter la fenêtre de dialogue demandant les identifiants en utilisant une URL contenant le nom d'utilisateur ainsi que le mot de passe comme suit :</p>
 
 <pre class="example-bad">https://utilisateur:password@www.example.com/</pre>
 
-<p><strong>L'utilisateur de ces URLs est déprécié.</strong> Dans Chrome, la partie <code>username:password@</code> dans les URLs est même <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=82250#c7">retirée pour des raisons de sécurité</a>. Dans Firefox, le site est testé afin de savoir s'il requiert ou non l'authentification et si ce n'est pas le cas, Firefox va avertir l'utilisateur avec une fenêtre de dialogue "Vous êtes sur le point de vous connecter au site "www.example.com" avec le nom d'utilisateur "username", mais le site ne requiert pas d'authentification. Ceci pourrait être une tentative pour vous piéger."</p>
+<p><strong>L'utilisation de ces URLs est dépréciée</strong>. Dans Chrome, la partie <code>username:password@</code> dans les URLs est même <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=82250#c7">retirée pour des raisons de sécurité</a>. Dans Firefox, le site est testé afin de savoir s'il requiert ou non l'authentification et si ce n'est pas le cas, Firefox va avertir l'utilisateur avec une fenêtre de dialogue « Vous êtes sur le point de vous connecter au site "www.example.com" avec le nom d'utilisateur "username", mais le site ne requiert pas d'authentification. Ceci pourrait être une tentative pour vous piéger. »</p>
 
-<h2 id="Voir_aussi">Voir aussi</h2>
+<h2 id="see_also">Voir aussi</h2>
 
 <ul>
- <li>{{HTTPHeader("WWW-Authenticate")}}</li>
- <li>{{HTTPHeader("Authorization")}}</li>
- <li>{{HTTPHeader("Proxy-Authorization")}}</li>
- <li>{{HTTPHeader("Proxy-Authenticate")}}</li>
- <li>{{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}</li>
+  <li>L'entête <a href="/fr/docs/Web/HTTP/Headers/WWW-Authenticate"><code>WWW-Authenticate</code></a></li>
+  <li>L'entête <a href="/fr/docs/Web/HTTP/Headers/Authorization"><code>Authorization</code></a></li>
+  <li>L'entête <a href="/fr/docs/Web/HTTP/Headers/Proxy-Authorization"><code>Proxy-Authorization</code></a></li>
+  <li>L'entête <a href="/fr/docs/Web/HTTP/Headers/Proxy-Authenticate"><code>Proxy-Authenticate</code></a></li>
+  <li>Les codes de statut : <a href="/fr/docs/Web/HTTP/Status/401"><code>401</code></a>, <a href="/fr/docs/Web/HTTP/Status/403"><code>403</code></a> et <a href="/fr/docs/Web/HTTP/Status/407"><code>407</code></a></li>
 </ul>