Passer d’un prototype LLM à la production : critères de go/no-go

Un prototype LLM peut démontrer qu’une interaction est possible. Il ne démontre pas encore que le système peut être déployé pour un périmètre métier réel. Une décision de go/no-go utile repose sur des preuves écrites : cas d’usage, données et droits, évaluation représentative, comportement attendu en cas d’écart, conditions d’exploitation et responsable de la décision.

En bref

Décidez sur un cas d’usage, des utilisateurs et un niveau de risque définis, pas sur une démonstration générale.
Évaluez la version candidate sur des tâches et des cas de refus représentatifs avant d’élargir le périmètre.
NIST recommande d’établir des seuils de performance ou d’assurance et une revue dans les processus de décision de déploiement. Ces seuils doivent être adaptés au contexte, pas copiés d’un autre projet.
Un no-go ou un périmètre réduit peut être une conclusion de cadrage valable lorsqu’une preuve nécessaire manque.

Cette grille aide une équipe à préparer une décision technique et métier. Elle ne remplace pas l’analyse de sécurité, de conformité, de protection des données ou les validations propres à l’organisation.

Pourquoi une démonstration réussie ne suffit-elle pas ?

Une démonstration montre généralement quelques entrées choisies, avec un corpus, des droits et une charge limités. La production introduit des questions supplémentaires : qui utilise le système, quelles sources il peut consulter, ce qui est acceptable quand il ne sait pas répondre, comment un changement est évalué et qui intervient lors d’une dégradation.

Le profil du NIST consacré à l’IA générative propose d’établir des seuils minimaux de performance ou d’assurance et de les revoir dans les politiques et processus d’approbation du déploiement. Il ne fournit pas un seuil universel ni une certification. Le niveau attendu dépend notamment de la tâche, des personnes concernées et des conséquences d’une réponse incorrecte.

La question de passage devient donc : « disposons-nous de preuves suffisantes pour ouvrir ce système à ce périmètre, avec ces limites et ces responsables ? » Elle est plus exigeante que : « le prototype a-t-il donné une bonne réponse ? »

Quel périmètre la décision doit-elle couvrir ?

Une décision de production doit nommer le périmètre plutôt que promettre une capacité générale. Commencez par documenter les éléments suivants :

Élément	Question à trancher	Preuve à préparer
Tâche métier	Quelle décision, recherche ou action le système doit-il aider à réaliser ?	Scénarios concrets et comportement attendu
Utilisateurs	Quels rôles peuvent utiliser le système ?	Règles d’identité et d’autorisation testables
Données et outils	Quelles sources ou opérations entrent dans la première version ?	Inventaire, propriétaires, exclusions et cycle de mise à jour
Limites	Que doit faire le système hors périmètre ou sans source suffisante ?	Cas de refus, message attendu et chemin d’escalade
Niveau de risque	Quelles erreurs sont inacceptables ou exigent une revue humaine ?	Critères de décision validés par les responsables concernés

Ce travail évite de confondre une capacité de modèle avec une autorisation de l’utiliser dans n’importe quel processus. Pour un système documentaire, notre guide sur le cadrage d’un projet RAG d’entreprise détaille la façon de relier un cas d’usage, un corpus, des droits et une décision de prototype.

Quelles preuves faut-il réunir avant un go ?

Un dossier de décision n’a pas besoin d’être long. Il doit être lisible et permettre de retrouver la preuve derrière chaque conclusion. Six catégories sont généralement nécessaires.

Une intention métier vérifiable. Décrivez la tâche, les utilisateurs et ce qui rendrait le résultat utile ou inutilisable.
Un périmètre de données et de droits. Listez les sources, leurs propriétaires, les exclusions et les contrôles qui doivent rester appliqués.
Un jeu d’évaluation représentatif. Préparez des cas normaux, ambigus, hors périmètre et interdits avant de comparer les versions.
Des résultats interprétables. Conservez les sorties, les règles de notation, les versions testées et les écarts qui nécessitent une décision.
Un plan d’exploitation. Précisez les traces utiles, la surveillance, les alertes, le traitement d’incident et la possibilité de limiter ou de revenir en arrière.
Une décision attribuée. Nommez la personne ou l’instance qui accepte le périmètre et les risques ouverts, avec les conditions de révision.

