Le modèle n'écrit pas le chiffre

Vous posez une question sur vos données à un modèle de langage. C'est le programme qui sait lire et écrire du texte, celui qui fait marcher 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. On l'écrit dans un langage fait pour cela, le Structured Query Language, abrégé en SQL. C'est 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.

La réponse au chiffre faux n'est pas de mieux poser la question. C'est d'enlever au modèle la possibilité de se tromper sur le chiffre. Il n'écrit pas la réponse : il écrit la requête. C'est la base qui répond, avec ce qu'elle contient. La différence a l'air de rien, mais elle change la nature de l'erreur. Une requête fausse se voit, se garde, se rejoue, se corrige. Un chiffre inventé 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. Elles arrivent dans l'ordre où on les pose 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. Elle compte les lignes de la table des factures, invoices. Elle ne garde que celles dont le statut vaut « en retard », overdue. Compter, en SQL, s'écrit COUNT. Elle n'en ramène jamais plus de cinq cents (LIMIT 500).

Afficher la requête n'est pas une coquetterie. C'est la preuve : quelqu'un qui connaît la base peut la lire, la contester, la relancer. 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 : écrire la requête juste pour cette base-là. Il faut les bons noms de tables. Il faut les bonnes jointures, c'est-à-dire les bons rapprochements entre deux tables par une colonne commune, les factures avec leurs clients par exemple. Il faut surtout les bonnes valeurs de filtre. Le statut d'une facture impayée s'écrit-il overdue, unpaid ou 3 ? Tout cela est écrit dans le schéma, le plan de la base : la liste de ses tables et de leurs colonnes. Un modèle sans ce plan invente des noms. Ils ont l'air justes. Ils sont faux. Un outil qui traduit une question en requête se juge donc là-dessus. Il doit coller à la base qu'on a devant soi.

Il y a deux façons de s'y prendre. La première renvoie le modèle à l'école. On appelle cela le réglage fin, ou fine-tuning. On reprend son entraînement sur les données du client, jusqu'à ce qu'il les connaisse par cœur. C'est cher, c'est lent. Et il faut tout recommencer dès que la base change. La seconde laisse le modèle tel quel. À chaque question, on lui glisse une fiche de révision : les quelques informations utiles pour cette question-là². Elle s'appelle la génération augmentée par récupération (Retrieval-Augmented Generation, RAG). Vanna, l'outil libre de référence sur ce terrain, fait partie de cette seconde famille¹.

Un point déroute. C'est le plus important de tous. Chez Vanna, « entraîner » ne veut pas dire ce qu'on croit. Cela veut dire remplir une base de connaissances, que le système ira consulter au moment de répondre. Le modèle, lui, ne change pas : aucun de ses réglages internes n'est touché. On range des textes dans une sorte de bibliothèque. Une question arrive. On y cherche les textes qui parlent de la même chose, même avec d'autres mots. On les ajoute à la question qu'on pose au modèle³.

Les trois contenus, 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. C'est le CREATE TABLE de chaque table, sa carte d'identité. Son nom, ses colonnes, et le type de chacune. Nombre, texte ou date. S'y ajoutent ses clés, les colonnes qui la relient aux autres tables. Elle apprend au modèle ce qui existe et l'empêche d'inventer. On range une table par fiche, pour que chacune ressorte séparément quand une question la concerne.

La documentation métier dit ce que la structure ne dit pas. Comment se calcule une mesure. Ce que veut dire le vocabulaire maison. À quoi correspondent les valeurs codées. Une phrase par fiche, écrite comme un utilisateur la dirait. « Le chiffre d'affaires hors taxes des commandes s'obtient en additionnant orders.total_ht_eur. » C'est là qu'on gagne le plus, parce que c'est exactement là qu'un modèle sans contexte se trompe.

Les paires question-requête arrivent en dernier dans le travail et en premier dans les résultats. Une question en français, la requête juste qui va avec. La documentation de Vanna le dit sans détour : c'est leur qualité qui décide du résultat¹. On comprend pourquoi en regardant le mécanisme. À 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 bon exemple, proche de la question posée, vaut donc mille exemples lointains. On range pour couvrir des cas, pas pour faire du volume. Vingt à cent paires vérifiées suffisent à démarrer. Encore faut-il couvrir les familles de questions que les gens vont poser⁹. Compter. Croiser deux tables. Filtrer sur une valeur codée. Classer les plus gros. Cet ordre de grandeur vaut pour une base de cette taille, ce n'est pas une règle générale. Il dépend du nombre de tables, du vocabulaire plus ou moins ambigu, du nombre de métiers couverts, et surtout des questions que les gens posent vraiment.

