Une base de données est un logiciel plutôt « lourd ». Prévu pour fonctionner longtemps (plusieurs années), il nécessite une phase de réflexion en amont qui modélise des processus métiers. Ces processus sont informatisés, les données sous-jacentes sont décortiquées et logiquement organisées. Par dessus tout cela, un ensemble de vues (les écrans que voient les utilisateurs, de calculs (des statistiques, des rapports, des exports) et de contrôles (droits et sécurité des données) sont ajoutés. L’ensemble fonctionne au sein d’un périmètre technique identifié et borné.
Lorsqu’un besoin de modification se fait sentir, la tâche est plus ou moins complexe suivant l’impact attendu sur la base de données existante.
Les points « faciles » à modifier sur une base de données en production
- Les modifications cosmétiques sont les plus simple à mettre en place : changer les vues des utilisateurs (couleurs, tailles, menus, supports…).
- Les modifications liées aux contrôles sont relativement aisés à modifier : la gestion des droits, si bien pensé pendant la phase de conception, est facile à faire évoluer.
- Les fonctions périphériques sont elles aussi plutôt rapides et peu impactantes sur l’ensemble : changer un export ou une moulinette d’import, présenter des statistiques d’une nouvelle façon, faire un lien avec un autre outil… c’est jouable.
Les points « ardus » à modifier sur une base de données en production
- Ajouter des données. Rajouter des « champs », compléter une fiche avec une nouvelle zone, agrémenter la base de nouvelles informations que les opérateurs devront remplir, des opérations simples mais qui nécessitent de reparcourir l’ensemble de l’outil. Des oublis sont facilement commis. Et que faire des anciennes données ? Faut-il toutes les reprendre pour remplir les nouveaux champs afin d’avoir un système homogène ?
- Modifier des données. Parce que l’on touche au coeur de l’outil, les impacts seront répercutés partout. Prudence maximale.
- Supprimer des données. Opérations à faire en prenant toutes les précautions nécessaires. Ce sont les impacts indirects qui sont souvent sous-estimés : tel lien avec ce logiciel métier qui fonctionne si bien qu’on l’avait oublié, tel rapport qui ne peut plus s’éditer, tel statistique qui devient fausse car une partie des données nécessaires a disparu. La difficulté est ici de ne rien oublier. C’est un travail fastidieux sur lesquels les décideurs passent parfois un peu trop vite. Le risque est essentiellement humain plutôt que technique.
- Faire évoluer les process métiers. C’est le pire des cas. La logique interne de l’outil doit évoluer. Un nouveau travail de modélisation doit être entrepris et il faut trancher : que faire de l’ancien fonctionnement et des données déjà rentrées dans le système ? L’archiver, le faire évoluer ? Qui s’en charge ?
- Changer d’infrastructure technique. Un problème technique pour les techniciens. Difficile à estimer et à mettre en oeuvre sans aucun effet de bord à cause de la complexité inhérente à l’informatique (la fameuse loi de Hofstadter). La simple montée de version n’est peut-être pas si simple à réaliser, il y a toujours des cas particuliers auxquels on avait pas pensé…
- La résistance au changement des utilisateurs. « Je préférais avant, alors je continue à faire comme avant… ».
Comment bien modifier une base de données ?
La solution de disposer de 2 bases de données est la meilleure lorsque la base est utilisé régulièrement. La base de production ne change pas et la base de test sert aux modifications. Un panel d’utilisateurs motivés, moteurs et force de proposition accepte de jouer le jeu et de faire double travail en intervenant sur la nouvelle mouture tout en continuant à travailler sur l’ancien système. Une fois que tout a été validé en détail, les modifications sont poussées en production.
Enfin, c’est une évidence : toujours sauvegarder et versionner ses bases de données (la logique et les données qui sont contenus à l’intérieur).
