Prepare Web API section for Markdown conversion (#2464)

* Remove summary classes and ids

* Remove unecessary hidden

* Remove useless span filled with useless attributes / ids

* Remove useless font

* Remove notranslate

* Remove id in other elements than headings

* Remove name attributes

* Remove <pre><code> for JS w/ language-js class

* Remove <pre><code> for HTML w/ language-html class

* Remove <pre><code> for other lang w/ language-* class

* Rm highlighted line in code samples

* fix links, internal, external, absolute URLs

* missing file from last commit

* Fix styles errors apart from table + some classes

* Fix notes and warnings (+ some other :x)

* fix typo during merge which broke a doc

* aand forgot a conflict

* fix remaining classes of errors except dls and images

* Fix dls

* Fix images (deki/mozillademos) and remaining style issues

* Remove script tag from svg file

* Remove script tag from svg fileS

* Compress SVG files for CI

1 files changed, 27 insertions, 31 deletions

diff --git a/files/fr/web/api/websockets_api/writing_websocket_servers/index.html b/files/fr/web/api/websockets_api/writing_websocket_servers/index.html
index d3797e4f46..5cc97ce8b0 100644
--- a/files/fr/web/api/websockets_api/writing_websocket_servers/index.html
+++ b/files/fr/web/api/websockets_api/writing_websocket_servers/index.html
@@ -7,20 +7,20 @@ translation_of: Web/API/WebSockets_API/Writing_WebSocket_servers
 
 <p>Un serveur WebSocket peut être écrit dans n'importe quel language de programmation qui supporte les "<a href="https://fr.wikipedia.org/wiki/Berkeley_sockets">Berkeley sockets</a>", par exemple C(++), python ou même PHP et JavaScript (avec nodejs). Ceci n'est pas un tutoriel destiné à un language particulier mais un guide aidant à l'écriture de votre propre serveur.</p>
 
-<p>Avant de débuter, vous <strong>devez</strong> connaître précisément le fonctionnement du protocole HTTP et disposer d'une certaine expérience sur celui-ci. Des connaissances sur les sockets TCP dans votre langage de développement est également précieux. Ce guide ne présente ainsi que le <u><em>minimum</em></u><em> </em>des connaissances requises et non un guide ultime.</p>
+<p>Avant de débuter, vous <strong>devez</strong> connaître précisément le fonctionnement du protocole HTTP et disposer d'une certaine expérience sur celui-ci. Des connaissances sur les sockets TCP dans votre langage de développement est également précieux. Ce guide ne présente ainsi que le <em>minimum</em> des connaissances requises et non un guide ultime.</p>
 
 <div class="note">
-<p>Lire la dernière spécification officielle sur les WebSockets <a href="http://datatracker.ietf.org/doc/rfc6455/?include_text=1">RFC 6455</a>. Les sections 1 et 4-7 sont particulièrement intéressantes pour ce qui nous occupe. La section 10 évoque la sécurité et doit être connue et mise en oeuvre avant d'exposer votre serveur au-delà du réseau local / lors de la mise en production. </p>
+<p><strong>Note :</strong> Lire la dernière spécification officielle sur les WebSockets <a href="http://datatracker.ietf.org/doc/rfc6455/?include_text=1">RFC 6455</a>. Les sections 1 et 4-7 sont particulièrement intéressantes pour ce qui nous occupe. La section 10 évoque la sécurité et doit être connue et mise en oeuvre avant d'exposer votre serveur au-delà du réseau local / lors de la mise en production.</p>
 </div>
 
 <p>Un serveur WebSocket est compris ici en "bas niveau" (<em>c'est-à-dire plus proche du langage machine que du langage humain</em>. Les WebSockets sont souvent séparés et spécialisés vis-à-vis de leurs homologues serveurs (pour des questions de montées en charge ou d'autres raisons), donc vous devez souvent utiliser un <a href="https://fr.wikipedia.org/wiki/Proxy_inverse">proxy inverse</a> (<em>c'est-à-dire de l'extérieur vers l'intérieur du réseau local, comme pour un serveur HTTP classique</em>) pour détecter les "poignées de mains" spécifiques au WebSocket, qui précédent l'échange et permettent d'aiguiller les clients vers le bon logiciel. Dans ce cas, vous ne devez pas ajouter à votre serveur des <em>cookies</em> et d'autres méthodes d'authentification. </p>
 
-<h2 id="La_poignée_de_mains_du_WebSocket"><a id="PoignéeDeMain" name="PoignéeDeMain">La "poignée de mains" du WebSocket</a></h2>
+<h2 id="La_poignée_de_mains_du_WebSocket">La "poignée de mains" du WebSocket</h2>
 
 <p>En tout premier lieu, le serveur doit écouter les connexions sockets entrantes utilisant le protocole TCP standard. Suivant votre plateforme, celui-ci peut déjà le faire pour vous. Pour l'exemple qui suit, nous prenons pour acquis que votre serveur écoute le domaine <em>exemple.com</em> sur le port 8000 et votre serveur socket répond aux requêtes de type GET sur le chemin <em>/chat</em>. </p>
 
 <div class="warning">
-<p><strong>Attention:</strong> Si le serveur peut écouter n'importe quel port, mais que vous décidez de ne pas utiliser un port standard (80 ou 443 pour SSL), cela peut créer en avant des problèmes avec les parefeux et/ou les proxys. De plus, gardez en mémoire que certains navigateur Web (notablement Firefox 8+), n'autorisent pas les connexions WebSocket non-SSL sur une page SSL. </p>
+<p><strong>Attention :</strong> Si le serveur peut écouter n'importe quel port, mais que vous décidez de ne pas utiliser un port standard (80 ou 443 pour SSL), cela peut créer en avant des problèmes avec les parefeux et/ou les proxys. De plus, gardez en mémoire que certains navigateur Web (notablement Firefox 8+), n'autorisent pas les connexions WebSocket non-SSL sur une page SSL. </p>
 </div>
 
 <p>La <em>poignée de mains</em> est la partie "Web" dans les WebSockets : c'est le pont entre le protocole HTTP et le WebSocket. Durant cette poignée, les détails (les paramètres) de la connexion sont négociés et l'une des parties peut interromptre la transaction avant la fin si l'un des termes ne lui est pas autorisé / ne lui est pas possible. Le serveur doit donc être attentif à comprendre parfaitement les demandes et attentes du client, sans quoi des procédures de sécurité seront déclenchées. </p>
@@ -40,18 +40,18 @@ Sec-WebSocket-Version: 13
 
 <p>Le client peut solliciter des extensions de protocoles ou des sous-protocoles à cet instant ; voir <a href="#Miscellaneous">Miscellaneous</a> pour les détails. En outre, des en-têtes communs tel que <em>User-Agent</em>, <em>Referer</em>, <em>Cookie</em> ou des en-têtes d'authentification peuvent être envoyés par la même requête : leur usage est laissé libre car ils ne se rapportent pas directement au WebSocket et au processus de poignée de main. A ce titre il semble préférable de les ignorer : d'ailleurs dans de nombreuses configurations communes, un proxy inverse les aura finalement déjà traitées. </p>
 
-<p>Si un des entêtes n'est pas compris ou sa valeur n'est pas correcte, le serveur devrait envoyer une réponse  "<a href="https://developer.mozilla.org/en-US/docs/HTTP/Response_codes#400">400 Bad Request</a>" (<em>erreur 400 : la requête est incorrecte</em>) et clore immédiatement la connexion. Il peut par ailleurs indiquer la raison pour laquelle la poignée de mains a échoué dans le corps de réponse HTTP, mais le message peut ne jamais être affiché par le navigateur (<em>en somme, tout dépend du comportement du client</em>). Si le serveur ne comprend pas la version de WebSockets présentée, il doit envoyer dans la réponse un entête <em>Sec-WebSocket-Version</em> correspondant à la ou les version-s supportée-s. Ici le guide explique la version 13, la plus récente à l'heure de l'écriture du tutoriel (<em>voir le tutoriel en version anglaise pour la date exacte ; il s'agit là d'une traduction</em>). Maintenant, nous allons passer à l'entête attendu : <em>Sec-WebSocket-Key</em>.</p>
+<p>Si un des entêtes n'est pas compris ou sa valeur n'est pas correcte, le serveur devrait envoyer une réponse  "<a href="/en-US/docs/HTTP/Response_codes#400">400 Bad Request</a>" (<em>erreur 400 : la requête est incorrecte</em>) et clore immédiatement la connexion. Il peut par ailleurs indiquer la raison pour laquelle la poignée de mains a échoué dans le corps de réponse HTTP, mais le message peut ne jamais être affiché par le navigateur (<em>en somme, tout dépend du comportement du client</em>). Si le serveur ne comprend pas la version de WebSockets présentée, il doit envoyer dans la réponse un entête <em>Sec-WebSocket-Version</em> correspondant à la ou les version-s supportée-s. Ici le guide explique la version 13, la plus récente à l'heure de l'écriture du tutoriel (<em>voir le tutoriel en version anglaise pour la date exacte ; il s'agit là d'une traduction</em>). Maintenant, nous allons passer à l'entête attendu : <em>Sec-WebSocket-Key</em>.</p>
 
 <div class="note">
-<p><strong>Astuce:</strong>  Un grand nombre de navigateurs enverront un  <a href="https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS#Origin"><code>Entête d'origine</code></a>. Vous pouvez alors l'utiliser pour vérifier la sécurité de la transaction (par exemple vérifier la similitude des domaines, listes blanches ou noires, etc.) et éventuellement retourner une réponse <a href="https://developer.mozilla.org/en-US/docs/HTTP/Response_codes#403">403 Forbidden</a> si l'origine ne vous plaît pas. Toutefois garder à l'esprit que cet entête peut être simulé ou trompeur (il peut être ajouté manuellement ou lors du transfert). De nombreuses applications refusent les transactions sans celui-ci. </p>
+<p><strong>Note :</strong> Un grand nombre de navigateurs enverront un  <a href="/en-US/docs/HTTP/Access_control_CORS#Origin"><code>Entête d'origine</code></a>. Vous pouvez alors l'utiliser pour vérifier la sécurité de la transaction (par exemple vérifier la similitude des domaines, listes blanches ou noires, etc.) et éventuellement retourner une réponse <a href="/en-US/docs/HTTP/Response_codes#403">403 Forbidden</a> si l'origine ne vous plaît pas. Toutefois garder à l'esprit que cet entête peut être simulé ou trompeur (il peut être ajouté manuellement ou lors du transfert). De nombreuses applications refusent les transactions sans celui-ci. </p>
 </div>
 
 <div class="note">
-<p><strong>Astuce:</strong> L'URI de la requête (<code>/chat </code>dans notre cas), n'a pas de signification particulièrement dans les spécifications en usage : elle permet simplement, par convention, de disposer d'une multitude d'applications en parallèle grâce à WebSocket. Par exemple <code>exemple.com/chat</code> peut être associée à une API/une application de dialogue multiutilisateurs lorsque <code>/game</code> invoquera son homologue pour un jeu. </p>
+<p><strong>Note :</strong> L'URI de la requête (<code>/chat </code>dans notre cas), n'a pas de signification particulièrement dans les spécifications en usage : elle permet simplement, par convention, de disposer d'une multitude d'applications en parallèle grâce à WebSocket. Par exemple <code>exemple.com/chat</code> peut être associée à une API/une application de dialogue multiutilisateurs lorsque <code>/game</code> invoquera son homologue pour un jeu. </p>
 </div>
 
 <div class="note">
-<p><strong>Note:</strong> <a href="https://developer.mozilla.org/en-US/docs/HTTP/Response_codes">Les codes réguliers (<em>c-à-d défini par le protocole standard</em>) HTTP</a> ne peuvent être utilisés qu'<strong><em>avant</em></strong> la poignée : ceux après la poignée, sont définis d'une manière spécifique dans la section 7.4 de la documentation sus-nommée. </p>
+<p><strong>Note:</strong> <a href="/en-US/docs/HTTP/Response_codes">Les codes réguliers (<em>c-à-d défini par le protocole standard</em>) HTTP</a> ne peuvent être utilisés qu'<strong><em>avant</em></strong> la poignée : ceux après la poignée, sont définis d'une manière spécifique dans la section 7.4 de la documentation sus-nommée. </p>
 </div>
 
 <h3 id="La_réponse_du_serveur_lors_de_la_poignée_de_mains">La réponse du serveur lors de la poignée de mains </h3>
@@ -65,16 +65,16 @@ Connection: Upgrade
 
 </strong></pre>
 
-<p>En sus, le serveur peut décider de proposer des extensions de protocoles ou des sous-protocoles à cet instant ; voir <a href="#Miscellaneous">Miscellaneous</a> pour les détails. L'entête Sec-WebSocket-Accept nous intéresse ici : le serveur doit la former depuis l'entête Sec-WebSocket-Key envoyée précédemment par le client. Pour l'obtenir, vous devez concaténater (<em>rassembler</em>) la valeur de <em>Sec-WebSocket-Key</em> et "<em>258EAFA5-E914-47DA-95CA-C5AB0DC85B11</em>" (valeur fixée par défaut : c'est une "<a href="https://en.wikipedia.org/wiki/Magic_string" style="line-height: 1.5em;">magic string</a>") puis procéder au hash par la méthode <a href="https://en.wikipedia.org/wiki/SHA-1" style="line-height: 1.5em;">SHA-1</a> du résultat et retourner le format au format <a href="https://en.wikipedia.org/wiki/Base64" style="line-height: 1.5em;">base64</a>. </p>
+<p>En sus, le serveur peut décider de proposer des extensions de protocoles ou des sous-protocoles à cet instant ; voir <a href="#Miscellaneous">Miscellaneous</a> pour les détails. L'entête Sec-WebSocket-Accept nous intéresse ici : le serveur doit la former depuis l'entête Sec-WebSocket-Key envoyée précédemment par le client. Pour l'obtenir, vous devez concaténater (<em>rassembler</em>) la valeur de <em>Sec-WebSocket-Key</em> et "<em>258EAFA5-E914-47DA-95CA-C5AB0DC85B11</em>" (valeur fixée par défaut : c'est une "<a href="https://en.wikipedia.org/wiki/Magic_string">magic string</a>") puis procéder au hash par la méthode <a href="https://en.wikipedia.org/wiki/SHA-1">SHA-1</a> du résultat et retourner le format au format <a href="https://en.wikipedia.org/wiki/Base64">base64</a>. </p>
 
 <div class="note">
-<p><strong>Pour information / pour mémoire :</strong> Ce processus qui peut paraître inutilement complexe, permet de certifier que le serveur et le client sont bien sur une base WebSocket et non une requête HTTP  (qui serait alors mal interprétée). </p>
+<p><strong>Note :</strong> Ce processus qui peut paraître inutilement complexe, permet de certifier que le serveur et le client sont bien sur une base WebSocket et non une requête HTTP  (qui serait alors mal interprétée). </p>
 </div>
 
-<p>Ainsi si la clé (la valeur de l'entête du client) était "<code>dGhlIHNhbXBsZSBub25jZQ==</code>", le retour (<em><u>Accept</u> * dans la version d'origine du tutoriel</em>) sera : "<code>s3pPLMBiTxaQ9kYGzzhZRbK+xOo=</code>". Une fois que le serveur a envoyé les entêtes attendues, alors la poignée de mains est considérée comme effectuée et vous pouvez débuter l'échange de données ! </p>
+<p>Ainsi si la clé (la valeur de l'entête du client) était "<code>dGhlIHNhbXBsZSBub25jZQ==</code>", le retour (<em>Accept * dans la version d'origine du tutoriel</em>) sera : "<code>s3pPLMBiTxaQ9kYGzzhZRbK+xOo=</code>". Une fois que le serveur a envoyé les entêtes attendues, alors la poignée de mains est considérée comme effectuée et vous pouvez débuter l'échange de données ! </p>
 
 <div class="note">
-<p>Le serveur peut envoyer à ce moment, d'autres entêtes comme par exemple Set-Cookie, ou demander une authenficiation ou encore une redirection via les codes standards HTTP et ce <em><strong>avant </strong></em>la fin du processus de poignée de main. </p>
+<p><strong>Note :</strong> Le serveur peut envoyer à ce moment, d'autres entêtes comme par exemple Set-Cookie, ou demander une authenficiation ou encore une redirection via les codes standards HTTP et ce <em><strong>avant </strong></em>la fin du processus de poignée de main. </p>
 </div>
 
 <h3 id="Suivre_les_clients_confirmés">Suivre les clients confirmés </h3>
@@ -88,12 +88,12 @@ Connection: Upgrade
 <h3 id="Format">Format</h3>
 
 <div class="warning">
-<p><strong>Note du traducteur</strong> : Dans cette partie, <code>payload </code>équivaut en bon français à <em>charge utile</em>. C'est-à-dire les données qui ne font pas partie du fonctionnement de la trame mais de l'échange entre le serveur et le client. Ainsi j'ai traduit <code>payload data comme des <em>données utiles. </em></code></p>
+<p><strong>Attention :</strong> Dans cette partie, <code>payload </code>équivaut en bon français à <em>charge utile</em>. C'est-à-dire les données qui ne font pas partie du fonctionnement de la trame mais de l'échange entre le serveur et le client. Ainsi j'ai traduit <code>payload data comme des <em>données utiles. </em></code></p>
 </div>
 
 <p>Chaque trame (dans un sens ou dans un autre) suit le schéma suivant : </p>
 
-<pre style="float: left; margin-right: 20px;"> <strong>0</strong>               <strong>1</strong>               <strong>2</strong>               3
+<pre> <strong>0</strong>               <strong>1</strong>               <strong>2</strong>               3
  0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
 +-+-+-+-+-------+-+-------------+-------------------------------+
 |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
@@ -146,10 +146,10 @@ Connection: Upgrade
 <pre>var DECODED = "";
 for (var i = 0; i &lt; ENCODED.length; i++) {
     DECODED[i] = ENCODED[i] ^ MASK[i % 4];
-<span style="line-height: 1.5;">}</span></pre>
+}</pre>
 
 <div class="note">
-<p>Ici la variable <code>DECODED</code> correspond aux données utiles à votre application - en fonction de l'utilisation ou non d'un sous-protocole (<em>si c'est <code>json</code>, vous devez encore décoder les données utiles reçues avec le parseur JSON</em>). </p>
+<p><strong>Note :</strong> Ici la variable <code>DECODED</code> correspond aux données utiles à votre application - en fonction de l'utilisation ou non d'un sous-protocole (<em>si c'est <code>json</code>, vous devez encore décoder les données utiles reçues avec le parseur JSON</em>). </p>
 </div>
 
 <h3 id="La_fragmentation_des_messages">La fragmentation des messages </h3>
@@ -158,7 +158,7 @@ for (var i = 0; i &lt; ENCODED.length; i++) {
 
 <p>Souvenez-vous de l'intérêt de l'opcode et ce qu'il implique dans l'échange des trames. Pour <em>0x1 </em>c'est du texte, pour <em>0x2 </em>des données binaires, etc. Toutefois pour <em>0x0</em>, la frame est dite "continue" (elle s'ajoute à la précédente). En voici un exemple plus clair, où il y a en réalité deux textes de message (sur 4 trames différentes) : </p>
 
-<pre style="font-size: 14px;"><strong>Client:</strong> FIN=1, opcode=0x1, msg="hello"
+<pre><strong>Client:</strong> FIN=1, opcode=0x1, msg="hello"
 <strong>Server:</strong> <em>(process complete message immediately) </em>Hi.
 <strong>Client:</strong> FIN=0, opcode=0x1, msg="and a"
 <strong>Server:</strong> <em>(listening, new message containing text started)</em>
@@ -177,35 +177,31 @@ for (var i = 0; i &lt; ENCODED.length; i++) {
 <p>Le <em>ping </em>ou le <em>pong </em>sont des trames classiques dites <strong>de contrôle</strong>. Les <em>pings </em>disposent d'un opcode à <code>0x9</code> et les <em>pongs </em>à <code>0xA</code>. Lorsqu'un <em>ping </em>est envoyé, le <em>pong </em>doit disposer de la même donnée utile en réponse que le ping (et d'une taille maximum autorisé de 125). Le <em>pong </em>seul (c-à-d sans <em>ping</em>) est ignoré. </p>
 
 <div class="note">
-<p>Lorsque plusieurs pings sont envoyés à la suite, un <strong>seul </strong>pong suffit en réponse (<em>le plus récent pour la donnée utile renvoyée</em>). </p>
+<p><strong>Note :</strong> Lorsque plusieurs pings sont envoyés à la suite, un <strong>seul </strong>pong suffit en réponse (<em>le plus récent pour la donnée utile renvoyée</em>). </p>
 </div>
 
 <h2 id="Clore_la_connexion">Clore la connexion </h2>
 
 <p>La connexion peut être close à l'initiative du client ou du serveur grâce à l'envoi d'une trame de contrôle contenant des données spécifiques permettant d'interrompre la poignée de main (de lever définitivement le masque pour être plus précis ; voir la <a href="http://tools.ietf.org/html/rfc6455#section-5.5.1">section 5.5.1</a>). Dès la réception de la trame, le récepteur envoit une trame spécifique de fermeture en retour (pour signifier la bonne compréhension de la fin de connexion). C'est l'émetteur à l'origine de la fermeture qui doit clore la connexion ; toutes les données supplémentaires sont éliminés / ignorés. </p>
 
-<h2 id="Diverses_informations_utiles"><a id="Miscellaneous" name="Miscellaneous">Diverses informations utiles</a></h2>
+<h2 id="Diverses_informations_utiles">Diverses informations utiles</h2>
 
 <div class="note">
-<p>L'ensemble des codes, extensions et sous-protocoles liés aux WebSocket sont enregistrés dans le (registre) <a href="http://www.iana.org/assignments/websocket/websocket.xml">IANA WebSocket Protocol Registry</a>.</p>
+<p><strong>Note :</strong> L'ensemble des codes, extensions et sous-protocoles liés aux WebSocket sont enregistrés dans le (registre) <a href="http://www.iana.org/assignments/websocket/websocket.xml">IANA WebSocket Protocol Registry</a>.</p>
 </div>
 
 <p>Les extensions et sous-protocoles des WebSockets sont négociés durant <a href="#PoignéeDeMain">l'échange des entêtes de la poignée de mains</a>. Si l'on pourrait croire qu'extensions et sous-protocles sont finalement la même chose, il n'en est rien : <strong>le contrôle des extensions agit sur les trames</strong> ce qui modifie la charge utile ; <strong>alors que les sous-protocoles modifient uniquement la charge utile,</strong> et rien d'autre. Les extensions sont optionnelles et généralisées (par exemple pour la compression des données) ; les sous-protocoles sont souvent obligatoires et ciblés (par exemple dans le cadre d'une application de chat ou d'un jeu MMORPG). </p>
 
 <div class="warning">
-<p><strong>NDT : </strong>Les sous-extensions ou les sous-protocoles ne sont pas obligatoires pour l'échange de données par WebSockets ; mais l'esprit développé ici est de rendre soit plus efficace ou sécurisée la transmission (l'esprit d'une extension) ; soit de délimiter et de normaliser le contenu de l'échange (l'esprit d'un sous-protocole ; qui étend donc le protocole par défaut des WebSockets qu'est l'échange de texte simple au format UTF-8). </p>
+<p><strong>Attention :</strong> Les sous-extensions ou les sous-protocoles ne sont pas obligatoires pour l'échange de données par WebSockets ; mais l'esprit développé ici est de rendre soit plus efficace ou sécurisée la transmission (l'esprit d'une extension) ; soit de délimiter et de normaliser le contenu de l'échange (l'esprit d'un sous-protocole ; qui étend donc le protocole par défaut des WebSockets qu'est l'échange de texte simple au format UTF-8). </p>
 </div>
 
 <h3 id="Les_extensions">Les extensions</h3>
 
-<div class="note">
-<p><strong>Cette section mériterait d'être étendue et complétée. Merci de le faire si vous disposez des moyens pour le faire. </strong></p>
-</div>
-
 <p>L'idée des extensions pourrait être, par exemple, la compression d'un fichier avant de l'envoyer par courriel / email à quelqu'un : les données transférées ne changent pas de contenu, mais leur format oui (et leur taille aussi...). Ce n'est donc pas le format du contenu qui change que le mode transmission - c'est le principe des extensions en WebSockets, dont le principe de base est d'être un protocole simple d'échange de données. </p>
 
 <div class="note">
-<p>Les extensions sont présentées et expliquées dans les sections 5.8, 9, 11.3.2, and 11.4 de la documentation sus-nommées. </p>
+<p><strong>Note :</strong> Les extensions sont présentées et expliquées dans les sections 5.8, 9, 11.3.2, and 11.4 de la documentation sus-nommées.</p>
 </div>
 
 <h3 id="Les_sous-protocoles">Les sous-protocoles </h3>
@@ -213,7 +209,7 @@ for (var i = 0; i &lt; ENCODED.length; i++) {
 <p>Les sous-protocoles sont à comparer à <a href="https://en.wikipedia.org/wiki/XML_schema">un schéma XML</a> ou <a href="https://en.wikipedia.org/wiki/Document_Type_Definition">une déclaration de DocType</a>. Ainsi vous pouvez utiliser seulement du XML et sa syntaxe et, imposer par le biais des sous-protocoles, son utilisation durant l'échange WebSocket. C'est l'intérêt de ces sous-protocoles : établir une structure définie (<em>et intangible : le client se voit imposer la mise en oeuvre par le serveur</em>), bien que les deux doivent l'accepter pour communiquer ensemble. </p>
 
 <div class="note">
-<p>Les sous-protocoles sont expliqués dans les sections 1.9, 4.2, 11.3.4, and 11.5 de la documentation sus-nommés. </p>
+<p><strong>Note :</strong> Les sous-protocoles sont expliqués dans les sections 1.9, 4.2, 11.3.4, and 11.5 de la documentation sus-nommés. </p>
 </div>
 
 <p>Exemple : un client souhaite demander un sous-protocole spécifique. Pour se faire, il envoie dans les entêtes d'origine du processus de poignées de mains : </p>
@@ -236,19 +232,19 @@ Sec-WebSocket-Protocol: wamp
 </pre>
 
 <div class="warning">
-<p>Le serveur ne peut (ne doit) envoyer plus d'un entête <code>Sec-Websocket-Protocol</code>. <strong>S'il n'en supporte aucun, il ne doit pas renvoyer l'entête <code>Sec-WebSocket-Protocol</code> (l'entête vide n'est pas correct). </strong>Le client peut alors interrompre la connexion s'il n'a pas le sous-protocole qu'il souhaite (ou qu'il supporte). </p>
+<p><strong>Attention :</strong> Le serveur ne peut (ne doit) envoyer plus d'un entête <code>Sec-Websocket-Protocol</code>. <strong>S'il n'en supporte aucun, il ne doit pas renvoyer l'entête <code>Sec-WebSocket-Protocol</code> (l'entête vide n'est pas correct). </strong>Le client peut alors interrompre la connexion s'il n'a pas le sous-protocole qu'il souhaite (ou qu'il supporte). </p>
 </div>
 
-<p>Si vous souhaitez que votre serveur puisse supporter certains sous-protocoles, vous pourriez avoir besoin d'une application ou de scripts supplémentaires sur le serveur. Imaginons par exemple que vous utilisiez le sous-protocole json - où toutes les données échangées par WebSockets sont donc formatés suivant le format <a href="https://fr.wikipedia.org/wiki/JavaScript_Object_Notation">JSON</a>. Si le client sollicite ce sous-protocole et que le serveur souhaite l'accepter, vous <u><strong>devez disposer</strong></u> d'un parseur (d'un décodeur) JSON et décoder les données par celui-ci. </p>
+<p>Si vous souhaitez que votre serveur puisse supporter certains sous-protocoles, vous pourriez avoir besoin d'une application ou de scripts supplémentaires sur le serveur. Imaginons par exemple que vous utilisiez le sous-protocole json - où toutes les données échangées par WebSockets sont donc formatés suivant le format <a href="https://fr.wikipedia.org/wiki/JavaScript_Object_Notation">JSON</a>. Si le client sollicite ce sous-protocole et que le serveur souhaite l'accepter, vous <strong>devez disposer</strong> d'un parseur (d'un décodeur) JSON et décoder les données par celui-ci. </p>
 
 <div class="note">
-<p><strong>Astuce:</strong> Pour éviter des conflits d'espaces de noms, il est recommandé d'utiliser le sous-protocole comme un sous-domaine de celui utilisé. Par exemple si vous utilisez un sous-protocole propriétaire qui utilise un format d'échange de données non-standard pour une application de <em>chat </em>sur le domaine <em>exemple.com</em>, vous devrirez utiliser : <code>Sec-WebSocket-Protocol: chat.exemple.com</code>. S'il y a différentes versions possibles, modifiez le chemin pour faire correspondre le path à votre version comme ceci : <code>chat.exemple.com/2.0</code>. Notez que ce n'est pas obligatoire, c'est une convention d'écriture optionnel et qui peut être utilisée d'une toute autre façon. </p>
+<p><strong>Note :</strong> Pour éviter des conflits d'espaces de noms, il est recommandé d'utiliser le sous-protocole comme un sous-domaine de celui utilisé. Par exemple si vous utilisez un sous-protocole propriétaire qui utilise un format d'échange de données non-standard pour une application de <em>chat </em>sur le domaine <em>exemple.com</em>, vous devrirez utiliser : <code>Sec-WebSocket-Protocol: chat.exemple.com</code>. S'il y a différentes versions possibles, modifiez le chemin pour faire correspondre le path à votre version comme ceci : <code>chat.exemple.com/2.0</code>. Notez que ce n'est pas obligatoire, c'est une convention d'écriture optionnel et qui peut être utilisée d'une toute autre façon.</p>
 </div>
 
 <h2 id="Contenus_associés">Contenus associés</h2>
 
 <ul>
- <li><a href="/en-US/docs/WebSockets/Writing_WebSocket_server" title="/en-US/docs/WebSockets/Writing_WebSocket_server">Tutorial: Websocket server in C#</a></li>
+ <li><a href="/en-US/docs/WebSockets/Writing_WebSocket_server">Tutorial: Websocket server in C#</a></li>
  <li><a href="/en-US/docs/WebSockets/Writing_WebSocket_client_applications">Writing WebSocket client applications</a></li>
  <li><a href="/en-US/docs/WebSockets/WebSocket_Server_Vb.NET">Tutorial: Websocket server in VB.NET</a></li>
 </ul>