Le fichier .htaccess

Ceci est une ARCHIVE, peut-être périmée. Vérifiez bien les compatibilités !

Cet article a pour but de vous faire découvrir le fichier .htaccess et son utilisation pour paramétrer les accès à votre site web.

Article original publié sur le site dynamique de l’immobilier

Le fichier .htaccess

Cet article a pour but de vous faire découvrir le fichier .htaccess et son utilisation pour améliorer votre site web.

Ce simple fichier texte [1] vous permet d’ajuster finement certains paramètres de votre serveur Apache tels que les redirections, les réécritures d’URL, les redirections et les restrictions d’accès.

Cette puissance permet le meilleur comme le pire. Même si la syntaxe des règles du fichier .htaccess est souvent triviale, la moindre faute dans celles-ci se traduira le plus souvent par la redoutée "erreur 500" [2].

L’une des utilisations les plus répandues de ce fichier est l’affichage d’une page 404 [3] personnalisée, beaucoup plus utile que celle procurée par défaut par votre navigateur favori.

Note aux utilisateurs FrontPage

Lorsque les extensions FrontPage sont installées, un fichier .htaccess est créé à la racine du site. Il faut donc être très prudent et éviter d’écraser ce fichier, faute de quoi les extensions FrontPage ne fonctionneraient plus sur votre site. De même, avant toute modification, une sauvegarde du fichier originel est utile, car toute erreur dans ce fichier pourrait rendre l’entièreté de votre site inaccessible.

Votre hébergement permet-il son utilisation ?

C’est, bien sûr, la première question à se poser. Elle ne fait malheureusement pas partie de celles auxquelles on peut répondre simplement.
Si votre hébergement se fait sur un système Unix/Linux et que le serveur Web est de type Apache, le fichier .htaccess est supporté. Ceci ne veut malheureusement pas dire que votre hébergeur en autorise l’utilisation.
Le plus souvent, les hébergements gratuits ont cette fonctionnalité désactivée.

Si votre hébergeur vous permet de restreindre l’accès à certains de vos répertoires à l’aide d’un mot de passe, c’est en général à l’aide du fichier .htaccess, dans ce cas, tout va bien.

De deux choses l’une : soit vous téléchargez votre fichier .htaccess et tout fonctionne comme vous l’espériez, soit cela ne fonctionne pas et au pire vous obtenez une "erreur 500". Dans ce cas, il ne vous reste plus qu’à retirer le fichier incriminé. Ce n’est pas bien dangereux, mais réservez vos essais à une période creuse. Le seul cas où un fichier .htaccess pourrait poser de réels problèmes est celui où le serveur utilise des extensions Microsoft FrontPage.
Ces dernières utilisent le fichier .htaccess et son écrasement les empêcherait à jamais de fonctionner.

Si vous n’aimez pas vivre dangereusement, le plus simple reste encore de demander à votre hébergeur ou à une connaissance ayant le même type d’hébergement que vous.

Pour effectuer vos tests, il est judicieux de créer un répertoire temporaire sur votre site, dans lequel vous mettrez un fichier index.html et le fichier .htaccess sur lequel vous travaillez.

Une fois votre fichier .htaccess mis au point, déplacez le dans le répertoire que vous voulez protéger, ou à la racine de votre site.

C’est supporté ? Bien ! Restez avec nous !

Avant toutes choses, il faut arriver à créer ce fichier. Sous pratiquement tous les systèmes d’exploitation, cela se fait sans problème comme n’importe quel fichier texte.
Windows peut toutefois ne pas accepter la création de ce fichier tel que souhaité. En effet, .htaccess est vu par Windows comme un fichier sans nom comportant une extension non standard. Si notepad ou votre éditeur favori ne vous permet pas d’enregistrer ce fichier avec le nom souhaité, sauvez-le comme htaccess.txt, vous le renommerez plus tard sur votre serveur à l’aide de votre logiciel de transfert ftp.
Attention : Une fois renommé, le fichier doit impérativement se nommer « .htaccess » (débutant par un point), sinon il sera sans effet.

