1 files changed, 5 insertions, 5 deletions
diff --git a/files/fr/web/http/compression/index.html b/files/fr/web/http/compression/index.html
index ec4fa26888..49b4794212 100644
--- a/files/fr/web/http/compression/index.html
+++ b/files/fr/web/http/compression/index.html
@@ -35,20 +35,20 @@ translation_of: Web/HTTP/Compression
 <p>Les algorithmes de compression avec pertes sont généralement plus performants que les algorithmes de compression sans perte.</p>
 
 <div class="note">
-<p>Puisque certains types de fichiers gèrent nativement la compression, il est souvent inutile de les compresser une seconde fois. En réalité, cela s'avère souvent contre-productif de par la taille induite par les données additionnelles nécessaires (lors de la compression, un dictionnaire de données est généré) le fichier en sortie est alors plus gros que celui avant compression. Veillez à ne pas utiliser les techniques suivantes pour les fichiers au format compressé.</p>
+<p><strong>Note :</strong> Puisque certains types de fichiers gèrent nativement la compression, il est souvent inutile de les compresser une seconde fois. En réalité, cela s'avère souvent contre-productif de par la taille induite par les données additionnelles nécessaires (lors de la compression, un dictionnaire de données est généré) le fichier en sortie est alors plus gros que celui avant compression. Veillez à ne pas utiliser les techniques suivantes pour les fichiers au format compressé.</p>
 </div>
 
 <h2 id="Compression_de_bout_en_bout">Compression de bout en bout</h2>
 
 <p>La compression de bout en bout constitue la compression permettant le plus de gain de performances pour le Web. La compression de bout en bout est définie par la compression du corps du message qui est effectuée par le serveur et ne sera modifié qu'une fois arrivé à destination par le client. Les étapes lors du transport laissent la charge utile inchangée.</p>
 
-<p><img alt="Séquence du serveur au client mettant en œuvre la compression de bout en bout" src="https://mdn.mozillademos.org/files/13801/HTTPEnco1.png" style="height: 307px; width: 955px;"></p>
+<p><img alt="Séquence du serveur au client mettant en œuvre la compression de bout en bout" src="httpenco1.png"></p>
 
 <p>L'ensemble des navigateurs récents supportent la compression de bout en bout et le seul élément à échanger entre le serveur et le client est l'algorithme de compression à utiliser. Ces algorithmes sont optimisés pour le transport du texte. Dans les années 90, les technologies de compression ont évoluées rapidement, il existe donc de nombreuses possibilités en termes d'algorithmes. Les algorithmes qu'il convient de considérer à l'heure actuelle sont : <code>gzip</code>, le plus utilisé et <code>br</code> le nouveau venu.</p>
 
 <p>Pour sélectionner l'algorithme à utiliser, le navigateur et le serveur s'appuient sur <a href="/fr/docs/Web/HTTP/Content_negotiation"> la négociation du contenu</a>. Le navigateur envoie un en-tête {{HTTPHeader("Accept-Encoding")}} contenant les algorithmes qu'il prend en charge par ordre de préférence, le serveur en sélectionne un pour compresser le corps de la réponse et inclut l'algorithme utilisé dans l'en-tête {{HTTPHeader("Content-Encoding")}} pour informer le navigateur de l’algorithme sélectionné. La négociation de contenu s'appuyant sur l'encodage des données le serveur doit envoyer un en-tête {{HTTPHeader("Vary")}} contenant au moins {{HTTPHeader("Accept-Encoding")}} en plus de l'en-tête de la réponse. Les caches seront ainsi en mesure de gérer les différentes représentations de la ressource.</p>
 
-<p><img alt="Séquence de négociation de contenu échangeant les algorithmes de compression et les en-têtes associés" src="https://mdn.mozillademos.org/files/13811/HTTPCompression1.png" style="height: 307px; width: 771px;"></p>
+<p><img alt="Séquence de négociation de contenu échangeant les algorithmes de compression et les en-têtes associés" src="httpcompression1.png"></p>
 
 <p>La compression permettant un gain de performance significatif, il est conseillé de l'activer pour l'ensemble des fichiers à l'exception des fichiers audios et vidéos au format compressé.</p>
 
@@ -58,11 +58,11 @@ translation_of: Web/HTTP/Compression
 
 <p>La compression saut par saut, bien que similaire à la compression de bout en bout se distingue fondamentalement par son fonctionnement : la compression n'a pas lieu au niveau du serveur mais entre des éléments du réseau situés entre le serveur et le navigateur, chaque bond pouvant utiliser un mécanisme de compression <em>différent</em>.</p>
 
-<p><img alt="Compression saut par saut entre le serveur et le client" src="https://mdn.mozillademos.org/files/13807/HTTPTE1.png"></p>
+<p><img alt="Compression saut par saut entre le serveur et le client" src="httpte1.png"></p>
 
 <p>HTTP permet de mettre en œuvre cette technique à l'aide d'un élément de négociation de contenu. Le nœud transmettant la donnée diffuse son utilisation de l'en-tête {{HTTPHeader("TE")}}, le noeud suivant choisit la méthode de compression appropriée et transmet son choix via {{HTTPHeader("Transfer-Encoding")}}.</p>
 
-<p><img alt="Diagramme de séquence détaillant les échanges d'en-têtes en compression saut par saut" src="https://mdn.mozillademos.org/files/13809/HTTPComp2.png"></p>
+<p><img alt="Diagramme de séquence détaillant les échanges d'en-têtes en compression saut par saut" src="httpcomp2.png"></p>
 
 <p>En pratique la compression saut par saut est transparente pour le serveur et le client et elle demeure rarement utilisée. Les en-têtes {HTTPHeader("TE")}} and {{HTTPHeader("Transfer-Encoding")}} sont le plus souvent utilisé pour transmettre des réponses par morceaux ce qui permet la transmission de ressource avant d'en avoir déterminé la taille.</p>