From: Lucien Gentis <lgentis@apache.org>
Date: Sat, 9 Apr 2016 16:19:31 +0000 (+0000)
Subject: XML updates.
X-Git-Tag: 2.5.0-alpha~1770
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=67c0fc084de326d57e1129082156a652a87583b2;p=apache

XML updates.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1738361 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/docs/manual/howto/auth.xml.fr b/docs/manual/howto/auth.xml.fr
index 4c9315660e..24d1a8887e 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: 1673932:1738331 (outdated) -->
+<!-- English Revision: 1738331 -->
 <!-- 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
@@ -336,65 +336,65 @@ 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. Vous pouvez m&ecirc;me simuler le comportement
-    des groupes en associant un fichier de mots de passe diff&eacute;rent pour
-    chaque groupe. L'avantage de cette approche r&eacute;side dans le fait
+    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. Vous pouvez même simuler le comportement
+    des groupes en associant un fichier de mots de passe différent pour
+    chaque groupe. L'avantage de cette approche réside dans le fait
     qu'Apache ne doit consulter qu'un fichier au lieu de deux. Par
     contre, vous devez maintenir un nombre plus ou moins important de
-    fichiers de mots de passe, et vous assurer de faire r&eacute;f&eacute;rence au bon
+    fichiers de mots de passe, et vous assurer de faire référence au bon
     fichier dans la directive <directive
     module="mod_authn_file">AuthUserFile</directive>.</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">
@@ -408,18 +408,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>
 
@@ -436,18 +436,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/mod/mod_access_compat.xml.fr b/docs/manual/mod/mod_access_compat.xml.fr
index c4cc38062f..1fe2262606 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: 1673945:1738217 (outdated) -->
+<!-- English Revision: 1738217 -->
 <!-- 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,39 +415,39 @@ 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>
@@ -445,26 +455,26 @@ et l'authentification utilisateur</description>
 </contextlist>
 <override>AuthConfig</override>
 <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">
@@ -474,10 +484,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">
@@ -491,22 +501,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_rewrite.xml.fr b/docs/manual/mod/mod_rewrite.xml.fr
index caa116115e..a95f19d055 100644
--- a/docs/manual/mod/mod_rewrite.xml.fr
+++ b/docs/manual/mod/mod_rewrite.xml.fr
@@ -1,7 +1,7 @@
 <?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: 1734260:1737774 (outdated) -->
+<!-- English Revision: 1737774 -->
 <!-- French translation : Lucien GENTIS -->
 <!-- Reviewed by : Vincent Deffontaines -->
 
@@ -133,7 +133,7 @@ moteur de réécriture</description>
       hôte virtuel pour lequel vous souhaitez utiliser des règles
       de réécriture.</p>
 
-      <p>Les directives <directive>RewriteMap</directive> du type
+      <p>Les directives <directive module="mod_rewrite">RewriteMap</directive> du type
       <code>prg</code> ne sont pas prises en compte au cours de
       l'initialisation du serveur si elle ont été définies dans un
       contexte où la directive <directive>RewriteEngine</directive> n'a
@@ -431,7 +431,7 @@ répertoire</description>
       <p>La directive <directive>RewriteBase</directive> permet de
       spécifier le préfixe d'URL à utiliser dans un contexte de
       répertoire (htaccess) pour les directives
-      <directive>RewriteRule</directive> qui réécrivent vers un chemin
+      <directive module="mod_rewrite">RewriteRule</directive> qui réécrivent vers un chemin
       relatif.</p>
       <p>Cette directive est <em>obligatoire</em> si vous utilisez un
       chemin relatif dans une substitution, et dans un contexte de
@@ -445,7 +445,7 @@ répertoire</description>
 	  une directive telle qu'<directive
 	  module="mod_alias">Alias</directive>).</li>
           <li>Le chemin du système de fichiers vers le répertoire
-	  contenant la <directive>RewriteRule</directive>, suffixé par
+	  contenant la <directive module="mod_rewrite">RewriteRule</directive>, suffixé par
 	  la substitution relative est aussi valide en tant qu'URL sur
 	  le serveur (ce qui est rare).</li>
 	  <li>A partir de la version 2.4.11 du serveur HTTP Apache,
