# Interroger son ERP en langage naturel : ce qui marche vraiment > Source: https://netray.co/fr/erp-langage-naturel-ia > Language: fr > Publisher: Netray (netray.co) > English version: https://netray.co/erp-ai/natural-language-query-erp Demander à son ERP en français « quelles commandes sont en retard ? » fonctionne si le modèle s'appuie sur une couche sémantique, une requête affichée, un accès en lecture seule et les droits de l'utilisateur. Sans ces garde-fous, les réponses sont séduisantes mais peu fiables. Dans la plupart des entreprises, obtenir un chiffre précis de l'ERP implique de demander à quelqu'un : le contrôleur de gestion, le consultant, le responsable informatique. La promesse du langage naturel est de rendre ce chiffre accessible au directeur d'usine, à l'acheteur ou au commercial sans passer par un état sur mesure. La promesse est tenable, mais seulement avec de l'ingénierie. Le simple fait de brancher un modèle de langage sur une base de données donne des requêtes plausibles et parfois fausses. Voici comment on fiabilise ce type d'assistant en contexte industriel. ## Pourquoi le text-to-SQL naïf échoue Une base ERP compte souvent des centaines ou des milliers de tables aux noms cryptiques, des champs codés (statuts numériques, indicateurs O/N), des jointures non évidentes et des règles de gestion qui n'apparaissent dans aucun schéma. Un modèle qui devine peut compter deux fois une ligne, ignorer un statut « annulé » ou mélanger des devises. Le risque principal n'est pas l'erreur visible, mais la réponse fausse qui a l'air juste. D'où l'importance de rendre chaque réponse vérifiable. ## La couche sémantique : traduire votre métier On décrit une fois, avec les key users, les objets métier (commande client, ordre de fabrication, article, fournisseur) et les définitions (« en retard » signifie date de besoin dépassée et statut non terminé). Cette couche sémantique, sous forme de vues, de descriptions de champs et d'exemples de requêtes validées, guide le modèle bien mieux que le schéma brut. C'est le travail le plus rentable du projet. Il est aussi réutilisable : le même glossaire sert au tableau de bord, à l'assistant et à la formation des nouveaux arrivants. - Vues métier nommées en français et décrites champ par champ - Définitions partagées des indicateurs (retard, taux de service, stock disponible) - Exemples de questions avec la requête correcte associée - Liste des tables et champs exclus (paie, données sensibles) ## Garde-fous : lecture seule, requête visible, droits respectés L'accès à l'ERP se fait avec un compte en lecture seule, limité aux vues validées. Chaque réponse affiche la requête ou l'appel d'API exécuté, afin qu'un utilisateur averti puisse la contrôler et que les erreurs soient détectées rapidement. Les droits de l'utilisateur sont reproduits : un commercial ne voit pas les prix d'achat si l'ERP les lui masque. Les limites de volume (nombre de lignes, durée d'exécution) protègent la base de production, et une réplique en lecture est préférable pour les analyses lourdes. ## Hébergement souverain et RGPD Envoyer à une API publique des extraits de votre carnet de commandes, de vos prix et de vos données clients pose des questions de confidentialité et, dès qu'il y a des données personnelles, de conformité RGPD. Un modèle open-weight (Llama, Qwen, Mistral, Gemma) servi avec vLLM ou Ollama sur vos GPU, ou dans un cloud qualifié de votre choix, évite ce transfert. Pour les secteurs exigeants, on peut viser un fonctionnement isolé du réseau public. Netray décrit l'architecture ; c'est à vous, selon vos obligations, de qualifier l'hébergement retenu, par exemple au regard de SecNumCloud si vous l'exigez. ## Évaluer la fiabilité avant de généraliser Avant la mise en service, on construit un jeu de quelques dizaines de questions réelles avec leurs réponses de référence, validées par les utilisateurs métier. On mesure le taux de réponses correctes, les cas d'échec et les questions ambiguës, puis on améliore la couche sémantique. Ce jeu sert ensuite de test de non-régression à chaque évolution de l'ERP. Annoncez clairement aux utilisateurs ce que l'assistant sait faire. Un périmètre étroit et fiable vaut mieux qu'un périmètre large et approximatif. ## Quand une autre solution est préférable Si les questions sont toujours les mêmes, un tableau de bord classique est plus simple et moins coûteux. Si votre éditeur propose déjà un assistant intégré qui répond à vos besoins et dont l'hébergement vous convient, commencez par là. Le langage naturel prend tout son sens quand les questions changent, quand elles croisent plusieurs sources (ERP, MES, documents) ou quand la confidentialité interdit les services publics. ## FAQ ### Peut-on faire confiance aux réponses ? Si la requête est affichée, si une couche sémantique cadre le modèle et si un jeu de tests valide le taux de réussite avant la mise en service, oui, avec la vérification que tout outil d'aide à la décision demande. ### L'assistant peut-il écrire dans l'ERP ? Par défaut non. Le mode lecture seule est la base. Les écritures éventuelles se limitent à des brouillons validés par une personne dans l'ERP. ### Quels ERP sont compatibles ? Les connecteurs sont indépendants de l'ERP : NetSuite, Infor SyteLine, M3, LN et d'autres systèmes disposant d'une base ou d'une API exploitable. L'effort dépend de la documentation et des droits d'accès. ### Faut-il un gros serveur GPU ? Cela dépend du modèle et du nombre d'utilisateurs. Un modèle de taille moyenne suffit souvent pour des questions d'ERP. Le dimensionnement est précisé lors du diagnostic. ### Que se passe-t-il si l'assistant ne sait pas répondre ? Il doit le dire, plutôt que d'inventer. Les cas non résolus sont consignés et servent à enrichir la couche sémantique.