---
tags: Mode d'emploi
---

# Modifications des preuves à posteriori

Ce document traite de la question des **modifications ou invalidations** de preuve à posteriori de son envoi.

Le principal problème de cette fonctionnalité est qu'elle a des impacts sur plusieurs autres systèmes :
- le moteur d'incitation ;
- l'édition d'attestation ;
- le moteur de détection d'anomalie.

Idéalement, il faudrait que les modifications se fassent dans le laps de temps autorisé par le registre de preuve de covoiturage ([5 jours](https://registre-preuve-de-covoiturage.gitbook.io/produit/mode-demploi/envoyer-des-trajets#quel-est-le-delai-denvoi-des-preuves-de-covoiturage)) actuellement. Comme cela ne correspond pas au besoin des opérateurs, il faut proposer des solutions alternatives.

## Impacts
### Incitations
Sur le moteur d'incitation, actuellement, on fonctionne en "flux tendu", un trajet est envoyé pour être processé 5 jours après sa réalisation (un trajet du 11 est processé le 16). Si on fait le calcul, le résultat va :
- être accessible par les AOM ;
- être accessible par les opérateurs - notamment ceux qui n'ont pas de moteur de calcul en interne ;

On ne peut pas modifier ce résultat puisqu'il est public. Si on a un trajet qui est invalidé par la suite, cela peut avoir un impact sur l'ensemble des calculs d'incitation qui suivent :
- problème de plafond de trajet par jour ;
- problème de plafond de budget ;
- etc.

### Attestations
De manière analogue, l'édition d'attestation est une photographie a un instant T, difficile de l'éditer sachant qu'un trajet pourrait être invalidé par la suite.

### Anomalies & Fraudes
Sur le moteur de détection d'anomalie, l'impact est limité : on peut refaire passer les calculs. Par contre, lorsque le moteur de détection d'anomalie impacte le moteur d'incitation, alors, on a le même problème que pour celui-ci.

## Pistes de travail
Pour essayer de trouver une solution qui convienne, il faut :
- permettre d'invalider un trajet dans un laps de temps qui suit son envoie ;
- que l'intégrité du résultat des calculs d'inciation/ de fraude sont conservées.

La solution que nous proposons est de décaler l'application des 3 systèmes dépendants de l'acquisition à la fin de la période sur laquelle les trajets peuvent être modifiés/supprimés. L'impact concret est donc un décalage plus important qu'actuellement entre la date du trajet et son traitement.

### Période
Sur ce décalage, deux possibilités :
- soit on est sur un nombre de jour glissant - par ex 30 jours ;
- soit on est sur une période fixe - par ex, chaque mois.

Pour permettre aux AOMs d'avoir des chiffres - bien que non "réel" - on peut faire un mix entre le système actuel de traitement à J+5 (draft) et un calcul **complet** en fin de période. Les première données ne servant finalement qu'à des fins d'affichage.

### Scope (modification vs invalidations)
Concernant le scope, deux possibilités :
- modification des trajets à posteriori ;
- invalidation des trajets à posteriori.

Il semble que la modification des trajets à posteriori revienne à modifier la période à laquelle les opérateurs doivent envoyer les trajets. Par ailleurs, les effets de bords potentiels sont à mesurer. **C'est pourquoi, dans un premier temps, nous proposons de nous limiter à l'invalidation**.

## Synthèse
Mise en place d'une période de calcul (exemple, J+X, la périodicité est à discuter voir ci-avant) :
- Envoie des trajets par les opérateur, via API, à J+5 au plus tard ;
- Traitement de ces données pour incitation à J+5 en version "draft". Ces données sont accessibles par les AOMs pour prévisualiser leurs incitations ;
- Lancement du traitement fraude à J+X ;
- Lancement des calculs d'incitation à J+X (après la fraude) ;
- Ouverture des points d'API "attestation" à J+X ;

## Endpoints
### Endpoint d'invalidation d'un trajet
- DELETE /journeys/{journey_id}
Request :

{
    code: 1,
    message: "Too many trip in period"
}

Response :
- OK
- code 204
- pas de body
- Not found
- 404
- Hors délais
- 403

---
---

### Endpoint d'information sur un trajet
- GET /journeys/{journey_id}
Response
- OK 200
- Not Found 404 (mm si journey_id d'un autre opé)

{
    journey_id: "",
    status: "accepted",
    error: {},
    result: {},
}

Status possible =

const status = [
  "waiting_normalization", // received, waiting for processing 
  "acquisition_error", // received but not saved due to acquisition error
  "normalization_error", // processing error
  "waiting_fraudcheck"  // processed, waiting for fraudcheck
  "fraudcheck_error", // fraudcheck detected
  "canceled", // cancelled by operator
  "ok", // evrything is ok :)
]

## Retours du webinaire
Les opérateurs en présence n'ont pas utilisé de VETO. Les propositions faites semblent être acceptées par tous.

Proposition des opérateurs : standardiser les retours d’erreurs.

Du point de vue technique les règles sont divisées en deux catégories :
* Règles basiques.
* Règles avec états.

Chronologie :
- Envoie des trajets par les opérateur, via API, à J+5 au plus tard ;
- Traitement de ces données pour incitation à J+5 en version "draft" avec des règles basiques. Ces données sont accessibles par les AOMs pour prévisualiser leurs incitations ;
- Lancement du traitement fraude à J+X ;
- Itération des calculs d'incitation (règles avec états) le 6 de chaque mois sur les données du mois précédent ;
- Opération 1 : annulation des incitations sur les trajets annulés ;
* Opération 2 : application des limites (exemple : 10 trajets / mois) ;
* Opération 3 : restriction externe (exemple : priorisation des campagnes).
- Ouverture des points d'API "attestation" à J+X.