Quelle est la meilleure architecture pour votre site Web ?

La syntaxe du HTML a peu évolué depuis une dizaine d’années. On peut même constater depuis quelques temps un retour aux sources avec le balisage sémantique. A contrario, l’architecture des sites a profondément changé. Aujourd’hui, le webdesigner dispose de nombreuses options pour structurer son site sans s’arracher les cheveux à le maintenir et le faire évoluer. Je vais évoquer les méthodes les plus fréquentes.

Par architecture, j’entends considérer le squelette du site, en dehors de toute considération visuelle ou ergonomique. Il s’agit d’un niveau plus basique mais peu souvent évoqué sur le Net :

  • la séparation des éléments récurrents (en-tête, navigation, etc.) et du contenu principal, changeant
  • l’intégration au sein d’une page du code qui « appelle » les différents éléments qui la composent
  • la manière dont sont organisés les fichiers correspondants

Les pages statiques

Les dinosaures du Web se souviennent probablement d’un temps où la page HTML était une et indivisible. Elle contenait l’intégralité des éléments récurrents en plus du contenu.

ARBORESCENCE :


/index.html

/presentation.html

En plus d’un surpoids conséquent sur chaque page, cela « figeait » progressivement le site au fur et à mesure de son enrichissement, car la moindre modification concernait un nombre croissant de pages. On se souvient sans nostalgie des longues séances de rechercher/remplacer sur des paragraphes entiers, envahi par l’angoisse qu’une ou deux pages passent à la trappe à cause d’un espace en trop. Bien souvent, d’ailleurs, l’unique issue, consistait à passer au peigne fin des dizaines de fichiers pour les contraindre par la force d’accepter les modifications. Fort heureusement, cette époque est révolue.

Les frames (cadres)

Les frames furent la première méthode à portée de tous pour inclure simplement un bloc récurrent au sein de pages différentes. Elles offraient une séparation des zones en fichiers individuels, beaucoup plus simples à mettre à jour à l’échelle d’un site. Elles ont eu leur heure de gloire avant que les mises en garde des hérauts de l’usabilité (en 1996 déjà !) ne soient entendues et qu’on bannisse cette source de confusion pour l’utilisateur. Elles ont au moins établi durablement le concept d’inclusion, un fichier se chargeant d’appeler les autres selon les besoins.

ARBORESCENCE :


/index.html

/frames_nav.html

/frames_entete.html

/frames_accueil.html

/frames_presentation.html

Les inclusions multiples

PHP3 est arrivé à point nommé pour pallier la déshérence des frames. Pour beaucoup de webmasters non formés à la programmation, ce langage se réduisait quasiment à sa fonction include() si pratique. Il faut dire que cela réglait avec élégance le problème de la maintenance : un fichier pour chaque élément récurrent, et un assemblage réalisé directement par le serveur, qui produisait un fichier HTML comme aux premiers jours, compatible avec tous les navigateurs. On a donc vu fleurir les inclusions à chaque bout de page, du type <td id="nav"><?php include ('inc/entete.php'); ?></td>, et idem pour la nav’, le bas de page, etc.

ARBORESCENCE :


/index.php

/presentation.php

/inc/nav.php

/inc/entete.php

Avec l’accroissement du nombre de pages de contenu, cette structure pose encore des problèmes de maintenance, puisque les inclusions sont mélangées à du code HTML. Si l’on souhaite remplacer le TD par un DIV pour construire un site sans tableaux, notre vieil ennemi le rechercher/remplacer refait surface. Et lui la crainte d’un oubli, si longtemps refoulée, affleure de nouveau. Est-il encore concevable, en deux-mille et des brouettes, qu’un travailleur de l’esprit soit réduit à répéter compulsivement la séquence ouvrir-cliquer-rechercher texte-sélectionner-CTRL V ? Il y a forcément une tâche plus stimulante pour votre cervelet.

L’include Haut/Bas

On peut déjà, on poussant à l’extrème l’usage des inclusions, séparer la page en trois blocs : le contenu ; ce qui va avant et ce qui va après. Ou plus précisément, le gabarit (ou template) du haut de page et celui du bas de page. Il n’y a plus que 2 inclusions par page et surtout, le code peut se balader à loisir entre le haut et le bas (la nav peut changer de localisation par exemple) sans affecter chaque page de contenu. Le fichier ressemblera donc à ça : <?

include ('inc/haut.php');

?>

<h1>Titre de la page</h1>

<p>Texte</p>

<?

include ('inc/bas.php');

