# Cycle de vie

> La vie d'une transaction et de ses enrichissements, du premier appel à l'expiration du contenu : rejeux, rafraîchissements, résultat courant, purge à 90 jours et ce qui survit.

Cette page suit une transaction dans le temps. Elle suppose que les appels portent un `external_transaction_id` et une `Idempotency-Key`, comme recommandé.

## Chronologie

| Moment | Événement | Ce que voit le client |
|---|---|---|
| J0, premier appel | Création : Noryo calcule, règle, mémorise la réponse sous l'`Idempotency-Key`, enregistre la transaction et son entrée économique | `200`, `enr_A`, statut du résultat, `usage` |
| J0, reprise avec la même clé | Rejeu idempotent | `200`, même corps, `Noryo-Idempotency-Replayed: true` |
| J0 à J0 + 24 h | La clé reste liée à cette requête | Une autre requête avec la même clé : `409 idempotency_key_reuse` |
| Au-delà de 24 h | La mémoire d'idempotence expire | La clé est libre ; la transaction, elle, reste connue |
| N'importe quand, même transaction renvoyée | Déduplication économique | `200`, résultat courant, `deduplicated: true`, non facturé |
| N'importe quand, rafraîchissement | Nouveau calcul de la même transaction | `200`, **nouvel** `enr_B`, en-tête `Location` |
| J0 + 90 jours | Le contenu de chaque résultat est purgé à l'issue de sa rétention | `GET` : `410 result_content_expired` |
| Après la purge, même transaction renvoyée | La transaction est connue, son contenu non | `410 result_content_expired` |
| Après la purge, rafraîchissement | Nouveau calcul, nouveau contenu | `200`, nouvel `enrichment_id`, facturé s'il aboutit |

La rétention de 90 jours s'applique au contenu de chaque résultat ; un résultat produit par un rafraîchissement a sa propre durée de conservation. Un résultat `not_found` n'a pas de contenu : il n'est jamais purgé et ne rend jamais `410`.

## Le résultat courant

Une transaction a toujours un résultat courant, celui qu'un nouvel envoi rend en déduplication :

- au départ, c'est le résultat de la création, quel que soit son statut (`resolved`, `partial` ou `not_found`) ;
- un rafraîchissement qui aboutit (`refresh_recalculated`) le remplace ;
- un rafraîchissement `partial` ou `not_found` est consigné avec son propre `enrichment_id`, mais ne le remplace pas ;
- une panne du moteur (`503 engine_error`) ne crée aucun résultat et ne remplace rien : l'`enrichment_id` que porte son corps ne désigne que la tentative échouée.

## Chaque `enrichment_id` est figé

```text
enr_A  ──>  résultat de la création       (toujours lisible tel quel jusqu'à sa purge)
enr_B  ──>  résultat du rafraîchissement  (devient le résultat courant s'il est refresh_recalculated)
```

Une lecture `GET` rend le résultat de l'identifiant demandé, jamais un autre. Pour suivre le dernier résultat d'une transaction, enregistrez l'identifiant rendu par chaque rafraîchissement.

## Ce qui survit à la purge

| Élément | Après 90 jours |
|---|---|
| Contenu du résultat (`merchant`, statut lisible) | Purgé |
| `enrichment_id` | Conservé : il rend `410`, pas `404` |
| Identité économique de la transaction | Conservée : la déduplication et le rafraîchissement restent possibles |
| Ligne de registre, unités, prix, horodatages comptables | Conservés : vous pouvez toujours prouver ce que vous avez acheté et quand |
| Libellé brut | Jamais conservé, à aucun moment |

## Sans `external_transaction_id`

Un enrichissement créé avec une seule `Idempotency-Key` a une vie plus courte : il est rejouable pendant 24 heures, lisible pendant 90 jours, mais il n'est rattaché à aucune transaction. Il ne se déduplique pas et ne se rafraîchit pas (`409 refresh_not_available`).

Voir aussi [Rafraîchir](https://developer.noryo.app/fr-FR/merchant/refresh) et [Rétention et 410](https://developer.noryo.app/fr-FR/merchant/retention).

---

Page canonique : https://developer.noryo.app/fr-FR/merchant/enrichments/lifecycle