Comment les requêtes SQL rigides alimentent vos hallucinations en matière d'IA

Vous intégrez une IA dernier cri à votre ancien ERP, en espérant un miracle. Au lieu de cela, elle vous ment effrontément. Le vrai problème ? Vous interrogez encore les données historiques comme si on était en 2005.

En tant que consultant ERP, je suis constamment confronté à ce genre de scénarios. Les dirigeants se précipitent pour intégrer l'IA générative à leurs systèmes d'entreprise, espérant obtenir instantanément des informations exploitables par le dialogue. Ils soumettent d'immenses modèles de langage à d'anciens entrepôts de données et attendent les résultats.

Mais cette approche échoue généralement dès qu'on met les pieds dans l'atelier de production.

Si vous essayez d'extraire le sens sémantique à l'aide de méthodes rigides et basées sur des mots-clés pour alimenter une IA moderne, vous provoquez pratiquement des hallucinations.

Analysons en profondeur nos méthodes actuelles d'interrogation des données d'entreprise et les orientations réelles des architectures compatibles avec l'IA. Une erreur à ce stade pourrait compromettre toute votre stratégie d'IA.

Les limites des requêtes ERP traditionnelles

Les bases de données dans des systèmes comme Infor LN sont phénoménales dans ce qu'elles font réellement : la précision et l'intégrité transactionnelle.

Elles sont conçues pour exécuter des règles spécifiques rapidement et sans erreur. Si vous savez précisément ce que vous cherchez, le SQL classique est idéal. Lorsque vous avez besoin de connaître l'état exact d'un ordre de production, une simple requête SQL suffit. Vous ciblez la table tisfc001, vous associez les clés primaires et vous récupérez l'enregistrement exact sans ambiguïté.

Mais l'analyse historique est rarement aussi précise.

Lorsqu'un responsable de la chaîne d'approvisionnement demande : « Pourquoi sommes-nous systématiquement en retard sur cette gamme de produits ? », une requête SQL standard ne peut répondre directement à cette question. Il faudrait joindre manuellement cinq modules différents, couvrant les achats, l'entreposage et la production. Plus important encore, il faudrait interpréter des notes non structurées laissées par différentes personnes dans différents services.

Imaginez que vous enquêtiez sur une panne machine récurrente et que vous analysiez les défauts de qualité. Vous rédigez une requête SQL standard cherchant WHERE description LIKE '%overheating%'. Votre base de données existante ne renverra docilement que les correspondances exactes.

Qu'est-ce qu'il ne prend pas en compte ? Tout le reste. Il ignore complètement les enregistrements critiques où un opérateur pressé a saisi des informations comme « température élevée », « surchauffe » ou « composants en feu » à la fin de son quart de travail.

Le SQL traditionnel manque de compréhension sémantique. Il ne perçoit que des caractères rigides. Lorsqu'on fournit ces résultats incomplets, filtrés par mots-clés, à une IA, le modèle tire des conclusions basées sur une réalité fragmentée. C'est précisément là que les informations stratégiques sont compromises.

L'avantage sémantique

Si vous devez analyser des données historiques à la recherche de corrélations floues, une base de données vectorielle offre un avantage structurel indéniable.

La vectorisation des données transforme le texte en coordonnées numériques appelées plongements lexicaux. Elle permet de regrouper les données en fonction de leur contexte et de leur signification mathématique. On peut comparer un plongement lexical à une coordonnée GPS associée à un concept précis.

Au lieu de faire correspondre des lettres, la base de données fait correspondre le sens sous-jacent. Si un planificateur saisit « retard du fournisseur » et qu'un opérateur d'entrepôt enregistre « attente de pièces », une requête SQL classique identifiera deux problèmes distincts. Une base de données vectorisée, quant à elle, reconnaîtra qu'il s'agit du même problème.

Dans une base de données vectorisée, les termes surchauffe et température élevée sont mathématiquement placés l'un à côté de l'autre.

En déchargeant vos données transactionnelles dans une base de données vectorielle comme Google AlloyDB, vous passez d'une simple correspondance de chaînes de caractères à une correspondance sémantique. Cette approche utilise généralement des pipelines de flux pour éloigner les données du cœur de l'ERP en toute sécurité.

Vous pouvez désormais interroger des années de données historiques en utilisant le langage naturel. Le système comprend l'intention. Les utilisateurs n'ont plus besoin de mémoriser des syntaxes SQL complexes, de naviguer dans des tables obscures ni de deviner d'anciennes abréviations.

L'architecture idéale pour commencer : RAG et isolation du cœur

Vous pourriez être tenté d'appliquer directement l'IA générative à votre ERP transactionnel. Ne le faites pas. Cela dégraderait fortement les performances opérationnelles et risquerait de bloquer votre système principal.

Les LLM sont extrêmement gourmands en ressources. Si vous connectez une IA conversationnelle directement à vos tables transactionnelles en temps réel, vous paralyserez vos opérations quotidiennes. Un employé d'entrepôt qui s'apprête à expédier une cargaison de marchandises ne devrait pas avoir à attendre que le système analyse dix ans de données de maintenance parce qu'un cadre demande à l'IA d'analyser ces dix dernières années.

La solution moderne repose sur la génération augmentée par la récupération (RAG) et l'isolation du noyau. La transition d'Infor depuis son ancien système Coleman ML. L'entreprise utilise désormais LangChain pour créer des agents capables d'un raisonnement sémantique approfondi, solidement ancré dans la logique métier.