?>

L’arborescence aura cet aspect :

ARBORESCENCE :


/index.php

/presentation.php

/tpl/haut.php // il peut lui-même contenir des includes vers tpl/nav.php et tpl/entete.php pour l'alléger

/tpl/bas.php

Il sera probablement nécessaire de passer quelques variables au gabarit du haut, pour peupler les zones telles que la balise TITLE, les mots-clés ou afficher un class="actif" sur la page active dans la nav. Ce n’est pas compliqué, il suffit de déclarer $TITRE = 'accueil'; juste avant d’inclure le gabarit du haut.

Ce type d’architecture a la particularité de multiplier les fichiers PHP à la racine. Pour ranger vos pages dans des dossiers, il faut régler la question de l’url des images, CSS et autres liens dans les gabarits qui sont liés à un unique fichier à la racine. Pour cela on pourra déclarer en début de page une variable $CHEMIN ='../'; en n’oubliant pas de l’intégrer dans toutes les url du gabarit (<img src="<?= $CHEMIN ; ?>img/logo.png">).

Cette architecture peut fournir une base assez simple pour un système de pages qui chargent à leur tour des contenus dynamiques. Sur un forum par exemple, on créera forum.php, sujet.php, message.php sur ce modèle.

Un contrôleur qui charge des fichiers de contenus

La notion de contrôleur provient des développeurs d’application (cf. le motif modèle-vue-contrôleur). Dans cette logique, un script (ici index.php) est chargé de recevoir les demandes du visiteur (par les paramètres passés en GET), de les faire traiter par le ‘modèle’ (analyser les variables, les transformer, charger des données), et de renvoyer à l’utilisateur un écran (la ‘vue’) qui en résulte. On pourra choisir de placer les pages de contenus dans des fichiers .php qui seront identifiés par le paramètre page. La requête index.php?page=presentation chargera ainsi la page presentation.php, grâce à la syntaxe suivante :

include ('tpl/haut.php');

$page = ($_GET['page']) ? $_GET['page'] : 'accueil';

if (file_exists('contenu/'. $_GET['page'] . '.php'))

{

include ('contenu/'. $_GET['page'] . '.php');

}

include ('tpl/haut.php');

Cette méthode a l’avantage de créer une arborescence propre : chaque type de fichier possède son dossier à la racine :

ARBORESCENCE :


/index.php

/contenu/accueil.php

/contenu/presentation.php

/inc/haut.php

/inc/bas.php

Le principal défaut de cette architecture est qu’elle ne permet pas au contrôleur de piocher des variables dans le fichier avant son affichage, notamment pour les balises TITLE et compagnie. Le contrôleur doit donc tenir un catalogue des pages, le plus souvent sous la forme d’un tableau associatif (Array) :

$pages = array (

"accueil" => array (

"titre" => "Accueil",

"keywords" => "accueil,home,bienvenue",

),

"presentation" => array (

"titre" => "Présentation",

"keywords" => "présentation,qui sommes-nous,notre activité",

),

);

Si le site devient complexe ou que la quantité d’infos sur chaque page augmente, cette architecture atteint ses limites. On pourrait certes le faire avec du XML ou un fichier INI en en-tête de la page de contenu, mais ça me paraît compliqué et source d’erreurs.

Le contrôleur et la base de données

J’ai vu plus d’un webmaster tenter la mise en oeuvre de systèmes d’include et de contrôleurs hybrides, avant d’en venir naturellement à chercher le salut dans les bases de données. Le travail sur un gros site est beaucoup plus fluide et sa mise à jour bien plus aisée dès que l’ensemble des contenus sont passés en base de données. On pourra ainsi stocker de manière normalisée le titre, les mots-clés, le contenu principal, mais aussi les droits d’accès de chaque page, sa position dans les rubriques et le gabarit qu’elles utilisent.

L’appel se fera généralement via un identifiant passé dans l’URL, comme index.php?page_id=59. A cette requête, le contrôleur pourra provoquer une série d’actions :

  • Connexion à la base de données
  • Requête sur l’objet répondant à l’id 59
  • Identification du template utilisé (par ex. page d’actu)
  • Inclusion du template « page d’actu » et calculs éventuels (le template peut lui-même effectuer des requêtes et afficher des contenus dynamiques)
  • Affichage de l’ensemble de la page

ARBORESCENCE :


/index.php

/inc/connexion_bdd.php

/inc/haut.php

/inc/bas.php

/tpl/actu.php

/tpl/liste_liens.php

