Comme j'ai un peu de mal à vous suivre dans la réflexion autour du SI (ça parle de LDAP, de dolibarr, de MySQL, du SI de FDN ou Aquilenet... ) j'ai un peu mis à plat le sujet. Selon moi, les besoins que nous avons ou allons avoir et auquel un SI devra (peut-être) répondre : - gérer la base adhérents - tenir une comptabilité rigoureuse - générer des factures, des reçus, des prélèvements? etc. - communiquer au public ou en interne - permettre une authentification sur les services (e-mails, etc.) - être interopérable avec les solutions qui nous permettrons de fournir différents accès (Marque blanche ? Wifi ? Fibre ? Notre propre porte ADSL ? etc.) - mesurer la consommation - vérifier le fonctionnement de nos équipements de production - etc. (et bien d'autres choses ! ) Pour ma part, un SI, ça se décompose déjà en 2 parties qu'il faut à tout prix éviter de mélanger ! Pour organiser tout ça dans ma tête j'ai fait un petit schéma en partant de bonnes pratiques existantes pour qu'on se comprenne bien. Je pense qu'il vaut mieux fragmenter les systèmes un script ou un job (de type de ce qu'on peut produire avec TOS ou autre cochonnerie du genre) car : ça prend 2 fois plus de temps d'installation (on utilise 2 systèmes différents), mais 2 fois moins de temps a intégrer (moins de code a pondre) et 2 fois moins de temps à maintenir (on peut mettre a jour les différentes briques avec moins de tracas de patchs, plugins etc. ). On migre une brique d'une solution A à une solution B plus facilement. Par exemple, le jour où on en a marre de gnucash, on passe à un autre soft et on refait le script qui fait l'interconnexion ou alors, on refait rien du tout car les "briques" à côté nous génèreront des .QIF... Bref, plus on a un gros système monolithique, plus il est difficile à entretenir et moins il risque de coller aux utilisations que chaque personne veut en faire. Donc, je ne pense pas que ça soit une bonne idée de faire une espèce de base (SQL ou autre) et de forcer les différents trucs qu'on veut installer à s'y plier. Déjà on risque de se limiter en choix (car untel sera pas connecté au SGBD que l'on a choisi ... ), ensuite on est pas à l’abri d'avoir à modifier constamment la BD commune parce que le soft A à mis son schéma à jour et ça va pas trop bien dans le sens du B qui n'a pas bougé depuis... -- Gaël (gfa)
