Le modèle n'écrit pas le chiffre

Vous posez une question sur vos données à un modèle de langage. Il répond un chiffre. Le chiffre est plausible, et il est faux. Personne ne signe un comité de direction sur un chiffre plausible, et c'est ce qui bloque le plus de déploiements en entreprise, bien avant les questions de budget ou de réglementation.

La réponse n'est pas de mieux demander. Elle est de retirer au modèle la possibilité de se tromper sur le chiffre : il n'écrit pas la réponse, il écrit la requête. La base, elle, répond ce qu'elle contient. Le déplacement paraît mince ; il change la nature de l'erreur. Une requête fausse se voit, se journalise, se rejoue et se corrige. Un chiffre halluciné ne se voit pas, parce qu'il ressemble exactement à un chiffre juste.

Cet article suit quatre questions réellement posées à un déploiement en entreprise, dans l'ordre où elles se posent en réunion : un chiffre du mois dernier, une prédiction ligne à ligne, une prévision à trois mois, puis un graphique. Trois étages sur un même socle, dont le nom se lit comme une adresse : txt2sql pour le chiffre, txt2sql2ml pour la prédiction, txt2sql2viz pour la figure. Le premier étage est un terrain balisé de l'industrie ; les deux autres sont beaucoup plus rares, et ce sont ceux que j'ai construits.

« Combien de factures sont en retard de paiement ? »

La réponse arrive en deux secondes : treize. Et, dépliée sous elle, la requête qui l'a produite.

SELECT COUNT(*) FROM invoices WHERE status = 'overdue' LIMIT 500

Cette requête affichée n'est pas une coquetterie de transparence. C'est la pièce à conviction : le lecteur qui connaît sa base peut la lire, la contester, la rejouer. Le chiffre n'est pas à croire, il est à vérifier.

Écrire du SQL en général, un modèle de langage récent le fait très bien. La difficulté est ailleurs, et elle est entière : écrire la requête juste pour cette base. Les bons noms de tables, les bonnes jointures, et surtout les bonnes valeurs de filtre. Le statut d'une facture impayée s'écrit-il overdue, unpaid ou 3 ? Un modèle qui ignore le schéma invente des noms plausibles et faux. Toute la valeur d'un outil de traduction de question en requête tient là : ancrer la génération dans la réalité d'une base donnée.

Deux familles de solutions existent. Le réglage fin réentraîne un modèle sur les données du client : coûteux, lent, et à recommencer à chaque évolution du schéma. La génération augmentée par récupération laisse le modèle intact et lui fournit, à chaque question, les éléments de contexte utiles². Vanna, l'outil libre qui fait référence sur ce terrain, relève de la seconde famille¹.

Un point déroute d'emblée, et c'est le plus important : chez Vanna, le mot « entraîner » désigne le remplissage d'une base de connaissances que le système consultera au moment de répondre. Aucun poids de réseau de neurones n'est modifié. On range des textes, on les retrouve par similarité de sens, on les colle dans la question posée au modèle³.

Les trois matières, dans l'ordre inverse de l'intuition

On range trois types de contenu, et l'intuition se trompe sur leur poids respectif.

La structure des tables vient en premier dans le temps : le CREATE TABLE de chaque table, ses colonnes, ses types, ses clés. Elle apprend au modèle ce qui existe et l'empêche d'inventer. Une table par entrée, pour que chacune se retrouve séparément.

La documentation métier encode ce que la structure ne dit pas : la définition d'une mesure, le vocabulaire maison, le sens des valeurs codées. Une affirmation autonome par entrée, tournée comme un utilisateur la dirait. « Le chiffre d'affaires hors taxes des commandes s'obtient en additionnant orders.total_ht_eur. » C'est là que l'on gagne le plus sur les définitions, précisément là où un modèle sans contexte se trompe le plus.

