Après un changement d’outil IA : quels cas faut-il retester ?

Partir de la différence, puis revenir au travail attendu

Je propose de commencer par une question précise : qu’est-ce que ce changement pourrait modifier dans le résultat utilisé par l’équipe ? Le nom commercial du modèle ou le message « mise à jour effectuée » ne décrit pas cette conséquence. Il faut relier la modification à une tâche, à ses données et à ses critères de qualité.

Le journal de maintenance sert à suivre les événements et leur traitement. Le présent article traite une étape plus étroite : construire la comparaison qui éclairera l’autorisation d’utiliser une configuration modifiée. Si la cause d’une mauvaise réponse reste inconnue, commencez par le diagnostic de l’étape à vérifier.

Le cadre volontaire du NIST prévoit de documenter jeux de tests, mesures et outils, puis d’évaluer dans des conditions proches de l’utilisation prévue. ^[1] J’en retiens un principe de travail : une conclusion doit rester attachée aux conditions dans lesquelles elle a été obtenue. Un essai dans un compte d’administrateur, avec d’autres documents, n’établit pas le fonctionnement pour l’utilisateur habituel.

Écrire ce qui change et ce qui doit rester stable

Conservez une référence avant et après : versions accessibles, consigne exacte, documents retenus, réglages connus, outils et droits utiles. Notez aussi les éléments que vous ne pouvez pas connaître ou fixer. Une interface peut ne pas exposer l’identifiant précis du modèle ; inscrivez cette limite au lieu de compléter la fiche par supposition.

Ce tableau organise des questions ; il n’affirme pas que chaque modification entraîne tous ces défauts. Si plusieurs éléments changent ensemble, vous pouvez examiner la configuration complète. En revanche, n’attribuez pas un écart au modèle seul. Pour rechercher la cause, il faudra éventuellement isoler les changements dans un environnement adapté.

Séparer évolution attendue et régression

Une régression est ici la dégradation d’un comportement que l’on voulait conserver. Une réponse différente peut au contraire être attendue : si une règle documentaire a changé, l’ancienne réponse correcte peut être devenue fausse. Garder le même corrigé pour tous les cas ferait alors passer la nouveauté utile pour un défaut.

Anthropic distingue les évaluations de capacités nouvelles de celles qui vérifient que les tâches déjà maîtrisées le restent. ^[2] Pour votre usage, marquez chaque cas avant l’essai : attendu inchangé, attendu modifié ou nouveau comportement à examiner. Précisez qui a validé l’attendu et sur quelle référence.

Exemple de raisonnement : une nouvelle consigne demande une synthèse plus courte. La longueur peut évoluer ; la distinction entre une date confirmée et une date proposée doit rester. Si le texte gagne en concision mais transforme une proposition en engagement, le changement échoue sur un critère utile au travail, même si la présentation plaît davantage.

Choisir les cas selon l’effet possible du changement

Je propose trois ensembles complémentaires. Les cas touchés exercent la règle modifiée. Les cas de frontière vérifient ses exceptions, les informations manquantes et les ambiguïtés. Les cas de contrôle vérifient des tâches que le changement était censé laisser intactes. Chaque cas doit justifier sa présence par une conséquence à examiner.

Reprenez des cas déjà documentés lorsque leur résultat et leurs conditions sont exploitables. Ajoutez des situations nouvelles quand le changement introduit une capacité ou une dépendance. Conservez quelques cas à part pendant les ajustements : réussir uniquement les exemples qui ont servi à corriger la consigne renseigne peu sur les autres formulations.

Définissez les critères avant de regarder les sorties : éléments obligatoires, erreur qui bloque l’usage, réserve tolérable dans ce périmètre, comportement attendu en cas d’incertitude. Un critère tel que « réponse professionnelle » demande une traduction observable. Par exemple : conserver le statut provisoire d’une date et indiquer qui doit encore la confirmer.

Le nombre de cas dépend de la diversité des situations et des conséquences d’une erreur. Le petit scénario ci-dessous explique la démarche ; il ne constitue pas un jeu suffisant pour autoriser un usage réel ou sensible.

Exemple fictif : raccourcir une synthèse sans inventer un engagement

Une équipe fictive prépare des brouillons de synthèse à partir de demandes logistiques. Elle remplace une instruction produisant un tableau par une instruction demandant un texte plus court. Les données d’entrée, le modèle affiché et l’absence d’envoi automatique restent inchangés dans ce scénario. Aucun assistant réel n’a été exécuté pour cet article.

