Théorie du groupware

Un article du dossier Cyberdemocratie
email Facebook Twitter
Màj : 16 juil. 2019 – # pages A4 : 6

Introduction

https://democratiedirecte.net/theorie-du-groupware/#Introduction
workgroup.png

Avertissement. Cette article a été créé récemment. Il fait cependant l'objet de régulières mises à jour, le développant au niveaux du fond comme de la forme.

Référentiel. Le présent article est fondé sur notre pratique du groupware Tiki, via son installation sur webdd.org. Le présent article ne peut cependant être considéré comme une description de tiki, qui n'est ici qu'un référentiel. Notre choix s'est porté sur Tiki après avoir testé ses plus proches concurrents : Drupal et Joomla.

La raison de notre choix en faveur de Tiki est que celui-ci est un groupware "clé en main" c-à-d prêt à l'utilisation. Drupal et Joomla sont plutôt des environnements d'intégration et de développement : l'administrateur peut choisir pour chaque application une marque de son choix parmi une liste de "plugins". Le problème avec ces plugins est qu'ils sont seulement supposés être compatibles avec l'API mise à la disposition des développeurs externes par Drupal et Joomla. Il en résulte des performances inférieures à Tiki en matière d'intégration (parfois ça ne fonctionne pas du tout), de sécurité, ou encore de convivialité (les interfaces des plugins sont différentes au niveau de la forme et de leur logique).

Définition

https://democratiedirecte.net/theorie-du-groupware/#definition

Un groupware est un système de travail collaboratif en réseau, composé d'une série d'applications intégrées, que nous appelons "modules" :

  • Forum
  • Votation
  • Authentification
  • Infolettre
  • Calendrier
  • Gestion des droits d'accès
  • ...

Structure

https://democratiedirecte.net/theorie-du-groupware/#structure

On peut décrire théoriquement un groupware comme la superposition d'au moins trois couches :

  1. la couche supérieure, dite "applicative", composée des diverses applications à la disposition de l'ensemble des utilisateurs ;

  2. la couche intermédiaire, dite "administrative", composées d'applications disponibles aux seuls utilisateurs disposant de droits d'administration ;

  3. la couche inférieure, dite "moteur", composées d'applications assurant automatiquement le fonctionnement des deux autres couches : notamment leur intégration, la communication avec le réseau Internet, ou encore la sécurité.

Modèle économique

https://democratiedirecte.net/theorie-du-groupware/#modele-economique

Divers modèles économiques sont possibles, qui sont déterminés notamment par des considération financières et de faisabilité technologique, concernant principalement la couche moteur.

La problématique est déterminée par deux champs technologiques :

  1. Client-serveur vs pair à pair ;
  2. Groupware vs Saas ;

Client-serveur vs pair à pair

Types de réseau

