failproofai 0.0.5 → 0.0.6-beta.1

package/.next/standalone/docs/fr/architecture.mdx

@@ -4,7 +4,7 @@ description: "Fonctionnement interne du gestionnaire de hooks, du chargement de
 icon: sitemap
 ---
 
-Ce document explique le fonctionnement interne de failproofai : comment le système de hooks intercepte les appels d'outils des agents, comment la configuration est chargée et fusionnée, comment les politiques sont évaluées, et comment le tableau de bord surveille l'activité des agents.
+Ce document explique le fonctionnement interne de failproofai : comment le système de hooks intercepte les appels d'outils de l'agent, comment la configuration est chargée et fusionnée, comment les politiques sont évaluées, et comment le tableau de bord surveille l'activité de l'agent.
 
 ---
 
@@ -12,10 +12,10 @@ Ce document explique le fonctionnement interne de failproofai : comment le syst
 
 failproofai comporte deux sous-systèmes indépendants :
 
-1. **Gestionnaire de hooks** - Un sous-processus CLI rapide que Claude Code invoque à chaque appel d'outil d'agent. Il évalue les politiques et retourne une décision.
+1. **Gestionnaire de hooks** - Un sous-processus CLI rapide que Claude Code invoque à chaque appel d'outil de l'agent. Il évalue les politiques et retourne une décision.
 2. **Moniteur d'agent (Tableau de bord)** - Une application web Next.js pour surveiller les sessions d'agent et gérer les politiques.
 
-Les deux sous-systèmes partagent les fichiers de configuration dans `~/.failproofai/` et le répertoire `.failproofai/` du projet, mais s'exécutent en tant que processus séparés et ne communiquent qu'à travers le système de fichiers.
+Les deux sous-systèmes partagent des fichiers de configuration dans `~/.failproofai/` et le répertoire `.failproofai/` du projet, mais ils s'exécutent en tant que processus séparés et ne communiquent que via le système de fichiers.
 
 ---
 
@@ -23,7 +23,7 @@ Les deux sous-systèmes partagent les fichiers de configuration dans `~/.failpro
 
 ### Intégration avec Claude Code
 
-Lorsque vous exécutez `failproofai policies --install`, des entrées comme celle-ci sont écrites dans `~/.claude/settings.json` :
+Lorsque vous exécutez `failproofai policies --install`, il écrit des entrées comme celle-ci dans `~/.claude/settings.json` :
 
 ```json
 {
@@ -44,7 +44,7 @@ Lorsque vous exécutez `failproofai policies --install`, des entrées comme cell
 }
 ```
 
-Claude Code invoque ensuite `failproofai --hook PreToolUse` en tant que sous-processus avant chaque appel d'outil, en transmettant un payload JSON sur stdin.
+Claude Code invoque ensuite `failproofai --hook PreToolUse` comme sous-processus avant chaque appel d'outil, en transmettant un payload JSON sur stdin.
 
 ### Format du payload
 
@@ -62,7 +62,7 @@ Claude Code invoque ensuite `failproofai --hook PreToolUse` en tant que sous-pro
 
 Pour les événements `PostToolUse`, le payload contient également `tool_result` avec la sortie de l'outil.
 
-Le gestionnaire impose une limite de 1 Mo sur stdin. Les payloads dépassant cette limite sont ignorés et toutes les politiques autorisent implicitement.
+Le gestionnaire impose une limite de 1 Mo sur stdin. Les payloads dépassant cette taille sont ignorés et toutes les politiques autorisent implicitement.
 
 ### Format de la réponse
 
@@ -94,7 +94,7 @@ Le gestionnaire impose une limite de 1 Mo sur stdin. Les payloads dépassant cet
 }
 ```
 
-**Instruction sur l'événement Stop :**
+**Instruction pour l'événement Stop :**
 - Code de sortie : `2`
 - Raison écrite sur stderr (pas sur stdout)
 
@@ -116,7 +116,7 @@ Le gestionnaire impose une limite de 1 Mo sur stdin. Les payloads dépassant cet
 ```
 - Code de sortie : `0` (l'opération est autorisée)
 - Lorsque plusieurs politiques retournent `allow` avec un message, leurs messages sont joints par des sauts de ligne en une seule chaîne `additionalContext`
-- Si aucune politique ne fournit de message, stdout est vide (comme auparavant)
+- Si aucune politique ne fournit de message, stdout est vide (comme précédemment)
 
 ### Pipeline de traitement
 
@@ -124,19 +124,19 @@ Le gestionnaire impose une limite de 1 Mo sur stdin. Les payloads dépassant cet
 
 ```text
 stdin JSON
