From: Lucien Gentis <lgentis@apache.org>
Date: Sat, 16 Apr 2016 16:36:26 +0000 (+0000)
Subject: XML updates.
X-Git-Tag: 2.4.21~246
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=977e515d0970257bc45f60794f4795a479e8b860;p=thirdparty%2Fapache%2Fhttpd.git

XML updates.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1739484 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/docs/manual/howto/auth.xml.fr b/docs/manual/howto/auth.xml.fr
index d31069d485c..10eef4088c7 100644
--- a/docs/manual/howto/auth.xml.fr
+++ b/docs/manual/howto/auth.xml.fr
@@ -1,7 +1,7 @@
-<?xml version="1.0" encoding="ISO-8859-1" ?>
+<?xml version="1.0" encoding="UTF-8" ?>
 <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1673563:1738542 (outdated) -->
+<!-- English Revision: 1738542 -->
 <!-- French translation : Lucien GENTIS -->
 <!-- Reviwed by : Vincent Deffontaines -->
 
@@ -28,18 +28,18 @@
 <title>Authentification et autorisation</title>
 
 <summary>
-    <p>L'authentification est un processus qui vous permet de v&eacute;rifier
-    qu'une personne est bien celle qu'elle pr&eacute;tend &ecirc;tre. L'autorisation
-    est un processus qui permet &agrave; une personne d'aller l&agrave; o&ugrave; elle veut
-    aller, ou d'obtenir les informations qu'elle d&eacute;sire.</p>
+    <p>L'authentification est un processus qui vous permet de vérifier
+    qu'une personne est bien celle qu'elle prétend être. L'autorisation
+    est un processus qui permet à une personne d'aller là où elle veut
+    aller, ou d'obtenir les informations qu'elle désire.</p>
 
-    <p>Pour le contr&ocirc;le d'acc&egrave;s en g&eacute;n&eacute;ral, voir le How-To <a
-    href="access.html">Contr&ocirc;le d'acc&egrave;s</a>.</p>
+    <p>Pour le contrôle d'accès en général, voir le How-To <a
+    href="access.html">Contrôle d'accès</a>.</p>
 </summary>
 
-<section id="related"><title>Modules et directives concern&eacute;s</title>
+<section id="related"><title>Modules et directives concernés</title>
 
-<p>Trois groupes de modules sont concern&eacute;s par le processus
+<p>Trois groupes de modules sont concernés par le processus
 d'authentification et d'autorisation. Vous devrez utiliser au moins un
 module de chaque groupe.</p>
 
@@ -79,57 +79,57 @@ module de chaque groupe.</p>
 </ul>
 
   <p>On peut aussi ajouter <module>mod_authn_core</module> et
-  <module>mod_authz_core</module>. Ces modules impl&eacute;mentent des
-  directives g&eacute;n&eacute;rales qui op&egrave;rent au dessus de tous les modules
+  <module>mod_authz_core</module>. Ces modules implémentent des
+  directives générales qui opèrent au dessus de tous les modules
   d'authentification.</p>
 
   <p>Le module <module>mod_authnz_ldap</module> est un fournisseur
   d'authentification et d'autorisation. Le module
   <module>mod_authz_host</module> fournit une autorisation et un
-  contr&ocirc;le d'acc&egrave;s bas&eacute;s sur le nom du serveur, l'adresse IP ou
-  certaines caract&eacute;ristiques de la requ&ecirc;te, mais ne fait pas partie du
-  syst&egrave;me fournisseur d'authentification. Le module
-  <module>mod_access_compat</module> a &eacute;t&eacute; cr&eacute;&eacute; &agrave; des fins de
-  compatibilit&eacute; ascendante avec mod_access.</p>
+  contrôle d'accès basés sur le nom du serveur, l'adresse IP ou
+  certaines caractéristiques de la requête, mais ne fait pas partie du
+  système fournisseur d'authentification. Le module
+  <module>mod_access_compat</module> a été créé à des fins de
+  compatibilité ascendante avec mod_access.</p>
 
   <p>Vous devriez aussi jeter un coup d'oeil au manuel de recettes de <a
-  href="access.html">Contr&ocirc;le d'acc&egrave;s</a>, qui d&eacute;crit les diff&eacute;rentes
-  m&eacute;thodes de contr&ocirc;le d'acc&egrave;s &agrave; votre serveur.</p>
+  href="access.html">Contrôle d'accès</a>, qui décrit les différentes
+  méthodes de contrôle d'accès à votre serveur.</p>
 
 </section>
 
 <section id="introduction"><title>Introduction</title>
     <p>Si votre site web contient des informations sensibles ou
-    destin&eacute;es seulement &agrave; un groupe de personnes restreint, les
-    techniques expos&eacute;es dans cet article vont vous aider &agrave; vous assurer
-    que les personnes qui ont acc&egrave;s &agrave; ces pages sont bien celles
-    auxquelles vous avez donn&eacute; l'autorisation d'acc&egrave;s.</p>
+    destinées seulement à un groupe de personnes restreint, les
+    techniques exposées dans cet article vont vous aider à vous assurer
+    que les personnes qui ont accès à ces pages sont bien celles
+    auxquelles vous avez donné l'autorisation d'accès.</p>
 
-    <p>Cet article d&eacute;crit les m&eacute;thodes "standards" de protection de
-    parties de votre site web que la plupart d'entre vous sont appel&eacute;s &agrave;
+    <p>Cet article décrit les méthodes "standards" de protection de
+    parties de votre site web que la plupart d'entre vous sont appelés à
     utiliser.</p>
 
     <note><title>Note :</title>
-    <p>Si vos donn&eacute;es ont un r&eacute;el besoin de s&eacute;curisation, pr&eacute;voyez
-    l'utilisation de <module>mod_ssl</module> en plus de toute m&eacute;thode
+    <p>Si vos données ont un réel besoin de sécurisation, prévoyez
+    l'utilisation de <module>mod_ssl</module> en plus de toute méthode
     d'authentification.</p>
     </note>
 </section>
 
-<section id="theprerequisites"><title>Les pr&eacute;requis</title>
-    <p>Les directives d&eacute;crites dans cet article devront &ecirc;tre ins&eacute;r&eacute;es
+<section id="theprerequisites"><title>Les prérequis</title>
+    <p>Les directives décrites dans cet article devront être insérées
     soit au niveau de la configuration de votre serveur principal (en
-    g&eacute;n&eacute;ral dans une section <directive module="core"
+    général dans une section <directive module="core"
     type="section">Directory</directive>), soit au niveau de la
-    configuration des r&eacute;pertoires (fichiers <code>.htaccess</code>)</p>
+    configuration des répertoires (fichiers <code>.htaccess</code>)</p>
 
     <p>Si vous envisagez l'utilisation de fichiers
     <code>.htaccess</code>, la configuration de votre serveur devra
     permettre l'ajout de directives d'authentification dans ces
     fichiers. Pour ce faire, on utilise la directive <directive
-    module="core">AllowOverride</directive>, qui sp&eacute;cifie quelles
-    directives pourront &eacute;ventuellement contenir les fichiers de
-    configuration de niveau r&eacute;pertoire.</p>
+    module="core">AllowOverride</directive>, qui spécifie quelles
+    directives pourront éventuellement contenir les fichiers de
+    configuration de niveau répertoire.</p>
 
     <p>Comme il est ici question d'authentification, vous aurez besoin
     d'une directive <directive module="core">AllowOverride</directive>
@@ -139,47 +139,47 @@ module de chaque groupe.</p>
 
     <p>Si vous avez l'intention d'ajouter les directives directement
     dans le fichier de configuration principal, vous devrez bien entendu
-    poss&eacute;der les droits en &eacute;criture sur ce fichier.</p>
+    posséder les droits en écriture sur ce fichier.</p>
 
-    <p>Vous devrez aussi conna&icirc;tre un tant soit peu la structure des
-    r&eacute;pertoires de votre serveur, ne serait-ce que pour savoir o&ugrave; se
-    trouvent certains fichiers. Cela ne devrait pas pr&eacute;senter de grandes
-    difficult&eacute;s, et nous essaierons de clarifier tout &ccedil;a lorsque le besoin
+    <p>Vous devrez aussi connaître un tant soit peu la structure des
+    répertoires de votre serveur, ne serait-ce que pour savoir où se
+    trouvent certains fichiers. Cela ne devrait pas présenter de grandes
+    difficultés, et nous essaierons de clarifier tout ça lorsque le besoin
     s'en fera sentir.</p>
 
     <p>Enfin, vous devrez vous assurer que les modules
     <module>mod_authn_core</module> et <module>mod_authz_core</module>
-    ont &eacute;t&eacute; soit compil&eacute;s avec le binaire httpd, soit charg&eacute;s par le
+    ont été soit compilés avec le binaire httpd, soit chargés par le
     fichier de configuration httpd.conf. Ces deux modules fournissent
-    des directives g&eacute;n&eacute;rales et des fonctionnalit&eacute;s qui sont critiques
-    quant &agrave; la configuration et l'utilisation de l'authentification et
+    des directives générales et des fonctionnalités qui sont critiques
+    quant à la configuration et l'utilisation de l'authentification et
     de l'autorisation au sein du serveur web.</p>
 </section>
 
 <section id="gettingitworking"><title>Mise en oeuvre</title>
-    <p>Nous d&eacute;crivons ici les bases de la protection par mot de passe
-    d'un r&eacute;pertoire de votre serveur.</p>
+    <p>Nous décrivons ici les bases de la protection par mot de passe
+    d'un répertoire de votre serveur.</p>
 
-    <p>Vous devez en premier lieu cr&eacute;er un fichier de mots de passe. La
-    m&eacute;thode exacte selon laquelle vous allez cr&eacute;er ce fichier va varier
+    <p>Vous devez en premier lieu créer un fichier de mots de passe. La
+    méthode exacte selon laquelle vous allez créer ce fichier va varier
     en fonction du fournisseur d'authentification choisi. Mais nous
-    entrerons dans les d&eacute;tails plus loin, et pour le moment, nous nous
+    entrerons dans les détails plus loin, et pour le moment, nous nous
     contenterons d'un fichier de mots de passe en mode texte.</p>
 
-    <p>Ce fichier doit &ecirc;tre enregistr&eacute; &agrave; un endroit non accessible
-    depuis le web, de fa&ccedil;on &agrave; ce que les clients ne puissent pas le
-    t&eacute;l&eacute;charger. Par exemple, si vos documents sont servis &agrave; partir de
+    <p>Ce fichier doit être enregistré à un endroit non accessible
+    depuis le web, de façon à ce que les clients ne puissent pas le
+    télécharger. Par exemple, si vos documents sont servis à partir de
     <code>/usr/local/apache/htdocs</code>, vous pouvez enregistrer le
     fichier des mots de passe dans
     <code>/usr/local/apache/passwd</code>.</p>
 
     <p>L'utilitaire <program>htpasswd</program> fourni avec Apache
-    permet de cr&eacute;er ce fichier. Vous le trouverez dans le r&eacute;pertoire
+    permet de créer ce fichier. Vous le trouverez dans le répertoire
     <code>bin</code> de votre installation d'Apache. Si vous avez
-    install&eacute; Apache &agrave; partir d'un paquetage tiers, il sera probablement
-    dans le chemin par d&eacute;faut de vos ex&eacute;cutables.</p>
+    installé Apache à partir d'un paquetage tiers, il sera probablement
+    dans le chemin par défaut de vos exécutables.</p>
 
-    <p>Pour cr&eacute;er le fichier, tapez :</p>
+    <p>Pour créer le fichier, tapez :</p>
 
     <example>
       htpasswd -c /usr/local/apache/passwd/passwords rbowen
@@ -196,19 +196,19 @@ module de chaque groupe.</p>
     </example>
 
     <p>Si <program>htpasswd</program> n'est pas dans le chemin par
-    d&eacute;faut de vos ex&eacute;cutables, vous devrez bien entendu entrer le chemin
-    complet du fichier. Dans le cas d'une installation par d&eacute;faut, il se
-    trouve &agrave; <code>/usr/local/apache2/bin/htpasswd</code>.</p>
+    défaut de vos exécutables, vous devrez bien entendu entrer le chemin
+    complet du fichier. Dans le cas d'une installation par défaut, il se
+    trouve à <code>/usr/local/apache2/bin/htpasswd</code>.</p>
 
-    <p>Ensuite, vous allez devoir configurer le serveur de fa&ccedil;on &agrave; ce
-    qu'il demande un mot de passe et lui pr&eacute;ciser quels utilisateurs ont
-    l'autorisation d'acc&egrave;s. Pour ce faire, vous pouvez soit &eacute;diter le
+    <p>Ensuite, vous allez devoir configurer le serveur de façon à ce
+    qu'il demande un mot de passe et lui préciser quels utilisateurs ont
+    l'autorisation d'accès. Pour ce faire, vous pouvez soit éditer le
     fichier <code>httpd.conf</code>, soit utiliser un fichier
-    <code>.htaccess</code>. Par exemple, si vous voulez prot&eacute;ger le
-    r&eacute;pertoire <code>/usr/local/apache/htdocs/secret</code>, vous pouvez
+    <code>.htaccess</code>. Par exemple, si vous voulez protéger le
+    répertoire <code>/usr/local/apache/htdocs/secret</code>, vous pouvez
     utiliser les directives suivantes, soit dans le fichier
     <code>/usr/local/apache/htdocs/secret/.htaccess</code>, soit dans le
-    fichier <code>httpd.conf</code> &agrave; l'int&eacute;rieur d'une section &lt;Directory
+    fichier <code>httpd.conf</code> à l'intérieur d'une section &lt;Directory
     "/usr/local/apache/htdocs/secret"&gt; :</p>
 
     <highlight language="config">
@@ -220,106 +220,106 @@ AuthUserFile "/usr/local/apache/passwd/passwords"
 Require user rbowen
     </highlight>
 
-    <p>Examinons ces directives une &agrave; une. La directive <directive
-    module="mod_authn_core">AuthType</directive> d&eacute;finit la m&eacute;thode
-    utilis&eacute;e pour authentifier l'utilisateur. La m&eacute;thode la plus
-    courante est <code>Basic</code>, et elle est impl&eacute;ment&eacute;e par
-    <module>mod_auth_basic</module>. Il faut cependant garder &agrave; l'esprit
+    <p>Examinons ces directives une à une. La directive <directive
+    module="mod_authn_core">AuthType</directive> définit la méthode
+    utilisée pour authentifier l'utilisateur. La méthode la plus
+    courante est <code>Basic</code>, et elle est implémentée par
+    <module>mod_auth_basic</module>. Il faut cependant garder à l'esprit
     que l'authentification Basic transmet le mot de passe depuis le
-    client vers le serveur en clair. Cette m&eacute;thode ne devra donc pas
-    &ecirc;tre utilis&eacute;e pour la transmission de donn&eacute;es hautement sensibles si
-    elle n'est pas associ&eacute;e au module <module>mod_ssl</module>. Apache
-    supporte une autre m&eacute;thode d'authentification : <code>AuthType
-    Digest</code>. Cette m&eacute;thode est impl&eacute;ment&eacute;e par le module <module
-    >mod_auth_digest</module> et a &eacute;t&eacute; con&ccedil;ue pour
-    am&eacute;liorer la s&eacute;curit&eacute;. Ce but n'a cependant pas &eacute;t&eacute; atteint et il est pr&eacute;f&eacute;rable
+    client vers le serveur en clair. Cette méthode ne devra donc pas
+    être utilisée pour la transmission de données hautement sensibles si
+    elle n'est pas associée au module <module>mod_ssl</module>. Apache
+    supporte une autre méthode d'authentification : <code>AuthType
+    Digest</code>. Cette méthode est implémentée par le module <module
+    >mod_auth_digest</module> et a été conçue pour
+    améliorer la sécurité. Ce but n'a cependant pas été atteint et il est préférable
     de chiffrer la connexion avec <module>mod_ssl</module>.</p>
 
     <p>La directive <directive
-    module="mod_authn_core">AuthName</directive> d&eacute;finit
-    l'<dfn>Identificateur</dfn> (Realm) &agrave; utiliser avec
-    l'authentification. L'identificateur poss&egrave;de deux fonctions. Tout
-    d'abord, le client pr&eacute;sente en g&eacute;n&eacute;ral cette information &agrave;
-    l'utilisateur dans le cadre de la bo&icirc;te de dialogue de mot de passe.
-    Ensuite, le client l'utilise pour d&eacute;terminer quel mot de passe
-    envoyer pour une zone authentifi&eacute;e donn&eacute;e.</p>
-
-    <p>Ainsi par exemple, une fois un client authentifi&eacute; dans la zone
-    <code>"Fichiers r&eacute;serv&eacute;s"</code>, il soumettra &agrave; nouveau
-    automatiquement le m&ecirc;me mot de passe pour toute zone du m&ecirc;me serveur
-    marqu&eacute;e de l'identificateur <code>"Fichiers r&eacute;serv&eacute;s"</code>. De
-    cette fa&ccedil;on, vous pouvez &eacute;viter &agrave; un utilisateur d'avoir &agrave; saisir
-    plusieurs fois le m&ecirc;me mot de passe en faisant partager le m&ecirc;me
-    identificateur entre plusieurs zones r&eacute;serv&eacute;es. Bien entendu et pour
-    des raisons de s&eacute;curit&eacute;, le client devra redemander le mot
-    de passe chaque fois que le nom d'h&ocirc;te du serveur sera modifi&eacute;.</p>
+    module="mod_authn_core">AuthName</directive> définit
+    l'<dfn>Identificateur</dfn> (Realm) à utiliser avec
+    l'authentification. L'identificateur possède deux fonctions. Tout
+    d'abord, le client présente en général cette information à
+    l'utilisateur dans le cadre de la boîte de dialogue de mot de passe.
+    Ensuite, le client l'utilise pour déterminer quel mot de passe
+    envoyer pour une zone authentifiée donnée.</p>
+
+    <p>Ainsi par exemple, une fois un client authentifié dans la zone
+    <code>"Fichiers réservés"</code>, il soumettra à nouveau
+    automatiquement le même mot de passe pour toute zone du même serveur
+    marquée de l'identificateur <code>"Fichiers réservés"</code>. De
+    cette façon, vous pouvez éviter à un utilisateur d'avoir à saisir
+    plusieurs fois le même mot de passe en faisant partager le même
+    identificateur entre plusieurs zones réservées. Bien entendu et pour
+    des raisons de sécurité, le client devra redemander le mot
+    de passe chaque fois que le nom d'hôte du serveur sera modifié.</p>
 
     <p>La directive <directive
     module="mod_auth_basic">AuthBasicProvider</directive> est, dans ce
-    cas, facultative, car <code>file</code> est la valeur par d&eacute;faut
+    cas, facultative, car <code>file</code> est la valeur par défaut
     pour cette directive. Par contre, cette directive sera obligatoire
     si vous utilisez une autre source d'authentification comme
     <module>mod_authn_dbm</module> ou
     <module>mod_authn_dbd</module>.</p>
 
     <p>La directive <directive
-    module="mod_authn_file">AuthUserFile</directive> d&eacute;finit le chemin
-    du fichier de mots de passe que nous venons de cr&eacute;er avec
-    <program>htpasswd</program>. Si vous poss&eacute;dez un grand nombre
-    d'utilisateurs, la dur&eacute;e de la recherche dans un fichier texte pour
-    authentifier un utilisateur &agrave; chaque requ&ecirc;te va augmenter
-    rapidement, et pour pallier cet inconv&eacute;nient, Apache peut aussi
-    stocker les donn&eacute;es relatives aux
-    utilisateurs dans des bases de donn&eacute;es rapides. Le module
+    module="mod_authn_file">AuthUserFile</directive> définit le chemin
+    du fichier de mots de passe que nous venons de créer avec
+    <program>htpasswd</program>. Si vous possédez un grand nombre
+    d'utilisateurs, la durée de la recherche dans un fichier texte pour
+    authentifier un utilisateur à chaque requête va augmenter
+    rapidement, et pour pallier cet inconvénient, Apache peut aussi
+    stocker les données relatives aux
+    utilisateurs dans des bases de données rapides. Le module
     <module>mod_authn_dbm</module> fournit la directive <directive
     module="mod_authn_dbm">AuthDBMUserFile</directive>. Les programmes <program>
     dbmmanage</program> et <program>htdbm</program> permettent de
-    cr&eacute;er et manipuler ces fichiers. Vous
+    créer et manipuler ces fichiers. Vous
     trouverez de nombreuses options d'autres types d'authentification
     fournies par des modules tiers dans la <a
-    href="http://modules.apache.org/">Base de donn&eacute;es des modules
+    href="http://modules.apache.org/">Base de données des modules
     d'Apache</a>.</p>
 
     <p>Enfin, la directive <directive
-    module="mod_authz_core">Require</directive> impl&eacute;mente la partie
-    autorisation du processus en d&eacute;finissant l'utilisateur autoris&eacute; &agrave;
-    acc&eacute;der &agrave; cette zone du serveur. Dans la section suivante, nous
-    d&eacute;crirons les diff&eacute;rentes m&eacute;thodes d'utilisation de la directive
+    module="mod_authz_core">Require</directive> implémente la partie
+    autorisation du processus en définissant l'utilisateur autorisé à
+    accéder à cette zone du serveur. Dans la section suivante, nous
+    décrirons les différentes méthodes d'utilisation de la directive
     <directive module="mod_authz_core">Require</directive>.</p>
 </section>
 
-<section id="lettingmorethanonepersonin"><title>Autorisation d'acc&egrave;s &agrave;
+<section id="lettingmorethanonepersonin"><title>Autorisation d'accès à
 plusieurs personnes</title>
     <p>Les directives ci-dessus n'autorisent qu'une personne (quelqu'un
-    poss&eacute;dant le nom d'utilisateur <code>rbowen</code>) &agrave; acc&eacute;der au
-    r&eacute;pertoire. Dans la plupart des cas, vous devrez autoriser
-    l'acc&egrave;s &agrave; plusieurs personnes. C'est ici
+    possédant le nom d'utilisateur <code>rbowen</code>) à accéder au
+    répertoire. Dans la plupart des cas, vous devrez autoriser
+    l'accès à plusieurs personnes. C'est ici
     qu'intervient la directive <directive module="mod_authz_groupfile"
     >AuthGroupFile</directive>.</p>
 
-    <p>Si vous voulez autoriser l'acc&egrave;s &agrave; plusieurs personnes, vous
-    devez cr&eacute;er un fichier de groupes qui associe des noms de groupes
+    <p>Si vous voulez autoriser l'accès à plusieurs personnes, vous
+    devez créer un fichier de groupes qui associe des noms de groupes
     avec une liste d'utilisateurs de ce groupe. Le format de ce fichier
-    est tr&egrave;s simple, et vous pouvez le cr&eacute;er avec votre &eacute;diteur favori.
-    Son contenu se pr&eacute;sente comme suit :</p>
+    est très simple, et vous pouvez le créer avec votre éditeur favori.
+    Son contenu se présente comme suit :</p>
 
    <example>
      Nom-de-groupe: rbowen dpitts sungo rshersey
    </example>
 
     <p>Il s'agit simplement une liste des membres du groupe sous la
-    forme d'une ligne s&eacute;par&eacute;e par des espaces.</p>
+    forme d'une ligne séparée par des espaces.</p>
 
-    <p>Pour ajouter un utilisateur &agrave; votre fichier de mots de passe
-    pr&eacute;existant, entrez :</p>
+    <p>Pour ajouter un utilisateur à votre fichier de mots de passe
+    préexistant, entrez :</p>
 
     <example>
       htpasswd /usr/local/apache/passwd/passwords dpitts
     </example>
 
-    <p>Vous obtiendrez le m&ecirc;me effet qu'auparavant, mais le mot de passe
-    sera ajout&eacute; au fichier, plut&ocirc;t que d'en cr&eacute;er un nouveau (C'est le
-    drapeau <code>-c</code> qui permet de cr&eacute;er un nouveau fichier de
+    <p>Vous obtiendrez le même effet qu'auparavant, mais le mot de passe
+    sera ajouté au fichier, plutôt que d'en créer un nouveau (C'est le
+    drapeau <code>-c</code> qui permet de créer un nouveau fichier de
     mots de passe)..</p>
 
     <p>Maintenant, vous devez modifier votre fichier
@@ -337,58 +337,58 @@ Require group GroupName
     </highlight>
 
     <p>Maintenant, quiconque appartient au groupe
-    <code>Nom-de-groupe</code>, et poss&egrave;de une entr&eacute;e dans le fichier
-    <code>password</code> pourra acc&eacute;der au r&eacute;pertoire s'il tape le bon
+    <code>Nom-de-groupe</code>, et possède une entrée dans le fichier
+    <code>password</code> pourra accéder au répertoire s'il tape le bon
     mot de passe.</p>
 
-    <p>Il existe une autre m&eacute;thode moins contraignante pour autoriser
-    l'acc&egrave;s &agrave; plusieurs personnes. Plut&ocirc;t que de cr&eacute;er un fichier de
+    <p>Il existe une autre méthode moins contraignante pour autoriser
+    l'accès à plusieurs personnes. Plutôt que de créer un fichier de
     groupes, il vous suffit d'ajouter la directive suivante :</p>
 
     <highlight language="config">Require valid-user</highlight>
 
     <p>Le remplacement de la ligne <code>Require user rbowen</code> par
-    la ligne <code>Require valid-user</code> autorisera l'acc&egrave;s &agrave;
-    quiconque poss&eacute;dant une entr&eacute;e dans le fichier password, et ayant
-    tap&eacute; le bon mot de passe.</p>
+    la ligne <code>Require valid-user</code> autorisera l'accès à
+    quiconque possédant une entrée dans le fichier password, et ayant
+    tapé le bon mot de passe.</p>
 </section>
 
-<section id="possibleproblems"><title>Probl&egrave;mes possibles</title>
-    <p>L'authentification Basic est sp&eacute;cifi&eacute;e d'une telle mani&egrave;re que
-    vos nom d'utilisateur et mot de passe doivent &ecirc;tre v&eacute;rifi&eacute;s chaque
-    fois que vous demandez un document au serveur, et ceci m&ecirc;me si vous
-    rechargez la m&ecirc;me page, et pour chaque image contenue dans la page
-    (si elles sont situ&eacute;es dans un r&eacute;pertoire prot&eacute;g&eacute;). Comme vous
+<section id="possibleproblems"><title>Problèmes possibles</title>
+    <p>L'authentification Basic est spécifiée d'une telle manière que
+    vos nom d'utilisateur et mot de passe doivent être vérifiés chaque
+    fois que vous demandez un document au serveur, et ceci même si vous
+    rechargez la même page, et pour chaque image contenue dans la page
+    (si elles sont situées dans un répertoire protégé). Comme vous
     pouvez l'imaginer, ceci ralentit un peu le fonctionnement. La mesure
-    dans laquelle le fonctionnement est ralenti est proportionnelle &agrave; la
-    taille du fichier des mots de passe, car ce dernier doit &ecirc;tre ouvert
-    et la liste des utilisateurs parcourue jusqu'&agrave; ce que votre nom soit
-    trouv&eacute;, et ceci chaque fois qu'une page est charg&eacute;e.</p>
+    dans laquelle le fonctionnement est ralenti est proportionnelle à la
+    taille du fichier des mots de passe, car ce dernier doit être ouvert
+    et la liste des utilisateurs parcourue jusqu'à ce que votre nom soit
+    trouvé, et ceci chaque fois qu'une page est chargée.</p>
 
-    <p>En cons&eacute;quence, ce ralentissement impose une limite pratique au
+    <p>En conséquence, ce ralentissement impose une limite pratique au
     nombre d'utilisateurs que vous pouvez enregistrer dans un fichier de
     mots de passe. Cette limite va varier en fonction des performances
-    de votre serveur, mais vous commencerez &agrave; remarquer un
+    de votre serveur, mais vous commencerez à remarquer un
     ralentissement lorsque vous atteindrez quelques centaines
-    d'utilisateurs, et serez alors appel&eacute;s &agrave; utiliser une m&eacute;thode
-    d'authentification diff&eacute;rente.</p>
+    d'utilisateurs, et serez alors appelés à utiliser une méthode
+    d'authentification différente.</p>
 </section>
 
-<section id="dbmdbd"><title>Autre m&eacute;thode de stockage des mots de
+<section id="dbmdbd"><title>Autre méthode de stockage des mots de
 passe</title>
 
-    <p>Suite au probl&egrave;me &eacute;voqu&eacute; pr&eacute;c&eacute;demment et induit par le stockage
-    des mots de passe dans un fichier texte, vous pouvez &ecirc;tre appel&eacute; &agrave;
-    stocker vos mots de passe d'une autre mani&egrave;re, par exemple dans une
-    base de donn&eacute;es.</p>
+    <p>Suite au problème évoqué précédemment et induit par le stockage
+    des mots de passe dans un fichier texte, vous pouvez être appelé à
+    stocker vos mots de passe d'une autre manière, par exemple dans une
+    base de données.</p>
 
     <p>Pour y parvenir, on peut utiliser les modules
     <module>mod_authn_dbm</module> ou <module>mod_authn_dbd</module>.
     Vous pouvez choisir comme format de stockage <code>dbm</code> ou
-    <code>dbd</code> &agrave; la place de <code>file</code> pour la directive
+    <code>dbd</code> à la place de <code>file</code> pour la directive
     <directive module="mod_auth_basic">AuthBasicProvider</directive>.</p>
 
-    <p>Par exemple, pour s&eacute;lectionner un fichier dbm &agrave; la place d'un
+    <p>Par exemple, pour sélectionner un fichier dbm à la place d'un
     fichier texte :</p>
 
     <highlight language="config">
@@ -404,18 +404,18 @@ passe</title>
     </highlight>
 
     <p>D'autres options sont disponibles. Consultez la documentation de
-    <module>mod_authn_dbm</module> pour plus de d&eacute;tails.</p>
+    <module>mod_authn_dbm</module> pour plus de détails.</p>
 </section>
 
 <section id="multprovider"><title>Utilisation de plusieurs fournisseurs
 d'authentification</title>
 
