Un prototype permet de décider si une idée mérite d'être poursuivie. La production pose une autre question : les utilisateurs peuvent-ils dépendre du système défini dans les conditions convenues ?
La différence ne se réduit pas au niveau de finition de l'interface. Elle concerne les responsabilités autour du résultat.
Les entrées ne sont plus choisies pour la démonstration
Un prototype utilise souvent quelques exemples connus. Les utilisateurs apportent des demandes incomplètes, des fichiers nouveaux, des contradictions et des volumes inattendus.
Documenter les entrées prises en charge et tester les exceptions importantes. Un périmètre de production peut être étroit ; il ne doit pas laisser croire qu'il couvre tous les cas.
Les permissions font partie de la qualité
Une réponse exacte montrée à la mauvaise personne reste inacceptable. Vérifier recherche, stockage, exports et actions selon l'utilisateur et l'organisation réels.
Ne pas confier les permissions à une simple instruction au modèle lorsque l'application peut empêcher l'accès avant transmission des données.
Les échecs demandent des états utiles
Que se passe-t-il si un fournisseur ne répond plus après le démarrage ? L'utilisateur comprend-il la situation ? Une relance peut-elle dupliquer une fiche ou une action ? L'exception arrive-t-elle à un responsable ?
Définir, selon le processus, les états en attente, en cours, à vérifier, approuvé, terminé et échoué. Conserver les éléments nécessaires à l'analyse sans enregistrer indistinctement du contenu sensible.
L'évaluation devient récurrente
Créer et versionner des exemples avec leurs attentes. Enregistrer la configuration de chaque évaluation. Inclure les échecs importants, pas seulement les questions auxquelles le modèle répond habituellement bien.
Après une modification de modèle, de prompt, de corpus ou d'intégration, rejouer les contrôles concernés. L'acceptation d'une ancienne version n'approuve pas automatiquement le nouveau comportement.
Le coût concerne tout le processus
Mesurer les étapes réelles, y compris relances, traitement documentaire et revue humaine. Définir les limites d'usage et la procédure lorsqu'elles sont atteintes.
Préciser qui paie les frais variables et qui examine une consommation inhabituelle.
Un responsable doit piloter la mise en production
Nommer les responsables du déploiement, des incidents, des accès et des évolutions. Définir la désactivation ou le retour arrière.
Fournir les instructions, dépendances, tests et procédures à l'équipe destinataire. Un transfert réussi comprend sa capacité à les utiliser, pas seulement l'envoi de liens.
L'acceptation peut être conditionnelle
La bonne décision peut être un groupe restreint, une seule famille documentaire, des brouillons sans envoi ou une validation obligatoire. Ces limites doivent être explicites et observables.
La revue précise ce qui a été testé, ce qui reste inconnu et les conditions à maintenir. Elle ne transforme pas « des tests ont été exécutés » en garantie générale.
Parler de préparation à la production · Service d'évaluation