Le modèle n'écrit pas le chiffre

Vous posez une question sur vos données à un modèle de langage, ce programme qui sait lire et écrire du texte et qui alimente les assistants conversationnels. Il répond un chiffre. Le chiffre est plausible. Il est faux. Personne, en comité de direction, ne signe sur un chiffre plausible. Voilà ce qui bloque le plus de déploiements en entreprise, bien avant les questions de budget ou de réglementation.

Posons le décor, parce que tout l'article tient dans trois mots. Une base de données est un ensemble de grands tableaux, cousins des feuilles de calcul : une table des clients, une table des factures, des milliers de lignes chacune. Une requête est une question posée à ces tableaux dans un langage fait pour cela, le Structured Query Language, SQL : une langue rigide, sans double sens, qui dit exactement quelles lignes prendre et quoi en faire. Le modèle de langage, lui, comprend le français ; il sait aussi écrire du SQL. Toute la suite tient dans cette rencontre.

Car la réponse au chiffre faux 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. La nuance a l'air de rien ; elle change la nature de l'erreur. Une requête fausse se voit, s'enregistre, se rejoue, se corrige. Un chiffre halluciné ne se voit pas, parce qu'il ressemble exactement à un chiffre juste.

Cet article suit quatre questions vraiment 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. 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

Même sans avoir jamais lu de SQL, on la déchiffre : compte (COUNT) les lignes de la table des factures (invoices) dont le statut vaut « en retard » (overdue), sans jamais en ramener plus de cinq cents (LIMIT 500).

L'afficher 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, entière : écrire la requête juste pour cette base. Les bons noms de tables, les bonnes jointures (l'opération qui relie deux tables par une colonne commune, les factures à leurs clients par exemple), 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, le plan de la base, la liste de ses tables et de leurs colonnes, 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 (fine-tuning) renvoie le modèle à l'école : on reprend son entraînement sur les données du client pour qu'il les connaisse par cœur. Coûteux, lent, à recommencer à chaque évolution du schéma. La génération augmentée par récupération (Retrieval-Augmented Generation, RAG) laisse le modèle intact : à chaque question, on lui glisse une fiche de révision, les quelques éléments de contexte utiles pour cette question précise². 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, le plus important de tous : 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. Rien ne change dans le modèle lui-même : aucun de ses réglages internes, ses poids, n'est modifié. On range des textes dans une sorte de bibliothèque, on retrouve ceux qui parlent de la même chose que la question posée, même dits avec d'autres mots, on les colle dans la question donnée au modèle³.

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

Trois types de contenu entrent dans cette bibliothèque. L'intuition se trompe sur leur poids respectif.

La structure des tables vient en premier dans le temps. C'est le CREATE TABLE de chaque table, sa carte d'identité en somme : son nom, ses colonnes, le type de chacune (nombre, texte, date) et ses clés, ces colonnes qui la relient aux autres tables. 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 quand une question la concerne.

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, là même 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. À chaque question, le système ne montre au modèle que les quelques fiches les plus proches ; le reste de la bibliothèque n'existe pas pour lui. 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⁹. Cet ordre de grandeur vaut pour un schéma de cette taille ; ce n'est pas une règle générale. Il dépend du nombre de tables, de l'ambiguïté du vocabulaire métier, du nombre de domaines fonctionnels et surtout de la distribution réelle des questions posées.

Deux règles de curation (le tri soigneux de ce qui entre dans la bibliothèque) priment. 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 *, la requête qui ramène toutes les colonnes sans en nommer aucune : elle n'apprend aucun nom de colonne à personne.

Deux verrous entre le modèle et la base

