Nao - Cursor pour les données

• Un éditeur de code IA basé sur VS Code, spécialisé dans les workflows data, qui se connecte directement à BigQuery/Snowflake/Postgres et fournit des fonctions de génération automatique de code adaptée aux schémas de données ainsi que de contrôle qualité
• Alors que les outils existants basés sur des LLM autocomplètent du SQL sans comprendre les schémas de données, nao génère du code SQL/Python/YAML précis grâce à un onglet IA basé sur le RAG et à des outils agentiques
• Il permet de rédiger, exécuter et visualiser des pipelines SQL dans une interface unique
• Les pipelines Python sont également pris en charge dans le même environnement, avec prise en charge des workflows dbt
• Il permet de voir d’un seul coup d’œil les écarts dans les données de résultat avant/après une modification de code ainsi que les problèmes de qualité des données, afin de déployer rapidement sans tests ou d’éviter les erreurs
• Principaux usages
  • Construction de pipelines data (SQL, dbt, etc.)
  • Détection des valeurs manquantes, doublons et anomalies
  • Comparaison entre données de développement et de production
  • Exécution et synthèse de tests prédéfinis
• Intégré à dbt, aux outils BI et aux data warehouses, il offre un environnement IDE adapté aussi bien aux data engineers qu’aux analystes et aux data scientists
• Compatible avec BigQuery, Snowflake et Postgres, avec Databricks, Iceberg et Redshift prévus prochainement
• Intégration également prévue avec Looker, Power BI, Metabase, Tableau
• Actuellement disponible uniquement sur Mac, avec des versions Windows/Linux prévues
• Différences avec Cursor et les MCPs
  • Cursor nécessite plusieurs appels MCP pour obtenir le contexte data, alors que Nao le fournit en permanence via un RAG unique
  • Les MCPs ne fonctionnent que de manière limitée dans Cursor et leur adaptabilité UI est faible
  • Nao est prépackagé : pas besoin de configuration, d’installation d’extensions, d’authentification ni de mise en place CI/CD, ce qui améliore l’expérience de développement même pour les non-spécialistes

FAQ

• Qui devrait utiliser nao ?
  • Les rédacteurs SQL, analytics engineers dbt, data scientists, data engineers, bref tous les membres d’une équipe data
• Quelle différence avec Cursor ?
  • C’est un IDE optimisé pour le contexte data, avec génération de code basée sur la compréhension des schémas de données, contrôle automatique de la qualité des données et prévision de l’impact des changements
• Quels langages sont pris en charge ?
  • Tous les langages sont pris en charge, avec une optimisation particulière pour SQL
• En quoi cela aide-t-il les workflows dbt ?
  • Il comprend les modèles, sources, documentations, tests et lineage au niveau des colonnes dans dbt, et fournit l’autocomplétion ainsi que la visualisation
• Qu’en est-il de la sécurité des données ?
  • Les données sont traitées uniquement en local et l’autorisation de l’utilisateur est demandée avant tout envoi à un LLM
  • Le code et les schémas ne sont pas stockés, seules les embeddings sont utilisées

[GN⁺]

Avis Hacker News

• Beaucoup de projets data basés sur des LLM apportent de la flexibilité et de l’aide, mais restent difficiles à reproduire et manquent d’interactivité ; Nao semble très bien concrétiser cette idée. J’ai créé Buckaroo, une interface de table de données pour Jupyter et Pandas/Polars, qui permet de voir immédiatement les données avec une table moderne, des histogrammes et des statistiques descriptives. J’ai lancé hier une fonction d’auto-nettoyage dans Buckaroo : elle choisit heuristiquement une méthode de nettoyage adaptée aux données et fournit le code validé correspondant. C’est extrêmement rapide, en moins de 500 ms. On peut tester plusieurs stratégies de nettoyage et choisir la plus appropriée. Les problèmes simples n’ont pas forcément besoin de passer par un LLM. C’est open source et très extensible

  • Je développe moi aussi quelque chose de très similaire. Ce n’est pas encore aussi abouti que Buckaroo, mais je trouve les applications embarquées dans les notebooks vraiment utiles

  • J’aime beaucoup la vue qui permet de visualiser le profilage des données ; je pense que c’est essentiel pour bien comprendre les données

