Le Conseil Régional de Bourgogne soutient le développement d'un logiciel libre

Posté par Laurent Costy . Édité par Benoît Sibaud, baud123 et Xavier Claude. Modéré par Xavier Claude. Licence CC by-sa
31
12
juil.
2012
Bureautique

Dans le cadre de son programme annuel d'actions innovantes ouvertes en particulier aux associations membres du Crajep¹ de Bourgogne, le Conseil Régional de Bourgogne a retenu le projet déposé par la Fédération Régionale des MJC de Bourgogne.

Il s'agira de développer un logiciel libre (sous licence AGPLv3) pour répondre aux besoins de gestion et de liens avec les adhérents d'une structure de type Maisons des Jeunes et de la Culture (MJC), Maisons Pour Tous (MPT), Maisons de Quartier ou Centre Social.

Dès le début du développement, la possibilité pour les adhérents d'intervenir et de contribuer aux contenus sera pensée pour encourager l'appropriation, par les adhérents, de l'outil. Par ailleurs, la licence choisie permettra à tout un chacun, une fois la première version produite, de s'affranchir des coûts de licence couramment rencontrés pour ce type de logiciel et de faire adapter le logiciel grâce aux libertés accordées par la licence AGPLv3.

Afin de consolider un cahier des charges cohérent avec la majeure partie des structures visées, la Fédération Régionale de Bourgogne-Champagne est encore à la recherche de 2 à 4 associations de types ciblés ci-dessus afin qu'elles participent à la consolidation du cahier des charges jusqu'au recettage du logiciel.

Pour tout contact : frmjc-bourgogne CHEZ wanadoo.fr

