failproofai 1.0.1-beta.0 → 1.0.1

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

@@ -0,0 +1,151 @@
+---
+title: Dashboard
+description: "Surveiller les sessions d'agents, examiner les appels d'outils et gérer les politiques"
+icon: chart-line
+---
+
+Le dashboard failproofai est une application web locale permettant de surveiller vos sessions d'agents IA et de gérer les politiques. Voyez ce que vos agents ont fait pendant votre absence.
+
+---
+
+## Démarrer le dashboard
+
+```bash
+failproofai
+```
+
+S'ouvre à l'adresse `http://localhost:8020`.
+
+Le dashboard lit les données de configuration locales du projet, des sessions et de failproofai directement depuis le système de fichiers. Les fonctionnalités optionnelles authentifiées, telles que les rappels d'audit et les invitations, transmettent les informations nécessaires à ces requêtes (y compris les adresses e-mail) vers des API distantes.
+
+---
+
+## Pages
+
+### Projets
+
+Liste tous les projets Claude Code, OpenAI Codex, GitHub Copilot CLI _(bêta)_, Cursor Agent _(bêta)_, OpenCode _(bêta)_, Pi _(bêta)_, Hermes, OpenClaw, Factory Droid, Devin, Antigravity et Goose trouvés sur votre machine. Les projets Claude sont découverts depuis `~/.claude/projects/` (ou le chemin défini par `CLAUDE_PROJECTS_PATH`) ; les projets Codex sont découverts en analysant chaque transcription sous `~/.codex/sessions/<YYYY>/<MM>/<DD>/*.jsonl` et regroupés par le `cwd` enregistré dans le premier enregistrement de chaque session ; les projets Copilot CLI sont découverts en analysant chaque fichier `~/.copilot/session-state/<sessionId>/workspace.yaml` (configurable via `COPILOT_HOME`) et regroupés par son champ `cwd` ; les projets Cursor Agent sont découverts en analysant les métadonnées par session sous `~/.cursor/agent-sessions/<sessionId>/` (configurable via `CURSOR_HOME`, avec `conversations/` et `sessions/` sondés comme alternatives) pour un scalaire `cwd` dans `meta.json` / `session.json` / `workspace.yaml` ; les projets OpenCode sont découverts en interrogeant sa base de données SQLite à `~/.local/share/opencode/opencode.db` via `opencode db --format json` (nous lisons les tables `session` et `project` et regroupons par `project_id`) ; les projets Pi sont découverts en analysant les transcriptions JSONL par session sous `~/.pi/agent/sessions/<encoded-cwd>/<timestamp>_<uuid>.jsonl` (configurable via `PI_SESSIONS_DIR`) et en extrayant le `cwd` du premier enregistrement de chaque session ; les sessions de passerelle Hermes sont lues directement depuis le magasin SQLite de chaque profil — `~/.hermes/state.db` plus `~/.hermes/profiles/<name>/state.db` (remplaçable via `HERMES_HOME`, ou `HERMES_DB_PATH` pour une seule base de données) — et regroupées en projets `hermes-<profile>-<source>` par profil et `source` (Slack/Telegram/cli/cron — les sessions de passerelle n'ont pas de cwd) ; les sessions de passerelle OpenClaw sont lues depuis `~/.openclaw/agents/<agentId>/sessions/*.jsonl` et regroupées en projets `openclaw-<agentId>-<channel>` par agent et canal (également sans cwd) ; les projets Factory Droid sont découverts depuis les transcriptions JSONL à `~/.factory/sessions/<encoded-cwd>/*.jsonl` et regroupés par cwd ; les projets Devin depuis sa base de données SQLite à `~/.local/share/devin/cli/sessions.db` (regroupés par le `working_directory` de chaque session) ; les projets Antigravity depuis les transcriptions JSONL à `~/.gemini/antigravity-cli/brain/<conversationId>/…/transcript_full.jsonl` et regroupés par cwd ; et les projets Goose depuis sa base de données SQLite à `~/.local/share/goose/sessions/sessions.db` (regroupés par le `working_dir` de chaque session). Un projet utilisé par plusieurs CLI s'affiche sur une seule ligne avec tous les badges correspondants. Utilisez le menu déroulant **CLI** au-dessus du tableau pour filtrer par un agent CLI spécifique ; l'URL conserve votre sélection sous la forme `?cli=claude|codex|copilot|cursor|opencode|pi|hermes|openclaw|factory|devin|antigravity|goose`.
+
+Hermes et OpenClaw sont limités à l'utilisateur et n'ont pas de répertoire de travail pour le regroupement, ils s'affichent donc sous forme d'**arborescence repliable** — profil (ou agent) au premier niveau, ses canaux en dessous — tandis que chaque CLI basé sur un cwd reste une ligne plate. Les lignes de dossier cumulent le nombre de sessions et l'activité la plus récente de tout ce qu'elles contiennent, les dossiers réduits sont mémorisés entre les visites, et une recherche par mot-clé développe tout ce qui correspond.
+
+Chaque projet affiche :
+- Le nom du projet (dérivé du chemin du dossier)
+- Un badge CLI — `Claude Code` (orange), `OpenAI Codex` (violet), `GitHub Copilot` (bleu), `Cursor Agent` (émeraude), `OpenCode` (ambre), `Pi` (rose) et/ou `Hermes` (indigo)
+- La date de l'activité de session la plus récente
+
+Cliquez sur un projet pour voir ses sessions.
+
+### Sessions
+
+Liste toutes les sessions au sein d'un projet. Chaque session affiche :
+- L'identifiant de session
+- Les horodatages de début et de fin
+- Le nombre d'appels d'outils
+- Le nombre d'activités de hook (politiques déclenchées)
+
+Utilisez le filtre de plage de dates et la recherche par identifiant de session pour affiner la liste. Les sessions sont paginées.
+
+Cliquez sur une session pour ouvrir le visualiseur de session.
+
+### Visualiseur de session
+
+Le visualiseur de session répond à la question clé pour les agents autonomes : qu'a fait l'agent, et est-il resté dans les limites fixées ? Un badge CLI à côté de l'en-tête indique si la session est une transcription Claude Code, OpenAI Codex, GitHub Copilot CLI, Cursor Agent, OpenCode, Pi, Hermes, OpenClaw, Factory Droid, Devin, Antigravity ou Goose. Il affiche une chronologie de tout ce qui s'est passé durant une session :
+
+- **Messages** - Les réponses textuelles de Claude et les invites utilisateur
+- **Appels d'outils** - Chaque outil invoqué par Claude, avec son entrée et sa sortie
+- **Activité des politiques** - Pour chaque appel d'outil, quelles politiques se sont déclenchées et quelle décision elles ont rendu
+
+La barre de statistiques en haut affiche la durée de la session, le nombre total d'appels d'outils et un résumé des décisions de hook (comptages allow / deny / instruct).
+
+Cliquez sur le bouton **Télécharger les journaux** pour exporter la session. Pour les sessions Claude Code, Codex, Copilot, Cursor et Pi, vous obtenez la transcription JSONL originale sur disque octet par octet ; pour OpenCode (dont les sessions résident dans SQLite et non sur disque), vous obtenez un document JSON reflétant les tables sous-jacentes `session` / `messages` / `parts`.
+
+### Audit
+
+Un rapport à personnalité qui rend compte du comportement réel de votre agent sur les sessions passées. Exécute la même analyse que la CLI `failproofai audit` mais l'affiche sous forme d'une affiche partageable en plein écran + quatre sections sous le pli :
+
+1. **Affiche** — occupe le premier viewport. Zone de capture PNG autonome avec le logo failproof_ai + libellé d'audit · index d'archétype (`№ NN of 08`) + date d'audit · score numérique (0–100) + pastille de rang percentile (`top 15%`) · le nom de l'archétype (l'un parmi `the optimist`, `the cowboy`, `the explorer`, `the goldfish`, `the paranoid architect`, `the precision builder`, `the hammer`, `the ghost`) + bande de 3 mots-clés · ligne de rareté `// only N% of agents are this archetype` · tuile de sigil 8×8 pixels · pied de page `audit yours → failproof.ai`. Trois boutons de partage se trouvent juste en dehors de la zone de capture : `post your archetype` (intention X), `share on linkedin`, `download poster`. La capture s'effectue via `html-to-image` afin que le PNG corresponde pixel par pixel au rendu à l'écran (bordures en pointillés, masque de logo SVG, dégradés, métriques de police — tout est préservé).
+2. **Points forts** — liste de comportements que votre agent réalise déjà correctement, dérivés des données d'audit en direct (taux d'appels d'outils propres, pas de push direct sur main, zéro fuite d'identifiants, zéro tempête de nouvelles tentatives) — chacun affiché uniquement lorsque la politique concernée présente un bilan propre sur la fenêtre d'audit.
+3. **Comportements inhabituels** — tableau de ce qui est passé au travers, classé par sévérité : `quand · ce qui a passé + la politique qui l'aurait intercepté · pastille de sévérité · observé`, où la récurrence indique `new` (une fois), `N× seen` (2–9 fois) ou `recurring` (10+).
+4. **Comment s'améliorer** — liste calme, une entrée par politique prescrite : nom de la politique en blanc, description en une ligne, commande d'installation + bouton de copie sur le côté droit. L'en-tête de section indique `enable all N → projected <score> · <tier>` (le score que vous atteindriez avec tous les correctifs appliqués), et son bouton `[install all]` copie la commande combinée `failproofai policy add a b c …` pour chaque politique prescrite.
+5. **Revenez meilleur** — deux cartes côte à côte. À gauche : définir un rappel (sélecteur de cadence `3d` / `7d` / `14d` / `30d` ; persiste via `/api/auth/reminder` une fois authentifié). À droite : débloquer des avantages failproof — `invite a friend` ouvre une fenêtre modale acceptant une liste d'adresses e-mail d'amis séparées par des virgules/espaces/sauts de ligne (10 maximum par envoi), les envoie via POST à `/api/audit/invite`, qui les transmet au `POST /v0/invite` du serveur API. Le serveur API envoie un e-mail par destinataire depuis `invite@failproof.ai` avec l'expéditeur en Cc et `Reply-To` défini, de sorte que le destinataire voit qui l'a invité et l'expéditeur reçoit une copie dans sa boîte de réception. Les utilisateurs anonymes sont d'abord redirigés via `AuthDialog` afin que l'adresse e-mail de l'expéditeur soit connue avant l'envoi des invitations. La gestion des droits / avantages est prévue dans une prochaine étape.
+
+Alimenté par le moteur d'exécution `failproofai audit` — voir [CLI Audit](/fr/cli/audit) pour le moteur d'analyse sous-jacent, les indicateurs pris en charge et les invariants de cache par transcription. Le dashboard met en cache le dernier résultat dans `~/.failproofai/audit-dashboard.json` (mode `0600`, emplacement unique, les nouvelles exécutions écrasent) afin que les revisites soient instantanées ; **les caches par transcription et par résultat complet sont tous deux rejetés à la lecture s'ils ont plus de 7 jours**, ainsi le dashboard ne sert jamais silencieusement un résultat vieux d'une semaine — passé la TTL, `/audit` retombe sur son état vide et invite à relancer une analyse. Cliquer sur `[ re-audit now ]` près du bas du rapport envoie un POST `/api/audit/run` avec `noCache: true` — la ré-analyse contourne le cache par transcription et réanalyse chaque transcription depuis le début plutôt que de retourner silencieusement le résultat mis en cache — et le dashboard interroge `/api/audit/status` à 1 Hz jusqu'à la fin de l'exécution ; une bande de progression rose épinglée s'affiche en haut du viewport pendant l'exécution avec un minuteur écoulé, et le nouveau résultat remplace l'ancien en place en cas de succès (sans rechargement de page ; une ré-analyse échouée laisse le rapport précédent intact). En cas d'échec, la bande devient rouge avec un message basé sur `RerunError.kind` (`timeout` / `network` / `post_failed`). L'état vide (pas de cache ou expiré) et l'état zéro session (le cache existe mais l'analyse n'a trouvé aucune transcription) sont affichés séparément.
+
+### Politiques
+
+Une page à deux onglets pour gérer les politiques et examiner l'activité.
+
+<Tabs>
+  <Tab title="Onglet Politiques">
+  - Sélection multiple des CLI d'agents que failproofai protège depuis un seul panneau — Claude Code, OpenAI Codex, GitHub Copilot, Cursor Agent, OpenCode, Pi et Hermes ont chacun une ligne avec le statut d'installation (`Active` / `Detected` / `Inactive`), le chemin des paramètres de portée utilisateur et un accent coloré à la marque. Cochez ou décochez les CLI souhaités et cliquez sur `Apply changes` pour installer/désinstaller le delta en une seule étape. Les CLI dont le binaire est détecté dans le PATH sont pré-cochés.
+  - Activez ou désactivez individuellement les politiques en un seul clic (écrit dans `~/.failproofai/policies-config.json` — partagé entre tous les CLI installés)
+  - Développez une politique pour configurer ses paramètres (pour les politiques prenant en charge `policyParams`)
+  - Définissez un chemin de fichier de politiques personnalisé
+  </Tab>
+  <Tab title="Onglet Activité">
+  - Historique paginé complet de chaque événement de hook déclenché dans toutes les sessions
+  - Filtrez par décision, type d'événement, CLI (Claude Code / OpenAI Codex / GitHub Copilot _(bêta)_ / Cursor Agent _(bêta)_ / OpenCode _(bêta)_ / Pi _(bêta)_ / Hermes / OpenClaw / Factory Droid / Devin / Antigravity / Goose), nom de politique ou identifiant de session
+  - Chaque ligne affiche : horodatage, nom de la politique, décision, badge CLI (orange = Claude Code, violet = OpenAI Codex, bleu = GitHub Copilot, émeraude = Cursor Agent, ambre = OpenCode, rose = Pi, indigo = Hermes, sarcelle = OpenClaw, rose foncé = Factory Droid, violet foncé = Devin, cyan = Antigravity, lime = Goose), nom de l'outil, identifiant de session et la raison des décisions deny/instruct
+  - Cliquez sur un identifiant de session pour ouvrir sa transcription — le visualiseur détecte automatiquement quel CLI a déclenché le hook (Claude `~/.claude/projects/…`, Codex `~/.codex/sessions/…`, Copilot CLI `~/.copilot/session-state/<id>/events.jsonl`, Cursor Agent `~/.cursor/agent-sessions/<id>/events.jsonl`, OpenCode `~/.local/share/opencode/opencode.db`, Pi `~/.pi/agent/sessions/<encoded-cwd>/<id>.jsonl`, Hermes `~/.hermes/state.db`, OpenClaw `~/.openclaw/agents/<id>/sessions/*.jsonl`, Factory Droid `~/.factory/sessions/<encoded-cwd>/<id>.jsonl`, Devin `~/.local/share/devin/cli/sessions.db`, Antigravity `~/.gemini/antigravity-cli/brain/<id>/…/transcript_full.jsonl`, Goose `~/.local/share/goose/sessions/sessions.db`) et affiche le badge CLI correspondant dans l'en-tête
+  </Tab>
+</Tabs>
+
+---
+
+## Actualisation automatique
+
+Le dashboard dispose d'un bouton d'activation de l'actualisation automatique dans la navigation supérieure. Lorsqu'elle est activée, la page actuelle s'actualise périodiquement pour afficher les nouvelles sessions et l'activité des politiques au fur et à mesure. Indispensable pour surveiller les sessions d'agents autonomes de longue durée.
+
+---
+
+## Désactiver des pages
+
+Si vous n'avez besoin que de certaines parties du dashboard, définissez `FAILPROOFAI_DISABLE_PAGES` avec une liste de noms de pages séparés par des virgules :
+
+```bash
+FAILPROOFAI_DISABLE_PAGES=policies failproofai
+```
+
+Valeurs valides : `policies`, `projects`, `audit`.
+
+---
+
+## Configurer le chemin des projets
+
+Par défaut, le dashboard lit depuis le répertoire de projets Claude Code standard. Remplacez-le pour des configurations personnalisées :
+
+```bash
+CLAUDE_PROJECTS_PATH=/custom/path/to/projects failproofai
+```
+
+---
+
+## Accès depuis un hôte non-localhost
+
+Lorsque vous exécutez le dashboard en **mode développement** (`npm run dev`) et y accédez depuis un nom d'hôte autre que `localhost` — par exemple, un domaine personnalisé, une IP distante ou une URL tunnelisée — vous pouvez voir un avertissement tel que :
+
+```text
+⚠ Blocked cross-origin request to Next.js dev resource /_next/webpack-hmr from "dashboard.example.com".
+```
+
+Il s'agit de Next.js qui bloque l'accès cross-origin à son websocket HMR (rechargement de module à chaud), une fonctionnalité exclusivement liée au mode développement. Pour autoriser votre hôte, utilisez l'indicateur `--allowed-origins` :
+
+```bash
+npm run dev -- --allowed-origins dashboard.example.com
+```
+
+Pour plusieurs hôtes ou adresses IP, passez une liste séparée par des virgules :
+
+```bash
+npm run dev -- --allowed-origins dashboard.example.com,192.168.1.5
+```
+
+Vous pouvez également définir la variable d'environnement `FAILPROOFAI_ALLOWED_DEV_ORIGINS` à la place :
+
+```bash
+FAILPROOFAI_ALLOWED_DEV_ORIGINS=dashboard.example.com npm run dev
+```
+
+<Note>
+Ceci s'applique uniquement au mode développement. Lors de l'exécution de `failproofai` (mode production), il n'y a pas de websocket HMR ni de problème de ressource de développement cross-origin.
+</Note>

package/.next/standalone/docs-old/fr/examples.mdx

@@ -0,0 +1,307 @@
+---
+title: Exemples
+description: "Comment configurer des hooks pour Claude Code et l'Agents SDK"
+icon: book-open
+---
+
+Des exemples prêts à l'emploi pour les scénarios courants. Chacun montre comment installer et ce à quoi s'attendre.
+
+---
+
+## Configurer des hooks pour Claude Code
+
+Failproof AI s'intègre à Claude Code via son [système de hooks](https://docs.anthropic.com/en/docs/claude-code/hooks). Lorsque vous exécutez `failproofai policies --install`, des commandes de hook sont enregistrées dans le fichier `settings.json` de Claude Code et se déclenchent à chaque appel d'outil.
+
+<Steps>
+  <Step title="Installer failproofai">
+    ```bash
+    npm install -g failproofai
+    ```
+  </Step>
+  <Step title="Activer toutes les politiques intégrées">
+    ```bash
+    failproofai policies --install
+    ```
+  </Step>
+  <Step title="Vérifier que les hooks sont enregistrés">
+    ```bash
+    cat ~/.claude/settings.json | grep failproofai
+    ```
+
+    Vous devriez voir des entrées de hook pour les événements `PreToolUse`, `PostToolUse`, `Notification` et `Stop`.
+  </Step>
+  <Step title="Lancer Claude Code">
+    ```bash
+    claude
+    ```
+
+    Les politiques s'exécutent désormais automatiquement à chaque appel d'outil. Essayez de demander à Claude d'exécuter `sudo rm -rf /` — la commande sera bloquée.
+  </Step>
+</Steps>
+
+---
+
+## Configurer des hooks pour l'Agents SDK
+
+Si vous développez avec l'[Agents SDK](https://docs.anthropic.com/en/docs/agents-sdk), vous pouvez utiliser le même système de hooks de manière programmatique.
+
+<Steps>
+  <Step title="Installer failproofai dans votre projet">
+    ```bash
+    npm install failproofai
+    ```
+  </Step>
+  <Step title="Configurer les hooks dans votre agent">
+    Passez des commandes de hook lors de la création de votre processus d'agent. Les hooks se déclenchent de la même façon que dans Claude Code — via stdin/stdout JSON :
+
+    ```bash
+    failproofai --hook PreToolUse   # appelé avant chaque outil
+    failproofai --hook PostToolUse  # appelé après chaque outil
+    ```
+  </Step>
+  <Step title="Écrire une politique personnalisée pour votre agent">
+    ```javascript
+    import { customPolicies, allow, deny } from "failproofai";
+
+    customPolicies.add({
+      name: "limit-to-project-dir",
+      description: "Keep the agent inside the project directory",
+      match: { events: ["PreToolUse"] },
+      fn: async (ctx) => {
+        const path = String(ctx.toolInput?.file_path ?? "");
+        if (path.startsWith("/") && !path.startsWith(ctx.session?.cwd ?? "")) {
+          return deny("Agent is restricted to the project directory");
+        }
+        return allow();
+      },
+    });
+    ```
+  </Step>
+  <Step title="Installer la politique personnalisée">
+    ```bash
+    failproofai policies --install --custom ./my-agent-policies.js
+    ```
+  </Step>
+</Steps>
+
+---
+
+## Bloquer les commandes destructives
+
+La configuration la plus courante — empêcher les agents de causer des dommages irréversibles.
+
+```bash
+failproofai policies --install block-sudo block-rm-rf block-force-push block-curl-pipe-sh
+```
+
+Ce que cela fait :
+- `block-sudo` — bloque toutes les commandes `sudo`
+- `block-rm-rf` — bloque la suppression récursive de fichiers
+- `block-force-push` — bloque `git push --force`
+- `block-curl-pipe-sh` — bloque l'exécution de scripts distants via un pipe vers le shell
+
+---
+
+## Prévenir les fuites de secrets
+
+Empêcher les agents de voir ou de divulguer des identifiants dans la sortie des outils.
+
+```bash
+failproofai policies --install sanitize-api-keys sanitize-jwt sanitize-connection-strings sanitize-bearer-tokens
+```
+
+Ces politiques se déclenchent sur `PostToolUse` — après l'exécution d'un outil, elles nettoient la sortie avant que l'agent ne la voie.
+
+---
+
+## Recevoir des alertes Slack quand les agents ont besoin d'attention
+
+Utilisez le hook de notification pour transférer les alertes d'inactivité vers Slack.
+
+```javascript
+import { customPolicies, allow, instruct } from "failproofai";
+
+customPolicies.add({
+  name: "slack-on-idle",
+  description: "Alert Slack when the agent is waiting for input",
+  match: { events: ["Notification"] },
+  fn: async (ctx) => {
+    const webhookUrl = process.env.SLACK_WEBHOOK_URL;
+    if (!webhookUrl) return allow();
+
+    const message = String(ctx.payload?.message ?? "Agent is waiting");
+    const project = ctx.session?.cwd ?? "unknown";
+
+    try {
+      await fetch(webhookUrl, {
+        method: "POST",
+        headers: { "Content-Type": "application/json" },
+        body: JSON.stringify({
+          text: `*${message}*\nProject: \`${project}\``,
+        }),
+        signal: AbortSignal.timeout(5000),
+      });
+    } catch {
+      // ne jamais bloquer l'agent si Slack est inaccessible
+    }
+
+    return allow();
+  },
+});
+```
+
+Installez-le :
+
+```bash
+SLACK_WEBHOOK_URL=https://hooks.slack.com/... failproofai policies --install --custom ./slack-alerts.js
+```
+
+---
+
+## Maintenir les agents sur une branche
+
+Empêcher les agents de changer de branche ou de pousser vers des branches protégées.
+
+```javascript
+import { customPolicies, allow, deny } from "failproofai";
+
+customPolicies.add({
+  name: "stay-on-branch",
+  description: "Prevent the agent from checking out other branches",
+  match: { events: ["PreToolUse"] },
+  fn: async (ctx) => {
+    if (ctx.toolName !== "Bash") return allow();
+    const cmd = String(ctx.toolInput?.command ?? "");
+    if (/git\s+checkout\s+(?!-b)/.test(cmd)) {
+      return deny("Stay on the current branch. Create a new branch with -b if needed.");
+    }
+    return allow();
+  },
+});
+```
+
+---
+
+## Exiger des tests avant les commits
+
+Rappeler aux agents d'exécuter les tests avant de faire un commit.
+
+```javascript
+import { customPolicies, allow, instruct } from "failproofai";
+
+customPolicies.add({
+  name: "test-before-commit",
+  description: "Remind the agent to run tests before committing",
+  match: { events: ["PreToolUse"] },
+  fn: async (ctx) => {
+    if (ctx.toolName !== "Bash") return allow();
+    const cmd = String(ctx.toolInput?.command ?? "");
+    if (/git\s+commit/.test(cmd)) {
+      return instruct("Run tests before committing. Use `npm test` or `bun test` first.");
+    }
+    return allow();
+  },
+});
+```
+
+---
+
+## Verrouiller un dépôt de production
+
+Commitez une configuration au niveau du projet afin que tous les développeurs de votre équipe bénéficient des mêmes politiques.
+
+Créez `.failproofai/policies-config.json` dans votre dépôt :
+
+```json
+{
+  "enabledPolicies": [
+    "block-sudo",
+    "block-rm-rf",
+    "block-force-push",
+    "block-push-master",
+    "block-env-files",
+    "sanitize-api-keys",
+    "sanitize-jwt"
+  ],
+  "policyParams": {
+    "block-push-master": {
+      "protectedBranches": ["main", "release", "production"]
+    }
+  }
+}
+```
+
+Puis commitez-le :
+
+```bash
+git add .failproofai/policies-config.json
+git commit -m "Add failproofai team policies"
+```
+
+Chaque membre de l'équipe ayant failproofai installé récupèrera automatiquement ces règles.
+
+---
+
+## Établir un standard de qualité à l'échelle de l'organisation avec des politiques de convention
+
+La configuration la plus impactante : commitez `.failproofai/policies/` dans votre dépôt avec des politiques adaptées à votre projet. Chaque membre de l'équipe les obtient automatiquement — aucune commande d'installation, aucun changement de configuration.
+
+<Steps>
+  <Step title="Créer le répertoire et ajouter des politiques">
+    ```bash
+    mkdir -p .failproofai/policies
+    ```
+
+    ```js
+    // .failproofai/policies/team-policies.mjs
+    import { customPolicies, allow, deny, instruct } from "failproofai";
+
+    // Enforce your team's preferred package manager
+    // (or enable the built-in prefer-package-manager policy instead)
+    customPolicies.add({
+      name: "enforce-bun",
+      match: { events: ["PreToolUse"] },
+      fn: async (ctx) => {
+        if (ctx.toolName !== "Bash") return allow();
+        const cmd = String(ctx.toolInput?.command ?? "");
+        if (/\bnpm\b/.test(cmd)) return deny("Use bun instead of npm.");
+        return allow();
+      },
+    });
+
+    // Remind the agent to run tests before committing
+    customPolicies.add({
+      name: "test-before-commit",
+      match: { events: ["PreToolUse"] },
+      fn: async (ctx) => {
+        if (ctx.toolName !== "Bash") return allow();
+        if (/git\s+commit/.test(ctx.toolInput?.command ?? "")) {
+          return instruct("Run tests before committing.");
+        }
+        return allow();
+      },
+    });
+    ```
+  </Step>
+  <Step title="Commiter dans git">
+    ```bash
+    git add .failproofai/policies/
+    git commit -m "Add team quality policies"
+    ```
+  </Step>
+  <Step title="Continuer à améliorer">
+    Au fur et à mesure que votre équipe rencontre de nouveaux modes de défaillance, ajoutez des politiques et poussez-les. Tout le monde reçoit la mise à jour au prochain `git pull`. Ces politiques deviennent un standard de qualité vivant qui évolue avec votre équipe.
+  </Step>
+</Steps>
+
+---
+
+## Plus d'exemples
+
+Le répertoire [`examples/`](https://github.com/failproofai/failproofai/tree/main/examples) du dépôt contient :
+
+| Fichier | Ce qu'il illustre |
+|------|---------------|
+| `policies-basic.js` | Politiques de base — bloquer les écritures en production, le force-push, les scripts via pipe |
+| `policies-notification.js` | Alertes Slack pour les notifications d'inactivité et la fin de session |
+| `policies-advanced/index.js` | Imports transitifs, hooks asynchrones, nettoyage de la sortie avec PostToolUse, gestion de l'événement Stop |

package/.next/standalone/docs-old/fr/for-agents.mdx

@@ -0,0 +1,38 @@
+---
+title: "Pour les agents"
+description: "Ajoutez la documentation Failproof AI à votre agent de développement en une seule commande. Compatible avec Claude Code, Cursor, Windsurf et plus encore."
+---
+
+Ajoutez la référence complète Failproof AI à votre agent de développement en une seule commande. Compatible avec Claude Code, Cursor, Windsurf et tout autre agent prenant en charge les skills.
+
+```bash
+npx skills add https://docs.befailproof.ai
+```
+
+`npx skills` détecte les agents que vous avez installés et ajoute le skill dans le bon format pour chacun d'eux automatiquement.
+
+## Ce que couvre le skill
+
+| Domaine | Contenu |
+|---------|---------|
+| Policies | Noms des policies intégrées, types d'événements, paramètres, activation/désactivation |
+| Custom policies | `customPolicies.add()`, filtres de correspondance, API `allow`/`deny`/`instruct` |
+| Objet contexte | `ctx.eventType`, `ctx.toolName`, `ctx.toolInput`, `ctx.session` |
+| Configuration | Structure de `policies-config.json`, fusion des scopes, `policyParams` |
+| CLI | `failproofai policies --install`, `--uninstall`, `--custom`, scopes |
+| Dashboard | Visionneuse de sessions, activité des policies, variables d'environnement |
+| Architecture | Flux du hook handler, codes de sortie, contrat stdin/stdout |
+
+## Le skill est-il complet ?
+
+Mintlify génère un fichier `llms.txt` à partir de toutes les pages de la navigation. La documentation Failproof AI couvre l'API complète — chaque policy, option et exemple est inclus. Si vous constatez qu'il manque quelque chose, la source est disponible à l'adresse `https://docs.befailproof.ai/llms-full.txt`.
+
+Pour un contexte ciblé, pointez directement vers une page spécifique :
+
+```bash
+# Uniquement l'API des custom policies
+npx skills add https://docs.befailproof.ai/custom-policies
+
+# Uniquement les built-in policies
+npx skills add https://docs.befailproof.ai/built-in-policies
+```