Archives mensuelles : novembre 2003

Prestations de services pour les associations

Une petite exploration des prestataires de services ayant une offre spécifiquement dédiée au marché associatif :

Structuration du secteur associatif

Le Crédit Coopératif présente sa segmentation du marché associatif. Tout d’abord, figure le secteur sanitaire et social, organisé en unions ou fédérations (UNIOPSS, FEHAP, UNAPEI, APAJH, FNARS, CCOMCEN, UNASSAD, …) pour lesquelles le Crédit Coopératif offre un fonds de garantie mutuelle, des services télématiques et de télétransmission pour gérants de tutelle professionnels. Ensuite vient le secteur de l’enseignement privé (90% d’établissements catholiques) et de la formation (OPCA), pour lequel le Crédit Coopératif propose des services de facilitation du cycle de gestion et des financements d’investissements avec garanties, ainsi que des services de gestion de fonds et de trésorerie. Puis on trouve les organisme confessionnels (congrégations et leurs oeuvres par exemple) auxquels le Crédit Coopératif propose des placements solidaires ou éthiques. Viennent ensuite les clubs, ligues, comités et fédérations du sport pour lesquels il est nécessaire de financer certains équipements spécifiques. Les associations de solidarité internationale ont, quant à elles, des besoins de transferts de fonds internationaux. Les organismes de défense de l’environnement peuvent trouver un complément de financement par le biais de placements solidaires gérés par le Crédit Coopératif. Enfin, le secteur des loisirs et du tourisme associatif fait l’objet de prestations de financement de travaux (création d’établissements hôteliers).

Alternatives open source à MS Access

Il semblerait qu’il apparaisse enfin des alternatives open source à MS Access : Rekall (distribué sous licence GPL ici et lu et discuté sur Slashdot) mais aussi un module d’OpenOffice (il doit être bien caché car la dernière fois que j’ai rapidement testé OpenOffice, je ne l’ai pas trouvé). Tiens, tiens, amusant, le langage de script de Rekall est Python !
Pour mémoire, toujours en Python, les produits zetadb et Formulator, dans l’environnement Zope, pourraient bien servir à faire la même chose mais en version Web.

Logiciel pour le financement associatif

Le financement des organismes sans buts lucratif a ses spécificités et constitue un segment particulier pour les offres logicielles, au moins en Grande-Bretagne. Là-bas, le produit largement leader sur le marché s’appelle « Raiser’s Edge » de la société Blackbaud, avec une base installée de plus de 1000 clients. Ce type de logiciels permet d’accepter les dons en ligne avec une intégration complète dans le système de comptabilité de l’association. Un challenger est Visual Alms de Westwood Forster. Les autres grandes fonctionnalités des logiciels de ce type concernent la gestion des membres et des cotisations ainsi que des fonctionnalités plus « classiques » telles que la gestion de la paye, la gestion financière, budgétaire, etc.
D’après la base de connaissances de lasa.org.uk, une association qui a des besoins simples et cherche un système mono-utilisateur pourrait trouver son bonheur pour environ 500 euros ; pour 2 à 5 utilisateurs, les logiciels un peu plus pointus et basés sur un outil bureautique tel que Microsoft Access coûteraient de l’ordre de 10 000 euros et autant en coût d’implémentation et de formation ; pour des systèmes conçus pour 5 à 25 utilisateurs et s’appuyant sur un serveur de base de données, forcément, ça coûte plus cher…

Give Something Back

Du temps où elle publiait gratuitement sa lettre de veille sur le développement durable, la société Utopies racontait l’expérience de la société « Give Something Back« , une société américaine qui avait décidé que ses profits ne seraient pas distribués aux propriétaires ni aux actionnaires mais à des associations locales. De 1993 à 1998, ces dons dépassaient les 2 millions de francs. L’activité de cette société est la distribution de fournitures pour machines de bureau (photocopieurs, imprimantes, …) et la papeterie. L’un de ses principes de gestion est l’autofinancement total (aucun emprunt) et ses 2 dirigeants-fondateurs en sont salariés. La redistribution des profits aux associations locales est organisée de manière originale : la destination des dons est décidée à 40% par les clients de l’entreprise (qui votent à partir d’une liste de 30 associations proposée par la société) et à 30% par ses employés, les 30% restant étant attribués par les fondateurs eux-mêmes.
Le fonctionnement de cette entreprise s’inspire de la société de distribution alimentaire créée par Paul Newman, Newman’s Own.

EJB : ce qu’il ne faut pas faire avec