-    <p>Depuis l'arriv&eacute;e des nouvelles architecture d'autorisation et
-    d'authentification bas&eacute;es sur les fournisseurs, vous n'&ecirc;tes plus
-    limit&eacute; &agrave; une m&eacute;thode d'authentification et d'autorisation
+    <p>Depuis l'arrivée des nouvelles architecture d'autorisation et
+    d'authentification basées sur les fournisseurs, vous n'êtes plus
+    limité à une méthode d'authentification et d'autorisation
     unique. En fait, on peut panacher autant de fournisseurs que l'on
-    veut, ce qui vous permet d'&eacute;laborer l'architecture qui correspond
-    exactement &agrave; vos besoins. Dans l'exemple suivant, on utilise
+    veut, ce qui vous permet d'élaborer l'architecture qui correspond
+    exactement à vos besoins. Dans l'exemple suivant, on utilise
     conjointement les fournisseurs d'authentification
     file et LDAP :</p>
 
@@ -434,18 +434,18 @@ d'authentification</title>
 
     <p>Dans cet exemple, le fournisseur file va tenter d'authentifier
     l'utilisateur en premier. S'il n'y parvient pas, le fournisseur LDAP
-    sera sollicit&eacute;. Ceci permet l'&eacute;largissement des possibilit&eacute;s
-    d'authentification si votre organisation impl&eacute;mente plusieurs types
-    de bases d'authentification. D'autres sc&eacute;narios d'authentification
+    sera sollicité. Ceci permet l'élargissement des possibilités
+    d'authentification si votre organisation implémente plusieurs types
+    de bases d'authentification. D'autres scénarios d'authentification
     et d'autorisation peuvent associer un type d'authentification avec
     un autre type d'autorisation. Par exemple, une authentification
-    bas&eacute;e sur un fichier de mots de passe peut permettre l'attribution
-    d'autorisations bas&eacute;e sur un annuaire LDAP.</p>
+    basée sur un fichier de mots de passe peut permettre l'attribution
+    d'autorisations basée sur un annuaire LDAP.</p>
 
-    <p>Tout comme plusieurs fournisseurs d'authentification peuvent &ecirc;tre
-    impl&eacute;ment&eacute;s, on peut aussi utiliser plusieurs m&eacute;thodes
-    d'autorisation. Dans l'exemple suivant, on utilise &agrave; la fois une
-    autorisation &agrave; base de fichier de groupes et une autorisation &agrave; base
+    <p>Tout comme plusieurs fournisseurs d'authentification peuvent être
+    implémentés, on peut aussi utiliser plusieurs méthodes
+    d'autorisation. Dans l'exemple suivant, on utilise à la fois une
+    autorisation à base de fichier de groupes et une autorisation à base
     de groupes LDAP.</p>
 
     <highlight language="config">
@@ -463,46 +463,46 @@ d'authentification</title>
 &lt;/Directory&gt;
     </highlight>
 
-    <p>Pour un sc&eacute;nario d'autorisation un peu plus avanc&eacute;, des
+    <p>Pour un scénario d'autorisation un peu plus avancé, des
     directives de conteneur d'autorisation comme <directive
     module="mod_authz_core" type="section">RequireAll</directive> et
     <directive module="mod_authz_core"
     type="section">RequireAny</directive> permettent d'appliquer une
     logique telle que l'ordre dans lequel les autorisations sont
-    appliqu&eacute;es peut &ecirc;tre enti&egrave;rement contr&ocirc;l&eacute; au niveau de la
+    appliquées peut être entièrement contrôlé au niveau de la
     configuration. Voir <a
     href="../mod/mod_authz_core.html#logic">Conteneurs
-    d'autorisations</a> pour un exemple de ce contr&ocirc;le.</p>
+    d'autorisations</a> pour un exemple de ce contrôle.</p>
 
 </section>
 
 <section id="beyond"><title>Pour aller plus loin qu'une simple
 autorisation</title>
 
-    <p>La mani&egrave;re dont les autorisations sont accord&eacute;es est d&eacute;sormais
-    beaucoup plus souple qu'une simple v&eacute;rification aupr&egrave;s d'une seule
-    base de donn&eacute;es. Il est maintenant possible de choisir l'ordre, la
-    logique et la mani&egrave;re selon lesquels une autorisation est
-    accord&eacute;e.</p>
+    <p>La manière dont les autorisations sont accordées est désormais
+    beaucoup plus souple qu'une simple vérification auprès d'une seule
+    base de données. Il est maintenant possible de choisir l'ordre, la
+    logique et la manière selon lesquels une autorisation est
+    accordée.</p>
 
     <section id="authandororder"><title>Appliquer logique et
     ordonnancement</title>
-        <p>Le contr&ocirc;le de la mani&egrave;re et de l'ordre selon lesquels le
-	processus d'autorisation &eacute;tait appliqu&eacute;
-	constituait une sorte de myst&egrave;re par
-	le pass&eacute;. Dans Apache 2.2, un m&eacute;canisme d'authentification bas&eacute;
-	sur les fournisseurs a &eacute;t&eacute; d&eacute;velopp&eacute; afin de s&eacute;parer le
-	v&eacute;ritable processus d'authentification de l'autorisation et ses
-	diff&eacute;rentes fonctionnalit&eacute;s. Un des avantages colat&eacute;raux
-	r&eacute;sidait dans le fait que les fournisseurs d'authentification
-	pouvaient &ecirc;tre configur&eacute;s et appel&eacute;s selon un ordre particulier
-	ind&eacute;pendant de l'ordre de chargement du module auth proprement
-	dit. Ce m&eacute;canisme bas&eacute; sur les fournisseurs a &eacute;t&eacute; &eacute;tendu au
+        <p>Le contrôle de la manière et de l'ordre selon lesquels le
+	processus d'autorisation était appliqué
+	constituait une sorte de mystère par
+	le passé. Dans Apache 2.2, un mécanisme d'authentification basé
+	sur les fournisseurs a été développé afin de séparer le
+	véritable processus d'authentification de l'autorisation et ses
+	différentes fonctionnalités. Un des avantages colatéraux
+	résidait dans le fait que les fournisseurs d'authentification
+	pouvaient être configurés et appelés selon un ordre particulier
+	indépendant de l'ordre de chargement du module auth proprement
+	dit. Ce mécanisme basé sur les fournisseurs a été étendu au
 	processus d'autorisation. Ceci signifie que la directive
-	<directive module="mod_authz_core">Require</directive> d&eacute;finit
-	non seulement quelles m&eacute;thodes d'autorisation doivent &ecirc;tre
-	utilis&eacute;es, mais aussi l'ordre dans lequel elles sont appel&eacute;es.
-	Les m&eacute;thodes d'autorisation sont appel&eacute;es selon l'ordre dans
+	<directive module="mod_authz_core">Require</directive> définit
+	non seulement quelles méthodes d'autorisation doivent être
+	utilisées, mais aussi l'ordre dans lequel elles sont appelées.
+	Les méthodes d'autorisation sont appelées selon l'ordre dans
 	lequel les directives <directive
 	module="mod_authz_core">Require</directive> apparaissent dans la
 	configuration.</p>
@@ -512,56 +512,56 @@ autorisation</title>
 	type="section">RequireAll</directive>
  	et <directive module="mod_authz_core"
 	type="section">RequireAny</directive>, la
-	configuration contr&ocirc;le aussi le moment o&ugrave; les m&eacute;thodes
-	d'autorisation sont appel&eacute;es, et quels crit&egrave;res d&eacute;terminent
-	l'autorisation d'acc&egrave;s. Voir <a
+	configuration contrôle aussi le moment où les méthodes
+	d'autorisation sont appelées, et quels critères déterminent
+	l'autorisation d'accès. Voir <a
 	href="../mod/mod_authz_core.html#logic">Conteneurs
-	d'autorisations</a> pour un exemple de la mani&egrave;re de les
+	d'autorisations</a> pour un exemple de la manière de les
 	utiliser pour exprimer des logiques d'autorisation
 	complexes.</p>
 
-        <p>Par d&eacute;faut, toutes les directives <directive
+        <p>Par défaut, toutes les directives <directive
 	module="mod_authz_core">Require</directive> sont
-	trait&eacute;es comme si elles &eacute;taient contenues dans une directive
+	traitées comme si elles étaient contenues dans une directive
 	<directive module="mod_authz_core"
 	type="section">RequireAny</directive>. En d'autres termes, il
 	suffit
-	qu'une m&eacute;thode d'autorisation s'applique avec succ&egrave;s pour que
-	l'autorisation soit accord&eacute;e.</p>
+	qu'une méthode d'autorisation s'applique avec succès pour que
+	l'autorisation soit accordée.</p>
 
     </section>
 
     <section id="reqaccessctrl"><title>Utilisation de fournisseurs
-    d'autorisation pour le contr&ocirc;le d'acc&egrave;s</title>
-        <p>La v&eacute;rification du nom d'utilisateur et du mot de passe ne
-	constituent qu'un aspect des m&eacute;thodes d'authentification.
-	Souvent, le contr&ocirc;le d'acc&egrave;s &agrave; certaines personnes n'est pas
-	bas&eacute; sur leur identit&eacute; ; il peut d&eacute;pendre, par exemple de leur
+    d'autorisation pour le contrôle d'accès</title>
+        <p>La vérification du nom d'utilisateur et du mot de passe ne
+	constituent qu'un aspect des méthodes d'authentification.
+	Souvent, le contrôle d'accès à certaines personnes n'est pas
+	basé sur leur identité ; il peut dépendre, par exemple de leur
 	provenance.</p>
 
         <p>Les fournisseurs d'autorisation <code>all</code>,
 	<code>env</code>, <code>host</code> et <code>ip</code> vous
-	permettent d'accorder ou refuser l'acc&egrave;s en
-	fonction de crit&egrave;res tels que le nom d'h&ocirc;te ou l'adresse
-	IP de la machine qui effectue la requ&ecirc;te.</p>
+	permettent d'accorder ou refuser l'accès en
+	fonction de critères tels que le nom d'hôte ou l'adresse
+	IP de la machine qui effectue la requête.</p>
 
-        <p>L'utilisation de ces fournisseurs est sp&eacute;cifi&eacute;e &agrave; l'aide de
+        <p>L'utilisation de ces fournisseurs est spécifiée à l'aide de
 	la directive <directive
 	module="mod_authz_core">Require</directive>. Cette directive
 	permet d'enregistrer quels fournisseurs d'autorisation
-	seront appel&eacute;s dans le processus d'autorisation au cours du
-	traitement de la requ&ecirc;te. Par exemple :</p>
+	seront appelés dans le processus d'autorisation au cours du
+	traitement de la requête. Par exemple :</p>
 
         <highlight language="config">Require ip <var>address</var></highlight>
 
-        <p>o&ugrave; <var>adresse</var> est une adresse IP (ou une adresse IP
+        <p>où <var>adresse</var> est une adresse IP (ou une adresse IP
 	partielle) ou :</p>
 
         <highlight language="config">Require host <var>domain_name</var></highlight>
 
-        <p>o&ugrave; <var>nom_domaine</var> est un nom de domaine enti&egrave;rement
-	qualif&eacute; (ou un nom de domaine partiel) ; vous pouvez indiquer
-	plusieurs adresses ou noms de domaines, si vous le d&eacute;sirez.</p>
+        <p>où <var>nom_domaine</var> est un nom de domaine entièrement
+	qualifé (ou un nom de domaine partiel) ; vous pouvez indiquer
+	plusieurs adresses ou noms de domaines, si vous le désirez.</p>
 
         <p>Par exemple, si vous voulez rejeter les spams dont une
 	machine vous inonde, vous pouvez utiliser ceci :</p>
@@ -574,7 +574,7 @@ autorisation</title>
         </highlight>
 
         <p>Ainsi, les visiteurs en provenance de cette adresse ne
-	pourront pas voir le contenu concern&eacute; par cette directive. Si,
+	pourront pas voir le contenu concerné par cette directive. Si,
 	par contre, vous connaissez le nom de la machine, vous pouvez
 	utiliser ceci :</p>
 
@@ -585,8 +585,8 @@ autorisation</title>
 &lt;/RequireAll&gt;
         </highlight>
 
-        <p>Et si vous voulez interdire l'acc&egrave;s &agrave; toutes les machines
-	d'un domaine, vous pouvez sp&eacute;cifier une partie seulement de
+        <p>Et si vous voulez interdire l'accès à toutes les machines
+	d'un domaine, vous pouvez spécifier une partie seulement de
 	l'adresse ou du nom de domaine :</p>
 
         <highlight language="config">
@@ -601,61 +601,76 @@ autorisation</title>
         <p>L'utilisation de la directive <directive
 	module="mod_authz_core" type="section">RequireAll</directive>
 	avec de multiples directives <directive module="mod_authz_core"
-	type="section">Require</directive>, toutes avec la n&eacute;gation
-	<code>not</code>, n'accordera l'acc&egrave;s que si toutes les
-	conditions n&eacute;gatives sont v&eacute;rifi&eacute;es. En d'autres termes, l'acc&egrave;s
-	sera refus&eacute; si au moins une des conditions n&eacute;gatives n'est pas
-	v&eacute;rifi&eacute;e.</p>
+	type="section">Require</directive>, toutes avec la négation
+	<code>not</code>, n'accordera l'accès que si toutes les
+	conditions négatives sont vérifiées. En d'autres termes, l'accès
+	sera refusé si au moins une des conditions négatives n'est pas
+	vérifiée.</p>
 
     </section>
 
-    <section id="filesystem"><title>Compatibilit&eacute; ascendante du contr&ocirc;le
-    d'acc&egrave;s</title>
-        <p>L'adoption d'un m&eacute;canisme &agrave; base de fournisseurs pour
-	l'authentification, a pour effet colat&eacute;ral de rendre inutiles
+    <section id="filesystem"><title>Compatibilité ascendante du contrôle
+    d'accès</title>
+        <p>L'adoption d'un mécanisme à base de fournisseurs pour
+	l'authentification, a pour effet colatéral de rendre inutiles
 	les directives <directive
 	module="mod_access_compat">Order</directive>, <directive
 	module="mod_access_compat">Allow</directive>, <directive
 	module="mod_access_compat">Deny</directive> et <directive
-	module="mod_access_compat">Satisfy</directive>. Cependant, et &agrave;
-	des fins de compatibilit&eacute; ascendante vers les anciennes
-	configurations, ces directives ont &eacute;t&eacute; d&eacute;plac&eacute;es vers le module
+	module="mod_access_compat">Satisfy</directive>. Cependant, et à
+	des fins de compatibilité ascendante vers les anciennes
+	configurations, ces directives ont été déplacées vers le module
 	<module>mod_access_compat</module>.</p>
 
+    <note type="warning"><title>Note</title>
+      <p>Les directives fournies par le module
+      <module>mod_access_compat</module> sont devenues obsolètes depuis
+      la refonte du module <module>mod_authz_host</module>. Mélanger d'anciennes
+      directives comme <directive
+      module="mod_access_compat">Order</directive>, <directive
+      module="mod_access_compat">Allow</directive> ou <directive
+      module="mod_access_compat">Deny</directive> avec des nouvelles comme
+      <directive module="mod_authz_core">Require</directive> est techniquement
+      possible mais déconseillé. En effet, <module>mod_access_compat</module> a
+      été conçu pour supporter des configurations ne contenant que des anciennes
+      directives afin de faciliter le passage à la version 2.4. Voir le document
+      <a href="../upgrading.html">upgrading</a> pour plus de détails.
+      </p>
+    </note>	
     </section>
 
 </section>
 
 <section id="socache"><title>Mise en cache de l'authentification</title>
     <p>Dans certains cas, l'authentification constitue une charge
-    inacceptable pour un fournisseur d'authentification ou votre r&eacute;seau.
+    inacceptable pour un fournisseur d'authentification ou votre réseau.
     Ceci est susceptible d'affecter les utilisateurs du module
     <module>mod_authn_dbd</module> (ou les fournisseurs
-    tiers/personnalis&eacute;s). Pour r&eacute;soudre ce probl&egrave;me, HTTPD 2.3/2.4
+    tiers/personnalisés). Pour résoudre ce problème, HTTPD 2.3/2.4
     propose un nouveau fournisseur de mise en cache,
     <module>mod_authn_socache</module>, qui permet de mettre en cache
-    les donn&eacute;es d'authentification, et ainsi r&eacute;duire la charge du/des
+    les données d'authentification, et ainsi réduire la charge du/des
     fournisseurs(s) originels.</p>
     <p>Cette mise en cache apportera un gain en performance substantiel
-    &agrave; certains utilisateurs.</p>
+    à certains utilisateurs.</p>
 </section>
 
 <section id="moreinformation"><title>Pour aller plus loin . . .</title>
     <p>Vous pouvez aussi lire la documentation de
     <module>mod_auth_basic</module> et <module>mod_authz_host</module>
-    qui contient des informations suppl&eacute;mentaires &agrave; propos du
+    qui contient des informations supplémentaires à propos du
     fonctionnement de tout ceci.
-    Certaines configurations d'authentification peuvent aussi &ecirc;tre
-    simplifi&eacute;es &agrave; l'aide de la directive <directive
+    Certaines configurations d'authentification peuvent aussi être
+    simplifiées à l'aide de la directive <directive
     type="section"
     module="mod_authn_core">AuthnProviderAlias</directive>.</p>
 
-    <p>Les diff&eacute;rents algorithmes de chiffrement support&eacute;s par Apache
-    pour authentifier les donn&eacute;es sont expliqu&eacute;s dans <a
+    <p>Les différents algorithmes de chiffrement supportés par Apache
+    pour authentifier les données sont expliqués dans <a
     href="../misc/password_encryptions.html">PasswordEncryptions</a>.</p>
 
-    <p>Enfin vous pouvez consulter la recette <a href="access.html">Contr&ocirc;le
-    d'acc&egrave;s</a>, qui d&eacute;crit un certain nombre de situations en relation
+    <p>Enfin vous pouvez consulter la recette <a href="access.html">Contrôle
+    d'accès</a>, qui décrit un certain nombre de situations en relation
     avec le sujet.</p>
 
 </section>
diff --git a/docs/manual/howto/index.xml.fr b/docs/manual/howto/index.xml.fr
index 4b3c31a8462..083b4226fd0 100644
--- a/docs/manual/howto/index.xml.fr
+++ b/docs/manual/howto/index.xml.fr
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8" ?>
 <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
-<!-- English Revision: 1732097:1738639 (outdated) -->
+<!-- English Revision: 1738639 -->
 <!-- French translation : Lucien GENTIS -->
 <!-- Reviewed by : Vincent Deffontaines -->
 
@@ -85,6 +85,21 @@
       </dd>
     </dl>
 
+    <dl>
+      <dt>HTTP/2 avec httpd</dt>
+      <dd>
+      <p>HTTP/2 est une évolution du protocole de la couche application le plus
+      connu au monde, HTTP. Les efforts se sont concentrés sur une amélioration
+      de l'efficacité de l'utilisation des ressources réseau sans modifier la
+      sémantique de HTTP. Ce guide explique la manière dont HTTP/2 est
+      implémenté dans httpd, donne des conseils pour une configuration de base
+      ainsi qu'une liste de recommandations.
+      </p>
+
+        <p>Voir le <a href="http2.html">guide HTTP/2</a></p>
+      </dd>
+    </dl>
+
     <dl>
       <dt>Introduction au Inclusions côté Serveur (Server Side Includes
       ou SSI)</dt>
diff --git a/docs/manual/logs.xml.fr b/docs/manual/logs.xml.fr
index 3ddd070236e..4bd04f92f38 100644
--- a/docs/manual/logs.xml.fr
+++ b/docs/manual/logs.xml.fr
@@ -1,9 +1,9 @@
-<?xml version="1.0" encoding="ISO-8859-1" ?>
+<?xml version="1.0" encoding="UTF-8" ?>
 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
 <?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
 <!-- French translation : Lucien GENTIS -->
 <!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 1657858:1739105 (outdated) -->
+<!-- English Revision: 1739105 -->
 
 <!--
  Licensed to the Apache Software Foundation (ASF) under one or more
@@ -27,13 +27,13 @@
   <title>Fichiers journaux</title>
 
   <summary>
-    <p>Pour v&eacute;ritablement g&eacute;rer un serveur web,
-    il est n&eacute;cessaire de disposer d'un
-    retour d'informations &agrave; propos de l'activit&eacute; et des performances du
-    serveur, ainsi que de tout probl&egrave;me qui pourrait survenir. Le serveur HTTP
-    Apache propose des fonctionnalit&eacute;s de journalisation souples et tr&egrave;s
-    compl&egrave;tes. Ce document d&eacute;crit comment configurer ces fonctionnalit&eacute;s de
-    journalisation et interpr&eacute;ter le contenu des journaux.</p>
+    <p>Pour véritablement gérer un serveur web,
+    il est nécessaire de disposer d'un
+    retour d'informations à propos de l'activité et des performances du
+    serveur, ainsi que de tout problème qui pourrait survenir. Le serveur HTTP
+    Apache propose des fonctionnalités de journalisation souples et très
+    complètes. Ce document décrit comment configurer ces fonctionnalités de
+    journalisation et interpréter le contenu des journaux.</p>
   </summary>
 
   <section id="overview">
@@ -49,41 +49,41 @@
   </related>
 
   <p>
-  Le serveur HTTP Apache fournit toute une vari&eacute;t&eacute; de m&eacute;canismes
-  diff&eacute;rents pour la journalisation de tout ce qui peut se passer au
-  sein de votre serveur, depuis la requ&ecirc;te initiale, en passant par le
-  processus de mise en correspondance des URLs, et jusqu'&agrave; la fermeture
+  Le serveur HTTP Apache fournit toute une variété de mécanismes
+  différents pour la journalisation de tout ce qui peut se passer au
+  sein de votre serveur, depuis la requête initiale, en passant par le
+  processus de mise en correspondance des URLs, et jusqu'à la fermeture
   de la connexion, y compris toute erreur pouvant survenir au cours du
   traitement. De plus, certains modules tiers fournissent des
-  fonctionnalit&eacute;s de journalisation ou ins&egrave;rent des entr&eacute;es dans les
+  fonctionnalités de journalisation ou insèrent des entrées dans les
   fichiers journaux existants, et les applications comme les programmes
   CGI, les scripts PHP ou autres gestionnaires peuvent envoyer des
   messages vers le journal des erreurs du serveur.
   </p>
 
   <p>
-  Ce document d&eacute;crit le fonctionnement des modules de journalisation
+  Ce document décrit le fonctionnement des modules de journalisation
   fournis en standard avec le serveur httpd.
   </p>
 
   </section>
 
   <section id="security">
-    <title>Avertissement &agrave; propos de la s&eacute;curit&eacute;</title>
+    <title>Avertissement à propos de la sécurité</title>
 
-    <p>Tout utilisateur qui a les droits en &eacute;criture sur le r&eacute;pertoire dans
-    lequel Apache httpd &eacute;crit ses journaux pourra quasi
-    certainement avoir acc&egrave;s &agrave; l'uid sous lequel le serveur est d&eacute;marr&eacute;, en
+    <p>Tout utilisateur qui a les droits en écriture sur le répertoire dans
+    lequel Apache httpd écrit ses journaux pourra quasi
+    certainement avoir accès à l'uid sous lequel le serveur est démarré, en
     l'occurrence habituellement root. N'accordez <em>PAS</em> aux utilisateurs
-    l'acc&egrave;s en &eacute;criture au r&eacute;pertoire dans lequel les journaux sont stock&eacute;s
-    sans savoir exactement quelles en seraient les cons&eacute;quences ; voir le
-    document <a href="misc/security_tips.html">conseils sur la s&eacute;curit&eacute;</a>
-    pour plus de d&eacute;tails.</p>
+    l'accès en écriture au répertoire dans lequel les journaux sont stockés
+    sans savoir exactement quelles en seraient les conséquences ; voir le
+    document <a href="misc/security_tips.html">conseils sur la sécurité</a>
+    pour plus de détails.</p>
 
     <p>En outre, les journaux peuvent contenir des informations fournies
-    directement par un client, sans caract&egrave;res d'&eacute;chappement. Des clients mal
-    intentionn&eacute;s peuvent donc ins&eacute;rer des caract&egrave;res de contr&ocirc;le dans les
-    journaux, et il convient par cons&eacute;quent d'&ecirc;tre tr&egrave;s prudent lors de la
+    directement par un client, sans caractères d'échappement. Des clients mal
+    intentionnés peuvent donc insérer des caractères de contrôle dans les
+    journaux, et il convient par conséquent d'être très prudent lors de la
     manipulation des journaux bruts.</p>
   </section>
 
@@ -101,27 +101,27 @@
     </related>
 
     <p>Le journal des erreurs du serveur, dont le nom et la localisation sont
-    d&eacute;finis par la directive <directive module="core">ErrorLog</directive>,
+    définis par la directive <directive module="core">ErrorLog</directive>,
     est le journal le plus important. C'est dans celui-ci
-    que le d&eacute;mon Apache httpd va envoyer les informations de diagnostic et
+    que le démon Apache httpd va envoyer les informations de diagnostic et
     enregistrer toutes les erreurs qui surviennent lors du traitement des
-    requ&ecirc;tes. Lorsqu'un probl&egrave;me survient au d&eacute;marrage du serveur ou pendant
-    son fonctionnement, la premi&egrave;re chose &agrave; faire est de regarder dans ce
-    journal, car il vous renseignera souvent sur le probl&egrave;me rencontr&eacute; et
-    la mani&egrave;re d'y rem&eacute;dier.</p>
-
-    <p>Le journal des erreurs est habituellement enregistr&eacute; dans un fichier
-    (en g&eacute;n&eacute;ral <code>error_log</code> sur les syst&egrave;mes de type Unix et
-    <code>error.log</code> sur Windows et OS/2). Sur les syst&egrave;mes de type Unix,
+    requêtes. Lorsqu'un problème survient au démarrage du serveur ou pendant
+    son fonctionnement, la première chose à faire est de regarder dans ce
+    journal, car il vous renseignera souvent sur le problème rencontré et
+    la manière d'y remédier.</p>
+
+    <p>Le journal des erreurs est habituellement enregistré dans un fichier
+    (en général <code>error_log</code> sur les systèmes de type Unix et
+    <code>error.log</code> sur Windows et OS/2). Sur les systèmes de type Unix,
     le serveur peut aussi enregistrer ses erreurs dans
     <code>syslog</code> ou les
-    <a href="#piped">rediriger vers un programme</a> par l'interm&eacute;diaire d'un
+    <a href="#piped">rediriger vers un programme</a> par l'intermédiaire d'un
     tube de communication (pipe).</p>
 
-    <p>Le format par d&eacute;faut du journal des erreurs est descriptif et de forme
+    <p>Le format par défaut du journal des erreurs est descriptif et de forme
     relativement libre. Certaines informations apparaissent cependant dans la
