Fixes #1298 - update vs. en-US / fix typos (#1308)

* Fixes #1298 - update vs. en-US / fix typos
* FIX: Minor fix

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

1 files changed, 69 insertions, 69 deletions

diff --git a/files/fr/web/http/conditional_requests/index.html b/files/fr/web/http/conditional_requests/index.html
index a69cccc25e..5cd04d8440 100644
--- a/files/fr/web/http/conditional_requests/index.html
+++ b/files/fr/web/http/conditional_requests/index.html
@@ -2,147 +2,147 @@
 title: 'HTTP : Requêtes conditionnelles'
 slug: Web/HTTP/Conditional_requests
 tags:
+  - Conditional Requests
   - Guide
   - HTTP
-  - Requêtes Conditionnelles
 translation_of: Web/HTTP/Conditional_requests
 original_slug: Web/HTTP/Requêtes_conditionnelles
 ---
 <p>{{HTTPSidebar}}</p>
 
-<p class="summary">HTTP a un concept de requête conditionnelle où le résultat, et même le succés d'une requête, peut être changé en comparant les ressources affectées avec la valeur d'un validateur. De telles requêtes peuvent être utiles pour valider le contenu d'un cache et mettre de côté un contrôle inutile pour vérifier l'intégrité d'un document, comme le sommaire d'un téléchargement, ou éviter de perdre des mises à jour quand on télécharge ou modifie un document sur le serveur.</p>
+<p class="summary">Il existe en HTTP un concept de <em>requête conditionnelle</em> où le résultat, et même le succès d'une requête, peut être changé en comparant les ressources affectées avec la valeur d'un <em>validateur</em>. De telles requêtes peuvent être utiles pour valider le contenu d'un cache et éviter un contrôle inutile, pour vérifier l'intégrité d'un document, par exemple pour la reprise d'un téléchargement ou pour éviter de perdre des mises à jour quand on uploade ou modifie un document sur le serveur.</p>
 
-<h2 id="Principes">Principes</h2>
+<h2 id="principles">Principes</h2>
 
-<p>Les requêtes conditionnelles HTTP s'exécutent différemment en fonction de la valeur spécifique des en-têtes. Ces en-têtes définissent une condition de départ (pré-condition) et le résultat de la requête sera différent selon que la pré-condition est satisfaite ou non.</p>
+<p>Les requêtes conditionnelles HTTP s'exécutent différemment en fonction de la valeur spécifique d'en-têtes. Ces en-têtes définissent une condition de départ (pré-condition) et le résultat de la requête sera différent selon que la pré-condition est satisfaite ou non.</p>
 
 <p>Les comportements différents sont définis par la méthode qu'utilise la requête et par un ensemble d'en-têtes propres aux préconditions :</p>
 
 <ul>
- <li>Pour une méthode {{glossary("safe")}} comme {{HTTPMethod("GET")}}, qui, habituellement va chercher un document, la requête conditionnelle peut renvoyer le document si c'est pertinent seulement. Cela économise de la bande passante.</li>
- <li>Pour les méthodes {{glossary("safe", "unsafe")}} comme {HTTPMethod("PUT")}}, qui charge habituellement un document, la requête conditionnelle peut servir à charger le document, uniquement si l'original sur lequel la requête est basée est le même que celui stocké sur le serveur.</li>
+  <li>Pour une méthode <a href="/fr/docs/Glossary/safe">safe</a> comme <a href="/fr/docs/Web/HTTP/Methods/GET"><code>GET</code></a>, qui est généralement utilisée pour récupérer un document, la requête conditionnelle peut être utilisée afin de renvoyer le document uniquement si c'est pertinent. Cela économise de la bande passante.</li>
+  <li>Pour les méthodes <a href="/fr/docs/Glossary/safe">unsafe</a> comme <a href="/fr/docs/Web/HTTP/Methods/PUT"><code>PUT</code></a>, qui permet généralement d'uploader un document, la requête conditionnelle peut servir à charger le document, uniquement si l'original sur lequel la requête est basée est le même que celui stocké sur le serveur.</li>
 </ul>
 
-<h2 id="Validateurs">Validateurs</h2>
+<h2 id="validators">Validateurs</h2>
 
-<p>Toutes les en-têtes conditionnelles vérifient si la ressource stockée sur le serveur correspond à une version spécifique. Pour accomplir ceci, la requête conditionnelle doit préciser la version de la ressource car comparer l'ensemble bit à bit n'est pas faisable et pas toujours désiré non plus. La requête transmet une valeur qui caractérise la version. Ces valeurs sont appelées validateurs et il y en a de deux sortes :</p>
+<p>Tous les en-têtes conditionnels vérifient si la ressource stockée sur le serveur correspond à une version spécifique. Pour accomplir ceci, la requête conditionnelle doit préciser la version de la ressource. En effet, comparer l'ensemble octet par octet n'est pas faisable en pratique et ce n'est pas toujours le comportement désiré non plus. La requête transmet une valeur qui caractérise la version. Ces valeurs sont appelées validateurs et il en existe deux sortes :</p>
 
 <ul>
