Discussion :

[mramm75]

Bonjour à tous,

je sais que ma question a déjà été postée mais les réponses ne me permettent pas de décider.

La question est donc de savoir s'il faut ou pas conserver 4D ou du moins s'il faut lancer une consultation afin éventuellement de migrer vers un autre outil.

Le cadre est associatif (donc sans des moyens d'une entreprise).

4D est installé depuis longtemps et a fait l'objet de nombreux développements spéciaux. Aujourd'hui la version 12.2 est installée

L'usage est assez basique :
- des contacts (contacts individuels, société)
- des groupes pour des évènements
- gestion de la facturation des membres et évènements divers
- requête (pas très instinctif mais qui fonctionne bien lorsque l'on a compris !)

Problème :
- démarrage un peu lent (il faut sans cesse redémarrer 4D)
- impossible pour les quelques salariés de modifier les champs, il faut faire appel aux développeurs
- impossible pour les quelques salariés de construire un publipostage sans faire appel à un développement spécifique pour chaque publipostage

Certains développements sur mesure ont été effectués (liaison avec le site internet, gestion des droits d'accès au site…)

Ma question, n'ayant pas de compétences dans le domaine est doit-on conserver 4D ? et si non, quels sont les outils plus adéquats qui pourraient répondre à nos besoins.
Il me semble un peu rigide par rapport aux outils actuels et la forte dépendance vis-à-vis de la boite de développement ne serait-ce que pour faire un mailing me dérange.

Merci bien de votre avis de professionnels sur la question.

[sieste68]

Bonjour

de ce que je comprend, le problème n'est pas 4D mais l'équipe de développement qui veux garder la main sur son application.

L'usage est assez basique :
- des contacts (contacts individuels, société)
- des groupes pour des évènements
- gestion de la facturation des membres et évènements divers
- requête (pas très instinctif mais qui fonctionne bien lorsque l'on a compris !)

jusque là il s'agit d'une application on ne peut plus "standard' pour une base de donnée. La notion de requête dépend de l'interface, c'est tout.

Problème :
- démarrage un peu lent (il faut sans cesse redémarrer 4D)
- impossible pour les quelques salariés de modifier les champs, il faut faire appel aux développeurs
- impossible pour les quelques salariés de construire un publipostage sans faire appel à un développement spécifique pour chaque publipostage

le premier point me parait bizarre. Pourquoi redémarrer. L'apllication est-elle en réseau, sur PC / Mac, ... ?
Quel est le besoin de modifier un champ ? Cela est souvent du à un problème à la base de définition du besoin, ou alors d'un besoin qui évolue. L'application est-elle est cours de développement ?
Le publipostage peut être fait de plusieurs manière (php, 4D-Write, ...) Quelle est la technologie utilisée ?

Ma question, n'ayant pas de compétences dans le domaine est doit-on conserver 4D ? et si non, quels sont les outils plus adéquats qui pourraient répondre à nos besoins.
Il me semble un peu rigide par rapport aux outils actuels et la forte dépendance vis-à-vis de la boite de développement ne serait-ce que pour faire un mailing me dérange.

changer d'outils = reprendre ce qui a été fait er refaire => cela a un coût
l'utilisation de 4D ne nécessite pas de compétences spécifiques si l'on ne souhaite pas faire de développement. Tout dépend du produit utilisé, de comment il a été construit et de comment on l'utilise. Un seul outil qui fait tout demande parfois un peu d'investissement dans la compréhension de l'outil, maintenant, être pieds et mains liés au développeur, cela n'a pas de sens, surtout aujourd'hui.

Patrick

[mramm75]

Bonjour,

merci bien de cette réponse.

Oui, les usages me semblent assez basiques pour une base de données. Sauf que, en dehors des requêtes, seul l'entrée de nouvelles données est possible.

Le besoin de modification des champs n'est pas quotidien mais se pose de manière, disons régulière. C'est moins, je crois, un problème d'architecture de la base que d'évolution des missions.
J'avais l'impression, peut-être fausse, que certaines application de gestion de base de données permettaient aujourd'hui d'implémenter des champs, sans aller toucher au code.
L'application est utilisée depuis longtemps et n'est plus en cours de développement (même si des développements sont toujours demandés).

Les mailings se font via 4Dwrite, mais, implémenter des champs semble d'une certaine complexité puisque les développeurs doivent intervenir... Là aussi, il me semblait que les outils de gestion des bases de données actuels permettait avec une petite formation de faire ses propres mailing sans apprendre le code ...

Pour les problèmes de redémarrage, oui 4D est installé sur un serveur afin que toute l'équipe puisse y avoir accès.

Mais il est vrai que tout reprendre à 0 à un coût, humain et financier.