Intégration aux produits métier

Bienvenue

Un LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire local qui répond correctement dans un terminal ne rend service à personne tant qu'il n'est pas branché à un produit que des collaborateurs utilisent réellement : un portail RH, un outil de support, un CRM interne. Cette dernière étape — l'intégration — est souvent sous-estimée. Elle soulève des questions que les chapitres précédents n'ont pas eu besoin de traiter : où vit le modèle par rapport à l'application, comment l'appeler sans coupler tout le code à un fournisseur d'inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire précis, et surtout, que se passe-t-il quand le modèle local est en panne, surchargé, ou tout simplement trop lent pour l'usage visé.

Ce chapitre présente quatre patterns d'intégration, la manière de limiter le couplage grâce à un SDK compatible OpenAI, les mécanismes de repli à prévoir, et une méthode de test centrée sur l'acceptation métier plutôt que sur la performance brute du modèle.

Quatre patterns d'intégration

Le sidecar LLM

Dans ce pattern, le moteur d'inférence (Ollama, vLLM) tourne comme processus compagnon de l'application, sur la même machine ou dans le même pod Kubernetes. L'application lui parle en HTTP local, sans passer par le réseau externe.

C'est le pattern le plus simple à opérer pour une application unique à trafic modéré : latence réseau minimale, pas de dépendance à un service partagé, déploiement atomique (l'application et son modèle montent et descendent ensemble). Il a une limite claire : chaque instance de l'application embarque son propre modèle, ce qui multiplie la consommation de VRAM ou de RAM si l'application est répliquée pour la charge.

Le sidecar convient bien à un outil interne à faible nombre d'utilisateurs simultanés, ou à un cas où la donnée traitée ne doit jamais quitter la machine qui l'a reçue (poste de travail, environnement isolé). Au-delà d'une poignée d'instances applicatives, le coût mémoire cumulé dépasse rapidement celui d'un microservice mutualisé.

Le microservice d'inférence dédié

Ici, le moteur d'inférence est un service à part, exposé en interne via une API HTTP (le plus souvent compatible OpenAI), et plusieurs applications métier le consomment. C'est le pattern dominant en entreprise dès qu'on dépasse un seul produit consommateur : le RH, le support et l'outil commercial peuvent tous appeler le même point d'entrée.

Le microservice permet de mutualiser le GPUGPUIAProcesseur graphique parallélisant massivement les calculs matriciels ; indispensable à l'entraînement et à l'inférence des modèles de deep learning.Voir dans le glossaire, de centraliser le monitoring, la mise à jour de modèle et le contrôle d'accès. Il introduit en contrepartie une dépendance réseau et un point de contention : si le microservice est submergé par un pic sur un produit, tous les autres en pâtissent, à moins de mettre en place des quotas ou files de priorité.

La file d'attente asynchrone

Certaines tâches n'ont pas besoin d'une réponse en moins d'une seconde : résumé de tickets de la journée, classification en lot, génération de comptes-rendus. Dans ce cas, l'application dépose une tâche dans une file (Redis, RabbitMQ, SQS ou équivalent), un ou plusieurs workers consomment la file et appellent le LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire à leur rythme, puis écrivent le résultat où l'application ira le chercher (base de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire, webhook, notification).

Ce pattern découple totalement le rythme de la demande de celui du traitement. Il absorbe les pics sans faire attendre l'utilisateur final devant un écran de chargement, et il permet de dimensionner le nombre de workers indépendamment du trafic entrant. Le coût est une complexité opérationnelle supplémentaire : il faut surveiller la profondeur de la file, gérer les tâches en échec, et l'utilisateur doit accepter un délai de traitement.

L'erreur la plus fréquente est de forcer un appel synchrone sur une tâche qui pourrait attendre. Un bouton « Générer le compte-rendu de la semaine » n'a aucune raison de bloquer l'interface pendant trente secondes : une file d'attente avec notification à la fin change radicalement l'expérience perçue, pour le même travail de calcul.

Les outils exposés via MCP

