Flint – Un langage de visualisation pour l’ère de l’IA

 (microsoft.github.io)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Flint est un langage de visualisation qui détermine automatiquement le parsing, les axes, le formatage et les couleurs à partir de la signification des champs de données, afin de créer et modifier des graphiques sans configuration de bas niveau
  • Il déduit les détails nécessaires à l’encodage visuel à partir de types sémantiques comme Rank, YearMonth, Delta ou Temperature
  • Grâce à un modèle de mise en page élastique et aux principes de banking, il ajuste tailles, espacements et placements ; lorsque le graphique s’étend, il agrandit le canevas et réduit la largeur des bandes pour gérer les compositions denses
  • Il prend en charge 50 types de graphiques dans Vega-Lite, ECharts, Chart.js et Plotly, et génère aussi des graphiques Excel natifs modifiables via Office.js
  • Depuis une interface unique, il permet de changer de backend et de tirer parti des points forts de chaque outil, comme les sunbursts hiérarchiques d’ECharts, les traces statistiques et analytiques de Plotly, ou l’édition dans un classeur Excel

Spécifications fondées sur la sémantique et optimisation automatique

  • Flint déduit le parsing, les échelles, les axes, le formatage et les palettes de couleurs à partir de types sémantiques qui décrivent le sens des champs de données, comme Rank, YearMonth, Delta ou Temperature
    • Dans une heatmap montrant l’évolution nette des nouveaux utilisateurs par jeu et par mois, game est défini comme Category, period comme YearMonth et newUsers comme Profit
    • En fonction de cette sémantique, il détermine automatiquement le parseur de valeurs temporelles, le format des axes, la palette de couleurs divergente et le point médian
  • L’optimisation automatique de la mise en page applique un modèle de mise en page élastique et les principes de banking pour gérer dynamiquement tailles, espacements et placements en fonction du canevas
    • Lorsqu’un graphique à barres groupées passe d’une configuration clairsemée 5 × 3 à une configuration dense 22 × 3, il agrandit le canevas et réduit la largeur des bandes
    • Le fonctionnement est comparable à celui de ressorts qui trouvent leur place dans un conteneur extensible
  • Il est possible de modifier le design simplement en changeant de type de graphique et en reconnectant l’encodage visuel, sans manipuler directement des paramètres de bas niveau fragiles
    • Un graphique à barres facetté représentant la répartition de la population par sexe et par âge dans le recensement américain de 2000 peut être converti en pyramide des âges en changeant uniquement le type de graphique, le compilateur prenant en charge le reste des réglages de bas niveau