- <li>La date de dernière modification du document, la dernière date modifiée.</li>
- <li>une chaîne de caractére sans signification particulière identifiant uniquement chaque version. On l'appelle "étiquette d'entité" ou "etag".</li>
+  <li>La date de dernière modification du document fournie par <em><code>Last-Modified</code></em>.</li>
+  <li>Une chaîne de caractères sans signification particulière identifiant uniquement chaque version. On l'appelle "étiquette d'entité" ou "etag", fournie par <em><code>ETag</code></em>.</li>
 </ul>
 
-<p>Comparer les versions d'une même ressource est un peu délicat : en fonction du contexte, il y a deux sortes de vérification d'équivalence :</p>
+<p>Comparer les versions d'une même ressource est un peu délicat : en fonction du contexte, il existe deux sortes de vérification d'équivalence :</p>
 
 <ul>
- <li><em>Une validation forte </em>est utilisée quand une vérification bit à bit est demandé, par exemple pour reprendre un téléchargement.</li>
- <li><em>Une validation faible </em>est utilisée quand l'agent-utilisateur doit seulement déterminer si deux ressources ont le même contenu. Ils sont égaux même s'ils ont des différences minimes comme des publicités différentes ou un pied de page (footer) avec une date différente.</li>
+  <li><em>Une validation forte</em>, utilisée quand une vérification à l'octet près est demandée, par exemple pour reprendre un téléchargement.</li>
+  <li><em>Une validation faible</em>, utilisée quand l'agent-utilisateur doit seulement déterminer si deux ressources ont le même contenu. Ils sont égaux même s'ils ont des différences minimes comme des publicités différentes ou un pied de page avec une date différente.</li>
 </ul>
 
-<p>La sorte de la vérification est indépendante du validateur utilisé.  {{HTTPHeader("Last-Modified")}} et {{HTTPHeader("ETag")}}  permettent les deux tupes de validation bien que la complexité d'implémentation côté serveur soit variable.  HTTP se sert de la validation forte par défaut et spécifie quand la validation faible peut être employée.</p>
+<p>La sorte de la vérification est indépendante du validateur utilisé. <a href="/fr/docs/Web/HTTP/Headers/Last-Modified"><code>Last-Modified</code></a> et <a href="/fr/docs/Web/HTTP/Headers/ETag"><code>ETag</code></a> permettent les deux types de validation bien que la complexité d'implémentation côté serveur soit variable. HTTP se sert de la validation forte par défaut et spécifie quand la validation faible peut être employée.</p>
 
-<h3 id="Validation_forte">Validation forte</h3>
+<h3 id="strong_validation">Validation forte</h3>
 
-<p id="sect1">La validation forte consiste à garantir que la ressource est identique à celle à laquelle elle est comparée, au bit prés. C'est obligatoire pour certaines en-têtes et le défaut pour les autres. La validation forte est stricte et peut être difficile à garantir côté serveur mais cela garantit qu'à aucun moment une donnée n'est perdu, parfois au détriment de la performance.</p>
+<p>La validation forte consiste à garantir que la ressource est identique à celle à laquelle elle est comparée, à l'octet près. Cette validation est obligatoire pour certains en-têtes et correspond au comportement par défaut pour d'autres. La validation forte est stricte et peut être difficile à garantir côté serveur mais cela garantit qu'à aucun moment une donnée n'est perdue, parfois au détriment de la performance.</p>
 
-<p>Il est assez difficile d'avoir un identifiant unique pour la validation forte avec {{HTTPHeader("Last-Modified")}}. On le fait souvent en employant une {{HTTPHeader("ETag")}} avec le hachage MD5 de la ressource(ou un dérivé).</p>
+<p>Il est assez difficile d'avoir un identifiant unique pour la validation forte avec <a href="/fr/docs/Web/HTTP/Headers/Last-Modified"><code>Last-Modified</code></a>. On le fait souvent en employant une <a href="/fr/docs/Web/HTTP/Headers/ETag"><code>ETag</code></a> avec le hachage MD5 de la ressource (ou un dérivé).</p>
 
-<h3 id="Validation_faible">Validation faible</h3>
+<h3 id="weak_validation">Validation faible</h3>
 
