Intégration de l'IA en entreprise : connecter un LLM à l'ERP

L'un de vos distributeurs envoie un e-mail à 8 h 40 : « Bonjour, envoyez-nous 40 tubes de 20 comme la dernière fois, plus 5 cartons du jeu de joints avec notre remise spéciale, même adresse. » Pour que cette phrase devienne une ligne de commande dans l'ERP, il faut que quelqu'un lise le message, retrouve la référence, vérifie le stock et saisisse la pièce à la main. À 60 e-mails par jour, ce n'est pas un sujet d'« intelligence artificielle » : c'est une ligne de votre coût opérationnel.

À l'autre bout de la même usine, le responsable d'entrepôt demande un rapport à la DSI pour répondre à la question « combien de livraisons incomplètes avons-nous faites le mois dernier et à quels clients », et prend la file. Quand la réponse arrive trois jours plus tard, la question a perdu toute fraîcheur.

Ces deux scènes montrent où les grands modèles de langage (LLM — des modèles d'IA qui comprennent un texte écrit en langage humain et produisent à leur tour du texte) apportent réellement quelque chose au logiciel d'entreprise. Il ne s'agit pas de faire décider des machines, mais de combler l'écart entre le texte libre que rédigent les humains et les données structurées qu'attendent les systèmes. Dans cet article, nous abordons l'intégration de l'IA en entreprise autour de trois questions : qu'est-ce que cela nous apporte, combien cela coûte, et nos données fuient-elles ?

01. Que fait exactement un LLM dans un logiciel d'entreprise ?

Pourquoi un LLM est-il une couche de traduction et non un décideur ?

Ce que fait un LLM relève, au fond, de la traduction. Il convertit du texte libre en données structurées : la phrase « 40 tubes de 20 » devient l'objet {code_article: BR-020, quantite: 40}. Il fonctionne aussi dans l'autre sens : il transforme un tableau issu de la base de données en un résumé de trois phrases que le directeur commercial peut lire.

Garder cette définition nette est important, car la plupart des déceptions observées sur le terrain naissent ici. Demandez à un LLM « quel délai de paiement accorder à ce distributeur » : il produira une phrase assurée — mais c'est de la génération de langage, pas une décision financière. La décision doit rester dans vos règles de risque.

Comment relier un composant non déterministe à un système déterministe ?

Les systèmes de stock, de comptabilité et d'expédition sont déterministes : la même entrée donne toujours le même résultat, et il ne peut en être autrement. Le LLM, lui, est probabiliste ; il peut répondre à la même question avec deux formulations différentes. La façon sûre de réunir ces deux mondes est de tracer une frontière entre eux.

La règle : le LLM propose, le système valide, l'humain approuve, et l'écriture est faite par le code. Le LLM n'exécute jamais directement un INSERT en base. Sa sortie passe d'abord par la validation de schéma (la référence existe-t-elle vraiment, la quantité est-elle positive, l'encours du distributeur le permet-il ?) ; elle est ensuite présentée à l'écran, à une personne, sous la forme « valider / corriger ».

Concrètement : quand le LLM se trompe, la conséquence est qu'un utilisateur corrige un champ, pas que le système casse. C'est cette conception qui rend le risque supportable.

02. Comment se construit l'architecture : où le LLM se branche-t-il sur vos systèmes ?

Nous ne bâtissons pas cette structure en montant une plateforme de zéro, mais en ajoutant un anneau au-dessus des couches que vous exploitez déjà. La couche d'API REST .NET 8 déjà présente dans Think WMS et le Portail Distributeurs B2B en est le point de raccordement naturel.

Qu'est-ce que le RAG — entraîne-t-on le modèle avec les données de l'entreprise ?

Non. C'est le malentendu que nous rencontrons le plus souvent. Le RAG (Retrieval-Augmented Generation) consiste, plutôt qu'à entraîner le modèle sur vos données, à retrouver le document pertinent pour la question posée et à le faire lire au modèle à cet instant. Votre catalogue produits, vos procédures ERP et vos documents techniques sont découpés en petits fragments, chaque fragment est converti en une représentation numérique (embedding) puis stocké dans une base vectorielle ; à l'arrivée d'une question, les fragments les plus pertinents sont extraits et fournis au modèle comme contexte. Résultat : quand vous mettez à jour votre tarif, inutile de réentraîner le modèle, vous remplacez simplement le document — et vous pouvez vérifier sur quel document repose la réponse, puisqu'elle cite sa source.

03. Dans quels processus le bénéfice est-il concret ? Cinq scénarios

Les chiffres ci-dessous sont des estimations issues de mesures de charge sur des processus comparables et des fourchettes observées en pilote ; ils varient selon la qualité des données de chaque entreprise. Lisez-les comme des objectifs de départ à mesurer en étude de faisabilité, non comme un engagement ferme.

a) Comment fonctionne la saisie de commande en langage naturel dans le Portail B2B ?

Processus actuel : Le distributeur envoie sa commande en texte libre par e-mail ou WhatsApp. Un chargé de clientèle traduit les produits en références et les saisit à la main dans le portail ou l'ERP. Les confusions de référence et les lignes oubliées sont les deux erreurs les plus fréquentes.

Processus avec LLM : Le distributeur écrit la même phrase dans la barre de recherche du portail, ou l'e-mail entrant est analysé automatiquement. Le système fait la correspondance avec le catalogue produits via le RAG et présente le panier déjà constitué : « Vouliez-vous dire ceci ? » Le distributeur confirme et la commande descend dans l'ERP via la couche d'adaptateurs.

Gain mesurable : Les 4 à 6 minutes de saisie manuelle par commande réduites d'environ moitié ; une baisse nette des retours et corrections dus à une mauvaise référence. À 60 commandes par jour, cela représente une part importante de la charge d'une personne.

Où cela s'intègre : Portail Distributeurs B2B (interface React + couche d'adaptateurs agnostique à l'ERP) et module PWA pour les commerciaux itinérants.

b) Les comptes rendus de visite peuvent-ils être résumés automatiquement dans Think CRM ?