De plus en plus de logiciels concernent des applications de réseau (mail, navigateur, Facebook, Bitcoin, ...). Celles-ci sont conçues sur base de deux types possibles de réseau :

  • client-serveur c-à-d centralisé : mail, sites web, Facebook, banque en ligne, ... ;
  • pair à pair (PàP) c-à-d décentralisé (NB : en fait chaque noeud du réseau est à la fois client et serveur, mais aucun des noeuds n'est indispensable, contrairement au modèle centralisé qui ne peut fonctionner sans serveur) : Bitcoin, ...
Avantages et
inconvénients

Le coût total d'un serveur (matériel, local, maintenance, sécurité, ...) est bien plus élevé que celui d'un client. En revanche une application en réseau pair à pair est confrontée à une plus grande complexité, et même – selon le théorème CAP – à des limitations induisant d'inévitables arbitrages entre critères de performance des fonctionnalités de l'application. Il en résulte que le coût global d'une application décentralisée peut être plus élevé que celui d'une application mixte (notamment lorsqu'on intègre dans le coût la formation des utilisateurs et la gestion du risque).

Exemple. Un moteur de recherche décentralisé est confronté à la difficulté d'opérer de façon décentralisée les fonctions suivantes :

  1. apprendre la topologie des nœuds du réseau (annuaire des utilisateurs, ...) ;
  2. rechercher l’information sur tous les nœuds ;
  3. recevoir une réponse d’un nœud répondant aux critères de recherche.

Exemple d'arbitrage : garantir que toute recherche obtient un résultat peut impliquer que deux mêmes recherches n'obtiendront pas le même résultat.

CentraliséP2P
Efficacité+
Résilience+
Réseaux sociaux
et monopole

Un réseau purement pair-à-pair est difficilement compatible avec un modèle d'entreprise privée, dont l'organisation est pyramidale (sauf les véritables coopératives). D'autre part les applications dite de "réseau social" ont tendance à évoluer vers une situation de monopole car les utilisateurs préfèrent logiquement le réseau le plus populaire (cf. loi de Metcalfe). Par conséquent, selon nous, une application de réseau social ne peut être optimale pour la collectivité que si elle est gérée par une coopérative publique dans un système politique de démocratie directe.

NB : le fait que les Facebook et consorts seront probablement remplacés un jour par d'autres quasi-monopoles privés ne change rien à la problématique.

Groupware vs Saas

Le modèle dit du "logiciel en tant que service" ("software as a service" : SaaS) – où les logiciels sont installés sur des serveurs distants plutôt que sur la machine de l'utilisateur, et utilisés via Internet – est de type client-serveur plutôt que pair à pair (d'un point de vue technique mais également juridique).

Ce modèle est souple car :

  • le type de machine et de système d'exploitation de l'utilisateur (le "client" en termes technique aussi bien que commercial) est neutre : n'importe quel client peut s'abonner à tel ou tel service en ligne ;
  • les utilisateurs ont l'opportunité de changer de fournisseur "comme de chemise", et ainsi se composer un groupware "à la carte".

Les groupwares ne vont pas pour autant disparaître car (i) leur avantage est que leurs applications sont intégrées (notamment, l'output d'une application est directement utilisable par les autres applications) ; et (ii) une organisation peut très bien proposer un "groupware en tant que service" (GaaS).

Mise à jour technologique

https://democratiedirecte.net/theorie-du-groupware/#mise-a-jour-technologique

La mise à jour technologique (màjt) est un processus régulier permettant d'améliorer constamment la qualité des applications : fonctionnalités, rapidité, sécurité, convivialité, ...

La majt est plus complexe pour un groupware dont les applications proviennent de fabricants différents. Les API (couches applicative et administrative) qui permettaient leur intégration peuvent ne plus fonctionner si par exemple un nouveau protocole (couche moteur) de communication est utilisé.

On peut distinguer trois types de màjt :

  • extensive : ajouter de nouvelles fonctionnalités ;
  • corrective : corriger des bugs, améliorer des performances (vitesse d'affichage, etc) ;
  • systémique : nouvelle infrastructure logicielle (protocoles de bases, environnement de développement, langage de programmation, ...).

C'est la màjt systémique qui est la plus problématique car il peut en résulter que certaines fonctionnalités deviennent inopérantes dans les installations (*) réalisées avant la màjt, par exemple parce que les configurations fonctionnelles déterminées par l'administrateur d'une installation ne sont plus adaptées à la nouvelle infrastructure.

(*) Le présent site est une installation de WordPress ; webdd.org est une installation de Tiki ; ...

La vitesse du progrès technologique accentue la prégnance de la problématique des màjt systémiques. La présente théorie vise à simplifier cette problématique en déterminant un maximum de principes fonctionnels standards du groupware, pouvant ainsi servir de cahier des charges standardisé pour les concepteurs et développeurs des couches inférieures du modèle OSI. Ce faisant l'on maximise l'interchangeabilité, et partant, la mise en concurrences des technologies de base.

Rôle de l'État. On incitera d'autant plus les entreprises concernées à se soumettre au jeu de la concurrence, qu'il y aura sur le marché des entreprises publiques statutairement contraintes de développer des technologies adaptées à ce cahier des charge (ce qui accroît leur attrait au yeux des utilisateurs).

Modules

https://democratiedirecte.net/theorie-du-groupware/#modules

La présente section détermine des fonctionnalités importantes que devraient assumer les différents modules du groupware.

Forum

https://democratiedirecte.net/theorie-du-groupware/#module-forum
  1. Structure des réponse en arbre, avec possibilité pour l'admin de déterminer un niveau maximum de l'arbre (exemple niveau 2 : sujet > réponse > réponse à réponse.

Authentification

https://democratiedirecte.net/theorie-du-groupware/#module-authentification
  1. Sur base du registre national (authentification officielle), seul moyen efficace de neutraliser les identités multiples.
  2. Par toile de confiance.
  3. Intégration authentifications officielle et par toile de confiance (par exemple pour authentifier la compétence des membre d'un groupe de chercheurs, ou encore l'appartenance à une organisation décentralisée) ;