Re: Qui, comment ?

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).