Vous souhaitez bâtir un site permettant à des groupes d'utilisatrices d'échanger et de publier dans des espaces qui leurs soient propres sans que ces groupes ni ces espaces ne soient étanches. Typiquement, une utilisatrice pourra appartenir à plusieurs groupes, avec des privilèges différents dans chacun de ses groupes. Si une partie des informations mises en ligne par un groupe doivent n'être visibles qu'au sein de ce groupes, d'autres doivent, au contraire, être partagées selon des modalités flexibles (entre les groupes, publiques…).

Parmi l'ensemble des possibilités, deux solutions semblent se dégager des autres, au sein de la communauté Drupal. D'un côté, Commons se présente comme une solution prête à l'emploi. De l'autre, Organic Groups (OG) est un module¹⁾ dotant un site sous Drupal de puissantes fonctionnalités de “groupe”. En première approche, ces deux solutions semblent comparables. En réalité elles empruntent des démarches si radicalement opposées qu'ont ne peut en ignorer les différences.

Les conceptrices de sites sous Drupal ont l'habitude de bâtir des applications par assemblage de composants fonctionnels : thèmes, modules, features… Dans certains cas, les principales fonctionnalités du site correspondent à un type de besoin suffisamment partagé pour qu'une solution générale soit mise à disposition sous la forme d'une “distribution”, c'est-à-dire un ensemble de composant pré-assemblés. La conceptrice a généralement le choix de n'activer que les composants qui l'intéresse. Elle peut également, comme tout site Drupal, ajouter des composants dont elle aurait besoin et qui ne seraient pas apportés par la distribution qu'elle a choisie. Ce rapide panorama donne une fausse impression de continuum allant de l'assemblage “manuel”, composant par composant, jusqu'au site clés en main que l'on pourrait continuer à retoucher, améliorer. La réalité est moins enchantée. Choisir une distribution peut s'avérer très contraignant, comme nous verrons dans la section consacrée à Commons.

Il y a des notions fondamentales que Drupal ne permet pas d'exprimer. Certaines, telle l'arborescence²⁾ , relèvent de choix quasi-idéologiques. D'autres sont volontairement laissées à l'imagination de la communauté des développeuses Drupal. C'est le cas de la notion de groupe et de sous-groupe.

Organic Groups (OG) entend combler ce “manque”. Cette réponse se distingue par le fait qu'elle tente de s'enraciner aussi profondément que possible dans les mécanismes fondamentaux du fonctionnement du Drupal. L'objectif est de s'assurer que le maximum de fonctionnalités qui seront bâties sur Drupal bénéficieront des fonctionalités d'OG ; et au-delà, de proposer des mécanismes suffisamment génériques pour que des modules qui créent de nouveaux types d'objets puissent faire bénéficier ces derniers des apports d'OG.

OG prend ainsi le parti d'être un module “structurel” et potentiellement structurant. En lui même il n'apporte pas de fonctionnalités “sociale” ni “collaborative” mais il fournit les mécanismes de base pour les construire et le conformer à une grande variété de situations concrètes. Il s'attache aussi bien à permettre d'ériger des frontières, poreuses ou pas, entre des sous espace de communication (espaces privés et collaboratif) qu'à donner les moyens d'organiser le fonctionnement d'espaces et de groupes d'utilisatrices. Quelques exemples donneront un idée de la démarche et des possibilités ouvertes par cette famille de modules.

Si une application propose des types de contenus, alors OG fera en sorte que ces types de contenus aient (ou non !) une existence dans chaque groupe avec une distributions des droits entre les membres qui sera propre à chaque groupe. Si l'on ajoute au site des fonctionnalités de communication inter-utilisatrices (individuelle ou collective) ou d'espaces de travail partagés, OG prendra en charge la gestion des périmètres de diffusion et de collaboration, l'étanchéité ou la perméabilité des délimitations.

Enfin, OG assure en partie sa pérennité en s'appuyant lui-même sur les types primitif de Drupal (les entités) plutôt que d'introduire une nouvelle classe d'objets.