Le flux de travail RAG suit généralement les étapes opérationnelles suivantes :

• Déchargement : Vous transférez les données ERP hors du système transactionnel central. À l’aide d’outils comme Infor Data Fabric, vous transférez ces données vers votre base de données vectorielle. Votre système principal reste ainsi opérationnel.
• Recherche : Un utilisateur pose une question en langage naturel. La base de données vectorielle AlloyDB effectue une recherche rapide pour trouver des documents historiques conceptuellement pertinents.
• Extraction : Seuls les enregistrements valides sont envoyés comme contexte de référence à un modèle de langage externe de grande taille tel que Vertex AI. Ce modèle traite ces données et génère une réponse précise sans jamais interagir avec le système ERP en production.

Ce processus RAG constitue actuellement la base idéale pour toute initiative d'IA en entreprise. Il faut toutefois le considérer comme un point de départ, et non comme une finalité.

L'industrie évolue déjà vers la recherche agentique : des architectures où l'IA n'effectue pas une simple recherche sémantique statique, mais décide de manière autonome comment et où chercher. Elle utilise successivement plusieurs stratégies de recherche (recherche vectorielle, requêtes structurées, systèmes de fichiers, graphes de connaissances) en fonction de la complexité de la question.

Andrej Karpathy a récemment mis en lumière un modèle similaire : le LLM Wiki. Un agent d’IA précompile des données sources brutes dans une base de connaissances structurée et interconnectée. Au lieu de récupérer des fragments de texte à chaque fois, l’agent interroge un artefact propre et organisé qu’il a déjà constitué, enrichissant ainsi son intelligence au fil du temps.

Dans la plupart des environnements ERP actuels, une architecture RAG bien conçue est la solution idéale. Cependant, les contraintes liées à la fenêtre de contexte, qui rendaient le découpage vectoriel indispensable, diminuent rapidement. Si vous concevez votre architecture sans prévoir de transition vers des modèles de traitement par agents, vous devrez la mettre à jour dans dix-huit mois.

Tuer les hallucinations

Une hallucination de l'IA se produit lorsqu'un modèle linéaire à longue portée (LLM) génère une sortie fluide, persuasive, mais factuellement absurde. Ces modèles ne « connaissent » pas les faits ; ils ne font que prédire des probabilités en fonction de leur architecture sous-jacente.

Dans les environnements industriels complexes, une hallucination constitue une défaillance critique. L'IA pourrait inventer avec assurance un programme de maintenance conforme à une tendance statistique, mais qui n'existe pas dans la réalité. Elle pourrait suggérer de commander des pièces obsolètes depuis dix ans, simplement parce qu'elles apparaissaient fréquemment dans d'anciens journaux d'entretien.

Nous ne pouvons pas éliminer mathématiquement les hallucinations, mais nous devons les réduire jusqu'à ce qu'elles soient statistiquement négligeables. Voici des règles strictes que vous devez appliquer :

• Exiger un ancrage strict : forcer le LLM à se baser exclusivement sur le contexte RAG fourni par votre base de données vectorielles. Bloquer explicitement ses connaissances Internet pré-entraînées afin d’imposer un ancrage strict à l’entreprise.
• Mise en œuvre de la température zéro : paramétrer la température du modèle à zéro. Supprimer la créativité de l’IA pour garantir des résultats déterministes et hautement reproductibles. Nous recherchons une précision chirurgicale, pas une écriture créative.
• Mettre en place une solution de repli obligatoire : grâce à une ingénierie rigoureuse des invites, forcer le LLM à indiquer « Données introuvables » si la réponse dépend de données hors du contexte récupéré.
• Prioriser la qualité des données : toute cette architecture avancée est inutile si vos données sources sont de mauvaise qualité. Les données ERP alimentant la base de données vectorielle doivent être propres et normalisées.

Informations exploitables pour les responsables informatiques

Cessez de vous laisser emporter par l'engouement. L'achat d'une licence d'IA ne résoudra pas les problèmes d'une architecture d'entreprise défaillante. Si votre ERP est aujourd'hui un véritable fouillis de solutions de contournement non structurées, l'intégration à une IA ne fera qu'automatiser davantage la confusion.

Combinez la précision transactionnelle de votre ERP avec la compréhension sémantique d'une base de données vectorielle, et vous empêcherez enfin l'IA de deviner.

Avant d'investir dans des outils d'IA, commencez par évaluer la maturité actuelle de vos données. Analysez comment vos utilisateurs consignent les problèmes et vérifiez si ces descriptions sont suffisamment standardisées pour permettre une vectorisation efficace.

Ensuite, évaluez les bases de données vectorielles pour l'analyse historique. Cartographiez vos intentions de requête et, surtout, protégez votre système principal en concevant une architecture RAG découplée. Enfin, prévoyez une solution de repli. Concevez votre couche de récupération comme un composant modulaire, et non comme un monolithe. Lorsque les modèles d'agents seront suffisamment matures pour une utilisation en entreprise, vous devriez pouvoir modifier ou étendre votre stratégie de récupération sans avoir à tout reconstruire.

Si votre ERP peine encore aujourd'hui à fournir des données de base et propres, y ajouter une IA sémantique ne fera qu'accélérer son échec.

Si votre infrastructure de données est défaillante, l'IA ne fera qu'amplifier la confusion. Corrigez l'architecture avant d'acheter la licence.

Écrit par Andrea Guaccio 

5 mai 2026