SPIP est un système de gestion de contenu très utilisé par la communauté francophone. (le Monde Diplomatique, Reporters Sans Frontières, le site du gouvernement sur les retraites …).

Je l’utilise depuis plusieurs années, et j’en ai pas mal fait le tour. Voici ses points forts et ses faiblesses. Ces commentaires sont tout à fait personnels, et je suis plutôt à chercher la petite bête. En aucun cas l’idée est de faire du tort à SPIP, qui est un outil magnifique. C’est juste que quelques rigiditées me fatiguent et me font souvent perdre du temps lors de projets. C’est article est donc une façon pour moi de faire le point sur ce qui me gène dans SPIP pour mieux comprendre et analyser ses points faibles.

Forces, avantages de spip

  • assez simple d’utilisation et en Français
  • documentation en Français très bonne
  • objets assez pertinents : spip manipule des articles, des rubriques, des mots clés. Ces différents objets sont manipulés par des auteurs.
  • gratuit et open source
  • fichier mes_fonctions.php3 qui permet d’ajouter dans spip sa propre boite à outils de fonctions.

Faiblesses, inconvénients de spip

  • l’habillage d’un site en spip est long et compliqué : nécessité d’apprendre le language de boucles de spip pour créer ses propres squelettes. Le système de boucle nous fait en arriver à des trucs assez ridicules (besoin de créer une boucle pour afficher la moindre variable, besoin souvent d’avoir deux boucles imbriquées pour afficher une simple liste …)
  • pleins de fichiers à la racine du site (une vrai avalanche de inc-bidule.php3, chaque type de page doit aussi avoir un fichier php appelant, puis son fichier squelette associé. le fichier php appelant est assez inutile car il spécifie juste le squelette et le TTL(Time To Live). C’est agaçant d’avoir un tel bordel à la racine de son site.
  • raideur du système : parfois, un critère de selection n’a pas été prévu dans tel ou tel type de boucle. Donc pas possible de l’utiliser, c’est embettant.
  • code difficile à comprendre : j’ai un peu de mal quant à plonger dans le code de spip chaque fois que je veux le personaliser. Pourtant, il faut tout de même admettre qu’il est TRES bien commenté.
  • au final, c’est difficile de modifier la mécanique : ajouter une base de données (contenant un autre type d’objet) dans spip n’est pas très simple, et prend du temps. Idem, si on veut ajouter un champ à un objet existant (ajouter les coordonnées géographiques aux articles). C’est pas impossible et il y a souvent des astuces qui vont permettre d’atteindre notre but, mais ça va bouffer du temps, et il va falloir se presser le citron pour trouver le bon hack.
  • le workflow est rigide lui aussi.
  • le système de cache est un peu idiot : via TTL alors qu’une gestion “sur modif” est préférable de mon point de vue. Obligé de se battre avec le cache de spip quand on modifie du contenu ou bien les squelettes.
  • pas de bibliothèque d’images (chaque image est associée à UN article), souvent, les clients qui veulent un site aiment pouvoir rassembler leurs images dans une “media bank”.
  • spip n’a pas d’architecture modulaire. (en dehors de mes_fonctions.php3). Ce serait pourtant bien si spip avait celà : plus facile d’inclure ses propres fonctionnalités, on pourrait bénéficier des modules d’autres développeurs, …

Conclusion

SPIP est l’un des meilleurs CMS existant actuellement, mais juste un système de gabarits qui soit plus simple, celà aurait été vraiment bien.

Pour l’installation de sites avec CMS chez un client, j’aimerais avoir quelque chose de plus ouvert, moins rigide. Les nukes et Drupal sont hors course, car je n’aime pas la logique 3 colonnes du portail à la nuke et l’avalanche de fonctionnalités (tikiwiki est un exemple, ça fait beaucoup trop).

L’édition d’articles

Ca reste du textarea assez moche avec des accolades partout dès qu’on veut mettre du gras, italique, … :

  • j’aime pas les accolades
  • / pour italiques, j’aimerais mieux (comme pour les mails en rich text)
  • * pour gras (enfin, strong) (comme pour les mails en rich text)
  • _ pour souligner (comme pour les mails en rich text)

Et pourquoi pas un éditeur wysiwyg genre HtmlArea ? IE et Mozilla implémentent tous deux ce genre de gadjet qui est quand même assez idéal.