Bonjour,
Je crois être assez mal placé pour décrire l'objet social de SPIP et que ce serait plutôt à ses développeurs de s'accorder sur ses paradigmes...reste à savoir si elles et ils en auraient la patience et la volonté, notamment pour y consacrer du temps qui sera forcément investit au dépend du codage...
Mais c'est peut-être là citer, insidieusement, l'un des points fondammentaux. Devons-nous accorder la priorité à la performance technique de nos outils ou la soumettre à l'examen de leur utilité, à celui de l'influence de leur usage sur le fonctionnement de nos communautés ?
Là-dessus il serait facile de dévier vers l'outrance en dénonçant uniquement certains portails dits "sociaux" mais dont les finalités se résument au recouvrement d'information sur leur leurs usagers et leurs pratiques en ligne. Mais je ne pense pas quoique ce terrain là ait son intérêt, qu'il fasse beaucoup avancer la réflexion sur SPIP.
De fait, encourager à communiquer en ligne contraint à un certain niveau à dématérialiser les relations humaines. Si cela présente un avantage notamment par l'abolition des distances géographiques et des frontières, l'examen de l'impact local est moins réjouissant.
Je crois qu'un manque essentiel de l'accompagnement à l'usage de ce type d'outil procède de la façon empirique et très ponctuelle dont sont chaque fois abordées les questions :
- de répartition des rôles et prérogatives, qui sont souvent calquées sur une hiérarchie technicienne ; là où html offrait des capacités limitées de maitrise autonome, il faut bien considérer qu'appréhendé par des débutants la distribution webmaster/administrateur/rédacteur offre aussi celle de mettre en place la reproduction à l'échelle d'un portail de structures sociales pyramidales ne se justifiant pas obligatoirement...dans les structures associatives cela peut aller jusqu'à ajouter de nouvelles barrières et faire en sorte que ce ne soit plus seulement dans la conduite sociale de la structure qu'une autorité se construise au travers du CA, mais également sur tout ce qui procède de la communication.
- que du fait de cette dématérialisation les plus enthousiastes et plus à l'aise avec les technologies ont rarement souci de construire des communautés collaboratives avec leurs équipes rédactionnelles, ce qui tend dans la plupart des cas à recréer pour les structures collectives le traditionnel clivage webmaster/néophytes de l'époque des sites statiques, ce en dépit des capacités avérées des CMS à les résorber.
- faut-il le dire ? du développement des solitudes civiles et du déclin du dialogue interpersonnel dans la vraie vie, qui se traduit par le passage de la "solitude du geek" à une condition sociale de plus en plus universelle.
Je ne suis pas d'avis que situer le projet social de SPIP dans la "militance" présente un intérêt. Au moins pour l'usage du terme que je trouverais inapproprié. Il me semble toutefois présenter différentes caractéristiques propres au monde collaboratif auquel je crois.
Il pourrait par exemple se décrire comme un outil dont la vocation première serait la facilitation d'accès à toutes et tous, individuellement ou collectivement, aux moyens de s'exprimer et de publier en ligne en toute autonomie.
Ceci supposerait que toute l'instrumentation du projet poursuivant cet objectif s'oriente vers celui-ci, établissant certainement un distinguo par rapport à l'état actuel où beaucoup de documentation est orientée "webmasters" sans être particulièrement attentive à la compréhension de certains ressorts de pure "communication", ce qui produit certains phénomènes directement observables :
- Par exemple le mécanisme de publication directe mériterait une fonction débrayable de blocage de l'indexation dans les moteurs de recherche et de la diffusion de flux rss à la mise en service du portail. Hier encore, j'ai visité un site en construction dans un état peu reluisant, mais qui forcément est indexé...
- D'autre part si ce devait être aux utilisatrices et utilisateurs que serait dédié le projet, l'accueil et la navigation de spip.net ne se repartiraient pas comme actuellement : forcément tous les moyens de s'approprier l'outil à ce niveau serait rendus plus accessibles en amont que ceux permettant ses déploiements complémentaires (plugins) et développements.
Sur cette question de déploiement, en terme prospectif peut se poser la question de l'idéal en la matière, même si il n'était pas techniquement accessible : un cms qui s'installerait tout seul en un clic à partir d'un unique formulaire à peu près de la même manière dont ça se passe pour blogger par exemple. Peut-on imaginer un processus qui permettrait dans un premier temps d'utiliser la sérialisation de fichiers et non le recours à un sgbd, réservant éventuellement la possibilité de basculer vers une base dès que certaines conditions rendraient cette solution facilitante, ou simplement désirée par ses utilisateurs ?
Si le basculement vers SQLite me parait de bon augure a priori, en tant qu'utilisateur moi-même je dois dire que je n'arrive même pas à comprendre comment je peux déployer spip en ayant recours à ce SGBD "magique"...
Je lis bien qu'empiriquement cette vocation à "faciliter" soit bien au coeur du projet pour pas mal de ses contributrices et contributeurs.
Une question polémique toutefois : "faciliter quoi ?"
On a vu toute une branche de développements de plugins émerger et qui orientent clairement les utilisateurs vers le recours aux fameux "réseaux sociaux".
Le fait que leurs équivalents non-commerciaux, des choses comme Elgg par exemple, ne suscitent apparemment aucun intérêt ne me semble pas aller dans la direction vers l'appropriation d'une autonomie. D'ailleurs il faudra se poser cette question même :
- l'autonomie au web commercial compte-t-elle parmi les objectifs du projet ? et dans un cas positif de réponse à celle-ci, n'y aurait-il pas comme ça a pu être suggéré, matière à clairement présenter des distinguo parmi les plugins (choix openstreetmap/googlemap, par exemple)...
Si bien sûr l'usage de SPIP dans un cadre commercial doit s'inscrire dans une logique GPL 3, il me semble qu'il y ait en quelque sorte perte de répères quant au fait que ça n'ait pas été sa vocation première, et que dans une très large mesure, c'était précisément le fait de s'inscrire au service des individus et d'une communauté désintéressés, en prenant compte des obstacles d'accès représentés par les savoirs-faire techniques, en portant à son cahier des charges l'aménagement d'une "progressivité" dans ses apprentissages, qui faisaient son originalité.
- Ce que j'observe de spip-dev c'est que la plupart du temps ce qui se décrit comme objectif c'est la fonctionnalité
- Du coup la finalité de l'usage pour l'utilisatrice ou l'utilisateur final n'est abordée qu'au moment où celle-ci soulève des questions éthiques
Je m'aperçois que j'ai parlé de "cahier des charges" et je me demande si au sens strict du terme, SPIP en a jamais eu ? je veux parler ici de description des usages dont auraient besoin ses utilisatrices et utilisateurs dans la vraie vie, en amont des fonctionnalités informatiques qui sauraient les satisfaire.
Je crois que chercher à établir ce cahier des charges quelque part aiderait sûrement à échanger les points de vue, forcément contradictoires, de chacune et chacun concernant :
- l'intérêt social de la technologie SPIP : c'est à dire non pas ce qui techniquement va le distinguer d'autres CMS, mais en quoi - là c'est c'est subjectif à dessein - le projet rejoint certains paradigmes de l'Internet originel : libre circulation et libre échange des ressources, des documents, liberté et autonomie d'expression des opinions.
- sa place dans les contextes respectifs non seulement des "technologies facilitantes" mais tout autant de la "fuite en avant technologique". J'ai lu souvent ici des manifestations d'impatience à l'égard de dates de sortie de telle ou telle version et qui ont finit par me mettre mal-à-l'aise. J'ai parfois l'impression que comme dans nombre d'autres communautés de développeurs, se joue une sorte de course qui voudrait que le numéro de version ait forcément préhéminence sur la pertinence du projet. Mais si par exemple la documentation des usages de SPIP s'améliorait substantiellement en terme d'accessibilité, ne s'agirait-il pas d'une amélioration toute aussi significative que celle d'une version majeure à une autre du logiciel lui-même ?
Je reste espanté sur ce plan, par la constance dans bien des cas des usagers non-professionnels de spip (comme d'autres CMS) à déployer l'outil avant même de s'interroger sur ce à quoi il pourra leur servir !
Ceci est à mettre en parallèle au fait qu'il n'ait - encore à ma connaissance - jamais été déployé d'outil dédié au projet SPIP qui permette au public d'exprimer ses besoins : comment dans ce cas rédiger un cahier des charges ?
Tout ce qui existe pour assurer ces définitions se décline entre les forums, les retours d'intégrateurs et développeurs et donc en général par communauté des personnes qui utilisent déjà et effectivement SPIP.
Peut-être en utilisant limesurvey par exemple, y aurait-il intérêt à questionner les visiteurs de SPIP.NET sur ce qu'ils cherchent, sur qu'ils attendent en les invitant à l'exprimer en langage courant ?
Il me semble qu'un débat sur la nature et la finalité du projet SPIP dans son ensemble ne pourrait qu'être fructueux pour toutes ses composantes, parce qu'à mon avis aujourd'hui c'est l'échange entre elles qui me semble mériter l'attention : du public "intéressé" aux développeurs du core, en passant par les personnes qui se dédient, au travers de la conception de tutoriaux et de documentations à la clarification des rapports allant des uns aux autres.
D'ailleurs qu'en pensez-vous ? Pour vous y aurait-il matière à l'existence d'un "projet spip" et qui mérite distinguo du "projet logiciel" ? Ceci puisqu'il est notamment question de décliner des "distributions" et que ça renvoit d'une certaine façon à de vraies inerrogations sur l'unité et la cohérence du "projet spip", non ?
...encore une fois désolé pour la tarnine, en espérant qu'elle serve à quelque chose, vu qu'il est difficile de se torcher avec un courriel.
Bonne continuation en esperant que ce message Matthieu t'apporte quelques éléments de ce que tu attendais.
@+
Philippe
