Pédagogie de la base de données

Inséré dans le texte complet !

Toute association la plus modeste soit-elle gère des données : la liste des adhérents, la trésorerie, l'annuaire des contacts, etc. L'outil le plus simple pour répondre à ce type de besoin est le tableur (par exemple, celui de LibreOffice). C'est un outil d'une grande souplesse, facile à prendre en main et qui offre de nombreuses possibilités de traitement et d'analyse. Il est souvent inutile de mettre en place une solution plus sophistiquée que le tableaur si le volume de données traitées est faible.

Le tableur montre cependant rapidement ses limites lorsque :

• le volume et la complexité des donnnées augmentent : les données ne peuvent plus tenir dans une table unique
• plusieurs personnes interviennent sur la saisie de données : la souplesse du tableur le rend alors vulnérable à la maladresse d'une personne.

Dès lors, la seule solution est de mettre en place une base de données avec deux pistes :

• soit utiliser un outil générique de gestion de bases de données (par exemple, le module de LibreOffice, la combinaison PHP/MySql sur un serveur, etc.) et développer sa propre application ł maison »
• soit utiliser une application existante qui propose un modèle de données et une série d'interfaces les manipuler (par exemple, un logiciel de comptabilité )

La première piste est celle qui offre la plus grande liberté mais qui demande le plus fort investissement. C'est parfois l'unique solution lorsque l'association gère des données spécifiques à son domaine d'action et qu'aucune application existante ne propose un modèle de données satisfaisant. La plupart des applications métiers sont nées ainsi.

Dans le cas d'une application existante, il faudra être vigilant sur ses capacités d'adaption car un modèle de données n'est jamais figé et évolue dans le temps en fonction de son appropriation et de son utilisation.

Quelque soit la piste retenue, la gestion d'une base de données doit répondre à deux enjeux qui sont parfois en opposition :

• l'enjeu de la saisie : si l'on désire que la saisie des données soit l'œuvre de plusieurs personnes et non d'un responsable unique, il faut que le cout d'apprentissage de l'interface soit le plus bas possible (en particulier, si les personnes n'utilisent pas régulièrement) et que son usage soit le moins rébarbatif possible.
• L'enjeu de la valorisation : les données doivent être utiles et utilisées : publipostage, consultation en ligne en interne ou publique, états et rapports, les possibilités sont nombreuses, l'association doit identifier celles qui sont les plus pertinentes pour elle.

« Saisie » et « Valorisation » peuvent se trouver en opposition car l'impératif d'une saisie correcte poussera à la simplicité du modèle des données alors que l'envie d'une valorisation riche et diverse poussera à sa complexification. Par exemple, saisir une adresse complète dans un champ de texte unique est plus rapide (en particulier si l'adresse vient d'un copier-coller) que de la décomposer avec un champ pour chaque ligne, un champ pour le code postal, un champ pour la ville ; mais le jour où il faut grouper les adresses par ville ou par département, le modèle des champs séparés est le plus efficace.

Cependant, en cas d'arbitrage, ce sont les contraintes de saisie qui doivent l'emporter sur les désirs de valorisation suivant la règle d'or : l'absence de données vaut mieux que des données fausses ou peu fiables !

La mise en place d'une base de données change les pratiques de travail, il faudra donc particulièrement veiller à ce que les personnes chargées de la saisie aient une compréhension de l'ensemble du processus et de l'intérêt stratégique que représentent ces données pour l'association, l'idéal étant que ces personnes tirent un bénéfice immédiat de la bonne qualité de ces données dans le cadre de leurs missions au sein de l'assocation : c'est la meilleur garantie d'une saisie rigoureuse et régulière.