WrenAI : une couche de contexte versionnable pour le text-to-SQL généré par agents

Le problème : la logique métier absente du schéma

Un agent qui reçoit un schéma de base de données voit des tables, des colonnes et des types. Il ne voit ni les définitions approuvées, ni les énumérations, ni les unités, ni les jointures validées par l'équipe. Le README formule ce constat sans détour : la logique métier vit souvent hors de la base, et les agents se trompent en conséquence. WrenAI vise donc les équipes qui ont déjà des agents (Claude Code, Cursor, ou tout client parlant MCP) et qui veulent leur donner autre chose qu'un schéma brut. La cible n'est pas l'analyste qui cherche un graphique ponctuel : le README invite explicitement à passer son chemin si c'est le besoin. La cible, c'est le cas où plusieurs agents et plusieurs personnes doivent partager les mêmes définitions, et où une réponse fausse coûte plus cher qu'une réponse absente.

Une couche de contexte en fichiers, pas en prompts

Le mécanisme central tient dans trois artefacts nommés par le README : les modèles sémantiques (MDL), les définitions d'entreprise dans un fichier instructions.md, et une mémoire de ce qui a fonctionné. Ces éléments sont décrits comme versionnables, liés à des preuves et compatibles Git. C'est la différence de fond avec un agent qui empile des instructions dans un prompt système : ici, la connaissance est un objet que l'on peut relire, comparer et diffuser. Le README parle d'une couche de contexte IA ouverte, distincte de la couche sémantique gouvernée, et précise que la seconde apporte ce que les schémas ne contiennent pas. La génération s'appuie sur une récupération sensible au schéma, une planification via le MDL, une validation dry-plan et des erreurs structurées. L'agent orchestre, mais la trace reste dans son raisonnement. Cette répartition est cohérente : WrenAI ne prétend pas remplacer l'agent, il lui fournit un socle vérifiable.

Installation : la CLI pilote, le client IA découvre

Le démarrage se fait en deux temps. D'abord la CLI, avec deux commandes distinctes selon le besoin : pip install wrenai pour le socle, DuckDB inclus, puis pip install "wrenai[postgres,memory]" pour ajouter les extras par source de données et la mémoire. Ensuite, un stub de découverte en un seul fichier, à installer dans le client IA choisi. Le README insiste sur un point d'architecture : les guides de workflow sont servis à la demande par la CLI elle-même, ce qui garantit que la documentation correspond à la version installée. C'est un choix défendable, mais il déplace la documentation hors du dépôt et hors de l'indexation web, ce qui gêne la recherche d'information avant installation. Le README signale aussi que pip install peut être lent ou échouer depuis la Chine continentale, sans que le texte fourni aille plus loin. Les clés de configuration précises (chaîne de connexion, chemins des fichiers MDL) ne figurent pas dans l'extrait disponible : il faut consulter docs.getwren.ai.

Générer, déployer, savoir : trois temps inégaux

Le README résume la promesse en trois verbes. Générer : transformer une question métier en text-to-SQL gouverné et en graphiques. Déployer : convertir une réponse en tableau de bord exécuté côté navigateur via wren-core-wasm, puis le publier sur un compte Vercel ou Cloudflare Pages en une commande. Savoir : conserver la connaissance dans des fichiers relus et versionnés. Le deuxième temps mérite attention. Un tableau de bord qui s'exécute dans le navigateur suppose que les données ou le moteur compilé en WebAssembly atteignent le poste client, ce qui n'est pas anodin selon la sensibilité des données et le volume interrogé. Le README ne détaille pas ce point dans l'extrait fourni. Le troisième temps, lui, est le plus solide : des fichiers MDL et instructions.md relus en revue de code, c'est un modèle de gouvernance que peu d'outils de BI générative proposent.

Licence et frontière open core

Le badge du README annonce Apache 2.0, et le texte précise que le cœur, le SDK et les skills sont ouverts sous cette licence. Les métadonnées du dépôt renvoient toutefois NOASSERTION comme identifiant de licence, ce qui signifie que GitHub n'a pas su rattacher automatiquement le fichier LICENSE à une licence reconnue. Avant tout usage en entreprise, il faut lire le fichier LICENSE du dépôt et le faire valider en interne : je ne peux pas trancher cette divergence à partir des seules informations fournies. La frontière fonctionnelle, elle, est énoncée clairement : la sécurité au niveau ligne et colonne ainsi que le contrôle d'accès relèvent de l'offre Cloud ou self-hosted. Autrement dit, la version communautaire valide les plans et limite les lignes, mais ne filtre pas les données par utilisateur. Pour un déploiement interne où tous les lecteurs ont les mêmes droits, cela peut suffire. Dès qu'il faut segmenter les accès, la version ouverte ne couvre pas le besoin.