Le cas ordinaire contient une date confirmée, un responsable et une prochaine action. Le cas de frontière contient une date seulement envisagée et attend une confirmation. Un autre cas ne fournit aucune date. L’équipe ajoute un cas de contrôle comportant deux demandes qui ne doivent pas être fusionnées.

La conclusion proposée est de ne pas autoriser cette nouvelle consigne dans le périmètre étudié. Le défaut touche une condition déterminante, fixée avant l’essai. L’ancienne consigne ne reste utilisable que si elle demeure disponible, autorisée et adaptée aux références actuelles. À défaut, l’équipe prépare la synthèse par la voie manuelle prévue.

Les résultats du tableau sont entièrement fictifs. Ils illustrent pourquoi le nombre de cases réussies ne remplace pas l’examen du défaut restant. Ils ne démontrent ni l’infériorité d’une consigne courte ni la fiabilité d’un produit.

Comparer sans masquer la variabilité et les inconnues

Les sorties peuvent varier entre tentatives ; Anthropic distingue pour cette raison un cas de test de ses exécutions répétées. ^[2] Décidez à l’avance comment répéter les cas importants et conservez tous les résultats, y compris les échecs. Relancer jusqu’à obtenir une réponse satisfaisante ne permet pas de conclure que l’usage est stable.

Dans une comparaison avant/après, gardez les mêmes entrées, les mêmes critères pour les comportements inchangés et des conditions aussi comparables que possible. Pour une règle volontairement modifiée, conservez les deux attendus et expliquez leur différence. Évitez que le texte de la première réponse serve de contexte à la seconde si ce contexte ne fait pas partie de l’usage étudié.

Si l’ancienne configuration n’est plus accessible, les sorties enregistrées peuvent éclairer l’examen, avec leurs limites. Elles ne recréent pas une comparaison actuelle contrôlée. Vous pouvez vérifier l’aptitude de la version disponible à satisfaire les critères ; l’attribution d’un écart au changement restera plus incertaine.

Si un outil réalise une action, contrôlez l’état obtenu dans un environnement d’essai autorisé, pas seulement le message qui annonce la réussite. Anthropic distingue également la trace d’échange du résultat final dans l’environnement. ^[2] Préparez des données et des destinataires fictifs ; aucun essai ne doit créer par surprise un engagement réel.

Décider du périmètre autorisé et de la suite

Votre conclusion peut être : poursuivre dans le périmètre testé, poursuivre avec une restriction précise, corriger puis rejouer les cas, ou suspendre cet usage. Inscrivez la configuration concernée, les cas non couverts, les réserves, le décideur et les conditions de réexamen. Le NIST prévoit des mécanismes de désengagement ou de désactivation lorsque le fonctionnement ne correspond plus à l’usage prévu. ^[1]

Un retour arrière doit être possible et approprié : remettre une ancienne instruction ne rétablit pas nécessairement un ancien modèle, un document retiré ou un droit supprimé. Ne réactivez pas une configuration devenue inadaptée simplement parce qu’elle réussissait un ancien jeu de tests. Une solution manuelle ou une limitation temporaire peut être la bonne suite.

La fiche de retest après changement fournit un modèle à compléter, des entrées fictives et un corrigé de décision. Si vous devez construire ces contrôles avec les personnes qui utilisent l’IA, vous pouvez présenter l’usage et le changement envisagé, sans transmettre de données confidentielles.

Questions fréquentes

Faut-il tout retester après chaque changement ? Le périmètre doit être argumenté à partir de ce qui peut être affecté. Un changement mal compris ou transversal peut justifier un examen large. Ne concluez pas qu’une tâche est préservée au seul motif que son écran n’a pas changé.

Peut-on comparer uniquement la nouvelle réponse à l’ancienne ? L’ancienne réponse n’est pas la vérité de référence. Vérifiez les deux contre les critères et les pièces applicables, en distinguant l’attendu conservé de l’attendu modifié.

Une annonce de mise à jour suffit-elle à expliquer un défaut ? Non. Elle décrit ce que l’éditeur annonce dans un périmètre donné. Il reste à identifier la configuration réellement utilisée et à examiner les autres différences. Cet article ne rapporte aucune mise à jour particulière.

Ce retest suffit-il pour la sécurité ou la conformité ? La méthode porte sur une décision opérationnelle limitée. Les enjeux de sécurité, de données personnelles, de droit ou de métier sensible demandent leur propre examen avec les personnes compétentes.