Nous allons commencer notre découverte avec une fonctionnalité bien utile

La page d’erreur « sur mesure »

Comme tout internaute, vous avez déjà eu l’occasion de faire face à l’erreur la plus répandue, l’erreur 404. Cette erreur vient du fait que l’Internet est essentiellement mouvant, des millions de pages y apparaissent et disparaissent chaque jour.
Si un de vos visiteurs décide de mettre en favori l’une de vos pages pour y revenir plus tard, rien ne lui garantit que cette page sera toujours accessible à sa prochaine visite.
Vous pouvez à tout moment décider de la déplacer, de la renommer ou de la supprimer. C’est votre site, vous en avez le droit le plus absolu.

Que se passera-t-il lors du retour de ce même visiteur ? C’est simple : son navigateur fera une requête pour la page souhaitée, requête à laquelle le serveur répondra « pas trouvé ».
Dès la genèse du Web, les différents concepteurs ont bien intégré le fait que les utilisateurs seraient d’origines différents et qu’une page mentionnant ce laconique « pas trouvé » ne pourrait pas être exhaustive sur le plan linguistique. Ils ont donc défini des codes pour chaque type d’erreurs, laissant aux navigateurs le soin d’afficher le message dans la langue de l’utilisateur. D’où, dans ce cas précis, l’erreur communément appelée « erreur 404 ».

Pour éviter à vos visiteurs cette page peu esthétique, une seule ligne suffit dans le fichier .htaccess :

ErrorDocument  404  /mapage.html

Dès ce moment, toutes les requêtes pour des pages inexistantes recevront en retour la page mapage.html. Si vous êtes prévoyant, cette page pourrait présenter un plan de votre site qui évitera à votre visiteur de se sentir seul et abandonné de tous. Il faut bien sûr que ce fichier « mapage.html » existe à la racine de votre site sinon votre serveur ne saura plus où donner de la tête. Ne souriez pas, c’est arrivé à l’auteur de ces lignes.

D’une manière plus générale, l’instruction « ErrorDocument » s’écrit :

ErrorDocument  code-erreur  fichier

En plus de l’erreur 404, vous pouvez donc fournir des pages spécifiques pour les erreurs les plus fréquentes, par exemple :

401 - Autorisation Requise
400 - Mauvaise requête
403 - Interdit
500 - Erreur interne serveur

La restriction d’accès par mot de passe

Nous avons tous sur nos sites certains répertoires que nous souhaitons protéger des yeux indiscrets. Qu’il soit bien entendu ici, que la meilleure protection possible pour un document passe par la non publication sur le Web, quelle que soit le niveau de protection du serveur ou du répertoire.
Ceci est encore plus vrai s’il s’agit d’un hébergement mutualisé dont la gestion est assurée par un organisme indépendant. Ne stockez donc pas sur votre serveur Web d’informations dont la divulgation pourrait vous pénaliser.

Ces limitations étant exprimées, il est souvent utile ou dans certains cas indispensable d’avoir dans un répertoire des informations telles que le mot de passe d’accès à votre base de données ou les statistiques de fréquentation de votre serveur.
Dans le cadre des hébergements sur serveur Apache, il est aisé de soustraire certains répertoires à la curiosité du public. Cette fois encore, le fichier .htaccess est votre allié.

Le mode opératoire en est simple et s’appuie sur un deuxième fichier qui contiendra les noms et mots de passe des personnes autorisées à accéder au contenu du répertoire.

Dans le fichier .htaccess, saisissez les informations suivantes :

AuthUserFile /home/login/.htpasswd
AuthGroupFile /dev/null
AuthName "Acces Restreint"
AuthType Basic
<Limit GET POST>
require valid-user
</Limit>

Analysons de plus près ces quelques lignes :

AuthUserFile /home/login/.htpasswd
donne le répertoire dans lequel se trouve le fichier contenant les paires login/mot de passe des visiteurs autorisés. Notez bien qu’il ne s’agit pas d’une URL, mais bien d’un chemin d’accès depuis la racine du serveur.