-<p>La validation faible différe de la validation forte car elle considère que deux versions du document ayant le même contenu sont équivalentes. Par exemple, une page qui différerait d'une autre seulement par sa date dans le pied de page ou une publicité, sera considérée identique à l'autre avec la validation faible. Ces mêmes deux versions seront évaluées comme étant différentes avec la validation forte. Construire un système d'ETags pour la validation faible peut être complexe car cela induit de connaître l'importance des différents éléments de la page mais est trés utile dans le but d'optimiser les performances du cache.</p>
+<p>La validation faible diffère de la validation forte, car elle considère que deux versions du document sont identiques si le contenu est équivalent. Par exemple, une page qui différerait d'une autre seulement par sa date dans le pied de page ou une publicité, sera considérée identique à l'autre avec la validation faible. Ces mêmes deux versions pourraient être considérées comme différentes avec la validation forte. Construire un système d'ETags pour la validation faible peut être complexe car cela induit de connaître l'importance des différents éléments de la page mais est très utile dans le but d'optimiser les performances du cache.</p>
 
-<h2 id="En-têtes_conditionnelles">En-têtes conditionnelles</h2>
+<h2 id="conditional_headers">En-têtes conditionnels</h2>
 
-<p>Plusieurs en-têtes HTTP, appelées en-têtes conditionelles, apportent des conditions aux reques. Ce sont :</p>
+<p>Plusieurs en-têtes HTTP, appelées en-têtes conditionels, permettent de conditionner les requêtes :</p>
 
 <dl>
- <dt>{{HTTPHeader("If-Match")}}</dt>
- <dd>Succés si la {{HTTPHeader("ETag")}} de la ressource distante est égale à une de celles listées dans cette en-tête. Par défaut, à moins que l'etag soit préfixée <code>'W/'</code>, c'est une validation forte. it performs a strong validation.</dd>
- <dt>{{HTTPHeader("If-None-Match")}}</dt>
- <dd>Succés si la {{HTTPHeader("ETag")}} de la ressource distante est différente de toutes celles listées dans l'en-tête. Par défaut, à moins que l'etag soit préfixée <code>'W/'</code>, c'est une validation forte.</dd>
- <dt>{{HTTPHeader("If-Modified-Since")}}</dt>
- <dd>Succés si la date {{HTTPHeader("Last-Modified")}} de la ressource distante est plus récente que celle donnée dans l'en-tête.</dd>
- <dd></dd>
- <dt>{{HTTPHeader("If-Unmodified-Since")}}</dt>
- <dd>Succés si la date {{HTTPHeader("Last-Modified")}} de la ressource distante est plus ancienne ou égale à celle donnée dans l'en-tête.</dd>
- <dt>{{HTTPHeader("If-Range")}}</dt>
- <dd>Similaire à {{HTTPHeader("If-Match")}}, ou {{HTTPHeader("If-Unmodified-Since")}}, mais peut n'avoir qu'une seule etag, ou une date. Si ça ne colle pas, la requête est rejetée et à la place d'un statut de réponse {{HTTPStatus("206")}} <code>Partial Content</code> , un {{HTTPStatus("200")}} <code>OK</code> est envoyé avec la totlité de la ressource.</dd>
+  <dt><a href="/fr/docs/Web/HTTP/Headers/If-Match"><code>If-Match</code></a></dt>
+  <dd>Réussit si la <a href="/fr/docs/Web/HTTP/Headers/ETag"><code>ETag</code></a> de la ressource distante est égal à un de ceux listés dans cet en-tête. Par défaut, à moins que l'ETag soit préfixé par <code>'W/'</code>, c'est une validation forte.</dd>
+  <dt><a href="/fr/docs/Web/HTTP/Headers/If-None-Match"><code>If-None-Match</code></a></dt>
+  <dd>Réussit si la <a href="/fr/docs/Web/HTTP/Headers/ETag"><code>ETag</code></a> de la ressource distante est différent de tout ceux listés dans l'en-tête. Par défaut, à moins que l'ETag soit préfixé par <code>'W/'</code>, c'est une validation forte.</dd>
+  <dt><a href="/fr/docs/Web/HTTP/Headers/If-Modified-Since"><code>If-Modified-Since</code></a></dt>
+  <dd>Réussit si la date <a href="/fr/docs/Web/HTTP/Headers/Last-Modified"><code>Last-Modified</code></a> de la ressource distante est plus récente que celle donnée dans l'en-tête.</dd>
+  <dd></dd>
+  <dt><a href="/fr/docs/Web/HTTP/Headers/If-Unmodified-Since"><code>If-Unmodified-Since</code></a></dt>
+  <dd>Réussit si la date <a href="/fr/docs/Web/HTTP/Headers/Last-Modified"><code>Last-Modified</code></a> de la ressource distante est plus ancienne ou égale à celle donnée dans l'en-tête.</dd>
+  <dt><a href="/fr/docs/Web/HTTP/Headers/If-Range"><code>If-Range</code></a></dt>
+  <dd>Similaire à <a href="/fr/docs/Web/HTTP/Headers/If-Match"><code>If-Match</code></a>, ou <a href="/fr/docs/Web/HTTP/Headers/If-Unmodified-Since"><code>If-Unmodified-Since</code></a>, mais peut n'avoir qu'un seul ETag, ou une date. Si ça ne correspond pas, la requête est rejetée et à la place d'un statut de réponse <a href="/fr/docs/Web/HTTP/Status/206"><code>206</code></a> <code>Partial Content</code>, un <a href="/fr/docs/Web/HTTP/Status/200"><code>200</code></a> <code>OK</code> est envoyé avec la totalité de la ressource.</dd>
 </dl>
 
