Bonjour à tous,
Salut {F1},
J'aimerais bien aller sur votre île (de France) !
Sachez que j'admire sans retenue la brillante synthèse que représente votre article publié le 15/10/2004.
Coïncidence : La case à cocher pour sélection individuelle d'enregistrements sans point commun est la toute première fonctionnalité personnalisée que j'ai ajoutée, moi aussi, lorsque j'ai abordé le travail avec des formulaires dans MsACCESS !
Quant à votre dernier post, je m'empresse de le recopier dans ma collection d'arguments en sa faveur.
Cela fait toujours du bien d'avoir sous la main de quoi rabattre le caquet de ceux qui critiquent sans fondement.
Je n'y trouve pas de contradiction d'idées avec les miennes bien que j'aie utilisé le mot "béquille" qui n'était pas approprié.
(Cela dit, ôtez sa béquille à quelqu'un qui en a besoin : Il y a de fortes chances pour qu'il se retrouve par terre !)
Votre conception d'une architecture "composite" (ERP/MsACCESS) dès le départ me semble être une idée remarquable.
Elle éviterait bien des errements, dus à la difficulté que représente pour les informaticiens de cerner correctement un besoin vu de l'extérieur.
Malgré toutes les méthodes d'analyse existantes, il leur faudrait ajouter à leurs compétences une vue "métier" que seuls les gens du milieu peuvent avoir, et qui leur permettrait de distinguer clairement le spécifique du "standard".
De leur côté, les gens du métier ne voient pas les choses d'un point de vue exploitable pour un informaticien.
D'où l'intérêt pour l'entreprise d'avoir recours à un informaticien attitré, voire de l'embaucher.
Vaste sujet !
Pour en revenir à la question posée au départ dans ce débat, elle me semble être un faux problème (ou plutôt un problème mal posé).
En revanche les réponses ainsi que le contenu de votre article ont l'immense mérite de recadrer une quantité impressionnante d'idées reçues et de notions de base (de données) mal assimilées !
Quant au possibilités offertes par MsACCES dans le prototypage, y compris celui de produits destinés à une architecture client/serveur, elles sont, comme vous l'avez si bien montré, quasi illimitées.
Mais il existe un prérequis à cela, qui est de connaître son outil sur le bout des doigts, comme un compositeur connaît son instrument, et de travailler dans les règles de l'art (en queue de pie au clavier).
L'élaboration de maquettes fonctionnelles, même sur une quantité relativement faible de données, fait immédiatement ressortir un défaut de structure.
Ces maquettes permettent de tester le comportement des éléments critiques, voire de les mettre en évidence s'ils n'avaient pas été considérés comme tels.
Ce serait trop bête de s'en priver !
A plus forte raison losqu'on sait qu'un client ou une entité cliente n'a pas nécessairement la clairvoyance requise pour préciser l'évolution d'un besoin : Savoir anticiper est précisément ce qu'on attend de l'analyste/informaticien.
À cet égard, MsACCES s'avère être aussi un outil de spécification au moyen d'un modèle éprouvé.
J'ai connu ce cas, toujours dans le spatial, pour un logiciel de gestion "qualité bord" :
Après quelques années de fonctionnement sous MsACCESS, la transposition vers un grand système, pour raisons de montée en charge, s'est effectuée en un temps record !
Économie, sécurité de retrouver un découpage pertinent de l'information, une structure fiable et des fonctionnalités bien rodées, que souhaiter de mieux ?
Attention, vous risquez de lever un (gros) lièvre avec votre remarque à propos de MsEXCEL !
Très performant dans son domaine, on a souvent le tort de le "préférer" à MsACCESS pour "développer des bases de données" !!! (sic).
Peu d'usagers font la différence entre une gestion matricielle (cellules) et la gestion d'enregistrements (lignes) du moteur Jet.
Pourtant tout est là !
Il y aurait amplement matière à un autre débat !
Cordialement.
CRUSOE13
Partager