Le modèle produit une requête, rien de plus. L'exécution se fait ailleurs, avec un rôle de base en lecture seule, un compte qui a le droit de consulter les tableaux, jamais de les modifier et des garde-fous qui analysent la requête avant de la lancer. Analyser, ici, veut dire la décomposer comme on fait l'analyse grammaticale d'une phrase, sujet, verbe, compléments : cette décomposition s'appelle un arbre syntaxique⁴. C'est en lisant cet arbre que la chaîne refuse tout ce qui n'est pas une simple lecture. La séparation relève de la sécurité, non 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 contiennent pour de vrai. 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, on s'occupe des colonnes de faible cardinalité, celles qui ne prennent qu'une poignée de valeurs distinctes : un statut, une catégorie, jamais un montant. Chacune reçoit son domaine réel, lu dans la base, puis écrit dans le contexte donné au modèle. D'abord les types énumérés, ces colonnes dont la base connaît par construction la liste exacte des valeurs permises ; puis les colonnes de texte 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, alors qu'elle filtre sur une valeur écrite en toutes lettres (un littéral) absente du domaine connu, ne rend plus un vide muet. Une seconde tentative est faite en donnant les vraies valeurs au modèle ; à 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. C'est pourtant la seule qui prouve que la curation a servi. On réserve quelques paires que l'on ne range pas dans la bibliothèque : un jeu de contrôle. Le principe est celui de tout examen : on ne note pas un élève sur les exercices dont il a le corrigé sous les yeux. 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 façons de compter les points 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 mesure est la correspondance à l'exécution : on exécute en lecture seule la requête produite et la requête de référence, puis l'on compare les résultats, à l'ordre près. C'est la mesure des bancs d'essai du domaine, ces jeux publics de questions sur lesquels toutes les équipes se comparent, 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 la note par famille : comptages, jointures, filtres, palmarès. 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 ; 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, celle qui engage l'avenir et décide de quelque chose. Jusqu'ici, cette seconde question appelait un projet de plusieurs mois confié à des spécialistes des données, par client et par question.

L'idée qui change cela est simple. 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 : 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 millions de tableaux synthétiques, fabriqués pour l'exercice. Il ne connaît pas vos données ; il connaît la façon dont un tableau se comporte, comme un correcteur qui a lu des milliers de copies reconnaît une erreur au premier coup d'œil sur une copie qu'il n'a jamais vue. On lui montre celui-ci, il remplit les trous en un seul passage : aucun entraînement sur vos données, aucun réglage interne modifié, aucun modèle à stocker.

On appelle cela l'apprentissage en contexte. 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, 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 le problème mê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 (prédire une catégorie : partira, partira pas), la régression (prédire un nombre : le montant du mois prochain), le remplissage de trous et le classement des N premiers.

Deux écoles européennes et pourquoi j'ai choisi la française alors qu'il y a aussi Google dans la danse

Jusqu'à l'automne 2026, ce terrain a été tenu par deux équipes, toutes deux 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 dit l'intérêt industriel porté au sujet. C'est un signal de marché, pas une preuve technique.

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 et il faut le dater, car l'écosystème bouge vite. La première version, présentée à ICML en 2025, fait jeu égal avec TabPFN v2 sur deux cents jeux de données de classification, tout en étant systématiquement plus rapide, jusqu'à dix fois ; elle le dépasse sur les tableaux de plus de dix mille lignes¹³. La deuxième, TabICLv2, livrée en février 2026, ajuste et prédit un tableau de cinquante mille lignes sur cent variables en moins de dix secondes sur un processeur graphique H100¹⁴. Les comparaisons de cet article portent sur la première ; les dater évite de les lire comme un état permanent.

Mon choix s'est porté sur TabICL, pas par patriotisme. Les deux modèles tournent chez le client sans que rien ne sorte et les deux publient leurs poids, c'est-à-dire les milliards de réglages internes appris pendant l'entraînement. TabICL publie en plus le code qui a servi à l'entraîner¹⁴, générateur de données synthétiques compris. La différence se voit dès qu'on veut vérifier quelque chose : avec les poids seuls, on peut rejouer les prédictions ; avec le code d'entraînement, on peut refaire le modèle depuis le début. 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.

Le 29 septembre 2026, un troisième joueur est entré : Google Research a publié TabFM, quatre cents millions de réglages internes, entraîné lui aussi sur des tableaux fabriqués de toutes pièces. Sur TabArena, l'épreuve commune de cinquante et un jeux de données, ses trois variantes prennent les trois premières places et TabICLv2 arrive neuvième sur douze, en classification comme en régression²³. Ces chiffres sont ceux du tableau des auteurs de TabFM et non d'une mesure indépendante, mais ils sont trop nets pour être passés sous silence.

Ils ne changent pourtant rien au choix fait ici, et la raison tient en une ligne de licence. Les poids de TabFM sont publics, mais réservés à un usage non commercial : le texte exclut nommément les livrables client, les produits ou services payants et toute activité génératrice de revenu, sauf licence commerciale accordée par Google²⁴. Le modèle en tête du classement est donc celui qu'une entreprise n'a pas le droit d'employer pour répondre à son client. TabICL est sous licence BSD, la même que scikit-learn. Deux points complètent l'image : la variante la mieux classée de TabFM confie à Gemini la préparation des colonnes, donc les données sortent, ce que toute cette chaîne cherche justement à éviter ; et le regroupement de colonnes dont elle tire sa force est repris de TabICLv2 et de TabPFN-3. Le travail des deux écoles européennes est dedans.

