---
title: Comment ajouter une nouvelle capacité (API)
description: Pour les clients déjà intégrés via API (POST /v1/process) avec la Classification du risque de fraude (Trust Network) qui ajoutent la Vérification d'identité à leur contrat.
canonical: https://developer.unico.io/fr/dual-api/developers/api-reference/api/upgrade-guide
locale: fr
generated_by: markdown-export
---

:::info
Ce guide s'adresse aux clients déjà intégrés via **API** (`POST /processes/v1`) avec la Classification du risque de fraude (Trust Network) et qui ajoutent la Vérification d'identité à leur contrat.
:::

## Ajout de la Vérification d'identité

Ce guide explique l'évolution du moteur de décision visant à renforcer vos processus de validation d'identité.

:::warning[Exigence technique]
Contrairement aux autres intégrations, l'activation de cette capacité **nécessite la mise à jour de votre clé API**. Sans ce changement, vous ne pourrez pas recevoir les nouvelles réponses de validation d'identité — votre contact Unico vous les communiquera.
:::

### Le grand changement : la Vérification d'identité

La principale amélioration est la capacité à valider l'identité du titulaire (en plus des réponses de fraude). Le système vérifie désormais si la personne effectuant le processus est bien le titulaire du document fourni.

Il est essentiel que votre équipe comprenne et cartographie correctement la nouvelle interprétation des réponses avant l'activation de la capacité, afin de ne pas impacter votre opération.

### Tableau comparatif des résultats

| Résultat (Trust uniquement) | Résultat (Trust + IDUnico) | Signification et action recommandée |
|---|---|---|
| N/A | `APPROVED` | **Nouveau (état idéal).** L'utilisateur est le titulaire de la pièce d'identité et aucune preuve de fraude n'est détectée. |
| `INCONCLUSIVE` | `INCONCLUSIVE` | **Changement de nuance.** L'utilisateur est réel et aucune preuve de fraude n'est détectée, mais il n'y a pas de certitude qu'il soit le titulaire de la pièce d'identité. |
| `REPROVED` | `REPROVED` | **Rejet recommandé.** Indicateurs de fraude, ou le système a confirmé que l'utilisateur n'est pas le titulaire de la pièce d'identité. |
| `HIGH_RISK` | `HIGH_RISK` | Au moins une preuve de fraude forte. Le client décide de l'action à mener. |
| `CRITICAL_RISK` | `CRITICAL_RISK` | Au moins deux preuves de fraude critiques. Rejet recommandé. |

### Principaux changements de nomenclature

Assurez-vous que votre système est prêt à mapper ces trois changements fondamentaux dans votre flux d'approbation :

1. **L'arrivée de `APPROVED`** — c'est désormais l'état « idéal ». Si vous recevez ce code, vous avez la certitude totale de l'identité et de la sécurité du processus.
2. **La nouvelle nuance de `INCONCLUSIVE`** — auparavant votre principal feu vert. Cela signifie désormais que la personne est « réelle » et qu'il n'y a pas de fraude évidente, mais que le système n'a pas pu la relier à l'identité de la pièce d'identité avec une certitude totale.
3. **La sévérité de `REPROVED`** — en plus des indicateurs de fraude multifactoriels, cet état inclut désormais également les cas où l'utilisateur usurpe l'identité du titulaire de la pièce d'identité.