-  → analyser le payload (max 1 Mo)
-  → extraire les métadonnées de session (session_id, cwd, tool_name, tool_input, etc.)
-  → readMergedHooksConfig(cwd)    ← fusionne la config projet + locale + globale
-  → enregistrer les politiques intégrées activées avec les paramètres résolus
-  → charger les politiques personnalisées depuis customPoliciesPath (si défini)
-  → enregistrer les politiques personnalisées dans le registre de politiques
-  → évaluer toutes les politiques (intégrées en premier, puis personnalisées)
-      → le premier refus court-circuite
-      → les décisions d'instruction s'accumulent
-      → les messages d'autorisation s'accumulent
-  → écrire la décision JSON sur stdout
-  → persister l'événement dans ~/.failproofai/hook-activity.jsonl
-  → quitter
+  → parse payload (max 1 MB)
+  → extract session metadata (session_id, cwd, tool_name, tool_input, etc.)
+  → readMergedHooksConfig(cwd)    ← merges project + local + global config
+  → register enabled builtin policies with resolved params
+  → load custom policies from customPoliciesPath (if set)
+  → register custom policies into policy registry
+  → evaluate all policies (builtins first, then custom)
+      → first deny short-circuits
+      → instruct decisions accumulate
+      → allow messages accumulate
+  → write JSON decision to stdout
+  → persist event to ~/.failproofai/hook-activity.jsonl
+  → exit
 ```
 
 L'ensemble du processus s'exécute en moins de 100 ms pour les payloads typiques, sans aucun appel LLM.
@@ -145,7 +145,7 @@ L'ensemble du processus s'exécute en moins de 100 ms pour les payloads typiques
 
 ## Chargement de la configuration
 
-`src/hooks/hooks-config.ts` implémente le chargement de configuration à trois portées.
+`src/hooks/hooks-config.ts` implémente le chargement de la configuration sur trois niveaux.
 
 ```text
 [1] {cwd}/.failproofai/policies-config.json        ← projet   (priorité la plus haute)
@@ -156,8 +156,8 @@ L'ensemble du processus s'exécute en moins de 100 ms pour les payloads typiques
 Logique de fusion :
 - `enabledPolicies` - union dédupliquée sur les trois fichiers
 - `policyParams` - par clé de politique, le premier fichier qui la définit l'emporte entièrement
-- `customPoliciesPath` - le premier fichier qui le définit l'emporte
-- `llm` - le premier fichier qui le définit l'emporte
+- `customPoliciesPath` - le premier fichier qui la définit l'emporte
+- `llm` - le premier fichier qui la définit l'emporte
 
 Le tableau de bord web utilise `readHooksConfig()` (global uniquement) pour la lecture et l'écriture, car il n'est pas invoqué avec un répertoire de travail de projet.
 
@@ -171,7 +171,7 @@ Pour chaque politique :
 
 1. Rechercher le schéma `params` de la politique (si elle en possède un).
 2. Lire `policyParams[policy.name]` depuis la configuration fusionnée.
-3. Fusionner les valeurs fournies par l'utilisateur sur les valeurs par défaut du schéma pour produire `ctx.params`.
+3. Fusionner les valeurs fournies par l'utilisateur avec les valeurs par défaut du schéma pour produire `ctx.params`.
 4. Appeler `policy.fn(ctx)` avec le contexte résolu.
 5. Si le résultat est `deny`, s'arrêter immédiatement et retourner cette décision.
 6. Si le résultat est `instruct`, accumuler le message et continuer.
@@ -180,7 +180,7 @@ Pour chaque politique :
 Après l'exécution de toutes les politiques :
 - Si un `deny` a été retourné, émettre la réponse de refus.
 - Si des retours `instruct` ont été collectés, émettre une seule réponse d'instruction avec tous les messages joints.
-- Sinon, émettre une réponse d'autorisation (stdout vide, code de sortie 0).
+- Sinon, émettre une réponse d'autorisation (stdout vide, exit 0).
 
 ---
 
