
Ce qu'est vraiment PromptQL (et le virage que personne n'a annoncé)
Je construis des agents IA pour gagner ma vie, donc PromptQL a atterri sur mon bureau comme la plupart des nouveaux produits d'agents : avec une grande affirmation de précision et une démo qui paraît trop propre. La façon utile de l'évaluer consiste à séparer ce que le produit est de la manière dont il est actuellement commercialisé, car ces deux choses se sont éloignées l'une de l'autre au cours de la dernière année.
PromptQL vient de Hasura, l'entreprise qui a lancé le moteur GraphQL open source ayant dépassé les 100 millions de téléchargements en deux ans. Les fondateurs Tanmai Gopal et Rajoshi Ghosh ont levé une Série B de 25 M$ et une Série C de 100 M$, et fin 2025, VentureBeat décrivait l'entreprise comme une affaire valant plus d'un milliard de dollars, vendant des ingénieurs IA à 900 $/heure. Le cadrage utilisé par Tanmai est que le client de vos données a changé :
« Nous avons réalisé que les applications ne sont plus les éléments les plus importants ayant besoin d'accéder aux données. L'avenir, c'est l'IA qui parle aux données, l'IA qui accède aux données au nom de l'utilisateur. »
Le discours de 2025 était donc clair : une couche fiable, en langage naturel, par-dessus les données d'entreprise, positionnée contre le text-to-SQL, le tool-calling et le RAG. Puis la page d'accueil a changé. Aujourd'hui, promptql.io met en avant « un multiplayer AI agent, pensez à Claude ou ChatGPT, mais avec des fils partagés et un cerveau commun », et le problème central est la dégradation du contexte entre Slack, les documents, les tickets, le CRM et les tables d'entrepôt. Les logos cités sont des poids lourds : Cisco, McDonald's, Instacart, Swiggy et Lightspeed.
Les deux descriptions sont vraies, et pointent vers le même moteur. Mais si vous arrivez sur le site sans contexte, vous penseriez que PromptQL est un outil de connaissance d'équipe un peu comme Glean ou une base de connaissances interne partagée. Sous le capot, c'est toujours un agent de données. Gardez cela à l'esprit, car la tarification, la documentation et les benchmarks tournent tous autour du moteur de données, pas de l'enrobage type wiki.
Comment fonctionne PromptQL : d'abord planifier, puis exécuter
C'est la partie que je respecte vraiment, et la raison pour laquelle ce produit mérite un avis plutôt qu'un haussement d'épaules. La plupart des outils « IA sur vos données » confient tout le travail au modèle : lire les données, faire les calculs, écrire la réponse, le tout dans une seule fenêtre de contexte. PromptQL divise cela en deux.

Quand vous posez une question dans le Playground, PromptQL renvoie d'abord un plan de requête : une décomposition étape par étape, en langage clair, de la façon dont il va extraire, filtrer et traiter vos données, y compris les hypothèses qu'il formule. Vous pouvez le lire, et le modifier avec une icône crayon, moment où PromptQL « s'en souvient et s'autocorrige pour les futurs fils ». Cette transparence est ce que les lecteurs pressés ne devraient pas sauter : vous voyez le plan avant que la moindre donnée ne bouge.

Le plan s'exécute ensuite comme du vrai code. PromptQL récupère vos données et les organise avec Python, et vous pouvez développer chaque étape pour voir le Python et le SQL réels exécutés contre votre source. C'est la phrase sur laquelle repose tout le produit, dans les mots du fondateur :
« Plutôt que de générer des réponses, nous générons des plans dans un langage spécifique au domaine, propre à votre entreprise. Ces plans se compilent en actions déterministes avec des validations d'exécution et des contrôles de politique. »

Les résultats arrivent sous forme d'artefacts : tableaux structurés, texte ou graphiques qui vivent en dehors du contexte du modèle et sont référencés par les étapes ultérieures. C'est l'astuce intelligente pour la mise à l'échelle, car cela signifie que PromptQL peut travailler sur des données bien plus volumineuses qu'une fenêtre de contexte sans que le modèle en perde discrètement le fil. Le travail sémantique (classer, résumer, extraire, visualiser) est confié à des primitives IA étroites, chacune s'exécutant isolément avec un contexte ciblé, de sorte que le LLM ne raisonne jamais que sur une petite tranche bien délimitée.

