Audit des bases : le bilan

Premiers constats : la grande majorité des bases Alex (pas toutes) se trouvent dans un bon état d'intégrité physique (ie : au sens 4D du terme), les sites web sont pour la plupart dans leur présentation d'origine, les connecteurs ne sont jamais utilisés (sauf quelques fils RSS) et il existe une grande disparité dans la gestion des logs.

Exploitation

Logs

Les bases accessibles sur internet sont soumises à de très nombreuses requêtes, chaque accès à un enregistrement donnant lieu à une écriture au log. Nous avons rencontré des bases avec plusieurs millions d'enregistrements dans le log. Ceci provoque d'importants ralentissements de la base. Ces logs sont nettoyés et l'utilisation de l'outil d'administration des logs est inclus dans la présentation des nouveautés.

Historique des emprunts

Les statistiques sur les emprunts exploitent l'historique. Cependant, au delà d'un certain nombre d'années, ces derniers ne sont plus pertinents. Ils peuvent alors être supprimés de la base.

Messages

Les emails envoyés depuis plusieurs années peuvent être supprimés de la base. En général, ils concernent des envois de DSI ou encore des relances. Les conserver ne présente aucun intérêt, ils peuvent être supprimés.

Programmation

Scripts

Les erreurs rencontrés dans les scripts et ressources web génériques sont automatiquement corrigés par le convertisseur. Par contre, lorsqu'une base comporte des scripts spécifiques (quelqu'en ait été celui qui l'a réalisé), un export est réalisé et une analyse syntaxique est effectuée. Les erreurs de syntaxe des scripts sont corrigées avant la remise en exploitation. Une erreur de syntaxe peut engendrer une instabilité de la base (plantage) c'est pourquoi il est important, afin de retrouver un comportement stable, de corriger ces scripts.

Ressources web

Ceci est l'excercice le plus délicat. Lorsque les ressources n'ont pas été modifiées, un annule et remplace peut être opéré. Par contre lorsqu'une personnalisation a été effectuée, la mise en place des nouvelles ressources nécessite de comparer les anciennes ressources et les nouvelles.

Interface web

Nous avons rencontré beaucoup d'interfaces bleues (menus tout bleu, fonds de page bleu clair). Nous n'avons rien contre le bleu mais dans la plupart des cas, cela ne correspond en rien à la charge graphique du site intranet ou internet. Lorsque cela es possible, nous nous efforçons de donner au site du centre de documentation ou de la bibliothèque un "look and feel" comparable à celui du site général (exemple : ISARA et sa bibliothèque ; l'Agence de l'eau Rhin Meuse et son centre de documentation).

La gestion de contenu

Les premiers éléments sont mis en place afin qu'une véritable application puisse être développée (a minima : la page d'accueil). Cependant, c'est une autre dimension que prend alors l'application et il convient de mener une phase d'analyse structurée avant de se lancer dans la réalisation des pages : "que dire et à qui ?".

Le rôle de "guest" et des centres d'intérêt

Le contenu de la page d'accueil peut être automatiquement alimenté pour tout le monde en fonction du profil de l'utilisateur générique "guest" et de ses centres d'intérêt. Si cette fonction s'avère utile et si elle n'est pas encore en place, l'utilisateur guest est créé et des centres d'intérêt lui sont attachés.

Groupes et autorisations

Les bases issues d'une conversion depuis une version 5 ou antérieure ont, en général, conservé les groupes générés automatiquement lors de la conversion. Ces groupes sont remaniés (a minima, une recommandation est émise) afin de tenir compte de la réalité des attributions de chacun au sein des équipes en place.

Une discussion ouverte, un véritable échange

La phase sur site de la migration est l'occasion d'un échange fructueux. C'est une des (trop) rares occasions de pouvoir échanger sur l'utilisation de sa base de données, d'évoquer des projets, d'ouvrir des horizons... bénéfique pour tout le monde.