Le correctif n’est pas un autre tableau de bord plus grand. Il s’agit d’un enregistrement de preuves multicouches qui relie l’action du modèle, le résultat du harnais et l’état observé du système. Chaque modification automatisée doit comporter la cible d’origine, la cible proposée, les preuves utilisées pour effectuer la substitution, le score de confiance, l’assertion résultante et un statut explicite d’examen humain.
Pour une conversation d’évaluation ou d’approvisionnement, je poserais cinq questions. Premièrement, l’outil peut-il distinguer une réparation réussie d’une exécution réussie contre la mauvaise cible ? Deuxièmement, mesure-t-il les fausses guérisons sur des localisateurs perturbés de manière contradictoire plutôt que de mesurer uniquement si un test est réexécuté ? Troisièmement, un ingénieur peut-il reproduire la décision à partir d’un dossier d’audit ? Quatrièmement, l’outil s’abstient-il lorsque les preuves sont faibles, ou est-il optimisé pour une construction verte ? Cinquièmement, ses événements peuvent-ils être corrélés aux traces d’exécution de l’application et aux appels d’outils du modèle ?
J’aurais également besoin d’un mode de fonctionnement par étapes. La réparation autonome peut proposer un changement, mais les changements à fort impact doivent faire l’objet d’un tri assisté jusqu’à ce que l’organisation ait la preuve que la réparation conserve son sens. Cet esprit est similaire à l’accent mis par l’ingénierie du chaos sur des expériences disciplinées et observables : le système doit révéler ses modes de défaillance dans des conditions contrôlées avant de lui faire confiance dans des conditions incontrôlées.
