Le choix de SPIP, caractéristiques et contraintes

Introduction Le choix de SPIP : l’environnement humain Le choix de SPIP : un produit intégré Les aspects à valoriser Les contraintes à respecter

Au-delà de son environnement humain, le choix du logiciel SPIP pour cette étude tient évidemment aux caractéristiques du système lui-même. Pour expliquer ces caractéristiques et justifier ce choix, le plus simple consiste à comparer SPIP à d’autres outils de publication en ligne. Nous nous limiterons ici aux descriptions de chaque produit permettant de faire ressortir la philosophie de SPIP (une étude comparative exhaustive des différents produits n’est évidemment pas notre propos ici, les lecteurs intéressés pourront sur ce sujet consulter les archives du site Boomtchak, portail francophone consacré aux différents systèmes de publication).

phpNuke et ses clones

Le système le plus proche de SPIP est phpNuke (phpNuke étant à l’origine d’une vaste famille de produits aux fonctions très similaires, proposant une interface et des concepts quasiment identiques pour l’utilisateur final).

interface de gestion

De nombreuses différences fondamentales séparent phpNuke et SPIP, les deux points sur lesquels nous souhaitons attirer l’attention sont : le niveau de modularité de phpNuke par rapport à l’aspect très intégré de SPIP, et les fonctionnalités collaboratives de SPIP.

 Modularité / Intégration

Dans sa programmation même, phpNuke repose sur le principe de modularité : la possibilité de créer des briques logicielles qui enrichissent le système. Chaque fonctionnalité de phpNuke est ainsi une brique logicielle ajoutée, créée par l’équipe originelle du logiciel ou bien par des développeurs indépendants. Cette manière de programmer, très appréciée des informaticiens, transparaît directement dans l’interface de gestion du site : les éléments de gestion sont très nettement différenciés, chaque module proposant quasiment son interface, indépendamment des autres modules. En effet, chaque module doit pouvoir fonctionnemer de manière indépendante, puisqu’il ne peut dépendre d’un autre module (chaque webmestre peut installer ou non chaque module ; de fait, chaque module doit être relativement autonome et ne pas dépendre de la présence d’une autre brique que le webmestre pourrait ne pas avoir installée sur son propre site).

Cette approche présente des avantages énormes : la simplicité du développement de nouvelles fonctionnalités, y compris par d’autres développeurs que les créateurs du système lui-même. En pratique, cela conduit à un dynamisme impressionnant des développements, avec l’apparition régulière de nouveaux modules, et/ou d’améliorations de certaines fonctionnalités.

En revanche, cela introduit une forte disparité des fonctionnalités entre deux sites utilisant phpNuke, chaque site n’utilisant pas forcément les mêmes modules. Pour les personnes participant à plusieurs sites sous phpNuke, cela peut poser des difficultés d’adaptation (perte des repères et des habitudes, alors que les outils sont apparemment très semblables).

Cela pose de plus des difficultés de cohérence interne, certaines fonctionnalités pouvant sembler parfois incongrues dans le cadre d’un système de publication. Cela pose également des problèmes de qualité générale, certains modules étant remarquablement conçus, d’autres moins réussis ou pertinents (non seulement au niveau de la qualité informatique, mais surtout de l’expérience de l’utilisateur).

Dans le cadre de notre étude, la plus grosse limitation de cette méthode est la quasi impossibilité de concevoir une interface globale cohérente. Chaque module étant indépendant, il n’est pas possible de réfléchir à une hiérarchisation globable des fonctionnalités au travers de l’interface, ni de prévoir des liens logiques forts entres les fonctionnalités (puisqu’elles sont autonomes).

interface publique

À l’inverse, SPIP n’a pas été conçu pour être modulaire. Il s’agit d’un produit intégré : chaque fonctionnalité est reliée, non seulement au niveau du code, mais surtout au niveau de l’ergonomie et de l’interface, aux autres fonctions du système.

L’inconvénient est, très exactement, l’absence des avantages de la modularité de phpNuke : lourdeur de développement, relative difficulté à « ajouter » certaines fonctionnalités tant qu’on ne maîtrise pas l’ensemble de la logique du programme...

