README.fr.md

⚠️ This is an auto-generated translation. For the latest version, see the English README. Community corrections welcome!

🇺🇸 English | 🇨🇳 简体中文 | 🇯🇵 日本語 | 🇰🇷 한국어 | 🇪🇸 Español | 🇧🇷 Português | 🇩🇪 Deutsch | 🇫🇷 Français | 🇷🇺 Русский | 🇮🇳 हिन्दी | 🇹🇷 Türkçe | 🇻🇳 Tiếng Việt | 🇮🇹 Italiano | 🇸🇦 العربية | 🇮🇱 עברית

---

---

Environnements pris en charge

Douze environnements répartis en deux catégories — dix CLI de développement, et deux passerelles de chat et d'assistant (Hermes, OpenClaw). Une seule API de politiques et un historique de sessions commun pour tous. Ce qu'une politique peut bloquer dépend de l'environnement : l'interruption d'un appel d'outil avant son exécution est vérifiée sur les douze, les contrôles en fin de tour sur huit. La matrice par environnement liste les événements honorés par chacun.

Les agents qui ne s'exécutent dans aucun d'eux remontent leurs données via le SDK Python, qui vous offre le traçage, les sessions et les audits. L'application des règles nécessite un hook dans votre propre runtime — contactez-nous et nous vous aiderons à le mettre en place.

{/* A 6-column table instead of inline runs: table columns never re-wrap, so the grid stays 2×6 at any window width (scrolling on very narrow screens instead of collapsing into ragged orphan rows). */}

Installation

npm install -g failproofai
failproofai config                             # connectez vos agents et le daemon
failproofai policies add FailproofAI/policies  # choisissez ce que vous souhaitez appliquer
failproofai                                    # tableau de bord sur localhost:8020

La configuration installe les hooks et ne sélectionne aucune politique — la deuxième commande est celle qui place des garde-fous sur la machine, et n'importe quel pack se spécifie de la même façon (failproofai policies add <propriétaire>/<dépôt> ; policies show <propriétaire>/<dépôt> permet d'en consulter un au préalable). Exécutez failproofai config sans terminal — en CI, dans un conteneur, avec un agent aux commandes — et il applique la configuration sans poser de questions. Sur une machine qui n'a jamais été configurée, toute autre commande déclenche le même assistant en premier ; désactivez ce comportement avec FAILPROOFAI_NO_FIRST_RUN=1.

Tant qu'aucun pack n'est installé, la seule règle active est block-failproofai-commands, qui est toujours activée et ne peut pas être désactivée ni suspendue : un agent capable de suspendre l'application des règles pourrait désactiver toutes les autres politiques.

---

Ce que ça bloque

Politique	Ce qu'elle bloque
block-env-files	La lecture des fichiers .env et autres fichiers de secrets
warn-repeated-tool-calls	L'agent qui boucle sur le même appel
block-sudo	L'élévation de privilèges
warn-destructive-sql	DROP, TRUNCATE, DELETE sans clause de restriction
block-terraform / block-kubectl	Les modifications non relues sur l'infrastructure en production
block-rm-rf	La suppression récursive de fichiers
block-force-push / block-push-master	git push --force, les poussées directes sur main

Chacune de ces règles intercepte l'appel avant son exécution, ce qui garantit leur efficacité sur les douze environnements. Les quatre premières s'appliquent à tout agent capable d'appeler un outil ; les trois dernières sont les préférées des développeurs — les CLI de développement constituent la catégorie d'environnements que nous couvrons le plus en profondeur. La famille sanitize-* est à part : elle s'exécute après le retour d'un outil, signalant ainsi un secret dans la sortie de l'outil plutôt que de l'empêcher d'entrer dans le contexte.

→ Les 39 politiques intégrées

---

Vos propres politiques

Déposez un fichier dans .failproofai/policies/ — il se charge automatiquement, sans aucun flag. Commitez-le et toute l'équipe en bénéficiera au prochain pull.

