base de données : extrait d'une table

La difficile transition d’Excel vers une base de données

Les bases de données sont géniales. Vraiment. C’est écrit un peu partout sur ce site et sur le reste du web. Mais à tout le temps dire qu’une base de données est top on oublie parfois que les autres méthodes, et principalement les tableurs, ont des atouts qu’on ne retrouve pas – ou plutôt pas aussi facilement – dans une base de données.

Le tableur permet d’aller vite

Les bases de données aussi mais pas de la même façon. Une base de données est idéale lorsque le besoin à informatiser est bien délimité et plutôt stable. S’il faut tout casser et tout reconstruire tous les 12 mois parce que le besoin change, la souplesse et la rapidité de mise en oeuvre d’un tableur est très appréciable.

Pour modifier une base de données, il faut prendre le temps de bien faire : il faut éventuellement revoir la structure des tables (les développeurs n’aiment pas), reconstruire les écrans, re-paramétrer les imports/exports/stats, revoir les différentes fonctionnalités et liaisons entre les données.

Et comme on ne joue pas avec les vraies données, il faut certainement créer des copies, s’assurer qu’il n’y a pas de conflit avec la base en production (des alertes ou des emails automatiques par exemple) et procéder à des séries de tests en bonne et dû forme. Bref, c’est du boulot et ça prend du temps.

Le tableur permet de gérer les cas spéciaux et de bidouiller

Dans une base de données, tout est standardisé, bien rangé et les données sont suivies de prêt. C’est ce que l’on attend de ce type d’outils. Mais lorsqu’un cas imprévu se présente (pas vu lors de l’analyse, un oubli, une tâche qu’on ne fait qu’une fois par an, un nouveau cas tordu qui ne « rentre pas dans les cases », on se trouve bien embêté avec une base de données.

On contourne alors les contraintes de l’outil pour « faire rentrer » les données. Ça nuit à l’ergonomie, ça empêche d’avoir des statistiques vraiment justes mais ça règle temporairement le problème.

Avec un tableur, ce genre de problème n’existe pas : facile d’ajouter/supprimer une colonne ou une ligne. Facile de faire un regroupement ou une ventilation à la main. Facile de changer une formule rapidement. Comme les données ne sont pas protégées et qu’il n’y a pas de contrôles d’intégrité, n’importe qui peut faire n’importe quoi. C’est clairement dangereux mais c’est tellement facile.

Alors pourquoi passer aux bases de données ?

Justement, on passe aux bases de données pour avoir des données justes dans lesquelles ont pourra avoir confiance. Parce que la bidouille, ça ne fonctionne qu’un temps. C’est lorsque le chantier base de données est bien enclenché et qu’on se rentre de certaines lourdeurs que l’on regrette la facilité du tableur.

C’est juste un mauvais moment à passer (pour tout le monde, l’utilisateur final, le donneur d’ordre, l’exécutant). Au bout d’un cycle (une année le plus souvent), la base de données est stable et les bénéfices se font sentir à tous points de vue. C’est aussi à partir de ce moment que l’on commence à évoquer la V2 pour améliorer encore ou pour surcharger l’existant avec de nouvelles fonctionnalités.