Plan de retest d’un usage IA après changement : modèle et cas corrigé

Ce que vous obtenez et ce qu’il faut préparer

À la fin, vous devez pouvoir expliquer quel changement a été examiné, sur quels cas, avec quels résultats et ce que l’on peut en conclure. Le livrable est une décision limitée et sa preuve, pas une note globale de qualité de l’IA.

Préparez la référence de l’usage accepté, les éléments de configuration accessibles, les documents autorisés et une personne capable de juger le résultat métier. Si l’ancienne configuration manque, indiquez-le. Vous pourrez examiner la version disponible, sans prétendre disposer d’une comparaison avant/après contrôlée.

Les rubriques sont originales. Le NIST fournit un repère sur la documentation des essais et leurs conditions d’utilisation. ^[1] Anthropic distingue les cas de test, leurs tentatives et le maintien des comportements attendus. ^[2] Aucun de ces documents ne valide ce canevas ni n’impose le jeu fictif proposé.

Modèle vierge : neuf rubriques à compléter

Pour le journal de résultats, gardez une ligne par tentative : identifiant du cas ; configuration ; numéro de tentative ; référence de la sortie ; résultat par critère ; explication de l’écart. Un essai non réalisé doit rester « non exécuté ». Un résultat non vérifiable reste « indéterminé ».

Construire le jeu avant d’exécuter les essais

Choisissez les cas directement touchés, leurs exceptions et des cas de contrôle que la modification ne devrait pas affecter. Pour chaque entrée, écrivez l’information indispensable et l’erreur qui ferait refuser le résultat. Les critères doivent permettre à un autre évaluateur compétent de comprendre la conclusion.

Gardez les entrées et conditions aussi comparables que possible. Définissez les répétitions avant de commencer, en fonction des conséquences et des moyens. Ne retenez pas uniquement la meilleure sortie. Si vous corrigez la configuration pendant la séance, créez une nouvelle référence ; ne mélangez pas ses résultats avec ceux de la précédente.

Les cas ci-dessous donnent un exercice complet à comprendre ou adapter. Ils ne forment pas un échantillon représentatif de votre activité. Ajoutez les situations, formulations et limites réellement importantes avant toute décision d’usage.

Exercice fictif : passer d’un tableau à une synthèse courte

Une équipe fictive transforme des notes logistiques en brouillons de synthèse. La consigne A produit un tableau ; B demande un paragraphe court. Dans l’exercice, l’équipe veut changer la forme en conservant les dates, leur statut, les personnes responsables et les prochaines actions. Aucun envoi n’est autorisé par l’assistant.

La configuration A et la configuration B sont supposées disponibles pour l’exercice. Les mêmes entrées sont présentées séparément, sans historique d’une tentative précédente. Deux tentatives par cas sont inventées pour montrer la tenue du journal ; ce nombre n’est pas un seuil recommandé.

C1 est un cas courant touché par la nouvelle forme. C2 et C3 sont des cas de frontière. C4 sert de contrôle sur la séparation des actions. Pour ce scénario, perdre le caractère provisoire d’une date ou créer une date est bloquant ; l’élégance du style ne peut compenser cet écart.

Résultats fictifs et décision expliquée

Extrait inventé de la seconde sortie B sur C2 : « L’atelier aura lieu le 28 octobre ; Samir relance l’animateur le 22. » Le texte conserve deux dates, mais leur sens est altéré. Le critère n’était donc pas seulement « citer toutes les dates » : il exigeait de conserver la confirmation manquante.

Conclusion fictive : ne pas autoriser B pour cet usage ; conserver A uniquement si elle reste disponible, autorisée et adaptée, sinon utiliser la préparation manuelle prévue. Le responsable de l’usage fait corriger la règle de synthèse, puis rejouer C2, les autres cas et des variantes nouvelles. Les résultats inventés ne permettent aucun taux de fiabilité du système.

Le plan doit encore indiquer les vérifications non couvertes : autres formulations, autres types de demandes, droits d’accès et fonctionnement de l’environnement réel. La correction annoncée ne clôt pas l’essai. Une nouvelle version doit avoir ses propres résultats et sa décision.

Adapter le plan à un document ou à un outil modifié

Pour un document remplacé, marquez les cas dont l’attendu doit réellement changer. Conservez un cas qui cite l’ancienne version et un sujet qui doit rester inchangé, puis définissez le comportement voulu. Ne comparez pas toutes les réponses au corrigé de l’ancien document.

Pour un outil, ajoutez l’état attendu après l’action, les limites d’autorisation et le comportement en cas d’échec. Travaillez dans un environnement d’essai autorisé et avec des destinataires fictifs. Un message « terminé » ne suffit pas à établir que l’état attendu existe.

Pour un changement dont l’étendue reste inconnue, notez cette incertitude et faites préciser le périmètre. Une liste courte de cas réussis ne permet pas de déclarer intactes des fonctions qui n’ont pas été examinées.

Questions pratiques et prochaine étape

Peut-on modifier les critères après avoir vu le résultat ? Un critère peut être mal défini. Corrigez-le avec une raison traçable, puis réexaminez les résultats concernés selon cette nouvelle définition. Ne changez pas la règle uniquement pour faire accepter une sortie qui vous arrange.

Que faire si l’ancienne version n’est plus disponible ? Inscrivez la limite dans la comparaison. Des résultats archivés gardent leur contexte propre. Examinez la configuration actuelle contre les critères ; vous ne pourrez pas isoler avec la même confiance l’effet du changement.

Où conserver les sorties détaillées ? Dans l’espace autorisé pour ces données, avec des références dans la fiche. Le modèle ne définit aucune durée universelle de conservation et ne justifie pas de copier des données sensibles dans un document largement partagé.

La méthode retester après un changement développe le choix des cas. Le journal de maintenance conserve ensuite la suite décidée. Pour préparer une séance de retest avec votre équipe, décrivez la tâche et le changement sans joindre de contenu confidentiel.