Intégration LLM

Cadrage du sujet

Ce que recouvre l’intégration d’un LLM dans un produit

Intégrer un LLM, c’est écrire tout ce qui entoure l’appel au modèle. L’appel lui-même tient en quelques lignes. Le travail réel porte sur la préparation de l’entrée, la contrainte de sortie, la vérification du résultat et la conduite à tenir quand ce résultat n’est pas exploitable.

Cette couche est votre produit. Le modèle est interchangeable, elle ne l’est pas : c’est elle qui porte le ton, le périmètre, le format et les règles métier. La mécanique d’appel (authentification, quotas, reprises) relève d’une autre page, API IA. Ici, l’appel est supposé fonctionnel et l’attention porte sur ce qu’il produit.

La couche applicative au-dessus de l’API : ce qu’il faut construire soi-même

Cette couche regroupe des composants identifiables : un gestionnaire de prompts versionnés, un constructeur de contexte, un validateur de sortie, un ensemble de garde-fous, un mécanisme de repli, et une couche d’observation qui enregistre entrées, sorties et incidents.

Aucun de ces composants n’est fourni par le fournisseur du modèle. Des bibliothèques accélèrent l’écriture, mais la logique métier reste à votre charge : vous seul décidez ce qu’est une réponse acceptable. Le raccordement à vos documents est un cas particulier de construction de contexte, traité sur RAG.

Prompt system, contexte et fenêtre de tokens : structurer l’entrée du modèle

Le prompt system est un actif du produit, pas une chaîne de caractères perdue dans le code. Il se stocke à part, se versionne, se relit et se teste comme un élément critique. Une modification de prompt change le comportement de la fonctionnalité pour tous les utilisateurs : elle mérite le même soin qu’une modification de code.

Un prompt system exploitable précise : le rôle et le périmètre, les règles métier applicables, le format exact attendu en sortie, la conduite à tenir quand l’information manque, et ce qui est explicitement interdit. Les instructions vagues produisent des sorties vagues.

Le contexte, lui, se construit à chaque appel : historique utile de la conversation, données du dossier en cours, extraits de documents pertinents. La fenêtre de contexte est limitée, et cette limite varie selon les modèles et les fournisseurs. Traitez-la comme une ressource rare : sélectionnez, résumez, tronquez selon une règle explicite qui ne supprime jamais les instructions.

Arbitrages produit

Coûts en production, latence et arbitrages de qualité

En production, la qualité, le coût et le temps de réponse se règlent ensemble : améliorer l’un dégrade souvent les autres. Décider à l’avance quel curseur prime pour chaque fonctionnalité évite les arbitrages précipités. Le tableau ci-dessous met en regard les stratégies courantes.

Stratégie	Ce qu’elle améliore	Ce qu’elle coûte	Limite à surveiller
Router les demandes simples vers un modèle léger	Coût et temps de réponse sur le volume courant	Une règle de routage à maintenir et à évaluer	Un mauvais routage envoie un cas difficile au modèle le moins adapté sans que personne ne le voie
Réduire le contexte transmis à chaque appel	Coût d’entrée et attente perçue	Une sélection fine des passages utiles	La sélection devient un point de défaillance : ce qu’elle écarte, le modèle ne l’a jamais vu
Imposer un format structuré et valider la sortie	Fiabilité du traitement en aval	Un schéma à maintenir et des reprises en cas d’échec	Chaque reprise consomme un appel supplémentaire : plafonnez les tentatives
Diffuser la réponse au fil de sa production	Attente perçue par l’utilisateur	Une interface capable d’afficher un flux	La validation de format n’intervient qu’à la fin : prévoyez le retrait d’une réponse déjà affichée

Ces arbitrages n’ont de sens que si vous les mesurez. Enregistrez pour chaque appel la version de prompt, le modèle, le volume consommé, la durée et le verdict de validation. Ce journal transforme une intuition en décision.

Exemples concrets

Cas d’usage

• Ajouter un assistant de rédaction contextuel dans l’éditeur d’un SaaS existant
• Transformer une recherche par mots-clés en réponse rédigée et sourcée dans un back-office
• Pré-remplir des formulaires métier à partir d’un document déposé par l’utilisateur
• Reformuler et traduire automatiquement les fiches d’un catalogue avant validation humaine

Vos questions

Questions fréquentes

Faut-il faire du fine-tuning ou suffit-il d’un bon prompt system ?

Commencez par le prompt. Souvent, un prompt system précis, un contexte bien construit et une sortie contrainte suffisent. Le fine-tuning répond à un autre besoin : reproduire un style ou un format très spécifique de façon stable, ou raccourcir les instructions sur un volume d’appels important.

Le fine-tuning a un coût caché : il fige une version du modèle, demande un corpus d’exemples de qualité, et doit être refait quand le fournisseur fait évoluer son offre. Épuisez d’abord le prompt, le contexte et l’injection de documents.

Comment empêcher le modèle de répondre hors de son périmètre ?

Par une combinaison, jamais par une seule instruction. Le prompt system énonce le périmètre et la formule de refus à utiliser. Un contrôle en entrée écarte les demandes manifestement hors sujet. Un contrôle en sortie vérifie que la réponse s’appuie sur le contexte fourni et non sur les connaissances générales du modèle.

Acceptez que l’étanchéité ne soit pas totale. La question opérationnelle n’est pas d’empêcher toute sortie de périmètre, mais de la rendre visible et sans conséquence : journalisation des cas litigieux, réponse de repli plutôt qu’improvisation, recours humain proposé dans l’interface.

Comment tester une fonctionnalité dont les réponses ne sont jamais identiques ?

En testant des propriétés, pas des chaînes. Vérifiez que la sortie respecte le schéma, qu’elle contient les champs attendus, qu’elle s’appuie sur une source présente dans le contexte, qu’elle refuse quand elle doit refuser. Ces contrôles sont automatisables et se rejouent à volonté.

Complétez par une revue humaine sur un échantillon stable, avec une grille de notation écrite. Le but n’est pas la note absolue, mais la comparaison de deux versions dans les mêmes conditions. Une évaluation qui ne le permet pas ne vous apprend rien.

Que se passe-t-il quand le fournisseur met à jour ou retire un modèle ?

Le comportement de votre fonctionnalité change, parfois sans que rien n’ait bougé chez vous. C’est le risque structurel de l’intégration LLM, et il se traite par la préparation : identifiant de modèle en configuration, prompts hors du code, corpus prêt à être rejoué.

Quand l’annonce arrive, la démarche devient mécanique : rejouer le corpus sur le nouveau modèle, comparer avec la version en place, ajuster le prompt si nécessaire, puis basculer sur une part restreinte du trafic avant de généraliser. Sans corpus, la même opération se fait à l’aveugle.