Ce que dry-plan et erreurs structurées ne rattrapent pas

La validation dry-plan et les erreurs structurées avec indices constituent de vrais garde-fous : elles empêchent l'exécution d'un SQL mal formé et orientent l'agent vers une correction. Elles ne disent rien de la justesse sémantique. Une requête peut être syntaxiquement valide, passer le dry-plan, et répondre à côté parce que la définition du chiffre d'affaires retenue n'est pas la bonne. C'est précisément pourquoi la qualité du fichier MDL et de instructions.md devient le facteur limitant : un MDL incomplet produit des réponses fausses avec l'apparence de la gouvernance. Le README mentionne un eval runner parmi les primitives, mais l'extrait ne décrit ni son fonctionnement ni son format de sortie, donc je ne peux pas évaluer sa couverture. Autre point de friction : le dépôt a absorbé Wren Engine sous core/ en mai 2026, et l'ancienne application GenBI basée sur Docker est conservée sur la branche legacy/v1 sous le tag v1-final. Les lecteurs qui connaissaient le produit « chat-first » doivent donc vérifier sur quelle branche ils atterrissent.

Face à un agent LLM nu ou à un outil de BI classique

Le tableau comparatif du README positionne WrenAI contre trois approches. Face à un agent LLM nu, la différence est la gouvernance : l'agent écrit du SQL souvent faux, WrenAI écrit du SQL gouverné. Face à un outil de BI traditionnel, la différence est le mode de production : l'outil classique fait construire les tableaux de bord à la main dans son interface, WrenAI les fait générer et déployer par l'agent. Face à une couche sémantique nue, la différence est le périmètre : la couche nue porte des définitions de schéma, WrenAI y ajoute la connaissance non structurée issue des documents, wikis et fils de discussion. Cette dernière affirmation est la plus difficile à vérifier sans installation, car le README ne décrit pas l'ingestion de ces sources. Le point le plus tangible reste l'intégration MCP : WrenAI s'insère dans les agents que l'équipe utilise déjà, plutôt que d'imposer un client supplémentaire. C'est un argument concret pour qui a déjà standardisé son outillage.

Coût de maintenance et rythme de publication

Le rythme des versions est soutenu : wren-v0.14.0 le 8 septembre 2026, wren-v0.13.4 le 2 septembre, wren-pydantic-v0.3.0 le même jour, pour un dernier push au 9 septembre 2026. Le découpage en paquets distincts (wren, wren-pydantic) signifie que les mises à jour peuvent être désynchronisées, et qu'un projet qui épingle une version doit suivre plusieurs numéros. La fusion de Wren Engine dans core/ ajoute une charge de compréhension : le dépôt couvre désormais le moteur et l'application, ce qui élargit la surface à lire avant de contribuer. Côté exploitation, la CLI qui sert ses propres guides de workflow à la demande simplifie la cohérence documentaire mais complique l'automatisation, puisqu'il faut interroger l'outil installé plutôt que lire une page. Enfin, l'absence de sécurité ligne et colonne dans la version communautaire n'est pas un coût de maintenance mais une contrainte de conception : elle impose soit de rester sur des périmètres homogènes, soit de basculer vers l'offre commerciale.

Conclusion éditoriale

WrenAI convient aux équipes dont la logique métier (définitions, énumérations, jointures approuvées) vit hors de la base et dont les agents produisent du SQL plausible mais faux. Il ne convient pas à qui veut un graphique unique depuis un CSV, ni à qui attend du row-level security dans la version communautaire : le README renvoie explicitement ces contrôles à l'offre Cloud ou self-hosted. Avant d'adopter, vérifiez deux points dans votre clone : le contenu réel de la licence (le badge indique Apache 2.0, l'API GitHub renvoie NOASSERTION) et le périmètre de votre source de données dans la liste des 22+ connecteurs, en installant les extras correspondants comme wrenai[postgres,memory].

Sources officielles

1. Canner/WrenAI on GitHub
2. Issues
3. Project website
4. README
5. Releases