-    plupart des entr&eacute;es du journal. Voici un message typique
-    &agrave; titre d'exemple : </p>
+    plupart des entrées du journal. Voici un message typique
+    à titre d'exemple : </p>
 
     <example>
       [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
@@ -129,37 +129,37 @@
       /export/home/live/ap/htdocs/test
     </example>
 
-    <p>Le premier champ de l'entr&eacute;e du journal est la date et l'heure du
-    message. Le second champ indique la s&eacute;v&eacute;rit&eacute; de l'erreur rapport&eacute;e. La
+    <p>Le premier champ de l'entrée du journal est la date et l'heure du
+    message. Le second champ indique la sévérité de l'erreur rapportée. La
     directive <directive module="core">LogLevel</directive> permet de
-    restreindre le type des erreurs qui doivent &ecirc;tre enregistr&eacute;es
-    dans le journal des erreurs en d&eacute;finissant leur niveau de s&eacute;v&eacute;rit&eacute;. Le
-    troisi&egrave;me champ contient l'adresse IP du client qui a g&eacute;n&eacute;r&eacute; l'erreur.
+    restreindre le type des erreurs qui doivent être enregistrées
+    dans le journal des erreurs en définissant leur niveau de sévérité. Le
+    troisième champ contient l'adresse IP du client qui a généré l'erreur.
     Vient ensuite le message proprement dit, qui indique dans ce cas que le
-    serveur a &eacute;t&eacute; configur&eacute; pour interdire l'acc&egrave;s au client. Le serveur
-    indique le chemin syst&egrave;me du document requis (et non
+    serveur a été configuré pour interdire l'accès au client. Le serveur
+    indique le chemin système du document requis (et non
     son chemin web).</p>
 
-    <p>Une grande vari&eacute;t&eacute; de messages diff&eacute;rents peuvent appara&icirc;tre dans le
-    journal des erreurs. La plupart d'entre eux sont similaires &agrave; l'exemple
+    <p>Une grande variété de messages différents peuvent apparaître dans le
+    journal des erreurs. La plupart d'entre eux sont similaires à l'exemple
     ci-dessus. Le journal des erreurs peut aussi contenir des informations de
-    d&eacute;bogage en provenance de scripts CGI. Toute information qu'un script CGI
-    &eacute;crit sur la sortie d'erreurs standard <code>stderr</code> sera recopi&eacute;e
+    débogage en provenance de scripts CGI. Toute information qu'un script CGI
+    écrit sur la sortie d'erreurs standard <code>stderr</code> sera recopiée
     telle quelle dans le journal des erreurs.</p>
 
     <p>La directive <directive module="core">ErrorLogFormat</directive>
     vous permet de personnaliser le format du journal des erreurs, et de
-    d&eacute;finir les informations &agrave; journaliser. Si
-    <module>mod_unique_id</module> est pr&eacute;sent, vous pouvez utiliser le
-    drapeau <code>%L</code> &agrave; la fois dans le journal des erreurs et
+    définir les informations à journaliser. Si
+    <module>mod_unique_id</module> est présent, vous pouvez utiliser le
+    drapeau <code>%L</code> à la fois dans le journal des erreurs et
     dans le
-    journal des acc&egrave;s, ce qui aura pour effet de g&eacute;n&eacute;rer un identifiant
-    d'entr&eacute;e qui vous permettra de corr&eacute;ler les entr&eacute;es du journal des
-    erreurs avec celles du journal des acc&egrave;s.</p>
+    journal des accès, ce qui aura pour effet de générer un identifiant
+    d'entrée qui vous permettra de corréler les entrées du journal des
+    erreurs avec celles du journal des accès.</p>
 
     <p>Pendant la phase de test, il est souvent utile de visualiser en continu
-    le journal des erreurs afin de d&eacute;tecter tout probl&egrave;me &eacute;ventuel. Sur les
-    syst&egrave;mes de type Unix, ceci s'effectue &agrave; l'aide de la commande :</p>
+    le journal des erreurs afin de détecter tout problème éventuel. Sur les
+    systèmes de type Unix, ceci s'effectue à l'aide de la commande :</p>
 
     <example>
       tail -f error_log
@@ -170,31 +170,31 @@
     <title>Journalisation par module</title>
 
     <p>La directive <directive module="core">LogLevel</directive> permet
-    de sp&eacute;cifier un niveau de s&eacute;v&eacute;rit&eacute; de journalisation pour chaque
-    module. Vous pouvez ainsi r&eacute;soudre un probl&egrave;me propre &agrave; un module particulier
+    de spécifier un niveau de sévérité de journalisation pour chaque
+    module. Vous pouvez ainsi résoudre un problème propre à un module particulier
     en augmentant son volume de journalisation sans augmenter ce volume
-    pour les autres modules. Ceci est particuli&egrave;rement utile lorsque
-    vous voulez obtenir des d&eacute;tails sur le fonctionnement de modules
+    pour les autres modules. Ceci est particulièrement utile lorsque
+    vous voulez obtenir des détails sur le fonctionnement de modules
     comme <module>mod_proxy</module> ou <module>mod_rewrite</module>.</p>
 
-    <p>Pour ce faire, vous devez sp&eacute;cifier le nom du module dans votre
+    <p>Pour ce faire, vous devez spécifier le nom du module dans votre
     directive <directive>LogLevel</directive> :</p>
 
     <highlight language="config">
     LogLevel info rewrite:trace5
     </highlight>
 
-    <p>Dans cet exemple, le niveau de journalisation g&eacute;n&eacute;ral est d&eacute;fini
-    &agrave; info, et &agrave; <code>trace5</code> pour <module>mod_rewrite</module>.</p>
+    <p>Dans cet exemple, le niveau de journalisation général est défini
+    à info, et à <code>trace5</code> pour <module>mod_rewrite</module>.</p>
 
     <note>Cette directive remplace les directives de journalisation par
-    module des versions pr&eacute;c&eacute;dentes du serveur, comme
+    module des versions précédentes du serveur, comme
     <code>RewriteLog</code>.</note>
  </section>
 
 
   <section id="accesslog">
-    <title>Journal des acc&egrave;s</title>
+    <title>Journal des accès</title>
 
     <related>
       <modulelist>
@@ -208,185 +208,185 @@
       </directivelist>
     </related>
 
-    <p>Le journal des acc&egrave;s au serveur
-    enregistre toutes les requ&ecirc;tes que traite
-    ce dernier. La localisation et le contenu du journal des acc&egrave;s sont d&eacute;finis
+    <p>Le journal des accès au serveur
+    enregistre toutes les requêtes que traite
+    ce dernier. La localisation et le contenu du journal des accès sont définis
     par la directive <directive module="mod_log_config">CustomLog</directive>.
     La directive <directive module="mod_log_config">LogFormat</directive>
-    permet de simplifier la s&eacute;lection du contenu du journal. Cette section
-    d&eacute;crit comment configurer le serveur pour l'enregistrement des informations
-    dans le journal des acc&egrave;s.</p>
-
-    <p>Bien &eacute;videmment, le stockage d'informations dans le journal des acc&egrave;s
-    n'est que le point de d&eacute;part de la gestion de la journalisation. L'&eacute;tape
-    suivante consiste &agrave; analyser ces informations de fa&ccedil;on &agrave; pouvoir en
-    extraire des statistiques utiles. L'analyse de journaux en g&eacute;n&eacute;ral est en
-    dehors du sujet de ce document et ne fait pas vraiment partie int&eacute;grante
-    du travail du serveur web lui-m&ecirc;me. Pour plus d'informations &agrave; propos de ce
-    sujet et des applications d&eacute;di&eacute;es &agrave; l'analyse de journaux, vous pouvez vous
-    r&eacute;f&eacute;rer &agrave; <a href="http://dmoz.org/Computers/Software/Internet/
+    permet de simplifier la sélection du contenu du journal. Cette section
+    décrit comment configurer le serveur pour l'enregistrement des informations
+    dans le journal des accès.</p>
+
+    <p>Bien évidemment, le stockage d'informations dans le journal des accès
+    n'est que le point de départ de la gestion de la journalisation. L'étape
+    suivante consiste à analyser ces informations de façon à pouvoir en
+    extraire des statistiques utiles. L'analyse de journaux en général est en
+    dehors du sujet de ce document et ne fait pas vraiment partie intégrante
+    du travail du serveur web lui-même. Pour plus d'informations à propos de ce
+    sujet et des applications dédiées à l'analyse de journaux, vous pouvez vous
+    référer à <a href="http://dmoz.org/Computers/Software/Internet/
     Site_Management/Log_Analysis/">Open Directory</a>.</p>
 
-    <p>Diff&eacute;rentes versions du d&eacute;mon Apache httpd utilisaient d'autres modules
-    et directives pour contr&ocirc;ler la journalisation des acc&egrave;s, &agrave; l'instar de
+    <p>Différentes versions du démon Apache httpd utilisaient d'autres modules
+    et directives pour contrôler la journalisation des accès, à l'instar de
     mod_log_referer, mod_log_agent, et de la directive
     <code>TransferLog</code>. La directive
     <directive	module="mod_log_config">CustomLog</directive> rassemble
-    d&eacute;sormais les fonctionnalit&eacute;s de toutes les anciennes directives.</p>
+    désormais les fonctionnalités de toutes les anciennes directives.</p>
 
-    <p>Le format du journal des acc&egrave;s est hautement configurable. Il est
-    d&eacute;fini &agrave; l'aide d'une cha&icirc;ne de format qui ressemble sensiblement &agrave; la
-    cha&icirc;ne de format de style langage C de printf(1). Vous trouverez quelques
+    <p>Le format du journal des accès est hautement configurable. Il est
+    défini à l'aide d'une chaîne de format qui ressemble sensiblement à la
+    chaîne de format de style langage C de printf(1). Vous trouverez quelques
     exemples dans les sections suivantes. Pour une liste exhaustive de ce que
-    peut contenir une cha&icirc;ne de format, vous pouvez vous r&eacute;f&eacute;rer au chapitre
-    <a href="mod/mod_log_config.html#formats">cha&icirc;nes de format</a> de la
+    peut contenir une chaîne de format, vous pouvez vous référer au chapitre
+    <a href="mod/mod_log_config.html#formats">chaînes de format</a> de la
     documentation du module <module>mod_log_config</module>.</p>
 
     <section id="common">
       <title>Format habituel du journal</title>
 
-      <p>Voici une configuration typique pour le journal des acc&egrave;s :</p>
+      <p>Voici une configuration typique pour le journal des accès :</p>
 
       <highlight language="config">
 LogFormat "%h %l %u %t \"%r\" %&gt;s %b" common
 CustomLog logs/access_log common
       </highlight>
 
-      <p>Ici est d&eacute;finie l'<em>identit&eacute;</em> <code>common</code> qui est
-      ensuite associ&eacute;e &agrave; une cha&icirc;ne de format de journalisation particuli&egrave;re.
-      La cha&icirc;ne de format est constitu&eacute;e de directives d&eacute;butant par le
-      caract&egrave;re %, chacune d'entre elles indiquant au serveur d'enregistrer
-      un &eacute;l&eacute;ment particulier d'information. Des caract&egrave;res litt&eacute;raux peuvent
-      aussi &ecirc;tre ins&eacute;r&eacute;s dans la cha&icirc;ne de format ; il seront copi&eacute;s tels
-      quels dans le flux de sortie destin&eacute; &agrave; la journalisation.
-      Les guillemets (<code>"</code>) doivent &ecirc;tre &eacute;chapp&eacute;es en les faisant
-      pr&eacute;c&eacute;der d'un anti-slash (<code>\</code>) afin qu'elles ne soient pas
-      interpr&eacute;t&eacute;es comme la fin de la cha&icirc;ne de format. La cha&icirc;ne de format
-      peut aussi contenir les caract&egrave;res de contr&ocirc;le sp&eacute;ciaux
-      "<code>\n</code>" et "<code>\t</code>" pour ins&eacute;rer respectivement
-      un passage &agrave; la ligne et une tabulation.</p>
+      <p>Ici est définie l'<em>identité</em> <code>common</code> qui est
+      ensuite associée à une chaîne de format de journalisation particulière.
+      La chaîne de format est constituée de directives débutant par le
+      caractère %, chacune d'entre elles indiquant au serveur d'enregistrer
+      un élément particulier d'information. Des caractères littéraux peuvent
+      aussi être insérés dans la chaîne de format ; il seront copiés tels
+      quels dans le flux de sortie destiné à la journalisation.
+      Les guillemets (<code>"</code>) doivent être échappées en les faisant
+      précéder d'un anti-slash (<code>\</code>) afin qu'elles ne soient pas
+      interprétées comme la fin de la chaîne de format. La chaîne de format
+      peut aussi contenir les caractères de contrôle spéciaux
+      "<code>\n</code>" et "<code>\t</code>" pour insérer respectivement
+      un passage à la ligne et une tabulation.</p>
 
       <p>La directive <directive module="mod_log_config">CustomLog</directive>
-      d&eacute;finit un nouveau fichier journal en l'associant &agrave; l'identit&eacute;
-      pr&eacute;c&eacute;demment d&eacute;finie. Le chemin du nom de fichier associ&eacute; au journal
-      des acc&egrave;s est relatif au chemin d&eacute;fini par la directive
+      définit un nouveau fichier journal en l'associant à l'identité
+      précédemment définie. Le chemin du nom de fichier associé au journal
+      des accès est relatif au chemin défini par la directive
       <directive module="core">ServerRoot</directive>, sauf s'il
-      d&eacute;bute par un slash.</p>
+      débute par un slash.</p>
 
-      <p>La configuration ci-dessus va enregistrer les entr&eacute;es de
+      <p>La configuration ci-dessus va enregistrer les entrées de
       journalisation selon un format connu sous le nom de
       Common Log Format (CLF) pour "Format de journalisation standard".
-      Ce format standard peut &ecirc;tre produit par de nombreux serveurs web
-      diff&eacute;rents et lu par de nombreux programmes d'analyse de journaux.
-      Les entr&eacute;es de fichier journal g&eacute;n&eacute;r&eacute;es selon le format CLF
-      ressemblent &agrave; ceci :</p>
+      Ce format standard peut être produit par de nombreux serveurs web
+      différents et lu par de nombreux programmes d'analyse de journaux.
+      Les entrées de fichier journal générées selon le format CLF
+      ressemblent à ceci :</p>
 
       <example>
         127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
         /apache_pb.gif HTTP/1.0" 200 2326
       </example>
 
-      <p>Chaque partie de cette entr&eacute;e de journal est d&eacute;crite
+      <p>Chaque partie de cette entrée de journal est décrite
       dans ce qui suit.</p>
 
       <dl>
         <dt><code>127.0.0.1</code> (<code>%h</code>)</dt>
 
-        <dd>Il s'agit de l'adresse IP du client (l'h&ocirc;te distant) qui a envoy&eacute;
-	la requ&ecirc;te au serveur. Si la directive
-	<directive module="core">HostnameLookups</directive> est positionn&eacute;e &agrave;
-	<code>On</code>, le serveur va essayer de d&eacute;terminer le nom de l'h&ocirc;te
-	et de l'enregistrer &agrave; la place de l'adresse IP. Cette configuration
-	n'est cependant pas recommand&eacute;e car elle peut ralentir le serveur de
-	mani&egrave;re significative. Il est par cons&eacute;quent pr&eacute;f&eacute;rable d'utiliser un
+        <dd>Il s'agit de l'adresse IP du client (l'hôte distant) qui a envoyé
+	la requête au serveur. Si la directive
+	<directive module="core">HostnameLookups</directive> est positionnée à
+	<code>On</code>, le serveur va essayer de déterminer le nom de l'hôte
+	et de l'enregistrer à la place de l'adresse IP. Cette configuration
+	n'est cependant pas recommandée car elle peut ralentir le serveur de
+	manière significative. Il est par conséquent préférable d'utiliser un
 	processeur d'analyse de journaux a posteriori
 	tel que <program>logresolve</program>
-	pour d&eacute;terminer les noms d'h&ocirc;te. L'adresse IP indiqu&eacute;e ici n'est pas
-	n&eacute;cessairement l'adresse IP de la machine devant laquelle se trouve
+	pour déterminer les noms d'hôte. L'adresse IP indiquée ici n'est pas
+	nécessairement l'adresse IP de la machine devant laquelle se trouve
 	l'utilisateur. Si un serveur mandataire s'intercale entre le serveur
-	et l'utilisateur, l'adresse indiqu&eacute;e sera celle du mandataire et non
-	celle de la machine &agrave; l'origine de la requ&ecirc;te.</dd>
+	et l'utilisateur, l'adresse indiquée sera celle du mandataire et non
+	celle de la machine à l'origine de la requête.</dd>
 
         <dt><code>-</code> (<code>%l</code>)</dt>
 
         <dd>Le "trait d'union" indique que la portion d'information
-	correspondante n'est pas disponible. Dans le cas pr&eacute;sent, l'information
-	non disponible est l'identit&eacute; (RFC 1413) du client telle que d&eacute;termin&eacute;e
+	correspondante n'est pas disponible. Dans le cas présent, l'information
+	non disponible est l'identité (RFC 1413) du client telle que déterminée
 	par <code>identd</code> sur la machine cliente. Cette information est
-	tr&egrave;s peu fiable et ne devrait jamais &ecirc;tre utilis&eacute;e, sauf dans le cas
-	de r&eacute;seaux internes &eacute;troitement contr&ocirc;l&eacute;s. Le d&eacute;mon httpd ne cherchera
-	d'ailleurs &agrave; obtenir cette information que si la directive
-	<directive module="mod_ident">IdentityCheck</directive> est positionn&eacute;e
-	&agrave; <code>On</code>.</dd>
+	très peu fiable et ne devrait jamais être utilisée, sauf dans le cas
+	de réseaux internes étroitement contrôlés. Le démon httpd ne cherchera
+	d'ailleurs à obtenir cette information que si la directive
+	<directive module="mod_ident">IdentityCheck</directive> est positionnée
+	à <code>On</code>.</dd>
 
         <dt><code>frank</code> (<code>%u</code>)</dt>
 
         <dd>Il s'agit de l'identifiant utilisateur de la personne qui a
-	demand&eacute; le document, issu d'une authentification HTTP.
-	Ce m&ecirc;me identifiant est en g&eacute;n&eacute;ral fourni aux scripts CGI par
-	l'interm&eacute;diaire de la valeur de la variable d'environnement
-	<code>REMOTE_USER</code>. Si le statut de la requ&ecirc;te (voir plus loin)
+	demandé le document, issu d'une authentification HTTP.
+	Ce même identifiant est en général fourni aux scripts CGI par
+	l'intermédiaire de la valeur de la variable d'environnement
+	<code>REMOTE_USER</code>. Si le statut de la requête (voir plus loin)
 	est 401, cette identifiant n'est pas fiable car l'utilisateur n'est
-	pas encore authentifi&eacute;. Si le document n'est pas prot&eacute;g&eacute; par
-	mot de passe, cette partie d'information sera repr&eacute;sent&eacute;e par
-	"<code>-</code>", comme la partie pr&eacute;c&eacute;dente.</dd>
+	pas encore authentifié. Si le document n'est pas protégé par
+	mot de passe, cette partie d'information sera représentée par
+	"<code>-</code>", comme la partie précédente.</dd>
 
         <dt><code>[10/Oct/2000:13:55:36 -0700]</code>
         (<code>%t</code>)</dt>
 
         <dd>
-          L'heure &agrave; laquelle la requ&ecirc;te a &eacute;t&eacute; re&ccedil;ue.
+          L'heure à laquelle la requête a été reçue.
           Le format est le suivant :
 
           <p class="indent">
-            <code>[jour/mois/ann&eacute;e:heure:minutes:secondes zone]<br />
+            <code>[jour/mois/année:heure:minutes:secondes zone]<br />
              jour = 2*chiffre<br />
              mois = 3*lettre<br />
-             ann&eacute;e = 4*chiffre<br />
+             année = 4*chiffre<br />
              heure = 2*chiffre<br />
              minutes = 2*chiffre<br />
              secondes = 2*chiffre<br />
              zone = (`+' | `-') 4*chiffre</code>
           </p>Il est possible de modifier le format d'affichage de l'heure
-	  en sp&eacute;cifiant <code>%{format}t</code> dans la cha&icirc;ne de format du
-	  journal, o&ugrave; <code>format</code> est une cha&icirc;ne de format
+	  en spécifiant <code>%{format}t</code> dans la chaîne de format du
+	  journal, où <code>format</code> est une chaîne de format
 	  de la forme de celle de la fonction <code>strftime(3)</code>
-	  de la biblioth&egrave;que C standard, ou choisie parmi les
-	  formats sp&eacute;ciaux support&eacute;s. Pour plus de d&eacute;tails,
+	  de la bibliothèque C standard, ou choisie parmi les
+	  formats spéciaux supportés. Pour plus de détails,
 	  reportez-vous aux. <a
-	  href="mod/mod_log_config.html#formats">cha&icirc;nes de format</a>
+	  href="mod/mod_log_config.html#formats">chaînes de format</a>
 	  de <module>mod_log_config</module>.
         </dd>
 
         <dt><code>"GET /apache_pb.gif HTTP/1.0"</code>
         (<code>\"%r\"</code>)</dt>
 
-        <dd>La ligne de la requ&ecirc;te du client est plac&eacute;e entre guillemets.
+        <dd>La ligne de la requête du client est placée entre guillemets.
 	Elle contient de nombreuses informations utiles. Tout d'abord, la
-	m&eacute;thode utilis&eacute;e par le client est <code>GET</code>. Ensuite, le
-	client a demand&eacute; la ressource <code>/apache_pb.gif</code>, et enfin,
-	le client a utilis&eacute; le protocole <code>HTTP/1.0</code>. Il est aussi
-	possible d'enregistrer s&eacute;par&eacute;ment une ou plusieurs parties de la
-	requ&ecirc;te. Par exemple, la cha&icirc;ne de format "<code>%m %U %q %H</code>"
-	va enregistrer la m&eacute;thode, le chemin, la cha&icirc;ne de la requ&ecirc;te et le
-	protocole, ce qui donnera le m&ecirc;me r&eacute;sultat que
+	méthode utilisée par le client est <code>GET</code>. Ensuite, le
+	client a demandé la ressource <code>/apache_pb.gif</code>, et enfin,
+	le client a utilisé le protocole <code>HTTP/1.0</code>. Il est aussi
+	possible d'enregistrer séparément une ou plusieurs parties de la
+	requête. Par exemple, la chaîne de format "<code>%m %U %q %H</code>"
+	va enregistrer la méthode, le chemin, la chaîne de la requête et le
+	protocole, ce qui donnera le même résultat que
 	"<code>%r</code>".</dd>
 
         <dt><code>200</code> (<code>%&gt;s</code>)</dt>
 
         <dd>C'est le code de statut que le serveur retourne au client. Cette
-	information est tr&egrave;s importante car elle indique si la requ&ecirc;te a fait
-	l'objet d'une r&eacute;ponse positive (codes commen&ccedil;ant par 2), une
-	redirection (codes commen&ccedil;ant par 3), une erreur due au client (codes
-	commen&ccedil;ant par 4), ou une erreur due au serveur (codes commen&ccedil;ant
-	par 5). Vous trouverez la liste compl&egrave;te des codes de statut possibles
+	information est très importante car elle indique si la requête a fait
+	l'objet d'une réponse positive (codes commençant par 2), une
+	redirection (codes commençant par 3), une erreur due au client (codes
+	commençant par 4), ou une erreur due au serveur (codes commençant
+	par 5). Vous trouverez la liste complète des codes de statut possibles
 	dans la <a href="http://www.w3.org/Protocols/rfc2616/
 	rfc2616.txt">specification HTTP</a> (RFC2616 section 10).</dd>
 
         <dt><code>2326</code> (<code>%b</code>)</dt>
 
-        <dd>La derni&egrave;re partie indique la taille de l'objet retourn&eacute; au client,
-	en-t&ecirc;tes non compris. Si aucun contenu n'a &eacute;t&eacute; retourn&eacute; au client, cette
+        <dd>La dernière partie indique la taille de l'objet retourné au client,
+	en-têtes non compris. Si aucun contenu n'a été retourné au client, cette
 	partie contiendra "<code>-</code>". Pour indiquer l'absence de contenu
 	par "<code>0</code>", utilisez <code>%B</code> au lieu de
 	<code>%b</code>.</dd>
@@ -394,10 +394,10 @@ CustomLog logs/access_log common
     </section>
 
     <section id="combined">
-      <title>Combined Log Format (Format de journalisation combin&eacute;)</title>
+      <title>Combined Log Format (Format de journalisation combiné)</title>
 
-      <p>Une autre cha&icirc;ne de format couramment utilis&eacute;e est le
-      "Combined Log Format" (Format de journalisation combin&eacute;). Il s'utilise
+      <p>Une autre chaîne de format couramment utilisée est le
+      "Combined Log Format" (Format de journalisation combiné). Il s'utilise
       comme suit :</p>
 
       <highlight language="config">
@@ -406,10 +406,10 @@ CustomLog log/access_log combined
       </highlight>
 
       <p>Ce format est identique au Common Log Format, avec deux champs
-      suppl&eacute;mentaires. Chacun de ces deux champs utilise la directive
-      commen&ccedil;ant par le caract&egrave;re "%" <code>%{<em>header</em>}i</code>,
-      o&ugrave; <em>header</em> peut &ecirc;tre n'importe quel en-t&ecirc;te de requ&ecirc;te HTTP.
-      Avec ce format, le journal des acc&egrave;s se pr&eacute;sentera comme suit :</p>
+      supplémentaires. Chacun de ces deux champs utilise la directive
+      commençant par le caractère "%" <code>%{<em>header</em>}i</code>,
+      où <em>header</em> peut être n'importe quel en-tête de requête HTTP.
+      Avec ce format, le journal des accès se présentera comme suit :</p>
 
       <example>
         127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
@@ -418,36 +418,36 @@ CustomLog log/access_log combined
         (Win98; I ;Nav)"
       </example>
 
-      <p>Les champs suppl&eacute;mentaires sont :</p>
+      <p>Les champs supplémentaires sont :</p>
 
       <dl>
         <dt><code>"http://www.example.com/start.html"</code>
         (<code>\"%{Referer}i\"</code>)</dt>
 
-        <dd>L'en-t&ecirc;te "Referer" (sic) de la requ&ecirc;te HTTP. Il indique le site
-	depuis lequel le client pr&eacute;tend avoir lanc&eacute; sa requ&ecirc;te. (Ce doit &ecirc;tre
+        <dd>L'en-tête "Referer" (sic) de la requête HTTP. Il indique le site
+	depuis lequel le client prétend avoir lancé sa requête. (Ce doit être
 	la page qui contient un lien vers <code>/apache_pb.gif</code> ou
 	inclut ce dernier fichier).</dd>
 
         <dt><code>"Mozilla/4.08 [en] (Win98; I ;Nav)"</code>
         (<code>\"%{User-agent}i\"</code>)</dt>
 
-        <dd>L'en-t&ecirc;te User-Agent de la requ&ecirc;te HTTP. C'est une information
-	d'identification que le navigateur du client envoie &agrave; propos
-	de lui-m&ecirc;me.</dd>
+        <dd>L'en-tête User-Agent de la requête HTTP. C'est une information
+	d'identification que le navigateur du client envoie à propos
+	de lui-même.</dd>
       </dl>
     </section>
 
     <section id="multiple">
-      <title>Journaux d'acc&egrave;s multiples</title>
+      <title>Journaux d'accès multiples</title>
 
-      <p>Plusieurs journaux d'acc&egrave;s peuvent &ecirc;tre cr&eacute;&eacute;s en sp&eacute;cifiant tout
+      <p>Plusieurs journaux d'accès peuvent être créés en spécifiant tout
       simplement plusieurs directives
       <directive module="mod_log_config">CustomLog</directive> dans le
       fichier de configuration. Par exemple, les directives suivantes vont
-      cr&eacute;er trois journaux d'acc&egrave;s. Le premier contiendra les informations
-      de base CLF, le second les informations du Referer, et le troisi&egrave;me
-      les informations sur le navigateur. Les deux derni&egrave;res directives
+      créer trois journaux d'accès. Le premier contiendra les informations
+      de base CLF, le second les informations du Referer, et le troisième
+      les informations sur le navigateur. Les deux dernières directives
       <directive module="mod_log_config">CustomLog</directive> montrent
       comment simuler les effets des directives <code>ReferLog</code> et
       <code>AgentLog</code>.</p>
@@ -460,38 +460,38 @@ CustomLog logs/agent_log "%{User-agent}i"
       </highlight>
 
       <p>Cet exemple montre aussi qu'il n'est pas obligatoire d'associer
-      une cha&icirc;ne de format &agrave; un alias au moyen de la directive
+      une chaîne de format à un alias au moyen de la directive
       <directive module="mod_log_config">LogFormat</directive>. Elle peut
-      &ecirc;tre d&eacute;finie directement dans la ligne de la directive
+      être définie directement dans la ligne de la directive
       <directive module="mod_log_config">CustomLog</directive>.</p>
     </section>
 
     <section id="conditional">
       <title>Journalisation conditionnelle</title>
 
-      <p>Il est parfois souhaitable d'exclure certaines entr&eacute;es des journaux
-      d'acc&egrave;s en fonction des caract&eacute;ristiques de la requ&ecirc;te du client. On
-      peut ais&eacute;ment accomplir ceci &agrave; l'aide des
+      <p>Il est parfois souhaitable d'exclure certaines entrées des journaux
+      d'accès en fonction des caractéristiques de la requête du client. On
+      peut aisément accomplir ceci à l'aide des
       <a href="env.html">variables d'environnement</a>. Tout d'abord, une
-      variable d'environnement doit &ecirc;tre d&eacute;finie pour indiquer que la
-      requ&ecirc;te remplit certaines conditions. Pour ceci, on utilise en g&eacute;n&eacute;ral
+      variable d'environnement doit être définie pour indiquer que la
+      requête remplit certaines conditions. Pour ceci, on utilise en général
       la directive <directive module="mod_setenvif">SetEnvIf</directive>,
       puis la clause <code>env=</code> de la directive
       <directive module="mod_log_config">CustomLog</directive> pour inclure
-      ou exclure les requ&ecirc;tes pour lesquelles
-      la variable d'environnement est d&eacute;finie.
+      ou exclure les requêtes pour lesquelles
+      la variable d'environnement est définie.
       Quelques exemples :</p>
 
       <highlight language="config">
-# Marque les requ&ecirc;tes en provenance de l'interface loop-back
+# Marque les requêtes en provenance de l'interface loop-back
 SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
-# Marque les requ&ecirc;tes pour le fichier robots.txt
+# Marque les requêtes pour le fichier robots.txt
 SetEnvIf Request_URI "^/robots\.txt$" dontlog
-# Journalise toutes les autres requ&ecirc;tes
+# Journalise toutes les autres requêtes
 CustomLog logs/access_log common env=!dontlog
       </highlight>
 
-      <p>Autre exemple, imaginons l'enregistrement des requ&ecirc;tes en provenance
+      <p>Autre exemple, imaginons l'enregistrement des requêtes en provenance
       d'utilisateurs de langue anglaise dans un journal, et celles des autres
       utilisateurs dans un autre journal.</p>
 
@@ -501,9 +501,9 @@ CustomLog logs/access_log common env=!dontlog
         CustomLog logs/non_english_log common env=!english
       </highlight>
 
-	<p>Dans le contexte d'une mise en cache, il peut &ecirc;tre
-	int&eacute;ressant de conna&icirc;tre l'efficacit&eacute; du cache. Pour y parvenir,
-	on pourrait utiliser cette m&eacute;thode simple :</p>
+	<p>Dans le contexte d'une mise en cache, il peut être
+	intéressant de connaître l'efficacité du cache. Pour y parvenir,
+	on pourrait utiliser cette méthode simple :</p>
 
       <highlight language="config">
 SetEnv CACHE_MISS 1
@@ -511,17 +511,17 @@ LogFormat "%h %l %u %t "%r " %>s %b %{CACHE_MISS}e" common-cache
 CustomLog logs/access_log common-cache
       </highlight>
 
-      <p><module>mod_cache</module> va s'ex&eacute;cuter avant
-      <module>mod_env</module>, et si son action est couronn&eacute;e de
-      succ&egrave;s, il d&eacute;livrera le contenu sans faire appel &agrave; ce dernier. Si
-      l'URL se trouve dans le cache, la valeur journalis&eacute;e sera alors
+      <p><module>mod_cache</module> va s'exécuter avant
+      <module>mod_env</module>, et si son action est couronnée de
+      succès, il délivrera le contenu sans faire appel à ce dernier. Si
+      l'URL se trouve dans le cache, la valeur journalisée sera alors
       <code>-</code>, tandis que dans le cas contraire elle sera
       <code>1</code>.</p>
 
       <p>En plus de la syntaxe <code>env=</code>, la directive <directive
       module="mod_log_config">LogFormat</directive> supporte les
-      valeurs de journalisation conditionnelles bas&eacute;es sur le code de la
-      r&eacute;ponse HTTP :</p>
+      valeurs de journalisation conditionnelles basées sur le code de la
+      réponse HTTP :</p>
 
       <highlight language="config">
 LogFormat "%400,501{User-agent}i" browserlog
@@ -529,46 +529,46 @@ LogFormat "%!200,304,302{Referer}i" refererlog
       </highlight>
 
       <p>Dans le premier exemple, le <code>User-agent</code> sera
-      enregistr&eacute; si le code d'&eacute;tat HTTP est 400 ou 501. Dans le cas
-      contraire, c'est un caract&egrave;re "-" qui sera enregistr&eacute; &agrave; la place.
-      Dans le second exemple, le <code>Referer</code> sera enregistr&eacute; si
-      le code d'&eacute;tat HTTP n'est <strong>pas</strong> 200, 204, ou 302
-      (remarquez le caract&egrave;re "!" avant les codes d'&eacute;tat).</p>
+      enregistré si le code d'état HTTP est 400 ou 501. Dans le cas
+      contraire, c'est un caractère "-" qui sera enregistré à la place.
+      Dans le second exemple, le <code>Referer</code> sera enregistré si
+      le code d'état HTTP n'est <strong>pas</strong> 200, 204, ou 302
+      (remarquez le caractère "!" avant les codes d'état).</p>
 
       <p>Bien que nous venions de montrer que la journalisation conditionnelle
-      est souple et tr&egrave;s puissante, cette m&eacute;thode de contr&ocirc;le du contenu des
+      est souple et très puissante, cette méthode de contrôle du contenu des
       journaux n'est pas la seule. Les fichiers journaux sont plus utiles
-      quand ils contiennent un enregistrement complet de l'activit&eacute; du serveur,
-      et il est souvent plus ais&eacute; de simplement traiter &agrave; posteriori les fichiers
-      journaux pour supprimer les requ&ecirc;tes que vous ne voulez pas y voir
-      appara&icirc;tre.</p>
+      quand ils contiennent un enregistrement complet de l'activité du serveur,
+      et il est souvent plus aisé de simplement traiter à posteriori les fichiers
+      journaux pour supprimer les requêtes que vous ne voulez pas y voir
+      apparaître.</p>
     </section>
   </section>
 
   <section id="rotation">
     <title>Rotation des journaux</title>
 
-    <p>M&ecirc;me dans le cas d'un serveur mod&eacute;r&eacute;ment sollicit&eacute;, la quantit&eacute;
-    d'informations stock&eacute;es dans les fichiers journaux est tr&egrave;s importante.
-    Le fichier journal des acc&egrave;s grossit en g&eacute;n&eacute;ral d'1 Mo ou plus toutes
-    les 10000 requ&ecirc;tes. Il est par cons&eacute;quent n&eacute;cessaire d'effectuer
-    p&eacute;riodiquement la rotation des journaux en d&eacute;pla&ccedil;ant ou supprimant les
+    <p>Même dans le cas d'un serveur modérément sollicité, la quantité
+    d'informations stockées dans les fichiers journaux est très importante.
+    Le fichier journal des accès grossit en général d'1 Mo ou plus toutes
+    les 10000 requêtes. Il est par conséquent nécessaire d'effectuer
+    périodiquement la rotation des journaux en déplaçant ou supprimant les
     fichiers correspondants. On ne peut pas le faire pendant que le serveur
-    est en cours d'ex&eacute;cution, car Apache httpd va continuer &agrave; &eacute;crire dans l'ancien
+    est en cours d'exécution, car Apache httpd va continuer à écrire dans l'ancien
     fichier journal aussi longtemps qu'il le maintiendra ouvert.
-    C'est pourquoi le serveur doit &ecirc;tre
-    <a href="stopping.html">red&eacute;marr&eacute;</a> apr&egrave;s le d&eacute;placement ou la
-    suppression des fichiers journaux de fa&ccedil;on &agrave; ce qu'il en ouvre
+    C'est pourquoi le serveur doit être
+    <a href="stopping.html">redémarré</a> après le déplacement ou la
+    suppression des fichiers journaux de façon à ce qu'il en ouvre
     de nouveaux.</p>
 
-    <p>Avec un red&eacute;marrage <em>graceful</em>, on peut faire en sorte que le
+    <p>Avec un redémarrage <em>graceful</em>, on peut faire en sorte que le
     serveur ouvre de nouveaux fichiers journaux sans perdre de connexions
     existantes ou en cours avec les clients. Cependant, pour que ceci soit
-    possible, le serveur doit continuer &agrave; &eacute;crire dans les anciens fichiers
-    journaux pendant qu'il termine le traitement des requ&ecirc;tes en cours.
-    Il est donc n&eacute;cessaire d'attendre un certain temps apr&egrave;s le r&eacute;d&eacute;marrage
+    possible, le serveur doit continuer à écrire dans les anciens fichiers
+    journaux pendant qu'il termine le traitement des requêtes en cours.
+    Il est donc nécessaire d'attendre un certain temps après le rédémarrage
     avant d'effectuer tout traitement sur les fichiers journaux. Voici un
-    sc&eacute;nario typique dans lequel on effectue une simple rotation des
+    scénario typique dans lequel on effectue une simple rotation des
     journaux en compressant les anciens fichiers correspondants afin
     de gagner de l'espace disque :</p>
 
@@ -580,61 +580,61 @@ LogFormat "%!200,304,302{Referer}i" refererlog
       gzip access_log.old error_log.old
     </example>
 
-    <p>La section suivante pr&eacute;sente une autre m&eacute;thode de rotation des journaux
-    qui consiste &agrave; utiliser les
-    <a href="#piped">journaux redirig&eacute;s</a>.</p>
+    <p>La section suivante présente une autre méthode de rotation des journaux
+    qui consiste à utiliser les
+    <a href="#piped">journaux redirigés</a>.</p>
   </section>
 
   <section id="piped">
-    <title>Journaux redirig&eacute;s</title>
+    <title>Journaux redirigés</title>
 
-    <p>Nous avons vu que le d&eacute;mon httpd &eacute;crivait les informations de
-    journalisation des erreurs et des acc&egrave;s dans un fichier journal ;
+    <p>Nous avons vu que le démon httpd écrivait les informations de
+    journalisation des erreurs et des accès dans un fichier journal ;
     il peut aussi
-    rediriger ces informations vers un autre processus par l'interm&eacute;diaire d'un
-    tube de communication (pipe). Cette fonctionnalit&eacute; am&eacute;liore
-    consid&eacute;rablement la souplesse de la journalisation, sans ajouter de code
+    rediriger ces informations vers un autre processus par l'intermédiaire d'un
+    tube de communication (pipe). Cette fonctionnalité améliore
+    considérablement la souplesse de la journalisation, sans ajouter de code
     au serveur principal. Pour rediriger les informations de journalisation
     vers un tube de communication, remplacez simplement le nom de fichier
     journal par
-    le caract&egrave;re pipe "<code>|</code>", suivi du nom de l'ex&eacute;cutable qui va
-    recueillir les entr&eacute;es de journal sur son entr&eacute;e
+    le caractère pipe "<code>|</code>", suivi du nom de l'exécutable qui va
+    recueillir les entrées de journal sur son entrée
     standard. Le serveur va
-    lancer le processus de redirection des journaux au moment du d&eacute;marrage du
+    lancer le processus de redirection des journaux au moment du démarrage du
     serveur, et le relancera s'il cesse de fonctionner
-    pendant l'ex&eacute;cution du serveur.
-    (Nous d&eacute;nommons cette technique "journalisation
-    redirig&eacute;e fiable" gr&acirc;ce &agrave; cette derni&egrave;re fonctionnalit&eacute;.)</p>
-
-    <p>Les processus de journalisation redirig&eacute;e sont lanc&eacute;s par le processus
-    httpd parent, et h&eacute;ritent de l'UID de ce dernier. Cela signifie que les
-    programmes de journalisation dirig&eacute;e s'ex&eacute;cutent g&eacute;n&eacute;ralement en tant que
-    root. Il est donc tr&egrave;s important que ces programmes soient simples et
-    s&eacute;curis&eacute;s.</p>
-
-    <p>Un des grands avantages de la journalisation redirig&eacute;e est la possibilit&eacute;
-    d'effectuer la rotation des journaux sans avoir &agrave; red&eacute;marrer le serveur. Pour
-    accomplir cette t&acirc;che, le serveur HTTP Apache fournit un programme simple
-    appel&eacute; <program>rotatelogs</program>. Par exemple, pour une rotation des
+    pendant l'exécution du serveur.
+    (Nous dénommons cette technique "journalisation
+    redirigée fiable" grâce à cette dernière fonctionnalité.)</p>
+
+    <p>Les processus de journalisation redirigée sont lancés par le processus
+    httpd parent, et héritent de l'UID de ce dernier. Cela signifie que les
+    programmes de journalisation dirigée s'exécutent généralement en tant que
+    root. Il est donc très important que ces programmes soient simples et
+    sécurisés.</p>
+
+    <p>Un des grands avantages de la journalisation redirigée est la possibilité
+    d'effectuer la rotation des journaux sans avoir à redémarrer le serveur. Pour
+    accomplir cette tâche, le serveur HTTP Apache fournit un programme simple
+    appelé <program>rotatelogs</program>. Par exemple, pour une rotation des
     journaux toutes les 24 heures, ajoutez ces lignes :</p>
 
     <highlight language="config">
       CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common
     </highlight>
 
-    <p>Notez que l'ensemble de la commande qui sera appel&eacute;e par le tube de
-    communication a &eacute;t&eacute; plac&eacute;e entre guillemets. Bien que cet exemple
-    concerne le journal des acc&egrave;s, la m&ecirc;me technique peut &ecirc;tre utilis&eacute;e
+    <p>Notez que l'ensemble de la commande qui sera appelée par le tube de
+    communication a été placée entre guillemets. Bien que cet exemple
+    concerne le journal des accès, la même technique peut être utilisée
     pour le journal des erreurs.</p>
 
-    <p>Comme la journalisation conditionnelle, la journalisation redirig&eacute;e est
-    un outil tr&egrave;s puissant, mais si elle existe, il est pr&eacute;f&eacute;rable d'utiliser
-    une solution plus simple comme le traitement &agrave; posteriori hors ligne.</p>
+    <p>Comme la journalisation conditionnelle, la journalisation redirigée est
+    un outil très puissant, mais si elle existe, il est préférable d'utiliser
+    une solution plus simple comme le traitement à posteriori hors ligne.</p>
 
 
-  <p>Par d&eacute;faut, le processus de redirection du journal est lanc&eacute; sans
+  <p>Par défaut, le processus de redirection du journal est lancé sans
   invoquer un shell. Pour invoquer un shell, utilisez "<code>|$</code>"
-  au lieu de "<code>|</code>" (en g&eacute;n&eacute;ral avec <code>/bin/sh -c</code>)
+  au lieu de "<code>|</code>" (en général avec <code>/bin/sh -c</code>)
   :</p>
 
     <highlight language="config">
@@ -643,72 +643,72 @@ CustomLog "|$/usr/local/apache/bin/rotatelogs   /var/log/access_log 86400" commo
     </highlight>
 
 
-    <p>Il s'agissait du comportement par d&eacute;faut sous Apache 2.2. Selon
-    les sp&eacute;cificit&eacute;s du shell, ceci peut g&eacute;n&eacute;rer un processus shell
-    suppl&eacute;mentaire pour toute la dur&eacute;e du programme de redirection du
-    journal, et induire des probl&egrave;mes de gestion de signaux au cours du
-    red&eacute;marrage. La notation "<code>||</code>" est aussi support&eacute;e pour
-    des raisons de compatibilit&eacute; avec Apache 2.2 et est &eacute;quivalente &agrave;
+    <p>Il s'agissait du comportement par défaut sous Apache 2.2. Selon
+    les spécificités du shell, ceci peut générer un processus shell
+    supplémentaire pour toute la durée du programme de redirection du
+    journal, et induire des problèmes de gestion de signaux au cours du
+    redémarrage. La notation "<code>||</code>" est aussi supportée pour
+    des raisons de compatibilité avec Apache 2.2 et est équivalente à
     "<code>|</code>".</p>
 
-    <note><title>Note &agrave; propos de la plateforme Windows</title>
-    <p>Notez que sous Windows, la m&eacute;moire allou&eacute;e au bureau (desktop
+    <note><title>Note à propos de la plateforme Windows</title>
+    <p>Notez que sous Windows, la mémoire allouée au bureau (desktop
     heap) peut devenir insuffisante si vous utilisez de nombreux
-    processus vers lesquels sont redirig&eacute;s des journaux via un pipe, et
-    ceci particuli&egrave;rement si httpd s'ex&eacute;cute en tant que service. La
-    quantit&eacute; de m&eacute;moire du bureau allou&eacute;e &agrave; chaque service est sp&eacute;cifi&eacute;e
-    dans le troisi&egrave;me argument du param&egrave;tre <code>SharedSection</code>
-    de la cl&eacute; de registre
+    processus vers lesquels sont redirigés des journaux via un pipe, et
+    ceci particulièrement si httpd s'exécute en tant que service. La
+    quantité de mémoire du bureau allouée à chaque service est spécifiée
+    dans le troisième argument du paramètre <code>SharedSection</code>
+    de la clé de registre
     HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\SubSystems\Windows.
     <strong>Modifiez cette valeur avec prudence</strong> ; les
-    pr&eacute;cautions d'usage s'imposent lorsqu'on modifie la base de registre,
-    mais vous pouvez aussi saturer la m&eacute;moire du bureau si vous
-    sp&eacute;cifiez une valeur trop &eacute;lev&eacute;e.</p>
+    précautions d'usage s'imposent lorsqu'on modifie la base de registre,
+    mais vous pouvez aussi saturer la mémoire du bureau si vous
+    spécifiez une valeur trop élevée.</p>
     </note>
     </section>
 
   <section id="virtualhost">
-    <title>H&ocirc;tes virtuels</title>
+    <title>Hôtes virtuels</title>
 
-    <p>Lorsqu'un serveur poss&egrave;de plusieurs <a href
-    ="vhosts/">h&ocirc;tes virtuels</a>, il existe de nombreuses solutions pour g&eacute;rer
+    <p>Lorsqu'un serveur possède plusieurs <a href
+    ="vhosts/">hôtes virtuels</a>, il existe de nombreuses solutions pour gérer
     les fichiers journaux. Par exemple, on peut utiliser les journaux comme
-    s'il s'agissait d'un serveur avec un seul h&ocirc;te. Il suffit pour cela de
+    s'il s'agissait d'un serveur avec un seul hôte. Il suffit pour cela de
     placer les directives de journalisation en dehors des sections
     <directive module="core" type="section">VirtualHost</directive> au niveau
     du serveur principal, ce qui a pour effet de journaliser toutes les
-    requ&ecirc;tes dans le m&ecirc;me journal des acc&egrave;s et des erreurs. Cette technique
-    est cependant inappropri&eacute;e pour recueillir des statistiques sur chaque
-    h&ocirc;te virtuel individuellement.</p>
+    requêtes dans le même journal des accès et des erreurs. Cette technique
+    est cependant inappropriée pour recueillir des statistiques sur chaque
+    hôte virtuel individuellement.</p>
 
     <p>Si des directives <directive module=
     "mod_log_config">CustomLog</directive> ou
-    <directive module="core">ErrorLog</directive> sont plac&eacute;es dans une section
+    <directive module="core">ErrorLog</directive> sont placées dans une section
     <directive module="core" type="section">VirtualHost</directive>, toutes les
-    requ&ecirc;tes ou erreurs pour cet h&ocirc;te virtuel ne seront enregistr&eacute;es que dans
-    le fichier sp&eacute;cifi&eacute;. Tout h&ocirc;te virtuel qui ne poss&egrave;de pas de directives de
-    journalisation verra ses requ&ecirc;tes enregistr&eacute;es dans le journal du serveur
-    principal. Cette technique est appropri&eacute;e pour un petit nombre d'h&ocirc;tes
-    virtuels, mais si ce nombre est important, elle peut devenir compliqu&eacute;e &agrave;
-    g&eacute;rer. En outre, des probl&egrave;mes de <a
+    requêtes ou erreurs pour cet hôte virtuel ne seront enregistrées que dans
+    le fichier spécifié. Tout hôte virtuel qui ne possède pas de directives de
+    journalisation verra ses requêtes enregistrées dans le journal du serveur
+    principal. Cette technique est appropriée pour un petit nombre d'hôtes
+    virtuels, mais si ce nombre est important, elle peut devenir compliquée à
+    gérer. En outre, des problèmes de <a
     href="vhosts/fd-limits.html">nombre de descripteurs
-    de fichiers insuffisant</a> peuvent rapidement appara&icirc;tre.</p>
+    de fichiers insuffisant</a> peuvent rapidement apparaître.</p>
 
-    <p>Il existe un tr&egrave;s bon compromis pour le journal des acc&egrave;s. En int&eacute;grant
-    les informations &agrave; propos de l'h&ocirc;te virtuel &agrave; la cha&icirc;ne de format du
-    journal, il est possible de journaliser tous les h&ocirc;tes dans le m&ecirc;me
-    journal, puis de s&eacute;parer ult&eacute;rieurement le journal en plusieurs journaux
-    individuels. Consid&eacute;rons par exemple les directives suivantes :</p>
+    <p>Il existe un très bon compromis pour le journal des accès. En intégrant
+    les informations à propos de l'hôte virtuel à la chaîne de format du
+    journal, il est possible de journaliser tous les hôtes dans le même
+    journal, puis de séparer ultérieurement le journal en plusieurs journaux
+    individuels. Considérons par exemple les directives suivantes :</p>
 
     <highlight language="config">
 LogFormat "%v %l %u %t \"%r\" %&gt;s %b" comonvhost
 CustomLog logs/access_log comonvhost
     </highlight>
 
-    <p>Le champ <code>%v</code> sert &agrave; enregistrer le nom de l'h&ocirc;te virtuel qui
-    traite la requ&ecirc;te. Un programme tel que <a
-    href="programs/split-logfile.html">split-logfile</a> peut ensuite &ecirc;tre utilis&eacute;
-    pour g&eacute;n&eacute;rer "&agrave; froid" autant de journaux que d'h&ocirc;tes virtuels.</p>
+    <p>Le champ <code>%v</code> sert à enregistrer le nom de l'hôte virtuel qui
+    traite la requête. Un programme tel que <a
+    href="programs/split-logfile.html">split-logfile</a> peut ensuite être utilisé
+    pour générer "à froid" autant de journaux que d'hôtes virtuels.</p>
   </section>
 
   <section id="other">
@@ -733,45 +733,45 @@ CustomLog logs/access_log comonvhost
     </related>
 
     <section>
-      <title>Enregistrement du nombre r&eacute;el d'octets envoy&eacute;s et re&ccedil;us</title>
+      <title>Enregistrement du nombre réel d'octets envoyés et reçus</title>
 
       <p>Le module <module>mod_logio</module> fournit deux champs
-      <directive module="mod_log_config">LogFormat</directive> suppl&eacute;mentaires
-      (%I et %O) qui permettent d'enregistrer le nombre r&eacute;el d'octets re&ccedil;us et
-      envoy&eacute;s sur le r&eacute;seau.</p>
+      <directive module="mod_log_config">LogFormat</directive> supplémentaires
+      (%I et %O) qui permettent d'enregistrer le nombre réel d'octets reçus et
+      envoyés sur le réseau.</p>
     </section>
 
     <section>
       <title>Journalisation de style investigation judiciaire (forensic logging)</title>
 
       <p>Le module <module>mod_log_forensic</module> permet la journalisation
-      &agrave; des fins d'investigation judiciaire des requ&ecirc;tes des clients. La
-      journalisation est effectu&eacute;e avant et apr&egrave;s le traitement de la requ&ecirc;te,
-      qui fait donc l'objet de deux entr&eacute;es dans le journal. Le g&eacute;n&eacute;rateur de
-      journaux d'investigation est tr&egrave;s strict et ne permet aucune
-      personnalisation. C'est un inestimable outil de d&eacute;bogage et de s&eacute;curit&eacute;.</p>
+      à des fins d'investigation judiciaire des requêtes des clients. La
+      journalisation est effectuée avant et après le traitement de la requête,
+      qui fait donc l'objet de deux entrées dans le journal. Le générateur de
+      journaux d'investigation est très strict et ne permet aucune
+      personnalisation. C'est un inestimable outil de débogage et de sécurité.</p>
     </section>
 
     <section id="pidfile">
       <title>Fichier PID</title>
 
-      <p>Au d&eacute;marrage, le d&eacute;mon httpd Apache enregistre l'identifiant du
+      <p>Au démarrage, le démon httpd Apache enregistre l'identifiant du
       processus httpd parent dans le fichier <code>logs/httpd.pid</code>.
-      Le nom de ce fichier peut &ecirc;tre modifi&eacute; &agrave; l'aide de la directive
+      Le nom de ce fichier peut être modifié à l'aide de la directive
       <directive module="mpm_common">PidFile</directive>. Cet identifiant
-      permet &agrave; l'administrateur de red&eacute;marrer et arr&ecirc;ter le d&eacute;mon en
+      permet à l'administrateur de redémarrer et arrêter le démon en
       envoyant des signaux au processus parent ; sous Windows, vous devez
-      utiliser l'option de ligne de commande -k. Pour plus de d&eacute;tails,
-      consulter la page <a href="stopping.html">Arr&ecirc;t et red&eacute;marrage</a>.</p>
+      utiliser l'option de ligne de commande -k. Pour plus de détails,
+      consulter la page <a href="stopping.html">Arrêt et redémarrage</a>.</p>
     </section>
 
     <section id="scriptlog">
       <title>Journal des scripts</title>
 
-      <p>Afin de faciliter le d&eacute;bogage, la directive
+      <p>Afin de faciliter le débogage, la directive
       <directive module="mod_cgi">ScriptLog</directive> vous permet
-      d'enregistrer les entr&eacute;es et sorties des scripts CGI. Elle ne doit &ecirc;tre
-      utilis&eacute;e que pendant la phase de test, et en aucun cas sur un
+      d'enregistrer les entrées et sorties des scripts CGI. Elle ne doit être
+      utilisée que pendant la phase de test, et en aucun cas sur un
       serveur en production. Vous trouverez plus d'informations dans la
       documentation du module <a href="mod/mod_cgi.html">mod_cgi</a>.</p>
     </section>
diff --git a/docs/manual/mod/mod_access_compat.xml.fr b/docs/manual/mod/mod_access_compat.xml.fr
index 2ec19a38b3a..7382a2cfc60 100644
--- a/docs/manual/mod/mod_access_compat.xml.fr
+++ b/docs/manual/mod/mod_access_compat.xml.fr
@@ -1,7 +1,7 @@
-<?xml version="1.0"?>
+<?xml version="1.0" encoding="UTF-8" ?>
 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1673563:1738542 (outdated) -->
+<!-- English Revision: 1738542 -->
 <!-- French translation : Lucien GENTIS -->
 <!-- Reviewed by : Vincent Deffontaines -->
 
@@ -25,15 +25,15 @@
 <modulesynopsis metafile="mod_access_compat.xml.meta">
 
 <name>mod_access_compat</name>
-<description>Autorisations de groupe &agrave; base de nom d'h&ocirc;te (nom ou
+<description>Autorisations de groupe à base de nom d'hôte (nom ou
 adresse IP)</description>
 <status>Extension</status>
 <sourcefile>mod_access_compat.c</sourcefile>
 <identifier>access_compat_module</identifier>
 <compatibility>Disponible dans la version 2.3 du serveur HTTP Apache
-&agrave; des fins de compatibilit&eacute;
-avec les pr&eacute;c&eacute;dentes versions d'Apache httpd 2.x. Les directives fournies par
-ce module sont devenues obsol&egrave;tes depuis la refonte d'authz. Voir
+à des fins de compatibilité
+avec les précédentes versions d'Apache httpd 2.x. Les directives fournies par
+ce module sont devenues obsolètes depuis la refonte d'authz. Voir
 <module>mod_authz_host</module></compatibility>
 
 <summary>
@@ -44,46 +44,56 @@ ce module sont devenues obsol&egrave;tes depuis la refonte d'authz. Voir
     <directive module="core" type="section">Location</directive>, ainsi
     que dans les fichiers <code><a
     href="core.html#accessfilename">.htaccess</a></code> et permettent
-    de contr&ocirc;ler l'acc&egrave;s &agrave; certaines parties du serveur. On peut
-    contr&ocirc;ler cet acc&egrave;s en fonction du nom d'h&ocirc;te du client, de son
-    adresse IP ou d'autres caract&eacute;ristiques de la requ&ecirc;te, telles
-    qu'elles sont enregistr&eacute;es dans les <a href="../env.html">variables
+    de contrôler l'accès à certaines parties du serveur. On peut
+    contrôler cet accès en fonction du nom d'hôte du client, de son
+    adresse IP ou d'autres caractéristiques de la requête, telles
+    qu'elles sont enregistrées dans les <a href="../env.html">variables
     d'environnement</a>. Les directives <directive
     module="mod_access_compat">Allow</directive> et <directive
-    module="mod_access_compat">Deny</directive> permettent de sp&eacute;cifier
-    quels clients sont ou ne sont pas autoris&eacute;s &agrave; acc&eacute;der au serveur,
+    module="mod_access_compat">Deny</directive> permettent de spécifier
+    quels clients sont ou ne sont pas autorisés à accéder au serveur,
     alors que la directive <directive
-    module="mod_access_compat">Order</directive> d&eacute;finit le statut
-    d'acc&egrave;s par d&eacute;faut, et d&eacute;termine la mani&egrave;re dont les directives
+    module="mod_access_compat">Order</directive> définit le statut
+    d'accès par défaut, et détermine la manière dont les directives
     <directive module="mod_access_compat">Allow</directive> et
     <directive module="mod_access_compat">Deny</directive> interagissent
     entre elles.</p>
 
-    <p>Les restrictions d'acc&egrave;s &agrave; base de nom d'h&ocirc;te et
-    l'authentification &agrave; base de mot de passe peuvent &ecirc;tre impl&eacute;ment&eacute;es
-    simultan&eacute;ment. Dans ce cas, on utilise la directive <directive
-    module="mod_access_compat">Satisfy</directive> pour d&eacute;terminer la
-    mani&egrave;re dont ces deux modes de restrictions interagissent.</p>
+    <p>Les restrictions d'accès à base de nom d'hôte et
+    l'authentification à base de mot de passe peuvent être implémentées
+    simultanément. Dans ce cas, on utilise la directive <directive
+    module="mod_access_compat">Satisfy</directive> pour déterminer la
+    manière dont ces deux modes de restrictions interagissent.</p>
 
     <note type="warning"><title>Note</title>
       <p>Les directives fournies par le module
-      <module>mod_access_compat</module> sont devenues obsol&egrave;tes depuis
-      la refonte d'authz. Voir <module>mod_authz_host</module>.</p>
+      <module>mod_access_compat</module> sont devenues obsolètes depuis
+      la refonte du module <module>mod_authz_host</module>. Mélanger d'anciennes
+      directives comme <directive
+      module="mod_access_compat">Order</directive>, <directive
+      module="mod_access_compat">Allow</directive> ou <directive
+      module="mod_access_compat">Deny</directive> avec des nouvelles comme
+      <directive module="mod_authz_core">Require</directive> est techniquement
+      possible mais déconseillé. En effet, <module>mod_access_compat</module> a
+      été conçu pour supporter des configurations ne contenant que des anciennes
+      directives afin de faciliter le passage à la version 2.4. Voir le document
+      <a href="../upgrading.html">upgrading</a> pour plus de détails.
+      </p>
     </note>
 
-    <p>En g&eacute;n&eacute;ral, les directives de restriction d'acc&egrave;s s'appliquent &agrave;
-    toutes les m&eacute;thodes d'acc&egrave;s (<code>GET</code>, <code>PUT</code>,
+    <p>En général, les directives de restriction d'accès s'appliquent à
+    toutes les méthodes d'accès (<code>GET</code>, <code>PUT</code>,
     <code>POST</code>, etc...). C'est d'ailleurs ce que l'on souhaite
     dans la plupart des cas. Il est cependant possible de restreindre
-    certaines m&eacute;thodes, alors que les autres m&eacute;thodes ne se verront
-    impos&eacute;e aucune restriction, en regroupant les directives &agrave;
-    l'int&eacute;rieur d'une section <directive module="core"
+    certaines méthodes, alors que les autres méthodes ne se verront
+    imposée aucune restriction, en regroupant les directives à
+    l'intérieur d'une section <directive module="core"
     type="section">Limit</directive>.</p>
 
     <note><title>Fusion des sections de configuration</title>
-      <p>Lorsqu'une directive fournie par ce module est utilis&eacute;e dans
-      une nouvelle section de configuration, cette derni&egrave;re n'h&eacute;rite
-      d'aucune directive d&eacute;finie dans une section pr&eacute;c&eacute;dente.</p>
+      <p>Lorsqu'une directive fournie par ce module est utilisée dans
+      une nouvelle section de configuration, cette dernière n'hérite
+      d'aucune directive définie dans une section précédente.</p>
     </note>
 </summary>
 
@@ -93,30 +103,30 @@ ce module sont devenues obsol&egrave;tes depuis la refonte d'authz. Voir
 
 <directivesynopsis>
 <name>Allow</name>
-<description>Sp&eacute;cifie quels h&ocirc;tes peuvent acc&eacute;der &agrave; une certaine zone du
+<description>Spécifie quels hôtes peuvent accéder à une certaine zone du
 serveur</description>
-<syntax> Allow from all|<var>h&ocirc;te</var>|env=[!]<var>variable
+<syntax> Allow from all|<var>hôte</var>|env=[!]<var>variable
 d'environnement</var>
-[<var>h&ocirc;te</var>|env=[!]<var>variable d'environnement</var>] ...</syntax>
+[<var>hôte</var>|env=[!]<var>variable d'environnement</var>] ...</syntax>
 <contextlist><context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>Limit</override>
 
 <usage>
-    <p>La directive <directive>Allow</directive> permet de d&eacute;finir quels
-    h&ocirc;tes ont le droit d'acc&eacute;der &agrave; une certaine partie du serveur. On
-    peut contr&ocirc;ler l'acc&egrave;s par nom d'h&ocirc;te, adresse IP, intervalle
-    d'adresses IP, ou toute autre caract&eacute;ristique de la requ&ecirc;te client
-    enregistr&eacute;e dans les variables d'environnement.</p>
+    <p>La directive <directive>Allow</directive> permet de définir quels
+    hôtes ont le droit d'accéder à une certaine partie du serveur. On
+    peut contrôler l'accès par nom d'hôte, adresse IP, intervalle
+    d'adresses IP, ou toute autre caractéristique de la requête client
+    enregistrée dans les variables d'environnement.</p>
 
     <p>Le premier argument de cette directive est toujours
     <code>from</code>. Les arguments suivants peuvent prendre trois
-    formes diff&eacute;rentes. Si <code>Allow from all</code> est sp&eacute;cifi&eacute;,
-    tout h&ocirc;te se voit accord&eacute; l'acc&egrave;s, en tenant compte des directives
+    formes différentes. Si <code>Allow from all</code> est spécifié,
+    tout hôte se voit accordé l'accès, en tenant compte des directives
     <directive module="mod_access_compat">Deny</directive> et <directive
-    module="mod_access_compat">Order</directive> comme d&eacute;crit plus loin.
-    Pour ne permettre l'acc&egrave;s au serveur qu'&agrave; un h&ocirc;te ou un groupe
-    d'h&ocirc;tes particuliers, on peut sp&eacute;cifier un <em>nom d'h&ocirc;te</em> sous
+    module="mod_access_compat">Order</directive> comme décrit plus loin.
+    Pour ne permettre l'accès au serveur qu'à un hôte ou un groupe
+    d'hôtes particuliers, on peut spécifier un <em>nom d'hôte</em> sous
     une des formes suivantes :</p>
 
     <dl>
@@ -127,30 +137,30 @@ d'environnement</var>
 Allow from example.org
 Allow from .net example.edu
       </highlight>
-      <p>Les h&ocirc;tes dont les noms correspondent ou se terminent par la
-      cha&icirc;ne sp&eacute;cifi&eacute;e ont l'autorisation d'acc&egrave;s. Seules les
-      composantes enti&egrave;res du nom d'h&ocirc;te doivent correspondre ; ainsi,
+      <p>Les hôtes dont les noms correspondent ou se terminent par la
+      chaîne spécifiée ont l'autorisation d'accès. Seules les
+      composantes entières du nom d'hôte doivent correspondre ; ainsi,
       dans l'exemple ci-dessus, <code>foo.example.org</code>
       correspondra, mais <code>fooexample.org</code> ne conviendra pas.
       Avec cette configuration, Apache httpd va effectuer une double recherche
       DNS sur l'adresse IP du client, sans tenir compte de la
-      d&eacute;finition de la directive <directive
+      définition de la directive <directive
       module="core">HostnameLookups</directive>. Tout d'abord, une
-      recherche DNS inverse sur l'adresse IP est effectu&eacute;e pour
-      d&eacute;terminer le nom d'h&ocirc;te associ&eacute;, puis une recherche directe sur
-      le nom d'h&ocirc;te est effectu&eacute;e afin de s'assurer qu'il correspond
-      bien &agrave; l'adresse IP originale. L'acc&egrave;s ne sera accord&eacute; que si le
-      nom d'h&ocirc;te correspond et si les recherches DNS inverse et directe
+      recherche DNS inverse sur l'adresse IP est effectuée pour
+      déterminer le nom d'hôte associé, puis une recherche directe sur
+      le nom d'hôte est effectuée afin de s'assurer qu'il correspond
+      bien à l'adresse IP originale. L'accès ne sera accordé que si le
+      nom d'hôte correspond et si les recherches DNS inverse et directe
       concordent.</p></dd>
 
-      <dt>Une adresse IP compl&egrave;te</dt>
+      <dt>Une adresse IP complète</dt>
 
       <dd>
       <highlight language="config">
 Allow from 10.1.2.3
 Allow from 192.168.1.104 192.168.1.205
       </highlight>
-      <p>L'adresse IP d'un h&ocirc;te auquel on a accord&eacute; l'acc&egrave;s</p></dd>
+      <p>L'adresse IP d'un hôte auquel on a accordé l'accès</p></dd>
 
       <dt>Une adresse IP partielle</dt>
 
@@ -159,33 +169,33 @@ Allow from 192.168.1.104 192.168.1.205
 Allow from 10.1
 Allow from 10 172.20 192.168.2
       </highlight>
-      <p>De un &agrave; trois des premiers octets d'une adresse IP, afin de
-      restreindre l'acc&egrave;s &agrave; un sous-r&eacute;seau.</p></dd>
+      <p>De un à trois des premiers octets d'une adresse IP, afin de
+      restreindre l'accès à un sous-réseau.</p></dd>
 
-      <dt>Une paire r&eacute;seau/masque de sous-r&eacute;seau</dt>
+      <dt>Une paire réseau/masque de sous-réseau</dt>
 
       <dd>
       <highlight language="config">
         Allow from 10.1.0.0/255.255.0.0
       </highlight>
-      <p>Un r&eacute;seau a.b.c.d, et un masque de sous-r&eacute;seau w.x.y.z, pour
-      une d&eacute;finition plus pr&eacute;cise de la restriction d'acc&egrave;s impos&eacute;e &agrave; un
-      sous-r&eacute;seau.</p></dd>
+      <p>Un réseau a.b.c.d, et un masque de sous-réseau w.x.y.z, pour
+      une définition plus précise de la restriction d'accès imposée à un
+      sous-réseau.</p></dd>
 
-      <dt>Une sp&eacute;cification CIDR r&eacute;seau/nnn</dt>
+      <dt>Une spécification CIDR réseau/nnn</dt>
 
       <dd>
       <highlight language="config">
         Allow from 10.1.0.0/16
       </highlight>
-      <p>Identique au cas pr&eacute;c&eacute;dent, mis &agrave; part que le masque est
-      constitu&eacute; des nnn bits de poids fort.</p></dd>
+      <p>Identique au cas précédent, mis à part que le masque est
+      constitué des nnn bits de poids fort.</p></dd>
     </dl>
 
-    <p>Notez que les trois derniers exemples d&eacute;signent le m&ecirc;me ensemble
-    d'h&ocirc;tes.</p>
+    <p>Notez que les trois derniers exemples désignent le même ensemble
+    d'hôtes.</p>
 
-    <p>On peut sp&eacute;cifier des adresses et sous-r&eacute;seaux IPv6 de la mani&egrave;re
+    <p>On peut spécifier des adresses et sous-réseaux IPv6 de la manière
     suivante :</p>
 
     <highlight language="config">
@@ -193,23 +203,23 @@ Allow from 2001:db8::a00:20ff:fea7:ccea
 Allow from 2001:db8::a00:20ff:fea7:ccea/10
     </highlight>
 
-    <p>Le troisi&egrave;me format d'argument de la directive
-    <directive>Allow</directive> permet de contr&ocirc;ler l'acc&egrave;s au serveur
+    <p>Le troisième format d'argument de la directive
+    <directive>Allow</directive> permet de contrôler l'accès au serveur
     en fonction de l'existence d'une <a
     href="../env.html">variable d'environnement</a>. Lorsque <code>Allow
-    from env=<var>variable d'environnement</var></code> est sp&eacute;cifi&eacute;, la
-    requ&ecirc;te est autoris&eacute;e si la variable d'environnement <var>variable
+    from env=<var>variable d'environnement</var></code> est spécifié, la
+    requête est autorisée si la variable d'environnement <var>variable
     d'environnement</var> existe. En revanche, lorsque <code>Allow from
-    env=!<var>env-variable</var></code> est sp&eacute;cifi&eacute;, la
-    requ&ecirc;te est autoris&eacute;e si la variable d'environnement <var>variable
-    d'environnement</var> n'existe pas. Le serveur permet de d&eacute;finir
+    env=!<var>env-variable</var></code> est spécifié, la
+    requête est autorisée si la variable d'environnement <var>variable
+    d'environnement</var> n'existe pas. Le serveur permet de définir
     avec souplesse des variables d'environnement en se basant sur les
-    caract&eacute;ristiques de la requ&ecirc;te client et en utilisant les directives
+    caractéristiques de la requête client et en utilisant les directives
     fournies par le module <module>mod_setenvif</module>. Ainsi, on peut
     utiliser la directive <directive>Allow</directive> pour permettre
-    l'acc&egrave;s en fonction de param&egrave;tres comme le <code>User-Agent</code>
+    l'accès en fonction de paramètres comme le <code>User-Agent</code>
     (type de navigateur) des clients, le <code>Referer</code>, ou
-    d'autres champs d'en-t&ecirc;te de la requ&ecirc;te HTTP.</p>
+    d'autres champs d'en-tête de la requête HTTP.</p>
 
     <highlight language="config">
 SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
@@ -220,32 +230,32 @@ SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
 &lt;/Directory&gt;
     </highlight>
 
-    <p>Dans cet exemple, les navigateurs dont la cha&icirc;ne user-agent
+    <p>Dans cet exemple, les navigateurs dont la chaîne user-agent
     commence par <code>KnockKnock/2.0</code> se verront accorder
-    l'acc&egrave;s, alors que tous les autres seront rejet&eacute;s.</p>
+    l'accès, alors que tous les autres seront rejetés.</p>
 
     <note><title>Fusion des sections de configuration</title>
-      <p>Lorsqu'une directive fournie par ce module est utilis&eacute;e dans
-      une nouvelle section de configuration, cette derni&egrave;re n'h&eacute;rite
-      d'aucune directive d&eacute;finie dans une section pr&eacute;c&eacute;dente.</p>
+      <p>Lorsqu'une directive fournie par ce module est utilisée dans
+      une nouvelle section de configuration, cette dernière n'hérite
+      d'aucune directive définie dans une section précédente.</p>
     </note>
 </usage>
 </directivesynopsis>
 
 <directivesynopsis>
 <name>Deny</name>
-<description>D&eacute;finit quels h&ocirc;tes ne sont pas autoris&eacute;s &agrave; acc&eacute;der au
+<description>Définit quels hôtes ne sont pas autorisés à accéder au
 serveur</description>
-<syntax> Deny from all|<var>h&ocirc;te</var>|env=[!]<var>variable
+<syntax> Deny from all|<var>hôte</var>|env=[!]<var>variable
 d'environnement</var>
-[<var>h&ocirc;te</var>|env=[!]<var>variable d'environnement</var>] ...</syntax>
+[<var>hôte</var>|env=[!]<var>variable d'environnement</var>] ...</syntax>
 <contextlist><context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>Limit</override>
 
 <usage>
-    <p>Cette directive permet de restreindre l'acc&egrave;s au serveur en
-    fonction du nom d'h&ocirc;te, de l'adresse IP ou de variables
+    <p>Cette directive permet de restreindre l'accès au serveur en
+    fonction du nom d'hôte, de l'adresse IP ou de variables
     d'environnement. Les arguments de la directive
     <directive>Deny</directive> sont identiques aux arguments de la
     directive <directive
@@ -255,9 +265,9 @@ d'environnement</var>
 
 <directivesynopsis>
 <name>Order</name>
-<description>D&eacute;finit le statut d'acc&egrave;s par d&eacute;faut et l'ordre dans lequel
+<description>Définit le statut d'accès par défaut et l'ordre dans lequel
 les directives <directive>Allow</directive> et
-<directive>Deny</directive> sont &eacute;valu&eacute;es.</description>
+<directive>Deny</directive> sont évaluées.</description>
 <syntax> Order <var>ordre</var></syntax>
 <default>Order Deny,Allow</default>
 <contextlist><context>directory</context><context>.htaccess</context>
@@ -266,98 +276,98 @@ les directives <directive>Allow</directive> et
 
 <usage>
 
-    <p>La directive <directive>Order</directive>, associ&eacute;e aux
+    <p>La directive <directive>Order</directive>, associée aux
     directives <directive module="mod_access_compat">Allow</directive>
     et <directive module="mod_access_compat">Deny</directive>,
-    impl&eacute;mente un syst&egrave;me de contr&ocirc;le d'acc&egrave;s en trois passes. Au cours
-    de la premi&egrave;re passe, ce sont soit toutes les directives <directive
+    implémente un système de contrôle d'accès en trois passes. Au cours
+    de la première passe, ce sont soit toutes les directives <directive
     module="mod_access_compat">Allow</directive>, soit toutes les
     directives <directive
-    module="mod_access_compat">Deny</directive> qui sont trait&eacute;es, selon
-    la d&eacute;finition de la directive <directive
+    module="mod_access_compat">Deny</directive> qui sont traitées, selon
+    la définition de la directive <directive
     module="mod_access_compat">Order</directive>. Le reste des
     directives (<directive module="mod_access_compat">Deny</directive>
     ou <directive module="mod_access_compat">Allow</directive>) est
-    trait&eacute; au cours de la seconde passe. La troisi&egrave;me passe s'applique &agrave;
-    toutes les requ&ecirc;tes qui ne sont concern&eacute;es par aucune des deux
-    premi&egrave;res passes.</p>
+    traité au cours de la seconde passe. La troisième passe s'applique à
+    toutes les requêtes qui ne sont concernées par aucune des deux
+    premières passes.</p>
 
     <p>Notez que toutes les directives <directive
     module="mod_access_compat">Allow</directive> et <directive
-    module="mod_access_compat">Deny</directive> sont trait&eacute;es, &agrave; la
-    diff&eacute;rence d'un pare-feu classique o&ugrave; seule la premi&egrave;re r&egrave;gle qui
-    correspond est utilis&eacute;e. La derni&egrave;re directive qui correspond
-    s'applique ( &agrave; la diff&eacute;rence l&agrave; encore d'un pare-feu classique). De
+    module="mod_access_compat">Deny</directive> sont traitées, à la
+    différence d'un pare-feu classique où seule la première règle qui
+    correspond est utilisée. La dernière directive qui correspond
+    s'applique ( à la différence là encore d'un pare-feu classique). De
     plus, l'ordre dans lequel les lignes apparaissent dans le fichier de
     configuration n'a pas d'incidence -- toutes les lignes <directive
-    module="mod_access_compat">Allow</directive> sont consid&eacute;r&eacute;es comme
+    module="mod_access_compat">Allow</directive> sont considérées comme
     un groupe, toutes les lignes <directive
     module="mod_access_compat">Deny</directive> comme un autre, et le
-    statut par d&eacute;faut a son existence propre.</p>
+    statut par défaut a son existence propre.</p>
 
-    <p><em>Ordre</em> peut &ecirc;tre :</p>
+    <p><em>Ordre</em> peut être :</p>
 
     <dl>
       <dt><code>Allow,Deny</code></dt>
 
       <dd>Dans un premier temps, toutes les directives <directive
-      module="mod_access_compat">Allow</directive> sont &eacute;valu&eacute;es ; au
-      moins une d'entre elles doit correspondre, sinon la requ&ecirc;te est
-      rejet&eacute;e. Ensuite, toutes les directives <directive
-      module="mod_access_compat">Deny</directive> sont &eacute;valu&eacute;es. Si au
-      moins l'une d'entre elles correspond, la requ&ecirc;te est rejet&eacute;e.
-      Enfin, toute requ&ecirc;te qui ne correspond &agrave; aucune directive
+      module="mod_access_compat">Allow</directive> sont évaluées ; au
+      moins une d'entre elles doit correspondre, sinon la requête est
+      rejetée. Ensuite, toutes les directives <directive
+      module="mod_access_compat">Deny</directive> sont évaluées. Si au
+      moins l'une d'entre elles correspond, la requête est rejetée.
+      Enfin, toute requête qui ne correspond à aucune directive
       <directive module="mod_access_compat">Allow</directive> ou
-      <directive module="mod_access_compat">Deny</directive> est rejet&eacute;e
-      par d&eacute;faut.</dd>
+      <directive module="mod_access_compat">Deny</directive> est rejetée
+      par défaut.</dd>
 
       <dt><code>Deny,Allow</code></dt>
 
       <dd>Dans un premier temps, toutes les directives <directive
-      module="mod_access_compat">Deny</directive> sont &eacute;valu&eacute;es ; Si au
-      moins une d'entre elles correspond, la requ&ecirc;te est rejet&eacute;e,
-      <strong>&agrave; moins</strong> qu'elle corresponde aussi &agrave; une directive
+      module="mod_access_compat">Deny</directive> sont évaluées ; Si au
+      moins une d'entre elles correspond, la requête est rejetée,
+      <strong>à moins</strong> qu'elle corresponde aussi à une directive
       <directive module="mod_access_compat">Allow</directive>. Toute
-      requ&ecirc;te qui ne correspond &agrave; aucune directive <directive
+      requête qui ne correspond à aucune directive <directive
       module="mod_access_compat">Allow</directive> ou <directive
-      module="mod_access_compat">Deny</directive> est autoris&eacute;e.</dd>
+      module="mod_access_compat">Deny</directive> est autorisée.</dd>
 
       <dt><code>Mutual-failure</code></dt>
 
-      <dd>Cet argument a le m&ecirc;me effet que <code>Allow,Deny</code> et
-      est devenu de ce fait obsol&egrave;te.</dd>
+      <dd>Cet argument a le même effet que <code>Allow,Deny</code> et
+      est devenu de ce fait obsolète.</dd>
     </dl>
 
-    <p>Les mots-cl&eacute;s ne peuvent &ecirc;tre s&eacute;par&eacute;s que par des virgules ;
+    <p>Les mots-clés ne peuvent être séparés que par des virgules ;
     <em>aucun espace</em> ne doit s'intercaler entre eux.</p>
 
     <table border="1">
       <tr>
         <th>Match</th>
-        <th>R&eacute;sultat Allow,Deny</th>
-        <th>R&eacute;sultat Deny,Allow</th>
+        <th>Résultat Allow,Deny</th>
+        <th>Résultat Deny,Allow</th>
       </tr><tr>
-        <th>Correspond &agrave; Allow seulement</th>
-        <td>Requ&ecirc;te autoris&eacute;e</td>
-        <td>Requ&ecirc;te autoris&eacute;e</td>
+        <th>Correspond à Allow seulement</th>
+        <td>Requête autorisée</td>
+        <td>Requête autorisée</td>
       </tr><tr>
-        <th>Correspond &agrave; Deny seulement</th>
-        <td>Requ&ecirc;te rejet&eacute;e</td>
-        <td>Requ&ecirc;te rejet&eacute;e</td>
+        <th>Correspond à Deny seulement</th>
+        <td>Requête rejetée</td>
+        <td>Requête rejetée</td>
       </tr><tr>
         <th>Aucune correspondance</th>
-        <td>Par d&eacute;faut la seconde directive : rejet</td>
-        <td>Par d&eacute;faut la seconde directive : autorisation</td>
+        <td>Par défaut la seconde directive : rejet</td>
+        <td>Par défaut la seconde directive : autorisation</td>
       </tr><tr>
-        <th>Correspond &agrave; Allow &amp; Deny</th>
-        <td>La derni&egrave;re correspondance l'emporte : rejet</td>
-        <td>La derni&egrave;re correspondance l'emporte : autorisation</td>
+        <th>Correspond à Allow &amp; Deny</th>
+        <td>La dernière correspondance l'emporte : rejet</td>
+        <td>La dernière correspondance l'emporte : autorisation</td>
       </tr>
     </table>
 
-    <p>Dans cet exemple, tous les h&ocirc;tes du domaine example.org ont
-    l'autorisation d'acc&egrave;s ; tous les autres voient leur acc&egrave;s
-    refus&eacute;.</p>
+    <p>Dans cet exemple, tous les hôtes du domaine example.org ont
+    l'autorisation d'accès ; tous les autres voient leur accès
+    refusé.</p>
 
     <highlight language="config">
 Order Deny,Allow
@@ -365,13 +375,13 @@ Deny from all
 Allow from example.org
     </highlight>
 
-    <p>Dans l'exemple suivant, tous les h&ocirc;tes du domaine example.org ont
-    l'autorisation d'acc&egrave;s, sauf ceux du sous-domaine foo.example.org qui
-    voient leur acc&egrave;s refus&eacute;. Tous les h&ocirc;tes qui ne sont pas dans le
-    domaine example.org sont rejet&eacute;s car le statut par d&eacute;faut est positionn&eacute;
+    <p>Dans l'exemple suivant, tous les hôtes du domaine example.org ont
+    l'autorisation d'accès, sauf ceux du sous-domaine foo.example.org qui
+    voient leur accès refusé. Tous les hôtes qui ne sont pas dans le
+    domaine example.org sont rejetés car le statut par défaut est positionné
     sur <directive
     module="mod_access_compat">Deny</directive>, et consiste donc en un
-    refus d'acc&egrave;s.</p>
+    refus d'accès.</p>
 
     <highlight language="config">
 Order Allow,Deny
@@ -380,24 +390,24 @@ Deny from foo.example.org
     </highlight>
 
     <p>Par contre, si la valeur de la directive
-    <directive>Order</directive>, dans l'exemple pr&eacute;c&eacute;dent, est
-    <code>Deny,Allow</code>, tout le monde a l'autorisation d'acc&egrave;s.
-    Ceci est d&ucirc; au fait que <code>Allow from example.org</code> sera
-    &eacute;valu&eacute; en dernier, sans tenir compte de l'ordre r&eacute;el dans lequel les
+    <directive>Order</directive>, dans l'exemple précédent, est
+    <code>Deny,Allow</code>, tout le monde a l'autorisation d'accès.
+    Ceci est dû au fait que <code>Allow from example.org</code> sera
+    évalué en dernier, sans tenir compte de l'ordre réel dans lequel les
     directives apparaissent dans le fichier de configuration, et va
-    l'emporter sur <code>Deny from foo.example.org</code>. Tout h&ocirc;te qui
+    l'emporter sur <code>Deny from foo.example.org</code>. Tout hôte qui
     n'est pas dans le domaine <code>example.org</code> aura aussi
-    l'autorisation d'acc&egrave;s car le statut par d&eacute;faut est positionn&eacute; sur
+    l'autorisation d'accès car le statut par défaut est positionné sur
     <directive
     module="mod_access_compat">Allow</directive> et constitue donc une
-    autorisation d'acc&egrave;s.</p>
+    autorisation d'accès.</p>
 
-    <p>La pr&eacute;sence d'une directive <directive>Order</directive> peut
-    affecter le contr&ocirc;le d'acc&egrave;s &agrave; une partie du serveur m&ecirc;me en
+    <p>La présence d'une directive <directive>Order</directive> peut
+    affecter le contrôle d'accès à une partie du serveur même en
     l'abscence de directives <directive
     module="mod_access_compat">Allow</directive> et <directive
-    module="mod_access_compat">Deny</directive> associ&eacute;es, &agrave; cause de
-    son influence sur le statut par d&eacute;faut. Par exemple,</p>
+    module="mod_access_compat">Deny</directive> associées, à cause de
+    son influence sur le statut par défaut. Par exemple,</p>
 
     <highlight language="config">
 &lt;Directory "/www"&gt;
@@ -405,70 +415,70 @@ Deny from foo.example.org
 &lt;/Directory&gt;
     </highlight>
 
-    <p>va interdire tout acc&egrave;s au r&eacute;pertoire <code>/www</code> &agrave; cause
-    du statut d'acc&egrave;s par d&eacute;faut qui est d&eacute;fini &agrave; <directive
+    <p>va interdire tout accès au répertoire <code>/www</code> à cause
+    du statut d'accès par défaut qui est défini à <directive
     module="mod_access_compat">Deny</directive>.</p>
 
-    <p>La directive <directive>Order</directive> ne contr&ocirc;le l'ordre
-    dans lequel sont trait&eacute;es les directives d'acc&egrave;s qu'au cours de
+    <p>La directive <directive>Order</directive> ne contrôle l'ordre
+    dans lequel sont traitées les directives d'accès qu'au cours de
     chaque phase du traitement de la configuration du serveur. Ceci
     implique, par exemple, qu'une directive <directive
     module="mod_access_compat">Allow</directive> ou <directive
-    module="mod_access_compat">Deny</directive> situ&eacute;e dans une section
+    module="mod_access_compat">Deny</directive> située dans une section
     <directive module="core" type="section">Location</directive> sera
-    toujours &eacute;valu&eacute;e apr&egrave;s une directive <directive
+    toujours évaluée après une directive <directive
     module="mod_access_compat">Allow</directive> ou <directive
-    module="mod_access_compat">Deny</directive> situ&eacute;e dans une section
+    module="mod_access_compat">Deny</directive> située dans une section
     <directive module="core" type="section">Directory</directive> ou un
     fichier <code>.htaccess</code>, sans tenir compte de la
-    d&eacute;finition de la directive <directive>Order</directive>. Pour plus
-    de d&eacute;tails &agrave; propos de la fusion des sections de configuration, voir
+    définition de la directive <directive>Order</directive>. Pour plus
+    de détails à propos de la fusion des sections de configuration, voir
     le document <a
     href="../sections.html">Comment fonctionnent les sections Directory,
     Location et Files</a>.</p>
 
     <note><title>Fusion des sections de configuration</title>
-      <p>Lorsqu'une directive fournie par ce module est utilis&eacute;e dans
-      une nouvelle section de configuration, cette derni&egrave;re n'h&eacute;rite
-      d'aucune directive d&eacute;finie dans une section pr&eacute;c&eacute;dente.</p>
+      <p>Lorsqu'une directive fournie par ce module est utilisée dans
+      une nouvelle section de configuration, cette dernière n'hérite
+      d'aucune directive définie dans une section précédente.</p>
     </note>
 </usage>
 </directivesynopsis>
 
 <directivesynopsis>
 <name>Satisfy</name>
-<description>Interaction entre le contr&ocirc;le d'acc&egrave;s en fonction de l'h&ocirc;te
+<description>Interaction entre le contrôle d'accès en fonction de l'hôte
 et l'authentification utilisateur</description>
 <syntax>Satisfy Any|All</syntax>
 <default>Satisfy All</default>
 <contextlist><context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>AuthConfig</override>
-<compatibility>Affect&eacute; par <directive module="core" type="section"
+<compatibility>Affecté par <directive module="core" type="section"
 >Limit</directive> et <directive module="core"
-type="section">LimitExcept</directive> &agrave; partir de la version
+type="section">LimitExcept</directive> à partir de la version
 2.0.51</compatibility>
 <usage>
-    <p>Politique d'acc&egrave;s dans le cas o&ugrave; on utilise &agrave; la fois <directive
+    <p>Politique d'accès dans le cas où on utilise à la fois <directive
     module="mod_access_compat">Allow</directive> et <directive
     module="mod_authz_core">Require</directive>. L'argument est soit
     <code>All</code>, soit <code>Any</code>. L'utilisation de cette
-    directive n'a de sens que si l'acc&egrave;s &agrave; une zone particuli&egrave;re du
+    directive n'a de sens que si l'accès à une zone particulière du
     serveur est restreinte par utilisateur/mot de passe et en fonction
-    de l'adresse IP de l'h&ocirc;te client. Dans ce cas, par
-    d&eacute;faut (<code>All</code>), le client doit satisfaire &agrave; la
+    de l'adresse IP de l'hôte client. Dans ce cas, par
+    défaut (<code>All</code>), le client doit satisfaire à la
     restriction d'adresse, <em>et</em> fournir un couple
     utilisateur/mot de passe valide. Avec l'argument <code>Any</code>,
-    le client se verra accorder l'acc&egrave;s s'il satisfait &agrave; la restriction
+    le client se verra accorder l'accès s'il satisfait à la restriction
     d'adresse ou fournit un couple utilisateur/mot de passe valide. On
-    peut utiliser cette derni&egrave;re d&eacute;finition pour restreindre l'acc&egrave;s &agrave;
-    une zone par mot de passe, mais accorder l'acc&egrave;s aux clients
-    poss&eacute;dant certaines adresses IP sans qu'ils aient &agrave; fournir de mot
+    peut utiliser cette dernière définition pour restreindre l'accès à
+    une zone par mot de passe, mais accorder l'accès aux clients
+    possédant certaines adresses IP sans qu'ils aient à fournir de mot
     de passe.</p>
 
     <p>Par exemple, si vous souhaitez que les utilisateurs de votre
-    r&eacute;seau acc&egrave;dent &agrave; une zone de votre site web sans restriction, mais
-    que l'acc&egrave;s &agrave; cette zone n&eacute;cessite un mot de passe pour les autres
+    réseau accèdent à une zone de votre site web sans restriction, mais
+    que l'accès à cette zone nécessite un mot de passe pour les autres
     utilisateurs, vous pouvez utiliser une configuration du style :</p>
 
     <highlight language="config">
@@ -478,10 +488,10 @@ Satisfy Any
     </highlight>
 
     <p>
-    Une autre utilisation fr&eacute;quente de la directive
-    <directive>Satisfy</directive> est l'all&egrave;gement des restrictions
-    d'acc&egrave;s &agrave; un sous-r&eacute;pertoire par rapport aux restrictions d'acc&egrave;s au
-    r&eacute;pertoire parent :
+    Une autre utilisation fréquente de la directive
+    <directive>Satisfy</directive> est l'allègement des restrictions
+    d'accès à un sous-répertoire par rapport aux restrictions d'accès au
+    répertoire parent :
     </p>
 
     <highlight language="config">
@@ -495,22 +505,22 @@ Satisfy Any
 &lt;/Directory&gt;
     </highlight>
 
-    <p>Dans l'exemple ci-dessus, l'acc&egrave;s au r&eacute;pertoire
-    <code>/var/www/private</code> n&eacute;cessitera une authentification,
-    alors que l'acc&egrave;s au r&eacute;pertoire <code>/var/www/private/public</code>
-    sera accord&eacute; sans restriction.</p>
+    <p>Dans l'exemple ci-dessus, l'accès au répertoire
+    <code>/var/www/private</code> nécessitera une authentification,
+    alors que l'accès au répertoire <code>/var/www/private/public</code>
+    sera accordé sans restriction.</p>
 
 
     <p>Depuis la version 2.0.51, les directives
-    <directive>Satisfy</directive> peuvent &ecirc;tre restreintes &agrave; certaines
-    m&eacute;thodes particuli&egrave;res &agrave; l'aide des sections <directive
+    <directive>Satisfy</directive> peuvent être restreintes à certaines
+    méthodes particulières à l'aide des sections <directive
     module="core" type="section">Limit</directive> et <directive
     module="core" type="section">LimitExcept</directive>.</p>
 
     <note><title>Fusion des sections de configuration</title>
-      <p>Lorsqu'une directive fournie par ce module est utilis&eacute;e dans
-      une nouvelle section de configuration, cette derni&egrave;re n'h&eacute;rite
-      d'aucune directive d&eacute;finie dans une section pr&eacute;c&eacute;dente.</p>
+      <p>Lorsqu'une directive fournie par ce module est utilisée dans
+      une nouvelle section de configuration, cette dernière n'hérite
+      d'aucune directive définie dans une section précédente.</p>
     </note>
 </usage>
    <seealso><directive module="mod_access_compat">Allow</directive></seealso>
diff --git a/docs/manual/mod/mod_privileges.xml.fr b/docs/manual/mod/mod_privileges.xml.fr
index 267bcc5c63e..83bce4ddef1 100644
--- a/docs/manual/mod/mod_privileges.xml.fr
+++ b/docs/manual/mod/mod_privileges.xml.fr
@@ -1,7 +1,7 @@
-<?xml version="1.0"?>
+<?xml version="1.0" encoding="UTF-8" ?>
 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1375044:1739075 (outdated) -->
+<!-- English Revision: 1739075 -->
 <!-- French translation : Lucien GENTIS -->
 <!-- Reviewed by : Vincent Deffontaines -->
 
@@ -25,8 +25,8 @@
 <modulesynopsis metafile="mod_privileges.xml.meta">
 
 <name>mod_privileges</name>
-<description>Support des privil&egrave;ges de Solaris et de l'ex&eacute;cution des
-serveurs virtuels sous diff&eacute;rents identifiants
+<description>Support des privilèges de Solaris et de l'exécution des
+serveurs virtuels sous différents identifiants
 utilisateurs.</description>
 <status>Experimental</status>
 <sourcefile>mod_privileges.c</sourcefile>
@@ -35,113 +35,113 @@ utilisateurs.</description>
 plates-formes Solaris 10 et OpenSolaris</compatibility>
 
 <summary>
-<p>Ce module permet l'ex&eacute;cution de diff&eacute;rents serveurs virtuels sous
-diff&eacute;rents identifiants Unix <var>User</var> et <var>Group</var>,
-et avec diff&eacute;rents <a
-href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp">Privil&egrave;ges
-Solaris</a>. En particulier, il apporte au probl&egrave;me de
-s&eacute;paration des privil&egrave;ges entre les diff&eacute;rents serveurs virtuels la
-solution que devait apporter le module MPM abandonn&eacute; perchild. Il
-apporte aussi d'autres am&eacute;liorations en mati&egrave;re de s&eacute;curit&eacute;.</p>
-
-<p>&Agrave; la diff&eacute;rence de perchild, <module>mod_privileges</module> n'est
-pas un module MPM. Il travaille <em>au sein</em> d'un mod&egrave;le de
-traitement pour d&eacute;finir les privil&egrave;ges et les User/Group <em>pour chaque
-requ&ecirc;te</em> dans un m&ecirc;me processus. Il n'est donc pas compatible avec
-les MPM thread&eacute;s, et refusera de s'ex&eacute;cuter en cas d'utilisation d'un de
+<p>Ce module permet l'exécution de différents serveurs virtuels sous
+différents identifiants Unix <var>User</var> et <var>Group</var>,
+et avec différents <a
+href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp">Privilèges
+Solaris</a>. En particulier, il apporte au problème de
+séparation des privilèges entre les différents serveurs virtuels la
+solution que devait apporter le module MPM abandonné perchild. Il
+apporte aussi d'autres améliorations en matière de sécurité.</p>
+
+<p>À la différence de perchild, <module>mod_privileges</module> n'est
+pas un module MPM. Il travaille <em>au sein</em> d'un modèle de
+traitement pour définir les privilèges et les User/Group <em>pour chaque
+requête</em> dans un même processus. Il n'est donc pas compatible avec
+les MPM threadés, et refusera de s'exécuter en cas d'utilisation d'un de
 ces derniers.</p>
 
-<p><module>mod_privileges</module> traite des probl&egrave;mes de s&eacute;curit&eacute;
-similaires &agrave; ceux de <a href="../suexec.html">suexec</a> ; mais &agrave; la
-diff&eacute;rence de ce dernier, il ne s'applique pas seulement aux programmes
-CGI, mais &agrave; l'ensemble du cycle de traitement d'une requ&ecirc;te, y compris
+<p><module>mod_privileges</module> traite des problèmes de sécurité
+similaires à ceux de <a href="../suexec.html">suexec</a> ; mais à la
+différence de ce dernier, il ne s'applique pas seulement aux programmes
+CGI, mais à l'ensemble du cycle de traitement d'une requête, y compris
 les applications in-process et les sous-processus. Il convient
-particuli&egrave;rement &agrave; l'ex&eacute;cution des applications PHP sous
-<strong>mod_php</strong>, qui est lui-m&ecirc;me incompatible avec les modules
-MPM thread&eacute;s. Il est &eacute;galement bien adapt&eacute; aux autres applications de type
+particulièrement à l'exécution des applications PHP sous
+<strong>mod_php</strong>, qui est lui-même incompatible avec les modules
+MPM threadés. Il est également bien adapté aux autres applications de type
 script in-process comme <strong>mod_perl</strong>,
 <strong>mod_python</strong>, et <strong>mod_ruby</strong>, ainsi qu'aux
 applications en langage C telles que les modules Apache pour lesquels la
-s&eacute;paration des privil&egrave;ges constitue un probl&egrave;me.</p>
+séparation des privilèges constitue un problème.</p>
 
 </summary>
 
-<section id="security"><title>Consid&eacute;rations &agrave; propos de s&eacute;curit&eacute;</title>
+<section id="security"><title>Considérations à propos de sécurité</title>
 
-<p><module>mod_privileges</module> introduit de nouveaux probl&egrave;mes de
-s&eacute;curit&eacute; dans les situations o&ugrave; du <strong>code non s&ucirc;r</strong> peut
-s'ex&eacute;cuter <strong>&agrave; l'int&eacute;rieur du processus du serveur web</strong>.
-Ceci s'applique aux modules non s&ucirc;rs, et aux scripts s'ex&eacute;cutant sous
-des modules comme mod_php ou mod_perl. Les scripts s'ex&eacute;cutant en
-externe (comme par exemple les scripts CGI ou ceux s'ex&eacute;cutant sur un
-serveur d'applications derri&egrave;re mod_proxy ou mod_jk) ne sont pas
-concern&eacute;s.</p>
+<p><module>mod_privileges</module> introduit de nouveaux problèmes de
+sécurité dans les situations où du <strong>code non sûr</strong> peut
+s'exécuter <strong>à l'intérieur du processus du serveur web</strong>.
+Ceci s'applique aux modules non sûrs, et aux scripts s'exécutant sous
+des modules comme mod_php ou mod_perl. Les scripts s'exécutant en
+externe (comme par exemple les scripts CGI ou ceux s'exécutant sur un
+serveur d'applications derrière mod_proxy ou mod_jk) ne sont pas
+concernés.</p>
 
-<p>Les principaux probl&egrave;mes de s&eacute;curit&eacute; que l'on rencontre avec
+<p>Les principaux problèmes de sécurité que l'on rencontre avec
 mod_privileges sont :</p>
 
 
-<ul><li>L'ex&eacute;cution sous un utilisateur syst&egrave;me pose les m&ecirc;mes probl&egrave;mes
-de s&eacute;curit&eacute; que mod_suexec, et pratiquement les m&ecirc;mes que cgiwrap et
+<ul><li>L'exécution sous un utilisateur système pose les mêmes problèmes
+de sécurité que mod_suexec, et pratiquement les mêmes que cgiwrap et
 suphp.</li>
-<li>Une extension utilisateur (module ou script) malveillante, &eacute;crite en connaissant les m&eacute;canismes
-utilis&eacute;s par <strong>mod_privileges</strong>,
-pourrait &eacute;lever ses privil&egrave;ges &agrave; tout niveau
+<li>Une extension utilisateur (module ou script) malveillante, écrite en connaissant les mécanismes
+utilisés par <strong>mod_privileges</strong>,
+pourrait élever ses privilèges à tout niveau
 accessible au processus httpd dans tout serveur virtuel. Ceci introduit
-de nouveaux risques si (et seulement si) mod_privileges est compil&eacute; avec
+de nouveaux risques si (et seulement si) mod_privileges est compilé avec
 l'option <var>BIG_SECURITY_HOLE</var>.</li>
-<li>Une extension utilisateur (module ou script) malveillante, &eacute;crite en connaissant les m&eacute;canismes
-utilis&eacute;s par <strong>mod_privileges</strong>,
-pourrait &eacute;lever ses privil&egrave;ges pour s'attribuer
+<li>Une extension utilisateur (module ou script) malveillante, écrite en connaissant les mécanismes
+utilisés par <strong>mod_privileges</strong>,
+pourrait élever ses privilèges pour s'attribuer
 l'identifiant utilisateur d'un autre utilisateur (et/ou groupe)
-syst&egrave;me.</li>
+système.</li>
 </ul>
 
 <p>La directive <directive>PrivilegesMode</directive> vous permet de
-s&eacute;lectionner soit le mode <var>FAST</var>, soit le mode
+sélectionner soit le mode <var>FAST</var>, soit le mode
 <var>SECURE</var>. Vous pouvez panacher les modes en utilisant par
 exemple le mode <var>FAST</var> pour les utilisateurs de confiance et
-les chemins contenant du code enti&egrave;rement audit&eacute;, tout en imposant le
-mode <var>SECURE</var> o&ugrave; un utilisateur non s&ucirc;r a la possibilit&eacute;
+les chemins contenant du code entièrement audité, tout en imposant le
+mode <var>SECURE</var> où un utilisateur non sûr a la possibilité
 d'introduire du code.</p>
-<p>Avant de d&eacute;crire les modes, il nous faut pr&eacute;senter les cas
+<p>Avant de décrire les modes, il nous faut présenter les cas
 d'utilisation de la cible : "Benign" ou "Hostile". Dans une situation
-"Benign", vous voulez s&eacute;parer les utilisateurs pour leur confort, et les
-prot&eacute;ger, ainsi que le serveur, contre les risques induits par les
+"Benign", vous voulez séparer les utilisateurs pour leur confort, et les
+protéger, ainsi que le serveur, contre les risques induits par les
 erreurs involontaires. Dans une situation "Hostile" - par exemple
-l'h&eacute;bergement d'un site commercial - il se peut que des utilisateurs
-attaquent d&eacute;lib&eacute;r&eacute;ment le serveur ou s'attaquent entre eux.</p>
+l'hébergement d'un site commercial - il se peut que des utilisateurs
+attaquent délibérément le serveur ou s'attaquent entre eux.</p>
 <dl>
 <dt>Mode FAST</dt>
-<dd>En mode <var>FAST</var>, les requ&ecirc;tes sont trait&eacute;es "in-process"
-avec les uid/gid et privil&egrave;ges s&eacute;lectionn&eacute;s, si bien que la
-surcharge est n&eacute;gligeable. Ceci convient aux situations "Benign", mais
-n'est pas s&eacute;curis&eacute; contre un attaquant augmentant ses privil&egrave;ges avec un
+<dd>En mode <var>FAST</var>, les requêtes sont traitées "in-process"
+avec les uid/gid et privilèges sélectionnés, si bien que la
+surcharge est négligeable. Ceci convient aux situations "Benign", mais
+n'est pas sécurisé contre un attaquant augmentant ses privilèges avec un
 module ou script "in-process".</dd>
 <dt>Mode SECURE</dt>
-<dd>Une requ&ecirc;te en mode <var>SECURE</var> g&eacute;n&egrave;re un sous-processus qui
-supprime les privil&egrave;ges. Ce comportement est tr&egrave;s similaire &agrave;
-l'ex&eacute;cution d'un programme CGI avec suexec, mais il reste valable tout
-au long du cycle de traitement de la requ&ecirc;te, avec en plus l'avantage
-d'un contr&ocirc;le pr&eacute;cis des privil&egrave;ges.</dd>
+<dd>Une requête en mode <var>SECURE</var> génère un sous-processus qui
+supprime les privilèges. Ce comportement est très similaire à
+l'exécution d'un programme CGI avec suexec, mais il reste valable tout
+au long du cycle de traitement de la requête, avec en plus l'avantage
+d'un contrôle précis des privilèges.</dd>
 </dl>
-<p>Vous pouvez s&eacute;lectionner diff&eacute;rents
+<p>Vous pouvez sélectionner différents
 <directive>PrivilegesMode</directive>s pour chaque serveur virtuel, et
-m&ecirc;me dans un contexte de r&eacute;pertoire &agrave; l'int&eacute;rieur d'un serveur virtuel.
-Le mode <var>FAST</var> convient lorsque les utilisateurs sont s&ucirc;rs
-et/ou n'ont pas le privil&egrave;ge de charger du code "in-process". Le mode
-<var>SECURE</var> convient dans les cas o&ugrave; du code non s&ucirc;r peut
-s'ex&eacute;cuter "in-process".  Cependant, m&ecirc;me en mode <var>SECURE</var>, il
+même dans un contexte de répertoire à l'intérieur d'un serveur virtuel.
+Le mode <var>FAST</var> convient lorsque les utilisateurs sont sûrs
+et/ou n'ont pas le privilège de charger du code "in-process". Le mode
+<var>SECURE</var> convient dans les cas où du code non sûr peut
+s'exécuter "in-process".  Cependant, même en mode <var>SECURE</var>, il
 n'y a pas de protection contre un utilisateur malveillant qui a la
-possibilit&eacute; d'introduire du code supportant les privil&egrave;ges <em>avant le
-d&eacute;but du cycle de traitement de la requ&ecirc;te.</em></p>
+possibilité d'introduire du code supportant les privilèges <em>avant le
+début du cycle de traitement de la requête.</em></p>
 
 </section>
 <directivesynopsis>
 <name>PrivilegesMode</name>
-<description>Fait un compromis entre d'une part l'efficacit&eacute; et la
-vitesse de traitement et d'autre part la s&eacute;curit&eacute; &agrave; l'encontre des codes
-malicieux supportant les privil&egrave;ges.</description>
+<description>Fait un compromis entre d'une part l'efficacité et la
+vitesse de traitement et d'autre part la sécurité à l'encontre des codes
+malicieux supportant les privilèges.</description>
 <syntax>PrivilegesMode FAST|SECURE|SELECTIVE</syntax>
 <default>PrivilegesMode FAST</default>
 <contextlist>
@@ -150,77 +150,77 @@ malicieux supportant les privil&egrave;ges.</description>
 	<context>directory</context>
 </contextlist>
 <compatibility>Disponible sous Solaris 10 et OpenSolaris avec des
-modules MPMs non thread&eacute;s (comme <module>prefork</module> ou un module
-personnalis&eacute;).</compatibility>
+modules MPMs non threadés (comme <module>prefork</module> ou un module
+personnalisé).</compatibility>
 <usage><p>Cette directive permet de faire un compromis entre les
-performances et la s&eacute;curit&eacute; &agrave; l'encontre des codes malicieux supportant
-les privil&egrave;ges. En mode <var>SECURE</var>, chaque requ&ecirc;te est trait&eacute;e
-dans un sous-processus s&eacute;curis&eacute;, ce qui induit une d&eacute;gradation sensible
-des performances. En mode <var>FAST</var>, le serveur n'est pas prot&eacute;g&eacute;
-contre l'augmentation de privil&egrave;ge comme d&eacute;crit plus haut.</p>
-<p>Cette directive est sensiblement diff&eacute;rente selon qu'elle se trouve
+performances et la sécurité à l'encontre des codes malicieux supportant
+les privilèges. En mode <var>SECURE</var>, chaque requête est traitée
+dans un sous-processus sécurisé, ce qui induit une dégradation sensible
+des performances. En mode <var>FAST</var>, le serveur n'est pas protégé
+contre l'augmentation de privilège comme décrit plus haut.</p>
+<p>Cette directive est sensiblement différente selon qu'elle se trouve
 dans une section <code>&lt;Directory&gt;</code> (ou Location/Files/If)
 ou au niveau global ou dans un <code>&lt;VirtualHost&gt;</code>.</p>
-<p>Au niveau global, elle d&eacute;finit un comportement par d&eacute;faut dont
-h&eacute;riteront les serveurs virtuels. Dans un serveur virtuel, les modes
-FAST ou SECURE agissent sur l'ensemble de la requ&ecirc;te HTTP, et toute
-d&eacute;finition de ces modes dans une section <code>&lt;Directory&gt;</code>
-sera <strong>ignor&eacute;e</strong>. Le pseudo-mode SELECTIVE confie le choix
+<p>Au niveau global, elle définit un comportement par défaut dont
+hériteront les serveurs virtuels. Dans un serveur virtuel, les modes
+FAST ou SECURE agissent sur l'ensemble de la requête HTTP, et toute
+définition de ces modes dans une section <code>&lt;Directory&gt;</code>
+sera <strong>ignorée</strong>. Le pseudo-mode SELECTIVE confie le choix
 du mode FAST ou SECURE aux directives contenues dans une
 section<code>&lt;Directory&gt;</code>.</p>
 <p>Dans une section <code>&lt;Directory&gt;</code>, elle ne s'applique
-que lorsque le mode SELECTIVE a &eacute;t&eacute; d&eacute;fini pour le serveur virtuel.
-Seuls FAST ou SECURE peuvent &ecirc;tre d&eacute;finis dans ce contexte (SELECTIVE
+que lorsque le mode SELECTIVE a été défini pour le serveur virtuel.
+Seuls FAST ou SECURE peuvent être définis dans ce contexte (SELECTIVE
 n'aurait pas de sens).</p>
 <note type="warning"><title>Avertissement</title>
-	Lorsque le mode SELECTIVE a &eacute;t&eacute; d&eacute;fini pour un serveur virtuel,
-	l'activation des privil&egrave;ges doit &ecirc;tre report&eacute;e <em>apr&egrave;s</em>
-	la d&eacute;termination, par la phase de comparaison du traitement de
-	la requ&ecirc;te, du contexte <code>&lt;Directory&gt;</code> qui
-	s'applique &agrave; la requ&ecirc;te. Ceci peut donner &agrave; un attaquant
-	l'opportunit&eacute; d'introduire du code via une directive <directive
-	module="mod_rewrite">RewriteMap</directive> s'ex&eacute;cutant au
+	Lorsque le mode SELECTIVE a été défini pour un serveur virtuel,
+	l'activation des privilèges doit être reportée <em>après</em>
+	la détermination, par la phase de comparaison du traitement de
+	la requête, du contexte <code>&lt;Directory&gt;</code> qui
+	s'applique à la requête. Ceci peut donner à un attaquant
+	l'opportunité d'introduire du code via une directive <directive
+	module="mod_rewrite">RewriteMap</directive> s'exécutant au
 	niveau global ou d'un serveur virtuel <em>avant</em> que les
-	privil&egrave;ges n'aient &eacute;t&eacute; supprim&eacute;s et l'uid/gid d&eacute;fini.
+	privilèges n'aient été supprimés et l'uid/gid défini.
 </note>
 </usage>
 </directivesynopsis>
 
 <directivesynopsis>
 <name>VHostUser</name>
-<description>D&eacute;finit l'identifiant utilisateur sous lequel s'ex&eacute;cute un
+<description>Définit l'identifiant utilisateur sous lequel s'exécute un
 serveur virtuel.</description>
 <syntax>VHostUser <var>identifiant-utilisateur-unix</var></syntax>
-<default>H&eacute;rite de l'identifiant utilisateur sp&eacute;cifi&eacute; par la directive
+<default>Hérite de l'identifiant utilisateur spécifié par la directive
 <directive module="mod_unixd">User</directive></default>
 <contextlist><context>virtual host</context></contextlist>
 <compatibility>Disponible sous Solaris 10 et OpenSolaris avec les
-modules MPM non-thread&eacute;s (<module>prefork</module> ou MPM
-personnalis&eacute;).</compatibility>
+modules MPM non-threadés (<module>prefork</module> ou MPM
+personnalisé).</compatibility>
 
 <usage>
-    <p>La directive <directive>VHostUser</directive> permet de d&eacute;finir
+    <p>La directive <directive>VHostUser</directive> permet de définir
     l'identifiant utilisateur unix sous lequel le serveur va traiter les
-    requ&ecirc;tes par l'interm&eacute;diaire d'un serveur virtuel. L'identifiant
-    utilisateur est d&eacute;fini avant le traitement de la requ&ecirc;te, puis
-    restaur&eacute; &agrave; sa valeur de d&eacute;part via les <a
-    href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp">Privil&egrave;ges
-    Solaris</a>. Comme la d&eacute;finition
+    requêtes par l'intermédiaire d'un serveur virtuel. L'identifiant
+    utilisateur est défini avant le traitement de la requête, puis
+    restauré à sa valeur de départ via les <a
+    href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp">Privilèges
+    Solaris</a>. Comme la définition
     s'applique au <em>processus</em>, cette directive est incompatible
-    avec les modules MPM thread&eacute;s.</p>
-    <p><var>identifiant-utilisateur-unix</var> peut &ecirc;tre :</p>
+    avec les modules MPM threadés.</p>
+    <p><var>identifiant-utilisateur-unix</var> peut être :</p>
     <dl>
       <dt>Un nom d'utilisateur</dt>
-      <dd>Fait r&eacute;f&eacute;rence &agrave; l'utilisateur donn&eacute; par son nom.</dd>
+      <dd>Fait référence à l'utilisateur donné par son nom.</dd>
 
-      <dt><code>#</code> suivi d'un num&eacute;ro d'utilisateur.</dt>
-      <dd>Fait r&eacute;f&eacute;rence &agrave; l'utilisateur donn&eacute; par son num&eacute;ro.</dd>
+      <dt><code>#</code> suivi d'un numéro d'utilisateur.</dt>
+      <dd>Fait référence à l'utilisateur donné par son numéro.</dd>
     </dl>
 
-    <note type="warning"><title>S&eacute;curit&eacute;</title>
-    <p>Cette directive ne peut pas &ecirc;tre utilis&eacute;e pour ex&eacute;cuter Apache en
-    tant que root ! Elle est tout de m&ecirc;me susceptible de poser des
-    probl&egrave;mes de s&eacute;curit&eacute; similaires &agrave; ceux d&eacute;crits dans la
+    <note type="warning"><title>Sécurité</title>
+    <p>Cette directive ne peut pas être utilisée pour exécuter Apache en
+    tant que root ! Elle est tout de même susceptible de poser des
+    problèmes de sécurité similaires à ceux décrits dans la
     documentation de <a href="../suexec.html">suexec</a>.</p></note>
 </usage>
 <seealso><directive module="mod_unixd">User</directive></seealso>
@@ -229,39 +229,39 @@ personnalis&eacute;).</compatibility>
 
 <directivesynopsis>
 <name>VHostGroup</name>
-<description>D&eacute;finit l'identifiant du groupe sous lequel s'ex&eacute;cute un
+<description>Définit l'identifiant du groupe sous lequel s'exécute un
 serveur virtuel.</description>
 <syntax>VHostGroup <var>identifiant-groupe-unix</var></syntax>
-<default>H&eacute;rite de l'identifiant du groupe sp&eacute;cifi&eacute; par la directive
+<default>Hérite de l'identifiant du groupe spécifié par la directive
 <directive module="mod_unixd">Group</directive></default>
 <contextlist><context>virtual host</context></contextlist>
 <compatibility>Disponible sous Solaris 10 et OpenSolaris avec les
-modules MPM non-thread&eacute;s (<module>prefork</module> ou MPM
-personnalis&eacute;).</compatibility>
+modules MPM non-threadés (<module>prefork</module> ou MPM
+personnalisé).</compatibility>
 
 <usage>
-    <p>La directive <directive>VHostGroup</directive> permet de d&eacute;finir
+    <p>La directive <directive>VHostGroup</directive> permet de définir
     l'identifiant du groupe unix sous lequel le serveur va traiter les
-    requ&ecirc;tes par l'interm&eacute;diaire d'un serveur virtuel. L'identifiant
-    du groupe est d&eacute;fini avant le traitement de la requ&ecirc;te, puis
-    restaur&eacute; &agrave; sa valeur de d&eacute;part via les <a
-    href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp">Privil&egrave;ges
-    Solaris</a>. Comme la d&eacute;finition
+    requêtes par l'intermédiaire d'un serveur virtuel. L'identifiant
+    du groupe est défini avant le traitement de la requête, puis
+    restauré à sa valeur de départ via les <a
+    href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp">Privilèges
+    Solaris</a>. Comme la définition
     s'applique au <em>processus</em>, cette directive est incompatible
-    avec les modules MPM thread&eacute;s.</p>
-    <p><var>Unix-group</var> peut &ecirc;tre :</p>
+    avec les modules MPM threadés.</p>
+    <p><var>Unix-group</var> peut être :</p>
     <dl>
       <dt>Un nom de groupe</dt>
-      <dd>Fait r&eacute;f&eacute;rence au groupe donn&eacute; par son nom.</dd>
+      <dd>Fait référence au groupe donné par son nom.</dd>
 
-      <dt><code>#</code> suivi d'un num&eacute;ro de groupe.</dt>
-      <dd>Fait r&eacute;f&eacute;rence au groupe donn&eacute; par son num&eacute;ro.</dd>
+      <dt><code>#</code> suivi d'un numéro de groupe.</dt>
+      <dd>Fait référence au groupe donné par son numéro.</dd>
     </dl>
 
-    <note type="warning"><title>S&eacute;curit&eacute;</title>
-    <p>Cette directive ne peut pas &ecirc;tre utilis&eacute;e pour ex&eacute;cuter Apache en
-    tant que root ! Elle est tout de m&ecirc;me susceptible de poser des
-    probl&egrave;mes de s&eacute;curit&eacute; similaires &agrave; ceux d&eacute;crits dans la
+    <note type="warning"><title>Sécurité</title>
+    <p>Cette directive ne peut pas être utilisée pour exécuter Apache en
+    tant que root ! Elle est tout de même susceptible de poser des
+    problèmes de sécurité similaires à ceux décrits dans la
     documentation de <a href="../suexec.html">suexec</a>.</p></note>
 </usage>
 <seealso><directive module="mod_unixd">Group</directive></seealso>
@@ -270,104 +270,104 @@ personnalis&eacute;).</compatibility>
 
 <directivesynopsis>
 <name>VHostSecure</name>
-<description>D&eacute;termine si le serveur s'ex&eacute;cute avec une s&eacute;curit&eacute; avanc&eacute;e
+<description>Détermine si le serveur s'exécute avec une sécurité avancée
 pour les serveurs virtuels.</description>
 <syntax>VHostSecure On|Off</syntax>
 <default>VHostSecure On</default>
 <contextlist><context>virtual host</context></contextlist>
 <compatibility>Disponible sous Solaris 10 et OpenSolaris avec les
-modules MPM non-thread&eacute;s (<module>prefork</module> ou MPM
-personnalis&eacute;).</compatibility>
+modules MPM non-threadés (<module>prefork</module> ou MPM
+personnalisé).</compatibility>
 
 <usage>
-    <p>D&eacute;termine si les serveurs virtuels traitent les requ&ecirc;tes avec une
-    s&eacute;curit&eacute; avanc&eacute;e en supprimant les <a
+    <p>Détermine si les serveurs virtuels traitent les requêtes avec une
+    sécurité avancée en supprimant les <a
     href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp"
-    >Privil&egrave;ges</a> rarement requis par un serveur web, mais disponibles
-    par d&eacute;faut pour un utilisateur Unix standard, et donc susceptibles
-    d'&ecirc;tre demand&eacute;s par des modules et des applications. Il est
-    recommand&eacute; de conserver la d&eacute;finition par d&eacute;faut (On), sauf si elle
-    emp&ecirc;che une application de fonctionner. Comme la d&eacute;finition
+    >Privilèges</a> rarement requis par un serveur web, mais disponibles
+    par défaut pour un utilisateur Unix standard, et donc susceptibles
+    d'être demandés par des modules et des applications. Il est
+    recommandé de conserver la définition par défaut (On), sauf si elle
+    empêche une application de fonctionner. Comme la définition
     s'applique au <em>processus</em>, cette directive est incompatible
-    avec les modules MPM thread&eacute;s.</p>
+    avec les modules MPM threadés.</p>
     <note><title>Note</title>
     <p>Le fait que la directive <directive>VHostSecure</directive>
-    emp&ecirc;che une application de fonctionner peut constituer un signal
-    d'avertissement indiquant que la s&eacute;curit&eacute; de l'application doit &ecirc;tre
+    empêche une application de fonctionner peut constituer un signal
+    d'avertissement indiquant que la sécurité de l'application doit être
     revue.</p></note>
 </usage>
 </directivesynopsis>
 
 <directivesynopsis>
 <name>VHostCGIMode</name>
-<description>D&eacute;termine si le serveur virtuel peut ex&eacute;cuter des
-sous-processus, et d&eacute;finit les privil&egrave;ges disponibles pour ces
+<description>Détermine si le serveur virtuel peut exécuter des
+sous-processus, et définit les privilèges disponibles pour ces
 dernier.</description>
 <syntax>VHostCGIMode On|Off|Secure</syntax>
 <default>VHostCGIMode On</default>
 <contextlist><context>virtual host</context></contextlist>
 <compatibility>Disponible sous Solaris 10 et OpenSolaris avec les
-modules MPM non-thread&eacute;s (<module>prefork</module> ou MPM
-personnalis&eacute;).</compatibility>
+modules MPM non-threadés (<module>prefork</module> ou MPM
+personnalisé).</compatibility>
 
 <usage>
-    <p>D&eacute;termine si le serveur virtuel est autoris&eacute; &agrave; ex&eacute;cuter fork et
-    exec, et d&eacute;finit les <a
+    <p>Détermine si le serveur virtuel est autorisé à exécuter fork et
+    exec, et définit les <a
     href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp"
-    >privil&egrave;ges</a> requis pour ex&eacute;cuter des sous-processus. Si cette
-    directive est d&eacute;finie &agrave; <var>Off</var> le serveur virtuel ne
-    disposera d'aucun privil&egrave;ge et ne pourra ex&eacute;cuter ni des programmes
+    >privilèges</a> requis pour exécuter des sous-processus. Si cette
+    directive est définie à <var>Off</var> le serveur virtuel ne
+    disposera d'aucun privilège et ne pourra exécuter ni des programmes
     ou scripts CGI classiques via le module traditionnel
     <module>mod_cgi</module>, ni des programmes externes similaires tels
-    que ceux cr&eacute;&eacute;s via le module <module>mod_ext_filter</module> ou les
-    programmes de r&eacute;&eacute;criture externes utilis&eacute;s par la directive
+    que ceux créés via le module <module>mod_ext_filter</module> ou les
+    programmes de réécriture externes utilisés par la directive
     <directive module="mod_rewrite">RewriteMap</directive>. Notez que
-    ceci n'emp&ecirc;che pas l'ex&eacute;cution de programmes CGI via d'autres
-    processus et sous d'autres mod&egrave;les de s&eacute;curit&eacute; comme <a
+    ceci n'empêche pas l'exécution de programmes CGI via d'autres
+    processus et sous d'autres modèles de sécurité comme <a
     href="https://httpd.apache.org/mod_fcgid/">mod_fcgid</a>, ce qui est la
-    solution recommand&eacute;e sous Solaris.</p>
-    <p>Si cette directive est d&eacute;finie &agrave; <var>On</var> ou
-    <var>Secure</var>, le serveur virtuel pourra ex&eacute;cuter les scripts et
-    programmes externes cit&eacute;s ci-dessus. D&eacute;finir la directive
-    <directive>VHostCGIMode</directive> &agrave; <var>Secure</var> a pour effet
-    suppl&eacute;mentaire de n'accorder aucun privil&egrave;ge aux sous-processus,
-    comme d&eacute;crit dans la directive
+    solution recommandée sous Solaris.</p>
+    <p>Si cette directive est définie à <var>On</var> ou
+    <var>Secure</var>, le serveur virtuel pourra exécuter les scripts et
+    programmes externes cités ci-dessus. Définir la directive
+    <directive>VHostCGIMode</directive> à <var>Secure</var> a pour effet
+    supplémentaire de n'accorder aucun privilège aux sous-processus,
+    comme décrit dans la directive
     <directive>VHostSecure</directive>.</p>
 </usage>
 </directivesynopsis>
 
 <directivesynopsis>
 <name>DTracePrivileges</name>
-<description>D&eacute;termine si les privil&egrave;ges requis par dtrace sont
-activ&eacute;s.</description>
+<description>Détermine si les privilèges requis par dtrace sont
+activés.</description>
 <syntax>DTracePrivileges On|Off</syntax>
 <default>DTracePrivileges Off</default>
 <contextlist><context>server config</context></contextlist>
 <compatibility>>Disponible sous Solaris 10 et OpenSolaris avec les
-modules MPM non-thread&eacute;s (<module>prefork</module> ou MPM
-personnalis&eacute;).</compatibility>
+modules MPM non-threadés (<module>prefork</module> ou MPM
+personnalisé).</compatibility>
 
 <usage>
-    <p>Cette directive qui s'applique &agrave; l'ensemble du serveur permet de
-    d&eacute;terminer si Apache s'ex&eacute;cutera avec les <a
+    <p>Cette directive qui s'applique à l'ensemble du serveur permet de
+    déterminer si Apache s'exécutera avec les <a
     href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp"
-    >privil&egrave;ges</a> requis pour ex&eacute;cuter <a
+    >privilèges</a> requis pour exécuter <a
     href="http://sosc-dr.sun.com/bigadmin/content/dtrace/">dtrace</a>.
-    Notez que la d&eacute;finition <var>DTracePrivileges On</var> n'activera
-    pas &agrave; elle-seule DTrace, mais que <var>DTracePrivileges Off</var>
-    l'emp&ecirc;chera de fonctionner.</p>
+    Notez que la définition <var>DTracePrivileges On</var> n'activera
+    pas à elle-seule DTrace, mais que <var>DTracePrivileges Off</var>
+    l'empêchera de fonctionner.</p>
 </usage>
 </directivesynopsis>
 
 <directivesynopsis>
 <name>VHostPrivs</name>
-<description>Assigne des privil&egrave;ges &agrave; un serveur virtuel.</description>
-<syntax>VHostPrivs [+-]?<var>nom-privil&egrave;ge</var> [[+-]?nom-privil&egrave;ge] ...</syntax>
+<description>Assigne des privilèges à un serveur virtuel.</description>
+<syntax>VHostPrivs [+-]?<var>nom-privilège</var> [[+-]?nom-privilège] ...</syntax>
 <default>Aucun</default>
 <contextlist><context>virtual host</context></contextlist>
 <compatibility>Disponible sous Solaris 10 et OpenSolaris avec les
-modules MPM non-thread&eacute;s (<module>prefork</module> ou MPM
-personnalis&eacute;) et lorsque <module>mod_privileges</module> est construit
+modules MPM non-threadés (<module>prefork</module> ou MPM
+personnalisé) et lorsque <module>mod_privileges</module> est construit
 avec l'option de compilation
 <var>BIG_SECURITY_HOLE</var>.</compatibility>
 
@@ -375,35 +375,35 @@ avec l'option de compilation
     <p>La directive <directive>VHostPrivs</directive> permet d'assigner
     des <a
     href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp"
-    >privil&egrave;ges</a> au choix &agrave; un serveur virtuel. Chaque
-    <var>nom-privil&egrave;ge</var> correspond &agrave; un privil&egrave;ge Solaris tel que
+    >privilèges</a> au choix à un serveur virtuel. Chaque
+    <var>nom-privilège</var> correspond à un privilège Solaris tel que
     <var>file_setid</var> ou <var>sys_nfs</var>.</p>
 
-    <p><var>nom-privil&egrave;ge</var> peut &ecirc;tre &eacute;ventuellement pr&eacute;fix&eacute; par +
-    ou -, ce qui va respectivement accorder ou refuser le privil&egrave;ge. Si
-    <var>nom-privil&egrave;ge</var> est sp&eacute;cifi&eacute; sans + ni -, tous les autres
-    privil&egrave;ges pr&eacute;alablement assign&eacute;s au serveur virtuel seront refus&eacute;s.
-    Cette directive permet de construire ais&eacute;ment votre propre jeu de
-    privil&egrave;ges en annulant tout r&eacute;glage par d&eacute;faut.</p>
+    <p><var>nom-privilège</var> peut être éventuellement préfixé par +
+    ou -, ce qui va respectivement accorder ou refuser le privilège. Si
+    <var>nom-privilège</var> est spécifié sans + ni -, tous les autres
+    privilèges préalablement assignés au serveur virtuel seront refusés.
+    Cette directive permet de construire aisément votre propre jeu de
+    privilèges en annulant tout réglage par défaut.</p>
 
-    <note type="warning"><title>S&eacute;curit&eacute;</title>
+    <note type="warning"><title>Sécurité</title>
     <p>L'utilisation de cette directive peut ouvrir d'immenses trous de
-    s&eacute;curit&eacute; dans Apache, jusqu'au traitement de requ&ecirc;tes avec les
-    droits de root. Ne l'utilisez que si vous &ecirc;tes absolument s&ucirc;r de
+    sécurité dans Apache, jusqu'au traitement de requêtes avec les
+    droits de root. Ne l'utilisez que si vous êtes absolument sûr de
     comprendre ce que vous faites !</p></note>
 </usage>
 </directivesynopsis>
 
 <directivesynopsis>
 <name>VHostCGIPrivs</name>
-<description>Assigne des privil&egrave;ges au choix aux sous-processus cr&eacute;&eacute;s
+<description>Assigne des privilèges au choix aux sous-processus créés
 par un serveur virtuel.</description>
-<syntax>VHostPrivs [+-]?<var>nom-privil&egrave;ge</var> [[+-]?nom-privil&egrave;ge] ...</syntax>
+<syntax>VHostPrivs [+-]?<var>nom-privilège</var> [[+-]?nom-privilège] ...</syntax>
 <default>Aucun</default>
 <contextlist><context>virtual host</context></contextlist>
 <compatibility>Disponible sous Solaris 10 et OpenSolaris avec les
-modules MPM non-thread&eacute;s (<module>prefork</module> ou MPM
-personnalis&eacute;) et lorsque <module>mod_privileges</module> est construit
+modules MPM non-threadés (<module>prefork</module> ou MPM
+personnalisé) et lorsque <module>mod_privileges</module> est construit
 avec l'option de compilation
 <var>BIG_SECURITY_HOLE</var>.</compatibility>
 
@@ -411,23 +411,23 @@ avec l'option de compilation
     <p>La directive <directive>VHostCGIPrivs</directive> permet
     d'assigner des <a
     href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp"
-    >privil&egrave;ges</a> au choix aux sous-processus cr&eacute;&eacute;s par un serveur
-    virtuel, comme d&eacute;crit dans la directive
+    >privilèges</a> au choix aux sous-processus créés par un serveur
+    virtuel, comme décrit dans la directive
     <directive>VHostCGIMode</directive>. Chaque
-    <var>nom-privil&egrave;ge</var> correspond &agrave; un privil&egrave;ge Solaris tel que
+    <var>nom-privilège</var> correspond à un privilège Solaris tel que
     <var>file_setid</var> ou <var>sys_nfs</var>.</p>
 
-    <p><var>nom-privil&egrave;ge</var> peut &ecirc;tre &eacute;ventuellement pr&eacute;fix&eacute; par +
-    ou -, ce qui va respectivement accorder ou refuser le privil&egrave;ge. Si
-    <var>nom-privil&egrave;ge</var> est sp&eacute;cifi&eacute; sans + ni -, tous les autres
-    privil&egrave;ges pr&eacute;alablement assign&eacute;s au serveur virtuel seront refus&eacute;s.
-    Cette directive permet de construire ais&eacute;ment votre propre jeu de
-    privil&egrave;ges en annulant tout r&eacute;glage par d&eacute;faut.</p>
+    <p><var>nom-privilège</var> peut être éventuellement préfixé par +
+    ou -, ce qui va respectivement accorder ou refuser le privilège. Si
+    <var>nom-privilège</var> est spécifié sans + ni -, tous les autres
+    privilèges préalablement assignés au serveur virtuel seront refusés.
+    Cette directive permet de construire aisément votre propre jeu de
+    privilèges en annulant tout réglage par défaut.</p>
 
-    <note type="warning"><title>S&eacute;curit&eacute;</title>
+    <note type="warning"><title>Sécurité</title>
     <p>L'utilisation de cette directive peut ouvrir d'immenses trous de
-    s&eacute;curit&eacute; dans les sous-processus Apache, jusqu'&agrave; leur ex&eacute;cution avec les
-    droits de root. Ne l'utilisez que si vous &ecirc;tes absolument s&ucirc;r de
+    sécurité dans les sous-processus Apache, jusqu'à leur exécution avec les
+    droits de root. Ne l'utilisez que si vous êtes absolument sûr de
     comprendre ce que vous faites !</p></note>
 </usage>
 </directivesynopsis>
diff --git a/docs/manual/rewrite/rewritemap.xml.fr b/docs/manual/rewrite/rewritemap.xml.fr
index 360168cad15..d1e08b169b1 100644
--- a/docs/manual/rewrite/rewritemap.xml.fr
+++ b/docs/manual/rewrite/rewritemap.xml.fr
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1733403:1739051 (outdated) -->
+<!-- English Revision: 1739051 -->
 <!-- French translation : Lucien GENTIS -->
 <!-- Reviewed by : VIncent Deffontaines -->
 <!--
@@ -30,7 +30,7 @@
     module <module>mod_rewrite</module>. Il décrit l'utilisation de la
     directive <directive module="mod_rewrite">RewriteMap</directive>, et
     fournit des exemples pour chacun des différents types de
-    <code>RewriteMap</code>.</p>
+    <directive module="mod_rewrite">RewriteMap</directive>.</p>
 
     <note type="warning">Notez que la plupart de ces exemples ne
     fonctionneront pas en l'état dans le contexte de votre configuration
@@ -64,7 +64,7 @@
    données, ceux-ci étant par ailleurs énumérés dans la documentation de
    référence de <directive module="mod_rewrite">RewriteMap</directive>.</p>
 
-   <p>La syntaxe de la directive <code>RewriteMap</code> est la suivante
+   <p>La syntaxe de la directive <directive module="mod_rewrite">RewriteMap</directive> est la suivante
    :</p>
 
 <highlight language="config">RewriteMap <em>MapName</em> <em>MapType</em>:<em>MapSource</em></highlight>
@@ -93,10 +93,10 @@
     vide si aucune <em>DefaultValue</em> n'a été spécifiée.</p>
 
     <p>Par exemple, vous pouvez définir une directive
-    <directive>RewriteMap</directive> comme suit :</p>
+    <directive module="mod_rewrite">RewriteMap</directive> comme suit :</p>
     <highlight language="config">RewriteMap examplemap "txt:/path/to/file/map.txt"</highlight>
     <p>Vous pourrez par la suite utiliser cette table de correspondances
-    dans une directive <directive>RewriteRule</directive> comme suit :</p>
+    dans une directive <directive module="mod_rewrite">RewriteRule</directive> comme suit :</p>
 <highlight language="config">RewriteRule "^/ex/(.*)" "${examplemap:$1}"</highlight>
 
 <p>Il est possible de spécifier une valeur par défaut qui sera utilisée
@@ -106,8 +106,8 @@ si la recherche dans la table de correspondances est infructueuse :</p>
 
 <note><title>Contexte de répertoire et fichiers.htaccess</title>
 <p>
-Vous ne pouvez utiliser la directive <code>RewriteMap</code> ni dans
-les sections &lt;Directory&gt;, ni dans les fichiers
+Vous ne pouvez utiliser la directive <directive module="mod_rewrite">RewriteMap</directive> ni dans
+les sections <directive module="core" type="section">Directory</directive>, ni dans les fichiers
 <code>.htaccess</code>. Vous devez déclarer la table de correspondances
 au niveau du serveur principal ou dans un contexte de serveur virtuel.
 En revanche, si vous ne pouvez pas déclarer la table dans une section
@@ -122,6 +122,52 @@ correspondances <em>type-map</em> disponibles, et fournissent des
 exemples pour chacun d'entre eux.</p>
   </section>
 
+  <section id="int">
+    <title>int: Fonction interne</title>
+
+    <p>Lorsque le type-map <code>int</code> est spécifié, la source est
+    une des fonctions RewriteMap internes disponibles. Les développeurs
+    de modules peuvent fournir des fonctions internes supplémentaires en
+    les enregistrant via l'API <code>ap_register_rewrite_mapfunc</code>.
+    Les fonctions fournies par défaut sont :
+    </p>
+
+    <ul>
+      <li><strong>toupper</strong>:<br/>
+             Met tous les caractères de la clé en majuscules.</li>
+      <li><strong>tolower</strong>:<br/>
+             Met tous les caractères de la clé en minuscules.</li>
+      <li><strong>escape</strong>:<br/>
+             Protège les caractères spéciaux de la clé en les
+	     transformant en leur code hexadécimal.</li>
+      <li><strong>unescape</strong>:<br/>
+             Retraduit les codes hexadécimaux de la clé en caractères
+	     spéciaux.</li>
+    </ul>
+
+    <p>
+    Pour utiliser une de ces fonctions, créez une
+    <code>RewriteMap</code> faisant référence à cette fonction int, et
+    utilisez-la dans votre règle <code>RewriteRule</code> :
+    </p>
+
+    <p> <strong>Redirige un URI vers son équivalent en minuscules</strong></p>
+    <highlight language="config">
+
+RewriteMap lc int:tolower
+RewriteRule "(.*)" "${lc:$1}" [R]
+    </highlight>
+
+    <note>
+    <p>Notez que cet exemple n'est fourni qu'à titre d'illustration,
+    et ne constitue en aucun cas une recommandation. Si vous voulez
+    rendre des URLs insensibles à la casse, vous devez plutôt vous
+    tourner vers <module>mod_speling</module>.
+    </p>
+    </note>
+
+  </section>
+
   <section id="txt">
     <title>txt: tables de correspondances au format texte</title>
 
@@ -135,11 +181,11 @@ exemples pour chacun d'entre eux.</p>
     <p>Voici un exemple d'entrées valides dans un fichier de
     correspondances :</p>
 
-    <p class="indent">
+    <example>
       # Ligne de commentaires<br />
       <strong><em>clé</em> <em>valeur-substitution</em></strong><br />
       <strong><em>clé</em> <em>valeur-substitution</em></strong> # commentaire<br />
-    </p>
+    </example>
 
     <p>Lorsque la table de correspondance fait l'objet d'une recherche,
     la valeur spécifiée est recherchée dans le premier champ, et si elle
@@ -177,8 +223,9 @@ TELEPHONE  328
     </example>
 
     <p>Ainsi, lorsqu'une requête pour
-    <code>http://example.com/produit/TELEVISION</code> arrive, elle est
-    transformée en interne en <code>/prods.php?id=993</code>.</p>
+    <code>http://example.com/produit/TELEVISION</code> arrive, la directive
+    <directive module="mod_rewrite">RewriteRule</directive> s'applique, et la
+    requête est transformée en interne en <code>/prods.php?id=993</code>.</p>
 
     <note><title>Note: fichiers .htaccess</title>
     L'exemple donné est conçu pour être utilisé dans un contexte de
@@ -231,16 +278,16 @@ dynamique  www5|www6
 RewriteMap servers "rnd:/path/to/file/map.txt"
 
 RewriteRule "^/(.*\.(png|gif|jpg))" "http://${servers:static}/$1" [NC,P,L]
-RewriteRule "^/(.*)" "http://${servers:dynamic}/$1" [P,L]
+RewriteRule "^/(.*)"                "http://${servers:dynamic}/$1" [P,L]
     </highlight>
 
 
     <p>Ainsi, lorsqu'une image est demandée et que la première règle
-    convient, <code>RewriteMap</code> recherche la chaîne
+    convient, <directive module="mod_rewrite">RewriteMap</directive> recherche la chaîne
     <code>statique</code> dans le fichier de correspondances qui
     renvoie un des noms de serveurs spécifiés de manière aléatoire,
     ce dernier étant utilisé dans la cible de la règle
-    <code>RewriteRule</code>.</p>
+    <directive module="mod_rewrite">RewriteRule</directive>.</p>
 
     <p>Si vous voulez qu'un des serveurs soit plus souvent sollicité que
     les autres (par exemple s'il possède plus de mémoire, et peut donc
@@ -270,7 +317,8 @@ statique   www1|www1|www2|www3|www4
 RewriteMap examplemap "dbm=sdbm:/etc/apache/mapfile.dbm"
  </highlight>
 
-    <p>Ce type peut être choisi parmi sdbm, gdbm, ndbm ou db. Il est
+    <p>Ce type peut être choisi parmi <code>sdbm</code>, <code>gdbm</code>,
+    <code>ndbm</code> ou <code>db</code>. Il est
     cependant recommandé d'utiliser l'utilitaire <a
     href="../programs/httxt2dbm.html">httxt2dbm</a> fourni avec le
     serveur HTTP Apache, car il utilise la bibliothèque DBM appropriée,
@@ -286,7 +334,7 @@ $ httxt2dbm -i fichier-map.txt -o fichier-map.map
 </example>
 
 <p>Vous pouvez alors faire référence au fichier obtenu dans votre
-directive <code>RewriteMap</code> :</p>
+directive <directive module="mod_rewrite">RewriteMap</directive> :</p>
 <highlight language="config">
 RewriteMap mapname "dbm:/etc/apache/mapfile.map"
 </highlight>
@@ -297,7 +345,7 @@ même nom de base sont créés. Par exemple, vous pouvez obtenir deux
 fichiers nommés <code>fichier-map.map.dir</code> et
 <code>fichier-map.map.pag</code>. Ceci est tout à fait normal, et vous
 ne devez utiliser que le nom de base <code>fichier-map.map</code> dans votre
-directive <code>RewriteMap</code>.</p>
+directive <directive module="mod_rewrite">RewriteMap</directive>.</p>
 </note>
 
 <note><title>Mise en cache des recherches</title>
@@ -312,52 +360,6 @@ directive <code>RewriteMap</code>.</p>
 
   </section>
 
-  <section id="int">
-    <title>int: Fonction interne</title>
-
-    <p>Lorsque le type-map <code>int</code> est spécifié, la source est
-    une des fonctions RewriteMap internes disponibles. Les développeurs
-    de modules peuvent fournir des fonctions internes supplémentaires en
-    les enregistrant via l'API <code>ap_register_rewrite_mapfunc</code>.
-    Les fonctions fournies par défaut sont :
-    </p>
-
-    <ul>
-      <li><strong>toupper</strong>:<br/>
-             Met tous les caractères de la clé en majuscules.</li>
-      <li><strong>tolower</strong>:<br/>
-             Met tous les caractères de la clé en minuscules.</li>
-      <li><strong>escape</strong>:<br/>
-             Protège les caractères spéciaux de la clé en les
-	     transformant en leur code hexadécimal.</li>
-      <li><strong>unescape</strong>:<br/>
-             Retraduit les codes hexadécimaux de la clé en caractères
-	     spéciaux.</li>
-    </ul>
-
-    <p>
-    Pour utiliser une de ces fonctions, créez une
-    <code>RewriteMap</code> faisant référence à cette fonction int, et
-    utilisez-la dans votre règle <code>RewriteRule</code> :
-    </p>
-
-    <p> <strong>Redirige un URI vers son équivalent en minuscules</strong></p>
-    <highlight language="config">
-
-RewriteMap lc int:tolower
-RewriteRule "(.*)" "${lc:$1}" [R]
-    </highlight>
-
-    <note>
-    <p>Notez que cet exemple n'est fourni qu'à titre d'illustration,
-    et ne constitue en aucun cas une recommandation. Si vous voulez
-    rendre des URLs insensibles à la casse, vous devez plutôt vous
-    tourner vers <module>mod_speling</module>.
-    </p>
-    </note>
-
-  </section>
-
   <section id="prg"><title>prg: Programme de réécriture externe</title>
 
     <p>Lorque le type-map <code>prg</code> est spécifié, la source est
@@ -461,14 +463,15 @@ RewriteMap ma-requete "fastdbd:SELECT destination FROM rewrite WHERE source = %s
   <section id="summary">
     <title>Résumé</title>
 
-    <p>La directive <directive>RewriteMap</directive> peut apparaître
+    <p>La directive <directive module="mod_rewrite">RewriteMap</directive> peut apparaître
     plusieurs fois. Utilisez une directive
-    <directive>RewriteMap</directive> pour chaque fonction de mise en
+    <directive module="mod_rewrite">RewriteMap</directive> pour chaque fonction de mise en
     correspondance pour déclarer son fichier de correspondances.</p>
 
     <p>Bien que l'on ne puisse pas <strong>déclarer</strong> de fonction
     de mise en correspondance dans un contexte de répertoire (fichier
-    <code>.htaccess</code> ou section &lt;Directory&gt;), il est
+    <code>.htaccess</code> ou section <directive module="core"
+    type="section">Directory</directive>), il est
     possible d'utiliser cette fonction dans un tel contexte.</p>
 
   </section>
diff --git a/docs/manual/stopping.xml.fr b/docs/manual/stopping.xml.fr
index 9567bf53599..e877d372356 100644
--- a/docs/manual/stopping.xml.fr
+++ b/docs/manual/stopping.xml.fr
@@ -259,9 +259,9 @@ vous recevrez un message concernant ces erreurs.</note>
     n'&eacute;crase pas les fichiers des autres instances.</p>
 
     <p>Vous devez aussi prendre garde aux autres situations de comp&eacute;tition,
-    comme l'utilisation de l'enregistrement des logs avec un transfert de ceux-ci
-    dans le style <program>rotatelogs</program>. Plusieurs instances
-    du programme de <program>rotatelogs</program> qui tentent d'effectuer
+    comme l'enregistrement des logs avec un transfert de ceux-ci
+    via un pipe vers le programme <program>rotatelogs</program>. Plusieurs instances
+    du programme <program>rotatelogs</program> qui tentent d'effectuer
     une rotation des m&ecirc;mes fichiers de log en m&ecirc;me temps peuvent d&eacute;truire
     mutuellement leurs propres fichiers de log.</p></note>
 </section>
diff --git a/docs/manual/upgrading.xml.fr b/docs/manual/upgrading.xml.fr
index df667b86619..740d44f99df 100644
--- a/docs/manual/upgrading.xml.fr
+++ b/docs/manual/upgrading.xml.fr
@@ -1,9 +1,9 @@
-<?xml version="1.0" encoding="ISO-8859-1" ?>
+<?xml version="1.0" encoding="UTF-8" ?>
 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
 <?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
 <!-- French translation : Lucien GENTIS -->
 <!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 1686713:1738542 (outdated) -->
+<!-- English Revision: 1738542 -->
 
 <!--
  Licensed to the Apache Software Foundation (ASF) under one or more
@@ -24,137 +24,151 @@
 
 <manualpage metafile="upgrading.xml.meta">
 
-<title>Mise &agrave; jour de la version 2.2 vers la version 2.4</title>
+<title>Mise à jour de la version 2.2 vers la version 2.4</title>
 
 <summary>
-  <p>Afin d'assister les utilisateurs lors de leurs op&eacute;rations de mise &agrave;
+  <p>Afin d'assister les utilisateurs lors de leurs opérations de mise à
   jour, nous maintenons un document
-  qui comporte des informations critiques &agrave; l'attention des personnes qui
-  utilisent d&eacute;j&agrave; le serveur HTTP Apache. Ces informations
-  ne sont que de br&egrave;ves notes, et vous
+  qui comporte des informations critiques à l'attention des personnes qui
+  utilisent déjà le serveur HTTP Apache. Ces informations
+  ne sont que de brèves notes, et vous
   trouverez plus d'informations dans le document <a
-  href="new_features_2_4.html">Nouvelles fonctionnalit&eacute;s</a>, ou dans
-  le fichier <code>src/CHANGES</code>. Les d&eacute;veloppeurs d'applications
-  et de modules trouveront un r&eacute;sum&eacute; des modifications de l'API dans la
-  vue d'ensemble <a href="developer/new_api_2_4.html">Mises &agrave; jour de
+  href="new_features_2_4.html">Nouvelles fonctionnalités</a>, ou dans
+  le fichier <code>src/CHANGES</code>. Les développeurs d'applications
+  et de modules trouveront un résumé des modifications de l'API dans la
+  vue d'ensemble <a href="developer/new_api_2_4.html">Mises à jour de
   l'API</a>.</p>
 
-  <p>Ce document pr&eacute;sente les changements de comportement du serveur qui
-  peuvent n&eacute;cessiter une modification de la configuration, et une
-  méthode pour utiliser la version 2.4 du serveur en parall&egrave;le avec la
-  version 2.2. Pour tirer parti des nouvelles fonctionnalit&eacute;s de la
-  version 2.4, reportez-vous au document "Nouvelles fonctionnalit&eacute;s".</p>
+  <p>Ce document présente les changements de comportement du serveur qui
+  peuvent nécessiter une modification de la configuration, et une
+  méthode pour utiliser la version 2.4 du serveur en parallèle avec la
+  version 2.2. Pour tirer parti des nouvelles fonctionnalités de la
+  version 2.4, reportez-vous au document "Nouvelles fonctionnalités".</p>
 
-  <p>Ce document ne d&eacute;crit que les modifications intervenues entre les versions
-  2.2 et 2.4. Si vous effectuez une mise &agrave; jour depuis la version 2.0, vous
+  <p>Ce document ne décrit que les modifications intervenues entre les versions
+  2.2 et 2.4. Si vous effectuez une mise à jour depuis la version 2.0, vous
   devez aussi consulter le
   <a href="http://httpd.apache.org/docs/2.2/upgrading.html">document de mise
-  &agrave; jour de 2.0 vers 2.2.</a></p>
+  à jour de 2.0 vers 2.2.</a></p>
 
 </summary>
 <seealso><a href="new_features_2_4.html">Vue d'ensemble des nouvelles
-fonctionnalit&eacute;s du serveur HTTP Apache 2.4</a></seealso>
+fonctionnalités du serveur HTTP Apache 2.4</a></seealso>
 
   <section id="compile-time">
-    <title>Modifications des param&egrave;tres de compilation</title>
-     <p>Le processus de compilation est tr&egrave;s similaire &agrave; celui de la
+    <title>Modifications des paramètres de compilation</title>
+     <p>Le processus de compilation est très similaire à celui de la
      version 2.2. Dans la plupart des cas, vous pourrez utiliser votre
      ancienne ligne de commande <code>configure</code> (telle qu'elle
-     est enregistr&eacute;e dans le fichier <code>build/config.nice</code>
-     situ&eacute; dans le r&eacute;pertoire de compilation du serveur). Voici certains
-     changements intervenus dans la configuration par d&eacute;faut :</p>
+     est enregistrée dans le fichier <code>build/config.nice</code>
+     situé dans le répertoire de compilation du serveur). Voici certains
+     changements intervenus dans la configuration par défaut :</p>
 
     <ul>
-      <li>Les modules suivants ont &eacute;t&eacute; supprim&eacute;s : mod_authn_default,
+      <li>Les modules suivants ont été supprimés : mod_authn_default,
       mod_authz_default et mod_mem_cache. Si vous utilisiez
       mod_mem_cache sous la version 2.2, vous devez maintenant utiliser
       <module>mod_cache_disk</module> dans la version 2.4.</li>
 
-      <li>Toutes les impl&eacute;mentations de r&eacute;partition de charge ont &eacute;t&eacute;
-      d&eacute;plac&eacute;es vers des sous-modules sp&eacute;cifiques de mod_proxy, comme
+      <li>Toutes les implémentations de répartition de charge ont été
+      déplacées vers des sous-modules spécifiques de mod_proxy, comme
       <module>mod_lbmethod_bybusyness</module>. Vous devrez compiler et
-      charg&eacute;s tous les modules correspondants que votre configuration
+      chargés tous les modules correspondants que votre configuration
       utilise.</li>
 
       <li>Le support de BeOS, TPF, et des anciennes plates-formes telles
-      que A/UX, Next, et Tandem a &eacute;t&eacute; supprim&eacute;, car
-      elles ne sont plus consid&eacute;r&eacute;es comme maintenues.</li>
+      que A/UX, Next, et Tandem a été supprimé, car
+      elles ne sont plus considérées comme maintenues.</li>
 
-      <li>configure: les modules dynamiques (DSO) sont compil&eacute;s par
-      d&eacute;faut</li>
+      <li>configure: les modules dynamiques (DSO) sont compilés par
+      défaut</li>
 
-      <li>configure: par d&eacute;faut, seul un jeu de modules de base est
-      charg&eacute;. Les autres directives <directive>LoadModule</directive>
+      <li>configure: par défaut, seul un jeu de modules de base est
+      chargé. Les autres directives <directive>LoadModule</directive>
       sont mises en commentaires dans le fichier de configuration.</li>
 
-      <li>configure: le jeu de modules "most" est compil&eacute; par d&eacute;faut</li>
+      <li>configure: le jeu de modules "most" est compilé par défaut</li>
 
       <li>configure: le jeu de modules "reallyall" ajoute les modules de
-      d&eacute;veloppeur au jeu "all".</li>
+      développeur au jeu "all".</li>
     </ul>
 
   </section>
 
   <section id="run-time">
-    <title>Modifications de la configuration &agrave; l'ex&eacute;cution</title>
+    <title>Modifications de la configuration à l'exécution</title>
 <p>Des changements significatifs dans la configuration de
 l'autorisation, ainsi que quelques changements mineurs, peuvent
-n&eacute;cessiter une mise &agrave; jour des fichiers de configuration de la version
+nécessiter une mise à jour des fichiers de configuration de la version
 2.2 avant de les utiliser sous la version 2.4.</p>
 
     <section id="authz">
       <title>Autorisation</title>
 
-      <p>Tout fichier de configuration qui g&egrave;re des autorisations devra
-      probablement &ecirc;tre mis &agrave; jour.</p>
+      <p>Tout fichier de configuration qui gère des autorisations devra
+      probablement être mis à jour.</p>
 
     <p>Vous devez vous reporter au document <a
-    href="howto/auth.html">Authentification, autorisation et contr&ocirc;le
-    d'acc&egrave;s</a>, et plus particuli&egrave;rement &agrave; la section <a
+    href="howto/auth.html">Authentification, autorisation et contrôle
+    d'accès</a>, et plus particulièrement à la section <a
     href="howto/auth.html#beyond">Pour aller plus loin qu'une simple
-    autorisation</a> qui explique les nouveaux m&eacute;canismes permettant de
-    contr&ocirc;ler l'ordre dans lequel les directives d'autorisation sont
-    appliqu&eacute;es.</p>
+    autorisation</a> qui explique les nouveaux mécanismes permettant de
+    contrôler l'ordre dans lequel les directives d'autorisation sont
+    appliquées.</p>
 
-    <p>Les directives qui contr&ocirc;lent la mani&egrave;re dont les modules
-    d'autorisation r&eacute;agissent lorsqu'ils ne reconnaissent pas
-    l'utilisateur authentifi&eacute; ont &eacute;t&eacute; supprim&eacute;es : elles comprennent les
+    <p>Les directives qui contrôlent la manière dont les modules
+    d'autorisation réagissent lorsqu'ils ne reconnaissent pas
+    l'utilisateur authentifié ont été supprimées : elles comprennent les
     directives AuthzLDAPAuthoritative, AuthzDBDAuthoritative,
     AuthzDBMAuthoritative, AuthzGroupFileAuthoritative,
     AuthzUserAuthoritative et AuthzOwnerAuthoritative. Ces directives
-    ont &eacute;t&eacute; remplac&eacute;es par les directives plus explicites <directive
+    ont été remplacées par les directives plus explicites <directive
     module="mod_authz_core">RequireAny</directive>, <directive
     module="mod_authz_core">RequireNone</directive>, et <directive
     module="mod_authz_core">RequireAll</directive>.</p>
 
     <p>Si vous utilisez <module>mod_authz_dbm</module>, vous devez
-    mettre &agrave; jour votre configuration en rempla&ccedil;ant les directives du
+    mettre à jour votre configuration en remplaçant les directives du
     style <code>Require group ...</code> par des directives du style
     <code>Require dbm-group ...</code>.</p>
 
     <section id="access">
-      <title>Contr&ocirc;le d'acc&egrave;s</title>
+      <title>Contrôle d'accès</title>
 
-      <p>Dans la version 2.2, le contr&ocirc;le d'acc&egrave;s bas&eacute; sur le nom d'h&ocirc;te
-      du client, son adresse IP, ou d'autres caract&eacute;ristiques de la
-      requ&ecirc;te &eacute;tait assur&eacute; via les directives <directive
+      <p>Dans la version 2.2, le contrôle d'accès basé sur le nom d'hôte
+      du client, son adresse IP, ou d'autres caractéristiques de la
+      requête était assuré via les directives <directive
       module="mod_access_compat">Order</directive>, <directive
       module="mod_access_compat">Allow</directive>, <directive
       module="mod_access_compat">Deny</directive>, et <directive
       module="mod_access_compat">Satisfy</directive>.</p>
 
-      <p>Dans la version 2.4, ce contr&ocirc;le d'acc&egrave;s est assur&eacute;, comme tout
-      contr&ocirc;le d'autorisation, par le nouveau module
+      <p>Dans la version 2.4, ce contrôle d'accès est assuré, comme tout
+      contrôle d'autorisation, par le nouveau module
       <module>mod_authz_host</module>. Bien que le module
-      <module>mod_access_compat</module> soit fourni &agrave; des fins de
-      compatibilit&eacute; avec les anciennes configurations, les anciennes
-      directives de contr&ocirc;le d'acc&egrave;s devront &ecirc;tre remplac&eacute;es par les
-      nouveaux m&eacute;canismes d'authentification.</p>
+      <module>mod_access_compat</module> soit fourni à des fins de
+      compatibilité avec les anciennes configurations, les anciennes
+      directives de contrôle d'accès devront être remplacées par les
+      nouveaux mécanismes d'authentification.</p>
 
-      <p>Voici quelques exemples de contr&ocirc;le d'acc&egrave;s avec l'ancienne et
-      la nouvelle m&eacute;thode :</p>
-
-      <p>Dans cet exemple, toutes les requ&ecirc;tes sont rejet&eacute;es :</p>
+      <note><title>Mélanger anciennes et nouvelles directives</title>
+      <p>Mélanger d'anciennes directives comme <directive
+      module="mod_access_compat">Order</directive>, <directive
+      module="mod_access_compat">Allow</directive> ou <directive
+      module="mod_access_compat">Deny</directive> avec des nouvelles comme
+      <directive module="mod_authz_core">Require</directive> est techniquement
+      possible mais déconseillé. En effet, <module>mod_access_compat</module> a
+      été conçu pour supporter des configurations ne contenant que des anciennes
+      directives afin de faciliter le passage à la version 2.4. Les
+      exemples ci-dessous vous permettront de vous faire une meilleure idée des
+      problèmes qui peuvent survenir.
+      </p>
+      </note>
+
+      <p>Voici quelques exemples de contrôle d'accès avec l'ancienne et
+      la nouvelle méthode :</p>
+
+      <p>Dans cet exemple, toutes les requêtes sont rejetées :</p>
       <example>
         <title>version 2.2 :</title>
         <highlight language="config">
@@ -169,7 +183,7 @@ Deny from all
 	</highlight>
       </example>
 
-      <p>Dans cet exemple, toutes les requ&ecirc;tes sont accept&eacute;es :</p>
+      <p>Dans cet exemple, toutes les requêtes sont acceptées :</p>
       <example>
         <title>version 2.2 :</title>
         <highlight language="config">
@@ -184,8 +198,25 @@ Allow from all
 	</highlight>
       </example>
 
-      <p>Dans l'exemple suivant, tous les h&ocirc;tes du domaine example.org
-      ont l'autorisation d'acc&egrave;s, tous les autres sont rejet&eacute;s :</p>
+      <p>Dans l'exemple suivant, tous les hôtes du domaine example.org
+      ont l'autorisation d'accès, tous les autres sont rejetés :</p>
+
+      <example>
+        <title>version 2.2 :</title>
+        <highlight language="config">
+Order Deny,Allow
+Deny from all
+Allow from example.org
+        </highlight>
+      </example>
+      <example>
+        <title>version 2.4 :</title>
+	<highlight language="config">
+        Require host example.org
+	</highlight>
+      </example>
+    <p>Dans l'exemple suivant, tous les hôtes du domaine example.org
+      ont l'autorisation d'accès, tous les autres sont rejetés :</p>
 
       <example>
         <title>version 2.2 :</title>
@@ -201,6 +232,66 @@ Allow from example.org
         Require host example.org
 	</highlight>
       </example>
+
+      <p>Dans l'exemple suivant, le mélange d'anciennes et de nouvelles
+      directives produit des résultats inattendus.</p>
+ 
+      <example>
+        <title>Mélange d'anciennes et de nouvelles directives : RESULTAT
+	INATTENDU</title>
+          <highlight language="config">
+DocumentRoot "/var/www/html"
+
+&lt;Directory "/"&gt;
+    AllowOverride None
+    Order deny,allow
+    Deny from all
+&lt;/Directory&gt;
+
+&lt;Location "/server-status"&gt;
+    SetHandler server-status
+    Require 127.0.0.1
+&lt;/Location&gt;
+
+access.log - GET /server-status 403 127.0.0.1
+error.log - AH01797: client denied by server configuration: /var/www/html/server-status
+          </highlight>
+      </example>
+      <p>Pourquoi httpd interdit l'accès à server-status alors que la
+      configuration semble l'autoriser ? Parce que dans ce scénario de <a
+      href="sections.html#merging">fusion</a> de configuration, les
+      directives de <module>mod_access_compat</module> sont prioritaires par
+      rapport à celles de <module>mod_authz_host</module>.</p>
+
+      <p>L'exemple suivant quant à lui produit un résultat conforme :</p>
+
+      <example>
+        <title>Mélange d'anciennes et de nouvelles directives : RESULTAT
+	CONFORME</title>
+        <highlight language="config">
+DocumentRoot "/var/www/html"
+
+&lt;Directory "/"&gt;
+    AllowOverride None
+    Require all denied
+&lt;/Directory&gt;
+
+&lt;Location "/server-status"&gt;
+    SetHandler server-status
+    Order deny,allow
+    Deny from all
+    Allow From 127.0.0.1
+&lt;/Location&gt;
+
+access.log - GET /server-status 200 127.0.0.1
+        </highlight>
+      </example> 
+      <p>En conclusion, même si une configuration hybride peut fonctionner,
+      essayez de l'éviter lors de la mise à jour : soit conservez les anciennes
+      directives, puis migrez-les vers les nouvelles ultérieurement, soit
+      effectuez une migration immédiate de toutes les anciennes directives vers
+      les nouvelles.  
+      </p>      
     </section>
 
     </section>
@@ -208,130 +299,130 @@ Allow from example.org
     <section id="config">
       <title>Autres changements dans la configuration</title>
 
-      <p>D'autres ajustements mineurs peuvent s'av&eacute;rer n&eacute;cessaires pour
-      certaines configurations particuli&egrave;res, comme d&eacute;crit ci-dessous.</p>
+      <p>D'autres ajustements mineurs peuvent s'avérer nécessaires pour
+      certaines configurations particulières, comme décrit ci-dessous.</p>
 
       <ul>
-        <li>La directive <directive>MaxRequestsPerChild</directive> a &eacute;t&eacute; renomm&eacute;e en
+        <li>La directive <directive>MaxRequestsPerChild</directive> a été renommée en
 	<directive module="mpm_common">MaxConnectionsPerChild</directive>;
-	ce nouveau nom refl&egrave;te mieux l'usage de cette directive.
-	L'ancien nom est encore support&eacute;.</li>
+	ce nouveau nom reflète mieux l'usage de cette directive.
+	L'ancien nom est encore supporté.</li>
 
 	<li>La directive <directive>MaxClients</directive> a
-	&eacute;t&eacute; renomm&eacute;e en <directive
+	été renommée en <directive
 	module="mpm_common">MaxRequestWorkers</directive>; ce nouveau
-	nom refl&egrave;te mieux l'usage de cette directive. Pour les
+	nom reflète mieux l'usage de cette directive. Pour les
 	modules multiprocessus asynchrones, comme <module>event</module>, le nombre
-	maximal de clients n'est pas &eacute;quivalent au nombre de threads du
-	worker. L'ancien nom est encore support&eacute;.</li>
+	maximal de clients n'est pas équivalent au nombre de threads du
+	worker. L'ancien nom est encore supporté.</li>
 
         <li>La directive <directive
 	module="core">DefaultType</directive> ne produit plus aucun
-	effet, si ce n'est d'&eacute;mettre un avertissement si elle est
-	d&eacute;finie &agrave; une valeur autre que <code>none</code>. D'autres
+	effet, si ce n'est d'émettre un avertissement si elle est
+	définie à une valeur autre que <code>none</code>. D'autres
 	directives de configuration la remplacent dans la version 2.4.
         </li>
 
-	<li>La valeur par d&eacute;faut de la directive <directive
+	<li>La valeur par défaut de la directive <directive
 	module="core">AllowOverride</directive> est maintenant
 	<code>None</code>.</li>
 
-	<li>La valeur par d&eacute;faut de la directive <directive
+	<li>La valeur par défaut de la directive <directive
 	module="core">EnableSendfile</directive> est maintenant Off.</li>
 
-	<li>La valeur par d&eacute;faut de la directive <directive
+	<li>La valeur par défaut de la directive <directive
 	module="core">FileETag</directive> est maintenant "MTime Size"
 	(sans INode).</li>
 
         <li><module>mod_dav_fs</module>: le format du fichier <directive
-	module="mod_dav_fs">DavLockDB</directive> a chang&eacute; pour les syst&egrave;mes
+	module="mod_dav_fs">DavLockDB</directive> a changé pour les systèmes
 	avec inodes. L'ancien fichier <directive
-	module="mod_dav_fs">DavLockDB</directive> doit &ecirc;tre supprim&eacute; dans le
-	cadre de la mise &agrave; jour.
+	module="mod_dav_fs">DavLockDB</directive> doit être supprimé dans le
+	cadre de la mise à jour.
         </li>
 
         <li>La directive <directive module="core">KeepAlive</directive>
 	n'accepte que les valeurs <code>On</code> ou <code>Off</code>.
-	Avant, toute valeur autre que "Off" ou "0" &eacute;tait trait&eacute;e comme
+	Avant, toute valeur autre que "Off" ou "0" était traitée comme
 	"On".</li>
 
         <li>Les directives AcceptMutex, LockFile, RewriteLock, SSLMutex,
-	SSLStaplingMutex et WatchdogMutexPath ont &eacute;t&eacute; remplac&eacute;es par la
+	SSLStaplingMutex et WatchdogMutexPath ont été remplacées par la
 	directive unique <directive module="core">Mutex</directive>.
-	Vous devez &eacute;valuer l'impact de ces directives obsol&egrave;tes dans
-	votre configuration version 2.2 afin de d&eacute;terminer si elles
-	peuvent &ecirc;tre simplement supprim&eacute;es, ou si elles doivent &ecirc;tre
-	remplac&eacute;es par la directive <directive
+	Vous devez évaluer l'impact de ces directives obsolètes dans
+	votre configuration version 2.2 afin de déterminer si elles
+	peuvent être simplement supprimées, ou si elles doivent être
+	remplacées par la directive <directive
 	module="core">Mutex</directive>.</li>
 
         <li><module>mod_cache</module>: la directive <directive
 	module="mod_cache">CacheIgnoreURLSessionIdentifiers</directive>
-	effectue maintenant une correspondance exacte dans la cha&icirc;ne de
-	param&egrave;tres au lieu d'une correspondance partielle. Si votre
-	configuration mettait en jeu des sous-cha&icirc;nes comme
-	<code>sessionid</code> pour correspondre &agrave;
+	effectue maintenant une correspondance exacte dans la chaîne de
+	paramètres au lieu d'une correspondance partielle. Si votre
+	configuration mettait en jeu des sous-chaînes comme
+	<code>sessionid</code> pour correspondre à
 	<code>/une-application/image.gif;jsessionid=123456789</code>,
-	vous devez maintenant utiliser la cha&icirc;ne de correspondance
-	compl&egrave;te <code>jsessionid</code>.
+	vous devez maintenant utiliser la chaîne de correspondance
+	complète <code>jsessionid</code>.
         </li>
 
-	<li><module>mod_cache</module>: le second param&egrave;tre de la
+	<li><module>mod_cache</module>: le second paramètre de la
 	directive <directive module="mod_cache">CacheEnable</directive>
-	ne concerne les contenus en mandat direct que s'ils d&eacute;butent par
-	le protocole appropri&eacute;. Dans les versions 2.2 et ant&eacute;rieures, un
-	param&egrave;tre tel que '/' concernait tous les contenus.</li>
+	ne concerne les contenus en mandat direct que s'ils débutent par
+	le protocole approprié. Dans les versions 2.2 et antérieures, un
+	paramètre tel que '/' concernait tous les contenus.</li>
 
         <li><module>mod_ldap</module>: la directive <directive
 	module="mod_ldap">LDAPTrustedClientCert</directive> s'utilise
 	maintenant exclusivement au sein d'une configuration de niveau
-	r&eacute;pertoire. Si vous utilisez cette directive, passez en revue
-	votre configuration pour vous assurer qu'elle est bien pr&eacute;sente
-	dans tous les contextes de r&eacute;pertoire n&eacute;cessaires.</li>
+	répertoire. Si vous utilisez cette directive, passez en revue
+	votre configuration pour vous assurer qu'elle est bien présente
+	dans tous les contextes de répertoire nécessaires.</li>
 
 	<li><module>mod_filter</module>: la syntaxe de la directive
 	<directive module="mod_filter">FilterProvider</directive> utilise
-	maintenant une expression bool&eacute;enne pour d&eacute;terminer si un filtre
+	maintenant une expression booléenne pour déterminer si un filtre
 	s'applique.
         </li>
 
 	<li><module>mod_include</module>:
             <ul>
-            <li>L'&eacute;l&eacute;ment <code>#if expr</code> utilise maintenant le
-	    nouvel <a href="expr.html">interpr&eacute;teur d'expressions</a>.
-	    L'ancienne syntaxe peut &ecirc;tre r&eacute;activ&eacute;e via la directive
+            <li>L'élément <code>#if expr</code> utilise maintenant le
+	    nouvel <a href="expr.html">interpréteur d'expressions</a>.
+	    L'ancienne syntaxe peut être réactivée via la directive
 	    <directive
 	    module="mod_include">SSILegacyExprParser</directive>.
             </li>
-            <li>Dans la port&eacute;e du r&eacute;pertoire, une directive de
-	    configuration SSI* ne provoque plus la r&eacute;initialisation &agrave;
-	    leur valeur par d&eacute;faut de toutes les directives SSI* de
-	    niveau r&eacute;pertoire.</li>
+            <li>Dans la portée du répertoire, une directive de
+	    configuration SSI* ne provoque plus la réinitialisation à
+	    leur valeur par défaut de toutes les directives SSI* de
+	    niveau répertoire.</li>
             </ul>
         </li>
 
         <li><module>mod_charset_lite</module> : l'option
-	<code>DebugLevel</code> a &eacute;t&eacute; supprim&eacute;e en faveur d'une
+	<code>DebugLevel</code> a été supprimée en faveur d'une
 	configuration de la directive <directive
-	module="core">LogLevel</directive> au niveau r&eacute;pertoire.
+	module="core">LogLevel</directive> au niveau répertoire.
         </li>
 
         <li><module>mod_ext_filter</module> : l'option
-	<code>DebugLevel</code> a &eacute;t&eacute; supprim&eacute;e en faveur d'une
+	<code>DebugLevel</code> a été supprimée en faveur d'une
 	configuration de la directive <directive
-	module="core">LogLevel</directive> au niveau r&eacute;pertoire.
+	module="core">LogLevel</directive> au niveau répertoire.
         </li>
 
 	<li><module>mod_proxy_scgi</module>: certaines applications web
 	ne fonctionneront plus correctement avec la nouvelle
-	configuration de <code>PATH_INFO</code> qui est diff&eacute;rente de
+	configuration de <code>PATH_INFO</code> qui est différente de
 	celle de la version 2.2. La configuration
-	pr&eacute;c&eacute;dente peut &ecirc;tre
-	restaur&eacute;e en d&eacute;finissant la variable
+	précédente peut être
+	restaurée en définissant la variable
 	<code>proxy-scgi-pathinfo</code>.</li>
 
-	<li><module>mod_ssl</module>: le contr&ocirc;le de r&eacute;vocation des
-	certificats bas&eacute; sur les CRL doit &ecirc;tre maintenant explicitement
-	configur&eacute; via la directive <directive
+	<li><module>mod_ssl</module>: le contrôle de révocation des
+	certificats basé sur les CRL doit être maintenant explicitement
+	configuré via la directive <directive
         module="mod_ssl">SSLCARevocationCheck</directive>.
         </li>
 
@@ -339,21 +430,21 @@ Allow from example.org
 	ligne est maintenant 1Mo.
         </li>
 
-        <li><module>mod_reqtimeout</module>: si ce module est charg&eacute;, il
-	d&eacute;finit maintenant certains temps d'attente par d&eacute;faut.</li>
+        <li><module>mod_reqtimeout</module>: si ce module est chargé, il
+	définit maintenant certains temps d'attente par défaut.</li>
 
 	<li><module>mod_dumpio</module>: la directive
-	<directive>DumpIOLogLevel</directive> n'est plus support&eacute;e. Les
-	donn&eacute;es sont toujours enregistr&eacute;es au niveau <code>trace7</code>
+	<directive>DumpIOLogLevel</directive> n'est plus supportée. Les
+	données sont toujours enregistrées au niveau <code>trace7</code>
 	de <directive module="core">LogLevel</directive></li>
 
-        <li>Jusqu'&agrave; la version 2.2, sur les plateformes de style Unix, 
-	les commandes de redirection des logs d&eacute;finies via <directive
+        <li>Jusqu'à la version 2.2, sur les plateformes de style Unix, 
+	les commandes de redirection des logs définies via <directive
 	module="core">ErrorLog</directive> ou <directive
-	module="mod_log_config">CustomLog</directive> &eacute;taient invoqu&eacute;es
+	module="mod_log_config">CustomLog</directive> étaient invoquées
 	en utilisant <code>/bin/sh -c</code>. A
 	partir de la version 2.4, les commandes de redirection des logs
-	sont ex&eacute;cut&eacute;es directement. Pour retrouver l'ancien
+	sont exécutées directement. Pour retrouver l'ancien
 	comportement, voir la <a href="logs.html#piped">documentation
 	sur la redirection des logs</a></li>
 
@@ -366,55 +457,55 @@ Allow from example.org
 
     <ul>
       <li><module>mod_auto_index</module>: extrait maintenant les titres
-      et affiche la description pour les fichiers .xhtml qui &eacute;taient
-      jusqu'alors ignor&eacute;s.</li>
+      et affiche la description pour les fichiers .xhtml qui étaient
+      jusqu'alors ignorés.</li>
 
-      <li><module>mod_ssl</module> : le format par d&eacute;faut des variables
-      <code>*_DN</code> a chang&eacute;. Il est cependant encore possible
+      <li><module>mod_ssl</module> : le format par défaut des variables
+      <code>*_DN</code> a changé. Il est cependant encore possible
       d'utiliser l'ancien format via la nouvelle option
       <code>LegacyDNStringFormat</code> de la directive <directive
       module="mod_ssl">SSLOptions</directive>. Le protocole SSLv2 n'est
-      plus support&eacute;. Les directives <directive
+      plus supporté. Les directives <directive
       module="mod_ssl">SSLProxyCheckPeerCN</directive> et
       <directive module="mod_ssl">SSLProxyCheckPeerExpire</directive>
-      sont maintenant d&eacute;finies par d&eacute;faut &agrave; On, et les requ&ecirc;tes mandat&eacute;es
-      vers des serveurs HTTPS poss&egrave;dant des certificats non conformes ou
-      p&eacute;rim&eacute;s &eacute;choueront donc avec un code d'erreur 502 (Bad gateway).</li>
+      sont maintenant définies par défaut à On, et les requêtes mandatées
+      vers des serveurs HTTPS possèdant des certificats non conformes ou
+      périmés échoueront donc avec un code d'erreur 502 (Bad gateway).</li>
 
-      <li><program>htpasswd</program> utilise maintenant par d&eacute;faut les
-      condens&eacute;s MD5 sur toutes les plates-formes.</li>
+      <li><program>htpasswd</program> utilise maintenant par défaut les
+      condensés MD5 sur toutes les plates-formes.</li>
 
       <li>La directive <directive
       module="core">NameVirtualHost</directive> n'a plus aucun effet, si
-      ce n'est l'&eacute;mission d'un avertissement. Toute combinaison
+      ce n'est l'émission d'un avertissement. Toute combinaison
       adresse/port apparaissant dans plusieurs serveurs virtuels est
-      trait&eacute;e implicitement comme un serveur virtuel bas&eacute; sur le nom.
+      traitée implicitement comme un serveur virtuel basé sur le nom.
       </li>
 
       <li><module>mod_deflate</module> n'effectue plus de compression
-      s'il s'aper&ccedil;oit que la quantit&eacute; de donn&eacute;es ajout&eacute;e par la
-      compression est sup&eacute;rieure &agrave; la quantit&eacute; de donn&eacute;es &agrave; compresser.
+      s'il s'aperçoit que la quantité de données ajoutée par la
+      compression est supérieure à la quantité de données à compresser.
       </li>
 
       <li>Les pages d'erreur multilingues de la version 2.2.x ne
-      fonctionneront qu'apr&egrave;s avoir &eacute;t&eacute; corrig&eacute;es pour
-      respecter la nouvelle syntaxe de l'&eacute;l&eacute;ment <code>#if expr=</code>
+      fonctionneront qu'après avoir été corrigées pour
+      respecter la nouvelle syntaxe de l'élément <code>#if expr=</code>
       du module <module>mod_include</module>, ou si la directive
       <directive module="mod_include">SSILegacyExprParser</directive> a
-      &eacute;t&eacute; activ&eacute;e pour le r&eacute;pertoire contenant les pages d'erreur.
+      été activée pour le répertoire contenant les pages d'erreur.
       </li>
 
-      <li>La fonctionnalit&eacute; fournie par <code>mod_authn_alias</code>
-      dans les pr&eacute;c&eacute;dentes versions (en fait la directive
+      <li>La fonctionnalité fournie par <code>mod_authn_alias</code>
+      dans les précédentes versions (en fait la directive
       <directive module="mod_authn_core">AuthnProviderAlias</directive>)
       est maintenant fournie par <module>mod_authn_core</module>.  
       </li>
 
-      <li>Les directives RewriteLog et RewriteLogLevel ont &eacute;t&eacute;
-      supprim&eacute;es. Leur fonctions sont maintenant assur&eacute;es par la
+      <li>Les directives RewriteLog et RewriteLogLevel ont été
+      supprimées. Leur fonctions sont maintenant assurées par la
       directive <directive
-      module="core">LogLevel</directive> qui permet de d&eacute;finir
-      un niveau de journalisation appropri&eacute; pour le module
+      module="core">LogLevel</directive> qui permet de définir
+      un niveau de journalisation approprié pour le module
       <module>mod_rewrite</module>. Voir aussi la section <a
       href="mod/mod_rewrite.html#logging">journalisation de
       mod_rewrite</a>.</li>
@@ -426,18 +517,18 @@ Allow from example.org
   <section id="third-party">
     <title>Modules tiers</title>
 
-	<p>Tous les modules tiers doivent &ecirc;tre recompil&eacute;s pour la
-	version 2.4 avant d'&ecirc;tre charg&eacute;s.</p>
+	<p>Tous les modules tiers doivent être recompilés pour la
+	version 2.4 avant d'être chargés.</p>
 
-    <p>De nombreux modules tiers con&ccedil;us pour la version 2.2
+    <p>De nombreux modules tiers conçus pour la version 2.2
     fonctionneront sans changement avec le serveur HTTP Apache
-    version 2.4. Certains n&eacute;cessiteront cependant des modifications ; se
-    reporter &agrave; la vue d'ensemble <a
-    href="developer/new_api_2_4.html">Mise &agrave; jour de l'API</a>.</p>
+    version 2.4. Certains nécessiteront cependant des modifications ; se
+    reporter à la vue d'ensemble <a
+    href="developer/new_api_2_4.html">Mise à jour de l'API</a>.</p>
   </section>
 <section id="commonproblems">
-    <title>Probl&egrave;mes de mise &agrave; jour courants</title>
-    <ul><li>Erreurs au d&eacute;marrage :
+    <title>Problèmes de mise à jour courants</title>
+    <ul><li>Erreurs au démarrage :
     <ul>
       <li><code>Invalid command 'User', perhaps misspelled or defined by
       a module not included in the server configuration</code> - chargez
@@ -447,30 +538,30 @@ Allow from example.org
       by a module not included in the server configuration</code>, ou
       <code>Invalid command 'Order', perhaps misspelled or defined by a
       module not included in the server configuration</code> - chargez
-      le module <module>mod_access_compat</module>, ou mettez &agrave; jour
+      le module <module>mod_access_compat</module>, ou mettez à jour
       vers la version 2.4 les directives d'autorisation.</li>
 
       <li><code>Ignoring deprecated use of DefaultType in line NN of
       /path/to/httpd.conf</code> - supprimez la directive <directive
       module="core">DefaultType</directive> et remplacez-la par les
-      directives de configuration appropri&eacute;es.</li>
+      directives de configuration appropriées.</li>
 
       <li><code>Invalid command 'AddOutputFilterByType', perhaps misspelled 
       or defined by a module not included in the server configuration
       </code> - la directive <directive
-      module="mod_filter">AddOutputFilterByType</directive> qui &eacute;tait
-      jusqu'alors impl&eacute;ment&eacute;e par le module core, l'est maintenant par
-      le module mod_filter, qui doit donc &ecirc;tre charg&eacute;.</li>
+      module="mod_filter">AddOutputFilterByType</directive> qui était
+      jusqu'alors implémentée par le module core, l'est maintenant par
+      le module mod_filter, qui doit donc être chargé.</li>
 
     </ul></li>
-    <li>Erreurs de traitement des requ&ecirc;tes :
+    <li>Erreurs de traitement des requêtes :
     <ul>
       <li><code>configuration error:  couldn't check user: /path</code> -
       chargez le module <module>mod_authn_core</module>.</li>
-      <li>Les fichiers <code>.htaccess</code> ne sont pas trait&eacute;s -
-      V&eacute;rifiez la pr&eacute;sence d'une directive <directive
-      module="core">AllowOverride</directive> appropri&eacute;e ; sa valeur par
-      d&eacute;faut est maintenant <code>None</code>.</li>
+      <li>Les fichiers <code>.htaccess</code> ne sont pas traités -
+      Vérifiez la présence d'une directive <directive
+      module="core">AllowOverride</directive> appropriée ; sa valeur par
+      défaut est maintenant <code>None</code>.</li>
     </ul>
     </li>
 </ul>