Skip to main content
Fonctionnalité bêta. L’audit est publié en version bêta le temps que nous recueillions les premiers retours. Le catalogue de détecteurs et le format du rapport sont susceptibles de changer avant la prochaine version stable. N’hésitez pas à ouvrir une issue si quelque chose vous semble incorrect.
L’audit rejoue vos transcriptions passées de l’agent CLI à travers le moteur de politiques de failproofai et génère un rapport visuel partageable sur la page du tableau de bord /audit — l’archétype de votre agent, un score de 0 à 100, et précisément quelles politiques auraient détecté quoi.

​
Lancer l’audit

Trois façons de démarrer — toutes aboutissent au même rapport /audit.

Sans installation

npx -y failproofai audit télécharge failproofai, lance l’analyse et ouvre le tableau de bord pour vous — aucune installation préalable requise.

Depuis le CLI

failproofai audit lance l’analyse dans votre terminal, puis ouvre localhost:8020/audit automatiquement une fois terminé.

Depuis le tableau de bord

Lancez failproofai et cliquez sur Audit dans la barre de navigation (entre Policies et Projects), ou ouvrez /audit directement.
Lancez failproofai audit -h (ou --help) pour afficher l’aide. L’audit s’exécute entièrement hors ligne — aucun compte ni connexion réseau requis — et le tableau de bord reste actif jusqu’à ce que vous l’arrêtiez avec Ctrl+C.
Le tableau de bord analyse les transcriptions passées de l’agent CLI sur cette machine (Claude Code, Codex, Copilot, Cursor, OpenCode, Pi) et indique à quelle fréquence l’agent a effectué des actions que failproofai est conçu pour bloquer — vérifications de variables d’environnement, push forcés, préfixes cd <cwd> redondants, boucles de polling avec sleep, relecture de fichiers venant d’être édités, et bien d’autres. Pour chaque transcription, chaque événement d’utilisation d’outil est rejoué à travers les 39 politiques intégrées et à travers 8 détecteurs exclusifs à l’audit qui repèrent des motifs non encore couverts par les politiques en temps réel. Les comptages sont agrégés par politique / détecteur sur l’ensemble des sessions.

​
Ce que vous obtenez

La page /audit est une affiche plein écran partageable, suivie de quatre sections situées sous le pli :
  1. Affiche — l’identité de votre agent en un coup d’œil : son archétype (l’un des 8 — optimist, cowboy, explorer, goldfish, paranoid architect, precision builder, hammer, ghost), ses mots-clés de persona, la rareté de cet archétype, et un score de 0 à 100 avec un niveau (S jusqu’à bottom tier). Conçue pour être partagée — publiez-la sur X ou LinkedIn, ou téléchargez-la en PNG.
  2. // strengths — ce que votre agent fait déjà bien, exprimé en chiffres réels issus de l’analyse (ex. : taux d’appels d’outils propres, 0 tentative de push sur main), affiché uniquement lorsque la politique concernée affiche un bilan sans faille.
  3. // quirks — ce qui a échappé : un tableau classé des comportements que failproofai aurait détectés — quand c’est arrivé la dernière fois, ce qui a échappé (et la politique intégrée qui l’aurait bloqué), sa sévérité, et la fréquence à laquelle c’a été observé (new / recurring / N× seen).
  4. // how to improve — la liste des correctifs recommandés : une ligne par politique avec un failproofai policy add <slug> à copier-coller, ainsi qu’un bouton install all qui active toutes les recommandations en une fois et affiche votre score projeté si vous le faisiez.
  5. // come back better — ancrez la bonne habitude : définissez un rappel par e-mail pour un nouvel audit (3d / 7d / 14d / 30d) ou relancez l’audit maintenant, et invitez un ami à effectuer son propre audit (envoyé depuis failproof.ai, en Cc à vous). Les rappels et invitations nécessitent une connexion — voir failproofai auth.

​
Détecteurs exclusifs à l’audit

Ces détecteurs repèrent des motifs de comportement inefficaces qui ne sont pas (encore) appliqués en temps réel. Ils ne s’exécutent que pendant l’audit et ne bloquent jamais un appel d’outil en direct.

​
Caches

  • Cache par transcription dans ~/.failproofai/cache/audit/<sha1>.json, indexé par (mtime, size, engineVersion, detectorVersion) — invalidé automatiquement lorsque la transcription ou le code des politiques/détecteurs change. Chaque entrée stocke également un horodatage cachedAt comme métadonnée TTL (ne faisant pas partie de la clé de cache) ; les entrées de plus de 7 jours sont rejetées à la lecture afin que des résultats anciens ne survivent pas à l’évolution des détecteurs.
  • Cache du résultat global dans ~/.failproofai/audit-dashboard.json (mode 0600). Permet au tableau de bord de s’afficher instantanément lors de la navigation sans relancer l’analyse. Également rejeté à la lecture au-delà du TTL de 7 jours — /audit bascule alors vers son état vide et invite à relancer une analyse. Cliquez sur [ re-audit now ] en bas du rapport pour actualiser — le re-audit envoie noCache: true, ce qui contourne le cache par transcription et ré-analyse chaque transcription au lieu de retourner le résultat mis en cache ; l’exécution diffuse sa progression via une bannière épinglée en haut et remplace le résultat en place en cas de succès (sans rechargement de page ; un re-audit échoué conserve le rapport précédent).

​
Remarques

  • Aucune mutation. L’audit rejoue en mode lecture seule. warn-repeated-tool-calls est ignoré car son fichier sidecar par session serait autrement modifié.
  • Politiques de workflow ignorées. Les politiques require-*-before-stop ne se déclenchent que sur les événements Stop et utilisent execSync sur l’état git actif — elles n’ont pas d’interprétation significative dans un contexte rétroactif type « qu’aurait-il se passé en 2025 », et n’apparaissent donc pas dans les comptages de l’audit.
  • Politiques personnalisées ignorées. Les hooks personnalisés fournis par l’utilisateur ne sont pas rejoués (ils peuvent avoir changé depuis la session d’origine).