Enfin, chaque réponse reçoit un score de fiabilité basé sur la complexité de la requête, la précision des données et la confiance du modèle, accompagné de notes d'évaluation sur ce que l'analyse a inclus ou non. Si le score est faible, vous le corrigez, et la correction reste en place pour la prochaine fois. Venant du monde du support, ce schéma m'est familier : c'est le même réflexe qui sous-tend la prévention des hallucinations, à savoir que le système doit vous dire quand il n'est pas sûr, plutôt que de deviner avec un air assuré.

Le problème de fiabilité que PromptQL résout réellement
Pour comprendre pourquoi tout cela compte, regardez à quel point les modèles bruts se débrouillent mal sur de vraies questions de données. Tanmai cite le Berkeley Data Agent Benchmark, où les modèles de pointe obtiennent des scores bien inférieurs à ce qu'une démo laisserait supposer.

Sur des questions de données du monde réel, le benchmark de Berkeley place Opus 4.6 à 43 %, Gemini 3 Pro à 38 % et GPT-5.2 à 25 %, tandis que la génération classique de requêtes de base de données obtient un score « proche de 0 % ». La propre lecture du benchmark est que les agents « sélectionnent généralement les bonnes données, mais échouent à planifier le calcul ou à le mettre en œuvre correctement ». C'est exactement l'écart que vise la séparation planifier-et-exécuter de PromptQL, et c'est pourquoi le fondateur martèle sans cesse un mot :
« Le plus gros problème n'est pas de ne pas pouvoir répondre précisément à la question. Le gros problème, c'est que l'IA prétend être précise même quand elle ne l'est pas. Donc l'IA se trompe avec assurance. C'est ça, le problème. »
Hasura regroupe les échecs en quatre modes, et cette matrice 2x2 est la chose la plus utile à intérioriser avant d'évaluer n'importe quel outil d'analytique de données par IA, PromptQL ou un autre.

Venons-en maintenant à ce titre de « 100 % de précision ». Hasura est agréablement honnête sur le fait qu'il s'agit d'un appât : l'entreprise concède qu'une « affirmation de 100 % de précision ne tient techniquement pas la route », et l'affirmation réelle est celle d'une reproductibilité à 100 %, car le calcul s'exécute dans du code, pas via le raisonnement du modèle. Sur les tâches plus restreintes de base de données et numériques CRMArena-Pro, ils rapportent 100 % contre 30 à 60 % cités pour les approches de pointe. Traitez le chiffre rond comme une entrée en matière, et la reproductibilité comme la véritable fonctionnalité du produit.
Les fonctionnalités qui se démarquent
Au-delà de la boucle principale, quelques éléments distinguent PromptQL d'un chatbot de base de connaissances IA générique.
Des automatisations qui deviennent de vraies API. Une fois qu'un workflow fonctionne dans le Playground, vous le déployez comme point de terminaison HTTP appelable depuis Zapier, Slack, des tâches cron ou vos propres applications, sans coder. Cela transforme un fil ponctuel en processus métier reproductible, et c'est la fonctionnalité sur laquelle je m'appuierais le plus si je dirigeais une équipe de données.

Des jointures inter-systèmes via les métadonnées. PromptQL repose sur Hasura DDN, donc un supergraph assemble plusieurs sous-graphes, et les relations « n'ont pas besoin d'être adossées à la même source de données ». En pratique, cela signifie qu'il peut lier Postgres à une API SaaS et raisonner sur les deux, exactement là où échouent les outils conçus uniquement pour Snowflake ou un seul entrepôt.
Une couche de contexte qui se construit d'elle-même. L'enrobage 2026 ajoute un wiki qui s'alimente lui-même depuis Slack, Google Docs, Snowflake, PostHog et Salesforce, conserve un historique des révisions et des pistes d'audit, et applique un accès segmenté (externe, interne, personnel, confidentiel). C'est le genre de pari de contexte connecté que l'on retrouve aussi dans les outils IA de Salesforce. Les corrections que vous apportez deviennent des « compétences » partagées héritées par la personne suivante, le même problème de gestion des connaissances que combat chaque équipe, déguisé en agent.
Apportez votre propre modèle, et cela compte pour la facture. PromptQL fait tourner n'importe quel LLM, de Claude et GPT à des modèles à poids ouverts comme DeepSeek, Kimi K2 et GLM, servi via Fireworks. Vous pouvez changer de modèle par fil ou en cours de fil, et il interopère via MCP. Gardez cela en tête, car le choix du modèle est le levier le plus important sur le coût.

