Une information, un seul endroit
C'est le principe fondateur, et tout le reste en découle. Dans une base bien construite, chaque client existe une fois. Chaque produit existe une fois. Ce n'est pas une question d'élégance, c'est ce qui rend une correction possible : si l'adresse d'un client ne figure qu'à un seul endroit, la corriger une fois suffit à la corriger partout.
Techniquement, cette unicité repose sur la clé primaire, un identifiant propre à chaque enregistrement qui ne peut pas être attribué deux fois. Elle interdit les doublons par construction, et non par vigilance humaine. La nuance est décisive : une règle appliquée par le système tient dans le temps, une règle appliquée par la discipline de chacun finit toujours par céder.
Les liens entre les informations
Une commande appartient à un client. Une ligne de facture appartient à une commande. Un employé appartient à un service. Ces rattachements sont déclarés dans la structure elle-même, par des clés étrangères qui pointent vers l'enregistrement d'origine.
La conséquence pratique porte un nom, l'intégrité référentielle : le système vérifie qu'une commande ne peut pas référencer un client qui n'existe pas. Il devient impossible de créer une facture orpheline, ou de supprimer un client en laissant derrière lui des commandes rattachées à rien. Dans un ensemble de fichiers séparés, ces situations passent inaperçues et ne se découvrent qu'au moment où quelqu'un cherche à comprendre un écart.
Ce qui ne peut pas être saisi
Une base bien conçue refuse ce qui n'a pas de sens. Une date de fin antérieure à la date de début. Un montant dans un champ prévu pour un code postal. Un statut qui ne fait pas partie de la liste autorisée. Un champ obligatoire laissé vide.
Ces règles s'appellent des contraintes, et elles agissent au moment de la saisie plutôt qu'au moment du contrôle. C'est un renversement complet de la charge : au lieu de chercher les erreurs après coup dans un fichier de plusieurs milliers de lignes, on empêche leur entrée. Une base sans contrainte accepte tout, y compris l'absurde, et laisse le travail de vérification à des humains qui ont autre chose à faire.
L'historique, ou la mémoire de l'entreprise
Un tableur écrase. Quand une valeur est modifiée, l'ancienne disparaît sans laisser de trace. Une base peut conserver qui a modifié quoi, quand, et parfois la valeur précédente.
Cette mémoire sert plus souvent qu'on ne l'imagine. Retrouver les conditions accordées à un client il y a deux ans. Comprendre pourquoi un dossier a changé de statut. Reconstituer l'enchaînement des événements après une erreur. Répondre à un contrôle. Sans historique, chacune de ces questions se règle par une reconstitution approximative appuyée sur la mémoire des personnes présentes à l'époque.
Qui voit quoi
Un fichier partagé se protège mal. Soit une personne y a accès et voit tout, soit elle n'y a pas accès et ne voit rien. Une base permet de définir des droits par table, par colonne, parfois par ligne.
Concrètement, un commercial consulte ses clients sans voir les salaires. Un comptable accède aux montants sans modifier les fiches produits. Un stagiaire consulte sans supprimer. Ce n'est pas une question de confiance envers les personnes, c'est une manière de limiter la portée d'une erreur : on ne peut pas effacer par inadvertance ce à quoi on n'a pas accès.
Poser des questions plutôt que chercher
La différence la plus visible au quotidien tient dans cette bascule. Sur des fichiers séparés, obtenir une information croisée consiste à ouvrir, filtrer, copier, coller, recouper. Sur une base, on formule une question et le système répond.
Les clients d'une région sans commande depuis six mois. Le délai moyen entre un devis et sa signature. Les produits dont le stock passera sous un seuil au rythme actuel. Ces questions ne demandent aucune manipulation préalable, et surtout elles peuvent être reposées chaque semaine sans refaire le travail. Une information qu'on peut obtenir en continu finit par être utilisée pour décider. Une information qui demande une demi-journée reste dans le tiroir.
Les signes d'une base bien conçue
Sans entrer dans la technique, quelques indices se repèrent de l'extérieur :
- Aucune information n'est saisie deux fois, à aucun moment du parcours
- Les listes sont fermées plutôt qu'en texte libre, ce qui évite dix orthographes pour le même statut
- Les suppressions sont encadrées et ne laissent jamais d'éléments rattachés à rien
- Chaque enregistrement porte sa date de création et de modification
- Ajouter un cas particulier ne demande pas d'ajouter une colonne
- Une nouvelle personne comprend l'organisation sans qu'on lui explique les exceptions
Le dernier point résume tous les autres. Une structure qui exige des explications orales pour être utilisée correctement repose sur la mémoire de ceux qui la connaissent, et cette mémoire part avec eux.
Ce qu'il faut retenir
Une base de données n'est pas un endroit où l'on range des informations, c'est un ensemble de règles qui les empêchent de se contredire. Sa valeur ne se mesure pas à ce qu'elle contient mais à ce qu'elle refuse : les doublons, les liens cassés, les valeurs impossibles, les suppressions dangereuses.
C'est pour cette raison qu'une structure pensée au départ vieillit bien, et qu'une structure improvisée demande des corrections manuelles de plus en plus fréquentes à mesure que le volume grandit.
