Le développement d’applications LLM conçoit un produit où un modèle interprète, recherche, transforme ou génère des informations dans des limites métier, sécurité et exploitation explicites. Le produit comprend données, workflows, interfaces, évaluations, autorisation et contrôles d’exécution, pas seulement le modèle ou le prompt.
Un prototype paraît impressionnant parce qu’une personne choisit des exemples propres, répare le contexte et tolère les erreurs. La production reçoit demandes ambiguës, documents malveillants, preuves absentes, instructions contradictoires, longs contenus, utilisateurs simultanés, changements de modèle et dépendances indisponibles. Si l’équipe ne peut définir le comportement correct, rejouer une panne ou limiter un outil, davantage de prompt engineering ne rendra pas l’application fiable.
Commencez par une décision utilisateur délimitée et un contrat d’acceptation observable. Entourez l’inférence probabiliste de logiciel déterministe. Le modèle propose classifications, réponses ou plans; le code impose identité, autorisation, périmètre des données, schémas, transitions, limites d’action et libération. Évaluez le système complet avant lancement et après changement. La flexibilité n’a de valeur que si l’échec est visible, contenu et récupérable.
Périmètre produit
Définissez la décision avant l’interaction avec le modèle
« Construire un chatbot » n’est pas un contrat produit. Un périmètre utile indique qui accomplit quoi, avec quelles matières, quel résultat et quelle suite. Résumer une politique pour explorer diffère d’une décision de conformité. Rédiger un courriel diffère de l’envoyer. Une même capacité du modèle exige donc des contrôles très différents selon la conséquence.
Rédigez les exemples d’acceptation dans la langue du produit. Un assistant probant doit citer chaque affirmation matérielle depuis une source accessible et montrer les contradictions. Une extraction exige schéma canonique, provenance et état inconnu autorisé. Ajoutez les refus obligatoires. Le modèle reste ainsi subordonné à la valeur utilisateur et produit, ingénierie, sécurité et opérations testent le même objet.
- Nommer utilisateur, décision, entrée, sortie et système suivant.
- Séparer suggestion générée et action autorisée.
- Spécifier inconnu, conflit et escalade.
- Créer des portes distinctes pour les actions irréversibles.
- Relier chaque promesse de lancement à une évaluation.
Système qualité
Le corpus d’évaluation fait partie du produit
Les benchmarks de modèles disent peu sur votre workflow. Construisez un corpus depuis les distributions attendues. Les demandes ordinaires empêchent l’optimisation des seuls cas spectaculaires. Les exemples difficiles exposent qualité documentaire, ambiguïté, contexte long, terminologie multilingue, sources absentes et instructions dangereuses. Étiquetez les propriétés utiles plutôt qu’une note globale vague.
Évaluez composants et parcours. Les mesures de retrieval montrent la disponibilité des preuves, celles de génération le soutien, les simulations d’outils l’autorisation, et la revue finale l’accomplissement utilisateur. Enregistrez versions du modèle, prompt, index, outil et politique. Reproduisez chaque incident, corrigez le contrôle et ajoutez un cas de régression minimal.
| Couche | Question | Mesure |
|---|---|---|
| Retrieval | La preuve utile a-t-elle été trouvée? | Rappel et pertinence autorisée |
| Génération | La sortie est-elle prouvée et complète? | Soutien et rubrique |
| Structure | Le logiciel peut-il la consommer? | Schéma et invariants |
| Action | L’opération proposée est-elle permise? | Autorisation et arguments |
| Résultat | L’utilisateur termine-t-il la tâche? | Succès, correction, escalade |
Sécurité
Les instructions influencent le modèle, elles ne font pas loi
OWASP classe l’injection de prompt comme risque central et précise que le retrieval ou le fine-tuning ne la supprime pas. Tout texte lu peut contenir des instructions concurrentes, y compris un document d’un référentiel fiable. Délimiteurs et prompts réduisent la confusion mais ne constituent pas une autorisation. L’application suppose que le modèle peut proposer une action hors politique.
Les couches déterministes imposent les limites. Filtrez le retrieval selon l’utilisateur authentifié. Validez la sortie avant affichage ou exécution. Liez les outils à des identités serveur étroites et revérifiez chaque appel. Aucun secret dans les prompts. Séparez proposition et exécution et exigez une confirmation humaine pour les effets matériels. Testez attaques directes et instructions cachées dans documents, images et résultats.
- Traiter contenus chargés et retrouvés comme non fiables.
- Résoudre identité et autorisation hors du modèle.
- Donner des droits minimaux et propres à la tâche.
- Valider arguments et résultats à chaque frontière.
- Garder une porte humaine pour les actions conséquentes.
Exploitation
Concevez pour le changement, la panne partielle et le rejeu
L’application dépend des modèles, index, stockages, politiques et outils. Chacun peut ralentir, échouer ou changer de forme. Définissez délais, relances bornées, idempotence et solutions de repli par opération. Un résumé en lecture seule se relance souvent; un paiement ou message jamais aveuglément. Retournez un état en attente ou échoué au lieu de laisser le modèle raconter un succès non confirmé.
L’observabilité reconstruit le comportement sans devenir un lac de données incontrôlé. Capturez versions, temps, jetons, références, validations, état des outils et résultat. Minimisez ou expurgez le sensible selon le besoin de diagnostic. Les canaries comparent qualité, latence et coût. Une équipe fiable sait quelle version a produit le résultat, pourquoi ces sources et si l’action externe a réellement eu lieu.
- Versionner prompts, modèles, index, schémas, outils et politiques.
- Rendre les effets idempotents et confirmés séparément.
- Distinguer fin du modèle et fin métier.
- Fixer budget de latence et coût par résultat réussi.
- Conserver retour arrière et rejeu pour chaque version.
Ce qui caractérise un bon résultat
Résultats concrets pour développement d’applications LLM
- La première version résout une tâche nommée pour un utilisateur nommé avec non-objectifs et escalades.
- Un jeu d’évaluation versionné représente les cas courants, difficiles, ambigus, multilingues et adversariaux.
- Le contexte retrouvé porte identité de source, droit d’accès, fraîcheur et citation.
- Les sorties structurées sont validées avant base de données, interface ou système aval.
- Les outils utilisent le moindre privilège, une autorisation serveur, des paramètres bornés et une approbation humaine pour les actions matérielles.
- Les traces relient entrée, contexte, prompt, modèle, sortie, validation, outil et résultat sans collecter inutilement le sensible.
- L’équipe compare modèle, prompt ou retrieval sur qualité, latence, coût et risque avant déploiement.
- L’utilisateur reçoit une abstention utile ou un transfert si preuve, confiance ou dépendance est insuffisante.
Modèle opératoire
Comment exécuter le travail
- 01
Définir la tâche et le contrat d’acceptation
Décrivez utilisateur, déclencheur, entrée, sortie, décision suivante et coût de l’erreur. Listez non-objectifs, actions interdites et cas nécessitant une personne. Transformez le comportement souhaité en exemples et critères mesurables avant l’architecture.
- 02
Créer d’abord le corpus d’évaluation
Rassemblez des cas représentatifs couvrant trafic normal, bords, mauvais documents, langues, preuves indisponibles et instructions hostiles. Étiquetez faits, citations, formats, décisions et abstentions. Versionnez le jeu et protégez un échantillon de réserve.
- 03
Concevoir contexte et frontières de confiance
Décidez ce qui provient de l’utilisateur, du système, du retrieval, de la mémoire et des outils. Traitez le texte externe comme donnée non fiable. Imposez l’accès avant retrieval, minimisez le contexte, marquez la provenance et séparez instructions et contenu. Définissez conservation et effacement.
- 04
Ingénier les sorties et actions
Utilisez des schémas contraints et validez types, plages, références et invariants. Résolvez l’autorisation dans le code. Donnez aux outils des droits étroits, idempotence et limites. Exigez une approbation avant envoi, achat, suppression, signature ou changement à fort impact.
- 05
Exploiter par versions mesurées
Effectuez évaluations hors ligne, tests de sécurité, charge et revue humaine avant un canary. Observez qualité, latence, coût, abstention, corrections et incidents par version. Gardez les cas rejouables, revenez en arrière et ajoutez les pannes réelles au corpus.
Évaluation
Les questions qui changent la décision
- La partie variable nécessite-t-elle un LLM ou des règles, la recherche ou un modèle classique seraient-ils plus fiables?
- Quel est le plus petit résultat utilisateur évalué indépendamment?
- Quelles sources entrent en contexte et comment imposer accès, fraîcheur et provenance?
- Quelles sorties conseillent, modifient un état ou requièrent une approbation responsable?
- Faut-il retrieval, fine-tuning, outils ou combinaison?
- Quelles contraintes de latence, disponibilité, coût et données déterminent le choix?
- Comment l’utilisateur inspecte, corrige, conteste ou inverse un résultat?
- Quelle preuve permet de promouvoir un nouveau modèle, prompt, index ou outil?
Modes d’échec
Où les équipes perdent le contrôle
Une réponse fluide peut être fausse, sans preuve ou mal alignée avec la décision.
L’injection directe ou indirecte agit par l’utilisateur, les fichiers, les pages ou les résultats d’outils.
Un retrieval sans filtre d’accès peut révéler un contenu interdit à la source.
Mettre secrets ou autorisation dans le prompt confond instruction et frontière de sécurité.
Une sortie non validée devient code, requête, balisage ou action avec un impact classique.
Un agent aux outils larges amplifie une petite erreur en action externe irréversible.
Une mise à jour de modèle ou fournisseur change le comportement sans modification du code.
L’observabilité peut collecter trop de prompts, documents et sorties sensibles.
La moyenne d’exactitude cache une panne grave dans une langue ou un cas à fort impact.
Contexte et relances sans limites créent latence et coût instables.
Mesure
Mesurer le travail terminé
La mesure porte sur le processus terminé, y compris la revue et les exceptions. Le volume produit ne prouve pas à lui seul que le processus est meilleur.
- réussite de tâche sur corpus versionné et réserve protégée
- soutien des affirmations et correction des citations lorsque requis
- taux d’erreur critique par cas, langue et catégorie de risque
- abstention et escalade appropriées face au manque ou à l’ambiguïté
- échecs de schéma et réponses structurées réparées
- appels d’outils non autorisés ou trop larges bloqués avant exécution
- corrections, remplacements et résultats rouverts par les utilisateurs
- latence de bout en bout par percentile et parcours réussi
- coût modèle, retrieval, stockage et traces par résultat
- régressions détectées avant déploiement et délai de retour sûr
Questions
Questions fréquentes
Que comprend le développement d’une application LLM?
Il comprend périmètre produit, données, contexte, intégration du modèle, retrieval, évaluation, interface, sorties structurées, sécurité, autorisation des outils, observabilité, déploiement et exploitation. Le prompt est un composant versionné.
Faut-il utiliser RAG ou le fine-tuning?
Le retrieval convient au savoir actuel, attribuable et filtré par accès. Le fine-tuning peut façonner le comportement ou des motifs récurrents. Aucun ne résout seul autorisation, injection, soutien factuel ou évaluation, et certaines tâches n’en ont pas besoin.
Comment tester une application LLM?
Créez un corpus représentatif versionné avec faits, sources, formats, actions et abstentions. Testez retrieval, génération, schémas, outils et résultat séparément puis ensemble, avec des cas multilingues, ambigus et adversariaux.
Une application LLM peut-elle agir de façon autonome?
Elle peut proposer et effectuer des actions bornées, mais l’autorisation appartient au code. Utilisez droits minimaux, paramètres validés, idempotence, audit et approbation humaine explicite pour les actions conséquentes ou externes.
Sources
Sources primaires
- Ressources du cadre de gestion des risques IA National Institute of Standards and Technology
- LLM01:2025, injection de prompt OWASP GenAI Security Project
- Guide de prévention de l’injection de prompt OWASP Foundation
À propos de l’auteur
Tony Kim
Tony écrit sur l’IA appliquée, l’ingénierie produit fiable et les systèmes qui transforment les réponses complexes en exécution maîtrisée.
Zeke
Ingénierie de produits IA pour transformer un cahier des charges en produit fiable en production.
Directions produit, fondateurs et équipes d’ingénierie. Le point de départ est le processus existant, ses contraintes et les preuves déjà disponibles.
Découvrir Zeke→