@@ -204,15 +204,15 @@ interface BuiltinPolicyDefinition {
 }
 ```
 
-Les politiques qui acceptent des `params` déclarent un `PolicyParamsSchema` avec les types et les valeurs par défaut de chaque paramètre. L'évaluateur de politiques injecte les valeurs résolues dans `ctx.params` avant d'appeler `fn`. Les fonctions de politique lisent `ctx.params` sans vérification de nullité, car les valeurs par défaut sont toujours appliquées en premier.
+Les politiques qui acceptent des `params` déclarent un `PolicyParamsSchema` avec des types et des valeurs par défaut pour chaque paramètre. L'évaluateur de politiques injecte les valeurs résolues dans `ctx.params` avant d'appeler `fn`. Les fonctions de politique lisent `ctx.params` sans protection contre les valeurs nulles, car les valeurs par défaut sont toujours appliquées en premier.
 
-La correspondance de motifs à l'intérieur des politiques utilise des tokens de commande analysés (argv), et non une correspondance de chaînes brutes. Cela empêche le contournement via l'injection d'opérateurs shell (par exemple, un motif pour `sudo systemctl status *` ne peut pas être contourné en ajoutant `; rm -rf /` à la commande).
+La correspondance de motifs à l'intérieur des politiques utilise des tokens de commande analysés (argv), et non une correspondance de chaînes brutes. Cela empêche les contournements via l'injection d'opérateurs shell (par exemple, un motif pour `sudo systemctl status *` ne peut pas être contourné en ajoutant `; rm -rf /` à la commande).
 
 ---
 
 ## Politiques personnalisées
 
-`src/hooks/custom-hooks-registry.ts` implémente un registre basé sur `globalThis` :
+`src/hooks/custom-hooks-registry.ts` implémente un registre adossé à `globalThis` :
 
 ```typescript
 const REGISTRY_KEY = "__failproofai_custom_hooks__";
@@ -228,14 +228,14 @@ export function clearCustomHooks(): void { ... }  // used in tests
 `src/hooks/custom-hooks-loader.ts` charge le fichier de politique de l'utilisateur :
 
 1. Lire `customPoliciesPath` depuis la configuration ; ignorer si absent.
-2. Résoudre le chemin absolu ; vérifier que le fichier existe.
-3. Réécrire tous les imports `from "failproofai"` vers le chemin dist réel afin que `customPolicies` résolve vers le même registre `globalThis`.
+2. Résoudre vers un chemin absolu ; vérifier que le fichier existe.
+3. Réécrire tous les imports `from "failproofai"` vers le chemin dist réel afin que `customPolicies` se résolve vers le même registre `globalThis`.
 4. Réécrire récursivement les imports locaux transitifs pour assurer la compatibilité ESM.
 5. Écrire des fichiers `.mjs` temporaires et `import()` le fichier d'entrée.
 6. Appeler `getCustomHooks()` pour récupérer les hooks enregistrés.
 7. Nettoyer tous les fichiers temporaires dans un bloc `finally`.
 
-En cas d'erreur (fichier introuvable, erreur de syntaxe, échec d'import), l'erreur est consignée dans `~/.failproofai/hook.log` et le chargeur retourne un tableau vide. Les politiques intégrées ne sont pas affectées.
+En cas d'erreur (fichier non trouvé, erreur de syntaxe, échec d'import), l'erreur est consignée dans `~/.failproofai/hook.log` et le chargeur retourne un tableau vide. Les politiques intégrées ne sont pas affectées.
 
 Les politiques personnalisées sont évaluées après toutes les politiques intégrées. Un `deny` d'une politique personnalisée court-circuite quand même les politiques personnalisées suivantes (mais toutes les politiques intégrées ont déjà été exécutées à ce stade).
 
@@ -243,7 +243,7 @@ Les politiques personnalisées sont évaluées après toutes les politiques int
 
 ## Journalisation de l'activité
 