Deux règles comptent plus que tout pour choisir ce qui entre dans la bibliothèque. D'abord, toujours du SQL vérifié, c'est-à-dire exécuté pour de vrai et confirmé juste : une paire fausse apprend au système à produire du SQL faux. Ensuite, jamais de SELECT *. Cette requête ramène toutes les colonnes sans en nommer aucune. Elle n'apprend donc 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 passe ailleurs, sous un compte à part. Ce compte peut lire la base. Il ne peut pas la modifier. Avant de lancer la requête, des garde-fous l'analysent. L'analyser veut dire la découper comme on fait l'analyse grammaticale d'une phrase, sujet, verbe, compléments. Ce découpage 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. Cette séparation est une mesure de sécurité : la partie 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, le 4 septembre 2026. Jusque-là, le modèle recevait les noms et les types des colonnes, mais jamais la liste des valeurs qu'elles contiennent vraiment. Il a donc écrit WHERE status = 'confirmed' sur la table des factures. La requête était correcte, les garde-fous l'ont acceptée, elle s'est exécutée sans erreur. Et elle a rendu zéro ligne. Les vraies valeurs étaient paid, overdue et sent ; confirmed existait dans la table des commandes, pas dans celle des factures. L'utilisateur voyait un résultat vide, sans la moindre explication.

Ce défaut se répare des deux côtés. Pour l'éviter, on s'occupe des colonnes à peu de valeurs différentes. Un statut, une catégorie. Jamais un montant. On lit dans la base la liste réelle de leurs valeurs. On la donne au modèle avec le reste. On commence par les colonnes dont la base connaît d'avance la liste exacte. On continue par les colonnes de texte que les statistiques de la base signalent comme peu variées, en relisant leurs valeurs par une lecture limitée. Une colonne sans statistiques n'est jamais sondée : mieux vaut aucune liste qu'une fausse.

Vient ensuite la réparation. Une requête peut s'exécuter sans erreur et ne ramener aucune ligne, parce qu'elle filtre sur une valeur qui n'existe pas dans la colonne. Elle ne rend plus un vide muet. Le système réessaie une fois, en donnant les vraies valeurs au modèle. Si cela échoue encore, la réponse nomme la colonne, la valeur inventée et les valeurs qui existent vraiment.

Prouver que tout ce travail sert à quelque chose

C'est l'étape qu'on saute trop souvent. C'est pourtant la seule qui prouve que tout ce tri a servi. On met de côté quelques paires question-requête, qu'on ne range pas dans la bibliothèque : elles serviront d'examen. Le principe est celui de n'importe quel contrôle : on ne note pas un élève sur des exercices dont il a le corrigé sous les yeux. Si on mesure sur des questions déjà rangées, on mesure seulement la capacité du système à ressortir un exemple appris.

On peut compter les points de trois façons, de la moins fiable à la plus fiable. La première est le taux de SQL valide : c'est un simple garde-fou, puisqu'une requête peut être valide et fausse. La deuxième compare les deux requêtes caractère par caractère. Elle sous-estime beaucoup la justesse, parce que deux requêtes justes s'écrivent presque toujours différemment⁵. La bonne mesure est la troisième, la plus simple aussi. On exécute les deux requêtes, la produite et la référence, puis on compare les résultats. C'est la mesure des bancs d'essai du domaine, Spider⁶ et BIRD⁷. Ces jeux publics de questions servent à comparer toutes les équipes. Elle l'emporte parce qu'elle juge la réponse rendue, la seule chose qui compte.

Une note globale cache la famille de questions qui échoue⁸. On détaille donc la note par famille : comptages, croisements de tables, filtres, classements. Cette lecture dit quoi faire ensuite. Si les croisements sont faibles, il faut des exemples de croisements, 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 sur le passé. Combien avons-nous facturé le mois dernier, quels clients ont dépassé leur budget. Il ne répond pas à la question que le dirigeant pose juste après, celle qui porte sur l'avenir. Jusqu'ici, cette seconde question demandait un projet de plusieurs mois, confié à des spécialistes des données, à refaire pour chaque client et chaque question.