Cette liste est une synthèse de travail, pas une nouvelle norme. Elle rend opérationnels les sujets de gouvernance, de cartographie, de mesure et de gestion des risques décrits par le NIST.

Comment construire une évaluation qui peut réellement conduire à un no-go ?

Un test ne réduit le risque que s’il peut invalider une hypothèse. Construisez le jeu d’évaluation à partir de tâches métier réelles ou relues par les personnes qui connaissent le domaine. Ajoutez les cas qui dérangent la démonstration : demande ambiguë, source obsolète, donnée contradictoire, utilisateur sans droit, instruction hostile dans un document ou appel d’outil qui dépasse le scénario prévu.

Pour chaque cas, enregistrez la demande, le rôle utilisé, les sources ou actions autorisées, le comportement attendu et la règle de revue. La documentation Microsoft Foundry sur l’observabilité décrit l’évaluation de préproduction comme une étape qui teste notamment les cas limites, la robustesse, l’adhérence à la tâche, l’ancrage, la pertinence et la sécurité avant le déploiement.

Pour un RAG, il est utile de séparer la récupération documentaire, la réponse générée, les droits, la latence et le coût. Notre méthode pour évaluer un RAG en production explique pourquoi une bonne réponse isolée ne permet pas de diagnostiquer un système complet.

Quels critères de go/no-go faut-il écrire ?

Les critères doivent répondre à des questions observables. Ils ne doivent pas reprendre des pourcentages génériques trouvés dans un benchmark. Un tableau de décision peut prendre cette forme :

Domaine	Critère de décision à adapter	Décision si la preuve manque
Utilité	Les tâches prioritaires ont été testées avec une règle de revue comprise par le métier.	Réduire le périmètre ou compléter le jeu de tests.
Données et accès	Les sources, exclusions et refus attendus sont connus et vérifiables.	Bloquer l’ouverture aux rôles ou sources non couverts.
Qualité et sûreté	Les cas critiques ont une réponse attendue, une trace et un responsable de revue.	Corriger, ajouter un contrôle ou maintenir le cas hors périmètre.
Exploitation	L’équipe peut observer les erreurs utiles, limiter le système et investiguer un écart.	Préparer l’exploitation avant d’élargir l’accès.
Évolution	Une modification de modèle, de prompt, d’index ou d’outil peut être comparée à une référence.	Conserver la version de référence et organiser une nouvelle évaluation.

Un go peut être conditionnel : ouvrir un groupe d’utilisateurs défini, limiter les données ou désactiver une action à impact. Un no-go n’est pas nécessairement l’abandon du cas d’usage. Il peut conclure qu’un contrôle, une donnée, une règle d’accès ou un mécanisme d’exploitation doit être traité avant la prochaine évaluation.

Comment préparer l’exploitation avant l’ouverture ?

La production ne commence pas avec un tableau de bord. L’équipe doit savoir quelle information elle conservera pour comprendre une réponse ou une action : version du système, entrée et sortie dans le respect des règles de données, sources ou outils utilisés, décisions de contrôle, durée et résultat de l’exécution.

Microsoft décrit le monitoring de production comme un suivi de métriques opérationnelles, d’évaluations continues sur un échantillon du trafic, d’évaluations planifiées sur des jeux de tests et d’alertes lorsque des seuils de qualité ou de sécurité ne sont pas atteints. Le choix des métriques et des données de trace reste propre au contexte. Il doit respecter les règles de confidentialité et éviter de transformer l’observabilité en copie non maîtrisée de données métier. Notre méthode pour mesurer le coût d’un système LLM détaille les unités à relier à chaque parcours avant de comparer des versions.