-Après chaque événement de hook, le gestionnaire ajoute une ligne JSONL dans `~/.failproofai/hook-activity.jsonl` :
+Après chaque événement de hook, le gestionnaire ajoute une ligne JSONL à `~/.failproofai/hook-activity.jsonl` :
 
 ```json
 {
@@ -258,24 +258,24 @@ Après chaque événement de hook, le gestionnaire ajoute une ligne JSONL dans `
 }
 ```
 
-Une ligne par politique ayant pris une décision autre que allow. Les décisions d'autorisation ne sont pas journalisées (pour maintenir la taille du fichier réduite).
+Une ligne par politique ayant pris une décision autre que allow. Les décisions allow ne sont pas journalisées (pour garder le fichier léger).
 
 ---
 
 ## Architecture du tableau de bord
 
-Le tableau de bord est une application **Next.js 16** utilisant l'App Router avec des React Server Components et des Server Actions.
+Le tableau de bord est une application **Next.js 16** utilisant l'App Router avec les React Server Components et les Server Actions.
 
 ```text
 app/
-  layout.tsx                  ← Mise en page racine (thème, télémétrie, nav)
+  layout.tsx                  ← Mise en page racine (thème, télémétrie, navigation)
   projects/page.tsx           ← Composant serveur : liste tous les projets Claude
   project/[name]/page.tsx     ← Composant serveur : liste les sessions d'un projet
   project/[name]/session/
     [sessionId]/page.tsx      ← Composant serveur : affiche le visualiseur de session
   policies/page.tsx           ← Composant client : gestion des politiques + journal d'activité
   actions/
-    get-hooks-config.ts       ← Lire la config + la liste des politiques
+    get-hooks-config.ts       ← Lire la configuration + liste des politiques
     update-hooks-config.ts    ← Activer/désactiver une politique
     update-policy-params.ts   ← Mettre à jour les paramètres d'une politique
     get-hook-activity.ts      ← Paginer/rechercher dans le journal d'activité
@@ -287,19 +287,19 @@ app/
 **Flux de données :**
 
 - Les composants de page appellent `lib/projects.ts` et `lib/log-entries.ts` pour lire les données de projet/session directement depuis le système de fichiers (pas de couche API pour les lectures).
-- La page Politiques utilise des Server Actions pour toutes les mutations (activation/désactivation, mise à jour des paramètres, installation/suppression).
-- Le visualiseur de session analyse le format de transcript JSONL de Claude et affiche une chronologie des messages et des appels d'outils.
+- La page Politiques utilise les Server Actions pour toutes les mutations (activation/désactivation, mise à jour des paramètres, installation/suppression).
+- Le visualiseur de session analyse le format de transcription JSONL de Claude et affiche une chronologie des messages et des appels d'outils.
 
 **Décisions de conception clés :**
 
-- Pas de base de données - tout l'état persistant est dans des fichiers simples (`~/.failproofai/`, `~/.claude/projects/`).
-- Server Actions pour les mutations - aucune API REST nécessaire pour les opérations CRUD.
+- Pas de base de données - tout l'état persistant est dans des fichiers plats (`~/.failproofai/`, `~/.claude/projects/`).
+- Server Actions pour les mutations - pas d'API REST nécessaire pour les opérations CRUD.
 - React Server Components pour les pages de lecture - chargement initial plus rapide, pas de bundle client pour la récupération des données.
-- Composants client uniquement là où l'interactivité est nécessaire (bascules de politique, recherche d'activité, visualiseur de journal).
+- Composants client uniquement là où l'interactivité est nécessaire (activation des politiques, recherche dans l'activité, visualiseur de journaux).
 
 ---
 