Mais les avantages sont, en terme d’ergonomie et d’interface, énormes. Dès l’origine, SPIP a ainsi pu imposer une logique graphique renvoyant à la logique éditoriale classique (type comité de rédaction d’une magazine), logique qui facilite énormément l’implication des utilisateurs ne maîtrisant pas l’informatique (la logique éditoriale est, de manière générale, beaucoup plus connue du grand public que le processus « informatique » de création d’un site Web). De plus, il est ainsi possible de présenter de manière très forte la cohérence structurelle du système : une hiérarchie de rubriques, des articles et des brèves à l’intérieur de ces rubriques, des mots-clés permettant une navigation transversale entre ces éléments, etc. ; cette logique peut être exposée à l’utilisateur débutant de manière très visuelle, sans apprentissage préalable. Dans cette optique, une interface intégrée autorise une meilleure hiérarchisation des fonctionnalités par le travail graphique (mettre en avant les fonctions importantes et/ou les plus souvent utilisées).

Ainsi, le choix d’une interface intégrée (SPIP) autorise une réelle réflexion sur l’ergonomie et l’interface, y compris dans le cadre d’une refonte globale du produit. À l’inverse, un logiciel absolument modulaire (phpNuke) limite les possibilités de réflexion globale, chaque module restant plus ou moins indépendant ; et la cohérence structurelle du produit est quasiment impossible à faire ressortir au travers de l’ergonomie.

 Fonctions collaboratives

phpNuke propose peu de fonctions de discussion et de travail collaboratif dans l’espace privé. L’essentiel des discussions ayant lieu directement sur le site public, une fois l’information présentée sur le site public.

À l’inverse, SPIP a été conçu dès l’origine pour réaliser un travail collaboratif en amont de la publication. Avant même la publication, des forums permettent de travailler collectivement sur les documents proposés. Cela soit entre deux ou trois participants qui travaillent ensemble sur un même article, soit entre tous les participants au site, invités à commenter chaque document proposé à la publication.

Cet aspect justifie également mon choix de travailler sur l’espace privé de SPIP, de ce point de vue plus riche et plus cohérent.

Les blogs

Les systèmes de blogs sont plus récents, et proposent une approche très différente de la publication. Cette approche introduit, dans l’univers des outils de publication (CMS), l’aspect très simple et ludique des premiers temps du Web, notamment dans les homepages (pages personnelles).

La mise en ligne est ici grandement simplifiée et accélérée. La structure de site proposée est rudimentaire, les interfaces très accessibles pour le grand public.

À l’inverse, SPIP propose une mise en scène du processus de publication (rédaction, proposition, discussion/négociation éditoriale, validation éventuelle) beaucoup plus lourd. On peut parler ici, de dramatisation extrême de la publication. L’interface plus lourde (car gérant beaucoup plus d’éléments) caractérise aussi un tel produit.

Les blogs sont, de plus, essentiellement destinés à la réalisation d’un site personnel, les fonctions de travail collaboratif y sont donc très peu développées (voire totalement inexistantes).

Dans le cadre de mon étude, la richesse fonctionnelle et la présence de fonctions de collaboration de SPIP représentent une difficulté nettement plus intéressante. D’où, une fois de plus, le choix de cet outil.

Les Wiki

Les Wiki proposent eux aussi une méthode de publication et de gestion du site radicalement différente : le contenu est créé et modifié directement sur le site public. Chaque visiteur (ou seulement certains visiteurs inscrits) peut modifier le site directement au travers d’une interface très simple et, surtout, immédiate (les modifications apparaissent immédiatement).

Le dynamisme de tels sites est impressionnant. Citons notamment l’encyclopédie Wikipedia, totalement ouverte (enrichie directement par les usagers du Web) et multilingue, devenue en quelques mois seulement une énorme source documentaire.

J’ai préféré travailler sur SPIP, puisque la richesse (ou la « lourdeur ») de l’interface privée représente une difficulté plus intéressante pour mon projet. De plus, nous verrons plus loin qu’il n’est pas impossible d’ajouter à SPIP des fonctionnalités de Wiki, sans pour autant perdre ses caractéristiques premières. Élément qui présente, à son tour, de nouvelles difficultés en terme d’ergonomie et de cohérence du produit.

Conclusion

Les éléments propres à SPIP qui justifient mon choix sont donc :

— l’aspect réellement intégré du produit, qui autorise un réel travail d’ergonomie dans le cadre d’un produit ayant déjà sa cohérence propre ;

— la présence d’outils de travail collaboratif, qui rend à la fois plus difficile et plus intéressant l’étude ergonomique ;

— la possibilité d’ajouter certaines fonctionnalités propres aux autres outils (Wiki par exemple) dans ce produit, ce qui pose encore des difficultés intéressantes en terme de cohérence et d’ergonomie.