DBScan : comprendre une modélisation à partir de son DDL

Le besoin

Lorsque je crée rapidement une application, je commence par rédiger une première version du besoin avec un LLM suffisamment précis pour le projet. J’itère ensuite sur ce besoin jusqu’à obtenir une base cohérente, puis je demande au modèle de produire un DDL. Cette étape me permet de comprendre comment il envisage la structure des données et les relations entre les différentes entités.

Le DDL devient alors un support de discussion. Je peux revoir la modélisation, corriger ses ambiguïtés et poursuivre les échanges avant de passer au design, qui découle en partie de ces choix. Il me manquait cependant un moyen de voir en un coup d’œil ce que le modèle avait imaginé, sans devoir parcourir mentalement toutes les tables et leurs relations.

C’est de ce besoin qu’est né DBScan : un outil dans lequel coller directement un DDL pour l’analyser et le transformer en diagramme.

L’hypothèse

Mon hypothèse était qu’un DDL standard pouvait servir à la fois de format de travail avec le LLM et de source pour une représentation visuelle. Un outil capable de l’interpréter devait accélérer la relecture de la modélisation, rendre les relations plus évidentes et révéler rapidement les problèmes avant de commencer le développement.

J’ai d’abord recherché des solutions existantes proposant une approche comparable. Plusieurs reposaient sur un langage spécifique ajouté par l’outil. Cette couche supplémentaire ne correspondait pas à mon workflow : je préférais conserver un DDL classique, exploitable ailleurs et conforme aux standards déjà utilisés par les systèmes de gestion de bases de données.

La réalisation

Après ces recherches et plusieurs allers-retours sur le besoin, j’ai préparé un prompt détaillé, puis je l’ai transmis à Claude Code pour réaliser l’application. Les échanges suivants ont permis d’affiner le résultat jusqu’à obtenir un outil suffisamment abouti pour mon usage.

DBScan est une SPA statique développée avec ReactJS. Elle utilise le stockage local du navigateur, ce qui évite d’avoir à déployer une API ou une base de données pour conserver l’état nécessaire à son fonctionnement.

L’utilisateur colle son DDL dans l’application. Un parseur l’interprète, signale les erreurs de format ou les problèmes liés aux données et génère un diagramme de la structure. L’analyse prend en charge plusieurs dialectes SQL : MySQL, SQLite et PostgreSQL.

Le choix d’une SPA statique rend l’architecture particulièrement légère. Toute l’analyse est accessible depuis le navigateur, tandis que le DDL reste dans l’environnement local de l’utilisateur grâce à l’utilisation du localStorage.

Le résultat

La recherche initiale autour de l’idée a pris un peu plus de trente minutes. Une nouvelle demi-heure a été nécessaire pour préciser et faire évoluer le besoin. La réalisation, les échanges avec Claude Code et les corrections destinées à obtenir un résultat de qualité ont demandé environ une heure supplémentaire.

Enfin, la mise en production de la SPA sur ma plateforme a pris quinze minutes. En production, Caddy sert les fichiers statiques de l’application et prend en charge son exposition en HTTPS. En un peu plus de deux heures, le besoin a donc été transformé en un outil disponible en ligne et intégré à mon workflow de conception.

DBScan est accessible à l’adresse dbscan.paretolabs.fr.

Les limites et les enseignements

Le principal choix de cette expérimentation est de rester au plus près du SQL standard tout en prenant en compte les différences entre MySQL, SQLite et PostgreSQL. Cette approche évite d’imposer un nouveau langage, mais elle demande au parseur de gérer les particularités et les niveaux de compatibilité propres à chaque SGBD.

Le stockage dans le navigateur est cohérent avec une application statique et un usage individuel. Il simplifie fortement le déploiement, mais ne fournit ni synchronisation entre plusieurs appareils ni espace de travail partagé. Ces limites sont acceptables pour l’objectif initial : comprendre rapidement une modélisation proposée au cours d’une itération avec un LLM.

L’expérimentation confirme également l’intérêt de travailler sur le modèle de données avant le design. Visualiser le DDL permet de confronter très tôt le besoin à une structure concrète, de détecter les incompréhensions et d’éviter qu’elles se propagent dans les étapes suivantes du projet.

Conclusion

DBScan transforme une étape jusque-là difficile à lire rapidement en un support visuel immédiatement exploitable. En conservant le DDL comme format d’entrée, l’outil s’intègre à mon workflow sans ajouter de langage propriétaire ni enfermer la modélisation dans un format spécifique.

Cette expérimentation illustre une nouvelle fois la valeur d’une boucle courte : partir d’un besoin réel, étudier l’existant, préciser le résultat attendu, confier une réalisation cadrée à Claude Code, puis vérifier et corriger jusqu’à obtenir un outil utile en production.