spip-o-mania

Spip : Arno* l’interview

par davduf, 7 juillet 2002

Et, juste avant, ce préambule. Spip est un CMS à part. Un CMS orienté contenu éditorial. Spip n’est pas un dérivé de Nuke. Il est né ailleurs, en France, à la même période. Derrière Spip, il y a beaucoup d’amis, connus du temps où l’ADSL n’existait pas encore, où même le php devait balbutier. C’était l’époque où je faisais un site, Arno* le sien, et d’autres encore. On rêvait. On s’était même mis en tête de déclarer la guerre au web marchand, en rédigeant le Manifeste du Web indépendant. Cinq ans plus tard, nos routes se croisent encore. C’est con, mais ça fait chaud au coeur une constance pareille. Maintenant, au travail. Arno, l’interview.

D’où est venue l’idée de Spip ? A quel besoin répondait-il ? Peux tu brièvement nous tracer les grandes lignes dans l’histoire de
Spip, quand, où, comment ? Et surtout qui ? Et, enfin, quels sont les liens entre Spip et Uzine, et le Minirézo (avec breve présentation des deux derniers si tu veux bien...)

Bon, je te fais un paquet pour les trois questions, parce que ça
revient un peu au même. C’est d’ailleurs ce qui permet de comprendre
les caractéristiques de SPIP.

Le minirézo est un groupe informel de Webmestres (pas toujours les
mêmes, depuis le début ça change régulièrement) qui se sont mis à
discuter autour de ce qu’ils aimaient faire : des webzines, à la
manière d’un site qui existait à l’époque, en 1995-1996, La Rafale (tiens
tiens...). Ca a rapidement donné le Manifeste du Web indépendant, et
un site Web nommé uZine. Le principe d’uZine était à la fois d’être
un site d’activisme et de réflexion, et une expérience de groupe :
tous les participants au minirézo disposaient de l’accès au FTP du
site, et installaient eux-mêmes leurs textes (ce qui ne posait pas de
problème, puisque le principe du minirézo était qu’on était tous
webmestres de nos petits sites ; donc pas de difficultés pour que
chacun se débrouille avec le HTML).

Au bout d’un peu plus de deux ans, vers la mi-1997, le site s’est
progressivement arrêté. Une des raisons était que chaque mise-à-jour
du site devenait de plus en plus pénible à réaliser : pour chaque
nouvel article, il fallait reprendre plusieurs autres pages pour le
référencer, et parfois on écrasait les modifications d’un autre
participant.

Entretemps, on s’est mis au PHP, puis à mySQL. Mais ça n’a pas donné
un système de publication, ça a donné d’abord le Portail des Copains
de Lazuly. [Le but du Portail était d’être tellement automatisé que
Laz peut partir quinze jour en vacances sur un bateau dénommé "SPIP"
sans qu’on se rende compte de son absence.]

A la mi-2000, on a décidé de relancer uZine, mais sous une forme
cette fois-ci très différente, et notamment avec un outil nous
permettant de gérer le site à plusieurs et d’automatiser la mise en
page. Les premiers impératifs, issus de l’expérience du premier
uZine, étaient donc :

- que la mise en ligne des articles soit aussi simple et rapide que possible ;

- qu’il y ait des outils de travail collaboratif pour pouvoir gérer
collectivement le travail éditorial.

Depuis les débuts, les questions avaient pas mal évolué. Du
webzinat (autopublication, accès individuel à l’expression public),
on était passé à quelques expériences sur le travail collectif sur un
même site ; et là, on voulait expérimenter le travail collectif sur la
décision éditoriale (c’est-à-dire la négociation, au sein même du
site, de la ligne éditorial et du choix de ce qui devait être
publié). Donc, deux autres impératifs sont apparus :

- que tous les visiteurs puissent proposer des articles ;

- surtout, que ces visiteurs puissent également participer aux
discussions sur les choix éditoriaux.

C’est ainsi qu’est né une sorte de pré-version de SPIP pour uZine,
pour répondre à ces besoins spécifiques. Ce produit, développé et
consolidé, est devenu SPIP l’année suivante et a été distribué sous
licence GPL.

