Créer un diagramme entité-association en ligne

ErdDocs ne vous fait pas dessiner le diagramme : il le génère. Collez un dump SQL, un schéma Prisma, des migrations ou des modèles ORM. En quelques secondes apparaissent les tables, leurs colonnes et les relations en notation « patte de corbeau ». Vous voyez les tables telles qu’elles existent, c’est-à-dire le MLD, et non un MCD conçu en amont. C’est gratuit, sans compte et sans installation. Le schéma n’est envoyé sur aucun serveur.

Votre schéma

CREATE TABLE studios (
    id            bigserial    PRIMARY KEY,
    name          varchar(120) NOT NULL UNIQUE,
    country       varchar(60),
    founded_year  smallint
);

CREATE TABLE people (
    id         bigserial    PRIMARY KEY,
    full_name  varchar(160) NOT NULL,
    born_on    date
);

CREATE TABLE films (
    id           bigserial    PRIMARY KEY,
    studio_id    bigint       NOT NULL REFERENCES studios(id),
    title        varchar(200) NOT NULL,
    released_on  date,
    runtime_min  smallint,
    rating       varchar(8)
);

CREATE TABLE film_credits (
    film_id      bigint      NOT NULL REFERENCES films(id),
    person_id    bigint      NOT NULL REFERENCES people(id),
    credited_as  varchar(40) NOT NULL,
    billing      smallint,
    PRIMARY KEY (film_id, person_id, credited_as)
);

CREATE TABLE theaters (
    id       bigserial    PRIMARY KEY,
    name     varchar(120) NOT NULL,
    city     varchar(80)  NOT NULL,
    screens  smallint     NOT NULL DEFAULT 1
);

CREATE TABLE screenings (
    id          bigserial    PRIMARY KEY,
    film_id     bigint       NOT NULL REFERENCES films(id),
    theater_id  bigint       NOT NULL REFERENCES theaters(id),
    starts_at   timestamptz  NOT NULL,
    price       numeric(6,2) NOT NULL
);

CREATE TABLE studios (
    id            bigserial    PRIMARY KEY,
    name          varchar(120) NOT NULL UNIQUE,
    country       varchar(60),
    founded_year  smallint
);

CREATE TABLE people (
    id         bigserial    PRIMARY KEY,
    full_name  varchar(160) NOT NULL,
    born_on    date
);

CREATE TABLE films (
    id           bigserial    PRIMARY KEY,
    studio_id    bigint       NOT NULL REFERENCES studios(id),
    title        varchar(200) NOT NULL,
    released_on  date,
    runtime_min  smallint,
    rating       varchar(8)
);

CREATE TABLE film_credits (
    film_id      bigint      NOT NULL REFERENCES films(id),
    person_id    bigint      NOT NULL REFERENCES people(id),
    credited_as  varchar(40) NOT NULL,
    billing      smallint,
    PRIMARY KEY (film_id, person_id, credited_as)
);

CREATE TABLE theaters (
    id       bigserial    PRIMARY KEY,
    name     varchar(120) NOT NULL,
    city     varchar(80)  NOT NULL,
    screens  smallint     NOT NULL DEFAULT 1
);

CREATE TABLE screenings (
    id          bigserial    PRIMARY KEY,
    film_id     bigint       NOT NULL REFERENCES films(id),
    theater_id  bigint       NOT NULL REFERENCES theaters(id),
    starts_at   timestamptz  NOT NULL,
    price       numeric(6,2) NOT NULL
);

Your diagram appears here.

Un catalogue de films, généré à partir du SQL de gauche. Collez votre schéma par-dessus.

Diagramme entité-association généré à partir d’un schéma de catalogue de films : studios, people, films, film_credits, theaters et screenings, avec les marques de patte de corbeau sur chaque relation. — Le même schéma de catalogue de films, exactement tel que l’export SVG le dessine.

Est-ce un outil de dessin ?

Non. ErdDocs tire le diagramme du schéma que vous collez. Il n’y a donc ni palette de formes, ni outil de trait, ni page blanche pour commencer. Ici, un diagramme entité-association est le résultat de la lecture d’un schéma, pas quelque chose qu’on assemble. Vous collez le texte qui décrit déjà votre base, et les boîtes, colonnes, clés et cardinalités en découlent. Vous pouvez toujours déplacer les tables pour les disposer, et le lien de partage garde cette disposition. Mais tout ce qu’il montre vient de votre schéma, et rien n’est à recopier à la main.

