En fait, il y a pour moi deux sujets majeurs sur le forums qui interressent pas mal de personnes et qui posent des problèmes techniques, organisationnels et financiers :
- Le module de revue
- La synchronisation des données
- Coté technique -
Comme on le vois dans ce tread de discussion, il y a un gros manque pour certains utilisateurs dans le module revue, sous développé par rapport au module album. Il y a lieu de rescencer trés précisément les besoins et le mode de fonctionnement de ce module. Il appelle bien sur la création, soit de tables dans la base en ligne actuelle pour y stocker les informations des revues, soit une base en ligne séparée.
A l'extrème, il est aussi envisageable de scinder ce module Revue dans une application dédié, entierement vouée à cette gestion.
La synchronisation des données, réclamée aussi par quelques utilisateurs pour la gestion des albums, s'appliqueraient aussi aux revues. Cette synchronisation pose des problèmes techniques dans la manière de faire, mais aussi sur les contraintes de charges serveurs et transmission de données. Comme pour le module revue, il faut passer un bon moment à bien déterminer ce que l'on veux faire et de borner nos désirs dans les limites de la faisabilité.
- Organisationnels -
Après les contraintes techniques, c'est bien ici que nous retrouvons des contraintes ou des avantages. Je m'explique. Philippe est le créateur de BD Gest' et à ce titre, le propriétaire de cette application et de la base en ligne. Développé de manière "empirique" (Attention, ce n'est pas un terme péjoratif, mais un terme de développement en informatique), il n'a pas prévu un developpement modulaire ce qui gène ou rend impossible une multiprogrammation. Cela veut dire que toute la charge de travail repose sur lui et qu'il est le seul maître à bord. C'est normal, c'est son soft.
Mais dans le cas des deux modules évoqués plus haut, c'est presque une refonte complete de BD Gest' qui est demandé et pas une simple modification de virgule.
Il est fort probable que pour partir sur ce genre de développement (et je le conseille personnellement) il faut repartir sur de nouvelles bases :
- nouvelles spécifications tenant compte de l'existant et de l'expérience passé
- un code modulaire permétant une multiprogrammation
- une structure de controle, de validation et d'intégration du code.
Ou alors une nouvelle version programmée uniquement par Philippe, mais sans mettre en doute ses capacités, je ne suis pas sur qu'il soit pret à passer tous ses W.E. à refaire une nvl version tout seul...
Le facteur temp joue ici un facteur très très important...
- Financier -
Et bien pour ces deux évolution, ça coute des sous !
Quelque soit les solutions, ça implique une augmentation importante de l'espace disque serveur, de la charge CPU et de la bande passante.
Je ne compte pas la charge de developpement "gratuite", qui va couter moultes reproches, dépenses inconsidérées et même risque de rupture avec la/les compagne(s) du ou des programmeurs en causes !
Voila les quelques idées que j'avais à apporter au débat.
François
(comme dirait Karine 