Pour les agents qui appellent des outils, l’exploitation doit aussi permettre de retrouver l’opération proposée, le contrôle appliqué, la décision humaine éventuelle et le résultat. Notre article sur les validations humaines avant les actions d’un agent IA traite ce point de contrôle par type d’action. Le guide sur la traçabilité d’un agent IA explique comment relier ces événements à une même exécution.

Qui doit prendre la décision finale ?

La personne qui valide la mise en production doit pouvoir lire les preuves et connaître les limites acceptées. Selon le cas, la décision peut associer un propriétaire métier, un responsable technique, la sécurité, la protection des données, l’exploitation ou le responsable de l’outil connecté. Il ne s’agit pas de faire valider chaque détail par tous les rôles, mais d’éviter qu’une contrainte connue reste sans propriétaire.

Documentez au minimum :

le périmètre autorisé et les exclusions ;
les critères utilisés et les résultats observés ;
les risques ouverts explicitement acceptés ou reportés ;
le responsable de la surveillance et de la réponse en cas d’écart ;
la date ou l’événement qui déclenchera une révision de la décision.

Ce dossier permet de distinguer une décision de déploiement d’une impression favorable après une démonstration. Il rend aussi un retour arrière ou une réduction de périmètre plus simple à expliquer. Pour traduire cette capacité en procédure d'exploitation, définissez les conditions de suspension, de retour arrière et d'escalade d'un système GenAI avant l'ouverture.

Une décision de go reste incomplète si l’équipe qui doit exploiter le système ne peut pas appliquer les procédures, préparer un changement ou réduire le périmètre. Notre guide sur le transfert d’un système GenAI aux équipes internes propose un exercice de reprise et un dossier de transfert pour vérifier cette capacité avant la livraison.

FAQ

Un prototype LLM réussi est-il prêt pour la production ?

Non. Il peut démontrer une capacité technique, mais la production exige aussi un périmètre défini, des évaluations représentatives, des contrôles d’accès ou d’action, des conditions d’exploitation et une décision attribuée.

Quels seuils utiliser pour un go/no-go d’un système LLM ?

Il n’existe pas de seuil universel. Les critères doivent être fixés selon la tâche, les utilisateurs, le risque accepté et les conséquences d’un écart. Ils doivent être écrits avant la décision et associés à une preuve vérifiable.

Un no-go signifie-t-il qu’il faut abandonner le cas d’usage ?

Pas nécessairement. Un no-go peut conduire à réduire le périmètre, compléter le jeu de tests, traiter une règle d’accès ou préparer l’exploitation avant une nouvelle évaluation. La décision doit préciser ce qui manque et qui en est responsable.

Faut-il réévaluer un système après un changement de modèle ou de données ?

Oui. Un changement de modèle, de prompt, de corpus, d’index ou d’outil peut modifier le comportement du système. Comparez la version candidate à une référence sur les cas pertinents et consignez la décision avant d’élargir le changement.

Méthodologie et sources

NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, publié le 26 juillet 2024, consulté le 13 septembre 2026. Le profil présente notamment l’établissement de seuils de performance ou d’assurance et leur revue dans les processus d’approbation de déploiement.
Microsoft Foundry, Observability in Generative AI, consulté le 13 septembre 2026. La documentation décrit l’évaluation de préproduction et le monitoring après déploiement des applications et agents d’IA générative.
Microsoft Azure Architecture Center, Generative AI Operations for Organizations with MLOps Investments, consulté le 13 septembre 2026. Ce guide présente les boucles d’évaluation, de déploiement, d’inférence, de monitoring et de retour pour les systèmes GenAI.

La méthode proposée est une grille de décision pour des équipes qui préparent un système GenAI d’entreprise. Elle ne contient ni résultat client, ni prix, ni délai, ni promesse de sécurité, de conformité ou de performance. Les critères et responsabilités doivent être validés pour chaque organisation.

Vous devez transformer un prototype LLM en décision de déploiement défendable ? Décrivez votre périmètre à IgnitionAI. Un premier échange peut aider à identifier les preuves, contrôles et responsabilités à documenter avant une ouverture en production.