# Monitoring AML continu Source: https://help.didit.me/fr/aml-screening/ongoing-monitoring Updated: 2026-10-12 Le monitoring recrible chaque jour les sessions approuvées contre les listes à jour et les déplace vers En révision ou Refusée selon vos seuils. 0,07 $ par an. Le monitoring recrible les sessions approuvées **quotidiennement** contre les listes mises à jour, pour les sessions sur lesquelles vous l'activez. Une nouvelle correspondance au-dessus de votre seuil de revue déplace la session vers **En révision** ; au-dessus de votre seuil de refus, elle la déplace vers **Refusée**. Dans les deux cas, vous recevez un webhook `status.updated`. 0,07 $ par an, sans intégration supplémentaire nécessaire. [Video: Surveillance AML continue : re-filtrage quotidien et alertes webhook - Didit Academy](https://www.youtube.com/watch?v=NZwrHM9qqnU) ## Pourquoi un cribage unique ne suffit pas Le cribage à l'onboarding vous indique ce que les listes disaient ce jour-là. Des désignations sont ajoutées, les médias négatifs s'accumulent, et quelqu'un qui était clean en mars peut être sanctionné en août. Si votre obligation inclut le maintien à jour de la diligence client - et pour la plupart des entreprises régulées, c'est le cas - un cribage unique ne la remplit pas. ## Comment ça fonctionne Le monitoring est automatiquement disponible pour les sessions où un contrôle AML a tourné, **sans travail d'intégration supplémentaire** : ![La liste Vérifications des utilisateurs dans la console Didit avec des sessions sélectionnées et l'action Surveillance continue](https://help.didit.me/screenshots/sessions-bulk-light.webp) *Le monitoring est activé pour les personnes que vous choisissez de continuer à surveiller.* 1. **Contrôles quotidiens automatisés.** Chaque session approuvée dont le monitoring est activé est recriblée contre l'ensemble des listes de surveillance et de sanctions. 2. **Comparaison des seuils.** Les nouveaux résultats sont comparés aux mêmes seuils de revue et de refus configurés dans votre workflow. 3. **Changement de statut.** Une nouvelle correspondance au-dessus de votre seuil de revue déplace la session vers **En révision**. Au-dessus de votre seuil de refus, elle la déplace vers **Refusée**. 4. **Webhook.** Votre application reçoit un webhook `status.updated` avec le statut mis à jour et les détails des nouvelles correspondances, dans le même format que n'importe quel autre webhook. 5. **Console.** Le changement apparaît sur la session avec les nouvelles correspondances prêtes à être traitées. ## Ce pour quoi il faut concevoir **Une session approuvée peut changer de statut plus tard.** Si votre intégration traite Approuvée comme définitif et arrête d'écouter, vous manquerez exactement les événements que le monitoring existe pour livrer. Concrètement : - Continuez à traiter `status.updated` pour les sessions que vous avez déjà marquées comme vérifiées. - N'ignorez pas un webhook parce que la session est une session que vous avez close il y a des semaines. - Rendez votre propre état utilisateur capable de sortir à nouveau de « vérifié » - ce qui est en général le changement le plus difficile, car c'est une décision produit, pas seulement un gestionnaire d'événement. > **Warning:** Les webhooks ne se déclenchent que quand le statut **change réellement**. Pas de > nouvelle correspondance au-dessus du seuil signifie pas d'événement : le silence > est donc le cas normal et n'est pas une preuve que le monitoring ne fonctionne > pas. Si vous avez besoin d'une confirmation positive, vérifiez la session dans > la console plutôt que d'attendre un webhook qui, à juste titre, ne viendra > jamais. ## Ce que ça coûte **0,07 $ par an** par personne surveillée. Payé avec le crédit de votre offre ou votre solde. Tarifé annuellement plutôt que par cribage, de sorte que la cadence quotidienne ne multiplie pas le coût - c'est ce qui rend le monitoring continu abordable en volume plutôt que quelque chose à rationner. ## Activer et désactiver Il existe trois interrupteurs, et chacun nécessite l'accès en écriture aux vérifications : - **Dans le workflow**, aux côtés de l'étape AML, pour les nouvelles sessions. Il est désactivé par défaut. - **Pour les sessions que vous avez déjà**, sélectionnez-les dans **Vérifications des utilisateurs** et cliquez sur **Surveillance continue** dans la barre qui apparaît, puis sur **Activer** pour toutes. Les sessions sans étape AML sont ignorées. - **Sur une seule vérification**, avec l'interrupteur **Surveillance continue** de sa section AML. Le désactiver arrête le recriblage quotidien à partir de ce jour ; ce qui a déjà été trouvé reste sur chaque vérification. ## Prévoir la conséquence Ce que les équipes sous-estiment n'est pas l'intégration, c'est que le monitoring génère une file récurrente. Une nouvelle correspondance demande le même travail de résolution qu'une correspondance à l'onboarding : est-ce votre client, est-ce que ça compte, consigner le raisonnement. Voir [traiter les alertes AML](https://help.didit.me/fr/aml-screening/resolving-aml-hits). Si personne ne prend en charge cette file, le monitoring produit des alertes qui restent non lues, ce qui est pire que de ne pas surveiller du tout : vous avez désormais la preuve qu'on vous a informé et que vous n'avez rien fait. ## Le monitoring n'est pas le monitoring de transactions Deux choses différentes aux noms similaires : - **Le monitoring AML** recrible la *personne* contre les listes au fil du temps. C'est cet article. - **Le monitoring de transactions** évalue les *transactions* par rapport à des règles au moment où elles se produisent. Voir [comment fonctionne le monitoring de transactions](https://help.didit.me/fr/transactions-monitoring/transaction-monitoring-basics). Vous aurez probablement besoin des deux, et ils sont facturés séparément.