Gardez le même test.
Puis évaluez le contrôle.

Dans l’exemple détaillé de Microsoft, la pièce importante n’est pas seulement la politique générée. C’est aussi l’évaluation qui l’accompagne lors de l’exécution suivante. Microsoft a présenté run-assert-eval le 24 septembre 2026 comme un enchaînement reliant découverte des risques, exigences comportementales mesurables, contrôles à l’exécution et réévaluation. Son article Command Line indique que la définition du comportement, les cas et la méthode de jugement restent constants, la politique constituant l’intervention prévue. Pour la personne chargée de l’examen en entreprise, la question devient concrète : l’équipe peut-elle identifier précisément l’évaluation réutilisée et expliquer ce qui a changé autour d’elle ? De nouveaux cas plus faciles pourraient améliorer le résultat sans répondre à la question du traitement de l’échec initial. Conserver le test est donc une condition d’interprétation de l’intervention, pas un raccourci pour démontrer un lien causal.

Cette distinction compte lorsque découverte et acceptation partagent le même processus. La découverte cherche ce qui pourrait encore mal se passer ; l’évaluation d’une intervention examine le comportement de l’agent au regard d’une exigence précise, après un changement revu. Les deux démarches sont utiles, mais ne produisent pas les mêmes éléments de preuve. Nous proposons, pour l’acceptation, de conserver l’évaluation d’origine comme un dossier identifiable et d’ajouter séparément les nouveaux cas. Définissez le comportement interdit assez précisément pour qu’un échec permette une décision ciblée. Indiquez en parallèle quel travail autorisé et légitime doit continuer à aboutir. Sinon, un contrôle qui refuse simplement davantage de demandes peut sembler efficace tout en réduisant l’utilité de l’agent. Microsoft distingue explicitement ces catégories de résultats ; aucune ne devrait disparaître dans un score unique favorable.

Microsoft rapporte avoir réutilisé les éléments conservés de l’évaluation initiale pour l’exécution avec contrôle. Pourtant, les résultats globaux mis en avant pour les deux exécutions reposent sur des nombres différents de conversations applicables. Un rapprochement au niveau des cas est nécessaire avant de les interpréter. Le jeu de tests fixe et le sous-ensemble applicable ne sont pas interchangeables : conserver les cas ne suffit pas à expliquer quelles conversations remplissaient les conditions de chaque mesure. Demandez quels cas étaient applicables à chaque exécution, pourquoi certaines classifications ont changé et comment chaque résultat se rattache à son cas. Ne présentez pas les chiffres de synthèse comme une comparaison appariée à dénominateur identique, ni sous forme de graphique chiffré avant-après. Garder le même évaluateur contribue à préserver la méthode, sans le rendre infaillible ni résoudre les différences d’applicabilité. Une comparaison utile commence par des cas traçables, pas par l’hypothèse que deux totaux décrivent la même population.

La source précise que la génération ne vaut pas approbation automatique : la politique, sa description d’application, le point d’intervention et le raccordement à l’agent doivent être examinés avant l’exécution avec contrôle. Ce passage de relais porte sur le fond ; ce n’est pas une formalité administrative. Les personnes qui examinent le dispositif doivent comprendre quelle décision est appliquée, où elle prend effet et si l’agent évalué passe effectivement par ce point. Répéter l’évaluation ne compense pas un mécanisme d’application mal défini. Nous proposons un dossier de revue distinguant le contenu généré de la version retenue par les personnes pour l’évaluation, identifiant le changement de contrôle prévu et signalant les autres modifications susceptibles d’influencer l’interprétation. Si les cas ou les critères de jugement doivent changer, conservez une nouvelle version de l’évaluation au lieu de continuer à la présenter comme la comparaison d’origine. L’objectif est une chaîne de décisions vérifiable, pas l’affirmation que l’automatisation a approuvé sa propre production.

L’exemple de Microsoft comporte encore des comportements interdits après l’application du contrôle. Ces échecs doivent figurer dans le dossier de décision, sans être éclipsés par une affirmation générale selon laquelle le problème serait résolu. L’échantillon publié ne présente par ailleurs aucun échec observé du travail légitime dans les résultats avec contrôle ; cela ne prouve pas que ce travail reste toujours intact. Avant d’accepter un contrôle, demandez : à quelle exigence ces éléments répondent-ils, quels cas restent non résolus et qui prend en charge la suite ? Quelles attentes de travail légitime ont été testées et quelles tâches pertinentes sont restées hors de l’échantillon ? La personne chargée de la revue peut-elle examiner les décisions d’applicabilité et distinguer un refus observé d’une tâche autorisée accomplie correctement ? Le responsable doit consigner s’il accepte le périmètre évalué, le restreint ou demande un travail supplémentaire, avec ses motifs. Il s’agit de questions d’acceptation proposées, pas de conclusions tirées d’un déploiement que nous aurions testé. Le schéma associé organise ces vérifications ; il ne représente pas un succès mesuré.