-<h2 id="Cas_d'utilisation">Cas d'utilisation</h2>
+<h2 id="use_cases">Cas d'utilisation</h2>
 
-<h3 id="Mise_à_jour_du_Cache">Mise à jour du Cache</h3>
+<h3 id="cache_update">Mise à jour du cache</h3>
 
-<p>Le cas d'utilisation le plus commun pour les requêtes conditionnelles est la mise à jour du cache. Avec un cache vide ou absent, la ressource demandée est renvoyée avec un statut {{HTTPStatus("200")}} <code>OK</code>.</p>
+<p>Le cas d'utilisation le plus commun pour les requêtes conditionnelles est la mise à jour du'uncache. Avec un cache vide ou absent, la ressource demandée est renvoyée avec un statut <a href="/fr/docs/Web/HTTP/Status/200"><code>200</code></a> <code>OK</code>.</p>
 
-<p><img alt="The request issued when the cache is empty triggers the resource to be downloaded, with both validator value sent as headers. The cache is then filled." src="https://mdn.mozillademos.org/files/13729/Cache1.png" style="height: 265px; width: 741px;"></p>
+<p><img alt="La requête émise lorsque le cache est vide déclenche le téléchargement de la ressource et les deux valeurs de validation son prevent itt envoyés en en-tête. Le cache est alors rempli." src="cache1.png"></p>
 
-<p>Dans la ressource les validateurs sont renvoyés dans les en-têtes. Dans cet exemple, deux validateurs {{HTTPHeader("Last-Modified")}} et  {{HTTPHeader("ETag")}} sont envoyés mais il pourrait tout aussi bien n'y en avoir qu'un. Ces validateurs sont en cache avec la ressource (comme toutes les en-têtes) et seront utilisés pour embarquer les requêtes conditionnelles quand le cache est périmé.</p>
+<p>Avec la ressource, les validateurs sont renvoyés dans les en-têtes. Dans cet exemple, deux validateurs <a href="/fr/docs/Web/HTTP/Headers/Last-Modified"><code>Last-Modified</code></a> et <a href="/fr/docs/Web/HTTP/Headers/ETag"><code>ETag</code></a> sont envoyés, mais il pourrait tout aussi bien n'y en avoir qu'un. Ces validateurs sont en cache avec la ressource (comme toutes les en-têtes) et seront utilisés pour embarquer les requêtes conditionnelles quand le cache est périmé.</p>
 
-<p>Tant que le cache n'est pas obsolète, aucune requête n'esst publiée. Mais une fois qu'il est dépassé, il est principalement contrôlé par l'en-tête {{HTTPHeader("Cache-Control")}} , le client n'utilise pas directement la valeur en cache mais publie une requête conditionnelle. La valeur du validateur est employé comme paramètre des en-têtes {{HTTPHeader("If-Modified-Since")}} et {{HTTPHeader("If-Match")}}.</p>
+<p>Tant que le cache n'est pas obsolète, aucune requête n'est émise. Mais une fois qu'il est dépassé, il est principalement contrôlé par l'en-tête <a href="/fr/docs/Web/HTTP/Headers/Cache-Control"><code>Cache-Control</code></a>, le client n'utilise pas directement la valeur en cache mais publie une requête conditionnelle. La valeur du validateur est employé comme paramètre des en-têtes <a href="/fr/docs/Web/HTTP/Headers/If-Modified-Since"><code>If-Modified-Since</code></a> et <a href="/fr/docs/Web/HTTP/Headers/If-Match"><code>If-Match</code></a>.</p>
 
-<p>Si la ressource n'a pas changé, le serveur renvoie une réponse {{HTTPStatus("304")}} <code>Not Modified</code>. Cela rafraîchit le cache et le client peut se servir de la valeur en cache. Bien qu'il y ait un aller-retour requête-réponse qui consomme quelques ressources, cette méthode est plus efficace que de transmettre à nouveau la totalité de la ressource via le réseau.</p>
+<p>Si la ressource n'a pas changé, le serveur renvoie une réponse <a href="/fr/docs/Web/HTTP/Status/304"><code>304</code></a> <code>Not Modified</code>. Cela rafraîchit le cache et le client peut se servir de la valeur en cache. Bien qu'il y ait un aller-retour requête-réponse qui consomme quelques ressources, cette méthode est plus efficace que de transmettre à nouveau la totalité de la ressource via le réseau.</p>
 
