failproofai 1.0.1-beta.0 → 1.0.1

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

@@ -0,0 +1,350 @@
+---
+title: "CLI"
+description: "Pilotez toute l'Observabilité Failproof AI depuis le terminal ou un script : sans aller-retours vers le tableau de bord."
+---
+
+
+Pilotez toute l'Observabilité Failproof AI depuis le terminal ou un script : sans aller-retours vers le tableau de bord. La CLI `agenteye` interroge vos données (sessions, journaux d'événements, évaluations) et administre votre organisation (clés API, utilisateurs, paramètres, alertes, incidents, requêtes sauvegardées), afin que vous puissiez automatiser une vérification, intégrer l'Observabilité dans votre CI ou permettre à un agent de code d'inspecter la production. Chaque commande prend en charge un flag `--json`, ce qui la rend tout aussi utile à la ligne de commande ou pour un agent de code (Claude Code, Cursor) qui exécute des commandes shell et analyse les résultats.
+
+Avec un seul binaire, vous pouvez :
+
+- **Lire vos données** : `sessions`, `events`, `evals`, `errors` (filtrage par heure, agent, environnement, score).
+- **Gérer votre organisation** : `keys`, `users`, `settings`, `alerts`, `incidents`.
+- **Lancer des analyses** : SQL sauvegardé et exécuteur de requêtes ad hoc (`query`).
+- **Interroger l'assistant IA** : le même analyste en lecture seule que vous utilisez dans le tableau de bord (`agent`).
+
+> **Remarque :** Il s'agit de la CLI `agenteye`, un outil distinct du démon collecteur (`agenteye-collector`). La CLI communique avec votre tableau de bord ; le collecteur achemine les événements vers le serveur.
+
+---
+
+## Démarrage rapide
+
+De zéro à votre premier résultat en quatre lignes. Pointez la CLI vers votre tableau de bord, connectez-vous, confirmez votre identité, puis récupérez les exécutions du dernier jour :
+
+```bash
+pipx install agenteye
+agenteye --base-url https://agenteye.example.com login --email you@example.com   # code à 6 chiffres envoyé par e-mail
+agenteye whoami                                                                  # confirmer l'utilisateur + l'org active
+agenteye --json sessions --since 24h                                             # une ligne par exécution d'agent, dernières 24h
+```
+
+Cette dernière commande affiche un objet JSON des sessions les plus récentes (les plus récentes en premier, limité à 50 par défaut). Canalisez-le dans `jq` pour le découper, ou supprimez `--json` pour un tableau encadré et colorisé. Chaque ligne contient le statut de l'exécution et, si un évaluateur l'a scorée, ses scores de métriques (abrégés ici) :
+
+```json
+{
+  "sessions": [
+    {
+      "session_id": "run-8f2a",
+      "agent_id": "checkout-bot",
+      "environment": "prod",
+      "status": "error",
+      "scores": { "helpfulness": 0.42, "tool_efficiency": 0.55 },
+      "event_count": 37,
+      "started_at": "2026-07-16T09:14:02Z",
+      "last_event_at": "2026-07-16T09:14:48Z"
+    }
+  ],
+  "next_cursor": null
+}
+```
+
+Le reste de cette page explique chaque élément : [l'installation](#installation) en isolation, [la connexion](#authentication), [la configuration](#configuration), les [conventions globales](#global-options--conventions) partagées par toutes les commandes, et la [référence complète des commandes](#command-reference).
+
+---
+
+## Installation
+
+La CLI est un paquet PyPI public nommé **`agenteye`**. Installez-le dans un environnement isolé afin qu'il dispose toujours de ses propres dépendances :
+
+```bash
+pipx install agenteye
+# ou
+uv tool install agenteye
+```
+
+Python 3.10+ est requis. La commande installée est **`agenteye`** :
+
+```bash
+agenteye --version
+agenteye --help
+```
+
+> **Remarque :** Le SDK Python d'Observabilité Failproof AI utilise également le nom de distribution `agenteye`. Installer la CLI avec `pipx` ou `uv tool` (plutôt que `pip install` dans un virtualenv partagé) évite les conflits entre les deux. Un simple `pip install agenteye` convient uniquement si le SDK n'est pas installé dans le même environnement.
+
+---
+
+## Authentification
+
+La CLI s'authentifie auprès du **tableau de bord** avec un code à usage unique envoyé par e-mail :
+
+```bash
+agenteye login --email you@example.com
+# Un code à 6 chiffres vous est envoyé par e-mail ; collez-le à l'invite.
+```
+
+Le jeton de session est stocké dans `~/.agenteye/cli.json` (lisible uniquement par vous, mode `0600`) et est valide pendant 24 heures par défaut. Lorsqu'il expire, relancez `agenteye login`.
+
+```bash
+agenteye whoami     # afficher l'utilisateur courant, l'org active et les permissions
+agenteye logout     # révoquer la session et effacer le jeton stocké
+```
+
+`whoami` ne génère jamais d'erreur en cas de session manquante ou expirée ; il renvoie `logged_in: false` à la place, afin qu'un script ou un agent puisse sonder l'état d'authentification en toute sécurité (il peut tout de même retourner un code non nul si aucune URL de base n'est définie ou si le tableau de bord est inaccessible).
+
+**Prérequis :** votre e-mail doit être autorisé à se connecter au tableau de bord (demandez à votre administrateur d'Observabilité Failproof AI), et le tableau de bord doit être accessible à son URL de base (voir [Configuration](#configuration)). Si vous demandez un code et qu'il n'arrive pas, votre e-mail n'est probablement pas encore activé pour l'accès au tableau de bord.
+
+---
+
+## Choisir votre organisation (multi-tenant)
+
+Si votre compte appartient à plusieurs organisations, choisissez l'organisation active **lors de la connexion** ; elle est sauvegardée et utilisée pour toutes les commandes ultérieures :
+
+```bash
+agenteye login --org acme           # s'authentifier et définir le tenant actif en une seule étape
+agenteye orgs list                  # les orgs auxquelles vous avez accès (l'active est marquée)
+agenteye orgs switch globex         # changer la valeur par défaut sauvegardée
+agenteye --org globex sessions      # remplacer pour une seule commande
+```
+
+Si vous n'appartenez qu'à une seule organisation, elle est sélectionnée automatiquement et vous pouvez ignorer `--org` entièrement. Si vous appartenez à plusieurs et que vous n'en choisissez pas une, la CLI les liste et vous demande de relancer avec `--org <slug>`. L'org active est transmise au tableau de bord à chaque requête, et vos permissions sont résolues **par organisation** ; `agenteye whoami` affiche l'org active, vos permissions en son sein, et toutes vos appartenances.
+
+---
+
+## Configuration
+
+| Paramètre | Flag | Variable d'environnement | Défaut |
+|---|---|---|---|
+| URL de base du tableau de bord | `--base-url` | `AGENTEYE_DASHBOARD_URL` | **obligatoire** (pas de défaut) |
+| Org/tenant actif | `--org` | `AGENTEYE_ORG` | choisi à la connexion ; sauvegardé dans `~/.agenteye/cli.json` |
+| Jeton de session | `--token` | `AGENTEYE_CLI_TOKEN` | depuis `~/.agenteye/cli.json` |
+| Sortie JSON | `--json` | `AGENTEYE_CLI_JSON` | désactivé |
+| Ignorer la vérification TLS | `--insecure` / `--secure` | `AGENTEYE_INSECURE` | désactivé (sauvegardé à la connexion) |
+| Délai de requête (secondes) | `--timeout` | _(aucune)_ | 30 |
+| Désactiver la télémétrie d'utilisation | _(aucun)_ | `AGENTEYE_ANALYTICS_DISABLED` (ou `DO_NOT_TRACK`) | la télémétrie est actuellement désactivée ; rien n'est envoyé |
+
+L'ordre de résolution est **flag → variable d'environnement → fichier de configuration**. Il n'y a pas de valeur par défaut ; vous devez pointer la CLI vers votre tableau de bord, soit par commande (`--base-url https://agenteye.example.com`), soit une fois via l'environnement (elle est également sauvegardée après votre premier `login`) :
+
+```bash
+export AGENTEYE_DASHBOARD_URL=https://agenteye.example.com
+```
+
+Le répertoire de configuration respecte `AGENTEYE_HOME` (la même convention utilisée par le SDK et le collecteur) ; si défini, `cli.json` se trouve dans `$AGENTEYE_HOME/cli.json`.
+
+### TLS auto-signé ou interne
+
+Si votre tableau de bord est servi via HTTPS avec un certificat auto-signé ou interne (par exemple, un nom d'hôte de load-balancer brut), la vérification TLS le rejettera avec une erreur `CERTIFICATE_VERIFY_FAILED`. Utilisez `--insecure` pour ignorer la vérification du certificat :
+
+```bash
+agenteye --base-url https://agenteye.internal --insecure login
+```
+
+`--insecure` est **sauvegardé dans `cli.json` lors de la connexion**, de sorte que les commandes ultérieures ignorent automatiquement la vérification ; vous n'avez pas à répéter le flag. Utilisez `--secure` pour un appel vérifié ponctuel, ou pour réactiver la vérification lors de votre prochaine connexion. La CLI affiche un avertissement sur stderr avant toute commande qui contacte le tableau de bord avec la vérification désactivée. Ignorer la vérification supprime la protection contre les attaques de type man-in-the-middle ; assurez-vous de faire confiance au chemin réseau vers votre tableau de bord (VPN, sous-réseau privé, etc.) avant de vous en remettre à cette option.
+
+---
+
+## Télémétrie et confidentialité
+
+> **Remarque :** La CLI fournie **n'envoie aucune télémétrie d'utilisation aujourd'hui.** Un interrupteur maître est activé, de sorte que rien n'est transmis quelle que soit votre configuration. La section ci-dessous décrit la fonctionnalité de désactivation pour le cas où la télémétrie serait un jour activée.
+
+Même si elle était activée, la télémétrie se limiterait à des **analyses d'utilisation anonymes**, jamais à vos données d'agent, de session ou d'événement :
+
+- **Aucune donnée d'agent, de session ou d'événement ne quitte jamais votre infrastructure.** Seule l'utilisation de la CLI serait rapportée : le nom de la commande et de la sous-commande (ex. `keys create`), les **noms** des flags utilisés (jamais leurs valeurs), le statut de succès/sortie, et la durée, ainsi qu'un événement par action pour les mutations (ex. `api_key_created`, `query_run`) ne comportant que des noms/enums statiques et des comptages grossiers. Votre URL de tableau de bord, jeton de session, e-mail, slug d'org, identifiants de ressources, SQL, secrets de clés et filtres de requêtes ne seraient **jamais** envoyés. Les opérateurs ne seraient identifiés que par un identifiant interne opaque, jamais par e-mail.
+- **Désactivez à l'avance** en définissant `AGENTEYE_ANALYTICS_DISABLED=1` dans l'environnement de la CLI (la CLI respecte également la convention inter-outils `DO_NOT_TRACK=1`). Cela prend effet dès que la télémétrie serait activée, de sorte qu'un environnement soucieux de la confidentialité peut rester désactivé en permanence.
+- Si la télémétrie était activée, la CLI enverrait directement à PostHog (`https://us.i.posthog.com`) ; une machine avec cet hôte bloqué n'enverrait rien silencieusement et la CLI ne serait pas affectée.
+
+---
+
+## Options globales et conventions
+
+Lisez ceci une fois ; cela s'applique à chaque commande.
+
+- **Les options globales vont AVANT la commande.** `agenteye --json sessions` est correct ; `agenteye sessions --json` est une erreur d'utilisation. Les options globales sont `--json`, `--base-url`, `--org`, `--token`, `--insecure`/`--secure`, `--timeout`, `--quiet` et `--no-color`.
+- **`--json` affiche du JSON pur sur stdout, et rien d'autre.** Les lignes de statut humain, les avertissements et les erreurs vont sur **stderr**, de sorte qu'une capture stdout avec `--json` reste propre pour être canalisée dans `jq` même lorsqu'une ligne de statut est affichée. Sans `--json`, vous obtenez une vue encadrée et colorisée pour les yeux humains.
+- **Explorez avec `--help`.** Chaque commande et sous-commande dispose de `--help` (et de l'alias `-h`) : `agenteye -h`, `agenteye sessions -h`, `agenteye keys create -h`. L'aide de niveau supérieur liste également les codes de sortie et les options globales. Il n'existe pas de surface lisible par machine globale ; utilisez `--help` par commande, ainsi que `agenteye query schema` et `agenteye settings schema` spécifiques au domaine pour ces deux registres.
+- **Les confirmations sont ignorées automatiquement pour les scripts et les agents.** Les commandes de création/mise à jour/suppression demandent "êtes-vous sûr ?" dans un terminal interactif, mais **ignorent automatiquement cette invite sous `--json` ou lorsque stdin n'est pas un TTY** (un TTY est une session de terminal interactive ; un pipe ou un runner CI ne l'est pas), de sorte que les scripts et les agents ne se bloquent jamais. Utilisez `--yes`/`-y` pour l'ignorer explicitement. Comme l'invite ne se déclenchera pas pour un agent, un agent devrait confirmer les actions destructrices avec l'humain en amont.
+- **Pagination :** les résultats sont classés du plus récent au plus ancien et paginés par curseur (chaque page retourne un jeton à utiliser pour récupérer la suivante). `--limit N` (alias `-n`) plafonne les lignes et **vaut 50 par défaut** ; `--all` pagine automatiquement (par blocs de 200 lignes) **jusqu'à `--limit`**, donc un simple `--all` s'arrête toujours à 50. Pour un balayage complet, passez une limite explicite élevée : `--all --limit 1000`. `--page-size N` contrôle la taille des blocs par requête (max 200) ; `--cursor <id>` reprend à partir du `next_cursor` d'une page précédente.
+- **Filtres temporels :** `--since` accepte une fenêtre relative : `15m`, `1h`, `6h`, `24h`, `7d`, ou `all` (les présélections du tableau de bord). Pour une plage plus longue ou personnalisée (par exemple les 30 derniers jours), utilisez `--from`/`--to` : des horodatages UTC ISO-8601 explicites **avec `T` et un fuseau horaire** (ex. `2026-06-01T00:00:00Z`) qui remplacent `--since`. Une valeur séparée par des espaces ou sans fuseau horaire est une erreur d'utilisation.
+- **`--fields a,b,c`** (sur `events`, `sessions`, `evals`, `errors`) restreint la sortie à ces clés, aussi bien pour le tableau que pour `--json`. Les noms inconnus sont rejetés avec la liste des noms valides, un moyen pratique de découvrir les noms de champs.
+- **`--file payload.json`** (ou `--file -` pour lire depuis stdin) fournit un corps de requête JSON complet lorsqu'une ressource a une forme complexe (sur `alerts create/update`, `settings set` et `users create/update`). Le SQL de requête sauvegardée utilise `--sql @file.sql` à la place.
+- **Les filtres multi-valeurs** sont séparés par des virgules → correspondance sous forme d'ensemble (union dans un filtre, ET entre filtres) : `--event-type tool_use,tool_result`. Les options Click ne sont pas variadiques, donc `--add a b` ne fonctionne pas. Utilisez `--add a,b`, répétez le flag (`--add a --add b`), ou mettez entre guillemets (`--add "a b"`).
+
+---
+
+## Référence des commandes
+
+### Les 5 commandes que vous utiliserez le plus
+
+La plupart du travail quotidien passe par quelques commandes de lecture. Commencez ici, puis explorez la surface complète ci-dessous si nécessaire :
+
+| Commande | Ce qu'elle fait | Essayez |
+|---|---|---|
+| `sessions` | Une ligne par exécution d'agent : heure, env, agent, statut, dernier score. | `agenteye --json sessions --since 24h --status error` |
+| `events` | La trace brute étape par étape dans une exécution (ajoutez `--full` pour les payloads). | `agenteye --json events --session-id run-001 --all` |
+| `evals` | Résultats d'évaluation et scores ; `--aggregate` les agrège. | `agenteye --json evals --aggregate --since 7d --env prod` |
+| `errors` | Uniquement les événements en erreur ; `--aggregate` pour les comptages par type. | `agenteye --json errors --since 24h --aggregate` |
+| `list` | Découvrir les valeurs de filtre valides (agents, envs, modèles, …). | `agenteye list agents` |
+
+### Tout ce que la CLI peut faire
+
+La surface complète suit. La CLI dispose de **18 commandes de premier niveau**. Toutes les commandes de lecture acceptent `--json` et les options globales ci-dessus ; exécutez `agenteye <commande> -h` (ou `<commande> <sous-commande> -h`) pour la liste exhaustive des flags et la structure JSON de n'importe quelle commande.
+
+### Identité : `login` · `logout` · `whoami` · `orgs` · `version` · `help`
+
+```bash
+agenteye login --email you@example.com [--org acme]   # code à usage unique par e-mail ; sauvegarde la session
+agenteye logout                                       # effacer la session sauvegardée sur cette machine
+agenteye whoami                                       # utilisateur courant, org active, permissions
+agenteye version                                      # afficher la version de la CLI (identique à --version)
+agenteye help                                         # aide de niveau supérieur (identique à --help)
+```
+
+`orgs` inspecte et change le tenant actif :
+
+```bash
+agenteye orgs list        # vos orgs + votre rôle dans chacune (l'active est marquée)
+agenteye orgs switch acme # changer l'org active sauvegardée (omettez le slug pour choisir dans une liste sur un TTY)
+agenteye orgs current     # carte d'identité de l'org active
+agenteye orgs perms       # vos permissions dans l'org active, groupées par ressource
+```
+
+### Observer (lecture seule) : `events` · `sessions` · `evals` · `errors` · `list`
+
+Aucune de ces commandes n'a besoin de confirmation. Filtres partagés : `--session-id`, `--agent-id`, `--env` (**pas** `--environment`), et la plage temporelle (`--since` / `--from` / `--to`).
+
+```bash
+# events (alias : la trace brute étape par étape), plus récents en premier
+agenteye --json events --session-id run-001 --event-type tool_use,tool_result --all --limit 1000
+agenteye --json events --since 1h --search timeout --all | jq '.events[].payload'
+
+# sessions : une ligne par exécution d'agent (heure/env/agent/session/statut ; pas de filtrage par score)
+agenteye --json sessions --since 24h --status error
+agenteye --json sessions --agent-id checkout-bot --env prod --all --limit 1000
+
+# evals : résultats d'évaluation + scores ; --score filtre par métrique, --aggregate agrège
+agenteye --json evals --score helpfulness:0.5..0.8 --score tool_efficiency:..0.3
+agenteye --json evals --aggregate --since 7d --env prod        # mix de statuts + stats de score par clé
+
+# errors : événements en erreur ; --aggregate pour comptages/sessions/agents/dernière vue
+agenteye --json errors --since 24h --aggregate
+agenteye --json errors --since 24h --error-type timeout --all --limit 1000
+
+# list : découvrir les valeurs de filtre valides avant de filtrer
+agenteye list envs        # aussi : agents event_types score_filters models hooks tools error_types
+```
+
+`--score KEY:MIN..MAX` (sur **`evals`**, pas `sessions`) est répétable et combiné par ET ; chaque borne est optionnelle (`..0.5` signifie ≤ 0,5, `0.9..` signifie ≥ 0,9). Jusqu'à 20 filtres de score par requête. `evals --scores-full` est un flag d'affichage pour le **tableau humain uniquement** ; il affiche chaque paire de scores au lieu des premiers plus un comptage `+N`. Il n'a aucun effet sous `--json`, qui retourne toujours l'objet de score complet. Pour lire **une session de bout en bout**, combinez la trace d'événements avec son évaluation :
+
+```bash
+agenteye --json events --session-id run-001 --all --limit 1000 | jq '.events[] | {ts, event_type}'
+agenteye --json evals  --session-id run-001                       # ses scores + statut
+```
+
+### Gérer (soumis aux permissions) : `keys` · `users` · `settings` · `alerts` · `incidents`
+
+**`keys`** : clés API. Le secret est généré localement, envoyé au serveur (qui n'en stocke qu'un hash), et **affiché une seule fois** lors de la création/regénération ; capturez-le à ce moment-là. Avec `--json`, il apparaît uniquement dans le champ `key`. Référencé par **nom**.
+
+```bash
+agenteye keys list                                   # clés actives en premier, puis révoquées
+agenteye keys show ci-bot
+agenteye keys create ci-bot --add events:read.add    # limiter à ce dont vous avez besoin ; affiche le secret UNE FOIS
+agenteye keys create ops --permission-set standard --remove queries:run   # partir d'un preset, puis réduire
+agenteye keys update ci-bot --add evaluations:read --yes
+agenteye keys regenerate ci-bot --yes                # effectuer une rotation du secret (l'ancien cesse de fonctionner)
+agenteye keys disable ci-bot --yes                   # révoquer
+```
+
+Les permissions fonctionnent comme `(permission-set ∪ --add) − --remove`. Les jetons sont `slug:action` (ex. `events:read`) ou `slug:action.action` pour développer plusieurs actions sur une ressource (`events:read.add` → `events:read`, `events:add`). Presets : `read-only`, `standard`, `admin`. Les permissions réservées aux humains (`keys:update`) ne peuvent pas être accordées à une clé.
+
+**`users`** : membres de l'organisation, référencés par **e-mail** (un id UUID est également accepté).
+
+```bash
+agenteye users list [--active-only]
+agenteye users show dev@corp.com
+agenteye users create dev@corp.com --permission-set standard
+agenteye users update dev@corp.com --add alerts:write --remove queries:delete   # prédit + confirme
+agenteye users disable dev@corp.com --yes            # comporte des protections contre la suppression de soi-même ou de comptes protégés
+agenteye users enable dev@corp.com
+```
+
+**`settings`** : un registre fixe (vous lisez et modifiez les clés existantes ; vous ne pouvez pas en créer de nouvelles).
+
+```bash
+agenteye settings list                               # clé · valeur · type · mis à jour (secrets masqués)
+agenteye settings schema                             # ce que chaque clé accepte (type · plage · description)
+agenteye settings set session_ttl_secs --value 86400 --yes
+```
+
+**`alerts`** : définitions d'alertes, référencées par **nom**. `create` prend un NOM positionnel plus des flags ou un corps JSON complet via `--file`.
+
+```bash
+agenteye alerts list
+agenteye alerts show high-errors
+agenteye alerts create high-errors --file alert.json          # NAME est obligatoire (positionnel)
+agenteye alerts update high-errors --severity critical --yes
+agenteye alerts test high-errors --yes                        # déclencher une notification de test
+agenteye alerts delete high-errors --yes
+```
+
+**`incidents`** : incidents d'alerte, référencés par id (ids courts acceptés). `show` affiche le journal d'activité complet ; lisez-le avant d'agir.
+
+```bash
+agenteye incidents list --state firing                # aussi : acknowledged, resolved
+agenteye incidents count
+agenteye incidents show <id>
+agenteye incidents ack <id>
+agenteye incidents assign <id> you@corp.com           # l'assigné doit être un opérateur
+agenteye incidents resolve <id> --yes
+agenteye incidents open --alert-id <id> --severity critical    # ouvrir manuellement contre une alerte
+agenteye incidents comment-add <id> "root cause: upstream 5xx"
+agenteye incidents comment-list <id> ; agenteye incidents comment-delete <id> <comment-id>
+agenteye incidents subscribe <id> ; agenteye incidents unsubscribe <id> ; agenteye incidents subscribers <id>
+```
+
+### Analyses et assistant : `query` · `agent`
+
+**`query`** : SQL sauvegardé contre votre entrepôt d'analyses plus un exécuteur ad hoc. Les requêtes sauvegardées sont référencées par **nom** ; le SQL est validé côté serveur (SELECT/WITH uniquement, délai d'expiration des instructions, plafond de lignes).
+
+```bash
+agenteye query schema [TABLE]                         # disposition des colonnes des vues analytiques
+agenteye query run --sql "select count(*) from analytics.events"
+agenteye query run errs --arg prod --limit 100        # exécuter une requête sauvegardée + un $1 positionnel
+agenteye query list ; agenteye query show errs
+agenteye query create errs --sql @errs.sql --description "errored events (24h)"
+agenteye query update errs --sql @errs.sql --yes ; agenteye query delete errs --yes
+```
+
+**`agent`** : communique avec l'**assistant IA** intégré (le même analyste en lecture seule que vous pouvez utiliser dans le tableau de bord). Les conversations sont référencées par un chat-id court (résolution par préfixe).
+
+```bash
+agenteye agent health                                 # l'assistant IA est-il configuré/accessible
+agenteye agent models                                 # modèles que vous pouvez passer à --model (le défaut est marqué)
+agenteye agent ask "which agents errored most in the last day?"    # démarre une conversation ; affiche son id court
+agenteye agent ask --chat <short-id> "and which tools did they call?"   # continuer cette conversation
+agenteye agent chats ; agenteye agent show <short-id>
+agenteye agent rename <short-id> --title "error triage" ; agenteye agent delete <short-id>
+```
+
+---
+
+## Codes de sortie
+
+| Code | Signification |
+|---|---|
+| 0 | Succès |
+| 1 | Erreur inattendue (ex. le tableau de bord a retourné un 5xx) |
+| 2 | Erreur d'utilisation (arguments invalides, commande/flag inconnu, collision de noms) |
+| 3 | Impossible d'atteindre le tableau de bord |
+| 4 | Non connecté ou session expirée ; exécutez `agenteye login` |
+| 5 | Authentifié, mais votre compte ne dispose pas de la permission requise (le message la nomme) |
+| 6 | La ressource demandée est introuvable (ex. session ou id d'incident inconnu) |
+
+Ces codes rendent la CLI sûre à scripter : un agent de code peut brancher sur un `4` pour vous inviter à vous ré-authentifier, ou sur un `5` pour signaler la permission manquante. Voir [Recettes CLI pour les agents](/fr/agenteye/cli-recipes) pour les modèles de gestion des codes de sortie et les structures de sortie JSON.
+
+---
+
+## Prochaines étapes
+
+- **[Recettes CLI pour les agents](/fr/agenteye/cli-recipes)** : modèles de requêtes à copier-coller, one-liners `jq`, projections `--fields`, gestion des codes de sortie et structures de sortie JSON, écrits pour les agents de code qui pilotent la CLI.
+- **[Compétence CLI pour agent](/fr/agenteye/cli-skill)** : packagée cette CLI comme une *compétence* installable Claude Code / Codex afin qu'un agent de code pilote l'Observabilité Failproof AI à partir de requêtes en langage naturel.
+- **[Clés API](/fr/agenteye/api-keys)** : le modèle de permissions derrière `keys create --add …`.
+- **[Assistant IA](/fr/agenteye/assistant)** : activation de l'assistant qu'`agent ask` utilise.

package/.next/standalone/docs-old/fr/agenteye/codex-capture.mdx

@@ -0,0 +1,55 @@
+---
+title: "Capture de session Codex"
+description: "Transmettez les sessions OpenAI Codex locales de votre équipe vers AgentEye sous forme de sessions et d'événements ordinaires — sans modifier leur façon d'utiliser Codex."
+---
+
+Vos ingénieurs utilisent déjà OpenAI Codex au quotidien. La capture de sessions Codex importe ces sessions de codage dans AgentEye sous forme de sessions et d'événements ordinaires, afin que vous puissiez les rechercher, les rejouer et les évaluer aux côtés de tout ce que vous observez par ailleurs. Cette fonctionnalité complète le [SDK Python](/fr/agenteye/python-sdk) : le SDK instrumente les agents que vous écrivez, tandis que la capture récupère le travail Codex que votre équipe effectue déjà — sans aucune modification de leur façon de l'utiliser.
+
+Un petit collecteur en arrière-plan lit les transcripts de sessions locaux de Codex au fur et à mesure de leur écriture et les envoie vers AgentEye. Un seul collecteur par machine capture simultanément toutes les surfaces Codex locales — aucune configuration par surface n'est nécessaire.
+
+Ce même collecteur capture également d'autres agents — voir [OpenClaw](/fr/agenteye/openclaw-capture) et [Hermes](/fr/agenteye/hermes-capture). Activez chacun de ceux que vous utilisez ; un seul collecteur peut en capturer plusieurs à la fois.
+
+---
+
+## Ce qui est capturé
+
+Chaque surface Codex fonctionnant **localement** produit les mêmes transcripts de session sur disque, et le collecteur les récupère tous :
+
+- le **CLI** Codex et `codex exec`
+- l'**extension VS Code / IDE**
+- l'**application de bureau**, lorsqu'elle exécute une session localement
+
+Chaque session Codex devient une [session](/fr/agenteye/sessions) AgentEye ; ses messages utilisateur et assistant, son raisonnement, ses appels d'outils, ses résultats d'outils et son utilisation des tokens deviennent les [événements](/fr/agenteye/event-stream) correspondants. La surface d'origine de chaque session (CLI, IDE ou bureau) est enregistrée, ce qui vous permet de les distinguer.
+
+> **Les sessions cloud ne sont pas capturées.** L'application de bureau exécute de plus en plus de sessions dans le cloud Codex et ne conserve que leurs métadonnées sur la machine — il n'existe aucun transcript local à lire. Seules les sessions exécutées localement sont capturées.
+
+---
+
+## Activation
+
+La capture est désactivée jusqu'à ce que vous l'activiez. Installez le collecteur avec une clé API disposant de la permission `events:add` (voir [Clés API](/fr/agenteye/api-keys)), puis activez la capture Codex :
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/FailproofAI/agenteye-collector/main/install.sh \
+  | sh -s -- --key <YOUR_API_KEY> --codex-enabled
+```
+
+Cette commande installe le collecteur, l'enregistre en tant que service en arrière-plan et démarre la capture. Vérifiez qu'il fonctionne :
+
+```bash
+agenteye-collector health
+```
+
+Au premier démarrage, vos sessions Codex existantes sont importées rétroactivement une seule fois, puis la nouvelle activité est transmise en quelques secondes. Les fichiers de Codex ne sont qu'en lecture seule — ils ne sont jamais modifiés, déplacés ni supprimés — et chaque session est envoyée exactement une fois, même en cas de redémarrage.
+
+---
+
+## Où retrouver les données
+
+Les sessions capturées apparaissent dans **Sessions**, et leurs événements dans le flux **Events**, de la même façon que tout autre agent observé — ainsi, la [relecture de session](/fr/agenteye/sessions), la [recherche](/fr/agenteye/queries), les [évaluations](/fr/agenteye/evaluations) et les [alertes](/fr/agenteye/alerts) fonctionnent toutes avec elles. Filtrez par agent Codex pour les afficher séparément.
+
+---
+
+## Confidentialité
+
+Les transcripts Codex contiennent l'intégralité de la session — y compris les sorties de commandes, le contenu des fichiers et tout ce que Codex a lu ou écrit — et peuvent contenir des secrets. Les sessions capturées sont transmises telles quelles ; n'activez donc la capture que sur les machines et pour les équipes pour lesquelles la centralisation de ce contenu dans AgentEye est appropriée, et fournissez au collecteur une clé dont la portée se limite à `events:add`. Consultez [Sécurité](/fr/agenteye/security) pour en savoir plus sur l'isolation de vos données.

package/.next/standalone/docs-old/fr/agenteye/concepts.mdx

@@ -0,0 +1,87 @@
+---
+title: "Concepts"
+description: "Le vocabulaire de Failproof AI Observability — événements, sessions, évaluations, audits, findings et incidents — défini en un seul endroit."
+---
+
+
+Cette page définit le vocabulaire utilisé par Failproof AI Observability. Si un terme vous est inconnu dans un autre guide, il est défini ici. Inutile de la lire en entier : parcourez-la en diagonale, ou revenez-y dès qu'un mot mérite d'être précisé.
+
+---
+
+## Le modèle de données
+
+**Événement**
+La plus petite unité de données. Un événement enregistre une seule étape effectuée par votre agent : un `tool_use`, un `model_request`, un `hook_completed`, une `error`, etc. Votre agent émet des événements via le [Python SDK](/fr/agenteye/python-sdk) ; ils apparaissent en temps réel sur la page **Events**.
+
+**Session**
+Une exécution d'agent, identifiée par un `session_id`. Une session regroupe tous les événements partageant cet identifiant, consolidés en une seule ligne sur la page **Sessions** et représentés sous forme de graphe d'exécution sur sa page de détail. Une session commence généralement par `agent_start` et se termine par `agent_end`.
+
+**Agent**
+Un acteur nommé au sein d'une exécution, identifié par un `agent_id`. Une exécution peut impliquer plusieurs agents : par exemple, un planificateur qui instancie un sous-agent de synthèse. Les sous-agents portent un `parent_id`, ce qui permet à Failproof AI Observability de les représenter sur leurs propres pistes dans le graphe d'exécution.
+
+**Environnement**
+Un libellé indiquant où s'est déroulée l'exécution : `production`, `staging`, `dev`. Vous le définissez une seule fois lors de la configuration du SDK. Presque toutes les pages du tableau de bord permettent de filtrer par environnement.
+
+**Taux de remplissage de la fenêtre de contexte**
+Le pourcentage de la fenêtre de contexte d'un modèle consommé par une réponse. Failproof AI Observability l'horodate sur les événements `model_response` pour les modèles qu'il reconnaît, rendant ainsi visibles la croissance des prompts et les compactions imminentes directement dans le flux d'événements.
+
+---
+
+## Qualité
+
+**Évaluation**
+Un score de qualité pour une session terminée, produit par un service de notation que vous exécutez. Les évaluations sont optionnelles : tant que vous ne connectez pas d'évaluateur, les sessions sont enregistrées mais pas notées. Chaque évaluation peut comporter plusieurs scores nommés (par exemple `helpfulness`, `factuality`, `tool_efficiency`), chacun accompagné d'une courte note explicative. Voir [Evaluation suite](/fr/agenteye/evaluation-suite).
+
+**Clé de score**
+Le nom d'une dimension rapportée par un évaluateur, comme `helpfulness`. Les alertes et les audits peuvent surveiller une clé de score spécifique dans le temps.
+
+**Évaluateur**
+Votre service de notation. Failproof AI Observability lui envoie via POST la transcription d'une exécution terminée et stocke les scores renvoyés. Aucun évaluateur par défaut n'est fourni ; la logique de notation vous appartient.
+
+---
+
+## Identifier et corriger les défaillances
+
+**Hook**
+Un garde-fou ou un effet secondaire que votre framework d'agent exécute autour d'une étape : une vérification de sécurité du contenu, une anonymisation des données personnelles, un contrôle budgétaire. Les hooks émettent des événements `hook_triggered` / `hook_completed` avec un `outcome` (allow, deny, modify) et disposent de leur propre page d'observation.
+
+**Règle d'alerte**
+Une règle qui se déclenche lorsqu'une métrique dépasse un seuil que vous définissez : taux d'erreur, latence p95, coût en tokens ou score d'un évaluateur. Lorsqu'une règle se déclenche, elle ouvre un incident et notifie les canaux que vous avez choisis (e-mail, Slack, webhook, tableau de bord). Voir [Alerts](/fr/agenteye/alerts).
+
+**Incident**
+Un problème ouvert créé lorsqu'une règle d'alerte se déclenche. Les incidents suivent un cycle de vie (accusé de réception, assignation, résolution) et disposent d'une chronologie d'activité enregistrant chaque action. Vous pouvez également en ouvrir un manuellement.
+
+**Audit**
+Une investigation récurrente (toutes les heures à une fois par semaine) qui analyse vos journaux *à travers* les sessions pour détecter des patterns de défaillance pour lesquels vous n'avez pas encore écrit de règle : clusters d'erreurs, scores faibles, valeurs aberrantes de latence, boucles d'appels d'outils et exécutions n'ayant jamais abouti. Là où une alerte surveille une métrique que vous connaissez déjà, un audit vous indique ce sur quoi vous devriez vous pencher ensuite. Voir [Audits](/fr/agenteye/audits).
+
+**Finding**
+Un résultat classé et étayé par des preuves, issu d'une exécution d'audit. Un finding nomme un pattern, renvoie aux sessions exactes qui le sous-tendent et suit un cycle de vie de triage (accusé de réception, résolution, mise en sourdine, rejet). Failproof AI Observability déduplique les findings d'une exécution à l'autre, de sorte qu'un pattern connu est mis à jour plutôt que de s'accumuler.
+
+**L'assistant IA**
+Le chat intégré au tableau de bord qui répond en langage naturel à vos questions sur vos agents, en s'appuyant sur vos propres données. Il est en lecture seule par défaut ; tout ce qu'il crée (une requête sauvegardée, un tableau de bord) nécessite une approbation, et il ne peut jamais supprimer quoi que ce soit. Voir [AI assistant](/fr/agenteye/assistant).
+
+---
+
+## Fonctionnement
+
+**Organisation (tenant)**
+Un espace de travail isolé. Une instance Failproof AI Observability peut héberger plusieurs organisations, chacune avec ses propres utilisateurs, clés et données. Chaque URL du tableau de bord est rattachée à votre slug d'organisation (`/<org-slug>/…`).
+
+**Collector**
+`agenteye-collector`, le démon léger qui s'exécute sur chaque machine agent, regroupe les événements écrits sur disque par le SDK et les envoie au serveur.
+
+**Clé API**
+Un token à périmètre défini qui authentifie un client auprès du serveur. Les clés portent des permissions granulaires (par exemple `events:add` pour le collector, des périmètres en lecture seule pour une clé de tableau de bord). Voir [API keys](/fr/agenteye/api-keys).
+
+**Serveur**
+Le service d'ingestion et d'API. Il ingère les événements, stocke l'état opérationnel dans vos bases de données et sert le tableau de bord ainsi que la CLI.
+
+**Tableau de bord**
+L'interface web. Chaque page est rattachée à une organisation et lit les données via l'API du serveur.
+
+---
+
+## Étapes suivantes
+
+- [Overview](/fr/agenteye/overview) : comment ces éléments s'articulent entre eux.
+- [Observability](/fr/agenteye/observability) : les surfaces d'observation (Events, Sessions, Models, Tools, Hooks, Errors).

package/.next/standalone/docs-old/fr/agenteye/dashboards.mdx

@@ -0,0 +1,46 @@
+---
+title: "Tableaux de bord"
+description: "Transformez vos données d'agents en temps réel en une vue partagée que toute votre équipe consulte."
+---
+
+
+Transformez vos données d'agents en temps réel en une vue partagée que toute votre équipe consulte. Épinglez les requêtes importantes sous forme de graphiques, et tout le monde accède instantanément aux mêmes chiffres, sans avoir à relancer une seule requête.
+
+![Un tableau de bord construit à partir de requêtes sauvegardées : une courbe d'événements par heure, un histogramme des erreurs par type, un graphique en aire de la latence, et une répartition des tokens par modèle](/agenteye/images/dashboard-fleet.png)
+
+*Un tableau de bord, quatre requêtes sauvegardées : événements par heure, erreurs par type, latence et tokens par modèle.*
+
+## Tout le monde voit la même réalité
+
+Fini les captures d'écran partagées dans le chat et les mêmes requêtes relancées cinq fois par jour. Un tableau de bord est un espace partagé à l'échelle de l'organisation, que n'importe quel membre de votre équipe peut ouvrir pour consulter exactement la même vue. Quand les données sous-jacentes évoluent, les graphiques évoluent avec elles : le tableau est toujours à jour, et personne ne se dispute sur des chiffres périmés.
+
+Le tableau de bord de flotte ci-dessus est une bonne base pour les opérations quotidiennes :
+
+- une **courbe d'événements par heure**, pour surveiller le débit et détecter une chute soudaine
+- un **histogramme des erreurs par type**, pour identifier en un coup d'œil vos principales catégories de pannes
+- un **graphique en aire de la latence**, pour repérer les ralentissements avant que les utilisateurs se plaignent
+- une **répartition des tokens par modèle**, pour garder les coûts sous contrôle
+
+Vous trouverez vos tableaux de bord à `/<org-slug>/dashboards`.
+
+## Épinglez les requêtes que vous avez déjà sauvegardées
+
+Chaque vignette commence par une requête sauvegardée. Créez et sauvegardez la requête qui vous intéresse dans la bibliothèque [Requêtes](/fr/agenteye/queries) (préréglages intégrés et requêtes personnalisées, sur vos événements et évaluations), puis épinglez-la sur un tableau de bord sous la forme du graphique adapté à vos données : une **courbe** pour les tendances dans le temps, un **histogramme** pour comparer des catégories, une **aire** pour les volumes, ou un **camembert** pour une répartition en parts.
+
+Puisqu'une vignette n'est que votre requête sauvegardée affichée sous forme de graphique, rien n'est à synchroniser manuellement. Mettez à jour la requête une fois, et tous les tableaux de bord qui l'utilisent se mettent à jour automatiquement.
+
+## Surveillez la qualité, pas seulement le volume
+
+Le volume vous indique que les agents sont actifs. La qualité vous indique qu'ils font réellement leur travail. Orientez un tableau de bord vers vos [scores d'évaluation](/fr/agenteye/evaluations) et vous obtenez un tableau qui suit la qualité des exécutions dans le temps : une régression de qualité apparaît comme un creux sur un graphique, plutôt que comme une mauvaise surprise venue d'un client.
+
+![Un tableau de bord axé sur la qualité, construit à partir de requêtes d'évaluation sauvegardées](/agenteye/images/dashboard-quality.png)
+
+*Un tableau de bord qualité garde vos scores d'évaluation au premier plan, juste à côté des métriques opérationnelles.*
+
+Maintenez un tableau de bord opérationnel et un tableau de bord qualité côte à côte, et votre équipe dispose d'un seul endroit pour répondre à la fois à « est-ce que ça fonctionne ? » et « est-ce que c'est bon ? », sans que personne n'ait à relancer une requête.
+
+## Voir aussi
+
+- [Requêtes](/fr/agenteye/queries) : créez et sauvegardez les requêtes qui deviendront vos vignettes.
+- [Évaluations](/fr/agenteye/evaluations) : scorez vos exécutions pour pouvoir suivre la qualité dans le temps.
+- [Alertes](/fr/agenteye/alerts) : transformez un seuil sur n'importe laquelle de ces métriques en une notification.

package/.next/standalone/docs-old/fr/agenteye/error-tracking.mdx

@@ -0,0 +1,40 @@
+---
+title: "Suivi des erreurs"
+description: "Visualisez en un seul endroit toutes les défaillances de vos agents, regroupées pour qu'une rafale d'erreurs apparaisse comme un problème unique."
+---
+
+Visualisez en un seul endroit toutes les défaillances de vos agents, regroupées pour qu'une rafale d'erreurs apparaisse comme un problème unique. Vous disposez d'un accès en un clic entre « quelque chose est rouge » et l'exécution exacte qui a échoué, sans avoir à parcourir un flux en direct pour la retrouver.
+
+![La page Erreurs : un histogramme des défaillances au fil du temps au-dessus de lignes d'erreurs rouges groupées, chacune avec un bouton « + alert » en un clic](/agenteye/images/errors.png)
+*La page Erreurs : un histogramme des défaillances au fil du temps, avec les erreurs répétées regroupées en une seule ligne par incident.*
+
+## Toutes les défaillances, déjà collectées pour vous
+
+Quand un agent tombe en panne, vous ne devriez pas avoir à parcourir un flux d'événements en direct en espérant repérer les lignes rouges avant qu'elles disparaissent. La page **Errors** se charge de la collecte à votre place. Elle rassemble tout ce que le tableau de bord afficherait en rouge dans une interface de triage unique, de sorte que la première chose que vous voyez est ce qui échoue, et non l'endroit où chercher.
+
+Et elle détecte bien plus que les erreurs évidentes. En plus des événements `error` explicites, Failproof AI Observability remonte également les défaillances silencieuses : tout `tool_result`, `hook_completed` ou `agent_end` dont le contenu indique un échec apparaît ici. Un outil ayant retourné une erreur, ou un hook s'étant terminé de manière anormale, ne passe plus inaperçu simplement parce qu'aucune exception bruyante n'a été levée.
+
+En haut de la page, un histogramme trace l'évolution des erreurs dans le temps. Un simple coup d'œil vous indique s'il s'agit d'un filet constant en arrière-plan ou d'un pic apparu il y a quelques minutes, vous permettant de décider immédiatement si vous devez tout laisser tomber.
+
+Comme toutes les surfaces d'observation, la page Errors est limitée à votre organisation et se filtre par plage de dates, environnement, agent et session. Vous pouvez ainsi partir d'une liste couvrant l'ensemble de votre parc et la réduire à l'agent ou à l'environnement qui vous intéresse réellement.
+
+## Un seul incident, pas cent lignes identiques
+
+Une dépendance défaillante peut déclencher la même erreur des centaines de fois par minute. Sans regroupement, cela donne un mur de lignes quasi identiques qui noie l'information dont vous avez vraiment besoin.
+
+Failproof AI Observability regroupe les défaillances répétées partageant la même session et le même type d'erreur en une seule ligne. Une rafale apparaît comme un seul incident. Vous comptez des problèmes, pas des lignes de log, et le signal qui compte reste en évidence au lieu d'être noyé par son propre volume.
+
+## De « quelque chose est rouge » à l'événement exact
+
+Cliquez sur n'importe quelle ligne pour accéder directement à la session de cette exécution, positionné sur l'événement exact qui a échoué. Pas besoin de copier des identifiants de session ni de faire défiler pour trouver le moment de la rupture : vous arrivez directement dessus, avec le graphe d'exécution complet à portée de regard pour voir ce que l'agent faisait dans les instants précédant la défaillance.
+
+Si vous disposez de `alerts:write`, chaque ligne comporte également un bouton **+ alert**. Cliquez dessus et Observability ouvre une nouvelle règle d'alerte déjà configurée pour détecter ce même type de défaillance. L'incident que vous venez de traiter deviendra celui qui vous alerte la prochaine fois, au lieu de vous surprendre une deuxième fois.
+
+**Où le trouver :** la page **Errors** se trouve dans la section observe du tableau de bord, à l'adresse `/<org-slug>/errors`.
+
+## Ressources associées
+
+- [Alerts](/fr/agenteye/alerts) : transformez n'importe quelle défaillance en règle d'alerte.
+- [Incidents](/fr/agenteye/incidents) : suivez une alerte déclenchée de son ouverture à sa résolution.
+- [Sessions](/fr/agenteye/sessions) : ouvrez l'exécution complète derrière n'importe quelle erreur.
+- [Audits](/fr/agenteye/audits) : laissez Observability identifier les schémas de défaillance dans vos exécutions.