Tarification de PromptQL : ce que vous paierez réellement
PromptQL n'a aucune tarification par siège. C'est 100 % basé sur la consommation, facturé dans une unité normalisée appelée OLU (Operational Language Unit), qui regroupe les tokens d'entrée, de sortie, de cache et de création de cache sur tous les modèles en un seul chiffre cohérent, afin que votre facture ne change pas de forme quand vous changez de modèle.
| Forfait | Prix | Unité facturable | Ce que vous obtenez |
|---|---|---|---|
| Crédits gratuits | 50 $ par projet, +20 $ par coéquipier | OLU | Aucune carte requise ; suffisant pour des milliers de tâches simples sur un modèle à poids ouverts |
| Starter | 0,20 $ par OLU (0,14 $ en tarif d'introduction, à prix coûtant) | OLU | À l'usage, solde prépayé, mise en pause automatique à zéro, quotas par utilisateur ; tout compris (tokens + infra + bac à sable) |
| Enterprise | Sur mesure, contactez les ventes | OLU | Ajoute SSO, BYOC/VPC, réseau privé, LLM propres, pistes d'audit, ingénieurs déployés sur site |
Les coûts typiques par tâche cités par Hasura (au tarif de 0,14 $) sont honnêtes et modestes : moins de 2 OLU pour une tâche de données simple (moins de 0,28 $), environ 10 OLU pour un rapport complexe (~1,40 $), et environ 40 OLU pour une investigation approfondie (~5,60 $).
Voici le piège, et c'est l'élément le plus important de tout cet avis sur PromptQL du point de vue budgétaire. Le prix par OLU est fixe, mais le modèle que vous choisissez change le nombre d'OLU consommés par une tâche, et l'écart est énorme. Par rapport à une base Claude Opus 4.6 de 1,0x, GPT-5.2 tourne à 0,42x, Kimi K2.7 à 0,17x, et DeepSeek V4 Flash aussi bas que 0,018x, ce que Hasura présente comme jusqu'à 57 fois moins cher pour le même travail. Le même rapport peut donc vous coûter quelques dollars ou quelques centimes, selon uniquement le menu déroulant de modèle.
Plutôt que de vous faire faire ce calcul de tête, entrez vos propres chiffres :
Le point à retenir n'est pas un chiffre unique, c'est une habitude : sur PromptQL, choisir un modèle à poids ouverts pour les tâches routinières fait la différence entre une erreur d'arrondi et une vraie ligne de dépense. C'est le même raisonnement de coût total de possession que nous appliquons aux coûts des agents IA, simplement avec le menu déroulant de modèle comme curseur.
Ce que les gens disent vraiment de PromptQL
C'est ici que je dois être franc avec vous, car un avis honnête dit aussi clairement ce qu'il n'a pas pu trouver que ce qu'il a trouvé. L'empreinte publique de PromptQL est mince. Il n'y a aucun avis sur G2 ou Capterra au moment de la rédaction, et les deux lancements officiels « Show HN » n'ont presque rien suscité : six points et quatre commentaires sur l'un, six points et un commentaire sur l'autre. La majeure partie de la conversation se déroule sur les propres canaux de Hasura.
Ce que l'on trouve, c'est que la base de développeurs existante de Hasura apprécie la direction prise. Un utilisateur de longue date, réagissant au lancement :
« J'ai construit et géré plus de 10 bases de code en production utilisant Hasura. À mon avis, c'est une meilleure option que Supabase, Payload et d'autres pour construire son backend. Le fait qu'ils investissent du temps dans des ressources liées aux LLM pour la plateforme me rend heureux que nous l'ayons choisie à l'époque. »
Les chiffres de performance les plus impressionnants sont déclarés par l'éditeur lui-même, à pondérer en conséquence. L'équipe de Hasura rapporte « ~2x de précision et ~4x de reproductibilité » par rapport au tool-calling traditionnel, et Tanmai affirme des « contrats à sept chiffres en trois à cinq mois pour un produit encore en bêta ». Ce sont de vraies citations, mais c'est l'entreprise qui parle d'elle-même, pas un test indépendant, et il n'existe pas encore un corpus d'avis de produit tiers pour trianguler. Pour un produit affichant des logos comme Cisco et McDonald's, la communauté silencieuse est le plus gros signal d'alerte de cet avis.
Où PromptQL gagne, et où il ne gagne pas
Après avoir vécu dans la documentation, les captures d'écran du Playground et la page de tarifs, voici mon bilan honnête.
| Points forts | Points de vigilance |
|---|---|
| L'architecture planifier-puis-exécuter est une véritable réponse à l'IA « qui se trompe avec assurance » | Le marketing (« 100 % de précision », « multiplayer ») devance un historique public encore mince |
| Chaque étape est inspectable : plan de requête, Python/SQL, artefacts, score de fiabilité | La mise en place est un vrai projet de données (connecteurs, métadonnées HML, CLI DDN), pas prêt à l'emploi |
| De vraies jointures inter-systèmes via les métadonnées Hasura DDN | La documentation approfondie est réservée aux utilisateurs inscrits, ce qui rend l'évaluation avant inscription plus difficile qu'elle ne devrait l'être |
| Tarification à la consommation avec un énorme levier de coût via les poids ouverts | La facturation basée sur l'OLU demande du travail à prévoir ; Enterprise est entièrement sur devis |
| Apportez votre propre modèle, auto-hébergement ou VPC | Aucun avis indépendant ni notation par étoiles pour vérifier les affirmations de l'éditeur |
Utilisez PromptQL si vous êtes une équipe de données ou d'analytique avec des données désordonnées et multi-systèmes, de vraies exigences de fiabilité, et l'appétit d'ingénierie nécessaire pour modéliser votre couche sémantique. Le design planifier-puis-exécuter est la réponse la plus crédible que j'aie vue à l'IA qui se trompe avec assurance sur vos données, et la fonctionnalité d'automatisations transformées en API est une vraie réussite.
Passez votre chemin si vous vouliez un assistant clé en main, si vous êtes une petite équipe sans ingénieur de données, ou si votre véritable métier est le support client. Ce n'est pas un remplaçant de chatbot à base de règles, et ce n'est pas du tout destiné au helpdesk.
Essayez eesel pour la version support de cette idée
Si vous êtes arrivé jusqu'ici parce que l'idée d'un « agent fondé qui montre son travail et vous dit quand il n'est pas sûr » vous a parlé, mais que vos données vivent dans un helpdesk plutôt que dans un entrepôt, c'est exactement le problème sur lequel je travaille chez eesel AI. PromptQL apporte la discipline planifier-puis-exécuter au monde de l'analytique de données ; eesel apporte le même réflexe « ne devine pas, fonde-toi, prouve d'abord » au support.
Concrètement : eesel se connecte à votre Slack, votre helpdesk et des sources de connaissances comme Confluence et Notion, répond à partir de ces connaissances avec des citations, escalade plutôt que d'halluciner, et, la partie sans laquelle je ne livrerais rien, simule sur vos anciens tickets avant même de répondre à un vrai client. Auprès de plus de 8 000 clients, il résout une part réelle du volume de niveau 1 dès le premier mois, et la tarification est à l'usage, sans frais par siège. Si PromptQL est le coéquipier fiable pour les données, eesel est le coéquipier fiable pour le support.

Vous pouvez essayer eesel gratuitement, connecter une source en quelques minutes, et lancer une simulation avant de vous engager sur quoi que ce soit.
Foire aux questions
Qu'est-ce que PromptQL, et qui le fabrique ?
Combien coûte PromptQL ?
L'affirmation de « 100 % de précision » de PromptQL est-elle réelle ?
En quoi PromptQL diffère-t-il du text-to-SQL ou du RAG ?
À quelles sources de données PromptQL se connecte-t-il ?
PromptQL vaut-il le coup pour les équipes de support client ?

Article by
Alicia Kirana Utomo
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.