L'idée qui change tout est simple. La requête ne ramène plus un chiffre. Elle ramène un tableau dont la dernière colonne est la question. Cette colonne est remplie pour certaines lignes, vide pour celles qu'on veut 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 les exemples et la question. C'est exactement ce que sait lire un modèle tabulaire fondationnel. Un modèle de ce genre a été entraîné une fois pour toutes, dans son laboratoire, sur des millions de tableaux fabriqués pour l'exercice. Il ne connaît pas vos données : il connaît la façon dont un tableau se comporte. C'est un correcteur. Il a lu des milliers de copies. Il repère donc une erreur du premier coup d'œil, sur une copie qu'il n'a jamais vue. On lui montre le tableau, il remplit les trous en une seule fois. Rien n'est entraîné sur vos données, aucun réglage interne n'est modifié, aucun modèle n'est à stocker.

Cela s'appelle l'apprentissage en contexte, et tout le monde l'a déjà vécu. On donne un exemple à un assistant conversationnel, dans la conversation elle-même. Il comprend sans qu'on le réentraîne¹⁰. La comparaison a une limite et elle est intéressante. Un texte se lit de gauche à droite. Un tableau n'a pas d'ordre, ni entre ses lignes ni entre ses colonnes. C'est justement le problème que ces modèles ont dû résoudre.

La conséquence est directe : aucun projet d'entraînement, rien à 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 quatre usages. Prédire une catégorie, par exemple partira ou ne partira pas. Prédire un nombre, par exemple le montant du mois prochain. Remplir des trous. Et classer les 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. Elle est systématiquement plus rapide, jusqu'à dix fois. Sur les tableaux de plus de dix mille lignes, elle le dépasse¹³. 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.

J'ai choisi TabICL, et pas par patriotisme. Les deux modèles tournent chez le client, sans que rien ne sorte. Les deux publient leurs poids, c'est-à-dire les milliards de réglages appris pendant l'entraînement. TabICL publie en plus le code qui a servi à l'entraîner¹⁴, y compris le générateur de données. La différence se voit dès qu'on veut vérifier quelque chose. Avec les poids seuls, on peut refaire tourner les prédictions. Avec le code d'entraînement, on peut refaire le modèle depuis zéro. Quand on dit à un dirigeant « ce client va partir », pouvoir montrer d'où vient la réponse compte vraiment.

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. 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.

Ces chiffres ne changent pourtant rien au choix fait ici. Tout se joue sur 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é qui rapporte de l'argent ; il faut pour cela une 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'utiliser pour répondre à son client. TabICL est sous licence BSD, la même que scikit-learn. Deux détails complètent le tableau. La variante la mieux classée de TabFM confie la préparation des colonnes à Gemini, donc les données sortent, ce que toute cette chaîne cherche justement à éviter. Et la technique qui fait sa force est reprise de TabICLv2 et de TabPFN-3. Il s'agit du regroupement de colonnes. Le travail des deux écoles européennes est donc dedans.

Ce qui se passe là vaut d'être regardé, parce que c'est le logiciel libre à son meilleur. Chaque équipe lit les autres. Et chacune le dit. Le code de prévision de TabICL vient de TabPFN-TS, écrit par l'équipe allemande ; il reste donc sous la licence 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 arrivant doit poser ses chiffres à côté de ceux des autres, pas à 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 passé. Ils ont suffi pour que ces modèles sortent du laboratoire. Ils battent maintenant des chaînes automatiques réglées pendant quatre heures sur les données elles-mêmes. Ce n'est pas de la courtoisie entre chercheurs, c'est de la rivalité. Personne ne veut être neuvième sur douze.

Attention à 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 : l'idée est lisible par tout le monde, donc tout le monde en profite. Mais ce qu'on a le droit d'installer chez un client ne dépend que de la licence. D'où deux critères, qui se suivent sans se mélanger. On lit tout le monde. On installe ce que le droit permet.

Disons maintenant ce que veut dire ce 69 %. On le lit presque toujours de travers. Il ne veut pas dire qu'on est sûr à 69 % que ce client va partir. Il veut dire ceci. Prenez 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 prédiction sur une personne.