Les paires question vers requête arrivent en dernier dans l'ordre du travail et en premier dans l'ordre du gain. Une question en français, la requête juste correspondante. La documentation de Vanna le pose sans détour : leur qualité est le principal déterminant du résultat¹. Le mécanisme l'explique. Seul ce qui est récupéré influence une réponse ; la base de connaissances n'est jamais versée en entier. Un exemple juste et proche de la question posée vaut donc mille exemples lointains. On range pour la couverture, pas pour le volume : vingt à cent paires vérifiées suffisent à démarrer, à condition qu'elles couvrent les familles de requêtes que les utilisateurs produiront, du comptage à la jointure, du filtre sur valeur codée au palmarès des plus gros⁹.

Deux règles de curation priment, et la seconde est une règle de sûreté. Toujours du SQL vérifié, c'est-à-dire réellement exécuté et confirmé juste : une paire fausse apprend au système à produire du SQL faux. Et jamais de SELECT *, qui n'apprend aucun nom de colonne à personne.

Deux verrous entre le modèle et la base

Le modèle produit une requête, et rien de plus. L'exécution se fait ailleurs, avec un rôle de base en lecture seule et des garde-fous qui analysent la requête avant de la lancer. Analyser, ici, veut dire la lire comme un compilateur la lirait, sous forme d'arbre syntaxique⁴, et refuser tout ce qui n'est pas une lecture. La séparation relève de la sécurité, pas de l'élégance : le composant qui parle au modèle n'a jamais le droit d'écrire dans la base.

Le second verrou est né d'un échec précis, daté du 4 septembre 2026. Jusque-là, le modèle recevait les noms et les types des colonnes, jamais leur domaine, c'est-à-dire l'ensemble des valeurs qu'elles prennent réellement. Il a donc écrit WHERE status = 'confirmed' sur la table des factures. Syntaxiquement valide. Accepté par les garde-fous. Exécuté sans erreur. Zéro ligne. Les vraies valeurs étaient paid, overdue et sent ; confirmed appartenait à la table des commandes, une autre table. L'utilisateur voyait un résultat vide, sans la moindre explication.

Ce défaut se répare des deux côtés. En prévention, chaque colonne de faible cardinalité reçoit son domaine réel, lu dans la base et écrit dans le contexte donné au modèle : d'abord les types énumérés, que la base connaît exactement et gratuitement, puis les colonnes textuelles que les statistiques de la base déclarent de faible cardinalité, dont on relit le domaine par une lecture bornée. Une colonne sans statistiques n'est jamais sondée : mieux vaut pas de domaine qu'un domaine faux. En réparation, une requête qui s'exécute sans erreur mais ne ramène aucune ligne, et qui filtre sur un littéral absent du domaine connu, ne rend plus un vide muet ; une seconde tentative est faite en donnant les vraies valeurs au modèle, et à défaut la réponse nomme la colonne, le littéral inventé et le domaine réel.

Prouver que tout ce travail sert à quelque chose

Voilà l'étape que l'on saute trop souvent, et la seule qui prouve que la curation a servi. On réserve quelques paires que l'on n'entraîne pas, un jeu de contrôle. Mesurée sur des questions déjà rangées, la justesse ne dit rien de plus que l'aptitude du système à ressortir un exemple mémorisé.

Trois métriques sont possibles, de la plus faible à la plus fiable. Le taux de SQL valide est un simple garde-fou : une requête peut être valide et fausse. La correspondance textuelle, qui compare les deux requêtes caractère par caractère, sous-compte gravement la justesse, puisque deux requêtes justes s'écrivent presque toujours autrement⁵. La bonne métrique est la correspondance à l'exécution : on exécute en lecture seule la requête produite et la requête de référence, et l'on compare les résultats, à l'ordre près. C'est la métrique des bancs d'essai du domaine, Spider⁶ et BIRD⁷, parce qu'elle juge la réponse rendue, seule chose qui compte.