-<p><img alt="With a stale cache, the conditional request is sent. The server can determine if the resource changed, and, as in this case, decide not to send it again as it is the same." src="https://mdn.mozillademos.org/files/13731/HTTPCache2.png" style="height: 265px; width: 741px;"></p>
+<p><img alt="Avec un cache périmé, la requête conditionnelle est envoyée. Le serveur peut déterminer si une ressource a changé et, dans ce cas, décider de ne pas la renvoyer si c'est la même." src="httpcache2.png"></p>
 
-<p>Si la ressource n'a pas changée, le serveur renvoie juste une réponse  {{HTTPStatus("200")}}<code> OK</code> avec la nouvelle version de la ressource comme si la requête n'était pas conditionnelle et le client utilise cette nouvelle ressource et la met en cache.</p>
+<p>Si la ressource a changé, le serveur renvoie simplement une réponse <a href="/fr/docs/Web/HTTP/Status/200"><code>200</code></a><code> OK</code> avec la nouvelle version de la ressource comme si la requête n'était pas conditionnelle et le client utilise cette nouvelle ressource et la met en cache.</p>
 
-<p><img alt="In the case where the resource was changed, it is sent back as if the request wasn't conditional." src="https://mdn.mozillademos.org/files/13733/HTTPCache3.png"></p>
+<p><img alt="Dans le cas où la ressource a changé, elle est renvoyée, comme si la requête n'était pas conditionnelle." src="httpcache3.png"></p>
 
 <p>De plus, la configuration des validateurs côté serveur est totalement transparente : tous les navigateurs gèrent un cache et envoient de telles requêtes conditionnelles sans que cela ne nécessite de travail supplémentaire de la part du développeur.</p>
 
-<h3 id="Intégrité_d'un_téléchargement_partiel">Intégrité d'un téléchargement partiel</h3>
+<h3 id="integrity_of_a_partial_download">Intégrité d'un téléchargement partiel</h3>
 
 <p>Un téléchargement partiel de fichiers est une fonctionnalité de HTTP qui permet de reprendre des opérations en cours en économisant de la bande passante et du temps en conservant les données déjà reçues :</p>
 
-<p><img alt="A download has been stopped and only partial content has been retrieved." src="https://mdn.mozillademos.org/files/16190/HTTPResume1.png" style="height: 397px; width: 764px;"></p>
+<p><img alt="Un téléchargement a été stoppé et seule une partie du contenu a été récupérée." src="httpresume1.png"></p>
 
-<p>Un serveur qui supporte le téléchargement partiel le diffuse en envoyant une en-tête {{HTTPHeader("Accept-Ranges")}}. Quand il la reçoit, le client peut reprendre le téléchargement en envoyant une en-tête de requête {{HTTPHeader("Ranges")}} avec les données manquantes :</p>
+<p>Un serveur qui supporte le téléchargement partiel le diffuse en envoyant un en-tête <a href="/fr/docs/Web/HTTP/Headers/Accept-Ranges"><code>Accept-Ranges</code></a>. Quand il la reçoit, le client peut reprendre le téléchargement en envoyant un en-tête de requête <a href="/fr/docs/Web/HTTP/Headers/Ranges"><code>Ranges</code></a> avec les données manquantes :</p>
 
-<p><img alt="The client resumes the requests by indicating the range he needs and preconditions checking the validators of the partially obtained request." src="https://mdn.mozillademos.org/files/13737/HTTPResume2.png"></p>
+<p><img alt="Le client reprend la requête en indiquant l'intervalle dont il a besoin et les préconditions en vérifiant les validateurs de la requêtes obtenues partiellement." src="httpresume2.png"></p>
 
-<p>Le principe est simple mais il y a un problème potentiel : si la ressource téléchargée a été modifiée entre deux téléchargements, les données reçues correspondront à deux versions différentes de la ressource et le fichier final sera corrompu. Pour prévenir cela, des en-têtes conditionnelles sont employées.  Il y a deux manières de faire : la plus flexible se sert de {{HTTPHeader("If-Modified-Since")}} et de  {{HTTPHeader("If-Match")}}, le serveur retourne alors une erreur si la "pré-condition" n'est pas satisfaite et le client reprend le téléchargement depuis le début :</p>
+<p>Le principe est simple, mais il y a un problème potentiel : si la ressource téléchargée a été modifiée entre deux téléchargements, les données reçues correspondront à deux versions différentes de la ressource et le fichier final sera corrompu. Pour prévenir cela, des en-têtes conditionnelles sont employées. Il y a deux manières de faire : la plus flexible utilise <a href="/fr/docs/Web/HTTP/Headers/If-Modified-Since"><code>If-Modified-Since</code></a> et de <a href="/fr/docs/Web/HTTP/Headers/If-Match"><code>If-Match</code></a>, le serveur retourne alors une erreur si la pré-condition n'est pas satisfaite et le client reprend le téléchargement depuis le début :</p>
 
