Spip : Arno* l’interview

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