Presque tout ce qui ressort sur cette recherche fonctionne à l’inverse. La section suivante parle du seul cas qu’ErdDocs laisse aux outils de dessin : une base qui n’existe pas encore.

Le dessiner ou le générer ?

Tout dépend d’une seule chose : si le schéma existe déjà ou non.

Le schéma n’existe pas encore : dessinez-le. ErdDocs lit un schéma, c’est donc le seul cas qu’il ne couvre pas. Tant que la base n’existe pas, on dessine. Le modèle conceptuel (le MCD, en Merise) se décide en discutant des entités et des associations. Une commande possède-t-elle son adresse ou pointe-t-elle vers une adresse ? Cette relation est-elle vraiment plusieurs à plusieurs ? Pour cette discussion, un canevas ou un tableau blanc est le bon support. Quand elle aboutit à une migration ou à un CREATE TABLE, ErdDocs prend le relais et lit les tables.
Le schéma existe déjà : générez le diagramme. Une fois les tables créées, elles sont déjà décrites avec précision : dans les instructions CREATE TABLE, dans un schéma Prisma, dans les fichiers de migration, dans les classes de modèles de l’ORM. Redessiner tout cela à la main revient à recopier une description qu’on a déjà. C’est votre temps, et le résultat n’est qu’une seconde copie, moins fiable que l’original. Et la copie vieillit dès la migration suivante.

Parmi les outils de diagramme entité-association, ErdDocs est celui qui part d’une base qui existe déjà. Le reste de la catégorie sert à esquisser un modèle à partir de rien. La plupart des gens qui cherchent un outil de diagramme ER ont déjà le schéma. Ils prennent quand même un outil de dessin, parce que c’est ce que proposent les résultats de recherche.

Ce que fait ErdDocs et que les autres outils de diagramme ER ne font pas

Tous les outils ci-dessous dessinent un diagramme entité-association. Le tableau les compare sur ce que fait ErdDocs.

Fonction	ErdDocs	dbdiagram	Eraser	diagrams.net	Lucidchart	SmartDraw	Miro	Figma FigJam
Construit seul le diagramme depuis le SQL : les tables et toutes les relations	✓ Oui	✓ Oui	En partie: le SQL sert de consigne à l’IA	En partie: tables seules, relations à la main	En partie: tables placées à la main sur le canevas	En partie: à partir d’un CSV, pas du SQL	En partie: via l’IA ou le code Mermaid	En partie: uniquement à partir de code Mermaid
Lit Prisma et les modèles ORM	✓ Oui	× Non	En partie: le code sert de consigne à l’IA	× Non	× Non	× Non	× Non	× Non
Trouve gratuitement les relations sans clé étrangère	✓ Oui	En partie: par l’IA, dans une offre payante	Non précisé	× Non	× Non	× Non	En partie: l’IA suggère les relations	Non précisé
Le schéma ne passe pas par les serveurs de l’éditeur	✓ Oui	En partie: seulement dans le générateur de liens	× Non	✓ Oui	× Non	× Non	× Non	× Non
Exporte une image sans compte	✓ Oui	Non précisé	× Non	✓ Oui	× Non	× Non	En partie: seulement sur un tableau simple	× Non
Exporte en Mermaid, DBML et PlantUML	✓ Oui	En partie: DBML seulement	× Non	× Non	En partie: Mermaid seulement, via MCP	× Non	En partie: Mermaid seulement	× Non
Dictionnaire de données imprimable	✓ Oui	En partie: document web, sans PDF	Non précisé	× Non	× Non	× Non	Non précisé	× Non
Utilisable sans abonnement	✓ Oui	× Non	× Non	✓ Oui	En partie: pas d’import ERD dans l’offre gratuite	× Non	× Non	× Non

Le tableau s’appuie sur les pages des éditeurs eux-mêmes, telles qu’elles étaient en novembre 2026. « Non précisé » signifie que l’éditeur n’en dit rien. Les noms de produits appartiennent à leurs propriétaires.