-## Organisation des fichiers
+## Structure des fichiers
 
 ```text
 failproofai/
@@ -309,23 +309,23 @@ failproofai/
 │   ├── handler.ts                # Pipeline d'événements de hook
 │   ├── builtin-policies.ts       # 26 définitions de politiques
 │   ├── policy-evaluator.ts       # Moteur d'exécution des politiques
-│   ├── policy-registry.ts        # Enregistrement et recherche de politiques
+│   ├── policy-registry.ts        # Enregistrement et recherche des politiques
 │   ├── policy-types.ts           # Interfaces TypeScript
-│   ├── hooks-config.ts           # Chargement de configuration multi-portée
-│   ├── custom-hooks-registry.ts  # Registre de hooks basé sur globalThis
+│   ├── hooks-config.ts           # Chargement de la configuration multi-niveaux
+│   ├── custom-hooks-registry.ts  # Registre de hooks adossé à globalThis
 │   ├── custom-hooks-loader.ts    # Chargeur ESM pour les hooks JS utilisateur
-│   ├── manager.ts                # Opérations install / remove / list
-│   ├── install-prompt.ts         # Invite de sélection interactive des politiques
+│   ├── manager.ts                # Opérations d'installation / suppression / liste
+│   ├── install-prompt.ts         # Invite interactive de sélection des politiques
 │   ├── hook-logger.ts            # Journalisation vers hook.log
-│   ├── hook-activity-store.ts    # Persistance de l'activité dans hook-activity.jsonl
-│   └── llm-client.ts             # Client API LLM (pour les politiques pilotées par IA)
+│   ├── hook-activity-store.ts    # Persistance de l'activité vers hook-activity.jsonl
+│   └── llm-client.ts             # Client API LLM (pour les politiques basées sur l'IA)
 ├── app/                          # Tableau de bord Next.js (pages + server actions)
 ├── lib/                          # Utilitaires partagés
-│   ├── projects.ts               # Enumération des projets Claude depuis le système de fichiers
-│   ├── log-entries.ts            # Analyse du format JSONL des transcripts Claude
+│   ├── projects.ts               # Énumération des projets Claude depuis le système de fichiers
+│   ├── log-entries.ts            # Analyse du format JSONL des transcriptions Claude
 │   ├── paths.ts                  # Résolution des chemins système
 │   └── ...
-├── components/                   # Composants React UI partagés
+├── components/                   # Composants UI React partagés
 ├── contexts/                     # Fournisseurs de contexte React (thème, actualisation automatique, télémétrie)
 ├── examples/                     # Exemples de fichiers de hooks personnalisés
 └── __tests__/                    # Tests unitaires et E2E

package/.next/standalone/docs/fr/configuration.mdx

@@ -1,10 +1,10 @@
 ---
 title: Configuration
-description: "Format du fichier de configuration, système à trois portées et règles de fusion"
+description: "Format des fichiers de configuration, système à trois portées et règles de fusion"
 icon: gear
 ---
 
-failproofai utilise des fichiers de configuration JSON pour contrôler quelles politiques sont actives, leur comportement et l'emplacement des politiques personnalisées. La configuration est conçue pour être facilement partageable avec votre équipe — committez-la dans votre dépôt et chaque développeur bénéficie du même filet de sécurité pour l'agent.
+failproofai utilise des fichiers de configuration JSON pour contrôler quelles politiques sont actives, leur comportement, et les chemins de chargement des politiques personnalisées. La configuration est conçue pour être facilement partagée avec votre équipe — commitez-la dans votre dépôt et chaque développeur bénéficie du même filet de sécurité pour les agents.
 
 ---
 
@@ -13,16 +13,16 @@ failproofai utilise des fichiers de configuration JSON pour contrôler quelles p
 Il existe trois portées de configuration, évaluées par ordre de priorité :
 
 | Portée | Chemin du fichier | Objectif |
-|--------|-------------------|----------|
-| **project** | `.failproofai/policies-config.json` | Paramètres par dépôt, committés dans le contrôle de version |
+|--------|-------------------|---------|
+| **project** | `.failproofai/policies-config.json` | Paramètres par dépôt, commités dans le contrôle de version |
 | **local** | `.failproofai/policies-config.local.json` | Surcharges personnelles par dépôt, ignorées par git |
-| **global** | `~/.failproofai/policies-config.json` | Paramètres par défaut au niveau utilisateur pour tous les projets |
+| **global** | `~/.failproofai/policies-config.json` | Valeurs par défaut au niveau utilisateur pour tous les projets |
 
-Quand failproofai reçoit un événement de hook, il charge et fusionne les trois fichiers existants pour le répertoire de travail courant.
+Lorsque failproofai reçoit un événement de hook, il charge et fusionne les trois fichiers qui existent pour le répertoire de travail courant.
 
 ### Règles de fusion
 
-**`enabledPolicies`** — union des trois portées. Une politique activée à n'importe quel niveau est active.
+**`enabledPolicies`** — l'union des trois portées. Une politique activée à n'importe quel niveau est active.
 
 ```text
 project:  ["block-sudo"]