Processus actuel : Le commercial terrain visite cinq distributeurs dans la journée et rédige ses notes le soir — ou ne les rédige pas. Et quand il le fait, il reste une phrase du type « rencontré, positif » ; le responsable ne peut pas lire un pipeline dans ces notes.

Processus avec LLM : Le commercial laisse le compte rendu en note vocale sur son téléphone ou saisit un court texte libre. Le système en fait un enregistrement structuré : produits évoqués, motif d'objection, délai de paiement demandé, prochaine action et date proposée. Après validation du commercial, la proposition est enregistrée dans le CRM.

Gain mesurable : 2 à 3 heures de reporting par commercial et par semaine ; plus important encore, une hausse nette de la part des visites réellement saisies. Un CRM vide produit un rapport vide.

Où cela s'intègre : Think CRM (modules distributeurs B2B et clients finaux B2C).

c) Peut-on obtenir un rapport Power BI à partir d'une question en langage courant ?

Processus actuel : Le directeur général demande « sur quelle famille de produits le chiffre d'affaires a-t-il reculé en région de Marmara au dernier trimestre ». La demande part à la DSI ou au consultant BI, prend la file, et revient quelques jours plus tard.

Processus avec LLM : Le dirigeant écrit sa question en langage naturel. Le LLM reçoit le schéma de votre modèle de données (noms des tables et des mesures) comme contexte et produit une requête DAX ou SQL ; la requête s'exécute sous vos règles de droits et le résultat revient accompagné d'un graphique. La requête générée reste visible à l'écran, afin que l'équipe BI puisse la vérifier.

Gain mesurable : Pour les questions courantes à une seule dimension, le délai de réponse passe de plusieurs jours à quelques minutes. Les analyses complexes restent le métier du consultant BI — l'objectif est de désengorger la file de la DSI des questions simples.

Où cela s'intègre : Une couche questions-réponses bâtie sur notre service de reporting Power BI et de conseil BI.

d) Un opérateur ganté peut-il faire une réception de marchandises à la voix ?

Processus actuel : L'opérateur prend le terminal, retire un gant, choisit un menu à l'écran et saisit une quantité. En chambre froide, ou sur des lignes qui exigent les deux mains, cette étape est à la fois lente et source d'erreurs.

Processus avec LLM : L'opérateur parle : « Réception, douze cartons au rack numéro cinq. » La voix est convertie en texte, le LLM la transforme en l'objet de transaction attendu par le WMS, et le terminal demande confirmation à l'écran et à la voix. Après validation, le mouvement de stock est créé via l'API .NET 8.

