Les erreurs de conception de base de données que je vois le plus souvent

La base de données est la partie la moins réversible d’une application. Le code se réécrit ; un modèle de données rempli de plusieurs années d’historique se migre, avec précaution et avec un plan de retour arrière.

Voici les six erreurs que je retrouve le plus souvent en audit. Aucune n’est exotique. Toutes sont bon marché à éviter et chères à corriger.

1. Les contraintes d’intégrité laissées au code

Ce que je vois : pas de clés étrangères, pas de contraintes d’unicité, pas de vérification de valeurs. « On le gère dans l’application. »

Pourquoi ça casse : l’application n’est jamais le seul chemin vers la base. Il y a le script d’import ponctuel, la correction manuelle en urgence un vendredi soir, le traitement de reprise, et un jour une deuxième application. Chacun de ces chemins peut écrire une incohérence, et rien ne l’arrête.

Le résultat se voit toujours de la même façon : des commandes rattachées à des clients qui n’existent plus, des doublons que personne ne sait départager, des totaux qui ne tombent plus juste.

La correction : déclarer les contraintes dans la base. Le moteur les fait respecter quoi qu’il arrive, y compris pour le script écrit à la va-vite. C’est la meilleure assurance qualité qui existe, et elle est gratuite.

2. La suppression physique

Ce que je vois : une action « supprimer » qui efface réellement la ligne.

Pourquoi ça casse : un utilisateur supprime un dossier par erreur, et il n’y a aucun moyen de savoir ce qu’il contenait — sauf à restaurer une sauvegarde complète, ce qui écrase le reste.

Plus subtil : les données référencées ailleurs. Supprimer un client dont on a facturé des commandes rend l’historique de facturation incohérent, et les rapports de l’an dernier changent de valeur.

La correction : archiver plutôt que supprimer. Une colonne de date d’archivage, et les requêtes courantes excluent les lignes archivées. La donnée reste consultable, restaurable, et l’historique demeure exact.

3. Les dates sans fuseau horaire

Ce que je vois : une date-heure stockée sans information de fuseau.

Pourquoi ça casse : ça fonctionne parfaitement jusqu’au premier changement d’heure. Puis on découvre des rendez-vous décalés d’une heure, deux fois par an, et une heure qui existe en double fin octobre.

Cela casse aussi dès qu’un utilisateur se connecte depuis un autre pays, ou que le serveur est hébergé sur un autre fuseau que les utilisateurs — ce qui arrive plus souvent qu’on ne le prévoit.

La correction : stocker en UTC avec le fuseau, convertir à l’affichage. Décision de cinq minutes au début, migration délicate ensuite — parce qu’il faut deviner rétrospectivement dans quel fuseau chaque date avait été saisie.

Photo : rawpixel — licence CC0.

4. Les montants en nombres flottants

Ce que je vois : des prix stockés dans un type à virgule flottante.

Pourquoi ça casse : ces types ne représentent pas exactement les décimales. Les écarts sont minuscules, invisibles à l’unité — et ils s’accumulent. Une somme de dix mille lignes finit par tomber à un centime près, puis à deux.

Un centime d’écart sur un rapprochement comptable est un problème sérieux, et le déboguer est particulièrement ingrat.

La correction : un type décimal exact, ou des entiers en centimes. C’est une ligne de définition, et ça évite une catégorie entière de problèmes.

Photo : domaine public (CC0).

5. Les statuts en texte libre

Ce que je vois : une colonne texte qui contient « en cours », « En cours », « EN_COURS » et « en cours de traitement ».

Pourquoi ça casse : aucun filtre n’est fiable, aucun rapport ne tombe juste, et la logique métier se remplit de conditions défensives pour rattraper les variantes. Personne ne sait plus quelle est la liste exhaustive des statuts possibles.

La correction : une contrainte de valeurs autorisées, ou une table de référence. Et surtout, un endroit unique dans le code qui définit les transitions permises. Un statut ne devrait jamais pouvoir passer de « annulé » à « livré », et c’est le genre de règle qui se perd si elle n’est écrite nulle part.

6. L’absence d’index sur les colonnes de filtrage

Ce que je vois : des tables sans index en dehors de la clé primaire.

Pourquoi ça casse : tout va bien avec mille lignes. À cent mille, les pages mettent trois secondes. À un million, elles expirent. La dégradation est progressive, donc personne ne l’attribue à sa cause — on parle de « l’application qui rame », et on soupçonne le serveur.

La correction : indexer les colonnes utilisées pour filtrer, trier et joindre. Et vérifier en conditions réelles : un index qui semble juste peut ne pas être utilisé selon la façon dont la requête est écrite.

Attention à l’excès inverse : chaque index ralentit les écritures. On indexe ce qu’on interroge, pas tout.

Photo : MichaelGaida — licence CC0.

Deux erreurs plus rares, et plus graves

Stocker plusieurs valeurs dans une seule colonne. Une liste d’identifiants séparés par des virgules, un peu de JSON dans un champ texte pour « aller plus vite ». Cela fonctionne à l’écriture, et cela rend toute requête de filtrage impossible à indexer — donc lente, puis inutilisable. La correction est une migration lourde, parce qu’il faut créer une table de liaison et redistribuer les données existantes.

Utiliser une donnée métier comme identifiant. Le numéro de client, la référence produit, le SIRET. Ils semblent uniques et stables. Ils ne le sont pas : une fusion d’entreprises, une renumérotation, une correction de saisie, et l’identifiant change — entraînant tout ce qui le référence. Un identifiant technique, sans signification, coûte une colonne et évite ce scénario.

Comment je repère ces problèmes en audit

Je ne lis pas le modèle en premier. Je regarde trois choses, plus rapides et plus parlantes.

Les contraintes déclarées. Une base sans clé étrangère se repère en une requête sur le catalogue système. C’est le meilleur indicateur unique de la rigueur du modèle.

Les types de colonnes. Chercher les colonnes de montants en flottant et les dates sans fuseau prend deux minutes et donne immédiatement le niveau d’attention porté à la modélisation.

Les valeurs distinctes des colonnes de statut. Une requête de comptage par valeur révèle instantanément les variantes de casse et les libellés en double.

En un quart d’heure, ces trois vérifications donnent une image assez fidèle de ce qui attend l’équipe. Elles sont aussi un bon test à faire sur sa propre base, sans attendre qu’un tiers vienne le faire.

Ce que ces six erreurs ont en commun

Aucune ne casse quoi que ce soit le premier mois. Toutes deviennent visibles entre un et trois ans, quand la base est pleine et que la migration est un projet à part entière.

C’est précisément pour cela qu’elles sont si fréquentes : au moment où la décision se prend, rien ne signale le problème. Il n’y a pas de test qui échoue, pas d’alerte, pas de ralentissement.

C’est aussi pour cette raison que je considère la modélisation comme la partie du travail qui mérite le plus d’attention en début de projet — et celle qu’il ne faut jamais expédier pour gagner deux jours.