-<p><img alt="When the partially downloaded resource has been modified, the preconditions will fail and the resource will have to be downloaded again completely." src="https://mdn.mozillademos.org/files/13739/HTTPResume3.png"></p>
+<p><img alt="Lorsque la ressource partiellement téléchargée a été modifiée, les préconditions échoueront et la ressource devra à nouveau être téléchargée entièrement." src="httpresume3.png"></p>
 
-<p>Même si cette méthode marche, elle ajoute un échange requête/réponse quand le document a été modifié. Cela impacte la performance et HTTP a prévu une en-tête spécifique pour éviter ce scénario : {{HTTPHeader("If-Range")}}:</p>
+<p>Même si cette méthode fonctionne, elle ajoute un échange requête/réponse quand le document a été modifié. Cela impacte la performance et HTTP a prévu un en-tête spécifique pour éviter ce scénario : <a href="/fr/docs/Web/HTTP/Headers/If-Range"><code>If-Range</code></a>:</p>
 
-<p><img alt="The If-Range headers allows the server to directly send back the complete resource if it has been modified, no need to send a 412 error and wait for the client to re-initiate the download." src="https://mdn.mozillademos.org/files/13741/HTTPResume4.png" style="height: 263px; width: 770px;"></p>
+<p><img alt="Les en-têtes If-Range permettent au serveur de renvoyer directement la ressource complète si elle a été modifiée. Il n'est pas nécessaire d'envoyer une erreur 412 au client et d'attendre que ce dernier relance le téléchargement." src="httpresume4.png"></p>
 
-<p>Cette solution est plus efficace mais légèrement moins flexible puisqu' une etag seulement peut être utilisée dans la condition. On a rarement besoin d'une telle flexibilité additionnelle.</p>
+<p>Cette solution est plus efficace mais légèrement moins flexible puisqu'un seul ETag peut être utilisé dans la condition. On a rarement besoin d'une telle flexibilité additionnelle.</p>
 
-<h3 id="Èviter_les_problèmes_de_perte_de_mise_à_jour_avec_le_verrouillage_optimiste">Èviter les problèmes de perte de mise à jour avec le "verrouillage optimiste"</h3>
+<h3 id="avoiding_the_lost_update_problem_with_optimistic_locking">Èviter les problèmes de perte de mise à jour avec le "verrouillage optimiste"</h3>
 
-<p>Une opération commune des applications web est la mise à jour de document distants. C'est trés usuel dans tout système de fichiers ou dans les applications de contrôle de source et toute application qui permet de stocker des ressources distantes a besoin de ce mécanisme. Les sites comme les wikis et autres CMS s'en servent habituellement.</p>
+<p>Une opération commune des applications web est la mise à jour de documents distants. Cela arrive fréquemment dans tout système de fichiers ou dans les applications de contrôle de source. Toute application qui permet de stocker des ressources distantes a besoin de ce mécanisme. Les sites comme les wikis et autres CMS s'en servent habituellement.</p>
 
-<p>Vous pouvez l'implémenter avec la méthode {{HTTPMethod("PUT")}}. Le client lit d'abord les fichiers originaux, les modifie et finalement, les envoie au serveur.</p>
+<p>Vous pouvez l'implémenter avec la méthode <a href="/fr/docs/Web/HTTP/Methods/PUT"><code>PUT</code></a>. Le client lit d'abord les fichiers originaux, les modifie et finalement, les envoie au serveur.</p>
 
-<p><img alt="Updating a file with a PUT is very simple when concurrency is not involved." src="https://mdn.mozillademos.org/files/13743/HTTPLock1.png"></p>
+<p><img alt="Mettre à jour un fichier avec PUT est assez simple tant qu'il n'y a pas de concurrence." src="httplock1.png"></p>
 