Pour moi, parmi les grandes forces de Spip, on pourrait dire :
maquette personnalisable à souhait (pas de "3 colonnes" à la Nuke par
exemple), installation ultra simple (automatisée, avec choix des
options selon les hébergeurs), vitesse du produit (avec systeme
cache). En vois tu d’autres ?

A mon avis, c’est le travail sur l’interface de gestion du site :
l’interface est entièrement conçue dans une optique éditoriale. Il ne
s’agit jamais d’effectuer une fonction sur une base de données, mais
toujours d’utiliser une logique de publication. C’est ce qui rassure
les non-techniciens (notamment les visiteurs qui proposent des
articles : la logique qui leur est proposée est celle de la
publication de documents, il n’y a aucune considération technique
apparente) et qui fait que l’utilisation de SPIP est généralement
bien acceptée par des utilisateurs à priori hostiles à l’idée de
bidouiller sur un "logiciel qui fait de l’internet" (c’est fréquent
dans les associations : les réfractaires à l’informatique s’y mettent,
parce que l’interface correspond une logique qu’ils connaissent déjà).

Il y aussi un autre avantage, mais c’est très personnel : c’est nous
qu’on l’a fait ! Je savais pas où aborder ce point dans tes questions,
alors je te le place ici. Quand on a commencé à réfléchir à un
système de publication, avec Lazuly et Erwan, Erwan avait déjà
développé un système pour gérer l’Ornitho ; et avec Laz, on s’est
empressés de trouver des arguments fallacieux pour ne pas l’utiliser
(interface pas jolie, c’est pas ça qu’on veut...). En réalité, ce
qu’on voulait, c’était le faire nous même. De la même façon qu’on
s’était mis au HTML, dans un tel projet, le plaisir c’est le Do It
Yourself (trois accords de guitare, et te voilà sur la scène du
CBGB !). Donc pouvoir faire nous-même nos moulinettes en PHP et
construire nos requêtes mySQL. Par de nombreux aspects (et ça se
voyait énormément dans la première version de SPIP, affreusement mal
programmée selon les critères des informaticiens), SPIP s’est
construit comme ça : on a appris à le faire en le faisant. Je ne sais
pas si la démarche est perceptible, mais elle est centrale : le
plaisir du Web, c’est pas d’écrire ses textes dans Word et de les
copier-coller dans une interface toute faite sous Dreamweaver : c’est
le "Faites-le vous-même". Du coup, c’est cette envie qu’on espère un
peu communiquer aux utilisateurs ; ceux qui veulent seulement écrire,
ils peuvent prendre plaisir à finasser la typographique, essayer de
structurer le site de manière élégante... ; ceux qui veulent
bidouiller leur interface peuvent construire des choses plus ou moins
élaborées... On fournit un outil où la partie laborieuse est déjà
faite (gérer les requêtes mySQL et afficher les infos dans des
boucles PHP, c’est d’un chiant !), le plaisir étant de voir les
utilisateurs se former, seuls et entre eux : il y en a qui commencent
avec l’interface par défaut, puis qui décident d’apprendre le HTML
pour bidouiller le truc à leur sauce ; certains décident même
d’apprendre les rudiments du PHP, non pas pour modifier SPIP
lui-même, mais pour affiner leurs squelettes...

Peux tu en dire plus sur chacune des forces que je viens de citer ?

La liberté de l’interface graphique du site public, ça n’était
vraiment pas une option ; c’était impératif. L’un des plaisirs d’avoir
son site Web, c’est tout de même de lui donner la tête qu’on veut. La
seule subtilité ici a été de développer un petit système de
"boucles", qui permet de récupérer les informations avec quelque
chose qui se fond dans le HTML, sans avoir à gérer les requêtes
mySQL. En particulier, si on visualise son squelette dans son
butineur, les appels des boucles disparaissent, mais les emplacements
où doivent se placer les informations sont visibles (les titres
apparaissent, remplacés par la mention "#TITRE", mais au bon endroit
et dans la bonne police...).