Une note globale, seule, masque la famille de requêtes qui échoue⁸. On ventile donc par motif, et cette lecture guide la suite : des jointures faibles appellent des exemples de jointures, pas un modèle plus gros. C'est exactement ce qui s'est passé ici, et c'est le saut de 87,5 % à 100 % sur la figure.

« Quels clients risquent de partir, et avec quelle confiance ? »

Un chiffre exact répond à une question au passé. Combien avons-nous facturé le mois dernier, quels clients ont dépassé leur budget. Il ne répond pas à celle que le dirigeant pose juste après, et qui décide de quelque chose. Jusqu'ici, cette seconde question appelait un projet de science des données de plusieurs mois, par client et par question.

L'idée qui change cela tient en une phrase. La requête ne ramène plus un chiffre : elle ramène un tableau dont la dernière colonne est la question, connue pour certaines lignes, vide pour celles à prédire.

Une seule question, une seule requête, et les trous se remplissent. Le SQL ne sait pas prédire ; il sait aller chercher la bonne forme de tableau.

Ce tableau contient à la fois l'exemple et la question. C'est exactement ce qu'un modèle tabulaire fondationnel sait lire. Un tel modèle a été pré-entraîné une fois pour toutes, chez son laboratoire, sur des tableaux synthétiques ; il ne connaît pas vos données, il connaît la façon dont un tableau se comporte. On lui montre celui-ci, il remplit les trous en un seul passage, sans descente de gradient, sans apprentissage sur vos données, sans modèle à stocker.

On appelle cela l'apprentissage en contexte, et l'analogie qui porte est celle que tout le monde a déjà vécue : donner un exemple à un assistant conversationnel dans la conversation elle-même, et le voir comprendre sans qu'on le réentraîne¹⁰. L'analogie a une limite, et elle est instructive : un texte se lit de gauche à droite, un tableau n'a pas d'ordre, ni entre ses lignes ni entre ses colonnes. C'est précisément le problème que ces modèles ont eu à résoudre.

Conséquence directe : zéro projet d'entraînement, zéro artefact à maintenir. Le jour où l'on branche un nouveau client, il n'y a pas de modèle à réentraîner. Un même code couvre la classification, la régression, le remplissage de trous et le classement des N premiers.

Deux écoles européennes, et pourquoi j'ai choisi la française

Ce terrain est tenu par deux équipes, et les deux sont européennes. L'école allemande, à Fribourg-en-Brisgau, autour de Frank Hutter, a produit TabPFN, publié dans Nature en janvier 2025¹¹. Sa suite industrielle, Prior Labs, a été rachetée par SAP : annonce en mai 2026, clôture le 17 juillet, plus d'un milliard d'euros engagés sur quatre ans¹². Un éditeur allemand qui met un milliard sur un laboratoire allemand de dix-huit mois valide le sujet mieux que n'importe quel argument que je pourrais avancer.

L'école française est à l'Inria Saclay, dans l'équipe SODA, autour de Gaël Varoquaux, co-créateur de scikit-learn. Son modèle s'appelle TabICL. Sur deux cents jeux de données de classification, il fait jeu égal avec TabPFN v2 tout en étant systématiquement plus rapide, jusqu'à dix fois, et il le dépasse sur les tableaux de plus de dix mille lignes¹³.

Mon choix s'est porté sur TabICL, et pas par patriotisme : le code et les poids sont publiés¹⁴. C'est le seul des deux qu'un client peut auditer ligne à ligne et exécuter chez lui, sans rien envoyer dehors. Quand on répond « ce client va partir » à un dirigeant, pouvoir montrer d'où vient la réponse n'est pas un supplément d'âme.

Savoir qui va partir sans savoir pourquoi ne sert à rien. Chaque prédiction vient donc avec le poids de chaque variable et son sens, par les deux méthodes de référence : l'attribution par valeurs de Shapley, empruntée à la théorie des jeux, qui répartit la prédiction entre les variables comme on répartit un gain entre des joueurs¹⁵, et l'explication locale par substitut linéaire, qui approche le modèle autour de la ligne examinée par un modèle simple et lisible¹⁶. Les deux sont montrées côte à côte : quand elles divergent, c'est en soi une information.