Il vaut la peine de regarder ce qui se joue là, parce que c'est le logiciel libre à son meilleur. Chaque équipe lit les autres et l'écrit. Le dossier de prévision de TabICL est dérivé de TabPFN-TS, le code de l'équipe allemande, et reste sous la licence Apache de Prior Labs : c'est le fichier de licence de l'équipe française qui le dit²⁵. Le regroupement de colonnes de TabFM vient de TabICLv2 et de TabPFN-3, et Google le signale dans son propre article. Le classement qui les départage est public, donc un nouvel entrant doit poser ses chiffres à côté de ceux des autres plutôt qu'à côté des siens. Une équipe publie, les deux autres lisent, améliorent et republient. Entre l'article de Nature en janvier 2025 et celui de Google en septembre 2026, vingt mois ont suffi pour que ces modèles passent d'une curiosité de laboratoire à un outil qui devance des chaînes automatiques réglées pendant quatre heures sur les données elles-mêmes. Ce n'est pas de la courtoisie académique, c'est de la rivalité : personne ne veut être neuvième sur douze.

Une nuance, pour ne pas confondre deux libertés. Ce qui circule librement, c'est le savoir, pas toujours le droit de s'en servir. TabFM publie son article et ses poids tout en interdisant l'usage commercial, et le cercle tourne quand même, puisque l'idée est lisible par tout le monde. Mais la part que l'on peut installer chez un client, elle, ne dépend que de la licence. C'est pourquoi les deux critères se suivent sans se confondre : on lit tout le monde, on déploie ce que le droit permet.

Avant d'aller plus loin, il faut dire ce que signifie ce 69 %, car le chiffre se lit de travers presque toujours. Il ne dit pas que ce client partira et qu'on en est sûr à 69 %. Il dit que parmi les clients qui ressemblent à celui-là sur les colonnes observées, environ soixante-neuf sur cent sont partis. C'est une fréquence constatée, pas une prophétie sur une personne.

Deux choses bien distinctes rendent un tel chiffre incertain et les confondre coûte cher. La première est notre ignorance : peu de clients comparables dans l'historique, donc une estimation qui bougerait si l'on ajoutait des données. La seconde est le hasard du monde lui-même : à supposer même un historique parfait, deux clients identiques sur le papier ne prennent pas la même décision. La première se réduit en collectant davantage. La seconde ne se réduit jamais ; c'est pour cela qu'une prédiction honnête reste prudente.

De là vient une règle qui vaut pour les trois étages de cette chaîne : un chiffre sans son incertitude est une opinion déguisée en fait. Sur ces données-ci, aucune prédiction ne dépasse 69 % et c'est bon signe. Un outil qui aurait annoncé 97 % aurait simplement menti.

Reste que savoir qui va partir sans savoir pourquoi ne sert à rien. On ne retient pas un client avec une probabilité, on le retient avec une raison. Cette raison doit être assez précise pour qu'on puisse agir dessus.

Le problème porte un nom dans le commerce bien avant d'en porter un en statistique et sa formulation la plus célèbre tient en une phrase : « La moitié de l'argent que je dépense en publicité est gaspillée ; l'ennui, c'est que je ne sais pas laquelle. » On la prête au patron de grand magasin américain John Wanamaker, parfois à l'industriel britannique Lord Leverhulme, quelquefois à Henry Ford. La plus ancienne trace connue est un discours de 1919 qui l'attribue déjà à Wanamaker et ni les archives Wanamaker ni celles d'Unilever n'en gardent la moindre mention¹⁵. La phrase qui pose le problème de l'attribution n'est donc elle-même attribuable à personne.

Le problème, lui, est bien réel et il est mal posé au sens strict. La vente a eu lieu une fois. On ne saura jamais ce qui serait arrivé sans l'affiche dans le métro, parce que ce monde-là n'a pas été observé. Toute attribution est donc une convention : on se donne une règle de partage, puis on accepte de vivre avec.

Une petite expérience montre à quel point le choix de la règle compte. Deux canaux publicitaires, l'affichage et la publicité en ligne, achetés ensemble et donc très corrélés : 0,84 sur deux cents semaines simulées. Par construction, seul l'affichage agit sur les ventes ; l'en ligne est un passager. On demande ensuite à chaque canal ce qu'il explique.

Les deux premières barres disent tout. Interrogé seul, le canal en ligne explique 55,3 % de la variation des ventes, ce qui ferait un beau tableau de bord. Ajouté à l'affichage, il n'explique plus rien du tout : 0,0 %. C'est l'ennui de Wanamaker sous forme chiffrée.

