MKLFACTORY

Switch to desktop Register Login

Les solutions disponibles

Un certain nombre de problèmatiques sont donc à analyser avant de se lancer dans le projet. Il faut anticiper, notamment sur les futures technologies à employer pour arriver au résultat escompté.

4.6.1. Choix de l’hébergement

Le choix de l’hébergement fut un point important de la période d’anticipation à la création du site web. On savait pertinemment que l’on devait tenir compte de certains points techniques avant de se lancer dans l’investissement d’un hébergement.

Le site web sera géré via un CMS (Content Management System) ou SGM (Système de Gestion de Contenu). Nous avons donc besoin de plusieurs types de technologies web pour faire tourner la base de notre futur projet.

Il nous fallait un espace disque suffisant, une bande passante correcte, un nom de domaine inclus, Php 4 ou plus, l’accès aux .htaccess, MySQL 4 ou plus, accès ftp clair et surtout, compatibilité maxi- mum avec les CMS les plus performants sur le marché.

D6

Nous avons donc opté pour un Busines Pro chez OVH. Toutes les conditions requises sont remplies. Le rapport qualité/prix est intéressant. Nous disposons de 3 Go pour les fichiers physiques, d’un nom de domaine inclus dans le pack, de Php 4 ou 5 et de MySQL 5. Il est clairement indiqué qu’il est compatible avec les CMS le plus courant et performant du marché.

L’ offre de OVH Business Pro est un hébergement mutualisé très évolutif.

4.6.2. Choix du CMS

Avant de se lancer dans la course à l’installation, quelques CMS ont été analysés.

Plusieurs conditions doivent être réunies afin de respecter au mieux l’idée générale du projet. La première chose à garder à l’esprit est le fait qu’il faut un outil facilement utilisable et respecter un principe : favoriser la simplicité, aussi bien dans l’action que dans la façon de penser à l’intérieur du système. Il ne faut pas oublier que l’on a besoin d’un outil complet, certes, mais simple et direct, sans manœuvres longues à suivre ou difficile à appréhender. L’intérêt est aussi de ne pas toucher au code. Le Webmaster ne doit toucher aux informations sur le serveur ou aux fichiers que dans une situation extrême ; par exemple, s’il y avait un problème impossible à régler autrement; il ne doit pas toucher au code puisqu’il faut un maximum de simplicité et un minimum de techniques (pro- grammation notamment) voire pas du tout pour le Webmaster. Mais en aucun cas, il ne doit gérer « à la main « des actions triviales comme l’ajout d’une rubrique ou la mise en page d’un article. Il doit connaître le vocabulaire technique de son environnement, certes, mais ne doit pas accéder et modi- fier le code des scripts qui font tourner le site web.

Ensuite une certaine gestion hiérarchique des futurs utilisateurs doit être possible afin de gérer aux mieux les groupes de rédacteurs qui fourniront un type de contenus et alimenteront certaines rubri- ques spécifiques.

SPIP

Au vu de quelques expériences, une petite analyse de SPIP m’a permi de constater tout de suite qu’il ne pouvait pas convenir. En effet, pour mettre à jour les contenus des menus, il faut modifier les « squelettes « SPIP en passant par une syntaxe HTML estampillée SPIP.

Or, nous désirons avoir un site éditable facilement, sans toucher par une édition du code pour faire des actions basiques. L’accès via un panel d’administration est intéressant mais il nous faut un panel qui travaille aussi sur l’ajout automatique d’éléments type « menu » dans le site.

Le problème sera donc la mise à jour des éléments du site. Si une rubrique doit s’ajouter un jour, il faudra toucher au code et c’est un principe que l’on aimerait éviter.

De plus, le site public de base est réellement faible et fade. Et pour commencer à travailler correcte- ment, il faudrait redéfinir une structure HTML et inclure les balises SPIP correctes avant de travailler. Un point fort, cependant, est la communauté SPIP qui est importante et le site officiel offre des sour- ces d’aide qui ne sont pas négligeables.

Drupal

Afin de nous documenter sur Drupal, nous avons visité le site de démonstration. Suite à cela, il a été décidé que l’interface était un peu trop obscure : peu intuitive, la hiérarchie n’est pas au mieux, on a l’impression que c’est brouillon et la prise en main n’est pas immédiate. L’interface entre le panel et le site public est vraiment très floue. Difficile de s’y trouver sans une certaine expérience et une bonne analyse, ce qui serait coûteux en temps.

Faute de temps et d’expérience, il faut mieux éviter de s’enfoncer vers un CMS qui prendrait trop en durée de compréhension.

D7

Joomla

Suite à quelques expériences avec Joomla, il paraît le plus efficace. En effet, l’interface administra- teur, bien qu’impressionnante à première vue, est très complète. Beaucoup d’éléments peuvent être définis via le panel : cela passe de la gestion des utilisateurs du site à la définition du design global de celui-ci en passant par l’édition des menus, l’ajout de fonctionnalités, la gestion du contenu, etc.

L’aspect modulaire de ce Système de Gestion de Contenu est particulièrement intéressant. Contrai- rement à d’autres CMS, son aspect modulaire est complet. On peut greffer un grand nombre de composants et modules existants et variés afin d’ajouter un certain style de fonctions pour le site. Il y a de fortes chances que l’on puisse trouver des modules qui apporteraient des fonctions similaires à nos exigences ou du moins, qui s’en approchent au mieux.

L’éditeur de texte par défaut de Joomla est déjà assez évolué. Plus que celui de Spip par exemple. C’est un élément qui peut aider. De plus, d’autres éditeurs pourraient être ajoutés.
Le site public de base est plutôt bien. Il n’y a pas à toucher à la structure pour voir tout de suite
les résultats puisqu’il intègre directement tous les éléments et un kit graphique plutôt fonctionnel et agréable. Une fois installé, on peut directement travailler et mettre à disposition son contenu.

La communauté Joomla est très étendue, cela veut dire que l’on pourra trouver des informations dans le cadre d’un ajout de fonctionnalité ou s’il y a un problème avec le système.

4.6.3. Choix final

Suite à divers tests et expériences, le choix s’est fixé sur l’installation du CMS Joomla 1.0.15.

On aurait pu prendre la version 1.5.3., plus récente, qui est censée être stable mais la rétrocom- patibilité avec les modules 1.0.x n’est pas toujours respectée. Ainsi, en utilisant la version 1.0.15, l’on maximise la facilité d’actions, et minimise les erreurs et éventuelles éditions de code qui feront perdre du temps. On accède à un grand nombre d’actions disponibles immédiatement.

De plus, avec Joomla, on peut travailler tout de suite post-installation sans définir ou redéfinir une structure. Cela peut être fait à la fin, une fois que tout est au point techniquement, ce qui paraît logi- que.

Mis à jour le mardi 10 janvier 2012 23:29

Affichages : 1131

Design © MKLFACTORY All rights reserved.

Top Desktop version