Bonjour,
Voici un petit retour d'expérience d'un utilisateur de Spip. Je ne
suis pas développeur, mais j'utilise Spip depuis sa création, avant
même sa publication en fait. J'ai du faire une quarantaine de site
avec, dont quelques-uns sont particulièrement gros. C'est le cas du
site du Réseau Voltaire (www.voltairenet.org) sur lequel je vous donne
un petit retour d'expérience.
Ce site utilise Spip depuis 2002.
* * *
SPIP SUPPORTE LA CHARGE D'UN GROS SITE
Le site contient aujoud'hui près de 50 000 articles publiés dans 10
langues, dont environ 14 000 pour chacune des trois langues suivantes
: français, espagnol et arabe. Il accueillais récemment, d'après
Webalizer, un peu plus de 1 400 000 visites mensuelles (entre 45 000
et 50 000 par jour).
J'ai entendu dire par des webmasters qui hésitaient entre Drupal et
Spip que ce dernier n'était pas conçu pour de gros sites. C'est n'est
évidemment pas vrai. Voltairenet.org est assez gros et fonctionne
plutôt bien (sur serveur dédié).
Le serveur que nous utilisons est cependant actuellement saturé, d'où
de grosses lenteurs. Nous le transférons en ce moment sur un nouveau
serveur. Pour limiter la lourdeur, nous avons malheureusement dû
désactiver les statistiques de Spip. A noter que la consultation est
assez bien répartie sur les 24 heures du fait des provenances
différentes des visiteurs. Le site est en effet consulté depuis
plusieurs continents, en particulier l'Amérique (environ 4 à 7 heures
de moins qu'à Paris) et non seulement depuis la France ou l'Europe. Il
est aussi vu dans des pays où le vendredi est chômé et non le
dimanche. Cela fait qu'il n'y a pas de gros pic de consultation et
donc pas de forte charge à un moment particulier de la semaine ou de
la journée.
* * *
LE TRAVAIL QUOTIDIEN DANS L'ESPACE PRIVE
Au fur et à mesure des versions, le travail quotidien dans l'interface
privée est devenu plus fluide et facile. Je crois qu'il y a eu deux
changements qui ont été importants pour cela. D'une part, le menu
déroulant affichant la liste de toutes les rubriques qui permet de
naviguer dans le site depuis n'importe quelle page sans avoir besoin
de nombreux clics (sur une rubrique, un sous-rubrique, etc.). D'autre
part tous les ajouts d'ajax permettant de ne pas recharger une page
pour mettre à jour un élément. A noter néanmoins que les pages sont
lourdes à charger et qu'on ne peut pas aller vite ou ouvrir trop de
fenêtres à la fois. Pour travailler spécialement sur un article, c'est
très bien, pour mettre en ligne plusieurs articles à la fois, c'est
beaucoup moins pratique.
Un regret cependant : il y a beaucoup d'administrateurs sur notre site
et ils doivent associer des auteurs aux articles qu'ils publient.
Erreur très courante, créer un nouvel auteur sans vérifier qu'il
existe déjà. On se retrouve alors avec un auteur entré plusieurs fois
et avec plusieurs pages persos affichant à chaque fois un seul article
(alors qu'il devrait y avoir une seule page pour cette auteur avec
tous ses articles). C'est un vrai casse-tête lorsqu'il faut supprimer
les auteurs en doublons et associer les articles à un seul auteur. Une
fonction simple à ajouter et qui serait très pratique : lors de la
création d'un article, obliger à chercher parmi les auteurs existants
avant de proposer le bouton "Créer un nouvel auteur" (s'il n'y a pas
de résultat ou si le résultat de la recherche n'est pas satisfaisant -
car il est parfois très éloigné de la demande...).
Sur ce site, les articles dans chaque langue sont gérés par un
administrateur qui va valider ceux proposés à la publication. Or la
page "A suivre" affiche tous les articles quelle que soit la langue.
S'il était possible de n'afficher les articles proposés à la
publication que dans une langue, ce serait bien pratique. Cet usage
concerne, je crois, tous les gros sites multilingue. Sur un petit site
multilingue, un administrateur/webmaster gère souvent toutes les
langues, mais dès que le site se développe un peu ce n'est plus le
cas.
* * *
LE CHAMP <MULTI> ET LES FICHIERS DE LANGUES
Le site est donc multilingue. Nous utilisons le principe d'une
(sous-)rubrique par langue (et non des articles dans plusieurs langues
dans une même rubrique). Lorsque le multilinguisme est apparu sur
Spip, cela nous a permis de très gros développement. Auparavant, nous
avions installé plusieurs sites différentes, avec des noms de domaines
différents et des bases de données différentes pour chaque langue.
C'était évidemment terriblement lourd et impossible à gérer sur le
long terme. En 2005, nous avons fusionné les différentes bases de
données pour mettre en place un seul site multilingue (en UTF-8 car
nous avons des langues comme l'arabe et le russe).
Il y a deux éléments importants que nous utilisons et qui ne sont, à
mon sens, pas vraiment aboutis pour le multilinguisme.
- D'une part, les champs <multi> qui nous servent pour tous les
éléments transversaux ne pouvant pas être traduits à part (les
mots-clés, les auteurs et les rubriques).
- D'autre part, les fichiers de langues (local_fr.php...).
Le champ <multi> est vraiment indispensable pour un site multilingue.
Mais il n'est pas conçu selon la logique de Spip, c'est-à-dire quelque
chose de puissant mais simple d'utilisation pour des non
informaticiens. Cela ressemble à un hack et n'est pas facile à
utiliser pour les journalistes qui travaillent régulièrement dans
l'espace privé. Pour eux, il serait beaucoup plus simple d'avoir une
case avec le champ dans la langue dont ils s'occupent.
Le fichier de langues est aussi particulièrement important pour un
site multilingue. Mais sa mise à jour et ses traductions ne sont pas
réalisables par des non-informaticiens. Lorsque ce fichier ne contient
que quelques lignes, ce n'est pas bien grave. Mais dès qu'il commence
à être un peu long, cela devient problématique. Il existe bien l'outil
Trad-lang (pas évident à installer). Mais rien n'est prévu dans Spip
(ni même en plugin). Pourquoi ne pas intégrer cet outil dans Spip ? Il
serait mille fois plus pratique de mettre à jour les fichiers de
langues depuis la configuration du site dans l'espace privé.
D'après mon expérience de site multilingue, ces deux éléments ne sont
pas aboutis. Je regarde avec plaisir plein les nouvelles
fonctionnalités de Spip, mais je regrette que le multilinguisme ne
soit pas totalement finalisé.
* * *
LES ADMINISTRATEURS RESTREINTS
Le site utilise aussi de manière extensive les administrateurs
restreints. Sans cette fonction, il ne serait pas ce qu'il est. Son
apparition dans Spip nous a en effet permis de travailler avec des
équipes différentes dans plusieurs parties du monde. Le site
fonctionne sous la forme d'un réseau de presse où chaque publication
dispose d'une rubrique/secteur qu'elle gère elle-même. Il était donc
indispensable qu'elle ne puisse pas intervenir dans les autres
publications, comme cela aurait été le cas lorsqu'il n'y avait pas le
statut d'admin restreint.
Il y a aujourd'hui 26 publications (journaux ou agences de presse) sur
le site, dont environ la moitié est très active. Le statut
d'admin-restreint est donc pour nous particulièrement important (mille
mercis à la personne qui l'a introduit !). Je crois qu'il a été
envisagé un temps de le supprimer. Ce qui aurait été pour nous une
grave erreur. C'est au contraire une chose qu'il faudrait à mon sens
développer. Par défaut, les admins restreint de Spip ne peuvent
notamment pas créer d'auteur. Ce qui est un manque pour l'usage
quotidien d'un journal (dans notre cas, l'administrateur d'une
publication ne peut pas, par défaut, mettre les auteurs de sa
publication). Il existe un plugin permettant de gérer plus finement
les accès des admins/auteurs. Mais je regrette cependant que cela ne
soit pas pris en compte dans la version de base.
Il me semble que la question d'une gestion plus fine des droits ne se
pose pas seulement dans le cadre de site éditoriaux classiques comme
le nôtre, mais aussi de sites "web 2.0" avec une participation plus
active des visiteurs. Je suppose que si Spip veut s'ouvrir à un usage
plus participatif "web 2.0", il faudra bien intégrer cette question
dans la base même du logiciel.
* * *
PLUSIEURS SITES SUR UNE MÊME BASE DE DONNÉES
La base de données de Spip est utilisée par le site Voltairenet.org et
des secteurs sont affichés sur les sites de différentes publications.
Par exemple, l'agence Altercom a sa rubrique dans le site mutualisé et
son propre site (http://www.voltairenet.org/rubrique120081.html et
http://www.altercom.org) ou encore la UTPBA
(http://www.voltairenet.org/rubrique120448.html et
http://www.utpba.net).
On a mis cela en place assez rapidement (en 2004). Ce n'était pas
documenté, mais finalement très simple à faire (il suffisait de placer
les fichiers de Spip en FTP et de mettre le même fichier de connexion
à la base de données pour tous les sites, sans faire d'installation
particulière - il y avait aussi quelques réglages qui ont été
simplifiés par la suite pour les chemins des documents et des images
placés dans le dossier IMG du site central). Pour les mises à jours
c'est un peu de temps, évidemment. J'ai suivis l'annonce "une seule
installation de Spip pour plusieurs sites". Mais cela est resté au
stade de l'annonce et la contribution, dans Spip-contrib, a plus
embrouillé que facilité les choses. J'utilise donc toujours plusieurs
installations de Spip.
* * *
RETOUR SUR UN AUTRE SITE PLUS AXÉ SUR LA PARTICIPATION DES VISITEURS
Je travaille actuellement sur un autre site qui n'a plus seulement un
mode de fonctionnement éditorial mais fait intervenir les visiteurs
(genre "web 2.0"). Dans ce cadre, je rencontre vite les limites de
Spip. Dans l'absolu, les éléments sont là pour faire intervenir les
visiteurs. Dans la pratique, on n'évite pas les plugins, fonctions,
hacks et autres bidouilles.
Les ennuis commencent avec les formulaires d'inscriptions/connexion.
Ils fonctionnent bien, mais ne sont pas conçus pour les différents
usages qui se présentent sur les nouveaux sites. Le principe de
l'inscription en recevant le mot de passe par email est éloigné des
habitudes actuelles. Il n'est pas possible de changer simplement son
mot de passe (il faut cliquer sur "Mot de passe oublié ?" et l'on
reçoit un email indiquant une adresse où le faire). Rien n'est prévu
par défaut pour modifier ses informations personnelles (au minimum son
pseudo, son login et donc son mot de passe). Et il n'est pas possible
d'ajouter des informations plus complètes sans passer par un plugin.
C'est pourtant un cas qui va se présenter de plus en plus.
Le formulaire de connexion se met automatiquement dans le forum si
l'on met le formulaire pour rédiger un message sur la page. Or on peut
avoir d'autres éléments -comme le plugin notation- qui nécessitent
aussi une identification. On a alors besoin de pouvoir jouer plus
finement avec ce formulaire de connexion (l'afficher sous forme de
thickbox par exemple ou bien avec un petit déplié en jQuery). On
pourrait vouloir afficher côte à côte le formulaire de connexion et
celui d'inscription. Tout cela, même si c'est réalisable, n'est pas
évident à faire en l'état.
Je me réjouis de voir se préparer une version 2.0 de Spip. Mais je
regrette un peu qu'elle n'intègre pas la problématique des sites "web
2.0" autour de la participation des visiteurs.
* * *
DEUX ATOUTS DE SPIP PAS TOUJOURS PERÇUS
Je pense que, comme la plupart des utilisateurs, j'apprécie
particulièrement la logique de Spip qui est un outil très puissant ET
très facile d'utilisation pour les non informaticiens. Il n'y a pas de
"champs", d'"item" et autre jargon rebutant, mais des mots simples
comme "article" ou "rubrique". Chaque élément est placé logiquement,
encastré les uns dans les autres. Par exemple, on ne doit pas aller
dans une partie du site pour mettre des documents puis sélectionner
les articles auxquels ils sont liés. Graphiquement, ergonomiquement,
l'espace privé est facile d'accès. C'est ce qui fait la force de Spip.
(Mais pas toujours de ses plugins.)
Mais il y a aussi deux choses qui me paraissent importantes : le
travail autour de la typographie et les possibilités offertes par les
filtres graphiques.
L'application automatique de quelques règles typographiques a été mise
en place dès la création de Spip et c'est vraiment une bonne chose.
Cela participe à la qualité des sites que l'on peut réaliser avec
Spip. Il serait encore possible de développer ces filtres qui
s'appliquent tant au texte qu'aux dates (par exemple, je réalise
actuellement sur un agenda où je n'affiche pas "09:00" mais "9h" pour
un public d'humains et non de machines). J'ai vu le plugin d'Arnaud
pour faire des césures automatiques. Pour les graphistes qui viennent
du papier et regrettent certaines limites du web, c'est absolument
génial ! Au lieu d'extraire du noyau ce type de filtres, les intégrer
permettrait de mettre l'accent sur la qualité typographique de Spip et
serait vraiment un atout.
Un autre atout de Spip : les filtres graphiques. Avec les filtres
d'images-typos, les graphistes peuvent enfin mettre choisir la
typographie (au minimum pour les titres). Ils peuvent aussi
homogénéiser les images entrées par les nombreux auteurs et donner du
cachet à leur site. Cela permet d'élever Spip bien au dessus de tous
les logiciels conçus dans le seul univers informatique. Allier la
puissance du logiciel avec sa capacité à faire des sites graphiquement
époustouflants est une chose très importante et, je crois, à
valoriser.
A mes yeux, la qualité de Spip dans les domaines typographique et
graphique en fait un outil hors du commun.
* * *
Voilà... Donc mon retour d'expérience...
Merci à vous !
Raphaël