Gain mesurable : Quelques secondes par opération sur des tâches répétitives comme la réception et l'inventaire — un total significatif sur des milliers d'opérations par poste. Le vrai gain, ce sont les erreurs d'emplacement et de quantité en moins, puisque les mains restent libres.

Où cela s'intègre : Think WMS (terminal portatif Android + API REST .NET 8).

e) Qu'apporte un assistant interne de questions-réponses sur les procédures ERP ?

Processus actuel : La question « avec quel type de pièce émettions-nous l'avoir dans Mikro ? » atterrit sur le bureau d'un collègue expérimenté. Si cette personne est en congé, le travail s'arrête. Le savoir de l'entreprise est dans les têtes, pas dans les documents.

Processus avec LLM : Les documents de procédure, les manuels de l'ERP et les tickets de support passés sont chargés dans la couche RAG. Le collaborateur pose sa question et l'assistant donne la réponse avec le document source et le numéro d'article. Une réponse sans source n'est pas une réponse.

Gain mesurable : Une part importante des questions internes récurrentes résolue dès le premier contact ; un temps d'intégration raccourci pour les nouveaux arrivants. Bénéfice supplémentaire : voir quelles questions reviennent souvent et rédiger la procédure qui manque réellement.

Où cela s'intègre : Dans le cadre du conseil IT, intégré à votre portail ou intranet existant.

04. Où sont les risques : qu'acceptez-vous en connaissance de cause ?

Que signifie l'hallucination sur le plan opérationnel ?

Plutôt que de dire qu'ils ne savent pas, les LLM peuvent inventer une réponse d'apparence plausible. C'est ce qu'on appelle l'hallucination. Sur le plan opérationnel : le modèle peut proposer une référence qui n'existe pas, ou décrire une procédure avec assurance et à tort.

La solution n'est pas dans le modèle mais dans l'architecture. Une référence produit est toujours confrontée au catalogue réel : une référence inventée n'entre pas dans le système. L'assistant documentaire est tenu de citer ses sources. Et dans les flux critiques, la validation humaine n'est jamais supprimée.

Où vont nos données, et qu'en est-il de la protection des données ?

C'est la question à poser dès la première réunion. Trois options existent, offrant chacune un équilibre coût-confidentialité différent :

• Modèle cloud, contrat entreprise : On travaille avec l'engagement que les données ne servent pas à l'entraînement du modèle. Le démarrage le plus rapide et le moins cher, mais les données partent chez un sous-traitant à l'étranger.
• Hébergement situé en Türkiye : Le middleware et la base vectorielle restent sur des serveurs en Türkiye ; seul un contexte masqué et réduit au minimum nécessaire est envoyé au modèle.
• Modèle ouvert on-premise : Le modèle tourne sur votre propre serveur, les données ne sortent pas du bâtiment. Cela exige un investissement matériel et de la maintenance ; c'est l'option privilégiée pour les contenus sensibles comme les contrats et les tarifs.

Quelle que soit l'option, masquer les champs contenant des données personnelles (nom du contact chez le distributeur, téléphone, adresse) avant tout envoi au modèle est notre pratique standard. La conformité en matière de protection des données n'est pas une fonctionnalité produit : c'est une décision de conception.

Comment rendre le coût des tokens prévisible ?

L'usage d'un LLM se facture au volume de texte traité (tokens). À première vue, cela rend la budgétisation incertaine ; calculé par processus, il devient pourtant prévisible. Analyser une commande ou résumer un compte rendu coûte de l'ordre de quelques centimes par opération.

Voici ce que nous faisons en étude de faisabilité : nous prenons le volume mensuel d'opérations du processus, mesurons la consommation moyenne de tokens par opération et posons un plafond. Limites par utilisateur et par processus, cache pour les questions fréquentes, limite de fragments sur les documents longs — ce ne sont pas des détails techniques, ce sont des outils de contrôle budgétaire.

Où ne faut-il pas l'utiliser ?

Pour être honnête, cette partie de la liste compte autant que les domaines exploitables :

• Écritures comptables et calculs financiers : Écriture au journal, calcul de TVA, comptabilité analytique. C'est l'affaire du moteur de règles ; un LLM n'est pas un outil conçu pour l'arithmétique.
• Déclarations officielles et documents électroniques : Facture électronique, bon de livraison électronique, déclarations réglementaires. Une erreur de format ou de contenu a des conséquences juridiques.
• Travaux exigeant un résultat exact et reproductible : Solde de stock, lettrage des comptes, calcul de prix. Cela s'obtient en écrivant une requête, pas en interrogeant un modèle.
• Déclencheurs irréversibles : Lancer une expédition sans validation, paiement automatique, correspondance envoyée directement au client.