dbdiagram est le plus proche. Lui aussi construit le diagramme à partir du SQL. Mais il ne lit ni Prisma ni les modèles ORM, et n’exporte ni en Mermaid ni en PlantUML. Il ne trouve les relations sans clé étrangère que par l’IA, dans une offre payante. Ses offres payantes sont uniquement des abonnements. ErdDocs, lui, se paie une seule fois.

Eraser n’analyse pas le SQL. Il le transmet à un modèle d’IA sous forme de consigne, et le schéma quitte donc votre machine. L’export demande un compte, et Mermaid, DBML et PlantUML ne figurent pas parmi ses formats.

diagrams.net crée les tables à partir du SQL collé, mais c’est à vous de tracer à la main les relations entre elles. Il ne lit pas les modèles ORM et ne produit pas de dictionnaire de données.

Lucidchart demande un compte et une requête exécutée sur une base en service. Les tables importées se placent ensuite à la main sur le canevas. Les relations ne viennent que des clés étrangères déclarées.

SmartDraw construit un diagramme ER à partir d’un CSV, que vous exportez avec une requête sur une base en service. Il ne lit ni dump SQL ni modèles ORM, et fonctionne uniquement en ligne.

Miro et Figma FigJam construisent un diagramme ER avec l’IA ou à partir de code Mermaid, pas à partir du SQL. Le schéma est stocké dans leur cloud, et l’export passe par un compte.

Pourquoi un diagramme dessiné vieillit et un diagramme généré non

Un diagramme dessiné à la main est un instantané, sans lien avec la base. La migration suivante ajoute une colonne, renomme une table ou supprime une clé étrangère. Le diagramme montre toujours l’ancienne forme. Il le fera jusqu’à ce que quelqu’un se souvienne de son existence, retrouve le fichier, dispose d’une licence de l’éditeur et prenne le temps. En général, cela arrive la semaine où il a été dessiné, puis plus jamais. Beaucoup de dépôts contiennent un diagramme qui contredit le schéma posé à côté.

Un diagramme généré n’a pas de version à tenir à jour. C’est une vue du texte du schéma. Le relancer sur le dump actuel prend quelques secondes, et le résultat est juste parce qu’il vient du schéma lui-même. Vous pouvez le régénérer à chaque version. Depuis le même collage, vous exportez du Mermaid pour le README, du SVG pour le site de documentation, ou un dictionnaire de données complet pour la livraison.

Que pouvez-vous y coller ?

Dix formats, détectés automatiquement. Vous collez le fichier tel quel, et l’outil reconnaît de lui-même ce qu’il a sous les yeux.

SQL : des scripts PostgreSQL, MySQL, SQL Server et SQLite, tels que les serveurs et leurs outils les écrivent, exportés avec pg_dump, mysqldump ou « Générer des scripts » de SSMS. Les backticks, AUTO_INCREMENT, les lots GO de SSMS et les clés déclarées plus loin par un ALTER TABLE sont tous lus. Ce que contient un dump est expliqué sur la page MySQL.
Langages de schéma : Prisma, DBML, Mermaid et PlantUML. Ce sont déjà des diagrammes sous forme de texte, il ne reste qu’à les dessiner.
Modèles ORM : les classes Django, SQLAlchemy, Sequelize et TypeORM, ainsi que les migrations Laravel. Ce sont justement celles qui n’ont jamais eu de diagramme, parce que la base est définie dans le code de l’application.

La page des formats les présente tous, avec ce qui est lu et ce qui est volontairement ignoré.

Le résultat s’exporte aussi en Mermaid, DBML, PlantUML ou SQL, par exemple pour un README ou la documentation du projet.

Que montre le diagramme généré ?

Une boîte par table, avec ses colonnes et leurs vrais types, les clés signalées et la notation patte de corbeau aux deux extrémités de chaque relation. Le diagramme énonce donc la cardinalité au lieu de la laisser deviner. Comme il part des tables, c’est le MLD que vous voyez, et non un MCD. Dans le catalogue de films ci-dessus, film_credits est une table d’association qui porte ses propres colonnes. C’est la forme réelle d’un plusieurs à plusieurs une fois arrivé dans une base.

