Nous avons sollicité notre collègue informaticien pour vous répondre. Voici sa réponse :

Permettez moi de répondre à vos différentes questions séparément et dans le désordre :
"Je cherche des informations sur les capacités d'une base Access quant à ses capacités de gestion volumétriques"
Ces limites évoluent d'une version d'Access à l'autre.
Pour la dernière version en date - Access 2007 - Microsoft publie les caractéristiques sur son site dont voici un extrait :
Général :
Attribut Valeur maximale
Taille de fichier de base de données Access 2 giga-octets, moins l'espace nécessaire aux objets système
Nombre d'objets dans une base de données 32 768
Nombre d'utilisateurs simultanés 255

Table :
Attribut Valeur maximale
Nombre de champs dans une table 255
Taille d'une table 2 giga-octets, moins l'espace nécessaire aux objets système
Nombre de caractères dans un champ Texte 255
Nombre de caractères dans un champ Mémo 65 535 lorsque les données sont entrées par le biais de l'interface utilisateur ;
capacité de stockage de 2 giga-octets de caractères lorsque les données sont entrées par programme
Taille d'un champ Objet OLE 1 giga-octet
Nombre d'index dans une table 32
Nombre de champs dans un index 10
Nombre de caractères dans un enregistrement 4 000

(source : http://office.microsoft.com/fr-fr/access/HA100307391036.aspx (consulté le 10 septembre 2008) )

En principe, les limites de votre version sont consultables depuis le logiciel lui même, dans l'aide (F1) sous le mot-clé "Spécifications de Microsoft Access" ou "Caractéristiques de Microsoft Access".

"Le but de la base de données est de créer un système de gestion de documents numériques, y-a-t-il des limitations sur la taille de fichiers PDF ?"
Oui, 1Go d'après le tableau ci-dessus (Taille d'un champ Objet OLE).
Mais il est fortement déconseillé de stocker des fichiers (quel que soit leur format) à l'intérieur d'une base de données afin de ne pas la surcharger.
On préfèrera stocker dans la base uniquement le chemin vers ce fichier (exemple : la chaine de caractère "C:\Documents and Settings\nomdutilisateur\Mes documents\document.pdf"). L'application sera ainsi capable de retrouver ce chemin, et éventuellement de donner l'ordre au système d'exploitation d'ouvrir le fichier se trouvant à cet endroit. Access passe alors le relais à Windows, qui lui-même exécutera Acrobat afin de lire le fichier PDF. Dans ce cas de figure, les seules limites sont donc celles du logiciel Acrobat et de la configuration matérielle (notamment processeur et mémoire vive) du poste de l'utilisateur.

Voir les liens suivants :
http://access.developpez.com/faq/?page=Fichier#GestionFic (consulté le 10 septembre 2008)
http://access.developpez.com/faq/?page=Automation#shellexecute (consulté le 10 septembre 2008)

"A partir de combien de notices peut-on considérer la base de données comme peu fiable?
La base est-elle capable de gérer convenablement la recherche et l'affichage de documents numériques au delà de 2000 notices ?"

Tout dépend ce que l'on entend par "fiabilité".
Selon que l'on est développeur, administrateur ou simple utilisateur de la base de données, plusieurs critères sont importants :

D'une part, la capacité de la base à préserver les données dans un état cohérent (éviter - par exemple - que la base contienne des données correspondant à un document qui a été supprimé).
Cela dépend fortement de la structure de la base de données. Pour cette raison, il est recommandé de confier sa conception à un spécialiste si la cohérence des données est importante. Celui-ci sera plus ou moins limité dans sa volonté de concevoir une base robuste par les caractéristiques techniques du système de gestion de bases de données sur lequel elle sera hébergée. De ce point de vue, Access n'est clairement pas le système de base de données le plus évolué. En effet, ce logiciel est destiné aux petites applications à usage interne et ne convient pas à la gestion de données sensibles.

"D'autre part, les performances et la réactivité."
Access à la particularité d'être un logiciel dit "standalone" (qui s'exécute sur le poste de l'utilisateur), contrairement à la majorité des autres systèmes de gestion de bases de données qui sont conçus pour être déployés sur un serveur central, lequel va être interrogé par les applications clientes (on parle alors d'architecture "client-serveur").
Donc, lorsque vous utilisez Access, plus votre poste est performant, plus l'application sera réactive et capable de supporter une lourde charge donc de gérer un grand nombre de notices sans saturer votre système.
Donner un nombre critique de notices avant que cela ne se produise est impossible car cela dépend de la configuration de la machine que vous utilisez.
De plus, cela dépend également fortement du volume que représente chaque notice, de la façon dont elles sont structurées, et du degré d'optimisation des requêtes qui les manipulent.

Enfin, la stabilité de l'application (éviter les "plantages" du logiciel ou du système d'exploitation).
Access en soi-même est un logiciel relativement stable à condition bien sûr que la base soit bien conçue, que les scripts exploitant les données ne contiennent pas de bogue, que la machine de l'utilisateur ait une configuration matérielle suffisante au vu du volume des données, et que son système d'exploitation soit également stable. Or, c'est souvent là que le bât blesse : un poste de travail sous Windows est loin de pouvoir garantir la même stabilité et la même disponibilité que - par exemple - un serveur sous un système UNIX. Il se peut que cela soit un problème ... ou pas. A vous de voir.

"Je sais que tout dépend de la qualité et de la clarté de l'implémentation, mais n'y-a-t-il pas des préconisations générales à respecter?"
D'une façon générale, il vaut mieux anticiper l'évolution des besoins : savoir comment faire lorsqu'il faudra ajouter des fonctionnalités, si le volume des données ou le nombre d'utilisateurs augmentent etc ...
Il faut être sûr que la solution que vous choisirez permettra ces évolutions de façon à ne pas être "coincé" lorsque cela arrivera.

Par exemple, si plusieurs utilisateurs sont amenés à travailler simultanément sur la base, ou si cela est susceptible de se produire à l'avenir, il est fortement recommandé d'opter pour un système de base de données "client-serveur" tel que MS SQL Server, Oracle, MySQL ou PostgreSQL. En revanche, contrairement à Access, ces logiciels ne fournissent que les fonctionnalités de gestion des données et non les interfaces graphiques qui permettent à un être humain "normalement constitué" de les manipuler. Dans cette hypothèse, il faudra confier à un développeur le soin de créer de telles interfaces à l'aide d'un langage de programmation.

En résumé, la recommandation que je peux vous faire est de vous adresser à un spécialiste qui saura - au minimum - vous conseiller. En effet, il semble que votre projet soit relativement évolué (un catalogue de données bibliographiques avec un moteur de recherche, cela n'est pas rien) et que vous ayez des exigences en termes qualité puisque vous vous renseignez sur le sujet.
Or, si quelqu'un de suffisamment à l'aise avec l'outil informatique peut arriver à créer une petite application avec Access cela restera du "bricolage" : cela peut rendre service un temps mais on ne peut pas compter dessus à moyen ou à long terme si telle est votre intention.
Pour cette raison, la collaboration et la communication entre vous et les informaticiens (qu'ils soient internes à votre organisme ou prestataires) est primordiale, en particulier lors de l'étude des besoins.
Département de l'informatique - Service TIC - enssib

MOTS CLES : Traitement de l'information : Catalogues,
Traitement de l'information : Informatique documentaire