Les deux autres points (pour nous c’était aussi impératif : la
configuration en modifiant un fichier texte, ça rebute tout être
normalement constitué ; et pour le cache, obligé aussi, avec la
première version qui ne l’avait pas, uZine faisait planter la machine
du copain qui nous hébergeait tous les deux jours), je ne sais pas
trop pourquoi ça n’était pas plus répandu dans les autres systèmes.
Car une fois qu’on a décidé de le faire, c’est relativement simple.

Cela dit, pour la simplicité de l’installation, on a dû se tromper
quelquepart : je passe mon temps à lire des commentaires de nukeurs
qui expliquent qu’ils n’ont pas réussi à l’installer...

Pour l’aspect graphique, vous parlez de "squelettes", l’équivalent
nukien de "thème". Comptez vous en développer plus ? En mettre en d/l ?
Inciter les designers spipiens à en fournir en libre téléchargement ?

Justement, ils ne jouent pas seulement un rôle graphique, c’est
pourquoi ce ne sont pas des "thèmes". Ils gèrent bien sûr la
présentation graphique, mais également la structure du site. Lorsque
l’on commence à bien bidouiller ses squelettes, on peut adapter SPIP
à des besoins très spécifiques ; il y a par exemple un tutorial sur le
site qui prend pour exemple un site de jeux vidéo : avec les
squelettes standards de SPIP, un tel site est rigoureusement
impossible à réaliser ; mais en créant les squelettes ad hoc, on
obtient un résultat qui n’était pas prévu à l’origine.

Du coup, comme il y a des combinaisons imprévisibles de situations,
de choix de webmestres, créer des squelettes "universels" (valables
pour tous les sites, à la manière des thèmes de Nuke), c’est à la
fois très difficile et finalement pas forcément la bonne solution.
Les meilleurs squelettes, ce sont forcément ceux conçus pour la
structure que l’on veut donner à son site.

Mais évidemment, lorsque des graphistes fournissent des squelettes,
même relativement spécifiques, on les propose au téléchargement.

Note également que nous n’avons volontairement pas masqué les
squelettes des sites. Par défaut ils sont faciles à récupérer. Par
exemple, si tu veux savoir comment fonctionnent les squelettes des
articles d’uZine, il te suffit d’aller voir là :
http://www.uzine.net/article.html
Comme pour le HTML, il te suffit de regarder le code source d’un
autre site pour apprendre à faire la même chose.

Pour Spip, vous avez dû écrire un langage propre, une syntaxe,
notamment en ce qui concerne les mises en pages, les boucles. Que
dirais-tu à un débuatnt qui pourrait craindre ce nouvel apprentissage ?

Que c’est le premier pas qui coûte. C’est vrai qu’au début, ça n’est
pas évident, car il faut en comprendre le principe même des boucles.
Mais une fois qu’on a compris (et ça n’est pas sorcier), il y a une
courbe de progression rapide et illimitée (perso, je découvre des
possibilités et des astuces régulièrement).

Passé cette première étape, là on commence à réellement s’amuser. Au
début par de petites modifications, en copiant des bouts de code
par-ci par-là, puis en développant une structure de site personnelle.

Et puis il y a la mailing-list de SPIP. Les questions portant sur les
boucles sont certainement celles qui obtiennent le plus de réponses :
très souvent, plusieurs utilisateurs fournissent des solutions
différentes, échangent des trucs pour rendre cela plus élégant. Un
aspect finalement assez ludique, un peu comme on peut s’échanger des
bouts de code HTML lorsqu’on apprend ("et comment tu obtiens cet
effet ?"...).

Envisagez vous d’étoffer votre site support ( ;-) ?

Là t’es chiant : se cogner la rédaction des docs, c’est une calamité :-)

Cependant c’est une préoccupation permanente : on ne sort pas une
nouvelle version sans les ajouts des docs qui vont avec. Pour la
version 1.0, on avait retardé la sortie de 3 mois, le temps d’avoir
une documentation complète.

Et, oui, il y a toujours des choses à faire sur la documentation...

Envisagez vous de lancer un Spip anglophone ?

Oui, c’est prévu. Mais auparavant, il faut qu’on termine la version
1.4. La version de SPIP pour l’export (!), ce sera sans doute la
version suivante. Techniquement, ça ne devrait pas être monstrueux ;
en revanche, il va falloir traduire les documentations, et organiser
les listes pour répondre aux utilisateurs étrangers (le gros du
boulot est plutôt de ce côté). Tu nous files un coup de main pour la
traduction en suédois ?

