Quand on parle d'intelligence artificielle dans les outils métier, on passe souvent directement aux cas d'usage spectaculaires — génération de contenu, chatbots, assistants. Ce qui est moins souvent décrit, c'est comment on fait concrètement pour intégrer un LLM dans une application réelle, avec des contraintes de confidentialité, de cohérence et de coût.
CORPORIS est un projet R&D que j'ai développé pour explorer ce territoire : une plateforme B2B de formation métier avec un moteur RAG local intégré. Voici ce que j'ai appris en le construisant.
Le problème que CORPORIS devait résoudre
Dans une organisation, les référentiels documentaires — procédures internes, fiches métier, guides de conformité — sont souvent vastes, peu structurés, et difficiles à mobiliser au moment où un collaborateur en a besoin.
Le besoin identifié était précis : permettre à la plateforme de valider automatiquement qu'un apprenant a bien compris un document de référence, sans que cette validation soit une simple extraction de mots-clés. Il fallait une compréhension contextuelle.
Un LLM seul ne suffisait pas. Envoyer l'intégralité d'un document dans un prompt à chaque requête est coûteux, lent, et dépasse souvent les limites de contexte des modèles. Le RAG — Retrieval-Augmented Generation — est la réponse à ce problème.
Pourquoi le RAG plutôt qu'un LLM classique
Le principe du RAG est simple : au lieu d'injecter toute la connaissance dans le prompt, on stocke les documents sous forme de vecteurs sémantiques, et on ne récupère que les passages pertinents pour répondre à une question donnée.
Concrètement, ça change tout :
- Le coût par requête chute — on envoie 3-4 passages ciblés au lieu de 50 pages.
- La précision augmente — le modèle répond sur la base du document réel, pas de ses connaissances générales.
- Les hallucinations diminuent — le modèle est ancré dans un contexte documentaire vérifiable.
- La confidentialité est maîtrisable — les documents ne quittent pas le système si on utilise un modèle local.
Pour CORPORIS, j'ai implémenté 3 niveaux de fallback LLM : un modèle local en priorité pour les données sensibles, un modèle API léger pour les requêtes standard, et un modèle plus puissant pour les cas complexes. La décision de niveau se fait automatiquement selon la sensibilité du document.
L'architecture choisie
L'architecture repose sur quatre composants principaux :
- Django comme framework central — gestion des utilisateurs, des parcours, des permissions et de l'API.
- Un pipeline d'ingestion — les documents sont découpés en chunks, transformés en vecteurs via un modèle d'embeddings, et stockés dans une base vectorielle.
- Le moteur de retrieval — à chaque question posée par le système, les passages les plus proches sémantiquement sont récupérés et injectés dans le contexte du LLM.
- Le module de validation comportementale — au-delà de la vérification de compréhension, CORPORIS analyse 5 axes comportementaux (rigueur, autonomie, réactivité, coopération, curiosité) à partir des patterns de réponse.
Les défis concrets rencontrés
Le développement a mis en lumière des défis qui ne sont jamais mentionnés dans les tutoriels :
La qualité du découpage documentaire. Un mauvais découpage en chunks produit des passages qui sortent du contexte et trompent le modèle. J'ai testé plusieurs stratégies — découpage fixe, découpage par paragraphe, découpage par section sémantique — avant de trouver la bonne granularité selon le type de document.
La gestion des documents multilingues. Les référentiels métier sont rarement dans une seule langue. L'alignement des embeddings entre le français et l'anglais nécessite un modèle multilingue ou une stratégie de traduction préalable.
La latence perçue. Un pipeline RAG complet (retrieval + génération) prend entre 2 et 8 secondes selon le modèle. Pour une interface utilisateur, c'est long. J'ai implémenté du streaming et des réponses progressives pour rendre l'attente acceptable.
Les tests. Comment tester qu'un LLM répond correctement ? J'ai mis en place 30 tests automatisés couvrant des cas nominaux et des cas limites (documents contradictoires, questions hors-scope, tentatives de contournement).
Ce que ça change pour les organisations
Au-delà de CORPORIS, l'intégration d'un moteur RAG dans un outil métier ouvre des cas d'usage concrets pour toute organisation qui gère de la documentation :
- Validation automatique de la compréhension des procédures internes lors de l'onboarding.
- Assistance contextuelle dans un outil de GED — "à quelle procédure s'applique ce document ?"
- Génération de résumés exécutifs depuis des rapports d'audit volumineux.
- Recherche sémantique dans des archives documentaires mal indexées.
La clé, dans tous ces cas, est de rester ancré sur le problème métier. Le RAG n'est pas une fin en soi — c'est un mécanisme qui permet à un LLM de raisonner sur votre documentation, vos processus, votre contexte.
C'est cette différence — entre un outil générique et un outil ancré dans une réalité organisationnelle — qui détermine si l'IA apporte réellement de la valeur ou si elle reste un gadget démonstratif.
Anjarahasina Raobelina
Consultant en digitalisation