L’usage veut que ce fichier soit souvent nommé .htpasswd, mais ce n’est pas du tout une obligation. Il est même conseillé d’utiliser un autre nom, le fichier sera d’autant plus difficile à trouver. Ne le mettez pas dans un répertoire qui fait partie du site mais placez-le plutôt en dehors de cette arborescence si vous en avez le choix.

Dans le système d’exploitation Unix/Linux, tous les fichiers dont le nom commence par un point décimal sont des fichiers cachés. Attention : caché ne signifie pas invisible, mais signifie plutôt qu’ils n’apparaissent pas dans les commandes les plus fréquentes si leur affichage n’est pas spécifiquement demandé.

AuthGroupFile /dev/null
permet de donner un droit d’accès à un ensemble d’utilisateurs faisant partie d’un même groupe et est rarement utilisée dans le cas de sites Web personnels. Dans l’exemple, le fichier « /dev/null » est l’équivalent Unix de « nulle-part » ou « pas de fichier spécifique »

AuthName "Acces Restreint"
est la chaîne de caractère qui apparaîtra dans la boîte de dialogue au moment de la saisie du nom et du mot de passe.

AuthType Basic
détermine le type d’authentification utilisé, dans notre cas l’authentification HTTP standard.

<limit GET POST> ... </limit>
détermine le type d’opérations permises. GET s’applique à la majorité des pages Web, PUT est utilisé par certains scripts ou éditeurs pour faire de l’upload sous protocole http. Il est important de mettre GET et POST en majuscule sur les dernières versions d’Apache.

require valid-user
signifie littéralement qu’un utilisateur valide est requis, à savoir un utilisateur pour le nom duquel une ligne existe dans le fichier .htpasswd. Une variante pourrait être :
require user pierre paul
pour limiter l’accès aux seuls utilisateurs pierre et paul

Le fichier .htpasswd

C’est très simple, pour chaque utilisateur autorisé ce fichier contient une ligne sous la forme « nom:mot de passe crypté » ou encore « pierre:saqKFoHV4rU.E »

La seule difficulté, pour autant que c’en soit une, étant de crypter le mot de passe. Il existe deux types d’approche différents :

-  Vous avez accès a un shell Unix/Linux

htpasswd -c passwdfile username

Dans cette commande, « passwdfile » représente le chemin complet du fichier mot de passe souhaité, « username » est le nom de l’utilisateur.

-  Pour tous ceux qui n’ont pas d’accès au shell unix, plusieurs sites sur le Web vous permettent d’obtenir le mot de passe encrypté, par exemple : http://ovh.fr/cgi-bin/crypt.pl

Vous voilà en mesure de restreindre l’accès à vos répertoires privés ou, pourquoi pas, de créer des répertoires réservés aux copains ou aux membres de votre famille.

Vous avez déplacé vos pages ?

Il est parfois nécessaire de déplacer certaines pages ou répertoires d’un site dans l’optique d’une restructuration. Ceci ne va pas sans poser quelques problèmes inhérents au changement d’adresse :
-  la page n’est plus accessible pour les visiteurs qui l’ont mise dans leurs favoris.
-  les références à cette page dans les moteurs de recherche et annuaires pointent vers l’ancienne adresse.

Dans ces deux cas de figure, plutôt que de présenter une page d’erreur personnalisée au visiteur, il est beaucoup plus élégant de le rediriger automatiquement vers la nouvelle adresse. Ici encore, le fichier .htaccess nous sera précieux.

Pour déplacer une page :

RedirectPermanent ancien.html http://www.domaine.tld/nouveau.html

Cette directive signale au navigateur que la page ancien.html a été renommée nouveau.html et renvoie l’entête correcte au navigateur pour signaler ce fait (entête 301 « déplacement permanent »). L’avantage de cette approche est que les robots d’indexation des différents moteurs apprendront que cette page a été déplacée et modifieront leur index pour refléter la nouvelle adresse. Dans le cas de Google, le PageRank [4] de l’ancienne page sera automatiquement transmis à la nouvelle page.