@@ -32,7 +32,7 @@ global:   ["block-sudo", "sanitize-api-keys"]
 resolved: ["block-sudo", "block-rm-rf", "sanitize-api-keys"]  ← union dédupliquée
 ```
 
-**`policyParams`** — la première portée qui définit les paramètres d'une politique donnée l'emporte entièrement. Il n'y a pas de fusion profonde des valeurs au sein des paramètres d'une politique.
+**`policyParams`** — la première portée qui définit des paramètres pour une politique donnée l'emporte entièrement. Il n'y a pas de fusion profonde des valeurs au sein des paramètres d'une politique.
 
 ```text
 project:  block-sudo → { allowPatterns: ["sudo apt-get update"] }
@@ -46,7 +46,7 @@ project:  (aucune entrée block-sudo)
 local:    (aucune entrée block-sudo)
 global:   block-sudo → { allowPatterns: ["sudo systemctl status"] }
 
-resolved: { allowPatterns: ["sudo systemctl status"] }  ← retombe sur global
+resolved: { allowPatterns: ["sudo systemctl status"] }  ← repli sur global
 ```
 
 **`customPoliciesPath`** — la première portée qui le définit l'emporte.
@@ -112,7 +112,7 @@ Type : `Record<string, Record<string, unknown>>`
 
 Surcharges de paramètres par politique. La clé externe est le nom de la politique ; les clés internes sont spécifiques à chaque politique. Chaque politique documente ses paramètres disponibles dans [Politiques intégrées](/fr/built-in-policies).
 
-Si une politique possède des paramètres mais que vous ne les spécifiez pas, les valeurs par défaut intégrées de la politique sont utilisées. Les utilisateurs qui ne configurent pas `policyParams` du tout obtiennent un comportement identique aux versions précédentes.
+Si une politique possède des paramètres que vous ne spécifiez pas, les valeurs par défaut intégrées de la politique sont utilisées. Les utilisateurs qui ne configurent pas `policyParams` du tout obtiennent un comportement identique aux versions précédentes.
 
 Les clés inconnues dans le bloc de paramètres d'une politique sont silencieusement ignorées au moment du déclenchement du hook, mais signalées comme avertissements lors de l'exécution de `failproofai policies`.
 
@@ -122,7 +122,7 @@ Type : `string` (optionnel)
 
 Un message ajouté à la raison lorsqu'une politique retourne `deny` ou `instruct`. Utilisez-le pour donner à Claude des indications exploitables sans modifier la politique elle-même.
 
-Fonctionne avec n'importe quel type de politique — intégrée, personnalisée (`custom/`), convention de projet (`.failproofai-project/`), ou convention utilisateur (`.failproofai-user/`).
+Fonctionne avec tout type de politique — intégrée, personnalisée (`custom/`), convention de projet (`.failproofai-project/`) ou convention utilisateur (`.failproofai-user/`).
 
 ```json
 {
@@ -141,40 +141,40 @@ Fonctionne avec n'importe quel type de politique — intégrée, personnalisée
 }
 ```
 
-Lorsque `block-force-push` refuse, Claude voit : *« Force-pushing is blocked. Try creating a fresh branch instead. »*
+Lorsque `block-force-push` bloque, Claude voit : *« Le push forcé est bloqué. Try creating a fresh branch instead. »*
 
-Les valeurs non-chaînes et les chaînes vides sont silencieusement ignorées. Si `hint` n'est pas défini, le comportement est inchangé (rétrocompatible).
+Les valeurs non-chaînes et les chaînes vides sont silencieusement ignorées. Si `hint` n'est pas défini, le comportement reste inchangé (rétrocompatible).
 
 ### `customPoliciesPath`
 
 Type : `string` (chemin absolu)
 
-Chemin vers un fichier JavaScript contenant des politiques de hook personnalisées. Ce champ est défini automatiquement par `failproofai policies --install --custom <path>` (le chemin est résolu en chemin absolu avant d'être enregistré).
+Chemin vers un fichier JavaScript contenant des politiques de hook personnalisées. Ce champ est défini automatiquement par `failproofai policies --install --custom <path>` (le chemin est résolu en chemin absolu avant d'être stocké).
 
-Le fichier est chargé à chaque événement de hook — il n'y a pas de mise en cache. Consultez [Politiques personnalisées](/fr/custom-policies) pour les détails de création.
+Le fichier est rechargé à chaque événement de hook — il n'y a pas de mise en cache. Consultez [Politiques personnalisées](/fr/custom-policies) pour les détails de création.
 
 ### Politiques basées sur les conventions
 
 En plus du `customPoliciesPath` explicite, failproofai découvre et charge automatiquement les fichiers de politiques depuis les répertoires `.failproofai/policies/` :
 
 | Niveau | Répertoire | Portée |
-|--------|-----------|--------|
+|--------|------------|--------|
 | Projet | `.failproofai/policies/` | Partagé avec l'équipe via le contrôle de version |
 | Utilisateur | `~/.failproofai/policies/` | Personnel, s'applique à tous les projets |
 
 **Correspondance de fichiers :** Seuls les fichiers correspondant à `*policies.{js,mjs,ts}` sont chargés (par exemple `security-policies.mjs`, `workflow-policies.js`). Les autres fichiers du répertoire sont ignorés.
 
-**Aucune configuration nécessaire :** Les politiques de convention ne nécessitent aucune entrée dans `policies-config.json`. Déposez simplement les fichiers dans le répertoire et ils seront pris en compte au prochain événement de hook.
+**Aucune configuration requise :** Les politiques de convention ne nécessitent aucune entrée dans `policies-config.json`. Il suffit de déposer des fichiers dans le répertoire et ils seront pris en compte au prochain événement de hook.
 
-**Chargement par union :** Les répertoires de convention du projet et de l'utilisateur sont tous deux analysés. Tous les fichiers correspondants des deux niveaux sont chargés (contrairement à `customPoliciesPath` qui utilise la règle du premier gagnant).
+**Chargement par union :** Les répertoires de convention du projet et de l'utilisateur sont tous deux analysés. Tous les fichiers correspondants des deux niveaux sont chargés (contrairement à `customPoliciesPath` qui utilise la règle « première portée gagnante »).
 
-Consultez [Politiques personnalisées](/fr/custom-policies) pour plus de détails et des exemples.
+Consultez [Politiques personnalisées](/fr/custom-policies) pour plus de détails et d'exemples.
 
 ### `llm`
 
 Type : `object` (optionnel)
 
-Configuration du client LLM pour les politiques qui effectuent des appels à l'IA. Non requis pour la plupart des configurations.
+Configuration du client LLM pour les politiques effectuant des appels à l'IA. Non requis dans la plupart des configurations.
 
 ```json
 {
@@ -187,20 +187,20 @@ Configuration du client LLM pour les politiques qui effectuent des appels à l'I
 
 ---
 
-## Gestion de la configuration depuis l'interface en ligne de commande
+## Gestion de la configuration depuis la CLI
 
 Les commandes `policies --install` et `policies --uninstall` écrivent dans le fichier `settings.json` de Claude Code (les points d'entrée des hooks), tandis que `policies-config.json` est le fichier que vous gérez directement. Les deux sont distincts :
 
 - **`settings.json`** — indique à Claude Code d'appeler `failproofai --hook <event>` à chaque utilisation d'outil
 - **`policies-config.json`** — indique à failproofai quelles politiques évaluer et avec quels paramètres
 
-Vous pouvez modifier `policies-config.json` directement à tout moment ; les modifications prennent effet immédiatement au prochain événement de hook, sans redémarrage nécessaire.
+Vous pouvez modifier `policies-config.json` directement à tout moment ; les changements prennent effet immédiatement au prochain événement de hook, sans redémarrage nécessaire.
 
 ---
 
-## Exemple : configuration au niveau projet avec les paramètres par défaut de l'équipe
+## Exemple : configuration au niveau projet avec des valeurs par défaut d'équipe
 
-Committez `.failproofai/policies-config.json` dans votre dépôt :
+Commitez `.failproofai/policies-config.json` dans votre dépôt :
 
 ```json
 {
@@ -219,4 +219,4 @@ Committez `.failproofai/policies-config.json` dans votre dépôt :
 }
 ```
 
-Chaque développeur peut ensuite créer `.failproofai/policies-config.local.json` (ignoré par git) pour ses surcharges personnelles sans affecter ses coéquipiers.
+Chaque développeur peut ensuite créer `.failproofai/policies-config.local.json` (ignoré par git) pour des surcharges personnelles sans affecter ses coéquipiers.