Déployez des LLM dans votre entreprise : configuration étape par étape

Déployer un modèle de langage en production ne consiste pas à télécharger un ZIP et à exécuter une commande. J’ai vu des équipes passer des mois sur une preuve de concept qui fonctionnait sur le portable d’un ingénieur et qui tombait en panne dès le premier lundi avec vingt utilisateurs simultanés. Ce guide décrit le processus réel de configuration, avec les décisions qui comptent et les points où presque tout le monde trébuche.

Avant de toucher à quoi que ce soit : définissez le cas d’usage et le critère de succès

La configuration technique dépend du travail que le modèle va effectuer. Un assistant interne qui répond sur la documentation d’entreprise (récupération augmentée sur des PDF) n’est pas la même chose qu’un classificateur de tickets de support (une tâche délimitée où un petit modèle bien ajusté l’emporte sur un grand modèle avec un prompt générique).

Écrivez une phrase concrète avant de choisir un fournisseur : « le commercial saisit une question sur les prix et reçoit une réponse avec le lien vers la section du catalogue en moins de trois secondes ». Si vous ne pouvez pas mesurer cela, vous ne pouvez rien configurer avec discernement.

Une erreur courante : des équipes qui commencent par demander « un ChatGPT interne » sans délimiter le domaine ni les sources. Le résultat est un chat qui hallucine sur la politique de congés parce que personne ne lui a donné accès au bon document. Délimitez les sources avant le modèle.

Décision 1 : API gérée, modèle ouvert auto-hébergé ou hybride

Trois voies réelles, avec des coûts et des frictions différentes :

• API d’un fournisseur cloud : vous mettez en place en quelques heures. Le coût est variable par token et la latence dépend du réseau. Adapté à presque tout, sauf lorsqu’il y a des données qui ne peuvent pas sortir du périmètre.
• Modèle ouvert sur votre infrastructure : contrôle total de la donnée, coût fixe de GPU. Nécessite de savoir opérer l’inférence : quantification, mémoire vidéo, files de requêtes. Un modèle de 7-8 milliards de paramètres en quantification 4 bits tourne sur un GPU de 24 Go ; un modèle de 70B en nécessite plusieurs ou des quantifications agressives qui dégradent la qualité.
• Hybride : petit modèle local pour classifier et router, grand modèle via API uniquement pour les requêtes complexes. Réduit le coût et l’exposition des données.

Selon la documentation officielle des principaux frameworks d’inférence (vLLM, TGI, Ollama), la performance en production dépend davantage du batching et de la gestion du cache KV que du modèle choisi. Un serveur mal configuré avec un excellent modèle offre une moins bonne expérience qu’un serveur bien ajusté avec un modèle moyen.

Le facteur que personne ne budgétise : le GPU

Si vous optez pour l’auto-hébergement, calculez la mémoire avant d’acheter. Règle pratique : paramètres en milliards × octets par paramètre selon la quantification (≈0,5 octet en 4 bits, ≈1 octet en 8 bits, ≈2 octets en 16 bits) plus l’espace pour le contexte. Un 7B en FP16 occupe environ 14 Go rien qu’en poids ; avec un contexte long, vous manquez de VRAM plus vite que vous ne le pensez.

Décision 2 : comment vous lui donnez la connaissance de l’entreprise

C’est ici que se trouve 80 % du travail réel. Deux approches :

Récupération augmentée (RAG)

Vous découpez les documents, générez des embeddings, les stockez dans un index vectoriel et, à chaque requête, vous récupérez les fragments pertinents pour les injecter dans le prompt. Étapes de configuration :

1. Ingestion avec contrôle de versions. Chaque document porte des métadonnées : source, date, département, permissions. Sans permissions dans les métadonnées, un stagiaire peut lire les procès-verbaux du conseil.
2. Découpage réfléchi. Fragments de 300 à 800 tokens avec chevauchement. Découper par caractères casse les tableaux et les listes ; découpez par structure (en-têtes, paragraphes).
3. Embeddings et réindexation. Choisissez un modèle d’embeddings multilingue s’il y a des documents en plusieurs langues. Planifiez la réindexation lorsque le corpus change ; un index obsolète répond avec des données d’il y a deux ans sans prévenir.
4. Récupération hybride. Combinez recherche sémantique et recherche lexicale (BM25). Les codes produit et les noms propres échouent en recherche purement vectorielle.
5. Reranking et seuil. Un reranker écarte les fragments non pertinents. Définissez un seuil : si la similarité est faible, l’assistant doit dire « je ne sais pas » plutôt qu’inventer.