import { customPolicies, deny, allow } from "failproofai";

customPolicies.add({
  name: "no-production-writes",
  match: { events: ["PreToolUse"] },
  fn: async (ctx) => {
    if (ctx.toolInput?.file_path?.includes("production"))
      return deny("Writes to production paths are blocked.");
    return allow();
  },
});

Trois décisions disponibles pour chaque politique :

Décision	Effet
allow()	Autoriser l'opération
deny(message)	La bloquer — le message est renvoyé à l'agent
instruct(message)	La laisser passer, mais ajouter du contexte à la prochaine invite de l'agent

→ Écrire une politique

---

Observabilité

L'application des règles représente une moitié du tableau. L'autre moitié, c'est voir ce que l'agent a réellement fait.

Lancez failproofai sans arguments et il sert un tableau de bord sur localhost:8020 en lisant l'historique d'exécution déjà présent sur votre machine — pas de compte, pas d'inscription, rien ne quitte la machine. Vous obtenez la liste des sessions, la séquence des appels de modèles, les appels d'outils et les décisions des hooks à l'intérieur de chaque exécution, ce qui a été bloqué et ce que la politique a indiqué à l'agent, ainsi qu'un audit hors ligne (failproofai audit) qui analyse votre historique à la recherche de motifs risqués et suggère des politiques pour les prévenir.

→ Tableau de bord local · Lire une trace · Audit local

Failproof AI Observability est la version hébergée du même modèle de données, destinée aux équipes faisant tourner des agents sur une flotte de machines : chaque exécution de chaque environnement en un seul endroit, un graphe d'exécution avec des sous-agents parallèles sur leurs propres voies, la latence p50/p95/p99 pour les modèles, les outils et les hooks, le suivi des coûts et de la fenêtre de contexte par modèle, le suivi des erreurs, du SQL sur vos propres traces avec des tableaux de bord partageables, des évaluations notées par votre propre service, des audits planifiés qui transforment les échecs récurrents en constats étayés par des preuves, et des alertes routées vers Slack, par e-mail ou via un webhook signé. L'auto-hébergement dans votre propre cluster est disponible dans le plan Entreprise.

→ Sessions · Audits · Réserver une démo

---

Documentation

Démarrage
Démarrage rapide	Installer, connecter un environnement, voir la première exécution
Concepts	Comment fonctionne le système de hooks
Environnements pris en charge	Les 12 environnements et ce que chacun peut appliquer

Observer
Sessions	Suivre une exécution : modèles, outils, erreurs, latence
Lire une trace	Ce que le graphe d'exécution vous indique
Audits	Trouver des motifs d'échec sur de nombreuses sessions
Tableau de bord local	localhost:8020, sans compte nécessaire

Appliquer
Packs de politiques	Les politiques Failproof AI et les packs du hub de politiques
Écrire une politique	À partir d'un audit ou directement en code
Configuration	Portées de configuration, règles de fusion et paramètres de politique

Instrumenter votre propre agent
SDK Python	Remonter les exécutions depuis un agent sans environnement dédié
SDK de politiques	Référence allow / deny / instruct

---

Licence

MIT avec Commons Clause — gratuit pour un usage interne et personnel ; la revente commerciale de failproofai lui-même nécessite un accord séparé. Consultez LICENSE pour le texte complet.

---

Contribuer

Voir CONTRIBUTING.md. Les nouvelles politiques, les cas limites et les traductions sont les bienvenus.

Compilez avant de commencer. Exécutez d'abord bun install && bun run build. Ce dépôt fait tourner ses propres hooks failproofai sur lui-même, et ils résolvent l'import failproofai par rapport au bundle compilé dist/ — sans compilation, vous obtiendrez des erreurs de hook Cannot find package 'failproofai'. Recompilez après avoir modifié src/. Voir Build before the in-repo dev hooks will work.

---

Conçu avec ❤️ par befailproof.ai à San Francisco et Bengaluru.