Re: Plan de test Clever Age

froggy m'expliquait (le 16.07.2004 14:10):

> Au final, l'oeil averti d'un administrateur ou d'un développeur saura
> comprendre le benchmark avec ses points forts et ses faiblesses. Mais ceci
> est autant vrai pour les SGBD(R) que pour toute comparaison entre deux
> systèmes.

Le soucis principal dans ce que vous dites, est que ce n'est ni le
développeur, ni l'administrateur qui prennent la décision d'utiliser
telle ou telle plate-forme pour l'architecture à mettre en place. Ce
sont les DSI. Je prends une exemple : dans l'administration (celles qui
sont décentralisées du moins), les DSI ne sont pas forcément compétentes
en tout et vont se reposer énormément sur ce genre de tests. Dans ce
genre de contexte, qui plus est, rentrent en compte les différents
"rôles" qui sont fixés par la hiérarchie (l'administration étant un lieu
ou la hiérarchie et la politique peuvent -fortement- régner). Souvent,
les DSI n'aiment pas non plus qu'on prennent les décisions à leur place
ou qu'on convoitent leur poste. Mais là je m'éloigne et celà fait plus
partie de la sociologie que de l'informatique. Quoi qu'il en soit, du
côté fournisseur, c'est ce que l'on observe et on a droit, parfois à des
discours un peu gratinés, car "c'était dans le ZéroNain" ou encore "dans
le DMR". Je ne critique pas la presse non plus : je critique
l'ambivalence de certains discours et la mécompréhension de certains
points techniques. Bref, il faut être _trés_ précautionneux lorsqu'on
compare des produits et je pense que la levée de bouclier envers les
tests évoqués dans ce thread confirme l'analyse générale portée par une
partie, sinon l'ensemble, des intervenants de la liste (du moins ceux
qui se sont exprimés sur le sujet).

> Il n'y a pas de Benchmark bidonné. Il y a juste un banc de test qui a été
> fixé. Quelqu'un qui cherche à développer mon exemple, ne se fiera pas
> juste à un test sur la lecture/ecriture de deux tables, mais cherchera en
> parallèle à se renseigner sur les possibilites de chaque BDD via le
> net/newsgroup. La solution technique à long therme devenant primordial.

Pas si c'est un DSI justement. Un DSI cherchera peut être à faire faire
une étude par un groupe de travail éventuellement?! Mais parfois ce
n'est pas fait car celà coûte comme vous le disiez de l'argent et les
budgets peuvent ne pas être investis SI un article dans une revue de
référence fait office de test et qu'il y a mécompréhension. A terme,
celà peut être catastrophique.

> - Une majorité des PME/PMI ont un pack office (avec ou sans Access, avec
> ou sans license) d'installer sur leur ordinateur. En conséquence, il tres
> tres facil de developper un outil rapide et simple sans pour autant avoir
> des connaissances pointus en informatique. Avec Access, on peut "tripoter"
> des tables sans pour autant avoir la moindre connaissance du langage SQL.

Oui peut être, mais il ne faut pas confondre le front end et le
backend! On peut faire de l'access avec Postgresql en backend!

> - Le gratuit (/Libre), reste encore aujourd'hui quelque chose qui fait
> peur et peu être associé à quelque chose fonctionnant mal/moins bien qu'un
> logiciel possédant une license. Par ailleurs, un logiciel payant offre la
> garenti d'avoir un service après vente (de bonne ou mauvaise qualité), et
> cela rassure ENORMEMENT les dites PME/PMI. Si je prend pgsql, à moins de
> passer par une société de prestation de service, il faut s'addresser sur
> les forums, NGs, MLs, etc et la réponse peut parfois être très longue. Si
> ma BDD crash pour une raison imputable au développement de pgsql, je peux
> m'en prendre qu'à moi même, alors qu'avec un SAV, j'ai quelqu'un sur qui
> taper. Ceci est nullement une critique, mais une constatation.

Effectivement, la notion de responsabilité vis à vis d'un produit est
souvent une grande question dans les PME/PMI. La question est de savoir
si les gens sont prêts à prendre leur responsabilité plutot que de la
rejeter sur une société tiers.

--
Jean-Christophe Arnu
Paratronic