failproofai 1.0.1-beta.0 → 1.0.1

package/.next/standalone/docs-old/fr/cli/audit.mdx

@@ -0,0 +1,126 @@
+---
+title: Auditer les sessions passées (bêta)
+description: "Comptez combien de fois l'agent a effectué des actions inutiles ou risquées dans les transcriptions passées"
+---
+
+<Note>
+  **Fonctionnalité bêta.** L'audit est disponible en bêta le temps de recueillir les premiers retours.
+  Le catalogue de détecteurs et le format du rapport peuvent évoluer avant la prochaine version stable.
+  N'hésitez pas à ouvrir un ticket si quelque chose vous semble incorrect.
+</Note>
+
+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 et 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 d'accéder — toutes aboutissent au même rapport `/audit`.
+
+<CodeGroup>
+
+```bash npx (sans installation)
+npx -y failproofai audit
+```
+
+```bash failproofai audit
+failproofai audit
+```
+
+```bash failproofai (tableau de bord)
+failproofai
+```
+
+</CodeGroup>
+
+<CardGroup cols={3}>
+  <Card title="Sans installation" icon="bolt">
+    `npx -y failproofai audit` télécharge failproofai, lance le scan et ouvre le
+    tableau de bord automatiquement — rien à installer au préalable.
+  </Card>
+  <Card title="Depuis la CLI" icon="terminal">
+    `failproofai audit` exécute le scan dans votre terminal, puis ouvre
+    `localhost:8020/audit` automatiquement une fois terminé.
+  </Card>
+  <Card title="Depuis le tableau de bord" icon="gauge">
+    Lancez `failproofai` et cliquez sur **Audit** dans la barre de navigation (entre Policies et
+    Projects), ou ouvrez `/audit` directement.
+  </Card>
+</CardGroup>
+
+<Tip>
+  Exécutez `failproofai audit -h` (ou `--help`) pour afficher l'aide. L'audit fonctionne **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`.
+</Tip>
+
+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 la fréquence à laquelle 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 par sleep, re-lecture de fichiers venants d'être modifiés, et bien plus.
+
+Pour chaque transcription, chaque événement d'utilisation d'outil est rejoué à travers les 39 politiques intégrées **et** à travers 8 détecteurs propres à l'audit qui repèrent des patterns 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** pleine page et partageable, suivie de quatre sections 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 — postez sur X ou LinkedIn, ou téléchargez en PNG.
+2. **`// strengths`** — ce que votre agent fait déjà bien, exprimé en chiffres réels issus du scan (ex. : taux de tool-call propres, `0` tentative de push vers main), affiché uniquement lorsque la politique concernée n'a aucune infraction.
+3. **`// quirks`** — ce qui s'est glissé : un tableau classé des comportements que failproofai aurait interceptés — *quand* cela s'est produit pour la dernière fois, *ce qui a glissé* (et la règle intégrée qui l'aurait bloqué), sa *sévérité*, et la fréquence d'apparition (`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, plus un bouton **install all** qui active toutes les recommandations d'un coup et affiche votre **score projeté** si vous le faites.
+5. **`// come back better`** — adoptez la bonne habitude : configurez un **rappel** par e-mail (`3d` / `7d` / `14d` / `30d`) ou relancez l'audit maintenant, et **invitez un ami** à effectuer son propre audit (envoyé depuis failproof.ai, avec vous en Cc). Les rappels et invitations nécessitent une connexion.
+
+## Audits planifiés
+
+Si vous faites tourner le **démon failproofaid** (voir [`failproofai config`](/fr/cli/install-policies)),
+il peut relancer l'audit selon un calendrier et rafraîchir le rapport `/audit` en
+arrière-plan. Cette option est **désactivée par défaut**, car le scan lit le *contenu*
+de chaque transcription de session de l'agent sur cette machine — rien ne scanne de façon planifiée
+tant que vous ne le demandez pas.
+
+Activez-la dans `~/.failproofai/config.toml` :
+
+```toml
+[audit]
+auto = true
+interval_days = 7
+```
+
+| Clé | Signification |
+|---|---|
+| `auto` | `true` active le scan planifié. Toute autre valeur — absente, `false`, `"yes"` — désactive la fonctionnalité. |
+| `interval_days` | Jours entre les scans. Limité à 1–90 ; `0`, une valeur négative ou non numérique revient à `7`. |
+
+- Le calendrier est basé sur **l'horloge murale**, ce qui lui permet de survivre aux suspensions et redémarrages : un ordinateur portable qui était en veille au-delà de son heure prévue s'exécute **une seule fois** au réveil, sans rattrapage en file.
+- Chaque exécution est un processus distinct à faible priorité (`nice 19`) — jamais sur le chemin des hooks du démon, qui reste libre pour répondre aux appels d'outils.
+- Un scan est ignoré si `failproofai audit` ou la relance depuis le tableau de bord est déjà en cours ; il est retenté peu après plutôt que traité comme un échec.
+- La progression est écrite dans `~/.failproofai/state/audit-schedule.json` (dernière exécution, prochaine échéance). Ce fichier appartient au démon — modifiez la cadence dans `config.toml`.
+
+<Note>
+Si vous avez activé cette option sur une machine configurée avec une ancienne version de failproofai, exécutez
+`failproofai config` une fois. La définition de service du démon nécessite une entrée supplémentaire
+avant de pouvoir lancer la CLI, et le rafraîchissement fait partie de cette commande.
+</Note>
+
+## Détecteurs propres à l'audit
+
+Ces détecteurs repèrent des patterns de « comportement inefficace » pas encore appliqués en temps réel. Ils ne s'exécutent que lors de l'audit et ne bloquent jamais un appel d'outil en direct.
+
+| Détecteur | Ce qu'il compte |
+|---|---|
+| `redundant-cd-cwd` | Commandes Bash commençant par `cd <cwd> && …` alors que les commandes s'exécutent déjà dans `cwd`. |
+| `prefer-edit-over-read-cat` | `cat`/`head`/`tail`/`less`/`more` sur un seul fichier source — utilisez l'outil `Read`. |
+| `prefer-edit-over-sed-awk` | Modifications en place avec `sed -i` / `awk … > file` — utilisez l'outil `Edit`. |
+| `prefer-write-over-heredoc` | Écriture de fichiers via heredoc / `echo > file` multiligne — utilisez l'outil `Write`. |
+| `sleep-polling-loop` | Long `sleep N` (≥ 30s) ou boucles de polling `while …; sleep …; done`. |
+| `find-from-root` | `find /`, `find /home`, `find /usr`, etc. — limitez la portée à `cwd`. |
+| `git-commit-no-verify` | `git commit … --no-verify` / `-n`, en sautant les hooks. |
+| `reread-after-edit` | `Read` d'un fichier qui vient d'être modifié par `Edit`/`Write` dans la même session. |
+
+## Caches
+
+- **Cache par transcription** dans `~/.failproofai/cache/audit/<sha1>.json` indexé par `(mtime, size, engineVersion, detectorVersion)` — invalidé automatiquement lorsque la transcription ou le code de politique/détecteur change. Chaque entrée stocke également un horodatage `cachedAt` comme **métadonnées TTL** (non incluses dans 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 le scan. Également rejeté à la lecture au-delà du **TTL de 7 jours** — `/audit` revient alors à son état vide et invite à relancer une analyse fraîche. Cliquez sur `[ re-audit now ]` en bas du rapport pour actualiser — la relance envoie `noCache: true`, ce qui contourne le cache par transcription et rescanne toutes les transcriptions au lieu de retourner le résultat mis en cache ; l'exécution diffuse sa progression via une bannière persistante en haut et remplace le résultat en place en cas de succès (sans rechargement de page ; un échec de la relance conserve le rapport précédent).
+
+## Remarques
+
+- **Aucune mutation.** L'audit se rejoue en mode lecture seule. `warn-repeated-tool-calls` est ignoré car son fichier annexe par session serait sinon modifié.
+- **Politiques de workflow ignorées.** Les politiques `require-*-before-stop` ne se déclenchent que sur les événements `Stop` et s'exécutent via `execSync` contre l'état git en direct — elles n'ont pas d'interprétation significative du type « qu'aurait-il pu se passer en 2025 », et n'apparaissent donc pas dans les comptages d'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).

package/.next/standalone/docs-old/fr/cli/dashboard.mdx

@@ -0,0 +1,29 @@
+---
+title: Voir les sessions
+description: "Lancer le tableau de bord pour parcourir les sessions d'agents et gérer les politiques"
+---
+
+```bash
+failproofai
+```
+
+Lance le tableau de bord web sur `http://localhost:8020`.
+
+## Options
+
+| Indicateur | Description |
+|------------|-------------|
+| `--port <number>` | Port d'écoute (par défaut : `8020`) |
+| `--allowed-origins <origins>` | Hôtes/IPs séparés par des virgules autorisés à accéder aux ressources de développement |
+
+Pour pointer le tableau de bord vers un dossier de projet Claude non par défaut, définissez la variable d'environnement `CLAUDE_PROJECTS_PATH` au lancement.
+
+## Exemples
+
+```bash
+# Lancer sur un port différent
+failproofai --port 9000
+
+# Utiliser un chemin de projets Claude personnalisé via une variable d'environnement
+CLAUDE_PROJECTS_PATH=~/my-claude-projects failproofai
+```

package/.next/standalone/docs-old/fr/cli/environment-variables.mdx

@@ -0,0 +1,70 @@
+---
+title: Variables d'environnement
+description: "Configurer le comportement de failproofai avec des variables d'environnement"
+---
+
+## Tableau de bord
+
+| Variable | Description |
+|----------|-------------|
+| `PORT` | Port du tableau de bord (défaut : `8020`) |
+| `CLAUDE_PROJECTS_PATH` | Remplace l'emplacement où sont recherchés les dossiers de projets Claude Code |
+| `FAILPROOFAI_DISABLE_PAGES=policies,projects` | Pages du tableau de bord à masquer, séparées par des virgules |
+| `FAILPROOFAI_ALLOWED_DEV_ORIGINS` | Hôtes/IPs autorisés à accéder aux ressources de développement. Équivalent à `--allowed-origins`. |
+
+## Journalisation
+
+| Variable | Description |
+|----------|-------------|
+| `FAILPROOFAI_LOG_LEVEL=info\|warn\|error` | Niveau de journalisation du serveur (défaut : `warn`) |
+| `FAILPROOFAI_HOOK_LOG_FILE` | Chemin personnalisé du fichier de journal des hooks, ou `true` pour le chemin par défaut (`~/.failproofai/logs/hooks.log`) |
+
+## Télémétrie
+
+failproofai envoie par défaut des données de télémétrie d'utilisation anonymes. Il existe deux façons de
+la désactiver, et c'est la plus restrictive qui s'applique — une variable d'environnement
+ne peut jamais réactiver ce que le fichier de configuration a désactivé.
+
+| Variable | Description |
+|----------|-------------|
+| `FAILPROOFAI_TELEMETRY_DISABLED=1` | Désactive la télémétrie d'utilisation anonyme pour ce processus |
+
+Pour la désactiver définitivement sur la machine, ajoutez ceci dans `~/.failproofai/config.toml` :
+
+```toml
+[telemetry]
+enabled = false
+```
+
+<Note>
+Le fichier de configuration est l'option à utiliser si vous exécutez le **démon failproofaid**.
+Le démon est un service à portée système, et son environnement n'inclut pas
+les variables exportées depuis votre shell — `FAILPROOFAI_TELEMETRY_DISABLED` ne peut donc pas
+l'atteindre. `[telemetry] enabled = false` est lu aussi bien par le CLI que par le démon.
+</Note>
+
+Le démon ne rapporte que son propre **cycle de vie** : le fait qu'il a démarré (et si
+l'exécution précédente s'est terminée proprement), qu'il s'est arrêté, quand son worker d'évaluation a été
+lancé ou redémarré, quand une tâche de collecte a échoué, et le résultat d'une
+récupération de politique cloud. Ces données ne contiennent que des valeurs et des compteurs à faible cardinalité — jamais un chemin de fichier, une commande, une politique, une invite ou quoi que ce soit extrait d'une transcription. Il n'y a aucun événement par appel d'outil.
+
+## Authentification
+
+| Variable | Description |
+|----------|-------------|
+| `FAILPROOF_API_URL` | Remplace l'URL de base du serveur API utilisée par la boîte de dialogue d'authentification du tableau de bord. Par défaut `https://api.befailproof.ai` ; à définir sur `http://localhost:8080` (ou autre) lors de l'exécution d'un serveur API local. |
+| `FAILPROOFAI_AUTH_DIR` | Remplace l'emplacement de stockage de `auth.json` (défaut : `~/.failproofai`). Principalement utile pour des tests isolés. |
+
+## Invite de premier démarrage
+
+| Variable | Description |
+|----------|-------------|
+| `FAILPROOFAI_NO_FIRST_RUN=1` | Ignore l'invite proposant d'installer des politiques lors du premier appel nu à `failproofai` |
+
+## LLM (pour l'évaluation des politiques)
+
+| Variable | Description |
+|----------|-------------|
+| `FAILPROOFAI_LLM_BASE_URL` | Point de terminaison de l'API LLM (défaut : `https://api.openai.com/v1`) |
+| `FAILPROOFAI_LLM_API_KEY` | Clé API pour les politiques basées sur un LLM |
+| `FAILPROOFAI_LLM_MODEL` | Nom du modèle (défaut : `gpt-4o-mini`) |

package/.next/standalone/docs-old/fr/cli/hook.mdx

@@ -0,0 +1,30 @@
+---
+title: Hook handler (interne)
+description: "Le sous-processus que Claude Code appelle à chaque événement d'outil"
+---
+
+```bash
+failproofai --hook <EventType>
+```
+
+Il s'agit de la commande enregistrée dans le fichier `settings.json` de Claude Code par `failproofai policies --install`. Vous n'avez normalement pas à l'appeler directement.
+
+Lit un payload JSON depuis stdin, évalue toutes les politiques activées, et se termine avec un code indiquant la décision :
+
+| Code de sortie | Décision | Effet |
+|----------------|----------|-------|
+| `0` | `allow` | Autorise l'action |
+| `1` | `deny` | Bloque l'action — Claude reçoit le motif du refus |
+| `2` | `instruct` | Injecte des instructions dans le contexte de Claude |
+
+### Types d'événements pris en charge
+
+| Catégorie | Événements |
+|-----------|------------|
+| **Exécution d'outils** | `PreToolUse`, `PostToolUse`, `PostToolUseFailure`, `PermissionRequest`, `PermissionDenied` |
+| **Cycle de vie de session** | `SessionStart`, `SessionEnd`, `Stop`, `StopFailure` |
+| **Interaction utilisateur** | `UserPromptSubmit`, `Notification`, `Elicitation`, `ElicitationResult` |
+| **Sous-agents et tâches** | `SubagentStart`, `SubagentStop`, `TaskCreated`, `TaskCompleted`, `TeammateIdle` |
+| **Configuration** | `InstructionsLoaded`, `ConfigChange`, `CwdChanged` |
+| **Système de fichiers** | `FileChanged`, `WorktreeCreate`, `WorktreeRemove` |
+| **Contexte** | `PreCompact`, `PostCompact` |

package/.next/standalone/docs-old/fr/cli/install-policies.mdx

@@ -0,0 +1,57 @@
+---
+title: Installer les politiques
+description: "Activer les politiques pour qu'elles s'exécutent à chaque appel d'outil de l'agent"
+---
+
+```bash
+failproofai policies --install [policy-names...] [options]
+```
+
+Écrit des entrées de hook dans le fichier de paramètres de votre CLI d'agent installé (Claude Code, OpenAI Codex ou GitHub Copilot CLI _(bêta)_) afin que failproofai intercepte les appels d'outils.
+
+Alias : `failproofai p -i`
+
+## Options
+
+| Indicateur | Description |
+|------------|-------------|
+| `--cli claude\|codex\|copilot` | CLI(s) d'agent pour lesquels installer ; séparés par des espaces (ex. `--cli claude codex copilot`) ou répétés. Omettre pour détecter les CLI installés et afficher une invite. |
+| `--scope user` | Installe dans le fichier de paramètres de portée utilisateur (Claude : `~/.claude/settings.json` ; Codex : `~/.codex/hooks.json` ; Copilot : `~/.copilot/hooks/failproofai.json`). Par défaut. |
+| `--scope project` | Installe dans le fichier de paramètres de portée projet (Claude : `<cwd>/.claude/settings.json` ; Codex : `<cwd>/.codex/hooks.json` ; Copilot : `<cwd>/.github/hooks/failproofai.json`). |
+| `--scope local` | Claude uniquement — installe dans `<cwd>/.claude/settings.local.json`. Codex et Copilot n'ont pas de portée `local`. |
+| `--custom <path>` / `-c` | Chemin vers un fichier JS contenant des politiques de hook personnalisées |
+
+## Comportement
+
+- **Aucun nom de politique** — ouvre une invite interactive pour sélectionner les politiques
+- **Noms spécifiques** — active ces politiques (ajoutées à celles déjà activées)
+- **`all`** — active toutes les politiques disponibles
+
+L'installation est additive : exécuter `--install` à nouveau ajoute de nouvelles politiques sans supprimer les existantes.
+
+## Exemples
+
+```bash
+# Installer toutes les politiques par défaut globalement (interactif)
+failproofai policies --install
+
+# Installer des politiques spécifiques pour le projet en cours
+failproofai policies --install block-sudo sanitize-api-keys --scope project
+
+# Activer toutes les politiques en une seule fois
+failproofai policies --install all
+
+# Installer avec un fichier de politiques personnalisées
+failproofai policies --install --custom ./my-policies.js
+
+# Installer pour OpenAI Codex (portée projet)
+failproofai policies --install --cli codex --scope project
+
+# Installer pour GitHub Copilot CLI (bêta) pour le projet en cours
+failproofai policies --install --cli copilot --scope project
+
+# Installer pour les trois CLI à la fois
+failproofai policies --install --cli claude codex copilot
+```
+
+Lorsque `--custom <path>` est fourni, le fichier est validé immédiatement — il doit appeler `customPolicies.add()` au moins une fois. Le chemin résolu est enregistré dans `policies-config.json` sous la clé `customPoliciesPath`.

package/.next/standalone/docs-old/fr/cli/list-policies.mdx

@@ -0,0 +1,31 @@
+---
+title: Lister les politiques
+description: "Voir quelles politiques sont activées, leurs paramètres et les politiques personnalisées"
+---
+
+```bash
+failproofai policies
+```
+
+Affiche toutes les politiques avec leur statut, les paramètres configurés et les politiques personnalisées.
+
+## Exemple de sortie
+
+```text
+Failproof AI Hook Policies (user)
+
+  Status  Name                          Description
+  ──────  ──────────────────────────────────────────────────────────────
+  ✓       block-sudo                    Block sudo commands
+            allowPatterns: ["sudo systemctl status"]
+  ✓       block-rm-rf                   Block recursive deletions
+  ✗       block-curl-pipe-sh            Block curl|bash patterns
+  ✓       sanitize-api-keys             Redact API keys from output
+            additionalPatterns: [{ regex: "MY_TOKEN_...", label: "..." }]
+
+  ── Custom Policies (/home/alice/myproject/my-policies.js) ──────────────
+  ✓       require-jira-ticket           Block commits without ticket
+  ✓       approval-gate                 Approval gate for destructive ops
+```
+
+Les clés inconnues dans `policyParams` sont signalées ici afin que vous puissiez détecter les fautes de frappe rapidement.

package/.next/standalone/docs-old/fr/cli/migrate.mdx

@@ -0,0 +1,86 @@
+---
+title: Migrer le répertoire personnel
+description: "Mettre ~/.failproofai à niveau vers la structure attendue par cette version, et prévisualiser les changements avant exécution"
+---
+
+```bash
+failproofai migrate --dry-run   # afficher le plan, sans rien modifier
+failproofai migrate             # exécuter la migration
+```
+
+La plupart des utilisateurs n'ont jamais besoin de taper cette commande. Elle s'exécute automatiquement au premier lancement après une mise à niveau, et [`failproofai update`](/fr/cli/update) l'inclut déjà. Utilisez-la directement lorsque vous souhaitez voir le plan avant son exécution, ou effectuer la migration de manière isolée.
+
+## Indexé sur la structure, pas sur la version
+
+`~/.failproofai/VERSION` enregistre un numéro de **structure** — la forme du répertoire, et non la version qui l'a écrit. Les migrations sont indexées sur ce numéro, ce qui rend un grand écart peu coûteux :
+
+- Les versions npm changent à chaque publication, potentiellement des dizaines entre deux structures.
+- Ainsi, une machine qui saute trente publications **sans changement de structure** exécute **zéro** migration, et non trente opérations inutiles.
+- Et une machine qui saute plusieurs structures d'un coup exécute chaque étape dans l'ordre, chaque étape ne connaissant que ses deux extrémités.
+
+C'est important parce que npm ne peut pas mettre à jour automatiquement un paquet installé. Une machine restée sur une version pendant des mois puis passant plusieurs structures d'un coup est le cas normal, pas l'exception.
+
+## Le mode dry run
+
+`--dry-run` affiche la chaîne exacte et les fichiers qui seraient sauvegardés au préalable, sans rien modifier — ni migration, ni sauvegarde, ni entrée dans le registre :
+
+```
+Layout 2 on disk; this build speaks 3.
+1 step(s) would run:
+  2 → 3  layout 2 → 3: carry config.toml and credentials.toml into JSON, move
+         custom-policies/ back up into policies/, nest the policy config at the root
+
+These would be copied to ~/.failproofai/migrations/backup-layout2 first:
+  VERSION
+  config.toml
+  credentials.toml
+```
+
+## Ce qui est conservé et ce qui est reconstruit
+
+Chaque chemin du répertoire personnel déclare le type de données qu'il contient, ce qui détermine si une migration peut le supprimer. La règle : **ce qui est dérivé ou récupérable peut être abandonné ; tout ce que vous avez saisi, tout ce qui n'a pas encore été transmis, et tout ce qui identifie la machine est conservé.**
+
+| Conservé | Reconstruit ou récupéré |
+|---|---|
+| `config.json` — paramètres, `daemon.configured`, chemins de capture supplémentaires | Le cache d'audit |
+| `credentials.json` — votre enrôlement cloud | Les déploiements gérés dans le cloud (récupérés et vérifiés par condensat au prochain sondage) |
+| `policies-config.json` — votre sélection de politiques et leurs paramètres | L'état temporaire du daemon |
+| `policies/` — vos propres fichiers de politiques et les helpers qu'ils importent | |
+| `hook-activity/` — le journal de décisions lu par le tableau de bord | |
+| Les événements non transmis encore en file d'attente pour l'envoi | |
+| `cursors/` — les repères du collecteur | |
+| Le binaire du daemon dans `bin/` | |
+
+<Note>
+  Les événements non transmis sont conservés plutôt que supprimés car la perte serait permanente, pas seulement différée : le repère du collecteur a déjà avancé au-delà de tout ce qui se trouve dans la file d'attente, donc rien ne lirait jamais cette plage d'une transcription. La migration demande également au daemon de transmettre ce qui est en file d'attente dès qu'elle se termine, de sorte que le résultat habituel est qu'il ne reste rien à conserver.
+</Note>
+
+Les clés qu'une version *plus récente* a écrites dans `config.json`, `credentials.json` ou `policies-config.json` sont également préservées, plutôt que supprimées par un lecteur plus ancien.
+
+## Le registre qu'elle laisse
+
+```
+~/.failproofai/migrations/
+  applied.json                 une entrée par étape : structure, CLI, horodatage, durée, résultat
+  backup-layout<n>/            copies des fichiers irremplaçables, prises avant la première étape
+```
+
+`applied.json` est ce qui répond à la question « par quoi cette machine est-elle réellement passée » — la première chose à vérifier lorsque quelque chose semble anormal après une mise à niveau. Joignez-le à un rapport de bug.
+
+La sauvegarde est délibérément petite plutôt qu'une copie de l'ensemble du répertoire : la migration ne supprime plus rien d'irremplaçable par conception, donc ce contre quoi il vaut la peine de se prémunir est un *défaut dans une étape*, et ces quelques fichiers sont là où un tel défaut ferait mal.
+
+## Si une étape échoue
+
+La chaîne s'arrête là. `VERSION` n'est mis à jour que par une étape qui s'est terminée avec succès, donc le répertoire personnel reste marqué avec son ancienne structure et la prochaine commande réessaie — un répertoire personnel n'est jamais marqué comme à jour sur la base d'une migration partielle. L'étape est enregistrée dans `applied.json` avec `"ok": false`, et la sauvegarde reste à l'endroit où elle a été prise.
+
+## Un répertoire plus récent est refusé, pas migré
+
+Si `~/.failproofai/` a été écrit par une version **plus récente** de failproofai que celle que vous exécutez, la commande s'arrête et vous indique de mettre à niveau à la place. Ces données sont valides et une CLI plus récente les lit normalement ; migrer « en avant » à partir de celles-ci n'est pas une opération qui existe, et les réinitialiser détruirait quelque chose de récupérable.
+
+```
+This machine's failproofai directory was written by a newer version (layout 4;
+this build speaks 3). Upgrade rather than migrate:
+  npm install -g failproofai@latest
+```
+
+Le daemon applique la même règle : `failproofaid` refuse de démarrer avec une structure qu'il ne comprend pas, plutôt que de lire et d'écrire des chemins qui ont changé.

package/.next/standalone/docs-old/fr/cli/remove-policies.mdx

@@ -0,0 +1,43 @@
+---
+title: Désinstaller les politiques
+description: "Supprimer les entrées de hook des paramètres de Claude Code"
+---
+
+```bash
+failproofai policies --uninstall [policy-names...] [options]
+```
+
+Supprime les entrées de hook failproofai du fichier `settings.json` de Claude Code.
+
+Alias : `failproofai p -u`
+
+## Options
+
+| Indicateur | Description |
+|------------|-------------|
+| `--scope user` | Supprimer des paramètres globaux (par défaut) |
+| `--scope project` | Supprimer des paramètres du projet |
+| `--scope local` | Supprimer des paramètres locaux |
+| `--scope all` | Supprimer de toutes les portées simultanément |
+| `--custom` / `-c` | Effacer le `customPoliciesPath` de la configuration |
+
+## Comportement
+
+- **Aucun nom de politique** — supprime toutes les entrées de hook failproofai du fichier de paramètres
+- **Noms spécifiques** — désactive ces politiques tout en conservant les hooks installés
+
+## Exemples
+
+```bash
+# Supprimer tous les hooks globalement
+failproofai policies --uninstall
+
+# Désactiver une politique spécifique (conserve les hooks installés)
+failproofai policies --uninstall block-sudo
+
+# Supprimer les hooks de toutes les portées
+failproofai policies --uninstall --scope all
+
+# Effacer le chemin des politiques personnalisées
+failproofai policies --uninstall --custom
+```

package/.next/standalone/docs-old/fr/cli/update.mdx

@@ -0,0 +1,64 @@
+---
+title: Mise à jour après une montée de version
+description: "Finaliser ce que npm ne peut pas faire : migrer le répertoire personnel et synchroniser le daemon"
+---
+
+```bash
+npm install -g failproofai@latest && failproofai update
+```
+
+C'est tout ce qu'il y a à faire pour une mise à jour. `npm` remplace le CLI ; `failproofai update` s'occupe du reste.
+
+## Pourquoi une deuxième commande est nécessaire
+
+`npm install -g` ne remplace qu'une seule chose — le CLI. Deux autres composants d'une installation failproofai résident intentionnellement en dehors du package, et aucun des deux n'est déplacé lors de l'exécution de npm :
+
+- **`~/.failproofai/`**, vos paramètres, l'inscription cloud, la sélection des politiques et l'historique. Une nouvelle version peut organiser ce répertoire différemment, et cette réorganisation doit être effectuée par du code qui connaît les deux structures.
+- **Le binaire du daemon `failproofaid`**, situé dans `~/.failproofai/bin/failproofaid-<version>`. Il ne se trouve délibérément *pas* dans `node_modules` : une mise à jour qui remplacerait le fichier sous un service en cours d'exécution redirigerait un daemon actif vers un binaire construit à partir d'une source différente, et la suppression du package le retirerait d'un service qui entrerait alors en boucle de crash à chaque démarrage.
+
+Ainsi, après `npm install -g` seul, le CLI est à jour mais pas le daemon. `failproofaid` refuse de démarrer avec une structure de répertoire qu'il ne reconnaît pas — une incompatibilité signalée de façon explicite plutôt que silencieuse — et les deux parties doivent donc être synchronisées. `failproofai update` est cette étape.
+
+## Ce que la commande fait
+
+<Steps>
+  <Step title="Exécute les migrations de structure en attente">
+    Lit la structure enregistrée dans `~/.failproofai/VERSION` et exécute les étapes nécessaires pour la mettre au niveau attendu par cette version. En général, aucune migration n'est nécessaire — voir [`failproofai migrate`](/fr/cli/migrate).
+  </Step>
+  <Step title="Met en place le binaire du daemon correspondant">
+    À partir du package de plateforme déjà téléchargé par npm si possible (sans réseau), sinon depuis l'artefact de publication pour cette version exacte, vérifié par SHA-256 avant utilisation.
+  </Step>
+  <Step title="Redémarre le service et confirme qu'il est opérationnel">
+    Vérifié par sondage plutôt que supposé — un gestionnaire de service signale un processus actif dès qu'il est forké, ce qui ne signifie pas pour autant qu'il fonctionne correctement.
+  </Step>
+</Steps>
+
+## Options
+
+| Option | Effet |
+|--------|-------|
+| `--no-daemon` | Migre uniquement le répertoire personnel, en laissant le daemon à sa version actuelle. |
+
+<Warning>
+  `--no-daemon` laisse en place un daemon dont la version est désynchronisée. Sur une machine configurée pour exiger le daemon, chaque événement de hook **échoue en sécurité** si le daemon ne peut pas répondre — et un daemon qui refuse de démarrer avec un répertoire migré ne peut pas répondre. Il est préférable de laisser la partie daemon s'exécuter.
+</Warning>
+
+## En cas de problème
+
+La commande se termine avec un code non nul et indique quelle partie a échoué. Deux cas méritent attention :
+
+- **Une étape de migration ne s'est pas terminée.** Le répertoire est conservé avec son *ancienne* structure, de sorte que la prochaine commande la réessaie — aucun répertoire n'est jamais marqué comme à jour sur la base d'une migration partielle. Des copies de vos paramètres et de votre inscription ont été sauvegardées avant toute exécution, dans `~/.failproofai/migrations/backup-layout<n>/`.
+- **Le daemon n'a pas pu être redémarré sans mot de passe.** `sudo -n` est utilisé délibérément, afin que rien ne demande jamais de saisie depuis un affichage de progression. La commande affiche la ligne exacte à exécuter vous-même.
+
+<Note>
+  Rien dans ce processus ne nécessite l'assistant de configuration interactif. Vos paramètres, votre inscription cloud et votre sélection de politiques survivent à une mise à jour — une machine migrée applique donc exactement les mêmes règles qu'avant, ce qui importe surtout sur les machines sans utilisateur présent : un runner CI, une machine de flotte, une passerelle sans interface graphique.
+</Note>
+
+## Automatisation
+
+`failproofai update` est non interactif et peut être exécuté sans risque même s'il n'y a rien à faire — il indique qu'aucune migration n'était nécessaire et se termine avec le code 0. L'intégrer après chaque mise à jour dans un script de provisionnement ou un Dockerfile est l'usage prévu :
+
+```dockerfile
+RUN npm install -g failproofai@latest && failproofai update --no-daemon
+```
+
+(`--no-daemon` dans une construction d'image, où il n'y a pas encore de service à redémarrer.)

package/.next/standalone/docs-old/fr/cli/version.mdx

@@ -0,0 +1,12 @@
+---
+title: Vérifier la version
+description: "Afficher la version installée de failproofai"
+---
+
+```bash
+failproofai --version
+# or
+failproofai -v
+```
+
+Affiche le numéro de version installé.