Le partage de Shapley moyenne sur les deux ordres et tranche : 52,5 % à l'affichage, 27,7 % à l'en ligne. Leur somme fait 80,1 %, c'est-à-dire exactement ce que les deux canaux expliquent ensemble. Cette additivité n'est pas un heureux hasard : c'est l'une des propriétés que Shapley a exigées de son partage et elle est ce qui rend le résultat défendable en réunion. Le protocole est publié, à refaire plutôt qu'à croire : deux cents semaines simulées, graine 20260925, régression linéaire, valeur d'un groupe de canaux mesurée par la part de variance des ventes qu'il explique.

Reste une limite qu'il faut énoncer, sous peine de faire dire à la méthode ce qu'elle ne dit pas. Shapley attribue 27,7 % à un canal dont nous savons, par construction, qu'il ne cause rien. Ce n'est pas une faute de la méthode : elle répond fidèlement à la question posée, qui est « qu'est-ce que le modèle a utilisé ». Elle ne répond pas à « qu'est-ce qui a causé la vente ». Pour celle-là, il n'existe pas de raccourci : il faut une expérience, couper le budget d'un canal sur une région et comparer avec les autres. L'attribution explique le modèle ; seule l'expérimentation atteint la cause.

Le modèle a rendu un seul nombre en regardant une dizaine de colonnes à la fois. On voudrait pouvoir dire : tant de ces 69 % viennent de l'ancienneté du contrat, tant du nombre de réclamations, tant du dernier montant facturé. Découper un résultat unique en parts, une par variable qui l'a produit, porte un nom : l'attribution. Rien ne garantit d'avance qu'elle soit possible, car le modèle n'a pas calculé son nombre comme une somme de contributions ; il a tout mélangé. L'attribution reconstruit après coup un partage qui n'existait pas dans le calcul.

La difficulté se voit sur un essai naïf. Pour mesurer ce qu'apporte une variable, on peut la retirer et regarder de combien la prédiction baisse. L'ennui, c'est que la réponse dépend de l'ordre dans lequel on retire les autres. Retirer l'ancienneté du contrat fait beaucoup chuter la prédiction si l'on n'a encore rien retiré et presque rien si l'on a déjà retiré le nombre de réclamations, parce que les deux disent en partie la même chose. Il n'y a donc pas une contribution, mais autant de réponses que d'ordres possibles.

Lloyd Shapley a résolu ce problème en 1953, pour un tout autre usage : partager équitablement le gain d'une équipe entre ses membres, quand chacun n'apporte pas la même chose et que les apports se recouvrent¹⁶. Sa réponse tient en une phrase : puisque l'ordre change le résultat, on considère tous les ordres possibles et l'on prend la moyenne. C'est l'image de l'addition d'un dîner. Selon qui arrive en premier et selon ce qui se partage, la part de chacun change ; en moyennant sur tous les ordres d'arrivée, on obtient un partage que personne ne peut contester. Ces travaux lui ont valu le prix Nobel d'économie en 2012. Appliquée à une prédiction plutôt qu'à un dîner, la même construction dit combien chaque variable a pesé et dans quel sens¹⁷.

La seconde méthode part d'une idée différente et tout aussi simple. Un modèle compliqué le reste, mais si l'on regarde d'assez près, autour d'un seul client, il se comporte presque comme une droite, de la même façon qu'une courbe paraît droite quand on zoome assez. On fabrique donc, dans ce petit voisinage seulement, un modèle simple qui imite le gros, puis on lit ses coefficients¹⁸, qui se lisent directement.

Les deux sont montrées côte à côte. Quand elles s'accordent, la lecture est solide. Quand elles divergent, c'est en soi une information : la prédiction tient alors à un équilibre fragile entre variables et il vaut mieux le savoir avant d'appeler le client.

« 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 ; 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 : l'écart entre les deux mois ne veut rien dire.

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, des sauts sans régularité qu'aucun motif ne relie : 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 ; 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 : ce qui est tenu n'est pas la qualité de la réponse, c'est que son incertitude soit affichée avec elle.

Un détail d'implémentation dit bien dans quel monde on travaille. L'horizon de prévision, le nombre de mois à prédire, 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, puis rendue en direct, sans tableau de bord préconstruit à maintenir (ces pages de graphiques figées que l'on prépare à l'avance). La nuance a son prix pour qui décide : un tableau de bord répond aux questions d'il y a six mois, celles que l'on avait prévues au moment de le construire.