/tpl/recherche.php

Je n’entrerai pas ici dans le détail de la structuration de votre base de données. La plupart des CMS séparent rubriques, articles, liens, images dans des tables séparées. J’ai personnellement l’habitude d’enregistrer toutes les données d’un site dans un « grand arbre » qui mêle rubriques, articles, images et modules fonctionnels. Si certains sont intéressés, je pourrai l’aborder dans un autre article. L’essentiel est de garder à l’esprit que la base de données impose un effort de structuration important au départ, mais donne une flexibilité absolue à la longue. Si vous l’associez à la programmation orientée objet, vous obtenez un système bien ordonné et facile à faire évoluer.

Il n’y a pas de limite, par exemple, au nombre de gabarits que vous pouvez créer pour vos contenus. Vous pouvez développer des modules extrèmement riches, qui incluent à leur tour de nombreuses sous-pages, et qui sont référencés par un unique ID dans la base de données. Vous pouvez également créer un état « en attente » pour les contenus non validés, et les afficher en grisé dans le gabarit approprié.

Attention, cependant, à ne pas surcharger de code les champs de texte de la base. Les balises (surtout lorsqu’elles ne sont pas décoratives) vieillissent, même dans une base de données. Très vite le bel encart jaune placé en <div style="background-color:yellow">Texte</div> se révèle démodé et vous revoilà parti à éplucher les champs de votre table pour traquer les bouts de code obsolètes. Si possible, n’utilisez que du code sémantique (h1, p, blockquote), surtout pas d’infos de style. Vous pourrez ainsi revoir le style sans toucher au source. Mieux, choisissez une syntaxe Wiki et parsez le fichier avec des expressions régulières lors de la lecture : libre à vous de transformer tous les === titre === en H3 ou en H4 selon l’évolution future du site.

Outil de référencement professionnel - essai gratuit Ce contenu a été publié dans Webdesign, avec comme mot(s)-clé(s) , , , , , , . Vous pouvez le mettre en favoris avec ce permalien.

8 réponses à Quelle est la meilleure architecture pour votre site Web ?

  1. fridim dit :

    On pourrait aussi noter les divers frameworks pour finir, qui règlent le problème de l’architecture à adopter (Ruby On Rails, catalyst, …).

  2. babali dit :

    Bravo pour cet article trouvé par hasard sur le net et qui correspond à ma préoccupation du moment … comment architecturer mon futur site. Mon premier site développé coorespondant au paragraphe "L’include Haut/Bas" j’aimerais cette fois l’architecturer au mieux pour gérer le multilingues et faciliter le référencement.

    Pouvez vous me préciser comment vous avez organisé votre base de donnée dans votre "grand arbre" ?

    Merci

  3. Damien Ravé - Le Caphar dit :

    @babali : Très rapidement, le principe est simple : chaque ligne de la base de donnée possède deux éléments de « position » : le champ id (INT primary auto-increment) et le champ parent_id qui rattache l’élément à un niveau supérieur.

    Tous les objets du site sont dans la même base. On peut donc avoir un objet invisible « arborescence » (id 1, parent_id 0) à laquelle se rattachent des pages Web, par exemple « accueil » (id 2, parent_id 1) et « notre societé » (id 3, parent_id 1). Sur cette dernière page, on aura un bloc <div> (id 4, parent_id 3), une page de deuxième niveau (id 5, parent_id 3) et une image (id 6, parent_id 3).

    Il faut ensuite créer le bon template (gabarit) pour chacun de ces éléments. Par exemple, régler la question des « pages » qui apparaissent sous forme de page entière lorsqu’on passe leur id dans l’url, mais également sous forme de lien (quel titre ? quelle accroche ?) dans l’arborescence ou la page du niveau précédent.

    Au plan technique, je recommande l’utilisation de code orienté objet (voir mon introduction à la POO).

    Les questions à régler sont nombreuses, surtout si on veut éviter à 100% l’insertion de code HTML via le CMS, mais ce système est flexible et puissant.

  4. Nicolas dit :

    @damien, vous pistez a une heure bien tardive -)

  5. Florian dit :

    Merci pour cet article. Je me balade sur le web depuis quelque jour pour comprendre pourquoi je bloque avec mes include ba j’ai compris.

    Du coup on repart au taf pour apprendre et créer une belle structure propre =D

  6. yakou dit :

    salam,
    merci pour cet article, j’ai trouvé tout ce que je voulais savoir.

  7. yakou dit :

    le premier paragraphe est dupliquer dans l’article.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *