# Observabilité

> Ce que vous pouvez observer de votre intégration (en-têtes, identifiants, page Usage de Platform), ce que Noryo journalise de chaque tentative, et ce qu'il ne journalise jamais.

L'observabilité d'une intégration repose sur deux sources : ce que chaque réponse vous dit, et la page [Usage](https://platform.noryo.app/usage) de Platform. Noryo garde de son côté un journal par tentative, que le support consulte à partir du `Noryo-Request-Id`.

## Ce que chaque réponse vous dit

| Signal | Où | À quoi il sert |
|---|---|---|
| `Noryo-Request-Id` | En-tête de chaque réponse | Identifier la tentative, la citer au support |
| Statut HTTP et `code` | Statut, corps d'erreur | Classer les erreurs : à corriger, à reprendre |
| `enrichment.status`, `enrichment.reason` | Corps `200` | Mesurer la couverture : part de `resolved`, `partial`, `not_found` |
| `usage.billable`, `usage.units` | Corps `200` des routes `POST` | Suivre la consommation |
| `Noryo-Idempotency-Replayed` | En-tête des `200` `POST` | Compter les rejeux, et ne pas compter leur `usage` deux fois |
| `usage.deduplicated` | Corps `200` des routes `POST` | Compter les transactions renvoyées |
| `Noryo-RateLimit-Remaining` | En-tête de chaque `200` et des `429` | Anticiper la limite de débit |
| `enrichment.environment` | Corps `200` | Vérifier qu'une clé de Production sert bien la Production |

## Ce qu'il est utile de journaliser

Une ligne par tentative, avec : le `Noryo-Request-Id`, votre `Idempotency-Key`, la route, le statut HTTP, le `code` d'erreur s'il y en a un, `enrichment.status`, `Noryo-Idempotency-Replayed`, et votre propre mesure de latence. Avec ces champs, vous pouvez calculer votre taux d'erreur, votre taux de reprise, votre couverture et votre consommation sans dépendre d'une autre source.

Ne journalisez ni l'en-tête `Authorization`, ni le secret de la clé.

## La page Usage de Platform

La section Merchant API de la page [Usage](https://platform.noryo.app/usage) couvre les trente derniers jours du workspace :

| Vue | Contenu |
|---|---|
| Par jour | Appels, unités, et répartition `resolved`, `partial`, `not_found`, `engine_error`, `429`, rafraîchissements |
| Appels récents | `request_id`, date, `enrichment_id`, résultat, type d'appel, unités |

Elle ne compte que les appels qui ont produit un résultat : les tentatives refusées avant le calcul (`401`, `400` de validation, `429` de votre seau) et les rejeux n'y figurent pas. Elle n'affiche ni latences ni codes HTTP : ces mesures n'existent que dans le journal d'exploitation de Noryo. Pour un suivi exhaustif, vos propres journaux restent la référence.

## Ce que Noryo journalise de chaque tentative

Noryo écrit une ligne par tentative HTTP, y compris les tentatives refusées : un `401` ou un `415` laisse aussi sa ligne. Cette ligne porte l'identifiant de la tentative, la route (sous forme de gabarit, jamais le chemin tapé), la méthode, le statut, le code public, l'environnement, le statut du résultat, l'indication de rejeu ou de limite de débit, et le temps passé par étape : authentification, limite de débit, moteur, règlement.

Pour relier les lignes sans désigner personne, le workspace et la clé y figurent sous forme de **pseudonymes**, et l'`Idempotency-Key` et l'`external_transaction_id` sous forme d'**empreintes HMAC tronquées**, d'où la valeur ne peut pas être retrouvée.

## Ce que Noryo ne journalise jamais

- l'en-tête `Authorization`, le secret d'une clé, son vérificateur ;
- le libellé brut ;
- la valeur brute d'une `Idempotency-Key` ou d'un `external_transaction_id` ;
- le corps de la requête, et l'identité marchande rendue.

C'est pourquoi le support vous demandera un `Noryo-Request-Id`, et jamais votre libellé ni votre clé.

---

Page canonique : https://developer.noryo.app/fr-FR/merchant/operations/observability