Salut,
Quelques tentatives de réponses à ces très intéressantes interpellations.
ARNO* a écrit :
(1) Avant même d'en arriver aux mots-clés hiérarchisés, on pourrait carrément commencer par se demander pourquoi il y a _toujours_, dans SPIP, cette limite absolue: un article, une brève, un site, un document, ne peuvent se trouver que dans une seule rubrique, et une rubrique ne peut elle-même dépendre que d'une seule rubrique.
Ces principes-là ne sont, me semble-t-il, pas remis en cause par les mots-clés hiérarchisés. Il s'agit simplement de donner la possibilité d'avoir non plus une seule arborescence dans le site, mais plusieurs. Avec les mots-clés hiérarchisés, on reste en plein dans la logique "robuste et cohérente" de spip.
C'est vrai que la logique du "rhyzome" les remet en cause, mais je ne crois que ce fameux rhyzome (même si, à titre personnel, je trouve ça hautement excitant comme perspective) puisse servir à autre chose qu'à des développements assez particuliers (et potentiellement, si on se limite à une navigation avec un tel outil, assez déroutants pour les visiteurs, effectivement).
* la structure d'imbrication des rubriques pourrait ne pas être strictement hiérarchique (c'est-à-dire qu'une rubrique ne peut pas être à l'intérieur d'une de ses rubriques «enfant», pour éviter actuellement les «boucles» fatales de structure...).
Non, non, je crois qu'il faut garder un "repère". Si les rubriques sont considérées comme un outil trop rigide, rien n'empêche de ne pas les utiliser (tout placer dans une rubrique unique "mon site" et créer une navigation uniquement par mots-clés) mais il faut continuer à disposer de cet outil très structurant qu'est l'arborescence de rubriques, très utile dans de nombreux cas.
* le fait que ça produit très rapidement des sites totalement bancals, mêmes les webmestres «confirmés» risquant de se lancer dans des structures à la noix en pensant que cette liberté technique va pallier une réflexion très mal calée; or, une des volontés de SPIP (en standard), c'est non seulement de fournir des automatismes techniques, mais d'induire des structures de site simples et robustes (c'est-à-dire facilement navigables, bien organisées, etc.);
Par rapport à ça (cet argument - qui revient assez souvent, je trouve - des webmestres qui vont faire des conneries), j'ai un peu de mal, sur le plan politique, avec cet argumentaire. Je ne suis pas du tout sûr, pour le dire de manière un peu caricaturale, qu'il appartient à spip de se substituer à l'intelligence de ses utilisateurs. C'est le propre d'un outil puissant de pouvoir être mal utilisé (les mots-clés hiérarchiques comme la fission nucléaire).
Il existe aujourd'hui des sites spip qui sont de vrais foutoirs, où les potentialités déjà très importantes de spip sont utilisées n'importe comment, pour le plaisir de les utiliser et pour suppléer l'absence d'une réflexion éditoriale sur la cohérence du contenu proposé, sa "navigabilité" et ce genre de choses. C'est inévitable. Spip doit-il pour autant renoncer à mettre à la disposition de tous ces fonctionnalités avancées.
Je ne plaide pas ici pour une course en avant, bêtement, où l'innovation technique vaut pas elle-même. Il me semble que trois types d'arguments sont actuellement utilisés pour justifier la non-intégration d'une nouvelle (ou le retrait d'une) fonctionnalité dans spip:
1. Une question éthique. Il est légitime que les développeurs de spip, par conviction idéologique ou pour d'autres raisons, estiment qu'il ne souhaitent pas faciliter certains usages de l'outil qu'ils produisent. On réfléchit à deux fois avant d'instaurer des mécanismes pouvant être utilisés comme systèmes de flicages, on favorise ou non l'emploi des formats ouverts, on tente d'éviter que le logiciel n'induise des hiérarchies sociales quand ce n'est pas absolument nécessaire. Aucun problème.
2. Un calcul d'efficacité. Le gain gagné pour x% des opérations ou pour x% des utilisateurs implique des pertes pour le restant que l'on juge trop importantes. J'inclus dans ce second argument la cohérence fonctionnelle (la perte induite par une nouvelle fonctionnalité n'est pas nécessairement limitée à des micro-secondes de temps de calcul). Ce second argument est le fondement de la cohérence de l'outil spip, une sorte de rasoir d'Occam radicalement nécessaire, même s'il ne participe que peu à une critique de fond des nouvelles fonctionnalités discutées (et n'empêche donc pas, a priori, leur développement sous la forme de "modules", "plug-ins",...).
3. Une posture éditoriale. Spip, c'est "ça". Si les deux premiers argument me paraissent incontestables (en ce compris dans leur inévitable part d'arbitraire), ce troisième me paraît plus faible. Peut-être que je le comprends pas ou pas bien. Pour le dire autrement, j'ai l'impression que le modèle du "webzine collaboratif", même s'il reste indubitablement dominant, ne constitue plus qu'un pourcentage minoritaire des usages de spip, lesquels usages se sont très largement diversifiés. Ca crée souvent un hiatus, voire une incompréhension entre certains spipiens "de base" et les directions prises par le développement de spip.
=> Essayez de considérer en quoi le fait d'ouvrir ces libertés aux mots-clés plutôt qu'aux rubriques est autre chose qu'un pis-aller pour déplacer les risques vers un endroit moins voyant. 
Non, puisque la logique des mots-clés hiérarchisés ne contredit pas les rubriques. Pour le "rhyzome", l'appliquer aux mots-clés plutôt qu'aux rubriques procède à mon avis simplement d'une logique de préservation des usages majoritaires, en ne laissant effectivement que des endroits "moins voyants" à ceux qui veulent pousser plus loin (je ne crois pas d'ailleurs que des options comme les mots-clés hiérarchiques ou en ryzomes devraient apparaîtres dans l'interface public sans qu'une variable ad hoc ait été activée à la main dans un ficgier php).
[...]
Pour pousser le bouchon un peu plus loin, il n'est pas impossible d'ailleurs que, la base étant ouverte aux modifications, l'idée même de mot-clé devienne assez limitée, puisqu'il sera peut-être plus lisible de fabriquer pour chaque «groupe de mot» un type d'élément dans la base ad hoc («Lieux», «Noms propres», «Ingrédients»...). Du coup, pousser aujourd'hui au développement des mots-clés conduira à des habitudes encore plus bancales, car décalées avec la logique de SPIP.
Ca c'est hyper-intéressant et je crois que beaucoup ne demandent pas mieux que de s'engager dans cette voie. Cela dit, ça pose quand même un certain nombre de questions, dont deux me semblent essentielles:
- Il faut que l'interface privée permette non seulement la manipulation des nouveaux objets aussi facilement que les actuels (bref, il faut écrire un script générique susceptible de manipuler indiféremment les "articles" actuels, avec ou sans nouveaux champs, ou les "recette de cuisine" de demain) mais aussi la manipulation des méta-objets (ici, les groupes de mots-clés; dans un autre cadre la création du type "recette de cuisine" ou "référence bibliographique",... ou tout autre objet qu'on souhaiterait manipuler dans spip). On est loin du compte.
- La réalisation de "groupes de mots-clés" selon le modèle que tu proposes (via la création d'un nouveau méta-objet spip) suppose que les nouveaux objets de spip puissent être liés facilement à d'autres. Je ne demande pas mieux (ça serait sympa de lier des brèves à des articles, des articles entre eux,...), mais - outre le fait que c'est mille fois pire à intégrer pour les utilisateurs ne voulant pas trop se prendre la tête - ça devient très vite l'usine à gaz (j'ose à peine imaginer l'inflation exponentielle du nombre de tables de liaisons qu'implique la possibilité de lier chaque objet à chaque autre dans un modèle où le nombre d'objets n'est pas limité).
Une voie intermédiaire et sans doute plus réaliste consisterait peut-être à réaliser une "boîte à outil" dont chacun des élément pourrait ou non être utilisés par chaque nouveau méta-objet. Cette boîte à outils contiendrait simplement les outils actuellement disponibles sur les articles (c-à-d: 1° le module de gestion des dates; 2° les images et documents joints; 3° les auteurs; 4° les mots-clés; 5° les forums; 6° les pétitions,...). Lors de la création d'un nouveau méta-objet, il "suffirait" de choisir lesquels de ces outils seront utilisés par les objets appartenant à ce méta-objet. Par exemple, si je créé le type "brève" (en supposant qu'il n'existe pas encore) dans le but de reproduire le fonctionner de l'objet "brève" actuellement inscrit "en dur" dans spip, je l'autorisarait à utiliser les dates, les mots-clés, les forums, mais pas les auteurs, les documents joints ou les pétitions. Dans cette optique, les mots-clés gardent leur pleine pertinence.
Bref, les mots-clés sont actuellement un outil très simple à mettre en oeuvre et à manipuler, je ne suis pas sûr qu'il faille lacher la proie pour l'ombre et se lancer dans l'émulation des mots-clés par les méta-objets qu'il sera bientôt possible de manipuler avec spip.
Mes trois sous,
François
