DSL et LLM : la méthode Fowler pour fiabiliser vos sorties d'IA en production

Le 14 juillet 2026, Martin Fowler a publié sur son site un article signé Unmesh Joshi, Distinguished Engineer chez Thoughtworks à Pune, en Inde, et auteur de « Patterns of Distributed Systems ». Son constat : les LLM génèrent du code à une vitesse impressionnante, mais rien ne garantit qu'ils produisent exactement ce qui est attendu si on les laisse écrire en langage libre. Sa réponse tient en un mot : le DSL, un langage à syntaxe contrainte, dédié à un domaine précis, qui transforme un LLM capricieux en outil fiable en production.

Pour ceux qui découvrent le sujet : un DSL (Domain-Specific Language) est un langage restreint à un usage précis, par opposition à un langage généraliste comme Java ou Python. SQL pour interroger une base de données, les manifestes YAML de Kubernetes pour décrire une infrastructure, PlantUML, Mermaid ou Graphviz pour des diagrammes : ce sont tous des DSL. Ils expriment un nombre limité de concepts avec une syntaxe stricte, et c'est précisément ce qui les rend précieux face à un LLM.

Pourquoi le prompt libre atteint ses limites en production

Joshi rappelle un point qu'il avait déjà développé dans un article précédent, autour de ce qu'il appelle l'Upfront Specification Impossibility : un cahier des charges écrit à l'avance n'est jamais qu'une hypothèse de départ. Les vrais arbitrages, les cas limites et les contraintes concrètes se découvrent en construisant, pas en rédigeant une spécification exhaustive au début. Relire du code généré par une IA ne remplace pas non plus l'écriture : c'est en écrivant qu'on est forcé de trancher où placer une responsabilité, quelles frontières exposer. La revue de code valide un résultat, elle ne force pas les mêmes décisions de conception.

Conséquence directe pour un prompt en langage naturel : si l'intention n'est pas mappée à des briques précises et reproductibles, chaque génération peut varier légèrement, et personne ne peut vérifier automatiquement qu'elle respecte les règles du domaine. C'est exactement le mur que rencontrent les équipes qui tentent de faire générer directement du code de production, une configuration d'infrastructure ou une requête métier par un LLM en texte libre.

Le DSL, une camisole utile pour un LLM

C'est là que le DSL change la donne. Un langage généraliste comme Java offre une multitude de façons valides d'exprimer la même intention : le LLM doit choisir parmi toutes ces variantes, avec un risque d'erreur à chaque choix. Un DSL supprime cette variation. Quelques exemples suffisent alors au modèle pour générer une syntaxe correcte de manière fiable, sans fine-tuning ni jeu d'entraînement dédié.

Le point le plus utile pour la production concerne les agents, c'est-à-dire un LLM qui tourne en boucle générer-vérifier de manière autonome plutôt qu'en génération unique. Un DSL est presque toujours accompagné d'un validateur déterministe : un parseur, un schéma JSON, un vérificateur de types ou un compilateur. L'agent peut générer une proposition, la faire passer par ce validateur, et se corriger à partir de l'erreur remontée, sans intervention humaine. Et surtout, ces erreurs sont formulées au niveau du domaine, par exemple « vous ne pouvez pas sélectionner une action avant d'avoir choisi un client », plutôt que comme une pile d'appels illisible enfouie dans du code généré.

L'exemple Tickloom : construire le langage avec le LLM

Joshi illustre ce mécanisme avec Tickloom, un modèle de domaine et un DSL qu'il a construits pour représenter le comportement des systèmes distribués. La grammaire du DSL est directement imposée par le compilateur du langage hôte, et les scénarios générés sont vérifiés automatiquement : le LLM ne peut tout simplement pas produire un scénario incohérent qui compile. Dans cette approche, le LLM joue deux rôles distincts : partenaire de brainstorming pendant la construction du vocabulaire du domaine, puis interface en langage naturel une fois ce vocabulaire établi.

Un autre exemple concret donné dans l'article : un outil qui génère des présentations PowerPoint riches en diagrammes à partir d'un fichier YAML décrivant la structure, avec des références à des diagrammes PlantUML annotés d'étapes. Un simple prompt en langage naturel décrivant une séquence d'échanges entre plusieurs nœuds produit directement le PlantUML avec les marqueurs d'étape attendus, sans ambiguïté de syntaxe.

Joshi insiste toutefois sur une limite importante : l'avantage du DSL ne tient que si le langage reste suffisamment petit et contraint pour qu'une poignée d'exemples en contexte suffise à le transmettre. Concevoir et maintenir un DSL a un coût réel. Le gain se concentre sur des langages bien pensés, réellement restreints, et adossés à un validateur, pas sur n'importe quel format ad hoc.

Ce que ça change concrètement pour vos projets

Pour une équipe qui intègre un LLM dans un produit ou un outil interne, cette approche se traduit par une règle simple : ne demandez jamais à un LLM de générer directement le format final critique (code de production, configuration d'infrastructure, requête de base de données) en texte libre si vous pouvez le faire passer par un DSL intermédiaire validé par un schéma ou un parseur.

Concrètement, cela peut prendre la forme d'un schéma JSON strict pour une génération de configuration, d'une grammaire dédiée pour des scénarios de test, ou d'un sous-ensemble volontairement restreint d'un langage existant pour une automatisation interne. La boucle générer-valider-corriger, propre à un agent, devient alors fiable sans supervision humaine constante : c'est précisément ce qui manque au prompt libre en production.

Notre lecture chez CZSyn

Sur les projets où nous branchons un LLM à un workflow client (génération de rapports, automatisation d'exports, assistants internes), le constat de Joshi rejoint ce que nous observons sur le terrain : le prompt libre fonctionne très bien en démo et devient vite ingérable dès qu'il faut le fiabiliser en production. La différence se joue rarement sur le choix du modèle, mais sur la structure qu'on impose en sortie.

L'approche DSL a un coût d'entrée réel : il faut concevoir le langage, écrire le validateur, documenter les exemples. Mais pour une PME qui souhaite automatiser une tâche répétitive avec un LLM sans embaucher une équipe de supervision humaine permanente, c'est souvent le seul chemin crédible vers un système qui tient dans la durée. Nous recommandons cette approche dès qu'un agent IA touche à des données ou des configurations sensibles chez un client.

Sources primaires

• Martin Fowler, « DSLs Enable Reliable Use of LLMs », par Unmesh Joshi, 14 juillet 2026.
• Documentation officielle, plantuml.com.
• Documentation officielle, mermaid.js.org.