Avant de toucher au code : les décisions qui conditionnent tout
Intégrer un modèle de langage dans un site web ne commence pas par l’installation d’un SDK. Cela commence par répondre à trois questions qui déterminent le reste de la checklist : quelle tâche concrète le LLM résout, où l’inférence s’exécute et qui assume le coût par token. Si vous n’avez pas de réponse ferme pour les trois, toute intégration finira par être un prototype coûteux que personne ne maintient.
Cette liste de vérification est ordonnée par phases réelles de projet. Ce n’est pas un guide théorique : chaque point inclut la raison pour laquelle il existe et l’erreur typique qu’il permet d’éviter. Certains points ne s’appliquent pas à tous les cas et je l’indique explicitement.
Phase 1. Définition du cas d’usage (ne sautez pas cette partie)
1.1. Écrivez la tâche en une phrase vérifiable
« Améliorer l’expérience utilisateur » n’est pas une tâche. « Classer les tickets de support entrants en cinq catégories avec une étiquette de confiance » en est une. Si vous ne pouvez pas mesurer si la réponse du modèle est correcte, vous ne pouvez pas l’intégrer avec des garanties.
1.2. Vérifiez si un LLM est réellement nécessaire
Beaucoup de tâches attribuées aux LLMs se résolvent avec des règles, des expressions régulières ou un classifieur classique moins cher et déterministe. Un LLM brille dans le langage libre, l’ambiguïté et la génération ; il échoue dans les calculs exacts, la logique stricte et les données qui changent chaque minute. Si votre cas est « extraire un montant d’une facture au format fixe », vous n’avez probablement pas besoin d’un modèle génératif.
1.3. Définissez le coût maximal acceptable par interaction
Les prix par million de tokens varient beaucoup entre fournisseurs et entre modèles d’une même famille. Avant d’intégrer, calculez : longueur moyenne du prompt + longueur moyenne de la réponse × volume quotidien estimé. Un chatbot qui reçoit 3 000 requêtes par jour avec des prompts de 2 000 tokens peut coûter plus que l’hébergement annuel du site. Ayez ce chiffre avant d’écrire la première ligne.
Phase 2. Architecture et sécurité
2.1. La clé d’API ne voyage jamais vers le navigateur
C’est l’erreur la plus courante et la plus coûteuse. Tout appel depuis le JavaScript du client expose la clé dans les outils de développement. L’appel au fournisseur doit partir de votre serveur ou d’une fonction edge. Si vous avez besoin de streaming vers le navigateur, utilisez un proxy sur votre backend qui relaie les chunks.
2.2. Choisissez entre API externe et modèle auto-hébergé
API externe : rapide à implémenter, sans infrastructure, mais vous dépendez de la disponibilité et des prix du fournisseur, et les données sortent de votre environnement. Modèle auto-hébergé (par exemple, des poids ouverts servis avec des outils d’inférence locaux) : contrôle total et coût fixe, mais exige un GPU, de la maintenance et du savoir-faire. Pour des sites web petits ou moyens, l’API est généralement la décision sensée ; pour des données sensibles avec des exigences strictes de résidence, l’auto-hébergement peut être obligatoire.
2.3. Filtrez et minimisez les données que vous envoyez
Avant d’envoyer un prompt, supprimez les identifiants personnels, les courriels et les données de paiement dont le modèle n’a pas besoin. Ce n’est pas seulement une question de conformité réglementaire : cela réduit les tokens et améliore la qualité de la réponse en éliminant le bruit.
2.4. Protection contre l’injection de prompt
Si le LLM traite du contenu que l’utilisateur contrôle (commentaires, descriptions de produit, textes collés), partez du principe que ce contenu peut contenir des instructions malveillantes. Atténuations pratiques : séparez les instructions du système et le contenu de l’utilisateur avec des délimiteurs clairs, validez la sortie contre un schéma, et ne laissez jamais la sortie du modèle déclencher des actions destructrices sans confirmation humaine.
Phase 3. Conception du prompt et de la sortie
3.1. Instruction système stable et versionnée
Conservez le prompt système dans un fichier avec un contrôle de version. Lorsque vous changez un mot, vous pourrez comparer les résultats. Les prompts qui vivent dans le code mélangés à la logique métier sont impossibles à auditer.
3.2. Sortie structurée chaque fois que possible
Si le résultat alimente une base de données ou une interface, demandez du JSON avec un schéma défini et validez la réponse avec un parseur strict. Si le modèle renvoie du texte libre et que vous faites un split par virgules, vous casserez dès que le modèle changera de format. La plupart des fournisseurs actuels proposent des modes de sortie structurée ; utilisez-les.
3.3. Incluez des exemples dans le prompt (few-shot)
Deux ou trois exemples d’entrée-sortie correcte améliorent souvent davantage le résultat que des paragraphes d’instructions. Ils coûtent des tokens, alors réservez-les aux tâches où le format importe.
3.4. Définissez le comportement en cas de doute
Indiquez explicitement ce que le modèle doit faire lorsqu’il ne sait pas : renvoyer un champ confiance : basse, une phrase concrète de dérivation vers un humain, ou une réponse vide que votre interface interprète. Sans cette instruction, le modèle inventera avec une totale assurance.
Phase 4. Intégration dans le frontend
4.1. États de chargement et annulation
Les réponses génératives prennent des secondes. L’interface a besoin d’un état d’attente visible et d’un bouton d’annulation qui abandonne la requête. Si vous utilisez le streaming, affichez le texte au fur et à mesure qu’il arrive : cela réduit notablement la perception de lenteur.
4.2. Accessibilité du composant
Le conteneur de réponses doit avoir aria-live=»polite» pour que les lecteurs d’écran annoncent le nouveau texte. Le streaming sans gestion de l’accessibilité génère des expériences cassées pour les utilisateurs de lecteurs d’écran.
4.3. Limites côté client et côté serveur
Limitez la longueur d’entrée des deux côtés. Un champ de texte sans limite est une voie directe vers des prompts gigantesques qui gonflent votre facture. Ajoutez également une limite de requêtes par session ou par IP.
Phase 5. Qualité, évaluation et surveillance
5.1. Ensemble de tests avec réponses attendues
Avant de publier, réunissez entre 30 et 100 cas représentatifs avec la réponse correcte annotée à la main. Exécutez le prompt contre eux chaque fois que vous le modifiez. Sans ce banc d’essai, chaque changement est un pari.
5.2. Journalisation des requêtes et des réponses (avec précaution)
Conservez le prompt, la réponse et la latence pour pouvoir déboguer. Anonymisez avant de stocker et définissez une période de rétention. Un log sans politique de rétention devient un passif.
5.3. Alertes de coût et de latence
Configurez un seuil de dépense quotidien qui vous alerte avant que la facture ne devienne incontrôlable. Une boucle infinie côté client ou un bot qui répète des requêtes peuvent multiplier la consommation en quelques heures.
Phase 6. SEO et visibilité
6.1. Le contenu généré ne s’indexe pas par magie
Si le LLM génère des pages ou des fragments que vous voulez positionner, ils ont besoin d’une URL propre, d’un titre, d’une méta description et d’un rendu côté serveur. Un widget qui génère du texte dans un div après une interaction de l’utilisateur n’apporte rien au crawl.
6.2. Ne générez pas de contenu massif sans révision
Les politiques de qualité des moteurs de recherche découragent le contenu produit à grande échelle sans valeur ajoutée. Si vous utilisez le LLM pour rédiger, utilisez-le comme brouillon avec révision éditoriale. Selon la documentation officielle des principaux moteurs de recherche, le critère reste l’utilité pour l’utilisateur, pas la méthode de production.
6.3. Bloquez ou marquez les routes internes de l’assistant
Les endpoints de votre API et les routes de génération ne doivent être ni explorables ni indexables. Ajoutez noindex et des restrictions dans robots.txt là où cela s’applique.
Phase 7. Lancement et maintenance
7.1. Déploiement progressif
Activez la fonction pour un pourcentage d’utilisateurs d’abord. Mesurez le taux d’erreur, la latence et la satisfaction avant de l’ouvrir à tout le trafic.
7.2. Plan de dégradation
Que se passe-t-il si le fournisseur renvoie des erreurs 429 ou 500 ? Définissez une réponse de secours : message d’indisponibilité, formulaire de contact ou réponse mise en cache. Un assistant qui casse la page lorsque l’API échoue est pire que pas d’assistant du tout.
7.3. Révision périodique du modèle
Les fournisseurs retirent des versions de modèles avec des préavis. Notez la date de dépréciation de la version que vous utilisez et testez la migration avant qu’elle ne soit forcée. Les prompts affinés pour une version peuvent se comporter différemment sur la suivante.
Un cas concret et sa leçon
Dans un projet d’assistant pour une boutique de composants, l’équipe a testé le prompt avec des questions de catalogue et cela fonctionnait bien. Au moment de la publication, les utilisateurs ont commencé à poser des questions sur les compatibilités entre pièces. Le modèle répondait avec assurance sur des combinaisons qui n’existaient pas dans le catalogue. La cause : le prompt incluait un échantillon de produits, pas le catalogue complet, et le modèle comblait les lacunes avec plausibilité. La solution n’a pas été un meilleur prompt, mais de récupérer les produits pertinents de la base de données et de les passer comme contexte à chaque requête. Leçon : si la réponse dépend de données qui changent, le modèle a besoin d’accéder à ces données au moment de la requête, pas d’un échantillon statique dans le prompt.
Ce que cette checklist ne résout pas
Il n’y a aucune garantie que le modèle réponde correctement à tout. Les LLMs hallucinent, et aucune configuration n’élimine complètement ce comportement. Il n’existe pas non plus de prompt parfait : ce qui fonctionne aujourd’hui peut se dégrader avec la prochaine mise à jour du fournisseur. Et il y a des tâches où un LLM n’est pas l’outil adéquat : recherches exactes, calculs financiers, filtres déterministes. Le reconnaître à temps économise budget et frustration.
Si vous parcourez ces phases dans l’ordre et consignez par écrit les décisions de chacune, vous aurez quelque chose de plus précieux qu’une intégration qui fonctionne : vous aurez une intégration que vous pouvez maintenir lorsque le modèle, le fournisseur ou l’équipe changeront.