> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Cycle de vie : états utilisateur et entreprise > Cycle de vie des entités Didit : états Utilisateur et Entreprise, passages ACTIVE/FLAGGED/BLOCKED et suppression. Paiement à l'appel. Chaque entité User et Business dans Didit suit un cycle de vie prévisible. Comprendre ce cycle est essentiel pour concevoir vos flux d'onboarding, de surveillance continue et de remédiation. ## Schéma du cycle de vie ```mermaid theme={null} stateDiagram-v2 [*] --> ACTIVE: Created (API, console, or auto from session) ACTIVE --> FLAGGED: Rule match / analyst review / suspicious pattern FLAGGED --> ACTIVE: Analyst clears / remediation completed ACTIVE --> BLOCKED: Manual block / blocklist match FLAGGED --> BLOCKED: Investigation concludes blocked BLOCKED --> ACTIVE: Manual unblock (analyst only) ``` ## Détail des statuts | Statut | Signification | Effet | | - | - | - | | `ACTIVE` | Par défaut : l'entité est en règle | Les nouvelles sessions et transactions passent par vos workflows et règles configurés | | `FLAGGED` | L'entité présente un problème en attente nécessitant un examen | Les nouvelles sessions sont tout de même traitées, mais passent par défaut en `IN_REVIEW` ; les transactions peuvent être escaladées automatiquement selon les règles | | `BLOCKED` | L'entité est bloquée sur votre plateforme | Les nouvelles sessions sont refusées automatiquement ; les nouvelles transactions sont refusées automatiquement ; aucun nouveau lien de session ne peut être créé pour ce `vendor_data` | > [!NOTE] > > La modification du statut via `PATCH /v3/users/{vendor_data}/update-status/` ou `PATCH /v3/businesses/{vendor_data}/update-status/` émet un webhook (`user.status.updated` / `business.status.updated`) afin que vos systèmes en aval puissent réagir en temps réel. ## Phases du cycle de vie **1. Création** Une entité est créée de l'une des trois façons suivantes : * **Créée automatiquement** lorsque vous démarrez une session avec un nouveau `vendor_data`. L'entité est créée au statut `ACTIVE`. * **Précréée via l'API** à l'aide de `POST /v3/users/create/` ou `POST /v3/businesses/create/`. Le statut est `ACTIVE` par défaut. * **Créée dans la console** par un responsable de la conformité : le statut est initialement `ACTIVE`, sauf si l'opérateur en décide autrement. Chaque entité reçoit un `uuid` généré par Didit et un identifiant `vendor_data` appartenant au client. **2. Vérification** Les sessions sont rattachées à l'entité via `vendor_data`. Chaque session passe par votre [workflow](https://docs.didit.me/fr/console/workflows.md) configuré : vérification d'identité, détection du vivant, correspondance faciale, filtrage AML, documents, recherche dans le registre pour les KYB, et ainsi de suite. Les sessions terminées mettent à jour les compteurs agrégés de l'entité : * `session_count`, `approved_count`, `declined_count`, `in_review_count` * la map `features` : le dernier statut de chaque fonctionnalité sur l'ensemble des sessions (par exemple `{ "id_verification": "APPROVED", "aml": "IN_REVIEW" }`) * les champs de profil sont repris de la dernière session approuvée (par exemple `full_name`, `date_of_birth`, `portrait_image`). **3. Utilisation active** Une fois qu'une entité compte une ou plusieurs sessions approuvées, vous pouvez : * **Soumettre des transactions** faisant référence à l'entité via `vendor_data` dans le payload de la transaction * **Lancer une surveillance AML continue** : analyses périodiques des listes de sanctions, de PPE et de presse négative * **Procéder à une revérification selon un calendrier** : créer de nouvelles sessions pour le même `vendor_data` à intervalles réguliers * **Agréger les signaux de risque** entre les sessions et les transactions **4. Transitions de statut** Le statut d'une entité change automatiquement ou manuellement. **Transitions automatiques** * `ACTIVE → FLAGGED` lorsqu'une transaction dépasse le seuil d'examen ou qu'une règle ajoute l'entité à une liste de surveillance. * `ACTIVE → BLOCKED` lorsqu'une biométrie faciale correspond à une entrée de la liste de blocage. Une session refusée n'ajoute pas l'entité à la liste de blocage et ne modifie donc pas son statut. Le blocage d'un sujet refusé est une étape manuelle : ajoutez l'entrée depuis la [page Liste de blocage](https://docs.didit.me/fr/console/blocklist-users.md) ou via l'[API Lists](https://docs.didit.me/fr/management-api/lists/overview.md). Une entrée de type `USER` (le `vendor_data`) fait passer le statut à `BLOCKED`. **Transitions manuelles** : elles se produisent lorsqu'un analyste modifie le statut depuis la console, ou lorsque vous appelez l'endpoint `update-status`. Chaque transition émet un webhook `user.status.updated` ou `business.status.updated`. **5. Suppression** Les entités sont supprimées via `POST /v3/users/delete/` ou `POST /v3/businesses/delete/` (en lot). L'enregistrement de l'entité est supprimé définitivement. La suppression d'un User purge également chaque [gabarit biométrique](https://docs.didit.me/fr/management-api/biometric-templates/overview.md) conservé pour lui après la suppression de ses sessions, de sorte que la personne ne correspond plus lors de la détection de doublons ni dans la Recherche faciale. Les sessions de vérification ne sont pas couvertes par ces endpoints, pas plus que les transactions. Supprimez les sessions avec [Supprimer une session](https://docs.didit.me/fr/sessions-api/delete-session.md) ou [Supprimer des sessions en lot](https://docs.didit.me/fr/management-api/sessions/batch-delete.md) ; les transactions se suppriment depuis la console. ## Horodatages d'activité Les entités enregistrent leur activité afin de vous aider à repérer les profils inactifs ou actifs : | Horodatage | Mis à jour lorsque | | - | - | | `first_session_at` | La première session a été créée pour cette entité | | `last_session_at` | La session la plus récente a été créée ou mise à jour | | `last_activity_at` | Un changement est intervenu : session, transaction, changement de statut ou mise à jour du profil | Utilisez ces horodatages pour filtrer les entités inactives, planifier les revérifications ou déclencher la surveillance continue. ## Événements émis pendant le cycle de vie | Phase du cycle de vie | Webhooks émis | | - | - | | Création (automatique à partir d'une session) | `status.updated` (session), `user.data.updated` ou `business.data.updated` | | Vérification | `status.updated` (session), `data.updated` | | Changement de statut | `user.status.updated` ou `business.status.updated` | | Transaction soumise | `transaction.created` | | Changement de statut d'une transaction | `transaction.status.updated` | Consultez les [webhooks d'entité](https://docs.didit.me/fr/entities/webhooks.md) pour la structure des payloads et les modalités de livraison. ## Étapes suivantes > [card] [Liaison avec vendor\_data](https://docs.didit.me/fr/entities/vendor-data-linking.md) > > Comment `vendor_data` relie les sessions, les transactions et les entités entre elles. > [card] [Opérations sur les Users](https://docs.didit.me/fr/entities/users/operations.md) > > Créer, mettre à jour, modifier le statut et supprimer les entités User. > [card] [Opérations sur les Business](https://docs.didit.me/fr/entities/businesses/operations.md) > > Créer, mettre à jour, modifier le statut et supprimer les entités Business. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.