-<p>Cependant, les choses deviennent un peu moins précises dés que l'on parle de simultanéité des comptes. Pendant qu'un client est en train de modifier  localement sa nouvelle copie de la ressource, un second client peut récupérer la même ressource et faire de même avec sa copie. Ce qui arrive ensuite est regrettable : quand ils enregistrent les modifications sur le serveur, celles du premier client sont écartées par l'enregistrement du second client qui n'est pas au courant des changements effectués sur la ressource par le premier client. Le choix qui est fait n'est pas communiqué aux autres protagonistes. Les changements adoptés changeront avec la vitesse d'enregistrement, ce qui dépend de la performance des clients, des serveurs et même de l'humain qui édite le document sur le client. Le "gagnant" changera d'une fois à l'autre. C'est donc une "course des conditions" ({{glossary("race condition")}}) qui conduit à des comportements problématiques difficiles à cerner et à débugger.</p>
+<p>Cependant, les choses deviennent un peu moins précises dès que l'on parle de simultanéité des connexions. Pendant qu'un client est en train de modifier localement sa nouvelle copie de la ressource, un second client peut récupérer la même ressource et faire de même avec sa copie. Ce qui arrive ensuite est regrettable : quand ils enregistrent les modifications sur le serveur, celles du premier client sont écartées par l'enregistrement du second client qui n'est pas au courant des changements effectués sur la ressource par le premier client. Le choix qui est fait n'est pas communiqué aux autres protagonistes. Les changements adoptés changeront avec la vitesse d'enregistrement, ce qui dépend de la performance des clients, des serveurs et même de l'humain qui édite le document sur le client. Le "gagnant" changera d'une fois à l'autre. C'est donc une situation de compétition (<a href="/fr/docs/Glossary/race condition"><i>race condition</i></a>) qui conduit à des comportements problématiques difficiles à cerner et à déboguer.</p>
 
-<p><img alt="When several clients update the same resource in parallel, we are facing a race condition: the slowest win, and the others don't even know they lost. Problematic!" src="https://mdn.mozillademos.org/files/13749/HTTPLock2.png" style="height: 504px; width: 904px;"></p>
+<p><img alt="Lorsque plusieurs clients mettent à jour la même ressource en parallèle, on a une situation de compétition (race condition) : c'est le plus lent qui gagne et les autres ne savent pas qu'ils ont perdu…" src="httplock2.png"></p>
 
-<p>Il n'existe aucune manière de gérer ce problème sans ennuyer l'un ou l'autre client. De toutes façons, les mises à jour perdues et la "course des conditions" sont appelées à disparaître. Nous voulons des résultats prévisibles et être notifiés quand les changements sont rejetés.</p>
+<p>Il n'existe aucune manière de gérer ce problème sans ennuyer l'un ou l'autre des deux clients. Toutefois, cela permet d'éviter les mises à jour perdues ou les situations de compétition. On souhaite avoir des résultats prévisibles et s'assurer que les clients soient prévenus lorsque leurs modifications sont rejetées.</p>
 
-<p>Les requêtes conditionnelles permettent d'implémenter l'algorithme de contrôle de concurrence (<em>o</em><em>ptimistic locking algorithm) </em>utilisé par la plupart des wikis ou systèmes de contrôle des sources. Le concept est de permettre au client d'avoir des copies de la ressource, les laisser se modifier localement puis de contrôler la mise en concurrence en autorisant celles du premier client soumettant une mise à jour. Toutes les mises à jour ultèrieures basées sur la version maintenant obsolète sont rejetées :</p>
+<p>Les requêtes conditionnelles permettent d'implémenter l'algorithme de contrôle de concurrence (<em>ptimistic locking algorithm</em>) utilisé par la plupart des wikis ou systèmes de contrôle des sources. Le concept est de permettre au client d'avoir des copies de la ressource, les laisser se modifier localement puis de contrôler la mise en concurrence en autorisant celles du premier client soumettant une mise à jour. Toutes les mises à jour ultérieures basées sur la version maintenant obsolète sont rejetées :</p>
 
-<p><img alt="Conditional requests allow to implement optimistic locking: now the quickest wins, and the others get an error." src="https://mdn.mozillademos.org/files/13751/HTTPLock3.png" style="height: 471px; width: 904px;"></p>
+<p><img alt="Les requêtes conditionnelles permettent d'implémenter un mécanisme de verrou optimiste : c'est le plus rapide qui gagne et les autres reçoivent une erreur." src="httplock3.png"></p>
 
-<p>Ce ci est implémenté par les en-têtes {{HTTPHeader("If-Match")}} ou {{HTTPHeader("If-Unmodified-Since")}} . Si l'etag ne correspond pas au fichier original ou si le fichier a été modifié depuis son obtention, le changement est alors simplement rejeté avec une erreur {{HTTPStatus("412")}} <code>Precondition Failed</code>. C'est maintenant à l'initiative du client que se réglera l'erreur : soit en prévenant le client de redémarrer avec la nouvelle version, soit en présentant au client les différences entre les deux versions pour l'aider à choisir les modifications à conserver.</p>
+<p>Ce ci est implémenté par les en-têtes <a href="/fr/docs/Web/HTTP/Headers/If-Match"><code>If-Match</code></a> ou <a href="/fr/docs/Web/HTTP/Headers/If-Unmodified-Since"><code>If-Unmodified-Since</code></a>. Si l'ETag ne correspond pas au fichier original ou si le fichier a été modifié depuis son obtention, le changement est alors simplement rejeté avec une erreur <a href="/fr/docs/Web/HTTP/Status/412"><code>412</code></a> <code>Precondition Failed</code>. C'est maintenant à l'initiative du client que se réglera l'erreur : soit en prévenant le client de redémarrer avec la nouvelle version, soit en présentant au client les différences entre les deux versions pour l'aider à choisir les modifications à conserver.</p>
 
