failproofai 1.0.1-beta.1 → 1.0.1

package/.next/standalone/docs-old/fr/agenteye/event-stream.mdx

@@ -0,0 +1,50 @@
+---
+title: "Flux d'événements"
+description: "Au moment où votre agent agit, vous le voyez."
+---
+
+
+Au moment où votre agent agit, vous le voyez. Le flux d'événements est votre pouls en direct sur chaque agent en production : pas d'attente, pas de recherche dans les logs, pas de devinettes sur ce qui vient de se passer.
+
+![Le flux d'événements en direct : lignes d'événements colorées défilant en temps réel, filtrables par environnement, agent, session, type d'événement et texte libre](/agenteye/images/events-stream.png)
+
+*Chaque événement de chaque agent de votre organisation, du plus récent au plus ancien, mis à jour au fil de l'eau.*
+
+## Votre pouls en direct sur chaque agent
+
+Quand un agent démarre une exécution, appelle un modèle, déclenche un outil, exécute un hook ou rencontre une erreur, la ligne apparaît en haut du flux au moment même où cela se produit. Il suit en continu tous les événements de tous vos agents, du plus récent au plus ancien, ce qui vous donne toujours une image actuelle plutôt qu'une image périmée.
+
+Cela signifie plus besoin de surveiller des fichiers de logs sur un serveur quelque part, ni de fouiller plusieurs machines, ni d'assembler manuellement des horodatages. Vous ouvrez une seule page et vous regardez déjà la production.
+
+Les lignes sont colorées par type, ce qui vous permet de lire le flux d'un coup d'œil plutôt que d'analyser chaque ligne. En un clin d'œil, chaque ligne vous montre :
+
+- **Son type**, codé par couleur : `agent_start`, `model_response`, `tool_use`, `hook_completed`, `error`, et bien d'autres.
+- **Un résumé en une ligne** de ce qui s'est passé, ce qui vous évite souvent d'ouvrir quoi que ce soit pour comprendre l'essentiel.
+- **Le nombre de tokens** pour l'étape.
+- **Un indicateur de remplissage de la fenêtre de contexte** lorsqu'il s'applique, rendant visible la croissance du prompt et l'approche d'une compaction avant qu'elles ne posent problème.
+
+Surveiller le flux en direct signifie que vous détectez un mauvais déploiement, une boucle incontrôlée ou une rafale d'erreurs au moment où cela se produit, pas lors de la revue des logs du lendemain.
+
+## Trouver l'unique exécution qui pose problème
+
+Quand quelque chose semble anormal, vous ne voulez pas le flot d'informations complet. Vous voulez l'unique exécution qui a planté. Le flux se filtre rapidement : par environnement, par agent, par session, par type d'événement ou par texte libre.
+
+Filtrez par identifiant de session ou d'agent pour suivre une exécution depuis son premier événement jusqu'au dernier. Filtrez par type d'événement pour isoler une seule catégorie d'activité, par exemple tous les `error` de l'organisation en une seule vue. Combinez des filtres pour passer de « tout, partout » à « cet agent, en prod, en erreur » en quelques clics, puis agissez sur ce que vous trouvez.
+
+La recherche en texte libre vous amène directement à un message, un nom d'outil ou un identifiant que vous avez déjà sous la main, transformant un signalement client en exécution précise en quelques secondes.
+
+## Où le trouver
+
+Le flux d'événements est la page d'accueil de votre organisation. Connectez-vous et c'est la première surface sur laquelle vous atterrissez, à `/<org-slug>/`, de sorte que le triage commence dès votre arrivée.
+
+En coulisse, vos agents émettent des événements via le SDK, le collecteur les achemine vers votre serveur d'observabilité Failproof AI, et le flux les suit à mesure qu'ils arrivent dans une infrastructure que vous contrôlez. Quand vous voulez la vue consolidée plutôt que la trace brute, les événements de chaque exécution se regroupent en une seule ligne dans Sessions, à un clic de là.
+
+C'est la source de vérité brute sur laquelle s'appuient toutes les autres surfaces d'observation. Donc, quand un chiffre semble erroné ailleurs, le flux est l'endroit où vous confirmez ce qui s'est réellement passé.
+
+## Voir aussi
+
+- [Sessions](/fr/agenteye/sessions) : les mêmes événements regroupés en une ligne par exécution, avec un graphe d'exécution de style git.
+- [Telemetry](/fr/agenteye/telemetry) : ce que vos agents envoient et comment les événements parviennent au flux.
+- [Suivi des erreurs](/fr/agenteye/error-tracking) : une surface de triage unique pour tout ce qui a mal tourné.
+- [Alertes](/fr/agenteye/alerts) : transformez n'importe quel seuil en règle de notification.
+- [CLI et agents](/fr/agenteye/cli-and-agents) : la même trace en direct depuis votre terminal.

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

@@ -0,0 +1,53 @@
+---
+title: "Capture de sessions Hermes"
+description: "Intégrez les sessions de votre passerelle Hermes — Slack, Telegram, CLI et exécutions planifiées — dans AgentEye sous forme de sessions et d'événements ordinaires."
+---
+
+[Hermes](https://hermes-agent.nousresearch.com) répond à votre équipe depuis n'importe quel outil de travail — Slack, Telegram, la CLI, des exécutions planifiées. La capture de sessions Hermes intègre l'ensemble de ces interactions dans AgentEye sous forme de sessions et d'événements ordinaires, afin que l'assistant que votre équipe utilise au quotidien soit aussi observable que les agents que vous développez vous-même.
+
+Un petit collecteur en arrière-plan lit le dépôt de sessions local de Hermes au fur et à mesure de son écriture, puis transmet les sessions à AgentEye. Son fonctionnement est identique à celui des captures [Codex](/fr/agenteye/codex-capture) et [OpenClaw](/fr/agenteye/openclaw-capture), et un seul collecteur peut en capturer plusieurs simultanément.
+
+---
+
+## Ce qui est capturé
+
+Toutes les sessions Hermes présentes sur la machine sont capturées, quel que soit le canal d'origine. Chacune devient une [session](/fr/agenteye/sessions) AgentEye ; ses messages utilisateur et assistant, ses appels d'outils et leurs résultats deviennent les [événements](/fr/agenteye/event-stream) correspondants.
+
+Le canal depuis lequel une session a démarré — Slack, Telegram, CLI ou une exécution planifiée — est enregistré sur la session, ce qui vous permet de les distinguer et de filtrer sur un seul canal à la fois. Sont également consignés : le modèle utilisé par la session, le chat et la personne à l'origine de son démarrage, ainsi que, lorsqu'une session en a engendré une autre, le lien vers sa session parente.
+
+Les sessions apparaissent dès que Hermes les démarre, qu'un message ait été échangé ou non, et la réponse d'un tour ainsi que ses appels d'outils sont conservés dans l'ordre réel des événements. Lorsqu'une session se termine, vous obtenez également la raison de sa fin, son coût et le nombre de tokens consommés.
+
+---
+
+## Activation
+
+La capture est désactivée par défaut. 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 Hermes :
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/FailproofAI/agenteye-collector/main/install.sh \
+  | sh -s -- --key <YOUR_API_KEY> --hermes-enabled
+```
+
+Cette commande installe le collecteur, l'enregistre en tant que service en arrière-plan et lance la capture. Pour vérifier qu'il est en cours d'exécution :
+
+```bash
+agenteye-collector health
+```
+
+Vous capturez plusieurs agents sur la même machine ? Ajoutez le flag de chacun à la même commande — par exemple `--hermes-enabled --codex-enabled`.
+
+Au premier lancement, vos sessions Hermes existantes sont importées rétroactivement en une seule fois, puis la nouvelle activité est transmise en quelques secondes. Les données de Hermes sont uniquement lues — jamais modifiées ni supprimées — et chaque message est transmis une seule fois, même après des redémarrages.
+
+`health` vous indique également si tout ce que le collecteur a capturé a bien atteint AgentEye. Si un lot n'a pas pu être livré, il est conservé et réessayé plutôt que supprimé, et la vérification signale un état non sain tant que des données sont encore en attente — ainsi, « sain » signifie que vos données sont bien arrivées, et pas seulement que le processus est en vie.
+
+---
+
+## Où les retrouver
+
+Les sessions capturées apparaissent dans **Sessions**, et leurs événements dans le flux **Events**, comme pour 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 sur ces données. Filtrez par l'agent Hermes pour les visualiser de manière isolée.
+
+---
+
+## Confidentialité
+
+Les sessions Hermes contiennent la transcription complète — y compris les sorties de commandes, le contenu des fichiers et tout ce que l'agent a lu ou écrit — et peuvent contenir des secrets. Les sessions capturées sont transmises telles quelles ; n'activez donc la capture que dans les contextes où la centralisation de ce contenu dans AgentEye est appropriée, et donnez au collecteur une clé limitée à la seule permission `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/incidents.mdx

@@ -0,0 +1,50 @@
+---
+title: "Incidents"
+description: "Dès qu'une alerte se déclenche, chacun peut voir que l'incident est ouvert, qui en est responsable, et ce qui s'est passé jusqu'ici — sur une seule chronologie attribuée."
+---
+
+
+Dès qu'une alerte se déclenche, la première question est toujours « qui s'en occupe ? » Les incidents y répondent : à l'instant où un seuil est franchi, tout le monde peut voir que l'incident est ouvert, qui en est propriétaire, et exactement ce qui s'est passé jusqu'ici, avec un historique propre et attribué que vous pouvez transmettre directement à un post-mortem.
+
+![La boîte de réception des incidents : cartes d'incidents liés à des alertes et ouverts manuellement, regroupées par état, chacune avec un badge de sévérité et un assigné](/agenteye/images/incidents.png)
+*La boîte de réception regroupe les incidents ouverts par état et permet de filtrer par sévérité et par assigné, afin que vous voyiez immédiatement ce qui nécessite une intervention humaine.*
+
+## Savoir qui s'en occupe, d'un coup d'œil
+
+Fini les « est-ce que quelqu'un regarde ça ? » dans un fil de discussion. Un dépassement ouvre automatiquement un incident et le dépose dans une boîte de réception partagée, regroupée par état. Acquittez-le et votre nom y est affiché, signalant au reste de l'équipe que c'est pris en charge. L'acquittement est partagé : plusieurs opérateurs peuvent acquitter le même incident, chacun étant enregistré séparément, de sorte qu'une salle de crise entière s'affiche par nom sans que les uns n'écrasent les autres. Assignez un seul propriétaire pour le triage, et filtrez la boîte de réception par sévérité ou par assigné pour n'afficher que ce qui vous concerne.
+
+## Toute l'histoire, sur une seule chronologie
+
+Quand l'incident est terminé, le compte rendu est déjà prêt. Ouvrez n'importe quel incident et vous obtenez les preuves du dépassement, ses assignés et abonnés, un fil de commentaires pour coordonner sur place, et une chronologie d'activité en ajout seul.
+
+![Une vue détaillée d'un incident : l'alerte parente et le résumé du dépassement, les assignés et abonnés, une chronologie d'activité attribuée, et un fil de commentaires](/agenteye/images/incident-detail.png)
+*Tout ce qui s'est passé, dans l'ordre, chaque ligne signée par celui qui l'a effectuée.*
+
+Chaque action (ouverture, acquittement, résolution, etc.) est écrite dans cette chronologie et n'est jamais modifiée. Chaque entrée est attribuée : à l'opérateur qui l'a effectuée, par e-mail, ou à **automated** pour tout ce que Failproof AI Observability a fait de manière autonome, comme l'ouverture de l'incident lors du dépassement. Rien n'est anonyme et rien n'est perdu, si bien que le post-mortem s'écrit en grande partie tout seul.
+
+## Comment un incident évolue
+
+```mermaid
+stateDiagram-v2
+    [*] --> firing
+    firing --> acknowledged: an operator acks
+    firing --> resolved: an operator resolves
+    acknowledged --> resolved: an operator resolves
+    resolved --> [*]
+```
+
+- **Ouvert (firing) :** le dépassement ouvre l'incident et notifie vos canaux une seule fois. Les dépassements répétés sont regroupés dans le même incident et actualisent ses preuves au lieu de vous notifier encore et encore.
+- **Acquitté (acknowledged) :** un opérateur le prend en charge. Il reste ouvert, et les dépassements ultérieurs mettent à jour les preuves discrètement.
+- **Résolu (resolved) :** un opérateur le clôture. La résolution automatique lorsque la condition se dissipe est prévue mais pas encore activée, donc un incident reste ouvert jusqu'à ce qu'un humain le résolve — ce qui garantit une vision honnête de ce qui a réellement été réglé. Un nouvel incident peut s'ouvrir sur la même alerte ultérieurement.
+
+Une alerte ne peut contenir qu'un seul incident ouvert à la fois, de sorte qu'une règle instable ne peut pas vous noyer sous des doublons. Vous pouvez également ouvrir un incident manuellement : un incident autonome pour quelque chose qu'aucune alerte n'a détecté, ou un incident rattaché à une alerte existante, si vous disposez de `incidents:write`.
+
+## Où le trouver
+
+Les incidents se trouvent à `/<org-slug>/incidents`. La consultation nécessite **`incidents:read`** ; l'ouverture d'un incident manuel nécessite **`incidents:write`** ; l'acquittement, l'assignation, les commentaires et la résolution nécessitent **`incidents:ack`**. Les anciennes clés ayant accordé le droit `alerts:ack` retraité continuent de fonctionner, car il est honoré en tant que `incidents:ack`, de sorte que votre rotation d'astreinte n'a pas besoin d'être réémise.
+
+## Voir aussi
+
+- [Alertes](/fr/agenteye/alerts) : les règles qui ouvrent ces incidents lorsqu'un seuil est franchi.
+- [Suivi des erreurs](/fr/agenteye/error-tracking) : consultez tous les échecs en un seul endroit et promouvez-en un en alerte.
+- [Audits](/fr/agenteye/audits) : l'analyste planifié qui détecte les défaillances qu'aucune règle ne surveillait.

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

@@ -0,0 +1,23 @@
+---
+title: "Observer"
+description: "Les surfaces d'observation permettent de surveiller en temps réel ce que font vos agents et d'explorer chaque exécution en détail."
+---
+
+
+Les surfaces d'observation permettent de surveiller en temps réel ce que font vos agents et d'explorer chaque exécution en détail. Tout ici est en direct, limité à votre organisation, et filtrable par plage de dates, environnement, agent et session — vous passez de « quelque chose cloche » à l'exécution exacte en quelques secondes.
+
+![Le flux d'événements en direct, coloré par type et filtrable par environnement, agent et session](/agenteye/images/events-stream.png)
+
+Quatre surfaces, chacune avec sa propre page :
+
+- **[Flux d'événements](/fr/agenteye/event-stream)** : le suivi en direct, étape par étape, de chaque exécution pour tous les agents, du plus récent au plus ancien. La page d'accueil de votre organisation et premier point de triage.
+- **[Sessions et graphe d'exécution](/fr/agenteye/sessions)** : ces événements regroupés en une ligne par exécution, accompagnés d'une représentation visuelle de type git montrant comment chaque exécution s'est déroulée.
+- **[Métriques de performance](/fr/agenteye/telemetry)** : cartes de chaleur de latence et indicateurs p50/p95/p99 pour vos modèles, outils et hooks, afin de distinguer les pics extrêmes de la médiane.
+- **[Suivi des erreurs](/fr/agenteye/error-tracking)** : une surface de triage unique pour tout ce qui a mal tourné, à un clic d'une alerte déclenchée vers l'exécution responsable.
+
+## Liens connexes
+
+- [Évaluations](/fr/agenteye/evaluations) : notez chaque exécution selon la qualité.
+- [Alertes](/fr/agenteye/alerts) : transformez n'importe quel seuil en règle de notification.
+- [Audits](/fr/agenteye/audits) : laissez Failproof AI Observability identifier automatiquement les schémas d'échec entre les sessions.
+- [CLI et agents](/fr/agenteye/cli-and-agents) : la même observabilité depuis votre terminal.

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

@@ -0,0 +1,49 @@
+---
+title: "Capture de session OpenClaw"
+description: "Transmettez les sessions OpenClaw locales de votre équipe vers AgentEye en tant que sessions et événements ordinaires — sans aucune modification de votre façon d'utiliser OpenClaw."
+---
+
+Si votre équipe utilise [OpenClaw](https://docs.openclaw.ai), la capture de session OpenClaw importe ces sessions dans AgentEye en tant que sessions et événements ordinaires, afin que vous puissiez les rechercher, les rejouer et les évaluer aux côtés de tout ce que vous observez. Cette fonctionnalité complète le [SDK Python](/fr/agenteye/python-sdk) : le SDK instrumente les agents que vous développez, tandis que la capture OpenClaw enregistre le travail que votre équipe réalise déjà — sans aucune modification de leur façon de l'exécuter.
+
+Un petit collecteur en arrière-plan lit les transcripts de session locaux d'OpenClaw au fur et à mesure de leur écriture et les envoie vers AgentEye. Il fonctionne de la même manière que la [capture Codex](/fr/agenteye/codex-capture), et un seul collecteur peut capturer les deux simultanément.
+
+---
+
+## Ce qui est capturé
+
+Chaque agent configuré dans l'installation OpenClaw d'une machine est capturé par le collecteur de cette machine — aucune configuration par agent n'est nécessaire.
+
+Chaque session OpenClaw devient une [session](/fr/agenteye/sessions) AgentEye ; ses messages utilisateur et assistant, ses appels d'outils et les résultats de ces appels deviennent les [événements](/fr/agenteye/event-stream) correspondants.
+
+---
+
+## 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 OpenClaw :
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/FailproofAI/agenteye-collector/main/install.sh \
+  | sh -s -- --key <YOUR_API_KEY> --openclaw-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 est bien en cours d'exécution :
+
+```bash
+agenteye-collector health
+```
+
+Vous capturez plusieurs agents sur la même machine ? Ajoutez le flag de chacun à la même commande — par exemple `--openclaw-enabled --codex-enabled`.
+
+Au premier démarrage, vos sessions OpenClaw existantes sont importées une seule fois, puis la nouvelle activité est transmise en quelques secondes. Les fichiers d'OpenClaw sont uniquement lus — jamais modifiés, déplacés ou supprimés — et chaque session est envoyée exactement une fois, même lors des redémarrages.
+
+---
+
+## Où retrouver les données
+
+Les sessions capturées apparaissent dans **Sessions**, et leurs événements dans le flux **Events**, comme pour tout autre agent que vous observez — ainsi, le [replay de session](/fr/agenteye/sessions), la [recherche](/fr/agenteye/queries), les [évaluations](/fr/agenteye/evaluations) et les [alertes](/fr/agenteye/alerts) fonctionnent tous sur ces données. Filtrez par agent OpenClaw pour les afficher séparément.
+
+---
+
+## Confidentialité
+
+Les transcripts OpenClaw contiennent l'intégralité de la session — y compris la sortie des commandes, le contenu des fichiers, et tout ce que l'agent a lu ou écrit — et peuvent contenir des secrets. Les sessions capturées sont transmises telles quelles, donc n'activez la capture que sur les machines et pour les équipes pour lesquelles la centralisation de ces données dans AgentEye est appropriée, et accordez au collecteur une clé limitée au seul scope `events:add`. Consultez la section [Sécurité](/fr/agenteye/security) pour en savoir plus sur l'isolation de vos données.

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

@@ -0,0 +1,108 @@
+---
+title: "Failproof AI : Observez vos agents pour détecter les défaillances"
+description: "Failproof AI Observability est une plateforme auto-hébergée pour observer, évaluer et améliorer vos agents IA en production."
+---
+
+
+Failproof AI Observability est une plateforme auto-hébergée pour observer, évaluer et améliorer vos agents IA en production. Elle enregistre tout ce que font vos agents (chaque appel d'outil, requête de modèle, hook et erreur), note la qualité de chaque exécution, et met en évidence les défaillances que vous n'auriez pas su chercher — le tout dans un tableau de bord que vous faites tourner dans votre propre infrastructure.
+
+Si vous déployez des agents IA et que vous en avez assez de deviner pourquoi une exécution a mal tourné, c'est par ici qu'il faut commencer. Cette page explique ce que Failproof AI Observability vous apporte et comment les différentes pièces s'articulent, avant même que vous n'installiez quoi que ce soit.
+
+> **Failproof AI Observability est un produit entreprise de Failproof AI.** Vous voulez le voir en action ? Demandez une démo : écrivez à [nikita@befailproof.ai](mailto:nikita@befailproof.ai).
+
+![Une session Failproof AI Observability représentée sous forme de graphe d'exécution à la git, à côté de sa chronologie d'événements, avec un détail par exécution des outils, modèles et hooks dans le panneau de droite](/agenteye/images/session-detail.png)
+
+*Chaque exécution d'agent est représentée sous forme de graphe d'exécution à la git (gauche), à côté de sa chronologie d'événements. Les sous-agents parallèles ont chacun leur propre couloir ; le panneau de droite détaille les outils, modèles, hooks et la consommation de tokens pour l'exécution.*
+
+---
+
+## Voir en action
+
+Deux courtes vidéos illustrent les deux choses que les équipes recherchent en premier : tracer une exécution, et détecter automatiquement les défaillances.
+
+<div style={{ position: "relative", width: "100%", paddingBottom: "56.25%", height: 0, overflow: "hidden", borderRadius: "12px", margin: "1.5rem 0" }}>
+  <iframe src="https://www.youtube.com/embed/VWxukZc5k7s?autoplay=1&mute=1&loop=1&playlist=VWxukZc5k7s&rel=0&playsinline=1" title="Watch: Agent Tracing by Failproof AI (2 min)" allow="autoplay; encrypted-media; picture-in-picture; fullscreen" allowFullScreen style={{ position: "absolute", top: 0, left: 0, width: "100%", height: "100%", border: 0 }}></iframe>
+</div>
+
+*Traçage d'agent : suivez une exécution pas à pas, de l'objectif aux outils jusqu'à la réponse finale.*
+
+<div style={{ position: "relative", width: "100%", paddingBottom: "56.25%", height: 0, overflow: "hidden", borderRadius: "12px", margin: "1.5rem 0" }}>
+  <iframe src="https://www.youtube.com/embed/C5nHKGQIqZQ?autoplay=1&mute=1&loop=1&playlist=C5nHKGQIqZQ&rel=0&playsinline=1" title="Watch: Automatically find where your agent is failing (2 min)" allow="autoplay; encrypted-media; picture-in-picture; fullscreen" allowFullScreen style={{ position: "absolute", top: 0, left: 0, width: "100%", height: "100%", border: 0 }}></iframe>
+</div>
+
+*Failproof Audit : laissez Failproof AI Observability analyser vos logs sur l'ensemble des sessions et vous indiquer ce qu'il faut corriger.*
+
+---
+
+## Pourquoi les équipes l'utilisent
+
+- **Voyez ce que votre agent a réellement fait.** Chaque exécution devient un graphe d'exécution lisible à la git : quels outils ont fonctionné en parallèle, quels sous-agents ont divergé, où l'exécution s'est bloquée, et ce qu'elle a consommé.
+- **Détectez automatiquement les régressions de qualité.** Connectez un petit service de notation et Failproof AI Observability note chaque exécution terminée — une baisse d'utilité ou une hausse des hallucinations apparaît d'elle-même.
+- **Trouvez les défaillances pour lesquelles vous n'avez écrit aucune règle.** Des audits récurrents analysent vos logs sur l'ensemble des sessions pour repérer des clusters d'erreurs, des valeurs aberrantes de latence, des scores faibles et des exécutions bloquées, puis vous remettent des résultats classés et étayés par des preuves.
+- **Soyez alerté quand ça compte vraiment.** Des règles de seuil se déclenchent sur le taux d'erreur, la latence, le coût ou les scores d'évaluation, et ouvrent des incidents que vous pouvez prendre en charge, assigner et résoudre.
+- **Posez des questions en langage naturel.** Un assistant IA intégré au tableau de bord répond à des questions comme « comment évolue la qualité en production cette semaine ? » en s'appuyant sur vos propres données. Toute modification qu'il propose est soumise à validation.
+- **Gardez la maîtrise de vos données.** Failproof AI Observability est auto-hébergé : les événements, les prompts et les analyses restent dans une infrastructure que vous contrôlez.
+
+---
+
+## Ce que vous obtenez
+
+Failproof AI Observability s'articule autour de trois idées (**observer**, **analyser** et **administrer**), reflétées dans la barre latérale gauche du tableau de bord.
+
+**Observer** (la réalité brute de ce qui s'est passé) :
+
+- **[Flux d'événements](/fr/agenteye/event-stream)** : la trace en direct, étape par étape, de chaque exécution (appels d'outils, appels de modèles, hooks, erreurs).
+- **[Sessions](/fr/agenteye/sessions)** : ces événements regroupés en une ligne par exécution, chacune prête à être notée, avec un graphe d'exécution à la git.
+- **[Métriques de performance](/fr/agenteye/telemetry)** : cartes thermiques de latence par surface et indicateurs p50/p95/p99 pour les modèles, outils et hooks, pour qu'une valeur aberrante en queue de distribution ressorte clairement par rapport à la médiane.
+- **[Suivi des erreurs](/fr/agenteye/error-tracking)** : une surface de triage unique pour tout ce qui a dysfonctionné, à un clic d'une alerte déclenchée.
+
+![La page d'observation des outils : une carte thermique de latence, une bande de percentiles et un graphique de distribution des outils sur 24 plages temporelles](/agenteye/images/tools.png)
+
+*Chaque surface d'observation associe une sparkline et des indicateurs p50/p95/p99 à une carte thermique de latence et une bande de percentiles. Ici : Outils.*
+
+**Analyser** (transformer l'activité en réponses) :
+
+- **[Requêtes](/fr/agenteye/queries)** et **[tableaux de bord](/fr/agenteye/dashboards)** : du SQL sauvegardé sur vos événements et évaluations, représenté sous forme de graphiques dans des tableaux de bord partagés à l'échelle de l'organisation.
+- **[Évaluations](/fr/agenteye/evaluations)** : scores de qualité produits par votre propre service d'évaluation, avec le raisonnement associé à chaque score.
+- **[Audits](/fr/agenteye/audits)** : investigations récurrentes qui font remonter les patterns de défaillance sur l'ensemble des sessions.
+- **[Alertes](/fr/agenteye/alerts)** et **[incidents](/fr/agenteye/incidents)** : règles de seuil qui vous notifient, accompagnées d'un workflow d'incidents pour les trier.
+
+**Interfaces** (accédez à vos données à votre façon) :
+
+- **[CLI](/fr/agenteye/cli-and-agents)** : pilotez l'ensemble de votre déploiement depuis le terminal ou un script, et laissez un agent de développement le faire pour vous en langage naturel.
+- **[Assistant IA](/fr/agenteye/assistant)** : posez des questions sur vos agents en langage naturel, directement depuis le tableau de bord.
+- **API REST** : tout ce que font le tableau de bord et la CLI est soutenu par une API REST que vous pouvez appeler directement avec une [clé API](/fr/agenteye/api-keys) à portée limitée — ingérer des événements, interroger des sessions et des évaluations, et gérer des tableaux de bord, alertes, audits, utilisateurs et clés, pour intégrer Failproof AI Observability dans vos propres outils.
+
+**Administrer** (faites-le tourner pour votre équipe) :
+
+- **[Clés API](/fr/agenteye/api-keys)** : tokens à portée limitée pour le collecteur, le tableau de bord et l'assistant.
+- **Utilisateurs** : connexion sans mot de passe, par e-mail avec liste d'autorisation.
+- **Paramètres** : configuration par organisation, y compris les surcharges de fenêtre de contexte des modèles.
+
+---
+
+## Comment les pièces s'articulent
+
+Les données circulent dans un seul sens, de votre code d'agent vers le tableau de bord : votre agent (via le SDK Python) émet des événements vers l'agenteye-collector, qui les achemine vers le serveur, lequel sert le tableau de bord. Deux services optionnels complètent l'ensemble — un service de notation (évaluations) et un service d'assistant IA (le chat intégré au tableau de bord).
+
+- **SDK Python** : vous ajoutez quelques appels `agenteye.event.*` à votre agent ; les événements sont mis en mémoire tampon localement.
+- **agenteye-collector** : un démon léger sur chaque machine agent qui regroupe les événements en lots et les envoie au serveur.
+- **Serveur** : ingère vos événements, maintient l'état opérationnel dans vos propres bases de données, et expose l'API REST utilisée par le tableau de bord, la CLI et vos propres intégrations.
+- **Tableau de bord** : l'endroit où vous explorez tout.
+- **Services optionnels** : un service de notation (évaluations) et un service d'assistant IA (le chat intégré au tableau de bord).
+
+Pour le vocabulaire utilisé tout au long de la documentation (*event, session, evaluation, audit, finding, incident*), consultez [Concepts](/fr/agenteye/concepts).
+
+---
+
+## Obtenir Failproof AI Observability
+
+Failproof AI Observability est un produit entreprise de Failproof AI, et fonctionne en complément de Failproof AI Enforcement — le produit de politiques et de garde-fous — sous la marque Failproof AI. Il fonctionne entièrement dans votre propre environnement. Si vous n'avez pas encore accès aux packages, demandez une démo et nous vous aiderons à démarrer : écrivez à [nikita@befailproof.ai](mailto:nikita@befailproof.ai).
+
+---
+
+## Prochaines étapes
+
+- [Concepts](/fr/agenteye/concepts) : le vocabulaire de Failproof AI Observability en un seul endroit.
+- [Observabilité](/fr/agenteye/observability) : suivez ce que font vos agents, exécution par exécution.
+- [Sécurité](/fr/agenteye/security) : comment Failproof AI Observability maintient vos données isolées et sous votre contrôle.

package/.next/standalone/docs-old/fr/agenteye/python-sdk-skill.mdx

@@ -0,0 +1,135 @@
+---
+title: "Compétence Agent du SDK Python Failproof AI Observability"
+description: "Passez d'un agent non instrumenté à des événements visibles, votre agent de codage trouvant les points d'instrumentation, les écrivant et prouvant qu'ils ont bien été intégrés."
+---
+
+Dites à votre agent de codage *« ajoute Failproof AI Observability à cet agent »* et laissez-le lire votre boucle, déterminer où placer l'instrumentation, l'écrire et vérifier les événements avant de considérer le travail terminé.
+
+La **compétence SDK Python** (`agenteye-python-sdk`) est une *Agent Skill* : un dossier d'instructions qu'un agent de codage tel que Claude Code ou Codex charge à la demande lorsqu'une tâche lui correspond. Elle apprend à l'agent à utiliser le [SDK Python](/fr/agenteye/python-sdk) — ce n'est pas une bibliothèque, et elle ne modifie en rien le fonctionnement du SDK.
+
+## L'instrumentation est facile à écrire et facile à rater silencieusement
+
+Le SDK est minimaliste : treize méthodes d'événements, toutes avec des paramètres nommés uniquement. Un agent de codage peut lire la référence du [SDK Python](/fr/agenteye/python-sdk) et produire une instrumentation plausible en une minute.
+
+Le problème, c'est que ce SDK ne lève pas d'exception en cas d'erreur, et une mauvaise instrumentation ressemble exactement à une bonne instrumentation jusqu'à ce que quelqu'un ouvre un tableau de bord et le trouve vide. Les erreurs qui font perdre du temps sont toutes des silences :
+
+| L'erreur | Ce que vous voyez |
+|---|---|
+| Pas de `agent_start` | Tous les événements arrivent. Zéro session. |
+| Environnement jamais défini | Tout fonctionne, classé sous `dev`. |
+| `outcome="failure"` | L'exécution s'affiche en vert — seuls `failed`, `error`, `timeout`, `rejected` comptent. |
+| Un nom de champ mal orthographié | Accepté et stocké comme nouveau champ. |
+| Événements émis depuis un pool de threads | Silencieusement abandonnés. |
+
+Aucun de ces cas ne lève d'exception. Aucun n'apparaît dans les tests. Chacun est documenté dans la compétence, énoncé comme un contrat avec la vérification qui le détecte.
+
+## Ce qu'elle fait, dans l'ordre
+
+La compétence exécute les trois mêmes étapes qu'un ingénieur rigoureux suivrait :
+
+1. **Planifier.** Elle lit votre boucle d'agent et pose les deux questions auxquelles vous seul pouvez répondre : ce qui constitue une exécution (votre `session_id`), et qui sont les acteurs distinguables (votre `agent_id`). Elle obtient un accord sur ces points avant d'écrire du code, car les modifier plus tard divise votre historique et casse les tendances.
+2. **Écrire.** Elle lie l'identité une seule fois par exécution plutôt que de la propager à travers chaque point d'appel, et elle choisit une forme sûre pour la concurrence — un détail qui compte, car le raccourci évident mélange silencieusement deux exécutions simultanées en une seule session.
+3. **Vérifier.** Elle exécute votre agent et lit les fichiers d'événements résultants, en vérifiant que `agent_start` est présent, que l'environnement est correct et qu'une exécution a produit une session.
+
+Cette troisième étape est celle que les gens ignorent. Le SDK écrit les événements dans des fichiers locaux, donc une intégration complète peut être prouvée sur un ordinateur portable sans serveur, sans clé API et sans réseau — c'est précisément pourquoi la compétence insiste pour le faire.
+
+## Son rapport aux autres compétences
+
+Trois compétences, une séparation nette :
+
+| Compétence | À utiliser quand | Ce qu'elle modifie |
+|---|---|---|
+| **Compétence SDK Python** (cette page) | Vous voulez que votre agent *émette* de la télémétrie — « ajoute de l'observabilité », « pourquoi mon agent n'apparaît pas ? » | Écrit du code dans le dépôt de votre agent. Ne lit rien. |
+| **[Compétence Evaluator](/fr/agenteye/evaluator-skill)** | Vous voulez *noter* les exécutions — « que devrions-nous même mesurer ? » | Écrit du code dans votre dépôt ; lit la télémétrie |
+| **[Compétence CLI](/fr/agenteye/cli-skill)** | Vous voulez *lire* ce qui s'est passé, ou opérer votre déploiement | Pilote la CLI en votre nom, y compris les modifications |
+
+Elles se relaient dans cet ordre : cette compétence fait circuler les événements, l'évaluateur les note, la CLI les relit. Il n'y a rien à évaluer et rien à lire tant que votre agent n'émet pas de sessions — donc si vous partez de zéro, commencez ici.
+
+## Prérequis
+
+1. **Python 3.10+** et la base de code de l'agent que vous souhaitez instrumenter.
+2. **Le SDK.** Il est distribué aux clients sous forme de wheel privé plutôt que depuis un index public — votre intégration couvre comment l'obtenir et l'installer. La compétence connaît le chemin d'installation et vous demandera plutôt que de deviner si elle ne le trouve pas.
+3. **Rien d'autre.** Pas de connexion au tableau de bord, pas de clé API, pas de réseau. La compétence vérifie à partir des fichiers d'événements que le SDK écrit, elle peut donc terminer et prouver son travail hors ligne.
+
+## Où l'obtenir
+
+La compétence se trouve dans la collection publique [`FailproofAI/skills`](https://github.com/FailproofAI/skills) :
+
+```bash
+npx skills add FailproofAI/skills --skill agenteye-python-sdk -a claude-code
+```
+
+Ajoutez `-g` pour l'installer pour tous les projets plutôt que pour le seul projet en cours, et `--copy` si votre environnement ne suit pas les liens symboliques. Pour Codex, passez `-a codex`.
+
+## Installation manuelle
+
+Les Agent Skills sont des dossiers contenant un `SKILL.md` et des références associées. Si vous préférez ne pas utiliser l'installateur :
+
+- **Claude Code** : copiez le dossier `agenteye-python-sdk/` dans `~/.claude/skills/` (tous les projets) ou `<votre-dépôt>/.claude/skills/` (ce dépôt uniquement). Claude Code le découvre automatiquement — vérifiez la liste `/skills`, ou posez simplement une question qui lui correspond.
+- **Codex** : Codex lit le même `SKILL.md`. Le fichier `agents/openai.yaml` inclus définit `allow_implicit_invocation: true`, il est donc auto-sélectionné quand une tâche lui correspond ; sinon invoquez-le avec `$agenteye-python-sdk`.
+
+Exécutez votre agent **dans le dépôt contenant le code que vous souhaitez instrumenter** — la compétence lit votre boucle d'agent avant de proposer quoi que ce soit.
+
+## À quoi ressemble une session
+
+```text
+vous  ▸ Ajoute Failproof AI Observability à cet agent.
+
+agent ▸ J'ai lu votre boucle — un dispatcheur d'outils dans tools.py, un
+        wrapper Anthropic dans llm.py. Deux questions avant d'écrire quoi
+        que ce soit.
+
+        Qu'est-ce qui constitue une exécution ? Vous gérez les requêtes
+        en parallèle, donc j'utiliserais l'id de requête que vous avez
+        déjà dans ctx.request_id — ainsi une session ici et une requête
+        dans vos logs sont la même chaîne.
+
+        Et qui sont les acteurs ? Je vois un chemin planificateur et un
+        chemin chercheur. Les étiqueter séparément, ou c'est un seul
+        agent pour vous ?
+
+vous  ▸ L'id de requête, c'est bon. C'est un seul agent, appelez-le "assistant".
+
+agent ▸ Terminé. J'ai enveloppé le dispatcheur et le client LLM ;
+        agent_start et agent_end encadrent handle_request, y compris le
+        chemin d'erreur. J'ai utilisé un contexte local pour l'identité
+        — votre dispatcheur exécute les outils dans un pool de threads,
+        et l'approche plus simple aurait mélangé des exécutions
+        simultanées en une seule session sans se plaindre.
+
+        Vérifié sur une vraie exécution : 11 événements dans 4 fichiers —
+        agent_start, model_request/response, tool_use/tool_result x3,
+        agent_end (outcome=success). environment=production, une session
+        par requête, durées appariées.
+
+        Une chose que je n'ai PAS faite : votre pool de workers dans
+        batch.py soumet directement à l'executor, donc les événements
+        venant de là seraient perdus. Voulez-vous que je corrige ça aussi ?
+```
+
+Le schéma à remarquer : il a lu le code avant de proposer, n'a posé que les questions auxquelles vous seul pouvez répondre, a réutilisé un id que vous aviez déjà, a choisi la forme sûre pour la concurrence *parce qu'* il a vu un pool de threads, et **a vérifié en lisant les événements réels** plutôt qu'en déclarant le succès — puis a signalé l'endroit qu'il savait qui échouerait silencieusement.
+
+## Ce que vous pouvez lui demander
+
+- *« Pourquoi mon agent n'apparaît pas sur le tableau de bord ? »* → parcourt l'échelle : les événements sont-ils écrits, `agent_start` est-il présent, l'environnement est-il correct, le collecteur lit-il au bon endroit.
+- *« Tout arrive sous dev. »* → l'environnement n'a jamais été défini, ou a été réinitialisé par un appel ultérieur.
+- *« Ajoute le suivi des tokens. »* → trouve votre wrapper LLM et enregistre le modèle, la raison d'arrêt et l'utilisation.
+- *« Instrumente aussi les sous-agents. »* → une session, des étiquettes d'agent distinctes, imbriqués sous leur parent.
+- *« Écris des tests pour l'instrumentation. »* → pointe le SDK vers un répertoire temporaire et effectue des assertions sur les événements qu'il a écrits.
+
+## Points de vigilance
+
+**Laissez-le vérifier.** L'étape qui rend cette compétence utile est la dernière — exécuter votre agent et relire les événements. Un agent qui écrit l'instrumentation et s'arrête a fait la moitié facile, et la moitié qui échoue silencieusement, c'est l'autre.
+
+**Convenez des noms avant le code.** `session_id` et `agent_id` sont les axes selon lesquels chaque surface regroupe les données. Les renommer plus tard divise l'historique : les anciennes exécutions conservent les anciennes étiquettes et vos tendances se cassent. La compétence posera la question ; la réponse mérite une minute de réflexion.
+
+**Si votre agent propose d'installer le SDK depuis un index public, la compétence n'a pas été chargée.** Le SDK est distribué en privé. Cette proposition est un signe révélateur que votre agent de codage improvise plutôt que de suivre la compétence — arrêtez-le là et vérifiez que la compétence est installée.
+
+En dehors de cela, son rayon d'action est limité : elle écrit du code dans votre répertoire de travail et des fichiers d'événements là où vous lui indiquez. Elle ne lit rien de votre déploiement et n'y change rien.
+
+## Étapes suivantes
+
+- **[SDK Python](/fr/agenteye/python-sdk)** : la référence complète des événements — chaque type d'événement et chaque champ — derrière ce que cette compétence automatise.
+- **[Sessions](/fr/agenteye/sessions)** : ce que produit votre instrumentation une fois les événements reçus.
+- **[Agent Skill Evaluator](/fr/agenteye/evaluator-skill)** : l'étape suivante une fois que les exécutions arrivent — les noter.
+- **[Agent Skill CLI](/fr/agenteye/cli-skill)** : relire votre télémétrie.