A l’occasion de la sortie du livre « Bitter EJB », Slashdot fait le point sur ce qu’il ne faut pas faire avec les EJB. Il est rappelé que « bien qu’outils incroyablement puissants entre les mains d’architectes expérimentés, les EJBs sont le sujet d’un grand nombre de mauvais emploi par les développeurs novices qui en font un usage inapproprié ». C’est souvent la complexité des EJB qui tourne les entreprises vers d’autres plate-formes applicatives. Encore une fois, il est rappelé qu’un fusil à éléphant n’est pas forcément l’armement adéquat pour se débarrasser d’une souris domestique.
Mais les remarques les plus intéressantes viennent, comme souvent, des lecteurs/commentateurs de Slashdot. Ceux-ci, dans leur majorité, sont perplexes devant les EJBs. Ainsi, l’un d’entre eux affirme : « La grande majorité des gens avec qui j’ai parlé semble montrer qu’ils n’ont jamais rencontré de projet de développement pour lesquels l’utilisation d’EJB n’aurait pas été totalement superflue et pour lesquels des solutions plus simples, plus faciles à maintenir et moins coûteuses n’a pas été finalement retenue. » Encore un développeur amer au sujet des EJB : « [Avec les EJBs,] il vous faut construire 10 systèmes qui ne marchent pas avant de pouvoir deviner comment en faire un qui fonctionne. Franchement, les EJBs ne m’ont pas l’air de valoir la peine qu’il faut pour les apprendre. » Un peu plus loin : « Si il y a bien une technologie qui est en risque d’extinction dans le monde Java, c’est bien les EJBs. Pratiquement tous les nouveaux projets J2EE dont j’entend parler se tiennent bien à l’écart des EJBs et adoptent des solutions plus simples du type servlet/JSP avec JDO pour la persistence. Ensuite vous distribuez le système horizontalement avec mod_jk ou un équilibreur de charge matériel… Vue leur complexité et la nature restrictive de leur API, je n’ai vraiment pas besoin de cette technologie. » Un autre s’interroge : « Les EJBs… semblent causer plus de problèmes qu’elles n’en résolvent… Pour quel type d’usage sont-elles réellement appropriées ? Je n’ai pas été capable de le deviner la dernière fois que j’ai travaillé en environnement J2EE. ».
Heureusement, au moins un développeur Java cite un cas d’utilisation appropriée pour cette technologie : « Je suis un architecte qui travaille sur une application d’entreprise de plusieurs millions de dollars et notre expérience avec les EJB a été jusqu’ici extrêmement positive. Nous nous sommes bien gardés d’adopter les ‘entity beans’ en nous contentant d’une couche JDO… Avec du matériel modeste, nous remplaçons de manière assez rentable l’application mainframe que nous réécrivons ainsi. » Et un autre de conclure : « Si vous n’avez pas besoin d’une isolation transactionnelle dans le cadre d’un système distribué, les EJBs sont superflues. »

Comment le Web Sémantique se construit

Burningbird expose sa vision des dynamiques de construction du Web Sémantique : un mouvement bottom-up et progressif plutôt qu’un deus ex machina avec éclairs, tonnerre et fanfare, un mouvement par lequel on verra apparaître non pas le Web Sémantique mais un web sémantique. Son idée est que le bidouilleur qui veut publier des données sur le Web sous une forme digestible pour d’autres systèmes informatiques adoptera peu à peu le modèle de données RDF pour des motifs économiques.
En effet, grâce à ce modèle, le jour où il voudra réutiliser ses données pour les intégrer avec celles du voisin et construire une nouvelle application, « il n’aura plus qu’à » ajouter des règles logiques par-dessus. Celles-ci s’appliqueront sans douleur car le modèle RDF est conçu pour l’application de règles de ce type et préserve, pour ce faire, l’identité des sources de données. Ainsi, ces règles logiques pourront simplement dire des choses du genre : « Selon la source C, la ressource XYZ au sens que lui confère la source A est équivalente à la ressource 123 au sens que lui confère la source B ». Chaque source (chaque « auteur » de données) peut donc faire coexister ses données avec celles de ses voisins, qu’elles soient ou non cohérentes avec celles-ci. Les systèmes à base de règles sont là pour recoller les morceaux a posteriori et sans douleur. Cela suppose simplement que le bidouilleur ait adopté le bon modèle de donnée a priori.
Par contre, si le concepteur n’a pas anticipé ce besoin de réutilisation de données et s’est par exemple contenté d’adopter un vocabulaire XML spécifique, il devra souffrir à chaque fois qu’il voudra les intégrer avec celle du voisin car il devra alors développer et redévelopper des moulinettes spécifiques de transformation de ses données (XSLT, …). Investir dans l’adoption d’un modèle « universel » de données tel que RDF se révèlerait donc rentable dès que les réutilisations de données se multiplient.

Caractéristiques du modèle open source

Cet article expose quelques caractéristiques du modèle open source : pas de coût de licence logicielle bien sûr, pas de dépendance à un fournisseur, choix élargi de fournisseurs de services, haute flexibilité/possibilité de personnalisation, stabilité accrue, moindre coût matériel (ne nécessite qu’un serveur intel pour linux et non des serveurs haut de gamme), cycles de développement plus rapides.
L’article cite également quelques autres caractéristiques mais qui sont à mon sens plus discutables : meilleure évolutivité, liberté de choix du rythme de déploiement des nouvelles versions, meilleure prise en compte de l’utilisateur final pour le développement de nouvelles fonctionnalités.

Perdez-vous dans un wiki.

Cet entretien avec Ward Cunningham, inventeur du concept des Wikis, offre une présentation assez fidèle des caractéristiques particulières des usages courants des Wikis. Je retiens ces remarques de l’intervieweur (Bill Venners) : …Dans un sens, un wiki est comme une très petite version de l’internet. Il y a de tout un peu partout… … Il est nécessaire de prendre le temps de faire la connaissance d’un site wiki. En y passant du temps, on prend ses marques petit à petit. Au début, on est plutôt perdu et sans repères, lorsque vous débarquez et voyez toutes ces informations qui vont dans tous les sens et ne sont pas organisées pour le lecteur. Ce à quoi Ward Cunningham lui répond : Effectivement, un wiki reste toujours sur le point d’être organisé.
Pour découvrir un wiki francophone et apprendre à vous y perdre, visitez le CraoWiki.