Le champs d'application d'OG est donc très large. Dès l'instant où l'on sort du schéma de publication standard de Drupal basé sur une hiérarchie unique de rôles, il y a potentiellement une place pour OG. Par exemple, un même site pourra réunir une face publique, un “intranet” et un “extranet”. Les trois étant différenciés mais totalement opaques les uns aux autres. Il pourra également permettre d'organiser les règles de fonctionnement d'un réseau social “sur mesure”. Dans tous les cas, les contenus et les moyens de communication seront nécessairement apportés par d'autres modules. On arrive assez rapidement à un nombre important de modules. Comme toujours en pareilles circonstances, les choix sont délicats puisque la pérennité de l'application dépend de la justesse dans l'appréciation du potentiel et du dynamisme de chaque module. Qui plus est, OG ayant un effet structurant, l'application devient très fortement dépendante de la collection de modules le composant. La réputation d'OG en tant que brique de base et sa généralisation dans des projets “sociaux et communautaires” majeurs (Open Atrium, Commons) sont des gages de solidité.

Le principe d'utilisation d'OG le rend accessible aux amatrices éclairées travaillant par simple assemblage-configuration de modules. Il demande cependant un montée en compétence en raison de l'usage cohérent mais non trivial qu'il fait des types primitifs. L'investissement est payé en retour puisque la technique de “OGéisation” de fonctionnalités s'appuyant toujours sur les mêmes mécanismes, on les acquiert une fois pour toutes.

C'est assurément la voie à privilégier si lorsqu'on veut créer un site répondant aux types d'utilisation formulés en introduction. On peut être tentée de reculer devant la complexité du site à créer et maintenir³⁾ et se laisser tenter par des solutions toutes faites. Mais “externaliser” la cohérence et la stabilité technique à un prix : l'enfermement dans une solution sans toujours y trouver la tranquillité qu'on attend en retour. Dès lors qu'on veut coller un tant soit peu aux spécificités d'un projet ou d'un collectif⁴⁾, la mise en œuvre d'une plate-forme de coopérative, collaborative, communautaire ou sociale passe nécessairement un assemblage complexe de fonctionnalités, donc de composants.

Commons est considérée comme une distribution orientée "réseau social". Le terme distribution y prend une signification particulière. Il s'agit d'une application informatique prête à l'emploi. En forçant le trait, on pourrait même ignorer qu'elle est bâtie sur Drupal. D'ailleurs, Commons est définie comme “a complete social business software solution for organizations⁵⁾”. En clair, recourir à Commons, c'est décider d'installer une application dédiée. Certes, cette application est bâtie sur Drupal et elle est open source mais toute analogie avec un développement classique de site à partir de Drupal s'arrête là.

Les conséquences d'un tel choix sont nombreuses. Pour éviter toute déconvenue, il est vivement conseillé d'installer Commons comme s'il s'agissait d'une application autonome et non d'un composant Drupal. Tout module Drupal que vous décideriez d'ajouter introduirait une complexité qui dépasserait ce que maîtrise une amatrice éclairée.

Sans trop entrer dans les détails, il faut savoir que Commons modifie de nombreux composants majeurs de Drupal : des modules communautaires vitaux et même le sacro-saint noyau (core) de Drupal ! Une des conséquences pratiques de ce comportement “invasif” de Commons est que vous devrez vous caler sur le calendrier de mise à jour de Commons. Par exemple, vous ne pourrez pas appliquer une mise à jour de sécurité du noyau ( ou de tout autre module modifié par Commons) sans risquer de casser votre site. Vous devrez attendre que cette mise à jour soit intégrée à Commons et publiée ! Certes, Commons bénéficiant du soutien d'Acquia, on peut lui accorder quelque crédit en matière de réactivité et de pérennité. Il faudra surtout se demander si le risque pris en retenant cette distribution est justifié.

La manière dont Commons est distribué ne contribue pas à clarifier le statut de cette application : est-ce une collection restreinte de composants spécifiques, un vaste ensemble de composants spécifiques ou généraux, ou une application invasive ?. Dans sa version 7.x-3.21, par exemple, on peut se procurer Commons sous trois formes :

