j'ai une idée de la reponse:
 
Access : non client serveur
 
SQL Server : client serveur
 
mais j'arrive pas trouver les mots pour expliciter la distinction

avec un client/server, le client n'est que consommateur/instructeur, et le serveur uniquement moteur de requêtes.
 
avec un non client/server, le client et le serveur sont le même process, et ça fait tout.
 
ensuite, en client/server, on a généralement une structure prévue pour gérer plusieurs clients en //, alors qu'en architecture classique, c'est rarement le cas, et si ça l'est, c'est généralement peu fiable et peu performant.
 
PS: la notion de client/server ne s'applique pas qu'aux SGBD, un bête site web, c'est une application client/server. le client, c'est le navigateur, le serveur c'est IIS ou Apache. Quand tu écoutes la radio sur internet, c'est la même chose : ton player est le client, et RealServer/Media Server est le serveur.
Quand tu achètes un billet de train sur un automate, l'automate est client de l'application de réservation des billets (qui n'est pas dans l'automate évidement).
 
A noter aussi, que d'un point de vue données, évidement, avec une architecture client/server, tu as une centralisation des informations que tu n'as pas avec une application classique.
Idem pour la nécessité de puissance de calcul : logiquement, pas besoin d'une grosse machine pour faire tourner le client, et tu peux concentrer ton argent pour doper le serveur, alors qu'avec une architecture classique, c'est chaque PC utilisateur qu'il faut doper.

voila un bon résumé ;-)

oué merci pour le resumé
Je connais bien les notions d'achitecture client/serveur
mais je sais pas pourquoi, j'arrivais pas a trouver une definition concernant les SGBD

Ben c'est la même
 
PS: ceci dit, par définition, un SGBD est "normalement" client/serveur. Les exceptions sont très rares (mais répendues). En effet, un SGBD a pour vocation principale, comme son nom l'indique, la gestion des données. Mais aussi la centralisation.
C'est donc par principe "stupide" d'avoir un SGBD qui ne sert pas à de la centralisation de données (parceque si elles sont éparpillées un peu partout, c'est difficile de dire qu'elles soient vraiment gérées)

clair
les seule utilisés d'avoir des données un peu partout (donc pas centralisées), mais qui ont un grand interet  
c'est  
- le cas du load balancing comme a la SNCF
- la spécialisation geographique, comme chez Pagesjaunes. Les bases d'adresse/telephone sont découpées entre serveurs (ex: regionaux)

Ben même dans le cas de ces deux exemples, on reste avec :
1/ Une structure centralisée : répartir les données sur plusieurs serveurs distincts ne veut pas dire que la logique n'est pas centralisée. Ainsi, pour les pages jaunes, d'un serveur à l'autre, on retrouvera la même structure. Pour la SNCF, je suppose qu'en plus du load-balancing, le systèmes est découpé en plusieurs modèles qui se complètent.
2/ Des clients déportés : un même client sera capable de retrouver sur quel serveur les données sont, et ainsi le groupement de serveur peut être assimilé en un super-serveur.
 
En fait, ça me fait penser à une architecture simple, qu'on utilise tous les jours sans le savoir : les DNS.
Il existe des serveurs "root", qui, il me semble, stockent la liste de tous les noms de domaines par leur première lettre alpabétique. Il y a ainsi 26 serveurs, stockant chacun la liste des noms de domaine commençant par une lettre à la fois.
 
Ensuite, vu le nombre de requêtes, ces 26 serveurs ne sont pas suffisants. Il y a donc ensuite une floppée de serveurs qui permettent d'associer une requête à un nom de domaine inconnu à chacun de ces 26 serveurs. Pour les requêtes déjà exécutées, ils conservent une liste en cache, afin de ne plus avoir à soliciter les serveurs root à chaque requête.
 
Cette architecture en étoite se propage sur un très grand nombre de niveau. Ainsi, jusqu'au niveau du FAI, on retrouve une floppée de DNS, tous se basant sur leur propre cache, un DNS "maître" connaissant tous les alias du domaine du FAI, mais aussi des liens vers d'autres DNS afin de pouvoir forwarder une requête qu'ils ne savent pas résoudre.
 
Une entreprise possédera généralement elle aussi ses propres serveurs DNS, qui permettent de résoudre les noms de domaine du réseau de l'entreprise, mais aussi les requêtes sur les noms de domaine public.
 
C'est le meilleur exemple de load balancing qu'on puisse trouver, puisqu'il est accessible de tous, mais en plus se présente sous la forme de dizaines (centaines ?) de milliers de serveurs. Aucun serveur DNS au monde ne connait toutes les entrées DNS existantes, pour la simple et bonne raison que non seulement leur nombre est trop important, mais surtout qu'il y a trop de changements en permanance. Et pourtant, pour peut qu'une entrée ait plus de quelques heures (48 dans le pire des cas), en interrogeant n'importe quel serveur on est capable de retrouver la trace de n'importe quel nom de domaine.
 
Il s'agit donc d'une architecture client serveur à part entière, et malgré une notion de loadbalancing ne se basant pas sur la réplication, on est capable de retrouver n'importe quelle entrée en interrogeant n'importe quel serveur.
 
Le fonctionnement d'un serveur DNS est assez loin d'un serveur de SGBD mais... étant capable de faire une association nom - ip, cela fait cependant penser à un SGBD qui ne stockerait qu'une seule table à trois entrée : IP, NOM, TYPE. Pour moi, c'est donc parfaitement assimilable à un SGBD très spécialisé.
 
La cohérence du système est parfaite malgré un éclatement total des serveurs (et plus qu'un éclatement, chaque serveur peut être géré par une société différente, tout en gardant une cohérence parfaite des données).
 
Bref, tout ça pour dire que quelque soit la forme du load balancing (cluster, réplication, forwarding - cas du DNS -, etc.), il reste toujours assimilable à un unique serveur, du moins un système cohérent et unitaire.
 
Ca reste donc une architecture client/server.

effectivment
A propos des serveurs root
pour preciser ton propos,  les serveurs root gerent en fait chacun, la liste exhaustive d'une extension de domaine particulier.
Chacun de serveurs est dédié à .org ou .fr ou .com, .... une extension par serveur.
donc bref si ya 25 extensions de domaines (je sais pas combien exactement), ya donc 25 serveurs root.
 
bien sur on dira qu'un serveur gere ces DNS, mais physiquement il s'agit d'un serveur virtuel, c a dire un ensemble de machines physiques qui n'en font qu'un . ce qu'on appele une grappe, ou un cluster.
ca rejoint completement la notion de load balancing.
par fois le load balancing se traduit non seulement par la repartition de charge mais egalement la mise en commun de ressources materielles qui convergent vers un serveur central (notion similaire au concept SETI@home)

Mais MySQL est-il un SGBD fichiers ou client/serveur ?

client/server