Tout diagramme de schéma commence vrai et finit menteur. Quelqu'un le dessine la semaine précédant le lancement, il gagne une place de choix dans le wiki, puis le produit est livré. Vingt migrations plus tard, il montre toujours une table users sans deleted_at, une table orders qui a depuis été scindée en deux, et une relation supprimée lors d'un refactoring en mars. Les nouveaux ingénieurs le lisent, le croient et construisent sur l'image d'une base de données qui n'existe plus.
La réaction habituelle est la culpabilité : nous aurions dû le tenir à jour. Mais mettre à jour un diagramme à la main après chaque migration est une corvée que personne ne gagne, donc cela n'arrive jamais. La solution durable est de changer l'origine du diagramme. S'il est généré à partir du schéma au lieu d'être maintenu à côté, la dérive devient impossible, car l'image est toujours une vue de la vérité actuelle.
Traitez le diagramme comme dérivé, pas comme rédigé
Votre schéma vit déjà à un endroit canonique : les migrations que vous exécutez et le DDL que vous pouvez exporter depuis n'importe quel environnement. C'est la source de vérité, et elle est lisible par une machine. Un diagramme maintenu à la main est une deuxième copie de cette vérité, et deux copies de quoi que ce soit finissent par diverger. Il faut donc faire du diagramme une projection du schéma, comme un rapport est une projection d'une table : régénéré à la demande, jamais modifié jusqu'à devenir obsolète.
Concrètement, chaque fois que vous voulez l'image actuelle, vous fournissez le schéma actuel et obtenez le diagramme. Pas de réconciliation manuelle, pas de « qui a modifié ça en dernier », pas de relations périmées.
Générez le diagramme ER depuis le DDL que vous exportez déjà
Vous n'avez pas besoin d'un export spécial. Toute base de données peut vous fournir son schéma en SQL, et ce SQL est exactement ce que LetDraw lit. Sur Postgres, c'est une seule commande ; MySQL et les autres ont leurs propres équivalents.
# Postgres: dump just the schema, no data pg_dump --schema-only --no-owner mydb > schema.sql # then: Generate from Code → paste schema.sql → get the ER diagram
Ouvrez la boîte de dialogue Générer à partir du code, collez le fichier, et LetDraw construit le diagramme : des tables avec des colonnes typées, les clés primaires et étrangères marquées, et des liens un-à-plusieurs tracés à partir des clauses REFERENCES avec de vraies terminaisons en patte d'oie. Ce qui demandait un après-midi à faire glisser des rectangles se résume à un collage, et comme cela provient du vrai DDL, c'est correct par construction.
Un diagramme que vous régénérez en dix secondes ne devient jamais obsolète, car personne n'a besoin de penser à le mettre à jour.
Intégrez-le au flux de travail pour qu'il ne dérive jamais
Dès que générer le diagramme ne coûte presque rien, vous pouvez le placer là où il restera fidèle. Quelques habitudes qui rendent la dérive structurellement impossible :
- Régénérez à chaque release. Ajoutez « rafraîchir le diagramme ER depuis
schema.sql» à votre checklist de release. Il faut plus de temps pour lire cette phrase que pour le faire. - Comparez, ne redessinez pas. Quand une migration arrive, générez un nouveau diagramme et comparez. Nouvelle table, nouvelle colonne, clé modifiée : le changement est visible, et vous conservez les annotations ajoutées à la main sur les parties qui n'ont pas bougé.
- Limitez-vous au changement. En revue, collez uniquement les tables dont il est question. Un diagramme ER ciblé de six tables, dont l'actualité est prouvée, vaut mieux qu'un poster de quarante tables qui l'est peut-être.
- Gardez-le aussi sous forme de code. Reconvertissez le diagramme en Mermaid ou D2 et commitez-le à côté de la migration, pour que l'image accompagne le changement dans la même pull request.
Un diagramme de schéma sert à inspirer confiance
Un diagramme de schéma ne mérite sa place que si les gens le croient sans vérifier. Pour gagner cette confiance, la discipline ne suffit pas : il faut supprimer l'étape humaine qui se passe mal. Générez l'image à partir du DDL que vous maintenez déjà, rafraîchissez-la chaque fois que le schéma évolue, et le diagramme cesse d'être une pièce de musée pour devenir un outil que l'équipe utilise vraiment. Correct par construction, à jour par défaut.
Exportez votre schéma, collez-le une fois, et voyez à quel point votre modèle mental est proche de la base de données que vous faites réellement tourner.