BAML : écrire ses fonctions LLM

BAML : écrire ses fonctions LLM comme du code typé

Quand un agent ou un pipeline IA doit renvoyer des données structurées, JSON, objets métier, listes d’entités, on se retrouve vite à bricoler des prompts à rallonge, à parser des réponses à la main et à prier pour que le modèle respecte le format. BAML (BoundaryML), publié sous licence open source et arrivé en version 0.222 en avril 2026, propose une autre voie : décrire ses fonctions LLM dans un petit langage dédié et typé, puis générer automatiquement un client fiable pour son langage de programmation.

De l’ingénierie de prompt à l’ingénierie de schéma

L’idée centrale de BAML tient en une phrase : ce qui compte vraiment, ce n’est pas la formulation magique du prompt, mais la définition précise des entrées et des sorties attendues. On écrit dans un fichier .baml une fonction qui déclare ses paramètres, le type de son résultat (une classe, une énumération, une liste) et le modèle à appeler. BAML compile ensuite ce fichier en un client type-safe pour Python, TypeScript, Ruby, Go, Java, C# ou Rust. Le développeur appelle une fonction normale de son langage, et récupère un objet déjà validé, pas une chaîne de texte à déchiffrer.

Ce que BAML apporte concrètement

• Sorties structurées fiables : grâce à son algorithme de parsing aligné sur le schéma (SAP, Schema-Aligned Parsing), BAML extrait des données conformes même quand le modèle n’a pas d’API de tool-calling native, ce qui est précieux pour les LLM locaux servis par Ollama, vLLM ou SGLang.
• Validation intégrée : les annotations @assert et @check permettent de poser des règles sur les sorties, soit bloquantes, soit non bloquantes via un type Checked<T> qui transporte le résultat de la vérification.
• Indépendance du modèle : on change de fournisseur ou de modèle dans la définition BAML, sans toucher au reste du code applicatif.
• Outillage de développement : extension d’éditeur avec aperçu du prompt réellement envoyé, tests de la fonction directement dans le projet, ce qui rapproche le travail sur les prompts d’un cycle de développement logiciel classique.

Où BAML se place dans une chaîne IA

BAML occupe une couche bien identifiée : celle de la frontière entre le code et le modèle. Là où un framework d’agents orchestre des étapes et où un moteur d’inférence sert le modèle, BAML garantit que chaque appel renvoie une structure de données exploitable et vérifiée. Il se compare naturellement à des outils comme Outlines, qui force un format JSON, ou Pydantic AI, qui valide côté Python, mais s’en distingue par son langage dédié multi-cible et son parsing tolérant qui fonctionne avec presque n’importe quel modèle.

Pour un système souverain, c’est un point d’appui solide : on décrit une fois ses fonctions LLM, on les teste, on les versionne, et on garde la liberté de basculer entre un modèle local et une API distante selon le coût et la sensibilité des données.

Pour démarrer

Un premier essai parlant : prendre une tâche d’extraction réelle, par exemple transformer une fiche texte en objet structuré (nom, dates, montants, catégorie), l’écrire comme une fonction BAML avec une classe de sortie et deux ou trois règles @assert, puis l’exécuter une fois sur un modèle cloud et une fois sur un modèle local. La comparaison des résultats, à code applicatif strictement identique, montre immédiatement la valeur de l’approche : le format tient, et le reste du programme n’a pas bougé.