Rares sont les projets informatiques qui arrivent directement à la phase « Base de données » sans passer par d’autres outils plus simples en amont. Ce peut être un jeu de fiches cartonnées, un répertoire papier, un logiciel basique dédié à l’usage envisagé ou l’incontournable boite à outils de tout utilisateur de bureau : le tableur.
Et puis, petit à petit, les limites de l’outil en cours se font sentir de façon de plus en plus importante : des lourdeurs au quotidien, des erreurs, des formules alambiquées pour faire ressortir l’information de valeur, une difficulté à partager les données ou à être plusieurs à s’en servir à la fois… le moment est venu de passer à autre chose. Généralement, il se passe au minimum plusieurs mois avant que cette étape soit atteinte : le besoin a suffisamment mûri et vous avez l’impression d’avoir exploré le périmètre complet du besoin à informatiser.
C’est à ce stade de la réflexion (« je vois les limites de mes outils, je veux faire mieux, plus simple, plus vite et plus sécurisé ») que la base de données devient un choix envisageable. L’autre possibilité consiste à regarder s’il n’existe pas un outil logiciel qui existe déjà et qui fait exactement ce que vous souhaitez. Au pire, les outils déjà disponibles sur le marché permettent-ils des modifications ?
Les points à valider afin de passer sereinement à une base de données
Votre besoin est-il suffisament mature ?
Si c’est pour tout changer dans 1-3-6 mois, ce n’est pas encore le bon moment. Si vous êtes créateur d’entreprise, la tentation est grande de vouloir avoir les outils parfaits dès le début de l’activité. Sauf à connaître précisément l’activité, il y a peu de chance que l’activité n’évolue pas au fil des 36 premiers mois et vous risquez de vous retrouver avec une base de données ne répondant plus à votre besoin.
Ou bien, prévoir un socle suffisamment évolutif et garder en tête que ce premier jet sera amené à évoluer dans les mois qui viennent. Il faut alors garder du budget pour plus tard et affecter maximum 20% du budget à la création initiale.
Vos outils actuels vous empêchent-ils de faire ce que vous voulez ?
Ou bien est-ce juste pour essayer autre chose ? Ce n’est pas parce qu’un outil vous semble limité qu’il l’est vraiment. Et une décision rationnelle est toujours préférable à un coup de coeur (ou un coup de sang, c’est selon votre façon de fonctionner). L’herbe semble toujours plus verte ailleurs et vous serez certainement séduits et aiguillonés par des outils qui semblent répondre parfaitement à votre besoin.
L’expérience prouve que les solutions miracles n’existent pas et qu’il y a toujours des fonctionnalités manquantes, des problèmes de migration, des régressions fonctionnelles… Si vos outils vous bloquent vraiment, il faut absolument prendre le temps de bien comparer les différentes possibilités, privilégier les plus simples à mettre en place (souvent une amélioration de l’existant), recenser exactement les besoins, prendre le temps de comparer et enfin tester pour de vrai (avec de vraies données tout le process).
Vous avez l’impression de perdre du temps ?
À part perdre ses données et ne pas avoir confiance dans son outil, rien de pire qu’un outil qui rame. Si la saisie des informations est lente, si l’extraction des données met plus d’une seconde à s’afficher, si aucune indication graphique ne permet de distinguer un temps de chargement d’un temps perdu, alors oui, il faut envisager une nouvelle solution.
Si votre solution actuelle est trop lente, avant de changer d’outil, plusieurs solutions sont à tester :
- Faire le ménage et supprimer / archiver les données obsolètes ;
- Augementer les ressources. Si votre outil est en ligne, vous pouvez certaintement faire un essai de quelques jours avec un(plan supérieur pour tester. Idem si l’outil est en local : vous pouvez tenter d’y accéder depuis un machine plus puissante.
- Changer de configuration. Si vous accédez à votre application via un navigateur, tentez de le remplacer temporairement par un autre. Parfois, ça suffit.
Vous avez l’impression de ne pas profiter de la richesse de vos données ?
Collecter de la donnée et ne pas l’utiliser est du gâchis. Et c’est contre la logique de minimisation des données chère au RGPD et une bonne pratique numérique : on ne collecte que ce dont on se sert vraiment. Si maintenant, vous avez de la valeur cachée dans vos données et que votre outil vous empêche d’y accéder, est-ce qu’une migration vers une base de données est vraiment nécessaire ?
Il existe peut-être des passerelles pour extraire vos données et les exploiter dans un autre outil. Les outils de business intelligence et les solutions proposées dans le cloud sont souvent pré-configurés avec des connecteurs qui peuvent à minima travailler à base de données tabulaires (CSV ou tableur). Même si les données ne sont pas bien organisées, la puissance des algos et les solutions techniques permettent de faire parler la donnée.
Est-ce une obligation ?
Il se peut que votre organisation soit soumise à des contraintes légales (données personnelles), des normalisations exigeantes (ISO) ou des référentiels de sécurité informatique bien particuliers. Dans ces cas précis, la bascule vers une base de données peut être nécessaire et des modifications importantes impacteront certainement tout le système d’information.
Est-ce que personne ne sera oublié ?
Votre solution actuelle fonctionne peut-être parfaitement pour certains collaborateurs. Mais pas pour tous. Il ne faudrait surtout pas que le nouveau système de base de données satisfasse les utilisateurs qui éprouve des difficultés mais desserve les anciens utilisateurs satisfaits.
Les bases de données sont souvent des outils structurants et un changement de base de données est souvent une révolution pour les utilisateurs. Dans le bon comme dans le mauvais sens. Il faut que le périmètre fonctionnel soit au moins le même et que l’adaptation au changement soit prévu. Ou bien risquer un mésusage et de l’insatisfaction avec la nouvelle solution.
La base actuelle échange aussi peut-être avec d’autres outils via des échanges automatisés. Ces intégrations et dépendances, qu’on oublie trop facilement quand elles fonctionnent, s’interfaceront-elles aussi bien avec le nouveau système ?
Est-ce rentable ?
Une fois la migration réalisée, est-ce que les bénéfices à l’utilisation de l’outil surpassent les coûts engendrés par la migration ? Il faut regarder les éléments financiers mais aussi le temps passé et la satisfaction des utilisateurs et des bénéficiaires. Les ressources affectées à la migration peuvent être amortis sur 3 ans ou plus suivant la durée de vie prévue d’utilisation de la base de données.
Pouvez-vous revenir en arrière ?
Si vraiment ça se passe mal, est-il possible de revenir à la situation précédente ? On parle ici de rétrocompatibilité pour intégrer les nouvelles données dans l’ancien système ou de solution de repli pour effacer et repartir de l’ancienne solution avant la bascule.
Avez-vous les ressources ?
Avez-vous les poches suffisamment profondes et du temps devant vous pour envisager une migration vers une base de données ?
Les bases de données qui durent le plus longtemps sont celles dans lesquelles du temps et de l’argent ont été investis. Un changement d’outil réussi se mesure non pas dans la rapidité de migration mais dans le gain au quotidien une fois que la nouvelle solution est en place. Et pour que la migration se passe bien, il faut la préparer : recueil des fonctionnalités, tests techniques, tests avec les utilisateurs réels, montée en charge, import de données partiel puis import complet, sauvegardes, extractions… Plus le précédent outil a été utilisé longtemps, plus la migration risque d’être complexe.