Lancer et examiner un audit

Lancez un audit dès que son objectif et sa population sont suffisamment précis pour qu’un autre opérateur sache à quoi ressemble un résultat valide.

Lancer et inspecter un audit

Tableau de bord
CLI

Accédez à Analyser → Audits, ouvrez l’audit et sélectionnez lancer maintenant. Une réponse en file d’attente signifie que le répartiteur le démarrera sous peu.
Ouvrez la nouvelle exécution pour consulter son statut, sa fenêtre, sa durée, le nombre de résultats et le rapport.
Sélectionnez une session de preuves pour ouvrir la trace exacte.
Retournez à la page de l’audit pour modifier les paramètres, désactiver la planification ou inspecter les exécutions précédentes.

fp audits run checkout-reliability
fp audits runs checkout-reliability --limit 10
fp --json audits runs checkout-reliability
fp audits findings --audit checkout-reliability

Consultez la référence fp audits pour l’historique des exécutions, les résultats et les commandes de triage.

Avant de lancer

Confirmez que des sessions existent dans la fenêtre temporelle sélectionnée.
Vérifiez les filtres d’environnement et d’agent.
Assurez-vous que le contexte de référence est à jour.
Veillez à ce que l’objectif décrive un mode de défaillance, et non une conclusion souhaitée.

Examiner l’exécution

Commencez par le statut de l’exécution, la couverture des sessions et la vérification que l’analyse par le modèle s’est bien déroulée. Inspectez ensuite la sévérité, la description, les sessions de preuves, les requêtes associées et la piste de prévention suggérée pour chaque résultat. Utilisez le statut des résultats pour les accuser de réception, les mettre en sourdine, les rejeter, les résoudre, les rouvrir ou assigner des tâches. Conservez les preuves même lorsque le résultat est rejeté ; elles expliquent pourquoi cette décision a été prise.

Interpréter une exécution vide ou différée

Condition d’exécution	Ce que cela signifie	Que faire
L’analyse s’est exécutée et n’a produit aucun résultat	Les preuves sélectionnées n’ont pas permis d’établir un résultat à la sensibilité configurée.	Confirmez que la portée contient des sessions représentatives, puis considérez le résultat comme sain, à moins que l’objectif ou le contexte n’ait été trop vague.
L’analyse par le modèle a été ignorée ou a échoué	L’exécution se termine avec zéro résultat, mais l’investigation agentique n’a pas été effectuée. Le scan déterministe des identifiants et des données personnelles rapporte toujours des comptes de correspondances dans les statistiques d’exécution, mais ne crée pas de résultats.	Corrigez le service d’analyse ou la configuration et relancez. N’interprétez pas le résultat vide comme une preuve que la population est saine.
L’analyse par le modèle est désactivée	L’exécution réussit avec zéro résultat. Le scan déterministe ne remplace pas l’analyse par le modèle et n’ouvre pas de résultats.	Activez l’analyse par le modèle ou désactivez l’audit plutôt que de vous fier à un audit incapable de produire des résultats.
Aucune capacité d’analyse n’est immédiatement disponible	L’audit reste en file d’attente et effectue de nouvelles tentatives au lieu d’ignorer la population.	Attendez que la capacité soit disponible ou répartissez les ancres d’audit. Les opérateurs auto-hébergés doivent faire évoluer les réplicas d’agent d’audit et la capacité du répartiteur correspondant.
La capacité reste indisponible pendant toute la fenêtre de nouvelles tentatives	L’exécution abandonne avec zéro résultat et envoie une notification d’échec lorsque la livraison par e-mail est disponible.	Vérifiez si la flotte d’audit est saturée ou redémarre répétitivement.

Lorsque l’analyse ne s’exécute pas, les audits since_last conservent cette fenêtre non analysée ouverte pour la prochaine exécution réussie. Les résultats existants ne sont pas archivés, car une analyse ignorée ne prouve pas que la défaillance a disparu.

Comprendre les notifications d’échec

Une exécution échouée ou une étape d’analyse par le modèle échouée utilise les destinataires e-mail de l’audit. Si l’audit ne dispose d’aucun canal e-mail, Failproof AI se replie sur le paramètre alerts.email_default_recipients de l’organisation, afin qu’un audit silencieusement défaillant dispose toujours d’une voie d’escalade. L’e-mail doit être activé pour l’organisation et le SMTP doit être configuré. Sinon, l’échec est journalisé mais aucun e-mail ne peut être envoyé. Les échecs d’exécution ne déplacent pas l’ancre de planification fixe de l’audit. Chaque exécution stocke également le contexte agent exact utilisé pour chaque agent sous forme d’instantané de contrat. Les modifications ultérieures ne changent pas le standard de preuve enregistré avec une exécution antérieure.

Ne déployez pas de politique de blocage directement à partir d’un résultat non vérifié. Ouvrez les traces citées et confirmez que la règle distingue bien les comportements non sécurisés des usages légitimes.

​Lancer et inspecter un audit

​Avant de lancer

​Examiner l’exécution

​Interpréter une exécution vide ou différée

​Comprendre les notifications d’échec

Lancer et inspecter un audit

Avant de lancer

Examiner l’exécution

Interpréter une exécution vide ou différée

Comprendre les notifications d’échec