initial commit

5 files changed, 1063 insertions, 0 deletions

diff --git a/files/fr/learn/server-side/premiers_pas/client-serveur/index.html b/files/fr/learn/server-side/premiers_pas/client-serveur/index.html
new file mode 100644
index 0000000000..f20b96e64d
--- /dev/null
+++ b/files/fr/learn/server-side/premiers_pas/client-serveur/index.html
@@ -0,0 +1,316 @@
+---
+title: La relation Client-Serveur
+slug: Learn/Server-side/Premiers_pas/Client-Serveur
+translation_of: Learn/Server-side/First_steps/Client-Server_overview
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{PreviousMenuNext("Learn/Server-side/First_steps/Introduction", "Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</div>
+
+<p class="summary">Maintenant que vous connaissez le but et le bénéfice de la programmation côté serveur, nous allons analyser en détails ce qui se passe quand un serveur reçoit une requête dynamique de la part d'un navigateur. Comme la plupart des sites gèrent le code côté serveur (requêtes et réponses) de la même manière, cela vous aidera à comprendre ce que vous devrez faire ensuite en écrivant votre propre code.</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">Prérequis :</th>
+   <td>Compréhension basique des notions informatiques et de ce qu'est un serveur web.</td>
+  </tr>
+  <tr>
+   <th scope="row">Objectif :</th>
+   <td>Comprendre les interactions client-serveur sur un site dynamique et particulièrement quelles opérations devront être effectuées par le code côté serveur.</td>
+  </tr>
+ </tbody>
+</table>
+
+<p>Il n'y a pas de code "réel" dans la suite de cette présentation parce que nous n'avons pas encore choisi un framework web à utiliser pour écrire notre code ! Ce tutoriel est quand même trés pertinent car les comportements décrits doivent être implémentés par votre code côté serveur, sans qu'il ait à se soucier (le serveur...)   de quel langage de programmation ou framework vous vous servez.</p>
+
+<h2 id="Serveurs_Web_et_HTTP_un_avant-goût">Serveurs Web et HTTP (un avant-goût)</h2>
+
+<p>Les navigateurs web communiquent avec les serveurs web avec le protocole <a href="/en-US/docs/Web/HTTP">HTTP</a><strong> : H</strong>yper<strong>T</strong>ext<strong>T</strong>ransfer <strong>P</strong>rotocol. Quand vous cliquez un lien sur une page, soumettez un formulaire ou lancez une recherche, le navigateur envoie une requête HTTP (<em>HTTP Request) </em>au serveur.</p>
+
+<p>Cette requête inclut :</p>
+
+<ul>
+ <li>Une URL identifiant la cible et la ressource (un fichier HTML, un point particulier de données sur le serveur ou un outil à lancer).</li>
+ <li>Une méthode qui définit l'action requise ( par exemple récupérer un fichier ou sauvegarder certaines données ou mises à jour). Les différentes méthodes/verbes et les actions associées sont listées ci-dessous :
+  <ul>
+   <li><code>GET</code>: Récupérer une ressource spécifique, par exemple un fichier html contenant des informations sur un produit ou une liste de produits.</li>
+   <li><code>POST</code>: Crée une ressource comme un nouvel article dans un wiki, ajouter un contact dans une base de données, enregistrer les données d'un formulaire d'inscription...</li>
+   <li>
+    <p><code>HEAD</code>: Récupérer les informations "metadata" d'une ressource spécifique sans le "body" comme ferait GET. Vous pouvez utiliser une requête HEAD pour, par exemple, la date de dernière mise à jour d'une ressource puis, utiliser GET (plus "coûteuse") seulement si la ressource a été changée.</p>
+   </li>
+   <li><code>PUT</code>: Met à jour une ressource existante ou en crée une si elle n'existe pas.</li>
+   <li><code>DELETE</code>: Supprime la ressource spécifiée.</li>
+   <li><code>TRACE</code>, <code>OPTIONS</code>, <code>CONNECT</code>, <code>PATCH</code>: ces verbes sont utilisés pour des tâches moins communes ou plus avancées nous ne les couvrirons donc pas ici.</li>
+  </ul>
+ </li>
+ <li>Des informations complémentaires peuvent être encodées avec la requête (des données de formulaire HTML par exemple). Ces informations peuvent être encodées comme :
+  <ul>
+   <li>Paramètres URL : les requêtes  <code>GET</code> encodent les données dans l'URL envoyée au serveur en ajoutant des paires nom/valeur en fin de celle-ci. Exemple : <code>http://mysite.com<strong>?name=Fred&amp;age=11</strong></code>.    Il y a toujours un point d'interrogation (<code>?</code>) séparant le début de l'URL des paramètres passés. Ainsi qu'un signe égal (<code>=</code>) séparant le nom de la valeur associée et une esperluette (<code>&amp;</code>) séparant chaque paire. Les paramètres URL ne sont pas sécurisés car ils peuvent être changés et soumis une deuxième fois par l'utilisateur. Pour cette raison, les requêtes URL paramètres/<code>GET</code> requests ne sont pas utilisées pour des requêtes mettant à jour des données sur un serveur.</li>
+  </ul>
+ </li>
+ <li><code>POST</code> data.  Les requêtes <code>POST</code> ajoutent de nouvelles ressources dont les données sont encodées dans le corps de la requête.</li>
+ <li>Cookies côté Client.  Contient les données de session du client, incluant les clés dont peut se servir le serveur pour déterminer le statut de login et les accés/permissions aux ressources.</li>
+</ul>
+
+<p>Les serveurs Web attendent une requête du client puis la traitent quand elle arrive. Il répond ensuite au navigateur avec un message HTTP Response. La réponse contient un statut <a href="/en-US/docs/Web/HTTP/Status">HTTP Response </a>indiquant si, oui ou non, la requête a abouti. (ex : "<code>200 OK</code>" pour un succés, "<code>404 Not Found</code>" si la ressource ne peut être trouvée, "<code>403 Forbidden</code>" si l'utilisateur n'est pas autorisé à voir la ressource etc. Le corps d'une réponse aboutie à une requête  <code>GET</code> contiendrait la ressource demandée.</p>
+
+<p>Quand une page HTML est retournée, elle est affichée par le navigateur. Le navigateur, nativement, pourra découvrir des liens vers d'autres ressources (ex : une page HTML intégre habituellement des pages JavaScript et CSS ), et enverra des requêtes séparées pour télécharger ces fichiers.</p>
+
+<p>Les sites web dynamiques ou statiques (voir sections suivantes) utilisent les mêmes protocoles/modèles de communication.</p>
+
+<h3 id="Exemple_de_requêteréponse_GET">Exemple de requête/réponse GET </h3>
+
+<p>Vous faites une simple requête <code>GET</code> en cliquant sur un lien ou en faisant une recherche sur un site (sur une page de moteur de recherche par exemple). Une requête HTTP envoyée lorsque vous effectuez une recherche sur MDN pour les termes : "La relation Client-Serveur" ressemblera beaucoup à ce qui suit mais ne sera pas identique car des parties du message dépendent des paramètres de votre navigateur.</p>
+
+<div class="note">
+<p>Le format des messsages HTTP est défini par un standard web  (<a href="http://www.rfc-editor.org/rfc/rfc7230.txt">RFC7230</a>). Vous n'avez pas besoin de connaître ce niveau de détails mais vous saurez au moins d'où vient tout ça !</p>
+</div>
+
+<h4 id="La_requête">La requête</h4>
+
+<p>Chaque ligne de la requête contient des informations sur celle-ci. La première partie est appelée l'en-tête ( <strong>header</strong>) et contient beaucoup de données utiles. De la même manière qu'un <a href="/en-US/docs/Learn/HTML/Introduction_to_HTML/The_head_metadata_in_HTML">HTML head</a> contient des informations utiles (pas le contenu réel qui lui, se trouve dans le corps (body) :</p>
+
+<pre>GET https://developer.mozilla.org/en-US/search?q=la+relation+Client+-+serveur&amp;topic=apps&amp;topic=html&amp;topic=css&amp;topic=js&amp;topic=api&amp;topic=webdev HTTP/1.1
+Host: developer.mozilla.org
+Connection: keep-alive
+Pragma: no-cache
+Cache-Control: no-cache
+Upgrade-Insecure-Requests: 1
+User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
+Referer: https://developer.mozilla.org/en-US/
+Accept-Encoding: gzip, deflate, sdch, br
+<code>Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7</code>
+Accept-Language: en-US,en;q=0.8,es;q=0.6
+Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=False; dwf_sg_task_completion=False; _gat=1; _ga=GA1.2.1688886003.1471911953; ffo=true
+</pre>
+
+<p>Les premières et secondes lignes contiennent la plupart des données déjà évoquées précédemment :</p>
+
+<ul>
+ <li>Le type de la requête (<code>GET</code>).</li>
+ <li>La cible de la  ressource URL (<code>/en-US/search</code>).</li>
+ <li>Les paramètres URL (<code>q=La%2relation%2Client%2-%2Bserveur&amp;topic=apps&amp;topic=html&amp;topic=css&amp;topic=js&amp;topic=api&amp;topic=webdev</code>).</li>
+ <li>Le site web cible/hôte (developer.mozilla.org).</li>
+ <li>La fin de la première ligne inclut aussi une petite chaîne identifiant la version spécifique du protocole (<code>HTTP/1.1</code>).</li>
+</ul>
+
+<p>La dernière ligne contient des données sur les cookies côté client — vous observerez que dans ce cas, le cookie a une id pour gérer la session :    (<code>Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; ...</code>).</p>
+
+<p>Les lignes restantes concernent le navigateur utilisé et les sortes de réponses qu'il peut accepter. Par exemple, vous pouvez voir ceci :</p>
+
+<ul>
+ <li>Mon navigateur (<code>User-Agent</code>) est Mozilla Firefox (<code>Mozilla/5.0</code>).</li>
+ <li>Il accepte les données compressées (<code>Accept-Encoding: gzip</code>).</li>
+ <li>Il accepte les familles de caractères suivantes :  (<code>Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7</code>) et pour les langages : (<code>Accept-Language: de,en;q=0.7,en-us;q=0.3</code>).</li>
+ <li>La ligne <code>Referer</code> indique l'adresse de la page web qui contenait le lien vers cette ressource (Par ex. l'origine de la requête : <code>https://developer.mozilla.org/en-US/</code>).</li>
+</ul>
+
+<p>Les requêtes HTTP peuvent aussi avoir un corps mais dans ce cas précis, il est vide.</p>
+
+<h4 id="La_réponse">La réponse</h4>
+
+<p>La première partie de la réponse à cette requête est détaillée ci-dessous. L'en-tête contient les données suivantes :</p>
+
+<ul>
+ <li>La première ligne embarque le code <code>200 OK</code>, qui nous dit que la requête a abouti.</li>
+ <li>Nous pouvons voir que la réponse est formatée en  <code>text/html</code> (<code>Content-Type</code>).</li>
+ <li>On remarque qu'elle utilise l'ensemble des caractères UTF-8 (<code>Content-Type: text/html; charset=utf-8</code>).</li>
+ <li>L'en-tête indique aussi la taille (<code>Content-Length: 41823</code>).</li>
+</ul>
+
+<p>À la fin du message nous avons le contenu du corps  — lequel contient le "vrai" HTML demandé par la requête.</p>
+
+<pre class="brush: html">HTTP/1.1 200 OK
+Server: Apache
+X-Backend-Server: developer1.webapp.scl3.mozilla.com
+Vary: Accept,Cookie, Accept-Encoding
+Content-Type: text/html; charset=utf-8
+Date: Wed, 07 Sep 2016 00:11:31 GMT
+Keep-Alive: timeout=5, max=999
+Connection: Keep-Alive
+X-Frame-Options: DENY
+Allow: GET
+X-Cache-Info: caching
+Content-Length: 41823
+
+
+
+&lt;!DOCTYPE html&gt;
+&lt;html lang="en-US" dir="ltr" class="redesign no-js"  data-ffo-opensanslight=false data-ffo-opensans=false &gt;
+&lt;head prefix="og: http://ogp.me/ns#"&gt;
+  &lt;meta charset="utf-8"&gt;
+  &lt;meta http-equiv="X-UA-Compatible" content="IE=Edge"&gt;
+  &lt;script&gt;(function(d) { d.className = d.className.replace(/\bno-js/, ''); })(document.documentElement);&lt;/script&gt;
+  ...
+</pre>
+
+<p>Le reste de l'en-tête de la réponse contient des informations sur la réponse elle-même (quand elle a été générée), sur le serveur et comment le navigateur doit gérer la page ( <code>X-Frame-Options: DENY</code> cette ligne dit au navigateur de ne pas autoriser cette page a être intégrée dans une  {{htmlelement("iframe")}} dans un autre site).</p>
+
+<h3 id="Exemple_de_requêteréponse_POST">Exemple de requête/réponse POST</h3>
+
+<p>Un <code>POST</code> HTTP est effectué lorsque vous soumettez un formulaire contenant des données à sauvegarder sur le serveur.</p>
+
+<h4 id="La_requête_2">La requête</h4>
+
+<p>Le texte ci-dessous montre une requête HTTP faite quand un utlisateur soumet un nouveaux profil sur ce site. Le format de la requête est presque le même que celui de la requête <code>GET</code> vue précédemment, bien que la première ligne identifie cette requête comme un <code>POST</code>. </p>
+
+<pre class="brush: html">POST https://developer.mozilla.org/en-US/profiles/hamishwillee/edit HTTP/1.1
+Host: developer.mozilla.org
+Connection: keep-alive
+Content-Length: 432
+Pragma: no-cache
+Cache-Control: no-cache
+Origin: https://developer.mozilla.org
+Upgrade-Insecure-Requests: 1
+User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
+Content-Type: application/x-www-form-urlencoded
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
+Referer: https://developer.mozilla.org/en-US/profiles/hamishwillee/edit
+Accept-Encoding: gzip, deflate, br
+Accept-Language: en-US,en;q=0.8,es;q=0.6
+Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; _gat=1; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=False; dwf_sg_task_completion=False; _ga=GA1.2.1688886003.1471911953; ffo=true
+
+csrfmiddlewaretoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT&amp;user-username=hamishwillee&amp;user-fullname=Hamish+Willee&amp;user-title=&amp;user-organization=&amp;user-location=Australia&amp;user-locale=en-US&amp;user-timezone=Australia%2FMelbourne&amp;user-irc_nickname=&amp;user-interests=&amp;user-expertise=&amp;user-twitter_url=&amp;user-stackoverflow_url=&amp;user-linkedin_url=&amp;user-mozillians_url=&amp;user-facebook_url=</pre>
+
+<p>La principale différence est que l'URL ne comporte pas de paramètres.  Comme vous voyez, l'information du formulaire est encodée dans le corps de la requête (par exemple : le nom complet du nouvel utilisateur est paramétré avec  <code>&amp;user-fullname=Hamish+Willee</code>).</p>
+
+<h4 id="La_réponse_2">La réponse</h4>
+
+<p>La réponse à la requête est expliquée dessous. Le statut "<code>302 Found</code>" dit au navigateur que le post a abouti et qu'il peut délivrer une deuxième requête HTTP pour charger la page spécifiée dans le champ  <code>Location</code>. L'information est donc en cela similaire à une réponse de requête <code>GET</code>.</p>
+
+<pre class="brush: html">HTTP/1.1 302 FOUND
+Server: Apache
+X-Backend-Server: developer3.webapp.scl3.mozilla.com
+Vary: Cookie
+Vary: Accept-Encoding
+Content-Type: text/html; charset=utf-8
+Date: Wed, 07 Sep 2016 00:38:13 GMT
+Location: https://developer.mozilla.org/en-US/profiles/hamishwillee
+Keep-Alive: timeout=5, max=1000
+Connection: Keep-Alive
+X-Frame-Options: DENY
+X-Cache-Info: not cacheable; request wasn't a GET or HEAD
+Content-Length: 0
+</pre>
+
+<div class="note">
+<p><strong>Note </strong>: Les requêtes et réponses montrées dans ces exemples ont été capturées avec l'application <a href="https://www.telerik.com/download/fiddler">Fiddler</a> , mais vous pouvez avoir des informations similaires en utilisant des "renifleurs" web  (e.g. <a href="http://websniffer.cc/">Websniffer</a>, <a href="https://www.wireshark.org/">Wireshark</a>) ou des extensions de navigateur comme  <a href="https://addons.mozilla.org/en-US/firefox/addon/httpfox/">HttpFox</a>. Vous pouvez essayer seul. Utilisez tous les outils recommandés, naviguez sur des sites et  éditez des profils de données pour explorer les différentes requêtes et réponses. La plupart des navigateurs modernes ont aussi des outils qui gérent les requêtes réseau, par exemple le <a href="/en-US/docs/Tools/Network_Monitor">Network Monitor</a> dans Firefox).</p>
+</div>
+
+<h2 id="Les_sites_statiques">Les sites statiques</h2>
+
+<p>Un site statique renvoie le même contenu codé en dur depuis le serveur quelle que soit la ressource demandée. Si vous avez une page concernant un produit à l'adresse  <code>/static/myproduct1.html</code>, cette même page sera retournée à chaque utilisateur. Si vous ajoutez un nouveau produit, vous devez ajouter une nouvelle page (par ex : <code>myproduct2.html</code>) et ainsi de suite. Cela peut être vraiment inefficace — Comment faire quand vous avez des milliers de pages "produit" à faire ? Vous allez répéter beaucoup de code identique dans chaque page (le modèle de base de la page, sa structure, etc.) et si vous voulez changer quoique ce soit dans la structure de la page — comme une section "produits dérivés" par exemple — alors, il faudra changer chaque page individuellement..</p>
+
+<div class="note">
+<p><strong>Note </strong>: Les sites statiques sont trés efficace quand vous avez un petit nombre de pages et que vous voulez envoyer le même contenu à chaque utilisateur. De toutes façons, ils peuvent avoir un coût certain de maintenance au fur et à mesure de l'augmentation du nombre de pages.</p>
+</div>
+
+<p>Voyons comment tout cela marche en révisant un diagramme d'architecture de site statique vu dans l'article précédent.</p>
+
+<p><img alt="A simplified diagram of a static web server." src="https://mdn.mozillademos.org/files/13841/Basic%20Static%20App%20Server.png"></p>
+
+<p>Quand un utilisateur veut naviguer jusqu'à une page, le navigateur envoie une requête HTTP <code>GET</code> spécifiant l'URL de sa page HTML. Le serveur retourne le document demandé depuis son système de fichiers et retourne une réponse  HTTP contenant le document et un  <a href="/en-US/docs/Web/HTTP/Status">HTTP Response status code</a> ( statut codé de la réponse HTTP) qui est  "<code>200 OK</code>" (indiquant le succés de l'opération). Le serveur peut retourner un statut différent, par exemple "<code>404 Not Found</code>"  si le fichier est absent sur le serveur , ou bien "<code>301 Moved Permanently</code>" si le fichier existe mais a été déplacé vers une nouvelle localisation.</p>
+
+<p>Le serveur d'un site statique n'aura à faire face qu'à des requêtes  GET vu qu'il ne stocke aucune donnée modifiable. Il ne change pas non plus ses réponses basées sur les données des requêtes HTTP (c'est à dire les paramètres URL ou les cookies). </p>
+
+<p>Comprendre comment fonctionnent les sites statiques est sans aucun doute trés utile à l'apprentissage de la programmation côté serveur car les sites dynamiques gèrent les requêtes pour les fichiers statiques (CSS, JavaScript, images statiques , etc.) exactement de la même manière.</p>
+
+<h2 id="Les_sites_dynamiques">Les sites dynamiques</h2>
+
+<p>Un site dynamique peut générer et retourner du contenu basé sur une requête URL spécifique et les données (plutôt que de toujours renvoyer le même fichier codé en dur à une URL particulière).  Toujours avec l'exemple d'un site "produits", le serveur stockera les données du produit dans une base de données plutôt que dans un fichier HTML individuel. Quand il reçoit une requête HTTP <code>GET</code> pour un produit, le serveur détermine l'ID du produit, va chercher les données dans la base de données puis construit la page HTML pour la réponse en intégrant les données dans un gabarit (template) HTML. C'est un avantage indéniable sur un site statique :</p>
+
+<p>Utiliser une base de données permet à l'information "produit" d'être stockée efficacement, en étant modifiable, extensible et bien indexée.</p>
+
+<p>Employer des gabarits HTML facilite la façon de changer la structure HTML parce que c'est fait en un seul endroit, dans un seul gabarit (template) et non pas sur potentiellement des milliers de pages statiques.</p>
+
+<h3 id="Anatomie_dun_requête_dynamique">Anatomie d'un requête dynamique</h3>
+
+<p>Cette section présente une vue d'ensemble du cycle dynamique HTTP de requête/réponse, construit avec ce que nous avons vu précédemment avec de plus amples détails. Toujours dans l'optique de "faire les choses en réel" nous utiliserons le contexte du site d'une équipe de sport où l'entraîneur peut sélectionner le nom de l'équipe et le nombre de joueurs dans un formulaire HTML et avoir en retour une suggestion "Meilleure composition" pour le prochain match.</p>
+
+<p><span style='color: rgba(0, 0, 0, 0.87); font-family: "Roboto",arial,sans-serif; font-size: 18px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; white-space: pre-wrap;' title="">Le diagramme ci-dessous montre les principaux éléments du site Web "entraîneur d'équipe", ainsi que des étiquettes numérotées pour la séquence des opérations lorsque l'entraîneur accède à la liste "meilleure équipe".</span><span style='background-color: #f5f5f5; color: rgba(0, 0, 0, 0.87); display: inline !important; float: none; font-family: "Roboto",arial,sans-serif; font-size: 18px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; line-height: 28px; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; white-space: pre-wrap;'> </span><span style='color: rgba(0, 0, 0, 0.87); font-family: "Roboto",arial,sans-serif; font-size: 18px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; white-space: pre-wrap;' title="">Les parties du site qui le rendent dynamique sont l’application Web (c’est ainsi que nous nous référerons au code côté serveur qui traite les requêtes HTTP et renvoie les réponses HTTP), la base de données, qui contient des informations sur les joueurs, les équipes, les entraîneurs et leurs partenaires.</span><span style='background-color: #f5f5f5; color: rgba(0, 0, 0, 0.87); display: inline !important; float: none; font-family: "Roboto",arial,sans-serif; font-size: 18px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; line-height: 28px; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; white-space: pre-wrap;'> </span><span style='color: rgba(0, 0, 0, 0.87); font-family: "Roboto",arial,sans-serif; font-size: 18px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; white-space: pre-wrap;' title="">relations, et les modèles HTML.</span></p>
+
+<p><img alt="This is a diagram of a simple web server with step numbers for each of step of the client-server interaction." src="https://mdn.mozillademos.org/files/13829/Web%20Application%20with%20HTML%20and%20Steps.png" style="height: 584px; width: 1226px;"></p>
+
+<p><font color="#001000" face="Arial,x-locale-body,sans-serif">Une fois que l’entraîneur a soumis le formulaire avec le nom de l’équipe et le nombre de joueurs, la séquence des opérations est la suivante:</font></p>
+
+<ol>
+ <li>Le navigateur Web crée une requête HTTP GET au serveur en utilisant l’URL de base de la ressource (/ best) et en codant l’équipe et le numéro du joueur sous forme de paramètres d’URL (par exemple / best? team=my_team_name&amp;show = 11) ou dans le cadre de l’URL modèle (par exemple / best / my_team_name / 11 /). Une requête GET est utilisée car la requête extrait uniquement des données (sans les modifier).</li>
+ <li>Le serveur Web détecte que la demande est "dynamique" et la transmet à l'application Web pour traitement (le serveur Web détermine comment gérer différentes URL en fonction des règles de correspondance de modèle définies dans sa configuration).</li>
+ <li>L'application Web identifie l'objectif de la demande d'obtenir la "meilleure liste d'équipes" en fonction de l'URL (/ best /) et recherche le nom d'équipe requis et le nombre de joueurs à partir de l'URL. L'application Web obtient alors les informations requises de la base de données (en utilisant des paramètres "internes" supplémentaires pour définir quels joueurs sont les "meilleurs", et éventuellement en obtenant également l'identité de l'entraîneur connecté à partir d'un cookie côté client).</li>
+ <li>L'application Web crée dynamiquement une page HTML en plaçant les données (de la base de données) dans des espaces réservés dans un modèle HTML.</li>
+ <li>L'application Web renvoie le code HTML généré au navigateur Web (via le serveur Web), ainsi qu'un code d'état HTTP de 200 ("success"). Si quoi que ce soit empêche le code HTML d'être renvoyé, l'application Web renvoie un autre code, par exemple "404" pour indiquer que l'équipe n'existe pas.</li>
+ <li><span style='background-color: #f5f5f5; color: rgba(0, 0, 0, 0.87); display: inline !important; float: none; font-family: "Roboto",arial,sans-serif; font-size: 18px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; white-space: pre-wrap;'>Le navigateur Web commence alors à traiter le code HTML renvoyé, en envoyant des demandes distinctes pour obtenir tous les fichiers CSS ou JavaScript qu’il référence (voir étape 7).</span></li>
+ <li><span style='background-color: #f5f5f5; color: rgba(0, 0, 0, 0.87); display: inline !important; float: none; font-family: "Roboto",arial,sans-serif; font-size: 18px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; white-space: pre-wrap;'>Le serveur Web charge les fichiers statiques à partir du système de fichiers et les renvoie directement au navigateur (là encore, le traitement correct des fichiers est basé sur les règles de configuration et la correspondance des types d'URL).</span></li>
+</ol>
+
+<p><span style='background-color: #f5f5f5; color: rgba(0, 0, 0, 0.87); display: inline !important; float: none; font-family: "Roboto",arial,sans-serif; font-size: 18px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; white-space: pre-wrap;'>Une opération de mise à jour d'un enregistrement dans la base de données serait gérée de la même manière, sauf que, comme toute mise à jour de base de données, la demande HTTP du navigateur devrait être codée en tant que demande POST.</span></p>
+
+<h3 id="que_faire_dautre">que faire d'autre?</h3>
+
+<p>Le travail d'une application Web consiste à recevoir des requêtes HTTP et à renvoyer des réponses HTTP. Bien que l'interaction avec une base de données pour obtenir ou mettre à jour des informations soit une tâche très courante, le code peut faire d'autres choses en même temps, ou ne pas interagir du tout avec une base de données.Un bon exemple de tâche supplémentaire qu'une application Web pourrait exécuter serait l'envoi d'un courrier électronique aux utilisateurs pour confirmer leur inscription sur le site. Le site peut également effectuer une journalisation ou d’autres opérations.</p>
+
+<h3 id="Renvoyer_autre_chose_que_du_HTML">Renvoyer autre chose que  du HTML</h3>
+
+<p>Le code de site Web côté serveur ne doit pas nécessairement renvoyer des extraits / fichiers HTML dans la réponse. Au lieu de cela, il peut créer et renvoyer de manière dynamique d'autres types de fichiers (texte, PDF, CSV, etc.) ou même des données (JSON, XML, etc.).L'idée de renvoyer des données à un navigateur Web afin qu'il puisse mettre à jour de manière dynamique son propre contenu ({{glossary ("AJAX")}}) existe depuis un certain temps. Plus récemment, les "applications à page unique" sont devenues populaires, le site Web entier étant écrit avec un seul fichier HTML mis à jour de manière dynamique en cas de besoin. Les sites Web créés à l'aide de ce style d'application génèrent des coûts de calcul considérables entre le serveur et le navigateur Web, ce qui peut donner l'impression que les sites Web se comportent beaucoup plus comme des applications natives (très réactives, etc.).</p>
+
+<h2 id="Les_frameworks_Web_simplifient_la_programmation_Web_côté_serveur">Les frameworks Web simplifient la programmation Web côté serveur</h2>
+
+<p>Les infrastructures Web côté serveur facilitent beaucoup la rédaction de code permettant de gérer les opérations décrites ci-dessus.L’une des opérations les plus importantes qu’ils effectuent consiste à fournir des mécanismes simples pour mapper les URL de différentes ressources / pages à des fonctions de gestionnaire spécifiques. Cela facilite la séparation du code associé à chaque type de ressource. Cela présente également des avantages en termes de maintenance, car vous pouvez modifier l'URL utilisée pour fournir une fonctionnalité particulière à un endroit, sans avoir à changer la fonction de gestionnaire.Par exemple, considérons le code Django (Python) suivant qui mappe deux modèles d'URL à deux fonctions d'affichage. Le premier modèle garantit qu'une requête HTTP avec une URL de ressource / best sera transmise à une fonction nommée index () dans le module views. Une demande qui a pour motif "/ best / junior" sera plutôt transmise à la fonction d'affichage junior ().</p>
+
+<pre class="brush: python"># file: best/urls.py
+#
+
+from django.conf.urls import url
+
+from . import views
+
+urlpatterns = [
+    # example: /best/
+    url(r'^$', views.index),
+    # example: /best/junior/
+    url(r'^junior/$', views.junior),
+]</pre>
+
+<div class="note">
+<p><strong>Note</strong>: Les premiers paramètres des fonctions url () peuvent paraître un peu bizarres (par exemple, r '^ junior / $') car ils utilisent une technique de correspondance de modèle appelée "expressions régulières" (RegEx ou RE). Vous n'avez pas besoin de savoir comment fonctionnent les expressions régulières à ce stade, car elles nous permettent également de faire correspondre les modèles de l'URL (plutôt que les valeurs codées en dur ci-dessus) et de les utiliser comme paramètres dans nos fonctions d'affichage. À titre d'exemple, un RegEx très simple pourrait dire "faire correspondre une seule lettre majuscule, suivie de 4 à 7 lettres minuscules".</p>
+</div>
+
+<div>L'infrastructure Web permet également à une fonction d'affichage d'extraire facilement des informations de la base de données. La structure de nos données est définie dans des modèles, qui sont des classes Python qui définissent les champs à stocker dans la base de données sous-jacente. Si nous avons un modèle nommé Team avec un champ "team_type", nous pouvons utiliser une syntaxe de requête simple pour récupérer toutes les équipes ayant un type particulier.</div>
+
+<div>L’exemple ci-dessous donne la liste de toutes les équipes ayant le type d’équipe exact (sensible à la casse) de "junior" - notez le format: nom du champ (team_type) suivi du  double underscore, puis du type de match à utiliser (ici nous utilisons: exact). ). Il existe de nombreux autres types de match et nous pouvons les enchaîner. Nous pouvons également contrôler l'ordre et le nombre de résultats retournés.</div>
+
+<div></div>
+
+<pre class="brush: python">#best/views.py
+
+from django.shortcuts import render
+
+from .models import Team
+
+
+def junior(request):
+    list_teams = Team.objects.filter(team_type__exact="junior")
+    context = {'list': list_teams}
+    return render(request, 'best/index.html', context)
+</pre>
+
+<p>Une fois que la fonction junior () a obtenu la liste des équipes juniors, elle appelle la fonction render () en transmettant la requête HttpRequest d'origine, un modèle HTML et un objet "context" définissant les informations à inclure dans le modèle. La fonction render () est une fonction pratique qui génère du HTML à l'aide d'un context et d'un template HTML, puis le renvoie dans un objet HttpResponse.De toute évidence, les frameworks Web peuvent vous aider dans de nombreuses autres tâches. Nous discutons beaucoup plus d'avantages et de choix de frameworks Web populaires dans le prochain article.</p>
+
+<h2 id="Summary">Summary</h2>
+
+<p>À ce stade, vous devez avoir une bonne vue d'ensemble des opérations que le code côté serveur doit effectuer et connaître certaines des manières dont une infrastructure Web côté serveur peut faciliter cela.</p>
+
+<p>Dans un module suivant, nous vous aiderons à choisir le meilleur framework Web pour votre premier site.</p>
+
+<p><span style="background-color: #ffffff; color: #333333; display: inline !important; float: none; font-family: Arial,x-locale-body,sans-serif; font-size: 16px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal;">{{PreviousMenuNext("Learn/Server-side/First_steps/Introduction", "Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</span></p>
+
+<h2 id="In_this_module">In this module</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Learn/Server-side/First_steps/Introduction">Introduction to the server side</a></li>
+ <li><a href="/en-US/docs/Learn/Server-side/First_steps/Client-Server_overview">Client-Server overview</a></li>
+ <li><a href="/en-US/docs/Learn/Server-side/First_steps/Web_frameworks">Server-side web frameworks</a></li>
+ <li><a href="/en-US/docs/Learn/Server-side/First_steps/Website_security">Website security</a></li>
+</ul>
diff --git a/files/fr/learn/server-side/premiers_pas/index.html b/files/fr/learn/server-side/premiers_pas/index.html
new file mode 100644
index 0000000000..a8caf88e4d
--- /dev/null
+++ b/files/fr/learn/server-side/premiers_pas/index.html
@@ -0,0 +1,45 @@
+---
+title: Premiers pas dans la programmation d'un site côté serveur
+slug: Learn/Server-side/Premiers_pas
+tags:
+  - Débutant
+  - Encodage
+  - Guide
+  - Intro
+  - Programmation côté serveur
+translation_of: Learn/Server-side/First_steps
+---
+<div>{{LearnSidebar}}</div>
+
+<p>Dans ce module nous répondrons à quelques questions fondamentales sur la programmation côté serveur — "Qu'est-ce que c'est ?", "En quoi diffère-t-elle de la programmation côté client ?" et "Pourquoi est-ce si utile ?". Nous fournirons ensuite un aperçu de certaines infrastructures d'applications web (aussi appelé frameworks) côté serveurs parmi les plus populaires, ainsi que des conseils pour sélectionner la plus approprié pour créer votre premier site. Enfin un article vous présentera les questions de sécurité pour un serveur web.   </p>
+
+<h2 id="Prérequis">Prérequis</h2>
+
+<p>Pour suivre ce module, aucune connaissance en programmation web côté serveur ou tout autre type de programmation n'est nécessaire.</p>
+
+<p>Vous aurez besoin de comprendre "comment fonctionne le web". Nous vous recommandons de lire d'abord les sujets suivants :</p>
+
+<ul>
+ <li><a href="https://developer.mozilla.org/fr/Apprendre/Qu_est-ce_qu_un_serveur_web">Qu'est-ce qu'un serveur web</a></li>
+ <li><a href="https://developer.mozilla.org/fr/Apprendre/Quels_logiciels_sont_n%C3%A9cessaires_pour_construire_un_site_web">De quel logiciel ai-je besoin pour créer un site web ?</a></li>
+ <li><a href="https://developer.mozilla.org/fr/Apprendre/Transf%C3%A9rer_des_fichiers_vers_un_serveur_web">Comment transférer des fichiers sur un serveur web ?</a></li>
+</ul>
+
+<p>Avec cette compréhension de base, vous serez prêts à parcourir les modules de cette section.</p>
+
+<h2 id="Guides">Guides</h2>
+
+<dl>
+ <dt><a href="https://developer.mozilla.org/fr/docs/Learn/Server-side/Premiers_pas/Introduction">Introduction au côté serveur</a></dt>
+ <dd>Bienvenue au cours de programmation débutant de MDN ! Dans ce premier article, nous examinerons la programmation côté serveur, répondant à des questions comme «En quoi consiste-t-elle ?», «En quoi diffère-t-elle de la programmation côté client ?» et «Pourquoi est-ce si utile ?». Après avoir lu cet article, vous comprendrez comment la programmation côté serveur donne aux sites web toute leur puissance.</dd>
+ <dt><a href="/fr/docs/Learn/Server-side/Premiers_pas/Client-Serveur">Présentation client-serveur</a></dt>
+ <dd>Maintenant que vous connaissez le but et les avantages potentiels de la programmation côté serveur, nous allons examiner en détail ce qui se passe lorsqu'un serveur reçoit une "requête dynamique" d'un navigateur. Comme la plupart des codes côté serveur traitent les demandes et les réponses de la même manière, cela vous aidera à comprendre ce que vous devez faire lorsque vous écrivez votre propre code.</dd>
+ <dt><a href="/fr/docs/Learn/Server-side/Premiers_pas/Web_frameworks">Frameworks web côté serveur</a></dt>
+ <dd>Le dernier article vous a montré ce qu'une application web côté serveur doit faire pour répondre aux demandes d'un navigateur web. Nous allons maintenant vous montrer comment les frameworks web peuvent simplifier ces tâches ; nous vous aiderons à choisir le bon framework pour coder votre première application web côté serveur.</dd>
+ <dt><a href="https://developer.mozilla.org/fr/docs/Learn/Server-side/First_steps/Website_security">Sécurité de votre site web</a></dt>
+ <dd>La sécurité de votre site web requiert une vigilance dans tous les aspects de sa conception et de son utilisation. Cet article d'introduction ne fera pas de vous un gourou de la sécurité des sites web, mais il vous aidera à comprendre les premières mesures importantes à prendre pour mettre votre application web à l'abri des menaces les plus courantes.</dd>
+</dl>
+
+<h2 id="Évaluations">Évaluations</h2>
+
+<p>Ce module "aperçu" n'a aucune évaluation car nous ne vous avons pas encore montré de code. Nous espérons à ce stade que vous avez une bonne compréhension des types de fonctionnalités que vous pouvez fournir en utilisant la programmation côté serveur et que vous avez pris une décision quant à l'infrastructure web côté serveur que vous utiliserez pour créer votre premier site web.</p>
diff --git a/files/fr/learn/server-side/premiers_pas/introduction/index.html b/files/fr/learn/server-side/premiers_pas/introduction/index.html
new file mode 100644
index 0000000000..d61d1d18c4
--- /dev/null
+++ b/files/fr/learn/server-side/premiers_pas/introduction/index.html
@@ -0,0 +1,234 @@
+---
+title: Présentation du côté serveur
+slug: Learn/Server-side/Premiers_pas/Introduction
+tags:
+  - Apprendre
+  - Débutant
+  - Guide
+  - Intro
+  - Programmation côté serveur
+  - Serveur
+translation_of: Learn/Server-side/First_steps/Introduction
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{NextMenu("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps")}}</div>
+
+<p class="summary"><span class="seoSummary">Bienvenue au cours pour débutant de MDN sur la programmation côté serveur. Dans ce premier article, nous allons regarder la programmation côté serveur sans rentrer dans les détails techniques, en répondant aux questions telles que "qu'est-ce que c'est?", "quelle est la différence avec la programmation côté client?", et "pourquoi est-ce utile?". Après avoir lu cet article vous comprendrez commment la programmation côté serveur donne toute leur puissance aux sites web.</span></p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">Prérequis:</th>
+   <td>Connaissances de base en informatique. Une compréhension de base de ce qu'est un serveur web.</td>
+  </tr>
+  <tr>
+   <th scope="row">Objectif:</th>
+   <td>Se familiariser avec la programmation côté serveur, ce qu'elle peut faire, et en quoi elle diffère de la programmation côté client.</td>
+  </tr>
+ </tbody>
+</table>
+
+<p>La plupart des sites web à grande échelle utilisent du code côté serveur pour afficher dynamiquement différentes données lorsque nécessaire ; ces données sont généralement extraites d'une base de données stockée sur un serveur et envoyées au client pour être affichées avec du code (HTML et/ou JavaScript). </p>
+
+<p>L'avantage le plus significatif du code côté serveur est sans doute qu'il permet d'adapter le contenu du site web à chaque utilisateur. Les sites dynamiques peuvent mettre en évidence du contenu pertinent en fonction des préférences et des habitudes de l'utilisateur. Il peut également faciliter l'utililsation des sites web en stockant des données, des informations personnelles — par exemple donner la possibilité d'enregistrer une carte de crédit pour les achats suivants.</p>
+
+<p>Cela peut même permettre une interaction avec les utilisateurs du site, en envoyant des notifications et mises à jour par email ou via d'autres canaux. Toutes ces capacités rendent possible un engagement plus important avec l'utilisateur.</p>
+
+<p>Dans le monde moderne du développement web, apprendre le développement côté serveur est fortement recommandé.</p>
+
+<h2 id="Quest-ce_que_la_programmation_côté_serveur">Qu'est-ce que la programmation côté serveur?</h2>
+
+<p>Les navigateurs web communiquent avec les <a href="/fr/Apprendre/Qu_est-ce_qu_un_serveur_web">serveurs web</a> en utilisant le protocole {{glossary("HTTP")}} (<strong>H</strong>yper<strong>T</strong>ext <strong>T</strong>ransfer <strong>P</strong>rotocol). Quand vous cliquez sur un lien dans une page web, envoyez un formulaire, ou encore lancez une recherche, une <strong>requête HTTP</strong> est envoyée du navigateur au serveur cible.</p>
+
+<p>Une requête inclut <em>une URL</em> pour identifier la ressource demandée, <em>une méthode</em> pour définir l'action désirée (comme GET pour obtenir, DELETE pour supprimer ou POST pour publier) et peut également inclure des informations supplémentaires encodées dans <em>les paramètres</em> de l'URL (des paires clés/valeurs envoyées via une chaîne de recherche — <a href="https://en.wikipedia.org/wiki/Query_string">query string</a> en anglais), les données POST (données envoyées par la <a href="/fr/docs/Web/HTTP/M%C3%A9thode/POST">méthode HTTP POST</a>), ou les {{glossary("Cookie", "cookies associés")}}.</p>
+
+<p>Les serveurs web attendent des requêtes du client, les traitent quand elles arrivent, et répondent au navigateur web avec une <strong>réponse HTTP</strong>. La réponse contient <em>un statut</em> qui indique si la requête a pu être traitée avec succès ou non (exemple "HTTP/1.1 200 OK" pour indiquer le succès). </p>
+
+<p>Le corps de la réponse, si la requête réussit, contient alors la ressource demandée (comme une page HTML, une image, etc...), que le navigateur web peut alors afficher.</p>
+
+<h3 id="Sites_statiques">Sites statiques</h3>
+
+<p>Le diagramme ci-dessous montre l'architecture d'un serveur web basique pour un <em>site statique</em> (un site statique est un site qui renvoie du contenu codé en dur, c'est à dire le contenu d'un fichier, quand une ressource donnée est demandée). Quand un utilisateur veut naviguer sur une page, le navigateur envoie une requête HTTP "GET" spécifiant son URL.</p>
+
+<p>Le serveur récupère le document demandé du système de fichiers et retourne une réponse HTTP contenant le document et le <a href="/fr/docs/Web/HTTP/Status#R%C3%A9ponses_de_succ%C3%A8s">statut de la réponse</a> (habituellement, 200 OK). Si le fichier ne peut pas être recupéré pour une raison x ou y, le statut d'erreur est retourné (voir <a href="/fr/docs/Web/HTTP/Status#R%C3%A9ponses_d'erreur_c%C3%B4t%C3%A9_client">réponses d'erreur client</a> et <a href="/fr/docs/Web/HTTP/Status#R%C3%A9ponses_d'erreur_c%C3%B4t%C3%A9_serveur">réponse d'erreur serveur</a>).</p>
+
+<p><img alt="A simplified diagram of a static web server." src="https://mdn.mozillademos.org/files/13841/Basic%20Static%20App%20Server.png" style="height: 223px; width: 800px;"></p>
+
+<h3 id="Sites_dynamiques">Sites dynamiques</h3>
+
+<p>Un site web dynamique, quant à lui, est un site dont une partie des réponses sont générées <em>dynamiquement</em>, à la demande. Sur les sites dynamiques, les pages HTML sont normalement crées en insérant des données d'une base de données dans des espaces réservés à l'intérieur de templates HTML (c'est une manière beaucoup plus efficace que des fichiers statiques pour stocker de grandes quantités de contenu). </p>
+
+<p>Un site dynamique peut retourner des données différentes pour une URL, en se basant sur les informations fournies par l'utilisateur ou les préférences stockées et peut effectuer des opérations avant de retourner la réponse.</p>
+
+<p>La plupart du code pour maintenir un site web dynamique doit s'exécuter sur le serveur. La création de ce code est ce qu'on appelle la "<strong>programmation côté serveur</strong>" (ou parfois "<strong>codage back-end</strong>").</p>
+
+<p>Le diagramme ci-dessous montre une architecture simple pour un <em>site web dynamique</em>. Comme dans le diagramme précédent, les navigateurs envoient des requêtes HTTP au serveur, qui les traite et retourne les réponses HTTP appropriées.</p>
+
+<p>Les requêtes pour les ressources <em>statiques</em> sont toujours gérées de la même manière que pour les sites statiques (les ressources statiques sont tous les fichiers qui ne changent pas —typiquement : CSS, JavaScript, Images, fichiers PDF etc).</p>
+
+<p><img alt="A simplified diagram of a web server that uses server-side programming to get information from a database and construct HTML from templates. This is the same diagram as is in the Client-Server overview." src="https://mdn.mozillademos.org/files/13839/Web%20Application%20with%20HTML%20and%20Steps.png"></p>
+
+<p>Les requêtes pour les ressources <em>dynamiques</em>, elles, sont transmises (2) au code côté serveur (indiqué dans le diagramme comme <em>Web Application</em>). Le serveur interprète la requête, lit les informations correspondantes dans la base de données (3), combine les données récupérées avec les templates HTML (4), et renvoie la réponse avec le HTML généré (5,6). </p>
+
+<div>
+<h2 id="La_programmation_côté_serveur_cest_pareil_que_côté_client">La programmation côté serveur c'est pareil que côté client?</h2>
+</div>
+
+<p>Voyons maintenant le code impliqué dans la programmation côté serveur et côté client. Dans chaque cas, le code est significativement différent :</p>
+
+<ul>
+ <li>Ils ont des objectifs et des préoccupations différents.</li>
+ <li>Ils n'utilisent généralement pas les mêmes langages de programmation (exception faite de JavaScript, qui peut être utilisé côté serveur et côté client).</li>
+ <li>Ils s'exécutent dans des environnements différents du système d'exploitation.</li>
+</ul>
+
+<p>Le code exécuté par le navigateur est connu sous le nom de <strong>code côté client</strong> (ou <strong>front-end</strong>) et se préoccupe principalement de l'apparence et du comportement des pages web affichées. Cela inclut sélectionner et styliser les composants de l'interface utilisateur, créer la mise en page, la navigation, valider les formulaires, etc. D'un autre côté, la programmation côté serveur implique de définir le contenu retourné au navigateur en réponse aux requêtes. Le code côté serveur gère des tâches telles que la validation des données envoyées, l'utilisation des bases de données pour stocker et récupérer des données et l'envoi de données générées au client tel qu'attendu.</p>
+
+<p>Le code client est écrit en <a href="/fr/Apprendre/HTML">HTML</a>, <a href="/fr/Apprendre/CSS">CSS</a>, et <a href="/fr/Apprendre/JavaScript">JavaScript</a> — il est exécuté dans un navigateur web et a peu ou pas accès au système d'exploitation de l'utilisateur (inclut un accès limité au système de fichiers).</p>
+
+<p>Les développeurs web ne peuvent pas contrôler quel navigateur est utilisé par l'utilisateur pour voir le site web  — or les navigateurs fournissent des niveaux de compatibilité inconsistants quant aux fonctionnalités du code côté client, et une partie du challenge de la programmation côté client consiste à gérer les différences de support des navigateurs.</p>
+
+<p>Le code côté serveur peut être écrit dans nombre de langages de programmation — les langages les plus populaires pour la programmation web côté serveur sont en autres PHP, Python, Ruby, C#, et NodeJS(JavaScript). Le code côté serveur a plein accès au système d'exploitation du serveur et le développeur est libre de choisir le langage (et la version) qu'il veut utiliser.</p>
+
+<p>Typiquement, les développeurs écrivent leur code en utilisant des <strong>frameworks web</strong>. Les frameworks web sont des ensembles de fonctions, objets, règles et autres constructions de code conçus pour résoudre des problèmes courants, accélérer le développement et simplifier les différents types de tâches rencontrées dans un domaine particulier.</p>
+
+<p>Encore une fois, bien que le code côté client et côté serveur utilisent des frameworks, les domaines d'application sont très différents et par conséquent les frameworks aussi. Les frameworks web côté client simplifient les tâches de mise en page et de présentation tandis que les frameworks web côté serveur fournissent des fonctionnalités "courantes" que vous auriez probablement à implémenter vous-même autrement (comme le support des sessions, des utilisateurs et de l'authentification, l'accès à la base de données, les bibliothèques de templates, etc.).</p>
+
+<div class="note">
+<p><strong>Note </strong>: Les frameworks côté client sont souvent utilisés pour accélérer le développement du code côté client, mais vous pouvez également choisir d'écrire tout le code à la main ; en vérité, écrire votre code à la main peut être plus rapide et plus efficace si vous n'avez besoin que d'une petite interface web très simple.</p>
+
+<p>En revanche, vous ne penseriez presque jamais à écrire les composants côté serveur d'une application web sans framework — implémenter des fonctionnalités vitales comme un serveur HTTP est très difficile à faire à partir de rien, comme disons en Python, alors que les frameworks web Python comme Django le fournissent tout prêt à l'emploi, accompagné d'autres outils très utiles.</p>
+</div>
+
+<div>
+<h2 id="Que_peut-on_faire_côté_serveur">Que peut-on faire côté serveur?</h2>
+
+<p>La programmation côté serveur est très utile parce qu'elle nous permet de délivrer efficacement de l'information taillée sur mesure pour l'utilisateur et ainsi créer une bien meilleure expérience utilisateur.</p>
+</div>
+
+<p>Des compagnies comme Amazon utilisent la programmation côté serveur pour construire la recherche de produits, faire des suggestions de produit ciblées sur les préférences du client et ses habitudes d'achat, simplifier les achats, etc.</p>
+
+<p>Les banques l'utilisent pour stocker les informations du compte ainsi que faire des transactions et n'autoriser à les consulter que les utilisateurs reconnus. D'autres services comme Facebook, Twitter, Instagram, et Wikipedia utilisent la programmation côté serveur pour mettre en avant, partager et contrôler l'accès au contenu.</p>
+
+<p>Les utilisations les plus courantes et les plus bénéfiques de la programmation côté serveur sont listées ci-dessous. Vous verrez qu'il y a quelques recoupements :</p>
+
+<h3 id="Stockage_et_distribution_de_linformation_plus_efficaces">Stockage et distribution de l'information plus efficaces</h3>
+
+<p>Imaginez combien de produits sont disponibles sur Amazon et combien de posts ont été écrits sur Facebook. Créer une page statique distincte pour chaque produit ou article serait totalement impossible.</p>
+
+<p>La programmation côté serveur nous permet plutôt de stocker l'information dans une base de données et de construire et retourner dynamiquement le HTML ainsi que d'autres types de fichiers (comme les PDF, images, etc.). Il est également possible de simplement retourner des données ({{glossary("JSON")}}, {{glossary("XML")}}, etc.) pour les afficher avec des frameworks côté client (cela réduit la charge de travail du serveur et la quantité de données qui doit être retournée).</p>
+
+<p>Le serveur ne se limite pas à l'envoi d'informations à partir de bases de données, il peut retourner le résultat d'autres outils logiciels, ou les données de services de communication. Le contenu peut même être ciblé pour le type d'appareil client qui le reçoit.</p>
+
+<p>Comme les informations se trouvent dans une base de données, elles peuvent également être partagées et mises à jour plus facilement avec d'autres systèmes (par exemple, quand des produits sont vendus en ligne ou dans un magasin, le magasin peut mettre à jour son inventaire).</p>
+
+<div class="note">
+<p><strong>Note </strong>: Votre imagination n'a pas à travailler dur pour voir les bénéfices du code côté serveur pour le stockage et distribution de l'information:</p>
+
+<ol>
+ <li>Allez sur <a href="https://www.amazon.com">Amazon</a> ou tout autre site e-commerce.</li>
+ <li>Cherchez un certain nombre de mot-clés et remarquez que la structure de la page de change pas, même si les résultats oui. </li>
+ <li>Ouvrez deux ou trois produits. Remarquez que la structure et la disposition de la page sont identiques, mais que le contenu pour les différents produits a été extrait de la base de données.</li>
+</ol>
+
+<p>Pour un terme de recherche courant  ("poisson", disons) vous pouvez voir littéralement des millions de valeurs retournées. Utiliser une base de données permet à ces données d'être stockées et partagées efficacement, et permet de contrôler la présentation de l'information à partir d'un seul endroit.</p>
+</div>
+
+<h3 id="Expérience_utilisateur_personnalisée">Expérience utilisateur personnalisée</h3>
+
+<p>Les serveurs peuvent stocker et utiliser des informations sur les clients pour fournir une expérience utilisateur personnalisée. Par exemple, beaucoup de sites proposent d'enregistrer une carte de crédit pour que les détails n'aient pas à être saisis de nouveau. Des sites comme Google Maps peuvent utiliser les emplacement enregistrés ou l'emplacement en cours pour fournir des informations d'itinéraire et chercher ou utiliser l'historique des voyages précédents pour trouver des boutiques locales dans les résultats de recherche.</p>
+
+<p>Une analyse plus approfondie des habitudes des utilisateurs peut être utilisée pour anticiper leurs intérêts et personnaliser les réponses ou les notifications du serveur, par exemple pour fournir une liste des lieux précédemment visités ou les plus populaires que vous pourriez vouloir chercher sur la carte.</p>
+
+<div class="note">
+<p><strong>Note : </strong><a href="https://maps.google.com/">Google Maps</a> sauvegarde vos recherches et votre historique de visites. Les emplacement fréquemment visités ou fréquemment recherchés sont plus mis en avant que les autres.</p>
+
+<p>Les résultats de recherche Google sont optimisés en fonction des recherches précédentes.</p>
+
+<ol>
+ <li> Allez sur <a href="https:\\google.com">Google</a>.</li>
+ <li> Recherchez "football".</li>
+ <li> Maintenant tapez "favoris" dans la barre de recherche et regardez les prédictions de recherche de l'autocomplete.</li>
+</ol>
+
+<p>Coïncidence ? Nada!</p>
+</div>
+
+<h3 id="Accès_contrôlé_au_contenu">Accès contrôlé au contenu</h3>
+
+<p>La programmation côté serveur permet aux sites de restreindre l'accès aux utilisateurs autorisés et de ne servir que les informations qu'un utilisateur à la permission de voir.</p>
+
+<p>Quelques exemples du monde réel incluent :</p>
+
+<ul>
+ <li>Les réseaux sociaux comme Facebook permettent aux utilisateurs de contrôler entièrement leurs propres données, mais permettent seulement à leurs amis de les voir ou des les commenter. L'utilisateur détermine qui peut voir ses données, et par extension, dans le flux de qui elles apparaissent —  l'autorisation est une partie centrale de l'expérience utilisateur !</li>
+ <li>
+  <p>Le site sur lequel vous êtes en ce moment même contrôle l'accès au contenu : les articles sont visibles à tout le monde, mais seuls les utilisateurs identifiés peuvent éditer le contenu. Essayez de cliquer sur le bouton <strong>Modifier</strong> en haut de cette page — si vous êtes identifié, vous verrez la vue d'édition ; sinon, vous serez redirigé vers la page d'inscription.</p>
+ </li>
+</ul>
+
+<div class="note">
+<p><strong>Note </strong>: Il existe de nombreux autres exemples où l'accès au contenu est contrôlé. Par exemple, que voyez-vous si vous allez sur le site en ligne de votre banque ? Connectez-vous à votre compte — quelles autres informations pouvez-vous voir et modifier ? Quelles informations pouvez-vous voir que seule la banque peut changer ?</p>
+</div>
+
+<h3 id="Stocker_les_informations_de_sessiondétat">Stocker les informations de session/d'état</h3>
+
+<p>La programmation côté serveur permet aux développeurs d'utiliser des <strong>sessions</strong> — en gros, un mécanisme qui permet au serveur de stocker des informations sur l'utilisation en cours d'un site et d'envoyer des réponses différentes selon cette information.</p>
+
+<p>Cela permet, par exemple, à un site de savoir qu'un utilisateur s'est déjà identifié et afficher des messages qui lui sont destinés, d'afficher son historique de commande, ou peut-être encore, dans le cas d'un jeu, lui permettre de reprendre là où il en est resté.</p>
+
+<div class="note">
+<p><strong>Note </strong>: Visitez le site d'un journal qui a une offre d'abonnement et ouvrez des pages (par exemple <a href="http://www.theage.com.au/">The Age</a>). Si vous continuez à visiter le site quelques heures/jours, éventuellement, vous commencerez à être redirigé vers des pages expliquant comment vous abonner, et vous ne pourrez plus accéder aux articles. Cette information est un exemple de session stockée dans des cookies.</p>
+</div>
+
+<h3 id="Notifications_et_communication">Notifications et communication</h3>
+
+<p>Les serveurs peuvent envoyer des notifications générales ou personnalisées à l'utilisateur via le site web lui-même ou par email, SMS, messagerie instantannée, conversations vidéo ou autres services de communication.</p>
+
+<p>Quelques exemples incluent :</p>
+
+<ul>
+ <li>Facebook et Twitter envoient des emails et SMS pour notifier des nouvelles communications.</li>
+ <li>Amazon envoie régulièrement des emails qui suggèrent des produits similaires à ceux que vous avez déjà acheté ou vu, par lesquels vous pourriez être intéressé.</li>
+ <li>Un serveur web peut envoyer des messages d'alerte aux administrateurs du site pour les prévenir en cas de mémoire insuffisante sur le serveur ou d'activité suspecte de l'utilisateur.</li>
+</ul>
+
+<div class="note">
+<p><strong>Note </strong>: Le type de notification le plus courant est la "confirmation d'inscription". Choisissez presque n'importe quel site qui vous intéresse (Google, Amazon, Instagram, etc.) et créez un nouveau compte en utilisant votre adresse email. Vous recevrez rapidement un email qui confirme votre inscription, ou qui exige une confirmation pour activer votre compte.</p>
+</div>
+
+<h3 id="Analyse_des_données">Analyse des données</h3>
+
+<p>Un site web peut collecter beaucoup de données sur les utilisateurs : ce qu'ils cherchent, ce qu'ils achètent, ce qu'ils recommandent, combien de temps ils restent sur chaque page. La programmation côté serveur peut être utilisée pour affiner les réponses en fonction de l'analyse de ces données.</p>
+
+<p>Par exemple, Amazon et Google font tous deux de la publicité pour des produits en se basant sur les recherches précédentes, sur les achats que vous avez faits.</p>
+
+<div class="note">
+<p><strong>Note </strong>: Si vous êtes un utilisateur de Facebook, allez sur votre flux principal et regardez les posts. Notez que certains posts ne sont pas classés par ordre numérique — en particulier, les posts qui ont le plus de "likes" sont souvent placés plus haut dans la liste que les posts plus récents.</p>
+
+<p>Observez également quels types de publicités vous voyez — vous pourrez voir des publicités pour des choses que vous avez regardé sur d'autres sites. L'algorithme de Facebook pour mettre en avant du contenu et faire de la publicité est un peu un mystérieux, mais il est clair qu'il prend en compte vos likes et ce que vous avez l'habitude de regarder !</p>
+</div>
+
+<h2 id="Sommaire">Sommaire</h2>
+
+<p>Félicitations, vous avez atteint la fin du premier article sur la programmation côté serveur. </p>
+
+<p>Vous avez maintenant appris que le code côté serveur est exécuté sur un serveur web et que son rôle principal est de contrôler <em>quelle</em> information est envoyée à l'utilisateur (tandis que le code côté client gère principalement la structure et la présentation des données pour l'utilisateur).</p>
+
+<p>Vous devez également comprendre que c'est utile pour créer des sites web qui délivrent de l'information <em>efficacement</em>, adaptée à chaque utilisateur et avoir une bonne idée de quelques choses que vous seriez capable de faire quand vous serez programmeur back-end.</p>
+
+<p>Finalement, vous devez comprendre que le code côté serveur peut être écrit dans de nombreux langages de programmation et que l'on peut utiliser des frameworks web pour rendre ce processus plus facile.</p>
+
+<p>Dans un futur article,  nous vous aiderons à choisir le framework le plus adapté pour la création d'un premier site. Ensuite, nous vous présenterons les principales interactions client-serveur plus en détails.</p>
+
+<p>{{NextMenu("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps")}}</p>
+
+<h2 id="Dans_ce_module">Dans ce module</h2>
+
+<ul>
+ <li><a href="/fr/docs/Learn/Server-side/First_steps/Introduction">Introduction au côté serveur</a></li>
+ <li><a href="/fr/docs/Learn/Server-side/First_steps/Client-Server_overview">Vue d'ensemble Client-Serveur</a></li>
+ <li><a href="/fr/docs/Learn/Server-side/First_steps/Web_frameworks">Frameworks web côté serveur</a></li>
+ <li><a href="/fr/docs/Learn/Server-side/First_steps/Website_security">La sécurité d'un site web</a></li>
+</ul>
diff --git a/files/fr/learn/server-side/premiers_pas/web_frameworks/index.html b/files/fr/learn/server-side/premiers_pas/web_frameworks/index.html
new file mode 100644
index 0000000000..b75c70fa0f
--- /dev/null
+++ b/files/fr/learn/server-side/premiers_pas/web_frameworks/index.html
@@ -0,0 +1,306 @@
+---
+title: Les frameworks web côté serveur
+slug: Learn/Server-side/Premiers_pas/Web_frameworks
+tags:
+  - Débutant
+  - Guide
+  - Server
+  - Web
+translation_of: Learn/Server-side/First_steps/Web_frameworks
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{PreviousMenuNext("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps/Website_security", "Learn/Server-side/First_steps")}}</div>
+
+<p class="summary">L'article précédent nous a montré à quoi ressemble la communication entre les clients et les serveurs web, la nature des demandes et des réponses HTTP et ce qu’une application web côté serveur doit faire pour répondre aux demandes d’un navigateur web. Avec ces connaissances en main, il est temps d'explorer comment les frameworks peuvent nous simplifier la tâche.  En chemin, vous comprendrez comment choisir le framework le mieux adapté pour votre première application web côté serveur.</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">Prérequis :</th>
+   <td>Connaissance informatique de base.</td>
+  </tr>
+  <tr>
+   <th scope="row">Objectif :</th>
+   <td>Comprendre comment les frameworks simplifient le développement/la maintenance du code côté serveur et vous faire réfléchir à propos de la sélection d'un framework pour votre propre développement.</td>
+  </tr>
+ </tbody>
+</table>
+
+<p>Les sections suivantes proposent des illustrations avec des fragments de codes utilisés par des frameworks réels. Ne soyez pas inquiété si vous ne comprenez pas tout directement. Les explications viendront au fur et à mesure.</p>
+
+<h2 id="Vue_densemble">Vue d'ensemble</h2>
+
+<p>Les frameworks web côté serveur (c-à-d "web application frameworks") facilitent l'écriture, la maintenance et la mise à l'échelle d'applications web. Ils fournissent des outils et des bibliothèques qui simplifient les tâches courantes de développement web, notamment l'acheminement des URL vers les gestionnaires appropriés, l'interaction avec les bases de données, les sessions et l'autorisation des utilisateurs, le formatage de la sortie (HTML, JSON, XML, par exemple) et l'amélioration de la sécurité contre les attaques web.</p>
+
+<p>Dans la section suivante, nous allons voir un peu plus de détails comment les frameworks facilite le développement d'applications web. Nous verrons alors les critères utilisés pour choisir un framework adapté.</p>
+
+<h2 id="Que_peut_faire_un_framework_web_pour_vous">Que peut faire un framework web pour vous ?</h2>
+
+<p>Les frameworks web fournissent des outils et des bibliothèques pour simplifier les opérations de développement web courantes. Utiliser un framework web côté serveur n'est pas obligatoire, mais fortement conseillé... Cela vous facilitera grandement la vie. Cette section présente certaines des fonctionnalités parmi les plus souvent fournies par les frameworks web.</p>
+
+<h3 id="Travailler_directement_avec_les_requêtes_et_les_réponses_HTTP">Travailler directement avec les requêtes et les réponses HTTP</h3>
+
+<p>Comme nous l'avons vu dans le dernier article, les serveurs web et les navigateurs communiquent via le protocole HTTP — les serveurs attendent les requêtes HTTP du navigateur, puis renvoient des informations dans les réponses HTTP. Les infrastructures web vous permettent d'écrire une syntaxe simplifiée qui générera un code côté serveur pour travailler avec ces demandes et réponses. Cela signifie que vous aurez un travail plus facile, en interagissant avec un code plus facile, de niveau supérieur, plutôt que des primitives de réseau de niveau inférieur.</p>
+
+<p>L'exemple ci-dessous montre comment cela fonctionne dans le framework web Django (Python). Chaque fonction "view" (un gestionnaire de demandes) reçoit un objet HttpRequest contenant les informations de la demande et doit renvoyer un objet HttpResponse avec la sortie formatée (dans ce cas une chaîne).</p>
+
+<pre class="brush: python"># Django view function
+from django.http import HttpResponse
+
+def index(request):
+    # Get an HttpRequest (request)
+    # perform operations using information from the request.
+    # Return HttpResponse
+    return HttpResponse('Output string to return')
+</pre>
+
+<h3 id="Acheminer_les_requettes_au_gestionnaire_approprié">Acheminer les requettes au gestionnaire approprié</h3>
+
+<p>La plupart des sites fournissent un certain nombre de ressources différentes, accessibles via des URL distinctes. Il est difficile de gérer toutes ces fonctions en une seule fois. Par conséquent, les infrastructures web fournissent des mécanismes simples pour mapper les modèles d'URL vers des fonctions de gestionnaire spécifiques. Cette approche présente également des avantages en termes de maintenance, car vous pouvez modifier l'URL utilisée pour fournir une fonctionnalité particulière sans avoir à modifier le code sous-jacent.</p>
+
+<p>Différents frameworks utilisent différents mécanismes pour la cartographie. Par exemple, l'infrastructure web Flask (Python) ajoute des itinéraires pour afficher les fonctions à l'aide d'un décorateur.</p>
+
+<pre class="brush: python">@app.route("/")
+def hello():
+    return "Hello World!"</pre>
+
+<p>Alors que Django attend des développeurs qu'ils définissent une liste de mappages d'URL entre un modèle d'URL et une fonction d'affichage.</p>
+
+<pre class="brush: python">urlpatterns = [
+    url(r'^$', views.index),
+    # example: /best/myteamname/5/
+    url(r'^(?P&lt;team_name&gt;\w.+?)/(?P&lt;team_number&gt;[0-9]+)/$', views.best),
+]
+</pre>
+
+<h3 id="Faciliter_laccès_aux_données_via_la_requête">Faciliter l'accès aux données via la requête</h3>
+
+<p>Les données peuvent être encodées dans une requête HTTP de différentes manières. Une demande HTTP GET pour obtenir des fichiers ou des données du serveur peut coder les données requises dans les paramètres d'URL ou dans la structure d'URL. Une demande HTTP POST de mise à jour une ressource sur le serveur inclura plutôt les informations de mise à jour en tant que "données POST" dans le corps de la demande. La requête HTTP peut également inclure des informations sur la session ou l'utilisateur en cours dans un cookie côté client. Les frameworks web fournissent des mécanismes appropriés au langage de programmation pour accéder à ces informations. Par exemple, l'objet HttpRequest que Django transmet à chaque fonction d'affichage contient des méthodes et des propriétés permettant d'accéder à l'URL cible, le type de demande (par exemple, un HTTP GET), les paramètres GET ou POST, les données de cookie et de session, etc. Django peut également transmettre informations codées dans la structure de l'URL en définissant des "modèles de capture" dans le mappeur d'URL (voir le dernier fragment de code dans la section ci-dessus).</p>
+
+<h3 id="extraction_et_simplification_de_l’accès_à_la_base_de_données">extraction et simplification de l’accès à la base de données</h3>
+
+<p>Les sites web utilisent des bases de données pour stocker des informations à partager avec les utilisateurs et sur les utilisateurs. Les infrastructures web fournissent souvent une couche de base de données qui extrait les opérations de lecture, d'écriture, de requête et de suppression de base de données. Cette couche d'extraction est appelée ORM (Object-Relational Mapper).</p>
+
+<p>L'utilisation d'un ORM présente deux avantages :   </p>
+
+<ol>
+ <li>Vous pouvez remplacer la base de données sous-jacente sans avoir nécessairement besoin de changer le code qui l'utilise. Cela permet aux développeurs d’optimiser les caractéristiques des différentes bases de données en fonction de leur utilisation.   </li>
+ <li>La validation de base des données peut être mise en œuvre avec le framework. Il est ainsi plus facile et plus sûr de vérifier que les données sont stockées dans le type de champ de base de données approprié, qu’elles ont le format correct (par exemple une adresse électronique) et qu’elles ne sont en aucun cas malveillantes (les pirates peuvent utiliser certains modèles de code pour agir mal, telles que la suppression des enregistrements de la base de données).</li>
+</ol>
+
+<p>Par exemple, le framework web Django fournit un ORM et fait référence à l'objet utilisé pour définir la structure d'un enregistrement en tant que modèle. Le modèle spécifie les types de champs à stocker, ce qui peut fournir une validation au niveau du champ sur les informations pouvant être stockées (par exemple, un champ de courrier électronique autoriserait uniquement les adresses de courrier électronique valides). Les définitions de champ peuvent également spécifier leur taille maximale, leurs valeurs par défaut, leurs options de liste de sélection, leur aide pour la documentation, leur libellé pour les formulaires, etc. Le modèle ne spécifie aucune information sur la base de données sous-jacente, il s'agit d'un paramètre de configuration susceptible d'être modifié séparément de notre code.</p>
+
+<p>Le premier extrait de code ci-dessous montre un modèle Django très simple pour un objet Team. Ceci stocke le nom et le niveau de l'équipe en tant que champs de caractères et spécifie un nombre maximal de caractères à stocker pour chaque enregistrement. Team_level étant un champ de choix, nous fournissons également un mappage entre les choix à afficher et les données à stocker, ainsi qu'une valeur par défaut.</p>
+
+<pre class="brush: python">#best/models.py
+
+from django.db import models
+
+class Team(models.Model):
+    team_name = models.CharField(max_length=40)
+
+    TEAM_LEVELS = (
+        ('U09', 'Under 09s'),
+        ('U10', 'Under 10s'),
+        ('U11, 'Under 11s'),
+        ...  #list our other teams
+    )
+    team_level = models.CharField(max_length=3,choices=TEAM_LEVELS,default='U11')
+</pre>
+
+<p>Le modèle Django fournit une API de requête simple pour la recherche dans la base de données. Cela peut correspondre à plusieurs champs à la fois en utilisant différents critères (par exemple, exact, insensible à la casse, supérieur à, etc.), et peut prendre en charge des instructions complexes (par exemple, vous pouvez spécifier une recherche sur les équipes U11 ayant un nom d'equipe (team name) qui commence par "Fr" ou se termine par "al").</p>
+
+<p>Le deuxième extrait de code montre une fonction d'affichage (gestionnaire de ressources) permettant d'afficher toutes nos équipes U09. Dans ce cas, nous spécifions que nous voulons filtrer tous les enregistrements où le champ team_level a exactement le texte 'U09' (notez dans l exemple ci dessous comment ce critère est transmis à la fonction filter () sous forme d'argument avec le nom du champ et le type de correspondance séparés par un double. underscores: team_level__exact).</p>
+
+<pre class="brush: python">#best/views.py
+
+from django.shortcuts import render
+from .models import Team
+
+def youngest(request):
+    <strong>list_teams = Team.objects.filter(team_level__exact="U09")</strong>
+    context = {'youngest_teams': list_teams}
+    return render(request, 'best/index.html', context)
+</pre>
+
+<dl>
+</dl>
+
+<h3 id="Rendering_data">Rendering data</h3>
+
+<p>Les frameworks web fournissent souvent des systèmes de templates. Ceux-ci vous permettent de spécifier la structure d'un document de sortie, en utilisant des espaces réservés pour les données qui seront ajoutées lors de la génération d'une page. Les modèles sont souvent utilisés pour créer du HTML, mais peuvent également créer d'autres types de documents.</p>
+
+<p>Les frameworks web fournissent souvent un mécanisme facilitant la génération d'autres formats à partir de données stockées, notamment {{glossary ("JSON")}} et {{glossary ("XML")}}.</p>
+
+<p>Par exemple, le système de templates Django vous permet de spécifier des variables en utilisant une syntaxe "double-handlebars" (par exemple,<code>{</code><code>{ <em>variable_name</em> </code><code>}</code><code>}</code> ), qui sera remplacée par les valeurs transmises à partir de la fonction d'affichage lors du rendu d'une page. Le système de templates prend également en charge les expressions (avec la syntaxe:<code>{% <em>expression</em> %}</code> ), qui permettent aux templates d'effectuer des opérations simples, telles que l'itération des valeurs de liste transmises au modèle.</p>
+
+<div class="note">
+<p><strong>Note </strong>: Many other templating systems use a similar syntax, e.g.: Jinja2 (Python), handlebars (JavaScript), moustache (JavaScript), etc.</p>
+</div>
+
+<p>L'extrait de code ci-dessous montre comment cela fonctionne. En reprenant l'exemple "youngest_teams" de la section précédente, le modèle HTML se voit transmettre par la vue une variable de liste nommée youngest_teams. Dans le squelette HTML, nous avons une expression qui vérifie d'abord si la variable youngest_teams existe, puis itère dans une boucle for. À chaque itération, le modèle affiche la valeur team_name de l'équipe dans un élément de liste.</p>
+
+<pre class="brush: html">#best/templates/best/index.html
+
+&lt;!DOCTYPE html&gt;
+&lt;html lang="en"&gt;
+&lt;body&gt;
+
+ {% if youngest_teams %}
+    &lt;ul&gt;
+    {% for team in youngest_teams %}
+        &lt;li&gt;\{\{ team.team_name \}\}&lt;/li&gt;
+    {% endfor %}
+    &lt;/ul&gt;
+{% else %}
+    &lt;p&gt;No teams are available.&lt;/p&gt;
+{% endif %}
+
+&lt;/body&gt;
+&lt;/html&gt;
+</pre>
+
+<h2 id="Comment_choisir_un_framework_web"><span style='background-color: #f5f5f5; color: rgba(0, 0, 0, 0.87); display: inline !important; float: none; font-family: "Roboto",arial,sans-serif; font-size: 24px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; white-space: pre-wrap;'>Comment choisir un framework web</span></h2>
+
+<p>Il existe de nombreux frameworks web pour presque tous les langages de programmation que vous souhaitez utiliser (nous énumérons quelques-uns des frameworks les plus populaires dans la section suivante). Avec autant de choix, il peut devenir difficile de déterminer quel framework constitue le meilleur point de départ pour votre nouvelle application web.</p>
+
+<p>Certains des facteurs qui peuvent affecter votre décision sont les suivants:</p>
+
+<ul>
+ <li><strong>Effort d'apprentissage </strong>: L'effort d'apprentissage d'un framework web dépend de votre familiarité avec le langage de programmation sous-jacent, de la cohérence de son API, de la qualité de sa documentation ainsi que de la taille et de l'activité de sa communauté. Si vous avez peu d'eqperience en programmation, pensez à Django (l’un des plus faciles à apprendre en fonction des critères ci-dessus). Si vous faites partie d'une équipe de développement qui possède déjà une expérience significative avec un framework web ou un langage de programmation particulier, il est logique de s'en tenir à cela.</li>
+ <li><strong>Productivité </strong>: la productivité mesure la rapidité avec laquelle vous pouvez créer de nouvelles fonctionnalités une fois que vous êtes familiarisé avec le framework. Elle inclut à la fois les efforts d'écriture et de maintenance du code (car vous ne pouvez pas écrire de nouvelles fonctionnalités alors que les anciennes sont endommagées). Un grand nombre des facteurs qui affectent la productivité sont similaires à ceux de "Effort d'apprentissage" - par ex. documentation, communauté, expérience en programmation, etc. - les autres facteurs incluent:
+  <ul>
+   <li><em>Objectif / origine du framework </em>: certains frameworks web ont été créés à l'origine pour résoudre certains types de problèmes, et restent meilleurs pour créer des applications web avec des contraintes similaires. Par exemple, Django a été créé pour soutenir le développement d'un site web de journal. Il est donc bon pour les blogs et les autres sites impliquant la publication d'éléments. En revanche, Flask est un cadre beaucoup plus léger et est idéal pour créer des applications web s'exécutant sur des périphériques intégrés.</li>
+   <li><em>Populaire vs Impopulaire</em>: Un framework populaire est un frameqork dans lequel il est recommandé de "meilleures" manières de résoudre un problème particulier. Les frameworks populaire ont tendance à être plus productifs lorsque vous essayez de résoudre des problèmes courants, car ils vous orientent dans la bonne direction, mais ils sont parfois moins flexibles.</li>
+   <li><em>Ressource incluses vs. l'obtenir vous-même </em>: certains frameworks web incluent des outils / bibliothèques qui traitent tous les problèmes que leurs développeurs peuvent penser "par défaut", tandis que des frameworks plus légers attendent des développeurs web qu'ils choisissent la solution aux problèmes de bibliothèques séparées (Django est un exemple inclue " tout " tandis que  Flask est un exemple de framework très léger). Les frameworks qui incluent tout sont souvent plus faciles à démarrer car vous avez déjà tout ce dont vous avez besoin, et il est probable qu’il soit bien intégré et bien documenté. Cependant, si une structure plus petite contient tout ce dont vous avez besoin (le cas échéant), elle peut alors s'exécuter dans des environnements plus restreints et disposer d'un sous-ensemble de choses plus petites et plus faciles à apprendre.</li>
+   <li><em>Si le framework encourage ou non les bonnes pratiques de développement </em>: par exemple, un cadre qui encourage une architecture Model-View-Controller où on sépare le code en fonctions logiques engendrera un code plus facile à maintenir qu'un code qui n'a pas d'attente de la part des développeurs. De même, la conception de la structure peut avoir un impact important sur la facilité de test et de réutilisation du code.</li>
+  </ul>
+ </li>
+ <li><strong>Performances du framework/langage de programmation </strong>: généralement, la <em>vitesse</em> n’est pas le facteur le plus important dans la sélection car même des exécutions relativement lentes, comme Python, sont plus que <em>suffisantes</em> pour les sites de taille moyenne fonctionnant avec un matériel raisonnablement performant. Les avantages perçus en termes de vitesse par rapport à un autre langage comme C++ ou JavaScript peuvent être compensés par les coûts d’apprentissage et de maintenance.</li>
+ <li><strong>Mise en cache </strong>: la popularité de votre site web grandit, vous constatez peut-être que le serveur ne peut plus gérer toutes les requêtes. À ce stade, vous pouvez envisager d’ajouter un support pour la mise en cache : une optimisation dans laquelle vous stockez tout ou partie de la réponse à une requête web afin qu'il ne soit pas nécessaire de la recalculer la prochaine fois. Retourner la réponse en cache à une requête est beaucoup plus rapide que d'en calculer une. La mise en cache peut être implémentée dans votre code ou sur le serveur (voir proxy inverse). Les infrastructures web auront différents niveaux de prise en charge pour définir le contenu pouvant être mis en cache.</li>
+ <li><strong>Adpatation </strong>: votre site web connaît un succès fantastique, vous avez épuisé les avantages de la mise en cache, vous atteignez même les limites de la mise à l'échelle verticale (exécuter votre application Web sur un matériel plus puissant). À ce stade, il est temps de penser à une mise à l’échelle horizontale (partager la charge en répartissant votre site sur un certain nombre de serveurs web et de bases de données) ou «géographiquement», car certains de vos clients sont très éloignés de votre serveur. L'infrastructure web que vous choisissez peut faire toute la différence en termes de facilité d'adaptation de votre site.</li>
+ <li><strong>Sécurité web </strong>: certains environnements web offrent une meilleure prise en charge de la gestion des attaques web courantes. Django, par exemple, supprime toutes les entrées utilisateur des modèles HTML afin que le code JavaScript saisi par l'utilisateur ne puisse pas être exécuté. D'autres frameworks offrent une protection similaire, mais celle-ci n'est pas toujours activée par défaut.</li>
+</ul>
+
+<p>Il existe de nombreux autres facteurs possibles, y compris les licences, que le cadre soit ou non en cours de développement actif, etc.</p>
+
+<p>Si vous débutez en programmation, vous choisirez probablement un framework facile à prendre en main. Une documentation riche et une communauté active sont également des critères pertinents pour votre choix. Pour la suite de ce cours, nous avons choisi Django (Python) et Express (Node/JavaScript) principalement parce que ces frameworks sont faciles à apprendre et bénéficient d'un bon soutien.</p>
+
+<div class="note">
+<p><strong>Note</strong>: Let's go to the main websites for <a href="https://www.djangoproject.com/">Django</a> (Python) and <a href="http://expressjs.com/">Express</a> (Node/JavaScript) and check out their documentation and community.</p>
+
+<ol>
+ <li>Navigate to the main sites (linked above)
+  <ul>
+   <li>Click on the Documentation menu links (named things like "Documentation, Guide, API Reference, Getting Started".</li>
+   <li>Can you see topics showing how to set up URL routing, templates, and databases/models?</li>
+   <li>Are the documents clear?</li>
+  </ul>
+ </li>
+ <li>Navigate to mailing lists for each site (accessible from Community links).
+  <ul>
+   <li>How many questions have been posted in the last few days</li>
+   <li>How many have responses?</li>
+   <li>Do they have an active community?</li>
+  </ul>
+ </li>
+</ol>
+</div>
+
+<h2 id="A_few_good_web_frameworks">A few good web frameworks?</h2>
+
+<p>Let's now move on, and discuss a few specific server-side web frameworks.</p>
+
+<p>The server-side frameworks below represent <em>a few </em>of the most popular available at the time of writing. All of them have everything you need to be productive — they are open source, are under active development, have enthusiastic communities creating documentation and helping users on discussion boards, and are used in large numbers of high-profile websites. There are many other great server-side frameworks that you can discover using a basic internet search.</p>
+
+<div class="note">
+<p><strong>Note</strong>: Descriptions come (partially) from the framework websites!</p>
+</div>
+
+<h3 id="Django_Python">Django (Python)</h3>
+
+<p><a href="https://www.djangoproject.com/">Django</a> is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. Built by experienced developers, it takes care of much of the hassle of web development, so you can focus on writing your app without needing to reinvent the wheel. It’s free and open source.</p>
+
+<p>Django follows the "Batteries included" philosophy and provides almost everything most developers might want to do "out of the box". Because everything is included, it all works together, follows consistent design principles, and has extensive and up-to-date documentation. It is also fast, secure, and very scalable. Being based on Python, Django code is easy to read and to maintain.</p>
+
+<p>Popular sites using Django (from Django home page) include: Disqus, Instagram, Knight Foundation, MacArthur Foundation, Mozilla, National Geographic, Open Knowledge Foundation, Pinterest, Open Stack.</p>
+
+<h3 id="Flask_Python">Flask (Python)</h3>
+
+<p><a href="http://flask.pocoo.org/">Flask</a> is a microframework for Python.</p>
+
+<p>While minimalist, Flask can create serious websites out of the box. It contains a development server and debugger, and includes support for <a href="https://github.com/pallets/jinja">Jinja2</a> templating, secure cookies, <a href="https://en.wikipedia.org/wiki/Unit_testing">unit testing</a>, and <a href="http://www.restapitutorial.com/lessons/restfulresourcenaming.html">RESTful</a> request dispatching. It has good documentation and an active community.</p>
+
+<p>Flask has become extremely popular, particularly for developers who need to provide web services on small, resource-constrained systems (e.g. running a web server on a <a href="https://www.raspberrypi.org/">Raspberry Pi</a>, <a href="http://blogtarkin.com/drone-definitions-learning-the-drone-lingo/">Drone controllers</a>, etc.)</p>
+
+<h3 id="Express_Node.jsJavaScript">Express (Node.js/JavaScript)</h3>
+
+<p><a href="http://expressjs.com/">Express</a> is a fast, unopinionated, flexible and minimalist web framework for <a href="https://nodejs.org/en/">Node.js</a> (node is a browserless environment for running JavaScript). It provides a robust set of features for web and mobile applications and delivers useful HTTP utility methods and <a href="/en-US/docs/Glossary/Middleware">middleware</a>.</p>
+
+<p>Express is extremely popular, partially because it eases the migration of client-side JavaScript web programmers into server-side development, and partially because it is resource-efficient (the underlying node environment uses lightweight multitasking within a thread rather than spawning separate processes for every new web request).</p>
+
+<p>Because Express is a minimalist web framework it does not incorporate every component that you might want to use (for example, database access and support for users and sessions are provided through independent libraries). There are many excellent independent components, but sometimes it can be hard to work out which is the best for a particular purpose!</p>
+
+<p>Many popular server-side and full stack frameworks (comprising both server and client-side frameworks) are based on Express, including <a href="http://feathersjs.com/">Feathers</a>, <a href="https://www.itemsapi.com/">ItemsAPI</a>, <a href="http://keystonejs.com/">KeystoneJS</a>, <a href="http://krakenjs.com/">Kraken</a>, <a href="http://loopback.io/">LoopBack</a>, <a href="http://mean.io/">MEAN</a>, and <a href="http://sailsjs.org/">Sails</a>.</p>
+
+<p>A lot of high profile companies use Express, including: Uber, Accenture, IBM, etc. (a list is provided <a href="http://expressjs.com/en/resources/companies-using-express.html">here</a>).</p>
+
+<h3 id="Ruby_on_Rails_Ruby">Ruby on Rails (Ruby)</h3>
+
+<p><a href="http://rubyonrails.org/">Rails</a> (usually referred to as "Ruby on Rails") is a web framework written for the Ruby programming language.</p>
+
+<p>Rails follows a very similar design philosophy to Django. Like Django it provides standard mechanisms for routing URLs, accessing data from a database, generating HTML from templates and formatting data as {{glossary("JSON")}} or {{glossary("XML")}}. It similarly encourages the use of design patterns like DRY ("dont repeat yourself" — write code only once if at all possible), MVC (model-view-controller) and a number of others.</p>
+
+<p>There are of course many differences due to specific design decisions and the nature of the languages.</p>
+
+<p>Rails has been used for high profile sites, including:<strong> </strong><a href="https://basecamp.com/">Basecamp</a>, <a href="https://github.com/">GitHub</a>, <a href="https://shopify.com/">Shopify</a>, <a href="https://airbnb.com/">Airbnb</a>, <a href="https://twitch.tv/">Twitch</a>, <a href="https://soundcloud.com/">SoundCloud</a>, <a href="https://hulu.com/">Hulu</a>, <a href="https://zendesk.com/">Zendesk</a>, <a href="https://square.com/">Square</a>, <a href="https://highrisehq.com/">Highrise</a>.</p>
+
+<h3 id="Laravel_PHP">Laravel (PHP)</h3>
+
+<p><a href="https://laravel.com/">Laravel</a> is a web application framework with expressive, elegant syntax. Laravel attempts to take the pain out of development by easing common tasks used in the majority of web projects, such as:</p>
+
+<ul>
+ <li><a href="https://laravel.com/docs/routing" rel="nofollow">Simple, fast routing engine</a>.</li>
+ <li><a href="https://laravel.com/docs/container" rel="nofollow">Powerful dependency injection container</a>.</li>
+ <li>Multiple back-ends for <a href="https://laravel.com/docs/session" rel="nofollow">session</a> and <a href="https://laravel.com/docs/cache" rel="nofollow">cache</a> storage.</li>
+ <li>Expressive, intuitive <a href="https://laravel.com/docs/eloquent" rel="nofollow">database ORM</a>.</li>
+ <li>Database agnostic <a href="https://laravel.com/docs/migrations" rel="nofollow">schema migrations</a>.</li>
+ <li><a href="https://laravel.com/docs/queues" rel="nofollow">Robust background job processing</a>.</li>
+ <li><a href="https://laravel.com/docs/broadcasting" rel="nofollow">Real-time event broadcasting</a>.</li>
+</ul>
+
+<p>Laravel is accessible, yet powerful, providing tools needed for large, robust applications.</p>
+
+<h3 id="ASP.NET">ASP.NET</h3>
+
+<p><a href="http://www.asp.net/">ASP.NET</a> is an open source web framework developed by Microsoft for building modern web applications and services. With ASP.NET you can quickly create web sites based on HTML, CSS, and JavaScript, scale them for use by millions of users and easily add more complex capabilities like Web APIs, forms over data, or real time communications.</p>
+
+<p>One of the differentiators for ASP.NET is that it is built on the <a href="https://en.wikipedia.org/wiki/Common_Language_Runtime">Common Language Runtime</a> (CLR), allowing programmers to write ASP.NET code using any supported .NET language (C#, Visual Basic, etc.). Like many Microsoft products it benefits from excellent tools (often free), an active developer community, and well-written documentation.</p>
+
+<p>ASP.NET is used by Microsoft, Xbox.com, Stack Overflow, and many others.</p>
+
+<h3 id="Mojolicious_Perl">Mojolicious (Perl)</h3>
+
+<p><a href="http://mojolicious.org/">Mojolicious</a> is a next generation web framework for the Perl programming language.</p>
+
+<p>Back in the early days of the web, many people learned Perl because of a wonderful Perl library called <a href="https://metacpan.org/module/CGI">CGI</a>. It was simple enough to get started without knowing much about the language and powerful enough to keep you going. Mojolicious implements this idea using bleeding edge technologies.</p>
+
+<p>Some of the features provided by Mojolicious are: <strong>Real-time web framework</strong>, to easily grow single file prototypes into well-structured MVC web applications; RESTful routes, plugins, commands, Perl-ish templates, content negotiation, session management, form validation, testing framework, static file server, CGI/<a href="http://plackperl.org">PSGI</a> detection, first class Unicode support; Full stack HTTP and WebSocket client/server implementation with IPv6, TLS, SNI, IDNA, HTTP/SOCKS5 proxy, UNIX domain socket, Comet (long polling), keep-alive, connection pooling, timeout, cookie, multipart and gzip compression support; JSON and HTML/XML parsers and generators with CSS selector support; Very clean, portable and object-oriented pure-Perl API with no hidden magic; Fresh code based upon years of experience, free and open source.</p>
+
+<h2 id="Summary">Summary</h2>
+
+<p>This article has shown that web frameworks can make it easier to develop and maintain server-side code. It has also provided a high level overview of a few popular frameworks, and discussed criteria for choosing a web application framework. You should now have at least an idea of how to choose a web framework for your own server-side development. If not, then don't worry — later on in the course we'll give you detailed tutorials on Django and Express to give you some experience of actually working with a web framework.</p>
+
+<p>For the next article in this module we'll change direction slightly and consider web security.</p>
+
+<p>{{PreviousMenuNext("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps/Website_security", "Learn/Server-side/First_steps")}}</p>
+
+<h2 id="In_this_module">In this module</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Learn/Server-side/First_steps/Introduction">Introduction to the server side</a></li>
+ <li><a href="/en-US/docs/Learn/Server-side/First_steps/Client-Server_overview">Client-Server overview</a></li>
+ <li><a href="/en-US/docs/Learn/Server-side/First_steps/Web_frameworks">Server-side web frameworks</a></li>
+ <li><a href="/en-US/docs/Learn/Server-side/First_steps/Website_security">Website security</a></li>
+</ul>
diff --git a/files/fr/learn/server-side/premiers_pas/website_security/index.html b/files/fr/learn/server-side/premiers_pas/website_security/index.html
new file mode 100644
index 0000000000..bc47ab4042
--- /dev/null
+++ b/files/fr/learn/server-side/premiers_pas/website_security/index.html
@@ -0,0 +1,162 @@
+---
+title: La sécurité d'un site Web
+slug: Learn/Server-side/Premiers_pas/Website_security
+tags:
+  - Débutant
+  - Guide
+  - Sécurité
+  - Sécurité Web
+translation_of: Learn/Server-side/First_steps/Website_security
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{PreviousMenu("Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/Premiers_pas")}}</div>
+
+<p class="summary">La sécurité d'un site web exige de la vigilance dans tous les aspects de sa conception et de son utilisation. Cet article d'introduction ne fera pas de vous un gourou de la sécurité des sites web, mais il vous aidera à comprendre d'où viennent les menaces et ce que vous pouvez faire pour renforcer votre application web contre les attaques les plus courantes.</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">Pré-requis :</th>
+   <td>Connaissances de base en informatique.</td>
+  </tr>
+  <tr>
+   <th scope="row">Objectif :</th>
+   <td>Comprendre les menaces les plus courantes à la sécurité des applications web et ce que vous pouvez faire pour réduire le risque de piratage de votre site.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Quest-ce_que_la_sécurité_dun_site_web">Qu'est-ce que la sécurité d'un site web?</h2>
+
+<p>Internet est un endroit dangereux ! Fréquemment, nous entendons parler de sites web devenus indisponibles en raison d'attaques par déni de service, ou affichant des informations modifiées (et souvent préjudiciables) sur leurs pages d'accueil. Dans d'autres cas, très médiatisés, des millions de mots de passe, d'adresses électroniques et de détails sur des cartes de crédit sont divulgués au public, exposant les utilisateurs du site web à la fois à l'embarras personnel et au risque de pertes financières.</p>
+
+<p>L'objectif de la sécurité des sites web est de prévenir ces types d'attaques. Plus formellement, la sécurité des sites web est l'acte de protéger les sites web contre l'accès, l'utilisation, la modification, la destruction ou la perturbation non autorisées.</p>
+
+<p>La sécurité efficace d'un site web nécessite un effort de conception sur l'ensemble du site : dans votre application web, dans la configuration du serveur web, dans vos politiques de création et de renouvellement des mots de passe et dans le code côté-client. Bien que tout cela semble très inquiétant, la bonne nouvelle est que si vous utilisez un framework web côté serveur, il incluera certainement par défaut des mécanismes de défense solides et bien pensés contre un certain nombre des attaques les plus courantes. D'autres attaques peuvent être atténuées grâce à la configuration de votre serveur web, par exemple en activant HTTPS. Enfin, les outils d'analyse de vulnérabilité accessibles au public peuvent vous aider à découvrir d'éventuelles erreurs dans votre conception.</p>
+
+<p>Le reste de cet article détaille les menaces les plus courantes qui pèsent sur les sites web et quelques étapes simples pour protèger votre site.</p>
+
+<div class="note">
+<p><strong>Note </strong>: ceci est un article d'introduction, conçu pour vous aider à réflechir à la sécurité de votre site web. Il n'est en rien exhaustif.</p>
+</div>
+
+<h2 id="Menaces_visant_la_sécurité_des_sites_web">Menaces visant la sécurité des sites web</h2>
+
+<p>Cette section n'énumère que quelques-unes des menaces les plus courantes visant les sites web et la façon dont elles sont tenues à distance. À mesure que vous lisez, notez comment les menaces apparaissent lorsque l'application web fait confiance ou n'est pas assez méfiante vis-à-vis des données provenant du navigateur !</p>
+
+<h3 id="Cross-Site_Scripting_XSS">Cross-Site Scripting (XSS)</h3>
+
+<p>XSS est un terme utilisé pour décrire une classe d'attaque qui permet à l'attaquant d'injecter des scripts, exécutés côté-client, <em>au travers</em> du site web pour viser le navigateur web des autres utilisateurs. Comme le code injecté provient du site web le navigateur web le considère comme sûr, il peut de ce fait faire des choses comme transmettre le cookie d'authentification de l'utilisateur à l'attaquant. Une fois que l'attaquant obtient ce cookie il peut se connecter sur le site comme si il était l'utilisateur attaqué et peut faire tout ce que l'utilisateur pourrait faire. En fonction du site sur lequel l'attaque se produit, cela peut inclure l'accès aux détails de carte bancaire, les informations des contacts, la modification du mot de passe, etc.</p>
+
+<div class="note">
+<p><strong>Note </strong>: les vulnérabilités XSS ont historiquement été les plus courantes.</p>
+</div>
+
+<p>Il y a deux manières principales pour demander au site de retourner un script injecté vers un navigateur web — elles sont désignées en tant que vulnérabilités XSS <em>réfléchie</em> et <em>persistante</em>.</p>
+
+<ul>
+ <li>Une vulnérabilité XSS  réfléchie se produit quand le contenu de l'utilisateur transmis au serveur est immédiatement retourné, sans avoir été modifié, pour être affiché dans le navigateur — tout les scripts présents dans le contenu d'origine seront exécutés quand la nouvelle page sera chargée!<br>
+  On prendra par exemple une fonction de recherche dans un site où les termes recherchés sont encodés en tant que paramètres dans l'URL, et que ces termes sont affichés en permanence avec les résultats. Un attaquant peut construire un lien de recherche contenant un script malicieux en tant que paramètre (ex: <code>http://mysite.com?q=beer&lt;script%20src="http://sitedangereux.com/malicieux.js"&gt;&lt;/script&gt;</code>) et le transmettre par e-mail à un autre utilisateur. Si l'utilisateur ciblé clique sur ce "lien intéressant", le script sera exécuté quand les résultats de la recherche seront affichés. Comme vu auparavant, cela donne à l'attaquant toute les informations dont il a besoin pour se connecter sur le site avec le compte de la victime — potentiellement faire des achats en tant que cet utilisateur ou accèder à la liste de contacts..</li>
+ <li>Une vulnérabilité XSS <em>persistante</em> sera celle où le script malicieux est stocké sur le site web puis affiché, sans modification, un peu plus tard par les autres utilisateurs et exécuté à leur insu.<br>
+  Par exemple, un écran de discussion qui accepte les commentaires contenant du code HTML pur peuvent stocker le script malicieux de l'attaquant. Quand les commentaires sont affichés le script est exécuté et peut ensuite transmettre à l'attaquant les informations nécessaires pour accèder au compte de l'utilisateur. Cette méthode d'attaque est extrêmement courante et efficace, parce que l'attaquant n'a pas besoin d'avoir une relation directe avec les victimes.<br>
+  <br>
+  Alors que l'envoi de données avec <code>POST</code> ou <code>GET</code> est la source la plus commune de vulnérabilité XSS, toute donnée en provenance du navigateur web est potentiellement vulnérable (cela inclut l'affichage des données des cookies par le navigateur, ou les fichiers de l'utilisateur qui sont chargés et affichés).</li>
+</ul>
+
+<p>La meilleur défense contre les vulnérabilités XSS est de supprimer ou désactiver toutes les balises qui peuvent potentiellement contenir des instructions pour exécuter du code. Pour HTML cela inclut les tags comme <code>&lt;script&gt;</code>, <code>&lt;object&gt;</code>, <code>&lt;embed&gt;</code>, et <code>&lt;link&gt;</code>.</p>
+
+<div>
+<p>Il est nécessaire de traiter les données saisies par l'utilisateur pour être sûr qu'il ne puisse ni exécuter de scripts ni pertuber le fonctionnement normal du site (ce procédé est appelé <em>input sanitization</em> en anglais). De nombreux frameworks proposent par défaut cette vérification sur les entrées des formulaires.</p>
+</div>
+
+<h3 id="Injection_SQL">Injection SQL</h3>
+
+<p>L'injection SQL est une vulnérabilité qui permet à un attaquant d'exécuter du code SQL frauduleux sur une base de données, permettant l'accès, la modification ou la suppression des données quelque soit le droit de l'utilisateur. Une attaque par injection réussie peut permettre l'usurpation d'un compte, la création d'un compte avec les droits administrateur, l'accès à toute les données du serveur, ou la modification / destruction des données pour le rendre inutilisable.</p>
+
+<p>Cette vulnérabilité est présente quand la saisie de l'utilisateur est transmise à une requête SQL sous-jacente qui peut modifier le sens de la requête. Par exemple, dans le code ci-dessous qui devrait lister l'ensemble des utilisateurs avec un nom particulier (<code>userName</code>) et qui provient d'un formulaire HTML:</p>
+
+<pre class="brush: sql">statement = "SELECT * FROM users WHERE name = '" + <strong>userName</strong> + "';"</pre>
+
+<p>Si l'utilisateur entre un nom correct cela marchera comme voulu. Cependant un utilisateur malveillant peut changer complètement le sens de cette requête SQL pour obtenir la requête qui suit, simplement en ajoutant le texte, <strong>en gras</strong> ci dessous, en tant que nom, cette requête, modifiée, va créer une requête SQL valide qui va supprimer la table <code>users</code> et sélectionner toute les données de la table <code>userinfo</code> (révèlant les informations de chaque utilisateur). Tout cela est rendu possible à cause du début du texte injecté  (<code>'a';</code>) qui va complèter la requête d'origine (<code>' </code>est le symbole pour délimiter une chaine de texte en SQL).</p>
+
+<pre class="brush: sql">SELECT * FROM users WHERE name = '<strong>a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't</strong>';
+</pre>
+
+<p>Le moyen pour éviter ce type d'attaque est de s'assurer que toute saisie de l'utilisateur transmise à une requête SQL ne peut pas changer la nature de cette requête. Un moyen de faire cela est d'<a href="https://fr.wikipedia.org/wiki/Caract%C3%A8re_d%27%C3%A9chappement">échapper</a> tous les caractères de la saisie utilisateur quand ils ont un sens particulier en SQL.</p>
+
+<div class="note">
+<p><strong>Note </strong>: la requête SQL considère le symbole ' comme le début et la fin d'une chaine de texte. En ajoutant le caractère \ nous allons "échapper" ce symbole, et dire à SQL de le traiter comme une simple partie de la chaîne de caractères.</p>
+</div>
+
+<p>Dans la requête ci-dessous nous avons échappé le caractère '. Le SQL va donc interpréter la chaine complète (en gras) comme un nom (un nom étrange en effet, mais pas nuisible).</p>
+
+<pre class="brush: sql">SELECT * FROM users WHERE name = '<strong>a\';DROP TABLE users; SELECT * FROM userinfo WHERE \'t\' = \'t'</strong>;
+
+</pre>
+
+<p>Les frameworks web se chargent bien souvent d'échapper ces caractères à votre place. Django, par exemple, s'assure que toute saisie d'un utilisateur transmise au modèle est bien échappée.</p>
+
+<div class="note">
+<p><strong>Note</strong>: Cette section s'inspire beaucoup des informations de <a href="https://en.wikipedia.org/wiki/SQL_injection">Wikipedia ici</a>.</p>
+</div>
+
+<h3 id="Falsification_de_requête_inter-sites_CSRF">Falsification de requête inter-sites (CSRF)</h3>
+
+<p>Les attaques CSRF permettent à un utilisateur malveillant d'éxécuter des actions à l'a ide des identifiants d'un autre utilisateur sans que cet utilisateur ne soit informé ou consentant.</p>
+
+<p>Ce type d'attaque s'explique mieux avec un exemple. John est l'utilisateur malveillant qui sait qu'un site particulier permet à des utilisateurs authentifiés d'envoyer de l'argent vers un compte particulier en utilisant des requêtes HTTP POST qui incluent le numéro de compte et le montant. John construit un formulaire qui inclut son numéro de compte et un montant dans des champs cachés (invisibles) et le transmet à un autre utilisateur du site (avec le bouton de validation déguisé en un lien vers un site "pour devenir riche".</p>
+
+<p>Si un utilisateur clique sur le bouton de validation, une requête HTTP POST, contenant les informations de transaction, va être transmise au serveur ainsi que le cookie que le navigateur web associe au site (l'ajout à la requête du cookie associé au site est le comportement normal du navigateur). Le serveur va vérifier le cookie d'authentification, et l'utiliser pour déterminer si l'utilisateur est ou n'est pas connecté et donc permet ou non la transaction.</p>
+
+<p>Au final tout utilisateur qui va cliquer sur le bouton de validation, alors qu'il sera connecté sur le site d'échange d'argent, va autoriser la transaction. John va devenir riche !</p>
+
+<div class="note">
+<p><strong>Note </strong>: l'astuce ici est que John n'a pas besoin d'accéder aux cookies de l'utilisateur (ou à ses identifiants), le navigateur web stocke cette information et l'inclut automatiquement dans toute les requêtes destinées au serveur associé.</p>
+</div>
+
+<p>Un moyen de prévenir ce type d'attaque est que le serveur demande que chaque requête POST possède un secret généré par le serveur et spécifique à l'utilisateur (le secret serait transmis par le serveur lors de l'envoi du formulaire de transaction). Cette approche empêche John de créer son propre formulaire car il n'est pas capable de connaitre le secret que le serveur founit à l'utilisateur. Même si il venait à trouver ce secret et créer un formulaire pour un utilisateur particulier, il ne pourrait pas utiliser ce formulaire pour attaquer d'autres utilisateurs</p>
+
+<p>Les framework web incluent souvent des mécanismes afin de prévenir les attaques CSRF.</p>
+
+<h3 id="Autre_menaces">Autre menaces</h3>
+
+<p>Les autres attaques et vulnérabilités courantes incluent:</p>
+
+<ul>
+ <li><a href="https://www.owasp.org/index.php/Clickjacking">Clickjacking</a>. Dans cette attaque un utilisateur malveillant détourne les clics destinés à un site visible et les envoie dans une page cachée en dessous. Cette technique peut être utilisée, par exemple, pour afficher le site légitime d'une banque mais capturer les identifiants d'authentification dans une &lt;iframe&gt; invisible controlée par l'attaquant. Sinon cela peut être utilisé pour obtenir de l'utilisateur qu'il clique sur le bouton visible d'un site, mais en le faisant il va en fait cliquer involontairement sur un bouton différent. Comme défense, votre site peut se prévenir d'être inclut dans une iframe d'un autre site en configurant les bonnes en-têtes HTTP.</li>
+ <li><a href="/fr/docs/Glossaire/Déni_de_service_distribué">Déni de Service</a> (DoS). Le déni de service est souvent pratiqué en surchargeant de fausses requêtes un site cible avec afin que l'accès au site soit perturbé pour les usagers légitimes. Les requêtes peuvent simplement être nombreuses, ou elles peuvent individuellement nécessiter une grande quantité de ressource (ex: chargement de fichiers lourds, etc). La défense contre cette attaque se base souvent sur l'identification et le blocage du mauvais trafic tout en autorisant l'arrivée des messages légitimes. Ces défenses sont généralement intégrées ou en amont du serveur web (elle ne font pas partie de l'application web).</li>
+ <li><a href="https://en.wikipedia.org/wiki/Directory_traversal_attack">Découverte via la navigation dans les répertoires et fichiers</a>. Dans cette famille d'attaque un utilisateur malveillant va tenter d'accèder aux fichiers du serveur web auxquels il ne devrait pas avoir accès. Cette vulnérabilité se produit quand l'utilisateur peut transmettre le nom d'un fichier qui comprend les caractères de navigation dans le système de fichier (par exemple: <code>../../</code>). La solution est de désinfecter la saisie avant de l'utiliser.</li>
+ <li><a href="https://fr.wikipedia.org/wiki/Remote_File_Inclusion">Inclusion de fichiers</a>. Dans cette attaque un utilisateur est capable de spécifier un fichier "involontaire" pour être affiché ou exécuté dans les données transmises au serveur. Une fois chargé ce fichier peut être exécuté sur le serveur web ou du côté client (menant à une attaque XSS). La solution est de vérifier les saisies avant de les utiliser.</li>
+ <li><a href="https://www.owasp.org/index.php/Command_Injection">Injection de commandes</a>. Les attaques par injection de commande permettent à un utilisateur malveillant d'exécuter des commandes systèmes frauduleuses sur le système hôte. La solution est de vérifier chaque saisie des utilisateurs avant de les utiliser dans les appels systèmes.</li>
+</ul>
+
+<p>Il y en a beaucoup d'autres. Pour une liste plus exhaustive vous pouvez consulter la catégorie <a href="https://en.wikipedia.org/wiki/Category:Web_security_exploits">failles de sécurité Web</a> (Wikipedia) et <a href="https://www.owasp.org/index.php/Category:Attack">la catégorie Attaques</a> (du projet OWASP).</p>
+
+<h2 id="Quelques_messages_clés">Quelques messages clés</h2>
+
+<p>La majorité des attaques citées précédement réusissent lorsque l'application web fait confiance aux données provenant du navigateur web. Quoique vous fassiez d'autre pour améliorer la sécurité de votre site web, vous devez désinfecter toutes les saisies des utilisateurs avant de les afficher, de les utiliser dans les requêtes SQL ou de les transmettre dans les appels du système ou du système de fichier.</p>
+
+<div class="warning">
+<p><strong>Important</strong> : la leçon la plus importante à retenir concernant la sécurité d'un site web est de ne <strong>jamais faire confiance aux données du navigateur web</strong>. Cela comprend les requêtes <code>GET</code> avec la présence des paramètres dans l'URL, les données envoyées avec les <code>POST</code>, les en-têtes HTTP, les cookies, les fichiers chargés par l'utilisateur, etc. Il faut toujours vérifier et assainir les données. Il faut toujours s'attendre au pire.</p>
+</div>
+
+<p>Quelques autres points que vous pouvez mettre en place :</p>
+
+<ul>
+ <li>Utilisez une politique de gestion des mots de passe efficace. Encouragez les mots de passe solides avec leur renouvellement fréquent. Prenez en compte une authentification à deux facteurs sur votre site (l'utilisateur, en plus du mot de passe, devra fournir un autre code d'authentification généralement fourni par un matériel physique, que seul l'utilisateur possède, comme un code envoyé sur le téléphone par SMS).</li>
+ <li>Configurez vos serveurs web pour utiliser <a href="/en-US/docs/Glossary/https">HTTPS</a> et <a href="/en-US/docs/Web/Security/HTTP_strict_transport_security">HTTP Strict Transport Security</a> (HSTS). HTTPS chiffre les données transmises entre le client et le serveur. Cela garantit que les données d'authentification, les cookies, les données transistant avec <code>POST</code> et les informations d'en-têtes deviennent moins disponibles pour l'attaquant.</li>
+ <li>Tenez vous informé des dernières menaces (<a href="/en-US/docs/">la liste actuelle d'OWASP est ici</a>) et préoccupez vous toujours des vulnerabilités les plus courantes en premier.</li>
+ <li>Utilisez <a href="https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools">des outils de recherche de vulnérabilités </a> pour faire automatiquement des recherches de bug sur votre site (votre site pourra également proposer un programme de <em>buf bounty </em>pour déceler des bugs, <a href="https://www.mozilla.org/en-US/security/bug-bounty/faq-webapp/">comme le fait Mozilla ici</a>).</li>
+ <li>Ne stockez et n'affichez que les données nécessaires. Par exemple, si votre utilisateur doit stocker des données sensibles comme des informations bancaires, affichez seulement ce qui sera suffisant pour être identifié par l'utilisateur, mais pas suffisament pour être copié par un attaquant et être utilisé sur un autre site. La méthode la plus courante en ce moment est de n'afficher que les quatre derniers chiffres du numéro de carte bancaire.</li>
+</ul>
+
+<p>Les frameworks web peuvent aider à atténuer beaucoup des vulnérabilités les plus courantes.</p>
+
+<h2 id="Résumé">Résumé</h2>
+
+<p>Cet article a présenté le concept de sécurité web et quelques-unes des menaces courantes vis-à-vis desquelles il faut se protéger. Le plus important à comprendre est qu'une application web ne peut pas faire confiance aux données provenant du navigateur ! Les données des utilisateurs doivent toutes être nettoyées avant d'être affichées ou utilisées dans les requêtes SQL ou dans les appels systèmes.</p>
+
+<p>C'est la fin de <a href="/fr/docs/Learn/Server-side/First_steps">ce module</a>, couvrant vos premiers pas dans le développement d'un site web côté serveur. Nous espérons que vous avez apprécié apprendre les concepts fondamentaux. Vous êtes désormais apte à choisir un framework web et à commencer à programmer.</p>
+
+<p>{{PreviousMenu("Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</p>