Un projet de stage explorant comment l'IA générative peut prolonger un ERP existant plutôt que le remplacer : au lieu de construire un nouveau système, le travail s'est fait à l'intérieur d'un système déjà en production, contraint par ses données, ses utilisateurs, et la nécessité de continuer à fonctionner pendant l'expérimentation.
Le problème et les contraintes
L'entreprise souhaitait intégrer des fonctionnalités d'IA générative à son ERP — notamment pour automatiser la génération et l'exploitation de certains documents et informations — sans perturber un système déjà en production. Cette contrainte a structuré tout le reste : la solution devait s'intégrer à un ERP existant plutôt que fonctionner seule, préserver la confidentialité des données métier, et, autant que possible, tourner en environnement local plutôt que d'appeler une API externe. Des réponses cohérentes et adaptées au contexte métier comptaient plus que la seule capacité brute du modèle, le tout dans un temps de stage limité.
Approche
- Étude et comparaison de plusieurs modèles de langage au regard des besoins fonctionnels de l'ERP, plutôt que retenir le premier qui fonctionne.
- Expérimentation du déploiement local d'un LLM et de son intégration avec l'ERP, pour mesurer ce que coûte un déploiement local en mise en place et en ressources face à un modèle hébergé.
- Exploration d'une approche RAG (Retrieval-Augmented Generation) afin que le modèle s'appuie sur les connaissances déjà détenues par l'application, plutôt que de répondre uniquement à partir de ses connaissances générales.
- Participation aux premières fonctionnalités de génération automatisée de documents, et aux tests fonctionnels permettant de juger si les réponses d'un modèle étaient assez pertinentes et cohérentes pour être utilisées.
Compromis faits
Decision
Déploiement local plutôt qu'un modèle hébergé, pour une partie des expérimentations : garde les données métier et l'environnement d'exécution sous contrôle, au prix de contraintes matérielles et de performance qu'une API hébergée n'a pas.
Decision
RAG plutôt qu'une génération directe : ajoute une étape de récupération et de préparation du contexte que le modèle doit attendre, mais ancre les réponses dans les connaissances propres à l'entreprise plutôt que dans l'entraînement général du modèle — une étape qui se justifie pour un ERP où une réponse fausse mais bien formulée est pire qu'une réponse lente.
Résultats
L'expérimentation a permis d'intégrer et de tester plusieurs fonctionnalités d'IA générative dans le contexte de l'ERP, dont une première chaîne de traitement exploitant un modèle de langage pour générer du contenu. Elle a aussi fait apparaître des différences de comportement réelles entre les LLM comparés, et des indices sur les cas où une architecture RAG justifie sa complexité — ceux qui nécessitent d'ancrer le modèle dans des connaissances spécifiques au domaine plutôt que générales. Aucune métrique quantitative n'a été retenue à ce stade : les résultats ont été jugés par des tests fonctionnels et une comparaison qualitative entre modèles, pas par un score unique.
Ce que je referais différemment
Remplacer la comparaison qualitative par un protocole d'évaluation plus systématique, avec des métriques pensées pour les applications LLM : pertinence des réponses, fidélité aux sources, taux d'erreur, temps de réponse. Je mettrais aussi en place une évaluation automatisée, pour que comparer des modèles ou repérer une régression au fil des évolutions ne dépende pas d'une relecture manuelle des réponses.