RETOUR AU BLOG

ANALYTICAL METHODS · TABULAR AI

IA tabulaire : une prédiction n'est pas un paragraphe

Décrire un tableau et estimer un résultat inconnu sont deux tâches analytiques différentes.

Duke Analytics 30 septembre 2026 6 min
IA tabulairePrédictionMéthodes analytiques
IA tabulaire : une prédiction n'est pas un paragraphe

Une question peut être conversationnelle. Son exécution peut mobiliser plusieurs méthodes.

Vous avez une table de clients : dates de contrat, usage produit, historique support, renouvellements passés. Vous posez à une IA une question raisonnable : quels clients risquent de ne pas renouveler le mois prochain ? Elle répond par trois paragraphes soignés sur l'engagement, la satisfaction et la relance proactive.

La prose peut être utile. Mais elle n'a pas nécessairement répondu à la question posée. Cette distinction compte davantage que le fait que la réponse arrive dans une fenêtre de chat.

La colonne manquante

Prenons un exemple volontairement simplifié et fictif. Exemple historique A : 18 sessions, 1 ticket, renouvelé. Exemple historique B : 4 sessions, 3 tickets, non renouvelé. Nouveau cas : 9 sessions, 2 tickets, renouvellement inconnu.

Les résultats historiques sont connus une fois leur fenêtre d'observation close. Pour le nouveau cas, le résultat est encore dans le futur. Un système prédictif tente d'estimer ce résultat inconnu avec une méthode définie, souvent sous forme de probabilité, qui doit être testée sur des résultats indisponibles au moment de la prédiction. Trois lignes ne prouvent rien ; elles rendent seulement visible la frontière entre l'observé et l'estimé.

Les modèles de fondation ne se limitent pas au langage

TabPFN est une famille de modèles pré-entraînés pour la prédiction sur données structurées. Prior Labs référence un rapport technique TabPFN-3.5 daté du 15 septembre 2026, qui décrit notamment classification et régression [1][2]. C'est un signal de recherche pertinent pour les équipes analytiques, pas la preuve automatique qu'il s'agit du meilleur modèle pour une entreprise donnée.

Un modèle de langage garde un rôle précieux : clarifier une demande, expliquer un terme, orchestrer un outil analytique approuvé. L'erreur serait de croire que, parce que l'utilisateur parle en langage naturel, chaque partie de la réponse doit être produite par génération de texte.

Quatre tâches cachées dans une conversation

UNE QUESTION, QUATRE TÂCHES
  1. 01CLARIFIER« Renouvellement » : contrat signé, facture émise ou paiement reçu ? Mois civil ou 30 jours ?
  2. 02CALCULERUn résultat observé, sous une définition convenue. Preuve : une requête reproductible.
  3. 03ESTIMERUn résultat inconnu : horizon défini et performance mesurée sur des données tenues à l'écart.
  4. 04DÉCIDERQui doit recevoir une offre ? Effet de l'offre, coût, objectif. Un score de risque ne suffit pas.

Une même interface peut porter les quatre tâches. Elle ne doit pas les faire paraître équivalentes : un événement compté, une prévision et une action proposée ne sont pas le même type d'affirmation.

Une réponse utile porte son statut analytique

  • Statut : prédiction, pas un résultat observé
  • Cible : non-renouvellement sous 30 jours
  • Moment de prédiction : avant tout envoi d'offre
  • Entrées : l'information disponible à ce moment
  • Évaluation : une période ultérieure, tenue à l'écart
  • Limite : le risque n'établit pas la réaction à une offre

C'est un format de résultat proposé, pas la capture d'une fonctionnalité livrée. Son but : rendre les hypothèses cachées inspectables. Pour un manager, ces champs répondent à des questions pratiques : décrit-on ce qui s'est passé, estime-t-on ce qui ne s'est pas encore passé, et que faudrait-il pour justifier une décision ?

Le test doit ressembler à l'usage prévu

Si une équipe veut scorer ses clients chaque lundi matin, l'évaluation doit respecter ce qui était connu chaque lundi, pas ce que contient la base aujourd'hui. Une date de résiliation saisie plus tard peut devenir un corrigé accidentel, tout comme un prétraitement qui a déjà appris des exemples tenus à l'écart [3]. Comparez les méthodes sur la même période ultérieure, avec la même cible, la même frontière d'information, et une baseline simple.

Quand la sortie est une probabilité, vérifiez aussi qu'elle est calibrée : parmi les cas notés autour de 70 %, l'événement devrait survenir environ 70 % du temps sur un échantillon suffisant. C'est une autre question que l'utilité du classement [4].

La prédiction n'est toujours pas la décision

Un client peut avoir un risque élevé de départ et peu de chances de changer d'avis après une remise. Un autre peut être moins à risque mais bien plus sensible à une intervention. Choisir une action exige un raisonnement supplémentaire et, si l'on revendique un effet, des preuves supplémentaires.

Périmètre : cet article traite de méthodes analytiques et d'une architecture proposée. Il n'annonce pas d'intégration TabPFN et ne présente pas de benchmark prédictif DUKE.

Sources

  • [1] Prior Labs, rapports techniques : TabPFN-3.5, publié le 15 septembre 2026 (priorlabs.ai/technical-reports), vérifié le 30 septembre 2026.
  • [2] Prior Labs, capabilities (priorlabs.ai/capabilities).
  • [3] Scikit-learn, common pitfalls : data leakage.
  • [4] Scikit-learn, probability calibration.

Prêt à passer à l'action sur vos données ?

30 minutes avec le studio. On vous montre Duke à l'œuvre sur vos données.

RÉSERVER UNE SESSION
INTERLUDEElectrophazz, les vibes du studio