Pour déplacer un répertoire :

RedirectPermanent /ancien http://www.domaine.tld/nouveau/

Il est important de noter que dans le cas d’utilisation de la directive RedirectPermanent, la nouvelle adresse de page ou de répertoire doit être une URL complète.

Pour changer de nom de domaine :

RedirectPermanent / http://www.nouveaudomaine.tld/

Cette directive redirigera la racine de l’ancien site vers le nouveau domaine.

Note : Seuls les moteurs de recherche ajusteront leur index pour refléter la nouvelle adresse. N’oubliez pas de demander aux annuaires de modifier leurs liens vers vos pages.

Pour des redirections plus avancées, découvrez la suite de l’article : La réécriture d’URL

Notes

[1Avec le protocole ftp, il est impératif de transférer le fichier .htaccess en mode texte et non en mode binaire, de manière à obtenir les caractères de fin de ligne appropriés au système d’exploitation du serveur. De même, l’édition en local devra se faire en mode texte.

[2L’erreur 500 est une erreur interne au serveur, survenant le plus souvent lors de l’appel d’un module inexistant ou effectuant une opération illégale.

[3L’erreur 404, ou « page inexistante », est l’erreur la plus fréquente sur le web.

[4Indice de mesure de popularité d’une page utilisé par Google et noté sur une échelle de 0 à 10.

Discussion

30 discussions

  • Bonjour,

    J’utilise le fichier .htaccess pour un site SPIP qui vient remplacer un autre site. Les faisant cohabiter pour le moment, j’utilise :

    RedirectPermanent /compo.php ?niveau=umr&page=menu_actu http://citeres.univ-tours.fr/spip.php?rubrique15

    pour rediriger les pages de l’ancien site vers le nous site mis en place. Le fichier htaccess est bien lu par le serveur mais la redirection ne se fait pas... A la place, j’ai une erreur 404...
    Qu’est-ce que j’ai fait de travers ???

    Merci de votre aide

    Répondre à ce message

  • Bonjour, je suis sous spip 2.1.10 et j’ai régulièrement une erreur 310 : « trop de redirections »

    Conditions de l’erreur :
    Mon hébergeur : 1&1 - serveur mutualisé
    -  seulement quand l’utilisateur est logué
    -  lorsqu’il clique sur un lien du type « /spip.php ?... »
    (exemple : /spip.php ?page=rubrique%3D113&id_rubrique=113&date_select=2011-05-16 )

    Bilan  : spip surcharge les redirection lorsque l’utilisateur est logué et clique sur des liens du type « /spip.php ?... » avec plusieures variables en environnement.

    Le problème peut-il venir d’une mauvaise configuration de mon fichier htaccess ?

    Merci beaucoup pour votre aide ;)

    Répondre à ce message

  • 1

    Bonjour,
    Sous spip 2.8.1, j’ai un problème d’indexation par google.
    En utilisant l’outil d’exploration du site comme googlebot, j’obtiens le type de message suivant qui présente des infos troublantes pour le titre et le contenus du body :

    Type Googlebot : Web
    
    HTTP/1.0 301 Moved Permanently
    Date: Sun, 13 Mar 2011 09:24:17 GMT
    Server: Apache
    X-Powered-By: PHP/5.2.17-0.dotdeb.0
    Location: urls_html_dist
    Content-Length: 260
    Connection: close
    Content-Type: text/html
    Content-Language: fr
    
    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
    <html lang='fr' dir='ltr'>
    
    <head>
    <title>HTTP 301</title>
    </head>
    <body>
    <h1>HTTP 301</h1>
    <a href="urls_html_dist">Si votre navigateur n'est pas redirig&eacute;, cliquez ici pour continuer.</a></body></html>

    Un échange sur le forum de google me pose la question :

    Je ne vois pourtant pas de redirection. Serait-il possible qu’il y en ait une dans certains cas dans ton .htaccess ?

    Si vous avez une explication merci bien

    • Bonjour,
      Je me répond car j’ai débloqué la situation.

      Le fichier htaccess n’y était pour rien dans ce problème.

      En fait il m’a suffit de recharger le pulgin CFG pour le mettre à jour et tout est rentré dans l’ordre.

      Google retrouve bien le chemin du site et l’indexation est bien à jour.

      A continuer

    Répondre à ce message

  • 2
    Pascal Boulerie

    L’article ne parle pas de la directive RewriteBase , essentielle quand le site est hébergé dans un sous-répertoire et non pas à la racine.

    Précisions sur cette directive :
    http://www.apachefrance.com/Manuels/Apache_1.3_VF/mod/mod_rewrite.html#RewriteBase

    PS A noter que les commentaires donnés dans le fichier htaccess.txt livré par défaut avec SPIP ne sont pas très explicites :

    ### Configuration sous-repertoire
    # Chez la plupart des hebergeurs il faut indiquer « RewriteBase / »
    # sinon modifiez cette ligne

    Il eut mieux valu donner un exemple plus détaillé :

    ### Configuration sous-repertoire
    # Chez la plupart des hebergeurs il faut indiquer « RewriteBase / »
    # Par contre, si votre site SPIP est hébergé et est vu de l’extérieur expressément dans un sous-dossier,
    # par exemple mon_spip_a_moi
    # (et que vous y accédez par une adresse en http://nom_du_serveur/mon_spip_a_moi )
    # modifiez la ligne suivante selon la syntaxe suivante :
    # RewriteBase /mon_spip_a_moi

    • Cet article date de 2003... Si vous avez la possibilité d’en proposer une version rafraichie, nul ne vous en voudra :-)

      A noter aussi : le coeur de spip gère désormais les erreurs 404 et renvoie vers le squelette 404.html qu’il suffit donc de personnaliser. Plus besoin de .htaccess pour ça donc.

    • Ah merci, mine de rien c’est une info précieuse. Mais je veux bien, au contraire, expliquer comment personnaliser ce squelette.hlm pour ceux qui découvrent spip et tout le reste.

    Répondre à ce message

  • 2

    Bonjour,

    j’essaie de rediriger des requêtes indexées par Google provenant d’un ancien CMS.
    Ces requêtes sont de la forme « www.monsite.com/index.php?module=orki&page=view.... » ce qui renvoie une 404 -> logique.
    Mais je voudrais rediriger 301, et là je n’ai pas réussi la manip : j’utilise les url propres de SPIP, mais l’ajout en entête du .htaccess de « RedirectMatch permanent », « Redirect permanent » ou « RewriteRule » n’a rien donné : je n’arrive pas à « capter » les requêtes de type « index.php ?module=orki&page=view... » pour les rediriger sur ma page d’accueil.

    Quelqu’un serait-il plus inspiré que moi ;-)
    Merci beaucoup,
    françois.

    • Quelles url complètes écris-tu ?
      La ligne

      RedirectPermanent /blog http://perline.org/spip.php?page=rubrique&id_rubrique=xx

      marche bien chez moi

    • Bonjour Perline,

      Plus précisément, je voudrai que les urls qui contiennent la chaine : module=orki& soient redirigées vers l’accueil. J’ai essayé les REGEX avec RedirectMatch permanent, mais je ne suis pas assez calé pour y arriver.

      Merci pour ton aide ;-)
      françois

    Répondre à ce message

  • Bonjour.
    J’ai un problème , j’aimerai ajouter dans le fichier .htaccess la liste des adresses IP des machines des users qui ont habilité à se connecter à l’espace privé de mon site web.
    Comment faire ?
    Merci.

    Répondre à ce message

  • Bonjour,

    Finalement, existe-t-il une solution pour filtrer la lecture de seulement certains dossiers. J’utilisais sans soucis le fichier .htaccess dans mon précédent site. Ce n’était pas difficile. La partie à protéger se trouvait placée dans un dossier particulier.

    Ici, avec SPIP, c’est différent. Je ne comprends pas comment protéger seulement un répertoire du site. Sur le site www.arpeges.org, je souhaiterais créer un répertoire « Espace membres ». Comment limiter l’accès aux seuls adhérents à ce seul répertoire ?

    Merci

    Répondre à ce message

  • 1

    Bonjour

    J’ai voulu rendre l acces de mon site en restreint.

    Pour cela comme expliqué j’ai mis un .htacess et .htpasswd sur mon home (www). cela fonctionne.

    Sauf que depuis des que je vais sur mon espace privé que je souhaite modifier un artcile / une rubrique ou autre...j’arrive sur une page « accès interdit » comme s’il n’arrivait pas à revenir sur le public.

    Pour info mes codes sont les memes pour l’espace privé et l’espace public (c’es tpeut etre ca le soucis mais je ne peux plus les modifier car a chaque fois je reviens sur cette page interdit)
    le cooki de correspondance est bien mis...

    bref que dois je faire

    merci de votre réponse.

    • Pour info je n’ai pas mis ces fichier dans un dossier squelette le soucis est peut etre la ????

    Répondre à ce message

  • 3

    J’aimerai avoir un petit renseignement concernant la restriction par mot de passe:comment je fais pour sélectionner le répertoire (voir le rubrique créée)à protéger par mot de passe/login

    • Bonjour,

      Tout simplement en mettant un fichier .htaccess dedans ! ;-)

    • Bonjour,
      J’ai bien compris le principe mais je recherche depuis un moment où sont stockés les rubriques créées et les pages associées ? Nous avons en effet développé un site pour un club associatif. On voudrait donc limiter les accés aux rubriques spécifiques des différentes sections. Mais pas moyen de mettre la main sur le répertoire créé par SPIP (ex : pour la natation, le n° de rubrique est le 20 ) dans l’arborescence du site.

      Merci pour ton aide.

    • Je cherche sans succès une solution identique (partie publique et partie privée d’un même site)

      Pour répondre à la question, il est normal de ne rien trouver... SPIP ne génère pas de fichiers dans l’arborescence, tout est contenu dans la base de données (c’est son point fort pour le partage...).

      A part réinstaller une seconde fois SPIP dans un sous-répertoire protégé, et à la condition que l’hébergeur autorise DEUX bases de données DISTINCTES, je ne vois pas de solution.... mais cela revient à avoir deux sites....

      Il faudrait que SPIP ajoute dans chaque table une valeur indiquant si l’article est public ou privé.. ça existe peut-être, mais je n’en trouve trace nulle part dans la doc, ni dans l’interface de rédaction des articles... peut-être que dans la version 2.xxx !

      Merci à celui qui aurait une idée simple et donc lumineuse...

    Répondre à ce message

  • 2
    Anne-Caroline Paucot

    Pour effectuer un test, j’aimerais protéger mon site « hyaka » placé dans le repertoire www. Le truc de base de spip. Où est-ce que je mets le fichier .htpasswrd et qu’est-ce que j’indique comme chemin au fichier .htaccess. J’ai fait plein d’essais et cela ne fonctionne pas.
    Serait-il possible d’avoir la ligne de code ? Merci d’avance.

    • Dan (admin Webmaster Hub)

      Bonjour Anne-Caroline,

      J’ai vu que ton site hyaka.com est hébergé sur un 20GP OVH.
      Le chemin absolu du répertoire www de ton site sur le serveur devrait donc être /home/hyaka/www/ (sous réserve pour le hyaka, car OVH utilise generalement 8 caracteres)

      Tu peux mettre le fichier .htpasswd a plusieurs endroits, mais je te suggèrerais de le mettre dans /home/hyaka parce que dans ce cas il est tout à fait protégé étant en dehors de l’espace web.

      Dans ce cas, tu peux mettre la ligne suivante dans le fichier .htaccess :
      AuthUserFile /home/hyaka/.htpasswd

      Remplaces hyaka par ton véritable login ovh s’il est différent.

      Cordialement

      Dan

    • OVH gère automatiquement la création de ce fichier via le “Manager

      Les instructions du fichier .htaccess sont légèrement différente du standard, et les l’interface assure en plus un cryptage très efficace.

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom