Amanéa Voyages · application métier en production · 2025-2026
Fiabiliser un schéma de base en production
Le schéma garantit-il que les contenus publiés restent cohérents et correctement adressés ?
Contexte et données
Base MySQL de 17 tables, 13 modèles et 24 contrôleurs côté application. Contenus éditoriaux, destinations, voyages avec étapes, projets clients et carnets de voyage. Application vivante, avec des données réelles : toute modification de schéma devait rester rétrocompatible.
Méthode
Audit table par table, à la recherche de trois familles de défauts : attributs non atomiques, contraintes d'intégrité manquantes, relations mal placées.
- Attributs atomisés. Durée, nombre de personnes et saisonnalité d'un voyage vivaient en texte libre ("14 jours", "Mars – Mai"). Devenus des champs numériques dédiés — jours, couple min/max, deux mois de début et de fin.
- Contraintes ajoutées. Contrainte UNIQUE sur le slug des articles et des destinations : deux URL identiques ne peuvent plus exister en base. L'application, elle, ne distingue pas encore ce cas précis d'une autre erreur — l'utilisateur voit un message générique, pas la vraie cause.
- Relations corrigées. Sur les articles, la couverture passe par une table de liaison dédiée vers les médias plutôt que par un chemin en dur ; sur les voyages, elle devient une clé étrangère directe.
Résultat
Deux articles ou deux destinations ne peuvent plus partager la même URL : la base le refuse. La durée, la capacité et la saison d'un voyage sont saisies une seule fois en back-office, sous forme de champs numériques, et mises en forme de façon uniforme sur les six pages publiques qui les affichent. Les couvertures des articles et des voyages se gèrent depuis le back-office, reliées à la médiathèque plutôt que codées en dur.
Ce que j'en retiens
Trois choix de modélisation méritent d'être expliqués.
Seule vraie dénormalisation assumée du lot : la destination d'un projet client reste un champ texte libre obligatoire — un client peut demander une destination hors catalogue, la contrainte aurait rendu le métier impossible. Elle est doublée d'une clé étrangère optionnelle, mais celle-ci ne sert qu'à résoudre l'image de couverture par priorité, jamais à rendre la destination du projet interrogeable par catégorie. Ce n'est pas un refus de la clé étrangère : c'est une clé étrangère à portée volontairement limitée.
Le mot-clé d'illustration reste sur la table des articles plutôt que sur celle des destinations : deux articles sur le même pays peuvent avoir des ambiances visuelles différentes, le placer sur la destination aurait imposé le même visuel à tous les articles d'un même pays.
La couverture d'un contenu passe par deux relations distinctes plutôt qu'une seule avec un indicateur — une pour la couverture, une pour la galerie. Sur la table de liaison de couverture, l'identifiant de l'article est lui-même la clé primaire : la structure garantit à elle seule qu'un article n'a jamais qu'une seule couverture, sans qu'aucun contrôle applicatif n'ait besoin de l'imposer — contrairement à la galerie, qui accepte plusieurs médias par article. Fusionner les deux relations aurait rendu chaque requête ambiguë sur ce qu'elle récupère réellement.
Une dette reste identifiée et non soldée : la couverture d'une destination est toujours un chemin stocké en dur, pas une clé étrangère — la même correction que sur les articles et les voyages, pas encore appliquée ici.
L'atomisation de la durée, du nombre de personnes et de la saisonnalité a été pensée pour permettre un filtrage à venir. Aujourd'hui, elle sert un affichage cohérent sur plusieurs pages et une saisie fiable en back-office — la recherche par ces critères reste à construire.