Remplacer un modèle d’IA et le tester sur le même parcours

Lors d’un changement de modèle, examinez tout le parcours applicatif concerné. Un nouvel identifiant de modèle dans la configuration ne constitue pas une preuve suffisante. Utilisez un jeu d’évaluation existant et consignez le changement réellement comparé.

Consigner clairement les deux configurations

Documentez, pour chaque variante, l’identifiant du modèle, la version du prompt, les sources fournies, les outils et les paramètres. Si entrées, règles et traitement restent identiques, vous pourrez examiner plus précisément le changement de modèle. Si le prompt, l’adaptateur ou l’évaluation changent aussi, vous comparez deux configurations applicatives ; n’attribuez pas la différence au seul modèle.

Microsoft décrit la comparaison de variantes enregistrées sur les mêmes cas et l’examen des échecs individuels. Les décisions métier attendues pour votre parcours doivent être fixées avant la comparaison.

Montrer les différences pour chaque cas

L’exemple suivant est entièrement fictif. Une application doit extraire un identifiant de projet d’un message ou demander une vérification manuelle. Elle n’accorde aucun accès au projet. Les noms de champs appartiennent à notre schéma interne, pas à une API fournisseur.

Le tableau contient des sorties supposées pour l’explication. Ce n’est pas un test de modèle exécuté. Les descriptions des cas ne remplacent pas les entrées originales versionnées d’une comparaison réelle.

Dans le deuxième cas, la nouvelle variante choisit un projet malgré l’incertitude. Dans le troisième, elle enfreint le contrat de champs. Une évaluation globale pourrait masquer ces causes d’erreur différentes. Une sortie formellement valide doit aussi être correcte sur le plan métier.

Traiter les erreurs avant de poursuivre

OWASP recommande de valider les sorties du modèle avant de les transmettre aux composants en aval. Dans l’exemple, l’absence d’un champ obligatoire ne doit pas être traitée comme une extraction réussie. L’application doit rejeter la sortie ou l’orienter vers la vérification prévue. La présence d’un champ projet n’autorise toujours pas l’accès.

Outre les cas métier et de format, examinez les langues réellement nécessaires, les indisponibilités et les nouvelles tentatives. Une seule exécution ne donne pas une fréquence d’erreur stable. Si les erreurs connues servent à ajuster la nouvelle variante, des cas supplémentaires tenus à l’écart sont nécessaires pour un contrôle indépendant.

Prévoir ensemble mise en service et retour

Avant la mise en service, définissez les erreurs qui empêchent le changement et la personne chargée d’évaluer les écarts non résolus. Dans le tableau, il faut d’abord traiter l’attribution prématurée d’un projet depuis un message ambigu et le champ obligatoire manquant.

Conservez l’ancienne configuration applicative et un retour vérifié vers celle-ci. Clarifiez aussi si l’ancien modèle reste disponible et si les données conservées restent compatibles. Après le changement, observez les résultats réels du parcours concerné ; trois cas illustratifs ne prouvent pas une aptitude générale à la production.

Sources

• Microsoft — Evaluate models, prompts, and agents

• OWASP 2025 — Improper Output Handling