Quelles sont les évolutions que vous aimeriez apporter à Spip ?

Chacun a ses idées, mais il n’y a pas de plan d’ensemble prévu (pas
de chemin de fer façon Mozilla). Il y en effet plusieurs facteurs qui
influent sur le développement :

- d’abord, l’idée d’origine, qui se développe selon la logique
initiale ; c’est très important, c’est parfois source de tensions (j’y
reviendrai), mais l’idée, c’est que SPIP n’est pas un produit
terminé, au contraire il se développe vers une certaine cohérence.
Avant de faire des changements radicaux, le but visé est que le
produit fasse tout ce qu’on peut attendre de lui, sans nuire à sa
logique propre. C’est le moteur principal ;

- les besoins qui apparaissent sur des sites qui utilisent SPIP ;
c’est imprévisible au départ, mais ça joue un rôle important. Par
exemple, j’ai récemment vu comment Samizdat avait modifié SPIP pour
qu’il soit adapté à ce qu’ils faisaient à Gênes ; du coup, la
prochaine version intégrera certaines fonctionnalités liées à cela ;

- les possibilités qui apparaissent suite à de précédentes
évolutions. Il arrive fréquemment qu’en ajoutant une certaine
fonctionnalité, ou en reprogrammant une partie du fonctionnement, on
découvre qu’on peut du coup insérer de nouvelles possibilités sans
trop se fouler. Par exemple, en ce moment, Fil reprogramme le système
d’identification pour l’accès à la gestion du site, cela devrait nous
ouvrir des possibilités imprévues pour le site public.

Parmi les trés rares critiques que l’on vous fait, il en est une qui
a trait à votre développement. On dit l’équipe de dev de Spip moins
ouverte que d’autres. Penses tu que cette remarque soit justifiée ?

Y’a pas la même critique sur le créateur de phpNuke, un méchant pas
gentil qui est pas assez ouvert alors on va faire des fork absolument
identiques à Nuke ? :-)

Cela dit, il y a effectivement quelques caractéristiques de SPIP qui
peuvent provoquer ce genre de réaction :

- SPIP est un produit jeune. Comme je l’ai indiqué plus haut : il
reste beaucoup à faire dans la logique même du produit. Du coup, on
est forcément dirigistes sur certains points, car on a souvent une
idée très précise de ce vers quoi SPIP va évoluer, alors que ça ne se
voit pas encore dans le produit actuel.

- SPIP est très différent des Nuke-like. Or beaucoup de développeurs
sont arrivés sur la liste de SPIP avec des idées préconçues liées à
Nuke (par exemple, les premières semaines, on se faisait engueuler
tous les jours parce qu’il n’y a pas d’add-on dans SPIP ; alors que
les squelettes permettent beaucoup de choses normalement réalisées
avec les add-on dans Nuke, et que l’intégration de fonctionnalités
externes dans le langage de boucles n’a rien d’évident - c’est tout
de suite plus facile quand tout est prédéfini en PHP). D’où forcément
certaines incompréhensions.

- L’interface de gestion de SPIP est résolument axée sur une
métaphore de publication, de flux éditorial. Or, par nature, les
informaticiens qui savent bidouiller en PHP/mySQL pensent les
fonctionnalités en terme d’interface de base de données. Là aussi,
nombreuses incompréhensions. (Pour exagérer, je dirais que certaines
fonctionnalités semblaient plus conçues pour phpMyAdmin que pour
SPIP.)

- Enfin SPIP est réellement utilisé par des utilisateurs sans aucune
connaissance technique. C’est vraiment quelque chose auquel on prend
énormément de soin, et qui énerve certains techos. L’équilibre entre
la souplesse des fonctionnalités et l’évidence de l’interface
graphique (en gros : on ne doit pas se demander à quoi sert tel
bouton), ça revient à tirer un fil entre l’usine à gaz et le soft
totalement bridé. Naturellement, les informaticiens veulent un
maximum de souplesse et de fonctions puissantes, en même temps on ne
veut pas effrayer les réfractaires aux manuels de 200 pages. :-)

