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 ?

Laisser un commentaire

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