Quand le LLM doit agir sur le système d'information — consulter un dossier salarié, créer un ticket, interroger une base de connaissances — le pattern function callingtool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire / MCP (Model Context ProtocolMCPIAModel Context Protocol : protocole permettant de brancher des outils et sources externes (docs, tickets, bases) à un agent LLM via des serveurs dédiés.Voir dans le glossaire) permet de décrire au modèle un ensemble d'outils typés, que celui-ci peut décider d'appeler au cours de sa réponse. Le serveur MCP fait l'intermédiaire entre le modèle et les systèmes internes, ce qui a un avantage de sécurité déterminant : le modèle ne touche jamais directement la base de données, il ne fait que demander l'exécution d'une action prédéfinie, dont le code applicatif garde le contrôle complet (validation des paramètres, droits de l'utilisateur, journalisation).

Un outil MCP mal conçu qui expose une requête SQL libre ou un accès fichier non restreint transforme une fonctionnalité pratique en faille de sécurité. Chaque outil doit être aussi étroit que possible dans ce qu'il permet de faire, et vérifier les permissions de l'utilisateur au moment de l'exécution, pas seulement au moment de la configuration.

Limiter le couplage avec le SDK OpenAI-compatible

Ollama et vLLM exposent tous les deux une API HTTP compatible avec le format OpenAI (/v1/chat/completions, /v1/embeddings). Ce choix, devenu un standard de fait dans l'écosystème, permet d'utiliser le SDK officiel openai (Python, Node, etc.) simplement en changeant l'URL de base et la clé d'API — souvent une valeur arbitraire côté serveur local.

from openai import OpenAI

client = OpenAI(
    base_url="http://inference.internal:8000/v1",
    api_key="cle-locale-sans-valeur-reelle",
)

response = client.chat.completions.create(
    model="llama-3.1-8b-instruct",
    messages=[{"role": "user", "content": "Résume ce ticket support en trois lignes."}],
    temperature=0.2,
)

L'intérêt de ce choix dépasse la simple commodité de code. En codant l'appel contre l'interface OpenAI plutôt que contre une bibliothèque spécifique à Ollama ou à vLLM, l'application métier reste portable : passer d'un moteur d'inférence à un autre, ou basculer temporairement vers une API commerciale en cas de panne, ne demande qu'un changement de configuration.

Les deux moteurs ne supportent pas exactement le même sous-ensemble de paramètres OpenAI (grammaires de sortie, logprobs, appel d'outilsappel d'outilsIAMécanisme par lequel un modèle produit un appel de fonction structuré que le code environnant décide d'exécuter. Le modèle n'a jamais d'accès direct : il propose, le code dispose.Voir dans le glossaire multiples). Il faut vérifier au cas par cas les paramètres réellement utilisés par l'application avant de considérer la portabilité comme acquise.

Isoler l'appel derrière une couche métier

Même avec un SDK standardisé, il est recommandé de ne jamais appeler directement le client OpenAI depuis le code métier. Une fine couche d'abstraction — une fonction ou un petit service generer_reponse(contexte, taches) — permet de centraliser : le choix du modèle, les paramètres par défaut (température, longueur maximale), la gestion des erreurs, et le point d'injection du fallback.

Fallback et dégradation contrôlée

Un LLM local peut tomber en panne pour des raisons variées : redémarrage du service, saturation de la file de requêtes, dépassement de la fenêtre de contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire, ou simplement une latence devenue inacceptable sous charge. Un produit métier ne peut pas se permettre de planter ou de rester silencieux dans ces cas.

Trois niveaux de repli sont couramment combinés :

1. Retry avec backoff — une erreur transitoire (timeout réseau, pic de charge momentané) se résout souvent en réessayant après un court délai croissant.
2. Bascule vers un second moteur — un modèle plus petit et plus rapide, hébergé en local ou une API externe, pris comme filet de sécurité si le service principal ne répond pas dans un délai fixé.
3. Dégradation fonctionnelle — si aucun modèle n'est disponible, l'application propose un comportement réduit mais utile : formulaire de recherche classique à la place d'une réponse générée, message d'attente avec mise en file pour traitement différé, ou renvoi vers un humain.

Palier 1 : le modèle principal (8B, vLLM) répond en moins de deux secondes dans 95 % des cas. Palier 2 : au-delà de trois secondes sans réponse, l'appel bascule vers un modèle plus petit (3B, Ollama) qui répond avec une qualité moindre mais acceptable. Palier 3 : si les deux moteurs sont indisponibles, le ticket est automatiquement transmis à un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire humain avec la mention « traitement automatique indisponible », sans que l'utilisateur ne voie d'erreur technique.

Ce qui distingue une dégradation bien conçue d'un simple message d'erreur, c'est que l'utilisateur métier ne perçoit jamais la panne technique : il perçoit un service plus lent ou plus simple, jamais cassé.

Exemple d'architecture : assistant RH interne

Prenons un cas concret : un assistant qui répond aux questions des salariés sur les congés, la mutuelle et les procédures internes, avec la capacité de créer une demande de congé directement.

• Frontend : widget de chat intégré au portail RH existant.
• Backend applicatif : reçoit la question, récupère le contexte pertinent (RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire sur la base documentaire RH), construit le promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire.
• Microservice d'inférence (vLLM, modèle 8B instruct) : génère la réponse, avec appel d'outils MCP pour « consulter le solde de congés » ou « créer une demande de congé ».
• Serveur MCP : expose ces deux outils, vérifie que l'utilisateur authentifié a bien le droit d'agir sur son propre dossier, journalise chaque action.
• Fallback : en cas d'indisponibilité, le widget affiche un lien direct vers le formulaire papier habituel plutôt qu'un message d'erreur brut.

Cette architecture illustre un principe central du chapitre : le LLM ne remplace aucun système existant (le SIRH continue de gérer les congés), il ajoute une couche conversationnelle par-dessus des systèmes qui restent responsables de la vérité des données.

Tests d'acceptation métier

Les benchmarks techniques (perplexité, temps de génération, débit en tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire par seconde) mesurent la qualité et la performance du modèle en soi. Ils ne disent rien sur la question qui compte pour le produit : est-ce que l'assistant RH répond correctement aux questions réelles des salariés, sans halluciner de procédure inexistante ?

Les tests d'acceptation métier se construisent différemment :

• Un jeu de questions représentatif, rédigé avec les équipes métier (RH, support), pas par l'équipe technique seule.
• Des critères d'acceptation binaires ou notés définis à l'avance : la réponse cite-t-elle la bonne politique de congés ? Refuse-t-elle correctement une action hors périmètre ?
• Une rejouabilité automatisée : ce jeu de tests tourne à chaque changement de modèle, de prompt système ou de version du moteur d'inférence, pour détecter une régression avant la mise en production.

La démonstration ponctuelle valorise les meilleurs cas ; les tests d'acceptation, eux, doivent inclure les questions ambiguës, les demandes hors périmètre et les cas limites remontés par le support, faute de quoi le produit échoue en usage réel malgré une démo convaincante.

Ces tests gagnent à être versionnés avec le prompt système et rejoués automatiquement dans le pipeline de déploiement, exactement comme des tests d'intégration classiques. Un changement de modèle, une mise à jour du moteur d'inférence ou une simple reformulation du prompt système peuvent faire régresser silencieusement la qualité perçue sans qu'aucune alerte technique ne se déclenche, puisque le service continue de répondre — juste moins bien. Documenter le taux de réussite du jeu de tests à chaque version permet de repérer ce type de régression avant qu'un utilisateur ne la signale.

Observabilité et coûts en production

Une fois l'intégration en place, deux dimensions supplémentaires méritent un suivi continu : l'observabilité et le coût réel d'exploitation.

Côté observabilité, il est utile de journaliser, pour chaque requête, la latence de bout en bout, le nombre de tokens consommés en entrée et en sortie, le palier de fallback éventuellement activé, et un identifiant de version du modèle et du prompt système. Ces informations permettent de détecter une dégradation progressive (temps de réponse qui augmente semaine après semaine) avant qu'elle ne devienne un incident visible par les utilisateurs.

Côté coût, contrairement à une API commerciale facturée à l'usage, un LLM local a un coût principalement fixe : GPU ou serveur provisionné, consommation électrique, temps d'administration. Le suivi utile n'est donc pas le coût par requête, mais le taux d'utilisation de la capacité disponible au fil de la journée. Un microservice d'inférence dimensionné pour l'heure de pointe mais utilisé à 10 % le reste du temps invite à revoir soit le dimensionnement, soit la mutualisation avec d'autres produits métier.

Si plusieurs équipes métier construisent chacune leur assistant sur le même microservice d'inférence, il est efficace de mutualiser aussi le cadre de tests d'acceptation : un jeu de questions par produit, mais une seule chaîne d'exécution et un même format de rapport, pour que les résultats restent comparables dans le temps.

En résumé

L'intégration d'un LLM local à un produit métier se joue moins dans le choix du modèle que dans les décisions d'architecture qui l'entourent : où il vit par rapport à l'application, comment l'appeler sans s'enfermer dans un fournisseur d'inférence unique, et comment le produit continue de fonctionner — dégradé mais fonctionnel — quand le modèle n'est pas disponible. Le SDK compatible OpenAI réduit le couplage technique ; les patterns sidecar, microservice et file asynchrone couvrent des besoins de latence différents ; les outils MCP permettent au modèle d'agir sans jamais avoir un accès plus large que l'utilisateur qui l'invoque. Enfin, seuls des tests d'acceptation construits avec les équipes métier permettent de savoir si l'assistant rend réellement le service attendu, au-delà des chiffres de performance du modèle.