LLM en entreprise : ce que recouvre une solution sur mesure
Déployer un LLM en entreprise revient rarement à entraîner un modèle maison. La solution sur mesure assemble un grand modèle de langage existant, les documents de l’organisation, des règles d’accès et une supervision. Quatre architectures couvrent l’essentiel des projets, du modèle généraliste appelé par API jusqu’au modèle ouvert installé sur des serveurs choisis.
Le LLM d’entreprise n’est presque jamais un modèle maison
Un grand modèle de langage, ou LLM pour large language model, est un programme entraîné sur d’immenses volumes de textes à prédire la suite la plus probable d’un passage, fragment après fragment. De cette mécanique naissent des capacités concrètes : résumer, reformuler, classer, extraire une information, rédiger une réponse. Le modèle ne consulte aucune base de faits ; il produit un texte plausible, d’où des erreurs affirmées avec aplomb, appelées hallucinations.
Entraîner un tel modèle depuis zéro mobilise des corpus gigantesques, des grappes de processeurs graphiques pendant des semaines et des équipes de recherche, un investissement que seuls quelques éditeurs assument, parmi lesquels OpenAI, Meta, Google ou Mistral AI. Un petit modèle dédié à une tâche étroite se construit parfois de bout en bout ; un modèle de langage généraliste, presque jamais.
Pour une PME ou une ETI, « l’IA sur mesure » désigne donc ce qui entoure le modèle : instructions, données consultées, outils actionnés, interface, droits d’accès, supervision. Une solution sur mesure se juge sur cet assemblage.
Quatre architectures, du plus simple au plus lourd
Un modèle généraliste appelé par API
L’application de l’entreprise envoie chaque demande au modèle généraliste d’un fournisseur par une interface de programmation, dont l’API REST expliquée aux non-développeurs détaille le principe. Elle y joint des instructions permanentes, qui fixent rôle, ton et limites, et déclare au modèle des outils : consulter une fiche client, vérifier un stock, ouvrir un ticket. Le modèle demande l’exécution d’un outil, l’application l’exécute avec ses propres droits. Rien n’est entraîné : le sur mesure tient dans cette intégration.
Les documents de l’entreprise branchés sur le modèle
La génération augmentée par récupération, abrégée RAG, ajoute une étape de recherche. Les documents de l’entreprise (procédures, contrats types, fiches produits) sont découpés en passages et indexés. À chaque question, le système retrouve les passages les plus proches et les transmet au modèle, qui compose sa réponse en s’appuyant sur ces extraits et peut en citer l’origine. La qualité dépend alors de la base : un intranet d’entreprise vraiment utilisé fournit une matière autrement plus fiable qu’un partage de fichiers à l’abandon.
Un modèle ajusté sur des exemples métier
L’ajustement, ou fine-tuning, prolonge l’entraînement d’un modèle existant sur des exemples propres au métier : des courriers et leur réponse type, des tickets et leur catégorie. Le modèle ajusté acquiert une forme, un vocabulaire, une manière de trier, avec une constance que de simples instructions obtiennent mal. Il retient mal, en revanche, des faits qui bougent : un tarif modifié réclame un nouvel ajustement, là où la voie documentaire se contente d’un fichier remplacé.
Un modèle ouvert hébergé sur des serveurs choisis
Certains éditeurs publient les poids de leurs modèles, c’est-à-dire les paramètres appris pendant l’entraînement. La famille Llama de Meta en fait partie, et la documentation de Mistral AI distingue des modèles à poids ouverts sous licence Apache 2.0, d’autres sous licence maison ou non commerciale. Ce modèle ouvert tourne sur les serveurs de l’entreprise ou chez un hébergeur qu’elle désigne, sans qu’aucune requête quitte ce périmètre. Machines à processeurs graphiques, mises à jour et sécurité passent en contrepartie à sa charge ou à celle de son prestataire.
Le choix entre ces quatre voies se prépare avec un accompagnement technique sur mesure ; du côté de Digital Unicorn, l’offre de développement d’IA consiste à intégrer de grands modèles de langage existants, de la famille Llama ou GPT, ou à bâtir la solution entièrement à partir de zéro. Pour une base documentaire branchée comme pour un ajustement sur exemples, des data scientists y rassemblent, nettoient et organisent les données que réclame le projet, puis surveillent le comportement du modèle après sa mise en service et proposent des améliorations. Cette continuité, de la préparation des données au suivi en production, sécurise l’architecture retenue bien après son lancement.
Côté organisation, trois données de départ orientent cet arbitrage. Un recueil de procédures publiques n’appelle pas les précautions d’un fonds de dossiers clients. Une exigence de confidentialité forte écarte d’emblée certains hébergements. Et quelques dizaines de questions par jour ne pèsent pas sur la facture comme le traitement automatique de tout le courrier entrant.
Où partent les données confiées au modèle de langage
Toute requête transporte des données : la question, les passages joints, parfois un nom de client ou un montant. Dans les trois premières architectures, ce paquet part chez le fournisseur du modèle de langage, au moins le temps du traitement.
Ce que prévoient les conditions des fournisseurs
La CNIL, l’autorité française de protection des données, a publié le 16 octobre 2025 une fiche expliquant comment refuser que ses conversations entraînent les principaux assistants conversationnels : côté particuliers, cette réutilisation est courante. Côté développeurs, la documentation de l’API d’OpenAI indique que les données envoyées n’entraînent pas ses modèles sans accord explicite, les journaux de détection des abus étant gardés jusqu’à 30 jours sauf obligation légale. Le centre d’aide de Mistral AI, mis à jour le 31 août 2026, précise qu’hors offres entreprise les données saisies peuvent nourrir l’entraînement faute d’opposition. D’où une règle simple : lire les conditions de la formule souscrite, pas celles de la marque, et les relire à chaque renouvellement.
Ce que change un hébergement en Europe
Un traitement hors de l’Espace économique européen constitue un transfert, que le RGPD encadre. Selon la CNIL, il exige une protection suffisante, assurée par une décision d’adéquation, comme celle que Bruxelles a rendue le 10 juillet 2023 pour le Data Privacy Framework américain, ou par des clauses contractuelles types. Des données traitées dans cet espace n’appellent aucun de ces outils. OpenAI ouvre d’ailleurs, sous conditions, une région européenne de stockage et de traitement pour les nouveaux projets de son API.
Documents consultés ou documents appris
Consacré à l’IA générative, le guide de l’ANSSI, l’autorité nationale de cybersécurité, relève qu’aucun droit d’accès ne s’applique aux données d’entraînement, du fait même du fonctionnement des réseaux de neurones, alors que les données ajoutées en production se cloisonnent par profil. Un modèle ajusté sur des dossiers sensibles risque donc d’en restituer des fragments à n’importe quel utilisateur, quand une base branchée filtre les passages selon les droits de chacun. Le même guide demande de traiter un modèle avec la sensibilité des données qui l’ont formé.
Ce qui pèse une fois le modèle en service
Le coût d’un modèle de langage court à chaque question posée, bien après la livraison.
Le volume de requêtes et la longueur des textes
Les fournisseurs facturent leur API au jeton, un fragment de mot, en comptant le texte envoyé comme le texte produit. Une architecture documentaire allonge chaque envoi, puisque les passages retrouvés accompagnent la question. Un modèle hébergé en propre inverse la logique : la dépense devient fixe, celle des serveurs, qu’ils tournent à plein ou à vide.
La taille du modèle et le temps de réponse
En règle générale, un modèle plus volumineux traite mieux les demandes complexes, mais répond plus lentement et coûte plus cher. Une tâche de tri ou d’extraction se contente souvent d’un modèle compact. Devant un client, l’affichage progressif rend l’attente acceptable ; le reste peut tourner la nuit. Pour un modèle hébergé en propre, le guide de l’ANSSI note que ces déploiements reposent généralement sur des processeurs graphiques, et recommande de les réserver au système d’IA plutôt que de les partager avec d’autres applications métier.
La supervision de la qualité des réponses
Un modèle peut répondre différemment à une même question et se tromper avec assurance. La qualité se mesure donc en continu :
- part des réponses corrigées par un collaborateur ;
- signalements des utilisateurs ;
- réponses produites sans passage documentaire à l’appui ;
- coût moyen par requête et délai de réponse.
Ces mesures rejoignent naturellement un tableau de bord analytics sans usine à gaz, à côté des indicateurs métier qu’elles servent.
Changer de modèle sans tout reconstruire
Les fournisseurs retirent des versions et révisent tarifs et conditions ; un modèle mieux adapté peut aussi surgir.
Une couche d’abstraction entre l’application et le modèle
L’application ne parle jamais directement au fournisseur, mais à un module intermédiaire qui traduit ses demandes vers le modèle retenu. Instructions, description des outils et règles de filtrage vivent dans ce module, côté entreprise, et non dans la console d’un éditeur. Grâce à cette couche d’abstraction, changer de modèle revient à modifier une configuration puis à revalider. Les architectures diffèrent ici : un index documentaire survit au remplacement du modèle qui rédige les réponses, alors qu’un ajustement réalisé sur le modèle fermé d’un éditeur reste chez cet éditeur.
Un jeu de test maison pour comparer
Seule une évaluation sur des cas réels dit si un autre modèle fait mieux. Le jeu de test réunit des questions représentatives, les réponses attendues validées par les métiers et quelques pièges : demande hors périmètre, document contradictoire, information absente. Rejoué sur le modèle en place puis sur le candidat, il compare exactitude, ton, coût et délai, sans se fier aux palmarès publics, mesurés sur d’autres tâches, et se rejoue à chaque nouvelle version annoncée.
Les quatre architectures côte à côte
| Architecture | Données exposées au fournisseur | Effort de mise en place | Maîtrise de l’hébergement | Coût d’exploitation |
|---|---|---|---|---|
| Modèle généraliste par API | Chaque requête et ses pièces jointes | Faible | Celle du fournisseur, région selon l’offre | Proportionnel à l’usage |
| Documents branchés (RAG) | Requête et passages retrouvés | Moyen : indexation, droits, mises à jour | Index maîtrisé, modèle chez le fournisseur | Requêtes plus longues, plus l’index |
| Modèle ajusté | Exemples d’entraînement, puis requêtes | Élevé : corpus d’exemples à constituer | Variable selon le modèle de départ | Nouvel ajustement à chaque évolution |
| Modèle ouvert hébergé | Aucune hors du périmètre choisi | Élevé : serveurs, sécurité, mises à jour | Complète | Fixe : serveurs et exploitation |
Ces voies se combinent volontiers : une base documentaire branchée sur un modèle ouvert hébergé réunit fraîcheur des documents et maîtrise du périmètre.
Cinq questions pour orienter le choix
Cinq réponses écrites dessinent l’architecture probable :
- Quelles informations le modèle devra-t-il lire, et qui a le droit de les consulter ?
- Ces informations changent-elles chaque semaine, ce qui oriente vers des documents branchés ?
- La tâche exige-t-elle une forme très constante, terrain naturel de l’ajustement ?
- Quel volume de requêtes et quel délai de réponse sont attendus ?
- Quelle localisation des données le secteur, les clients ou l’assureur imposent-ils ?
Prochaine étape : rassembler une vingtaine de questions réelles des équipes, chacune avec la réponse qu’un collaborateur expérimenté y apporterait. Ce corpus nourrit la discussion d’architecture, puis devient le premier jeu de test le jour où deux modèles devront être comparés.