Deux choses très différentes rendent ce chiffre incertain. Les confondre coûte cher. La première est notre ignorance : il y a peu de clients comparables dans l'historique, donc l'estimation bougerait si on ajoutait des données. La seconde est le hasard du monde : même avec un historique parfait, deux clients identiques sur le papier ne prennent pas la même décision. La première diminue si on collecte davantage. La seconde ne diminue jamais. C'est pour cela qu'une prédiction honnête reste prudente.

D'où une règle, qui vaut pour les trois étages. Un chiffre sans son incertitude est une opinion déguisée en fait. Sur ces données, aucune prédiction ne dépasse 69 %. C'est bon signe. Un outil qui aurait annoncé 97 % aurait menti.

Savoir qui va partir ne sert à rien. Il faut savoir pourquoi. On ne retient pas un client avec une probabilité. On le retient avec une raison, assez précise pour qu'on puisse agir.

Le problème porte un nom dans le commerce bien avant d'en porter un en statistique. La formule la plus célèbre du métier dit ceci : « 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. 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. Il est aussi 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 existé. Partager le mérite entre les canaux est donc forcément une convention : on choisit une règle de partage, puis on l'assume.

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 fait la moyenne des deux ordres et tranche : 52,5 % à l'affichage, 27,7 % à l'en ligne. Les deux parts font 80,1 %, c'est-à-dire exactement ce que les deux canaux expliquent ensemble. Ce n'est pas un hasard heureux : Shapley a justement exigé que les parts s'additionnent. C'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. La valeur d'un groupe de canaux se mesure par la part des variations de ventes qu'il explique.

Reste une limite à dire clairement, sinon on fait dire à la méthode ce qu'elle ne dit pas. Shapley attribue 27,7 % à un canal dont nous savons, puisque nous avons fabriqué l'exemple, qu'il ne cause rien. Ce n'est pas une faute de la méthode. Elle répond fidèlement à la question posée. Cette question est : qu'est-ce que le modèle a utilisé ? Ce n'est pas la même que celle-ci : qu'est-ce qui a causé la vente ? Pour celle-là, il n'y a pas de raccourci. Il faut une expérience : couper le budget d'un canal sur une région, et comparer avec les autres. Le partage explique le modèle ; seule l'expérience atteint la cause.

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

On voit la difficulté 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 baisser la prédiction si on n'a encore rien retiré. Le même retrait ne change presque rien si 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. Il cherchait à 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 est simple : puisque l'ordre change le résultat, on regarde tous les ordres possibles et on prend la moyenne. Pensez à une addition au restaurant. Selon qui arrive en premier et selon ce qu'on partage, la part de chacun change. En faisant la moyenne 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é à une prédiction plutôt qu'à un dîner, le même calcul dit combien chaque variable a pesé, et dans quel sens¹⁷.

La seconde méthode part d'une idée différente, tout aussi simple. Un modèle compliqué reste compliqué. Mais si 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. Ses coefficients se lisent directement¹⁸.

Les deux méthodes sont montrées côte à côte. Quand elles s'accordent, la lecture est solide. Quand elles divergent, c'est déjà une information : la prédiction tient à un équilibre fragile entre variables, et mieux vaut 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 seul chiffre sur l'avenir, c'est de la voyance. Un chiffre avec sa fourchette, c'est une décision. Et cette figure dit quelque chose de désagréable qu'il faut savoir lire : la fourchette est plus large que l'écart entre les trois mois. Août paraît meilleur que juillet, mais les barres se recouvrent presque entièrement. L'écart entre les deux mois ne veut donc rien dire.

L'outil n'est pas en cause : c'est la donnée qui est mauvaise. La série mensuelle de cette base de démonstration n'est que du bruit, des sauts sans aucune régularité. Sur vingt et un mois : 293 euros un mois, 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. La promesse ne porte pas sur la qualité de la réponse. Elle porte sur l'incertitude affichée à côté.

Un détail d'implémentation dit bien dans quel monde on travaille. 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 par cent mille mois à prévoir. On obtenait des dates absurdes et un calcul qui bloquait la machine, pour un résultat que personne n'avait demandé sérieusement. Ce nombre est maintenant plafonné. Au-delà, une prévision n'a de toute façon aucune valeur, donc on ne perd rien.

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

