Construire une base de données est long et généralement onéreux. Alors est-ce que ça vaut vraiment le coup ? En combien de temps, une base de données s’amortit-elle et quelle est sa durée de vie ?
À partir du moment ou la base de données a été correctement conçue (c’est à dire bien modélisée et intelligemment déployée), sa durée de vie peut être très longue. En informatique, 3 ans est considéré comme long mais une base de données peut être utilisable pendant plus de 10 ans sans être remise en cause.
Quand faire évoluer une base de données ?
Il existe 3 aspects différents qui vont influer sur la durée de vie d’une base de données. Certains sont maîtrisables et calculables en amont, d’autres pas du tout.
- Contraintes liées au logiciel retenu : Aujourd’hui, les bases de données se basent toutes sur des SGBD. En vieillissant, la base de données peut pousser le logiciel dans ces retranchements et provoquer des goulots d’étranglements : trop de données (plus de place, trop d’information à traiter rendant l’outil lent ou pénible à utiliser), trop d’accès en concurrence, des calculs trop importants… Les SGBD peuvent eux-aussi évoluer pour corriger des bugs, ajouter des fonctionnalités et parfois les montées de version (obligatoires pour bénéficier du support ?) nécessitent de re-développer des briques de la base de données.
- Contraintes liées aux technologies sous-jacentes : C’est la raison la plus pénible. Parce que l’informatique évolue, la compatibilité avec les anciens logiciels est plus ou moins assurée. Une base de données peut alors de retrouver caduque à cause des évolutions logicielles du système d’exploitation, de l’espace d’hébergement, de la rupture avec la technologie précédente. Dans la majorité des cas et comme pour le point précédent, il y a « juste » à adapter la base de données pour qu’elle fonctionne de nouveau avec les technos récentes.
- Contraintes liées à l’évolution du besoin : C’est la raison « normale » d’une évolution. Le besoin de l’entreprise évolue. Le process à informatiser a changé et il faut que l’outil le reflète. On est ici dans la vie du logiciel et cela peut se faire de 2 façons différentes :
- on attend que la solution actuelle devienne vraiment obsolète et on change tout. Solution privilégiée lorsqu’aucun budget n’est prévu pour les améliorations courantes, cette façon de faire est laborieuse. Le moment charnière lié à la bascule entre ancienne et nouvelle version nécessite une bonne préparation (cohérence des données, formation des utilisateurs, résistance au changement…).
- on améliore en permanence la solution en travaillant de façon itérative. Les structures qui ont la chance d’avoir un professionnel compétent en interne privilégie cette solution car elle permet d’intégrer en douceur les changements. D’autres contraintes peuvent alors survenir et ces dernières sont bien connues des informaticiens (produire des modifications solides, propres et documentées pour assurer la maintenabilité des modifications mises en place, former les utilisateurs, améliorer dans le cadre d’un plan d’ensemble de concert avec la direction…).
Faire évoluer une base de données : quoi garder ? quoi jeter ?
Dans la majorité des cas, les fondamentaux d’une base de données sont conservés : les données et la logique qui les relie (la modélisation) est conservée et/ou peu altérée. De nouvelles règles métier viennent se brancher sur l’existant et de nouvelles fonctionnalités sont mises en place.
Pour le reste, c’est à dire les technos utilisés, les écrans proposés, les fonctionnalités d’accès aux données (en saisie, en recherche, en lecture), il est fréquent qu’une évolution remette en cause ces aspects.
Très simplement : données + modélisation conservés, technos et écrans utilisateurs renouvelés.