-<h3 id="Gérer_le_premier_téléchargement_d'une_ressource">Gérer le premier téléchargement d'une ressource</h3>
+<h3 id="dealing_with_the_first_upload_of_a_resource">Gérer le premier téléchargement d'une ressource</h3>
 
-<p>Le premier téléchargement d'une ressource est un des cas résultant du comportement précédent. Comme toute mise à jour d'une ressource, le téléchargement va faire l'objet d'une "course des conditions" si deux clients essaient un enregistrement au même instant. Pour éviter cela, les en-têtes conditionnelles peuvent être employées : on ajoute {{HTTPHeader("If-None-Match")}} avec la valeur particulière <code>'*'</code>, représentant n'importe quelle etag. La requête aboutira seulement si la ressource n'existait pas avant :</p>
+<p>Le premier téléchargement d'une ressource est un des cas résultant du comportement précédent. Comme toute mise à jour d'une ressource, le téléchargement va faire l'objet d'une situation de compétition si deux clients essaient un enregistrement au même instant. Pour éviter cela, les en-têtes conditionnels peuvent être employés : on ajoute <a href="/fr/docs/Web/HTTP/Headers/If-None-Match"><code>If-None-Match</code></a> avec la valeur particulière <code>'*'</code>, représentant n'importe quel etag. La requête aboutira seulement si la ressource n'existait pas avant :</p>
 
-<p><img alt="Like for a regular upload, the first upload of a resource is subject to a race condition: If-None-Match can prevent it." src="https://mdn.mozillademos.org/files/13753/HTTPFirst.png" style="height: 311px; width: 895px;"></p>
+<p><img alt="Comme pour un upload normal, le premier upload d'une ressource est sujet à une situation de compétition. If-None-Match peut empêcher cela." src="httpfirst.png"></p>
 
-<p><code>If-None-Match</code> fonctionnera seulement avec les serveurs compatibles HTTP/1.1 (et postérieur). Si vous n'êtes pas sûr que le serveur le soit, vous devez d'abord envoyer une requête {{HTTPMethod("HEAD")}} à la ressource pour vérifier.</p>
+<p><code>If-None-Match</code> fonctionnera seulement avec les serveurs compatibles HTTP/1.1 (et postérieurs). Si vous n'avez pas la certitude que le serveur soit compatible, vous devez d'abord envoyer une requête <a href="/fr/docs/Web/HTTP/Methods/HEAD"><code>HEAD</code></a> à la ressource pour vérifier.</p>
 
-<h2 id="Conclusion">Conclusion</h2>
+<h2 id="conclusion">Conclusion</h2>
 
-<p>Les requêtes conditionnelles sont une fonctionnalité essentielle d'HTTP et permettent la construction d'applications efficaces et complexes. Pour le cache et la reprise des téléchargements, la seule obligation du webmaster est de configurer le serveur correctement, en paramètrant les bonnes etags : dans certains environnements, c'est un véritable défi. Une fois cela fait, le serveur renverra les requêtes conditionnelles adaptées.</p>
+<p>Les requêtes conditionnelles sont une fonctionnalité essentielle d'HTTP et permettent la construction d'applications efficaces et complexes. Pour le cache et la reprise des téléchargements, la seule tâche du webmaster consiste à configurer le serveur correctement. Dans certains environnements, paramétrer correctement les ETags peut s'avérer un véritable défi. Une fois que c'est fait, le navigateur pourra exploiter les requêtes conditionnelles.</p>
 
-<p>Pour verrouiller ces dispositifs, c'est l'inverse : les développeurs web devront publier une requête avec les en-têtes appropriées tandis que les webmasters peuvent en général se fier à l'application pour effectuer ces vérifications.</p>
+<p>Pour les mécanismes de verrou, c'est l'inverse : les développeurs web devront publier une requête avec les en-têtes appropriés tandis que les webmasters peuvent en général se fier à l'application pour effectuer ces vérifications.</p>
 
-<p>Dans les deux cas, c'est clair, les requêtes conditionnelles sont une des fonctionnalités essentielles du Web.</p>
+<p>Dans les deux cas, les requêtes conditionnelles représentent une fonctionnalité essentielle du Web.</p>