@@ -933,6 +933,13 @@ la réécriture soit effectuée
 	    en utilisant la variante the <strong>-L</strong> ou
 	    <strong>-h</strong>.</dd>
 
+            <dt><strong>-ne</strong></dt>
+            <dd>Est numériquement <strong>n</strong>on <strong>é</strong>gal à<br />
+	     La <em>Chaîne de test</em> est considérée comme un entier et est
+	     numériquement comparée à l'<em>expression de comparaison</em>. Vrai
+	     si les deux éléments comparés sont numériquement différents.
+	     Equivalent à <code>!-eq</code>.</dd>	    
+
            </dl>
         </li>
 
@@ -959,7 +966,7 @@ la réécriture soit effectuée
 	    utiliser avec précautions car les performances du serveur
 	    peuvent s'en trouver affectées !</dd>
 
-	    <dt><strong>-H</strong></dt>
+	    <dt><strong>-h</strong></dt>
 	    <dd>est un lien symbolique, selon la convention bash<br />
             Voir <strong>-l</strong>.</dd>
 
@@ -1202,7 +1209,7 @@ relatives.</li>
 l'intégralité du
 chemin de l'URL dans un contexte de répertoire (htaccess), vous devez
 utiliser la variable <code>%{REQUEST_URI}</code> dans la directive
-<directive>RewriteCond</directive>.</li>
+<directive module="mod_rewrite">RewriteCond</directive>.</li>
 
 <li>Le prefixe supprimé se termine toujours par un slash, ce qui
 signifie que la comparaison s'effectue avec une chaîne qui ne comporte
@@ -1328,8 +1335,9 @@ substitution !
       seront remplacés par le contenu du <strong>N</strong>ème groupe
       du <em>Modèle</em> qui correspondait. Les variables du serveur
       sont les mêmes que dans la <em>Chaîne_de_test</em> d'une
-      directive <code>RewriteCond</code>. Les fonctions de comparaison
-      sont issues de la directive <code>RewriteMap</code> dans la
+      directive <directive module="mod_rewrite">RewriteCond</directive>. Les
+      fonctions de comparaison sont issues de la directive <directive
+      module="mod_rewrite">RewriteMap</directive> dans la
       section de laquelle elles sont décrites. Ces trois types de
       variables sont évaluées dans l'ordre ci-dessus.</p>
 
@@ -1366,7 +1374,7 @@ substitution !
       des
       <strong><code>[</code><em>drapeaux</em><code>]</code></strong>
       comme troisième argument de la directive
-      <code>RewriteRule</code>. Séparés par des virgules au sein d'une
+      <directive>RewriteRule</directive>. Séparés par des virgules au sein d'une
       liste encadrée par des crochets, les <em>drapeaux</em> peuvent
       être choisis dans la table suivante. Vous trouverez plus de
       détails, et des exemples pour chaque drapeau dans le <a
diff --git a/docs/manual/upgrading.xml.fr b/docs/manual/upgrading.xml.fr
index 213788543b..15adde3d30 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: 1686712:1738217 (outdated) -->
+<!-- English Revision: 1738217 -->
 
 <!--
  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 la mani&egrave;re
-  d'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 la manière
+  d'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">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> assure la
+      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,8 @@ 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>
@@ -201,6 +215,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 +282,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><directive>MaxRequestsPerChild</directive> a &eacute;t&eacute; renomm&eacute;e en
+        <li><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 +413,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,46 +440,46 @@ 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>
@@ -413,7 +487,7 @@ Allow from example.org
       <li><module>mod_cgid</module> utilise la valeur de la directive
       <directive module="core">Timeout</directive> du serveur pour
       limiter le temps d'attente entre les sorties d'un programme CGI.
-      La valeur de ce temps d'attente peut maintenant &ecirc;tre modifi&eacute;e via
+      La valeur de ce temps d'attente peut maintenant être modifiée via
       la directive <directive
       module="mod_cgid">CGIDScriptTImeout</directive>.
       </li>
@@ -425,18 +499,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
@@ -446,30 +520,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>