Deux mises en garde:
1) ceci n'est pas un mode d'emploi

2) ce billet sera mis régulièrement à jour au fur (généralement entre parenthèse) et à mesure de nos investigations et des commentaires reçus. Mais l'essentiel à tout de même été écrit en 2007 !

1. Mise en place du CMS sur le serveur

Poser le CMS Drupal : 5 minutes. Poser le CMS Spip: 7 minutes. On rigole, mais à peine. Poser un CMS brut et presque bête, c'est rapide, après seulement les choses se corsent. Force est pourtant de constater que cela va un poil plus vite avec Drupal. Moins de masques de saisie, des codes à fournir plus instinctifs et surtout, sitôt validé, on entre sur un site et non sur une administration de site.

(ajoutons que ce site vocables.co,, par souci d'expérience, a été posé sans code informatique via drupal. Celui qui commencerait ainsi devrait comprendre la logique menu-page de drupal et la logique des blocs, c'est tout. Avec Spip, il devrait ajouter à son expertise une initiation aux boucles de Spip, ce qui est plus audacieux. Par contre, une fois cela acquis, ce même nouveau venu pourra plus facilement customiser son spip. Bref, chronoliquement les difficultés ne se situent pas au même moment.)

2. Découverte de l'administration

Or justement, l'administration de Spip en décourage plus d'un. Il y a là un paradoxe: l'univers Spip est sympa (alors que celui de Drupal est plutôt anonyme), et ceux qui utilisent Spip régulièrement le trouvent tout à fait convivial. Il y a pourtant à redire. L'interface de l'admin Spip, pour sympathique qu'elle est, impose une conception des choses qui ne se comprend pas spontanément. Des domaines administratifs (et très sérieux !) se placent presque au même niveau que l'édition des pages. Le simple éditeur se retrouve confronté à de nombreuses entrées qui ne le concerneront jamais. Sur l'ensemble des personnes avec qui nous travaillons, nous pouvons dire qu'environ 20% ont compris instantanément, 50% après une formation et s'en estiment satisfait, 25% ont compris mais continuent de "bloquer" régulièrement, et 10% ne semblent pas vraiment s'y faire. Avouons que ces 10% sont justement ceux-là qui peuvent se permettre d'abandonner longtemps leur site. L'utilisation régulière de Spip règle généralement tous les problèmes.

Pourtant, tout nous semble plus simple avec Drupal. L'administration semble plus banale, voire morne, mais elle est modulable. Chacun peut ainsi se construire son petit menu à soi pour ne plus avoir à retourner dans la grande admin. Et pour nous cela fait toute la différence. Ainsi ce site est-il géré quotidiennement avec une menu "admin" simplifié: "ajouter une page", "ajouter un post blog", "voir mon compte", "voir les menus", "retour grande admin".

3. Editer une page

Avantage à Drupal, qui permet de gérer ses pages en restant dans le site côté public, tandis que Spip renvoie toujours au site d'administration, via son volet /ecrire. (ok, Spip dispose d'un plugin à charger pour cela: "crayons"). Autre avantage, l'intégration et la modification d'images dans la page se fait directement (via le module - voir plus bas - tinymce) alors que chez Spip on circule entre deux vues de la page, et on ne peut pas modifier la taile des images d'un coup de souris. Pour finir le système de "révision" sur Drupal va permettre de revenir à une version précédente d'une page si on n'aime plus la dernière. (chez Spip révision exisite aussi, bien caché dans configuration/fonctions avancées) et un jeu de couleur permet de voir quelles phrases ont changé).

4. Modifier le template de base

Chacun de ces deux CMS est livré avec un template de base, appelé "squelettes" chez Spip, "thèmes" chez Drupal. Là encore (toujours en pensant à un CMS "pour les nuls" sans le développement sur mesure qu'une équipe comme vocables.com permettrait...sic), on préfèrera la solution Drupal, pour deux raisons essentielles: le thème Drupal de base a déjà une allure de site alors que celui de Spip ne ressemble franchement pas à grand chose (on ne le voit d'ailleurs presque jamais en usage).

Mieux, quand il s'agit de changer pour un autre thème, on découvre que notre site Drupal dispose de 5 autres templates par défaut (changeable en deux clics), et qu'une page Web de drupal.org recense une foultitude de thèmes. Chez Spip, soit on écrase tous ses squelettes avec une autre volée de squelettes, soit on utilise le plugin qui permet de faire à l'identique que drupal). Il n'y a pas de page Web officielle pour rassembler les templates de la communauté, mais des dizaines de liens éparpillés sur les forums et dans le site Spip, sans grande possibilité de les évaluer facilement (en un mot: testez-les et vous verrez). Petit bémol quand même pour Drupal: ses thèmes sont essentiellement à trois colonnes, et ressemblent fort à des blogs lors de l'installation. A chacun de les personnaliser, mais cela est vaste puisque Drupal offre des "blocs" qu'on pourra placer à divers endroits (et ainsi multiplier les menus au besoin, alors que le spip de base n'offre qu'un unique menu).

5. Ajouter des fonctionnalités

Nous entendons par là ces petites bêtes qui boostent votre CMS, "modules" chez Drupal, "plugins" chez Spip. On apprécie la page Web dédiée à ce sujet sur drupal.org, les commentaires et les reviews. Le message est beaucoup plus succint chez Spip, et il faut souvent circuler dans les forums au préalable. A installer, les modules de l'un et de l'autre sont aussi simples (avouons quand même que plusieurs modules Spip suscitent moult discussions dans des forums où l'on recherche le bon module de la bonne version Spip...).

6. Etre trouvé par les moteurs de recherche

Pour Drupal, nous avons identifié le module "title" et le module "metatags" qui vont facilement donner la mains aux éditeurs pour qu'ils puissent sans code ajouter des mots clés, une description et une title à la page. Avec Spip, des pages non officielles, comme celle-ci, indiquent quel code informatique introduire dans ses squelettes. Pas trop compliqué, mais on sort là du cadre de cet article qui comparait l'usage des deux CMS par de non informaticiens.

7. Gestion des droits ou "rôles"

Un premier avantage pour Spip qui par défaut offre un rôle administrateur (ou rédac chef) et un rôle rédacteur. Quand la rédacteur enregistre son article, l'administrateur en est informé et peut le relire puis le publier et/ou envoyer un message à son auteur. On apprécie aussi de pouvoir créer des administrateurs limités à telle ou telle rubrique(s).

Avec Drupal, on ne va pas pouvoir définir ainsi une rubrique , mais limiter les autorisations à des types de fichiers (pages, formulaires, stories,), ce qui peut vite trouver sa limite, selon les projets. Par contre, on peut liste les fichiers qu'un auteur a e droit de modifier (mais fastidieux dans une rédaction bien sûr). Et il manque le processus de validation à la Spip, mais il existe un module "workflow" qui devrait nous intéresser (à suivre).

Pour finir avec les rôles, la souplesse de Drupal va permettre de définir des rôles très très spécifiques, alors que Spip, sauf erreur (merci aux commentateurs) nous limitera aux trois droits définis plus haut.

A suivre dès que nos clients nous en laisseront le temps!

Lire ce billet >