05. Comment cela s'emballe-t-il et s'achète-t-il ?

Notre approche ne consiste pas à ouvrir un budget vaste et flou sous l'étiquette « projet IA ». L'intégration de l'IA en entreprise ressemble davantage à un chantier d'amélioration des processus qu'à un achat de logiciel ; c'est pourquoi nous suivons un parcours en quatre étapes, avec une porte de sortie à chacune :

1. Cadrage et faisabilité (1 à 2 semaines) : Nous observons les processus sur place et constatons l'état des données et de la documentation. Livrable : processus candidats, fourchette de gain attendue, estimation de coût et liste de risques. La conclusion peut être « pas encore pertinent sur ce processus » ; nous préférons le dire d'emblée.
2. Pilote (4 à 6 semaines, un seul service) : Un processus, un nombre d'utilisateurs limité, un objectif mesurable. Le critère de réussite du pilote est écrit dès le départ : par exemple la réduction visée du temps de saisie des commandes.
3. Déploiement : Si le pilote tient ses promesses, extension aux autres services et produits, avec habilitations et formation.
4. Usage et maintenance mensuels : Coût d'usage du modèle, supervision, fraîcheur documentaire et améliorations. Ce poste n'est pas optionnel — une couche RAG non entretenue se périme en quelques mois.

Pourquoi ne vendons-nous pas un « module IA » séparé ?

Parce que l'utilisateur ne veut pas utiliser de l'intelligence artificielle : il veut saisir sa commande vite et voir son rapport sans attendre. Les modules qui exigent un écran à part, une licence à part et une habitude à part restent sur l'étagère.

C'est pourquoi nous intégrons la capacité LLM dans l'écran de réception du WMS, dans le formulaire de visite du CRM et dans la barre de recherche du portail. L'utilisateur n'apprend pas un nouvel outil ; l'écran qu'il utilise déjà lui demande moins de clics. Conséquence commerciale : l'investissement va à l'usage plus poussé d'un produit déjà en service, pas à un module que personne n'ouvre.

06. Par quel processus commencer ?

Le choix du bon pilote est la décision la plus déterminante du projet. Commencez par un processus qui satisfait les trois critères à la fois :

1. Répétitif : Réalisé des dizaines de fois par jour. Sur une tâche ponctuelle, le gain ne se mesure pas.
2. À dominante texte : Son entrée est du texte libre, de la voix ou des documents. Les tâches numériques et normées relèvent déjà du logiciel classique.
3. À erreur réversible : Une proposition erronée doit pouvoir être corrigée — tant qu'elle est à l'écran, pas une fois l'expédition partie.

Avec ces trois critères, vous pouvez ramener vos propres processus à une liste courte. Dans la plupart des entreprises industrielles et de distribution, la liste commence par la saisie de commande et les questions-réponses sur la documentation interne : les deux ont un volume quotidien élevé, une entrée textuelle et des erreurs corrigibles à l'écran.

Un avertissement : en dressant la liste, choisissez le processus le plus répété, pas le plus visible. Une démonstration qui impressionne en comité de direction et une fonctionnalité qui fait vraiment gagner du temps sur tout un poste ne sont pas souvent la même chose. Le but d'un pilote n'est pas de faire un spectacle, mais de documenter un écart mesurable.

Il faut aussi regarder le volet données dès le départ. Là où le même article figure sous trois noms différents dans le catalogue, ou là où les procédures n'ont jamais été écrites, le premier chantier n'est pas d'installer un LLM : c'est de remettre ces deux points en ordre. C'est d'ailleurs le sujet auquel nous consacrons le plus de temps lors du cadrage.

Clarifions ensemble par où commencer : lors d'un échange de cadrage gratuit, nous passerons en revue votre ERP actuel (Mikro, Logo ou autre), la qualité de vos données et vos processus pour déterminer quelle étape produira réellement un gain — et si elle n'en produit pas, nous vous le dirons aussi. Notre équipe du Teknopark GTÜ de Gebze est toujours disponible pour parler d'un système qui fonctionne réellement sur le terrain.