Ajustement fin (fine-tuning)

Utile pour le style, le format de sortie et les tâches répétitives avec de nombreux exemples étiquetés. Ce n’est pas l’outil pour injecter une connaissance changeante : un modèle ajusté avec le catalogue de janvier continuera de répondre avec celui de janvier. Pour les données qui changent, le RAG.

Configuration du prompt système et des garde-fous

Le prompt système est de la configuration, pas de l’écriture créative. Définissez : rôle, ton, limites, format de sortie et que faire en cas de doute. Soyez explicite sur le format si vous allez parser la réponse (JSON avec schéma fixe, par exemple) et validez la sortie avec un parser avant de la montrer à l’utilisateur.

Garde-fous minimaux que vous devez configurer :

• Filtre d’entrée et de sortie pour les données personnelles selon la politique interne.
• Limite de longueur de contexte et de tokens de sortie (évite les coûts débridés).
• Journal des conversations avec rétention définie et accès audité.
• Rate limiting par utilisateur et par IP.
• Bouton « signaler une réponse incorrecte » qui alimente une file de révision.

Un détail que vous découvrez en production : les utilisateurs collent des conversations complètes d’autres chats dans le prompt. Sans limite de longueur, le coût par session se multiplie et le modèle se laisse distraire par un contexte non pertinent.

Intégration avec les systèmes de l’entreprise

L’assistant vit rarement isolé. Configuration typique :

1. Couche d’orchestration (backend propre ou framework d’agents) qui reçoit la requête, décide si elle consulte l’index, appelle un outil ou répond directement.
2. Connecteurs vers les systèmes internes via API avec des identifiants de service en lecture seule et des permissions minimales. Ne donnez jamais au modèle des identifiants d’écriture sur l’ERP dans la première version.
3. Authentification et héritage des permissions. L’assistant doit répondre uniquement avec ce que l’utilisateur peut voir. Cela s’implémente dans la couche de récupération, pas dans le prompt : demander au modèle de « ne pas révéler de données confidentielles » n’est pas un contrôle d’accès.
4. Observabilité. Traces par requête : tokens d’entrée et de sortie, latence, fragments récupérés, coût estimé. Sans cela, vous ne pouvez ni optimiser ni justifier la dépense.

Testez avec des données réelles avant d’ouvrir la porte

Montez un ensemble d’évaluation avec des questions réelles d’utilisateurs et des réponses attendues. Mesurez : précision de la réponse, taux de « je ne sais pas » corrects, latence au 95e percentile et coût moyen par requête. Selon des études du secteur, une part significative des défaillances des assistants d’entreprise provient de la récupération, pas de la génération : le modèle répond bien à un fragment erroné.

Testez aussi les cas limites : questions ambiguës, requêtes hors domaine, tentatives de manipulation du prompt. Et examinez le comportement avec des documents scannés mal numérisés : un OCR sale génère des réponses avec des chiffres corrompus.

Déploiement progressif et maintenance

Commencez avec un groupe pilote de dix ou vingt personnes d’un seul département. Recueillez les retours pendant deux semaines, ajustez le prompt et le corpus, et seulement ensuite élargissez. Ayez un plan de retour en arrière : pouvoir désactiver l’assistant sans casser le flux de travail de l’équipe.

Maintenance continue indispensable : réindexer lorsque les documents changent, revoir les coûts hebdomadaires, surveiller la latence et mettre à jour le modèle lorsqu’une meilleure version apparaît, uniquement après avoir passé l’évaluation. Changer de modèle sans évaluer est le moyen le plus rapide de dégrader un système qui fonctionnait.

Ce que cette approche ne résout pas

Un LLM configuré ainsi ne remplace pas un système de règles dans les processus où l’exactitude est obligatoire (calcul de paie, conformité réglementaire avec des chiffres). Il n’est pas non plus fiable pour le raisonnement mathématique complexe sans outils externes. Et il n’élimine pas la nécessité d’une révision humaine dans les communications externes sensibles.

La configuration pas à pas qui fonctionne est celle qui commence de manière délimitée, mesure, et n’élargit que ce qui démontre de la valeur. Le reste, c’est de la dépense en tokens.