• composants⁶⁾,
• no-core,
• core.

Malgré les différences de packaging, les trois “versions” participent de la même conception d'application invasive altérant des composants critiques. La première ne contient que la collection des composants spécifiques à Commons (mais demandera à ce que d'autres composants soient installés). La deuxième réunit les composants Commmons et les composants communautaires, dans les versions requises par Commons. La dernière contient l'application complète : commposants spécifiques et communautaire ainsi que le noyau Drupal. Toutes les versions contiennent les mécanismes d'altération des composants critiques. Dès lors, il est logique que la version proposée, par défaut, soit la version core (compète et autonome).

Au premier abord, l'amatrice éclairée trouvera sans doute que Commons est un faux amis, un objet bizarre qui lui échappe. Il faut garder présent à l'esprit que la conception de sites Drupal par simple assemblage de composants (à la manière d'un jeu de construction) n'est qu'une des modalités d'utilisation de Drupal. Comme pour d'autres CMS bien établis (Wordpress, Joomla…) c'est le mode d'utilisation le plus populaire. Mais ce n'est pas seul⁷⁾. Dans le cas commun, un investissement mesuré et des connaissances techniques limitées sont suffisantes pour aboutir à un site riche de fonctionnalités. Commons vise plutôt les utilisatrices se situant à deux extrêmes.

Pour l'amatrice sans grande expérience technique, Commons s'installe aussi simplement qu'un Joomla ou un Wordpress.Pour autant que les besoins principaux soient couverts, le site est utilisable en l'état. Commons est toutefois doté de composants à forte densité technique que l'amatrice débutante se gardera bien d'utiliser ;) L'amatrice éclairée en concevra une certaine frustration car, face à cet objet complexe, elle se retrouvera aussi démunie que sa consœur moins expérimentée. Mais l'une comme l'autre trouveront largement de quoi s'occuper en s'attelant à la prise en main et à la configuration fine de cette application ambitieuse.

À l'autre bout du spectre des compétences, une conceptrice-développeuse Drupal chevronnée pourra s'intéresser à Commons pour en faire le cœur d'une application spécialisée⁸⁾ spécifique à une organisation donnée. La démarche de développement et la technicité requise rappellent celles des celles de sociétés de services concevaient⁹⁾ et développaient des solutions autour d'applications propriétaires.

Comme beaucoup d'applications Open Source, il faut prendre Commons pour ce qu'il est : un développement spécifique, piloté par un “éditeur”, censé répondre à une catégorie de besoins, tels que les imaginent Acquia, qui se trouve être mis à disposition en open source.

Certaines personnes n'arrivent pas à choisir entre Commons et OG. Une solution médiane consisterait à “copier” Commons en partant d'un Durpal-core standard et en faisant confiance à la sélection de modules retenue par Acquia pour Commons.

Appliquer mécaniquement, cette technique ne conduit nulle part. La question est : quel est l'objectif poursuivi ? Si par le plus des hasards, cette question trouvait une réponse, il n'en resterait pas moins une question subsidiaire : cette technique est-elle le meilleur moyen d'atteindre cet objectif ?

Soyons lucide : la seule raison est l'indécision… Si l'on fait confiance à Commons, autant profiter du travail très substantiel produit ou synthétisé par les auteurs de la distribution. Refaire la même chose, à côté, en moins bien (forcément), n'est rien d'autre qu'un moyen de se pourrir la vie en s'imaginant cultiver sa différence. Ça peut être psychologiquement bénéfique (rien à dire) mais c'est techniquement, fonctionnellement et organisationnellement inepte.

En revanche, apprendre autant que possible des choix faits par des personnes qui traitent la même classe de problèmes que celui que l'on cherche à résoudre me semble procéder d'un veille élémentaire. De même que, confrontées à plusieurs composants proposant des fonctionnalités équivalentes¹⁰⁾, on sera attentive à des informations quantitatives ¹¹⁾ on s'intéressera à des données qualitatives telles que l'expérience des personnes actives, les soutiens dont bénéficie le composant ou la réputation des équipes utilisant ces composants dans leurs projets¹²⁾.