« Quelle est la prévision du chiffre d'affaires pour les trois prochains mois ? »

Même socle, même modèle, autre question. La requête ramène cette fois une série dans le temps, et la réponse porte sur les mois qui n'existent pas encore.

Un chiffre unique sur l'avenir, c'est de la voyance ; un chiffre avec sa fourchette, c'est une décision. Et cette figure-là dit quelque chose de désagréable qu'il faut savoir lire : la fourchette est plus large que l'écart entre les trois mois. Le mois d'août paraît meilleur que juillet, mais les barres se recouvrent presque entièrement, si bien que l'écart entre eux n'est pas interprétable.

Ce n'est pas un défaut de l'outil, c'est un verdict sur la donnée. La série mensuelle de cette base de démonstration est du bruit : sur vingt et un mois, 293 euros un mois contre 72 380 un an plus tard, et trois mois manquants. Aucune méthode ne peut prévoir cela, et la seule réponse honnête est une fourchette large. Un outil qui aurait rendu trois beaux chiffres alignés aurait maquillé la situation. C'est le même principe qu'au premier étage : la garantie ne porte pas sur la qualité de la réponse, elle porte sur le fait que la réponse ne peut pas mentir sur sa propre incertitude.

Un détail d'implémentation dit bien dans quel monde on travaille. L'horizon de prévision est lu dans la question de l'utilisateur, donc dans du texte libre. « Dans cent mille mois » se traduisait en cent mille périodes à prévoir, c'est-à-dire des dates hors bornes et un calcul qui monopolise la machine pour un résultat que personne n'a demandé sérieusement. L'horizon est désormais plafonné : au-delà, une prévision n'a de toute façon aucune valeur statistique, la borner n'ampute rien de réel.

« Montre-moi où se concentre le chiffre d'affaires »

Dernière question, dernier maillon différent : le résultat n'est plus un nombre ni un tableau, c'est une figure. Elle est choisie automatiquement selon la forme de la donnée et l'intention de la question, et rendue en direct, sans tableau de bord préconstruit à maintenir. La nuance a son prix pour qui décide : un tableau de bord répond aux questions d'il y a six mois.

Reste que ce choix est justement l'endroit où un modèle de langage peut faire n'importe quoi. Montrez-lui cent vingt-sept noms de graphiques, il peut en inventer un, en mal orthographier un, ou en choisir un incompatible avec les colonnes présentes, par exemple une carte quand aucune colonne ne porte de géographie. La garantie ne peut donc pas être une promesse de bonne conduite. Elle doit être dans la structure.

Le modèle choisit le plat dans un menu qu'il n'a pas écrit. C'est une garantie d'un autre ordre qu'un réglage de température ou qu'une consigne ajoutée au début de la conversation : elle ne dépend pas de la docilité du modèle, elle dépend de la forme du programme. Et, comme au premier étage, elle rend l'erreur restante visible et traitable : une figure mal classée se corrige d'un clic, elle ne se confond pas avec une figure juste.

Le rendu tourne sur sprezzature.ai, un moteur de figures libre¹⁹. Son catalogue compte cent vingt-sept types de graphiques, des courbes aux diagrammes de flux, treemaps, cascades, essaims et cartes. Ce n'est pas de la gourmandise : plus le catalogue est large, plus la liste des candidats compatibles avec des colonnes données est riche, et plus le choix automatique tombe juste.

Chaque figure respecte en outre un standard d'accessibilité et de rigueur chromatique : contraste vérifié, lisible en daltonisme, jamais une couleur seule porteuse d'information, polarité annoncée sur tout axe qui a un bon sens. Ce n'est pas cosmétique. Un graphique mal contrasté projeté dans une salle, personne ne le lit ; et un graphique qui exige de distinguer deux verts exclut un homme sur douze. Les règles héritées de la sémiologie graphique¹⁷ et des mesures de perception¹⁸ sont ici du code, pas des recommandations.