On dit que vous ne savez plus exactement ce que l’acronyme Spip
signifie... C’est vrai ? ;-)

C’est un mensonge éhonté ! On n’a pas oublié : on ne l’a jamais su.

Pour l’instant, officiellement, ça veut dire "Système de publication
pour l’internet et le dernier P on ne sait pas ce que c’est". Mais
dans le logo, ça faisait trop long.

Plusieurs projets ont repris certaines de vos idées, je pense à
Glasnost, à ProjectX. Qu’en pensez vous ?

Ben, épatant ! J’ai hâte de voir ça (et puis on ira leur piquer des
bouts de code et des bonnes idées).

As tu une idée du nombre de sites sous Spip ?

Ce que j’en sais, c’est la liste des sites qui se sont inscrits :
http://www.uzine.net/article884.html

Tes plus grandes
suprises parmi les utilisateurs ?

Honnêtement, non, pas de surprises.

La diversité des sujets abordés, c’est l’aspect joyeuseuement
bordélique du Net, donc c’est pas surprenant, juste sympathique.

Pour la diversité des structures qui les utilisent (des particuliers,
des associations, des journaux, des écoles, des administrations, des
partis politiques, des sites de campagne électorale, des
entreprises...), ça n’est pas non plus très étonnant. Contrairement à
ce qu’on nous répète (qu’on nous répète moins ce moment, remarque),
le Web n’est pas une affaire de méga-techos ultra-diplomés ; les sites
hors de prix réalisés par des grosses SSII, c’est pas tellement
courant. Pour une large part, les sites sont toujours réalisés par le
type qui s’intéresse au Net, qui bidouille son site à lui, et qui
propose aux autres de s’en charger. Du coup, s’il connait SPIP, hé
ben ce sera SPIP pour l’assoc, la boîte, le parti...

Ce qui fait surtout plaisir, c’est qu’il y a très très peu de sites
sous SPIP consacrés à SPIP. C’est utilisé pour causer des sujets qui
tiennent à coeur (des sujets de la "vraie vie", quoi). Ca donne
l’impression d’avoir rendu service.

Pour finir, quel regard avez vous sur la communauté Nukienne, et plus
généralement sur les autres CMS ?

Sur les autres CMS, excellent, épatant, y’en a plein, c’est la fête !
Sérieusement, c’est indispensable si on ne veut pas que nos petits
outils deviennent d’affreux instruments normatifs. Plus il y a de
produits différents, moins les utilisateurs seront obligés de se
plier aux spécificités des logiciels ; ils pourront choisir le produit
qui convient à leur besoin, plutôt que réduire leurs besoins pour que
ça rentre dans le logiciel.

Pour Nuke, du coup, ben oui, épatant sous cet aspect. En revanche, je
n’arrive pas à m’expliquer pourquoi les 200 nuke-like sont tous
identiques. Que ce soit plus rapide, orienté objet, ou que sais-je
encore, c’est certainement épatant, mais finalement la façon de faire
des sites est invariante d’un soft à l’autre, à peu de choses près.
Du coup, une multitude de systèmes qui imposent la même norme aux
webmestres, c’est de la belle énergie gaspillée... (je vais me faire
engueuler, tu crois ?).

ARNO*
Spip : http://www.uzine.net/spip

Messages

  • Cela dit, pour la simplicité de l’installation, on a dû se tromper quelquepart : je passe mon temps à lire des commentaires de nukeurs qui expliquent qu’ils n’ont pas réussi à l’installer...

    Bin oui SPIP est trop simple pour ces gens ;-)

    J’ai exactement le même problème avec EVA : ceux qui n’y connaissent rien lise la doc et c’est bon ... par contre ceux qui connaissent déjà SPIP (ou autres) oublient les étapes de l’installation d’EVA à la fin et se retrouvent avec un truc incomplet

  • Moi j’ai lu quelque part Système de publication pour l’Internet partagé (voilà pour le dernier P). Du coup j’ai vite ajouté ça dans Wikipedia et ils l’ont gardé. Bon, faudrait aussi ne pas oublier de rendre un hommage appuyé à l’écureuil de Spirou :-)