¹ déclinaison régionale du CNAJEP (Comité pour les relations nationales et internationales des Associations de Jeunesse et d'Education Populaire)

  • # Qui, comment ?

    Posté par (page perso) . Évalué à  5 .

    Seule source primaire que j'aie trouvé : http://www.frmjc-bourgogne.org/spip.php?article2027
    Quelle forme économique et technique prendra le développement du logiciel ? Qui est-ce qui développera, pour quel prix, et avec quelles techniques ? Comment l'hébergement sera-t-il proposé ?

    J'imagine que la fédération des MJC de Bourgogne + Champagne a contacté toutes celles de la région ? (sinon, je peux transmettre à celle de Sens).

    Je trouve intéressant le choix de l'AGPL… mais je me demande si ça ne signifie pas qu'on a choisi de faire un développement de zéro sans vérifier si une solution déjà existante pourrait servir de base aux développement des fonctionnalités attendues.

    • [^] # Re: Qui, comment ?

      Posté par . Évalué à  9 .

      Quelle forme économique et technique prendra le développement du logiciel ? Qui est-ce qui développera, pour quel prix, et avec quelles techniques ? Comment l'hébergement sera-t-il proposé ?

      Je suis la personne qui va développer la solution. Je suis lyonnais et fais partie d'une coopérative d'activités et d'emploi.
      En réalité, si l'annonce n'est pas précise concernant les objectifs fonctionnels - ce n'est pas le but -, il s'agit de davantage qu'un outil de gestion d'adhérents.
      Sans rentrer dans les détails, l'outil veut également donner la possibilité aux structures de gérer :

      • leurs contacts (penser aux responsables d'ateliers, à la presse, aux élus etc)
      • les activités qu'elles proposent (évènements réguliers ou temporaires, inscriptions, tarifs…)
      • le partage de documents, la notion de pièces jointes
      • l'envoi de messages à tous, aux membres d'une activité, aux responsables, à l'équipe..
      • la sortie d'états pré-définis et la possibilité d'en créer

      Le cahier des charges n'est pas finalisé et ne le sera que lorsque plusieurs structures y auront participé.

      Ce projet est une spécialisation d'un projet plus large sur lequel je travaille, destiné aux associations de petite à moyenne taille : un outil souhaité participatif, c'est à dire non seulement pour le bureau mais aussi pour tous les adhérents voire les sympathisants. Il y est prévu de pouvoir s'organiser en groupe, de gérer ses rencontres et réunions, de communiquer directement sur l'outil, de pouvoir faire part de ses compétences et disponibilités…

      L'application sera en mode Web, point que je pourrais débattre ici. Je ne suis pas de ceux qui prônent l'emploi du Web partout et je trouve que les applications clientes dites lourdes conservent bien des avantages. Néanmoins, lorsque l'on s'adresse à un large public de non techniciens, le mode Web est parfois, à mon avis, incontournable.

      Les contraintes auto-imposées de l'application sont les suivantes :

      • l'accessibilité : l'outil devra pouvoir fonctionner pour le plus large public possible
      • la simplicité : le logiciel sera destiné à un public de non informaticiens; il écoutera donc ses utilisateurs à propos de son ergonomie. Si le spectre de fonctionnalités visé peut paraître large, le but est de proposer des choses simples. On ne fera clairement pas le café (il ne s'agit pas de réécrire un groupware d'entreprise)
      • le déploiement en quelques clics : l'outil devra pouvoir être déployé via un simple [pip install](http://www.pip-installer.org) sous UNIX, via un installateur à assez court terme sous Windows. Il devra fonctionner y compris sur une machine d'il y a une dizaine d'années. L'objectif est de permettre à des associations sans compétences avancées en informatique et dotée de peu de moyens de l'installer et de l'utiliser.

      Le financement octroyé par le conseil régional représentera en ce qui me concerne entre un tiers et la moitié du coût de développement (base SMIC, et je ne compte pas la veille et la R&D).

      Le modèle économique est encore à définir; mais il devrait être assez classique pour un éditeur de logiciel libre :

      • proposer une offre sur Internet pour ceux qui ne souhaitent pas l'outil en local
      • proposer l'installation, la configuration sur place
      • assurer la maintenance (mise à jour de l'outil etc), le support, notamment téléphonique
      • formation sur l'outil
      • développement sur mesure de fonctionnalités non prévues
      • enfin, si l'effort est important, le coût de la migration des données dont dispose la structure

      Je rappelle qu'en tant que projet libre, une structure pourra choisir de gérer elle-même tous ces aspects, et pourra bien entendu faire appel à un autre prestataire.

      La plateforme sélectionnée côté serveur est la suivante : Python2, le framework Flask et l'ORM Peewee.

      Voilà les raisons de ce choix :

      • Python est le meilleur compromis pour remplir les contraintes citées ci-dessus. Il dispose d'un serveur Web inclus tout à fait capable (CherryPy est sinon un serveur pur Python, portable doué pour de la mise en production). Il inclut le moteur de base de données SQLite. Quant au langage lui-même, avec le framework et l'ORM sélectionnés, l'objectif de performances (déploiement sur une vieille machine) devrait être rempli. Enfin, plusieurs outils existent pour empaqueter une application Python dans un exécutable (objectif de déploiement facile).
      • Python est un langage qui continue sa lente ascension. Il s'agit d'un des
      • langages les plus populaires si j'en crois les statistiques glanées ça et là. Il jouit d'une solide réputation et de beaucoup d'utilisateurs dans la communauté du libre, ce qui est un bon point (à terme contribution, audit de code).
      • L'écosystème permet d'anticiper un certain nombre de choses à court terme telle que la production de fichier au format OpenDocument comme à moyen terme (optimisation via Cython, intégration dans des environnements hétérogènes et j'en passe).

      On me reprochera sans doute de ne pas choisir PHP, notamment du fait de son ultra-présence sur les hébergements mutualisés. Voilà pourquoi :

      • il ne me semble pas simple de proposer un outil sous forme de paquet avec du code PHP qui sera utilisable avec très peu de configuration sous les différents systèmes d'exploitation
      • sur l'avantage supposé : il existe des hébergements mutualisés supportant Python; bien que je concède qu'ils soient clairement moins nombreux et que la mise en place y est peut-être moins aisée. Toute documentation à ce sujet sera bien entendu bienvenue. Je trouve qu'à partir du moment où tout est fait pour faciliter l'installation sans compétences particulières et où des alternatives pour l'hébergement existent, cela est suffisant.
      • cet argument est subjectif mais en ce qui me concerne, je trouve qu'à qualité proche, du code Python est plus lisible et plus concis.
      • et puis il ne faut pas oublier mes compétences personnelles, ma connaissance de l'écosystème, aujourd'hui plus avancées en Python que sur d'autres plateformes.

      J'imagine que la fédération des MJC de Bourgogne + Champagne a contacté toutes celles de la région ? (sinon, je peux transmettre à celle de Sens).

      Cette annonce a été envoyée à une centaine de destinataires en Bourgogne. J'imagine que la MJC de Sens a été prévenue mais sur ce point, c'est Laurent qui saura mieux répondre que moi.

      Je trouve intéressant le choix de l'AGPL… mais je me demande si ça ne signifie pas qu'on a choisi de faire un développement de zéro sans vérifier si une solution déjà existante pourrait servir de base aux développement des fonctionnalités attendues.

      Vous avez raison, le projet sera construit "from scratch".
      Les objectifs de l'outil m'ont amené vers ce choix : je n'ai pas connaissance de solution libre dans un domaine proche qui soit orientée participatif et qui remplisse les contraintes citées plus haut.

      Concernant la licence, le choix se porte vers l'AGPLv3 car c'est celle qui répond le mieux à notre vision pour ce type d'outil.
      Je serai peut-être amené à développer des bibliothèques dans le cadre de ce projet. Ces dernières seront publiées sous une licence plus permissive (selon leur nature, BSD ou MPL).

      Je tiens également à rassurer concernant la nature du projet, même si je ne peux ici avancer que ma bonne foi : la totalité du code et de la documentation seront libérés. L'investissement non couvert par la subvention est réalisé sur mes fonds propres (une garantie pour moi d'indépendance).

      • [^] # Re: Qui, comment ?

        Posté par (page perso) . Évalué à  4 . Dernière modification : le 13/07/12 à 15:43

        Merci de cette réponse très détaillée et instructive, qui entraîne définitivement ma sympathie : je suis moi-même dans une CAE, développeur Python, et confronté également à certaines problématiques mentionnées.
        Il ne faut pas se justifier de ne pas faire du PHP ! La seule chose qui me fasse tiquer (mais bon, il y a un ORM, et c'est sans doute lié à l'objectif de portabilité ultime), c'est sqlite.

        Bravo pour ce marché, pour le courage de faire un développement ouvert, et encouragements pour la suite !

        PS: (au passage, il y a un lyonnais dans mon enseigne (majerti) - j'ose faire ma pub)

        PPS: dès que vous avez un github/bitbucket/repo autre, faites-le savoir !

        • [^] # Re: Qui, comment ?

          Posté par . Évalué à  2 .

          Merci pour les encouragements et déjà pour les questions, qui m'ont permis d'expliquer plus en détails le projet.

          La seule chose qui me fasse tiquer (mais bon, il y a un ORM, et c'est sans doute lié à l'objectif de portabilité ultime), c'est sqlite.

          Alors en effet, Peewee permet d'utiliser SQLite, MySQL et Postgre. En dehors de l'avantage sur la portabilité et le peu de configuration nécessaire, je trouve que SQLite est un très bon moteur dans de nombreux cas. Je l'ai déjà utilisé en prod avec succès. On lui reproch(ait) souvent trois choses :

          • son défaut de certaines fonctionnalités importantes, comme les contraintes référentielles
          • son verrou sur toute la base de données en écriture
          • en Python, le pilote inclus n'est pas par défaut thread-safe

          Je vais peut-être dire des bêtises - dans ce cas, surtout arrêtez-moi - mais :

          • concernant le premier point, SQLite le supporte depuis la 3.6.19.
          • pour le second, le verrou ne devient important que si le volume de requêtes est élevé, ce qui ne devrait pas être le cas ici (même sur une grosse structure, nous n'atteindrons pas plusieurs centaines d'écritures par seconde). Plusieurs contournements existent cependant, bien que je n'ai pas eu à les tester : utiliser plusieurs bases et les lier lors des requêtes qui en ont besoin, utiliser le module asynchrone
          • Peewee, entre autres, répond au problème via threadlocals.

          Cela dit, ce sont des fonctionnalités avancées de la base qui seront à jauger le moment venu. La montée en charge devrait par défaut se faire en migrant vers un moteur plus adapté.

          PPS: dès que vous avez un github/bitbucket/repo autre, faites-le savoir !

          A priori, il y aura un Trac avec les sources comme premier lieu de la gestion du projet, un accès HTTP au dépôt (Mercurial), plus un miroir Github (via HG-GIT).

          PS: (au passage, il y a un lyonnais dans mon enseigne (majerti) - j'ose faire ma pub)

          HS : le monde est petit, je suis allé visiter votre site ce matin, depuis celui de la PyCon Fr.

      • [^] # Re: Qui, comment ?

        Posté par . Évalué à  3 .

        En fait c'est dommage car le logiciel existe déjà et a été développé par l'association Musiques Tangentes, une asso qui s'investit dans le logiciel libre et la culture libre depuis longtemps. Leur logiciel tourne et est béta testé par des écoles de musiques. Il fait déjà tout ca et même beaucoup plus. Idéalement il faudrait vous mettre en contact. le logiciel s'appelle ALJEM. Pour une coopération libriste l'asso qui le développe est là : http://www.musiques-tangentes.asso.fr/

        Voilou Jérémie

        • [^] # Re: Qui, comment ?

          Posté par . Évalué à  2 .

          En fait c'est dommage car le logiciel existe déjà

          Et bien c'est plutôt une bonne nouvelle si un logiciel libre existant répond aux contraintes citées plus haut ainsi qu'à une bonne partie du cahier des charges. Y a-t-il un lieu avec des informations sur l'outil ?

          Je contacte avec l'association dans la foulée, merci.

          • [^] # Re: Qui, comment ?

            Posté par . Évalué à  2 .

            Yes, je vois que vous vous êtes mis en contact yep c'est génial le Logiciel Libre vivre le code libre
            bises
            J.

        • [^] # Re: Qui, comment ?

          Posté par (page perso) . Évalué à  4 . Dernière modification : le 14/07/12 à 09:25

          Je ne trouve pas beaucoup d'infos sur ce logiciel, en dehors de l'annonce.
          En fait, c'est le source que j'eus aimé, une démo que j'eus adoré…

          Chaque cahier des charges est différent : CiviCRM, en PHP, ou pour des choses dans un langage un peu sérieux : OpenERP ou Tryton (je ne cite que ce qui me passe par la tête, en Python, mais je pense que Java n'est pas à exclure), permettent de gérer des associations/fondations, en convoquant des réunions, en émettant des newsletter, mais le plus important reste l'adaptation au métier précis du client : c'est dans les détails que réside le gros du travail.

      • [^] # Re: Qui, comment ?

        Posté par (page perso) . Évalué à  3 .

        Coucou,

        de la part d'un dév qui travaille justement sur une appli web de gestion d'association, qui est aussi de Bourgogne, qui est assez proche des MJC, et enfin qui adore SQLite, je trouve l'idée passionnante et excitante :)

        Bravo et à bientôt !

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # Sur la sollicitation des structures...

    Posté par . Évalué à  4 .

    Bonjour,

    La Fédération a diffusé l'appel à l'ensemble des MJC de Bourgogne et de Franche Comté ainsi qu'au deux MJC de Champagne adhérentes de son réseau. La MJC de Sens a donc été destinataire : l'arrivée récente d'un nouveau directeur sur cette structure ne permettra sans doute pas de rendre prioritaire, pour elle, ce type de participation ; mais si elle avait un besoin impérieux, elle saura sans aucun doute se signaler.

    En ce qui concerne la remarque du développement à partir de 0, elle est tout à fait légitime. Cependant, une implication assez avancée dans la rédaction du guide des Logiciels Libres destinés aux associations au sein du groupe de travail Libre Association de l'April a permis de bien appréhender ce qui aurait pu convenir : des logiciels proches du besoin existaient mais ne satisfaisaient pas complètement le cahier des charges que l'on s'est donné. L'autre aspect important concerne la nécessité d'appropriation : le fait de contribuer aux cahier des charges et aux premiers essais permettra aux MJC d'adopter plus facilement le logiciel par la suite. C'est discutable mais c'est la conviction acquise.

    Voilà pour moi et merci pour l'intérêt porté à cette nouvelle !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.