Ce que la production apprend et que la préparation ne peut pas deviner

Aucune curation en amont ne connaît la façon dont les utilisateurs vont formuler leurs demandes, ni les tournures, les raccourcis et les cas particuliers propres à chaque organisation. La production révèle cette distribution réelle des questions. Chaque question bien traitée, et surtout chaque correction, est une information que la curation initiale n'avait pas.

La boucle est simple à énoncer : une personne pose une question, le système produit la requête, elle s'exécute en lecture seule, un humain valide le résultat ou corrige la requête, et c'est seulement une fois validée que la paire rejoint l'index. La question semblable suivante retrouve alors ce nouvel exemple.

La règle de sûreté est absolue et c'est la plus facile à rater : jamais d'apprentissage aveugle. Capturer automatiquement toute requête générée pour la réinjecter comme exemple empoisonne la récupération pour toutes les questions semblables à venir. Du mauvais SQL apprend au système à produire du mauvais SQL. Une paire n'est donc acceptée que par une voie de retour dédiée, qui rejoue les garde-fous et réexécute la requête avant de l'accepter : aucune confiance aveugle, même envers ce que l'appelant présente comme déjà vérifié.

Quatre propriétés séparent un mécanisme qui marche sur un poste d'une boucle de production. La persistance, car l'index vit dans la base déjà en place²⁰ et non dans un cache perdu au premier redémarrage. L'idempotence, l'identifiant d'une paire dérivant de son contenu, si bien que la resoumettre ne crée pas de doublon qui encombrerait la récupération. La traçabilité, chaque paire issue du terrain étant marquée comme telle, distincte du corpus curé, ce qui permet d'auditer ce que la production a appris au système et de retirer un mauvais exemple précis. Et la mesure : après un lot d'ajouts, on rejoue le jeu de contrôle. Le progrès se vérifie, il ne se suppose pas.

Ce que cela change, et ce que cela ne change pas

Avant, une question métier part en ticket vers l'équipe data et revient dans trois jours, souvent après que la décision a été prise sans elle. Une question prédictive, elle, part en projet. Après, la question est posée à voix haute, la réponse chiffrée arrive en quelques secondes, et la question suivante aussi : la réunion garde son rythme. Ce qui compte n'est pas que la machine fasse de l'analyse, c'est que le délai entre la question et le chiffre fiable passe de trois jours à trois secondes sans dégrader la fiabilité, puisque le chiffre vient de la base.

Ce que cela ne change pas mérite d'être dit aussi clairement. Le modèle peut toujours écrire une mauvaise requête : la garantie porte sur la visibilité de l'erreur, pas sur son absence. La limite réelle n'est pas le volume de données, puisque le pipeline attaque la base et non un export, et que c'est le SQL qui filtre ; la limite est la qualité du schéma et du vocabulaire. Une base dont les colonnes s'appellent col_17 ne se laissera pas interroger en français, et aucun modèle n'y changera rien.

Les trois lignes

txt2sql question → SQL → base → le chiffre réel txt2sql2ml question → SQL → tableau à trous → la prédiction et sa fourchette txt2sql2viz question → SQL → lignes → le bon graphique, en direct

Un seul socle, trois étages. À chacun, la même discipline : le modèle propose la forme, la machine vérifie, et la donnée tranche. C'est ce qui sépare un chiffre que l'on peut signer d'un chiffre qui a seulement l'air juste.

Bibliographie

Les travaux ci-dessous sont ceux sur lesquels cette chaîne s'appuie réellement, dans l'ordre où l'article les mobilise. Chaque notice dit ce que la source établit et à quel endroit elle sert ici.