• Je trouve que c’est une très belle idée. Je me demande comment le modèle Tab a été entraîné : Fill in the middle, ou à partir de l’historique d’édition ? Quelqu’un a partagé hier un billet de blog sur l’autocomplétion Tab de Cursor, et je l’ai lu avec beaucoup d’intérêt

  • Nous utilisons des modèles Fill in the middle (des modèles entraînés en interne à partir de Mistral et Qwen), en y ajoutant le contexte des données de l’utilisateur. Nous utilisons aussi notre propre parseur SQL pour fournir le contexte de schéma approprié selon la position du curseur

• Après l’avoir utilisé en continu pendant quelques semaines, j’ai constaté une vraie amélioration de mon workflow. Je le choisis désormais plus d’une fois sur deux à la place de VSCode et de ses extensions. Le chat pour l’analyse exploratoire des données, les feuilles de travail et la fonctionnalité de traçage de lignage des colonnes changent complètement la donne pour le développement dbt. Tout cela donne l’impression d’avoir été conçu avec beaucoup de soin pour correspondre à ma façon réelle de travailler. Claire et Christophe réagissent aussi très vite aux retours et ajoutent ou corrigent les fonctionnalités rapidement. Le produit évolue vite dans la bonne direction

  • Merci beaucoup, et merci aussi de nous aider à améliorer nao

• Je trouve ça vraiment séduisant. J’ai regardé la vidéo YouTube plusieurs fois, et j’ai été très impressionné par la manière dont cela raccourcit la boucle de feedback. C’est vraiment génial

  • Merci, c’est exactement notre objectif : raccourcir cette boucle de feedback. Les équipes data ont souvent des boucles de feedback plus longues que les ingénieurs logiciels, et nous essayons de les réduire pour rapprocher davantage la donnée d’un flux de développement

• Je me demande si cela fonctionne uniquement avec du raw SQL. Dans mon projet, j’écris les requêtes avec un query builder comme Kysely sur Postgres + TypeScript ; je me demande si je peux l’utiliser tel quel aujourd’hui

  • Pour le moment, Tab fonctionne surtout bien avec le raw SQL (fichiers SQL purs ou chaînes SQL). En revanche, avec le chat/agent, si vous indiquez que vous utilisez Kysely et que vous fournissez le contexte du data warehouse, cela peut être pris en charge dans une certaine mesure. Je ne connaissais pas Kysely, mais après avoir vu le GIF de présentation du projet, l’autocomplétion a l’air plutôt bonne. C’est différent d’une approche par tabulation, mais intéressant

• Je me demande quelle part de mes données/prompts est transmise au modèle. Mon schéma, ce n’est pas un problème, mais les données du data warehouse sont souvent des données sensibles. J’imagine qu’il existe une offre entreprise, mais j’aimerais savoir à l’avance si des données ou résultats autres que le code sont envoyés au serveur, ou si seul le code l’est

  • Le contenu des données lui-même n’est pas transmis au modèle sauf si l’utilisateur l’autorise explicitement. Le serveur ne stocke que des embeddings de la base de code et du schéma de données. Le contenu des données n’est accessible qu’en local sur la machine de l’utilisateur. Quand l’agent exécute une requête sur le data warehouse, il demande d’abord une autorisation avant de lire les résultats. Sans accord, rien n’est envoyé au LLM et un aperçu local reste possible. Avec la version entreprise, les prompts et le contexte peuvent aussi être protégés séparément sans passer par un endpoint LLM public

• Quelqu’un aurait des recommandations de liens vers des outils basés sur des LLM pour la data engineering et la data science ?

  • Je suis en train de constituer un dépôt de liste de ce type d’outils LLM, et je compte le finaliser bientôt

• J’aime bien les fonctionnalités proposées. Est-ce que la prise en charge de SQLite est aussi prévue à l’avenir ?

  • Bien sûr. Cela ne devrait pas être très difficile à ajouter. DuckDB est aussi prévu dans la prochaine release, et nous pourrons également ajouter SQLite. Je suis curieux de savoir si vous utilisez SQLite pour du développement local

• Je me demande comment c’est géré quand on fait des jointures transitives entre plusieurs tables sans FK/PK. En dehors de ça, une fonctionnalité d’analyse d’usage/réécriture sur des requêtes inefficaces déjà existantes pourrait aussi être un énorme atout

  • Pour les jointures, nous fournissons au modèle le schéma de chaque table ainsi que les types de jointures déjà utilisés dans le dépôt et l’historique des requêtes, afin de l’aider à déduire les relations. L’analyse d’usage fait aussi clairement partie de la feuille de route ; nous prévoyons d’accéder aux logs du data warehouse afin de mesurer l’usage réel de chaque table