Or 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 elle-même, là où le modèle ne peut pas la manquer.

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 (le bouton qui rend le modèle plus ou moins aventureux) 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 grand nombre n'est pas de la collectionnite : plus le catalogue est large, plus la liste des candidats compatibles avec les colonnes présentes est riche, 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, sens de lecture annoncé sur tout axe où monter vaut mieux que descendre. Rien de cosmétique là-dedans. Un graphique mal contrasté projeté dans une salle, personne ne le lit ; un graphique qui exige de distinguer deux verts exclut un homme sur douze. Les règles héritées de la sémiologie graphique, l'étude de ce que les formes visuelles savent vraiment transmettre¹⁹, 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. Une fois validée, la paire rejoint la bibliothèque d'exemples, l'index où le système pioche. La question semblable suivante retrouve alors ce nouvel exemple.

La règle de sûreté est absolue. 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 : la bibliothèque vit dans la base déjà en place²², pas dans une mémoire perdue au premier redémarrage. L'idempotence : l'identifiant d'une paire est calculé à partir de son contenu, la soumettre deux fois ne crée donc aucun doublon qui encombrerait la récupération. La traçabilité : chaque paire venue du terrain est marquée comme telle, distincte du corpus trié à la main, 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 au lieu de se supposer ; c'est le jeu de contrôle qui tranche.

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, 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, 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. L'architecture garantit la lecture seule, l'arbre syntaxique autorisé et les bornes ; elle ne garantit pas que la requête corresponde à l'intention métier. Sur ce point, elle réduit les modes d'échec et les rend visibles, ce qui n'est pas la même chose que les supprimer. 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 ; 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.

Remerciements

Remerciement chaleureux à Marie Sacksick, Edmond Jacoupeau, Bachir Zerroug et Vincent Sammiez pour nos discussions fructueuses sur ces sujets.

Bibliographie

Aucun de ces titres n'est là pour décorer : chacun porte une décision de conception prise plus haut. Les notices disent laquelle.

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, celle-là même 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 fait 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. « One-Half the Money I Spend for Advertising Is Wasted, But I Have Never Been Able To Decide Which Half », Quote Investigator, 11 avril 2022. quoteinvestigator.com Retrace la formule attribuée à John Wanamaker. La plus ancienne trace connue est un discours de 1919 qui la lui prête déjà ; ni les archives Wanamaker ni celles d'Unilever, pour la variante Leverhulme, n'en gardent trace. C'est la source du paragraphe sur l'attribution et la raison pour laquelle cet article présente la citation comme apocryphe plutôt que comme un fait.
16. Shapley, L. S. (1953). « A Value for n-Person Games », dans H. Kuhn et A. Tucker (dir.), Contributions to the Theory of Games II, Princeton University Press, 307-317. L'article d'origine, écrit pour partager le gain d'une équipe entre ses membres. Il pose l'axiome qui fait tout : puisque l'ordre d'arrivée change la part de chacun, on moyenne sur tous les ordres. Shapley a reçu le prix Nobel d'économie en 2012 avec Alvin Roth. Soixante ans séparent ce texte de son usage en apprentissage automatique.
17. 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.
18. 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.
19. 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.
20. 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.
21. 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.
22. 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.
23. Kong, W., Louidor Ilan, E., Nie, S. et al. (2026). « TabFM: A Zero-Shot Foundation Model for Tabular Data », Google Research, 29 septembre 2026. arXiv:2609.37959 Le troisième modèle du genre, quatre cents millions de réglages internes, entraîné sur des tableaux synthétiques tirés de modèles causaux. Ses tableaux de résultats donnent le classement TabArena cité ici, où ses trois variantes devancent TabPFN-3, AutoGluon et TabICLv2. Mesures faites par les auteurs eux-mêmes sur un banc d'essai public, à lire comme telles.
24. Google (2026). TabFM Non-Commercial License v1.0, licence des poids publiés. huggingface.co Le texte qui tranche la question pour un usage professionnel. Il réserve le modèle aux usages non commerciaux et sa définition du terme exclut explicitement les livrables client, les produits ou services payants et toute activité génératrice de revenu, sauf licence commerciale accordée par Google. À comparer avec la licence BSD de TabICL, qui n'impose aucune de ces conditions.
25. Équipe SODA, Inria. tabicl, fichier de licence. github.com/soda-inria/tabicl BSD trois clauses pour l'essentiel, avec une exception déclarée : le dossier de prévision est un travail dérivé de TabPFN-TS et reste sous licence Apache au nom de Prior Labs. La preuve concrète que les deux écoles se lisent, dans un document que personne n'écrit pour la galerie.

Deux lectures pour élargir. Mes livres préférés en IA, pour la vue d'ensemble commentée. 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.