1. Vanna AI. Training advice, documentation du projet. vanna.ai/docs/training-advice Pose sans détour la hiérarchie des trois matières et la règle de sûreté reprise ici : la qualité des paires question vers requête est le principal déterminant du résultat, et du mauvais SQL appris apprend au système à produire du mauvais SQL.
2. Lewis, P. et al. (2020). « Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks », NeurIPS. arXiv:2005.11401 L'article qui a donné son nom à la génération augmentée par récupération. Il établit le principe employé au premier étage : laisser le modèle intact et lui fournir, à chaque question, les éléments de contexte utiles, plutôt que de réentraîner ses poids.
3. Vanna AI (2023). How Vanna works, how to train it, data security. medium.com/vanna-ai Décrit pas à pas le mécanisme de récupération dont dépend tout le reste : la question est vectorisée, les connaissances les plus proches sont ramenées par type, et seules celles-là entrent dans le contexte. C'est de là que vient la règle « la couverture prime sur le volume ».
4. Mao, T. sqlglot, analyseur et transpileur SQL en Python, licence MIT. github.com/tobymao/sqlglot L'analyseur qui transforme la requête produite en arbre syntaxique avant toute exécution. C'est lui qui rend les garde-fous possibles : on inspecte la structure de la requête, pas une chaîne de caractères, et l'on refuse tout ce qui n'est pas une lecture.
5. Pourreza, M. et Rafiei, D. (2023). « Evaluating Cross-Domain Text-to-SQL Models and Benchmarks », EMNLP. arXiv:2310.18538 Montre que les notes des bancs d'essai sous-estiment les modèles, parce qu'une question en langue naturelle admet plusieurs requêtes justes. Justifie le choix de la correspondance à l'exécution contre la comparaison textuelle, fait ici.
6. Yu, T. et al. (2018). « Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task », EMNLP. arXiv:1809.08887 Le banc d'essai qui a fixé les usages du domaine, à commencer par l'évaluation sur des bases jamais vues à l'entraînement. Le jeu de contrôle tenu à l'écart décrit ici en est la transposition à l'échelle d'un seul client.
7. Li, J. et al. (2023). « Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs », NeurIPS. arXiv:2305.03111 Le banc d'essai BIRD, bâti sur de vraies bases, sales et volumineuses. Il documente l'écart entre une requête syntaxiquement correcte et une requête juste, qui est exactement l'écart que le bug du domaine de colonne a fait apparaître ici.
8. Zavaleta, G. (2026). « Why 90 % accuracy in text-to-SQL is 100 % useless », Towards Data Science. towardsdatascience.com Défend la lecture par catégorie contre la note globale : une justesse moyenne élevée cache la famille de requêtes qui échoue, et c'est celle-là qui décide de l'usage réel. C'est la lecture qui a désigné ici les jointures et un filtre, et permis le renfort ciblé.
9. NVIDIA. NeMo Agent Toolkit, text-to-SQL, documentation technique. docs.nvidia.com Donne indépendamment le même ordre de grandeur pour le corpus d'exemples et la même exigence de validation sur un jeu tenu à l'écart. Deux sources d'origines très différentes qui convergent sur « vingt à cent paires bien choisies ».
10. Brown, T. et al. (2020). « Language Models are Few-Shot Learners », NeurIPS. arXiv:2005.14165 L'article qui a établi l'apprentissage en contexte : un exemple donné dans la conversation suffit à orienter le modèle, sans toucher à ses poids. Les modèles tabulaires fondationnels transposent exactement cette idée d'un texte à un tableau.
11. Hollmann, N., Müller, S., Purucker, L. et al. (2025). « Accurate predictions on small data with a tabular foundation model », Nature, 637, 319-326. 10.1038/s41586-024-08328-6 TabPFN, l'école allemande. Établit qu'un modèle pré-entraîné une fois sur des tableaux synthétiques bat, en un seul passage et sans réglage, des méthodes ajustées sur les données elles-mêmes. C'est le résultat qui rend ce deuxième étage possible.
12. SAP (2026). SAP Completes Prior Labs Acquisition, communiqué du 17 juillet 2026. news.sap.com Le rachat du laboratoire de Fribourg, annoncé en mai et clos en juillet 2026, avec plus d'un milliard d'euros engagés sur quatre ans. Cité ici comme mesure de l'intérêt industriel porté aux modèles tabulaires, et non comme argument technique.
13. Qu, J., Holzmüller, D., Varoquaux, G. et Le Morvan, M. (2025). « TabICL: A Tabular Foundation Model for In-Context Learning on Large Data », ICML. arXiv:2502.05564 L'école française. Une attention par colonnes puis par lignes construit une représentation de taille fixe pour chaque ligne, ce qui permet de tenir des tableaux bien plus grands. Jeu égal avec TabPFN v2 sur deux cents jeux de données, jusqu'à dix fois plus rapide, et au-dessus au-delà de dix mille lignes.
14. Équipe SODA, Inria. tabicl, code et poids du modèle. github.com/soda-inria/tabicl La raison concrète du choix fait ici : le code d'entraînement, le code d'inférence et les poids sont publiés, donc auditables et exécutables chez le client, sans qu'aucune donnée ne sorte.
15. Lundberg, S. et Lee, S.-I. (2017). « A Unified Approach to Interpreting Model Predictions », NeurIPS. arXiv:1705.07874 Importe en apprentissage la valeur de Shapley, qui répartit un gain collectif entre des joueurs selon leur contribution marginale moyenne. Appliquée à une prédiction, elle dit combien chaque variable a pesé, et dans quel sens.
16. Ribeiro, M. T., Singh, S. et Guestrin, C. (2016). « Why Should I Trust You? Explaining the Predictions of Any Classifier », KDD. arXiv:1602.04938 L'explication locale par substitut : on approche le modèle, au voisinage de la seule ligne examinée, par un modèle simple et lisible. Montrée ici à côté de la précédente, parce que deux méthodes qui divergent sur une ligne sont un signal en soi.
17. Bertin, J. (1967). Sémiologie graphique. Les diagrammes, les réseaux, les cartes, Gauthier-Villars. Le traité qui établit qu'une forme graphique n'est pas un habillage mais un encodage, et que chaque variable visuelle a ses propriétés propres. C'est le fondement du filtre déterministe : une figure incompatible avec les colonnes présentes ne doit jamais être proposée.
18. Cleveland, W. S. et McGill, R. (1984). « Graphical Perception: Theory, Experimentation, and Application to the Development of Graphical Methods », Journal of the American Statistical Association, 79(387), 531-554. 10.1080/01621459.1984.10478080 Classe expérimentalement les encodages visuels par précision de lecture, la position sur une échelle commune devant la longueur, elle-même devant l'angle et la surface. C'est la mesure qui justifie les règles appliquées automatiquement aux figures de cet article.
19. Harchaoui, W. sprezzature-figures, moteur de figures libre. github.com/warith-harchaoui/sprezzature-figures Le catalogue de cent vingt-sept types de graphiques du dernier étage, et le vérificateur qui accompagne chacun : contraste, polarité annoncée, étiquettes qui ne se chevauchent pas. Les six figures de cet article en sortent.
20. pgvector, extension de recherche vectorielle pour PostgreSQL, licence PostgreSQL. github.com/pgvector/pgvector Permet de ranger la base de connaissances dans le PostgreSQL déjà en place, donc sans rien déployer de neuf. C'est ce qui donne à la boucle d'amélioration sa persistance : les exemples validés survivent aux redémarrages et sont communs à toutes les instances du service.

Pour aller plus loin, deux lectures plus larges que le sujet de cet article : mes livres préférés en IA pour le panorama commenté, et The Visual Display of Quantitative Information d'Edward Tufte pour tout ce que le dernier étage automatise sans pouvoir le remplacer : le jugement sur la question que la figure doit poser.