Re: [LibreAsso] Vos avis pour le guide libre association

[Benoit Pansier <benoit.pansier AT gmail.com>]

Solution globale : SG
Ensemble de solutions spécifiques : ESS
Solutions spécifiques : SS
Le 24/05/2011 00:44, Encolpe Degoute a écrit :
> Cette définition vaut lorsque cette locution est utilisé dans un
> paragraphe argumenté, pas dans un mail de 5 mots.

Absolument pas. Je vous serai gré de ne pas me tenir un procès 
d'intention. Si j'avais écrit un "paragraphe argumenté", j'aurais 
précisé automatiquement et implicitement les limites de mon opinion et 
n'aurais donc pas eu à préciser qu'elle n'engageait que moi.

> La solution globale n'essaie d'être interopérable qu'avec elle-même avec
> quelques format d'imports de données pour effectuer la migration. A part
> quelques exceptions elles n'utilisent aucun format standardisé.
Pourriez-vous citer quelques  exemples validant votre hypothèse ? Une SG 
acceptant un faible nombre de formats en E/S et un ESS aux 
fonctionnalités équivalentes acceptant un grand nombre de formats en E/S 
pour divers domaines.

> > - interface unifiée
> Et souvent plus complexe car il faut compter nombre de menus pour
> atteindre certaines fonctionnalités utilisées au quotidien.
Je suis certain qu'il est plus facile de prendre ses marques sous Libre 
Office que sous gnumeric + abiword ...
D'autre-part la compatibilité des divers éléments élimine certaines 
sources de complication.

> > - déploiement plus simple et rapide (par rapport à un ensemble
> > équivalent de solutions spécifique)
> Si le déploiement est plus rapide la configuration est plus
> problématique. Un paramètre mal positionné peut rendre difficile
> l'utilisation de la solution globale.
Une SG est de type "tout ou rien", c'est une évidence. Si les 
dépendances entre les diverses briques du SI sont fortes, un ESS 
disparate le sera aussi (à ceci-près que le nombre de paramètres 
"critiques" croîtra).

> > - évolutivité dans le cas des solutions à extensions
> La pérennité est plus recherchée que l'évolutivité. Une association n'a
> pas des compétences fixes dans la durée et une solution installée doit
> pouvoir restée en l'état pendant plusieurs années sans présenter de risques.

Et un nouveau besoin doit pouvoir être comblé sans nécessiter une 
refonte totale du SI. De plus, les solutions à extensions nécessitent 
moins de compétences pour être maintenues ce qui les rend plus pérennes.

> > - réduction des tâches de maintenance (par rapport à un ensemble
> > équivalent de solutions spécifique)
> Mais chaque tâche de maintenance est plus critique puisqu'une seule
> erreur et toute l'infrastructure est hors-service. L'organisation de
> procédures simples est plus facile à mettre en œuvre que quelques
> processus lourds.
cf supra

> Les solutions globales présentes un autre problème : elles sont
> tellement générique qu'il est parfois difficile de les plier aux besoins
> exacts pour devoir se contenter d'une série de besoins approchés.
> Si je prends l'exemple de Plone et le la plateforme Zope, il existe déjà
> toutes les extensions possibles dont pourrait avoir besoin une
> association en dehors de la comptabilité. Maintenant je ne suis pas sur
> de vouloir présenter Plone comme la solution universelle à des novices
> car si elle est facile à déployer et à mettre en œuvre, sa
> personnalisation demande des connaissances importantes. Le raisonnement
> est facilement répétable pour OpenERP ou SugarCRM quelles que soient
> leurs qualités.

Un packageage (désolé pour le néologisme) avec des pré-configurations ou 
des profils adaptés à divers besoins serait intéressant, je le reconnais.

Il est évident que les SG auront tendance à convenir plutôt aux 
associations de taille conséquente.

Si l'on regarde le succès des grands (en terme d'utilisation) 
environnements graphiques (KDE & Gnome)  on s'aperçoit qu'il est du 
entre-autres au fait que les besoins principaux sont couverts sans 
devoir compiler d'obscurs modules et qu'il y-a une unité dans les 
interfaces qui facilite la prise en main. Pour Ubuntu et ses dérivés,on 
a un ensemble clés en main, avec des variantes adaptées à des besoins 
spécifiques.

Pour en revenir à la question initiale.

Que ce soit une SG ou un ESS, la certitude d'avoir au final un truc qui 
réponde à tous les besoins sera AMHA (et c'est une marque d'humilité) 
primordiale pour accepter une migration (but du guide).

Partant de là, je pense que les SS devraient être présentés comme des 
modules autonomes d'un ESS concurrençant les SG.

Une solution intermédiaire serait de présenter les SG et les ESS à 
égalité, comme la presse bilingue.
begin:vcard
fn:Benoit Pansier
n:Pansier;Benoit
email;internet:benoit.pansier AT gmail.com
tel;cell:33618340449
version:2.1
end:vcard