Backends pris en charge et versions récentes

  • Flint prend en charge 50 types de graphiques sur Vega-Lite, ECharts, Chart.js et Plotly, et la galerie contient 121 exemples par backend
    • L’interface unifiée masque les API et modèles de programmation propres à chaque backend
    • ECharts peut être utilisé pour les sunbursts hiérarchiques, et Plotly pour les traces statistiques et analytiques
    • Via Office.js, il produit des graphiques Excel natifs pouvant être insérés et modifiés dans un classeur
  • v0.4.0, publiée le 24 juillet 2026, ajoute 38 types de graphiques Plotly et 18 modèles de graphiques Excel natifs modifiables
  • v0.3.0, publiée le 19 juillet 2026, ajoute un widget de graphique dynamique permettant de changer de type de graphique et de modifier les propriétés sur place
  • v0.2.2, publiée le 15 juillet 2026, ajoute le mode compact dodge et une mise en page de violin groupé

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Réactions sur Hacker News

  • Même à l’ère de l’IA, je pense que l’API de ggplot reste la meilleure API de graphiques. La « Grammar of Graphics » n’était pas qu’un slogan marketing, mais une tentative réelle de créer une grammaire capable d’exprimer tous les graphiques qualitatifs possibles
    Ce travail est présenté dans https://link.springer.com/book/10.1007/0-387-28695-0. J’ai découvert ce livre en étudiant d’anciens graphiques dessinés sur papier, et les graphiques des rapports annuels de la Banque centrale d’Australie des années 1960 à 1980 avaient une vraie personnalité, alors qu’au début des années 2000 ils ont été remplacés par des graphiques Excel assez fades
    Même si ggplot ne reproduit pas totalement le charme de ces anciens graphiques, il semble s’en être beaucoup inspiré dans sa manière de transmettre l’information. La section 20.1 recrée le graphique de Minard sur la campagne de Russie de Napoléon, et on peut voir un exemple similaire ici : https://www.andrewheiss.com/blog/2017/08/10/exploring-minard...
    Le rendu est plus agréable que celui de pyplot et des API construites par-dessus, et pyplot semble assez limité par son rendu raster et sa gestion du texte. ggplot est moins connu des ingénieurs logiciels parce qu’il appartient à l’écosystème R, mais j’aimerais que les écosystèmes Node.js et Python s’inspirent davantage de cette API

    • C’est la Grammar of Graphics de Wilkinson qui a inspiré ggplot, et ce manuel ne mentionne même pas ggplot
      J’ai aussi publié Algraf, un DSL créé à partir de la même philosophie : https://williamcotton.github.io/algraf/demos. Les démos incluent aussi le graphique de Minard
    • plotnine pour Python mérite aussi le détour : https://raw.githubusercontent.com/rstudio/cheatsheets/main/p...
      Il a été développé dans l’orbite de RStudio, où travaillait Hadley Wickham, le créateur de ggplot, et il est aujourd’hui soutenu par Posit, où il travaille désormais
    • La spécification JSON du backend Vega-Lite suit elle aussi globalement les idées de la Grammar of Graphics. J’aime davantage ggsql, présenté récemment sur HN : https://ggsql.org/
    • La sémantique de la Grammar of Graphics est déjà idéale pour les humains comme pour les agents. ggsql l’implémente sous forme de fonctions SQL définies par l’utilisateur, donc plus faciles à manipuler pour les agents, et je ne vois pas bien ce que Flint apporte en plus
    • Si vous cherchez un charme dessiné à la main et êtes prêt à utiliser METAPOST, il y a fiziko : https://github.com/jemmybutton/fiziko

  • J’ai essayé Flint ainsi que l’approche consistant à faire générer directement une spécification Vega-Lite par l’IA, et Flint n’était pas une meilleure solution
    Flint est correct pour personnaliser à bas niveau des types de graphiques prédéfinis, mais lorsqu’un agent ou sous-agent produit directement une spécification Vega, on obtient des visualisations bien plus souples et de meilleure qualité, comme l’affichage des minima et maxima d’une série temporelle ou des annotations à des dates d’événements précises
    Cela dit, Vega-Lite exige une validation de spécification et des consignes précises, et il faut continuellement gérer des bugs et comportements étranges. Si l’on veut démarrer vite sans construire une stack dédiée à la création de graphiques, Flint est plus stable

  • On dirait que l’objectif est de piloter plusieurs backends de graphiques via une seule interface, mais si une IA peut écrire du Flint, pourquoi ne pas lui faire écrire directement le code du backend ? La raison de rendre les backends interchangeables n’est pas très claire
    Cela dit, s’il s’agit d’une API simple pour les LLM, cela peut avoir l’avantage d’améliorer l’efficacité en tokens

    • Chaque backend de graphiques prend en charge des types différents. S’il est vraiment facile de passer d’un sunburst ECharts à un histogramme facetté Vega-Lite comme dans les exemples du projet, ce serait très utile

  • Microsoft/Flint-Chart a aussi été présenté le 2 juillet 2026 : https://github.com/microsoft/flint-chart, https://news.ycombinator.com/item?id=48756577
    Le 8 juillet, il a été reposté sous le titre « Show HN: Microsoft releases Flint, a visualization language for AI agents » : https://microsoft.github.io/flint-chart/#/, https://news.ycombinator.com/item?id=48834924

  • Quel est le problème, au fond, avec le simple fait de dire « fais-moi un graphique XYZ avec plotly » ?

    • Dans la visualisation automatisée de données, cette approche nécessite un sandbox pour exécuter le code JavaScript ou Python généré. Avec une spécification comme Flint, on peut valider puis afficher directement, et si le LLM génère mieux du Flint que du Vega-Lite, cela peut être utile

  • Il y a déjà eu une discussion plus importante il y a 22 jours : https://news.ycombinator.com/item?id=48834924

  • Un DSL pour l’IA ne semble pas très pertinent. Les modèles ont été entraînés sur des bibliothèques graphiques existantes et les manipulent déjà plutôt bien
    À long terme, après avoir publié Flint, des labos pourraient créer un « benchmark graphique » pour suradapter leurs modèles à ce DSL, mais cela semble demander énormément de travail

  • Je ne sais pas à partir de quel niveau une abstraction devient excessive. Est-ce que Plotly ou Plotly Express ne suffisent pas déjà, et en quoi une spécification JSON de plus ouvrirait-elle une nouvelle ère ?

  • C’est intéressant, mais je ne sais pas si c’est vraiment nécessaire. Il existe déjà beaucoup de bibliothèques de graphiques matures, dont Apache ECharts, et au final cela ressemble à une réinvention de la roue
    Un nouvel outil sort, on lui ajoute progressivement des fonctionnalités, puis un autre outil, avec une conception et une syntaxe légèrement différentes, finit par remplacer l’outil d’origine
    On peut aussi exploiter les forces propres à chaque backend : ECharts pour les sunbursts hiérarchiques, Plotly pour les tracés statistiques et analytiques, Excel pour les graphiques à éditer dans un classeur. Ou alors mieux vaut choisir une bibliothèque de graphiques qu’on aime et bien en maîtriser les fonctionnalités, plutôt que de mélanger les préréglages de plusieurs bibliothèques sans vraiment peaufiner les détails