Les tableaux qui n'existaient pas

Chapitre 2 — Les tableaux qui n'existaient pas

Un technicien d'une entreprise mécanique du Nord-Est nous l'a raconté devant un espresso, avec ce calme vénitien qui annonce une catastrophe : "Notre chatbot savait tout sur le moteur. Sauf les données du moteur." Puis il a expliqué. Leur assistant IA interne savait décrire les gammes de produits, les contextes d'utilisation, l'histoire de la marque, les avantages concurrentiels. Une merveille, sur le plan narratif. Mais lorsqu'un client demandait le couple nominal du modèle CMP50L — c'est-à-dire la donnée technique pour laquelle les gens ouvrent le catalogue, le numéro pour lequel on achète un moteur — le chatbot répondait de manière vague, parfois plausible, parfois non. Cinq mois de développement, le directeur opérationnel de plus en plus perplexe, et personne ne savait dire pourquoi.

Le diagnostic est arrivé par hasard, presque par ennui, en inspectant manuellement la base de données après la énième réunion sans conclusion. Le catalogue PDF contenait 342 tableaux techniques. Dans la base de données, il n'y en avait pas un seul. Pas une poignée : zéro. Aucun. Le code qui extrayait les tableaux des PDF enregistrait les données dans des champs appelés columns et data, tandis que le code qui les indexait ensuite s'attendait à des champs appelés headers et rows. Un "synonyme" non respecté. Une convention interne qui avait sauté lors d'un refactoring oublié. Le résultat, pendant cinq mois silencieux : l'ensemble des données numériques du catalogue — paires, puissances, diamètres, poids, codes de commande, tensions d'alimentation — s'est écoulé du robinet sans jamais être versé dans le verre. Trente-quatre-deux tableaux, perdus un par un dans un silence liturgique.

C'est le type de bug qui ne hurle pas. Il ne lève pas d'exceptions, ne fait pas planter quoi que ce soit, n'apparaît dans aucun journal. Simplement, une partie du monde cesse d'exister pour votre système, et personne ne s'en aperçoit tant qu'un utilisateur — généralement un utilisateur mécontent — ne pose suffisamment de questions persistantes pour révéler l'abîme. Et c'est emblématique d'un problème bien plus vaste que les noms des champs : les frameworks RAG génériques sont optimisés pour le texte courant — articles, pages web, paragraphes de fiction — et traitent les tableaux comme des citoyens de seconde zone, quand ils les traitent. Mais les documents d'entreprise italiens sont souvent des tableaux. Catalogues techniques, listes de prix, spécifications produit, fiches de sécurité, bulletins de commande : la partie précieuse, pour ceux qui consultent ces documents, est celle tabulaire. Celle qui se casse en premier et dont personne ne se rend compte.

La leçon n'est pas "soyez attentif aux noms des champs". Elle est plus contraignante : dans un RAG sérieux, chaque type de contenu — tableaux, images, codes alphanumériques, titres de paragraphes, notes de bas de page — a besoin d'un traitement dédié, conçu, testé. Et le test de fonctionnement n'est pas "le chatbot répond à des questions banales" — même les systèmes défectueux y répondent, car il y a suffisamment de données flottantes pour construire quelque chose de plausible. Le vrai test est "le chatbot répond à des questions qui l'obligent à toucher chaque pièce du pipeline". Des questions spécifiques, numériques, vérifiables. Des questions pour lesquelles il existe une réponse juste et une seule, et si le système se trompe, vous le savez immédiatement.

Si vous ne faites pas ce test, vous ne savez pas si votre RAG fonctionne. Vous savez seulement qu'il ne se plaint pas. Et "ne pas se plaindre" est un critère de qualité très bas pour un système que les gens utiliseront pour prendre des décisions.