Point de la construction du portail en août 2013
Bonjour, voici ma réponse au point sur le choix entre développer ou utiliser des propositions de logiciel libre existante :
"mon coeur balance toujours entre agréger des solutions existantes (libres de préférence, mais qui demande de longues heures de recherches, tests...) ou faire moi-même (ce qui représente un lourd investissement temporel et ajoute encore une alternative de plus à l'ensemble existant). As-tu pu vraiment trouver ton bonheur dans l'existant ?"
J'ai observé souvent la tendance pour les développeurs à développer soi-même plutôt qu'utiliser des solutions existantes. J'ai même vu une personne redévelopper complètement une solution existante à l'identique juste pour la mettre à sa main, appliquer ses habitudes personnelles de programmation qu'elle présentait comme des règles générales. Ce phénomène n'est pas étranger aux difficultés insurmontables que j'ai rencontrées dans mes différentes tentatives de mettre en place des processus de développement basés sur la modélisation.
Ce phénomène est à analyser sous plusieurs angles. Il y a tout un volet de l'ordre de ce je pourrais appeler la psychologie du programmeur sur lequel je ne vais pas m'étendre car je pense qu'il est assez connu et que les enjeux sont ailleurs. On peut citer :
- La réticence à utiliser ce qui est fait par d'autres.
- Le besoin de "faire une oeuvre".
- La crainte d'avoir à négocier les fonctions et la manière de les développer.
- La tendance à penser que ce que l'on fait soi même est ce qui se fait de mieux.
Un point qui me parait important est que le code est un langage pour le développeur. J'ai eu de nombreuses discussions avec Aurélien Renou sur ce sujet. Il ne voyait pas l'intérêt de passer par une étape formelle et pensait qu'échanger des phrases SQL avec les équipes pour faire une spécifications était un moyen efficace et l'on ne peut pas dire que la vie lui ait donné tord.
Sur un tout autre plan, c'est la question de la valeur du code. Nous avons lu des articles qui disent que le code n'a pas de valeur, mais d'autres que les choix techniques dans un projet sont une clé de succès décisive. Le code n'a pas de valeur :
- En raison du coût du codage dans le budget général d'un projet.
- Car chaque ligne de code est réécrite plusieurs fois avant que la solution soit à maturité.
- Parce que dans une approche basée sur les modèles et la génération de code toute la valeur est dans le modèles.
- Parce que les technologies changent vite et qu'il faut recoder une même solution périodiquement.
Les arguments opposés :
- Une solution complète fonctionnellement riche et pertinente représente une masse de code qu'il a fallu mettre au point et finalement c'est le code qui tourne, pas les specs ni les modèles.
- C'est le moyen le plus rapide donc le moins coûteux pour disposer d'une solution.
Tout cela serait à affiner, en l'état c'est un constat qui est fait plutôt par référence à des approches classiques de projets de développement, l'approche Agile, l'extrem programming donnent un éclairage un peu différent.
Pour nous qui avons une certaine ambition quant à la puissance et la qualité des solutions la première chose qui me parait importante est la hauteur de vue et l'économie de notre temps. Nous devons avoir une vision complète de la solution à réaliser avec un accent tout particulier sur la relation avec les utilisateur potentiels. C'est la démarche de satisfaction client, pensée intelligemment, d'où l'importance du recueil de besoin, de la gestion des exigences, de la robustesse, de la flexibilité de la documentation. Et nous devons savoir répartir nos énergies sur les différents activités d'un projet en fonction de leur importance.
Par rapport à la question coder ou réutiliser du logiciel libre, je remarque que le plus souvent la décision de coder après une tentative de s'approprier une solution de logiciel libre : n'est pas prise collectivement mais c'est une initiative du développeur qui la partage une fois que le développement est très avancé et constitue déjà un début de patrimoine dont on pose la question de la valeur. le cahier des charges et le processus de sélection du logiciel libre sont peu ou pas formalisés le développement se fait hors de toute organisation projet, la besoin adressé n'est pas explicité, le développeur pense connaître exactement le besoin, met les enjeux sur des aspects techniques qui n'intéressent pas les utilisateurs potentiels ( ex java contre php) souvent le logiciel libre a été adopté à la suite d'une démo ou d'un test de premier niveau qui a charmé les utilisateurs mais qui ensuite demande un effort d'appropriation que l'on hésite à faire. les solutions de logiciel libre ne sont généralement pas documentées, la seule solution pour les découvrir est de les installer et de les essayer ce qui est très consommateur de temps et permet mal d'évaluer la couverture des besoins.
Pour s'approcher d'une conclusion, il faut d'abord réaffirmer certaines bonnes règles qui sont générales : Expliciter son cahier des charges. Allouer des ressources à l'évaluation des logiciels libres et formaliser le processus de choix. Accepter de passer du temps à l'appropriation. Si un développement spécifique est décidé, lui faire suivre un processus conforme à l'état de l'art, en particulier accepter de réaliser un minimum de documentation dans un langage compréhensible par les utilisateurs pour au moins leur permettre de vérifier ex ante s'il répondra à leur besoin. Tout en affirmant que le processus projet à la mode ISO 9000 est obsolète et que des méthodes agiles permettent d'aller beaucoup plus vite.
Un bilan sommaire de l'utilisation des outils que j'ai retenus :
Portail[modifier | modifier le wikicode]
Solution : Drupal7[modifier | modifier le wikicode]
Je n'ai pas réussi à bien rentrer dans le produit.
Je l'ai positionné comme portail d'orchestration des autres outils. Ce qui ne sera effectif que lorsqu'un LDAP global sera en place, ce qui est un gros travail. Il comporte des fonctionnalités redondantes avec les outils fédérés ce qui rend un peu inutile l'effort pour prendre en main les fonctions et donne un aspect fouillis au portail.
ECM/GED[modifier | modifier le wikicode]
Solution : nuxeo[modifier | modifier le wikicode]
Fonctionnement maintenant parfaitement satisfaisant.
Répond très bien au besoin pour le domaine de la GED avec le composant DM ( Document Management).
Composant Asset Management, présenté comme gestion de contenus multi medias. Semble avoir une ergonomie un peu différente, on ne comprend pas bien les spécificités et surtout si les documents gérés dans DM sont de fait ou pas considérées comme une sorte d'asset. Pour le moment j'ai pensé prudent de ne pas s'y pencher trop.
Tendance à étendre son spectre dans le domaine des réseaux sociaux et du Case management. Sur l'aspect réseau social cela le met en concurrence avec Drupal. Une stratégie pourrait être de positionner nuxeo au coeur de la plate-forme de groupeware et supprimer Drupal.
Sur l'aspect case management : on remarque que plusieurs solutions on besoin d'intégrer un moteur de work flow et qu'ensuite celui-c peut être mis en jeu dans d'autre domaines. Ici le moteur est JBPM de bonne réputation. Il est vrai que si l'on met en oeuvre des workflow pour gérer des processus de gestion documentaire, l'envie vient naturellement de créer des processus dans des domaines proches. Exemples : le processus demandes de congé, ... Pour l'instant je ne me suis pas lancé dans le design de work flows. Il est extrêmement difficile de la faire sans utiliser nuxeo studio qui est payant. D'autre part je pense que les processus doivent être designés en BPMN puis compilés en BPEL, ce n'est pas comme cela que nuxeo fonctionne, interrogé sur le sujet, nuxeo répond que c'est parce que qu'il font est mieux.
Le projet de plugger un éditeur de diagrammes BPMN sur le moteur JBPM serait intéressant. Intégration très intéressante avec Zimbra et OpenOffice/Libre Office ( fonctionnement encore à valider)
CRM[modifier | modifier le wikicode]
Solution : VTiger[modifier | modifier le wikicode]
Première approche sur la recommandation des NetInvaders.
Semble très complet fonctionnement mais l'approche est un peu difficile à appréhender.
Plus destiné à ceux qui vendent des produit que du service.
Approfondir la découverte avant de conclure ( et surtout de se lancer dans un développement chevauchant)
Forum[modifier | modifier le wikicode]
Solution : Wordpress[modifier | modifier le wikicode]
Parfait pour gérer un blog.
Le produit étend son domaine, chevauche maintenant celui des CMS.
A décider quel outil mettre en maitre des autres.
Documentation/Gestion des connaissance/Wiki[modifier | modifier le wikicode]
Solution : media wiki[modifier | modifier le wikicode]
Parfait pour la corédaction de documentation.
Quelques difficultés à maîtriser les modèles.
Difficile de faire des wikis confidentiels, ce n'est pas la philosophie de l'outil, donc attention pour une utilisation dans un projet client.
modélisation[modifier | modifier le wikicode]
Solution : Enterprise architect[modifier | modifier le wikicode]
Le nouveau couteau suisse du softeux.
Ce n'est ni libre ni gratuit, mais du jamais vu pour le rapport puissance/prix
gestion code source[modifier | modifier le wikicode]
Solution : svn[modifier | modifier le wikicode]
Fait parfaitement ce pour quoi il est fait.
tracker[modifier | modifier le wikicode]
Solution : Mantis[modifier | modifier le wikicode]
Fait parfaitement ce pour quoi il est fait.
Laisse toute liberté de définir le cycle de vie du ticket. Il est donc important de le définir et éviter d'avoir plusieurs déinifions dans l'entreprise ce qui rendrait plus difficile l'établissmeent de statistiques et tabelaux de bord au niveau société.
Reporting/Business intelligence[modifier | modifier le wikicode]
Solution : SpagoBI[modifier | modifier le wikicode]
Découverte en cours.
Au niveau du spectre fonctionnel répond aux différents besoins.
Sur le papier, excellent candidat pour supporter le projet de supervision des développements par analyse des traces laissées dans le système par les membres de l'équipe projet.
Testé avec succès la connexion aux bases EA sous MySQl et nuxeo sous postgreSQL.
Bon candidat également pour le projet de "sanity checks" sur la base nuxeo.
SGBD[modifier | modifier le wikicode]
Solution : MySQL[modifier | modifier le wikicode]
Fait parfaitement ce pour quoi il est fait.
Solution : postgreSQL[modifier | modifier le wikicode]
Fait parfaitement ce pour quoi il est fait.
Quand on découvre postgresql on découvre les manques de MySQL : MySQL ne gère pas l'intégrité référentielle.
Postgre dispose d'un add-on pou rla gestion des données géolocalisées
Groupware[modifier | modifier le wikicode]
Solution : Zimbra[modifier | modifier le wikicode]
Très sympa portail webmail. Fonctionnalité de porte-document qui empiète un peu sur la GED. Lui préférer une intégration avec nuxeo plus riche.
Bureautique[modifier | modifier le wikicode]
Solution : Libre Office[modifier | modifier le wikicode]
Chaque fois qu'il y a un sujet d'intégration bureautique dans un logiciel libre c'est LO ou OO qu'on référence. Difficile de s'y habituer après 25 ans de pratique de MSOffice, mais ça marche. Consommation mémoire (très) importante.
Le module base est intéressant, il donne un moyen facile de faire un peu de gestion de données alors que MS Access ne fait pas partie du pack MSOffice de base et n'est donc pas toujours disponible.
Fonctionnement validé avec des sources de données ODBC sur MySQL et postgreSQL.
Conclusion[modifier | modifier le wikicode]
Ma conclusion personnelle et provisoire est une préférence pour l'utilisation de logiciels libres en préférant ceux qui ont une approche modulaire et qui intègrent d'autres projets. Ceci permet : une liberté de choix dans les modules que l'on intègre d'avoir des modules qui restent concentrés sur leur coeur de métier s'il y a un besoin on peut faire un effort de développement pour compléter/améliorer une fonctionnalité. de se concentrer sur le fonctionnel et de ne pas laisser les choix techniques prendre le dessus de prendre connaissance du consensus du domaine, de participer à sa construction et éventuellement de confronter son approche à celle des confrères. A cet égard les solutions telles que Vtiger, nuxeo, SpagoBI toutes développées en java montrent des similitudes dans l'architecture qui sont le reflet d'un effet de communauté intéressant.