Beaucoup de projets Rails, Django ou Laravel ne déclarent aucune clé étrangère dans la base. ErdDocs déduit alors la relation du nom de la colonne, par exemple film_id → films ou user_id → users. Il la trace en pointillé, pour qu’une relation déduite ne soit jamais prise pour une contrainte que la base impose. Cette étape compte surtout sur les bases de production dont on hérite, et la page outil de diagramme de base de données explique pourquoi.

Questions fréquentes

Est-ce un éditeur où l’on déplace des boîtes à la main ?

Non. ErdDocs génère le diagramme à partir du schéma que vous collez. Il n’y a ni palette de formes ni outil de trait, et c’est voulu. Vous pouvez toujours déplacer les tables pour arranger la disposition, et le lien de partage la garde. Mais rien n’est dessiné à la main : chaque boîte et chaque trait vient du SQL.

Vaut-il mieux dessiner le diagramme à la main plutôt que le générer ?

ErdDocs génère le diagramme dès que les tables existent. C’est le cas de la plupart des gens, car le schéma existe en général avant que quelqu’un en demande une image. Le seul cas qu’il laisse de côté est celui d’une base pas encore construite. Avant la première migration, on discute du modèle de données en esquissant les entités sur un canevas, et ce sont alors les outils de dessin généralistes qui conviennent. En Merise, c’est l’étape du MCD. Une fois l’esquisse devenue migration ou CREATE TABLE, collez-la ici : le diagramme vient alors du schéma lui-même, et c’est le MLD.

Est-ce que ça remplace un MCD pour un cours de Merise ?

Non. Le MCD se conçoit avant les tables, avec entités, associations et cardinalités (0,n). ErdDocs ne fait pas le passage du MCD au MLD : il part du SQL déjà écrit. Il sert à vérifier que le MLD obtenu est bien celui qu’on voulait, et à produire le dictionnaire de données qui l’accompagne.

Que puis-je y coller ?

Dix formats : du SQL PostgreSQL, MySQL, SQL Server et SQLite, des schémas Prisma, DBML, Mermaid, PlantUML, des modèles Django, SQLAlchemy et Sequelize, des entités TypeORM et des migrations Laravel. Le format est détecté automatiquement. Collez le fichier tel quel, sans nettoyage ni export préalable.

Faut-il un compte, une installation ou une connexion à la base ?

Rien de tout cela. L’analyseur est du JavaScript qui tourne dans votre navigateur. Il n’y a donc aucun serveur auquel se connecter ni aucun schéma à envoyer. Les noms de tables et de colonnes ne quittent pas votre machine. Ouvrez la page, collez, et le diagramme est là.

Que se passe-t-il quand le schéma change ?

Vous collez le nouveau dump et le diagramme se régénère en quelques secondes. Un diagramme dessiné doit être modifié par la personne qui se souvient qu’il existe, donc il s’écarte de la base dès la migration suivante. Un diagramme généré ne peut pas s’en écarter, car il repart à chaque fois du schéma.

C’est gratuit ?

Pour le diagramme, oui. Les schémas jusqu’à 25 tables sont dessinés en entier, sans compte. Les exports en PNG, SVG, Mermaid, DBML, PlantUML et SQL sont gratuits. Les plus grands sont aussi analysés entièrement, mais les tables au-delà de la limite restent verrouillées. Un paiement unique de 9 $ US lève la limite et débloque le dictionnaire de données.

Pages liées

Qu’est-ce qu’un diagramme entité-association : la notion, et comment en lire un.
Outil de diagramme de base de données : le même outil, présenté pour ceux qui partent d’une base plutôt que d’un modèle.
Symboles du diagramme entité-association : ce que veulent dire les formes et les extrémités des traits.
Diagramme de schéma : en quoi un diagramme de schéma diffère d’un diagramme entité-association.
Exemples de diagrammes : des domaines traités en entier, chacun avec son SQL.
Alternative à ERDPlus : ce qu’ErdDocs fait et qu’un outil de dessin ne fait pas.
Du SQL au diagramme entité-association : l’outil, avec tous les formats qu’il lit.