Dernière question, et 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 des données et ce que demande la question, puis dessinée sur le moment. Il n'y a donc pas de tableau de bord à entretenir. Un tableau de bord est une page de graphiques figés, préparée à l'avance. Il répond aux questions qu'on se posait il y a six mois. Celles qu'on avait prévues en le construisant.

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. Il peut en mal orthographier un. Il peut aussi en choisir un qui ne va pas avec les colonnes présentes. Une carte, par exemple, quand aucune colonne ne contient de lieu. La sécurité ne peut donc pas reposer sur sa bonne volonté. Elle doit être dans la forme du programme, là où le modèle ne peut pas passer à côté.

Le modèle choisit un plat dans un menu qu'il n'a pas écrit. Cette garantie n'est pas de la même nature qu'un réglage de température. Ce bouton rend le modèle plus ou moins aventureux. Elle n'est pas non plus de la nature d'une consigne ajoutée au début de la conversation. Elle ne dépend pas de la docilité du modèle, mais de la forme du programme. Et comme au premier étage, elle rend l'erreur qui reste visible et réparable : une figure mal choisie se corrige d'un clic, sans jamais se confondre avec une figure juste.

Le dessin est fait par sprezzature.ai, un moteur de figures libre²¹. Son catalogue compte cent vingt-sept types de graphiques, des courbes aux diagrammes de flux, en passant par les treemaps, les cascades et les cartes. Ce grand nombre n'est pas de la collection pour la collection : plus le catalogue est large, plus il y a de graphiques compatibles avec les colonnes qu'on a, et plus le choix automatique tombe juste.

Chaque figure respecte en plus des règles d'accessibilité et de couleur. Le contraste est vérifié. La figure reste lisible pour une personne daltonienne. Jamais une couleur seule ne porte une information. Le sens de lecture est indiqué 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, et un graphique qui demande de distinguer deux verts exclut un homme sur douze. Ces règles viennent de la sémiologie graphique, l'étude de ce que les formes visuelles savent vraiment transmettre¹⁹, et de mesures sur la perception²⁰. Ici, ce sont des lignes de code, pas des recommandations.

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

Aucun tri préparé à l'avance ne devine comment les gens vont formuler leurs demandes. Il ignore leurs tournures, leurs raccourcis, les cas particuliers de chaque entreprise. Seule la production montre les questions qu'on pose vraiment. Chaque question bien traitée, et surtout chaque correction, apprend quelque chose que le tri initial ne savait pas.

La boucle est simple. Une personne pose une question. Le système écrit 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. La question suivante qui lui ressemble retrouvera ce nouvel exemple.

Une règle de sûreté ne souffre aucune exception. C'est la plus facile à rater : jamais d'apprentissage aveugle. Capturer automatiquement toutes les requêtes produites pour les réinjecter comme exemples empoisonne la bibliothèque 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 un chemin dédié, qui rejoue les garde-fous et réexécute la requête avant de l'accepter. Aucune confiance aveugle, même envers ce qu'on nous présente comme déjà vérifié.

Quatre propriétés séparent un mécanisme qui marche sur un poste d'une boucle qui tient en production. La persistance : la bibliothèque vit dans la base déjà en place²², et non dans une mémoire perdue au premier redémarrage. L'idempotence : l'identifiant d'une paire est calculé à partir de son contenu, donc la soumettre deux fois ne crée pas de doublon. La traçabilité : chaque paire venue du terrain est marquée comme telle, à part du corpus trié à la main. On peut ainsi vérifier ce que la production a appris au système, et retirer un mauvais exemple précis. Et la mesure : après chaque lot d'ajouts, on repasse l'examen. On vérifie le progrès au lieu de le supposer.

Ce que cela change et ce que cela ne change pas

Avant, une question métier partait en ticket vers l'équipe data et revenait trois jours plus tard, souvent après que la décision avait été prise sans elle. Une question sur l'avenir, elle, partait en projet. Maintenant, la question se pose à 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 un chiffre fiable passe de trois jours à trois secondes, parce que 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 qu'on ne fera que lire la base, dans des limites connues. Elle ne garantit pas que la requête corresponde à ce que la personne voulait vraiment demander. Sur ce point, elle réduit les façons de se tromper et les rend visibles. Les supprimer serait autre chose. La vraie limite n'est pas le volume de données, puisque la chaîne interroge la base directement et que c'est le SQL qui filtre. La vraie limite, c'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, et partout la même discipline : le modèle propose la forme, la machine vérifie, la donnée tranche. C'est ce qui sépare un chiffre qu'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 contenus 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.